2007-11-01 14:29 : 平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみた 最近、八角研究所で技術記事を書いているのですが、私が参加した 2006 年度下期未踏ソフトウェア事業（2006 年 11 月 ～ 2007 年 8 月末まで）の体験談を書いてみました。 未踏の体験談を書こうと思った動機について書きます。 私がお世話になった PM は東工大の千葉先生だったのですが、同じ PM 配下でも他の方は凄腕のエンジニアであり、能力的にも住む世界が異なるという感じでした。そういうエンジニアは目立つので、私は未踏のエンジニアというともの凄い凄腕ばかりを思い浮かべてしまうのですが、未踏ソフトウェア創造事業そのものは、適切な提案ができれば平凡なエンジニアにも門戸が開かれています。 というか、普通のエンジニアこそ挑戦すべき制度です。とはいえ、

「The Top Ten Subversion Tips for CVS Users」という記事がありました。 Subversionの開発を行っているGoogle社のBrian Fitzpatrick氏が書いているブログ記事のようです。 元々は2004年にONLampで発表されたものだそうです。 以下、要約です。 誤訳などの可能性があるので原文もご覧下さい。 1. ステータスを見るにはstatusを利用しよう CVSでは、手元のコピーと最新レポジトリとの違いを見たい場合、 cvs updateを使いますが、cvs updateをしてしまうと、違いを知ると同時に手元のコピーが最新の状態にupdateされてしまいます。 (-nを使わない場合。また、statusコマンドもありますがあまり使い勝手は良くありません。) Subversionでは、updateを行わずに状態だけを知る事ができます。 $

asahi.comの記事によると、12日に起きた自動改札機の障害は、無効カードデータの情報送信時に、境界バイト処理に失敗することが原因だったそうだ。 よくわからないのは記者の解説。意訳が入っているらしく数字が理解できないのだが、「85件増すごとに5件の割合で、余った2バイトの処理を忘れる」という引用があるので、ここの数字だけは表現が正しいと思われる。ちなみに、開発（納品？）元の日本信号からは、10月15日付けで簡単な報告が公開されおり、朝日新聞の記事はその詳細をインタビューしたものと思われる。 このバグ、どういう話だと思われますか？

古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

はじめに　シグナルについての解説最終回です。今回はシグナルを扱う上での注意点や、よりよい実装方法の提案、シグナルの未来等について説明します。過去の記事signalについて（前篇）signalについて（中篇） 5. 実装上の注意点　前回まで説明してきたとおり、シグナルは気軽に使うことができる便利なプロセス間通信です。しかしシグナルには、やってはいけないことや気をつけるべき点が多く存在します。以下、代表的な注意点を挙げます。5.1 最適化問題　volatileはそれほど使われない宣言修飾子ですが、これは最適化を制御する修飾子です。なぜこの修飾子がシグナルと関係あるのかについてですが、先にソースコードを示します。 /* 1. gcc -g -W -Wall signal_test_volatile.c -o signal_test_volatile 2. gcc -g -W -Wall sign

ソフトウェアの難読化に興味を持ったので、どういう手法があるのか調べてみました。 結構面白かったです。 この分野は勉強していくと非常に面白そうですね。 (メチャメチャ奥が深そうですね) 以下に、簡単な手法をいくつかピックアップしてみました。 様々な手法を組み合わせて、ぐちゃぐちゃの読みにくい出力を生成できるそうです。 また、自動的に出力をぐちゃぐちゃにするツールも色々あるようです。 名前マングリング 何をするかバレバレの名前をバイナリ中に残してしまうと、すぐに解析されてしまいます。 それを防ぐために関数名などをマングリングしてしまいます。 例えば、以下のようなコードがあったとします。 secret_key_funcという秘密鍵を扱う関数があるとします。 例えば、これをdefineでhogera()に変えてしまうと、何をしたい関数なのかが多少わかりにくくなります。 #include <stdi

@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ

はじめに　シグナルはUNIXなどのOSにおける非同期イベントを通知する仕組みですが、「最古のプロセス間通信」「SysV系とBSD系で動きが違う」「昔のシグナルを使うと汎用性が無くなってしまう」「スレッドと相性悪し」といった理由からか、私の経験上、業務系アプリケーションではあまり使われていません。たまに使っているものを見ると、誤った使い方をしているものが多かったりします。　ところがこのシグナル、いろいろ調べていくと意外と奥が深く、有用に使えるのに、以外と情報が少ないことがわかりました。　今さらな感もありますが、ここでは私が知っている事や、調べた結果、今までの経験から得た知識などをまとめてみたいと思います。　ただし、環境によって動作が違うことが想定され、また一部のプログラムは環境に対し重大な影響を与えてしまうものもあります。プログラム等の使用に際しては十分に注意して頂き、ご自身の責任の範囲で行

未だに半年前のエントリにブクマされるみたいなので、もう少しjavascriptについて書いてみる。 今回は大規模化開発におけるJavascriptの注意点とかそういうの。当てはまらない環境の方もいます。(しかも基本的な事だらけで大したことは書いてないです) ほぼリッチクライアントを主目的としたjavascripterとコードを対象とします。 どちらかというと、ライブラリを提供する側の視点から 1.ログを出力せよ あなたが書いたコードは遅い、と必ず言われます。なので言われる前から、自分の書いたコードの処理時間をログするようにしましょう。 次のような処理時間を計測するロガーを作ります。 var TraceLog = function (){ this.startTime = -1; var outer = document.getElementById('_outer'); if(oute