せっかく言及頂いたのでお礼ついでにエントリー。 id:gamellaの鋭い指摘にはもっと多くの人が耳を傾けるべき。 「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」を指向したい - Future Insight 日本にマッチするのは「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」なのだと思う。 僕の立場はこれとほぼ同じですが、「日本の技術力が足りない」というところはもう少し精確に説明したほうがよいですね。 ちょっと紹介したいのが下記のNYTimesの記事。 Silicon Valley Hiring Perks: Meals, iPads and a Cubicle for Spot Then there are salaries. G

プログラムを書いているとき、コードの量がどんどん増えていって規模も内容も訳が分からなくなってしまうことを俗に「スパゲッティ」と言ったりしますが、まさにその状態を視覚化したインフォグラフィックです。ApacheやPythonなど著名なオープンソースソフトウェアについてのものばかりなので図を見て「あーやっぱり」と思うことがあるかもしれません。 これらはカリフォルニア大学デービス校の研究者、マイケル・オガワ氏が制作したもの。それぞれのラインは開発者、横軸は時間を表し、上下のラインが近いほど、関係の深いコードの開発を行っていることを示します。 また対応しているブラウザでは、それぞれのラインの上にカーソルを置くとハイライトされます。 以下、クリックすると元のサイズのSVG画像が表示されます。 Webサーバーのデファクトスタンダード、Apache。最初の2年間はほぼドキュメント作りに費やされ、なかなか

自分のブログに書こうとも思ったのですが、会社が特定されてしまいそうなのでここに書きます。どこかに書かなければならないと思ったのは、この事実を誰かに伝えなければならないと思ったからです。 私が勤めていた会社はシステム屋さんです。2タイプの職場があって、一つはお客に注文を受けてシステムを開発してリリースして終了。もう一つはお客の会社に居候させてもらってシステムの維持管理をするというものです。私は後者のほうです。 お客は工場も複数構える結構大きな企業で、様々なプラスチック製品やコンピューター部品を作るところであります。日本だけじゃなくて海外とも取引があったと思います。 1. コンピュターシステムの入れ替えを要求されるこの不況のなか、様々な設備投資の資金を抑える事を進めていた中で、システムについても、もっとコストの安いものをと以前より私の会社の上役達と試行錯誤を繰り返してきたのですが、そもそものお

@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

家電通販最大手のジャパネットたかた。同社における開発言語のメインはCOBOLだ。通信販売で取り扱う商品は日々追加され、客先でのセッティングといった付帯サービスも多様化している。情報システムを統括する星井龍也専務執行役員は、「こうした状況変化に迅速に対応するためには、COBOLの高い生産性が必要だ」と語る。（聞き手は井上英明＝日経コンピュータ、写真は林田大輔） メインの開発言語にCOBOLを据えていると聞く。 2008年1月、基幹システムをメインフレームからUNIXサーバーにオープン化するプロジェクトを開始する際に、「当社はメインの開発言語をCOBOLとする」と宣言しました。26人いる情報システム部員の全員が、COBOLを読み書きできるようにしています。それまでは、COBOLを読み書きできる部員は3人だけでした。 当社のシステムにおいて基幹となるのは、販売管理システムです。お客様からの注文や

日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問　日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海

LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 なお、Gitの基本的な考え方や使い方については分散バージョン管理システムGit入門でも紹介しているので、そちらも参照してほしい。

金融機関のシステム子会社に勤める高山真一さん（仮名）は，親会社の基幹系システムをオープン化するプロジェクトに，価格交渉の担当者として参加していた。このプロジェクトでは，親会社の担当者による強硬な値下げ要求により，数十人ものITエンジニアが苦しまされた。 「機能追加分は払わない」 親会社のシステム企画部門に所属するこのプロジェクトの担当者から，システムの概要仕様書を提示された。その仕様書に基づいて見積もることを求められ，約3億円（本誌推定）と見積もった。悲劇の種はこの時点で既にまかれていた。後から考えれば，この概要仕様書は，どうやらユーザーへのヒアリングを十分に行わずに作成されたものだった。それに基づいて見積もった金額が基準となってしまい，その後の不当な値下げが要求される事態を招くことになった。 概算見積もりの後に機能を詳細に検討すると，概要仕様書にはない，必要な機能が次々と判明する。精査す

僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ

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

分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理

友達から聞いた話だけど来年春に出る大作が相当ヤバイことになってるらしい。 いわゆる友達は開発下請け会社で働いていて、誰でも知っている大作ゲームを作っている。 どのタイトルかは言えないが聞けば誰でも知っているような有名作品だ。 始めて聞いた時は驚いた。子供の頃ずいぶん遊んだものだったからだ。 だがあまり開発は順調ではいらしい。デスマーチっていうあれがあるのは知ってたから、忙しいんだなという程度に聞いていたがじっくり話を聞くととんでもないことになっているらしい。 原因は色々あるらしく誰が一番悪いとは言えないみたいだ。 現場にやる気がないのだけは真実らしくて、それは一番偉いクリエイターが気まぐれすぎて下請け会社の作業がストップしたことがあるからだと言っていた。 そして下請け会社は最初に大作を引き受けた時とは段違いに大きな会社になっていたので、 自分の会社だけで作るソフトで人気作品が何本もできてい

東武百貨店は2007年10月2日、約20年ぶりとなる基幹系システムの全面刷新を完遂した。費用は約8億円。構想時は“相場”から見て、その倍はかかる規模だった。業務ごとにシステムの特性と停止時の影響度を調べ、リライトか再構築かを見極めた上で、13社のベンダーから提案を募った。開発開始から稼働まではわずか1年半。情報システム部の人材育成でも大きな成果が得られた。 「本当に予算内で基幹系システムを全面刷新できるのか」。東武百貨店の情報システム部、葛馬正記部長は、ベンダーからの提案書が出てくる間、じりじりしていた。相場の半分といえる低予算を前提に綿密なRFP（提案依頼書）を作ったが、自社だけでなく同業種でも前例がないため、いまひとつ自信を持てなかった――。 それから1年半後の2007年10月、予算通りの費用と期間で、新たな基幹系システムがオープン系プラットフォーム上で動き出した（図1、2）。売り上げ

プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら