2009年11月30日のブックマーク (5件)

  • Martin Fowler's Bliki in Japanese - ビジネスリーダブルなDSL

    http://martinfowler.com/bliki/BusinessReadableDSL.html 2008/12/15 ビジネスピープルは、DSLを使えば、プログラマがいなくてもソフトウェアのルールを書けるのだろうか? DSLの話になると、ビジネスピープルが自分でコードを書くのかといった話によくなる。 こうした考えには、COBOLのインターフェースの話を持ち出そう。 元々のCOBOLの目的は、プログラマがいなくてもソフトウェアを書けるようにすることだった。が、結果は見ての通りである。 プログラマがいなくてもコードを書けるという話には、COBOL(とその他大勢)が失敗したところを、今回はどうやって克服するのかと尋ねるようにしている。 私は、プログラミングには特殊なマインドセットが必要だと考えている。 それは、マシンに正確な指示を与えること、そして、そうした膨大な指示を構造化して、

    int128
    int128 2009/11/30
    日本のビジネスモデル向けに書き直したい。
  • Twitter API Wiki / Twitter API Documentation

    Twitter exposes its data via an Application Programming Interface (API). This document is the official reference for that functionality. Getting Started The concepts every developer should know before interacting with the API. Methods The API supports the following methods to send and receive Twitter data. Search API Methods search trends trends/current trends/daily trends/weekly REST API Methods 

    int128
    int128 2009/11/30
  • 会社の辞め方 その1

    さて、NZへ引越しを決断したので、まずはカナダの会社を辞めなければならない。 ここで私が入社したときの契約に問題があった。 契約書には、3年以内に自己都合でやめた場合、日からの移住にかかった費用(引越し、渡航費、ビザ関係費用)を返さなければならないという項目があることである。 こちらとしては永住権取れるまで辞めるつもりもなかったし、2年で会社がここまでだめになるとも思っていなかっため、軽くサインしていたのだ。 会社の業績が悪化して、日向けのサポートチームをどんどんクビ切りしてしまったため、サポート、ドキュメント翻訳、プリセールスなどでほとんど忙殺される毎日であった。 デベロッパとして採用されたのに、これではあんまりだというのが、こちらの不満である。これは、サポート業務やドキュメント業務を軽視しているわけではなく、自分のスキルを活かせない仕事に不満があった。 そんな状況のため、辞めたから

    会社の辞め方 その1
    int128
    int128 2009/11/30
  • NTTグループの「クラウド」は成功するか

    「クラウド・コンピューティング」という用語を,記事やプレスリリースなどで目にしない日はほとんどない。調査会社の米ガートナーによると,8月時点でクラウドは“『過度な期待』のピーク期”にあり“幻滅期”に向かい始めているとのことだが,国内外を問わず数多くのICT企業が,今日現在もこの言葉をキーワードにビジネスを展開している。 クラウドそのものは扱う範囲が広く,この言葉を使う立場によって大きく変わる。その動向については,既に多くの記事が公開されているため,筆者が重ねて述べる必要はないだろう。 筆者が注目しているのは,国内企業の中でクラウドに積極的な姿勢を見せるNTTの動きだ。海外では米グーグルや米アマゾン・ドットコムなど新興のインターネット企業や米マイクロソフト,米IBMといったコンピュータ・ベンダーが主役の分野に,日の通信事業者がなぜ取り組んでいるかを考える。 当初は「SaaS over NG

    NTTグループの「クラウド」は成功するか
    int128
    int128 2009/11/30
    はいはいクラウドクラウド
  • UIは正規化しない方がいいと思う - 六の日記はこっちになったぞ

    曰く、「データ構造をこれこれこうすれば共通化できるでしょ。そうすると、この画面とこの画面とこの画面と・・・は同じデータを見る事になるんだから、分ける意味が判らない、意味がないでしょ。だから画面をひとつにしろって話でblur blur blur」 いやー、それ分けた方がいいと思います。 「えー?じゃあ、この画面とこの画面とこの画面・・・・と、何が違う?」 アクターが違う、ユースケースが違う、サブシステムからして違う、他色々考えるとあれもこれも違ってくると思う。というか、唯一違わないのがデータ構造、ただそれだけ。 そりゃ「出来る限りは」正規化というか共通化した方がいいと思うけど、データが正規化出来るという事実「だけ」を根拠にUIの正規化を正当化するのはおかしい。 稼働し始めると、ユーザーさんからどうせ「フォーカス順はこうした方が」「入力欄の並び順が」「この場合これが必須なので」とか、アクターや

    UIは正規化しない方がいいと思う - 六の日記はこっちになったぞ
    int128
    int128 2009/11/30
    共通化は頭で考えると失敗するよ。机上のクーロン。