  |
はてなキーワード: プラグインとは
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
そういうときはフォークしてカスタマイズして使ってるんだけど、いじくってるうちに不要なコードとか気になりだして気づいたら一から作ってしまうことが多い。
せっかく良かれと思ってissueを投げてきてくれた人に答えることができないから公開したくない。
issueを無効にすることも出来るけどpull requestでコメント送信できちゃうのがつらい。
学生時代はクラスメイトに無視をされてきたので、関わってくる人を無視することに抵抗がある。
言葉の壁で相手を傷つけたくはない。
超が付くほど人間関係を大事にしているわけでもなく、いきあたりばったりでおちゃらけで人と関わっているけど、無視をするということだけは譲れない。
英語を学ぶ気力がない。
休みは月3日、一日14時間労働、その後は反省会という名目の飲み会で毎日+2時間拘束されると気力が弱っていく。
プラグインを修正する度にVimを起動し直すのは時間の無駄だ。
以前見かけた素晴らしいリローダブルコードをブックマークしてあるので紹介する。
http://anond.hatelabo.jp/20150501131712
ちなみに、set allを初期化するとcommentstringを再設定しなければならなくなるので、
commentstringに依存するプラグインに影響が出るので、私はset allを初期化していない。
グローバル変数を使う場合は変数名の先頭に名前空間をつけよう。
ありきたりな名前を付けると他のプラグインに影響する可能性があるからだ。
良い変数名の付け方
名前空間の区切りは#でなくてもPHPのPSRで定義されているように_を使っても良いだろう
(Qiitaのほうに2019年版があるので今はそちらを…。こちらは2015年版な感じです。)
Vimの外でもVim風の操作ができたりするのは彼らのおかげだ。
デフォルト、オプション、プラグイン、アドオン、様々な手段で提供されている。
Vimを使っている人でも使うかどうかは人それぞれだし、
どの程度Vimを再現できているのかも実装によってまちまちなのだが、
なんだかんだで有名どころのテキストエディタや統合開発環境では何らかの形で提供されることが多くなったように思う。
(一覧に無いものは私が知らないか忘れているだけなので、実際にはまだあると思う)
| 統合開発環境 | 名称 |
|---|---|
| Visual Studio | VsVim |
| Xcode | XVim |
| Eclipse | Vrapper |
| NetBeans | jVi |
| IntelliJ IDEA | IdeaVim |
| MonoDevelop | Vi Mode |
| Qt Creator | FakeVim |
| テキストエディタ | 名称 |
| Emacs | VIP |
| Emacs | Viper |
| Emacs | Evil |
| Atom | Vim mode |
| Atom | vim-mode-plus |
| Sublime Text | Vintage |
| Sublime Text | Vintageous |
| Brackets | vimderbar |
| Visual Studio Code | Vim |
| Light Table | Vim |
| ブラウザ | 名称 |
|---|---|
| Firefox | Vimperator |
| Firefox | VimFx |
| Firefox | Vimium |
| Chrome | Vimium |
| Chrome | Vrome |
| Chrome | Vichrome |
| Chrome | cVim |
| Opera | VimOperate |
| Opera | wasavi |
| Safari | sVim |
| Safari | vimari |
いくつかのコマンドでも。
| コマンド | 分類 |
|---|---|
| bash | シェル |
| zsh | シェル |
| ksh | シェル |
| tcsh | シェル |
| yash | シェル |
| tig | gitインターフェース |
| less | ページャー |
| cgdb | デバッガ |
| LuaKit | Webブラウザ |
| 名称 | 操作 |
|---|---|
| jkで前後の項目に移動 | |
| TweetDeck | jkで前後の項目に移動 |
| jkで前後の項目に移動 | |
| Google+ | jkで前後の項目に移動 |
| Tumblr | jkで前後の項目に移動 |
| GitHub | jkで前後の項目に移動 |
| jkで前後の項目に移動 | |
| Pixiv(複数投稿) | jkで前後の絵に移動 |
| ニコニコ静画(漫画) | jkでスクロール |
| ニコニコ静画(電子書籍) | hjklで前後のページに移動(wasdでも可) |
| はてなブックマーク | jkで前後の項目に移動 |
ゲームも。
| 名称 | 操作 |
|---|---|
| nethack | hjklで上下左右に移動(yubnで斜め移動) |
＞ viのhjklは先行する何かの影響で実装された記憶があるので、操作が共通だからというだけで「viを忍ばせる」というのは言い過ぎではないかという気がする
＞ まして「vimを忍ばせる」というのは、ちょっとその、まあなんというか…
確かにVimではなくviの模倣だったりして無理があった…。hjklの大元を辿るとどこに辿り着くんだろう(ビル・ジョイの使っていたキーボードとは別？)
http://anond.hatelabo.jp/20151222002334の元増田だよ！
思いの外レスが付いてびっくりだよ！！スラドで見た時は流石にびっくりしたね！
適当に書きなぐったのでまあNeo****を害悪だとかなんとか言ったけど、まあちょっと言い過ぎたかなっては思ってる
でもね、初手からNeo****でプラグインを入れるのを勧める記事が溢れているのはやっぱり害悪だと思うな！
せめてなれてから(vimtutorを終わらせてから)入れるべきじゃないかな？
あ、でも勘違いされないように言っておくけどLingrのみんなはちゃんとOSS活動やってて偉いなって思ってるよ！煽りじゃなく。
ほんとはだんまりしてるつもりだったけど、気になったコメントが有ったから返信するよ！
http://anond.hatelabo.jp/20151225003934
ただwとかiとか書いてある記事は不要、ないほうがマシっていう意見は変わらない
せめて先頭の方にvimtutorって書いてあればまあまだ許せるけどね
あとset -o viだけど、（ちなみにスラドでset -o viはbashでbashはニワカって書いてあってわろた）
set -o emacsのほうが使いやすいと思うよ。主観だけどねｗ
なんでかっていうとシェルではテキストオブジェクトを使えてうれしい時が少ないから。
あとDo one thing...はエディタにも当てはまると思うけどなあ。そんな否定することじゃないんじゃない？まスラドのみんなの意見も聞きたいとこだね！
まー結局誰がどう何を使おうといいんだけどね、昔からのvimユーザーとしてvim使いにあらずんばエンジニアにあらず（まあそこまでじゃないけど）、みたいな風潮がf*ckだと思う
（また主観がどうのとか言われると思うけど、実際のブコメとかでもそういうコメントあったからね、少なくとも俺以外もそう思ってる人は少なくないと思うよ
が、リニューアルされても突っ込みどころが満載なので、http://anond.hatelabo.jp/20150508190512に引き続きこき下ろす。
「エターナル青春系ブラウザ」と名乗らなくなったほか、「便利なブラウザを作りたい!! 答えは意外と簡単でした」のようなブラウザ開発者にとっては挑発的なフレーズがなくなり、「ユーザの声で進化するブラウザです」にトーンダウン。
ただし、「エターナル青春系ブラウザ」が完全に消えたわけではなく、本体のバージョン情報やD社のホームページには残ったままだ。これからどうするのかは知ったことではない。
不評だったのか知らないが、リニューアルとともにいなくなっていた。
これって最初から、つまりユーザーの意見を聞く前からついてませんでしたっけ？
「ユーザーの許可なく送信されるスパイウェアやアドウェアの排除や、Kinzaと無関係なソフトウェアの追加インストールはしません」
これだと、スパイウェアやアドウェアの排除をしないことになってるけど。
イメージダウンに直結するので、これは多分すぐに直ると思うが。
リニューアル前の文は「(中略)スパイウェアやアドウェアの排除はもちろんのこと、(中略)無関係なソフトウェアを追加インストールしません」だったので、まともな校正ができていないだけだろう。
まさか、「スパイウェアやアドウェアの排除はもちろん(しません)」じゃないよね？
突っ込みが多方面から来たのだろうか。ようやく当たり障りのない「Chromiumと同性能」に変化したようだ。
ただ、後述する「ブラウザ開発サポート」を見ると、本当はChromeと同等じゃないと言いたくないがために変えたのではないかと疑いたくなる。
ただブラウザ作ってるだけだと儲からないのか、ブラウザ開発の手伝い(受託？)とかリサーチもやるらしい。ページにはChromiumを使った専用ブラウザやそのプラグイン開発を手伝うと書いている。
しかし、Chromiumのことを「Google Chromeと同等の機能を持ち」と書かれているのは相変わらずで、ChromiumとChromeの違いさえ明確にしないようなところに誰が問い合わせするだろうか。
やっぱり勘違いしているんだろうか。それとも、自社製品がChromeと同等じゃないと言いたくない理由でもあるのだろうか。
もし問い合わせする場合は、この部分を徹底的に突っ込むべきである。
トップページはまだまだ洗練されていない感じがする。自発的でない開発態度も相変わらずのようだ。わかったことは、文章を校正できる人がいないことぐらい。
リリース間隔は以前よりはましになって、Chromiumの安定版のバージョンに比較的早くついてきているようだ。自ブログで募集していたのだから、少しはリソース強化できたのだろう。
にもかかわらず、ポータブル版、64ビット版、ベータ版をまだ出さない。これが、元Operaの創業者が代表で人的リソース確保ができていてユーザーさえ確保できればマネタイズプランも見えているブラウザVivaldiとの違いかな。差は開く一方である。
ここ2,3年くらい、Vimが妙に流行っている。はてブやqiitaでもVim関連のページが出れば大量にブクマがつくし、「俺はVim派だから」みたいな発言を大学だったりtwitterだったりでもみる。
しかしその実、世間に出回る「vim tips」みたいなのをみると、cやr,はたまたw,$,0,..など超がつくほど基本的なものしか載っていない。
なんでこんな常識的なものにこんなにブクマつくの？？？っていっつも驚く。
昔はvimに憧れるワナビーがブクマをつけてるのではないかと思っていたが、どうやら今のネット界隈では「vim派」と言って通ぶることが一種のステータス？になっているのではないかと思うようになった。
ちょっと前に流行ったvim pluginブームにもびっくりした。vimはあくまでもIDEなんていらないスクリプトを書いたり、CUIでエディットしたい時に使うものだろう。
ものには使いみちというものがある。文章、少なくとも日本語はVimに向かないし、Javaの開発ならeclipseですらvimよりよっぽど生産性が高い。
vimにpluginなど入れて喜んでいる一部の人達をみると、やはりvimで通ぶっているだけではないかと思えてしまう。
.vimrcは長けりゃいいっていうものではない。それがemacsに対するvimの美徳のひとつではなかったのか。
そもそも、vim人口が見かけ上増えているにもかかわらずemacs人口が増えていないのがおかしい。どうも最近のvim派の人たちはemacsをあまりうまく使えていないようである。（俺のまわりだけかもしれないが）
昔のhackerはエディタ戦争なんて言いながらもお互い両方のエディタを使えたものだ。大体がshellでset -o viなんてしたら使いづらくて仕方がない。shellはctrl-aで先頭に戻るし、ctrl-rで履歴検索をするものである。
そもそもエディタ戦争なんて洒落にすぎないんじゃないかと個人的には思っている。viとEmacsは基本教養である。どちらかしかできないのは文盲のようなものである。
vimvim言ってブクマしてるみなさん、vimtutorは起動したことありますか？Vim関連の記事を100個ブクマするよりよっぽど有用です。
Do one thing and do it wellって知ってますか？一つのプログラムでなんでもしたいならwordかVSで十分です。無理してviを使う必要はないです。
俺はまだLinuxを使い始めて10年くらいだけれど、エディタはvi(m)一筋だった。
何がいけなかったのだろうか。
あとviとvimがうんぬんというブコメありましたが、逆に今日びviとvimを使い分けることがあるんでしょうか…？
（もちろんインストール直後のdebianとかだとvim.tinyしか入ってないけど）
普通/usr/bin/viってvim.basicを指してることが多いと思います。もしvim.tinyを指していたらごめんなさい。
てかaliasなりupdate-alternativesみたいなの使われたほうがいいのでは…？
id:akanehara （増田はじめてだからよくわかんないけどブコメに返すのこれでいいの？）
いやね、俺はNeoなんちゃらとかなんちゃら.vimとかのプラグインが流行りまくってるのどうかと思うんよ。
vi使いたくてあんなゴタゴタした画面分割するならtmuxかscreenで別タブにシェル開けばいいしそのほうが拡張性高いじゃん…っていう。
それかVSなりIntelliJで（ちなみに俺はeclipse使います。微妙にdisったけど）
あとはSIGSTOP（てかSIGTSTPか）で止めるのもよい使い方だと思う。
とにかくこれからviなりunixを使い始める人達がああいう害悪に影響されてほしくない。Neoほげほげよりtmuxとかctrl-zのほうがのちのちず～～～っと役に立つから。
viが流行ること自体はいいと重います。emacsももっとはやって欲しいです。nanoは即update-alternatives --config editorするんで知りません
と思ったらなんかみなさんいろいろ考察してくださっていますが、今やviクラスタ≠unixクラスタなのか…
なんてこったい
TeXは確実にGUIのほうが使いやすいよ。俺はTeXstudioだけど、シェアウェア買ってる人もいるね。特に仕事道具にしてる人は。
vimじゃあPDFからジャンプとかできないから校正の時とか使いづらいことこの上ない
一理ある
問題はvim scriptはelispに劣ってるところだと思う。
言語プラットフォームとしてみたときやっぱりemacsには一日の長があるよ
なのにpluginとか言って喜んでるのはなんか違うと思うなあ。
今日NeoBundleUpdateでプラグインをアップデートしてからVimを再起動し直すと、ファイルを開いても何も表示されなかった。
まだ直らなかった。
引数に-u NONE を付けてファイルを開いたらファイル内容が表示された。
おおお治った。
今日更新されたプラグインでNeoBundleが原因であることが分かった。
ツイッターでNeoBundleについて検索したら同じ症状の人がいたから元凶はNeoBundleにあると確定だ。
やらかすの何度目だよいい加減にしろ。
あと、お前すぐissue閉じ過ぎなんだよ。一定期間はオープンにしとけよ。
この作者、他人のプラグインをよくdisってたので、俺も遠慮なく記事にさせてもらった。
作者が見なくてもいいようにエゴサでもしない限り閲覧できないようにここに書いてるのに、
わざわざlingrに貼り付けて事を大きくしようとしているのはどっちだよ。
悪意があるのはコミュニティーで拡散しているお前や便乗で批判に乗っかってるお前だろボゲが。
JavascriptやPHPでもタイポ指摘してくれるvimプラグインぐらいありそうだけど。
ためしにぐぐったら、 syntasticとか出たけど、それじゃ駄目？
vimは変態紳士用と言われるだけあって慣れるのにかなり時間がかかり、学習コストも高めだが、
慣れてくると非常にコーディング速くなる。
体感的にはvimにしてからコーディングが2倍〜3倍程度は速くなっている気がする。
しかもまだまだ、プラグインや設定を突き詰めることで、もっと速くなるであろうことも感じられる。
そのほかにもvimを使い始めてからコマンドラインに恐怖感を感じにくくなったし、よりlinuxに親しめるようにもなった。
そんなことから個人的には vimに移行してよかったと思っているのだが、その反面あまりうれしくない副作用も出ている。
vimの操作ではカーソル移動をhjklキーで行うのだが、vim以外のソフト（特にエディタ）の時もhjklでカーソル移動をしようとしてしまう。
また、他にも、モード切り替えのiやjj打鍵、ddで行削除、xで一文字削除、oで改行空行挿入、yyで行コピーなどなどが出てしまう。
vimの操作は体に染み付くと考える前に操作してしまう中毒性があるようだ。
vimで日本語を打つのはあまり便利ではないので（まだ日本語打ちを便利にする設定を知らないので）、
ブログなどを書く時はマークダウン形式のブラウザエディタなどをつかっているが、操作体系の意識的な切り替えが大変だ。
強い薬には強い副作用ということか。
どっちももうできてるよ。ある程度は。
アプリケーション付属のマクロ機能で簡単な自動化をするのだってプログラミングだし、MMDでありもののモデルに簡単なモーションつけるのだってアニメーションだ。
まあ、元増田の言いたいのはそういうことじゃなくて、独立したアプリケーションそのものを作っちゃうようなプログラミングだとか、TVで放送されるようなアニメなんだろうけど。そこでちょっと考えてほしい。
今、なにかすごい機械があって、プログラミングのことを知らないでもそれを使うと商用プログラムみたいなのが作れるとか、あるいは絵を書けなくても商業アニメに匹敵するようなオリジナルアニメが作れる、のだとしよう。
そしてあなたの頭の中には、欲しいプログラム、あるいは見たいオリジナルアニメがある。あとは機械を使ってそれを現実化するだけだ。
さて、どうやってあなたの頭の中にあるそのイメージを機械に伝える? あるいは機械が出してきたものが自分の頭の中にあるイメージと違っていたとして、それをどうやって機械にフィードバックする?
本当に欲しいものを機械に指示するには、細部まで---少なくとも自分がこだわりたい精度まで---の詳細を一旦情報として外部化する必要があるな。これはたとえ脳に直接プラグインが可能になったとしてもだ。見たいものを細部まで思い描けなけりゃ、伝えることはできない。
どうやって必要な情報を漏らさずに網羅する? そのために最も確実で最も簡単な方法は、何らかの言語を使う(プログラム)か、具体的な図形表象を使う(アニメーション)か、だと思うよ。
(別の方向として、コンピュータに勝手に創作させて、それに注文をつけることで自分の望むものへ近づけてゆく、という手はある。自分がプロデューサの立場になって、コンピュータをクリエータとして使って欲しいものが出てくるまでダメ出しを続けるわけだ。でもその方向は(1)自分の欲しいものを手に入れるのに多分ものすごい手間がかかるんじゃないか (2)できたものは果たして自分が作ったものなのか、という議論はあるだろう。)
(もひとつの方向として、コンピュータをサポート役として使って自分の不得意をカバーしてもらう、という手はある。人体デッサンが不得意でも使いやすいリグが組まれた人体モデルがあればそこそこポーズは作れるかもしれないし、制約を含めた人体の動きのシミュレーションをやってくれるソフトがあれば「ここからここまで歩く」を一発で作れるかもしれない。それは今あるツールの延長線上に自然にあるものだろう。そういうのを使いこなすことで、従来要求された表現技術が無くても作品が作れるようになる可能性は高い。けれどもそれって、別の種類の表現技術の訓練が必要になったってだけだと思うよ。そういうツールを使いこなす技術がね。)
シルバーウィークやることもないし、何か勉強でもしようかなぁとか思ってるひと、ここはひとつ「オトナのサイト」でも作ってみます？
こんにちは。少し前にアレを書いた者です。
http://anond.hatelabo.jp/20150731164453
実はアレがなかなか好評だったようで、気を良くした私はまた何かできないかと思い、
無い知恵を絞りに絞って出てきたのが『XVIDEOS動画まとめサイトの作り方講座』を公開することでした。
ネットには「簡単に月収100万円！」とか「たった1時間の副業で月10万円！」といった、うさん臭い情報商材が山ほどありますが、
あれ申し込んでみたら実は「アダルトサイトを作ってみよう！」だったりするわけです。
あんなのに大金払うくらいなら、とりあえず安いレンサバ＋WordPressで作ればいいだけじゃんとか思ってました。
だってあんな情報1000円くらいの価値しかないですから。いや100円かな。10円でもいらないか。
私はかれこれ10年以上、サイト運営だけで生計を立てているので、多少なりともノウハウ的なものはあるつもりです。
そんな経験や知識を全部さらけ出したものができたら面白いんじゃない？と思ったわけです。もちろん無料で。
それで作るにあたってまず最初にどんな事を書こうかリストアップしてみました。
と有頂天でさっそく書き始めてみたものの、なにこれ超大変じゃん…。書いても書いてもゴールが全然見えないじゃん…。
面倒くさい気持ちを必死で抑え、辞めたい衝動を酒でごまかし、あまりのストレスからキャン玉を握りつぶしてしまうアクシデントに見舞われながらも、
1カ月かかってやっと完成したのがこちらです。
まだまだ足りないところはあるかもしれませんが、初めてサイトを作るときに知りたい初歩的なことや、
既にサイトを運営している人向けの実践的な内容だったり、長期的に稼ぐための広告掲載のコツだったり。
