余裕が必要
自ら何かをやろうと思うと余裕が必要だ。余裕といってもたくさんある。健康、お金、時間などだろうか。
今の所、健康やお金には困ってない。（決してお金に余裕があるわけではないけど、普通に生活ができて、やりたいプログラミングは無料でできる範囲が広い）
問題になってくるのは時間。まず子育て期なので家ではなかなか自分の時間が作れない。勉強を見るし、お風呂も入れる、食事の世話から、オムツ替え、体調を崩せば病院にも連れて行く。なので自由な時間は、今このブログを書いている通勤電車の中と子どもが寝静まった後だ。
こんな中、仕事が忙しくなると辛い。仕事が忙しく家に帰るのが遅くなるので、妻が子どもことをやることになるので、むしろ楽だろう。というと、そうではない、任せっきりで申し訳ない気持ちになり、精神的に辛い。
取り返そうと思い、帰ってから食器を洗ったり、お風呂洗ったり、洗濯をしたり、できる範囲で家事をする。
そんな感じで忙しくなるとふと時間が出来たときは、だらけたくなる。ゲームやテレビで時間を潰してしまう。ビールを飲んでしまう。むしろ寝た方が良いのにダラダラしたくなる。
こうなると悪循環なのだけど、どうしたらよいか？
仕事については効率が悪くなってる。ダラダラ仕事をしてる場合もある。可能なら気を引き締めて、集中して仕事を一つ終わらせる。集中出来ないならかえって寝る。
家に帰ってダラダラモードになってると思ったら、ゲーム禁止、テレビ禁止、ビール禁止で速攻寝る。家事そっちのけで寝る。
とにかく気持ちの切り替えが大切だと思う。経験的には2度ほど連続して気持ちを切り替えれれば、その後スムーズに行く。
実はそういうモードになりつつあるので、今日から実践だ！
ハッカソンに参加
先月の終わりに初めてハッカソンに参加した。とても面白く、刺激を受けた。自分の成長にもつながり、また参加したいと思う。
ハッカソンに参加して大切なことを学んだ。
1.新しいアイディア
多種多様な人が集まりアイディアを出し合うので、自分では思い付かないようなアイディアが出てくる。三人寄れば文殊の知恵というけれど、自分だけではなく、みんなで考えることの大切さを学んだ。
2.モノを作ってデモ
ハッカソンでは最終的にアイディアを形にしてデモをする。アイディアだけでなく形にすることで現実的な課題もわかる。さらに限られた時間の中でデモまで持っていく必要があるので集中して開発する。大変な面はあるけど、デモまで持っていけると達成感もある。
3.人と人のつながり
最後に1番大切なのは人と人のつながりだと思った。他の人がいるからアイディアが出る。他の人も頑張っているからデモまでいける。など人と人のつながりは大切だ。さらに終わった後に振り返りをしたり、飲みに行ったり、SNSでつながってその後も影響を与え合ったりと偶然の出会いを大切にしたいと思った。一期一会を大切にしよう。
とにかく楽しんだハッカソン。また参加したいと思う。
文章を書く方法
ブログ書いてると途中から書きたい話からずれて、違う話になっていることに気づいた。そこで数学の問題を解くときに重ねて解決策を考えてみた。
（数学を教えることがあって、生徒が問題を解くときの課題に近いと思ったからだ。）
数学の問題を解いていると、色んな式が出てくるうちに、そもそも何を解くのか忘れてしまうことがあるのだ。
例えば2次方程式と直線に囲まれた面積を求める問題だとしよう。交点を求めて、その解の範囲で積分する。
最初に交点を求める必要があるため、2つの式を連立させて解く。そこで次にやることがわからなくなってしまうのだ。
積分をするのを忘れて求めた交点を答えとしてしまったり、積分しようと思っても積分範囲がわからなかったりするのだ。
ここでの課題は2つあると思う。
1つ目は全体の流れを理解できてないこと。とりあえず交点を求めたり、積分をしようとしてみたりして、前後の関係がわかってないのだ。
2つ目はそれぞれの計算問題の習熟度が十分でないこと。必要な条件が準備されていて交点を求めよとか、積分して面積を求めよという問題は解けるのだが、まだスラスラ解けるわけでなく、頑張って解いている。そのため全体を考える余裕がない。
ではどう解決するかというと、全体の流れを最初に考えることと、基本的な計算問題はスラスラ出来るまで練習すること。
私がブログを書くときも同じ状態なのだろと仮定して以下のことを試してみようと思う。
まずはブログで書きたいことを凝縮してタイトルを決める。
次に段落ごとのサブタイトルで全体の流れを決める。
最後にサブタイトルごとに文章を書く。
後はブログを毎日書き、習熟度を上げていく。
ちなみに私は文章のプロではなく、むしろ底辺の方なので、上記のやり方の効果は全く無保証。逆にいい方法を教えて欲しい。
「継続は力なり」なので、まずは続けよう。
子育て期の土日は自由な時間か？
金曜日に毎日ブログを書くと決めて、さっそく土曜日書けなかった。平日は通勤時間中に書こうと決めたが、土日はどうするか。土日というと休みなので時間があるじゃないかと思われがちだが、子育て期は違うと思う。
土日は子どもも休みで家にずっといるので、ほぼ自分の時間を作れない。食事の世話から始まり、家事をしつつ子どもの遊び相手、子どもの勉強を見たり、するとまた食事の時間という感じで、一日中忙しい。
はっきり言って、通勤時間や休み時間は自由に使えるし、大人はわがまま言わないし、自分のペースで仕事ができるし、仕事の方がかなり楽だと思う。
子どもと一緒に遊ぶ時間というのは、自由な時間とも言えるが、自分のためだけに使っているわけではなく、例えばブログを書くネタにはなっても、書く時間にはならない。
そういった意味では土日は自由な時間にはならないだと思う。主婦（夫）で毎日子どもの世話をしている人は、さらに大変だろうと思う。
とは言っても、毎日ブログを書くと決めたので、土日も書いていこうと思う。子どもが寝た後か、朝早く起きるか、どちらかになると思う。時間は作るものだから、自分の大切な時間を有効に使っていきたいと思う。
毎日ブログを書くこと
WEB+DB100号に「あのときの自分へ」という記念エッセイがあった。その中に「勉強すべきこと、すべきでないこと」という記事があった。
勉強はすべきだけど、技術進歩の早い今、すぐに廃れる技術がほとんど。そのため賞味期限を意識して勉強することが大切。
でも根源的な学習、数学やアリゴリズム、オブジェクト指向の設計コンセプトなどは簡単に廃れない。
汎用的な知識もそうだ。勧められてるのは「勉強法」「リサーチ方法」「仮設検証」「改善」に関するノウハウ。なるほどと思った。
最後にブログを毎日書こうと思ったきっかけでもある最も効率のよい勉強法。それはブログを書くこと。記事を書くために、しっかり調べ、実験する。それが結果として自分の身になる。
ブログを書こうと思ってもなかなか継続できなかったけど、今回は頑張ってみようと思う。今の自分にとって毎日自由に使える確実な時間。それは通勤時間。この時間にブログを書こうと思う。
しかしただの日記ではなく自分で感じたこと、学んだことが次につながるような内容にしようと思う。
今変われば間に合う。今日から頑張っていこうと思う。
Excel VBAで使える自作のテストフレームワークを使って、実際に開発してみた。
はじめに
以前にExcel VBAで使えるテストフレームワークを作ったので、自作のフレームワークを使ってみて、実際に開発してみました。
前回の日記の記事を見ると半年以上たっていますが、2度ほど開発に使ってみて改善を加えました。
実際に使ってみると
実際に使ってみると、すぐにエラーが発生しました。テストモジュールにsetUpを定義していなかったことが原因だったことを今でも覚えています。
テストフレームワークを作って、テストもしているとはいえ、実運用だと簡単にエラーが発生してします。あるあるですね。気づけば簡単なことですが、開発しているときは気づかないことはあります。
最初にエラーが発生した時はフレームワークは修正せずに、setUpを定義して使っていました。
その後も、クラスやモジュールごとにテストモジュールを分けようと思ったら、今度はsetUpが両方に定義してあると重複してエラーになりました。結構悲しくなりましたが、テストモジュールは1つで行うことに決めて、またしてもフレームワークは修正しませんでした。
その後もいくつかバグがあったのですが、バグリストとして残しておき、今回はとりあえず運用回避で乗り切りました。
2回目の使用
その後テストフレームワークを使う機会がまたやってきました。今回はすでにバグリストがあったので、まずはテストフレームワークの修正に入りました。
運用回避できるものもあったのですが、さすがに許せないバグもあり、直せるバグはすべて直そうと思いました。
（実はアサーションの失敗を出力するのですが、最後のアサーションの結果が出るようになっていました。しかも途中で失敗していても、最後の成功の結果が出ていたので、エラーの個所が分からず、これは開発にかなりの影響が出ると思ってバグ修正した次第です。）
すべてのバグを修正できたわけではないですが、修正したことでかなり使い勝手はよくなりました。
テストフレームワークの効果
実はこの開発は以下のような経緯をたどっています。
新規開発（以降v1と呼びます）は、テストフレームワークを使用せず、自分で結果を比較して、正しいかどうかを判定してテストをしていました。
その後の改修（以降v2と呼びます）で、自作のテストフレームワークを適用したのですが、v1のテストはそのままにして、v2の新規機能分だけテストフレームワークを使用しました。テストフレームワーク分は快適だったのですが、v1に影響が出る部分で再テストするときは使い勝手が違って不便でした。
その後の改修（以降v3と呼びます）で、全面的に自作のテストフレームワークを適用して、v1のテスト部分もテストフレームワークで書き直しました。
v1のテストを書き直した時に、テストコードがシンプルになって、読みやすくなって、テストフレームワークの威力を感じました。テストコードは半分以下になったと思います。また結果の確認も簡単になり、開発がかなりスムーズに進むようになりました。
おわりに
自作のテストフレームワークは、ケントベックのテスト駆動開発入門を読んで、自分で作ってみたのですが、軽量なフレームワークなのに、その効果は絶大だと思いました。しかもxUnitは、色んな言語に移植されているので、使い勝手が言語が違ってもあまり変わらないというのも素晴らしいと思います。
何よりちまちま自分でテストコードを書いて比較して、とやるよりテストフレームワークを使うことによって効率が格段に上がることを体験しました。
自分で作ったテストフレームワークが自分で実感できるほどの効果があり、とても嬉しくも感じました。
今回の開発を踏まえてのv1.0.2をリリースしましたので、Excel VBAを使って開発している人がいましたら、ぜひご活用ください。
