野狐消暇録

所感を記す

2015年の抱負

情報技術

これを2015年の年末に読み返す時、僕の心境は如何なものか。今推測するに「一年経ったけど、やりたい事がそれほど変わっていない」と思うのではないか。いずれにしろ、進捗が大いにある事を願う。

Androidがこの先どのぐらいあるかは分からないが、タブレット端末のアプリ開発の需要はこれからしばらくなくならないと思う。そこで、Android開発を通して、タブレット端末用のアプリ開発の事始めにしたいと思う。

去年からAndroidのアプリ開発をしたいと思っていたので、派遣元の会社で行っているエンジニア研修は、Androidをテーマにした。今はオセロゲームを作りながら、実装に慣れる事を目標にしている。

オセロゲームは3月末までに一通り作り上げ、後は機能追加をしながら、勉強を続けたいと思っている。カメラ機能やバイブレーション機能など、APIを色々呼んでみたいと思う。1年後に、Androidアプリの保守改修が仕事で出来るようになっていれば、上々。

  • インフラ関係

ネットワークが分からなかったり、Linux系のサーバを触れなかったり、ちょっと自分はインフラが弱い。仕事上での要求に応えられていない。これではいけないという事で、インフラ関係の勉強を少しづつ進めたいと思っている。ネットワーク・スペシャリスト試験の本を買い、少しづつ読んでいるけど、いつ取れる事やら覚束ない。仕事ができないのは困るので、少しづつ取り組んでいきたい。

  • その他

コンパイラを作ってみたいとか、プログラミング・コンテストをまたやりたいとか、色々思っているが、どこまでできるかは、仕事の忙しさに依存する。暇があれば、結構できるかもしれない。電子工作もやってみたいと言いつつ、結局まだやっていない。やりたい事が少しづつでも、出来てくるといいな。そんな年頭所感でした。

  • おまけ

結婚したい。これ、おまけじゃない、これが第一の目標じゃ！

■

40分程度坐禅を実施。

人類の誓いを改めて読む。
深い哲理の実践としてではなく、取り敢えずの生活原理として、この誓いを生きてみたいと思う。
それはまだ禅の修行を始めたばかりの自分でも可能なはずの事だからである。

仕事の愉しみ

自分は、音楽を聴いたり、人と話したりという事が楽しい。しかし、自分にはそういう享受的な楽しみとは別の楽しみがある。それは仕事である。僕はプログラマとして働いている。プログラミングは子供の頃からやっていた訳ではなく、仕事として始めたのである。今はプログラミングが楽しい。自分は仕事が重要な事だと思っている。それは生活の糧を得るという事もあるが、何か、この活動そのものが、非常に面白く感じる。僕はこの活動をどんどん前へ進めたいのである。あるいは、こういってもいい。これが僕の生き甲斐である。僕は、人に何かをしてもらったりする事がそれほど面白くない。もちろん、それはそれで楽しい時間を過ごせる。しかし、何か物足りないのだ。はっきり言うと、全然そこに手応えがないのだ。それでは僕は嫌なのである。人は名声であるとか、或いは豪邸に住むとか、そういう事に、本当に喜びを感じて生きられるのだろうか？　そういう事は、人生の浮沈の１ページに過ぎず、本当に大切ではないと思う。本当にその人にとって大切な事は別にあると思う。それが何かは人によって違うだろう。同じではない。しかし、仕事を大切にし、これに楽しみを見い出せた人は幸せではないだろうか？　僕はそういう点で、自分の考えにある確信を持っている。僕の活動は、少なくとも僕自身にとって、面白い、間違いなく面白いのである。僕は自分の人生に、ある積極性を見い出したと思う。僕はついに、ある事に熱心になる事ができたと思う。仕事に楽しみと喜びを見い出し、仕事に打ち込んでいく事、そういう事を、僕は一生の支えとし、自分に大切にしていくつもりである。僕はおそらく、人が苦であるようなことも、あまり苦ではない。自分の能力を生かせる仕事ほど有難いものはない。僕は仕事を通して、生きる事を理解できると思う。僕はともかく仕事がしたい。仕事がとても面白い。一生懸命働く事をしたい。

『Javaによる関数プログラミング』を読みました。

情報技術

Java8になり、ラムダ式がサポートされました。

Stream APIという、関数プログラミングのためのAPIも提供されるようです。

『Javaによる関数プログラミング』はそんなリニューアルしたJavaの使い方を解説した本です。

本には、どこでどう関数プログラミングしたら良いかが書いてあり、とても参考になりました。著者はオブジェクト指向のためのデザインパターンを引いて関数プログラミングを説明しており、理解が進みました。

特に関心した点、気付かされた点を以下に挙げます。

これは僕のプログラミングの中に、今までありませんでした。複数の似たメソッドの差分をパラメータ化する場合、値として括り出す事しかできなかったのです。例えば、SQL文字列を引数として渡し、渡したSQLを発行するDBアクセス用のメソッドがあったとします。この時、SQLは確かに処理ですが、型としてはただの文字列=String型であり、差分は飽くまでも、値の形にするしかありませんでした。しかし、ラムダ式はSQL文字列と異なり、意味だけでなく、プログラムにとって実際に処理です。これにより、所謂ボイラープレートを括り出したメソッドが作れるかもしれない。これは僕のプログラミングにとって大きな進歩です。これからはコーディングに際し、値だけでなく、処理の差分もパラメータ化できるという事になるのです。

オブジェクト指向と関数プログラミングが近い関係にあるという話は以前にも聞いた事がありました。自分の経験としても、最初に関数プログラミング的に設計、コーディングを進めて、機能が完成した後、オブジェクト指向の考えに沿ってリファクタリングするのが、いつものコーディングスタイルでした。

具体的には、最初に入出力を繋ぐような、この本のタイトルにもなっているStreamを作るようなプログラムを書きます。画面遷移が多いプログラムだとこの方法は使えませんが、その場合は、画面遷移を表にまとめる所から始めます。そして、Streamを作る中で、どうしても、状態として管理せざるを得ない部分に注意します。なぜかというと、ひとつには、ここにバグが入りやすいからです。さらに、状態として管理する部分が常にひとつの状態を取っているか、マルチスレッドでアクセスされたりしないかも考えます。そうやって注意しながらコーディングを進め、一応動く所までいったら、簡単なテストの後、プログラムを見直します。ここでオブジェクト指向について考えます。同じような情報をひとつのクラスに纏めます。アクセスレベルも見直し、基本的には小さくします。かなり書き直す事も良くあります。そうしたら一応完成。極端に速度が遅くない事を天に祈ります。これは冗談です。

速度が遅かったら、DBアクセスとか、OSのメモリ使用量が極端に増加していないかとか、色々調査が必要になると思いますが、あまりやった事がありません。今後できるようになるのが、自分の課題です。

話を元に戻すと、そういう、関数プログラミング的なアプローチと、オブジェクト指向で推奨されているアプローチと、両方使ってコーディングしている中で、相性の良さを肌感覚では感じていました。オブジェクト指向に基づいてリファクタリングすると、所謂関数プログラミングの指針で書いたコードも綺麗になる事が良くあったからです。しかし、この本の著者は、そういう実感レベルから更に踏み込み、オブジェクト指向のためのデザインパターンの用語を用いて、関数プログラミングのアプローチを説明しています。

例えば、ストラテジ・パターンです。ストラテジは日本語に訳すと戦略です。ここで戦略は、プログラムの実行方法を指しています。これは、メソッドに戦略、つまり実行方法を引数として渡す事により、そのメソッドの実行方法を切り替えるというデザインです。関数プログラミングに当て嵌めると、戦略がラムダ式であり、冒頭に挙げた処理を引数として渡すメソッドは、ストラテジ・パターンとして説明できます。

また、ラムダ式の実装がJavaの文法の中でどのように実現されているかの解説も興味深く読みました。自分は、まだちゃんと理解できていないように思いますが、Javaの継承の仕組みを利用してラムダ式を実現しているようです。そうした点、関数プログラミングとオブジェクト指向の関係について、もっと理解したいと感じました。

  • 引数に取ったオブジェクトではなく、新しいオブジェクトを作って返却する。

これも知ってはいたのですが、この事により、変数の不変性が保たれる訳です。引数に渡したオブジェクトがコレクションであったとして、単にコレクションへの参照が更新されないという事ではなく、コレクションの要素が更新されない。こういう使い方をする事により、中身まで不変な変数という事になる。これはちょっとなるほどと思いました。そうやって、次々に新しいコレクションを生成しながら、処理を進めるという事です。この考え方もそうですが、関数プログラミングの手法は、所謂関数型言語でなくても使える手法がほとんどで、大変学び甲斐があります。この間書いたExcelVBAプログラムでコレクションを扱う機会があり、早速この方法を使いました。VBAはプログラミング言語としては簡素なもので、その時使っていたコレクションは単なる二次元配列でした。この二次元配列を引数にとり、２つの列の値をマージした新しい列を作成し、その列を返すようにしました。この事により、元の二次元配列は破壊されずに、新しいコレクションが手に入ったわけです。VBAは関数プログラミングを支援する仕組みはほとんどないように思いますが、この程度の事は普通のプログラミング言語がサポートしている範囲の機能で充分可能です。

 

ここに挙げた以外にも、面白い話題はいくつもあり、とても良い本に出会ったと思います。この本は既に関数プログラミングに慣れたプログラマには優しすぎるかもしれませんが、僕にはちょうど良いようです。また読み返したいと思います。

ヴィクトリアの未着工建築 [小説]

　先日、神保町の古書街をふらふらと歩いている時、工学の古本屋を見つけて中に入った。壁に本が並ぶ階段を降りて、書棚と書棚の狭い間を進むと、奥に曲がり角があった。奥に進むと希少本がガラスケースに入っていくつか展示してあった。その中にその本はあった。非常に珍しい本であるとかつて教わった教授に聞いていたので、とても興味を惹かれ、ぜひ手に取って見てみたいと思った。店員を探し、レジに若い男を見つけた。頼むと、ちょっと待ってくれと言ってどこかに行った。帰ってくると、店主が出かけていて、あと1時間ほど戻らない。店主が帰るまで待ってくれないかという。自分は用事を控えていたので、その場は諦めて帰った。しかし、どうしても気になるので、店主に手紙を書き、今度見せてくれないかと頼むと、快く承知する旨の返信を寄越してくれた。

ある雨の日、約束の時刻にもう一度工学の古本屋を訪ねて、本を見せてもらった。本は面白かった。しかし、その本の内容を直接ここに記すのは止そうと思う。本は建築に関するものであり、しかも図版を主としているので、うまく説明できる自信がない。その代わり、本に付けられた跋文を紹介したい。おそらくこの跋文を紹介する事が、そのままこの本の内容を紹介する事にもなると思う。

 

その本の著者は、40歳を過ぎた、ヴィクトリアという女である。女が40歳を過ぎた時、その本が出版されている。それは著者の生年と本の出版された日付から分かる。この女が跋文の中に自身で書いた略歴によると、彼女は若い頃、商業学校に通ったがすぐに止め、建築系の専門学校に入り直した。両親の生活が貧しく学費がなかったため、4年制の学校に通えず、伯母の家に下宿しながら、2年制の学校を出た。すぐに建築事務所の仕事に就くつもりだったが、就職活動をしている最中、隣国との緊張が高まった。ちょうど新年に田舎に帰った時、戦争が始まってしまい、就職どころではなくなった。田舎で両親と日を送るうち、町長の館で働いている男との縁談があり、結婚して子供を二人もうけた。そのうちに戦争は終わったものの、建築の仕事はそのまま諦め、子供を育てているうちに日が経った。ある日、港街まで用事があって遠出した時、偶然建築を教わった先生と会った。再会を喜び、招かれるままに先生の家で歓待を受けた。その家は学生の頃に何度か訪れた事があった。懐かしい先生は既に60歳を過ぎ、建築学校の教師は辞めていた。しかし、本棚には教職を勤めていた頃に収集した多くの蔵書がまだそのまま残っていた。その本をいくつか見せてもらった。本の中に見た事のない建物のスケッチがあった。聞くと外国の建築を写したものとの事。その日は先生の家に泊まり、明くる日村に帰った。それからしばらく図版で見た外国の建物の事が頭に付いて離れなかった。気が付くと夜仕事を終えてから建物の設計図を紙に落書きするようになっていた。それは先生の家で見た外国の建築に想を得て彼女の考えた建築であった。ひとつ描き上げると捨てるのが惜しくなった。折角描いたのだからと手元に置いておくうち、またひとつ、またひとつと少しづつ設計図が溜まっていった。彼女が跋文に記すには、この本はその設計図に目を留めた人に勧められて出版するものである。私は職業建築家ではないから、この本に収められた建築で実際に建てられたものはひとつもない。また、実際に建てようとしても、建てられないに違いないような設計が多く含まれている。これは依頼を受けて描いた設計ではないから、そこまで深く実現性を考慮しなかったのである。しかし、それが却って、人の思い付かない、奇異な外観や内装を生んだのかもしれない。おそらく人が出版を勧めたのも、その故であろう。

 

彼女は本に題を付けなかったようであるが、おそらく出版元がこの跋文を読み、ひとつも実際に建てられなかったという所を受けて、『ヴィクトリアの未着工建築』なる表題を付けたようである。