Matthew Inman
Jason Zimdars / 青木靖 訳 2010年8月31日 「Webデザインを始めたい場合、どうすればいいんでしょう?」とか、「Webアプリを作り始めるには、どんなスキルが必要ですか?」といった質問をする人がたくさんいる。おすすめの本を山ほど挙げたり、「となりのやつより115%上をいく55の技」みたいな記事を何十本かリストアップするのは簡単だが、本当のところを言うと、始めるために何かを学ぶ必要はない。一番重要なことが何かというと、ただ始めることなのだ。 何かを作り始めること。Webデザインを学びたいならWebサイトを作ればいい。起業家になってWebベースの製品を売るビジネスを始めたいなら何かアプリを作ればいい。まだスキルがないかもしれないけど、どうしてそんなこと気にするの? どんなスキルが必要になるかもわからないというのに。 すでに知っていることを使って始める Webで何か作りたいん
ブレイス・アグエラ・ヤルカスが示す拡張現実地図 (TED Talks) TED2010での息をのむようなデモで、ブレイス・アグエラ・ヤルカス(Blaise Aguera y Arcas)がMicrosoftの新しい拡張現実地図テクノロジーを披露します。 ソース: Blaise Aguera y Arcas demos augmented-reality maps 字幕: 青木 靖 関連リンク Bing Maps シアトル Bing Maps パイクプレースマーケット Bing Maps ハイチ地震地図 Seadragon Photosynth Photosynthチームブログ WorldWide Telescope TED2007でのアグエラ・ヤルカスの講演
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新
Jeff Atwood / 青木靖 訳 2007年3月12日 シリコンバレーに行くことがあれば、コンピュータ歴史博物館を覗いてみることを強くお勧めする。現存で唯一動作するPDP-1があって、それを使ってオリジナルのSpacewarゲームができるような場所が、他にあるだろうか? 私は行ってみたが、すごかった。ゾクゾクした。妻は退屈しきっていたが、それでもずっと付き合ってくれたことに感謝している。 この博物館は特設展よりも常設展示の方に本当に面白いものがある。それが建物の大部分を占めていて、かつて耳にしたことのあるあらゆるコンピュータが置かれている。見ることのできる所蔵品の中に、1999年のGoogleの 初期のサーバがある。 Googleの最初の量産サーバ 1999年 Google, Inc. アメリカ 限られた資金で、Googleの創業者ラリー・ペイジとサーゲイ・ブリンはこの安価な相互接続
Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての 「それがないんだったら買わない」機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——「この1個だけ付け加えれば・・・きっとあの連中もおとなしくなってくれる」 しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私
Kathy Sierra / 青木靖 訳 2006年9月27日 Webやテクノロジーの世界では(その他の多くの分野でも)、大きなアイデアというのは若い人から生まれるようだ。弱冠27歳にして、Ruby on Railsフレームワークの作者デビッド・ハイネマイヤ・ハンソンは世界を変え、Rubyに存在 意義を与えた。それにFlickrを作ったカタリナとスチュワートがいる。そして言うまでもなく、私がこの記事を書いているブログサービスの 生みの親、Six Apartのベンとミナがいる。 ラリーとサーゲイ、Googleの裏にいる「男の子」たち。ジェフ・ベゾスがAmazonを設立したのは、ちょうど30歳のときだった。O'Reillyの最初のFoo Campで、バート†をゲームで苦しめていた相手の若い子がBitTorrentの作者であるブラム・コーエンだったことを後で知った(彼はTime誌の最も影響力のあ
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
Paul Graham / 青木靖 訳 2006年10月 最近やった講演の後のQ&Aで、スタートアップを失敗させるのは何かという質問をした人がいた。その場に立ったまま何秒か呆然としていた後、それが一種のひっかけ問題なことに気付いた。これはスタートアップを成功させるのは何かという質問と等価なのだ——失敗の原因となることをすべて避けるようにすれば、成功することができる——そしてこれはその場で答えるにはあまりに大きな問だった。 後になって、私はこの問題をそういう方向から見るのも有効かもしれないと思うようになった。すべきでないことをすべて並べたリストがあれば、それをただ逆にするだけで成功へのレシピに変えることができる。そしてこの形のリストの方が、実践する上で使いやすいかもしれない。やらなければならないことをいつも頭に入れておくよりは、何かやってはいけないことをしているときにそれと気付くというほうが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く