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

近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読

少しご無沙汰しています。 今回からまた新しいシリーズです。ソフトウェアに関係する事柄のあれこれについて書いてみたいと思います。3回程度の予定です。 今回はコーディング規約についてです。コーディング規約がどんなものかはプログラマやSEなどを経験していれば知らない人はまずいないと思います。会社としてきちんとドキュメントになっているところもあれば、部や課、プロジェクト単位で適用している所もあるようです。 ただ、わたしの経験では、なぜか、なかったところの方が多かった気がします（気がするというのは実際はあったが見たことがなかっただけかもしれないので。もっともそれじゃないのと同じですが）。 現在のわたしの状況に関しては、「なかった」ので、わたしが作ってメンバーに周知しています。わたしが作るコーディング規約に関しては基本的にA4用紙に1枚程度の量で、そんなにきつく縛っていません（たぶん）昔ほどコーディン

わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない！」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ

この場合に、たとえば「9999」と記入した回答があったらどうしましょう。回答者は1億円以上の年収があるので、こう表現したのだと思います（1億円を超える場合に、回答者を悩ませる点でもこの自由記入は、あまり良い例とは言えませんが、それは今回置いておきましょう）。 この場合は、この質問のこの回答だけを「外れ値」として集計から除く処理を行うという判断をすることがあります。世帯年収の単純平均を算出すると、この回答が平均値をかなり押し上げてしまうからです。 年収などの場合は、その回答の分布はなだらかな山の形を形成することが多いのですが、分布から極端に離れた値にごく少数の回答が存在することがあります。これを異常値として排除するのです。科学の実験などでもこういった処理を行うことがあります。 普通の調査では、中央値や最頻値を併用するとよい全体を代表する値という指標はいくつかあります。平均値は最も代表的な指標

不具合の追跡プロセスはソフトウェア開発の下流工程では非常に重要なもので、それはそのままソフトウェア開発の下流工程を規定するものといっても過言ではありません。不具合は、一般に開発者とQAの間で、不具合報告書（PR：Problem Report）をやり取りしながら管理することになります。今回は、不具合の状態と処理方法に注目し、不具合を追跡するプロセスについて説明します。 不具合とは ソフトウェアが意図もしくは期待したとおりに動作しないことを指して不具合といいます。面白いことに、ソフトウェアの「不具合」にはいろいろな別名があります。 不具合 障害 欠陥 故障 不備 バグ エラー 仕様 これらはすべて、同じソフトウェアの「不具合」を指す用語として使われることがあります。ただし、ドメインによっては、ソフトウェアの不具合の種類により、これらの別名を使い分けることもあります。仕様どおりに実装できていない

「よくわかるC言語」，今回は連載3回目です。1回目はBorland C++コンパイラ＊1のオプションを指定して，C言語のコードの1行から複数のアセンブリ・コード，つまりマシン語が出力されることを確認しました。2回目は浮動小数点数の計算に誤差が出る理由などを説明し，変数の性質を学びました。さて今回は，プログラムの構造を説明し，「C言語のプログラムはどのように書けばよいのか」を大まかに理解してもらうことを目標にします。カメラのズームをいったんぐっーと引くように，ワイドな視界でC言語のプログラミングを眺めてみましょう。 基本は構造化プログラミングにあり 皆さんは「構造化プログラミング」という言葉をご存知ですか？ 1960年代後半，エドガー・ダイクストラ＊2が中心となって提唱したプログラミングの考え方です。現在，主流となりつつあるオブジェクト指向プログラミングも，実は構造化プログラミングをベースと

Part1では，プログラムをかたち作る要素について，「段取り」のメタファーを用いてプログラミング言語の種類にできるだけ左右されない基礎を説明します。 まず，私たちが作ろうとしているプログラムの全体像を，ざっくりとつかみましょう。今までコンピュータを使っているだけだった人が，コンピュータ上で動くプログラムを作ろうとすると，「プログラムって何？」「どの部分を作ればいいの？」と戸惑うと思います。 そこでちょっと視点を変え，プログラムとコンピュータを切り離して考えてみましょう。私たちは毎日，いろいろな物事をうまく進めようと，アタマの中で「段取り」を組み立てています。そうした段取りを，アタマの中からうまく取り出し，コンピュータに組み込める形に整えたもの。それがプログラムである，と考えてみるのです。 うまく段取りすれば物事が効率よく進みますが，段取りがマズいと無駄な労力がかかります。プログラムも同じこ

コン基礎の教え方の宝庫（7） 堅苦しいアルゴリズム研修を盛り上げる 私はこうやって教えています～難解な技術をわかりやすく教えるコツ～ 新人研修で「アルゴリズム」を取り上げるIT企業が多くあります。聞いただけで逃げ出したくなるような堅苦しいテーマです。講師は、何とかして講座を盛り上げなければなりません。講座の導入部、楽しく学べる実習、ゴールとする課題、提出物など、私の経験上うまくいった方法を紹介しましょう。 実習でアルゴリズムとは何かを伝える 新人研修では、実習を多くすると盛り上がります。アルゴリズム研修の導入部でアルゴリズムとは何かを伝えるときも、実習を行うことをお勧めします。フローチャートの基本的な図記号を教えてから、身近なことをフローチャートを描かせます。たとえば、起床してから会社に来るまでの手順、カレーを作るときの手順などをフローチャートに描かせるのです。 単にフローチャートを描かせ

素朴なBigtable、できること できないこと：分散Key-Valueストアの本命「Bigtable」（2）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 あまりにもRDBとは異質な「Bigtable」 前回の「もう1つの、DBのかたち、分散Key-Valueストアとは」では、連載第1回目として、クラウドコンピューティングにおける新しい潮流である「リレーショナルデータベース（RDB）から分散Key-Valueストア（分散KVS）への移行」が、どのようなパラダイムシフトをもたらすのかを解説しました。今回からは、グーグルが運用する代表的な分散KVS「Bigtable」の内部構造を紹介し、クラウドの本質をより深く掘り下げます。 前

NTTデータは2010年10月29日、米国のITサービス企業「キーン」（写真）の買収について、キーンならびに同社の株主代表と合意したと発表した。買収額は非公表だが1000億円強とみられる。買収完了時期は2010年12月を予定している。 NTTデータによれば、キーンは「総合的かつグローバルに提供しているITサービス企業」である。アプリケーションの開発・保守に加え、独SAPや米OracleのERP（統合基幹業務システム）パッケージの導入サービス、インフラ管理サービス、BPOサービスなどを提供しているという。 キーンの顧客は、公共系や金融系、製造企業や製薬企業など幅広い。商圏の中心は北米だが、欧州やアジアに及ぶ顧客を持つ。2009年12月期の売上高は約654億100万円。従業員1万2500人のうち、半数の6900人はインドのオフショア開発センターなどアジア圏で勤務する。設立は1965年で、本社は