╭(・ㅂ・)و hilog

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

201808 振り返り

1年の約7割が終わってしまった。
お盆に読もうと思って実家に送った本を開かずに送り返したのが夏の思い出だな。
最近研修でいろいろすごいエンジニアに会える機会があって追いつかないとなと思う日々。

べんきょうかい

後ろの方でガヤガヤしていてとても申し訳ないことをしたと反省。
そろそろまたチームでの開発をしたいなと最近思うことが増えた。

ほん

ちょっとだけ積読解消。
お盆で実家に帰った際に小説をいろいろ買ってしまい、そちらに割く時間が増えてしまったけど楽しかったからそれはそれでよし。

えいが

最近、僕のヒーローアカデミアのアニメを全部見たのだが、ベタなストーリーにハマってしまった。
ヒーローや努力友情勝利が好きな人には向いていると思う。
アニメ映画多かったけどどれもそれぞれ面白いところがあって良かった。
「怒りそうになったら、おっぱいのことを考えるといいよ。」

ぶろぐ

自分の中で曖昧だったところを埋めれる本を読んだのでまとめてみてた。
それよりも英語しなきゃなーと思ったのでもう1冊。

hihihiroro.hatenablog.com

medium.com

「ビッグデータを支える技術」を読んでみて

ビッグデータという響きに乗って買ったけれども読んでなかったが、お盆で時間もできたことだしと読んでみた。

著者はGoogleを支える技術を書いた西田圭介さん。MapReduceの基本的な考え方を学んだのはこの本だったなと思い出した。

最近はデータ分析についての本が多いと思うが、本書はデータを活用するための基盤をどのようにシステム化するかについて書いてある。

データを

  • どのように集めるか
  • どのように保存するか
  • どのように処理するか
  • どのように可視化するか

がまとめられてわかりやすく説明されていると思った。
特定のフレームワークや技術について書いてあるわけでもなく、データを集め加工するために考えなくてはいけないことが体系立てて書いてあった。それぞれの技術がなぜ生まれたのか、その時々の実現したいことによって適切とされるアーキテクチャについても説明があった。

それぞれの処理で問題になりそうなこと、問題になった際の解決への考え方を書いているのも自分で運用していくために必要な知識としてとても勉強になった。

また、最後の章にはクラウドサービス(AWSGCP、TDなど。Azureはなかった…)によるデータパイプラインの特徴と違いについての説明もあった。
それぞれの違いについても軽く紹介されていたので自分が使う際にどれを使うか選ぶ際の参考になりそう。

まとめ

データの蓄積から分析基盤作りまでが図解込みで優しく説明されていた。いままで有耶無耶になっていた部分を埋めることや、これからデータパイプラインを作成しようとしている人にはとても良い本だと思う。
紹介されている技術については触りしか書いてないのでここで学んだものを自分で調べて使う、構築して綺麗なパイプラインを作っていきたいと思った。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

201807 振り返り

今月は暑いせいもあってやる気があまり出なかった。
仕事がいろいろ忙しかった気もするけど、気がついたらまた1月が終わってしまっていた気がする。
後半はやる気がぜんぜん出てこなくて家にいる間は仮面ライダーWを観ている時間が多かった。
もっと活動時間を増やすようにしたいから動きやすくしないと。

べんきょうかい

データを使うための技術選定、チーム作成について詳しい話がきけてとても面白かった。
自社でも取り入れれる箇所についてはどんどん取り入れて使いやすくしていきたいなと思った。
July Tech Festaは安定のインフラ関連の話が多くて面白かったけど、公式のTOEIC試験を受けに行ってたので2セッションしか聞けなかった。資料探して読もうと。

ほん

部屋をキレイにしたいと思い、見直したところだいぶ荷物が増えてしまっていた。
ミニマリストになりたいわけでは全然ないけどきれいに見える片し方などを勉強したくなって本を何冊か買ってみた。
とりあえず床に積んでしまっている本を片付ければさっぱりするのではと。。。

えいが

応援上映が面白かったな。ただ、観たことない映画だと話分からなくなりそうだから1度観た映画なら行っても良いなと思った。
映画見る本数さがってきたからもう少し見に行きたい。

ぶろぐ

読んだ冊数にたいして2本書いているから面白かった本にあたって良かった。

hihihiroro.hatenablog.com

medium.com

medium.com

「プログラマーとお仕事をするということ」を読んでみて

エンジニア以外の人と話をするときに、気にすれば良いことの気づきを得れるかもと思い読んでみた。

目次は以下

第1章:イントロダクション
第2章:なぜソフトウェア開発は建築と似ていないのか
第3章:アジャイル
第4章:彼らは一日中なにをしているのか?
第5章:緑の大きなチェックマーク
第6章:ジャーゴンの謎を解く
第7章:プログラマーを採用するには
第8章:プログラマーの心を占めるもの
第9章:プログラマーを上機嫌に保つ
第10章:すべてが悪くなるとき

ソフトウェアの開発手法、一般的な用語の説明、採用の仕方、エンジニアの生態までと幅広く書いてある。
たしかにビジネス側の人が知っていてくれれば話すときに楽かなと思う。話をするときに同じ言葉が使えるというのはすごい楽だし伝わりやすいと思う(どこかの会社の英語化をディスってるわけじゃない

ただ全体的にエンジニアを持ち上げすぎている感じはした。物を作るというのはたしかに必要なことだ。
しかし、

  • なにを作るか決める
  • 作る人、リソースを確保する
  • リサーチして改善案を考える
  • お金を調達する

などもとても必要なことだ。
社内でもたまにプロダクトを作って満足している人を見かける。
それをユーザに使ってもらうために、お金を稼いでくる人たちがいることを忘れてる人が多いと思う。
自分たちが作ったものを宣伝してくれたり、トラブルが起きたときに対応をしてくれている人達がいるのだ。
そこら辺を忘れると納期を気にしなくなったり、自分たちの使いたいものを使ってお金に糸目をつけずに開発をしてしまうなどのことが起きてしまう。

ビジネスの人もエンジニアも両方いないとできないことのほうが多いのだから、話をする時間を増やしていくのが一番なのかなと思う。どちらが偉いとかではなくどちらも必要なのだから仲良くするだけで問題ないはずだ。
相手が何を考えているのかなど考えたところでエスパーでもなければ分からないのだから、とりあえず話しかけれるという関係が出来上がっているのが一番良いと思う。

まとめ

  • プログラマーとお仕事をするということを読んだ
  • ビジネスの人がエンジニアをどう思っているのかを知るために読むのも面白いのではと思った
  • まず、話しかけやすい場をつくることをしてみようと思った

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個の「やってみること」が書いてある。定期的にチェックをしてみようと思う。