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

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

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

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

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

構成とオススメの進め方

本書は１～８章で文法や関数の説明、９・１０章が例題であとはおまけです。

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

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

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

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

車輪の再実装

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

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

まとめ

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

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

はじめに

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

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

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

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

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

www.oreilly.co.jp

gihyo.jp

accounts.booth.pm

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

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

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

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

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

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

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

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

富豪的な紙の技術書

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

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

まとめ

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

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

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

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

エンジニアが学ぶ物流システムの「知識」と「技術」

対象読者

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアの役割分担

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

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

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

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

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

まとめ

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

先行レビュー

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

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

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

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

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

ソフトウェアデザイン 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:レアケースでそういった感情が本当にない変人

『Java本格入門』で、Javaの知見を体系的に濃縮する

Javaのプログラムを書いているとき、「これはベストな書き方なのか？」という疑問は常にあると思います。ネットで調べる、レビューを受けるといった、確認方法はいくつかあると思いますが、その一つが本書になると思います。

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

表紙の情報量が非常に多いのが特徴です。

対象読者層

「はじめに」に書いてあるのでほぼ合っていると思います。

オススメな人

• Javaをある程度お仕事で書いてきた

• 体系的に学びなおしたい

お仕事で書いてきたというのは、実際に稼働するコードを書いた。また、他人の書いたコードを読んだり直したりしたことがある、という意味です。

向かない人

プログラミング経験がほとんどない人

特徴

トピックは多岐にわたりますが、全般的にめちゃくちゃ絞り込んであります。「本格入門」であって入門書ではないので、ある程度文法を分かっている前提で進みます。

また、筆者のこれまでの経験を生かして、「結局どうすればいいか」が書いてあります。

例えば、インタフェースのデフォルト実装をとりあげます。

抽象クラスとどのように使い分けるのかという疑問について、「インタフェースのデフォルト実装は基本的に使わなくてよい」と簡潔に答えています。

理由としては、

デフォルト実装は、Javaの「過去のバージョンとの互換性*1」のために生まれた

という、Javaの歴史を感じるものになっています。納得感のある説明になっていると思います。

デザインパターン

GoFのデザインパターンは23種類もあって身に着けるのが大変ですが、本書では9つに絞って紹介しています。

結城『デザインパターン入門』に比べると、書中ですべてのコードを載せているわけではありませんが、実際に使いそうな例になっています。

Abstract Factoryパターンでの呼び出し側のコードは以下の通りです。

public class SampleMain {
    public static void main(String... args) {
        String env = "PostgreSQL";
       
        Factory factory = createFactory(env);
        Connection connection = factory.getConnection();
        Configuration configuration = factory.getConfiguration();
    }

    private static Factory createFactory(String env) {
        switch(env) {
            case "PostgreSQL":
                return new PostgreSQLFactory();
            case "MySQL":
                return new MySQLFactory();
            default:
                throw new IllegalArgumentException(env);
        }
    }
}

ただ、個別のパターンの解説の詳しさは、結城本のほうが上回っています。例えば、このパターンでは「工場」を増やすのは簡単です。OracleFactoryは既存の実装に影響を与えずに追加できます。一方、新しい「部品」、HogeSettingsを追加しようとすると、すべての既存の「工場」に影響が出てしまうので大変です。そのような説明が結城本に記載されています。

本書でも記載はありますが、個人的には結城本を読んで初めてちゃんと理解できた印象です。「わかっている人にはこれくらいの説明で十分」という感覚ですかね。

記載のないもの

後半で、デザインパターンや各種ライブラリの説明がありますが、基本的には各クラス内で、どのように書くべきかという説明が中心になっています。設計的な話はあまりないのかな*2という印象です。

まとめ

ブログタイトルに「濃縮する」と書いた通り、コンパクトに必要な記載を詰め込んでいるのが本書の良いところだと思います。

余談ですが、私は6年くらい前に筆者たちが所属するアクロクエストテクノロジー株式会社に1日インターンに行ったことがあります。当時は1ミリもプログラムを書いたことがなかったはずなのになんで行ったのか全く覚えていませんが、こういった形でまた巡り合うことになるとは、不思議な縁を感じます。

*1:具体的には7と8

*2:一定レベル以上のクラス設計は本書の対象外という記載もある