新法で「アプリストアを競争状態に」の現実味、公取委はApple・Googleと長期戦も 2024.05.16
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り! 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
まずはじめに、京都は美人が多い。 はてなのジョエルテスト ソース管理システムを使っているか? Yes. gitを使っている 1オペレーションでビルドを行えるか? Yes. 毎日ビルドを行うか? Yes. 障害票データベースを持っているか? Yes. gitと連携する内製ツールをつかっている。 新しいコードを書くまえにバグを修正するか? Yes. 更新可能なスケジュール表を持っているか? Yes. はてなグループを使っている。 仕様書を持っているか? Yes. テスト駆動開発なので、テストが動く仕様書。 プログラマは静かな労働環境にあるか? Yes. 買える範囲で一番良い開発ツールを使っているか? Yes. テスト担当者はいるか? Yes. プログラマを採用するときにコードを書かせるか? YES YES YES! 「廊下での使い勝手テスト」を行っているか? Yes. 満点。 はてなの開発 サ
コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。 他の要素としては、クローリングとインデキシング、クラウド系というところらしい。 サーバをグリッド化(やや死語だな)して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。 昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。 あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。 あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
プロジェクト管理ツールの必要性 みなさんのプロジェクトは上手に運営できていますか? プロジェクトメンバーのタスクの進捗管理はできていますか? 問題・課題管理はスムーズに行えていますか? ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか? 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか? ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか? ソースコードはきちんと管理されていますか? リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか? プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい
少し時間があったので「発注者ビューガイドライン」なるものを読んだ。NTTデータや富士通など大手SIerが共同で作成したものだそうで、要は顧客に分かりやすい外部設計書の書き方をまとめたものだ。「こんな“業界標準”が必要なの」とツッコミを入れたくもなったが、やはり重要だと思い直した。 外部設計書はシステム仕様のうち顧客から見た機能の定義だから、ここがいい加減だとプログラマ向けの内部設計書も作れず、システム開発なんかできないはずだ。それでもシステムを作れてしまうのが恐ろしいところで、後で顧客から「話が違う」と文句が出て、手戻りが発生、下手をすると火だるまのプロジェクトになる。だから、しっかりとした要件定義を基に分かりやすい外部設計書を作り、顧客と合意するというのは本来、不可欠な作業だ。 でも、そんなことはSIerなら先刻承知。各社とも分かりやすい外部設計書を作るノウハウを持っているだろうから、改
そんなわけで、プロジェクトの始まりはTracから。これがないと仕事が始まりません。 Tracが一番良いわけでも無いんだけど、日本語マニュアルがあるところと、ユーザが多いことから、subversionとの連携スクリプトなどが多数公開されているところが、選択理由です。 Railsベースでも複数、プロジェクト管理ソフトが出てきているので、どれか良い物に育ってくれると嬉しいなと思っています。 さて、tracのインストール方法はwebで沢山見つかるので、それを参考にインストール。 Tracは初期設定でも十分使いやすいんですが、チケット登録で担当者をドロップダウンリストにするために設定を変更します。 tracの設定ファイル conf/trac.iniの下記の項目を変更してください。 [trac] default_charset = utf-8 # 文字コードはUTF-8で [ticket] restr
「有名人身長推定サイト SETAKE」「EREK」などのサービスを作ったたつをさんはドメイン取得からサービスリリースまでは半日でこなすという。飲み会で生まれたアイデアをもとにサービスを開発することもあるため、ペンはどこにでも持ち歩く工夫をしている。 「ひとりで作るネットサービス」第11回目は、Web APIを活用して次々と小粋なサービスを開発するたつをさん(35)にお話をうかがった。「ドメイン登録からサービスリリースまで半日が目安」と言い切る彼は、どのように企画・開発・運用を行っているのか。その秘訣に迫った。 飲み会の会話から「有名人身長推定サイト」が生まれた 「作ったものはたくさんの人に使ってもらいたいですよ。エンジニアですから」と話すたつをさん。彼が作るサービスはWeb APIを使ったシンプルなものが多い。ちょっとしたアイデアが、情報の見せ方を工夫することで“意外と便利”なサービスにな
PHPは生産性の高い開発言語として広く普及しました。現在も多くのWebアプリケーション開発でPHPが採用されており、その手軽さも手伝って実績を伸ばし続けています。手軽に開発できることから、個人での開発もでき、独自の開発手法が多く存在し、複数人では統一が難しいといわれています。 そのため複数人による開発では、確固とした開発手法がとられてない事例が多いのも事実です。開発手法が確立されてない場合、規模が大きくなるとすぐに破綻してしまいます。それを避けるには、開発手法を確立しておく必要があります。 本連載では複数人によるPHPを用いたWebアプリケーション開発において、実際に筆者の所属するウノウ株式会社が行っている手法を例に効率的な開発手法を解説していきます。本連載の内容はPHPだけでなくRubyやPerlのような他の言語にも適用できます。また1人で開発を行う時に非常に有効な方法です。実際に筆者が
Leon Bambrick / 青木靖 訳 2007年4月19日 木曜 新しい機能を見積るというのは・・・こちらに泳いでくる小さな魚のようなものだ。 小さな魚がくるぞ。 あの小さな魚を見て! あの魚小さいよ! あの魚なら食べられる! 一口で飲み込んでしまえそうだ! そんなに簡単だって、間違いない? もちろん簡単に決まってる! こんな小さいんだから! だけど前は間違ったじゃない。 うるさい、頭の中の声! この魚は小さいって。真ん前から見てるんだから間違いないよ! 一口だ。パクッ! それで終わり。朝飯前さ! 魚とは言えないくらいだ! ただの点だ! 小さな点! 小さな点を食べてやる! そら、魚が来る! 待てよ、なんか嫌な予感がしてきた。 もう遅いよ。約束しちゃったんだから。 魚を横から見たところ。 あーあ。
尾藤正人です。 Ruby で debug する7つの方法 Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 ということなので、僕が PHP でやってること書いてみたいと思います。 preprint_r() print_r() とか var_dump() だと HTML の中に出してブラウザで見るときにすごく見にくくなります。 そこで preprint_r() という関数を定義して、<pre></pre> で囲んで見やすいように出力しています。 function preprint_r(&$var, $title = '') { echo _preprint_r($var, $title); } function &_preprint_r(&$var, $title = '') { if
2007年04月13日07:30 カテゴリArt プログラマーの義務宣言 Objection, Your Honor! プログラマの権利宣言 すべてのプログラマは2つのモニタを持つ権利を有する すべてのプログラマは高性能なPCを持つべきである すべてのプログラマはマウスとキーボードの選択の権利を有する すべてのプログラマは快適な椅子を持つべきである すべてのプログラマは高速なインターネット接続を持つべきである すべてのプログラマは静かなる仕事環境を持つべきである すべてのプログラマはVGAモニタで作業する術を学ぶべき 君たちはどうやってLinuxやFreeBSDをラックマウントサーバーに仕込むんだい? Xがないと手も足も出ないなんてことないだろうね。 できればさらにシリアルコンソールで作業する術も学ぶべき。私は一度海外の顧客が壊してしまったSunのFirmwareをリモートで修復したことが
ソースコード・ドキュメンテーション・ツール Doxygen は、C++、C、Java、Objective-C、Python、IDL (Corba、Microsoft 風)、Fortran、VHDL、PHP、C# 向けのドキュメンテーション・システムです。 D にもある程度対応しています。 Doxygen には、次の3つの利点があります。 文書化されたソースファイルのセットから、 オンライン・ドキュメント・ブラウザ (HTML形式) やオフラインのリファレンス・マニュアル (形式) を生成することができます。 RTF (MS-Word)、PostScript、ハイパーリンク PDF、圧縮 HTML、Unix man ページ形式の出力もサポートされています。ドキュメントは、ソースから直接抽出されます。これにより、ドキュメントとソースコードの一貫性を保つことがとても容易になります。 Doxyge
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
2007/04/03 全米で第6位のトラフィックを稼ぐ人気SNSサイト「Facebook」のコアモジュール「Thrift」がオープンソースとして公開された(公式ブログ)。ライセンスは独自の「Thrift Software License」(改変や再配布を許容している点はGPL同様のようだ)。Facebookは学生向けSNSとして2004年にスタートし、その後、学生以外にも会員を拡大。2007年2月現在の会員数は1700万人。アップロードされている写真点数は10億枚以上で、1日600万枚の画像がアップロードされるなど、画像共有サイトとして見てもFlickrよりも大きい。そんな急成長した巨大サイトを支えたのは、独自に作り上げた開発フレームワークだったようだ。 多数の言語で開発したモジュールをシームレスに統合 Facebookが、開発フレームワークとして自ら作成したのがThriftだ。“thri
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く