「Coupe Baguette」のWebサイトができあがるまで

はじめに

明けましておめでとうございます。
新年第一弾のブログは前々から温めていたプライベートプロジェクトのご報告から始めたいと思います。

妻がパン屋を始めました

実は去年の年末から妻がCoupe Baguette(クープバゲット)という小さな手作りパン工房を開店しました。

まあ、平たくいうとパン屋さんです。
別にこれで大儲けしまくろうとか、そんな大きな野望はなくて、あくまで趣味の延長でやっているお店です。
まだ子どもも小さいし、家事と育児を兼業しながらやらなきゃいけないので、営業日も金曜日と土曜日だけです。

とはいえ、妻のパン作りに対する熱意と研究熱心さは僕も舌を巻くほどなので、パンの味は抜群にうまいと思います。
職人です。完全に独学だけど。

「国産小麦や天然酵母を使ってるけど、前面には押し出したくない。あくまで味で勝負したい。」

「どんなに体にいい食材を使っていても、おいしくなかったら意味がない。」

といった妻の発言に僕は彼女の職人気質を感じずにはいられません。

まだまだ開店したばかりで、知る人ぞ知る、というレベルにも達していませんが、来てくれたお客さんは結構リピーターさんになってくれているようです。
みなさんももし機会があればいらしてください。

・・・で終わっちゃうと、ただの宣伝になっちゃうので、技術的なお話も交えます。

店のWebサイトができあがるまで

店のWebサイトは僕が作りました。
ええ、一応技術者ですから。これぐらいは楽勝楽勝！・・・ではなくて、結構大変でした。
仕事柄、社内システムの開発が中心で、外向けのWebサイトってほとんど作ったことがないんですよね。
もちろん、HTMLやCSSの基本は理解していますが、そこまで凝ったデザインのWebシステムを作ってきたわけではありませんでした。

まず、デザインのセンスがない。
オシャレなWebサイト、ダサいWebサイトは感覚的に見てわかるけど、自分で作れと言われたら「ゴメンなさい」というレベル。

そして、仮にデザインが決まったとしても、それをHTMLやCSSで実装できる自信がない。
HTMLやCSSは当然使ったことがあるけど、それでもWeb屋さんではないのでそこまで高度な使い方をしてきたわけではない。

加えて、Webサイトをどうやってインターネット上に公開するのかよくわからない。
社内Webシステムを構築することはあっても、外向けに独自ドメインを取って公開するようなWebサイトを作ったことがない。

そんな僕がこれらの課題をどうやってクリアしたのかを記しておきます。

デザイン

まずデザインについて。
TwitterのTLを見てると、時々Webデザイン関連のリンクが流れてきたりするので、そのへんをちょくちょくチェックしていました。
その中で見つけた以下の2冊が良さそうだったので、購入して読みました。

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

デザインのルール、レイアウトのセオリー。

どちらもWebに特化した本ではないです。
一冊目はタイポグラフィーっていうか、チラシのレイアウトやフォントの使い方が主に説明されています。
二冊目は雑誌のレイアウトに関するテクニックが中心です。

あれ？何かWebネタがほとんどないぞ？というのは買った後で気づいたんですが、それでも素人の僕は全然知らなかった「デザインパターン」がたくさん載っていたので非常に参考になりました。

HTMLとCSS

次にHTMLやCSSの使い方について。
こちらは以下の本で勉強しました。

実践 Web Standards Design ~Web標準の基本とCSSレイアウト&Tips~

tableタグなんかでレイアウトを組むのを良しとせず、あくまでHTMLはコンテンツをマークアップするためだけに使い、見た目は完全にCSSでコントロールするテクニックを紹介しています。
最初はHTMLだけで構築された素朴なWebページが徐々にCSSによって進化していく過程をサンプルコード付きで説明してくれるので、非常にわかりやすかったです。

Webサイトの公開

最後にWebサイトを公開する方法について。
まず、一応プログラマなので静的なHTMLだけじゃなくて、サーバーサイドでごにょごにょできるWebフレームワークを使いたいなと思いました。
会社ではASP.NETを使っていますが、あまりインターネット向けのWebサイトで使われている印象はありません。
PerlやPHPは結構メジャーですが、どちらもあまり好きな言語仕様じゃないし・・・。*1

となるとやっぱりRuby? そしてやっぱりRuby on Railsじゃない? ということで、Railsでサイトを作ろうと思いました。
Rails関連の情報を集めていく過程で、Herokuというサービスを使うと手軽にRailsアプリを公開できるということを知り、HerokuとRailsを使ってWebサイトを構築していきました。

そして完成

そしてあっちやこっちで色々壁にぶち当たりながら、何とか公開にたどり着いたのが以下のWebサイトです。

Coupé Baguette クープ バゲット

デザイン面ではまだまだ改善の余地があるとは思いますが、少なくとも「ホームページビルダーを使って作ってみました〜」的な素人臭さは払拭できているんじゃないかと思います。

WebサイトのソースコードはGitHubに上げています。
まあソースコードといっても、今のところほとんどロジックらしいロジックは書いてないんですけどね。

GitHub - JunichiIto/cb: for cb site.

おわりに

普段はプライベートであまりプログラミングをすることもないし、外向けのWebサイトを作ることもほとんどなかったので、今回は色々といい勉強ができたと思います。
WebデザインにしてもHTMLやCSSの使い方にしても、食わず嫌い的な苦手意識は無くすことができました。
とはいえ、まだまだ初級レベルであることは否めないので、妻のWebサイトをSandboxにしながら(?)スキルを向上させていけたらな〜と考えています。

余談

店の看板も自作しました。なぜかDIYスキルも少しアップしています。

あと、店の帳簿も僕が付けています。
簿記の資格も思いがけないところで役に立ちました。

あわせて読みたい

半年ぐらい前、店を建ててもらう建築屋さんを選んでいた頃のエピソードです。色々と紆余曲折はありましたが、結局「できる営業さん(社長さん)」の会社で建ててもらいました。

リフォーム会社に学ぶプロのお仕事 - give IT a try

外向けのWebサイトを作る時に学んだことをまとめたエントリです。

独自ドメインのWebサイトとメールアドレスをなるべくお安く作るためのメモ - give IT a try

デザイン関連の書籍はこのサイトを見て決めました。

2read.jp - このウェブサイトは販売用です！ - まとめ ランキング 読書 ログイン 書籍 著者 小説 マンガ リソースおよび情報

*1:少なくともPHPは使ったことがないのですが、よくdisられているのでちょっと心理的な抵抗が・・・。

これまでに読んできた技術書を振り返る

このエントリを書こうと思ったきっかけ

irofさんのこちらのエントリが面白かったので、僕も技術書についてあれこれ書いてみたくなりました。

私の技術書の選び方 - 日々常々

僕の場合は技術書の選び方、というテーマではなくて、自分が技術書とどのように付き合ってきたのかということを振り返ってみたいと思います。

序盤

僕もこの業界に入った時は、技術書らしい技術書よりも「xxxポケットリファレンス」とか「逆引きxxxの技」みたいな、「書いてある内容をそのまま書き写せば終わる」タイプのリファレンス本をよく買っていた気がします。
代表的な一冊はやはりコレですね。

【改訂第3版】 SQLポケットリファレンス (POCKET REFERENCE)

もちろん、リファレンス本自体が悪いわけではないですし、今でも時々買ったりします。
ただ、今思えば当時は「楽して仕事をこなしたい」「高くて分厚い技術書なんて読む気がしない」という手抜き精神が現れた結果だったと思います。

中盤

しばらくすると僕はとあるJava案件に放り込まれて、オブジェクト指向の面白さに目覚めました。

それまでは「プログラムは似たようなプログラムを見つけてコピペして作る物である」と先輩から教えられていたので(最悪)、僕の中でプログラマは「ちょっとだけ頭を使う単純作業労働者」みたいなものでした。

ところがその案件に入ってみると、「一カ所をちょっと変えただけで、全画面の振る舞いが変わる」みたいな魔法のようなことができることを知りました。(それまでは全画面すべてコピペで変更、でしたから・・・)
StrutsやHibernateといったフレームワークの便利さにもびっくりしました。

それ以来、「技術力があれば魔法のような凄いことができる。そして新しい技術を使って開発するのはめっちゃ面白い」ということを知り、主体的に勉強することに目覚めました。

当時はとりあえず「オブジェクト指向」と名のつく書籍や言語を勉強しまくりました。
このあたりから「高くて分厚い技術書」もよく購入するようになりました。
Rubyと出会ったのでも、ちょうどその時期です。

プログラミングRuby―達人プログラマーガイド

全盛期

Code Completeとの出会い

さらに、インターネットを見ているとCode Completeという本の内容を紹介しているサイトを見つけました。
たぶんこのページだったと思います。

BOOK Preview：Code Complete 第2版 - ＠IT

その内容が魅力的だったので、Code Completeを上下巻買いました。
上下巻あわせて約1万2000円。
一度に買った技術書の金額としてはそれまでで一番高かったと思います。

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

CODE COMPLETE 第2版 下 完全なプログラミングを目指して

しかし、その内容は衝撃的でした。
なるほど、こういうことに気をつけてプログラミングすると、こんなメリットがあるのか！と気づかされまくりでした。
確かに安くはない買い物でしたが、当時の僕に取ってはその値段の何倍以上もの価値がありました。

そして、Code Completeには数多くの参考文献がありました。
「なるほど、Code Completeはこうした文献を凝縮してできているんだな」と考えた僕は、それらの参考文献の中から面白そうなものを片っ端から読んでいきました。

これまた「高くて分厚くて難しい技術書」がほとんどでした。
しかし、この頃になると「はじめてのxxx」のような初心者向けの技術書よりも、そういう「難しそうな技術書」ばかりを好んで読んでました。

Code Complete経由で知った「難しい」技術書の中の一冊はこちらです。

実践的プログラムテスト入門

分厚い本の方が分かりやすい

それからオライリーの本なんかも初心者には取っ付きにくそうな雰囲気を醸し出していますが、正規表現の本なんかは非常に明快でした。

詳説 正規表現 第3版

この本を読んで思ったのは「分厚い本の方が本質的なことを丁寧に教えてくれるので、かえって分かりやすいのではないか」ということです。
なので、ますます「はじめてのxxx」みたいな本は敬遠するようになってきました。

ピークの頃は2週間前後でCode Completeぐらいの厚さの本を読んでいたので、大体4000〜5000円の本を毎月2冊ぐらい読んでいたと思います。
お金もかかるし、本を読む時間もかかるし、確かに読書にかけるコストは小さくはないですが、それ以上に著者の人たちが膨大な時間をかけて溜め込んだ知識や経験が本を読むことで得られるとすれば安いコストです。
また、先人たちの知識や経験なしに自分たちの考えだけで問題を解決しようとすると、解決するどころか思わぬアンチパターンへ迷い込んでしまうリスクもあります。
なので、読書は自分が楽してゴールへ近づくための「小さな苦労」にすぎないんじゃないかと思います。

全盛期以後

しかし、その後技術書を読むペースが落ち、積読本が増えてきました。
その主な理由は結婚です。

まず、お小遣い制になったので、それまでのように技術書が好きなように買えません。
仕事でどうしても必要だから、という理由で小遣いの枠を超えて技術書を買ってもらう場合もあります。しかし、独身時代のように気軽に面白そうだから買ってみる、ということは出来なくなりました。
なので4000円を超えるようなちょっと高めの技術書を買いたい時は、会社の経費で買ってもらうこともあります。
しかし、会社で買う時は申請が却下されたり、承認までに時間がかかってすぐに買えない場合もあるので、結局自分で買うしかない場合も多いです。

また、独身時代は「１人の時間」がたくさんあるのでかなり本を読めました。
しかし結婚して子どもができると、家族サービスの時間が増えるのと引き換えに、本を読む時間が減ります。
なので1人の時間を確保するために、朝5時ぐらいに起きて本を読んだり、ブログを書いたりすることが多いです。*1

というわけで、一時期に比べるとペースは落ちていますが、それでも2〜3ヶ月に一回ぐらい2〜3冊の技術書をまとめ買いしている気がします。
まあそのうちのいくつかは積読本になってしまうことも多いですが・・・。

洋書にも手を出す

ちょっと話は前後しますが、最近は洋書も買っています。
きっかけは米オライリーが出しているiPhone向けの電子ブックです。
日本語で読めたらベストなんですが、英語版は\600で購入できるので、試しに一冊買ってみました。

The Productive Programmer (Theory in Practice (O'Reilly))

元から英語は得意な方だったので、大体の内容(8割前後?)は辞書なしで理解できました。
「なんだ洋書でもいけるやん」と思ったら、こっちのもんです。
海外で発売されている技術書のバリエーションは日本の比じゃありません。
特に日本では永遠に発売されないようなマイナーな技術のマニアックな本がいっぱい発売されています。
また、日本語に翻訳されるのを待たずとも、面白そうな新刊をチェックすることもできます。

いきなり洋書で数千円払うのはちょっと怖い、という方は僕のようにお手軽価格の米オライリー電子ブックを一度購入してみると良いと思います。

これまでに読んできた技術書のリスト

そんなこんなで、これまでに読んだ技術書やビジネス書、語学の本などを合わせると300冊を超えました。*2
これまでに買った本や読んだ本はブクログに残していっています。

junichiitoの本棚 (伊藤淳一) - ブクログ

そしてこれから

僕はこれからもこの調子で技術書をたくさん読んで、勉強していきたいと思います・・・ではなくて、最近はちょっと考えが変わってきています。

昔は読書量(INPUT)が多ければ、自分のスキルアップにもつながり、そうした習慣が社外でも評価されるのではないかと考えていました。
しかし、世間のトレンドを見ていると最近はINPUTよりもOUTPUTの方が重視されている気がします。
もちろん、質のいいINPUTがないと質のいいOUTPUTに繋がりにくいとは思いますが、要は頑張ってINPUTばかりしていてもダメなんじゃないか、ということです。

こうやってブログを書くのも一種のOUTPUTですが、それ以上に勉強会やセミナーで発表したり、自作のWebサービスを公開したり、そういう外向けのアピールもやっていかないとこの先、プログラマとして生き残っていけないんじゃないかと思ったりします。

そうはいってもなかなか行動には移せていないんですけどね〜。
でも2012年も新しく始まったことだし、今年はそうした「作品」を何か残せたらいいなと思います。

ではでは。

あわせて読みたい

過去に書いた技術書のまとめエントリです。よかったらどうぞ。

情報システム開発に役立つ10冊+10冊 - give IT a try
オブジェクト指向関連書籍リスト - give IT a try

*1:そして、うまく起きられないときもしばしば・・・。

*2:積読本を考えると300冊も読んでへんやろ！？というツッコミはなしでお願いします。。。

僕がサクラエディタからVimに乗り換えるまで

はじめに

恐怖のエディタ、Vim。

僕はこの間までずっとサクラエディタを愛用していましたが、最近Vimを使うようになりました。
ええ、Vimです。あのVimです。Viでもいいけど。

Vim・・・使いこなしている人はそれだけで玄人っぽく見られる伝説のエディタ。

実際にVimを使えばすさまじいスピードのコーディングが可能になる。(らしい)

しかしそんな憧れだけで手を出しても大半の技術者は全く手に負えず、すぐに尻尾を巻いて元のエディタに舞い戻ってしまう恐怖のエディタ。

それがVimである。

・・・はい、僕の中でVimやViのイメージはそんな感じでした。
実際、Unix/Linuxマシンのターミナル上で何度か(いやいや)使ったことがありましたが、まあ扱いにくいのなんのって。

「カーソルは十字キーで動くけど、どうやって入力するの？ 」
「えっ？ "i"を押せ？ 」
「入力が終わったらESC？ なんでそんなことすんの？」
「コードを入力・・・あれ？なんかおかしいぞ？なんか入力できてない！？(←通常モードのままでコードを打ち込んだ)」
「もうあかん・・・。Windowsマシンに持ってきて、いつものサクラエディタで編集してから上書きコピーしようっと。そっちの方が絶対速い！」

・・・そんな感じの使い方しかできなくて、できれば一生避けて通りたいエディタでした。
(とか言いながら、「使えたらちょっとカッコいいかも」みたいな憧れはやっぱり片隅に抱えてたんですけどね〜。)

Vimを使おうと思ったきっかけ

実際、プログラマは長年やってるんですが、結構Windows上で開発することが多くて、Unix/Linuxのターミナルを触ることがほとんどなかったんです。
だから無理して覚える必要もないし、前職の頃から使っているサクラエディタで十分便利だと考えていました。

ところが、このところUnix/Linuxのターミナルを使わなきゃいけない案件がちょこちょこやってきて、毎回Windowsで編集というのも非効率に思えてきました。

「う〜ん、そろそろ覚えないとヤバいなあ。やってみるか、Vim・・・。(そして玄人っぽいプログラマにステップアップしてみるか♪)」

ということで、Vimを本格的にマスターする決心をしました。

Vimに乗り換えるまでの流れ

アウトラインだけまとめるとこんな感じです。

1. チュートリアルサイトを参考にして手を動かす
2. チートシートをプリントアウトする
3. 動画でVimの機能をチェックする
4. チートシート(Version 1.0)を完成させる
5. Vimを実践で使う
6. Vim標準のチュートリアルも活用する
7. Vimをカスタマイズする
8. コマンドを復習する
9. さらに情報を収集する
10. 定期的に復習を繰り返す

詳細は以下で説明します。

1. チュートリアルサイトを参考にして手を動かす

まず、以下のサイトをチュートリアルにして、実際にVimを動かしてみました。

Big Sky :: Learn Vim Progressively

なるほど、確かにサクラエディタにはない機能がたくさんあるぞ、ということは確認できました。
ただし、あくまでチュートリアルに従うだけなので、果たして実業務で使うことがあるのかどうか、確信はありませんでした。

2. チートシートをプリントアウトする

次に、以下のチートシートをプリントアウトしました。

vim-cheatsheet.pdf

いっぱいコマンドが載っていますが、一気に全部は覚えられないので、最初に読んだチュートリアルで紹介されているコマンドにだけ赤ペンでチェックを入れました。

3. 動画でVimの機能をチェックする

それから今度は以下の動画をチェックしました。

コーディングを3倍速くする！ Vim入門 | CSS-EBLOG

Vimの使い方を実際に動かしながら解説してくれるので、結構勉強になります。

動画の中で説明されているコマンドとチートシートを見比べて、載っていないコマンドがあればチートシートに追記したりしました。

実際はコマンドが載っていないのではなくて、それはコマンドのコンビネーションだったりするのですが、細かいことはまだよく分からないので、とりあえず自分が知らないと思ったコマンドは追記していきました。

4. チートシート(Version 1.0)を完成させる

これでオリジナルのチートシートができあがります。
この時点でチートシートにはコマンドの中でも特に基本的なコマンドにチェックが入っていますし、チートシートには載っていないコマンドも追記されています。

たとえば、僕のチートシートはこんな感じです。

5. Vimを実践で使う

さあ、このチートシートを片手にいよいよ実践に突入です。
これからはサクラエディタを完全に封印します。(もちろんWindowsのメモ帳も)
テキストファイルを編集する場合はVim一本に絞り込みます。
最初はある程度非効率になることを覚悟しながら、Vimだけでテキストファイルを編集します。

"i"を押してしまうと、ある意味メモ帳と同じような挙動になってしまうのですが、できるだけそのような使い方はせず、ノーマルモードと挿入モードを使い分けるように努力します。
また、Webなどで新しい知識を得た場合はチートシートに追記していきます。

もちろん、仕事だけでなくプライベートでもVimに一本化します。
Vimはプラットホームを選ばないので、どこでも使えるのが強みです。

6. Vim標準のチュートリアルも活用する

Vimを実務で使いながら、さらに修行をします。
Vimには標準でチュートリアルが付属しているので、これを活用します。
ちょっと長いですが、一気に全部終わらそうとせず、2〜3日に分けて終了させればいいと思います。

チュートリアルでvimエディタの使い方を覚えよう — 名無しのvim使い

7. Vimをカスタマイズする

Vimに慣れてくると、微妙に使い勝手が悪いような部分が見えてきます。
標準の設定だと色々な便利機能がOFFになっていたりするので、設定を変更しましょう。

Vimの設定は「vimrc」を変更するのですが、多機能すぎて素人にはよく分かりません。(僕もまだ十分理解できてません)
そこでネットで公開されているオススメ設定をそのまま拝借してみましょう。
サイトによって多少の違いはありますが、どのサイトにもある程度共通のオススメ設定が載っているはずです。

Vim初心者的導入メモ 2/3 「vimrc設定」編 - ナレッジエース

8. コマンドを復習する

そんなこんなで2〜3日ぐらい「Vim縛り」をやっていると、徐々にVim恐怖症は消えてくると思います。
おめでとうございます！これであなたも立派なVimmerです！！・・・と喜ぶのはまだ早いです。

もう一回チートシートを見直してください。

もう一回VimのTutorialをやってみてください。

あれ？Vimにこんなコマンドがあるなんて知らなかったぞ？何か便利そうやん！

と思うようなコマンドをいくつか再発見できるはずです。
最初のうちは基本的なコマンドや使い慣れたコマンドを利用するだけで必死になってしまいますが、余裕が出てくると新しい便利なコマンドにも気がつくようになってきます。
さらに「Vim力」をアップさせるために、そうした新しいコマンドも利用できるようになりましょう。

9. さらに情報を収集する

あとできれば、これまでチェックしていなかったVim関連のWebサイトや書籍をチェックしてみてください。
自分の知らないVimの使い方やコマンドのコンビネーションがまだまだあることに気づくはずです。
僕の場合はこの本を読みました。(職場の同僚から借りました)

Learning the vi and Vim Editors: Text Processing at Maximum Speed and Power

また、チートシートも第２弾、第３弾を作ってみてください。
僕は上述のLearning Vimからリファレンスページをコピーして、チートシートを新たに作りました。
これらのチートシートをデスクの片隅置いて、「あんなことがしたい」「こんなことがしたい」と思ったときにチェックするようにしました。
さらに、一回使ったコマンドは再び使う可能性が高いので、赤ペンでチェックを入れました。

10. 定期的に復習を繰り返す

チートシートやVim関連情報は定期的に(月１回とか)復習することをお勧めします。
Vimに慣れてきたとしても、いつのまにか自分の知っているコマンドだけで作業をしてしまう可能性があるためです。
せっかくVimを使うのであれば、色んなコマンドを使いこなせるようになりたいものです。

2012.04.15 追記

定期的な復習に最適(?)なBe VimmerというTwitterボットを作りました。
詳しくはこちらのブログで解説しています。良かったら利用してみてください。
Vimコマンドを定期的に解説してくれるTwitterボットを作りました - give IT a try

まとめ

Vimのメリット

僕はこんな感じでサクラエディタからVimに乗り換えました。

実際に乗り換えてみると、Vimの便利さが分かります。
特にカーソルの移動がすいすいできるので、十字キーを連打する回数が減りました。
行単位や単語単位のコピー＆ペーストなんかも速くなります。
あと、どんなファイルタイプでもCtrl + Pで変数名やキーワードの自動補完ができるのも便利です。

あー、こんなことができたらもっとVimは便利なのになー、と思うときはたいていその願いを叶えるオプションやコマンドがあるので、まずはネットを検索してみてください。
たとえばWindowsでクリップボードをVimと共有する場合も設定変更で実現できます。

vimエディタからクリップボードを利用する。 — 名無しのvim使い

また先ほども述べましたが、色々なプラットホームで使えるのでOSが変わってもテクニックの使い回しが可能です。
加えて歴史のあるエディタなのでネット上の情報も豊富です。

Vimのデメリット(?)

Vimに慣れてくると、今度はメモ帳的な動きをするエディタが嫌になるかもしれません。
たとえば、Visual Studioを使ったコード編集やOffice製品のドキュメント編集とか。

あと、間違ってVimコマンドをタイプして変な動きを招くこともあります。
VimでCtrl + Fは画面スクロールになりますが、これをブラウザでうっかりやってしまうと検索ダイアログが開きます。

たぶん、筋金入りの強者はこの辺も全部Vim仕様に置き換えていくんでしょうけど・・・。

勇気を出して踏み出せば、きっとあなたも立派なVimmer！

というわけで、以前の僕のようにVim恐怖症を患っているプログラマの方も、僕の体験談を参考にしてVimmerの仲間入りをしてもらえるとうれしいです。

ではこのへんで。

あわせて読みたい

脱初心者を目指すなら知っておきたい便利なVimコマンド25選 (Vimmerレベル診断付き)
長年Vimを使ってみて、「これはVimならでは」と思うような便利コマンドを集めてみました。
チェックリストを使ってVimmerレベル診断もできます！w

脱初心者を目指すVimmerにオススメしたいVimプラグインや.vimrcの設定
あまりマニアックになりすぎない程度に便利なプラグインや.vimrcの設定を紹介しています。
Vimに慣れてきて「もっと効率的にコードを書きたい！」と思った頃に読むと効果的かもしれません。

社内でVimコマンド古今東西ゲームをやってみた - give IT a try
チームにVimmerが何人かいるなら、こんなゲームはいかがでしょうか？