2008-09-05
ITPro Challenge! 2008 見てきた
去年も面白かったけど、今年も面白かったな。
印象に残ってるのは、
- 川崎氏の「意図的にシステムの弱い部分を作っておいて、そこがダメになりそうだったらスケールアップする」という話
- あぁ、そういうやり方もあるんだなぁと思った。確かに全部潰れることは回避できるかもと。
- 奥地氏の「できないから、やらない」ではない「やらないから、できない」
- まさに自分のことを言われてる感じだった
- 宮川氏の「What are you coding?」
- 金子氏の「プログラミングしただけで犯罪」
- 話の内容自体も面白かったけど、このことについて懸念してるのが良くわかった。やっぱり研究者なんだなぁと
- ライトニングトークではひげぽん氏の「パフォーマンスを工数に入れる」
- これはよく実感することなので「グラフにする」ってことも含めて実際にやりたいなと思う
という感じかな。
あとは、弾さんと吉岡さんの微妙にかみ合ってない感が面白かったです。
来年もやるといいな。モチベーション上がっていい。
セミナー聞く→モチベーション上がる→プログラミング→もっと書けるようになりたいなぁでちょっと落ち込む→セミナー聞く
のループだ。
以下はメモ。
あとで動画配信されたらまた見よう
モバゲータウンをこうして作った - 川崎修平氏（ディ・エヌ・エー）
モバオク
- 今の取締役「守安氏」に携帯用オークション作ってと言われた
- ゼロから作っていいよと言われたのでやる気up
- 開発に当たって
- 自分の好きなことをどんどん取り入れたかった
- サービスが成功してもヤフオクに流れないように
- 開発内容
- 絵文字の使い方が困難だった
- フレームワークから作成した
- SHM（shared momery）を使った高速リスティングの実装
- 困ったこと
- 驚いたこと
- ケータイユーザはものすごくページを見る
- ユーザと運営者の距離が近く、反応もすごく早い
- 問い合わせをtailしておいて、本番反映したらそこに不具合情報があがってくるとか
- 新規サービス開発の進め方
- 基本的に自宅開発で深夜作業
- 作業中は基本的に連絡もとらない
- 自宅サーバ上で開発中のサービスを公開しているので、他のメンバーはそこを見る
- ドキュメントなし、引き継ぎはソース見ろ
- 基本的に自宅開発で深夜作業
- 開発スタイル
- 運用の工夫
- 意図的に弱い部分を作っておく
- Apache1台に負荷をかけておいて、そいつがダメになったらサーバ増やすかという感じ
- 意図的に弱い部分を作っておく
ポケロト
- あんまり記憶にない
ポケットアフィリエイト
モバゲータウン
- 開発期間3ヶ月
- あんまりコミュニティーサービスを自分で使ってなかったから自分で使いたくなるコミュニティーサービスにしようとした
- 開発内容
- 困ったこと
- SNSを使わないので勘所がわからなかった
- サーバ不足、ラック不足
- 多人数開発前提じゃない作りなので、今結構大変
サービス作りの心がけ
- 自分が作りたいものを作る
- ユーザが使いたいサービスと一致するように訓練
- 初めに想定しておいて、実際そう使われたかどうかをフィードバックで確認
- こんなサービスが目の前に現れたらワクワクするという高揚感
- これができたら自分はすごいという問題設定
技術について
- ハッカーじゃない（なりたいけど）
- 自分のものづくりのために技術を習得
- 何かを思いついたらすぐに設計が頭に浮かんで実装できるようにしておく
- 枯れた技術で作れる部分は、枯れた技術で作る
- モジュール、ライブラリはできるだけ自分で書く
- すぐに対応できるように全体を把握しておきたい
ひとり開発だと
- 楽な点
- イメージ通りのものが作れる
- イマイチかもしれない機能も自分で作れるから試せる
- 辛い点
- ひとりよがりになる危険
- だんだん飽きてきて寂しくなる
こんな環境で作れるのが理想
- 作家と編集者のような関係
- 作る側：実績、信頼、愛情、責任感
- 任せる側：任せられるどうかを判断できる能力、適切なインプットと判断力
- 自分は集客力のあるサービスを作ることに専念して、苦手な所は専門家に任せられる
- サポートや営業など
質問など
- セキュリティは？
- iPhone対応は？
- モバオク、モバゲーの文化作りが大変と言ったけどどうだったの？
- どうして成功したと思いますか？
- 他の技術社員は？
- 自分の作った物をメンテナンスしてくれる
- 新しいサービスも作ってる
オープンソースで育つエンジニアリング・スキル - 奥地秀則氏（nexedi）
- 一端のエンジニアになるには新しいことに挑戦しよう
- 注意事項
- 発表内容はあくまで一つの考え方
- 色んな人が居るから優越はつけられない
- 発表内容はあくまで一つの考え方
- 表のプロフィール
- 裏のプロフィール
- 1993年高校三年のときに初めてコンピュータに触れる
- 京大マイコンクラブ（KMC）で遊ぶ
- 1998年GNUプロジェクトに参加
- 2003年GRUB2を開始
貴重な人材になる方法
- あなたの存在が重要であるということ
- あなたの代わりを見つけるのが簡単ではないということ
- 方法その一：専門家路線
- 一芸に秀でる
- 条件：天才であること
- 短所：中途半端だと干される、理解されないことが多い
- 方法その二：複合路線
- 数種の分野に卓越する
- 条件：あきらめが良いこと
- 長所：安定しやすい
- 短所：立ち位置が微妙
- 方法その三：オールラウンダー路線
- 数多くの領域に精通する
- 短所：雑用係になる可能性
- 方法その四：汚れ仕事路線
- 誰もやりたくないことをやる
- 長所：案外儲かる
- 短所：やりたいことはまずできない
私の哲学
- 人生とは、世界をより良い場所にするためにある（自分にとって）
- 本業に割かれる時間は膨大
- 意に反することばかりやるのは無駄
- 「できないから、やらない」ではない「やらないから、できない」
- 無理だと思った時点で無理になる
- でも本当に無理なことは絶対無理（楽観的な現実主義で）
- 無理だと思った時点で無理になる
- 振り返ってみると
- 保険があれば手を出しても一応安心
エンジニアへの適性
プログラマになるには
オープンソースがスキルに与える効果
質問等
- フランスに行くきっかけ
- 知人の紹介でやりたいことと合致してた
- オープンソースばかりやってる会社だった
- 知人の紹介でやりたいことと合致してた
- 保険はなんだったの？
- 外国で働くことの苦労は？
- 外国で働くことよりもギークと働くということが大変だった
- 自分がすごいということをアピールしないと認められない
- ギャグ一つとっても言って良いかどうかわからないプレッシャーがあった
- 外国で働くことよりもギークと働くということが大変だった
- コンピュータから経営の方に興味が出たきっかけは？
- 自分はコンピュータにガッツリだった人間ではなく変化が色々あったからすんなり入った
- 新しいことができることの方が嬉しい
- 自分はコンピュータにガッツリだった人間ではなく変化が色々あったからすんなり入った
- 経営としての考え方は頭の動かし方が違う？
- 基本的にはモノの考え方は変わらない
- ルールがあって、例外があって、それを処理して
- 基本的にはモノの考え方は変わらない
- コンピュータは決まりきった動きしかしないし感情もないから人間とは違うよね？
- （コンピュータも感情あるかもしれないって雑談になった）
Why open matters - 宮川達彦氏（Six Apart）
- 自己紹介（ホームかアウェイかよくわからなかったので）
- Agenda
Open Sourceに出会うまで
- 1977神奈川県横浜生まれ
- naoya氏や、Six Apartの2人と同い年
- あんまり子供時代はコンピュータに触れなかった
- 1996に東京大学理科一類
- 1998情報科学科に最低点で進学
- 1999夏大学院入試落ちる
- ほぼ落ちることない試験
- 一日の数学全くできなくて二日目行かなかった
- ほぼ落ちることない試験
- 2000.03わざと1単位落として留年
- さっきの話（奥地氏）の「保険」をかけた
- 2000.04にオン・ザ・エッヂのデスマ案件
- 2000.11 CPAN Authorになる
- 初めにアップしたのは弾さんが作ったモジュールを汎用的にしてアップ
- MacIE用のモジュール（あんまり使ってる人いなかったけど堀江さんが使ってた）
- Linux Conferenceに参加
- 初めにアップしたのは弾さんが作ったモジュールを汎用的にしてアップ
- 2001.01にテクニカルディレクターとして入社
- 2002春 Sledge開発（2003年オープンソース化）
- バージョン1.1が4年に出てる安定したもの
- オープンソース化について
- モチベーションについて - 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
- 2004 October Six ApartのBenと食事
- 2005 Jan. Six Apartに入った
- YAPCでの集まり
- Community = People Get involved.
- コードを書いて人と関われた
- Community = People Get involved.
Open Platform
- TypePad
- 古いイメージがあるけど、もっとよくしたい
- OpenIDなどの対応
- Openってなに？ - Community driven Open Standards
- 誰かが取り決めたものを使うのではなく、使う人達が「こうしたらいいんじゃないか？」と話し合って決める
- 日本でも追っかけるだけじゃなく、声を上げて
- 大きい企業でない開発者は？
まとめ
- 現在おかれてる環境にとらわれないで
- コードはあなた自信を変える（世界を変えるだと他で言ってるので）
- オープンな議論が財産になって行く
- CODING IS NOT A CRIME. NOT CODING IS A CRIME.
- コードを書くのは犯罪ではないって言葉があるけど、ちょっと言い換えて「コードを書かないのは罪だよ」と。
質問等
- ライトニングトークはどこでも行われるようになったね
シミュレーション的発想によるプログラミング - 金子勇氏（Dreamboat）
- 色んな所でWinnyの話はしたので生い立ちとか
自己紹介
いったい何者？
シミュレーションとは？
発想の根源
プログミラング方針
- 初期設計はあまり重視しない
- ベースとなる理屈は最も重要
- 基本モデルは簡単な方が良い
- そこから生み出される結果は複雑な方が良い
- 予想外の結果を重視
- 試行錯誤を重視
- アプリ例
まとめ
- シミュレーションの面白さ
- 予想外の結果が出てくること
- その割に作るのが簡単
- シミュレーション的プログラミング
- 流れ
- 思いついたアイデアを最低限で実装
- テストラン
- 小変更（パラメータ）
- 大変更（根本）
- 離れた概念を組み合わせると面白いことができる
- 流れ
- 少しでも先に進むことが重要
- 一気に飛び越えようと無理をしない
- 初めに作るのは最低限のシンプルなもので良い
- 無駄なことをしない
- 本来は何か思いついたらこまめに公開すべき
- フィードバックで色々変えられる
- 自由に公開できたら良いのだけど。。
- プログラムは表現手法
- 検閲しないようにしてもらいたい
- 自分の仕事は裁判に勝って「プログラムするだけで逮捕」という状況をなくしたい
質問等
ライトニングトーク
シンプルWEB基盤技術 - 柳瀬隆敏氏
Cutter - 須藤功平氏
YAMLとJSON用のスキーマバリデータとデータバインディング - 桑田誠氏
ホワイトボード型CMS「SaasBoard」 - 久保田秀和氏
- Webをフリーレイアウト
- 文字や絵や画像が書ける
- Sprite
- マイクロコンテンツを統一的な方法で自由に配置
- idのついたdivに子要素のdivの入れ子
- コンテンツの参照方法はx,yをパラメータで持つ（固定URLも可能）
ギーク図書館 - 阪本真一(quill3)氏
- 引っ越し先に大きな図書館があって、そこに技術書がたくさん置いてあった
- 図書館のUIが最悪だった
- 3000件結果があるのに1000件までしか表示してくれないとか
- 機能
- これから
- 学んだこと
- 他人に文句言うくらいなら自分尾手を動かす
- 自分専用のサービスを作って公開
- 小さく作って大きく育てる
パフォーマンスチューニングの基礎の基礎 - 蓑輪（ひげぽん）氏
- Moshの開発絵の苦労した経験を元に
- 結論
- むやみに良いデザインを壊すな
- 最初にゴールを決める
- 計測
- パフォーマンスを工数に入れる
- やってはいけないこと
- パフォーマンスを後回しにすると作ってから使い物にならないとかある
- 「ここがいかにも遅そうだから」はダメ。計測して確かめる
- 短いサイクルをまわす
- 開発時は良いデザイン、良いコードに専念
- 計測
- チューニング
- 計測を半自動化して楽しくする
- グラフを描くと一目瞭然
- いつから遅くなったか、いつから早くなったかがわかる
エロ目ジェネレータのすべて - 原田均氏
ならべて/narabeでの英語サービス挑戦 - 秋元裕樹氏
- 日米同時リリース
- やってみたかった
- 成功よりもやってみたかった
- ganchiku.comの世界をまわるフリーランス大野氏が開発
- 日米リリースについて
- 開発はsymfonyの機能で補完
- 文化の違いを気をつけた○とチェックとか
IT業界で学生がこの先生きのこるためには? - ujihisa氏
- タイトルはネタでVimの話
- Vimscriptはかわいい
コモンズ・マーカーができるまで - 星暁雄氏
- 任意のページにコメントを付けられて、そこに自動スクロールしてくれる
弾さん
- まとまらない感をみなさん持ち帰ってください
吉岡さん
- 技術は教えれるけど、スタイルや気持ちはコピーできないからそういうところを押さえてくれればいいな
Permalink | コメント(2) | トラックバック(0) | 02:22 
トラックバック - http://d.hatena.ne.jp/lesamoureuses/20080905/1220635324
リンク元
- 594 http://b.hatena.ne.jp/hotentry
- 483 http://b.hatena.ne.jp/
- 466 http://reader.livedoor.com/reader/
- 271 http://www.hatena.ne.jp/
- 174 http://d.hatena.ne.jp/
- 161 http://phpspot.org/blog/archives/2008/09/200898.html
- 73 http://b.hatena.ne.jp/entrylist?sort=hot
- 72 http://b.hatena.ne.jp/add?mode=confirm&title=ITPro Challenge! 2008 %u898B%u3066%u304D%u305F - JavaScript%u3068%u304BPerl%u3068%u304BPHP%u3068%u304B%u3055%u304F%u3089%u3068%u304B%u52C9%u5F37%u3059%u308B&url=http://d.hatena.ne.jp/lesamoureuses
- 67 http://itpro.nikkeibp.co.jp/article/Watcher/20080904/314172/?ST=develop&P=5
- 53 http://popurls.com/
