プログラミングのタネ

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
椅子から立ち上がっただけで、激しいぎっくり腰に見舞われた、たなけんです。
本エントリでは、私なりのプログラミングのネタの探し方について記載します。

どう書く？org

はじめに頭に浮かんだのはどう書く？orgです。(久しぶりにのぞいてみるとサーバエラーになっていましたが)
問題の範囲が小さく、様々な言語で解答されているので、とっかかりやすく、他言語の特徴なども知ることができ、新しく覚えた言語を手に馴染ませる際に良く利用していました。

プログラミング本の写経

プログラミングの本、例えばPaul Grahamのon Lispであれば、Common Lispでどう書くか、ということが示されています。僕の場合は、Common LispではなくClojureでon Lispの写経を行いました。(SICPも早く完了したいのですが。。。)
その言語についての知識が全くない状態であれば、ただ写経するだけでも、習慣的な記法が身に付いて良いかと思いますが、私は少し退屈だと感じたのと、Clojureが好きであるという点から、少し言語を変えて写経を行いました。
Ruby on Railsを初めて学んだ際には”RailsによるアジャイルWebアプリケーション開発”という本を黙々と写経(というかコマンドとかもそのまま打ってました)しました。そのころは、Javaで書かれた自社製の独自フレームワークを使って開発することしかしておらず、Railsでは本当に少しのコードで、こんなことができるんだと衝撃を受けました。
写経をしながらだと、開発環境が整えられているためか、フレームワークのソースなどもその場で気になった瞬間に読むことができ、そういった点からも、手を動かさずに読むよりも理解が深まる気がします。
そういった訳で、プログラミング本はプログラミングのネタ供給元としてなかなか優れていると思います。

競技プログラミング

プログラミングコンテストチャレンジブックなど競技プログラミングのお題が紹介されている本やWebサイトも良質なネタの供給元だと考えられます。
しかし、僕自身がそれ程高度なアルゴリズムや実行時のパフォーマンスに関心がないため、競技プログラミングのお題でプログラムを書くことはあまりありません。(Excelの自動操作なんとかして的な、泥臭いけど知識が無いとてこずる系が興味の中心です)

ランサーズ

ランサーズというフリーランスへ仕事を依頼することができるサイトがあるのですが、ここでシステム開発系の依頼もいくつかあるようです。
内容としては、Webサイト構築、データの変換やデータベース構築などです。
その中で下記の2つの依頼が僕の目を引きつけました。

• Webから商品情報をスクレイピングしてデータベースに登録する
• 独自性ルールの麻雀ゲームを実装する

これを見た時、『これは職業プログラマ向け、どう書く？orgだ』と感じました。
それほど難しくなく、かつ現実的なスキルセットが必要なプログラムのネタが、ランサーズには転がっています。さらにそのプログラムの市場価値(依頼金額)も見られるので、『自分だったらx時間でできそう』とか、『この分野の依頼が多いから、やったことないけど手を出してみるか』といった自分のスキルの需要と供給についても考えられるので、『プログラム書きたいけど手頃なネタがないなぁ』という方には、ランサーズに出されているお題に取り組んでみることを、是非おすすめします。(個人的には、こういったスキルマッチングの市場がより一般的になるのかどうかなど、プログラムのネタ探し以外の点でもランサーズおよび類似サービスに注目しています)

必要に迫られ系

最後になりますが、やはり最も楽しいのは、自分のプログラムで現実の問題を解決することでしょう。ざっと思い出しただけで、今年は下記のプログラムを留学生活の合間に書いていました。

• 計算問題自動生成(姪っ子向け、問題数、難易度を選んで計算問題生成)
• 数独を途中までソルバ(単純に数を当てはめるだけの部分はプログラムに解かせ、推理が必要な部分は自分が楽しみながら解くためのツール)
• 超簡易ERP(発注、在庫、営業、受注、販売、顧客、採用、給与、財務を管理するRailsアプリ、友人が文房具販売のスモールビジネスを始めるため、夏休み中に作成)
• レポーティング (ビジネスゲームで得られる膨大なデータをDBに落とし込み、グラフを作成、マーケットシェアなど加工が必要な情報の計算)
• ビジネスゲームロジック類推(蓄積したデータを変数に、統計モデルを検証し、どのパラメータが何に、どれくらい影響を与えるかを類推。)
• 簡易OCR(画像データを変換、分割し、必要な箇所の文字を読みDBへ補完)
• 英単語検索、記録(はじめは自分向けのコンソールツール、同じ単語を何回調べるかとか、類義語が簡単に取得出来るようにするなどをWordNetを使って実装。その後Webアプリとしてリニューアル)
• オークションの売買履歴自動記録(アマゾンマーケットプレイスの上位1200冊の出品情報を継続的に取得(スクレイピング)記録し、売れるまでの期間、価格とランキングの変遷、売れる本のジャンルなどを求める)
• 2chまとめの自動取得(スクレイピング)
• Wordpress.comのブログに自動投稿(Seleniumでブラウザを自動操作)
• POIを使ってExcelファイル作成(アドホックに良くある)

必要に迫られ系の変種としては、ライブラリの検証が挙げられます。このブログで紹介したDatomicやQuartzite、Web-driverなど、新しいライブラリを使う際には、いきなり既存のプロジェクトに組み込むのではなく、検証用プロジェクトを作成し、機能を一通り試しています。厳密には『何を書くか?』というプログラムのネタを供給してはいませんが、『何か書く、できることの幅を広げる』という観点からは、ライブラリの検証もひとつのプログラムのネタと言っても良いかと思います。
ローカルに保存されているプロジェクトの残骸を数えてみると、上記プログラム以外にも30ほどプロジェクトがあり、2週間に1つ以上のベースでは新規ライブラリを試していた様です。(ふと思い出しましたが、今年の頭はcoffeescriptやクライアントサイドMVCにこってりはまっており、spine.jsなどソースをガリガリ読んでいました。こちらも機会を見つけて紹介したいと思います)

まとめ

今年書いたプログラムの総括のようになってしまいましたが、プログラムを書きたいけど何を書けば良いか分からない、という方のヒントになればと思い、本記事をしたためました。
ランサーズを見て、どう書く？orgを思い出したのが事の発端ですが、ブログを書いているうちに、必要に迫られて書いたプログラムの思い出が頭に浮かび、長くなってしまいました。
Clojureを使い続けて3年目です。はじめはファイルの入出力でさえもわざわざ調べて書いていたのですが、今ではDBやWebのプログラミングも手短にできるなど、手に馴染んできました。現実的な問題を解き続ける事で、できることの幅が広がり、達成するまでの労力と時間が短縮されました。
この冬に、学生からソフトウェアエンジニアへと職業が戻りますが、業務内/外にこだわらず、Clojureを使って問題を解決していきたいと思います。
また、ゲームを使った学習についても関心があるので、Javascriptのゲームライブラリであるenchant.jsもClojurescriptのラッパを書くなどして使ってみたいと思っています。

今日の作業は以上、最後までお読み頂き、ありがとうございました。

たなけん(作業時間30分)

第3イテレーションの振り返り

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
肩甲骨のストレッチの効果か、姿勢が良くなったと最近言われた、たなけんです。
本エントリでは、第3イテレーションを振り返ります。

Datomicおよび各種ライブラリを利用した所感

長所

Clojureで書かれている製品である為、クエリにそのままClojureの式(自作の関数も含む)を使う事が出来る

Clojureで書かれている製品である為、Clojureのデータをそのまま収納する事が出来る

原理的にはスケールアウトが可能
クエリおよびデータの追加、変更がほぼClojureのS式である(Clojureネイティブである)点が唯一にして最大の長所だと思います。RDBMSを利用していると、例えばSELECT文ではSQLの書式に従い、SQLの関数を利用して結果を得て、そこからClojureのデータに束縛し直す必要があります。しかし、Datomicではfindの条件にそのままClojureの関数が使えるため、SQLとClojureのデータを行き来するような処理は必要なく、手早く開発することができました。

短所

• 無料版ではfreeおよびmemプロトコルのみであるため、スケールアウト性能を検証することができない
• BIツールのように複数のテーブルを結合するなど、様々な角度からデータを解析する方法が確立されていない
• 集約系の関数など、自力で実装しなくてはならない

RDBMSであればスタースキーマなど、分析対象のデータを多次元的に扱う手法が確立されています。Datomicの柔軟なクエリ構築力を考慮すると、恐らく良い実装方法があるのだろうと、ぼんやりとそのポテンシャルは感じたのですが、今の時点では具体的な方法までは見えていません。

短所としてBIツールの様な多次元表の利用を挙げましたが、「プログラマブルなクエリが書ける、マクロも書ける」というDatomicの潜在能力を引き出せば、SQLを使うよりもスマートにこれらのソフトウェアを実装することができると(根拠は薄弱ですが)直観しています。

Webアプリケーションを一通り書いてみて気付いたこと(およびClojure愛)

これまで、主なClojureの使い道はツール作成でした。しかし、今回はプレゼンテーション層からパーシステント層までClojureを用いて、小さいながらもWebアプリケーションを完成させることができました。そこで気付いたことを振り返りたいと思います。

自転車あるいは糊

Clojureは私にとって最も手に馴染んだプログラミング言語です。そのしっくり来る感じを例えると「自転車」です。気軽に、どこへでも、最短距離で移動できる乗り物です。
他のプログラミング言語を同様に例えるとすれば、Cは飛行機、Javaは鉄道、Pythonはバスでしょうか。それぞれに利点はありますが、家の裏の公園に行く為に、飛行場を作ったり、線路を引くのは、得たい結果に対して労力が釣り合わない気がします。その点Clojureは行きたい場所へ、そこが車さえも入り込めない路地であっても、最短経路でたどり着くことができます。
また、目的地が遠ければ、鉄道や飛行機を乗り継いで行けばいいのです。駅と飛行場の間は自転車で移動し、最後のバス停から終着地点までの間だけ自転車に乗る事もできます。これは必要に応じてCやJavaで書かれたアプリケーションやライブラリをClojureから使って、目的の機能を実現している時の、僕の頭の中にあるイメージです。
実際、ブログでも紹介したTesseractやImagemagickをClojureから操作し、H2 Database Engineへデータを格納後、帳票を出力するツールの実装は、この乗り継ぎの比喩の良い実例と言えるでしょう。そしてWebアプリケーションに関しても、一から書いたコードは少なく、殆どはライブラリが提供する機能をつなぎ合わせたものでした。
多くの人はこう言うでしょう。「それは自転車ではなくて糊だよ」と

マクロ

自転車の例えはまだ続きます。車のエンジンをバラしてまた組み挙げられる人はどれくらい居るでしょうか、またそれに掛かる時間は?工具は?
バラして組み直す事、これはすなわち言語そのもののハックのしやすさの比喩といえます。
Clojureはシンプルです。特殊形式とマクロと関数しかルールが無いと言っても良いでしょう。構造が簡潔であり、なおかつユーザが手を加える余地を十分に残しています。マクロは、簡単に言えば言語の構文を規定し直す機能です。私は多用はしませんが、「いざとなればマクロでなんとでもできる」という信頼感があります。メカニズムを把握していて、そこに手を入れることができる感覚、それは自転車いじりに似ています。自動車のエンジンや、電車のモーターは、固そうですし、私には複雑過ぎます。
マクロの存在がClojureをシンプルかつ柔軟にしており、マクロがあるため僕はClojureを信頼して使い込む事ができています。この感覚が、やはり私にとって自転車なのです。

万人の自転車へ

Clojureが私にとって自転車である事、それは多くの人にとってどうでも良い話だと思います。しかし、Clojureは他の人にとっても自転車となり得る言語だとしたら?
私はJavaのアプリケーションやライブラリを鉄道に例えました。同様にClojureのライブラリは地下鉄や高速道路網と例えても良いかもしれません。多くの人が利用する点から点への移動には、より効率よく移動するための道が敷かれるからです。そして、それら全ての乗り物に、だれでも自転車を携えて乗ることができます。
このブログを読まれた方が、「Clojure使ってみようかな」と思ってもらえるように、これからもClojureの魅力を伝えていきたいと思います。

私に足りないもの

自転車は簡単に乗れますが、奥が深い乗り物です。フォームの善し悪しで、疲労度が大きく変わります。
私はこれまで、全くの我流でコードを書散らしてきました。自転車で言えばがむしゃらに漕いでいる状態です。
Webアプリを設計、開発する中で何度も「どう書くのが関数型言語の特性を活かしているのか?」と自問しつつも、まず動く物を優先して、ここまで漕ぎ進めて来ました。
当初の目標であったプレゼンテーション層からパーシステント層まで実装を終えた今、次に何をすべきかと考えました、私には何が足りないのだろうか?と。
そこで考え至った結論が、フォームの改善です。プログラミングの基礎です。

年内の目標

コンピュータ書の古典"SICP(計算機プログラムの構造と解釈)"の原著が本家サイトから無料で読む事ができます。関数型プログラミングのエッセンスを掴むべく、このSICPの原著を年末までに読み切りたいと考えています。
学習記録をブログに綴る事で、読者の皆様にも関数型言語でのプログラミングの公理のようなものをお伝えできればと考えています。

運用フェーズに向けて

Webアプリの開発フェーズはほぼ終了しましたが、まだこのプロジェクトは終わっていません。そうです、Herokuにデプロイしてサービスを公開、運用ノウハウを蓄積するというタスクが残っています。また、運用しながらメンテナンス性を高める為にリファクタリングしたり、ログ解析ツールそして機能追加など、改修のアイデアはまだまだあります。
SICPリーディングと平行して、Webアプリプロジェクトも継続していきます。

今回の作業は以上。最後までお読み頂き、ありがとうございました。

たなけん(作業時間1時間)

第2イテレーションの振り返り

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
肩甲骨周辺の筋肉をほぐすと代謝が上がると聞き、日々肩を回している、たなけんです。
本エントリでは、第2イテレーションを振り返ります。

Clojurescriptおよび各種ライブラリを利用した所感

Clojurescriptの利点

Javascriptに馴染めない、という理由からWebクライアントの開発言語にClojureを採用しました。Google Closure Libraryで提供される関数やオブジェクトを利用する感覚が、通常のClojureからJavaのライブラリを利用する感覚に非常に近く、スムーズに開発を進めることができました。また、DOMやイベントの操作についての関数が十分に整備されていたことも、開発効率の向上につながりました。

Clojurescriptの欠点

多少違和感があった点としては、通常のClojureでは副作用を期待する処理にdoマクロを用いるのですが、Clojurescriptではdoマクロを用いずに次々と式を評価していく点があげられます。ライブラリの読み込みや表の描画など、戻り値を利用しない処理が多く、この点は若干の気持ち悪さがありました。

コンパイルとデバッグ

ClojurescriptからJavascriptへのコンパイルなど、導入前は手間が掛かることを想定していたのですが、lein-cljsbuildを用いることで、コンパイルを意識することなく開発を進めることができました。ただし、デバックについてはFirebugを用いてJavascriptのコードにブレイクポイントを設定し、エラーを解析する必要がありました。この点については、HTML 5で提供されるsource mapを利用することで、解決できるのではと考えています。

repl

Clojurescriptのreplは通常のClojureのreplほど洗練されておらず、若干使い勝手が悪かったです。そのため、Clojurescriptで提供されている関数の動作を確認する程度にしか利用しませんでした。この問題は、Emacsとの連携で解決できそうです。(本家サイトのEmacs連携のWikiページ)

Google jsapi (visualization API)

表や図などのオブジェクトが提供されており、自分でtableタグなど書く手間が省け、開発時間を短縮することができました。また、オブジェクトへのidの付与など、今回は利用しなかったものの、通常の利用では必須となるであろう機能も用意されており、また機を見てAPIを調査したいと思います。

Twitter Bootstrap

正直あまりUIに時間を掛けなかったので、なんとも言えません。
動的にCSSを生成するフレームワークとしてlessを採用しているようですので、こちらも機会を見て掘り下げてみたいと思います。

今後利用してみたいツール、フレームワーク

Clojurescriptについて調査を進める中で、気になるツール、フレームワークがあったので、この場を借りて紹介したいと思います。

lein-cljsbuild (複雑なソースのビルド、テストの自動実行)

今回はコンパイル機能のみを利用したのですが、その他にもClojure(.clj)ファイルとClojurescript(.cljs)ファイルを別ディレクトリに保存しておき、ビルド時に1つのJavascriptを生成する機能や、PhantomJSを起動してテストを自動的に実行する機能などをlein-cljsbuildは持っているようです。
特にビルドに関してですが、クライアント側で実行するコードであっても、純粋なClojureで記述できる部分がcljファイルに保存できると、単体テストの仕組みなどをサーバ側と統一できるため、非常に開発効率が上がると思います。
さらに、cljsソースとcljソースが粗結合となるため、Sinon.jsなども絡めることでcljs(ブラウザの操作などを含む不純なClojurescript)コードのテストもより単純化できるのではと感じました。

Clojure one

Clojure oneはサーバ、クライアントの双方をClojure(Clojurescript)で開発可能にした統合Webアプリケーションフレームワークです。単体テストの仕組みなども組み込まれているようで、非常に便利なのではないかという印象です。便利な反面、何かしら制約があるかもしれませんが、次回ClojureでWebアプリケーションを利用する際には、実際に使ってみようと考えています。

Bishop

BishopはClojureで書かれた、HTTPリクエスト処理ライブラリです。Webmachine互換のAPIを持ちRestfulなWebサービスを実現するために利用することができるようです。

クライアントサイドMVCフレームワークについては後述しますが、Webアプリケーションのあり方として、ロジックはサーバーサイド、描画と操作はクライアントサイドにまとめてしまった方が良いのではないかと個人的には考えています。Bishopは多様なリクエスト処理関数を実装しており、ロジックに特化したサーバサイドのライブラリとして、有用なのではと、密かに目をつけています。

クライアントサイドMVCフレームワーク

Bishopの項でも述べた通り、ブラウザでの描画および操作はクライアントサイドで完結させたいと個人的には考えています。そういった要望に応えるのがBackbone.jsやSpine.jsなどクライアントサイドMVCフレームワークです。

Coffeescriptの練習がてらSpine.jsを利用した感想としては、「何故、今までこれを使わなかったのだろう」と思ってしまったくらいに便利でした。(JavascriptではなくCoffeescriptでモデルなど定義できたからかもしれませんが。。。)

今後、クライアントサイドの処理が複雑なアプリケーションを作成する際には、ClojurescriptとこれらのクライアントサイドMVCフレームワークを組み合わせて実装出来ないか、検討したいと考えています。

今回の作業は以上。最後までお読み頂き、ありがとうございました。

たなけん(作業時間30分)

第1イテレーションの振り返り

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。、たなけんです。本エントリでは、第1イテレーションを振り返ります。

第1イテレーションの振り返り

普段はツール開発にClojureを利用していましたが。今回のアプリケーション開発では、堅牢なアプリケーション開発のために以下の点を意識しました。

• ライブラリの利用
• ツールの利用
• 実装

ライブラリの利用

多数のライブラリを利用しましたが、その中でも下記のライブラリについて利用した感想を簡単に紹介したいと思います。

• clojure.tools.logging: ログ出力。副作用のある処理なのでdoと合わせて使うと便利
• clj-xpath: xpath問い合わせ。完結かつ柔軟にxmlノードを抽出できて便利
• clojure.test: テストコード定義。Leiningenからもテストが実行可能で便利

ツールの利用

実際にツールを利用した感想を以下に記します。

• IDE: emacs。起動、終了が高速かつ、replを利用しながらテスト可能でありEclipceよりも使い勝手が良い印象
• バージョン管理: git。特別な利用をしていないためSubversionなどと同様な印象
• 継続的インテグレーション: Jenkins。まだ運用方法が未確立

実装

実装時に様々なClojureの機能や関数を利用しましたが、その中でも便利だったものを以下に紹介します。

• 例外処理: gen-classを使用。Exceptionを継承することでアプリケーション例外を定義
• 関数の公開範囲: 他の名前空間から呼ばれない関数はdefn-で定義
• reduce関数: ネストされたハッシュから値を抽出する際に利用

今回の作業は以上。最後までお読み頂きありがとうございました。

たなけん (作業時間30分)