二重ループのバグ - プログラマーの脳みそ
太郎くんはJavaでコマンドラインから渡された英文字("zero", "one", "two", "three")をアラビア数字(0, 1, 2, 3)に置き換えるコードを書いた。 public class Sample { static String[] values = {"zero", "one", "two", "three"}; public static void main(String[] args) { // \u000aHoge hoge = Hoge.outerLoop;outerLoop:do{ switch(hoge) {case outerLoop:for(int i=0; i<args.length; i++) { // 引数ループ for (int j=0; j<values.length; j++) { // 照会文字列ループ if (values[j].e
Java 30byte FizzBuzz - プログラマーの脳みそ
なっちゃん（以下な）「なんかさー。タイトルが無理すぎない？」 ぎぃくん（以下ぎ）「まあ流行りだからね」 せっちゃん（以下せ）「流行りって言ってもFizzBuzzを３０バイトで - Togetterが1/24だし、1週間経ってるけど。どちらかと言えばオワコン？」 な「まあまあ」 ぎ「とりあえず、どのぐらい無理っぽいか見てみるかい？」 普通のFizzBuzz せ「じゃぁまあ普通のFizzBuzzをみてみましょ。」 な「FizzBuzz Javaでググって…これかな？ Fizz Buzz - Semicolonless Java」 public class FizzBuzz { public static void main(String[] args) { for (int i : new int[] { 0 }) { while (++i <= 100) { if (i % 15 == 0)
再帰的ジェネリクスの代入互換性 - プログラマーの脳みそ
Javaのややこしいジェネリクスの話をしよう。*1 再帰的ジェネリクス クラスHogeがあったとして、型変数Tを取る。 public class Hoge<T> {} このHogeの型変数Tがextends Hogeとすると public class Hoge<T extends Hoge> {} すると、T extends Hoge の Hoge が raw型だと警告される。Hogeの<>の部分にHoge型を継承した型を指定しなければならない。ここで型変数T が extends Hogeだったので、丁度いいからT型をおさめよう。 public class Hoge<T extends Hoge<T>> {} これは再帰的ジェネリクス(recursive generics)と呼ばれているようだ。 追記：僕は勝手に自己言及型ジェネリクスなどと呼んでいた。情報サンクス！併せてタイトルなども表現
Javaジェネリクス再入門 - プログラマーの脳みそ
ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクション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型で宣言されておりキャストが必要だった。このキャストはプログラ
プログラマの値崩れ - プログラマーの脳みそ
pixivと仕事の値崩れと - プログラマーの脳みそは「絵を描く」という仕事の値崩れとそれを防ぐにはという話題だった。僕はプログラマなので、当然ながらプログラマの仕事の値崩れについて考えを巡らせる。 需要と供給 プログラマというのは人材不足だ。そして頭数は余っている。どういう事かといえば、プログラマの質というのは総じて低いのだ。 SI業界(注文に応じてシステムをフルオーダーで開発する業態)では、「プログラマ≒プログラムを書く人」「SE = システムエンジニア ≒ お客さんの要望を取りまとめる人」ってカテゴライズがされてて、プログラマ ＜ SE という扱いになっていることが多い。 SI業界で必要とされるプログラミング技能は総じて低い。というか、業務用のプログラムってのはその8割はたいした技能が必要ないプログラムで出来ているといっていい。人手がかかり面倒くさい作業を人海戦術でこなしている、とい
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
アーキテクトと変態は紙一重 - プログラマーの脳みそ
「卵をテーブルに立てることができますか？」「そんなのできるわけがない」「こうやるんですよ。グシャッ」「そんなの俺でもできる！」 コロンブスの卵のような話は多々あって、工学の成果の多くはそういうものかもしれない。「こうやればできる」を探し出すまでが大変で、見習って真似るのはよほど簡単。よほど簡単とはいうものの、それでも10年ぐらいエンジニアやっててもなかなか到達できなかったりする世界だったりするわけだ。道を開いた人はまさにニュートンの言うところの巨人で*1そうした偉大な先人の肩に乗って僕らは若くして多くの知見を得られ、多くの技能を身につけることができる。 エンジニアたらんとするなら、やはり何かを切り開きたいものだ。自分は巨人ではないけれども、巨人の真似事をしようと悪戦苦闘の日々である。アーキテクトを志したからには背負わねばならない業の様なものだ。 アーキテクトの発想 実業務では日々いろいろな
メソッドの最後でしかreturnを書いてはいけない時 - プログラマーの脳みそ
柴田 芳樹 (Yoshiki Shibata)：So-netブログに出てくる、「メソッドや関数の最後でしかreturn文を書いてはいけないと、プロジェクトの標準として何らかの方法で強制」された場合、機械的な書き換えを行うことで対応することが出来る。 まずは戻り値がvoidのメソッド。条件分岐などでreturnしているようなケース。 public void hoge1a(boolean b) { if (b) { System.out.println("true"); return; } else { System.out.println("false"); return; } } これはラベル付きブロック+break文に置き換えることで単純に置換できる。 public void hoge1b(boolean b) { ret:{ if (b) { System.out.println("t
Javaバイトコードの読み方 - プログラマーの脳みそ
Javaのデバッグをしていて、ステップ実行中にステップインを繰り返したらソースコードのないところに行き当たったことがあるだろう。あるいはEclipseでF3キーでクラスやメソッド・フィールドの宣言元を辿っていってソースコードのないところに行き当たったことがあるだろう。 Eclipseの場合、"Class File Editor"というものが開く。そこにはJavaのバイトコードのニーモニックがズラズラと並んでいて、「これは読めないや、ワケが分からない」と投げ出してしまったりしていないだろうか。 怖がることはない。ちょっとコツを掴めばすぐに読めるようになる。 Class File Editorの開き方 自前のJavaクラスの場合、ビルドして出来上がったclassファイルを開く必要がある。"Package Explorer"だとclassファイルは隠されていて見えないのでWindow -> Sh
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
サービスを出会い系とみなされないために - プログラマーの脳みそ
「出会い系サイト規制法」、正式名称「インターネット異性紹介事業を利用して児童を誘引する行為の規制等に関する法律」がかなり酷くて、警察庁のページによれば この法律では、出会い系サイト事業を「インターネット異性紹介事業」と呼んでいます。 「インターネット異性紹介事業」とは、以下の４要件をすべて満たす事業をいいます。 面識のない異性との交際を希望する者（異性交際希望者といいます。）の求めに応じて、その者の異性交際に関する情報をインターネット上の電子掲示板に掲載するサービスを提供していること。 異性交際希望者の異性交際に関する情報を公衆が閲覧できるサービスであること。 インターネット上の電子掲示板に掲載された情報を閲覧した異性交際希望者が、その情報を掲載した異性交際希望者と電子メール等を利用して相互に連絡することができるようにするサービスであること。 有償、無償を問わず、これらのサービスを反復継続
デザインパターンとしての例外ハンドラ - オブジェクト指向と型システムの狭間で例外を考える その4 - プログラマーの脳みそ
例外考察シリーズ。 オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ 契約書に捨印を押す - オブジェクト指向と型システムの狭間で例外を考える その2 - プログラマーの脳みそ try-catch方式・ハンドラ方式 - オブジェクト指向と型システムの狭間で例外を考える その3 - プログラマーの脳みそ 前回はプログラム言語の例外処理機構としてtry-catch方式の他に、ハンドラによる例外処理方式を考えることができる、という話をした。「考えることができる」がこの2010年現在にそういった例外処理機構をもった言語があるかというと僕は寡聞にして知らない。ああ、僕は本当に寡聞なのでただの無知の可能性のほうが高い。メジャーどころではなさそうなんだけどどうだろう。 プログラム言語の機能として、という話だと、プログラム言語を作ろうという人とか、あるいは将来にハンドラ式の例外処
FizzBuzz ループ→再帰→Composite→Strategy→Visitor - プログラマーの脳みそ
最近FizzBuzzをblogで書くといいよみたいな流れになっている(曲解)ので FizzBuzz - 文殊堂 と id:monjudoh が言ったからというわけではないのだけど、FizzBuzzとアルゴリズムの書き換えの話をしよう。 やや昔のエントリになるけどもJavaでFizzBuzzを再帰で作ったというエントリをみつけた。 public class FizzBazzSaiki{ public static void main(String[] args){ System.out.println(func(args.length>0?Integer.parseInt(args[0]):30)); } public static String func(int i){ if(i == 1) return "1"; System.out.println(func(i-1)); return
ソースコードの心脳問題 - プログラマーの脳みそ
先のコードコメントに書くべきは「意図」 - プログラマーの脳みその関連でソースコードの心脳問題という話をしよう。 心脳問題というのは脳という分子機械が、いかにして心を持つのかという哲学のような脳科学のようなテーマの話題。*1紀元前にプラトンのイデア論にて意識とは何かという基礎命題は与えられていたわけだけども、古代には哲学の範疇に収まっていた。 ところが現代のコンピュータサイエンスでは、脳みそのシュミレーションがかなりの規模でできるようになってきていて、工学的に脳を作れる時代が近く迫ってきている。2007年の記事になるが 今回、現在世界最速の性能を持つ「BlueGene L」スーパー・コンピューター上に、マウスの脳の半分にあたる800万のニューロンの働きを再現させる事に成功したそうです。 使われたのは、それぞれが256MBのメモリを使用する、4096台のプロセッサを持つ「BlueGene L
契約書に捨印を押す - オブジェクト指向と型システムの狭間で例外を考える その2 - プログラマーの脳みそ
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みその続き。 僕は不勉強なのでメイヤー氏の思想というものをそれほどトレース出来ていない。だから開放閉鎖原則についての哲学のようなもの、というのはデザインパターンから嗅ぎとったもので、誤りがある可能性が高いということをあらかじめ断っておく。間違いは指摘してもらえると嬉しい。 検査例外は開放閉鎖原則に反しない まず、検査例外は発生したその場、もしくは直接の呼出し元で処理しない限り、throws に記述せざるを得ない。 そうしない場合、より上位層の throws を追加する必要が出てくる。このような追加、もしくは変更は、中間のクラスの再リリースという手間も必要となる。 これは、明らかに開放閉鎖原則に違反する。 例外について色々と考えてみた - ぐるぐる～ 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」につい
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌のあんまりな釣りタイトルにやれやれだぜ、と思いつつも非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESSでツッコミたかったことが突っ込まれてしまってるので、しょうがないのでオブジェクト指向と型システムの話でもしよう。 Javaの静的型システム ≠ オブジェクト指向 僕が10年ほど前、Javaを使い始めてからしばらくたってやっとオブジェクト指向プログラミングが掴めて楽しくなってきた頃合、これこそがオブジェクト指向なのだと誤解をしていたころ、オブジェクト指向は型がチェックできてなんぼだと思ってた。 javascriptのプロトタイプ型のオブジェクト指向に憤り、「あんなものはオブジェクト指向ではない」などと思うのがJavaプログラマ的中二病というやつだが
日本語でプログラミングしてはいけない理由 - プログラマーの脳みそ
詳しすぎる詳細設計書 - SiroKuro Page とか 詳細設計書に何を書くべきか？ - Sacrificed & Exploited 関連。 ソースコードと１対１で対応するような仕様書を書いてはならない理由。 日本語は読み上げれるかもしれないが内容を理解できるとは限らない 日本人なら日本語で書かれた相対性理論の教科書を読み上げることはできる。しかし相対性理論を理解できるというわけではない。 日本語は論理演算を表現するのに向いていない OR と XOR の区別がつかなかったり、括弧による演算順番の指定がやたら面倒くさくて見通しの悪いものになったり。 日本語は例外処理を記述するのに向いていない 法律の例外事項とかの読みにくいことと来たら。 日本語はシンタックスハイライトされない 「を」とか「は」とかカラフルになっても嬉しくないけど。 日本語はコンパイラによる静的チェックができない Wor
IT業界の00年代を振り返る - プログラマーの脳みそ
00年代のIT業界というと、2000年問題に始まった。西暦を数字2桁で管理していたがために桁あふれするだなんて、今になって思えばなんとメモリをケチッていた時代だろうと思うところだが、当時のマシンスペックを思えば仕方無くもある。 2000年初頭のマシンスペック 2000年2月17日に発売されたWindows2000の要求スペックは、Pentium 133MHz以上、メモリ 32MB以上、ハードディスク 850 MB以上の空き容量であった。 1996年にリリースされたJavaは2000年5月8日をもってJ2SE 1.3がリリースされ、かなりこなれてきていたし、Java VMのパフォーマンスもほどほどだった。当時の19200kbpsほどのモデムではJavaAppletのダウンロードには時間がかかったし、当時のJREの起動の遅さもあってJavaといえば遅い、というステレオタイプが根づいていたが、ビ
結婚します - プログラマーの脳みそ
昨年は葬式で終わるような年だったのだけど、年も明けたところでめでたい話を。私、このたび結婚することになりました。 結納とか結婚式とか この手の風習は地域性もあるから一概には言えないのだけど、親父が言うには、新郎とその両親、仲人が新婦の家を訪ねて、新婦の一族とお祝いをするのが結納、新婦とその両親、仲人が新郎の家を訪ねて新郎の一族とお祝いするのが結婚式だったそうな。*1 今では家もそれほど広くないし、自宅で結婚式の宴会をやるのも大変なので会場に新郎新婦の親族を一同に集めて宴会する形式になっちゃったわけですね。それに友人知人や仕事関係の人とか入り混じってターゲットがごちゃまぜでどうもてなしていいのか分らないような感じになっちゃってるんですね。 高いお祝い金を包んで退屈で窮屈な披露宴にいったことはないですか？ そもそも披露宴とか友人を広く呼ぶと費用もかかるから簡単に呼べないんですよね。友人知人をど
コードコメントに書くべきは「意図」 - プログラマーの脳みそ
2.トリッキーな実装 ソースを読んだだけではすぐにわからないようなアルゴリズムを採用している場合や、使用しているライブラリのバグ回避のための特殊な処理を行っている場合、または他の人が見たときや自分が数年後に見た時に「なぜここでこんなことを？」と感じる可能性がある場合にはソースコードにコメントを追加するべきだ。これは言わばトリッキーな実装である。 ソースコードのコメント率は20%を切ることが望ましい : 小野和俊のブログ 私はこの部分にはもうちょっと汎用的に「意図」を書くべき、とすることを提案しよう。*1 トリッキーな実装というのは、「普通」ということが分かっていて初めてトリッキーかが分かる。普通か、トリッキーか、というのは時代背景*2というかハード的な制約も関係するだろう。常識は移ろいゆく。本人がトリッキーではないと確信して書かれるコードと、トリッキーなコードとの線引きはどうしたらよいのだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
