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


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

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

アリさんマークの引越社 (引越社関西)
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) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。


A Life Summary of an Gypsy