Rails勉強会@東京 第30回の懇親会の席で話していて、 id:takahashim さんがハッとすることを言った。バグバグなコードは負債であると。 バグバグなコードは、それだけでメンテに定常的な出費を産む。書き直せばそのコストはいらないのに。バグバグなコードはあらゆる危険性を産む。なまじモノがあるだけについコードを無条件に資産と見なしてしまいがちだが、実は怪しいコードは負債であると。 そして、でっち上げのコードが必要な場合も確かに存在するのだ、とも。「無借金経営だけが経営じゃない」そうだ。なるほどね。 ここで、自動化されたテストケースが存在しないことをもって負債と見なす、と基準を定めよう。テスト可能性が担保されていればそのコードはそれなりに安全であるわけだし、差し換えもローコストなわけなので。「レガシーコード = テストが存在しないコード」という定義は『 Working Effecti

http://anond.hatelabo.jp/20080130215148 http://slashdot.jp/askslashdot/article.pl?sid=08/02/03/0022251 危険だとか迷惑だとか踏み台だとか色々かいてあるけれど(というか踏み台ってなんだろ？) そんなに大切な個人情報をたくさん扱ってるサイトなんてどれだけあるかな。 http://d.hatena.ne.jp/Hamachiya2/20080131/security 多分ネタなんだろうが，あえて釣られてみる．*1 Q. 2個同じ機器を抱えているが、コードも2つある。共通関数化しないか A. 2個同じものがある機器構成でもセンサ類のレジスタは別になる。だから共通の関数にできないのはあたりまえだ Q. 関数が尋常じゃない長さ(700行)なので可読性のため分割しませんか A. 関数コールであちこちに飛

粗悪なSEO業者が乱立中 （読売新聞 関西版） 読売新聞の記事によると、検索順位を保証しますといいながら依頼すると逆に順位が下がるなどSEO苦情が増加中らしい。 公開日時：2007年07月03日 21:19 読売新聞 関西版の記事（記事名：「検索で上位」のはずが・・・SEO業界団体に苦情続々,http://osaka.yomiuri.co.jp/news/20070703p202.htm）によると、検索順位を保証するという会社のSEOサービスを利用した結果、逆に順位が下がったという苦情が増えているということです。 記事で紹介された事例では、SEO対策ソフトを5年間リースで契約したけれども導入後に順位が大幅に低下（16～40位から300位以下に）、業者に苦情をいったけれども「順位上昇は確約していない、順位が下がったのはソフトが原因ではない」と説明されたそうです。リースも途中解約ができないとい

毎日、人材紹介会社のコンサルタントは転職希望者と会う。さまざまな出会い、業務の中でこそ、見えてくる転職の成功例や失敗例。時には転職を押しとどめることもあるだろう。そんな人材コンサルタントが語る、転職の失敗・成功の分かれ道。 最近、下請けの立場で仕事をされているITエンジニアから、次のような話をよく聞くのです。 「いま常駐している（あるいは派遣されている）プロジェクトでは、元請けの会社の人と一緒に仕事をしています。彼らの仕事ぶりを見る限り、協力会社の自分にだって十分マネージャは務まると思います。だから自分も下請け（あるいは派遣）を脱して、元請けで上流工程を担当したい」 確かにそのとおりのときもあるのでしょう。ただし、ときには思い違いではないかと思うこともあります。今回は、このことに関連したお話をさせていただきたいと思います。 「俺にもできる」が実現できる例 あるソフトハウスに勤務していたある

2007年03月24日03:25 カテゴリ書評/画評/品評 書評 - ボクがライブドア社長になった理由 ライブドアが行ったM&Aには賛否両論があるが、絶対に正解だったものが少なくとも一つある。 ボクがライブドアの社長になった理由 平松庚三 弥生の買収、だ。 なぜそれが正解だったか? 平松庚三その人がいたからである。 本書「ボクがライブドア社長になった理由」は、株式会社ライブドア代表取締役社長である平松庚三の自伝。率直に行ってしまえば、自伝としての面白さでは前代表取締役社長の 堀江貴文の本の方が面白い。 しかし、今のライブドアが必要としている長は、面白い自伝を書ける人ではない。面白いサービスを提供し維持する社員たちに、存分に力を発揮してもらう人である。平松庚三ほどの適任者が他に存在するだろうか。 ソニーを出て以来、平松氏は「外様社長」を歴任してきた。合州国では比較的よく見られるこのキャリアパ

Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての ｢それがないんだったら買わない｣機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——｢この1個だけ付け加えれば･･･きっとあの連中もおとなしくなってくれる｣ しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私

ドットインストール代表のライフハックブログ

（追記:「ホームページ」さまざまな用例集と「ホームページ」という日本語をめぐっても参照） 英語圏で「Home Page」と言っても、ブラウザのスタートページの事だと思われてしまう。数年前に調べたときは、Web siteの意味でHome Pageを使っている誤解した英語ネイティヴの人が居たりしたけど。そのときはその人は例外だという結論に成った。（ちなみに情報や指摘は何でも歓迎している。NASA Home Pageが誤解の発祥説とか、public_html/index.htmlのトップページをHomepageと呼ぶのが誤解された説。Web siteのことを総括して"Home page"と呼ぶのは英語としては若干間違ってはいない説等の話は読んだ事が有る） それに北米における「Home」も、日本の都市圏における「家」の感覚とは違い、応接間はゲストを招く公的な対外スペースというニュアンスも有ったりす

「現在のソフトウェアは規模が増大しています。建築で言えば、今までは一軒家の建築だったから腕の良い大工さんの能力でやっていけたけど、高層ビルは腕の良い大工さんが居るだけでは建てられませんよね。だから工学的な手法が必要なのです。」 えっと、理系の人間が、理系の人間に対して行う説明じゃないね。「A=>BだからA'=>B'である」と言いたかったら、AとBの関係がA'とB'の関係と同一であることをまず証明しないと。 ソフトウェア開発において、「建築」に相当する作業は、ビルド。英語ではどっちもbuild。どっちも、すでにちゃんとした設計書がある状況で、それを実際のモノにする作業。 「一軒家の建て方と高層ビルの建て方が違う」は、「小さいプログラムと大きいソフトウェアのビルド方法は違う」に相当する。小さいときはコンパイラを直接起動したらいいし、ちょっと大きくなったらmakefileを書けばいいし、もっと大

Ruby on Rails(以下Rails)は、Linux、Apache、Firefox等に続く、最も成功したオープンソースソフトウエアになりそうである。そして、それは同時に、これまでのオープンソースに無い、全く新しい質を持つ新しい現象の芽生えでもある。オープンソースという現象が、WikipediaやDiggの成功を通して、プログラマのコミュニティの外にインパクトを与えているように、Railsの中に芽生えつつある新しい「質」も集団知や新しい社会システムのデザインについて、ひとつの大きな参照点を構築するだろう。 その新しい「質」とはひとことで言って「スピード感」である。 成功したオープンソースソフトウエアは、全て、モジュールあるいはプラグインシステムを持っている。つまり、多様なニーズとシーズを持つ多数のプログラマがエコシステムを築くことが可能になっていて、それが特定の有力なニッチに最適化する

タイトルがうまく思いつきませんが、だらだらと思いつきを書きますよ？ 情報が自律している世界に経済があったらきっとこんな感じ。 構造 生産：全ての情報生産者 ↓ 流通：広告屋、アフィリエイト 高速道路：検索屋 ↓ 小売 百貨店：ポータル 専門店：コンテンツサイト 地域商店：個人サイト ↓ 消費 地域コミュニティ：CGM 消費者：個人 要素 商品：コンテンツ 対価：トラフィック パッケージ：RSS みたいな感じなんじゃないか。 鉄道（XML/EDIみたいな）を敷設する資本力がなくても、コンテンツをRSSというパッケージに梱包することさえできれば、あとはXMLが開拓してきた道を走る100万台のトラック（無数のWEBサービス）が適切な受け手に届けてくれる。そんなイメージ。金融とかメディアとかはメタのメタとか複雑になるから無視。 ＜こっから妄想＞ ろくに売り物作れてない生産者が「うちに直接足を運んで