2015年12月31日木曜日

2015年まとめ

概要
去年までは、本を書いたり、毎日ブログを書いたり、ボランティアの技術情報サイトをせっせと書いたりして、プライベートにあまり余裕がありませんでした。
今年は少しペースを落として、プライベートを大事にするように心がけました。余裕が出てくると、見えるものがまた違ってきます。いま継続的に行っているボランティアの作業が一段落したら、また何か新しいことをしたいですね。

仕事まとめ
今年の前半は、昨年から引き続いてヘッドロック社の『ミリ姫大戦』というゲームの開発に関わらせていただいていました。
実装技術としては、EmscriptenというC++をJavaScriptにコンパイルするコンパイラを使ったことが大きなところです。なぜEmscriptenを使ったかというと、C++が得意なのと、何か問題が発生してもなんとかできるメンバーが集まっていたからです。そのほか、今回はCMakeを使ってビルドシステムを構築したので、複数のターゲット環境があっても、共通のビルドの仕組みを使えるようになりました。
そのほか、プロ向けの教育の仕事を継続して行っています。現在は、C# + Unityで開発をしながら教えています。単純なコードの書き方だけでなく、どういった考え方でそうしているかを教えたり、学んだことをまとめて発表してもらったり(他者への説明も含めての理解)、プロジェクトや仕事一般の進め方についても教えてたりします。あと数ヶ月くらいいまのを続けて、次のプロジェクトでほかの技術も経験してもらったりすれば、一人前になってくれるでしょう。


仕事以外のプログラミング関係まとめ
仕事以外では、日本語でのC++リファレンスサイトcpprefjpの執筆は、引き続きやっています。
cpprefjpでは、いくつか大きなことがありました。

まず、SEO(検索エンジン最適化)。cpprefjpサイトをGoogle SitesからGitHub Pagesに完全移行したことによって、cpprefjpのページが、検索エンジンになかなか引っかかってくれなくなりました。自分では自分のサイトをGoogleで検索して行ったりせず、サイト内のURLも直に入力したりしてるので困っていなかったのと問題を把握していなかったのですが、ユーザーがcpprefjpに辿り着けないという問題がありました。
そのため、全てのページに、検索に引っかかりやすくするためのメタ情報の埋め込みなんかを行っていました。おかげでだいぶ回復しました。検索順位はまだ低いですが、ページビューは移行前より少し多いくらいにはなったので、このまま使われていけば、検索順位も上がっていくでしょう。

次に、ライブラリ編の作業が完了しました。
cpprefjpは元々、C++標準ライブラリのリファレンスサイトとしてはじめて、全ての関数、全てのクラスにサンプルを付けよう、ということを目標にしてきました。
これは途方もない作業でした。何人にも手伝ってもらいましたが、それでも終わりが全く見えず、何度も心が折れて燃え尽き症候群になったりもしました。「cpprefjpが終わったらサイトを全部消して自殺しよう」のように考えてしまっていた時期もありました。
それでも、4年間、毎日こつこつ続けて、なんとかライブラリ編の完了まで来れました。その時点でのサイトのページ数は2,543ページ。本にして8冊分の分量になりました。これを書籍の執筆やブログの更新と並行して行っていたのだから、よくがんばったなーと自分のことながら思います。
cpprefjpはボランティアのみでやっていて、広告もありません。たまに誰かがAmazonのウィッシュリストから送ってくれたりもしていますが、cpprefjpのユーザーから直接対価をもらったりはしていません。ボランティアなのに、よくこんなに続くよなーと思います。なぜ続けてこれたかと言えば、「途中で挫折したという実績を作りたくなかったから」というのが理由として大きかったです。自分に対して挫折を許容すると、次に始めることもまた同じことになってしまうと思い、始めたことはしっかりやりきろう、の精神で4年間続けてこれました。あとは言語編が一段落したら、「やりきった」ということにしてしまってもいいかなと考えたりもしています。まだわかりません。
cpprefjpを収益化しよう、という話もありますが、ぼくはコンテンツを作るのに忙しくて全然話が進んでいないので、まだ当分はこのままです。

cpprefjpでは、いろいろな教訓がありました。
始めたころは、「集合知なんだから、みんなで書けばなんとかなるさ」と思っていましたが、実際は8割以上をぼくが書いています。継続的に手伝っていただいている方も何人かいて、非常に助かっていますが、やはり能動的に活動してくれる人というのは少ないのだな、ということを実感しました。このことからの教訓としては、「プロジェクトを始めるときは、一人でやりきれるくらいの規模でやる」ということです。善意のボランティアが大量に集まることを期待してはいけません。
それと、cpprefjpを始めたころは、ぼくがプロジェクト管理の知識を持っていなかったこともあり、根性だけでやっていました。議論をするにしても結論の出し方がわからなかったりしましたし、編集ツールの選定も勢いだけで決めてしまったり、マイルストーン(短期目標)を立てずにゴールだけを決めてしまったりしました。最近はプロジェクト管理もしっかり学ぶようにしています。cpprefjpのあとに始めた書籍執筆のプロジェクトとかでは実践もしてきています。cpprefjpもライブラリ編の途中からは、マイルストーンを立ててやるようにしたので、だいぶ気持ちが楽になりました。

cpprefjpのライブラリ編完了にあたって、協力してくれた方々と打ち上げができてよかったです。本当はマイルストーンの完了ごとにそういうのができるとよかったですね。本当に、ここまでお付き合いいただいて、ありがとうございました。こんな大きなプロジェクトは、もう二度とやりたくないですねw

参照:「cpprefjpのライブラリ編が完了しました - Faith and Brave- C++で遊ぼう

言語編は、2016年中には終わるでしょう。

Boost.勉強会は、大きな問題が発生したりもしましたが(蒸し返したくないのでとくに書きません)、なんとか続けてこれています。ただ、ぼくのモチベーションが下がっているので、あまり開催したくないというのがあります。
理由はいくつかあります。まずぼくが個人的に、江添さんに会いたくないということ。彼が来るようになってから、Boost.勉強会が自分にとって居心地がよくない状態になってきたので、開催する気力が下がっています。別に彼が問題を起こしているわけではないので、ブラックリストに入れたりはしません(いまのところ)。Boost.勉強会は発表主体の状態から脱却するために、以前にディスカッション会をやりましたが、いまの状態だと開催に踏み切れないですね。
それと、Boost.勉強会は人数が集まりすぎる、というのもあります。仙台でBoost.勉強会をやったときには、20人くらいだったのでほぼ全員が発言する機会がありました。しかし、東京で100人が集まってしまうと、やはり参加者と発表者の間に壁みたいなのが見えてしまいます。参加したいひとに「人数を絞りたいから、積極的に議論に参加しない人は参加するな」みたいなことを言うつもりはないので、Boost.勉強会の定員を減らすようなことは考えていません。しかし、ぼくは全員が主役の勉強会というのをやりたいので、cpprefjpが一段落したときにでも、Boost.勉強会とは別の勉強会を考えてみようかと思ったりしています。

Boostの日本語情報サイトboostjpでは、Boostのリリースノート翻訳は継続的にやってこれています。これは軽めのタスクで、ほどよい英語の勉強にもなっているので、しばらくは続けていけるでしょう。
ぼくは、cpprefjpよりは、boostjpでのBoost逆引きリファレンスの方をやりたいので、早くcpprefjpを終わらせたいところです。


趣味まとめ
2年くらい前から友人に誘われてバイクに乗っています。今年はオフシーズンの冬に大型二輪の免許をとりました。オフシーズンだから、という理由だけで免許をとったのですが、免許をとったら大型バイクがほしくなってしまいました。
ゴールデンウィークのツーリングから帰ってきてすぐにNinja 400Rを手放し、次のバイクを買いました。





YZF-R1の2013年モデルです。最高です。
来年はサーキットデビューしたいですね。それと北海道ツーリングに行きたいです。まだまだ夢は尽きません。

最後に
仕事で関わっていただいた方々、コミュニティや趣味で付き合っていただいた方々、ありがとうございます。まだまだ至らない身ではありますが、来年はいっそう気持ちよく過ごせるよう行動していきたいと思います。
来年もよろしくお願いします。

2015年7月14日火曜日

『インタフェースデザインの心理学』を読み終わった


『インタフェースデザインの心理学』を読み終わりました。
知りたかったことがだいたい書いてあったので、すごくよかったです。

ユーザビリティの部分を、感覚ではなく論理で作るために役立てられます。それと、この本で言う「インタフェース」は、画面のユーザーインタフェースだけではなく、サービスデザインのような根底の部分の設計にも適用できます。

1 Tipsが2〜3ページ程度なので、さらっと知りたいことを調べられます。より詳しい情報を知りたい場合は、すべてに参考文献となる論文が示されているので、そこから調べられます。たいへん便利です。

開発者の人たちは、みんな読むといいと思います。

2015年3月18日水曜日

『経営者の条件』 簡易レビュー

ドラッカーの著書『経営者の条件』を読み終わったので、簡単なレビューを書きます。

本書のタイトル『経営者の条件』は、原著では『The Effective Executive』となっています。本書の定義では、エグゼクティブ(Executive)とは経営に関係なく成果を出すよう実行する人のことを言うので、経営者寄りの本ではありますが、読者を経営者に限定した本ではないです。原著のタイトルを、意図にあったように訳すなら「効果的に成果を出す」とかそんな感じでしょう。

本書では、仕事で成果を出すにあたって身につけたほうがいい、いくつかの習慣を論じています。1959年の本なのでだいぶ古いですが、現代でも状況としてはあまり変わっていないように感じました。
エグゼクティブが身につけたほうがいい習慣は、時間の使い方、意思決定に当たって基本となる方針を立てることだったり、「部長」のような役職ではなく「会社・プロジェクトに対してどのような貢献をする人か」で考え・話すようにする、とかそんな感じのことです。

この本をオススメしてくれたのは近藤さんでしたが、「あぁ、近藤さんはたしかにこの本の影響を受けてるな」という感じがしました。
ドラッカーの文章はちょっと読みにくくて、「こういうときはこうしたほうがいい」みたいなものではなく、「エグゼクティブはこう考える」のように、主張ではなく、著者が考える理想像の列挙 + 事例という形式だったので、よく読まないと主張が読み取りにくかったりはします。

本書の読者層としては、以下の2パターンかと思います。

  1. 問題意識を持って本書を読み、後天的にエグゼクティブになりたい人
  2. 経験則と断片的な知識を元にしてすでにエグゼクティブだけど、成果を出す原則を知りたい人

この読者層にマッチする人にとって、本書は有益なものになると思います。


2015年2月16日月曜日

始めるのが遅くていいこと

学び始めるのが早くていいこともあれば、遅くていいこともある。
遅くていいことというのは、入門の時点から「自分がどうやって理解してきたか/成長してきたか」を自己分析しながら始められる、ということ。

書籍『アプレンティスシップ・パターン』を書いた共著者の一人は、30歳くらいからプログラミングを始めたらしい。その学び始めから自分の成長を分析してきたことで、「開発者がどのように成長していけばいいか」をテーマにした本を書くに至った。

ぼくは、プログラミングを始めたころの自分の感覚をよく覚えていなくて、たとえば「変数とは何か」をどうやって理解したのか覚えていない。そのため、入門時のいくつかについては、何がわからなかったのかわからない、という状態になっている。なので、それらのことについては現状、人に教えられない。

そろそろ、そのあたりを再入門しようかと思う。『プログラマの考え方がおもしろいほど身につく本 問題解決能力を鍛えよう!』という本がよさそうなので、いま読んでる本を読み終わったら買ってみよう。


2015年2月3日火曜日

バイクにリムステッカーを付けた

バイクを買ってから1年10ヶ月ほど経つので、気分転換にちょっとしたカスタムとして、リムステッカーというのを付けてみた。

これは、ホイールのフチに付ける色付けのステッカーです。こんな感じになりました。



バイクのとはちょっと違う色の、青紫にしてみました。

リムステッカーはこれ:



RDFというメーカーの、17インチサイズです。
次は、3月の末くらいにタイヤ交換を予定しています。

2015年1月28日水曜日

技術書を書くペース

技術本を書くペースについて考える。

最初に本を書いた23歳当時に実測したのだけど、B5版の技術書で1日フルで書いて11ページが限界だった。平日はがんばって4ページくらい。
この作業のなかには、調べ物と検証の時間も含まれている。

平日に毎日がんばって書くと、75日で1冊分の300ページに到達する。これは休日に休むことを考慮して3ヶ月。3ヶ月間も全力は維持できないので、これはだいたい破綻する。
(このあと推敲と他者レビューで最低1ヶ月はかかる)
なので、習慣化をせず情熱だけで書くと、だいたい力尽きる。

1年の平日はだいたい260日くらいなので、平日に無理せず1.2ページくらい書けば、レビューも含めて燃え尽きずにだいたい1年で書けるんじゃないかなと。

少しずつでいいから、毎日書きましょう。

後日、脳科学の観点から、習慣化したほうがいい根拠について(気が向いたら)書く(かも)。