« July 2018 | Main | September 2018 »

模型制作に卓上掃除機が便利!

最近の模型用の工具やマテリアルはすごいですな。私の子供の頃はホームセンターなんかが宝の山で、いろいろな工具を「これは模型制作に使えるんじゃないか?」と思って探していました。ニッパと接着剤はプラモデル製作の象徴とも言える工具とマテリアルなので早い段階から専用のものがでていましたが、デザインナイフ、目立てヤスリ、瞬間接着剤、ドリルとピンバイス、プラパイプや木工パテなど、模型専門ではないものの中から「定番」のものが出来ていったものでした。

ところが、時代は流れました。この「知らないと損する工具選び」というモデルグラフィックスでお馴染み大日本絵画さんの工具の紹介本では、ほとんどの工具やマテリアルが模型専門のメーカー、例えば田宮、長谷川、ウェーブ、GSIクレオスなどから販売されています。すごい時代になったもんだなあ。

いろいろと気になる工具やマテリアルがたくさん載っていて、この本はとても楽しいです。言うなれば、模型が趣味の人にとっての工具の話ってのは、釣り好きの仕掛け談義みたいなものですから、これはもう楽しくないはずはないのです。

で、ですね。そんな知恵と工夫が凝らされまくった模型専用工具の数々の中に、卓上掃除機が取り上げられてました。曰く、「模型制作とは、これすなわち"粉を作り出す"作業なのだ」。言い得て妙ですな。昔は学習机の手前の引き出しをゴミ箱にして(これも模型誌で学んだやり方だった気がする)、切りくずなどは手前にさっと払って引き出しへ捨ててましたが、今の机は引き出しなんかありません。

パーツから除去したゲート(ランナーとパーツのつなぎの部分・・・って、ゲートがわからないひとはランナーもわからないよな)は直径2mmぐらいのプラスチックの粒として机に上にたまるわけですが、それを指でつまんでは箱に集めてまとめて捨てるんですが、こぼしたり、ひっくり返したりで床に蒔かれてしまうこともままあり。

そこでこの卓上掃除機。手のひらにすっぽり入るぐらいのコンパクトさで切りくずがでたら上からさっと吸い取ります。ああ、快適。これいいわ。プラモの組み立ての必須工具といえば、ニッパに紙やすりの2つだけですが、これを入れてもいいぐらいです。これは気がつかなかったなあ。というわけで、おすすめです。誰にだ?

| | Comments (0) | TrackBack (0)

便座を交換した

自宅の便座を壊しました。

ちょっと体重がね・・・増えすぎたね。

便座というものは、便器にボルト2本で固定されているものなのですが、そのうちの1本が根元からポキッと折れました。まあ、よく知りませんけど築20年近くの賃貸マンションですから、その程度の故障は普通に起こりうることです。うん、しょうがない。しょうがないよ、うん。

で、イマドキは便利なもので交換方法もググれば普通に出てきます。便座というものはユニバーサルな規格で、ボルトの間隔は統一されていて、便座のサイズが普通のと大きいのと2種類ある程度のものらしいです。最近は温水洗浄便座が一般化したことにより、ホームセンターなどではなく電気屋で普通に買えるし・・・というか、Amazonでいくらでも売ってます。普通の便座を買っても5,000円ぐらいするみたいですが、温水洗浄便座も安いものは15,000円程度で買えるみたい。壊しちゃった便座は捨てるしかないわけで、となると引っ越すときに持って行くわけにもいきませんから、そんな高い便座をつけるのももったいないですけど、15,000円ならまあいいかなって感じですよね。

というわけで、適当に買いました。お客様として担当したことがあるという縁で、ウォシュレットなTOTOではなくINAXをチョイス。いやー、仕事でINAXのトイレのカタログは読み込みました。当時のカタログには100万円の有田焼の手洗い鉢とかあったんですよ、受注生産で。飲食店向けとかなんですかねぇ。

便座の取り付けはボルト2本なので特に難しいことはないんですけど、洗浄便座は水を引き回さないとダメなわけで、タンクへのパイプを外して分岐を入れ、タンクへフレキでつなぎ直さなければなりません。難しくはないですけど、水回りの作業は気を遣います。留守中に水が漏れたら大惨事です。なので、土曜日の午前中に始めて、週末様子を見ました。とりあえず大丈夫そうなので一安心。

やっぱりお尻を洗ってもらえるのは良いものですな。ついでに掃除も出来てトイレも綺麗になったし、よい気分です。

| | Comments (0) | TrackBack (0)

Clean Architecture/Robert C. Martin

アンクル・ボブの「Clean」シリーズ第3弾。「クリーン・アーキテクチャ」については、 ずいぶん前に記事が書かれていて、ググるとそれなりにたくさんの言及があります。

私はこれ、知らなかったです。というか、もしかしたら絵を見たことぐらいはあったのかもしれないですが、この絵を見てもここに何か自分の認識を改めるようなエッセンスがあるかどうかって全然わからないので、特に興味を惹かれなかったんだと思います。

で、この本の結論としては、この記事に出ているこの同心円の図がゴールよってことなんですが、そこに至るまでの道のりが丁寧にきっちり書いてあるので、なんかすごく楽しく、納得もしました。

Clean_architecture_2 そもそもこれが同心円になっている理由なんですが、恐らくは古典的なWebの3層モデルとか、MVCアーキテクチャみたいなものがあったとして、その両端、つまりGUIとDBがいずれも最も外側のレイヤーに来るよというようなイメージから来ているんだと思います。

GUIもDBもI/Oなんだから、それが一番下層であり、上から下への1次元のレイヤー構造で書き表すことももちろんできると思うんですが、わざわざ同心円にしているのはその対比のせいですよね。で、この一番外側GUIやDBが来るのはいいんですが、フレームワークも実装の詳細なんだから、一番外にいるべきだと。むしろ、そうさせないフレームワーク(本書の中では「結婚を迫る」というような言われ方をしますが)はよろしくないと。

それらがぜーんぶ一番外の層に来た上での、上の図のCtrlの中を3つのレイヤーにするぜという話で、じゃあ、そこにアプリケーションがどんなビジネスを体現するかに依らないソフトウエアアーキテクチャとしての3つのレイヤーがあるんですよと言われると、「ほう、それはちょっとすぐには思いつかないっすな」って感じじゃないですか。

で、一番内側はエンティティ。ぱっと考えるとエンティティってデータのことなんで一番内側もデータで、一番外側もデータ。どーすんのって思います。

もちろん、ボブおじさんのいうエンティティは、最も高次元のビジネスルールとそれを体現するデータ構造のことなので、RDBのスキーマ構造とは違うもの。つまり、Railsのようにアプリケーション設計において最も根源的なものとしてのビジネスルールとデータを実装の詳細に過ぎないRDBのスキーマを使って表現してしまうようなアーキテクチャを強いるフレームワークは一番よろしくないものってことになります。

よろしくないとどうなるかというと、変更と保守とデプロイが難しくなるよと。ボブおじさんのいうアーキテクチャの役割は、それらに寄与するため(だけ)なので、逆にRailsはそれと何をトレードオフしたのかって話です。ま、そう言われればそうかな。

というわけで、(本書でももちろん言及されているとおり)このアーキテクチャはコストが高いです。あの同心円ではさっぱりイメージがつかめないと思いますが、本書で示されている典型的なJavaで構築されたWeb+DBシステムの構造はこうなります。

Clean_architecture2_2

かなーりリッチ。

<I>って書かれているのはInterfaceで、なんでこんなにやたら出てくるかと言えば、下位のレイヤーを上位のレイヤーは参照できないから。

例えば、DBアクセスで言えば「こんな構造のオブジェクトにデータ詰めてくれや」とユースケース層がData Access Interfaceを定義し、データアクセスをするコンポーネントがそれを実装して、DBから取ったデータを詰めて返すと。つまり、上位レイヤーをビルドするときに、下位のレイヤーをimportしないよと。そう出来て初めて、下位のレイヤーへの依存がなくなるわけです。

この方法を「依存関係逆転の原則」(DIP)と呼んでいて、この本を通じて、ひたすら何度も出てきます。要するに、DIPのDはDI(依存性注入)のDなわけです。SpringみたいなDIコンテナはお馴染みだし、仕組みも使い方も理解しているつもりですが、私はこのDIPという考え方を理解してはじめて存在意義と、ここでなんで"Dependency"という単語が使われているのか理解しました。はー、なるほどね。

で、とにかくモジュール(ソースファイルの単位ぐらいの意味)レベルでも、コンポーネントレベルでも、アーキテクチャを構成するレイヤーレベルでもDIP、DIP、DIPと何度も何度も出てきます。

そして、考えてみれば今こさえてるシステムでも全然できてないですわ。コントロールレイヤーとビジネスルールを形作るロジックのレイヤーとデータアクセスをするレイヤーとちゃんとレイヤー分割はしているけどDIPはまるっきり出来てないです。

しまいにはボブおじさんは「OOPの存在意義は、ポリモーフィズムを使ってDIPが簡単に実装できることだけだ」ぐらいのことを言い出します。でもまあ確かにコンポーネントを正しく分離するには依存関係がちゃんとしている必要があって、単なるユーティリティクラス以上のものをちゃんと交換可能にするためには、DIPされてないとダメだというのはまったくもってその通りです。

ただ、じゃあ本当にこの通りやるのか、こうならないフレームワークはだめなんかと言えば、それはケース・バイ・ケースってことになります。なんせこのアーキテクチャはコストが高いので。そこでバランスを取って何がベストか見極めるのがアーキテクトの仕事だし、そのベストはアプリケーションのライフステージによって変わるので、アーキテクトは常にコードを書きながら(このレベルで言うならば、コード書かないアーキテクトはあり得ない)、常に見極めていかなきゃならんわけです。

というわけで、ものすごく示唆に富み、なおかつ、読んでいて楽しい(ボブおじさんの昔話もいろいろ聞けるし)本です。そして、特にクラスを分割すべきかどうか、モジュールをどうまとめたら良いのかというレベルの設計方針に悩みを持っている人にお勧め。そのレベルの設計方針が積み上がって、最終的にはクリーン・アーキテクチャへたどり着くことになるからです。

| | Comments (0) | TrackBack (0)

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-/Mitch Lacey

すでにテスト駆動開発(TDD)と並んで常識というレベルにまで普及したスクラム。少なくとも、思想的には普及しましたよね。

どのぐらい実践されているのかとか、どのぐらい成功裏にプロジェクトが完了しているのかとかは良くわかりませんけど、2018年にシステム開発のプロジェクトをしようとするならば、まず、スクラムが開発手法として選択肢に上がらないことはないでしょう。

とはいえ、です。私がスクラムマスターの研修を受けて思ったことは、「スクラムがきちんと出来るメンバーがそろったならば、スクラムじゃなくたってプロジェクトは上手くいくだろう」ということでした。それまでの開発手法は前提として、それなりの能力を持った開発者やリーダーが定められたプロセスをきちんと実行できるならば、プロジェクトはうまく進むのだとしていました。そのため、プロジェクトにトラブルが生じたら「何が出来ていないのか」ということがチェックされました。

で、よくよく考えてみるとそのプロセスというのは、「ちゃんとやる」ことがすごく難しいものでした。例えば、「要件はすべて明確にされる必要がある」とか「リスクは網羅的に把握されなくてはならない」とか。で、トラブったら「漏れてた」「網羅性に問題があった」と言われるわけですが、いや、「すべて」とか「網羅」とか、普通に無理でしょう。無理だったわけですよ、後から言うのは何とでも出来るけども。

それがスクラムになると、「プロジェクトを進める上で障害が必ずあります。チームはそれをみんなで解決しなくてはいけません」「チームには必ず改善すべき点があります。毎スプリント何かを改善していくことによりチームは向上します」となる。「○○をしろ」ではなく「ゴールを達成するために何をするのか考えて、ベストのことをやれ」になる。抽象度が一つ上がっていて、そのレベルでどう行動するのかのルールが決められたフレームワークがスクラムなので求められていることは難しいわけ。だから、開発者にとって魅力的なんだけども。

そんなスクラムなので、「こういう場合はどうしたらいいの?」というケースはけっこうあると思います。もちろん、スクラム自体はそれに答えてくれないケースも多いんだけど、そのようなケーススタディについていろいろ書いてあるのが、この本です。物語仕立てのケーススタディを読むのがけっこう楽しい。

こんなケースについて、ヒントが得られます。

  • プロジェクトを進めるのに必要なスキルを持つメンバーが集められなかった
  • まだ何も始めてないのにいつ出来るか報告しろと言われた
  • チームでいちばんのリーダーと、いちばん仕様を把握している人と、最も優秀なプログラマが同一人物なので、3つのロールを兼ねた
  • TDDや継続的デリバリーやペアプログラミングはスクラムのプラクティスではないのでやらない
  • 毎日デイリースクラムに遅刻する奴がいて、メンバーがキレた
  • 4週間のスプリントでスプリントバックログを消化しきれないので、5週間に伸ばしたい
  • チームの状態が悪く仕事が終わらないから、レトロスペクティヴをパスしたい
  • チームのスタープレイヤーが異動になった。それも、今日。
  • オフショア先の開発者をチームに入れろと言われた
  • プロジェクトをはじめたいが、プロダクトバックログが数百あって、スプリント1でどれをやればいいか決められない

まあ、あるあるっすなー。

というわけで、スクラムをやり始めたら直面するであろうあるあるについていろいろと検討している本です。具体的な手法や、思考のツールも満載ですし、ケーススタディを通じて「スクラムっぽい考え方」を理解できるというのも良い。語り口も軽やかで読みやすいです。良書ですねー。

| | Comments (0) | TrackBack (0)

F1.2グランプリ 2018前半戦

今年のF1も前半戦が終わり、シャットダウン・ピリオドに入りました。ご苦労様。バカンスを楽しんでください。でも、たぶんホンダは休んでないんだろうなあ。大変だなあ。

さて、今年は本当に久しぶり(10年ぶりぐらいだよね)にトップチーム間のパフォーマンスの差が小さく、接近した戦いが続いています。皆さんも楽しんでらっしゃることでしょう。

ところが、トップ3チームとそれ以下のチームとの差がとても大きくなっています。まるでF1が2カテゴリーに分かれてしまっているかのよう。そして、このトップチームを除いた7チームの争いもものすごく僅差です。

今回は、この7チームがF1のセカンドカテゴリー、すなわちF1.2というクラスだったと仮定して、その戦いをまとめてみたいと思います。

では、F1.2のポイント争いを観てみましょう。レギュレーションは以下です

  • トップ3チームをレース結果から除いた順位をつけ、その結果に対して10-6-4-3-2-1方式のポイントを与える(これで大体総合順位10位あたりまでが入賞になります)
  • 決勝と同じように3チームを除いた予選結果に対して、1位に1点を与える

こういう結果になりました。本物のランキングの7位以下とは、ちょっと違う並びになるのが興味深い。

20180802_125727_2

チャンピオン争いはルノーの2人とハースのマグヌッセンの間で繰り広げられています。ヒュルケンベルグは12戦中4戦で優勝をあげる活躍でリード。ほんと、なんでこの人が表彰台未経験なんだろう・・・不思議だ。

一方、マグヌッセンは4回のポールポジションをゲットしながら2勝にとどまっています。サインツは未勝利ながら安定してポイントを稼いで3位。4位はさすがのアロンソ。開幕戦の優勝が光っていますが、しぶとくポイントを稼いでいます。その一方でバンドーンは10位で苦しんでます。バンドーンにも同情の余地がかなりあるんですが、それはそれとしてアロンソはやっぱりすごいですね。

この後は、オコン、ガスリー、ペレス、グロージャンと続き、ここまでが優勝してるドライバー。なんとガスリーは2勝してるんですが、それを含めて入賞が4回と安定感のない成績が心配。1年目のパッケージで2人とも新人ドライバーというところが成績が安定しない理由なんでしょうか。ここに「チーフデザイナー離脱」という要素が加わったトロロッソの今後は決して明るくありません。ただ、後半のレースは経験済みのコースが増えてくるのでそこはいいところかも?

大活躍のルクレールですが、順位的に言えばまだ9位。しかし、まだまだ伸びしろのありそうなザウバーのマシンは、後半戦が楽しみです。個人的にはもう一年ザウバーで、今度はナンバーワン待遇で勉強してみるのがいいんじゃないかと思います。2年目でフェラーリに行っても潰されちゃうんじゃないかと心配です。

というわけで、いかがだったでしょうか。7人のウィナーが出ている接戦です。こちらのカテゴリーも見所いっぱい。後半戦もお楽しみに!

| | Comments (0) | TrackBack (0)

« July 2018 | Main | September 2018 »