ブログだと、見方によってはわかりにくくなってますね。
LINQ to Excelのテーマに絞ってで見ていた人にはわからなくなるところでした。
まあそんな熱心な読者がいるかどうかという問題もありますが。
Rubyで作業を進めているのにLINQもないということで、
SpreadsheetAdDataというテーマに変更して続行してます。
そろそろ曲がりなりにも公開版にたどり着きそうですね。
最初はドキュメントとかいいかなとかいう気分になってますし。
- Ruby on RailsのTipsを書いた本。
小さめの本ですが、様々な局面で利用できる方法がいろいろ書いてあり、
調べるのには便利ですね。
説明はわかりやすく、またサンプルも豊富です。
Ruby on Railsは機能が豊富で、Tipsの有効性は高いため、
こういう本は役に立ちます。
付録ではCoffeeScriptの文法の詳細な解説などもあり、
これも役に立ちますね。
Ruby on Rails 3 ポケットリファレンス/技術評論社
- ￥2,919
- Amazon.co.jp
- 最近モバイルアプリが増えています。
小さな画面で非常に高い使い勝手を実現しているものが多く、
UIの設計の要求はかなり高まっていると言ってよいでしょう。
この本では、そのテクニックをまとめて紹介しています。
テクニックといっても高度なテクニックだけではありません。
ツールバーや検索ボタンのような当たり前のことも載っています。
モバイルアプリや、そうでなくてもネットを日ごろから使っていれば、
直感的に知っていることも多いでしょう。
しかし、知っていることと使いこなせることの間には大きな隔たりがあります。
使いやすいアプリをきちんと設計するためには、
使ってみて、こういう使い勝手が便利ということがわかっているだけでは足りません。
なぜそのような使い方がよいのか、
理路整然とした理解がなければ、
自分のアプリケーションに応用することはできません。
それは難しく、本を読むだけで理解できるものでもないとは思いますが、
本にまとまっている知識が手助けにはなるでしょう。
これらのことが、具体的に実在のソフトウェアの画面写真とともに載っている本です。
また、現在ではまだ誰でも使っているとは言えないようなパターンも紹介されています。
見た覚えくらいはあるのですけれど。
また、アンチパターンも紹介されています。
総合的にモバイルデザインパターンを学ぶために、
モバイルアプリの開発者なら、
一度は読んでおくべき本でしょう。
モバイルデザインパターン― ユーザーインタフェースのためのパターン集/オライリージャパン
- ￥2,730
- Amazon.co.jp
昨日ここに書いた意見は、
仕事でプログラムの生産性について出た意見がどうもおかしいと思ったので、
まとめてみたわけですが。
そもそも生産性の追求が、
プログラムのオプションで存在するもの、
と思っている人が多いらしいです。
いやそんなことはないと思うんですがね。
プログラムの生産性というのは、
プログラムという商品の原価なのだから、
商売でやっている以上は、
それを切り離して何かするというのはあり得ないんですけどねえ。
実際、手段と目的を意識して働いていたなら、
プログラムで商品を生産する過程はほとんど、
生産性を落とさないための作業で占められているんですけどねえ。
設計品質落とさないのだって、技術力あげるのだって、大体その目的でしょう。
なんとなくプログラム組んでいると忘れることが可能なのか。
さてここが通じていないと仕事ができないので、
まわりの人間を何とか動かさないといけないわけですが。
私に何とかできる問題なのか。
はてさて。
まあ社内の人間がここ見る可能性もあるわけですが。
たぶん来ませんけど可能性は。
どうせあきれてんのはばれてそうだからまあいいですね。
ばれているから動かないのかもしれませんが。
しかし。ちゃんとしてほしい。切実に。
商品を作っている職業プログラマーにとって、生産性は非常に重要な要素です。プログラムに限らず、商品を作る場合に原価は非常に重要ですが、プログラムの場合には原価はほぼ製作者の作業量に比例するのですから。
また、オープンソースプログラマーや研究者の場合は多少関係があいまいになりますが、原理的には同じことが言えます。お金には換算しにくくなりますが、作業量が有限なリソースであるという点では同じです。
プログラムにおいて生産性は重要なので、生産性を上げるために学ぶべきことはたくさんあります。プログラマーは比較的学習を求められる職業ですが、必要とされる多くは生産性にまつわるものです。
もちろんすべてではありません。たとえば効率的なアルゴリズムを求めるという学習もあります。これはあまり生産性には関係してきません。でも、効率的なアルゴリズムについての技術書は全体の中ではわずかですね。
学問的なものでは、設計に関するソフトウェアメトリクスなどの研究もされていますが、それを測る意味がなんであるかというと、それは生産性が上がるということにほかなりません。どんな設計をしたところで、無限の時間を与えられてコーディングとデバッグを繰り返せば、いつかは完成するわけですからね。有限の時間を有効に使う必要があるから、プログラムの技術は必要とされるのです。
しかし困ったことに、生産性を定量的に測定する方法は確立されていません。
現代科学の成果は定量的な測定によって確実な結果を積み重ねることによってなされてきました。プログラムの生産性を定量的に測定することができれば、様々な技法の優劣を細かに検証することができるため、有利な技法のみを組み合わせることができ、プログラムの生産性は飛躍的に上がることでしょう。しかし残念ですが、プログラム業界でそういう現象はまだ起きていません。
もちろんプログラム技術の研究の初期には定量的な測定の試みは行われ、結果も出ていました。たとえば古典的名著「人月の神話」には、プログラマーによって生産性に10倍の差が出るという結果がのっています。
ただその後の報告が続いていないようです。論文などに目を通して言っているわけではないので、純粋に学会レベルでは成果も出ているのかもしれませんが、書籍で紹介されるようなレベルで活用できる数字は数十年出てきてない模様です。
そして、最近ではプログラム業界の偉い人が、生産性を測定するなどそもそもあきらめろと言っています。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?MeasuringProductivity
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity
プログラム業界に「計測できないものは制御できない」という言葉を広めたトム・デマルコは、
http://www.amazon.co.jp/dp/4764901331/xpjp-22
後年を撤回し、計測の効果を計測することはできていない、と言っています。
http://www.amazon.co.jp/%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3%E5%A4%A7%E3%81%84%E3%81%AB%E8%AA%9E%E3%82%8B%E2%80%95%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A224%E3%81%AE%E9%96%83%E3%81%8D%E3%81%A8%E5%86%B4%E3%81%88-%E3%83%88%E3%83%A0-%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3/dp/4817160578/ref=cm_cr-mr-title
プログラムの生産性の測定は誤差が大きく、たぶん実用レベルで測定することは現代の科学では不可能です。計測できないことが実証されたわけではないので、将来もできないとは限りませんが、少なくとも現状でそれを行うには大変なコストがかかり、現実的ではありません。
信用できない数字を探すことにコストをかけることや、また信用できない数字を信じて対策を立てることは、生産性を上げる邪魔にしかなりませんから、そのような数字はだんだんあげられなくなっているようです。
それでも、しばらく前まではRuby on Railsの生産性がJavaの10倍という話があったように、宣伝文句には数字が挙げられていたようです。しかし、最近Visual Studioの宣伝で生産性の向上は数字では挙げられていません。現代では、宣伝にすらそんないい加減な数字はだされなくなっているようです。
ただ、生産性の向上を定量的に計測することが不可能だからと言って、生産性の向上をしなくてもよい、ということにはなりません。多くの開発者は現代も生産性を向上させるための努力を行っています。自分だけが行わなければ、自分の作成するソフトウェアの価格競争力がなくなるだけのことです。
測定を定量的に行うことが不可能なら、定性的に行えばよいのです。科学的に厳密な検証には使いにくくなりますが、人間が一般的な活動で法則のほとんどは定性的にしか得られていませんので、十分に役に立つといえます。
プログラム業界の話を具体的にすると、一つ一つのツールや工夫を試してみて、労力が減るかどうかを主観的に判断すればよいのです。
実験とかを見慣れていない人にはこちらのほうが理解しやすいとも言えるでしょう。
定量的な測定と違い、一つ一つの工程について確実な効果を積み重ねるというわけにはいきませんが、工夫は大量に行われますから、一つ一つの効果を確実に確認する必要は必ずしもありません。一定の割合で役に立たないものがあったとしても、全体的には効果があることは認められるでしょう。
可能であるなら、数社の単位で総合的な生産性の測定を行うとよいでしょう。ただ、Micorosoftが自社のツールについてそういう数字を発表できていないことを考えると、相当大規模なデータをそろえないと、意味のある数字は出せない可能性が高いですが。
そもそも努力したことを客観的に確認できないから何も努力しませんってわけにはいきませんからね。プログラム業界に限らず、目に見えない努力の上に世の中は成り立っているのですから。
現状では、数値測定ができないから無駄とは思わずに努力を続けていく必要があります。
- もうすぐ発売される、Windows8の機能について書かれた本。
Windows8は、単なる新OSというだけではなく、
UIデザインの方針やAPIを一新してきているため、
プログラマーは注目をしておくべきです。
最初にその辺の説明を持ってきていますね。
ネットにもいろいろな情報は書いてありますが、
書籍だけあって一段突っ込んだ説明になっています。
また、それ以外にもOSの新機能もいろいろ説明してありますし、
読んでおくべき本ではあるでしょう。
Windows 8 新機能徹底検証 (インプレスムック)/インプレスジャパン
- ￥1,890
- Amazon.co.jp
このブログは、
基本的にプログラムに関係のあるネタに限っているので、
量的に毎日は無理なのですが。
書いても書かなくてもいいというのはどうにも続けにくいので。
毎日書いて、書くことがなくなったら休んで、
またたまってきたら毎日書く、という流れで行きたいものですね。
基本的にプログラムに関係のあるネタに限っているので、
量的に毎日は無理なのですが。
書いても書かなくてもいいというのはどうにも続けにくいので。
毎日書いて、書くことがなくなったら休んで、
またたまってきたら毎日書く、という流れで行きたいものですね。
Windows8の発売までひと月を切りましたが、
Surfaceの発売についての情報が出ていません。
10/26に発売されるという話ですが、
アメリカ以外では出ることも決まっていないような。
出て、安ければ買いたいものですが。
はてさて。
出てほしいものですね。
Surfaceの発売についての情報が出ていません。
10/26に発売されるという話ですが、
アメリカ以外では出ることも決まっていないような。
出て、安ければ買いたいものですが。
はてさて。
出てほしいものですね。
休暇中の勉強はおおむね技術書を読むにとられてしまいましたが、
Rubyで作っているSpreadSheetAsDataの開発を少し再開することができました。
なんだかんだ言って全然進みませんが、
多少は進んでいるのはよいことですね。
ブログのアクセス解析を見てみると、
月に一度くらい、Excelの読み書きライブラリを求めてこのブログにたどり着く人がいるらしく、
なんとなく申し訳ないです。
いやまあ、ググってみて見つけたと思ったら実装はまるで使えないとか、
よくある話ではあるんですけどね。
冷静に考えるときにする必要はないんですが。
まあ早く進めねば。
終わったらC#に移植する予定になっているのですが。
いつになることやら。
会社で新技術を導入するのは難しいですねえ。
腕の良い職人がいなくては、
お金をもらおうとしても無理だと思うのですが。
別にお金を出したいから商品を買う人はいないわけで。
まず買ってくれるだけの価値を創出しないと、商売は無理なのだが。
まあ良い職人がいるだけでもお金は儲かりませんがね。
はてさて。
どうしたものか。
腕の良い職人がいなくては、
お金をもらおうとしても無理だと思うのですが。
別にお金を出したいから商品を買う人はいないわけで。
まず買ってくれるだけの価値を創出しないと、商売は無理なのだが。
まあ良い職人がいるだけでもお金は儲かりませんがね。
はてさて。
どうしたものか。