ひよっこエンジニアの独り言

メーカー勤務ソフトウェアエンジニアのブログ

【書評】ふつうのLinuxプログラミング

書評

次のプロジェクトでLinuxベースの組み込み開発を行うので基本のおさらいで読みました。

本書では、Linuxの概念として、ファイルシステム、プロセス、ストリームを取り上げそれぞれ解説しています。 普段なんとなくでやっていたCentOSのサーバー管理や大学時代に勉強したソケットなど、それがどう動いているか網羅的にわかって良書でした。

C言語の実装をやっているだけではシステムコールやlibcの差をあまり意識しませんが、システムコールに重点を起いて解説が書いてあるので非常に勉強になります。 写経までやらずに、読み物としてLinuxの基礎知識のおさらいするのに向いています。

トランペット練習日記20190511

かなり調子がいい。唇の周りの筋肉に負担がかからず、柔軟に吹けている

調子を整える

どうした日は調子が良いか?考えることが大切な気がする。 自分の場合は、前回トランペットを吹いてから、次にトランペットを吹くまでの累計睡眠時間が10時間以上20時間以下くらいだとかなり調子がいい。 逆に6時間睡眠くらいで連日練習すると、疲労が抜けずていない感じがする

調子がいい日の状態

ウィンドコントロールと唇のグリップがちょうどよい感じ。 自分の課題は、この2つの調整にありそう。 適切な唇のグリップ感で、適切にwindをcontrolし適切なwind powerで吹くことが大切。 どこかのバランスが崩れると、唇の周辺筋に負担がかかり(例えば適切でないwindpowerで吹くと、その分唇のグリップを強めにやる必要があるはず)疲れやすかったり音が当たりにくかったりするのかなぁ。

ある音に対してwindpowerが不足=>唇のグリップで頑張る ある音に対してwindpowerが過剰=>唇のグリップで頑張る or グリップが支えきれず息が漏れて音が外れる。無理に当てようとすると意識的に唇をグリップしないといけない=>疲れる。 になる。結局全ての音に対して適切なwind powerを体に身に着けて、その量をwind controlすることが大切になるんだろうな。

なんて繊細な楽器だ!!!

【書評】クリーンアーキテクチャ

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

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

書評

あんくるボブの経験則から導き出したアーキテクチャ

基本的なSOLID原則からしっかりと解説があり、初心者にも優しい作りになっていると思います。 フレームワーク、WEBに表示するかどうかなどを全て「詳細」と位置づけ、より抽象度が高いレベルで設計を扱っています。 フルスタックフレームワークなどを”詳細”と位置づけることは、なかなか難しいですが、そこらへんはどうなのでしょうか…。これこそがアーキテクトの腕の見せ所?

コード例が少ないので、Qiitaなどで実装された記事を読むとより理解が進むと思います。 詳細な解説は下記の記事がわかりやすいです。

qiita.com

クリーンアーキテクチャの大事なポイント

色々と議論ありますが、「SOLID原則を守ること」、この課題に収束するのだと思います。 SOLID原則を守ることで、メリットは

  • 循環依存が起こらない
  • 変化に強い
  • テスト可能

になるのだと思います。 TDDかじってた人間からすると、「テスト可能」が一番インパクト強いです。 単体テストないと色々と担保できなくなるので…

実装時のポイント

本にも書いてありましたが、最終的にアーキテクチャが守られるかは実装者の力に依るところが大きいと思います。 また、実装者への依存を避けるためにCIなどで監視していく仕組み(check style, understandなど)は必要です。 アーキテクチャを作るだけでは意味がないので、どう継続させるか、も非常に大切な点だと今回本を読んで理解できました。

美味しいコーヒーショップ

名古屋の桜山にある吉岡コーヒー。

coffeey.exblog.jp

名古屋らしく平日はモーニングをやっているらしいです。 インドネシアのマンデリンを購入しましたが、粒が大きく、マンデリンらしいコクのある味でした。

転職活動始めてみた

ITエンジニア入社5年目にして転職活動始めてみました! 2つのサイトでTry中です。

ビズリーチ

日英の職務経歴書を登録しました。

ベンチャーや時折日系の大企業からカジュアル面談のお誘いをそれなりにもらえます。自分が聞きたいもののみ行けば十分かと。

リクルートなどの大手のエージェントはあまりいなくて、特定の分野特化のエージェントが多いイメージです。  

Linkedin

適当に職務経歴を英語で書いて、転職フラグをONにしておいたら勝手に連絡が来ます。

ビズリーチとは異なり、外資系の企業(IBMやらGAFAやら)、と大手の日系企業(N産とか)、と大手外資系の転職エージェントがメインです。

MicrosoftGoogleのリクルーターもLinkedinでカジュアル面談で声をかけたりするらしいです。自分はMicrosoftとN産からお誘いを頂きました。 基本英語でメールが来るので、英語のいい練習になるかもしれません。笑

所感

とりあえず転職活動を始めるなら、上記2つのサイトを使ってエージェントに頼らずカジュアル面談を受けてみるのが良さそうです。 案外他社のビジョンやエンジニアと話をしていくなかで自分の気持が整理できて、指針が見えてくるかなーと。 年収交渉や予定調整はただただめんどくさいので、最終的に指針が決まってからエージェントを使うで充分だと思います。

そのうちコーディングテストについてもまとめよーっと。

追記: コーディング試験は、Qiitaでまとめました。

コーディングテストに打ち勝つ - Qiita

【書評】マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

書評

マイクロサービスについてアーキテクチャ的観点から解説した本です。 単なる設計観点だけでなく、モニタリングや回復性といった分散システムの様々な観点からマイクロサービスでどうするべきか、著者なりの考えが記されています。

面白かったのは、最初からマイクロサービス化するのではなくドメインへの理解が進んできた段階でBundleContext(境界づけられたコンテキスト)でサービスを分割していく考え方です。 システム構築のはじめからマイクロサービス化を考慮しながら進めるのかと考えていましたが、そうではなく分割するべきタイミングで分割するのが大切なようです。 結局は、 システムがモノリスになった段階で、ドメイン分析を行い正しいと考えられるコンテキストで分割した結果マイクロサービスになる、のかな。

最後の付録で、AzureServiceFabricの解説があったけど、Kubernetesでないのは時代的背景だったりがあるのかもしれません。

この本の前提として、ドメイン駆動設計があるので、そちらともペアで読んだほうがいいかなーと言う感じでした。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

おすすめする人

数年くらいWEBシステム構築に携わってマイクロサービスに興味がある人。 システム設計初心者には難しい本かも。

【書評】アジャイルな見積もりと計画づくり

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

書評

ずっと積ん読だった本。 アジャイル界隈では名著として扱われています。 読んだ結果、やっぱり名著でした。 各章ごとにプラクティスやその考え方が非常によくまとまっています。

最後の章では、アジャイル開発を始める開発チームが立ち上がっていく様子がケーススタディとして取り上げられています。 それまでの章で書かれていたことが忠実に物語に落とし込まれているなーと言う印象です。 これからアジャイル開発を始める方々には、開発者やPO含め皆に読んでほしい本です。

「見積もりと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。」

個人的な考え

アジャイル」という言葉が使われて結構経って、今では当たり前のようになっています。 若干言葉が先行してうまいように使われているだけな気もするけど、本当に大切なことはアジャイルマニフェストに書かれていることが実現できているかで、今の自分達がアジャイルかどうかはどうでもいいんだよなーって思ったり。 agilemanifesto.org