╭(・ㅂ・)و hilog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

201806 振り返り

久しぶりに勉強会に行った。他の会社なり他の人なりが楽しそうに様々なことを試しているのを聞くのは自分もやろうというやる気が出るので適度に勉強会には参加しようと思う。
コンテナ周りやオーケストレーションをよく触っているけどまだ自分の中でもどうすれば良いのか悩むことが多いのでそのへんのベストプラクティスをもっと追求していきたい。あとはデータの収集をどうにか綺麗にしたい。

来月はもっと本読んで僕もなにか勉強した共有しようと。

べんきょうかい

microserviceの話ってことだったので申し込んでみた。
サービスディスカバリとかログどうしてるとか聞きたかったけどインフラよりの話はなかったな。
次はインフラの人もいるともっと話ができるかなと思った。
相変わらず人見知りが発動してしまった。

ほん

仕事の関係でマニュアルを読むことが多かったので、技術書を読む気力が起きなかった。
ベースキャンプのしごとの仕方は面白かったので、取り入れれそうなことをチームメンバと試していってみよう。
部屋の写真をたくさん見たので今の部屋を綺麗に整えていきたい。まずは本を減らすことが必須になるけど。

えいが

日本語の映画のみになったのは久しぶりな気がする。
映画見てから原作を読む事が多いんだけど、このパターンだと登場人物の想像ができなくなってちょっと悲しいなと気がついた。

201805 振り返り

今月はもう終わりなのかと思ったほど時間がすぎるのが早かった気がする...
kubernetes上でシステムを動かすことにして、ローリングアップデートとかログ周りとか気になることが多い。この辺知見のある人達とお話したいなー。

先月参加したJapan Container Days v18.04で応募したら、おうちkubernetesセットをサイバーエージェントさんからいただけました。ありがとうございます!!
少しづつ組み立てて遊ぼうと。
おうちkubernetesについてはこちら

ほん

今月は疲れていたので漫画と小説多め。
6月以降はまた積読の技術書読んでいこうと思う。

えいが

GODZILLAが3部作みたいだけど本当に次で終わるのかな。
まだ見れてないアヴェンジャーズをやってるうちに観に行かなければ。

ぶろぐ

最近は技術そのものというよりも、開発手法とか思想とかについての本を読むことが増えた気がする。
もう少し手を動かして遊びたくなってきたのでまた何かの技術について本を読みながら触ってみる時間を増やしていきたい。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「リーン開発の本質」を読んでみて

結局なんだっけって思うことが多いのでリーン開発の本質を読んでみた。

リーンソフトウェア開発の原則として7つのことが書いてあった。
本書ではこの原則の説明が事例と一緒に豊富に書かれていた。

原則1 : ムダをなくす(Eliminate Waste)
原則2 : 品質を作り込む(Build Quality In)
原則3 : 知識を作り出す(Create Knowledge)
原則4 : 決定を遅らせる(Defer Commitment)
原則5 : 速く提供する(Deliver Fast)
原則6 : 人を尊重する(Respect People)
原則7 : 全体を最適化する(Optimize the Whole)

ムダの定義

チームが行う活動の中で、顧客に価値を提供するために役に立っていないものを「ムダ」と定義し分類されている。

未完成の作業のムダ
余分な機能のムダ
再学習のムダ
引き継ぎのムダ
タスク切り替えのムダ
遅れのムダ
欠陥のムダ

開発者にとってのムダとはなんだろうと考えてみた。
最も大きなムダは技術的負債なのでは無いかと思う。
古代遺跡のようなアーキテクチャ、古文書のような手順書、暗号文のようなコード。どれをとっても機能追加や新規開発にとって邪魔になるものであると思う。
技術的負債を減らすことで、開発速度の加速もバグの埋め込み減少もできるのではないかと思う。開発者にとってのムダの削除とはナニハトモアレ技術負債を無くすことなのではないかと。

最後にリーン開発を行うための10個の「ロードマップ」と21個の「やってみること」が書いてある。定期的にチェックをしてみようと思う。

「Infrastructure as Code」を読んでみて

Effective DevOpsを読んだ。
その中で4つの要素が必要なものと書いてあり、そのうちのツールについて勉強しようと思いたって積読になっていたInfrastructure as Codeを読んだ。

インフラをコードで管理することができる。コードで管理できればソフトウェア開発のプラクティスをインフラにも適用できる。プラクティスとは以下のもの。

  • ヴァージョン管理
  • テストの導入
  • CI/CDの導入

クラウドやオートメーションツールの普及によりインフラに変更を加えることが簡単になったため、コンピュータリソースのテンプレートや設定ファイルでインフラを管理するようになった。ツールを使うことで手作業を減らしミスを減らしていく。
また、マイクロサービスのような新しいアーキテクチャが標準になってきたことにより、必要なサーバ構成も変わっていく。アプリケーションの変更に付随してインフラも変更を余儀なくされることが多々ある。

  • 大きく変更させるのではなく小さい変更を適度に繰り返す
  • モニタリングの設定、確認
  • 高速なフィードバックに対する対応
  • 継続的なテスト

強く納得したのは以上のことだった。これらは、アプリケーション開発では当たり前の事のように言われていることだなと感じた。(できているかはともかく…

まとめ

Infrastructure as Codeとはインフラ、アプリケーションと関係なくリードタイムを短くすることを目的とした手法を考えて実行していくこと、またそのようなことができるチームを作っていくことなのだと思った。
今後どのようなアーキテクチャやツールが標準になっていくかは分からないが、すぐに対応できるようにインフラもアプリケーションも細々と勉強し続けようと思う。

おまけ

ちょうど本を読み出す前に監訳の@gosukenatorさんの書斎についての記事を読んだ。その中でブックストッパーが紹介されており、本を開きながら書く際にとても役に立った。便利便利。

201804 振り返り

気がついたら36歳になってました。ほしいものリストから沢山のお祝いを頂きました。
送ってくださった皆様本当にありがとうございます。直接くださった方も同じくありがとうございました。何かのタイミングでお返しができればと考えています。

自分の市場価値を知るために転職ドラフトを試してみました。
8社からお話をいただき、最高金額750万円、平均665万円でした。今の自分の値段が分かったので外の人と話をできればなと思います。是非色々な会社の人と話をしてみたいなー。

べんきょうかい

コンテナの勉強のため1日カンファレンスに参加してきた。
コンテナというよりはKubernetesの勉強会かと思うほどKubernetesについての発表が多かったけど面白かった。
ログ周りとかイメージの作成についてとかチームメンバーでもう少し話し合ってみようと思った。

ほん

積読になっている技術書を少しずつだけど読みはじめた。自分は本を読む時に絵として理解できないとあまり覚えれないので読むのに時間がかかってしまう。部屋の本を減らすためにもちょっとずつでも毎日読み続けるようにしよう。
あとは睡眠時間を少し削ってみるか。
TOEICの勉強法についての本を何冊か読んだ。文法、単語、発音の基礎をやり時間をかけて苦手科目を埋めていくしか無いんだろうな (あたりまえ...

えいが

今回のコナンは警察の説明がたくさん出ていて子供が理解するのが大変そうだなと思った。
いぬやしきの飛行映像が綺麗だった。また、CGの勉強してみようかな。

ぶろぐ

自分の中であまり理解できてないDevOpsについて学ぼうと思って読んだ本と、コンテナの勉強しに行った勉強会についてブログ書いた。
コンテナでの標準的な決まり事とかベストプラクティスとか色んな人と話し合ってみたい。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

Japan Container Days v18.04 に参加してきた

ベルサール神田で行われたJapan Container Days v18.04に参加してきた。

mesos + marathonを使用してコンテナ化したアプリの運用を2年ほどしてきたのだがまだまだ勉強不足だなと感じることが多々あるため詳しい方とお話できればなと思って参加しようと思った。

参加してきたセッションは以下

あれ?Kubernetesって名前ばっかり見える。
イベントの名前なんでしたっけ?と思うほどKubernetesの話ばかりだった。
Kubernetesを知らないなんて...って言われてしまうほどスタンダードになったんだろうなと。

一部の発表を除いてどの発表もすでに数年以上運用をしている人たちの発表ばっかりだったのでとても生々しい話が聞けたし、自分で構築運用をしていくうえで考えなければいけないことが分かった気がした。

いろいろ学ぶことが多かったけど今回自分の中に残ったのは

  • 必要なものがあったら自分達で開発して置き換え
  • 開発するためにソースコード、基準を学んでおく
  • 担当する箇所によって学ぶべき事柄は変わる

書くと当たり前なことだけど、自分ではできてないなと思いながら話を聞いていた。OSSなのだから足りない機能は自分で開発して取り込んでもらうこともできる。開発するための定義については公開されている (ex. OCICRI)ことさえ守れば問題ない。

また3つ目については、アプリエンジニアは要件を出してDockerfileを書くことでコンテナを作れるまで行う、SREが要件通りに実行できる環境を構築するというメルカリの事例を聞いた内容からの感想。アプリエンジニアは自分のできるアプリケーションを作成するのとシェルスクリプト感覚でDockerfileを書いて終わり。気がついたらコンテナがKubernetes上で動いていて要件が達成されていた。
これはチームとしての働き方として理想だなと思った。チームが目的を共有していてメンバーが自分のやるべきことをやることで最短で結果を出す。アプリエンジニアはKubernetesについて詳しくなる必要がないし、SREの方はコンテナを要望通りに動かす環境構築に集中すれば良い。

個人的に面白かった発表は、Container Networking Deep DiveDockerだけじゃないコンテナruntime徹底比較!Istioと共にマイクロサービスに立ち向かえ!。最初はネットワーク、次はruntimeをいろいろ検証してみたっていう話。インフラ周りの実証結果を見るのが楽しかったし自分でもあれこれ試してみたいと思った。
最後はマイクロサービスとの戦い方。Istioが思っていたよりもできることが多かった。資料は読んでみたけど試したことまだないから検証導入していきたいなと思った。発表資料の中にIstioを始めるまでのロードマップがあったので試してみよう。

まとめ

きっとコンテナを直接どうこうということはないんだろうなと思った。コンテナを運用するためのオーケストレーションだったりコンテナを見つけるためのサービスメッシュだったりコンテナをどう隠して運用できるかの話にすすんでいるだろうな。このままだとおいてかれてしまうから勉強しなくては。いろいろ刺激的な1日だった。

他にも面白そうなコンテンツばかりだったから帰ったら資料探してみようと。

宣伝

Kubernetesについて自分なりのまとめを作っているので宜しければ

「Effective DevOps 」を読んでみて

devopsってなんだかよく分からなかったので読んでみようと思った。

これをやればdevops、これを守ってなければdevopsではないみたいな明確な定義がされていない。
ただし必要な要素はあるらしい。それが以下の4つである。

コラボレーション
アフィニティ(親近感、一体感)
ツール
スケーリング

最後まで読んで思ったのは、一貫してチームとして働くことの大切さが書いてある。
自分の中でこういったことかなと思うったのは以下。

  • チームとして活動するのだから失敗を恐れずに、失敗から学んでいく。
  • バージョン管理システムを使おう
  • 非難のない文化、組織的な学習、多様性をもったチーム
  • 「私」よりも「私たち」で物事に対応することが大切であるとのこと。
  • すべてのメンバーを価値ある大切な人として認めて受け入れる

それぞれの章ではチームとして働くために必要なことの説明が書いてあった。
仕事で関わりのある人と話をして問題を解決していく。当たり前に思えることだけども、実際にいろいろなチームや人と話してみるとできていないことがよく分かる。もっとみんなちゃんと話をすれば簡単に解決するのにと思うことが多い。

技術的な問題よりもチームとして働くための文化を作ることがよっぽど大事なことなのだろう。

結局大事なことは個人で働くのではなく、チームとして働くことが大事なのだろう。
その働き方がモブプログラミングと呼ばれたりdevopsと呼ばれたりしているだけなのではないかと思う。

すべてのメンバーを価値ある大切な人と思い、健全なシステムを構築・運用していくためのチームを作り活動をしていくようにしたい。