ニコニコ動画開発記
この記事は，日経ソフトウエア2008年3月号から掲載した「ニコニコ動画開発記」の再録です。記事は執筆時の情報に基づいており，現在では異なる場合があります。 2007年12月12日，筆者がその開発と運用に携わったサイト「ニコニコ動画」が，サービス・インからめでたく1周年を迎えました。サービスを始めた1年前から400万人を超えるユーザーを集めるサイトに成長した今日まで，筆者は波乱の連続といえる経験をしてきました。 連載「ニコニコ動画開発記」では，ニコニコ動画開発者の一人である筆者が，本サイトと筆者の軌跡を振り返ります。ニコニコ動画のユーザーの皆さんもそうでない方も，あるエンジニアの奮闘記としてお楽しみいただければ幸いです。 ニコニコ動画開発記（上） いつもだれかがそこにいる ニコニコ動画開発記（中） 激闘！フェニックス・プロジェクト ニコニコ動画開発記（下） すごい勢いで進化
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
我々は公共性の進化に見あった速度で進化しているか - アンカテ
Attacking PHP - Matzにっき(2008-01-26) まつもとさんのこのエントリから凄い騒ぎになっているようだけど、ここで一番重要なことは、PHPやRubyがどうのこうのでなくて Webアプリケーションをなめるな こっちの方だと思う。 「初心者にやさしい言語(技術、方法論)の開発」→「本質的な問題の隠蔽と関係者の人口増加の同時進行」→「問題の拡散」というパターンはこれまで何度も繰り返されてきたことだ。 たとえば、VisualBasicやAccessやExcelのユーザが増えはじめた時は、「DBをなめるな」と私は思った。データベースというものは、しっかり業務分析をした上で、論理設計と物理設計をきちんとしないと、最後には破綻する。イージーなツールにも使い道はあるけど、明かに想定を超えた使い方で業務ソフトを作ってしまい、つぎはぎだらけになって収拾がつかなくなる例を何度も見てきた
Cometに代表されるサーバ・プッシュ技術の復権
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします。（編集部） サーバ・プッシュの歴史 Webアプリケーションが広まるにつれて、レスポンスやリアルタイム性を重視することが多くなってきました。Webアプリケーションの形式によっては、ユーザーが主体的に操作してデータを取得するよりも、サーバ側が必要と思われるデータを送り付けることが主体の場合もあります。 例えば、Webブラウザを利用したチャットであれば、通常ページが更新されるのはリロードされたタイミングですが、サーバ・プッシュ型の実装がなされている場合は、新しいメッセージが追加された瞬間に、参加ユーザー全員に伝搬されなければいけません。 Webブラウザを活用したサーバ・プッシュの手法は、古くはNets
Mylyn＆Tracでリズムに乗ってタスクを大掃除♪
最小限の管理コストで最大の「見える化」を 近年「開発の見える化」が話題となっていますが、いざやろうとするとなかなか難しいものです。 模造紙を壁に張り付ける「タスク看板」などを利用してタスクの「見える化」を行っても、肝心のタスクの実行状況が見えなかったり……。そんなことはないでしょうか？ 本当にチームメンバーのタスクを把握できているでしょうか？ そもそも「タスク」とは、コーディングやテストといった純然たる作業や、故障処理、管理、仕様変更などの副次的な作業も含みます。開発を見える化する際に基本となる1つの単位です。 今回紹介するMylynとTracを利用すると、タスク取得→コミット、タスク取得→コミット、……というリズムに乗った開発で、作業履歴（ログ）を残しながら各開発担当者の作業内容を明確にできます。最小限の管理コストで最大の見える化を。世にも不思議なMylynマジック、とくとご覧ください。
【XDev】「とりあえず作って，後から作り直せ」，Rubyのまつもと氏が語るエンタープライズ開発：ITpro
写真●「X-over Development Conference 2007」で講演する，まつもとゆきひろ氏 「結局のところ，顧客に何が必要かは，顧客にも開発者にも理解は不可能だ。そうならば，まずアプリケーションを作って，それを使ってもらい，顧客に合うように直すしかない。これからのエンタープライズ開発も，とにかく速く安く作って，直すことが重要になる」－－。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日，ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは，「YouTube」に代表されるように，「仕組みそのものよりも，データがどれだけ集まっているかが生死を分けている」（ま
デスクトップアプリケーションは死んだ - Kentaro Kuribayashi's blog
"Ev's Rants: Desktop Applications are Dead"が面白かったので、翻訳してみた。というか、「超訳」だが。 原著者: Eugueny Kontsevoy 超訳者: kentaro a.k.a. id:antipop 原文のURL: http://kontsevoy.blogspot.com/2007/08/desktop-applications-are-dead.html いまさらその話かよ、って？そんなこといっても、「デスクトップアプリケーションは死んだ！」とか、いまもみんなそこらを叫んで回ってんじゃん。 その連中の多くは、いわゆる「ウェブアプリケーション」の開発者どもだ。誰があんな連中のいうことを聞くんだ？やつらは本物の開発者なんかじゃない。だよね？全然ものがわかってないし。あいつらときたら、malloc()やfree()すらまともに使えないんだか
twitterブームの陰で注目を集める“Erlang” － ＠IT
2007/04/27 “twitter”がブームだ。140バイト以内の短いメッセージで“現在進行形”の自分のステータスをほかのユーザーとシェアするだけのオンラインサービスだが、本国の米国はもとより、日本でも非常な人気を集めている。Alexaでアクセス数の推移を調べると、今年に入ってから本格的にブレークしている様子が分かる。4月22日にはニューヨークタイムズもtwitterと、サンフランシスコ在住の創業者2人を記事で取り上げている。 twitterのコミュニケーションツールとしての新しさ twitterに参加してみると、チャットやメール、SNSといった、既存のコミュニケーションツールのいずれとも異なる、不思議なつながり方が新鮮で楽しい。熱心にメッセージを更新するユーザーを見ていると、CUSeeMe、ICQ、mixiなどが登場したときに人々が示した熱狂に近いものを感じる。 twitterでは、
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その2）
ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう