2009-03-30 15:24 :
「実践バグ管理」の執筆を時系列に紹介しながら、本執筆の流れを紹介する記事の連載を開始しました
八角研究所の技術連載で、実践バグ管理の執筆を時系列に紹介しながら、本企画提案から出版までの流れを執筆者の視点から紹介する記事の連載「書籍「実践バグ管理」執筆体験記」を開始しました。実践バグ管理は、クジラ飛行机さんとの共著であり、本連載では複数人による執筆やり方について深く触れています。
八角研究所 : 書籍「実践バグ管理」執筆体験記（1） - 執筆の開始と出版社への提案
そのうち技術系の本を書いてみたい方におすすめです。また、実践バグ管理については、こちらの記事を参照してください。
Posted by あかさた（編集）
2008-08-25 19:35 :
アーキテクチャパターン「Blackboard」
ここしばらく POSA 本 を片手にアーキテクチャパターンを再勉強して記事にしています。アーキテクチャパターン Blackboard の記事ができたので紹介します。
八角研究所 : POSA 本でアーキテクチャパターンを勉強しよう（4） - アーキテクチャパターン「混沌から構造へ」より「Blackboard」
http://www.hakkaku.net/articles/20080825-262
過去の記事は以下の通りです。
■ 上記連載の趣旨
アーキテクチャパターンはシステムの基本となる構造を定義するための大規模なパターンです。デザインパターンのようにシステムの部分的な設計を支援するものではなく、システム全体の構造を対象にしています。
アーキテクチャレベルの判断は、部分的な設計判断よりリスクが高いことが多いわけですが、その割にはなかなか勉強する機会がありません。
そこで、アーキテクチャ設計を勉強できる数少ない本の一つであるPOSA 本 を片手にアーキテクチャパターンを勉強するための記事を書いてみることにしました。
しかし、パターンに対するイメージはさまざまです。構造を重視しすぎるあまり、「実際の開発で導き出される設計と何か違う」という理由で忌避する人がいることも事実です。パターンの紹介記事の中には、構造や実装のみを紹介することで、こうした傾向をあおっている節もあります。
# 小難しいから回避する人もいますが。。。
本当はパターンは、「なぜそのような設計判断をするか」「どのようなときにその設計を用いるのか」など、意思決定のプロセスを残し、あるいは読み手が学習するためのものです。本記事では、わかりやすさは重視しながらも、できる限りパターンのメリットを殺さないように書くことを心がけています。
Posted by あかさた（編集）
2008-07-25 15:57 :
アーキテクチャパターン「Pipes and Filters」
ここしばらく、POSA のアーキテクチャパターンを再勉強しているわけですが、前回のLayers に引き続き、Pipes and Filters の記事を書きました。
八角研究所 : POSA 本でアーキテクチャパターンを勉強しよう（3） - アーキテクチャパターン「混沌から構造へ」より「Pipes and Filters」
http://www.hakkaku.net/articles/20080724-252
Pipes and Filters は、普段の開発で採用することは少ないかも知れませんが、利用者に回ることが多い仕組みなので、しっかりと仕組みを抑えておきたいものです。
Posted by あかさた（編集）
2008-07-01 11:19 :
アーキテクチャパターン「Layers（レイヤ）」
ここしばらく、POSA のアーキテクチャパターンを再勉強しているわけですが、第一弾として「Layers（レイヤ）」について記事を書きました。以下をご参照ください。この記事ではウェブアプリケーションの世界（主に Rails）を意識して書いているので、ウェブ系の人でも比較的馴染みやすいのではないかと思います。
八角研究所 : POSA 本でアーキテクチャパターンを勉強しよう（2） - アーキテクチャパターン「混沌から構造へ」より「Layers（レイヤパターン）」
http://www.hakkaku.net/articles/20080630-227
Java EE 勉強会でもアーキテクチャに関する議論はされているみたいですが、POSA や PofEAA あたりが共有言語となっている雰囲気があります。この辺を理解して積極的に議論に参加していきたいものです。
Posted by あかさた（編集）
2008-06-03 09:33 :
ここで一度アーキテクチャパターンの勉強をやり直そうかな
ここしばらく、技術に関しては目先の視点での勉強ばかりをしていました。やれ Ajax だの Flex2 だの Comet だのという感じです。当然技術的には奥行きのない世界です。結局、Document-View（MVC の一種）な構造をもったアプリケーションをどううまく書いたらいいのかとか、インフラの状態と相談しながら通信の粒度をどのように決めていくかとか、本質的なところを考えなくてはなりません。
こうした設計の基本的な事柄を考える能力というものは、オブジェクト指向原理主義的なものを抜きにしても、エンジニアの基本的な体力の一つであると感じます。しかし、昨今のネットを見ると、そういう記事がない・・・というより、記事はあるのですが浮かんでこないという問題を抱えているように感じます。また、記事や知識は断片化していて、ある文脈をもった人たちの間でしか共有できていません。
一朝一夕に何とかなるものではありませんがまずは自分で勉強して記事を書いてみようかと思います。
まずは、アーキテクチャを勉強します。マーチン・ファウラーの PofEAA（エンタープライズアプリケーションアーキテクチャパターン）のように著名なフレームワークに実装例を探すことができる本を再読することも考えましたが、ここは一つそろそろ古典の領域に入りますが名著として名高い POSA 本（ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系）を読み直してみることにしました。
冷静に考えればこの本を読んだのは大学 4 年の時です。当時この本の良さを理解できていたとはとうてい思えません。今読んだらどのような知見を得られるのかわくわくしています。
・・・というような、需要があるかどうかわからない記事を書いても怒られないのか心配ですが（一応記事そのものは仕事として書いているので）、これから 2 ～ 3 ヶ月かけて POSA 本を勉強します。
POSA 本でアーキテクチャパターンを勉強しよう（1） - パターンとは何か？
http://www.hakkaku.net/articles/20080603-215
本に登場する例は少し古さを感じなくもないので、適用例の紹介はできるだけ最新の流行を反映したものにしたいと思います。設計を勉強したいという方は、ぜひおつきあいください。
Posted by あかさた（編集）
2008-05-23 09:32 :
haXe を PHP に変換する haXe/PHP
八角研究所にて、haXe を PHP に変換する haXe/PHP の紹介記事を書きました。こちらの記事でうにらさんにいただいた情報を元にしています。
クライアント（ブラウザ）もサーバも同一言語で書ける haXe を使ってみる（8） - haXe を PHP に変換する haXe/PHP を使ってみる
http://www.hakkaku.net/articles/20080523-212
haXe の弱点は、サーバサイドで動作する環境が NekoVM だということです。（それが強みという見方ももちろんできますが。）haXe/PHP は haXe を PHP に変換するので、安定した環境で動作することが期待できます。haXe/PHP はまだベータ版ですが、既存の PHP のコードを呼び出す方法などにも触れ、正式版が出たら普通に使えるように配慮しました。
個人的にはプログラミング言語としては悪名高い JS や PHP を Java 的な言語である haXe が隠蔽するというのはなかなか面白い試みだと考えています。ぜひ、伸びていって欲しいものです。
Posted by あかさた（編集）
2008-05-13 13:13 :
第4回RHGの逆襲（RHG 片手に Ruby 1.9 を読む集い）に参加した
第4回RHGの逆襲（RHG 片手に Ruby 1.9 を読む集い）に参加しました。以下にレポートを上げてあります。
RHG 片手に Ruby 1.9 を読む集い（The RHG Strikes Back）に参加した（4） - 第4回 RHG の逆襲
http://www.hakkaku.net/articles/20080513-204
今回の内容はガーベージコレクションです。今回は実験的に勉強会の動画をニコニコ動画にうｐしてみました。ぜひご覧ください。
マイリスト RHG 片手に Ruby 1.9 を読む集い（The RHG Strikes Back）‐ニコニコ動画(SP1)
http://www.nicovideo.jp/mylist/6648730
Posted by あかさた（編集）
2008-04-18 17:12 :
ユーザインタフェースとアプリケーションは分離する
八角研究所にて、AutoPagerize と LDRize などのユーザスクリプト（GreaseMonkey スクリプト）を例にあげつつ、「ウェブアプリの使い勝手の一部は単体のモジュールとして開発されるようになったた」「ウェブアプリ開発はこれからどうすべきか」という趣旨で記事を書きました。
八角研究所 : ユーザインタフェースとアプリケーションは分離する
http://www.hakkaku.net/articles/20080417-189
ついで（？）に、サイトを AutoPagerize と LDRize に対応させるまとめもコラムとして載せてあります。
Posted by あかさた（編集）
2008-04-08 10:28 :
第3回RHGの逆襲（RHG 片手に Ruby 1.9 を読む集い）に参加した
第3回RHGの逆襲（RHG 片手に Ruby 1.9 を読む集い）に参加しました。以下にレポートを上げてあります。
八角研究所 : RHG 片手に Ruby 1.9 を読む集い（The RHG Strikes Back）に参加した(3) - 第3回RHGの逆襲http://www.hakkaku.net/articles/20080408-183
今回の内容は Ruby のクラス・メソッド・モジュールの定義に関する部分を勉強しており、特異メソッドやメタクラスなど処理系好きのみならずオブジェクト指向好きにはおすすめの内容となっています。是非ご覧ください。
Posted by あかさた（編集）
2008-04-03 11:27 :
クライアント（ブラウザ）もサーバも同一言語で書ける haXe を使ってみる
八角研究所にて、クライアント（Flash, JavaScript）とサーバ（NekoVM）で動作するコードを出力するオブジェクト指向プログラミング言語 haXe を紹介する記事を書きました。
続きを読む
コメント
2008-05-19 23:34 : うにら
β版ですがPHPへの変換に対応したHaxeが出ていますよ
http://www.weblob.net/haxephp
2008-05-20 02:01 : あかさた
情報ありがとうございます！
haXe はサーバ側が NekoVM でどれくらい安定するか
わからないのが問題と言えば問題なので、PHP 変換が
安定してくれるのなら採用しやすくなりますね。
時間が取れたらさわってみます。
Posted by あかさた（編集）
2008-05-27 11:20 : うにら
記事読みました。早くジェネレータがこなれて正式に採用されるのを待つばかりです。
あと、compile_php.hxmlの記述についてなのですが、-phpオプションで指定するのはコンパイルするファイル名ではなく、変換したコードを出力するディレクトリのようです。
これは推測ですが、どうやらコンパイラが-mainオプションで指定したクラスから依存関係をたどって必要なファイルを変換するようです。
2008-05-27 12:48 : あかさた
記事をお読みいただきありがとうございます！
また、ご指摘ありがとうございます。ファイルでなくフォルダを指定する理由はおそらくそのとおりでしょう。一つのファイルにまとまる SWF/JS のジェネレータとは異なりますね。配置の観点から JS は一つのファイルになっている方がありがたいわけですが、PHP の場合はそういう縛りもないので haXe/PHP のスタイルはそれはそれでいい気がしています。
>早くジェネレータがこなれて正式に採用されるのを待つばかりです。
同感です。