昨日 if-then-else 文の順序に関するエントリを書いたところ、いくつか「レアケースは先に切って return する」というブクマコメントがあり、確かにこの点も考慮すべき重要な点なので前のエントリの補完的な意味も含めてエントリを書く。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } しかしもしこれがメソッド/関数で、次のように後続の処理がないものだった場合を考えてみる(後続の処理がある場合には先のエントリに書いた検討を行う)。 public void method() { if (よくあるケース/正常なケース) { // 通常の処理 } else if (特殊なケース1) { // 特殊な処理1 } else if (特殊

「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と

■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人

いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い

・最善を尽くしてもどうにもならないなら、自分のこれまでのやり方に固執せずに、課題を解決している先人達がどのように対処してきたのかを謙虚に学び、自らも実践を試みる。 ・先人達の方法を模倣しても課題が解決しないなら、自分の強みと弱みとを振り返り、自分の強みが活きるよう、先人から学んだ方法を微調整して再度課題解決に臨む。 ・失敗が続き、もう自分は降りよう、という気持ちになってしまったら、課題を乗り越えた先にある成功をイメージし、「あの坂を登れば、海が見える」のだ、と、自らを勇気づけるようにする。 ・身も心も疲れ果て、自分を奮起させる気力さえも無くなってしまったら、再起のためにあえて一時的に課題から離れ、安楽の中で自らを癒す期間を設けることも検討する。 解決が困難な課題に直面した時、ただ立ち尽くすだけでなく、解決に向けたステップをひとつひとつ踏んでいくことが大切なのだと、ここ半月ほどDiablo3

昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお

ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して

こんにちは、ITホストクラブでホストをしていますlalhaです。私はテレビも見ないしファッション雑誌も読みませんが、プログラミングについてはプロフェッショナル。今回は、モテるプログラマー女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 あえてコンパイルの通らないソースコードをノートPCに入れて携帯するようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくノートPCを開いてコンパイルしてみましょう。そして「あ〜ん！　このソースコード本当にマジでチョームカつくんですけどぉぉお〜！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「プログラムとか詳しくなくてぇ〜！ずっとこのコードいじってるんですけどぉ〜！コンパイルが通らないんですぅ〜！ぷんぷくり〜ん（怒）」と言いましょう。だいたいの男は自分の専門性をアピールしたがる習性があるので、ノートP

はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上

8/5から三日間、昨年に引き続き、九州大学非常勤講師として高度ICTリーダー特論という大学院の授業で福岡に来ている。この授業では、日本の大企業からはNECのシステム開発本部長の池上さん、国際的なリーダーシップということで東京海上で世界中を飛び回っている牧野さん、外資系企業のマイクロソフト楠さん、ベンチャー企業のUEI shi3zさんと私、経産省の境さんと、様々な立場の講師がプレゼン、パネルディスカッション、グループワークなどに参加しながら授業を進めるというなかなか面白いタイプの授業である。 こうした諍いのことをネットに書くのもどうかとも思ったのだが、リーダーシップを論じるために呼ばれた講師同士が飲み会で喧嘩、ということになると、授業そのものが駄目なリーダーの見本市のような様相を呈してしまうため、私たちが何を議論していたのかについて、shi3zさんにならって私の視点からもブログに書いてみよう

技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発

コメント一覧 (4) 1. kazu氏 2008年11月13日 15:08 はじめまして。彼氏が○○だった。別れたい…シリーズ？で、プログラマで別れたくない、ていうのはいいな！と思いました。プログラマは変だけど、素敵な仕事だと思います。頭の中が普通の人とちょっと違うけど、それはそれでいいと思うんですけどね^^ 2. ところてん 2008年12月08日 15:50 >君の瞳は100テラバイト ハードディスクの容量は二年で二倍くらいになってくから、 「15年位すると、君には価値がなくなるよ」って意味ですね。 3. みかん 2008年12月12日 16:04 ＞ところてん様 ハードディスクは構造が変わってしまう。 古いシステムでは使えないし、 人もそれを勉強しないと使えなくなる。 だけど「君」は構造はそのままで進化「容量増加」が出来るから、 かなり良いと思うよ。 彼氏しだいで、ゴミにもスーパーコ