オレ流AngularJSを使った設計ポリシー
Chrome MySQL Adminでは、 AngularJSを使って実装を行っています。Chrome appsでは、 何らかのMVC Frameworkの利用が勧められています。 AngularJSは、Controller、Directive、Template、Serviceなど、いくつかの部品群を組み合わせてアプリケーションを構成することになります。その機能の豊富さ故に、実はちゃんとしたポリシーを決めておかないと、いかようにでも作れてしまうために、かえって複雑さが増してしまうという危険性も出てきます。もちろんアプリケーションの作り始めは試行錯誤の連続なのですが、徐々に自分なりのポリシーみたいなものが確立されてくるはずです。 本エントリでは、Chrome MySQL Adminでの設計/実装ポリシーを簡単に紹介してみたいと思います。ちなみに、全てのソースコードは、以下にあります。 htt
僕が考えたChrome拡張機能を作るときのデザインパターン
最近いくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします。 Image collector extension goo.gl URL Shortener extension mixi Check button extension Semantic inspector これだけ作ってると、何となく自分でのChrome拡張機能を作り出す際のデザインパターン・・・っていう大それたものじゃないけど、ようはテンプレが確立されてきます。全く褒められない書き方をしているかもしれませんが、ここでそのテンプレ達を晒しておこうかな、と思います。 manifest.json まずはChrome拡張機能の要であるマニフェストファイルです。これは誰が書いてもさほど変わらない記述内容となるでしょう。 { "manifest_version": 2, "name":
maven2のsiteゴールで自作ページを追加する
maven2のsiteゴールは，標準Webページや各種レポートの出力により，プロジェクトの情報共有を行うためのWebページを簡単に生成することができる。もちろんこれだけでも十分魅力的なのだが，特にオープンソースなライブラリなどを開発するプロジェクトであれば，そのライブラリの使用方法やチュートリアル，ダウンロードページなどを追加して，siteゴールのみでコンテンツ全てを賄いたくなってくるだろう。今回は，siteゴールで自作のWebページを追加する方法を紹介しようと思う。 まずは，siteゴールを提供してくれるmaven-site-pluginプラグインについて，日本語を使用できるように設定しておく必要がある。もちろん自作のWebページは日本語で記述したいだろうから，ほとんどの場合この設定は必須となるだろう。 … org.apache.maven.plugins maven-site-plug
maven2のsiteゴールによるレポートの出力
maven2によって管理されているプロジェクトは，siteゴールを使用することによって，さまざまな情報をWebページとして自動的に出力することができる。これについては，「 maven2のsiteゴールによる標準Webページの出力」エントリで紹介した。今回は，プロジェクトの成果物に関する各種レポートをWebページとして出力するための方法を紹介してみよう。 Javaソフトウェア開発では，ソースコードを元にしてさまざまな2次的成果物を作成することになる。コンパイラによるclassファイルの生成や，コメントの記述を利用したJavadocの出力などが代表例としてあげられるだろう。それに加えて，単体テストの結果やカバレッジ率の測定結果なども，やはり2次的成果物ということができるだろう。 これらの出力は，maven2を利用していれば，いとも簡単に行うことができる。 ポイントは，pom.xmlファイルのr
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)」と実行すると、
DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。 結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。 DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
