タグ

ブックマーク / www.artonx.org (36)

  • L'eclat des jours(2009-07-19)

    _ 今日のRubyKaigi ささださんが、今にも泣き出しそうに感じたのは、おれだけか? (昨日の懇親会で、何気なくるびまの話を訊いたら(というか、今日のお題をすっかり失念していたのだが)、明日、終了のお話をするんだとかいってはぐらかされたが、終了ってそういう意味だったのか)。 _ 超人たちのWikiあるいはペディア(education) 江渡さんのパターン、Wiki、XPを読み終わって、振り返るに、おれは第3部のWikiが2つの意味でどえらくおもしろかった。 1つは、それが実装に関するトピックだということで、Wikiというソフトウェアについての考察だからだ。 で、問題はもう1つのほうにある。 パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)(江渡 浩一郎) 以前、山形浩生のアマゾン書評を読んでいて、やたらと印象に残ったのが、アイン?ランドの

    yohei
    yohei 2009/07/19
  • L'eclat des jours(2009-07-13)

    _ 7ページでわかるパターン、Wiki、XP 先日のジュンク堂トークセッションで、角谷&懸田コンビの掛け合いで、実は、7ページでこのの内容がわかる秘密兵器として紹介されていたのが、クリーンコードのコプリエンの前書きだ。 いや、それデタラメじゃねぇか、とあらためて読んで思ったが、でも、確かにおもしろい点は突いている。 Clean Code アジャイルソフトウェア達人の技(Robert C. Martin) 一体、コプリエンは前書きに何を書いているのだろうか? 印象深いのは、5Sだ。整理、整頓、清掃、清潔、しつけ。もちろん、クリーンコードというの前書きなので、一言でまとめれば、「このを読んで、きれいなコードを書きなさい」に尽きる。 これは、K&Kがetoさんからのアジャイルを始めるには何すれば良い? という質問に対して、ちょっと考えただけで、「あいさつすること」と答えたことに通じるものが

    yohei
    yohei 2009/07/13
  • パターン、Wiki、XP――時を超えた創造生成の原則 - L'eclat des jours(2009-07-10)

    _ パターン、Wiki、XP――時を超えた創造生成の原則 江渡さん(と角谷さんと懸田さん)のトークセッションを聴きにジュンク堂。 以下、メモの生データ どういうつもりで書いたのか 『パターン・Wiki・XP』ができるまで 2007年、オブジェクト倶楽部のイベントで講演したのがきっかけ。 2008年にプロジェクト開始 情報収集:中埜さんなどにインタビュー(都市計画の専門家としての山形浩生、ソフトウェアとしての平鍋) 2009年1月頃にレビューを開始 (角谷さん、懸田さん、shinoさんなど) →これによって、よりよくなった 例)3部構成が、2部と3部の入れ替え、章の追加 なぜ書いたのか? 内容は短時間で説明できない。したがって、なぜを説明する。 Wikiというシステムに興味を持ったのが2002年頃。 quikWebを作った (開発中の議論が良い経験になった) 機能追加によって悪くなることがあ

    yohei
    yohei 2009/07/10
  • L'eclat des jours(2009-07-04)

    _ 産み出す文化と保持する文化 相変わらずSOAPとRESTについて考える。もちろん理由もあるのだが、第三者の目で眺めて興味深いからでもある。 たとえば、WADLを眺めて、なんじゃこりゃと感じる。 LLとHL(そういえば、HLとは言わないな)があって、LLの人は既にハッピーなのだが、そこにHLの人がやってくる。なぜかは知らないがLLの人に「型宣言がないなんて信じらんない」とか言い出したりしてそこらじゅうにシグネチャを埋め込ませようとする。 いや、そんなものなくても困らないから、と言っても聞く耳を持たない。まるでイヌイットに海水パンツを売りに来たり、南洋諸島にオイルヒーターを売りに来たりする商社マンのようである。どうやら、それがなければならないらしい。もっと適切なのは、バナナがなりまくっているフィリッピンの小島のひとつに、バナナ架けを売り込みに来た商社マンであろう。さあ、君たち、バナナ架けを

    yohei
    yohei 2009/07/04
    HLでもWADLいるのかなあ。
  • 5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)

    _ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて(というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが)後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても(というか、Connectionならそういう方法もあり得るが、そうはいかな

    yohei
    yohei 2009/07/02
  • L'eclat des jours(2009-06-28): Webコンピューティングの位置

    _ Webコンピューティングの位置 コンピュータの特徴とは、ストアされたプログラムを実行することで、あらかじめ決めた手続きを高速かつ正確に再現することにある。 第二次世界大戦において、復号暗号の解読と弾道計算の2つの計算がコンピュータ開発のモティベーションとなった。 民生分野へ適用するとき、それは事務計算に対して行われた。 それまで事務計算は人間によって行われた。例外的な処理については現場の判断という柔軟な運用が可能であった。 しかしそれはコンピュータにはできないことである。 最初の価値の逆転が行われる。事務計算には例外的な処理は存在しないという前提を置くことで、この問題に対応した。 それによって、いわゆる大規模開発が許容されることとなった。開発されたシステムは中期以上にわたり変更されることはない。変更されずに使われることが前提に置かれたために、開発期間と開発要員という2つのコストを回収可

    yohei
    yohei 2009/06/28
  • L'eclat des jours(2009-03-09)

    _ 遅ればせながらUKアマゾンで買い物 ピーターラビットのが欲しいと子供にねだられた。 まあ、スタンダードだから(10年遅い気もするが)いいかなぁと思いながら、いったい、日語と英語どっちが欲しいんだ? と訊くと、両方とか答えやがる。 で、ふとUKアマゾンが安いと(もうずいぶん遅れたからそうでもないことになっているみたいだが)思い出したので、ちょっと探してみる。が、まずは、あわてず日のアマゾンで見ておく。 The World of Peter Rabbit Gift Box 1-12(Potter, Beatrix) $84が7354円か……というか、これは米ドルで書いてあるが、日で買ったほうが送料かからない分、安いかも。 と思って良く見ると、ボックスが小さい。で下に、13巻以降のもあった。 The World of Peter Rabbit: The Original Tales

  • L'eclat des jours(2009-03-01)

    _ IOU設計パターン というわけで(昨日の続き)、DDJJ 1996年10月号の『非同期設計パターン』だが、.NET Frameworkではそれらしきものが採用されているものの、そんなに広く使われているわけでもなさそうだ。 IOUパターンは、非同期IOを同期IOモデルのように、オブジェクトの利用者に見せかけるためのパターンで、非同期IOの結果をまるで同期IOのように、呼び出し側に返す。しかし、同期IOではなく、すぐに返す。 そのため、呼び出し側はお話にならないエラーはすぐに検出できる(これは同期IOでも同様。たとえばクローズ済みIOに対してメソッドを呼んだ場合)。 そうではない、たぶん、実行されるであろうIOについても、すぐに戻る。ただし、結果として返されるオブジェクトは、同期IOの場合と異なり、IOUオブジェクトだ。このオブジェクトは、筆者のAllan Vermeulenによって以下の

  • L'eclat des jours(2009-02-28)

    _ 1990年代 ある事情から1990年代の終わりから2000年代の初めのあたりに書かれた文章群を読んでいるのだが、非常に不思議な感じがする。 それと並行しながら、棚を整理しまくり、捨てたり、テラダの倉庫に預けるための箱詰めとかをしている。 どえらく古いDDJJとかが出て来て、ぱらっと見て、捨てたり、どうしようか迷ったり。ここでも非常に不思議な感じがする。 たとえば、1996年10月のDDJJが出てきた。これまで2回のフィルタリングを通して残してきたのだが、最初のフィルタリングから先、読んだ覚えがないので、おそらく今回のフィルタを通過させても読まないだろう。したがって、捨てたほうが良さそうだ。 その不思議な感じの1つの理由として、個人的なものがありうる。一番、いろいろ吸収しまくる必要もあれば実際にしたせいで、特に印象が、その時点のもので形成されているという可能性だ。したがって、反応しやす

  • L'eclat des jours(2008-11-20)

    _ ACIDからBASE ちょっと勉強。 BASE:ACIDの代わりをどうぞ 要約(のつもりだったがのりで)抄訳:(誤読は十分あり得る) これまでは垂直拡散(うまい訳はなんだろう? vertical scaling)ってのがひとつの方法だった。よりパワフルなマシンへ移行するという道筋だ。何より簡単だってのがいいところ。でも、問題がある。どこまででもでかくできるわけでもないし、何より金い虫だ。 それに対して水平拡散(horizontal scaling)ってのもある。いや、でもこれは複雑になる。この場合は、2次元で考えるといいね。横方向は機能分割。縦方向は断片化だ。Oracleのパーティショニングあたりとかかな。 機能分割はいいんだけど、そうなると1つのトランザクションが複数のデータベースサーバーをまたがる必要が出てくる。 エリック?ブルーワっていうバークレーの先生で、インクトミの首席サイ

    yohei
    yohei 2009/02/27
  • L'eclat des jours(2008-06-21) すべては初台の地下で始まった

    _ すべては初台の地下で始まった 高橋さんから、台湾のOSCみたいなカンファレンスの話を聞いたのだが、とにもかくにも、日のオープンソフト系カンファレンスのエンターテインメント性は異常、他に匹敵できるのは知っている限りではシアトルの連中だけ、というような内容。シアトルと渋谷のpmだのjsだのが突出しまくりである、と。 で、なぜだろう? と話は続く。 そこで、考えてみるわけだが、おれが最初に参加したことがあるのは(JUSの勉強会みたいなのは別にすると)、YAPRCだったわけで、pmとか言うと、当然、そこに見られた特徴について考えることがベースとなる。確かにPerl Mongersな人たちのプレゼンはおもしろかったような(覚えてないけど)。他にエンターテインメントと言えばライトニングトークは海外の企画の流用だったし、でも、何かもっとオリジナルで圧倒的なエンターテインメント性があるプレゼンがあっ

  • WhatIsTesting

    テストとテスティング XPの出現以来、それ抜きの開発は考えられないほど、テスティングフレームワークは必須のものとなりました。 「テスティングフレームワーク」 しかし、この呼び方になにやらうさんくさいものを感じる人もいるでしょう。 なぜ、「テスト」ではないのか? ここでは、テスティングという言葉の感覚を伝えたいと思います。 なお、アジャイル開発における「言葉」についてはAgileNaKotoBaを参照してください。 テストとはなんでしょうか? 私たちが日常的に利用する「テスト」という言葉は、品質保証テストのように、既に存在する仕様に基づいて実装された完成品が、基準を満たしているかを検査するという意味で使います。 同じように学校の期末テストは、既に学習した内容が学生の身についているかを判定します。 ここにあるのは、静的な基準であり、テストは既に完成した製品や知識に対して動かしがたい事実の判定を

  • L'eclat des jours(2007-10-28)

    _ エッセンシャルクォリティ マイクロソフトの関連には、以前はインサイドものってのもあったけど(で、それを一蹴したのが、Windowsプログラミングの極意なのかも知れないけど)、それとは別にエッセンシャルものってのがある。別名、ドンボックスと愉快な仲間たちシリーズと言っても良いかも。エフェクティブってのもあるから、嘘かも。 というようなことを思い出したのは、エッシェンシャルWFの序文をドンボックスが、また随分アオリ気味(ワイドにフロシキを広げたってこと)に書いているからだ。 何か大きなことが今まさに起きようとしているのです。 まあ、それについては後で。 というわけで、エッセンシャルWFを(アスキーのドットネットのとか共著してる)新丈径さんからいただいたわけだが、難しい位置づけのだなぁ。 エッセンシャルWF : Windows Workflow Foundation (Programm

  • HistoryOfWebApplication

    Webの黎明と商用インターネットの始まり 1989年にスイスのCERNに在籍していたティム・バーナード・リー(彼自身はイギリス人である)は、ネットワークを通じて互いに連携した文書に関するプロジェクトを提案した。このプロジェクトがWorld Wide Web――マークアップ言語のHTML、転送プロトコルのHTTP、名前指定のURI―(以下ではWWWと略す)の始まりである。そして1990年クリスマス、NeXTコンピュータ上にObjective-Cでプログラムされた最初のサーバーhttpdとクライアントWorldWideWebが完成した。この1990年という年はまた、ARPANETの終了の年であり、一方でワールドコムオンラインが一般ユーザーにダイアルアップサービスの提供を開始した年でもある。1989年のインターネット上での商業用電子メールの解禁と共に、まさにインターネット時代の始まりと言えよう。

  • L'eclat des jours(2004-10-24)

    _ プロクシとの通信料金 一度必ずキャッシュを送ってくれるんだが、この通信分も課金対象なのかな? 結局再読み込みする事になるんだが。 _ ステートレスコンポーネント 注)なんとなく書き始めてみたが精査できてないから結構怪しいとこがあるけど、仕上げる気力がないからこのままだったり。 あるコンポーネント(分離度が高く、他のプログラムから呼び出されることを前提としたプログラム)がステートレスであるとはどういう文脈で使われるかによってもちろん異なるのだが、暗黙の了解としては主となる公開メソッドの後続の呼び出しが以前の呼び出しに依存しないということだ。 当然、主とならない、たとえば依存性解消のためのセッタ呼び出しであるとかライフサイクルを通じて一度実行されるinitializeとかコンストラクタとかに、主となるメソッドの呼び出しは依存してもそれは構わない(それは不変条件あるいはクライアント側が実行す

  • L'eclat des jours(2007-06-19)

    _ リソースなのかRPCなのか REST魂ってのはありそうだな。と、 HTTP ステータスコードを正しく使おう と、ぶくまこめんとを眺めて思った。 complexTypeとか出てきてること考えると、SOAPツールキットみたいなものを使って実装したんじゃないかと思える。とすれば、実装の考え方はRPCだろうし、エラーコードはその関数の実行結果であって、関数呼び出しのレイヤーの結果とは別にするのは素直にみえる。しかし、そうではなくてリソースの取得と見ればステータスコードを使えというのはもっともだ。 RPCなら専用クライアントがあるのが(暗黙の)前提となるから、話は合うのだが、その一方で、そんなものなくても利用できるんだから(+多分、そんなものなしで利用してほしいと考えているようにもとれる)、だったらRPCとしての実装じゃなくて、リソース取得としての実装にすれば良いじゃんというのももっともだ。 こ