詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある - L'eclat des jours(2014-03-11)
_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある 流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。 ・要件定義書 要件を定義したもので、ユースケースについて記述したものだ。 ・機能設計書 要件を機能として記述したものだ ・詳細設計書 機能を実装に落とし込むものだ で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。 特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。 しかし、実はそう単純でもない。 問
AsakusaFW Operator DSLメモ(Hishidama's Asakusa Framework FlowDSL Memo)
概要 [/2016-02-11] 用語 演算子一覧 [/2019-06-14] どの演算子を使えばよいか [/2013-12-23] Optionクラス [/2021-12-21] Resultクラス [/2017-04-30] 値引数 [2018-09-26] GroupView [/2018-11-12] Sharedクラス [2017-06-04] マルチスレッドに関する注意 [/2016-05-30] プロパティーファイルの読み込み [2017-06-04] Asakusa Framework documentation 演算子リファレンス Asakusa DSLユーザーガイドの『Operator DSL』 cocoatomoさんの演算子選択のための流れ図 teppei_tosaさんのAsakusa 演算子 CheetSheet 概要 Asakusa Frameworkでは、Flo
Xtext超便利！ - ひしだまの変更履歴
ひしだまＨＰの更新履歴。 主にＴＲＰＧリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。 「Xtextってものがあるよ」と言われたので試してみたら、超便利で感激した！ Xtextは、DSLのエディターを作れるフレームワーク（Eclipseプラグイン）。 BNFみたいな記法でDSLのルールを定義するだけでエディターが作られるので、非常に便利。 自分独自のDSLを作りたいと思った場合、内部DSLと外部DSLという2つの方式がある。 内部DSLは、他の言語（ホスト言語と呼ぶ）上でDSLを記述できるようにする。例えばScalaやRubyは内部DSLを作るのに向いているらしい。 外部DSLの場合は、DSLを読み込んで解釈するパーサーを作らなければならない。パーサーを生成する言語も色々あるが、Xtextはパーサーだけでなくエディターまで生成されるところが優れている。 内部
モデル駆動(MDA)から仕様書駆動(SDA)へ - 設計者の発言
■何がMDAを殺したのか 期待されたわりにあっけなく消えてしまった技術用語は数多いが、そのひとつとして「モデル駆動アーキテクチャ(MDA,Model Driven Architecture)」を取り上げよう。ソフトウエアのあり方を「モデル」としてまとめ、これにもとづいて開発作業を合理化するための枠組みのことをいう。考え方としては昔からあったが、オブジェクト指向技術の標準化団体であるOMGによって2001年に体系化された。当時は注目されたものだが、今ではすっかり聞かれなくなった。 なぜか。MDAを実現させるための自由な発展を「UML」が邪魔したため――そう私はにらんでいる。 じっさいは、MDAにおいてUMLの利用が強制されているわけではない。しかし、なにしろOMGによって提唱された枠組みなので、UMLの利用が前提と理解されたのは自然の成り行きだった。ちょうどその頃は、この表記体系がソフトウエ
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
イマドキのIDE事情(133) e(fx)clipseでJavaFX 2を試してみよう!
JavaFX 2.0とe(fx)clipse JavaFXはもともと、Adobe AIRやMicrosoft Silverlightなどに対抗するJavaにおけるRIA技術として登場したものだ。当初は、JavaFX Scriptという独自のスクリプト言語でアプリケーションを構築するというものだったが、それほど普及が進まず、JavaFX 2.0からはJavaから利用可能なGUIアプリケーション向けのライブラリに方向転換している。 e(fx)clipseは、Eclipse上でJavaFX 2を使用したプログラミングをサポートするプラグインだ。前述のように、JavaFX 2は単なるJavaライブラリであるため、Eclipse単体で開発を行うことも可能だが、e(fx)clipseをインストールすることでFXMLやCSSの編集支援機能、FXGraphというUI定義用のDSLなどを利用することが可能に
バッチ設計と実装ガイド | Asakusa Framework
Asakusa Frameworkでは、基幹向けバッチアプリケーションの作成に主眼を置いた独自の領域特化言語(Domain Specific Language, 以下 Asakusa DSL)を利用してアプリケーションを作成します。 ケース・スタディを通じて、Asakusa DSLを前提とした設計手法と具体的な実装方法を理解することができます。 ここで解説する設計手法と実装ガイドは、Asakusa DSLの概要を理解していることを前提としています。 Asakusa DSLについては、以下のドキュメントを参照してください。 Asakusa Framework 入門 Asakusaでは、設計手法としてDAG（有向非循環グラフ）を利用した記述法で設計を行います。以下のドキュメントではAsakusa DSLの設計手法と実装手法を解説します。 AsakusaDSL設計手法（PDF） AsakusaD
JavaScriptでHTMLをレンダリングするDSL·blingbling DSL MOONGIFT
blingbling DSLはJavaScriptでHTML構造をレンダリングするDSLです。 HTMLでは表示（HTML）とデザイン（スタイルシート）、そしてプログラミング（JavaScript）が混在して動作します。それらを全て一つにまとめあげ、高速に動作するDSLがblingblin DSLです。 デモのコードです。Hello Worldと表示されています。 HTMLソースです。出力の記述はありません。 出力はJavaScriptで行っています。JavaScriptがそのままHTML構造と出力内容を兼ねています。 出力されたHTML構造です。一つ前のコードの内容が出力されています。 blingblin DSLにはblingbling HTMLとblingbling CSSの二種類があります。blingbling CSSを使えばより可読性の高い構造化されたスタイル記述ができるでしょう。
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Ashigelコンパイラ勉強会の感想 - ひしだまの変更履歴
ひしだまＨＰの更新履歴。 主にＴＲＰＧリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。 昨日『Ashigelコンパイラの勉強会』に参加してきました。 スライド：Inside of Asakusa DSL Togetter：#ashigel Ashigelコンパイラの勉強会 自分が書いてきたメモはほとんどスライドの写しなので、今回は感想だけ書きます。（というか全部理解できたとは言いがたいので、感想しか書けないというか(苦笑)） まず「DSL」という言葉について。 自分は最近Scalaを勉強していてScalaの本でよく「DSLの例」を見かけていた。Scala上に新しい構文っぽいものを作り上げ、それを使って目的の記述を行う形式。 なので漠然とAsakusa DSLもそんな感じかと思っていたんだけど、全然違った＾＾； Asakusa DSLは大きく三層に分かれていて
Perl5.11.2 の Perl_keyword_plugin ハックがまじアツイゼ!の巻。 - tokuhirom's blog
最近、さっぱり Perl のことを書かないので、Go に改宗したかとおもわれがちな tokuhirom ですこんばんわ。 http://d.hatena.ne.jp/gfx/20091121/1258770809 をみてたら、Perl5.11.2 でクールなハックがはいってることを知りました。こ れ は 熱 い!!ということでちょっと調べてみたよ! 端的にいうと、PL_keyword_plugin をつかえば、Devel::Declare のようなシンタックスを操作してしまう系の hack が可能になるということ。 つまり、Perl の syntax の制限で実現できなかった記法とかが、CPAN モジュールにより可能になるということ!その仕組みが Perl5 に公式にはいるということ! これは熱い。しかもこれ、激しく自由度が高い。これはキーワードをフックして、そっから先のパーズを Perl
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
第2回 内部DSLへの道 | gihyo.jp
今回は内部DSLの詳細、またその実践としてRubyを例にした実装について解説します。 内部DSLに適した言語 - Ruby 2005年12月にRuby on Railsの正式版のリリース以降、そのフレームワークのみならず、プログラミング言語Rubyを支持、採用するプログラマーが増えてきました。 そのことを端的に表しているのが、達人クラスのプログラマー、そしてアーキテクトの存在です。一人は『達人プログラマー[1]』『プログラミングRuby[2]』などの著書で知られているDave Thomas氏です。もう一人は『エンタープライズ アプリケーションアーキテクチャパターン[3]』などで著名なアーキテクト Martin Fowler氏です。Fowler氏が属している会社 - ThoughtWorks社[4]の多くのプロジェクトは、Rubyで開発していると聞いてます。 なぜ、彼等は、Ruby
ドメイン特化言語は英語のように書くべきではない
良いドメイン特化言語 (DSL) とは、プログラマ以外でも読むことができる英語のようなものだと広く言われている。Dave Thomas氏は、DSLは自然言語にできる限り近づくものではない(source)と主張し、そのような考え方に反対する。 さらに、これをDSL設計の指針とすることがむしろ有害であると主張する。また、彼が信じていることがDSL設計では重要であることを強調し、必ずしも英語らしくなくてもうまくいくDSLの例を紹介している。 Dave氏によると、DSLは英語や他の自然言語に近づく必要はない。なぜなら、それは実際に自然言語を話さないドメイン専門家など、かなり特別なカテゴリやユーザを対象にするからだ。 ドメイン専門家 [中略] は業界内の専門用語を話します。それは、彼らが仲間同士で効率的にコミュニケーションするための簡単な表現として発明した特別な言葉です。専門用語は英語を使うかもしれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer