レビュー『アウトプット大全』 お気に入りの項目3点

巷で一時期話題になっていたような気がします。

本書を雑に要約すると、「アウトプットをするといいことがたくさんあるからどんどんやっていきましょう。アウトプットっていうのはだいたい話す、書く、行動を変えるの3種類です。」となります。

お気に入り項目×3

本書の中にもありますが、全部を頭に入れなくてもいいと思います。3つくらい参考にできればそれで十分元が取れていると述べています。私も全部の内容は覚えていませんが、特に勉強になったコンテンツを3つ挙げたいと思います。

「なぜ?」を解決する

P33です。インプットをアウトプットに変える段階で、疑問点が生まれます。その疑問点を、解消に時間がかかるからという理由で自分は放置しがちでした。しかし、その疑問を解消することが成長に不可欠とのことです。実際、調べてみるとすぐに疑問が解決することもありますし、解決しなくても問題への知見は深まります。

想定問答集を作る

「15議論する」の一部です。資料を作ってレビューしてもらうと、思ったよりも指摘があってもうちょっとちゃんと作ればよかった……と反省することが多いです。想定問答集を作って議論や資料作成に臨もうと思います。

少し試してみましたが、想定問答を立てるのは難しく、時間がかかります。これもスキルということなのでしょう。

時間を決めて、構成を決めて書く

「38速く文章を書く」に出てくる、文章を書くコツです。時間は決めるとは、「今日は30分で書こう」というレベルでOKです。

早速、今回のブログ記事でも使ってみました。メインにお気に入りのコンテンツ3点を書き、あとは前後にまとめを挟めばいっちょ上がりとしました。

オススメの読み方

本書は1項目2~4ページと細かく、スキマ時間で読めるのをウリにしています。しかし私は読めるときに一気に通すべきという意見です。読んだ中で、特に気に入ったものを次の日から実行していくのが効果的な本書の使い方だと思います。

微妙な点

微妙な点も挙げておきます。もともと、否定的な前評判も受け取っていて、その内容は「作者のドヤ感が強い」というものでした。確かに、ことあるごとに自著やメルマガ等の宣伝が挟まっています。最後の方になってくるとそれが顕著ですので、「この作者めっちゃ自慢してくるなあ」という感想で締めくくられることになります。私は気になりませんでしたが、それが鼻持ちならない人もいると思います。

ドヤ感が強いと言いましたが、作者自身が「継続は力なり」を体現しているので、その点は見習っていきたいと思いました。

レビュー『入門Unixシェルプログラミング』

シェルスクリプトは、毎日書いている人は少ないと思いますが、ITエンジニアをやっていると断続的に出くわします。

いちどまとめて知識を得たいなと思って、前から積んでいた以下の書籍にとりくみました。

知識と例がバランス良く記載されていて、かなりの良書だと思います。

構成とオススメの進め方

本書は1~8章で文法や関数の説明、9・10章が例題であとはおまけです。

進め方のオススメとしては、第1章から順に読み進めていって、飽きてきたら9章に飛んで実際に例題のシェルを写経する、というものです。

実際に写経してみると、やたら引数チェック(例:if [ $# -ne 1 ])などでif文を書くことになるので自然と身につきます。

他にも、ここはスペース入れないとダメ・入れたらダメ、とか、これは1じゃなくてl(エル)なのね、シングルクォーテーションではなくてバッククォートなのか、など色々詰まるところがあります。

そうして考えながら書いていくことで、だいたいどのような処理が来ても読めるようになっていくと思います。

車輪の再実装

10章は普段使っているコマンドの再実装が多いです。catやwcなどがあります。もちろん簡易的なものだという理由もありますが、100行~200行という短さで書けるのはかなり驚きですね。個人的には、できたものを動かすのは楽しいですね。

とにかく例題がたくさんあるので書いているとだんだん慣れてきてある程度身につくようになっていると思います。

まとめ

実際に業務等でシェルスクリプトを扱うときは、既存のシェルを読みこみや、微修正から始めると思います。そうしたときに、本書の知識がベースとなっていれば基礎的なところでつまずかずに効率よく進められると思います。

私が電子書籍の技術書を使っていない背景

はじめに

私はITエンジニアをしていてたまに技術書を買いますが、紙が多いです。電子書籍には、検索可能なこと、かさばらないといったメリットがあるのは承知していますが、あまり使っていません。その理由を考えてみました。もしかしたら、ちょっとの工夫で電子書籍を有効に活用できるかもと思ったためです。

電子書籍で使いづらいなという点を挙げて、解決策を考えてみます。

難点1:どこから入手できるのか分かりづらい

紙の本の場合は、書店に行けば買えます。アマゾンで注文すれば、じきに届きます。

電子書籍については、ファイル形式がいくつかありますが、私がPDFでほしいです。PDFを入手しようとした場合、各出版社のサイトを使う必要があります。例えば以下です。

www.oreilly.co.jp

gihyo.jp

accounts.booth.pm

調べるのに多少時間がかかりました。どこかに書き留めておかないと、忘れてしまうと思います。この記事が書き留めそのものなので、忘れても大丈夫になりました。

難点2:PDFを各デバイスに連携するまでが手間

電子書籍を読むならiPadかなと考えていました。しかし、PCで読みたいときもあるかもしれません。そうなったときは、オンラインストレージに保存すればいいと思いますが、それがそもそも面倒です。

オフラインでも読めるように、ダウンロードしなきゃ…と考えるのは、カバンに本を詰めるのと同じか、それ以上の負担です。

ローカルに落とすのは1回だけでいいので、それはいいですね。

記事作成にあたって手順を一通り確認したので面倒に感じる気持ちは多少減りました。

難点3:PDFを読む環境を構築しきれていない

先ほど電子書籍iPadで読みたいと言いましたが、PCを外部モニターにつないだほうが家ではいいかもしれません。ただ、我が家にはよさげなモニターや置くスペースがないです。いや、頑張ればできるかな……。お金をかけるので、優先順位付けが要りますね。

富豪的な紙の技術書

紙の書籍は重いので、家でも会社でも読みたいとなると大変な思いをして持ち運ぶ必要があります。電子書籍なら、何冊でも重さは変わりません*1。しかし、現職ではそれなりの冊数の技術書が読めるように置いてあります。家と会社、どちらにも本があるので、持ち運ぶ必要はなくなりました。

さらにいうと、最近はあまり出社していませんね。

まとめ

電子書籍に感じていた難点を3つ挙げ、そのうち1つは解決、残り2つは未解決という状態になりました。

技術書は紙でも電子でもいいけど、紙のほうが扱いやすいかなと再認識しました。

*1:バイス自体に重量があるのは地味に大事なポイントだと思いますが

レビュー 『エンジニアが学ぶ物流システムの「知識」と「技術」』

対象読者

タイトルから想像されるように、物流業務をシステム的な観点から紐解いています。物流システムに入りたての人、もしくは物流システムを気にしないと行けない人には、有用だと思います。自分は後者でした。

製造業をベースにしていると思います。

物流業務・システムの基礎説明

「物流」という単語自体には、ある程度のイメージはあると思います。倉庫を経由してモノを目的地に運ぶという流れはイメージしやすいからです。

本書は、そのような入門者に対して、より詳細な業務内容、そしてそれを支えるシステムについて説明しています。

まずは業務についてですが、例えば、入庫と入荷の違いを説明できますか?

本書では、以下のように定義しています。

名称 定義
入荷 荷が納品されていて、検品前または受入前で倉庫に入庫される前の状態
入庫 検品に合格した荷が倉庫に受け入れられている状態

原則、入荷→検品→入庫の順番です。

このように、基礎から丁寧に業務を説明しています。

次にシステムについていうと、物流システムは物流システム単独で用いられるのではなく、他システムと連動して使われています。

例えば以下のシステムが紹介されています。

略称 日本語名 物流システムか
WMS 倉庫管理システム はい
TMS 輸配送管理システム はい
SCMシステム サプライチェーン・マネジメント いいえ
ERP 統合業務パッケージ いいえ
MES 製造実行システム いいえ

ちなみに、パッケージが導入されているかはまた別の問題で、TMSのパッケージはあまり導入されていないそうです。

システムの中身ももちろんですが、システム同士の関係性も説明されています。

ソフトウェアの役割分担

何度か出てくる話として、ERPWMSで役割をきっちり分けるべき、というのがありました。一言でいうと、ERPは在庫管理、WMSは現品管理です。

今まで人やエクセルでやっていたものをWMSでシステム化しようとする例を考えてみます。ERPは既にあるものとします。ゼロからスクラッチで作るのではなく、すでにあるパッケージを導入・拡張するでしょう。この際に必要なことは以下の通りです。

  • システムに、人が合わせる
  • 業務を整理、標準化する
  • 他システムとの連携を確認する

一つのソフトウェアですべてをカバーすることはできないので、どこかで境界線を引かなくてはいけません。そこが曖昧だと、間に入る作業*1が増え、難しくなってしまいます。

最近の私は、マイクロサービスを背景に、どのようにサービスを切り分けていくかということを考えています。ERPWMSの切り分けは、それの巨大版とも言えそうな気がしていて、重要なことだなと思っています。

まとめ

エンジニア向けとあって、物流業務の前提知識無しで物流システムの全体像を学ぶことができて良いと思います。図表も豊富に描かれていますので、多彩な業務・システムの関連が頭に入ってきやすいです。

先行レビュー

かなりニッチな分野のためか、先行レビューはほとんどありませんでした。

物流の本!『エンジニアが学ぶ物流システムの「知識」と「技術」』が物流未経験者におすすめ!

たぶん、Bizか企画の人が書いてそうなレビュー。基礎的な内容ですね、と書いてあって確かにと思いました。

*1:人力とエクセルをイメージしています。ヒューマンエラーが出てくるのを前提としています。

Software Design 2020年1月号より「マイクロサービスアーキテクチャ」

表題の特集を読みました。ページ数は少ないので、さっくりまとめられていいですね。自分はマイクロサービスについては初心者です。

全体として

マイクロサービスはどれくらいの大きさになるのかというのは、初心者の自分が最初に思い付いた疑問です。

特集を通読すると、若干の幅があるように感じます。一番細かく刻んでいるのは、第1章の増田さんだと思います。例えば、「顧客管理」では大きすぎであり、「顧客識別情報」「取引履歴」「連絡先」等々への分割を試みるべきとしています。

この段階で、新たに二つの疑問が生じました。一つは、「マイクロサービスに階層はあるのか?」というものです。説明を読んでいると、なんとなく階層はないようなイメージがあります。まぁ、階層化できるくらい強い依存があるのなら、最初から一つでいいような気もする・・・のでしょうか?

もう一つの疑問は、「マイクロサービスはいくつまでならバラして大丈夫なのか?」というものです。大丈夫というのは、メリットがデメリットを上回っているのか、に置き換えていいです。

メリットは以下が挙げられていました。

  • 変更にかかる時間が短くなること、コストが下がること

デメリットには以下が挙げられていました。

  • 通信のオーバーヘッドが発生すること
  • 障害発生時の原因追跡や復旧が難しくなること
  • 全体像を理解するのが難しくなること

なんとなくですが、二桁後半あたりから、人間の頭では全体像を理解できなくなってきそうな気がしますね。

以下、各章を見ていきます。

第1章 マイクロサービスって何? アプリケーションを「ばらばら」にする理由

アプリケーションをいくつかのサービスに分割します。分割というのは、実行環境を分けることです。そうして分割されたサービスをマイクロサービス(複数形でマイクロサービシズ)としています。

マイクロサービスが低コストになった理由に、実行環境の仮想化や、クラウド上で実行できるサービスの拡充が挙げられていました。これについては、自分の理解が不十分な気がしています。テスト*1・デプロイが簡単・自動になったからコストが下がったという理解であっているのでしょうか?

マイクロサービスのサービスの結びつきとして、「同期・非同期」および「直列・並列」の2軸で説明されていたのは、非常にわかりやすいと感じました。

第2章 ひとつひとつのサービスはどのように作れば良い? モノリシックなサービスを上手に切り分けるコツとは

まず、どう分けるか?どれくらいの大きさで分けるか?という話がありました。ここについては分かりやすく、特に変だなというところはありませんでした。

非同期的なサービスでも、アクターモデルとイベントモデルの2つがあると述べられています。個人的には、イベントモデルに若干かすったことがある程度で全然わからんのですが、とにかくパフォーマンスを上げる、もしくはスケールさせるために同期を捨てている、という感覚は持っておきたいと思いました。

面白かったのは、サービス間の(通信)プロトコルが何が適しているかというトピックで、HTTP(REST)がトップだったことです。すごいぞHTTP。ちなみに次におすすめされていたのは「クラウドサービスの独自プロトコル」でした。マネージドサービスで、非同期的なイベントモデルを扱うのに適しています。逆に言うと、シンプルな同期的な結合であった場合は、慣れ親しんだHTTPで問題ないということですね。

一つ気になったのは、購入キャンセルの例で

購入キャンセルのイベントに対して各サービスの動作がきちんと整合していなければなりません。システムとして全体の状態を管理してトランザクションするしくみになっている必要があるでしょう。

とあるのですが、そのトランザクションの仕組みをどう確保するかは相当大事なのでは・・・と思いました。直後に書いているRedisのPub/Sub機能とかはイベントモデルを実現する手段に過ぎないようですし。

第3章 サービス同士はどのようにつなげればいい? 作って学ぶBackends For Frontends

いくつかのマイクロサービスから返ってきた結果をまとめ、クライアントに返すBFF(Backends For Frontends )が紹介されています。ここらへんからマニアックになっていきます。

Server Side Rendering は名前くらいは聞いたことありますが、マイクロサービスの文脈で語られるのだなと思いました。多分他の背景もあるような気がします。しかし、Next.jsをVueのライブラリだと思っていた自分には全然わからない。

第4章 複雑なマイクロサービスをどのように管理すればよい? サービスメッシュを実現するIstioとOpenShift Service Mesh

サービス個別に監視ツールを導入したとき、システム全体の監視はどうするのかという問題があります。サービスメッシュとは、新設したサービスメッシュ層で監視に必要な情報(ログ)を収集する仕組みになります。

正直難しすぎてよく分かりませんでした。ただ、数が増えて全体的な監視が難しくなった時の解決策として、最近注目されているようです。

おわりに

自分みたいな何もわからない人から、ガチ勢まで読ませる内容だと思います。

一点気になったのは、字数を収めるために、日本語が若干おかしいような印象を受ける文がいくつかあったかなということです。削りに削って、いま自分が読んでいる文章があるのだなと察せられます。

*1:特にエンドツーエンド

JJUG CCC 2019 Fall参加記

JJUG CCC 2019 fall に参加しました。

こんな感じのタイムテーブルで行われた、大規模なJavaカンファレンスです。

https://ccc2019fall.java-users.jp/timetable.html

今回から、講演の一部が「ステップアップセッション」という初心者向けとしてラベル付けされていました。

参加したセッションの多くがこのステップアップセッションになりました。

Gradle を完全に理解した人が、何も分からなくなるための第一歩

資料は以下です。

qiita.com

QiitaでJavaといえばこの人です。

「今年はGradle結構やったのでアウトプットしてみました」ということを話していて、今までたくさんアウトプットしている人も新たにチャレンジしていてすごいなと思いました。

スライドの具体例がとても丁寧で分かりやすいです。

自分はGradleは初心者未満でした。たまに、ちょろっとライブラリを増やすとかくらい。

とはいえ今回のセッションで、「じゃあ明日からbuild.gradleのメンテよろしく!」って言われても泣きながらOKできるレベルにはなりそうな気がします。

入門 例外

資料は以下です。

github.com

独自例外クラスの中に、finalのプロパティを持たせて、受け手に情報を渡せるようになります。

例外を「投げる」ときはその名の通りthrowを書くのですが、その理由が説明されていたのが良かったです。ちなみに、 メソッドの実行を終了し、失敗したと呼び出し元に通知できる からです。

資料のよくわからないところを聞いてしまったが、資料のアラを突っ込んだ野暮なものでした。とりあえず雰囲気をつかむところが大事なのかなと。

入門ということで詳しく説明されませんでしたが、実際try-with-resourceで書くときのリソースって何なんでしょうね?ファイルとか?

DBアクセスとかはもう少し汎用的なところで書くような気がする。

これはステップアップセッションになっていませんでしたが、それに入れても良いかなと思いました。

まだまだ間に合うJUnit(再)入門

資料は以下です。

自分がJUnitに関して初心者であること、JUnit4から5に移行したいと考えている身であることから、お役立ちのセッションになりました。

アノテーションが導入されていたのがJunit4からだというのは初めて知りました。3以前は使ったことがないので。

Junit5だと、クラスやメソッドがpublicじゃなくてもいいのかというのはあまり意識していませんでした。まああんまり関係ないような…?

Junit5への移行のメリットとして、assertAllで全部のテストを実行してくれることがありそうです。

Junit4だと一か所でも落ちると、以降を実施してくれないので、Assertionを複数おいている場合はフラストレイティングな気がする。

JVM入門 -Javaプログラムが動く仕組み-

資料は以下です。

講演者がめちゃくちゃ緊張していた気がします。

JVMについて全く中身を勉強したことがないので、「こんな用語があるのか~」くらいの感想でした。

GCについては時間を割いて説明されていました。いくつか種類があるのを初めて知りました。以下の記事などを見て勉強したいと思います。

gihyo.jp

絵で説明しているのでふわ~とイメージが頭の中に入っていく感じでした。

今回出てきた用語を追うことでさらに理解が深められると思いました。後ろに参考資料もついています。

DIコンテナ入門

資料は以下です。

backpaper0.github.io

このころには大体燃え尽きているのでいいセッションがなかったら帰っているのですが、今回はスピーカー・内容ともに楽しみだったので参加しました。

まず、DIの仕組み、および内部生成ではなくインジェクションを使うメリットが説明されています。今までなんとなく把握しているものの、うまく説明できないレベルでしたが、今回はっきりしました。

Beanとコンポーネントは大体一緒というのは「そうなんだ、よくわからなかったけどそりゃ分からんわけだ」という感じでした。

講演者は、主観だとしたうえで、フィールドインジェクションよりコンストラクタインジェクションを使うべきだとしました。

ただ、自分のIntelliJ IDEAだと、フィールドインジェクションはコンストラクタインジェクションにするように警告されます。かなりはっきりとコンストラクタインジェクションを使うべきと言っていいと思います。とはいえ、その理由がよくわかっていなかったので明快になってよかったです。

まとめ

今回のセッションは、自分の興味を惹かれるものがたくさんあってよかったです。

ステップアップセッションのレベル感は自分の予想した通りで、それも良かったかなと。ほぼ全く触ってない分野はちょっと難しいなと感じますし、少しやっている分野については有意義という感触でした。

来期もこの枠組は設けて欲しいなと思いました。

おまけ

初心者向けは埋まるのが早いのでキャパをチェックすべきでしょう。私は一つのセッションが満員で入れませんでした。

紙でもらったタイムテーブルにはキャパが記載されていますが、HPだとないですね。

嫉妬と向き合う

最近「嫉妬なんかダサい、自分を高める努力をしろ」的な言説をよく見ます。個人的には大筋賛成なのですが、モヤっとすることもあるのでもう少し細かく言語化しようと思いました。

まず、先ほどの主張はざっくりすぎるので、以下の3つに分解しました。

  1. 嫉妬感情は醜い

  2. 嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

  3. そういうのを止めて自分を高める努力をすべき

嫉妬感情は醜い

自分の考え:そうでもない。

感情そのものを否定する考えは自分にはないです。なくすことも難しいんじゃないかなとも。感情が出てくるのはしょうがないですが、その後の行動をどうするかの方が大事だと思います。

嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

自分の考え:決めつけはよくないと思います。

相対評価を気にする人の場合、自分より上にいる人を叩き落せば、幸せになると思います。他のパターンでいうと、正義感を持って見知らぬ人をぶっ叩くと幸せになると聞いたことがあります。

あまり表に出しませんが、僕も他人の不幸話は嫌いではありません。とはいえ、周りにそこまでしたい人もいないし、よく知らない人を叩くのは悪いことだと思っているので上記のような行動を起こしていません。

そういうのを止めて自分を高める努力をすべき

自分の考え:上から目線が気に食わないが、内容は同意

自分もそう思う主張なので特に追加したいコメントはありません。

まとめ

そういうわけで、冒頭にある主張をして来る人にモヤッとした場合は、「この人は簡単そうに言っているけど実は嫉妬感情に打ち勝って今があるのかもしれない」と思うことにしました*1

それはそれとして、他人の足を引っ張って喜ぶ人は普通に悪人なのであまりそういった人に関わらないような人生にしたいです。

*1:レアケースでそういった感情が本当にない変人