  |
はてなキーワード: テキストエディタとは
タイトル通り。どこに質問を書けばいいのかわからず、とりあえず増田に書いておく。OSはWindows7
状態としては、firefoxとか使ってるときにvやcやhといった一部のキーが動作しなくなる。firefoxだけかと思ってたらTween（twitter用のソフト）でも使えなくなったりする。場合によってはdを押すとウィンドウがすべて最小化されたりする。
固定キー機能ってのは、特定のキーがずっと押されたままの状態になってしまうクソ機能。右のシフトキーを5回押したりすると出てくるアレね。Win＋Dでウィンドウ最小化できるため、固定キー機能でWinキーがオンになってるんじゃないかと考えた。
ところが、固定キー機能をオフ（コントロールパネル→コンピューターの簡単操作→キーボード動作の変更→固定キー機能を有効にするのチェックを外す）にしても同様の現象が発生。しかも全部のソフトで起こるわけではなく、『Tweenとfirefoxではhキーが押せないけどテキストエディタだと問題ない』みたいな状態なのが非常に厄介。
キーボードの故障も考えたが、現象発生中に別のキーボードに交換しても同様の現象が続いてるため、OS側の問題なんじゃないかと考えてる。
まだOSの再インストールしてないんだけど、再インストールするとデータのバックアップとかがすこぶる面倒なので出来れば避けたいところ。yahoo知恵袋とか探しても『キーボードの故障だね！ 買い替えなよ！！』って回答しか見つからない。どうしたもんか。
最近、報道も下火になってきたようなので、我が家のベネッセ顛末を記録しておく。
xxxx+benesse@yyyy.com みたいなメアド宛に迷惑メールが届き始める。
xxxx+benesse@yyyy.com は、ベネッセ提供のサービスに自分のアドレスとして登録したもの。当然、ベネッセのサービス以外には使っていない。
Web経由で、ベネッセに問い合わせ。情報漏洩などの事実がなかったか、調査と回答を依頼。
登録内容の確認などを挟み、2往復目で以下の回答。要は、
ということ。
平日にまとまって対応できるような時間もなく、交渉のプロを相手に変な言質を取られるのもイヤだったので、何かあれば電話ではなくメールでやりとりしたい旨を連絡。
引き続きセキュリティには気をつけるといった旨のメールを受領して、いったん終了。
ベネッセの情報漏えいの報道を受け、やっぱりオレ様の情報が漏えいしたのでは? と改めて確認。
オレ様のメアドは漏えいしていないとの回答。加えて、業務外や社外からの不正アクセスはなかったことも改めて確認たとのこと。
この時すでに、報道で、内部関係者が通常業務を装って不正に情報を持ち出したことが分かっていたため、「業務外や社外からの不正アクセスはなかった」確認だけでは不十分と感じた。また、この直後にオレ様が使っていたサービスの情報も漏えいしていたと報道発表。なぜ、こうも調査が甘かったのか理由を問いただしたメールに対する回答。ほぼ平謝り状態だが、中身はない。
9月10日の個人情報漏えい事故調査委員会の報告直後、結局オレ様の情報も漏えいしていたと確認できた旨、連絡を受領。
周囲の話を聞く限り、オレ様へのお詫び対応は優先的に行われた模様。手紙が来たのがやたら早かった。
さらに1ヶ月半後、追加で2通のお詫びの手紙が来た。結局、我が家からは3件の漏えいが確認できた、ということだろう。
の2点は、正直許し難い。
調査結果によれば、6月27日に情報漏えいの可能性を認識したとのことであり、オレ様の4月の問い合わせは全く生かされていなかったということになる。また、6月27日以前にも情報漏えいを示唆する問い合わせがあったなどという記載もないようである。もう少し、顧客の声1つ1つに真摯に向き合う姿勢があれば、こんな事態を引き起こすこともなかったのではないかと思う。重箱の隅系だが、「お客様本部」の位置付けを「お客様への支援を行う専門組織」としているあたりも気になる。ベネッセの不手際で迷惑している「お客様」に対し、ベネッセが「支援」をするというのである。支援などという第三者的な言い回しではなく、ベネッセ自らが回復させるという主体性を見せてもよいのではと思う。
さらに、問い合わせフォームについても問題を感じた。こちらが投入した質問文が、問い合わせシステムから返ってこないのである。こちらがテキストエディタなどで作成した文章をコピペすれば、一応保管はできるのだが、ベネッセ側が認識した質問文を、問い合わせ元は確認できない。うがった見方をすれば、ベネッセは質問文を偽装できるのである。よく「以下のような問い合わせを受け付けました」と、質問文をそのまま返してくる問い合わせシステムがあるが、ベネッセはなぜそうしなかったか、ということである。
情報漏えいへの対策としては、今ベネッセが取り組もうとしているように、システマティックにできるようにすることが重要だとは、オレ様も思っている。しかし、さらにその上で、数十年にわたり様々な方法で個人情報を集めてきた会社としてその責務を認識し、顧客に対する姿勢がどのように変化するか、も注視していこうと思う。
ここ、数年思っているのだが、「xxxx+zzzz@yyyy.com」といったメールアドレスを受け付けない入力フォームに、よく、出くわす。「+」がメールアドレスに使えない文字だと言われるのである。はじかれたときのメッセージで「正しいメールアドレスを入力してください」というのをよく見る。
いろいろ理由はあるのだろうが、ぜひ、「+」も使えるよう、「修正」してもらいたい。「+」は、メールアドレスに使用できる文字のはずである。間違ったメールアドレスなんかでは、決してない。
何年か前だけど評判がすごいからためしにインストールして一ヶ月くらい使ったけど、無料のIMEに比べて特に便利だとか頭いいとか感じなくて、試用期間が終わったらそのままアンインストールしたことがある。
ATOKが頭いいとか使いやすいとか気のせいじゃないの? 単に慣れてるだけなのを性能いいって言ってるだけとか。
以前の職場で、PCに入れるアプリは会社が許可したものだけってことになって、ATOK、秀丸、ベッキーあたりの有料ソフトを使ってた連中が「これが使えないと仕事の効率落ちるだろ！」みたいにゴネまくって会社に買わせるってことがあったけど、仕事はVisualStudioがメインでテキストエディタなんてサクラでもEmEditerでもなんでもいいんじゃね? って感じだったわ。自分は。
「金出して買ってるんだから優秀に決まってるだろ」って思い込みなんじゃないかって気がする。
- HHKB Professional JP …… 最強のキーボード（しかも省スペース。Adobe製品を利用するには JP版が便利）
- Logicool G9x …… つまみ持ちできるゲーミングマウス（最近価格が高騰している）
- SteelSeries Kinzu v2 Pro Edition …… Logicool G9x の後継マウスとしてテスト使用中
★文書執筆
- Scrivener …… 最強の文書執筆ツール（これ以上のものはない）
- Bean …… 簡単な文書作成（複雑なレイアウトはできないが、とにかく起動が速い。PDFも書き出せる）
- Adobe Creative Cloud …… デザイン用アプリケーションはこれでいい（結局は）
- Adobe Fontfolio …… 欧文フォントコレクション（高額だが結局安上がり）
★学習
- Anki …… 効率的な語学学習（英語／ドイツ語）。iPhone版と併用して効果アップ。
★プレゼンテーション
- QuickTime Pro 7 …… ムービーデータの簡単な編集
- Keynote …… プレゼンテーション用ソフトとしての完成度が高いし見た目もよい
★開発
- Tower …… Gitによるバージョン管理ソフト（他にもあるが最初に使ったソフトだから）
- Omni Focus …… GTDによる作業進捗管理。iPhone版と併用して効率アップ。
- Omni Graffle …… 図表作成
- SQLEditor …… データベーステーブルの設計用（Mac用のこの手のソフトは数が少ない）
- BBEdit …… テキストエディタ（他にもいろいろあるが、最初に使ったソフトだから）
- Cyberduck …… FTPクライアント（動作が遅いが、特に困ることがない）
- KeyRemap4MacBook …… Finder操作まで全部キーボードでやってしまう（Emacsな人にお勧め）
- NameMangler …… 一括ファイル名操作（類似ソフトに比べると動作が早い）
- Boom …… 音声ボリュームを限界以上に上げる（プレゼンテーション時に有用＊狭い部屋なら外部スピーカーがいらなくなる）
- Synergy …… Macとウインドウズマシンでキーボード／マウスを共用
- PlainCalc …… 履歴を残しながら簡単な計算ができる
- Paparazzi …… 長大なウェブページを一気にキャプチャできる
- ATOK …… 日本語入力環境は、作業時間を大きく左右する＝時給を左右する
- SizeUp …… キーボード操作でウインドウサイズを変更
- Alfred …… キーボード操作で、アプリケーション起動／インターネット検索
- FreeMan …… マシンのメモリ使用状況を監視し、適宜開放
- ClipMenu …… クリップボードを管理／テキスト変換
付記
ClipMenu では、クリップボードに保存されているテキストを変換できる。
用意しているアクションで常用しているのは下記の通り：
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
ここらへんでおれもMacの昔話を書いてみよう。
おれが最初にMacintoshに触ったのは、91年の4月だった。配属された研究室にMacintosh IIsiがあったのだ。OSは、漢字talk6.0.7.1だったように思う。
このころのソフトウェアに対するユーザーの意識はひどいもので、不法コピーがあたりまえだった。今だから、そして、おそらくどの研究室なのかばれないと思うから書くが、使用するソフトはすべて出所の怪しいものだった。
エクセル、マックライトII (Iを使っていたという話を聞いたことがない。マイナーだったのだろうか）、マックドロー、クリケットグラフ。コピーでなかったのはテキストエディタと端末ソフトだけだったのではないか。
その使い勝手はとにかくすばらしかった。マックライトIIの威力は、学会の要旨（一段組と二段組が混在すると当時の一太郎ではプレビューしないとま出来栄えがわからなかった。WYSIWYGという概念がなかったのだ）を書くときに思い知った。
それに貼る図は、クリケットグラフで書き、マックドローで修整してから貼り付けていた。これがほんの一年前には、一太郎で書いた要旨に手書きの図を貼り付けていたという。物理的にセロテープで貼っていたのである。
…だが、それでどのくらい時間の短縮になったかというと、実はかなり微妙だった。そう、爆弾マークが出るからである。
当時は何をやっても爆弾マークが出た。日本語入力と英語を切り替えても出たし、ソフトを切り替えるときも出た。放置しているだけでも出た。ひどい時は、セーブしようとしたら出たときもあった。いったいどうしろというのか。
使い始めてすぐ、漢字Talk7が発表になった。なんだかもっさりして、爆弾が出る比率もそんなに替わらない印象があったが、漢字Talk7.1に糸井重里がつけた愛称「おにぎり」はあまりにださすぎるので今でも忘れられない。そんな名前で呼んでるやつ一人も見たことないよ。
それとほぼ時期を同じくしてMacintosh classicやLCが販売されるようになった。classicは1000ドルパソコンといわれ、貧乏学生のおれも思わず買ってしまおうかと錯乱するほどの魅力的な商品だった。もっとも日本では二十万円台後半だったように記憶している。
LC系やclassicは順当に性能向上を繰り返していたが、ハイエンドはひどいもので、92年にはCDーROMを搭載したMacintosh IIviというモデルを発表しているが、これはなんとMac IIciよりCPUのクロック数が低く、CDーROM（当時はまだ使い道がなかった）を搭載したため無駄に馬鹿でかく、もちろん定価もすごく高いというしろものだった。
「これを買うくらいならLC系を買うよねー」という人がおおかったのかMacintosh IIviは売れなかったので、数か月して価格が改定されたらしい。らしい、というのはそのころパワーマックの噂が出始めて、68系のハイエンドマシンへの需要はかなり減少していたのでおれの記憶もあやふやなのである。
そして94年になると、いよいよパワーマックが発売されるのだが、これがまた遅い、高い、馬鹿でかいという端にも棒にもかからない代物であった。
その他にもレーザーライターNTX-Jがなんと定価120万円で発売されていたり、フォント関係のライセンスのひどさはちょっと混沌としていすぎていた。
まあ、色々と書きたいことはあるのだがおれはおじさんであるのでここらへんが体力の限界だ。
誰か有志がおれのあとを継いでアップルのこっちの足元を見たぼったくり体制を批判してくれ。
それではおやすみなさい。
vimは英語圏のテキストエディタなので日本語の編集には不向き。
英語は単語がスペースで区切られているから、単語単位での編集コマンドが生きてくるけど、
日本語にはスペース区切りの習慣は無い。
あと、モード切替時に一々日本語入力をオン・オフしなくちゃいけないのも不満。
（解消するプラグインあるらしいけど、標準では付いてない）
http://anond.hatelabo.jp/20140222185627
A HAPPY END WITH YEAR 2013 !
こう書き換えたいとき
A HAPPY NEW YEAR 2014 !
不便なテキストエディタでは、
→を８回、Delを３回、N、E、W、→を１回、Delを４回、Endを１回、←を２回、バックスペース１回、4、と入力する羽目になる。
でもこれって実は１１回で書き換えられる。
そう、Vimならね。
でもこれって実は１０回で書き換えられる。
Ctrl+{RIGHT}
Ctrl+{RIGHT}
Ctrl+{RIGHT}
Ctrl+Shift+{RIGHT}
{DELETE}
{END}
{LEFT}
{LEFT}
{BackSpace}
4
テキストエディタ使ってんのってRuby,Pythonあたりのスクリプト言語の人でしょ。
そんでスクリプト言語の場合だと、REPLで気軽に動作確認できるから、IDEほど補完が強力じゃなくても、不利にならないんじゃなかろうか。
かつてはVim対Emacsでガチ戦争があったが、最近ではどっちも大差ないと認識が広まってきのこたけのこ戦争となった。
対してこれらのエディタとVisualStadioやEclipseのようなIDEの間には今こそガチ戦争が勃発している。
数で圧倒的に有意に立つIDEユーザと本物のプログラマを自称するエディタユーザの争いである。
エディタユーザはIDEユーザを能なしと罵っていて、それに一理あるという風潮があると思うが、騙されてはいけない。
致命的なのはエディタではIDEのような補完入力ができないのだ。
これなしでどうプログラミングするというのか。
あるいは自分一人でコーディングするような場合も問題ないだろう。
まさかいちいち対象クラスのコードやドキュメントを読むというのか。
覚えておけばいいと言う人もいるが、バカも休み休み言えといった感じだ。
そういうことを言う人は、コンパイラも使わず機械語直打ちなプログラミングやってればいいよ。
きっと素晴らしい情報処理能力でみるみるうちにコードを完成させてくれるだろう。
まあ、実際には一月かかっても２分木ヒープも実装できないだろうけど。
また、リファクタリングやプロジェクト管理も一貫してできるIDEは単なるテキストエディタなど物ともしない。
エディタ勢は、これらより便利なツール類がvim scriptやemacs lispで書かれているかのように言っているが、そんなものは実在しない。
あるなら、誰もが使っているはずだ。
というより、そんなものがあったなら、そもそもIDE自体作られることはなかったはずなのだ。
実態はない。
実態があるというなら、実際にエディタでIDEより優れた生産性でコードを書いている動画がYoutubeにあふれるはずである。
だが実際にはそんなものはない。
なぜか？
もちろん、やりたくてもできないからだ。
エディタ対IDEの戦争の正体は、エディタの生産性の低さがいつ暴かれるかと戦々恐々している自称スーパープログラマ達の、自己弁護と時代に取り残されたという怨嗟の声の集まりである。
なんか偉そうに書いてみた。
SFCには頭がおかしいプログラミング言語使いがたくさんいる。特に研究室に入ると、バイトでバリバリ書いている人間や、研究や趣味でライブラリを量産する人間に出会うこともあるだろう。彼らに惑わされてはいけない。最初は彼らの言っていることは一つも理解できないだろう、理解する必要は無い。彼らはプロダクションで安定するかどうかという縛りから自由だ。流行り廃りに敏感で、昨日言ってることと今日言ってることが違う。
これは実際に手を動かして使ってみて好感触かどうかささっと確かめられる人間だからできることで、プログラミングできない人がこれについていこうとしたら間違いなくプログラミングが嫌いになる。
こういう言葉に惑わされるな、コードを書くための勉強をするな、コードを書け。
できる人は概ね、できない人の気持ちがわからない。受動的になるな。積極的に書け。
「プログラミングなんて特殊技能で、少なくとも教養じゃないでしょ..」という認識が横行している今だけのチャンスとも言える。
webプログラミングができると「技術的には簡単だがアイデア一発で作ってみた」もので、ほんのちょっとだけ有名になれる可能性がある。論文を書いて学会に投稿したりニュースになったりするよりも、よっぽどお手軽に(一部での)社会的ステータスを高めることができる(かもしれない)。
↓ こういうのでいい（失礼だが）。
こう言っている人間を見て何を思うだろうか。
「いや少しずつでいいから今やれよ」とか「英語できたらもっと世界ひろがるのに..」とか「大学生なのにそれで恥ずかしくないの」とか思うかもしれない。
知らない世界を知らずにいることは大いなる機会損失である。プログラミングに金はいらない。金はないけど時間はある、時間を大量投入できる最後の機会、大学生である内に学んでおいた方が望ましい。
基本的なスタンスとして、講義ではプログラミングを教えてはくれない。講義に期待するな。プログラミングに限らず、全ての講義は自習への足がかりであり、興味のとっかかりである。実際に意思を持って積極的にコードを書かない限りプログラミングのことは好きになれない。自分で考えながら手を動かしてコードを書かなければ覚えないし、初学者が配られたプリントを写経しても血肉にならない。
「今日から俺は！」という感じでプログラミング講義を受けると爆死は約束された未来である。「腕試ししよう」「これなら楽勝じゃろ」という意気込みで講義を受けると、意外に学ぶことが多い。完全な初学者の域は脱しておいた方が講義は有効的に活用できる。少なくとも、最初の2週間をインストールと環境構築のみで終わらせるスジの悪い講義を取得してはいけない。
また、講師によってはJavaScriptのことをJavaと呼称したり、JavaScriptはLispに比べて読解が平易であるためハッキングを受けやすいと言ったことを平然と言ってのける。選別にあたっては「講義名」と「講師名」を明言した上で「先輩に聞く」「Twitterを活用する」等の手段をとるべきである。十二分に注意されたし。
道具を選ばないのはプロだけである。初学者は多少高くても自分をサポートしてくれる良いマシンを入手すべきである。1行のコードを書くだけでも恐ろしい手数が必要なアーキテクチャを選択するのは愚行だ。
モデルは何でもいい、無理して上位機種を買う必要は無い。お金が余ってるならMacBookProを買えばいいし、勿論一番安いMacBookAirでも全く問題ない。特にweb系のコードを書く際、インターネットで検索して出てくる記事はだいたい「OSがUNIX系であること」を前提としたサンプルである。これをWindowsの開発環境に読み替えるのは、初学者に取ってつらいだろう。
また、Macならばパフォーマンスは多少犠牲になるがwindowsも起動できる。どうしても光学機器が必要になればCNSコンサルタントで外部接続式の光学機器を貸し出してくれる。Macが気に入らなくてもどうせ研究が射程に入る3年生に上がったぐらいのタイミングでPCを買い替えるだろう。バイトして稼いだ金で「俺の考えた最強のマシン」に買い替えればいい。それまではMacを使え。
OSに固有の使い方なんて学ぶ価値はない、覚える価値も無い、操作時間が短縮されるだけだ。「普通の会社はWindowsなんでしょう？」というくだらない理由でWindowsPCを選択肢の第一候補にするな。Windowsを買うなら積極的選択としてWindowsを買え。
SFCにおいて、PCは毎日抱えて通学し、毎日開いて講義を受け、苦楽を共にする相棒だ。消極的に選択するな。
SFCには「共同購入PC」という制度がある、これを利用してはいけない。
もし要件が変更され、Macがラインナップに入れば積極的に利用するべきである。
条件を示す。
見た目に変化が無いと楽しくないだろう、こんなのを実行しても何も楽しくないはずだ。
#include <stdio.h> int main() { int a; a = 1 + 1; printf("%d", a); }
マイナーな言語を選択してはいけない。「ライトウェイト言語」と呼ばれるくくりから選択肢するのがいいだろう、以下のようなものがある。
中でもjavascriptとrubyは推薦できる、SFCでも書いている人間は多い。
phpとperlはおすすめできない。ドキュメントは多いが、不慣れであればロジック以外に割かれる労力が非常に多い。pythonは日本語のドキュメントが少ないため最初はつらいだろう。
最初にjavascriptをやるのは理に適っている。index.htmlというファイルを作り、scriptタグの中にコードを書き、ブラウザでindex.htmlを開けばもう実行されている。web上のドキュメント量も豊富だ。
rubyも推薦できるが、少なくとも「自分でHTTPサーバを立てる」という言葉にピンと来るようになってから使い始めた方がいいだろう。きっと何をしていいかわからないはずだ。
他にもProcessing(http://processing.org)などが推薦できる。ダウンロードに時間がかかるだけでインストール作業は必要ない。こちらに関しては旧プロダクト名である「proce55ing」をキーワードに検索すると記事が引っかかりやすいという暗黙のルールがあった、今はどうだか知らない。
最近ではnode.jsの採用事例も増えてきた（他に比べれば圧倒的少数、増加傾向にあるという意味）。クライアントでもサーバでも活躍できるjsは学習コストパフォーマンスが高いと思われる。
書ける言語は一つにしぼってはいけない。なるべくたくさんの言語を使ってみよ。ブログ記事を読みあさり、「その言語は何が得意なのか」調査しろ。不得意なことをその言語にやらせるな。
下記のような上達ストーリーが考えられる。
例えばpythonは音響処理や数学計算が得意だったりする。そういった特徴を徐々につかみながら書ける言語の種類を増やし、好きな言語を見つけて好きな言語のことをもっと好きになればいい。
自分が好きな言語のことを胸を張って自慢できるようになったなら、あなたは既に初学者ではない。
人に聞くとvimやemacsを推薦されるかもしれない。もしそれを使ったことが無いなら、あるいは「プラグインの導入方法がわからない」なら、やめろ。Terminalを開かなくても書けるGUIアプリのテキストエディタを使え。
具体的にはSublimeText(http://www.sublimetext.com/3)を使うのがよい、無料である。
ライセンスが必要だが、起動時に「買ってね！」というダイアログが出続けるだけで無料で使用し続けられる。信頼できるエディタだと思ったら買えばいい。
SublimeText3にPackageControlというものを導入すると、標準で備わっていない機能を拡張できるようになる。こちらのブログ(http://p.tl/Ev7b)の「インストール手順」セクションのみを実行する。たとえば「Jadeという言語を、文法に従って色付けしてほしい(SyntaxColoring)が、その機能が無い」という時に、「Jade用プラグイン」をSublimeText内で検索し、インストールすることができる。
もし使い方がわからないければ、回りにいる「プログラミングができる優しい人」に上の記事を見せ「インストールしてくれませんか？」と頼んでみろ。きっと戸惑いながらも正しい操作をしてくれるだろう、一挙手一投足を見逃さず学べ。
エロ画像を集め続けるツールが欲しいとする。どうやったらいいか考える。クライアントjsだけでは限界が来る。rubyなど別の言語を試すステップを踏む。
http://www.slideshare.net/shokai/ss-26387303
プログラマ同士じゃないと伝わりにくい用語が頻発すると思う。逐一人に聞いていてはラチが開かない。人に聞くな、適当に読み飛ばせ。
ブログ記事は本ではない、それを読解しなければならない理由はない。適当にはてブでもつけといて、次の記事を読め。たくさん読めば共通項が見えるだろう、コードが書けるようになるに従い読めるようになるだろう。
みんなが息をするようにコード書いてさ、みんなでしあわせになろうよ。
