サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
hibituredure.blogspot.com
アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。 ビジネス的な有用性はどこにあるのかEvans氏発言要旨 経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか?という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。 雑感この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待してい
少し前になりますが、DSL読書会@JavaEE勉強会でCode GenerationとLanguage Workbenchesのまとめを発表したので、ここにも載せておきます。 Google Docsで作ってみたのですが、Slide Shareと勝手が違っていて、埋め込んだ状態でうまく閲覧できそうにないです。まともに見たい人は、最大化ボタンをクリックするのが良いかと思います。 僕の担当分はDSL本の最後の部分で、この資料はそれまでの部分のまとめが他の人から発表されている前提で作っています。これだけ見てもあまりわからないかもしれませんので、字だけになりますが少しだけ補足しておきます(Fowler DSLのエッセンスにさらっと目を通しておかれると、少しは分かり良いかもしれません)。 DSL Overview DSL概念全体の中でCode Generationがどのような位置づけにあるかを俯瞰する
概要 ドメイン(問題領域)のオブジェクトモデルを作成し、そこにドメインロジックと処理対象データを持たせるパターン。一見したところDBモデルと似ているが、データと処理両方を持っている点が異なる。条件分岐で処理を実行するかわりに、オブジェクトネットワークをセットアップする。作成されたパスをたどりながら処理を実行することで、目的を達成する。つまり、オブジェクト構造自体がアルゴリズムになる。 メリット 複雑で、変更が絶えず発生するロジックの修正コストが低い。ロジックの重複が少なく、規模は比較的小さくできる? デメリット トランザクションを多数のオブジェクトの相互作用によって実現するため、多数の開発者による並列開発が困難。(少なくとも、慣れていない人にとっては)設計が難しく、理解も難しい。 データベースとのマッピングが困難。 注意 ドメインオブジェクトに置くべきかどうか迷うロジック ドメインオブジェ
アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。 ビジネス的な有用性はどこにあるのか Evans氏発言要旨 経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか?という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。 雑感 この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待し
とあることからFowler DSLのエッセンスを考える機会があり、昔内輪向けに作った資料を引っ張りだして眺めてみたが、わりと良い線いってると思う。 HEAD FIRST DSL View more presentations from kentaro watanabe.FowlerのDSL本が提示する価値は、おおまかに以下の3点にある。上記のスライドでは1と2にフォーカスしている。 モデルを中心に据えた思想の提示実装スタイルの分類実装テクニック集これは、紙幅の大半が3に割かれており、書いた時点では実装テクニックを全て把握していなかったことや、そもそも3はまとめがほぼ不可能、ということもあった。 モデルを中心に据えた思想の提示 従来のDSLでは、スクリプトによるモデルの組み立て、という考えが必ずしも明示的に意識されておらず、DSLがもたらす価値の源泉はDSL自身にある、と考える傾向が強かった
DDD読書会@JavaEE勉強会代表として、「DDD難民に捧ぐ」の佐藤さん、読書会主催syの角田さん、思想系プログラマの和智さん、モデレータのt-wadaさんと一緒にパネルをさせていただきました。 推進派の佐藤さん、懐疑派の角田さん、受託開発現場の立場から自分、言葉を重視する立場から和智さんと、短い時間ながら立場を明確にしたパネルができたと思っています。 【19-B-5】出張!DDD難民救済キャンプ View more presentations from kentaro714. パネルの内容自体に関しては、SlideShareをながめながらtsudaってくれた方のTweet(#devsumi2010ハッシュタグ)を眺めれば、おおよその話は見えてくると思います。特に@yattom さんがとても詳細にtsudaってくださっています。 # yattomさんありがとうございます! というわけで、
このたび発売になる「実用Git」を、hirataraさん、kaisehさんと共訳させていただきました。きょう配本だそうなので、ぼちぼち書店に並ぶのではないかと思います。 この本は、前から順番に読みつつ出てくるコマンドを叩いていくことで、自然とGitが内部構造も含めてわかるようになっていることが特徴です。Gitを理解するには内部構造を知ることが近道なのですが、概念的な話だけでは頭に入ってきません。この本では、実際にリポジトリを用意し、コマンドを順に試していくことで、日常の作業と内部構造がつながりをもって理解できるように構成されています。 コマンド出力も丁寧に載せられているので、Git環境が手元にない場合でも、実際にGitを使っているように学ぶことができます。 自分自身、この翻訳をはじめた時は特にGitに詳しいわけではありませんでした。しかし、翻訳をすすめてGitを理解するにつれて、バージョン
最初に読んだ時には今ひとつ理解できなかったAggregate。社内のDDD読書会で読み返してみて感じたのは、「Aggregateは、従来の手続き的な一貫性維持に関する情報(トランザクションスコープ含む)をモデル上に明示したものである」と捉えることで理解しやすくなる、ということ。以下もう少し詳しくみていく。 Aggregateの定義と位置づけ DDDのGlossaryを見るとAggregateは、 A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consiste
アクターモデルは最後らへんかなー…と思ってたら、ScalaByExampleのChapter3はいきなりアクターモデルの話(Programming with Actors and Messages)だった。ちなみにChapter2は言語仕様の特徴的な部分のOverviewのような感じ。 Chapter3ではまず、丁寧に(Erlangスタイルの)アクターについて説明してくれている。 Actors are objects to which messages are sent. Every actor has a “mailbox” of its incoming messages which is represented as a queue. It can work sequentially through the messages in itsmailbox, or search for
数ヶ月前から社内でDDD勉強会を実施していて、最近「ユビキタス言語(Ubiquitous Language)」まで来たんだけど、ここでやっぱり「日本語を使ったら1つの言語、モデルになるのか?」という疑問が出てきた。JavaEE勉強会でも同様の意見が(確かhirataraさんから)出てきていたものの、残りの部分に答えが書いてある可能性もあったので、その時点では「まぁ、用語の一覧みたいなのを作ってなんとかすればいいんじゃないの?」と流したものの、あらためて同じ問題に直面してみると、なかなかやっかいな問題だ。先に進む前に、この時点での自分なりの結論を書いておく。 DDDの世界観まずは、DDDにおけるユビキタス言語やモデルの扱いについて簡単にまとめておく。# 断るまでもないと思うけど、もちろん個人的な理解。 ユビキタス言語はドメインモデルに基づく言語であり、ドメイン専門家と開発者の双方が作り、双方
リストのすべての要素を何かしらの方法で変換する操作は、Mapと言う。MapReduceのMapと同じだよね、たぶん。例えば、DoubleのListのすべての要素に、何かしらの数を掛け合わせたい場合を考えてみる。 def scaleList(xs: List[Double], factor: Double): List[Double] = xs match { case Nil => xs case x :: xs1 => x * factor :: scaleList(xs1, factor) }
via おとうさん、ぼくにもYコンビネータがわかりましたよ! きしだんさんすごいっす。自分も学習のために、ラムダの復習も兼ねつつJavaScriptでトライしてみる。独学で適当にやってるので間違いも多数あると思いますが、ご容赦を。 ラムダ ラムダ式は、関数の表現形式みたいなもので、おおよそfunction式に相当する。引数が複数あるのが違うところだけど、この話は後で解決する。(非形式的な)ラムダ式ってこんなもの。 λx.x*2このラムダ式は、xを受け取ったら2倍して返す関数を表している。 最初は読むのに(特にλ記号が複数になった場合に)とても苦労したんだけど、引数を「λ」と「.」で挟み込む形で表現した関数だ、と考えるとずいぶん読みやすくなった。これをJavaScriptで表すと… function(x) { return x * 2 } こうなる。ラムダ計算の体系では、計算のすべてをラムダ
実は第2回にも行っていたんだけど内容をまったく咀嚼できず、そのうちやろうと思っているうちに第3回が開催されてしまった ^^; 第2回 ラムダ計算と停止性問題 第2回は、主にラムダ計算について。前回の復習からはじまって、回路図のような絵を交えながらラムダ抽象化につなげていき、最後はJavaScriptのようなCのような疑似コードを使って、チューリングマシンの停止性問題を背理法で証明して終わった(と思う)。詳しくは、檜山さんのBlogに書いてあるので、そちらを見た方が良いと思う。 セミナー資料 紙芝居:ラムダ抽象 セミナー非参加者にもわかるリアルワールド向けラムダ計算 なぜ停止性について話したのか? 第3回 自然演繹と型付きラムダ計算、カリー/ハワード対応 第3回は、カリー・ハワード対応についての感覚的な理解がゴール。第2回とはうってかわって論理を中心に話をすすめていき、論理でやっていることが
またまた行ってきた。前回(論理・ラムダ・圏)、タイトルに「圏」とありながら、実際は圏の話がほとんどできなかったことを受けてはじまった、新シリーズ。細かいところや背景知識なんてわかるわけがない(数学ほとんどやってないし)ので、わかった範囲で書きとめておく。間違いまくってる可能性大。 全体的に教科書的に進めようかと思っていたそうだが、檜山さんが体調不良で方針転換。形式的なものより、お絵かきメインで進めることになった。 というわけで、第1回の予定はこうでした。まえおき/まえせついろいろな図の描き方圏の定義と実例休憩行列の圏で遊ぶコレクション・データ実際は、3の途中まで(休憩はやったよ!)で終了しました:-D まえおき/まえせつシリーズ全体の目標としては…圏の基本概念を学ぶ モナドの実例をたくさん知るモナド法則に慣れるモナドのクライスリ圏の作り方を知るモナドがモノイドであることを理解するこんなとこ
MS萩原さんのセッション。同名の書籍(元ネタはDBマガジンの同名の連載)が元になっていて、そのダイジェスト版+最新の動向の補足、という形。とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。 アーキテクチャの原則アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。 アーキテクチャ先行定義の原則アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。 モデリングとアーキテクチャ設計の双方のインプットとして、シ
社内でGoogle App Engineのミニ勉強会をやることになったので、技術者らしくAPIとかBigTableまわりとかやろうかなーと思って色々ドキュメントをあさっていたところ、思いがけず非常に面白いものを見つけてしまった。 それは、料金体系。たいていのGAE紹介サイトには、〜まで無料、以降〜みたいな形でさらっと書いてあるんだけど、思った以上に奥が深い。DoCoMoやソフトバンクモバイルより奥が深い。しかも、この料金体系によってアプリケーションの作り方にまで影響が出てくる可能性がある。こうなってくると、JPAとかJDOとか開発環境とか紹介するのなんて馬鹿馬鹿しくなってしまった。Google App Engine勉強会、って名目で人呼んどきながら、ずーっと料金の話ってありだろうか?なしだろうなぁ。 基本的な概念、リソースとクォータ さて、Google App Engineには利用可能な資
気づいた時にはちょっと感心してしまった。思いつきはするけど、ほんとにやるか!みたいな。そんなこんなで、KGSお客様番号をもとに日本の住所を割り出して転送する、と。そうそう、海外ショッパーズに支払うお金のうち、手数料は登録したクレジットカードで支払われるけど、海外発送料は着払いになっているので、現金を用意しとくこと。(今は着払いでもクレジットで払えるのだろうか?よく知らない。) 個人輸入にまつわる注意点 海外ショッパーズの梱包はしょぼい 自分のケースだけかもしれないが、海外ショッパーズは(一応)購入した製品をさらにダンボールで梱包して送ってくれる。しかし…自分の家に届いたダンボールは、どうみても使い古しのヨレヨレボロボロのダンボール。あけて中を見てみると、ダンボールよりかなり小さいRoombaの箱(というよりダンボールがやたら大きい)のまわりに緩衝剤(一応)が。この緩衝剤、ほとんどエアが抜け
丸山先生のジェネラルセッション。内容的にはEric Brewerの資料(CAP Theorem/Eventually Consistent)をクラウドの立場から眺める、といったもの。 ScalabilityとAvailability Scalabilityは、Scal-outによって達成できるが、Scale-outには技術的な裏打ちが必要であり、ノウハウの蓄積が必要。 Availabilityは、故障に対する適切な対処によって達成できるが、これには複製を作成する戦略(Replication)が基本になる。複製を作ってしまうと、同期の問題、すなわち一貫性に関する問題が発生する。 [メモ] CAP定理で言うと、ScalabilityがおおよそPartitionに、AvailabilityがそのままAvailabilityに、一貫性がConsistencyにあたると考えてよいと思う。上記は、クラ
ほとんど「大規模サイト構築のノウハウ全部見せます!-全部で20以上あるよ!-」みたいなノリだったので、とても全部メモることはできなかった。プレゼン資料欲しいです。
QCon Tokyo最後のセッション。以下のような豪華な参加者陣でした。 Floyd Marinescu (InfoQのエラい人) Dylan Schiemann(Dojoのエラい人)Randy Shoup(eBayのエラい人)Gregor Hohpe(Googleの中の人、EIPの共著者)Henrik Kniberg(Agileなコンサルタント)一緒に行ったメンバーとの会話で、なんとなく自分が担当になった雰囲気がしたので、わかる範囲で書き起こしつつ、自分の感想も(発言とは区別がつく形で)書いていきます。メモが中途半端なので、話をつなげるために微妙に補足してたりします。会話口調は、そのときの雰囲気から適当に作ってます。敬称はすべて省略してます。発言者とか間違えてるかもしれないので、その辺ふまえつつ適当に見てやってください。 [まずは、エンタープライズソフトウェア開発の動向について全員が2分
QCon Tokyo 2009 QCon Tokyoは2日間開催で、それぞれの日ごとに3つのトラック({1日目 => [Architecture, RIA, Ruby], 2日目 => [Cloud Computing/SOA, Agile, Case Study]})が設定されていて、トラックごとにセッションが4つ設定されている。また、各トラックに属する個別セッションとは別に、日ごとに2つのジェネラルセッションが設定されていて、大御所たちが話すことになっている。 QConでは、良いと思ったセッションに緑、普通と思ったセッションに黄、いまいちと思ったセッションに赤のカードを入れることになっているんだけど、これに習って自分が出席したセッションを評価すると、こんな感じになる。 [緑(よかった!)] アーキテクトの審美眼 by 萩原正義General Session 1 クラウドの技術的な特徴に
今更だけど見てみた。 1時間以上あるのに軽く引くが、本当に重要なのは30分程度。残りはこの人の経験談や、JavaScript界隈の近況、質疑応答。 この人のプレゼンは、皮肉がきいていて面白い。とりあえず、わかった範囲でメモっておく。 JavaScriptの現状 いまだに最も誤解された言語誤用しては怒っている人多し最もすばらしいアイデアから、もっともひどいアイデアまで含まれているこんなに幅の広い言語はほかにないコンピュータ科学者からカット&ペースト厨まで、どの言語よりも幅広いスキルの人が使っているJavaScriptへの不満 ブラウザプログラミングはひどいもんだ。 => まったくその通り 十分な速度が出ない。 => 現在ではすでにJSではなくDOMの問題。今はランタイムは十分速い。失敗の積み重ねだ。 => Javaが完全に失敗した環境でうまくやりつづけているだろ? 影響を受けた言語 Self
QCon Tokyoでは色々なところで「CAP Theorem」という定理が出てきた。が、eBayの人をのぞけば(たぶん)正確な定義は提示されておらず、不明な点がいくつか残っている。これからのインフラを考える上でも、QConセッションの内容をより良く理解するためにも、このあたりをまずきちんと理解しておきたい。主な疑問点は以下のとおり。 C, A, Pの特性の正確な定義は何なのかCAP定理が前提にしているシステムのモデルはどのようなものなのか Theoremとなっているが、単なる経験則なのか、それとも数学的な定理なのか 頼みの綱?のWikipediaを調べてみたが、日本語版はおろか英語版にも載っていない。概観をまとめた海外の記事を結城さんが訳してくれているようなので、これを読んでみる。 CAP Theoremそのものは、Eric BrewerがPODCカンファレンスのキーノートで提唱したもの
イケメンGregor Horhpeによるクラウドセッション。この人は、Martin Fowler SignitureのEnterprise Integration Patternsの著者の一人でもある。今回はEIPではなく、BASE〜CAP Theorem〜Google App Engineといったあたりのお話。 クラウドの良い点、悪い点 アーキテクト(の関心事)にとっては、夢を実現するコンセプト。 疎結合拡張性標準への準拠耐障害性無制限のコンピューティングパワーユビキタスしかし、開発者にとっては悪夢の発現。 No Call StackNo TransactionNo PromisesNo CertaintyNo Ordering Constraint# No Certaintyがよくわからず、訳せなかったので全部英語 ^^; [メモ] このあたりは、パネルディスカッションでGregorが
アクターモデルの説明あたりで謎が残ったCaseクラスとパターンマッチ。ようやくわかるのだろうか。 概要 Caseクラスとパターンマッチは、相互に関連するクラス群をグループ化して定義し、クラス群のそれぞれに対して異なる操作が必要になった際にクラス群を分解して個別に処理を行わせることができる仕組みの1つ。なんのこっちゃ。 OO言語のポリモーフィズムについて考えてみると、これは完全に上記の説明に当てはまることがわかると思う。ポリモーフィズムでは関連するクラス群を型階層としてグループ化し、個別の型に対して異なる操作が必要になった場合には、それぞれのオブジェクト型にふさわしい操作が動的に選択されて実行される。 Caseクラスとパターンマッチは、これを違う角度から実現するもの。イメージ的には、Enumとsiwtch + instanceofをまぜあわせて言語仕様に組み込んだような感じ。Enumライクに
いわゆるGenericsのメカニズムについては、ごく基本的な部分についてはJavaと同じように見える。型パラメータの境界(親の型としてXXXを持ってないといけないとか、子の型としてXXXを持ってないといけないとか)についても同じ。大きく違うのは、型パラメータの継承関係と、パラメータバウンドされた総称クラス(以下、面倒なので"総称クラス"と書く)自体の継承関係との関係、すなわち共変(Co-Variant)に関する部分。 といっても、共変自体にあまり詳しくないので、しばらく共変について勉強してみる。 共変 調べても定義らしい定義が出てこなくて困った。とりあえずは関連ありそうな記事として以下のようなものがあった。 Javaの理論と実践: Generics、了解! Javaの理論と実践: Genericsのワイルドカードを使いこなす、第1回 Javaの理論と実践: Genericsのワイルドカード
まず最初は、Action Pack: Resourcesというもの。中身を読んでみたけど、そもそも拡張前の仕様がわからないからさっぱり意味がわからない。 というわけで、まずはサンプルとしてあげられている「routes.rb」について調べることにする。ちなみにroutes.rbは、configディレクトリの中に置いてあります。またまたGoogle検索してみると… 優しいRailsの育て方 routes こんな素晴らしいページが。Migrationの時と同じBlogだ、感謝。 んで、これを読んでみると、routesはURLとコントローラ/アクションのマッピングを行うためのものらしい。基本的には、マッチするURLパターンと、マッチした場合に追加するリクエストパラメータ(キーと値)を指定できる。で、ここで map.connect '', :controller => "berryz", :acti
次のページ
このページを最初にブックマークしてみませんか?
『A Life in Shinjuku.』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く