タグ

ブックマーク / www.aoky.net (20)

  • ブロガーの壁(その2) - 途方にくれた人のためのアニメ

    Steve Yegge / 青木靖 訳 2006年9月17日 日曜 私のブログ器官の詰まりを解消することを目的としたN個のパートからなる短い投稿シリーズの第2回。さあ、鼻をつまんで! なんと言ってもこれは、見ての通り、ナンバー2*だからね。 * "make number two"は幼児語で「うんちする」の意。 ちょうど1年ほど前になるが、私は、自分でも驚いたことに、アニメ("Anime")、つまり日のアニメーションが好きなことを発見した。 宮崎駿の「千と千尋の神隠し」を見たのが始まりだった。(これは今ではみんな見てると思うけど。見てるよね?) アニメって、あのアメリカ下層民が見るやつ? アカデミー賞に長編アニメ賞ができたことで、アニメは今では多かれ少なかれメインストリームになった。も私も代わり映えがしないハリウッドのクズ映画には辟易していたし、年に2か3しか現れない当にいい映画

    Wacky
    Wacky 2021/04/27
  • Steve Yegge

    Steveyの退屈な近況報告 Rhino on Rails 全部取り消すから金をくれ! Egomania Itself いいアジャイルと悪いアジャイル ブロガーの壁(その2) - 途方にくれた人のためのアニメ ブロガーの壁(その1) - ジョエル・ウィンフリー バベル案内 Steve Yegge (スティーブ・イエギ) アセンブラからキャリアをはじめ、Amazonを経て、現在はGoogleで働く開発者。JavaPythonで書かれた50万行のMMORPG Wyvernの作者。ソフトウェア開発を扱 ったブログStevey's Blog Rantsを書いている。Amazon時代に書いていたブログのアーカイブがStevey's Drunken Blog Rants(TM)にある。"Anime"ファンで日語を学んでいたこともある親日家である。

    Wacky
    Wacky 2021/04/27
  • Fine Software Writings

    最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か? (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか? (Nick Bostrom) 厄介な問題を解決したい? ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W

  • ((Pythonで) 書く ((さらに良い) Lisp) インタプリタ)

    ((Pythonで) 書く ((さらに良い) Lisp) インタプリタ) Peter Norvig / 青木靖 訳 前のエッセイでは、90行のPythonコードでシンプルなLispインタプリタを書く方法を示した(lis.py)。このエッセイでは、3倍込み入っているが、より完全なlispy.pyを実装しよう。それぞれの節で1つの機能追加を扱っている。 (1) 新しいデータ型 - 文字列、論理型、複素数、ポート Lispyへの新しいデータ型の追加は3つの部分からなる。データの内部表現、それを扱う手続き、読み書きのためのシンタックスだ。ここでは4つの型を追加する(入力ポート以外はPythonのネイティブ表現をそのまま使う)。 文字列 文字列リテラルはダブルクォーテーションで囲まれる。文字列の中で \n は改行を、\" はダブルクォーテーションを意味する。論理型  構文 #t と #f はTrue

  • ((Pythonで) 書く (Lisp) インタプリタ)

    Peter Norvig / 青木靖 訳 このページには2つの目的がある。コンピュータ言語の実装について一般的な記述をすることと、Lispの方言であるSchemeのサブセットをPythonで実装する具体的な方法を示すことである。私はこのインタプリタをLispy (lis.py)と呼ぶ。何年か前に私はJavaとCommon LispでSchemeインタプリタを書く方法を示した。今回の目標は、アラン・ケイが「ソフトウェアのマクスウェル方程式」と呼んだところの簡潔さと取っつきやすさを可能な限り実現するということだ。 SchemeのサブセットLispy の構文と意味論 コンピュータ言語の多くは様々な構文的な決まり(キーワード、中置演算子、カッコ、演算子優先順、ドット記法、セミコロンなど)を持っているが、Lisp族言語の1つとして、Schemeの構文はすべてカッコ付きの前置記法であるリストを基とし

  • Steveyの退屈な近況報告

    Steve Yegge / 青木靖 訳 2007年12月6日 木曜 今日はクビをまぬかれるというエキサイティングな朝を過ごした。どういうことかというと、私はマウンテンビューにあるGoogle部に出張で来ていて、ミーティングの合間にRedditを眺めていたのだが、 そうしたらなんと、私がどういうわけかまた大衆紙Redditで取り上げられていた。今回はどうもクビになったらしいとかで、みんな勝手な憶測をしていた。言うまでもないだろうが、私は仕事上の計画はすべて棚に上げて、ほんとに自分はクビになったのか確かめようとした。優先順位が間違っているとか非難しないでほしい! そうして自動化されたシステムのちょっとした間違いだったことがわかった。そのシステムは自ら進化してブラウン運動から副社長レベルの意思決定者へと移行したらしい(トータルで2ステップの進化だ!)。あるいはこの自動システムは「未来世紀ブラ

    Wacky
    Wacky 2007/12/16
  • 頭の中にプログラムを入れる

    Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題

    Wacky
    Wacky 2007/08/27
  • 理解することが書き直すことを意味するとき

    Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新

    Wacky
    Wacky 2007/08/01
  • あらゆることがうまく行かなければどれくらいかかるか?

    はじめの一点での見積りと、最良値/最悪値の見積りを比較してみるなら、11.25という一点での見積り値の合計が、最悪値の合計18.25よりも最良値の合計10.5にずっと近いことがわかるだろう。 最良値と最悪値が両方とも一点での見積り値より高くなっているところがあるのも目に付く。最悪のケースについて考えることで、最良の場合でもやらなければならない作業がもっとあったことに気付いて、見積りを引き上げているのだ。最悪のケースをよく検討したいとき、私は開発者にあらゆることがうまく行かなければどれくらいかかるかと聞いている。人がする最悪の見積りというのは、真の最悪のケースよりは楽観的な最悪のケースとなっていることが多いのだ。 これは目を見開かせられるエクササイズだ。恥ずかしながら、私は仕事で見積りするときにいつも一点での見積りをしていた。これはプロジェクトスケジュールの惨事の多くにおいて出発点となってい

    Wacky
    Wacky 2007/07/07
    最悪のケースを検討したいとき、私は開発者にあらゆることがうまく行かなければどれくらいかかるかと聞く。人がする最悪の見積りというのは、真の最悪のケースよりは楽観的な最悪のケースとなっていることが多い
  • コンサルタントの秘密 - 圧力に屈するか、それとも交渉するか

    Gerald Weinberg / 青木靖 訳 2006年5月4日 木曜 私の最近のコンサルティング・クリニックで、1日ちょっと使って交渉というテーマに取り組んだ。仕事の内容、価格、条件、日程、そのほか、コンサルタントとクライアントの 間で行われるあらゆる交渉を扱った。宿題として、みんな何かについて交渉してくることになった。私はただの事にありついた。ある人はジャケットを50ドル値切った。ある参加者は クライアントに電話をかけて受け取っていた報酬を2倍にした。 少なくともアメリカ人には、交渉(negotiation)というのは汚い言葉、一種のタブーと見られている。宿題はこのタブーを乗り越えるために出したものだ。私たちは交渉についていろんなことを学んだが、中でも一番重要なのは、私たちが自分の回りに張り巡らしている心理的な障壁 のことだ。そのような障壁について知るために、2つのシナリオを見てみ

    Wacky
    Wacky 2007/07/07
    交渉相手の様々な形態の意識的・無意識的な操作に対処するスキルと意志を欠いていることが原因だ。
  • 「イノベーションの神話」の著者Scott Berkunが10の疑問に答える

    Guy Kawasaki / 青木靖 訳 2007年6月28日 Scott Berkunは1994年から1999年までMicrosoftのInternet Explorerチームで働いていた。最近出版された"The Myths of Innovation"(イノベーションの神話)の著者である。また2005年に はベストセラーとなった「アート・オブ・プロジェクトマネジメント」を書い ている。ワシントン大学の大学院でクリエイティブシンキングについて教えており、ニューヨークのGELカンファレンスで「聖なる場所」と題する建築ツアーを行い、イノベーションとデザインとマネジメントをテーマ に執筆を行っている。 彼の新しいではイノベーションがどのように起きるかについてのロマンチックな見方を探って(というよりは吹き飛ばして)いる。このQ&Aセッションでは、彼がイノベーションの当の姿について説明している

    Wacky
    Wacky 2007/07/07
    進歩が間違った方向に進んだ という話の多くは、認識の傲慢さのためだ
  • Steve Yegge、RailsをJavaScriptに移植する

    John Lam / 青木靖 訳 2007年6月24日 Foo Campで私が最初に行ったのは、「GoogleRailsクローン」と題するSteve Yeggeの講演だった。このタイトルを見てどうして聞かずにいられようか? Googleはプログラミング言語として、C++JavaPythonJavaScriptの4つを使っている。WebのフロントエンドJavaで書きたがる人がそういるとは思えないが、それはWebフロントエンド用のJavaコードをたくさん持っているGoogleにしても 同じだ。 Googleにおける開発者の生産性を引き上げるため、Steveは会社にRails(したがってRuby)を言語として採用するように訴えたが、それが叶わないとなると(Googleはインフラでサポートしなければならない言語の数を増やすのをとても嫌っている)、 彼は欲求不満のプログラマがみんなするだろ

  • スペル修正プログラムはどう書くか

    Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Google

    Wacky
    Wacky 2007/06/15
  • プログラミングの6大10項目リスト

    Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの「エゴレスプログラミングの十戒」 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに「空手」を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯

    Wacky
    Wacky 2007/05/03
    自分が誤りを犯すということを理解し、受け入れること 。
  • Googleのようにコンピュータを組み立てる

    Jeff Atwood / 青木靖 訳 2007年3月12日 シリコンバレーに行くことがあれば、コンピュータ歴史博物館を覗いてみることを強くお勧めする。現存で唯一動作するPDP-1があって、それを使ってオリジナルのSpacewarゲームができるような場所が、他にあるだろうか? 私は行ってみたが、すごかった。ゾクゾクした。は退屈しきっていたが、それでもずっと付き合ってくれたことに感謝している。 この博物館は特設展よりも常設展示の方に当に面白いものがある。それが建物の大部分を占めていて、かつて耳にしたことのあるあらゆるコンピュータが置かれている。見ることのできる所蔵品の中に、1999年のGoogleの 初期のサーバがある。 Googleの最初の量産サーバ 1999年 Google, Inc. アメリカ 限られた資金で、Googleの創業者ラリー・ペイジとサーゲイ・ブリンはこの安価な相互接続

    Wacky
    Wacky 2007/05/01
  • ソフトウェア開発者のための推薦図書

    Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための「楽しい料理だ。このを読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。このを読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこのがすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。このではやるべきでない悪い例には"coding horror"アイコンで印

  • 顧客の機能要求に折れないこと!

    Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての 「それがないんだったら買わない」機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——「この1個だけ付け加えれば・・・きっとあの連中もおとなしくなってくれる」 しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私

    顧客の機能要求に折れないこと!
    Wacky
    Wacky 2007/03/13
    あらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私たちは月並みになる。
  • 失敗した結婚みたいな企業が多すぎる

    Kathy Sierra / 青木靖 訳 2007年2月24日 いい結婚生活のための秘訣が何かというと・・・変わらないということだ。言い換えると、デートしていた頃と同じ人間でいつづけるということだ。関心を払うのをやめないこと。優しくするのをやめないこと。50ポンド太ったりしないこと。いちゃいちゃするのをやめないこと。情熱的でありつづけること。セクシーでいつづけること。気配りするのをやめないこと。電話に応えること。残念なことに、 企業というのは多くの場合、ろうそくを灯したディナーで上等のワインを開け、そして「君のことを話そう」と言ってくれるのは、取引が済むまでのことで、ひとたび彼らがあなたを手に入れたなら(つまり、あなたが顧客となったなら)、あなたはその関係がひっかけだったことに気付く。 これは大きな間違いだ。こんなのは個人的な関係だったら理解できないことだし、企業と顧客の関係であっても理解

    Wacky
    Wacky 2007/02/27
  • デモではものができあがっているように見せない

    Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも

    Wacky
    Wacky 2007/01/07
    どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。
  • いいアジャイルと悪いアジャイル

    スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

    Wacky
    Wacky 2006/10/17
  • 1