タグ

bizとdevに関するwebmarksjpのブックマーク (7)

  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • Google のソフトウェア開発 Days on the Moon

    Google 技術講演会「Developing Software in the Real World」に行ってきました。講演者は Google 東京 R&D センター ソフトウェアエンジニアの南野朋之さん。その 1 週間前に行われた、Mozilla Corporation の Seth Bindernagel と Seth Spitzer との講演会 (Mozilla Party JP 8.0 とは別物) には参加できなかったので、リベンジ (?) という形になります。 南野さんはインターンを経て Google へ入社、Google マップでの写真表示を開発された方で、今回の公演内容は Google でのソフトウェア開発体制、および Photos on Google Maps 開発の舞台裏に関してでした。 Google でのソフトウェア開発体制 OKR (Objectives and Ke

  • 「バグの無いシステムは無い」が「開発者は成功してほしい」

    稿は取材に基づいて客観的事実を伝える報道記事ではなく,谷島個人の考えを書くコラムです。 妙な書き出しになったが,その理由は後で述べる。ITpro Watcher欄の寄稿者,小飼弾氏が書いた『(6000)人が作ったシステムは必ずどこか壊れている』という文章が5月14日付で公開された。冒頭に「ここで語っておきたいのは,ITproの報道姿勢だ」とあったのでITpro関係者として読んでみると,中身は筆者および拙稿に対する批判と苦言であった。ITproではない場所に書いた記事にも言及されているので,ITproというより筆者の「報道姿勢」が問われていることになる。 インターネットの面白い所は双方向のやり取りが簡単にできることだと思う。ご意見を寄せてくれた小飼氏にまずお礼を申し上げる。ご指名を受けた以上,すぐにお答えしないといけないと思ったものの,なかなか書けず,今日までかかってしまった。言い訳になる

    「バグの無いシステムは無い」が「開発者は成功してほしい」
  • はてなシリコンバレー撤退の話題から考える、失敗への寛容さ - モチベーションは楽しさ創造から

    はてながシリコンバレーから撤退して、京都に戻っていく事がブログ界隈で話題でした。 一連のエントリを読んでいると、「日って相変わらず、失敗に対して寛容ではないなぁ」と感じるものがとても目に付きました。ある意味、「企業を取り巻く周囲の、失敗に対する寛容さがシリコンバレーと日の一番の違いではないだろうか?」と感じてしまいます。 別にはてなは、倒産したワケではないし、まして資金繰りに困っているわけでもない。ただ、アメリカの事業のもくろみが上手くいかなかっただけの話。 当然、そこで学んできたモノも多いと思います。 ・日でやった方が「優位性」がもてるもの ・日のリソースを使った方が優位なもの ・次のシリコンバレー進出の為に、準備すべきもの 失敗でしか学べないモノも実際にはたくさんあります。想定外の事もたくさん起こるし、理屈では考えられない出来事に出くわすのが現実です。 書物には書いていない、気

    はてなシリコンバレー撤退の話題から考える、失敗への寛容さ - モチベーションは楽しさ創造から
  • 仙石浩明の日記: 技術者の成長に役立つ会社とは?(2)

    技術者の成長に役立つ会社とは?(1) をとても多くの方々に読んで頂けました。 頂いたコメントや、 はてなブックマークに頂いたコメントを見ると、 賛同/批判 両方の立場から様々なご意見がありますね。 拙文が多くの方々の考えるきっかけになったのだとすれば、 書いた甲斐があるというものです。 特に学生さんにとっては、これから自身の人生を切り拓いていくのですから、 いま自分の将来について考えることは、 必ず後の人生にとってプラスになることでしょう。 以下に述べるのは、私が考える「技術者の成長に役立つ会社」の条件です。 他の人は異なった考えを持つかもしれませんし、 私自身も常に考え続けているので、 「役立つ会社」の条件が変ってくることがあるかも知れません。 しかし、 「技術者の成長にとって一番役に立つ会社を目指したい」というその思い自体は、 私が技術の責任者であり続ける限り、変らず持ち続けたいと思っ

  • バッドノウハウからグッドラッパーへ

    「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。 目次 はじめに 有益なものを生み出さなければ「奥が深い」とも呼ばれない バッドノウハウをグッドラッパーで隠そう 当によくないシステムとは よびかけ 補足:Perlとバッドノウハウ いろんな方からのコメント 反応リンク 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに 高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。 有益なものを生み出さなければ「奥が深い」とも呼ばれない もしも「奥が深い」システムが何

  • ユメのチカラ: 500万倍のスケーラビリティ

    カーネル読書会で、mixiのバタラさんにmixiのシステムをどのようにスケールアップしたかの話を聞く。開催以来最多の90名の登録(会場の都合で90名で登録を終了した)で、会場は立ち見が出るほどの盛況であった。宴会も50数名の参加をえてこれも大盛況であった。(大よっぱらいの人もいたけど(笑)) 内容はYAPCでの発表をアレンジしたものである。ようさんの日記に詳しい報告がある。 システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは当にとてつもないことで

  • 1