2009年12月8日に誕生した「セブンネットショッピング」。オープン直後から価格表示ミスなど、トラブルが相次いだ。消費不振の中、セブン&アイの新たな成長基盤になれるか。 「年内は1日も休めなかった」。幹部からはそんなため息が聞こえる。セブン&アイ・ホールディングスのEC（電子商取引）サイト、セブンネットショッピングに携わる社員は、年末年始も気が休まらなかったに違いない。 「“流通クラウドポータル”を目指す」。セブンネットショッピング社長の鈴木康弘氏がそう豪語する中で誕生した通販サイト。2009年12月7日、東京・四ツ谷のセブン&アイ・ホールディングス社内の会見場は、突然の告知にもかかわらず記者や関係者で埋め尽くされた。 ネットユーザーの指摘は厳しい 書籍から食品、日用雑貨に至るまで11のカテゴリー、500万品目の商品を揃え、2011年末までには1000万品目を扱うサイトにする－－。総合ネッ

ある時期に「オープンソース」というものがすごいぞと喧伝されていたことがあった。 ソフトウェアを作る際、プロジェクトリーダーがスケジュールや役割分担を決めて作っていくよりも、 ネットを通じて不特定多数が思い思いに自分のアイデアを注ぎ込み、 一つのものを作った方が色んな奴の知識や発想によってすごいものが出来るぞ、という考え方だ。 どっかの外国人が旗振りとなって、色んなプログラマが賛同して、それなりに盛り上がった。 でも、結局、今見てみたらどうだろう？大失敗じゃないか？だって、リナックスはOSの主流になってないじゃん。 梅田望夫はオープンソースの思想をプログラミングの分野だけでなく ネットを使って人文科学などにも応用したらなにやらすごいことが起こるはずだ、と書いていた。 速水健朗はそれを「ニューエイジ」と切って捨てていたけど、でもある程度は成功していると思う。 その一つの集大成がウィキペディアだ

ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善

ある程度の経験を積んだ技術者／プログラマであるかどうかを判断したいとき、「リビジョン管理システムを普通に使えるかどうか？」という基準はけっこう有効な気がした。 以下の使い方は、「使ってみれば便利さが分かるから」とか言ってなんら説明をしなかった僕の責任です -- と前置きしますが： proj/2009-10-23/, proj/2009-11-10/ なんてディレクトリが、リビジョン管理下になっている。 同じことだが、foo.c, foo-v2.c, foo-v3.c なんてファイルがある。 リポジトリのワーキングコピーとは別に、“ほんと”のワーキングディレクトリがあり、ほんとのワーキングディレクトリから一端リビジョン管理下ワーキングディレクトリにファイルコピーしてからコミットしている。 複数人参加単一プロジェクトのディレクトリ構成が、proj/tanaka/, proj/suzuki/,

前方互換性が悲惨 前方互換：新しいシステム向けのデータなどが、古いシステムでも使えること 最近は個人的にはgit使ってるし、バイトではBazaar使ってるしで、分散VCS以外ほとんど使っていなかったんだけど久々にSubversion使ったら見事にハマった。 なんなんですかね。新しい svn でレポジトリをいじったら古い svn から使えなくなるって。簡単に svn のバージョン上げられる環境じゃないケースとか考えてないんだろうか。パッケージマネージャのあるプラットフォームでいちいち最新版を落としてきて入れるとかナンセンスすぎでしょう。 分散VCSのほうがモデルとして優れている云々以前の問題ですね。

2.トリッキーな実装 ソースを読んだだけではすぐにわからないようなアルゴリズムを採用している場合や、使用しているライブラリのバグ回避のための特殊な処理を行っている場合、または他の人が見たときや自分が数年後に見た時に「なぜここでこんなことを？」と感じる可能性がある場合にはソースコードにコメントを追加するべきだ。これは言わばトリッキーな実装である。 ソースコードのコメント率は20%を切ることが望ましい : 小野和俊のブログ 私はこの部分にはもうちょっと汎用的に「意図」を書くべき、とすることを提案しよう。*1 トリッキーな実装というのは、「普通」ということが分かっていて初めてトリッキーかが分かる。普通か、トリッキーか、というのは時代背景*2というかハード的な制約も関係するだろう。常識は移ろいゆく。本人がトリッキーではないと確信して書かれるコードと、トリッキーなコードとの線引きはどうしたらよいのだ

セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。 企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。 利益＝売上-経費　なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。 例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開した

C# のコーディング規約としては、オブジェクト倶楽部のもの (PDF) が有名だけど・・・正直、これ使いたくない。 冒頭に「このドキュメントは Java コーディング標準(オブジェクト倶楽部バージョン)、VB.NET コーディング標準を C#用に変更したもの」なんて堂々と書いてる時点で・・・ で、この規約のどこが駄目なのか、なぜ駄目なのか、どうすればいいのかをまとめてみた。 なんだかんだで長文エントリ。 追記： ちなみに、C# の規約としてはクラス ライブラリ開発者向けのデザイン ガイドラインで十分だと思う。 更に追記： ブコメで教えてもらったんだけど、どうやらクラス ライブラリ開発のデザイン ガイドラインの方が新しいらしい。 2. ファイル構成 (1) ファイル名 public クラスはそのクラス名の 1 ファイルにする。 例：public class Customer は、Custom

経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」

犯人が分かったよママ。開発効率が悪いのは商用のAPサーバーのせいですよ。EJBの仕様のせいですよ。あ、もちろん、仕様がおかしいとか、コーダーの質が低いというのは抜いて考えてね。 これを読んでる人たちはわかると思うけど、Tomcatとかで開発してればちょっとソースコードかえたらすぐ動かせるじゃん？メソッド追加したりしたら、再起動かけなきゃいけないけどさ、すぐに再起動出来るじゃん？待っても10秒かかるかかかんないかでしょ？声を大にしていいたいけど、商用のAPサーバー共は再起動に数十秒から数分かかるんですよ？そりゃね、再起動の必要がないような修正だったらさ、10秒ちょいで使えるようになるけどね、正直そんなに待ってらんないんですよ。そりゃEJBの仕様をうまく使えばそれなりの部分を補えるかもしれないけどさ、開発中にどれだけの回数再起動すると思ってんの？開発効率もそうだけど再起動効率をもっと考えた方が

ConsistentHashing - コンシステント・ハッシュ法 とあるチャットで聞かれて図まで書いて解説したのでもったいないからエントリー化。ちなみにチャットが1時間弱だったのでこういうタイトルにした。 で、Bが消えるとBの責任範囲が全部Dに押し付けられてDがかわいそうでしょ。 Dの仕事が増えるでしょ。Cとか暇そうじゃん！サーバを複数用意しているメリットが薄れてる。みんなが同じくらい働くのが望ましい。 で、Bが1個の点で表現されているから「Bの手前」もDの1個だけで、そのせいで全部Dが引き受けるはめになった。つまり、仕事が細かく分割されてなくて1個の塊だから引き継ぐ人も1人だけで引き継いだ人涙目。あらかじめ仕事を100分割しとけばみんなで分担して肩代わりできて幸せだよね。 だからサーバが5個だけど点は5個じゃなくて500個打とう。それが仮想ノード。 実装はどうするの？という質問に対して

FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で