読者です 読者をやめる 読者になる 読者になる

ITPro Challenge! 2008 見てきた

カンファレンス

去年も面白かったけど、今年も面白かったな。
印象に残ってるのは、

  • 川崎氏の「意図的にシステムの弱い部分を作っておいて、そこがダメになりそうだったらスケールアップする」という話
    • あぁ、そういうやり方もあるんだなぁと思った。確かに全部潰れることは回避できるかもと。
  • 奥地氏の「できないから、やらない」ではない「やらないから、できない」
    • まさに自分のことを言われてる感じだった
  • 宮川氏の「What are you coding?」
    • Twitterで言葉を発言するのもCodeReposでコードをコミットするのも自分のエゴを時系列で並べてるという点で変わらないってのは目から鱗だった
    • あと「スピリチュアル系」笑った
  • 金子氏の「プログラミングしただけで犯罪」
    • 話の内容自体も面白かったけど、このことについて懸念してるのが良くわかった。やっぱり研究者なんだなぁと
  • ライトニングトークではひげぽん氏の「パフォーマンスを工数に入れる」
    • これはよく実感することなので「グラフにする」ってことも含めて実際にやりたいなと思う

という感じかな。


あとは、弾さんと吉岡さんの微妙にかみ合ってない感が面白かったです。
来年もやるといいな。モチベーション上がっていい。
セミナー聞く→モチベーション上がる→プログラミング→もっと書けるようになりたいなぁでちょっと落ち込む→セミナー聞く
のループだ。

以下はメモ。
あとで動画配信されたらまた見よう

モバゲータウンをこうして作った - 川崎修平氏(ディ・エヌ・エー)

  • モバゲーの話というより生い立ち
  • パソコン少年だった
  • 大学時代にunixとwebの世界を知り、パソコンに再度ハマる
    • フリープログラマとして
      • ここで開発スピードと危機回避能力がついた
    • オークション統計ページ(仮)を作成(現aucfan.com)
      • 自分で作ったサービスで喜んでもらえるのは嬉しい
      • 企業サイトと違って
    • 奥さんの家に光を勝手に引いたり、ペンギンの筐体のPCを置いたり
      • 「ペンギンかわいいから置いていいよね」的な感じで8台くらいに増えた
  • その後
    • ビッダーズ社員からメールで呼び出されそのままバイト
      • 最初は分析とパフォーマンス
    • 10個中1個当たればいいかという感じで3つくらい作った
    • モバオク、モバゲー
モバオク
  • 今の取締役「守安氏」に携帯用オークション作ってと言われた
    • ゼロから作っていいよと言われたのでやる気up
  • 開発に当たって
    • 自分の好きなことをどんどん取り入れたかった
    • サービスが成功してもヤフオクに流れないように
  • 開発内容
    • 絵文字の使い方が困難だった
    • フレームワークから作成した
    • SHM(shared momery)を使った高速リスティングの実装
  • 困ったこと
    • サービス開始当初は全然客が来なかった
      • あてがあったのだけど、そっちからの送客もなかった
    • 流行り始めたらサーバ増設が追いつかなかった
    • 携帯特有のトラフィックでネットワーク危機が限界
      • CDNで対応
  • 驚いたこと
  • ケータイユーザはものすごくページを見る
  • ユーザと運営者の距離が近く、反応もすごく早い
    • 問い合わせをtailしておいて、本番反映したらそこに不具合情報があがってくるとか
  • 新規サービス開発の進め方
    • 基本的に自宅開発で深夜作業
      • 作業中は基本的に連絡もとらない
    • 自宅サーバ上で開発中のサービスを公開しているので、他のメンバーはそこを見る
    • ドキュメントなし、引き継ぎはソース見ろ
  • 開発スタイル
    • やる気が出るまで横になって漫画
      • 北斗の拳とか男らしいの読んでモチベーション上げたり、げんしけん読んでまったりしたり、どうしてもダメな時は三国志読んだり
      • 休みまくると「そろそろ仕事でもやってもいいだろう」ってなる
    • 食事もとらない「午後の紅茶ミルクティー」
  • 運用の工夫
    • 意図的に弱い部分を作っておく
      • Apache1台に負荷をかけておいて、そいつがダメになったらサーバ増やすかという感じ
ポケロト
  • あんまり記憶にない
ポケットアフィリエイト
  • 2週間くらいで開発
  • 基本方針は自分が使いたいやつ
  • 開発内容
    • 安定
      • 1年ぐらいは手を入れてない
    • サーバはバックアップを入れて2台
    • モバゲーの足がかりになった
モバゲータウン
  • 開発期間3ヶ月
  • あんまりコミュニティーサービスを自分で使ってなかったから自分で使いたくなるコミュニティーサービスにしようとした
  • 開発内容
  • 困ったこと
    • SNSを使わないので勘所がわからなかった
  • サーバ不足、ラック不足
  • 多人数開発前提じゃない作りなので、今結構大変
サービス作りの心がけ
  • 自分が作りたいものを作る
    • ユーザが使いたいサービスと一致するように訓練
    • 初めに想定しておいて、実際そう使われたかどうかをフィードバックで確認
  • こんなサービスが目の前に現れたらワクワクするという高揚感
  • これができたら自分はすごいという問題設定
技術について
  • ハッカーじゃない(なりたいけど)
  • 自分のものづくりのために技術を習得
  • 何かを思いついたらすぐに設計が頭に浮かんで実装できるようにしておく
  • 枯れた技術で作れる部分は、枯れた技術で作る
  • モジュール、ライブラリはできるだけ自分で書く
    • すぐに対応できるように全体を把握しておきたい
ひとり開発だと
  • 楽な点
    • イメージ通りのものが作れる
    • イマイチかもしれない機能も自分で作れるから試せる
  • 辛い点
    • ひとりよがりになる危険
    • だんだん飽きてきて寂しくなる
こんな環境で作れるのが理想
  • 作家と編集者のような関係
    • 作る側:実績、信頼、愛情、責任感
    • 任せる側:任せられるどうかを判断できる能力、適切なインプットと判断力
  • 自分は集客力のあるサービスを作ることに専念して、苦手な所は専門家に任せられる
    • サポートや営業など
質問など
  • セキュリティは?
    • ケータイに閉じてるのでそこは結構楽
    • 入り口はキャリアのGWから来るので
    • XSSなどはフレームワーク側で対応してくれる
  • iPhone対応は?
    • 今「ここから先はケータイで」ってなるのが面白いのでとりあえずそのままでいいかなと
    • LAN経由とかでも来るのでメアド認証になるから一段セキュリティのレベルが下がる
      • これ以上は今はあんまり言えない
  • モバオク、モバゲーの文化作りが大変と言ったけどどうだったの?
    • モバオクはPCを混ぜないということで文化を作った
    • モバゲーは、モバオクの気持ちのいいコミュニケーションを取ってくれるユーザに「新しいサービスできたよ」と案内して、気持ちいいコミュニケーションの土台を作った
  • どうして成功したと思いますか?
    • ケータイはランキングとか口コミが基本
      • 友達紹介時にポイント付けたりとか
    • モバオクは商品の質が良かったので、ある程度見てくれれば広まると思ってた
    • モバゲーはよくわからない
  • 他の技術社員は?
    • 自分の作った物をメンテナンスしてくれる
    • 新しいサービスも作ってる

オープンソースで育つエンジニアリング・スキル - 奥地秀則氏(nexedi)

  • 一端のエンジニアになるには新しいことに挑戦しよう
  • 注意事項
    • 発表内容はあくまで一つの考え方
      • 色んな人が居るから優越はつけられない
  • 表のプロフィール
  • 裏のプロフィール
  • 1993年高校三年のときに初めてコンピュータに触れる
  • 京大マイコンクラブ(KMC)で遊ぶ
  • 1998年GNUプロジェクトに参加
  • 2003年GRUB2を開始
    • これがやりたかったわけでなく、誰かがやらなくてはいけないのに誰もやってなかったから
      • IPAの枠組みではGNUプロジェクトとして出せなかったので、あとからGNUに組み込んだ
貴重な人材になる方法
  • あなたの存在が重要であるということ
    • あなたの代わりを見つけるのが簡単ではないということ
  • 方法その一:専門家路線
    • 一芸に秀でる
    • 条件:天才であること
    • 短所:中途半端だと干される、理解されないことが多い
  • 方法その二:複合路線
    • 数種の分野に卓越する
    • 条件:あきらめが良いこと
    • 長所:安定しやすい
    • 短所:立ち位置が微妙
  • 方法その三:オールラウンダー路線
    • 数多くの領域に精通する
    • 短所:雑用係になる可能性
  • 方法その四:汚れ仕事路線
    • 誰もやりたくないことをやる
    • 長所:案外儲かる
    • 短所:やりたいことはまずできない
私の哲学
  • 人生とは、世界をより良い場所にするためにある(自分にとって)
    • 本業に割かれる時間は膨大
    • 意に反することばかりやるのは無駄
  • 「できないから、やらない」ではない「やらないから、できない」
    • 無理だと思った時点で無理になる
      • でも本当に無理なことは絶対無理(楽観的な現実主義で)
  • 振り返ってみると
    • KMC時代は用語とか全くわからない
    • GRUBはじめたときにブートローダのことなんかわからなかった
    • Nexedi始めたときに経営のことなんてわかってない(勉強しようと思った)
  • 保険があれば手を出しても一応安心
エンジニアへの適性
  • エンジニアに必要な要素
    • 優れたシステムを提供したいという熱意
    • コンピュータの仕組みに関する知識
      • プログラミング能力がなくては理解することはできない
    • 実用性のあるシステムを構築する
プログラマになるには
オープンソースがスキルに与える効果
  • オープンソースでないと
    • このソフトってどうなってるの?と思っても中身が調べられない
  • 直接コードで対話できる
  • 外部のエンジニアと一緒に活動できる
    • GNUのプロジェクトで良かったことはすごいプログラマとコードについて話せる
  • 機会が平等に与えられる
質問等
  • フランスに行くきっかけ
    • 知人の紹介でやりたいことと合致してた
  • 保険はなんだったの?
    • 大学院やめたときはプログラミングで食べて行けるネタはあった
  • 外国で働くことの苦労は?
    • 外国で働くことよりもギークと働くということが大変だった
      • 自分がすごいということをアピールしないと認められない
    • ギャグ一つとっても言って良いかどうかわからないプレッシャーがあった
  • コンピュータから経営の方に興味が出たきっかけは?
    • 自分はコンピュータにガッツリだった人間ではなく変化が色々あったからすんなり入った
      • 新しいことができることの方が嬉しい
  • 経営としての考え方は頭の動かし方が違う?
    • 基本的にはモノの考え方は変わらない
      • ルールがあって、例外があって、それを処理して
  • コンピュータは決まりきった動きしかしないし感情もないから人間とは違うよね?
    • (コンピュータも感情あるかもしれないって雑談になった)

Why open matters - 宮川達彦氏(Six Apart

  • 自己紹介(ホームかアウェイかよくわからなかったので)
    • サンフランシスコに住んでる
    • エンジニア20人(うち日本人3人)、全体は100人くらい?
    • 2006.11に引っ越し
  • Agenda
    • スピリチュアル系の講演をやってるはてなのid:naoya氏の去年の内容を見て、昔話などをすると良いかなと思った
    • Open Source
    • Open Community
    • Open Platform
      • Open Web
Open Sourceに出会うまで
  • 1977神奈川県横浜生まれ
  • あんまり子供時代はコンピュータに触れなかった
  • 1996に東京大学理科一類
    • 入学時に進路を決めなくていいのが良かった
    • 講義あんまり出ず、Netscape 3とかでネットサーフィン
    • たまたまオライリージャパンでアルバイト
      • バンドでメタルやってたら先輩にイベントで人足りないからと誘われた
      • それだけかと思ったけど、その後も事務仕事とか色々やった
      • スクリプト作った(今でもあってちょっとひいた。regist.cgiって間違った英語の名前あったりとか)
  • 1998情報科学科に最低点で進学
    • 今までの講義の評価で決まるのだけど講義行ってなかったからギリギリだった
    • C,C++,Scheme,Prolog,MLとかやった
    • オン・ザ・エッヂに友達がバイトしてたのでそこからバイト
      • 入社日は弾さんの1ヶ月ほど前
      • この1年後くらいに上場
    • 学業もPerl自然言語処理とかやった
  • 1999夏大学院入試落ちる
    • ほぼ落ちることない試験
      • 一日の数学全くできなくて二日目行かなかった
  • 2000.03わざと1単位落として留年
    • さっきの話(奥地氏)の「保険」をかけた
  • 2000.04にオン・ザ・エッヂのデスマ案件
    • それまではバイトだからあんまり大きな仕事はやってなかった
    • 月曜日に納品、金曜日に何もできてない状態
      • 自分の範囲(認証のAPIとか)は土曜の朝には終わってた
      • これをきっかけに堀江さんに目をつけられる
    • 社内共通モジュール開発エースプログラマ
    • 時給2000円で月300時間
    • この頃
  • 2000.11 CPAN Authorになる
    • 初めにアップしたのは弾さんが作ったモジュールを汎用的にしてアップ
      • MacIE用のモジュール(あんまり使ってる人いなかったけど堀江さんが使ってた)
    • Linux Conferenceに参加
  • 2001.01にテクニカルディレクターとして入社
    • 学校は最後2週間行って卒業
    • CPANモジュールのパッチを送る
      • Mailling List,IRC
      • 英語は高校大学で好きだったけど、やり取り心配だった。でもどんどん送った
      • IRCは聞き取れなかったとかないからおすすめ
  • 2002春 Sledge開発(2003年オープンソース化)
    • バージョン1.1が4年に出てる安定したもの
  • オープンソース化について
    • 受注案件のプレゼンス確保
    • OJT教育コストの低減
      • 人増やしてる時期だったので入社してくる人に「これ勉強しておいて」と言えた
    • 開発チームのモチベーション
      • 当時は思わなかったけど、今思うとオープンソースとして外に出ると自分のコードが世に出るのでモチベーションになる
  • モチベーションについて - CodeReposというmicro blogサービス(ネタ)
    • What are you coding?
    • Twitterで発言してるのと同じだと思う
      • 言葉かコードの違いだけ
    • 人間は自分のものを見てもらいたいというエゴがある
  • 2003 CPAN#1 Authorになる(現在は3位)
    • Software = People Credit counts
    • こうやってガンガン出してくと「何か面白いやついるぞ」ってことになる
      • 評価され信頼性が増える
Open Community/Communication
  • 2002冬 第0次ブログブーム
    • Movable Type
    • Impressive clean code & pluggable architecture
      • 他のアプリに比べてとても奇麗でpluginとかもよく考えられていた
    • Causual use of XML and RESTy APIs
    • 自分もpluginとかのコードを送ったりした
  • 2003.04 Shibuya.pm
  • 2003冬 livedoor Blog
    • 自分は1行も関わってない
  • 2004 Blog Hacks
    • その前にブログについて話して欲しいとnaoya氏に依頼したのがきっかけ
      • それまでオンラインの付き合いんだった
    • livedoor / Nifty 同業他社での共著
      • 同業他社で繋がってるということが不思議な感じだった
      • Open Communication Beyond Just Code
  • 2004 October Six ApartのBenと食事
    • 履歴書置くってと言われてCPANのURLを送った
      • 次の日の朝に「コード全部見たから入って」と言われた
  • 2005 Jan. Six Apartに入った
  • YAPCでの集まり
    • Community = People Get involved.
      • コードを書いて人と関われた
Open Platform
  • TypePad
    • 古いイメージがあるけど、もっとよくしたい
    • OpenIDなどの対応
  • Openってなに? - Community driven Open Standards
    • 誰かが取り決めたものを使うのではなく、使う人達が「こうしたらいいんじゃないか?」と話し合って決める
    • 日本でも追っかけるだけじゃなく、声を上げて
  • 大きい企業でない開発者は?
    • 今は色んな所で声を上げられるからそれを利用する
    • Web API 1.0
      • こういうのがあるから勝手に使ってね
    • Web API 2.0
      • ウチで走らせますよ
まとめ
  • 現在おかれてる環境にとらわれないで
  • コードはあなた自信を変える(世界を変えるだと他で言ってるので)
  • オープンな議論が財産になって行く
  • CODING IS NOT A CRIME. NOT CODING IS A CRIME.
    • コードを書くのは犯罪ではないって言葉があるけど、ちょっと言い換えて「コードを書かないのは罪だよ」と。
質問等
  • ライトニングトークはどこでも行われるようになったね

シミュレーション的発想によるプログラミング - 金子勇氏(Dreamboat)

  • 色んな所でWinnyの話はしたので生い立ちとか
自己紹介
  • Winny作者
    • プログラム作っただけで逮捕された人
  • プログミングは本来趣味
    • パソコンとの付き合いは長いけど仕事にはしてなかった
    • ちょっとしたフリーソフト公開
      • ここから発展して仕事
  • 経歴
    • 茨城大学大学院でドクター
    • NiftyやINTERNET上でフリーソフト公開
      • NekoFlight(フライトシミュレータ)
      • 1998,1999年とかに作ったもので3Dのレンダリング部分を自分で書いた
    • 日本原子力研究所
    • 引き続きフリーソフト公開
      • PS2出た頃
      • ゲーム向け物理演算関係が多い
    • 3DCGソフト会社
      • フリーソフトの商用化
    • IPA未踏ソフト第1期第2期に参加
      • 物理演算エンジン担当
    • 東大大学院特任助手
      • 戦略ソフトウェア創造人材育成プログラム
      • 東大の人ではない
    • Winny開発
    • 現在はDreameboad
いったい何者?
  • プログラマではない
    • 英語が話せても翻訳家ではないのと同じ
    • プログラムはアイディアの表現方法
  • シミュレーション屋
シミュレーションとは?
  • シミュレーション物理学
    • 第三の物理学
      • 複雑系などの検証(カオス系)
    • 理論物理学:実験結果と矛盾しない理論作り
    • 実験物理学:実験をして理論の検証
発想の根源
  • 自然科学的発想
    • 簡単なモデルから複雑な事象生成を好む
      • 仕様通りに動くのは楽しめない
      • 自分で作ったものがどのように動くかが楽しい
  • 作るプログラムは以外にシンプル
プログミラング方針
  • 初期設計はあまり重視しない
    • ベースとなる理屈は最も重要
  • 基本モデルは簡単な方が良い
    • そこから生み出される結果は複雑な方が良い
  • 予想外の結果を重視
    • 楽しい
    • バグはバグじゃない
  • 試行錯誤を重視
    • やってみると動く
    • 細かいパラメータをチューニングに落とし込む
    • テストプログラムは捨ててもいい
  • アプリ例
まとめ
  • シミュレーションの面白さ
    • 予想外の結果が出てくること
    • その割に作るのが簡単
  • シミュレーション的プログラミング
    • 流れ
      1. 思いついたアイデアを最低限で実装
      2. テストラン
      3. 小変更(パラメータ)
      4. 大変更(根本)
    • 離れた概念を組み合わせると面白いことができる
  • 少しでも先に進むことが重要
    • 一気に飛び越えようと無理をしない
    • 初めに作るのは最低限のシンプルなもので良い
  • 無駄なことをしない
    • 如何に手抜きできるかが重要
    • ポイントとなる箇所だけは手を抜かない
    • プログラムの速度最適化と似ている
  • 本来は何か思いついたらこまめに公開すべき
    • フィードバックで色々変えられる
    • 自由に公開できたら良いのだけど。。
  • プログラムは表現手法
    • 検閲しないようにしてもらいたい
  • 自分の仕事は裁判に勝って「プログラムするだけで逮捕」という状況をなくしたい
質問等
  • 今ゲームではシミュレーションが当たり前になってるけど何かネタはありますか?

ライトニングトーク

シンプルWEB基盤技術 - 柳瀬隆敏氏
  • ブラウザのウィンドウは簡単に画面が切り替えられる
    • GUIは簡単に変えられないからマルチウィンドウになってる
  • JavaApplet + Swingで実装できる
Cutter - 須藤功平氏
YAMLとJSON用のスキーマバリデータとデータバインディング - 桑田誠氏
  • YAMLとJSONは関連ツールが弱い。そこでKwalify
    • パーサ(パース前とパース後の両方のデータ)
    • スキーマ定義にオブジェクトの変換などがかける
  • スキーマ定義もYAMLやJSONで記述
ホワイトボード型CMS「SaasBoard」 - 久保田秀和氏
  • Webをフリーレイアウト
  • 文字や絵や画像が書ける
  • Sprite
    • マイクロコンテンツを統一的な方法で自由に配置
    • idのついたdivに子要素のdivの入れ子
  • コンテンツの参照方法はx,yをパラメータで持つ(固定URLも可能)
ギーク図書館 - 阪本真一(quill3)氏
  • 引っ越し先に大きな図書館があって、そこに技術書がたくさん置いてあった
  • 図書館のUIが最悪だった
    • 3000件結果があるのに1000件までしか表示してくれないとか
  • 機能
    • 図書館のデータをぶっこ抜いてきて、Amazonから検索(画像とかも)
    • タグ検索とか
    • 新着図書のRSS配信
  • これから
    • 大阪府立図書館にしか対応してないので他の図書館にも対応したい
  • 学んだこと
    • 他人に文句言うくらいなら自分尾手を動かす
    • 自分専用のサービスを作って公開
    • 小さく作って大きく育てる
パフォーマンスチューニングの基礎の基礎 - 蓑輪(ひげぽん)氏
  • Moshの開発絵の苦労した経験を元に
  • 結論
    • むやみに良いデザインを壊すな
    • 最初にゴールを決める
    • 計測
    • パフォーマンスを工数に入れる
  • やってはいけないこと
    • パフォーマンスを後回しにすると作ってから使い物にならないとかある
    • 「ここがいかにも遅そうだから」はダメ。計測して確かめる
  • 短いサイクルをまわす
    • 開発時は良いデザイン、良いコードに専念
    • 計測
    • チューニング
  • 計測を半自動化して楽しくする
  • グラフを描くと一目瞭然
    • いつから遅くなったか、いつから早くなったかがわかる
エロ目ジェネレータのすべて - 原田均氏
  • 顔写真をエロ目にするWebサービス
  • OpenCV+PythonのCGI
ならべて/narabeでの英語サービス挑戦 - 秋元裕樹氏
  • 日米同時リリース
    • やってみたかった
    • 成功よりもやってみたかった
  • ganchiku.comの世界をまわるフリーランス大野氏が開発
  • 日米リリースについて
    • 開発はsymfonyの機能で補完
    • 文化の違いを気をつけた○とチェックとか
IT業界で学生がこの先生きのこるためには? - ujihisa氏
  • タイトルはネタでVimの話
  • Vimscriptはかわいい
コモンズ・マーカーができるまで - 星暁雄氏
  • 任意のページにコメントを付けられて、そこに自動スクロールしてくれる

弾さん

  • まとまらない感をみなさん持ち帰ってください

吉岡さん

  • 技術は教えれるけど、スタイルや気持ちはコピーできないからそういうところを押さえてくれればいいな