主催・運営した エムスリー x Gunosy Beer bash！ の発表資料です＾＾ gunosy-beer.connpass.com/event/22825/
個人開発と徳
主催・運営した エムスリー x Gunosy Beer bash！ の発表資料です＾＾ gunosy-beer.connpass.com/event/22825/
最近のおっさんたち - steps to phantasien
Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
オブジェクト倶楽部 2009 夏イベントに登壇させていただきました - t-wada の日記（旧）
本日はオブジェクト倶楽部夏イベントにて 90 分もの長時間(!)喋らせていただきました。 会場にてお聞きくださった皆様、ありがとうございました。 講演の内容はというと、「創発的設計 (Emergent Design) 」というコンセプトについて講演をさせていただきました。自分は何を学んできたのか、何に学んできたのかを明かにし、いまの理解を立体化しました。「テスト駆動開発を本当に厳格に行うならば3イテレーション程度でアーキテクチャが破綻する」という意見に対する私の考えの表明でもあります。 Emergent Design - ObLove 2009 summerView more documents from t_wada. テスト駆動開発者はテスト駆動開発という手段だけで開発を行っている、つまり先行設計をしない、という誤解に対して、そのようなことはないという (ごく真っ当な) 結論になってい
[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提（状況／状態）は何か。 成り立つ事が単に多いだけ／今はたまたま成り立っている、と
![[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません](https://cdn-ak-scissors.b.st-hatena.com/image/square/f9042ce188c6adf10bc5510036708350fbfa0c46/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fe6eb841fd971e91609ad99e751b726c65a84d0f0%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fi.creativecommons.org%252Fl%252Fby-nc-sa%252F2.1%252Fjp%252F88x31.png)
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
Googleエンジニアから学ぶ、ハッカーになるための勉強法 - 久保清隆のブログ
Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W. Reeves 氏に，
高速にWeb開発をするために便利ないくつかのTIPS - KAYAC Engineers' Blog
outputz でいまだに1位になれたことがない村瀬です。 社内で開発をスムーズにするための tips 集を紹介したので、まとめておきます。 記事ではデモができないので便利さが伝わらない物も多いですが参考になれば幸いです。 screenとかzshとか便利だよ！と言う話は社内ではさんざんしているのでありません。 また、OSX 限定の内容もあります。 でははじめましょう。 keychain keychain と言っても OSX の KeyChain ではなく、コマンドラインのツールです。 これは ssh-agent をより便利にするためのラッパーです。これを使用すると ssh の秘密鍵のパスワードを一度入力するとあとはパスワードなしで ssh 接続できるようになります。 「同じこと二回も言わせんな！」といつも切れているような人は導入すると良いでしょう。 使い方は $ keychain ~/.s
Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り！ 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
『ギーク必聴のPodcast』
今までずっと40GBの第三世代iPodを使っていたのだが、もっと機動性が欲しくなったので、最近になってようやくiPod nanoを買った。それ以来、嬉々としてネット上でPodcastを探しては通勤の行き帰りに聴く毎日を送っている。 技術系Podcastはいくつか見つけたのだが、その中でも一番のお気に入りは「Software Engineering Radio」というPodcastだ。 http://www.se-radio.net/ このPodcastは、著名なエンジニアや著者との1時間くらいのインタビューを公開しているものだが、すごいのはインタビューされる人たちの布陣だ。OOやパターン、アジャイル関係の重鎮や、著名なエンジニアや言語設計者を軒並み総狩りしていて、北欧系ギークには涎モノの最強ラインナップになっている。 現在までで86エピソードが公開されているのだが、北欧っぷりを見るためにラ
d.y.d. Pluggable Type Systems
19:27 08/02/29 不動点ふたたび LtU で "Data Types a la Carte" を読みました。これの鍵となる技は「型コンストラクタに対する不動点演算子」だと思うのだけど、 あれ、なんで俺これ考えたことなかったんだ…？と不思議に思うくらい楽しげなアイデアですね。てい。 // 不動点演算子 via テンプレート。Dで。 // // Haskell でいう"普通の"不動点関数 fix f = f (fix f) と同じようなもの // = の代わりに継承になっちゃってますけど、まあ似たようなものです class Fix!(alias F) : F!(Fix!(F)) {} 不動点演算の実装は本題ではないので、Yコンビネータみたいな無駄な複雑化はしない方針で。 さて、これを使って class Pair(T) { T left; T right; } ２個同じ型の値のペアを
バグレポートはこう書け - バグレポートのための単文集
バグレポートはこう書け - バグレポートのための単文集 バグレポートのための単文集 send-pr とか bugzilla に投げるときとか、なんて書いて いいのかわからんのよね。 というわけで、とにかくいろんな文章をまとめてみる。 心構え バグレポートの目的は何か? バグを伝えることである。 よりよい英語を書くのが目的ではない。拙い英語でもいいから、 とにかく書け。ネイティブスピーカーなら、変な英語でもそれはそれで通じる。 日本語ネイティブは FreeBSD-users-jp:72469 を理解できるっしょ? それと同じ。 I'll take a look at this, as inetd is my problem. (inetd のバグレポートを受けて) inetd の件は俺が仕込んだバグなので、このレポートの面倒みるよ 異議なーし No objection from me. 2台
OBB vs AABB - Radium Software Development
This domain may be for sale!
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reddit - The heart of the internet
Social Codingの世界
ソースコードの品質向上のための効果的で効率的なコードレビュー
Efficient data transfer through zero copy
http://www.sabamiso.net/yoggy/hiki/?2007%2F04%2F09+%A5%EA%A5%D0%A1%BC%A5%B9%A5%A8%A5%F3%A5%B8%A5%CB%A5%A2%A5%EA%A5%F3%A5%B0%A4%DE%A4%C4%A4%EA%A4%CE%A5%E1%A5%E2