テスト駆動開発を初めて取り入れようとした時には、準備が大変でした。自動化の仕組みを用意するのも結構手間がかかりましたし、テストのためのプログラムを書くことも、最初はどう書けばいいのかを調べながらやったので時間かかりました。
でも、実際自動化テストを書いてやってみて、それで本当に心から思ったんですが、開発している時の安心感が全然違いますね。特に、ある部分の変更が別の部分に影響してないかどうかを判断する際には、自動化テストがあるのと無いのとでは、手間が全く違います。
僕はWebアプリの開発をずっとやってきたわけですけれど、自動化テストを取り入れていなかったプロジェクトの時は、何か変更を加えたら、影響を受けそうな怪しそうな部分を全部ブラウザ上で動かして手動と目視で確認していましたからね。非常に手間がかかっていました。自動化テストがあれば、テストを実行して放っておけば完了します。テスト実行中に別の作業もできますし、効率は比べ物になりません。
結果的に、テストプログラムを書く手間は後になって回収できているのですね。最初の自動化テスト用の環境構築とテスト用プログラムの記述の部分でハードルがありますが、頑張って乗り越え、自動化テストを導入する価値は十分あると思います。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月31日月曜日
2014年3月30日日曜日
フルスタックエンジニアって結構よくある話だよね
なんか最近フルスタックエンジニアってキーワードを目にして、なにかと思ったら、「インフラからミドルウェア、モバイル、デザインまで、あるいは設計からプログラミング、デプロイまで、何でもこなせるエンジニア」ということらしい。
ほう、僕の時代が来たか、って思ったんですけど、よく考えて見れば、別にこれって珍しい訳でも何でもなく、例えば比較的小規模のプロジェクトでは、一人のエンジニアが様々な仕事をこなさなければいけないので、自然とフルスタックエンジニアになるんですよね。Web系でしたら、自分でサーバを用意し、ネットワークやOS周りをセットアップし、要件定義・設計・開発・テストを実行し、デプロイまで行う。さらにメンテもする。そんな感じで仕事してれば一通りできるようになりますよ。
逆に言えば、１つの分野（例えばDB設計だったらDB設計だけとか）に依存している人にとっては、今後厳しい時代になるのかな、と思います。皮肉なことにそういうのは大規模プロジェクトに多く、大規模なプロジェクトに多く関わった人ほど自分の専門分野以外のことを何も知らなかったりします。だから大規模プロジェクトの経験イコール良い経験だとは限らないですね。
ということで、僕と同じように中小規模のプロジェクトで何でも屋のようにあらゆる作業を任されてきたフルスタックエンジニアの皆様、いよいよ我々の時代のようですよ？
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
ほう、僕の時代が来たか、って思ったんですけど、よく考えて見れば、別にこれって珍しい訳でも何でもなく、例えば比較的小規模のプロジェクトでは、一人のエンジニアが様々な仕事をこなさなければいけないので、自然とフルスタックエンジニアになるんですよね。Web系でしたら、自分でサーバを用意し、ネットワークやOS周りをセットアップし、要件定義・設計・開発・テストを実行し、デプロイまで行う。さらにメンテもする。そんな感じで仕事してれば一通りできるようになりますよ。
逆に言えば、１つの分野（例えばDB設計だったらDB設計だけとか）に依存している人にとっては、今後厳しい時代になるのかな、と思います。皮肉なことにそういうのは大規模プロジェクトに多く、大規模なプロジェクトに多く関わった人ほど自分の専門分野以外のことを何も知らなかったりします。だから大規模プロジェクトの経験イコール良い経験だとは限らないですね。
ということで、僕と同じように中小規模のプロジェクトで何でも屋のようにあらゆる作業を任されてきたフルスタックエンジニアの皆様、いよいよ我々の時代のようですよ？
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月29日土曜日
VimとEmacs両方に慣れておくべき理由
エディタ界の２大巨塔といえば、言わずと知れた Vim と Emacs でございますが、まあ僕は不毛な宗教論争に関わるつもりはありませんので、どっちを使うべきだなんて言うつもりは毛頭ございません。
学生時代にUnix/Linuxに触って最初に使ったエディタがEmacsでした。その頃はVimは全く使わず、Emacsで全てのテキスト編集を行っていた時期が２年くらい続いたと思います。Lispでカスタマイズも色々やりました。
ある時とある先輩にVimを強力にお勧めされて使い始め、慣れるために卒論を全部Vimで書いたことでVim使いになりました。慣れるまでには結構苦労しましたけど、慣れると便利ですよね。プログラミングをするなら断然Vim派です。普段使うエディタはVimになっていきました。
こんな経緯があって、両方のキー操作の流儀を身に付けたんですが、普段エディタとしてはVimを使っていますが、Emacsのキー操作でテキストを編集することも結構あるのです。
例えばメールを書く時は、昔はメーラー、今はGmailを使いますけれども、この時はEmacsのキー操作を使います。WindowsでしたらAutoHotKeyなんかで結構簡単に実現できますし、MacだとデフォルトでEmacs風のキー操作を受け付けてくれます。。それに限らず、テキストエディタ以外の部分でのテキスト入力はほぼすべてEmacsのキー操作でやっています。
その上で、テキストエディタはVimですね。カーソル移動やコピー＆ペースト、入力などを使いこなすと非常に便利で、繰り返しになりますけれどもプログラミングをするなら断然Vimが快適です。
ということで、Emacs風のキー操作とVim風のキー操作の両方に慣れておくと、状況に応じて使い分けられて便利ですよ、という話でした。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
学生時代にUnix/Linuxに触って最初に使ったエディタがEmacsでした。その頃はVimは全く使わず、Emacsで全てのテキスト編集を行っていた時期が２年くらい続いたと思います。Lispでカスタマイズも色々やりました。
ある時とある先輩にVimを強力にお勧めされて使い始め、慣れるために卒論を全部Vimで書いたことでVim使いになりました。慣れるまでには結構苦労しましたけど、慣れると便利ですよね。プログラミングをするなら断然Vim派です。普段使うエディタはVimになっていきました。
こんな経緯があって、両方のキー操作の流儀を身に付けたんですが、普段エディタとしてはVimを使っていますが、Emacsのキー操作でテキストを編集することも結構あるのです。
例えばメールを書く時は、昔はメーラー、今はGmailを使いますけれども、この時はEmacsのキー操作を使います。WindowsでしたらAutoHotKeyなんかで結構簡単に実現できますし、MacだとデフォルトでEmacs風のキー操作を受け付けてくれます。。それに限らず、テキストエディタ以外の部分でのテキスト入力はほぼすべてEmacsのキー操作でやっています。
その上で、テキストエディタはVimですね。カーソル移動やコピー＆ペースト、入力などを使いこなすと非常に便利で、繰り返しになりますけれどもプログラミングをするなら断然Vimが快適です。
ということで、Emacs風のキー操作とVim風のキー操作の両方に慣れておくと、状況に応じて使い分けられて便利ですよ、という話でした。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月28日金曜日
vimdiffの色設定を変更して見やすくする（黒背景用）
Linuxにおける差分表示ツールとしてはdiffコマンドがありますけれども、複雑な変更になってくるとvimdiffが使いやすい場面も多々あるわけでございます。特に横に並べて比較できるのは大きなメリットですよね。
ところが、デフォルトの設定ですと結構色が見辛いわけで、何とかしたいわけです。ちょっと検索して調べてみましたが、自分が思うような色設定がどっかに載ってたりとかしなかったので、自分で設定してみることにしましたよ。いつも黒背景で使っておりますので、そこに最適化してあることにご注意ください。
というわけで、下記の記述を .vimrc に加えればOKです。
これでvimdiffコマンドを実行するとこのようになります。
背景の色を差分の種類によって分けており、追加行は緑、削除行は赤、変更行は青で変更部分が明るい青になってます。
これでだいぶ見やすくなるんじゃないかと思います。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
ところが、デフォルトの設定ですと結構色が見辛いわけで、何とかしたいわけです。ちょっと検索して調べてみましたが、自分が思うような色設定がどっかに載ってたりとかしなかったので、自分で設定してみることにしましたよ。いつも黒背景で使っておりますので、そこに最適化してあることにご注意ください。
というわけで、下記の記述を .vimrc に加えればOKです。
" vimdiffの色設定 highlight DiffAdd cterm=bold ctermfg=10 ctermbg=22 highlight DiffDelete cterm=bold ctermfg=10 ctermbg=52 highlight DiffChange cterm=bold ctermfg=10 ctermbg=17 highlight DiffText cterm=bold ctermfg=10 ctermbg=21
これでvimdiffコマンドを実行するとこのようになります。
背景の色を差分の種類によって分けており、追加行は緑、削除行は赤、変更行は青で変更部分が明るい青になってます。
これでだいぶ見やすくなるんじゃないかと思います。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月27日木曜日
Macの端末内Vimで挿入モード時カーソル形状切り替え
Macで端末を起動してリモートにSSH接続し、Vimでソースコードを編集するって使い方を普段良くするんですけれども、以前からの不満の１つが挿入モードの時のカーソル形状を切り替えできないことでした。
MacVimであれば、ノーマルモードのカール形状はブロックで、挿入モードの時はカーソル形状が垂直バーとなります。これにより現在が挿入モードかどうかすぐ分かりますし、文字が挿入される位置も見やすくなります。
で、端末上で起動するVimにしても、実はカーソル形状の切り替えができるらしいことが調べてわかったんですが、いかんせんMacのOS X標準で用意されている"ターミナル.app"は、カーソル形状の切り替えに対応していないようです。しかしながら、"iTerm2"という端末アプリが対応しているらしいとのこと。
ということで、標準の"ターミナル.app"から"iTerm2"へ乗り換えるとともに、カーソル形状をモードによって切り替える設定をしました。
下記からダウンロードして解凍し、出てきたアプリを直接「アプリケーション」フォルダにドラッグ＆ドロップしてください。
http://www.iterm2.com/#/section/home
設定は好みですが、プロファイルの以下の部分は重要と思われますので書いておきます。
「Text」タブ
Treat ambiguous-width characters as double width にチェック → これにチェックを入れておかないと、□や◯といった記号の混じった文章がおかしくなります。
「Window」タブ
Disable session-initiated window resizing のチェックを外す → ウィンドウサイズを変更した時に追随させるにはチェックを外します。
「Terminal」タブ
Save lines to scrollback in alternate screen mode のチェックを外す → Vim起動中にウィンドウサイズを変更した場合に、Vim終了後の端末ヒストリーがおかしくならないようにするにはチェックを外す必要があります。
Report Terminal Type: "xterm-256color"に設定 → デフォルトだと"xterm"ですが、カラー表示が一部不完全になるので、この設定に変更します。
「Key」タブ
ターミナル上でMac側のショートカットキーが効かなくなる場合がありますので、ここで設定して回避します。僕の場合、日本語/英数の入力切り替えに使うキーを効くようにするために次のように設定しました。
Ctrl+Shift+J → Do not Remap Modifiers
Ctrl+Shift+: → Do not Remap Modifiers
さて、カーソル形状をモードによって切り替えるには、下記の設定を.vimrcに記述してVimを再起動します。
最初のt_SIとt_EIの設定では、エスケープシーケンスを用いてカーソル形状を設定しています。
また、ttimeoutlenはエスケープシーケンスをその時間内に入力すれば認識するという意味で、逆に言えばその時間まで待って初めてエスケープシーケンスの効果を認識するということになります。この時間が認識できるくらい長いと挿入モードを抜けた際にカーソル形状がすぐにもどらない、なんて事が起きます。エスケープシーケンスは手入力しないことがほとんどだと思うので、10msecに設定しています。（0でもいいという情報もみかけましたが念のため10msecにしてます。）
さらに、なぜか挿入モードを抜けた時にカーソルが次の操作をするまで見えなくなるという現象がたまに発生したので、上記設定をしたら治りました。なぜ治るのかの理由は不明ですが、追求しても仕方ないのでよしとします。（分かる人いたら教えてください。）
ちなみに、iTerm2は標準でマウスイベントに対応してまして、mouse=aと.vimrcに書いておけばホイールスクロールできますし、マウスドラッグがビジュアルモード選択になります。なおMac側でコピペしたい時にはOptionキーを押しながらドラッグするとできます。
これで快適にVimで操作できるでしょう。楽しいVimライフを！
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
MacVimであれば、ノーマルモードのカール形状はブロックで、挿入モードの時はカーソル形状が垂直バーとなります。これにより現在が挿入モードかどうかすぐ分かりますし、文字が挿入される位置も見やすくなります。
で、端末上で起動するVimにしても、実はカーソル形状の切り替えができるらしいことが調べてわかったんですが、いかんせんMacのOS X標準で用意されている"ターミナル.app"は、カーソル形状の切り替えに対応していないようです。しかしながら、"iTerm2"という端末アプリが対応しているらしいとのこと。
ということで、標準の"ターミナル.app"から"iTerm2"へ乗り換えるとともに、カーソル形状をモードによって切り替える設定をしました。
iTerm2のインストールと設定
下記からダウンロードして解凍し、出てきたアプリを直接「アプリケーション」フォルダにドラッグ＆ドロップしてください。
http://www.iterm2.com/#/section/home
設定は好みですが、プロファイルの以下の部分は重要と思われますので書いておきます。
「Text」タブ
Treat ambiguous-width characters as double width にチェック → これにチェックを入れておかないと、□や◯といった記号の混じった文章がおかしくなります。
「Window」タブ
Disable session-initiated window resizing のチェックを外す → ウィンドウサイズを変更した時に追随させるにはチェックを外します。
「Terminal」タブ
Save lines to scrollback in alternate screen mode のチェックを外す → Vim起動中にウィンドウサイズを変更した場合に、Vim終了後の端末ヒストリーがおかしくならないようにするにはチェックを外す必要があります。
Report Terminal Type: "xterm-256color"に設定 → デフォルトだと"xterm"ですが、カラー表示が一部不完全になるので、この設定に変更します。
「Key」タブ
ターミナル上でMac側のショートカットキーが効かなくなる場合がありますので、ここで設定して回避します。僕の場合、日本語/英数の入力切り替えに使うキーを効くようにするために次のように設定しました。
Ctrl+Shift+J → Do not Remap Modifiers
Ctrl+Shift+: → Do not Remap Modifiers
Vimの設定
さて、カーソル形状をモードによって切り替えるには、下記の設定を.vimrcに記述してVimを再起動します。
" 挿入モードでカーソル形状を変更する let &t_SI.="\e[6 q" let &t_EI.="\e[2 q" " カーソル形状がすぐに元に戻らないのでタイムアウト時間を調整 set ttimeoutlen=10 " 挿入モードを抜けた時にカーソルが見えなくなる現象対策(なぜかこれで治る) inoremap <ESC> <ESC>
最初のt_SIとt_EIの設定では、エスケープシーケンスを用いてカーソル形状を設定しています。
また、ttimeoutlenはエスケープシーケンスをその時間内に入力すれば認識するという意味で、逆に言えばその時間まで待って初めてエスケープシーケンスの効果を認識するということになります。この時間が認識できるくらい長いと挿入モードを抜けた際にカーソル形状がすぐにもどらない、なんて事が起きます。エスケープシーケンスは手入力しないことがほとんどだと思うので、10msecに設定しています。（0でもいいという情報もみかけましたが念のため10msecにしてます。）
さらに、なぜか挿入モードを抜けた時にカーソルが次の操作をするまで見えなくなるという現象がたまに発生したので、上記設定をしたら治りました。なぜ治るのかの理由は不明ですが、追求しても仕方ないのでよしとします。（分かる人いたら教えてください。）
ちなみに、iTerm2は標準でマウスイベントに対応してまして、mouse=aと.vimrcに書いておけばホイールスクロールできますし、マウスドラッグがビジュアルモード選択になります。なおMac側でコピペしたい時にはOptionキーを押しながらドラッグするとできます。
これで快適にVimで操作できるでしょう。楽しいVimライフを！
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月26日水曜日
Macのターミナル上のvimでマウスホイールスクロール
僕もvim愛用者の一人ですけれども、MacBookではMacVimとターミナル上のvimの両方を使い分けております。また、sshでリモート接続してターミナル上でvimを使うこともしばしばあります。そこで前から、ターミナル上でvimを使う時もマウスホイールでスクロールできたら便利だと思っておりまして、方法を調べてみました。
要点としては、
の３点です。
SIMBLは、MacのCocoaアプリケーションの動作をカスタマイズできる機能拡張です。このSIMBLの上にさらに用途別のプラグインをインストールすることで様々なカスタマイズができます。EasySIMBLは、本家SIMBLを改良して、ドラッグアンドドロップで簡単にプラグインをインストールできるようにしたものです。ダウンロード先はこちら↓
https://github.com/norio-nomura/EasySIMBL/
Macのターミナルがマウスイベントを送信できるようにするSIMBLプラグインです。先ほど上で述べたEasySIMBLを使ってインストールします。ダウンロード先はこちら↓
https://bitheap.org/mouseterm/
ダウンロードして解凍インストーラが出てきますが、このインストーラは使わずに、直接拡張子が「.bundle」のファイルをEasySIMBLの画面にドラッグアンドドロップしてください。
MouseTermをインストールすると、ターミナルの「シェル」メニューに「Send Mouse Events」が出現し、チェックのON/OFFで切り替えができるようになります。普段はONにしておき、Mac内の別のアプリにターミナル上の文字をコピペしたいときなどはOFFにするとよいでしょう。
.vimrcに次の記述を追加します。
なお、僕の環境ではttymouseは元々xterm2になっていたので２行目の設定は不要でした。
これで、ターミナル上のvimでもマウスが効くようになります。マウスホイールでのスクロールに加えて、クリックした部分へのカーソル移動、ドラッグによるビジュアルモード選択もできるようになります。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
要点としては、
- EasySIMBLをインストールする
- MouseTermをインストールする
- vimの設定でマウスを有効にする
の３点です。
EasySIMBLをインストールする
SIMBLは、MacのCocoaアプリケーションの動作をカスタマイズできる機能拡張です。このSIMBLの上にさらに用途別のプラグインをインストールすることで様々なカスタマイズができます。EasySIMBLは、本家SIMBLを改良して、ドラッグアンドドロップで簡単にプラグインをインストールできるようにしたものです。ダウンロード先はこちら↓
https://github.com/norio-nomura/EasySIMBL/
MouseTermをインストールする
Macのターミナルがマウスイベントを送信できるようにするSIMBLプラグインです。先ほど上で述べたEasySIMBLを使ってインストールします。ダウンロード先はこちら↓
https://bitheap.org/mouseterm/
ダウンロードして解凍インストーラが出てきますが、このインストーラは使わずに、直接拡張子が「.bundle」のファイルをEasySIMBLの画面にドラッグアンドドロップしてください。
MouseTermをインストールすると、ターミナルの「シェル」メニューに「Send Mouse Events」が出現し、チェックのON/OFFで切り替えができるようになります。普段はONにしておき、Mac内の別のアプリにターミナル上の文字をコピペしたいときなどはOFFにするとよいでしょう。
vimの設定でマウスを有効にする
.vimrcに次の記述を追加します。
set mouse=a set ttymouse=xterm2
なお、僕の環境ではttymouseは元々xterm2になっていたので２行目の設定は不要でした。
これで、ターミナル上のvimでもマウスが効くようになります。マウスホイールでのスクロールに加えて、クリックした部分へのカーソル移動、ドラッグによるビジュアルモード選択もできるようになります。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
2014年3月25日火曜日
コードは「簡潔」に。「短く」ではない。
プログラミングにおいて、コードは「簡潔」に書くようにしよう、とはよく言われることですね。冗長な書き方を排し、スッキリ読めるようにすることは大切なことです。その点にケチを付けるつもりはありません。
しかし、「簡潔」とは「短く」という意味ではありません。最も重要なのは、読んで処理の流れが分かりやすいことであって、短いほうかがそうなるかというと、僕は違うと思います。むしろ、あまりにコードを短くすることは、かえってコードを分かりにくくします。今プロジェクトでRubyを使っていますけれども、特にRubyのように豊富な組み込みライブラリを持ち、１つの処理を無数の方法で書けるような言語に関しては、短く書こうと凝り過ぎた記述がむしろ難読化を招くという罠があります。
もちろん、処理の流れを分かりやすく書こうと努力することで自然にコードが短くなり、見た目も美しくなるという副作用が発生しますから、見た目の美しいコードは読みやすいという法則があるのは確かなのですが、見た目の美しさとコードの短さは必ずしもイコールではありません。
さらにタチの悪いことに、同じ処理を短く書けるということは使用する言語に対するマニアックな知識がないとできないので、短いコード＝高い技術力という思い込みにも陥りがちであるように思います。しかし、よく考えて見れば、書いた人以外が読むのに苦労するようなコードを書く人間が本当に技術力が高いと言えるのでしょうか。むしろ、本来ならば難しいはずの処理を、簡単に分かるようにコード化して見せられる人間の方が、高い技術力があるといえるんじゃないかと、僕は思います。
プログラミング以外においても「難しいことを難しく説明するのは凡人であり、本当に頭のいい人間は、難しいことを易しく説明できる人間だ」とよく言われますけれども、プログラミングにおいてもこれは同じことだと思います。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
しかし、「簡潔」とは「短く」という意味ではありません。最も重要なのは、読んで処理の流れが分かりやすいことであって、短いほうかがそうなるかというと、僕は違うと思います。むしろ、あまりにコードを短くすることは、かえってコードを分かりにくくします。今プロジェクトでRubyを使っていますけれども、特にRubyのように豊富な組み込みライブラリを持ち、１つの処理を無数の方法で書けるような言語に関しては、短く書こうと凝り過ぎた記述がむしろ難読化を招くという罠があります。
もちろん、処理の流れを分かりやすく書こうと努力することで自然にコードが短くなり、見た目も美しくなるという副作用が発生しますから、見た目の美しいコードは読みやすいという法則があるのは確かなのですが、見た目の美しさとコードの短さは必ずしもイコールではありません。
さらにタチの悪いことに、同じ処理を短く書けるということは使用する言語に対するマニアックな知識がないとできないので、短いコード＝高い技術力という思い込みにも陥りがちであるように思います。しかし、よく考えて見れば、書いた人以外が読むのに苦労するようなコードを書く人間が本当に技術力が高いと言えるのでしょうか。むしろ、本来ならば難しいはずの処理を、簡単に分かるようにコード化して見せられる人間の方が、高い技術力があるといえるんじゃないかと、僕は思います。
プログラミング以外においても「難しいことを難しく説明するのは凡人であり、本当に頭のいい人間は、難しいことを易しく説明できる人間だ」とよく言われますけれども、プログラミングにおいてもこれは同じことだと思います。
※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。
登録:
投稿 (Atom)