JavaOne2013報告会福岡第二段で話したlambdaの資料に加筆して公開しました。 lambdaの詳細な構文は適当に調べてもらうとして、lambdaでどのようにプログラミングスタイルが変わるかということに重点おきました。 追記「用意されたFuncationalInterface」のリンクはここです。 Java8 Lambdaの文法拡張まとめ - きしだのはてな

昨日のOSC福岡2013の「勉強会x勉強会」セッションで飛び込みLTしたときのプレゼンに加筆して公開しました。 追記：福岡の人はFacebookの福岡IT関連勉強会に参加しておくと、勉強会情報が得やすいと思います。

昨日のエントリでカリーハワード同型対応について触れました。 関数を扱えることはどのようにプログラミング言語の能力をあげるか - きしだのはてな ついでに、このエントリを書くのに調べたカリーハワード同型対応の資料をまとめておきます。 この記事では、カリーハワード同型対応で、どのような型がどのような論理命題に対応するかを解説してあります。 数理科学的バグ撲滅方法論のすすめ - 第14回 型＝命題，プログラム＝証明：ITpro こちらのほうが、ちょっとくだけてるかな？ Curry-Howard Isomorphism - d.y.d. カリーハワード同型対応での山場は、排中律がSchemeのcall/ccに対応するというところで、gotoなどもだいたいこれにあてはまるようです。 排中律、つまり「a または not a」という命題です。これは証明としてはアヤシイので、古典論理からはずしましょうとな

lombokは、JavaでのアクセッサやtoString、equalsなどボイラープレートなコードをコンパイル時に生成してくれるライブラリです。 ただ、こういったコードの生成は、IDEを使えば自動で行えるので、わざわざlombokを導入するまでもないと考えることもできますが、ぼくはlombokを導入するべきだと考えて、lombokを使うようにしました。 このとき「lombokを導入するべき」と考えた理由を書いておきます。 lombokとは lombokは冒頭でも書いたように、Javaのアクセッサなどを生成してくれるライブラリです。 Project Lombok import lombok.*; @Setter @Getter @AllArgsConstructor @NoArgsConstructor @ToString public class LombokSample { privat

TDDにおいて、顧客などから「テストばかり書いていて間に合うのか？」などと質問されることがあると思います。 そんなときには、後ろからそっと抱きしめて 「そんな質問させてごめんな」 が正解です。 https://twitter.com/kis/statuses/350279800600018944 テスト駆動開発の効果はどのくらいある？ − Publickey テスト駆動開発 作者:Kent Beckオーム社Amazon

特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど

おねえさんを組み合わせ爆発から救うために、経路をZDDとして表したら、すっきりと経路情報が扱えました。 http://d.hatena.ne.jp/nowokay/20121018#1350528607 あとは、このZDDを効率よく構築できれば、おねえさんを救えそうです。このZDDの構築には、クヌース先生の開発したSimpathアルゴリズムを使うと非常に効率よく構築できます。 前回生成したZDDを見ると、同じノードにまとまっているものがいくつかあることがわかります。特に後半になるとどんどん同じパターンになるものがまとめられていきます。 つまり、この経路問題のZDDを構築するときには、いかに同じパターンになるものをまとめるかが鍵になるということです。 Simpathでは、辺の端だけに注目して、同じパターンになっていればそれ以降のノードを使いまわすという考え方で、ノードをまとめていきます。 つ

プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自

データベースつかれた ということで、書道しましょう、書道。 っても、筆とか硯とかもってないし、あっても机のうえ汚いし、そもそも筆で文字かくのむずかしい。 ここで、テクノロジーの力を借りるのですよ。 ただ、書道ソフトのようなものはあるのだけど、そういうの使うの結局筆で文字かけないといい感じにならないので、振り出しに戻る感じです。 そこでパスです。Illustlatorとか持ってる人ならそれで。持ってないなら、Inkscapeとかで。 あとは、Inkscapeならペンツールとかで適当に線を引いていきます。なめらかな線にする必要はありません。 バランス悪ければ、拡大縮小すればいいんです。 気に入らなければ、形をかえればいいんです。コツは、とめ・はね部分をぶっとくです。 最後に、色を黒くすれば、なんかそれっぽくなります。 書き出して、完成。

どうも、FizzBuzzがどうこうという話題を目にするなと思ったら、こういうエントリがあったらしい。 職業プログラマがFizzBuzz書けない理由 - muo-notes 趣旨としては「FizzBuzz書けなくてもプログラマとしてメシくえてるんだから、FizzBuzz書けない人をバカにするのはおかしい」ということだと思う。 ここで、このように書いてある。 彼らがFizzBuzzを書けないのは、おそらく彼ら自身が社会的価値を生む上で必要ないからであって彼らが無能だからではないということ。 とはいえ、次の記事にもあるように、受託開発の終わりが叫ばれるような時代に、FizzBuzzを書けない人が、今後もこれまでと同様な社会的価値を生んで行けるようには思えない。 受託ソフト開発会社は、もう終わり！ | 日経 xTECH（クロステック） 市場環境としては、このように書いてある。 国内中心に事業を展開

Javaからネイティブコード呼び出そうと思ったんです。 で、あんまりやる気もないんで、JNIじゃなくてJNAでやろうと思ったんです。 Windows7 64bitで。 ということで、まずMinGWインストールしたんです。 http://www.mingw.org/ んで、NetBeans7.1で「オプション」の「C/C++」のところの「ツールコレクション」で「ベースディレクトリ」に「MinGW\bin」を指定したんです。 それから「C/C++動的ライブラリ」プロジェクト作って、「newfile.c」って名前でこんなコード書きました。 #include <stdio.h> void hello(){ printf("test\n"); } それから「構築」ってやるとDLLができたんです。 あとはJavaからの呼び出しコード書こうと思って、まずはJNAのサイトからjna.jarをダウンロードし

報じられた事実はございませんし、報じられてもございません。

関係ないけど、誤謬(ごびゅう)を「ごしん」と読んでた時期がわたしにもありました。 で、本題。 先日「C++の授業を受けて理解できなかった人が、RubyでRailsをやったら簡単に理解した、Rubyすばらしい」という話がTwitterで流れていた。 ただ、これをもって、Rubyで授業やるとわかりやすい、と単純に考えてはいけない。 確かにC++はヘッダファイルやポインタみたいな、混乱ポイントがあるわけだけど、教育用途なら1ファイルに全部書くことでヘッダファイルからは逃れれるし、C++のライブラリつかえばポインタはあとまわしにできる。Rubyでも文法を淡々と初心者に教えれば「わけわかんない」という感想だけで終わらせることもできる。 なにより、このご時勢にプログラムの最初の授業をC++でやってる先生の授業がわかりやすいはずがない。わかりやすさに気をつける先生なら、JavaかC#かRubyか使ってい

東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Ａというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい

数字も表示されてないのは、やっぱFizzBuzzとして失格だと思うので、ちゃんと数字が表示されるようにがんばりました。 実行したらこうなります。ちゃんと数字が出てます！(追記:でも間違ってる！) Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43

この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。

プログラムには、手続きを記述するという側面と、式を記述するという2つの側面があります。 そして、それぞれの基礎理論としては、チューリングマシンとラムダ計算があるので、プログラムの理論としては、この2系統を勉強する必要があると思います。 ラムダ計算というのは、式によってどのような計算ができるかという理論です。式による条件分岐はそれほど難しくなく、Yコンビネータなどの不動点定理で、式によって繰り返し処理が行えるということが証明されたので、どのような計算でもできるということになっています。 チューリングマシンの理論とは、どのような手続きがどのような性質をもつかという理論です。プログラムの性質というのは、ある出力を行うプログラムが、入力に対してどのように時間がかかるか、どのようにメモリを使うかというものです。そしてこれがアルゴリズムの理論になります。 ところで、ぼくはブログで「アルゴリズムを勉強す

PHP-erはダメな言語でいかにまともなものを作るかっていうマイナスからのスタートだし、 JavaScript-erは何もないところで何か動いて楽しいっていう０からのスタートだし、 Ruby-erはRuby好きって言ってるだけだし、 Java-erはJavaの仕様にしか興味がないし。 Scala-erは生ぬるいこと言うと狩られるし、 Smalltalk-erは過去の栄光語ってるだけだし、 COBOL-erは苦労話しか出ないし、 FORTRAN-erはプログラムに興味ないし、 Perl-erは同窓会みたいだし、 Python-erは仲間探すの大変だし、 Erlang-erはどこにもいないし、 C-erは目先の仕事にしか興味ないし、 C++-erはC++の復興にしか興味ないし、 C#-erはWindowsにひきこもるし、 ActionScript-erはAdobe税はらうのに大変そうだし、 O