引越業者の比較 アリさんマークの引越社(引越社関西) と サカイ引越センター


過去にアリさんマークの引越社とサカイ引越センターを使ったことがあるのでその時の比較を書いておきます。

使ったのは次の区間です。 私がすべて立ち会いました。

アリさんマークの引越社 (引越社関西)
2008年 京都府京都市から兵庫県宝塚市、 2013年 大阪府大阪市阿倍野区から東京都足立区 (14万円)
2010年 サカイ引越センター
兵庫県宝塚市から大阪府大阪市阿倍野区

総評

アリさんマークの引越社がおすすめです。 エリアによるとは思いますが、 私はもうサカイ引越センターを使うことはないと思います。

アリさんマークの引越社 (引越社関西)

  • 荷物の扱いが丁寧。 大きな荷物(電子レンジなど)は運ぶ前にほこりを拭いてくれる。
  • ちょっとした清掃などもおねがいすればやってくれる(10分間サービス)。

2回使いましたが、2回とも気持ちよく引越できました。

サカイ引越センター

  • いろんな荷物の扱いが雑。
  • 部屋の中に汗がどんどん(したた)り落ちる。
  • かなり安くできる。
  • 使用後の段ボールを取りにきた人が怪しい人。
  • 営業はしつこい。
  • 契約後の連絡が遅い・不十分。

西宮・尼崎エリアのチームは日本国内でもトップレベルだと営業が言っていましたが、さほどでもないです。

そのほかだとアーク引越センターを使ったことがあります。 立ち会ったのは私ではないので詳細はわかりませんが、 悪い話は聞いていません。


ネオスチグミンが最大濃度配合された目薬


ネオスチグミンが最大濃度配合された目薬を探してみましょう。 「ネオスチグミンって何?」という方は目薬に含まれる成分の効果をご覧ください。

続きを読む ネオスチグミンが最大濃度配合された目薬

テスト駆動開発でのテストコードの育て方


参考書籍は Test Driven Development By Example [ Kent Beck ]、 日本語版は テスト駆動開発入門です。

今回はテストのエッセンスについてです。 テストを書いて、実装コードを書き、機能追加していく中で需要なポイントを拾って書きました。 テスト駆動開発でテストを先に書く手順の続きになります。

Assert を先に書く

テストを書くときは Assert から書くのがいいそうです。 確かに、 ゴールから決めるのは常套手段ですね。

Assert から始めるに当たって、 まず考えるのは次の2つです。

  • What is the right answer? (どうなったら正しいといえるのか)
  • How am I going to check? (どうやってチェックするのか、何の値をチェックするのか)

本書に載っている例を見ると、 上の2点から始めて Assert 部分 から 存在しないクラスを使ってテストを書き始め、 最終的にテストを完成させているのがよくわかります。

テストデータ

Kent Beck によれば テストにおいて使用するデータにも鉄則があります。 わかりやすいもの、 すなわち 1 でも 2 でもよいのなら 1 を使うんだとか。

またシステムによっては 実データをテストに使うこともあると思いますが、 Kent Beck は実データは特に次のようなケースで有効であると述べています。

  • 実稼働している他のシステムで出力されたデータを使うリアルタイムシステムのテストをする場合。
  • 変更前のプログラムと変更後のプログラムによる出力を比較する場合。

特に難しい話ではありませんが、 一旦整理して頭に入れておきましょう。

テストの実装ルール

テストコードは一般的なプログラミングルールを逸脱することがあります。 例えばマジックナンバー。 というのも、 テストにおいては実装コードを完成させることと テストによるフィードバックを必要なだけ得られるようにするのが目的だからです。 MONEY EXAMPLE の章でもありましたが、 まずマジックナンバーを使うことで ひとまずのテストを完成させていました。

もういちど MONEY EXAMPLE の章で列挙されていた方法について説明されています。 Fake ItTriangulation がありますが、 一番最初におさえないといけないのは Fake It です。

Fake It (‘Til You Make It)

英語版102ページでは python でテストフレームワークを作っていたときの実例が紹介されています。 テストコードが Fake からどんどん変わっていく部分が再掲されています。

Kent Beck は Fake It のメリットとして次の2つを挙げています。 2つめのは 少し前のページにも出てきていました。

  • まずテストをグリーンにすることでコードに確信がもてる。 余計な心配をしなくていい。
  • わかりきったものでもテストを書いてグリーンにしておくことで、 今どの機能が足りていないかをわかりやすくする。

そこから Triangulation の話へと続きます。 内容は MONEY EXAMPLE で出てきた話の復習です。 復習なので割愛します。

パラメータを増やす場合

テストが完成した後で機能を追加する例として sum(int value) から sum(int[] values) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。


報告・連絡・相談の重要性


自律的な組織を作る目的で行った施策が、実質的にホウレンソウの運用にも役立っていたので、ホウレンソウの視点からまとめました。 報告・連絡・相談、通称ホウレンソウは重要だとよく言われますが、マネージャになって「報告・連絡・相談をしろ」と言ったことはありませんでした。

私は普段、「報告」、「連絡」、「相談」という言葉を使わず、「連携」だとか「連絡」と総称して呼んでいますが、 この記事ではできるだけ分けて使うようにしました。

続きを読む 報告・連絡・相談の重要性

テスト駆動開発でテストを先に書く手順


Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。

今回読むのは Section III のところです。 テスト駆動開発のパターン について書かれています。

Isolated Test

Test の独立性についてですが、 Kent Beck は過去の経験から次のように綴っています。

First, make the tests so fast to run that I can run them myself, and run them often. That way I can catch errors before anyone else sees them, and I don’t have to dread coming in in the morning. Second, I noticed after a while that a huge stack of paper didn’t usually mean a huge list of problems. More often it meant that one test had broken early, leaving the system in an unpredictable state for the next test.

続けて書かれていますが、 ひとつの問題が発生した場合に失敗するテストはひとつであるべきです。 問題の特定を楽にするために。

そんな独立性の高いテストを作る手頃な方法として、 “実行順序に依存しないテスト” が挙げられていますね。

テストを書く前に ToDo List

Kent Beck は彼の経験から、 目的を達成するためには (プログラムで実現すべきことを実現するためには) やることを全部書き出すというのがいい と結論づけています。 Money Example の中でも ToDo List を作っていました。

ToDo List のメンテナンスにも注意が必要です。 Kent Beck は新しい ToDo が増えたとき、 既存の ToDo 含め 次の3つのカテゴリに分けます。

  • いまやる
  • あとでやる
  • できなくてもいい

テスト駆動開発において ToDo List に書かれるのは Test として実装するべき事項です。 具体的には Section IMoney Example に載っていたものです。

ToDo の書き方

Kent Beck は 大変丁寧なことに、 ToDo の書き方まで説明してくれています。 これは早く実践していきましょう。

  • 考察が必要な項目については “???” をつける。
  • すぐに実装に取りかかれるように書く。
    1. 実装が必要な演算についてテストケースを書く。
    2. もし実装前の演算であれば、 その演算の null version (特殊な場合) のテストケースを書く。
    3. 必要だと思うリファクタリングをリストアップする。

なぜテストを先に書くのか

Kent Beck はテストを先に書く理由について、 次のように書いています。

  • コードを書くプログラマとしてのゴールは機能追加であってテストを書くことではないため、実装の後(目的達成後)にテストコードを書くことはない。 (目的達成後にテストを書こうと思わない。)
  • (コードの)デザインについて考える時間が必要。
  • スコープを制御するためのメソッドが必要。 ここでいうスコープは、後のページで詳しく説明が出てくるが、要するにテストを順次グリーンにして、今実装すべき機能(スコープ)を整理するということ。

確かに、 実装が先に終わってテストがおまけになってしまう、 そんな経験が多々あります。 更に Kent Beck は テストのモチベーションのサイクルについても言及しています。 テストのモチベーションは開発者にとって一番大事かもしれません。

Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

A Life Summary of an Gypsy