Javaパフォーマンス計測 そんなタイマーで大丈夫か？ - プログラマーの脳みそ
駄目だ。大問題だ。 long t1 = System.currentTimeMillis(); long t2 = System.currentTimeMillis(); System.out.println(t2-t1); 結果はなんとでるか？ 99.9%以上の確率で0が表示される。そもそもSystem.currentTimeMillis()は時刻をミリ秒で返す。1行のプログラムを実行するのに1ミリ秒もかかってたら、たかだか1000行分動いただけで1秒かかってしまう。今のコンピュータはそんなに遅くない。 そもそもドキュメントをちゃんと読むと ミリ秒で表される現在の時間を返します。戻り値の時間単位はミリ秒ですが、値の粒度は基本となるオペレーティングシステムによって異なり、単位がより大きくなる場合があります。たとえば、多くのオペレーティングシステムでは、時間を 10 ミリ秒の単位で計測します
プログラマの値崩れ - プログラマーの脳みそ
pixivと仕事の値崩れと - プログラマーの脳みそは「絵を描く」という仕事の値崩れとそれを防ぐにはという話題だった。僕はプログラマなので、当然ながらプログラマの仕事の値崩れについて考えを巡らせる。 需要と供給 プログラマというのは人材不足だ。そして頭数は余っている。どういう事かといえば、プログラマの質というのは総じて低いのだ。 SI業界(注文に応じてシステムをフルオーダーで開発する業態)では、「プログラマ≒プログラムを書く人」「SE = システムエンジニア ≒ お客さんの要望を取りまとめる人」ってカテゴライズがされてて、プログラマ ＜ SE という扱いになっていることが多い。 SI業界で必要とされるプログラミング技能は総じて低い。というか、業務用のプログラムってのはその8割はたいした技能が必要ないプログラムで出来ているといっていい。人手がかかり面倒くさい作業を人海戦術でこなしている、とい
アーキテクトと変態は紙一重 - プログラマーの脳みそ
「卵をテーブルに立てることができますか？」「そんなのできるわけがない」「こうやるんですよ。グシャッ」「そんなの俺でもできる！」 コロンブスの卵のような話は多々あって、工学の成果の多くはそういうものかもしれない。「こうやればできる」を探し出すまでが大変で、見習って真似るのはよほど簡単。よほど簡単とはいうものの、それでも10年ぐらいエンジニアやっててもなかなか到達できなかったりする世界だったりするわけだ。道を開いた人はまさにニュートンの言うところの巨人で*1そうした偉大な先人の肩に乗って僕らは若くして多くの知見を得られ、多くの技能を身につけることができる。 エンジニアたらんとするなら、やはり何かを切り開きたいものだ。自分は巨人ではないけれども、巨人の真似事をしようと悪戦苦闘の日々である。アーキテクトを志したからには背負わねばならない業の様なものだ。 アーキテクトの発想 実業務では日々いろいろな
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
Java変態文法最速マスター - プログラマーの脳みそ
Java基礎文法最速マスター - いろいろ解析日記をリスペクト。 Javaの変態文法・技法一覧です。Javaの基礎をある程度知っている人はこれを読めばJavaの変態をマスターしてJavaを書くことができるようになっています。簡易リファレンスとしても利用できると思いますので、これは足りないと思うものがあれば教えてください。 1.基礎 エンクロージング型内部classの作成 外部classのインスタンスに紐付くインスタンスを生成します。外部クラスのインスタンス - 内部クラスのインスタンス間に、クラス - インスタンスのような関係を持たせることができます。 public class Outer { public class Inner { } } というようなクラスを作った場合、 Outer o = new Outer(); Inner i = o.new Inner(); となります。new
契約書に捨印を押す - オブジェクト指向と型システムの狭間で例外を考える その2 - プログラマーの脳みそ
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みその続き。 僕は不勉強なのでメイヤー氏の思想というものをそれほどトレース出来ていない。だから開放閉鎖原則についての哲学のようなもの、というのはデザインパターンから嗅ぎとったもので、誤りがある可能性が高いということをあらかじめ断っておく。間違いは指摘してもらえると嬉しい。 検査例外は開放閉鎖原則に反しない まず、検査例外は発生したその場、もしくは直接の呼出し元で処理しない限り、throws に記述せざるを得ない。 そうしない場合、より上位層の throws を追加する必要が出てくる。このような追加、もしくは変更は、中間のクラスの再リリースという手間も必要となる。 これは、明らかに開放閉鎖原則に違反する。 例外について色々と考えてみた - ぐるぐる～ 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」につい
日本語でプログラミングしてはいけない理由 - プログラマーの脳みそ
詳しすぎる詳細設計書 - SiroKuro Page とか 詳細設計書に何を書くべきか？ - Sacrificed & Exploited 関連。 ソースコードと１対１で対応するような仕様書を書いてはならない理由。 日本語は読み上げれるかもしれないが内容を理解できるとは限らない 日本人なら日本語で書かれた相対性理論の教科書を読み上げることはできる。しかし相対性理論を理解できるというわけではない。 日本語は論理演算を表現するのに向いていない OR と XOR の区別がつかなかったり、括弧による演算順番の指定がやたら面倒くさくて見通しの悪いものになったり。 日本語は例外処理を記述するのに向いていない 法律の例外事項とかの読みにくいことと来たら。 日本語はシンタックスハイライトされない 「を」とか「は」とかカラフルになっても嬉しくないけど。 日本語はコンパイラによる静的チェックができない Wor
コードコメントに書くべきは「意図」 - プログラマーの脳みそ
2.トリッキーな実装 ソースを読んだだけではすぐにわからないようなアルゴリズムを採用している場合や、使用しているライブラリのバグ回避のための特殊な処理を行っている場合、または他の人が見たときや自分が数年後に見た時に「なぜここでこんなことを？」と感じる可能性がある場合にはソースコードにコメントを追加するべきだ。これは言わばトリッキーな実装である。 ソースコードのコメント率は20%を切ることが望ましい : 小野和俊のブログ 私はこの部分にはもうちょっと汎用的に「意図」を書くべき、とすることを提案しよう。*1 トリッキーな実装というのは、「普通」ということが分かっていて初めてトリッキーかが分かる。普通か、トリッキーか、というのは時代背景*2というかハード的な制約も関係するだろう。常識は移ろいゆく。本人がトリッキーではないと確信して書かれるコードと、トリッキーなコードとの線引きはどうしたらよいのだ
java-ja15回で考えたこと - プログラマーの脳みそ
イベントレポートとかは他に挙げている人が多いので割愛。ここではjava-ja15回で挙がったネタとかで想起されたことを書くことにしよう。プログラマの馬鹿話ってこんなんだぜ的な。 宮本武蔵はアジャイラー説 宮本武蔵が五輪の書でアジャイルを説いているという説。僕は五輪の書を読んでいないので判断は保留。先物相場が世界に先駆けて日本で生まれていたみたいな突飛な面白さがあっていい。会場でも賛否両論と言った感じの反応。 武蔵の肖像画が理解できない人は少なかったみたい。Seasarカンファレンスでネタを飛ばしたら全然理解してくれなくて会場が凍った話とか。たとえ話を出してたとえをみんな知らなかったら確かに泣ける。@cactusmanが今日はスーツコスプレですとか言って会場を凍らせた話も。僕らがそもそも少数派だから会場でネタを言う時は身内で通じたからと言って安易に語ってはいけないというありがたい話。 @t_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
