JavaScript は ES2015 以降、言語標準の機能が強化され、Array の操作だけなら別に Underscore / lodash は必要ないかなと思い、最近はできるだけ粘って入れないようにしています。
ですが、どうしても Object と Array の変換がコンパクトに書けません。
Ruby ならこういうので一発なわけですよ。
Hash[*[['a', 'b'], ['b', 'c'], ['c', 'd']].flatten]
# => {"a"=>"b", "b"=>"c", "c"=>"d"}
で、軽く変換方法を見るとまーだいたい副作用ベースで forEach で書くわけですけど、いやそれやりたくないなぁと思って、稀によく利用する lodash を調べたらありました。
_.fromPairs - Lodash Documentation
_.fromPairs([['a', 1], ['b', 2]]);
// => { 'a': 1, 'b': 2 }
なんてこった Ruby そのままというか、flatten がない分むしろスマートです。
逆もあります。
toPairs と toPairsIn の違いは本家ドキュメントを参照してください。
lodash v4 がリリースされたのが 2016年1月なのですが、コツコツ更新されてるんですねー。1
さらに、「これだけのために lodash 入れるのやだなぁ」と思う方のために朗報。なんと、個別に npm があります。
こいつらを使えば必要な function だけを導入できるわけです。いやー至れり尽くせり。
これを書いている時点で最新の 4.17.10 が 2018-04-24 リリース。Underscore.js の方も最新リリースが 2018-06 で継続中。 ↩
やってみた
内容は以下のような感じで、Node.js ネイティブ環境では動かないオブジェクトに対して、それでも期待通りに呼び出されたかどうかを確認するためのテスト。
describe('SpreadsheetApp return ActiveSheet', ()=> {
it('called getActiveSheet() once', ()=> {
// まず Node.js 環境で動かないメソッド呼び出しを stub out
// SpreadsheetApp -> Spreadsheet -> Sheet の構造があって、
// getActiveSheet() は中間のオブジェクトの持つメソッドで、どうやっても動かせない
// これを spreadsheet.book().sheet() の構造にマップしようとしている
// getActiveSheet() メソッドを持つダミーのオブジェクトを返すメソッドを stub out
sinon.stub(spreadsheet, 'book').returns({getActiveSheet: function() { return {} }})
// stub out したメソッドを mock にして期待する動作を設定
let book = sinon.mock(spreadsheet.book())
book.expects('getActiveSheet').once()
// メソッドを実行したのち、結果の verify
spreadsheet.sheet()
book.verify()
})
})
※ もちろんこれをコピペしても動きません
ポイント
- 恐らくイマドキ JavaScript のテストのかなりの割合は Node.js 上で実行されている
- Node.js 環境には存在しないオブジェクト、メソッドに対して期待する振る舞いを記述するために、まず stub out する（でないと実際に呼び出されてしまったらエラーになる）
- そのうえで stub out したメソッドが期待通り呼び出されたかどうかを mock で verify する
で、たぶん合ってると思います。間違えてたら教えてくだしあ。
参考
この中の mock の記述、分かったような分からないような感じなんですよね。というか RSpec の時もそうだったんだけど、mock の説明の記述って汎用的に書かれているとほんとによく分からないので、個人的には RR の記述が分かりやすくてよかったのでオススメです。
RR - a test double framework for Ruby
RR は RR の記述そのものがすごくシンプルで分かりやすく、意味の方に集中しやすくてよいです。（が、RSpec 3+ とは完全には統合できないので注意が必要）
読者10人と考えた「Excelレガシー」再生への道：ITpro
いきなり脱線して、レガシーをどうするかから離れて遺産を残さずに資産を残すにはどうしたらいいだろう、というところに問題意識が集中してしまったので、そこだけ書きます。というのも、自分は Excel レガシーには困ってないからです。ということで世迷い言を言ってる可能性はありますが、そこら辺を踏まえて読んでください。
個人的にはですが、Excel VBA は絶対にやんないっすね。分からないからとか、やれと言う上司がいないからというのもあるわけですが、やはり危険な匂いがプンプンするからです。これは別に内部統制がどうとかで最近言い始めたわけじゃないです。それは
データとアプリが一体化していいのはパーソナルユース限定
だと思うからです。iTunes とかね。
基本的なスタンスは、専門性の高くない人が個人で頑張って Excel を活用することまでは否定しないが、システムを専門にする人間は作っちゃダメ、という形。これは、専門性の高くない人ならそれほど大規模なものは作らないだろうから、というのと、そこまで禁止するとお互いにギスギスして仕事しにくいからです。難しいのは作り込み終わった Excel アプリを直したくなってしまうケースなんですが、これも手を出さないようにしてます。
どうしても必要ならExcel の外にひっぺがして別なものを作ります。この際は当然データ構造も明確に定義しますし、アプリ側も保守が可能であることを前提にフツーに作るわけです。
こういうのは Excel じゃないものに当てはめてみればすぐに分かるんじゃないかと思います。例えば細かい sh スクリプトが何本も絡むようなものって、組んでる最中は早いんですけど、あとで大変だなと思うわけですよ。そしたらこれはもうちょっと高級なスクリプト言語にして一本化すべきだなとか、ライブラリにすべきだなと思いますよね。スクリプト言語にすればドキュメンテーションも楽になることが多いですし。
もちろんシステムを専門にしない人には基本的にその辺の嗅覚がないわけですから、頑張り過ぎちゃった場合には大変なものが残ることはあります。Access とかね。
で。
ちょっと思ったのは、あえて EUC の分野にも構成管理やコミュニケーション、ドキュメンテーションの重要性を持ち込んじゃうのはどうだろう？ というか恐らくですけど、シスアドの教科書には構成管理はともかく残りの二つは載ってると思うんですよね。Excel などのマクロを組み始めるというのはすでにシスアドの世界に足を踏み込んでいるものと看做して、検定や参考書にその世界の知識、ノウハウも載せていくべきなんじゃないでしょうか。
いや難しいのはよく分かりますよ？ ただ、アプリを作った場合はその後の責任も考えるようにしましょうという、雰囲気や流れは作っておくべきじゃないかなと思うわけですよ。むかーしワタシ表計算検定なるものを受けたことがありまして、当時は Lotus1-2-3 のマクロだったわけですけど、その試験ではやはりマクロが組めるかどうかで話が終わってるわけです。恐らく現在の検定も似たようなもんじゃないかと思うんですけど、ここに、
マクロを組む際、あるいは組む前に注意すべきこととして、
- そのブックはみんなが使いますか？
- みんなが使う場合はどういう作業ができたらよいか、どういう機能がほしいかをまずみんなで相談しましょう
- あなたはいつまでその作業に関わりますか？
- それは引き継ぎ可能ですか？
- マニュアルや内部動作の資料をちゃんと作っておきましょう1
- 具体的な残し方
てな辺りを、もう試験内容として組み込んでしまうべきなんじゃないかと思ったわけです。
いやまぁ、現存してる Excel レガシーには何の効果もないですけど、今後ね、今後どうしたらいいかというときに、少しはマシになるんじゃないかな、とね。
……。
だから先に書いたでしょ！ 話ずれてるって！ べつに Dan メソッドじゃないよ！
Excel そのものにそういう機能が組み込まれればいいんだろうけど、ほんとに実現したらますます Excel きらいになりそう。 ↩
最近のはぶにっきが話題になっていたので惹かれて読んでみている。ああいう切れ味鋭い語り口の人の本は、読んでいて気持ちよくなるか頭にくるかどちらかだというのは分かっているので、安心して読める。（あんまり読書そのものが得意じゃないので、どう転ぶか分からない本を読むのは好きじゃないのだ。）
まだ半分くらいしか読めていないんだけど、これはかなりすっきりする本なのは間違いない。こちらに DB の基本的な素養が全然ないので突っ込んだ話はかなりの部分が分からないんだけど、それでも「ダメな設計って言うだけなら簡単だよな」と斜に構えた読者（つまりオレだ）にきっちりカウンターをかましてくれる。気持ちいい。
「ダメな設計」って言葉はあちこちで見る。それは設計が腐っているからだよ、と。しかしどこがどう腐っているのかをちゃんと言ってくれているものはあまり見ない。これは DB に限らずプログラミングでもシステムの管理でもなんでもいいんだけど、全般的に「こうするものです」的な話の流れになっている情報というのは「ではこうした場合なぜダメなのか」をあまり掘り下げてくれない印象がある。もちろんそれを掘り下げるのは面倒だし大変なんだってのは分かるんだけど、腐ってるとだけ言われても困っちゃうのも事実なわけだ。しかしこの本はなぜダメなのかが明確になっている。そこがいい。これは、設計のことはよく分からないが目の前にダメだってことだけは分かっている DB があるから、余計に強く感じることなのかもしれないけど。
ただ、3部構成1の半分くらい読んだところで思うのは、「これ構成後付けじゃね？」って辺り。というか先に対象読者と、それ以前のレベルの人はまずこれとこれを読めと明示しておいてほしかった。付録を見れば参考文献はいっぱい列挙されているのでこの手の本としてはとても嬉しい配慮がされているんだけど、事前に絞った情報を出してくんないと、さすがにこれ全部は買えないし読めないし。
まぁこの本自体は手頃な分量なので、とりあえず第1部と第2部は細かいこと考えずにダダッと読んじゃうのがいいかもしんない。DB のことが分かっている人ならスラスラ読めるだろうし、分からなくても無理矢理ザクザク読んでしまってとりあえずレッスンしてから戻ってきてもいいんじゃないかと思う。少なくとも何が分からないのかさえ分からないレベルでない限りはなんとか読める。あー早くレッスンに入らないと。
気に入ったフレーズを書き出してみる。（ママじゃないよ。）
- 正規化には数学的な意味だけでなく業務の視点からの正規化が大事
- アイデンティファイヤ重要
- 「コード」はユーザーインターフェイスであり、ユーザーの都合、ビジネスの都合によって変更が入るので、これをキーに使ってはいけない。
- 複雑な（例外や運用時ルールの多い）業務のデータ構造は複雑になって当然。データ構造を無理にシンプルにするとプログラムが複雑になるだけ。
- データは（業務ベースでいけば）「その企業のもの」であって、「企業内の特定の誰かのもの」ではない。
- 蓄積することではなく、何らかのレポートを生成することが重要。
- DBMS にも富豪アプローチを。あえて性能を出すためにデータ構造に手を加えるのは分かりにくくなるのでオススメしない。
2006-07-15 追記
レッスン前はとても気持ちよく読めたが、実際のレッスンに入ったらやっぱりさっぱり分からなくなった。おまけに参考書籍にはどうも考え方の参考になる系のものが結構あり、教科書系のものが少ない感じ。うーん。教科書系も当たり外れあるだろうし、その辺が知りたかったんだけど、そういう目的には使えないようだ。
あくまで個人的にだけど、この本を読む前後で何を感じたかを書いておこう。
- DBMS を使えばデータ構造とプログラムの構造を切り離すことができそうで、使いこなせたら圧倒的にプログラムの量を減らせて嬉しいだろうと思っていた予想はたぶん当たっている。
- 第n正規形だの正規化崩しだの、なんだかなぁと思っていたんだけどこの本ではそこら辺は重視しておらず、少し安心した。しかし基礎的な用語が分からないことには変わりないので、何かしら教科書用意しないとなぁ。
- しかしこの本に書かれているように徹底的に業務を洗い出すのはやはり難しいだろうなぁ。何しろ自分たちの行為に無自覚な人間が多いから。まぁでもそれは絶対に無理っていう変更の要素が思い浮かぶようになったら、たぶんそれを避けるノウハウが自分の中に貯まってくるだろう。プログラムもそんな感じだから。
- ちくしょう、教科書で勉強したらもう一回戻ってきてやるぜ。
付録を除いてね ↩
OptionParser は定義に反するオプションの与え方をすると例外を発生しちゃうんだけど、こんな書き方で対処できる。まぁ、optparse チュートリアルとマニュアルの例外処理のところを読めば誰でも分かるんですけど。
require 'optparse'
opt = OptionParser.new()
opt.on( '-f filename' ) { |src|
@srcpath = src
}
begin
opt.parse!( ARGV )
rescue => err
puts err.to_s
end
チュートリアルには InvalidOption だけ書かれていたが、実際には
- InvalidOption
- 未定義のオプションを指定した
- MissingArgument
- 引数の必要なオプションに引数を与えなかった
で、いずれにせよ rescue では特に何も記述せずに補足でき、補足した例外をそのまま to_s するだけで十分使いものになる。
$ ruby opttest.rb -f
missing argument: -f
$ ruby opttest.rb -c
invalid option: -c
便利だなぁ。
が役に立つかも。めんどくせーよ > Safari てゆーか KHTML もっとちゃんとやれ。
cygstart を使えば余計な bash プロセスなどは残らない。
- & でバックグランドに回すのではなく
- cygstart 経由でアプリを呼び出す
この方法でランチャ不要になるかも。
OS X の場合はアプリ本体が terminal から見る場合と Finder から見る場合で異なるし、プログラムの移動が気楽にできる MacOS の良い点が spoil されてしまうのでこの方法はまだ躊躇している。