「サーバ/インフラを支える技術」を読んだ

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

10年以上前の本なのだが、古本屋でたまたま手にとって、よさそうだなと思って読んでみた。

冗長化とか構成管理とか、今でも通じる話の基本的な考え方が書いてあって、今読んでもいい本だと思う。

ツールは多分今だと違うやつだろうなとか、これはオンプレ時代だと大切だったんだろうな、みたいな話は流し読み。

個人的に一番よかったのは個別のインスタンスの負荷をどう見ていくかというところ。

ロードアベレージ見て、CPU負荷かI/O負荷か切り分けて、そしてそれがどういう仕組みなのか、みたいなところがとてもわかり易かった。

この辺の考え方はどこかで役に立ちそう。

コンテナベースの世界になるとまた違ってきそうだけど。

前よりはマシになっている気はするが、どうしてもインフラの苦手意識は消えない。

モダンな話は 入門 監視 ―モダンなモニタリングのためのデザインパターン あたりを読むと書いてあるのかなぁ。

それにしても10年前の本だと思うと、はてなってやっぱりすごい会社だったんだなと感じる。

Go で JSON を扱うユーティリティを作ってみた #golang

概要

Go で JSON を扱うときは構造体を用意して扱うのが一般的と思われる。

ただ外部の API 経由で取得する JSON なんかだと、フィールドが大量だったり、階層が深かったりして扱うのが大変だったりする。

一部の値だけ使いたいときにもっと手軽に扱えないかなー、と思ってユーティリティを作ってみた。

github.com

使い方

README とか Example も書いたんだけどこんな感じ。

jsonVal := `
  {
      "team": "FC Barcelona",
      "captain": {
          "name":"Messi", 
          "position":"Forward"
      }
  }
  `
// JSON 文字列からコンテナを生成
container, err := chazuke.FromJSON(jsonVal)
if err != nil {
    panic(err.Error())
}

// Get で ほしい情報にアクセスして Value で取り出す
team, err := container.Get("team").Value()
if err != nil {
    panic(err.Error())
}
fmt.Println(team) // -> FC Barcelona

// 階層化してる場合はこんな感じ
captain, err := container.Get("captain").Get("name").Value()
if err != nil {
    panic(err.Error())
}
fmt.Println(captain) // -> Messi

他にも配列を扱えるようにしたりしてる。

補足

まぁすでに何かしらありそうだなとは思っていたけれど、だいぶ似たようなのがあったw

勉強になったし、作りたいから作ったということで。。

github.com

「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」を読んだ

Amazon の Prime Reading で読めたので読んでみた。

スタートダッシュ方式による時間管理術の本。

自分は一定のペースで走るタイプなので、最初に全力を出す(この本でいうところの界王拳を使う)はあんまり向いてないなぁ、と思いつつ、なるほどなぁと思うところも多かった。

成功者という立場の人が言っているのは間違いない。

だけどそれを踏まえても、自身のやり方がいいと思っているし、読者に心からオススメしたいという筆者の熱い思いが伝わってくる。

こういう人だから成功したんだろうなとも思う。

朝、起きる時間を早めるところから始めてみようかなぁ。

#RSGT2019 に参加して考えたことなど

2019.scrumgatheringtokyo.org

今年も Regional Scrum Gathering Tokyo に参加してきた。

チケット取れずに行けないかなと思っていたけど、December チケットで滑り込み。

RSGT2019 をきっかけに自分が感じたり考えたことをまとめておく。

なので、セッションのレポートでもなんでもない。

成果を測定する

最近は Delivery をうまく行かせることに思考の比重がよっていたと思う。

でも「そもそもなんでやりたかったんでしたっけ?」「求める成果はなんでしたっけ?」という問いと、それは「何(の数字)がどうなっていたら成功なんでしたっけ?」というところは、ちょっと疎かになっていたかもしれないなぁ。

あと人間は見たいものを見てしまうので、「見ている数字が間違っている」可能性も往々にしてある。

求める成果と、成果を計測する指標は必ずしも結びつくものではないということは意識したい。

仕事は成果を、評価は能力を

ビジネスなんだし欲しいのは Outcome でしょ?というのはもちろんそうなんだけれど。

「技術は手段」みたいな言説にも通じるのかもしれないけど、どこかモヤっていたところがあって。

プログラマとかそれに類するような職種って、必ずしも(特に短期的な)成果に直接結びつく仕事をしているわけじゃないですよね。

そもそもが職種的に「計測できるものを作る」のが仕事なわけだし。

例えばすごい技術力があると、成果を出すためのオプションが増えたり、最適な手段を選べたりする。

だけどそれが直接成果になるわけじゃない。

そこに対して「成果を出せ」というのはどうしてもしっくり来なかった。

そんなことを考えていたら、ふと思いついたんですよね。

あぁ、成果で人事評価しようとするからおかしいんだと。

ビジネスは当然成果を求めていくべきなんですけど、人事評価は能力ですべきなんじゃないかなと。

「成果を出したから評価する」ではなく「成果を出す能力があるから評価する」なのであって。

短期的な成果にインセンティブやボーナスはあってもいいとは思うけど。

実験しよう

2018年の RSGT の Keynote で、リチャード・シェリダンが「Run The Expetriment」と言っていたのを強く覚えていて。

そしたら今年の Keynote はクリス・ルシアンが「Start Experimenting」と言っていて。

あぁ、自分の価値観に大きなインパクトを与えてる二人が同じこと言っているんだなぁと思うなどした。

実験しなきゃだめですね。

コミュニケーションの仕組みづくり

チーム開発にはコミュニケーションが重要というのは明白なわけですが。

よなよなエールの、コミュニケーションの「量を増やす」「質を高める」アプローチを仕組み化しているのは素晴らしいと思った。

個人の能力や努力に任せるよりも仕組み化する。

リモートワークみたいなものに抵抗が残るのは、単純接触機会の喪失だったりもするんだけれど、この辺の考え方は大きなヒントになるかもしれない。

マネージャーの心理的安全性

心理的安全性ゲームをやったとき、マネージャーをロールにおいてみたら、びっくりするくらいメンバーの気持ちが離れるのが早かった。

信頼を取り戻すチャンスすら与えられない感じ。

もちろんマネージャーがいろんなことに配慮しなきゃいけないのはそうなんだろうけど、気を遣いすぎて「マネージャーが言いたいことを言えない」っていう状況も健全じゃないよね。

メンバーの心理的安全性を確保する以上に、マネージャーの心理的安全性を確保する方が実は難しかったりするんじゃないの?と思った。

その他

OST ファシリテーターに挑戦したり、終わった後にお声掛けいただいて打ち上げっぽいもの?に参加したり他にもいろいろ刺激を貰ったけれどこの辺で終わりにしておく。

RSGT は年初にやってくれるのがいいね。

今年も頑張ろうという気持ちになる。

f:id:su-kun1899:20190114172856p:plain

「仕事は楽しいかね?」を読んだ

仕事は楽しいかね? (きこ書房)

仕事は楽しいかね? (きこ書房)

Prime Reading で無料だったので読んでみた。

悪くはないと思うのだが、それほど刺さるものでもなかった。

評判がよかったので、期待値が高かったからかもしれない。

どういう層がターゲットなのかはわからないけれど、読むタイミングによっても受け取り方は違ってきそう。

なんとなく、この本で語られているような内容は、違う道でインプットしてきた気がする。

仕事は楽しいかね?」という問に対し、「まぁ、それなりに」と答える程度には楽しんでいるので、あまりこの本は向いていなかったのかもしれない。

Gradleプラグインを作ってみた #groovy #gradle

概要

これまでMavenを中心に使ってきたんだけど、今のチームではGradleを採用している。

Gradle始めて使ってみてるので、試しにプラグインを作ってみた。

どんなプラグイン

github.com

ざっくりいうとただ指定したディレクトリ配下にあるSQLファイルを実行するだけのプラグイン

SQLファイルは構成管理に乗せるようなやつはFlywayなりで扱うと思うんだけど、構成管理に乗らないようなテストデータとかを流すやつがあったら便利じゃないかなと思ったのがきっかけ。

まぁすでにもっと便利なものがどこかにありそうだし、その程度のものならわざわざプラグインにしなくてもいいと思うけど、練習の意味もあるし作りたいから作ったという感じ。

GradleのプラグインポータルにもPublishしてある。

Gradle - Plugin: red.sukun1899.wanko

ハマったところ

JdbcDriverの依存は利用側で設定するようにしたかったのだが、プラグイン側でClassNotFoundExceptionが発生してしまった。

結局後述のリンクを参考に、build.gradleを読み込んでロードするようにした。

def loader = Sql.classLoader
project.buildscript.configurations.classpath.each { File file ->
    loader.addURL(file.toURI().toURL())
}

こんな感じ。 当該コードは下記。

wanko-gradle-plugin/WankoRunTask.groovy at master · su-kun1899/wanko-gradle-plugin · GitHub

参考にしたのは下記。

テスト

テストは下記スライドがとても参考になった。

テストを書いてGradleプラグインの開発効率を改善しよう

JJUG CCC 2018 Fall で登壇してきました #jjug_ccc #ccc_e4

JJUG CCC 2018 Fall にて「複雑なドメインに泥臭く立ち向かう」というタイトルで登壇してきました。

JJUG CCC での登壇は1年ぶりです。

セッション概要

www.java-users.jp

当日の資料

speakerdeck.com

前回登壇したときのブログ

su-kun1899.hatenablog.com

登壇を終えて

今回はスポンサーセッションとして話す機会をもらえました。

正直そんなにキャッチーなテーマじゃないと思っていたし、聞きに来てくれる人いるか不安でした。

それがまさか一番大きな会場になりあんなに人が来てくれるとは。。ありがたい話です。

こんなに大勢の人の前で話すことはこの先もそうそうないのではないか。

緊張の様子。

肝心のセッションの内容ですが、結構言いたいことを好き勝手に行った感じです笑

  • データと情報という切り口でモデルを捉えている話
  • 命名
  • モブプロの落とし穴

といったあたりはどこかで話せたらなぁと思っていたので、発表できてよかったです。

資料のレビュー等々、いろいろ協力してくれたチームメンバーには感謝してもしきれません。

今回の発表で心がけたこと

今回はこれまでの登壇とはアプローチを変えてみました。

今までは資料に割と全部情報を載せている感じだったのですが、「資料を読めばわかることは、資料を読めばいいだけになってしまうので、わざわざ聞きに行かなくてもいい」と同僚のアドバイスを受けてたしかになぁ、と思ったのがきっかけです。

なので資料だけでは伝わらないかもしれないけれど、話す内容と資料とセットで、その場に来てくれた人に一番伝えたいことが伝わることを心がけて話す内容や資料を整理しました。

結果を計測することはできませんが、Twitterや懇親会等でポジティブな反応をもらえたので、個人的にはよかったかなと思っています。

その他

どうしても発表があると心がフワフワして他のセッションになかなか集中できないのですが、下記のセッションはとてもよかったです。

www.slideshare.net

speakerdeck.com

なんだか最近DDDのキーワードもよく聞く気がするし、設計論的なのがトレンドなのかな?