Magnolia Tech

いつもコードのことばかり考えている人のために。

「レガシーコードからの脱出」を読んだ

「レガシーコードからの脱出」を読んだ

若干ウォーターフォールアジャイルの対立を煽り過ぎだな、と感じる前半戦(別にアジャイルにしたからといって成功するわけでもないし)と、散発的なテーマが並ぶ後半戦、なぜかやたらと詳細なテスト関係…と、正直これを読み込んだからといって新しい発見があるというより、冒頭のツイートでも書いたように、色々なテーマが詰まっているので、読書会などで自分の経験とか考えをまとめるきっかけにすると良いな、と思いました。

3日間くらいかけてメモを取りながら読んだところ、さまざまな過去の経験がよみがえってきたので、メモを取りながら疑問点とか、過去の振り返りを書き出しながら読むのがお勧めです。

「Design It!」を読んだ

副題にある通り「プログラマのためのアーキテクティング入門」ということで、どうやってシステムのアーキテクチャを設計していくか?という課題に対して向き合うための方法を示してくれる本です。

とはいえ、所謂アーキテクチャカタログ集ではないので、即効性の有る内容ではなく、ゼロベースでアーキテクチャを決めていくための思考のステップを示してくれる内容なので、具体的なアーキテクチャにつながる技術要素は、ここに示された内容を元に情報収集し、判断し、決めていくしかないですね。

第Ⅰ部 ソフトウェアアーキテクチャ入門
 1章 ソフトウェアアーキテクトになる
 2章 デザイン思考の基礎
第Ⅱ部 アーキテクチャ設計の基礎
 3章 デザイン戦略を立てる
 4章 ステークホルダーに共感する
 5章 アーキテクチャ上重要な要求を掘り下げる
 6章 アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)
 7章 パターンで土台を作る
 8章 意味のあるモデルで複雑さを扱う
 9章 アーキテクチャデザインスタジオを開く
 10章 設計判断を可視化する
 11章 アーキテクチャを記述する
 12章 アーキテクチャに通知表をつける
 13章 チームのアーキテクト力を強める
第Ⅲ部 アーキテクトの道具箱
 14章 問題理解のアクティビティ
 15章 潜在的な解決策を探るアクティビティ
 16章 設計をタンジブルにするアクティビティ
 17章 設計の選択肢を評価するアクティビティ

特に1章から4章まではマインドセット的な内容も多く、アーキテクチャ設計のステップを知りたい人はまずは5章の「アーキテクチャ上重要な要求を掘り下げる」から読むと良いでしょう。「制約」や「品質特性」など、必須の重要キーワードが出てきます。更に6章〜7章がまさに具体的なアーキテクチャを決めていくステップになっているので、最初は5章〜7章までをじっくり読むことをお勧めします。

8章から13章は、それをより良くするための手順や、視点ですし、14章以降はより具体的な手法になっています。このあたりは必要に応じて拾い読みすると良いですね。

アーキテクチャをタンジブルにする

この本を通じて「アーキテクチャをタンジブルにする」という印象的なキーワードが出てきます。「タンジブル(tangible)」は”触れられるようにする”という意味ですが、必ずしもアーキテクチャを図示することを意味していません。

「2.1.4 アーキテクチャをタンジブルにする」には以下のように書かれています。

アーキテクチャを図に描く、アーキテクチャをコードの中で生き生きと表現する、構造や品質特性を体験できるようなプロトタイプを構築する、アーキテクチャの一部がどう機能するかを示す簡単なモデルを作成する、関連するメタファーを作成する、システムの制御フローの一部を身振りで伝える、などだ。

必ずしもドキュメンテーションだけが方法ではなく、色々な手段が有ることを示しているのが良いですね。16章にはそのための具体的な手法が紹介されています。

おわりに

繰り返しますが、この本はアーキテクチャカタログではないので、これを読めばすぐにアーキテクチャデザインができるわけではないですし、特定のアーキテクチャを想定したものでもないので、技術的な情報収集はゼロからやっていく必要が有ります。

しかし、いにしえの”LAMP”とか、”まずはRails”、という時代ではなくなり、色々な選択肢が無限に有る中、ゼロベースで考える場面が多くなってきた現代ではこのような”思考のガイドライン”がますます重要になってきたと思います。

すべてのアーキテクチャ上の決定を細部までこの本に合わせてやっていると、今度は時間が足りなくなるような気もしますが、アーキテクチャ上の重要な意思決定を行う際には、このような原理原則に立ち返る瞬間はきっと必要だと思いました。とりあえずアーキテクトを目指す人は、一度流し読みをしておいて、いざという時に立ち返れるようにしておくと強力な武器になるのではないでしょうか。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

Design It!: From Programmer to Software Architect (The Pragmatic Programmers)

Design It!: From Programmer to Software Architect (The Pragmatic Programmers)

コードリファレンスと、クロージャと、map関数

このエントリはPerl Advent Calendar 2019の8日目の記事です。

7日目は@kfly8さんでした。

2019/12/8 追記: worthmineさんにコメントで、クロージャの定義が間違っているとご指摘頂きました。すっかり思い込みで誤ったことを書いてしまいました。ちゃんと原点に当たらないとダメですね。記事の内容が間違っているので、一度見直すためにクローズします。

ちゃんと25日までに書き直します!

HHKB Professional Type-Sを買った

長年初代のHHKB Professionalをメインで使っていて、それはそれでまったく壊れる気配がまったく無くて、買い換える必要は無いのだけど、別の環境で使っている、ちょっと前に買ったメカニカルキーボードがどうにも相性が悪く、使いづらかったので、思い切って購入。

最後までREALFORCE R2 「PFU Limited Edition」とどっちを買うか迷ったけど、結局サイズ感が慣れているので。

しかし、もっと早く買えば良かった。これまで使ってきたキーボードの中でこれに匹敵する打鍵感はたぶん無い。ADB時代のApple Keyboardが近い気もするけど、ここまで静音でもないし(というか、今では入手できないし)。

と言うわけで、テンキーやカーソルキー、ファンクションキーにそこまでこだわらない人(つまりvimユーザーか…)は、一つ持っておいて損は無いと思う。手入れしながら使えば平気で15年以上は使えてしまうので、コストパフォーマンスは素晴らしく良いし。

Airframe Meetup #3へ参加しました

airframe.connpass.com

Scala用のライブラリ集であるAirframeに関して学ぶミートアップ、Airframe Meetup #3へ参加してきました。第1回、第2回と絶妙に参加できないタイミングでの開催だったので、次こそは!と思っていましたが、タイミングが今回は合って参加することができました。

そもそもAirframeというのは、作者の@taroleoさんがScalaを使った実プロジェクトの中で得られた知見を元に作られていて、非常に実用的なライブラリ集です。Dependency Injection、JSON、MessagePack、HTTP、Loggingなど多種に渡る機能が一通りそろっています。

詳しくは公式ドキュメントを見てください。

wvlet.org

リポジトリは、以下のリンク先に有ります。

github.com

Scala、コレクションライブラリを除くとコアライブラリもそこまで品揃えは充実しておらず(ときどき分離されたりするし)、かといって定番ライブラリも同じジャンルにけっこう似たようなものが多く、選ぶのに苦労します。そんな時に、まずはこれを見て用途に合っているものが有るか、探せるのは非常に有りがたいですね。

今回は、そんなAirframeの最近の開発状況が紹介され、続けてLT3本という構成でした。特に、@taroleoさんによるAirframe specの紹介と、GitHub Actionでビルドを効率化した話が興味深かったですね。

Scalaの定番のテスティングフレームワークである、ScalaTestや、Specs2などのは割と機能が豊富過ぎて、どこから手をつけていいのか分かりづらいところがあって(なんであんな多数の記法をサポートしているのか…)、Airframe Specは、ミニマルと、過剰の中間を狙った、という話に感心しました。Airframe SpecでScalaのテストに入門するのはありだな、と思いました。

資料のリンク先を張っておきます。

docs.google.com

speakerdeck.com

paper.dropbox.com

あと、まだ資料は公開されていませんが、LTの最後は@takezoenさんによるDependency Injectionの歴史や、各ライブラリの特性についてのご紹介でした。

おわりに

@taroleoさんの落ち着いたトーンでのしゃべり方が、イベント全体の雰囲気を形作っていて、空気感が良かったですね。落ち着いていて、そして非常に正しいエンジニアリングというか、問題をきちんと解決する方法を考え、実行し、広めていくっていう姿勢が見られて非常に感銘を受けました。

あと、@taroleoさんは、「データ指向アプリケーションデザイン」の監訳を行われた訳ですが、終わった後の会場でその辺の話になったのが良かったですね。もっと話を聞きたかった。

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

また、ぜひ参加したい、と思わせてくれる、そんなミートアップでした。

Anker PowerPort Atom PD 2を買った

f:id:magnoliak:20191003235759j:plain

2年前にMacBook Pro 13″モデルを購入して以来、周りにUSB Type-Cで充電する機器が増えていった…ヘッドフォンや、スマホ、モバイルバッテリーと、今では日常的に充電する機器はみんなType-Cになったし、その中にはUSB PDで充電できる機器もけっこう有る。

そうすると複数ポートのUSB充電器が欲しくなるけど、Type-C & USB PDをサポートした複数ポートの充電器はいっこうにリリースされていなかった。あと、MacBook Pro 13″はUSB PDの中でも比較的容量が大きい60wだけど、これも対応した充電器の選択肢が全然なく、結局純正品がベスト、みたいな状況がずっと続いていた。

そして、ついにAnkerから最大60wの容量をサポートしつつ、USB PD x 2ポートの充電器が発売された。

1ポートだけなら最大60w、2ポート同時に使う時はそれぞれ最大30wと、MacBook Proも充電したいし、ガジェット系をまとめて充電したい、という希望にコレ一つで対応できる。あと、ちゃんとPSE認証も通っているので、安全に使える点も良い。

大きさもAppleの充電器より小型なので、持ち運びには丁度良い感じ。

一つだけ注意点は、Type-C→Lightning変換ケーブルを挿しておくと、実際にiPhoneを繋いでいなくても機器がつながった状態と認識され、もう一つのポートが最大30wになってしまうところ。両方Type-Cしか接続しなければ、実際に機器を繋いだ時だけ認識される。ケーブルを挿しっぱなしで運用したい人は要注意。

USB PD対応機器を2個以上持っている人は、まずは迷わずこれを買った方がいい、お勧めです。

充電のためのUSBケーブル

充電器を買ったら、次はケーブル。USB Type-Cの規格はとにかくカオスなので、USB3.1 Gen2規格&USB PD 5Aに対応したケーブルを一本用意しておくと間違えずに済む。基本機器付属のケーブルは使わない、くらいが混乱せずに良い。最近だとELECOMのが安いし、ケーブルの長さも0.5mと、1.0mが選べて良い。

自分は、周辺機器用と、充電用に、0.5mと1.0mを一本ずつ用意しています。

あと、USB 2.0対応だったら、ケーブルの長として2.0m、3.0m、4.0mが選べるけど、とにかくUSBケーブルは堅くて、取り回しに不便なので、そんな長いケーブルを用意するくらいなら普通の延長コードを用意しておいた方が全然良いです。 先日、3.0mを買ってみたけど、使うときだけ繋ぐ、という使い方には全然向いて無かった。

あとは充電器がType-Cになって付属しなくなったけど、MagSafe時代の充電器には必ず付属していた電源アダプタ延長ケーブルは、今でもそのまま使えるので、こちらを使うのもお勧めです。けっこう使わずに余らせている人が多いと思うので。

Apple 電源アダプタ延長ケーブル

Apple 電源アダプタ延長ケーブル

充電器と、ケーブルの持ち運び

充電器と、ケーブルをセットで持ち運ぶ時には、このペンケースが案外丁度良くて、充電器と2.0mのケーブルを横に並べて綺麗に収まります。

おわりに

というわけで、ついにUSB Type-C充電器の決定版が出たので、Type-Cが増えてきた人にはお勧めです。

でも4ポートとか出ないかな…電源容量が大きいから無理か…

Clean Architectureを読んだ

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

週末のTwitterのTLで「リスコフの置換原則」が話題に上がっていて、改めて色々と学びが有った。

その中で、そういえば各種設計原則が紹介されている「Clean Architecture」を読んでないことに気がついて早速注文して、今日届いたので、ずっと読んでた。

読みどころとしては…まずは「設計とアーキテクチャ」に出てくる生産性のグラフ!極端な例だとは分かっていつつも、割と直感的にそうだなって思うし、ああゆうふうに数字に出ていない場合は、やはりどこかに無理が生じている(暗黙のうちに、プロセスが省略されるとか)。

その次の、プログラミングのパラダイムとして「構造化プログラミング」「オブジェクト指向プログラミング」「関数型プログラミング」を駆け足でまとめている所も、少々強引だなーと思わせる所も有りつつ、振り返りにちょうど良かった。

続く第Ⅲ部で設計の原則について語られる。割と、この辺は最近設計的な発表がカンファレンスでも増えてきたので、そこで聞いたことと照らし合わせて読むとより理解が深まると思います。

「単一責任の原則」のように語感から得られる印象とは全然違う原則であることが丁寧に書かれていて、この辺は知識を棚卸しするためにも読んだ方がいいですね。


ざっと読み終わって思ったことは、「これは一人で読むより複数人で読んで、感想を言い合う、経験を共有し合うきっかけ」にした方が良い本だな、と思いました。この本を深く読み込むことで得られることはきっと有るとは思うんですけど、これを完璧に暗記したら良いコードが書けるか?といえば当然そうではないですし、これだけを信じ過ぎるのも危険です。

設計原則はあくまで自分が書こうとしているコードを、何の指針も無く書こうとするとさすがにマズいな!という時に参考にするものであって、それに従えば自動的に良いコードができあがるルールではないですからね。

ざっと読んで、コード書いて、振り返りを色んな人とやっていきましょう!