« 2014年12月 | トップページ | 2015年2月 »

2015年1月の記事

DBFluteって、凄いんだぜ!

1月の定例会で、忠さん(あだ名です)からDBFLuteの紹介をしてもらいました。

Pict2677_2
現在の顧客先サービスの開発で中心的に利用されているフレームワーク(と言うか、O/Rマッパーや強力で柔軟なツール群のセット)で、習得がちょっと大変、と言うか奥が深い(言い方を変えれば、習熟度が高まるほど、成果物の品質をより良いものに出来る!)フレームワークのようです。

Seasarプロジェクトの一部ですが、恥ずかしながら、このプロジェクトに参加させて戴くまでは、少なくとも私自身は勉強不足で聞いたこともありませんでした...。

しかして、その実態は?!.....

DBFluteって、凄いんだぜ!
というタイトルで始まった、忠さんのプレゼン&オンコーディングでのデモ

Pict2678_2
Pict2679_2
Pict2680_2とにかくDB変更に強い!・柔軟!

「アジャイルな開発プロセス」を採用すれば、必然的にDBも徐々に変更・拡張されて行きます
見直しと最適化が必要になって来ます。

変更をしたなら、再テストが必要です。

しかし、テストの工数は大きい!
かと言って、手を抜けばデグレードしてしまいます。

Pict2681_2「自動テストが有るじゃないか?!」と思うかも知れませんが、DBに関わる変更は影響範囲が広い。
書き直さなければならないテストコード自体のメンテナンスも、かなりの工数になります。

また、自動テストは「テストコードは正しく書かれている」という暗黙の?前提に立って行いますが、書くのは人間です。
人間は間違いを犯すもの。
だから、自動テストで効率を上げたい......のだけれど、テストコード自体を確実に正しく書く&変更も正しく行い続ける、ってのも結構な負担です。

レビューで精度を上げることは出来るかも知れませんが、その分、工数を食います。

結局、メリットとデメリット、「効率」を何処の範囲まで含めて解釈するのか?、そもそも納期に間に合うのか?、品質を担保できるのか?.....
いろいろな要素を考えつつ、「自動テストを適用する範囲・対象」にガイドラインを定め、「無闇に全コードにテストを仕込むのではなく、適度に手を抜く」ことが必要になって来ます(この「適度」の判断が難しい...)。

DBFluteでは、「RDB指向のタイプセーフ」という考え方で、「ConditionBeanの実装」を行うというアプローチを取る(勿論、新しいスキーマからコードを自動生成するということが前提にあります!)ことで、これらの工数増を抑えようということらしい。

また、「O/Rマッパーに頼りきれない、結局は複雑なSQL文はガリガリ書かないと動かせないよね」というシーンは、大抵のWebアプリ/Webサービスで生じることではないでしょうか?

と、そんな時には「外だしSQL(2WatSQL)」!!

2WaySQLとして必要なSQL文を書いて自動生成ツールに食わせると、
引数として使用するDTOも、検索結果DTOを自動生成してくれる点は勿論のこと、「SQL文の部分だけを、外だしSQLのソースからコピペしてアクセステストが出来る」ようになる!

この辺は詳細&正確には、私には書けません...。オリジナルのサイトを参照して下さい。http://dbflute.seasar.org/

Pict2682で、更に凄いのが、「テーブル定義書を自動生成してくれる(しかもドキュメント内でハイパーリンクしていて、効率的にテーブル間の関係を追えるようになっている!)」。

多くのプロジェクト(特に、拡張・変更を繰り返した寿命の長いシステムとか...)で見られる光景ですが、「既存ドキュメントが正しいという保証は無い(と言うか、正直言って9割正しかったら素晴らしい!?)」。

ところが、「出来上がったRDBスキーマからテーブル定義書を自動生成する(しかも、フィールド説明等もコードのファイルから自動的に抜き出して埋めてくれる!!)」ことが出来るので、コード&ビルド&システム・リリースの管理さえ出来ていれば、「ドキュメントが当てにならない、なんて事は起きるはずが無い!」。

これって素晴らしいことですよ!

この、テーブル定義書の自動生成機能は、DBFluteを使っていない既存のRDBに対しても使えるそうです。
勿論、その場合はフィード毎の説明等は埋めてくれませんが、「全てを人力でテーブル定義を起こさないといけない...」に比べれば、遥かに楽で確実でしょう!

そして更に!、DB変更を行った場合の、「各メンバーのローカル環境(RDBを各人の開発マシン上に構築している場合)の最新化を統一・徹底できない!」という問題にも対応しています!!(ReplaceSchema運用)

うっひゃー!

Pict2683

更に!(まだ有るのか...)、ハンズオンが同コミュニティ/サイト上から提供されています

そのハンズオンを進めていくことで、DBFluteの思想の理解と、より効率的に利用していく為の思考力が得られるようになっている、と(しかも、敢えて正解は提供されていない)。

凄く面白いですねえ!、素晴らしい!

Pict2685Pict2686より良いモノをなるべく楽をして提供できるようにする為に、苦労して(楽しみながら?)こんな思想と実現の為の成果物を作り出してしまう人がいるんですねえ。

改めて感心してしまいました。

また、分かり易くて面白い解説&デモをしてくれた忠さん、有難う御座いました!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (2) | トラックバック (0)

Ruby on Rails(RoR)での開発って...。

実質的に、今年初めての投稿になります。
今年も宜しくお願いします!もう1月下旬だっての!!)。

さて、新年早々の全社定例会は1/16(金)に行いました。

Pict2673
最初の記事は、社内・若手の渡辺さん(当ブログからリンクしている「Selenium関連ページ」は、殆ど全て渡辺さんによる原稿が元になってます!)による、「Ruby on Rails(RoR)による自社サービスのバックオフィス開発」から Rails の概要紹介です

弊社;アスペアでは、現時点までではJavaを始めとして、.NET系(主にC#)、PHPが主な開発言語になっています。
Ruby は実質的に Rails と必ずセットになっている感じですが、Rails での開発実務は(個人での趣味の開発経験のある数名を除けば)実績がありませんでした。
(今回、同時に活用しているjQueryは、経験の幅の差こそあれ、殆どのメンバーが経験済みですが)

Pict2674で、現在展開中の自社サービスのバックオフィス機能の追加開発に、RoRを採用してみようか?!
担当者個人にとっても、自社にとってもナレッジの蓄積になるし...、ってことで、今回、渡辺さんに RoR でのバックオフィス機能の開発を、学習・調査と並行しながら要求定義・設計・製造・テスト&リリースまでを担当して貰いました。

米国では RoR が最もポピュラー(?)で、Rails技術者の報酬が最も高いような記事も見かけるのですが、日本では Java、PHPが未だ幅を利かせていると思います。
(ことに、「巨大サイトの構築をPHPで行うのは適さないのでは?」といった声も社内外にあります)
市場の要望に応じて、PHPは社内の全員がサポートできますが、「俺は(私は)PHPが大好きっ!」という人は見かけませんね.....。

まあ、最初のWeb実装を Java から入ったという点が有るのかも知れませんが...。
(勿論、PHPのメリット、前提条件による向き/不向きが有ることは全員が認識しています)

さて、話は逸れましたが RoR の話。

Pict2676_2自社サービスとは言え、実務には変わりは有りません。
最低限の設計資料と共に、どんどん機能実装&リリースを繰返していきます。

あ、ちなみに、今回のバックオフィス開発は渡辺さん1人ですが、フロント開発担当者やデザイン担当とのコミュニケーションは欠かしていません(適宜での要求変更や追加なども有りました)。

また、「かんばんボード」も活用していますし、朝会も実施しています。
リリース毎のレビューと、後続反復への改善活動も継続して行って来ました。
(まあ、これらの点から「アジャイルな開発」と言っても全くの的外れではないと思ってます)

で、いきなり総括して今回の実開発上から得られた感想を幾つか。

※DBを直感的に扱えて便利!
※但し、複雑な検索・更新などは、結局は自分でSQL文を書かないとダメ。
※「コードの行数が少なくて済む!」という謳い文句を実感した!、確かに1行に簡単に(しかも見易く)書ける!
※IDEに良いものが無い。今回はEclipseにプラグインを入れて開発したが、コード補完機能が残念な状態。
※生産性に関しては、未だRoRに慣れているとは言い難いが、それでもPHPの時の1.2倍程度には達している。
※習熟度が上がれば、生産性の差はもっと広がるだろうと感じている。

.....とのこと。

Pict2675
言語やフレームワークは勿論のこと、開発支援ツール、プロジェクト運営支援ツール群、それらを有効に活かす為の開発プロセス/チームビルディングなど、様々な点で「良いものを、より早く、しかも楽しく作り・提供できる」ように、
ナレッジの蓄積と共有、提案への活用などを積み重ねて行きたいと改めて思いました。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

旧サイト閉鎖のお知らせ

アスペアの旧サイト(タイトル:「アスペアと町田」)は、2015/01/06を以て閉鎖させて戴きました。

2007年の更新を最後として、現在のアスペアの状況とは余りにも乖離した内容となっている為、返って弊社の理解を戴く上では誤解を招く危険性が高いと判断致しました。

以前のサイトでは、弊社:アスペアが存在する「東京都・町田市」の事務所周辺の紹介記事が多数を占めていました。

こちらは、変わったこと・変わらないこと、色々だろうと思います...。

一方、弊社:アスペアに関する記載も当然のこと多く存在していたのですが、こちらの方は前述の通り、7年を超える年月と共に必然的に変化して参りました。

当サイトの目的は、弊社:アスペアを知って戴きたいというのが主な目的でした(「町田」の紹
介は、その一端のつもりだったのですが、余りにも肥大化し過ぎてしまいました...)。

以上の理由・経緯により、旧サイト「アスペアと町田」は閉鎖とさせて戴きました。

ご愛顧戴いた方々には大変に申し訳ないのですが、どうぞご了承頂きますよう宜しくお願い致します。  m(_ _)m

| | コメント (0) | トラックバック (0)

« 2014年12月 | トップページ | 2015年2月 »