Excelの読み書きライブラリがそこそこできてきましたね。

C#版は放り出して、Ruby版の実装を進めていますが。

基本機能は一通り、実装できましたかね。
まだ穴は大きいのも含めいろいろ残っていますが。
まあその辺はおいおい。

いや早急に埋める必要があるものもありますが。
まあ一段落。
はしてますね。一応。

少なくともごく基本的なインターフェースはできました。

現状では、

WorkBook.open('C:\Book1.xlsx') do |book|
  x = book.Sheet1.A3
  y = book.Sheet2.B5
  book.Sheet1.A1 = x + y
end

という感じですね。
まあまだ基本機能だけですが、割といい線いってきていると思います。
まあ続けましょう。

ソースの公開は
https://github.com/potimarimo/SpreadsheetAsData
このへんで。

「まつもとゆきひろコードの未来」を読んで

Rubyを作った人として、
最近たぶん日本で一番有名なプログラマーである、
まつもとゆきひろさんがコードの未来について書いた本。

前半は、コードについて。
過去から未来への流れについての解説です。
言語作成者にして言語マニアで有名なまつもとゆひきろさんだけあって、
非常に含蓄のある解説になっています。

言語の未来への話としては、
goとDartとCoffeeScriptとLuaがあげられています。
低レベルを得意とするものが多いですね。
なんとなく、立ち位置的にはRubyのほうが新しいのでは。

むしろRubyの設計思想とかを語ったほうが、
言語の新潮流という意味では参考になったとような気がします。

まあ、今Cが活躍している分野でも、
新しい流れは来ているという説明にはなっていますね。
そういう説明も重要でしょう。

多種類の言語を俯瞰的に見て言語について解説した本としては、
大変素晴らしいものになっており、
役に立つものとなっています。

後半は、ビッグデータとかマルチコア関連の解説です。
こっちはまつもとさんの本職とは離れた部分で。
とはいえ楽天のビッグデータ関連のお仕事もやっているらしいですけどね。

私もこちらはそんなに詳しくないのですが。
最近のデータ関連は、低レベルな分野に踏み込んでいるものが多いですし。
とはいえ、わかりやすくためになる解説になっているのは間違いないですね。

いろいろな言語から呼び出す方法が書いてありますが、
Rubyのものもありますね。
説明にわかりやすい言語を使っているだけのようですが。

とりあえず低レベルな分野もこれからますます発展していくことと、
でも利用者としては、割と高レベルなAPIを利用しても使える、
ということはわかりました。

低レベルな部分もわかっておかないと、かえって遅くなって意味がない、という局面はありそうなので、
理解はしておく必要があると思います。
逆に実際に使うときはさらにもっと高レベルなAPIが必要な気もしましたけれど。

詳しい知識がなくては使いこなせないということは、近年減ってきましたが。
概要を理解しておかねばならない分野は、やはり広くなっていっているようですねえ。

あと、Rubyはマルチスレッド対応が大変弱いため、
マルチコア時代に対応できるのかという不安がありましたが。

作者はその辺もちゃんと考えているということがわかりました。
メモリ共有を伴うスレッドは、高レベルなプログラミングでは使い出がないので、
あえてプロセスに力を入れているということのようです。

そういえば、並列処理に強いことで有名になったErlangも、
プロセスを使っているみたいですしね。
そういう方針でも十分にマルチコア時代に対応できるのかもしれません。

いろいろと役に立つ本でしたね。

まつもとゆきひろ コードの未来/日経BP社

￥2,940

Amazon.co.jp

毎日書くのは大変ですね

プログラムに関することに限定したブログで毎日書くというのも、
考えてみればちょっと不可能に近いような気もしますね。

一日分のブログに書く知識量と、
一日平均の学習量を比べてみると、
前者のほうが多いような気がしてきました。

土日頑張れば何とかなるかもしれませんけれど。
はて。

勉強会ネタを書くと一週間持ちそうですが、
何となく噂話みたいでいやですしねえ。

まあ続くところまで続けてみましょう。
これまでに考察した話とかをつなげてなるべく。

Ruby調査の進捗

最近、いろいろあって、どうも勉強が進んでいませんね。

家でやっている、Excel読み込みライブラリ作成は、徐々にだが進んでいますが。

会社の昼休みにやっているRailsのほうは全然進んでいませんね。

いやまあ、そういえばお昼休みは代わりに技術書読んでいるので、そういう言い方をする必要もないのかもしれませんが。
お昼休みに読めるような簡単な技術書ですけどね。

進まないとどうも不安なので、
こういうときは一本化とか考えたほうがいいのかもしれませんねえ。

テスト駆動開発を使ううえで気になったこと

テスト駆動開発は、
きちんとテストを書くところから始めると。

一行一行しっかりとテストされたコードと、
実際に動かない部分を検出できることが確認できたテストが、
システマチックに出来上がる仕組みになっています。

ただ、リファクタリングを行って出てきたクラスなんかは、
そういう手法が使えません。
テストかく前にクラスができてしまっていますからね。

今そういうところのテストを書いているわけですが。
どうしてもテストがいい加減になりがちです。

これはどうするべきなのか。

頑張って気合の入ったテスト書くしかないのですかね。
あまり本質的な解決になってませんが。

なかなか悩ましいところです。

とりあえずRedmineの導入に成功

昨日失敗していたといいましたが、
とりあえず成功しました。

うまくいかなかった原因は、
設定ファイルを例からコピーして、
修正したつもりが修正が漏れていたところです。

環境が苦手といいつつ、
インストールの開設にないSQLiteを選択するというのが無謀でしたかね。
苦手とはいえ素人ではないのだから、無謀というのもあんまりのような気がしますが。

うまくいかない間違いをする場所が１，２か所程度であるなら、
問題の切り分けは簡単なのですが。

間違う可能性がある個所が何か所もある状況だと、
複数の間違いが連動して収拾がつかなくなってしまいます。

そして苦手感が増していくわけです。
オールマイティな人って、この辺をどうやって克服したのでしょう。
全分野において、苦手がなくなるまで勉強しているんでしょうか。

まあとりあえずローカルで試験運用してみましょう。
そのうちHerokuにでも公開してみましょうかね。
公開というか、外からでも使えるように。

Redmineの導入を試みました

基本的に私は環境系の知識は弱いのですが、
あまり弱いとばかり言っているわけにもいきません。

ので、その辺の不安から導入を見送っていた、
Tracを導入しようとしていみました。
と、とある掲示板でその話をしたらいきなり時代遅れになりかかっているという情報をいただきまして。
やっぱりRedmineを導入しました。

個人でのライブラリ開発やっているだけでも、
ある程度ちゃんと進んでいると、
機能追加予定がだんだん頭からあふれていくのですよね。

しかし。
うまく導入できず。
今日はそこまで。
残念です。

ある程度手動でやろうとしてあきらめ、
仕方ないのでAllInOneインストーラを利用しようとして、
それでなお動きません。
何なのでしょう。

基本知識が弱い分野だと、トラブル回避が難しく、
いろいろうまくいかないものですね。

Apacheが何たるかもよくわかってませんし。
いやまあサーバーなことはわかってますが。

その状況でWindows8を普段使いしようというのが間違っているのでしょうかね。
対応しているという保証はないですし。
いや、たぶん関係ないとは思うのですが。

後日また挑戦、ですね。

私はなぜRubyを学ぶか

手を動かしてちゃんとプログラムを作り始めたのは最近ですが、
数年前からRubyの書籍などをよく読んでいます。

仕事とかでRubyを使う予定は今のところありません。
個人のスクリプトとかなら使うかもしれませんが。

単に便利というだけなら、C#を使えばよいです。
IDEのサポートが強力なのは、
資料調べるのが面倒な人間には大変うれしいものです。

それなのに熱心にRubyを勉強したいと思うのはなぜかというと。

どう見てもRubyのライブラリが先進的だからです。

プログラムの読みやすさというのは、時代とともに進歩していきます。
昔は十分だった読みやすさでも、今は足りません。

FORTRANができた時は、
こんな簡単なら素人でも書けるので、
プログラマーはみんな職を失うのではないか、といわれましたが、
そんなことにはなっていません。

むしろ今の時代、FORTRANは難しい言語という人のほうが多いでしょう。
最新のFORTRANならともかく、初代のFORTRANは確実に難しいです。

なぜそうなるかというと。
プログラムが簡単になると、プログラムしなくてはならない内容も、より難しくなるからです。
簡単にできるなら、これもこれもこれもやって、ということになり、
結局は難しくなります。

そして、それをもっと簡単にできるプログラミング言語が開発される、ということが繰り返されています。

ということでプログラムは進歩し続けているのですが、
その進歩は、プログラム業界全体で影響を与え合いながら行われています。

プログラム言語に著作権はないですからね。
パクリ放題です。
そうやって、お互いにほかの言語の良いところをどんどん取り入れて、
全体的によくなっていくのです。

だから、ほかからまねされるような新しいものを持つ言語を学んでおくと、
その特性はほかの言語に真似されていくため、
長らく役に立ってくれるということですね。

また、そういう言語を学んでおくと、
その性質の一部だけでも、ほかの言語でプログラムするときに応用することができます。

そしてRubyは、
ほかの言語に真似されるべきすぐれた特性を、たくさん持っています。
だから学んでいるのですね。

なんか眺めになってきましたし、
具体的にどうすぐれていると思うのかは、
また後日に。

プログラムの美しさについて、修正

以前、Preziで公開して、
ここでも紹介した「プログラムの美しさについて」という資料ですが。

とあるチャットで物理学者の人にあったので、
相対性理論のあたりを添削してもらったところ、
微妙に流れがおかしい点があったようなので、
修正しました。

マックスウェルの方程式から直接光速不変の法則が出るというのはちょっと言い過ぎでしたね。
ということでエーテルの説明を入れてみました。

まあ、主題であるプログラムの美しさにはそんなに関係してこない修正ですけれど。
むしろ話が回りくどくなって美しさがわかりにくくなったかもしれませんが。

とはいえ。
誤解を招くような表現はよろしくないですしね。

http://prezi.com/2qy5mdthm4wp/presentation/

毎日書くのは難しい。

毎日書いているとネタが尽きてきましたね。

まあプロではないのだから、毎日面白い記事を思いつくものでもないですかね。
つまらなくて内容のほとんどない記事も、たまに混ぜ込む必要があるでしょうか。
いやいつものが面白いうというわけでもないですけれどね。

毎日書くのは文章の練習という意味合いもありますから、
それでも続けたほうがいいですよねえ。
毎日というペースを崩すと、ずるずると休んでしまいますし。

とか書いていると内容のない記事が一本できました。
今日はこれにしておきましょう。

人間、継続は大事ですね。
とか教訓の一つもつけて。