Magnolia Tech

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

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」を読んでないことに気がついて早速注文して、今日届いたので、ずっと読んでた。

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

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

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

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


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

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

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

コードと、データと、改修の歴史と

次の設計Nightに向けたネタの整理

ドメイン知識から、コードへ

DBの寿命はアプリより長い

ハードウェアの寿命(5年〜7年)に合わせて全面的にシステム更改を行ってアプリケーションがかなり書き換わっても(もしくは全部違うパッケージに入れ替わっても)、それまでのデータは捨てられることなく、移行しつつ使われ続ける。そうすると、今のシステムの要件だけでなく、明示的、または暗黙的に過去のシステムの要件が入り込んでいて、それを階層的に理解しないと「データを理解した」という状況に至らないのではないか。

アプリケーションはアドホックに改修され続ける

コード自体は無くなるかもしれないが、コードが実現していた機能や、たくさんのコードの集合が表現していた「プロジェクト固有の設計原則」「隠れた仕様」みたいなものはずっと残っていく(所謂、現行踏襲)。そのコードだけでなく、あるコードが他のコードへ与えた影響だけは残っていく。

歴史は運用と改修の積み重ね

データは運用されることで積み重なり、機能は改修されることで積み重なる。今あるシステムは、データと、コードと、その改修の歴史の積み重ねという3次元で構成されているので、本質的に理解するのは難しいのではないか?

で、本質的に難しいと考えて、どうすればいいのか?という事を考えていくわけです。

本件について、皆様のコメントを頂けるとうれしいです。

僕らがカンファレンスへ行く理由

本エントリは、BGMに「僕らが旅に出る理由」を流しながら読んで下さい。


builderscon 2019へ参加してきた

builderscon.io

特定の言語やフレームワークに特化したカンファレンスが多い中、buildersconは特定のテーマに縛られることの無い幅広さが魅力ですね(自分は見れていませんが、スーパーカミオカンデの発表はかなりTwitterのTLが盛り上がっていましたね)。

一方でPHP系のカンファレンスのように、間口が広い分、メインテーマのPHP以外の、設計や開発プロセスに関する話題もけっこう充実してきていて、必ずしもその言語を使っていないからといって最初から対象から外すのももったいないイベントも有ります。

もちろん、その言語、ライブラリに100%振り切ったカンファレンスもたくさんの学びが有ります。

(今年初参加だったScalaMatsuriはなかなかのディープなScalaトークだらけで、堪能しました。分からない悔しさが有りました)

この手のテックカンファレンス、無料も有りますが、たいていは参加費が5千円から1万円近くはかかるし、けっこう前からチケットを押さえないといけないので、それなりの覚悟はもって参加しないといけないわけですが、それでも参加するのはみんな自分の知見を惜しげもなく公開してくれるからです。

つまり、こうゆう気づきがあるわけです。

その発表で触れられた知見が、直接今自分の課題につながること無いかもしれないし、実はずっと無いかもしれないけど、それでも「何を課題と捉えたか?」「その課題をどう特徴付けたか?」「その課題を解決するまでの道筋をどうつけたか?」といった話は、絶対に役に立つと思うんですよ。そして、それが一人一人やり方は違うけど、ちゃんと発表できるところまで整理されているって、日常の中ではなかなか無いと思うんですよね。

本を書いてる人とか、有名人とかだけじゃなく、普段は全然名前を見かけない人だってたくさん発表していて(むしろそうゆう人の方が圧倒的に多い)、その人たちが「どう考えて、どう行動したか?」って所を短時間でなぞっていけるって意味の有る時間の使い方じゃないかなって思います。しかも、合間の時間とか懇親会では直接そのスピーカーに話しかけ放題って考えると、更にお得感が増しますよね。

色んな人の思考の過程が辿れる…これが僕がカンファレンスへ行く理由です。

なので、みんなテックカンファレンスへ行った方がいいです。

「データ指向アプリケーションデザイン」を読んだ

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

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

今年の夏休みの課題図書、「データ指向アプリケーションデザイン」をざっと読んだ。ところどころメモを取りながら進めては行ったけど、さすがに600ページ超えの厚さで全部を同じ集中度では読めなかったので、あまり馴染みのないストリーム処理あたりはかなりの流し読みになってしまった。たぶん2周目が必要。

書籍全体としては分散型のデータ処理基盤を設計するにあたり、どのような課題が有り、現実のソフトウェア(ここが重要!)がどのようにそれを解決しているのか?ということをありとあらゆるテーマについて語り尽くした本。これ以上は、もう実際に運用してみないと分からないレベルだと思う。

かなり分厚い本だけど、まずは第一章「データシステムの基礎」だけでもぜひ読んだ方がいい。「信頼性」「スケーラビリティ」「メンテナンス性」という現代のソフトウェアに求められる要素がコンパクトにまとめられている(ここだけなら20ページくらい)。

データストアよりアプリケーションの方が得意な人は引き続き「2章データモデルとクエリ言語」の「4章 エンコーディングと進化」を先に読むと入りやすいかも。JSONやProtocol Bufferなどのアプリケーションレイヤーの人に馴染みのある話題が出てきます。

夏休みシーズンももう終わりですが、数週間かけて少しずつじっくり読むには最適な本なので、秋の夜長に向けてぜひ読んでみて下さい。

なお、本書の名言としては、「最大限に努力しても、人間には信頼性がないことが知られています」という所ですね:)