上司「Java書けるんなら当然JavaScript呼び出せるよね？さっさとやっておいて」 JavaからJavaScriptを呼び出す Java 6 からスクリプトAPIを通じてスクリプト言語を呼び出すことができる。Java標準でJavaScriptのエンジン Rhinoが組み込まれているので特にインストール作業やクラスパスを通すような作業なしにJavaScriptの呼び出しをすることができる。 import javax.script.*; public class Sample { public static void main(String[] args) throws ScriptException { ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEn

Javaのクラス宣言には5種類ある。 トップレベルクラス・ネストしたクラス・内部クラス・ローカル内部クラス・匿名クラス(無名クラスとも言われる)の5種類だ。 今回はこの5種類のクラス宣言のおさらい。 トップレベルクラス これは普段使っているクラス。拡張子が.javaのファイルを作り、そのファイル名とクラス名を合致させなくてはいけない。そのjavaファイルのトップレベルに位置する。 ネストしたクラス 「ネストしたクラス」(Nested class)とはクラスの中にクラスがネストしている状態。トップレベルクラスの内側にstaticキーワードをつけてクラス宣言を行う。 public class Outer { public static class Nested { } } このネストしたクラスは、トップレベルクラスと同等の機能性を持つ。 クラス名はOuter.Nestedという名前で扱われるが

前回でパフォーマンス計測に用いるタイマーについての理解を深めたので、やっとパフォーマンスの計測を始めることができる。 今回のテーマはJavaの文字列連結だ。タイムリーだね。 文字列連結についての基礎知識 Javaの文字列連結についての言語仕様まわりは Stringの連結はそう簡単なものではない - じゅんいち☆かとうの技術日誌 が詳しい。しかし、パフォーマンス計測がなっちゃない。パフォーマンスの計測はそう簡単なものではない。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての*1。 そんなわけで、計測方法を工夫してみよう。二重ループとし、内側を1000回、それを500回繰り返す。ループが1回まわる間に1回ずつSy

ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクションAPIが挙げられる。java.util.Listとかjava.util.Mapとかのデータを格納するタイプのユーティリティクラスのことだ。 2004年にJavaのバージョンが5.0となるまでは、Javaにはジェネリクスの機能はなかった。なので、Listにデータを格納し、取得する場合は List list = new ArrayList(); list.add("hello!"); String str = (String) list.get(0); といったソースコードになる。 add()の引数はObject型で宣言されており、どんな参照型でもadd()することができた。 get()の戻り値もObject型で宣言されておりキャストが必要だった。このキャストはプログラ

Javaのデバッグをしていて、ステップ実行中にステップインを繰り返したらソースコードのないところに行き当たったことがあるだろう。あるいはEclipseでF3キーでクラスやメソッド・フィールドの宣言元を辿っていってソースコードのないところに行き当たったことがあるだろう。 Eclipseの場合、"Class File Editor"というものが開く。そこにはJavaのバイトコードのニーモニックがズラズラと並んでいて、「これは読めないや、ワケが分からない」と投げ出してしまったりしていないだろうか。 怖がることはない。ちょっとコツを掴めばすぐに読めるようになる。 Class File Editorの開き方 自前のJavaクラスの場合、ビルドして出来上がったclassファイルを開く必要がある。"Package Explorer"だとclassファイルは隠されていて見えないのでWindow -> Sh

詳しすぎる詳細設計書 - SiroKuro Page とか 詳細設計書に何を書くべきか？ - Sacrificed & Exploited 関連。 ソースコードと１対１で対応するような仕様書を書いてはならない理由。 日本語は読み上げれるかもしれないが内容を理解できるとは限らない 日本人なら日本語で書かれた相対性理論の教科書を読み上げることはできる。しかし相対性理論を理解できるというわけではない。 日本語は論理演算を表現するのに向いていない OR と XOR の区別がつかなかったり、括弧による演算順番の指定がやたら面倒くさくて見通しの悪いものになったり。 日本語は例外処理を記述するのに向いていない 法律の例外事項とかの読みにくいことと来たら。 日本語はシンタックスハイライトされない 「を」とか「は」とかカラフルになっても嬉しくないけど。 日本語はコンパイラによる静的チェックができない Wor

先のコードコメントに書くべきは「意図」 - プログラマーの脳みその関連でソースコードの心脳問題という話をしよう。 心脳問題というのは脳という分子機械が、いかにして心を持つのかという哲学のような脳科学のようなテーマの話題。*1紀元前にプラトンのイデア論にて意識とは何かという基礎命題は与えられていたわけだけども、古代には哲学の範疇に収まっていた。 ところが現代のコンピュータサイエンスでは、脳みそのシュミレーションがかなりの規模でできるようになってきていて、工学的に脳を作れる時代が近く迫ってきている。2007年の記事になるが 今回、現在世界最速の性能を持つ「BlueGene L」スーパー・コンピューター上に、マウスの脳の半分にあたる800万のニューロンの働きを再現させる事に成功したそうです。 使われたのは、それぞれが256MBのメモリを使用する、4096台のプロセッサを持つ「BlueGene L

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

スケジュールについてPMが知っていなければならない、絶対原則 - Fight the Futureを見て自分の体験を振り返ると、確かに数字の扱いがぞんざいな人が多いなぁと思う。 日本の大学進学率は40%以上あるわけで、高等数学を、あるいは工学を学んだ人は大手企業の社員には相当数いるはずなのだが。SIerって本当に大丈夫なのか？と思う事例も数ある。 ITの現場ではバグの発生数などを統計から出した指標と言うのが結構使われているのだけど、この適用の仕方が酷い。「システムの規模感」というのをどうやって測るかというのはIT業界の悲願とも言えるもので、この見えないパラメータに現場は踊らされている。正しく算出できるなら、どれだけデスマーチが減ることか！ 現場でよく用いられる「システムの規模感」とそれにまつわる各種指標と言うのは、ソースコードの行数を元に算出した数字だったりするわけで、相当に誤差が大きい。

「属人性？あれでしょ、その人じゃないとできないって奴」 じゃぁ問題。個人経営の病院があって、医者は一人しかいません。診察や医療行為は属人性が高いでしょうか？低いでしょうか？ 「その医者がいないとできないんだから属人性が高いんじゃないの」 違うんだよね。この場合は高いか低いかわからない。属人性ってのはそういう「その人じゃないとできない」じゃないんだよ。 「だって代われないじゃん」 いや、医師免許をもってる人なら代れるよ。属人性ってのはその仕事をやる技能や資格を持っているかどうかって話じゃないんだ。仕事のやり方が標準化されているかとか、マニュアル化されているかとか、引き継ぎできるかどうかって話題なんだよ。 「資格が必要でも引き継ぎができるなら属人性は低い？」 そうそう。 ソフトウェア開発の属人性の誤解 属人性の排除が狙うところってのは「その人しかやり方を知らないよ、秘密だよ」って作業をなくす話

JavaはCより速かった — ありえるえりあの実測データを興味深く眺めていた。 このあたりのジャンルは僕は専門ではないので聞きかじりになってしまうのだけど、Javaのホットスポットの場合、実行されているCPUなどの情報を元に、環境に合わせた最適化ができるというメリットがあるらしい。つまり、CPUの種類を見て並列処理系の命令セットを活用したりだとか、そういう最適化。コンパイルによってバイナリコードを作るC言語のような言語だと、コンパイル時でどのCPUで動くかなんて決定できないことが多いから最適化しにくい。 あとは、C言語のalloc - freeによる動的メモリ確保の処理速度が遅く、Javaのnew - GCによるメモリ管理のほうがパフォーマンスが良いらしいと聞く。 そんなわけで、状況によってはJavaはCより速いらしいとは聞いているのだけど、自分で計測してそういうデータを出したことがないの

プログラムにおける型システムってのは数学・論理学の型理論を基盤にしていて、抽象的なもやもやとした代物。この型システムの理論を現実に実装したものとして、多様なプログラム言語が存在するわけだ。 鶏と卵という話だとどっちなんだろう。実装が先でそれを理論としてまとめたって感じなのか、理論がまず考えられてプログラム言語が実装されたのか…。最初のプログラム言語というと1954年に登場したFORTRANで、IBMのジョン・バッカス氏*1によって考案された。FORTRANにはいくつかの数値型がある。この頃に型システムの体系的な理論ができていたとは思えないから多分、実装が先行なんだろうな。 理論としての型、そのJava実装のクラス 型システム(type system)でいう型(type)は型理論に基づくわけで、数学的な抽象概念に近い。例えば僕らが日常生活で数学的概念である1/3という値を厳密に使うことはない

ソフト開発の効率化は会計処理改革から（修正版） - プログラマーの脳みそ 経営者が自社ライブラリの開発に予算を割きたくない理由 - 売り切れました SIerがソフトウェアの再利用ができない理由 - プログラマーの脳みそ 採算のとれないライブラリに客が金を払うのか？ - 売り切れました の一連の議論の続き。 ライブラリ化の価値は？ 実際、SIをしながら共通利用できる部品ができあがっていき、最終的にそれが単体で製品となることはある。 しかしそれを計画的に行おうとすると、結局はパッケージソフト開発と同じようなリスクを背負うことになる。　しかもマーケットは「自社開発プロジェクト」にしかないとなると、そう簡単にＧＯが出せるものではない。 プログラマーにとっては当然、経営者にとってもハイリスクローリターンだ。 採算のとれないライブラリに客が金を払うのか？ - 売り切れました ここは意見が衝突する部分だ

高機能なIDEを使え、という話題になった場合にはだいたい決まった反論がある。それは確かにIDEの欠点の部分で、要するにIDEを使うかどうかは、そのメリット・デメリットを秤にかけて傾いた方を選ぶべきだ。 私は仕事では主にJavaの開発をやっているのだけど、どうにもEclipseの機能を使えていない人が多い。もちろん、私もそれほどEclipseをマスターしているというわけではないのだけども、それでもテキストエディタでの開発に戻らないだけの十分な理由がある。そこを伝えたかったのがEclipseからテキストエディタに戻れない10の理由 - プログラマーの脳みそだ。 こうした大きな恩恵があるにも関わらず、「そんな恩恵があるなんて知らなかったから」という理由でEclipseを使わないなんて選択をして欲しくない。Javaの父たるジェームズ・ゴスリン氏もIDEの重要性を訴えている。もっとも彼が推すのはNe

Javaでストリームの後始末などをする場合の話。 二重tryブロックになるととたんに見通しが悪くなる…。完璧な例外処理の例を誰か教えてほしい。 多重tryブロックの除去 - @katzchang.contexts と語ったのは、完璧な例外処理のような視点でのぼやきだった。*1finally中に例外が発生するようなケースでは元の例外をfinallyで発生した例外が隠蔽してしまう。このあたりの情報をどのように繋ぐべきなのだろうか？リンク先の考察では面倒極まりない例外処理コードを書いているのだけど、通常どのぐらいのところで妥協していいのだろうか？ 誰か答えを教えて欲しい。 *1:今見ると二重try節での例外を例外チェーンで繋ぐというのがそもそも目的外の例外チェーンの使い方な時点で微妙なやり方に思える。caused byに出てきてもなんか違うように思うんだがどうなんだろう？

Leo's Chronicle: 知性が失われて初めて言語が「亡びる」あたりを読んで、ちょっと違うんじゃないのと思った点を書いてみよう。 まず、論文の記述の話で言えば、流暢な表現は必要ないと思っている。格好悪くてもいいから意味が正確に伝わることが重要だ。査読はそういう視点で行われるべきだ。これが文学の世界なら中国人ながらに日本で芥川賞を受賞した楊逸氏が、前回の落選理由として「日本語表現が拙いから」と言われたのも仕方あるまいとなるわけだが。 その論旨の部分に対する査読という、論文特有の事情を鑑みれば、元記事の 別に難しい表現にこだわらなくても論理通ってれば意味を伝える表現は出来るだろうし、それが出来るのが科学研究分野なんだし。 いいじゃん、別に"Because"や"But"が何回続いたって。 "That's why..."とか"However..."を使わなくたって。意味通れば。 関係代名詞

ジェネリクスとは何か、ということをちょっと考えていた。以下、頭の中の思考をそのまま引っ張り出した文章なので読みにくいかもしれないが勘弁してほしい。 メソッドのI/Oに対して、あるプレースホルダを置き、そのメソッドを使う側でそのプレースホルダの部分に対してのキャストを漏れなく行ったのだとしたら、それはジェネリクス足りうる。 このメソッドを使う場所を漏れなく、というのはアスペクト指向だから、アスペクト指向が実はジェネリクスの要件ではないかと着想した。 さて、単にメソッドのI/Oつまるところ、引数と戻り値の型だけ合わせればよいのであれば、さほど難しいわけではないが、JavaやC#のジェネリクスはメソッドの集合であるクラスというものに対してジェネリクス型パラメータを与えることができる。 これは、ある種のメソッドの集合を考えて、プレースホルダが置け、アスペクト指向により該当箇所を網羅すれば済む。 さ

株式会社マジカジャパンの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ） 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - yvsu pron. yas あたりの話。 自分は地方の零細の下請け会社なわけなんだけど、自分の判断で契約を行える自由を持っている。かといって、契約内容については、実はそれほど自由には決められないものだ。 というのは、こっちの話ではなく、相手側の話なのだ。中規模以上の会社と契約しようとすると、おおむね定型の契約方式のいずれかを選択、変更可能なのは一部の数字だけ、ということが多い。 フリーエンジニアになってぶち当たる壁 IT関連と言うのは独立が非常にしやすい。設備投資などがほかの業種に比べ圧倒的に少ないから、自分の技術力を買ってくださいと個別交渉することさえ出来るなら即刻独立することができる。 フリーの身に