デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
書き直したって、いいんだよ
http://www.yamdas.org/column/technique/hatenablog.html なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？ プログラムをスクラッチから書き直すことに決めることだ。 まぁ、そんなわけないんだけどね。 「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
ロシアのソフト開発がいろんな意味で凄い - やまもといちろうBLOG（ブログ）
本来のミッションから少し離れて、本業の参考にと思って知己を得ていた先方の会社さんを訪問したり情報交換したりして過ごしていたんですが、いろいろ凄いです。「事情を日本のブログで紹介するよ」と言ったら、どこか明かさないという条件で許してくれました。 ● ソフトウェアの開発効率はあまり考えない シャチョーも担当者も現場の人も、効率は大事だけど開発に取り組む要員の創意工夫ややりがいを重視しているとのこと。現場レベルでは18ヶ月のプロジェクトが50ヶ月遅延した笑い話をしてくれたり、某ドイツの基幹系をロシア企業に提供する際にドイツ人の定義定義のやり方に嫌気が差し、そんなことだから戦争に負けるんだと掴み合いになった話を披露してくれました。 ● でっかいものを作りたがる どっちかっていうと日本では小さくて正確なコーディングを求めて、バージョンがアップするごとにコンパクトかつバグが少なくという方向で作業指示が
空き時間にスマフォでソースコードが読める『CodeLibrary』をリリースしました！ - hamheiの日記
英語でこの記事を読む（Reading in English） ・4/5 追記: 好きなプロジェクトのコードが読めるPocketCodeをリリースしました。 クリスマスも当然の如く開発充なはむへいです！ 僕と同じくクリエイティブで孤独なＸデイを過ごす500万人のエンジニアを応援する為に 『CodeLibrary』というOSS（オープンソースソフトウェア）のコードをスマフォ上で読めるアンドロイドアプリをリリースしました！ きっかけ 「OSSも読まないエンジニアって...」という記事を読んで、慌ててコードリーディングを始める 移動中にSNSを見る時間を、コードリーディングに充てたい スマフォでソーシャルにコードリーディングが出来るプラットフォームを作ろう！ ベータ版ができたから公開するお^^ ←ｲﾏｺｺ どんなアプリ？ ちょっとした空き時間に、スマートフォン上でソースコードが読める、アンドロイド
開発中に求めること - ✘╹◡╹✘
7月1日にCookpadにインターンとして参加してから1週間が経過した。「インターンに参加する」では齟齬があり、「インターンとして参加する」が最もしっくりくる雰囲気。ここでは時間が過ぎていくのが速すぎて恐ろしい。月と太陽まで高速なサイクルを回さなくてもいいのに。 今まではてなで働いた経験しかなかったけど、今回クックパッドで働いた経験が1週間貯まった。これまでは「はてなだからこうしているのかもしれない」という捉え方しか出来なかったけど、この時点で「ああどこも共通してこうなっているのかも」という視点に立って考えることが出来る状態になった。その視点から考えてみて、幾つかの共通する意見が明確になってきた。 学習コスト Cookpadの開発は、途中からJoinしやすい環境が整っていた。Railsを採用しているところは特に、内製フレームワークに対する理解の為の学習コストが発生することなく、開発に取り掛
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
モダンな Perl の開発環境の構築方法 - tokuhirom's blog
一般的な OSX 環境および Linux 環境における、モダンな Perl 開発環境の構築方法についてまとめてみたよ。 perlbrew のインストールperlbrew をつかうことにより、簡単に最新版の Perl5 を利用することができるようになる。 perlbrew をいれる。% curl -L http://xrl.us/perlbrew | perl - install % ~/perl5/perlbrew/bin/perlbrew init ~/.bashrc (または ~/.zshrc)に source ~/perl5/perlbrew/etc/bashrc を追記。あたらしいシェルをたちあげる。最新版の perl をインストールする。% perlbrew install perl-5.12.1 % perlbrew switch perl-5.12.1 ここまできたら、she
20%ルールの合理性 - takminの書きっぱなし備忘録 @はてなブログ
Twitter使い出してから、あまりこちらのブログにつぶやき系を書かなくなったんだけど、以前つぶやいた内容を再掲しておく。 - 実は新しい物を作っていく上でGoogleの20%ルールのうちの残りの80%の通常業務がかなり大事なのではないかという気がしている。その80％で研究開発技術者が直接ビジネスニーズを知ることが出来るから。 - 実は、日本の大企業のR&Dって（もちろん企業にもよるけど）かなり自由にやれている印象がある。会社の承認は必要だけど、自分たちである程度自由にテーマを選定して、それに対して100%の時間を使って研究をしているんじゃないかと思う。 ただ、これらの大企業は多大な投資をして、良い技術開発をしている割に、いまいちビジネス化がヘタなんじゃないかと感じている。 で、先のつぶやき「実は80%が大事」という考えに至ったわけです。 これは、研究開発から製品化までのスパンの短い情報系
iPhoneアプリ開発者があえて言う。iPhoneは終わる。 - 医者を志す妻を応援する夫の日記
私は、もともとWindows開発者(.NET)で、パッケージ基幹業務アプリケーションのベンダーで働いていました。同時に、家ではWeb開発をやっていました。最近は、フリーランスになって、iPhoneアプリ開発がメインになっています。ところが、iPhoneアプリ開発の比重が高まるにつれ、そのことに対する不安感が大きくなってきました。最近では、iPhoneアプリ開発の比重を減らすにはどうすればいいのか考えています。 iPhone 3GSが出てから、かなり売れてるみたいですね。私の住む熊本ではiPhoneユーザーはまだまだ少ないと思いますが、企業、団体、個人によるiPhoneアプリ開発に対する関心が高まっているのを感じています。東京あたりに行くとiPhoneアプリ開発者がゴロゴロいると聞きますが、熊本や福岡では開発者が足りていない状況です。 このような状況で、なぜ私がiPhoneアプリ開発の比重を
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
エンジニアの未来サミットについて素直に語ってみるよ！ : ロケスタ社長日記
そういえば、おとといくらいにエンジニアの未来サミットなるものに出てきました。パネルディスカッション。 いやぁ、楽しかったです。 思うところもあるので、ちょっと素直にいろいろ書いてみようかと。 エンジニアの未来サミットって何？ 技術評論社という会社さんが主催したイベントです。 エンジニアの未来サミット 本サミットでは，これからIT業界を目指す学生，また今IT業界に入ってきた若手エンジニア・デザイナーの皆さんからの疑問や不安に対し，業界をリードする「アルファギーク」の面々，そして今活躍している30代前後のエンジニア，いわゆる7x，8x世代の方々がお応えします。 簡単に言うと、IT業界についてどう思うかっていうのを、その業界の人に聞く、というイベントです。 個人的には、就職活動の人とかがやる業界説明セミナーみたいなのを想像していました。学生がターゲットというか。 どちらかという
要求は怪物みたいなもの
Angry Aussie / 青木靖 訳 2007年8月1日 水曜 8歳になる娘と話をすると、自分が何でもわかっているなどとは思わなくなる。 質問が上手なあの子は、私が答えられなかったり、少なくとも真剣に考えなきゃならないようなことを聞いてくる。真剣に考えるというのは重要で、いい加減な答えをしようものならすぐ突っ込まれてしまう。彼女が5歳で母親に日曜学校へ送り迎えしてもらっていた頃のある日、何の前触れもなくこんなことを聞いたことがあ った。 「ねえ、神様が私たちを作って、そして私たちを好きでいるなら、どうして神様は私たちが病気になるのをほうっておくの?」 あなたならどう答えるだろう? 私が最初に思いついたのは「ママに聞いてごらん」ということだった。しかしこれはその場しのぎにしかならない。最終的には「死なないくらいの病気かかると、かえって体が丈夫になるんだよ」という冴えない答でどうにか逃げお
第28回 日本企業を見限ったインドの“システム屋”から学んだこと
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第27回）で登場したインド人の“システム屋”経営者の言葉をもう1つ紹介したいと思います。彼から「日本企業向けの仕事はもうやりたくない」と言われたことがあります。英語力の問題ではなく、日本人はそもそもシステム開発に向いていないというのが彼の主張です。 これを聞いた私は、その場では苦笑するほかありませんでしたが、日本人の“システム屋”として悔しいという感情が残りました。しかし今ようやく、この意見には反論が可能だという思いに至りました。
Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これが無料とは！ スマートフォン向けサイトやアプリのワイヤーフレームを作成するソフトウェア -Prototyper
http://userenv.info/
このプロジェクトは無理です : 2chコピペ保存道場
https://www.fluxflex.com/