2012-02-10
行動と志
アメリカに行ってエンジニアリングを学びたい中学生 を眺めていると、ふと、正月に実家に帰省していたときにやっていたテレビ番組を思い出しました。奇しくも、主人公も同じ 14 歳のようです。
時は幕末…黒船来航以降、開国だ攘夷だと国中が騒いでいた時代――。
14歳の主人公・山田市之允（山田涼介・通称：市、後の顕義）は、国から忘れ去られたような村に我慢ができず、江戸へ行き人々の役に立ちたいと考える。しかし、肝心の江戸へ行く術がわからない。父・顕行（神田正輝）の勧めで松下村塾へ入門し、生涯の師・吉田松陰（合田雅吏）と出会う。父に松陰から江戸へ行く術を学べと諭されるが、市は罪人の松陰を慕えない。加えて、松下村塾の学問は畑仕事など一風変わったものばかり。
一向に江戸へ行く術など学べる気配はなく、市の不満が爆発。見かねた松陰は、「僕を斬れば江戸へ行く術を教える」と無茶な条件をつきつける。
何度も松陰を斬ろうとするが、結局斬ることができなかった市。その矢先、松陰を慕っていた塾生が斬り殺されるという事件が起きる。市は松陰を殺せず、市から松陰を守ると言った塾生が殺された。理不尽な死に泣き崩れる市に松陰は言う。
「人の行動には必ず理由がある。江戸に行きたいという理由（志）がなければ江戸に行っても役には立たない。江戸へ行くために、ここでしっかり勉強しなさい」
この言葉から松陰の真意を知り、市は初めて松陰を心から尊敬する。そして、いつか江戸へ行くために松下村塾で学ぼうと決意するのであった。
知られざる幕末の志士 山田顕義物語
「このままじゃダメだ」と言う焦燥感は、特に多感な時期であれば抱いてしまうのは、いつの時代も変わらないようです。ただ、単なる焦りから来る行動と何らかの「志（こころざし）」を抱いての行動には、多くの場合、その後に大きな違いが現れます。
最初の記事で話題になっていた方に関しては、だからどうこうと言うつもりはありません。私自身も似たようなモチベーションで高校、大学と進学していったのもありますし、私が「信頼関係の築けていない他人の言葉は（特に、人生を左右するような決断で悩んでる人には）届かないものだ」と考えているせいもあります。
同じような悩みを抱えていた時に、山田顕義は幸運にも吉田松陰と言う（本人にとって）信頼できると思える人に出会う事ができました。上記の方も「エンジニアの師」を探しているそうで、twitter だけを見ても多くの人達がそれに関連して助言や苦言を述べています。願わくは、そう言ったやり取りの中でプログラミングに限らず「この人の言説なら信頼できる」と思える人に出会えることを、と思います。
2012-02-09
句読点の変更
このサイトを含め、私が記述する文章の多くはこれまで句読点として「，．」を使用していました。たまに理由を聞かれる事があったのですが、前半は「論文と体裁を合わせる」と言うもの、後半は「これまで書いてきた文章と体裁を合わせる」と言うのが理由でした。
4．原稿の体裁
原稿は、次の（1）〜（10）の順に整える。
・・・（中略）・・・
4）句読点は“．”および“，”を用い、それぞれ1画（1字分）を用いる。
情報処理学会誌原稿執筆案内
元々、このブログを始めた理由の一つに、これから（日本語の）論文を書いて行くにあたって「日本語を書く練習をする」と言うものがあったので、文体や体裁、後は論の立て方等もそう言った事をある程度考慮しながら書いていました。
ただ、このブログを始め、いろいろな文章を書き始めた当時とは自分の状況も変わってきており、もはや論文を書く機会は恐らくないだろうと言う事と、句読点を「、。」にしなければならない文章を書く機会も増えてきているので、どこかのタイミングで句読点を変えないとなぁと気になってはいました。
そんな訳で、思い立ったが吉日と言う事で、今日以降、自分の書く日本語の文章は句読点を「、。」で統一しようと思います。
2012-02-08
はてなブックマークの利用動向 2012
以前に はてなブックマーク 年間ランキング TOP100 の推移 - Life like a clown と言う記事で，はてなブックマークの年間 TOP100 のブックマーク数の推移と総記事数，および総ブクマ数の推移をまとめたので，これに去年 (2011年) 分のデータを追加しました．
調査方法
はてなブックマークの年間 TOP100 のブックマーク数の推移については，歴代はてブ多い順 に掲載されている年ごとの TOP100 の記事のブックマーク数をグラフにしています．総記事数，および総ブクマ数の推移については，はてなブックマーク に表示されているそれぞれの値を 1 年に 1 回記録して，それらの値の推移を表，およびグラフ（グラフは増加数のみ）で表しています．
はてなブックマークの年間 TOP100 のブックマーク数の推移
以下に，はてなブックマークの年間 TOP100 のブックマーク数の推移を表したグラフを示します．尚，横軸は順位（1 〜 100位），縦軸は各順位に対応する記事のブックマーク数を表します．
2010年はやや鈍化したかに見えたブックマーク数ですが，2011年は再び盛り返した印象があります．2010年の TOP100 のブックマーク数と比較すると同ランクの記事でもブックマーク数が 700 程度増加しているようです．（同ランクで比較した時の）ブックマーク数の伸びも 2008年〜2009年を超えて過去最高の伸びを見せています．
総記事数，および総ブクマ数の推移
| 日時 | 記事総数 | 記事増加数 | ブクマ総数 | ブクマ増加数 |
|---|---|---|---|---|
| 2012/02/08 | 41,549,216 | Δ12,756,985 | 115,756,020 | Δ33,680,538 |
| 2011/02/04 | 28,792,231 | Δ9,477,589 | 82,075,482 | Δ25,392,788 |
| 2010/02/14 | 19,314,642 | Δ7,292,501 | 56,682,694 | Δ21,156,914 |
| 2009/02/08 | 12,022,141 | Δ4,648,374 | 35,525,780 | Δ14,476,100 |
| 2008/02/05 | 7,373,767 | Δ3,508,874 | 21,049,680 | Δ10,659,700 |
| 2007/02/02 | 3,864,893 | Δ2,537,365 | 10,389,980 | Δ7,537,746 |
| 2006/02/02 | 1,327,528 | Δ908,538 | 2,852,234 | Δ2,138,389 |
| 2005/07/06 | 419,060 | - | 713,845 | - |
グラフは，記事増加数，ブックマーク増加数の年ごとの推移を表しています．
こちらに関しても，「はてなブックマークの年間 TOP100 のブックマーク数の推移」ほどのインパクトはないですが，記事数，ブックマーク数ともに順調に増加していると言う印象です．
はてブ衰退論 - Life like a clown で，「はてブが twitter や Facebook に食われてしまう」と言う主張への反論を述べたのですが，あの問題提起があってから 1 年間はてブを見た結果として「はてブが twitter に食われる」と言うよりは「はてブは twitter 等の巨大な Web サービスのおこぼれをもらっている」と言う感想を抱きました（おこぼれ，と言うのは言い方が悪いかもしれません）．はてなブックマークは元々ニッチな Web サービスで利用者層も限られていたのですが，twitter 等との連携を行う事によって，そう言った膨大なユーザ数をかかえる SNS からの流入数が「食われてしまった」流出数よりも多いと言う印象です．
はてなブックマークにおいては， はてなブックマークの現状 - Life like a clown で述べたように，「ブックマークされている記事の 3割程度は 2ch まとめブログ」と言う事実は気になるところではありますが，まぁ何らかの SNS に食われてしまってサービスが終了するような事態は今の所はなさそうだなぁと思いました．
Related Pages
2012-02-06
嘘のコメントを減らす努力
見やすいコード表記について - タコブネ開発者ブログ と言う記事が目に留まったので今回はプログラミングのコメントについて．
プログラミングの可読性に関する議論は，個々の宗教に依るところも大きいので非常に難しいところです．前述した記事に書かれていた内容に関しては，その多くは「プロジェクト内で統一されていれば（どちらの表記が可読性に優れているか等の議論は）どうでも良い」程度の感想しかないなのですが，一点だけ気になった部分がありました．
以下，少し長いですが引用します．
SampleDTO sampleDto = (SampleDTO)testTableDAO.getPrimaryKey(dataDto.getId(),dataDto.getSubId(),dataDto.getStartDate(),dataDetailDto.getLineNo());この長文について「1文が長過ぎるので読みやすくしてくれ」と言われた場合の、あまり好ましくない変更事例は以下になります。
SampleDTO sampleDto = (SampleDTO)testTableDAO.getPrimaryKey( dataDto.getId(), dataDto.getSubId(), dataDto.getStartDate(), dataDetailDto.getLineNo());次も好ましくありません。変数を増やす事で、バグの温床を築いているようなものです。
String id = dataDto.getId(); String subId =dataDto.getSubId(); java.util.Date startDate =dataDto.getStartDate(); String lineNo =dataDetailDto.getLineNo(); SampleDTO sampleDto = (SampleDTO)testTableDAO.getPrimaryKey( id, subId, startDate, lineNo); // もしくは SampleDTO sampleDto = (SampleDTO)testTableDAO.getPrimaryKey(id,subId,startDate,lineNo);プログラムの流れを考慮するなら、こう書くのが望ましいでしょう。
// ------------------------ // testTableからデータ取得 // ------------------------ SampleDTO sampleDto = ( SampleDTO ) testTableDAO.getPrimaryKey( dataDto.getId(),dataDto.getSubId(), dataDto.getStartDate(), dataDetailDto.getLineNo() );極端に長い場合を除き、1列で記述できるものは半角スペースを利用して1列で記述します。またgetPrimaryKeyのパラメータが知りたい場合は、F2キーを押して、Eclipseの機能から参照して確かめます。このためにJavadocは必須です。
細かいパラメータを並べるのは、数行のプログラムならＯＫですが、実際にそのような機会はあまり無く、全体を流して読めるこの記述方法が重宝されるのです。
見やすいコード表記について - タコブネ開発者ブログ
上記の要求と解法を簡単に記述すると「引数が多すぎて概要の分かりづらい部分をコメントを利用する事によって解決する（読みやすくする）」と言う事になろうかと思います．
バグの温床となるコメント
さて，上記の一連の記述の問題点は，「無駄な変数を増やす事によるバグを警戒している割に，無駄なコメントを増やす事によるバグには無頓着である」と言う点です．プログラミングにおけるコメント論にも様々な議論がありますが，コメントを書く際に注意すべき点の一つに，実際のコードを修正した際にコメントの修正を忘れる事によって発生するコードとコメントの不一致，所謂「嘘のコメント」を（できるだけ）なくそうと言うものがあります．
よく「コメントをきちんと書け」ということを言われます。そのためか、初心者の書いたソースを見ると、必要以上に大量のコメントが書かれていることがあります。確かに全くコメントのないプログラムには読みにくいものが多いのは確かですが、何でもかんでもコメントをつけるのも同じく間違っています。余分なコメントは、プログラムとコメントの不一致、いわゆる「嘘のコメント」の原因になります。要するに「必要十分」なコメントを書くことが大切なのです。
省コメントのススメ - 職業としてのプログラミング
私は人の書いたコードを読むとき、普通はコメントが書いてあってもそれは見ない。中には、ひどいコードもあり、コメントを見ないと理解不能と言うコードもあるが、それでもコメントは見ないで理解しようとする。コメントを信じたばかりに、ひどい目にあった経験が何度もあるからだ。コメントはプログラマが書く物で、プログラマの文章能力は人による差が激しい。修正変更が繰り返されたようなコードは、たいていはコメントとコードが不一致になっている、またやっている内容を理解する時、コメントを読むよりコードを読むほうが早いことが多いと言うことも多い。
コメントが不要な分かりやすいコード
例えば，上記の指針でプログラミングを行う場合，TableDAO クラスの getPrimaryKey() メソッドを呼ぶ際にはほぼ「xxxTableからデータ取得」と言うコメントが付与される事になる事が予想されます．この際，もし getPrimaryKey() メソッドに何らかの修正が施され，処理の概要が「xxxTableからデータ取得」とは微妙に異なるものになってしまった場合，これまでに書いた全てのコメントを修正しなければならない可能性が出てきます．しかし，多人数でプログラミングを行う場合，自分が作成した（あるいは修正した）メソッドが実際にどこで使われているかを把握する事は難しいため，上記のような指針でプログラミングを行うと「嘘のコメント」を残す可能性が非常に高くなります．
蛇足ですが，上記のダメな例として「変数を定義する」と言うものが挙げられていましたが，例えば，バグの温床の理由が「変数への再代入によって発生するバグ」であるならば，final 修飾子を付けて再代入をコンパイルエラーにするような対策を行う事もできます．ローカル変数の final (C++ での const) に関する議論も様々で個人的にはそこまで強く勧めると言う訳でもないですが，少なくとも変に無駄なコメントを書くよりは幾分かマシだろうとは思います．
final String id = dataDto.getId(); final String subId = dataDto.getSubId(); final java.util.Date startDate = dataDto.getStartDate(); final String lineNo = dataDetailDto.getLineNo(); // 上記の変数への再代入を行おうとするとコンパイルエラーとなる． SampleDTO sampleDto = (SampleDTO)testTableDAO.getPrimaryKey(id,subId,startDate,lineNo);
プログラムで表現できる事をコメントでやろうとしない
上記の例の解法を改めて見てみると，「複雑なメソッド呼び出しとなっている部分の概要を伝える」と言うものになります．これはコメントを使わずとも実プログラム上で表現する事ができます．
/** * TableDAO オブジェクトから該当データ（プライマリーキー）を取得する． * データを取得する際に使用する情報は，引数に指定された DataDTO オブジェクトの * Id, SubId, StartDate, および DataDetailDTO オブジェクトの LineNo である． * * @param table データ取得元のテーブル * @param data データを取得する際に使用する情報 (Id, SubId, StartDate) を保持しているオブジェクト * @param detail データを取得する際に使用する情報 (LineNo) を保持しているオブジェクト * @return TableDAO オブジェクトから該当するデータを返す */ private SampleDTO getDataFromTable(TableDAO table, DataDTO data, DataDetailDTO detail) { return (SampleDTO)table.getPrimaryKey(data.getId(), data.getSubId(), data.getStartDate(), detail.getLineNo()); } // testTableDAO.getPrimaryKey(dataDto.getId(),dataDto.getSubId(),dataDto.getStartDate(),dataDetailDto.getLineNo()); // と記述されてあった部分を以下のように書き換える． this.getDataFromTable(testTableDAO, dataDto, dataDetailDto); // あるいは，testTableDAO, dataDto, dataDetailDto が全てクラスのメンバ変数であるならば， // いっそ下記のような形でも良いかもしれない． // this.getDataFromTestTable();
ブラックボックス化したい部分に対して新たなメソッドを定義する事で，元の部分には「コメントで説明する」代わりに「プログラムで説明する」事ができるようになります．プログラムで記述していれば，呼び出し元のメソッドに何らかの変更があった場合でも，例えば Java であれば Eclipse のリファクタリング機能を使用する事により割と楽に名前 (getDataFromTable 部分) を変更する事ができるだろうと思います．また，バラバラに散っていたコメントをメソッドのヘッダ部分一つにまとめる事ができたので，コメントとプログラムの整合性を管理するための手間も減る事となります．
尚，上記の方法だと TableDAO.getPrimaryKey() メソッドが複数のクラスで（頻繁に）使用されるような場合には，呼び出し元のクラスの数だけ getDataFromTable() メソッドが生成される事になるのであまりよくありません．その場合には，TableDAOWrapper のようなラッパクラスを作成して TableDAO クラスの各種メソッド呼び出しを適度にブラックボックス化していく等，まぁやり方はケースバイケースになるかと思います．
コメントは難しい
ある程度プログラミングを行ってきた経験として痛感する点として「コメント（を書く事）は非常に難しい」と言うものがあります．プログラミングのコメントにおける理想としては「必要なコメントのみを過不足書く」と言うものですが，どれが「必要なコメント」かを見極めるのは非常に難しい作業です．私自身も，自分がメインに使っているプログラミング言語*1に関しては，コード部分の指針みたいなものはある程度持てているのですが，コメント部分に関しては今でも常に悩みます．
「何が必要か何が不必要かなど（特に初心者には）判別できるわけがないので取りあえず思いつく限りコメントを書け」と言う主張は，一理あるようにも見えます．しかし，先にも述べた通り，不必要なコメントは「嘘のコメント」を容易に生み出し，「嘘のコメント」はバグの温床の一つとなります．そのレベル（取りあえず思いつく限りのコメントを書くレベル）でしか判別できない所謂「初心者」が，コンパイラやユニットテストの助けも期待できない（IDE によってはある程度助けてくれるのか？）コメントとコードとの整合性をきちんと管理できるかと問われると疑問符が付きます．
その意味では，コメントに助けを求める前に，まず，コード上のみで（可読性等も含めて）何とかできないかを模索すると言う姿勢が（特に初心者と呼ばれるうちは）大切なのではないかなと思います．
*1：ちなみに Java はまったくと言って良いほど触った事のない素人です．
2012-02-04
ネットワークサービス毎のユーザ層の偏り
3000万人の会員数を誇るGREE利用者があまりにも回りにいないので調べた結果、本当に住む世界が違ったという話 - ホームページを作る人のネタ帳 と言う記事を見かけたので今回はそれに関連した話題．
上記の事自体に関しては，「『普段、パソコンからプライベートでインターネットを使っていますか』と言うアンケートをインターネット上で行ったところ，なんと 98.2% もの高い結果が出ました」みたいなアンケート（参考：統計は3度嘘をつく）だなぁ，以上の感想はなかったのですが，実際，GREE や Mobage と Facebook, twitter 等とのユーザ層の違いは特に顕著に現れているように思います．
理由としては，やはりメインターゲットとなる端末（PC かモバイル端末か）の違いが大きいようです．
モバイル版GREEの月間アクセス数が100億PVを突破
少し古いデータですが，GREE 公式によると 2009年3月時点でモバイル版が 100億PV/月なのに対して，PC 版がおよそ 1.3億PV/月程度と非常に大きな違いがあります．
ちなみに，ニールセン・ネットレイティングスの日本の主要SNSサイトの利用動向によると Facebook の Windows PC からのページビューはおよそ 9.7億PV/月との事です．上記のグラフを見ると PC版 GREE のページビューの伸び方は 4,000万〜5,000万PV/年のようなので，2011/10 の PC版 GREE の 月間 PV を 2.5億程度と推測すると，大雑把ですが GREE の規模は Facebook の およそ 25% 程度となります．先のアンケート結果によると，Facebook ユーザで GREE のアクティブユーザでもある割合は 5% 程度だったそうなので，まぁそんなものじゃないかなぁと言う気もします．
一方で，携帯電話 (docomo) からの月間 PV を比較すると，やはり GREE 等の方が圧倒的になります．
Ameba, GREE, Mobage, mixi, Facebook, Twitter, 2011年12月 最新ドコモ携帯ネット視聴率
そんな感じで，「どっちが一般的か」みたいな話をすると不毛になるだけなのでアレですが，少なくとも，最初の記事のタイトル通り住む世界と言うかユーザ層は明確に異なっているようです．ただ，GREE や Mobage は，スマートフォンへの移行へ向けて大きく力を注いでいるようなので，そう言った移行がうまく成功すると（私を含む）これまで PC メインで Web を見ているようなユーザの目にも止まる機会が増えてくるのかなと思います．
