タグ

2012年2月20日のブックマーク (5件)

  • Macintoshの最期

    寂しい、けれど...。 Mac OS Xは、先週発表されたMountain Lionで「OS X」になりました。そう、「Mac」がなくなったんです。これは明確な意図があってのネーミングだと思われます。つまり、20年以上も続いてきたMacintoshというデスクトップメタファーの終わりが近いことが示されているのではないでしょうか。 これは、MacBookやiMacがなくなる、ということではありません。でもそうしたコンピューターを定義してきた、ソフトウェアの魂の部分が入れ替わっていくということです。おそらくあと2年もすれば、MacintoshはiOSという新しい花に命を譲った老木のような存在になっていることでしょう。 そんな見方を否定したい人もいるかもしれませんが、これが今実際に起こっている現実です。アップルがアプリ中心のユーザー体験モデルを構築しつつある一方では、マイクロソフトも情報中心のM

    Macintoshの最期
  • ノマド(遊牧民)の起源 なぜ強い者が遊牧民になるのか? : Market Hack

    1960年代にアメリカの援助でアフガニスタンのヘルマンド地方の灌漑プロジェクトが実施されました。砂漠を耕地に変えようとするこの計画は遊牧民が農地に定着せず失敗し、今では世界のアヘンの原料であるケシの花の75%を供給する土地になってしまっています。 このナイーブなアメリカの経済援助が失敗した背景には「砂漠では強い者が遊牧民(ノマド)になる」という掟(おきて)ないし価値観をアメリカ人が全く理解していなかったからだと言われています。 なぜ強い者が遊牧民になるのか? この歴史を知る事は最近流行っている「ノマド的なワークスタイル」を考える上でも示唆に富んでると思います。 日の中東研究の草分け的存在である岩村忍(いわむらしのぶ)は『世界の歴史 西域とイスラム』(中公文庫)の中で遊牧民の起源を次のように説明しています。 オアシスに人間が住みついて農耕を生業としているうちに(中略)家畜の飼養が始まった。

    ノマド(遊牧民)の起源 なぜ強い者が遊牧民になるのか? : Market Hack
  • Chromeが起動時に三つのランダムなドメインに接続しようとする理由

    Chrome connects to three random domains at startup.” — Mike West Chromeを起動した際、http://aghepodlln/とかhttp://lkhjasdnpr/のようなランダムなドメインへの接続を試みる。何でこんなコトをしているのかという見当はずれの推測が、いくつか出回っている。事実としては、この挙動は必要なのだ。以下の説明で、この疑問を晴らす。 このような接続要求の目的は、現在使用しているネットワークが、存在しないホスト名への接続要求を検知して勝手にリダイレクトするかどうかを判定するものである。例えば、少なからぬISPが、http://text/のようなDNSルックアップの失敗に対し、http://your.helpful.isp/search?q=text(あなたの親切なISP)へリダイレクトしている。この「親切

  • JavaScriptをやり始めた人が理解したほうが良いJSONパーサのコード - sifue's blog

    そろそろ4月も近いということもあって、新たにWeb業界やSIer業界に入るぞという方がプログラミングの勉強をし始めているころでしょうか。最近は、エンタープライズでもWebクライアントが主流になりつつあるのでJavaScriptの習得は避けては通れない道だと思います。また、Node.js等サーバーサイドのJavaScriptも出てきたこともあって、非常に有用な言語になりつつあります。 そんなJavaScriptを学び始めている人の中でも、ある程度プログラミングをやったことがある人がJavaScriptの綺麗な書き方を学ぶのに絶対理解しておいた方が良い300行程度のソースコードがあります。 それは、JavaScript: The Good Partsに載っているJSONパーサのコードです。 JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス 作者:

    JavaScriptをやり始めた人が理解したほうが良いJSONパーサのコード - sifue's blog
  • いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

    最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 (なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

    いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道