最近やりたいことメモ

半年くらいまえに30歳になった。フリーランスになってもう4年くらいかな。いろいろあって、現在までのよかったこと悪かったことをまとめておきたいのだが、それはまたあとで。
とりあえず今後の目標を考えてみた。目標というより現時点でやってみたいと思っていることリストな感じだけど。いっぱいあります。

  • 英語を上達させる(すくなくとも日常会話レベルまでは)。
  • ネットサービスをひとつ、1から作って運用する。
  • Perlを学ぶ。実用的なWebアプリを書けるくらいにはなりたい。
  • C言語とOSSについて学ぶ(ApacheとかMySQLとかLinuxカーネルのソースを読めるようなりたいな。。。)。
  • 数学を基礎からやり直す。
  • イラストやWebデザインができるようになる(素人以上、プロ未満くらいには)

技術的なことについて補足。
最近は低レイヤについてのスキルを取得したいと考えるようになってきた。OSのこととか、自分が普段使っているOSS(ApacheとかMySQLとか)のソースレベルでの理解とか。さらにベースになる数学の知識とか。

そういえば、社会人一年目にプログラムを書いていたとき、情報処理試験にでる２進数計算の知識とか実務のどこでつかうんだよ、ってよく思っていた。ハードディスクの回転数や読み込み時間の計算とか、大学で講義を受けた情報理論とか。そういうのはホントつまらなくて、勉強する気にもなれなかった。
でも、多くのプログラムを書いてきて、サーバーの設定、運用をしてきて、いろんな技術書を読んできた今になって、なんかそういう情報技術の基礎が無性に知りたくなってきた。
たぶん昔よりいろいろ分かってきたことがあって、その分かってきたことの根本の構造部分が、かつて退屈で仕方なかった「それ」なんだと判ったからだ。
それらは無味乾燥で退屈に見える。構造をなすものだからだ。私たちが普段目にして、心を動かされるものは構造の上に成り立つアプリケーションだったりサービスだったりする。でも構造を追うことが最近楽しくなってきた。

というわけで、個人的な最近の技術トレンドとしては、どんどん低レイヤに向かっている感じがする今日のこのごろです。
がんばろうー。おー。

CakePHPを使ってみた

じっくり使い始めて1ヶ月くらいたちました。
CodeIgniterとKohanaでいらいらさせられたFormヘルパーとバリデーションについてはまずまず気に入って使えてます。だが、どうしてもモデル周りの設計(というか全体的なデータの扱い)がよくないと思えてきた。開発効率がすごくあがったとかの話もあるようだがホントなのだろうか？　以下、現時点での考察です。

DBのテーブルに強く依存した設計

CakePHPはDBのテーブル構造にとても強く依存した設計になっています。1テーブル=1モデル=1アクションというシンプルな構造がCakePHPで想定されている設計のようです。デフォルトの規約でコントーラはコントーラ名から自動的に利用するモデルを決定します。またモデルはアクティブレコードなので1モデルクラス=1テーブルという構成になっています。
また、Formヘルパーもモデル名を指定するようにできていて、1モデル=1フォームのような構造でアプリケーションを構成することを想定した設計になっているようです。バリデーション定義もモデルに記述するので、POSTされる入力データ構造もまたモデルの構造(=テーブル構造)を前提とします。
もちろんこれら規約から外れた実装をすることもできますが、コードが複雑になるという弊害がもたらされます。

何がよくないのか？

上記のような構造なので、CakePHPはクライアントがHTTPリクエストを発行してレスポンスを受けるという1プロセス全体を通して、テーブル構造をそのまま反映したデータ(モデル)を利用します。そのための便利な規約やAPIをフレームワークが用意しています。
しかし実際にアプリケーションを実装すると、Webアプリケーションの各層で利用されるデータはそれぞれ微妙に異なることが多々あります。たとえば画面層でのデータにはデータソース層(=DB)にはないデータを使用することがあります。内部処理を分岐させるための(保存する必要のない)制御パラメータなどです。
CakePHPはこのようなデータの違いをうまく吸収してアプリケーションの各層を実装するのが困難な設計になっています。MVCによる見通しのよい構造はできていますが、モデル、ビュー、コントローラそれぞれで利用される各データ構造は常にDBのテーブルに縛られているのです。
JavaでWebアプリを実装していたときのことを思い出すと、テーブル構造はDAOによって論理上完全にビジネスロジックや画面からは隠蔽されていました。ビジネスロジックや画面はそれに必要なデータのみを扱えばよかったのです。（そのかわり各層でのデータ受け渡しなどの処理を実装する必要はあった）

要するにCakePHPはごくシンプルなアプリケーションを作成するのに最適な規約とAPIを用意しているが、複雑なビジネスロジック(モデル)の実装を困難にしている、というのが現在の印象です。そして大抵のWebアプリはCakePHPが想定しているほど「ごくシンプル」ではないと。
画面とDBでデータのミスマッチがあるとき皆どうしてるのかなあ。

CakePHP、CodeIgniter、Kohanaを使ってみた

暇な時間をみつけてCakePHPを使ってみた。PHPのフレームワークについて時間をとっていろいろ調べるのは初めてで、ほかにもCodeIgniterとKohanaを触ってみたのだが、いまいちだったので結局CakePHPを本格的に使ってみることにした。

でもCakePHPの話の前に、ざっくりCodeIgniterとKohanaについて。
CodeIgniter
CodeIgniterは軽量が売りのフレームワーク。たぶん。

  • メリット
    • 軽量、フレームワーク自体のカスタマイズがしやすい。
    • 制約がすくない。
    • 一通りの機能の習得が楽。
    • 公式の日本語ドキュメントが整備されている。ここをみればほぼ理解できる。
  • デメリット
    • DB周りの機能が薄い。アクティブレコードがない(一応あるが、他のアクティブレコードの実装に比べてスカスカ)
    • GETパラメータをデフォルトで削除する(使用できない)という設計がイヤ
    • バリデーションの設計がイヤ(バリデーションの定義を設定するというより、バリデーションライブラリを使ってごりごりコーディングするような感じになる)
    • Form周りの機能が薄い。(入力エラーになったときとかに入力値を自動で復元したりする機能がない。バリデーションとあわせて明示的に変数を指定する必要あり)

Kohana
kohanaはCodeIgniterのPHP5専用版といった感じです。CodeIgniterのデメリットの一つであるアクティブレコードの実装が解決されていたので、こっちのほうが良いかな？と思って調査したのが始まりです。

  • メリット
    • CodeIgniterに比べDB周りが強い。アクティブレコードの実装がある。
    • CodeIgniter同様、制約が少ない、習得が楽。
    • CodeIgniterに比べ、viewのテンプレート処理(Cakeでいうところのレイアウト)や認証ライブラリが標準のaddonで用意されている。
    • PHP5専用なので、よりオブジェクト指向っぽくコーディングできる。
    • モジュールにより部品化の設計がステキ。（アプリ→モジュール→システムのように階層化されていて部品化と拡張がしやすい）
    • 日本語情報はあんましないが、公式の英語ドキュメントだけでもほぼ問題なく作業できる。
  • デメリット
    • やっぱしバリデーションとForm周りの機能が薄い。

バリデーションとFormの薄さがなんとかならないのか、と思ってCakePHPいきました。次回からようやくCakePHPのお話。今日はここまで。

便利さは人の思考能力を低下させるのか？2

便利さは人の思考能力を低下させるのか？
の続き。
たとえばプログラミング言語の話。Javaはガーベッジコレクタという便利なメモリ開放の自動化機構があるので、プログラマはメモリがどう確保されてどう開放されているかとかを(基本的に)考える必要が無い。C言語しかなかったらそうはいかない。プログラマはメモリについて考えなければいけない。でもそのC言語もCPUの違いを吸収してくれるコンパイラがあるのでCPUについて深く考える必要がない。世の中にアセンブリ言語とマシン語しかなかったら、プログラマはCPUについてよく考えなければプログラムが組めない（と思う。。。実際にアセンブリ言語でコーディングしたことないのよ）。

私はWebアプリの開発が主な仕事なのだが、WebアプリをC言語やアセンブリ言語で作ったことはない。もしそのような言語で作ると仮定した場合、生産性はがた落ちになるだろう。考えなければならないことが多すぎるからだ。一方現在は何も考えないでものを作っているかというとそうではない。考えることは別の領域にいっぱいある。ソースの可読性、共通化、拡張性、UIの使いやすさ、生産性、統一性、負荷分散。。。その他いろいろ。

そう考えると、結局便利さがもたらすのは思考時間の「消失」ではなくて「移行」になるのではないだろうか。つまり考えるべきものの対象が動いただけなのだ。こうなると今まで時間を使うことができなかった領域に思考を集中させることができる。新しいサービスや価値とかはこういうところから生まれるんじゃないかなあ。

すごく乱暴に言い切ってしまうと「便利になることで思考能力が低下する」と危惧する人は結局、時代の流れについていけてないだけじゃないのかと。その人の価値観、常識、能力、人格を作り上げてきたのはこれまでの経験だ。だから便利さでその経験(や経験の中で考える行為)が無くなると、自分のもっている価値観や能力が社会から失われる(=低下する)と感じるのではないだろうか。それは事実かもしれない。でも失われたことをもうちょっとよく見てみると別の価値観、別の能力の創造につながっている。社会が変化しているのだ。古いものは消え新しいものが生まれる。そういうことだ。

でも一方で人間の根本はそんなに変わらないので、古くても本当によいものは文化として残ったり愛されたりするんじゃないかなとも思う。

便利さは人の思考能力を低下させるのか？

一昨日だったか、テレビ東京のワールドビジネスサテライトで検索エンジンについてニュースが流れていた。これから検索エンジンはさらに便利になっていくし、競争も激しくなっていくというのが主な内容。そしてこのニュースの最後にコメンテーター(であってるのかな?)の方が次のようなコメントをした。

「便利になりすぎて考える力が落ちてしまうのではないか」

正確になんと言っていたのかは覚えていないのだが、とにかく(過度な)便利さは人が思考する機会を奪ってしまう。そうするとモノを考えなくなってしまって、思考能力が低下するのではないか、という話だったはずだ。個人的にはそんなことにはならないんじゃないかと、思った。そのときはぱっと直感的にそんなことを思ったので、もうちょっとその件について考えてみようと思う。

要は、思考する時間が減るとその人の思考能力が低下するってことだ。これは分かりやすいし、その通りだと思う。でも検索エンジンの件で減っている思考時間は、その人が「目的の情報を得るための手段を考える」ことに費やしていた時間だ。目的の情報が見つかった後、それを読んで考えたりする思考の時間が減っているわけではない。むしろ情報を探すための時間が短縮されたためこちらの思考時間は増える。個人的なことだが、自分のプログラミング能力やシステム開発に関する知識、思考能力はグーグル先生がいなかったら今の半分も無いんじゃないかと思う。

一方、(もの考えることなく)大学のレポートや論文をネットからコピペして作ったりすることもあるようだが、これは確かに重要な思考時間を喪失していると思う。でも、どんなツールも使い方次第なので、いい面と悪い面双方がある。ああ、それをいっては身も蓋もないか。まあいいや。(汗

でも、考える力が最も伸びるのは、本人に考えたいとか深く知りたいと思うものが具体的にあるときだ。そのとき情報をすばやく得られるネットや検索エンジンは強力なツールになる。

ネットユーザーは企業に対して容赦ない

「グーグルに依存し、アマゾンを真似るバカ企業 」(幻冬舎新書)　夏野 剛 (著)

を読んだ。さらっと流し読みしたくらいだけど。で、見出しにある「ネットユーザーは企業に対して容赦ない」ということが書いてあって、うんうんそうだよなーと思った。
私自身、つい先日まであるウェブサービスを提供しているシステムの運用保守をやっていたのだが、ユーザーサポートにくるメールの中には「容赦ない」文面がしばしば寄せられていた。なので結構実感できることだった。

ネットではユーザが企業側の人間と直接対面することがない。だから人と人が直接会って行うコミュニケーションに発生する緊張感や遠慮、場の空気を読むなど一種の緩衝材がない。そのためユーザーはストレートに「容赦ない」リクエストを送る。

サービス提供側の人間としては、ネットの特性としてこういったことをメリットとして生かせるように対応していかねばなあと思ったりします。

仕事の区切り

先日今の仕事の契約が終わった。次の仕事を探さねば。。。

フリーになった理由は、いろんなシステム開発に携わって、新しい知識、技術を吸収できるんじゃないかと考えたから。会社に社員としていたときは一つのプロジェクトに1年以上くっつきっぱなしで、しかもそれが運用、保守も含むとなると、カオスなJavaコードの解析とかが仕事の多くを占めるようになる。
つまらないし、汚いコードを読むのがストレスになる。

フリーの利点は(ある程度)仕事が選べるということ。でも選べるほどの選択肢がない場合もありえる。仕事がまったくなかったりするかも。さて今回はどうなることやら。

とりとめもなく書いたが、次のお仕事がすぐに見つかるのかなあ、とちと不安になったりします。