「Mac OS X Cocoaプログラミング 第三版」とか最近の読書ログ。

Mac OS X Cocoaプログラミング 第三版

Mac OS X Cocoaプログラミング 第三版

を読み始めました。なんかそれなりものを、GW中にはつくろうと思います。まだ8章くらいですが、多分この本は、確かにこの本はCocoaフレームワークでモノづくりをする上では必読っぽい。

あと、

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

は結構前に読了したけど、ジョエルの
Joel on Software

Joel on Software

と似た印象。基本的にはいかにISVを立ち上げるて維持していくかという事。どちらも、でも小さく賭ける事の重要性を語っています。

あと、

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

は買ったもののまだ開いてない。

あとあと、JS系の情報が今年に入ってから明らかに急増していて、そろそろ整理しとかないと意味がわかない事になりそうな今日この頃。

「小さなチーム、大きな仕事」

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

読み始めた。
Rubyつながりです。

今更だけど『思想地図β』とかそのあたりのこと

思想地図β vol.1

思想地図β vol.1

東さん(東浩紀氏の事です。念のため)は、最近朝生とか出てるので、うちのおかんでも知っていてもおかしくない様な有名人になってしまい、そのタフさには関心せざるを得ない。いや、下の年代の俺が関心してる場合ではなくて、オレ頑張れという話ですが。

思想地図(βじゃないよ)の頃から読者をしているので、やっと在野でものを考える事に楽しみを見出す人たちに向けた雑誌が出るようになって嬉しい限り。思想系/人文系の雑誌は学生の時は、こんなもんかぁと思いながら読んでたもんだが、社会に出て仕事をする様になると、まったく生活に結びついていかない思考が延々と続くのにはもうついていけないし、うんざりという所、そんなもの読むなら勝間本とか読みますよ。とか言いたくもなる。少なくとも身銭を切って買いたくない。

そういう意味では、文化系トークラジオLifeは、自分は年齢的にややターゲットから外れつつあるのかもしれないが、回によっては、自分の関心と重なってこの五年間とても良いアンテナになってくれた。バブルの回から聞いてるけど、もう5年かぁ〜。で、そのLifeに東さんが出た回があって、それはもう個人的にLife史上に残る傑作回な訳だが、今聞き返すと、東浩紀氏の野望が着々と現実のものとなっている事を再認識する。この頃から、ルソーの「一般意思」とか言ってたんだね。「Googleがそうじゃん」とかね。まだTwitterは出始めの頃かな?その頃からしても着々とネット上には「一般意志2.0」が形成されている様で、すごいスピードで変化してるなぁと実感。

D

外伝3で、かなり東さんが感情的に思想系/人文系界隈のグダグダしている人たちに怒りをぶちまけているが、その怒りが『思想地図β』という形になって、3万部とか売れている訳だからね。いやはや。早くルソーの一般意志とGoogle的なものを論じたものも読みたいな。

ラジオの中でも、東さんが度々言及していたグーグル的なるもの世界はさらに加速してきていて、おれの頭も数年前なら考えられない程電脳化して、外部記憶装置+広大なネットにアクセスするiphoneがないと、もうどうにかなっちまいそうという世界が現実になってるけど、そうなるとはっきり思考の質が変わってきて、如何に効率よく情報を処理していくかという問題がかなり切実になってる。いやマジで。フィードが死ぬ程登録されたGoogle Readerチェックして、TwitterのTLも追いかけて、Read It LaterとEvernoteとはてぶのどこになにを保存するかの基準が不明確になりつつあるこんな時代にこそ、やはり、強靭に思考する為の思想が必要なんだよね。少なくともオレには。もちろん、情報収集諦めるという選択肢もあるけれど、量が質に転化する瞬間があるから、まだ、そこまで割り切れない。

そんな時代にこそ、生活から立ちがってくる思考が扱われている雑誌は貴重だ。という訳で、次号(震災特集だっけ?)も買う。

『大規模Webアプリケーション開発入門』

大規模Webアプリケーション開発入門 ―変化に強いWeb開発を実現する10の原則

大規模Webアプリケーション開発入門 ―変化に強いWeb開発を実現する10の原則

Amazonから届いた。いつポチッたのか記憶にないが。。。

パラパラ流し読みしたが、基本的にフロント系の設計に関するのネタが沢山。どれも設計に苦労した事がある人ならば、一度は通る道という感じで基本的な事を解説してくれている。

冒頭の、大規模Webアプリケーションのための10の原則を引用しときます。

  • [原則1] 大規模Webアプリケーションは、再利用性、保守性、信頼性の高いモジュール式コンポーネントで構築されます。
  • [原則2] JavaScriptやサーバサイドスクリプト言語オブジェクト指向を活用すると、モジュール性が促進され、大規模Webアプリケーションの再利用性、保守性、信頼性が改善されます。
  • [原則3] 大規模WebアプリケーションにおけるHTMLは、セマンティックであり、情報アーキテクチャにもともと備わっているもの以外の表示形式を含みません。そして、識別可能なセクションとしてさまざまなコンテキストに簡単に埋め込むことができます。
  • [原則4] 大規模WebアプリケーションにおけつCSSは、情報アーキテクチャから分離され、モジュール方式で適用でき、さまざまなコンテキストでモジュールを再利用する際に副作用がないプレゼンテーション層を構築します。
  • [原則5] 大規模WebアプリケーションにおけるJavaScriptは、モジュール式のオブジェクト指向方式で適用されるビヘイビア層を構成します。これは、さまざまなコンテキストでモジュールを再利用する際の副作用を防ぎます。
  • [原則6] ユーザインタフェースとバックエンド間でやり取りされる動的データは、明確に定義されたユーザインタフェースで管理します。ページやデータのロードや保存のため単一点を定義します。
  • [原則7] 大規模Webアプリケーションにおけるページは、再利用性の高いモジュールで構成されます。各モジュールは必要なものすべて(HTML、CSSJavaScriptなどすべて)をカプセル化した、さまざまなページのさまざまなコンテキストで使用できる凝縮度の高い構成単位で、独立して機能します。
  • [原則8] 大規模WebアプリケーションにおけるAjaxは、移植可能なモジュールであり、データの変更と表示の更新を明確に分離します。ブラウザとサーバ間のデータのやり取りは、明確に定義されたインターフェースで管理します。
  • [原則9] 大規模WebアプリケーションにおけるHTML、JavaScriptCSS、及び、PHP(※俺注、この本はバックエンドはPHPで解説してます。)は、パフォーマンスの優れたアプリケーションの基盤となります。また、サイト評価指標の取得やテストのための優れた環境も提供します。
  • [原則10] 大規模Webアプリケーションでは、サーバ上のファイル構成がアプリケーション自体のアーキテクチャを反映します。サーバ上のファイル構成は、各ファイルの使用範囲が明確に区分されている事を示します。

何言ってのかよくわからないフロントエンジニアのみなさんは、本書を読みましょう。当然だろ!このボケという人は、「エクスペンダブルズ」でも観て寝ましょう。おやすみなさい。

『六〇〇万人の女性に支持される「クックパッド」というビジネス』

最近、cookpadに興味深々なので、とりあえず読む。まあ、ライターの人は技術屋さんではないで、細かいツッコミだが、

誤:WebアプリケーションフレームワークRuby
正:WebアプリケーションフレームワークRuby on Rails

である。仕方がないけど、気になる。

内容は、クックパッドの社長がどうして、cookpadの様なサービスをつくろうと思ったか、どの様にcookpadが成長してきたか、cookpadの理念やポリシーといった話が殆ど。印象的なのは、社長の考え方が非常にロジカルで、基本的に納得出来ないことはやらない主義である点。

モノ作りに対する姿勢が非常にしっかりしており、それがサイトの設計から、広告主との関わり方から、ユーザの要望の捌き方まで貫かれている。常に真剣にじっくりと取り組んでいるんだなぁという印象を受ける。それ故に、がっぽり儲けるのではなく、徐々にだが、着実に堅実に結果がついてきている感じが、常に新規サービスのスクラップ&ビルドをやっている自転車操業のビジネスとは一線を画している感を受ける。

また、サービスの対象が食で、それ故に、ユーザの殆どが女性というのも、地に足が着いている。そんでこのユーザ層は、UXに大変厳しい。そこに全力で技術をつぎ込んでいるのも見逃せない。

という訳で、この書籍を読んだ限りでは非常に良い会社の様です。任天堂みたいな感じを受けるなぁ。規模はまだ全然違うけどね。

今年はJavaScript Yearになるのか?

ハイパフォーマンスJavaScript

ハイパフォーマンスJavaScript

最近、オライリーからJavaScript関係の本が続々出てる。今年は、JavaScriptが本格にくるらしい。たしかにnode.jsも盛り上がってるし、新しいもの取り込みが遅れ気味な業務系システムの開発でも非FlashでのRIA、つまり、Ajax+DHTML(でも最近このキーワード聞かないよなぁ。)でのフロント構築がほぼ必須になっている。(他にもRIA技術はあるけどね)さすがにHTML5の流れはまだ来てないけどね。それでも、ユーザは「ねぇ、GoogleみたなUIになんないの?」「iphone対応とかは?」みたいな事は言うので、その日も遠くはないだろうな。

個人的には、HTML5が普及して、IE6/7/8が消えてくれると非常に助かると思ったら本日のニュース。
http://www.publickey1.jp/blog/11/internet_explorer_9314ie10.html

これでやっと、メジャーなブラウザが一応HTML5対応になった訳だ。各ユーザ企業の皆様におかれましては標準ブラウザのバージョンアップを検討頂きたく。。。ただ、まだIEにこだわる必要がどれほどあるんだろうかはしらんけど。

でもこの流れも良い事ばかりではない。

これだけJavaScriptが言語として盛り上がってくると、当然、いろいろと別の問題も生じる。よくJava屋さんが、クライアントサイドのJavaScriptフレームワークとか考えちゃうと、クラスベースのオブジェクト指向にどっぷりなので、クラスという発想から抜けれないこと。巨大なクラスの継承ツリーとか見ると引きます。。。プロトタイプベースのオブジェクト指向言語であるJavaScriptでは、クラスという概念はない。でも、まあそれも仕方ない。だって、

 var hoge = new Object();

って文法なんだもん。こういう書き方だと、そりゃクラスベースの発想になるもの無理ない。(それにclassというキーワードも将来の拡張の為の予約語だったりする。。。)なので、自分は、こっちの書き方の方を好んで使います。タイプも楽だしね。

 var hoge = {};

このあたりの、JavaScriptの残念な点は、

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

に詳しいです。

その悪い部分に加えて、JavaScriptの言語仕様としての自由度の高さが、様々なコーディングスタイルを生み出し、邪悪な暗黙的なグローバル変数及び、IEの中途半端なDOM イベントモデルと合成されると、もう「保守性?拡張性?なにそれ?」的なUIの一丁あがりです。こういった問題は、jQueryとか、最近はあまり流行っていないけどPrototype.js等を使えば、ある程度回避できるんだけど、操るプログラマの力量に大きく左右される言語である事は間違いない。

自分の場合は、大規模で使う場合は、そのドメインで使うUIコンポーネントを作って、その後に、そのUIコンポーネントのDOM構造を扱うAPIを予め設計して、みんなでそれを使うという方法をよく採用する。それとは別にでCSSフレームワークもしっかり設計しておく。DSLの発想にかなり近い考え方で、保守性の向上と、生産性の向上を両立している。もちろんドメインが限定されるというデメリットはあるけどね。

えええと。。。何の話だっけ?

JavaScriptが流行るかという話か。うーん。わかりません。サーバサイドJavaScriptが大きな鍵を握っているとは思うけど、RilasレベルのJavaScriptフレームワークが出たりなんかすると面白い事になるだろうなぁ。

・追記

こんなの発見

JavaScript quiz
http://perfectionkills.com/javascript-quiz/

これはキツイ。特に後半。言語仕様を相当熟知してないと解けない。
自分は8点でした。。。人にJavaScript教える資格ねぇ〜。

jDeveloperを使って素敵なUIモックを一日で作る その1

jDeveloperOracleIDEで、Oracle ADFの開発ができます。Oracle ADFは、JSR227 の実装で、データバインドのフレームワークです。他の実装はない様なので、事実上はOracleの独自仕様みたいだけど。でも、仕様を読んでいると悪くはなさそうです。

Oracle ADFに関しては、ここらへんを読むと幸せになれます。
http://otndnld.oracle.co.jp/document/products/jdev/11/doc_cd/index.htm
※全部で3~4000ページくらいありますが、日本語なので大した事ないです。

ADF自体は、様々なサブフレームワークをもっていますが、その中のADF Faces(JSF1.2 をオラクルが拡張したリッチUIコンポーネント。JSF2.0にいつ対応するかわかりません。By Oracleの中の人)を使ってUIモックを作る機能があります。モックと言っても、CSVで作ったダミーデータを実際にUIにバインドして、グリグリできます。UIコンポーネントも豊富で、上手く組み合わせて使えばかなりカッコイイものが一日で出来ます。これをみせると多くのユーザは、「もうできてるじゃん!」という反応を示すので、出来上がったものを見せて自慢する時は細心の注意を払ってください。このUIモックに、モデル層のデータをリバインドしてやるとアプリケーションの一丁あがりです。モデル層は、EJBとかWebサービスでも大丈夫です。JSR227のおかげて、画面にドラッグするとちゃんとリバインドされます。せっかく綺麗に作ったモックを捨てずに済みます。よかったね。

という訳でモックを作る大体の手順。

  1. jDeveloperのインストール
  2. プロジェクトの作成
  3. 大体の画面遷移のお絵かき
  4. 簡単な画面のフレーム構成のデザイン(ここで適当にCSSや、GIMP2とかPhotoshop使って素材を作るとさらにいい感じになります)
  5. グリグリするCSVデータ作成。こちらに詳しいです。
  6. 作成したデータコントロールをデザイナにドラッグ&ドロップしてUIコンポーネントを選択

これで大体完成です。
コーディングが発生するのはCSSをちょろちょろいじる時くらいです。

数回に分けて解説していくつもりですが、待ちきれない場合は、マニュアルをガン見してなんとかしましょう。この機能を使うと以下の様な場合に非常に有効です。

  • ユーザが要件を固められず、なかなかアプリのイメージがわかない
  • アジャイル開発でユーザと素早くイメージを共有したい

これは、通常のHTMLモックでも出来ることは出来ますが、HTML/CSS/JavaScript(各種ライブラリ)の知識がそこそこないとかっこいいモノは作れないし、それなりに時間もかかります。10画面くらいあったりすると一人でも5日間くらいはかかってしまいます。それに最初にイメージがある場合に、いちいちHTML/CSS/JavaScripの細かい問題に拘泥せずに、サクっとイメージが形になるので、効率もいいです。IEがどうのこうのとか下らない事は後回しです。コーディングもないので、営業さんが提案に使うなんて事も出来ます。「次までに画面イメージ持ってきますから〜」的感じですね。