オレ流AngularJSを使った設計ポリシー
Chrome MySQL Adminでは、 AngularJSを使って実装を行っています。Chrome appsでは、 何らかのMVC Frameworkの利用が勧められています。 AngularJSは、Controller、Directive、Template、Serviceなど、いくつかの部品群を組み合わせてアプリケーションを構成することになります。その機能の豊富さ故に、実はちゃんとしたポリシーを決めておかないと、いかようにでも作れてしまうために、かえって複雑さが増してしまうという危険性も出てきます。もちろんアプリケーションの作り始めは試行錯誤の連続なのですが、徐々に自分なりのポリシーみたいなものが確立されてくるはずです。 本エントリでは、Chrome MySQL Adminでの設計/実装ポリシーを簡単に紹介してみたいと思います。ちなみに、全てのソースコードは、以下にあります。 htt
天使やカイザーと呼ばれて » Chrome Apps for mobileの開発方法
一部で話題になっていたGithubにある「MobileChromeApps / mobile-chrome-apps」ですが、先日遂に正式にGoogleからアナウンスがありました。デスクトップPC向けに開発されたChrome Appを元にして、このツールを使ってモバイル向けアプリ(Android/iOS)を自動的に作成することが可能です。HTML5とJavaScript、CSSを使って、Android/iOSアプリを開発することができるだけでなく、その中で各種Chrome APIを使うことができます。Cordovaベースなので、Cordovaそのものが提供する機能も利用することができるでしょう。 今日は、このツールの使い方を説明した文書を日本語訳してみました。以下の手順をやっていくことで、モバイル向けChrome Appを作ることを試すことができます。ぜひ体験してみてください！ Step
ロバストネス駆動開発？
過去に「 ロバストネス図113枚!!」でも取り上げたが，最近ロバストネス分析を設計の入り口にすることが多くなった。バウンダリ，コントローラ，エンティティという３つのステレオタイプは，今日のWebアプリケーションのアーキテクチャにかなりしっくりとくる。統一プロセスでも，ユースケースからクラスの発見をするために，ロバストネス分析をすることが推奨されている。 ロバストネス分析の結果のロバストネス図は，かなり直感的にシステムの構造と流れを示してくれるので，あまり実装に詳しくない人でも理解可能なようだ。システムの構造や設計に興味を持っているお客さんであれば，十分使用に堪えるシンプルさがあると思う（興味を持っていれば，が重要）。 僕が設計書と実装をできるだけ近づけるために，自動生成が効果的だと思っていることは，このエントリを読んでいる方々はご存知のことと思う。クラスを見つけるためのロバストネス分析が基
OpenSocial Development Environmentをリリースしました
OpenSocial Development Environmentの最初のバージョンを本日リリースしました。 http://www.eisbahn.jp/trac/osde OSDEは、OpenSocialアプリケーションを開発するためのEclipseプラグインです。もし皆さんがOpenSocialアプリケーションを開発しテストを行う際に、いずれかのSNS（orkut.com、myspace.com、hi5.comなど）を使わなければなりません。これらのSNSを使う手法は、皆さんに強力な制限を与えることでしょう。例えば、ソーシャルアプリケーションをテストするために友達を作らなければならず、多くの機能をサポートしたSNSを探さなければならず、SNSが安定して稼働していなければなりません。 OSDEは、皆さんに個人的なSNSを提供することができます。この小さなSNSの中で、皆さんは会員のプロ
HibernateでMap<string>なプロパティを扱う方法</string>
Hibernateを使っていて、ふと困った状況に遭遇。 @Entity @Table(name=”…”) public class Hoge { ・・・ protected Map desc; ・・・ } Hogeエンティティクラスのdescプロパティを永続化させるにはどうしたらいいのだろう？もし、descプロパティが、 protected Map desc; というように、Mapの値が別のエンティティだった場合は、特に問題はない。しかし上記の場合はMapの値がString。これは困った。 Interceptorを自分で作って、onSave()やonFlushDirty()などを実装してstateを入れ替えてみたりして試行錯誤を繰り返すも、残念ながらうまくいかない。そこで、HibernateのForumをいろいろと検索していく中で、同じ話題を発見できた。 [Topic: Map of pr
Firefox3.1はJITコンパイラを搭載予定
IE以外のWebブラウザとしてすっかり定着した感を個人的に勝手に持っているFirefoxだが、次の3.1ではJavaScriptコードの実行を高速化するために、JITコンパイラが搭載される予定らしい。 「JITコンパイラ搭載でJSを大幅高速化へ、Firefox」 - @IT http://www.atmarkit.co.jp/news/200808/25/firefox.html ベンチマーク結果では、約1.83倍の速度向上を実現したとのこと。 Javaの歴史が「JavaVMの速度向上」の歴史であることは有名だけど、JavaScriptも同じ道を地道に歩んでいるということなのだろう。でも、Javaの高速化技術とJavaScriptの高速化技術を比較するのは、ちょっと違うのか。むしろ、JRubyの高速化技術とJavaScriptの高速化技術が、似ているのかな。詳しくないのでよくわからないけど
コミッタは自分で名乗り出てなるものではない
と思う。もちろん、自分自身で新しい何かを作った時は、自動的にそのプロダクトのコミッタに就任しても良い。しかし、他人のプロダクトに対して、 「コミッタにならせてください」 っていきなり名乗り出るのは、OSSの世界を知らないにも程がある。 OSSは、もちろんソースコードが公開されているために、そのメリットとして「誰でも修正コードを作って適用できる」ということがあげられる。しかし、それが即コミッタ就任につながると思っている人がいるようだが、それは大きな勘違い。つまり、公開されたコードの不具合や改善策を提供することは、「OSSの利用者に課せられた当然の行為」であり、本来であれば、そのOSSプロダクトを利用する人全員が行うべき（少なくともそれを認識しておくべき）ことである。 それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。 あとからコミッタ
続： コミッタは自分で名乗り出てなるものではない
「 コミッタは自分で名乗り出てなるものではない」の内容に関して、ひがさんを始め、多くの方々のご意見をいただくことができて、とても嬉しい。ありがとうございます。 さて、 それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。 これは、 「 コミッタには気楽になっていいんだよ」 - ひがやすをblog よういちろうのblogをみると「コードに対する貢献をしたんだから、コミッタにしてくれ」っということなので、行動してるジャン最初に。好きだからこそ、コミッタになりたいと思うんでしょ。 と指摘されている通りで、「貢献してるんだからコミッタになりたい！」ということはもちろん主張していいことだと思います。「貢献」という言葉の意味が「不具合パッチ程度のもの」だとすると、僕の尺度からするとそれはコミッタになるための条件としては足りないと思っているので、r
iPhoneとOpenSocialは相性がよい？
既存の大手SNSが、iPhone向けのアプリケーションを続々と公開している。App Storeに「ソーシャルネットワーキング」というカテゴリがあるくらいの勢いである。FacebookやMySpace、そして先日mixiもiPhoenアプリの公開を始めた。 「 mixiのiPhoneアプリ公開」 - IT media このmixiアプリは、多くのmixiユーザに使われてるだけでなく、内部でAtomPubを使ってmixiにアクセスしていることが多くの技術者の心を掴んだ。つまり、超閉鎖的SNSだと思われているmixiも、AtomPubでの外部との連携手段が存在していた、ということだ。 OpenSocialでは、v0.8からRESTful APIが規定された。これにより、SNSのWebサイト外の任意の場所から、SNSが持つ情報を取得したり更新したりできるようになる。そして、その手順（プロトコル）が
第2回Ext.JS/Ext GWT勉強会に参加してきました
本日、「 第2回Ext.JS/Ext GWT勉強会」に参加させていただいた。その中で、Ext.jsを使ったOpenSocialアプリケーションの開発についてお話をする機会をいただいた。 来場者の興味は「Ext.jsのライセンス」と「Ext.jsの技術ネタ」に向いているようで、OpenSocialの説明に時間を割きすぎた僕の内容は、ちょっと場違い的な感じだったかもしれない。もうちょっと説明の仕方があったのかもなぁ、と反省。 皆さんExt.jsを含め、どのJavaScriptライブラリを使用すればいいか、悩んでいるようだった。Ext.js勉強会なので、少なくとも「Ext.jsいいですよ！」っていう売り文句がどのスピーカーからも聞かれないとダメなのかも。最低でも「Ext.js使ってみようかな！」って思いを持って帰って欲しいので、そういう意味では、今日の僕の発表が貢献できたかどうか、怪しいところと
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
Ext JS/Ext GWT勉強会に参加してきました
昨日行われた「 第1回Ext JS/Ext GWT勉強会」にお呼ばれしていたので、参加をしてきた。主催された方々は皆Mash up Awardつながりな方ばかりだったので、変に緊張することもなく楽しんできた。 内容は、以下の通り。 Ext Japanについて ユーザ事例を３つ紹介* * フリーディスカッション やはりExt.jsはまだまだ日本語の情報が少ないとのこと。確かに検索してみても、ヒット数は少ない。しかし、嬉しいことに 翻訳プロジェクトがすでに立ち上がっているので、今後日本語の情報も一気に増えてくるだろう。 APIリファレンスなどは、かなりの量が翻訳済みなので、非常に参考になるだろう。 事例として紹介されていた「 CRESCAT」と「 Afrous」は、どちらもExt.jsを使った力作。ここまでできるんだ、という良いお手本である。もちろん、 ONGMAPも。 Ver.2が出ていたの
「JRuby on Rails」について発表しました
昨日の4月30日、JJUG主催による「クロスコミュニティカンファレンス」にて、「JRuby on Rails」というお題目で話をしてきた。 | View | Upload your own 聴衆の中に潜んでいたJRuby第一人者から、手痛い突っ込みの数々を頂いた。ここで上記資料の中で訂正（ってわけじゃないけど）してみようと思う。 32枚目の「CGIに比べてパフォーマンス的に有利」と記述してしまったが、現状ではmongrel_clusterで真面目に(?)構築した方が、JRubyよりもパフォーマンスはいい数値が得られている、とのこと。僕が実測したときには、初回のアクセス以外はかなりレスポンスは良かったのだが、全体的にはまだまだ、という印象のようである。 33枚目でセッションのクラスタリングの話をしたのだが、現在のJRuby+GoldSpikeでは、普通にJavaのHttpSessionを使っ
Googleデベロッパー交流会第６回Android SDKに参加してきました
昨日の4/24、六本木ヒルズにて行われた「 Googleデベロッパー交流会 第６回 Android SDK」に参加してきた。前回の 第５回でパネリストとして参加し、今回は2回目となる。お題はAndroid SDKということで、OpenSocialに引き続き、Googleによるプラットフォームの紹介である。 OpenSocialの時もそうだったけど、今回もパネリスト全員が何らかのデモアプリを作って発表を行っていた。Androidでどこまでできるんだろう、という疑問を持っていたので、非常に参考になった。以下に、それぞれの内容と僕の印象を紹介しておこう。 — [英単語帳] ネット上にある辞書サービスを使って英単語の意味を引ける、いわば「単語帳」。サンプルのノートパッドを基本にして開発を進めたらしい。作者曰く、Androidのフレームワークが簡潔なので非常に生産性が高い、らしい。単にネットを叩いて
こみゅすけ Open Social Editionを作りました
こみゅすけには、 RESTful APIが実装されている。つまり、他のプログラムからこみゅすけの情報を取り出したり変更できるようにしてある。これを使って、「こみゅすけ Open Social Edition」なるものを作ってみた。現在、orkut SandboxとHi5 Sandboxにて動作している。 (1) こみゅすけ Open Social Edition for orkut (2) こみゅすけ Open Social Edition for Hi5 実はこの２つ、プログラム的には全く一緒。異なるOpen Socialコンテナで、言い換えると、異なるSNSサービスで、全く同じアプリケーションがそのまま動作することの証明である。ホントにあっさりと動いてしまったので、僕も正直びっくりした。CSSの解釈の違いなどに悩まされるのかなぁ、と考えていたのだが、所詮iframe内での表示なので、問
Googleデベロッパー交流会 第５回「Open Social」に参加してきました
先週の3月14日、 Googleデベロッパー交流会 第５回「Open Social」に参加させていただいた。今回は、パネルディスカッションのパネラーの一人として、Open Socialについて他のパネラーの方々と共に語らせていただいた。 何だかんだ言って、結局僕が一番話をしちゃってたかもしれない。うーん、良かったのか、悪かったのか。。。 Open Socialというと、やはりSNSアプリケーションの開発に関する話が中心になると思っていたのだが、僕にとって非常に意外だったのは、SNSを運用している人、あるいはSNSのサーバを作っている人が会場に多く来ていたということだ。特に、地域SNSとそれらのスケールアップを課題に持っている人が多く、その解決策としてOpen Socialに期待している、という話を伺うことができた。 Open SocialでのSNSアプリのポータビリティ性を重要と考えたため
ペアプログラミングってどうなの？
XPやアジャイルといった方法論によって有名になった「ペア・プログラミング」というものがある。その名の通り、二人でプログラミングを行うこと。これに僕は、ちょっと抵抗感がある。 まず、「ペアプログラミングは限定的なタイミングで威力を発揮する」と思っている。そもそもXPは「火消しのための方法論」をプロジェクト全体に適用しようと試みられた方法論である。僕はXPの流行前後の時期はまさに「ファイアーマン（火をつける人じゃなく消す人！）」だったため、特にXPに関しては興味を深く持った。例えば「不具合対応」という比較的細かな問題解決に対して、すでに大きなコードセットに立ち向かうためには、自分の知識だけでは足りない。つまり、コードセットの中で自分の知らない箇所や全体感などを把握している他人と共に「ここでもない、あそこでもない」とやり取りしながらコードを修正していくことは、バグ潰しという暗い作業を明るくしてく
毎回繰り返される不安と問題
実際のところ、システム開発における情報の蓄積および検索や体系化・再利用って、どれくらい行われているのだろうか？ 次々と迫ってくる開発案件。一つ案件がこなされる中で、不安材料とその解決方法は必ず蓄積される。しかし、次の案件にそれが生かされることはなく、振り出しに戻り、再度同じような反省材料と問題の解決方法が導かれる。そこには多くの車輪の再発明が含まれ、知識を脳みその中に蓄積している社員が退職してしまえば、全社的に情報がリセットされる。情報が属人化された結果、最悪なケースとしては、知識を持つ社員の人間性にその情報の活用が左右される。 少なくとも僕が渡り歩いてきた道の中で、そのような知識データベースに巡り合ったことは僕はない。素朴な疑問として、暗黙知として留めずに形式知として生きた情報を手にしているシステム開発ベンダーって、どれくらいあるのだろうか？ もし皆無だとすると、なぜそれが実現できないの
サーバをSolaris10に移行しています
サーバをSolaris10に移行しています Written on Feb 14, 2008. Posted in My PC environment ここ数日、このブログも、Eclipseのアップデートサイトも、こみゅすけも、eisbahn.jpで提供している全てのサービスを停止させていただいていた。昨日のデブサミでも何名かの方々から「どうしたの？」とご心配いただいてしまった。 落としている間何をしていたかというと、3年近く運用環境としていたLinuxのディストリビューション「Fedora(3, 6)」に別れを告げ、Solaris 10に移行しようと思ってせっせと作業をしていた。OSのインストール、Bind、Postfix、qpopper、Apache、PostgreSQL、perl、MovableType、VNCといったところがやっと導入完了。作業を始めたのがこの前の日曜日なので、約5日
ActiveResourceで拡張子なしのURIを発行する方法
Ruby on Rails 2.0から標準搭載されたActiveResource。これを使うと、RESTful APIをActiveRecordのように叩くことができるようになる。自分でURIを作ってopenすることもせず、レスポンスを自分でパースしてオブジェクトを作ることもせず、数行の記述でRESTfulなサービスを利用することが可能になる優れものだ。ActiveResourceの詳細は、 ここを見て欲しい。 さて、現状のActiveResourceは、僕にとって一つ気になる点がある。それは「URIが必ず拡張子付きで発行される」という仕様。例えば、 class Community < ActiveResource::Base self.site = ‘http://commusuke.eisbahn.jp/api/’ end として、「Community.find(1)」と実行すると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
