Magnolia Tech

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

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などのアプリケーションレイヤーの人に馴染みのある話題が出てきます。

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

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

Scala 2.13より未使用変数への警告を抑止するunused annotationが追加された

時々メソッドのインタフェースを揃えるために、わざと使わない引数を定義することが有る。

Scalatraでもインタフェースを揃えるためにServletのRequestとResponseをペアで定義しているが、必ずしも使っていない、みたいなコードがあり、ビルドの度に未使用パラメータの警告が出てしまう。

[warn] /repos/scalatra/auth/src/main/scala/org/scalatra/auth/ScentryStrategy.scala:44:35: parameter value request in method beforeAuthenticate is never used
[warn]   def beforeAuthenticate(implicit request: HttpServletRequest, response: HttpServletResponse): Unit = {}
[warn]                                   ^
[warn] /repos/scalatra/auth/src/main/scala/org/scalatra/auth/ScentryStrategy.scala:44:64: parameter value response in method beforeAuthenticate is never used
[warn]   def beforeAuthenticate(implicit request: HttpServletRequest, response: HttpServletResponse): Unit = {}
[warn]                                                                ^

将来の拡張性のために意図した未使用は警告しないで欲しいなぁ…と思っていたら、Scala 2.13よりunused annotationが追加された。

Scala Standard Library 2.13.0 - scala.annotation.unused

ドキュメントに全然コード例が無いので分かりづらいけど、テストコードにコメント付きで使い方が書かれているので、こちらを見た方が理解しやすいと思います。

scala/t10790.scala at 2.13.x · scala/scala · GitHub

Scala 2.13以降なので、後方互換性の観点からすぐに使うわけにはいかないけど、ライブラリ作ったりする人は知っておくといいと思いました。

ログミーTechで昨年に設計Night2018で話した内容が文字起こしされました!

connpass.com

昨年開催され、大好評だった「設計Night2018 powered by Classi」での自分の登壇内容がログミーTechさんにて文字起こしされました!

logmi.jp

logmi.jp

logmi.jp

ブクマも改めて80近く行きました。凄い!

この辺の話、もう一回整理して1時間くらいの完全版を喋りたい気持ちが有りますので、オープンなイベントでもクローズドな勉強会でも行きますので、興味がある方はご連絡下さい!