2019冬休み読書感想文

冬休みは数日、まるっとインプットの日にして積まれた本を20冊よんできました。今回は2018年〜2019年に出た本。主にtwitterとかで見かけた技術書とビジネス書が多め

私←ウェブ系ソフトウェアエンジニア、10年ちょっと業種規模各種

とくにすごい良かった本３冊

おかげで幸せなインプット期間となりました🥰ありがたし

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 網羅的で、具体的。コンテナの時代だけど /procの読み方あたりもカバーしてる
  • それでいてこの薄さ！ すぐ読めるからすぐ読も！
  • とりあえずさらっと読んでおいて、足りてないものないか俯瞰するのにもいいと思う
  • 20冊箱に詰めた中で、2018-2019出た本ということもありDevOps本がすごく多くて食傷気味だったのでさわやかに胃に入ってきたという説あり

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

  • なんかありがたすぎて拝みたくなるような本
  • 私はひたすらコードを書かせてもらっているシニアエンジニアだが、仮にマネジメントをすることがあっても「この本を参考にやっていく気持ちです」と言えるので良い
  • 興味深いのは、人心の扱いに忍術書と符合する点が多かったこと。後書きにチラっと、内観するのに瞑想が良いというようなことを紹介していたので、両者通じるところがあるのかもしれない

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

  • てっきり、「あるひDynamoDBみたいのを急に作るハメになったとき泣きながら読む本」かと思ったら違った
  • とにかくざっくり「データ」に関係する周辺のありとあらゆる、現在ある技術や理論がわかりやすくまとまっている。必見すぎた
  • 訳者も最高か？とにかく説明がわかりやすい。巻末に「用語集」があるのだけど、いかに簡潔さを保ちながら的確な文章を試みてるのがわかるのでそっからチラ見おすすめ
  • ふざけていつも各種RPCを「沼」って呼んでたんだけど、これからは「天空の城」と呼ぶことにします（おもしろ地図が載っているのです）

あと２冊、Clean Architecture 達人に学ぶソフトウェアの構造と設計 と THE TEAM 5つの法則 の話は社内ブログにつづける

ちなみにまだ積ん読、段ボール1箱残っている

2019年に出会ったおもしろアドテク仕様ベスト3

あっけまして、おっめでとーございまっす！！ 本日から始業という方も多い中（おつかれさまです！）私は明日までお休みいただいております😋

そんなお正月気分の謎テンションからお届けする表題の件

⚠️ビビビビ⚠️
びみょうに（ばっちり）仕事と関係しますが、仕事ではおもしろさ度合いに関わりなくいたって真剣に取り組んでいます。あと会社を代表する意見でもないのでヨロシクmm

あくまで仕様として読んでおもしろいところね！

じゃはりきって行きましょう！

第3位!! sellers.jsonとschain

https://iabtechlab.com/sellers-json/

"Header Bidding" を生み出した陣営と、競合しつつそのプラットフォームでもあるGoogle、次々現れる新手の業者、により高度に複雑化したサプライパスに対応するBuyerという構造前提での仕様というだけで、読み物としておもしろいのですがまあそういうのは置いといて、

おもしろポイント: Serialization of SupplyChain object がすごい

sourceの拡張仕様のschain。フィールド名に古き良きOpenRTB仕様踏襲ノリを感じられるあたりが、わりと好きです。

"source": {
    "ext": {
        "schain" : {
            "ver": "1.0",
            "complete" : 1,
            "nodes" : [
                {
                    "asi":"exchange1.com",
                    "sid":"1234",
                    "hp":1,
                    "rid":"bid-request-1",
                    "name":"publisher",
                    "domain":"publisher.com"
                },
                {
                    "asi":"exchange2.com",
                    "sid":"abcd",
                    "hp":1,
                    "rid":"bid-request-2",
                    "name":"intermediary",
                    "domain":"intermediary.com"
                }
            ]
        }

で、上記のようなノードリストをOpenRTB構造体じゃない場合（VAST URLとかで）どうすれば → に対してなんと！ 1つのQueryStringの値に表現するシリアライズ仕様がオマケで付いているのだ〜〜　すご〜〜い

! と , を駆使するのです。上記は以下のようにシリアライズされる

https://すてきなvast.url/?.....&schain=1.0,1!exchange1.com,1234,1,bid-request-1,publisher,publisher.com!exchange2.com,abcd,1,bid-request2,intermediary,intermediary.com

うひ　なんか、厳密にはRFC3986にこれ合っているだろうかこわいよw 私、ふつうにschainのJSON表現をURLエンコーディングするので良かったのじゃないかと思っています🤔

なにより一番おもしろかったのは、「デシリアライズの実装つくっちゃいました〜🙂」っていうニコニコPRが来たことです

第2位!! USP

https://iabtechlab.com/blog/iab-tech-lab-releases-v1-technical-specifications-for-iab-ccpa-compliance-framework-for-publishers-technology-companies/

CCPAのやつ。2020/1/1スタートだから、仕様はどうなるのかしらと思っていたら11/18に出てきました。けっこうギリだな

"regs": {
    "ext": {
        "us_privacy": "1NYN"
    }

us_privacyか〜〜〜　coppa gdprと来ているんだからuspでよかったのにな。国コード_ のノリなのなら3letterにしておいてくれ　みたいな私の好みはともかく

おもしろポイント: U.S. Privacy String format　

ﾑﾑﾑ? 1NYN とは　気になる謎の4文字。それは U.S. Privacy String Format という！　名前がなんか無駄にかっこいいw

急いで出したせいか、仕様のリンクが（PDFにする前の）google docsなのが可愛い

てかあれgoogle docsだったのか

f:id:tomi-ru:20200106225046p:plain

味わいあるフォーマット... こまったら、きっと1文字目（バージョン）が2になって5文字目が登場するんでしょうww

しかしこのある意味単純なフォーマットには副次的な良い（？）効果もあるのです。みなさま第3位をおぼえてらっしゃるでしょうか？！ そう、もしなんか1つのQueryStringのValueにU.S. Privacy状況をシリアライズして送りたい場合 →

.....&us_privacy=1NYN

そのまま使える！良さ（？）が

第1位!! OpenRTB 2.3 buyerid

https://iabtechlab.com/standards/openrtb/

OpenRTB 2.x系最新は2.5（2016年リリース）。2019年といえば3.0も出た年であるのに、何をいまさら2.3、という感じですが、不幸にも平成から令和に持ち込まれたすれ違い仕様案件に出会ってしまったのです〜〜

2.3（2015年1月リリース）は、2.0（2012年リリース）からの既存仕様をベースにしつつnative要素を追加したものなんですが、なんでか公開にする段階で（nativeとは関係のない）既存の userのbuyeruid というフィールドを、buyeridと u を抜いてリリースしてしまっていました。

typoが絶妙で気付きにくいわw（>u<）

これは特に変更を意図したものではなく、半年後に2.3.1としてbuyeruidに戻す修正リリースされています。あと2016年には2.4が出ています。

つまり問題は、2015年前半もしくは後半（2.3.1リリースを知らずに）仕様を読み接続完了した悲しいケース＞＜　悲しすぎる。　話を聞いて一瞬すべてが信じられなくなりましたが、ごく一部だったからよかった

🙇‍♂️

一瞬すべてが信じられなくなり全てを確認している中でGoogleの便利OpenRTB doc viewerとしても使っているこのページ や、大事につかわせてもらっているopenrtb.proto でも間違っているのが発覚

protoの方はPR取り込んでもらえました。やはりふつうに2.3.0ベースの資料だったようですね

github.com

さあ今年はどんなおもしろ仕様に出会えるのでしょうか。はりきって仕事にとりかかるやる気をあと1日で用意しようとおもいます！

今年もよろしくお願いいたします

社内のレポジトリのreadmeテンプレ

会社で、何かのレポジトリをパカ！って開けて出てくるREADME.mdが、 古い・ふんわり・不思議と一部の説明だけ充実している の3Fであることがあり、仕方ないのだけど（事業が継続した＋コードの成長が速い）

情報lessに寄せる方針でなんか整えたいな〜と思い、今年手をつけたレポジトリはついでに手直しした

いろいろ考え落ち着いてきているテンプレこちら

社内のレポジトリのreadmeテンプレ · GitHub

それが（例えばCPANモジュールであるとかで）定番の良いreadmeテンプレがあるジャンルの場合、それに合わせるべき。あとOSSなら"good readme template" とかで検索

ただ、既存社内サービスのアプリケーションコードのレポジトリの場合、そこをパカ！って開けた、やる気溢れる開発者が求めてるのは文章じゃなく

  • これは何なのか（目的のレポジトリか）
  • ローカル開発環境が立ち上がる魔法のコマンドとunit testが走る魔法のコマンド
  • 本番デプロイと確認方法

特に弊社の場合最低ラインこのへんかな〜とおもい上記テンプレになった。

補足

  • DevelopmentとDeploymentという単語が似ているので、トミール内協議の末Developがmentを獲得しました🙂
  • 基本足さないのだけど、適宜design doc的のものを参考にたとえばステート遷移図とかディレクトリガイドとかを足すこともある。
  • ソースコードのコミットがci/cd起点になるので、ビジネス的な詳細とかは、wikiに記載してそこに逃がすようにしてる。
  • CI/CDツールにオシャレバッヂがあればそれもつけている。
  • べつにコマンドはmakeじゃなくてもよい

これがいいのは、

なんか
すごい
わかった気になる
図

この図がホワイトボードの写真とかでも良くて、比較的楽に整然とできあがるところ

いまのところそこまで流行ってるわけではないのだが、今年を振り返りつつ可能な範囲なのでgistにupしてブログに書いてみた次第だ

Gotanda.pm #19

LTしてきました

gotanda-pm.connpass.com

さっこんイベントオーガナイザーの心労は増える傾向と思うのですが、飲食提供かつat homeな場がたのしかったですw

JSON関連のビギナー向けコーナーでは、その週ちょうど業務で「Data::Dumperでintのように見えるけどじつはフラグのアレでData::MessagePackではstringになるやつ」にハマった人をレビューしたばっかりだったのでおもしろかった

LTもじつにperlのLTらしくてよく。use fields推進派があらわれたり

会場提供でもあるモバイルファクトリーさんから、4月入りてたて新卒の方がごたんだpm新人枠でLTしていてGJだったのと、ふつうに二人ともおもしろくてレベルたかいな〜とおもいました

反省/新感覚だったのは、perlの -ple なワンライナートークに対する -e についての質問で「sed以上のことをするにはどうしたらよいのでしょうか？」というような感じ、質問者の質問の仕方がじつに的確すぎて、最初 オッこれは質問ではなくて面白質問オチなのか？と思ってしまった件ですね。そうか -e 's/xxx/yyy/' なサンプルだとsedと同様と見えてしまうのだなと認識しつつ、perlの -e より sed の方が有名なのか。sedってBSDとGNUで違ったり、そもそもsedじゃできないことわりとない？とか思い、perlの地味なマイナーさを認識しつつ啓蒙していこうぞっておもいました

make -fluct

4月🌸〜　新卒入社の季節ですね！

おもえば私もfluct異動してきて早1年。アドテクいちねんせいぶりっこはもう通用しなくなってきました

ふと思い立ち新人向けドキュメントなどの足りなさをなんとかしようと思ったつもりが、謎のテンションでfluct内のプチ便利ツールレポジトリに luct （ラクト）っていうfileを追加しました。中身はただのMakefileですが...

$ cat luct

# vim:set ft=make:
all:
    @echo hi!

こういうことができます！

$ make -fluct

hi!

ネタだけどｵｼｬﾚ⤴️

※ 実際はわりと便利系ツールがどかどか入るような形になっております。

ストイックなMakefileが好きな人が（VOYAGEGROUPの中でも多めに）所属 1 していますし、fluctは 小文字の f で始まるという奇跡のマリアージュ。これがfluctの新入社員が求めていたものでは... ないかもしれませんが🤔

Makefileが好きな人が多く、小文字の f で始まる企業の方はぜひ導入されてはいかがでしょうか！！

インスパイア元 2

あと書いてて思いつきましたが make は C もいけますね。大文字のCで始まる企業のかたは。。。

始まるー！　 CARTAホールディングス所属であるのでした。たとえば make -CARTA を用意したい気持ちになったば場合こういうのでいけますね！（ネタすぎるのでやりませんが）

$ mkdir -p ARTA
$ cat ARTA/Makefile
all:
    @echo hi!

Makefileが好きな人が多く、大文字の C で始まる企業の方はsetupスクリプトをMakefileにしてみてはいかがでしょうか！！

  1. ※2020年完成ぐらいをめざして進行中!! → https://voyagegroup.github.io/make-advent-calendar-2017-to-2018↩

  2. perlにはほんと学びがあるなあ↩

OpenRTBの萌えどころ

※重要※ 書いた人の意見であって所属する組織の見解ではありません

なんやかやでこの移ろうアドテクRTBトレンドを追いかけているがんばり、3.0を出し切ったがんばり評価できる反面、利用者として思うところもあるのですが...

OpenRTB仕様を読み物として読んだ時の個人的な萌えポイントは...

フィールド名のふんわりさ、これに尽きます！

読んだことない方で気になる方はこちら

w に h 、bcat に expdir に bidfloorcur...

CamelCaseでもsnake_caseでもない、略すこともある。この感じ。（なおfloorは3.0で flrになります）

burlとかbcatみたいに、同じレベルのprefix（この場合b = block）続く時は1文字に略すのかな〜と思いきや、adid（Ad ID）adm（Ad Markup）とか、2文字もあるんだねうんうんok まったく問題ないよ！　かーらーの！　adomain（Advertiser domain）

d 1個どこいったー

でも、嫌いじゃないんですよね。

これはもしかしたら、「ある程度内容をわかりつつ（protoみたいな作戦じゃないシリアライズも考慮されるわけで）フィールドサイズも削りたい。でもjson前提で仕様作るのはおかしいわけだけど何か一つの言語の推奨するアレに揃えるのもおかしい　😫うおーーーみんなで😫好き勝手いいやがってーーー」　の末なのか？とかを妄想して楽しくなるわけです（※ちゃんとIABの議事録読んではいない。気が向いたらちゃんと追います🌟

この感じ、JWTを最初に読んだ時の萌えに近いです。

あっこれで「ジョット」って読ますのね（カッコE↑）　しかも何かと3文字っ😍 3文字じゃあもう訳わからなくなってさえ貫くこの感じ萌え！というのに近い

しかし利用する側としてフィールド名は全くなんでも問題ないのだけど、Goとかだと言語仕様的なアレで gen-goしちゃうと無残にも func (m *BidResponse_SeatBid_Bid) GetImpid() float64　みたいなのにされてしまうのだーーー。使う方もgolintにさんざん「だからさ ID みたいのはIdでもidでもなくIDにしようよっていってるやん」と調教されてるんで なんもうれしくなくて不憫😭

かーらーの！

pmp.private_auction

ぷらいべぇと　おーくしょん　に　あんだーすこあ　いれちゃったよぉ

※ 諦めか？！　その後けっこうちらほらアンダースコア入る

あっ🤭　でもま待てよ🤔🤔

private ってフィールド、当時もしかして一部言語の予約語だからあえて回避したんすかね？　そうなんすかね？？

この苦労は泣け...!!

ないよ！　そしたらそこは... pricua これだろ！（←これはない

※なお3.0ではそのままの Item.private になりました⭐︎

そんな萌えポイント盛りだくさんのOpenRTB、2系からの

My Favorite Field Name Ranking Top 3〜〜

1位!!! fd

Final Decision！ ファイナルディシジョン👨‍⚖️　語感がかっこいい！！

なお3.0（というか現在の）Complex supply chainsの流れで削られました〜〜

2位!! tmax

:vim:

ぽくもあるし...

あなたの健康を守りますっぽくもある語感がなんとなく好き

3位! adm

最初、心の中でアダムって読んでましたww　神話的！

中身を理解してからのこのフィールドなんでもありか〜〜感。ついになんでもありフィールド登場か〜〜

と、思いきやアドマークアップだからネ！　とくにHTMLと言ってるわけじゃないし〜〜　XMLもマークアップだしぃ〜　JSONも！　っていやいやそれマークアップじゃなくない！　やっぱりなんでもありかい！

※3.0ではAdCOMっていう概念が導入されました

isucon8予選のはんせい

isucon

http://isucon.net/

去年初めてひとり参加してみたんだけど「これは仕事したことある人と３人でやればわりといけるかな？」と思っていたところ、社内の人にさそってもらったのでチームで参加してみました（タジーに誘われたメンツなので tar.gz 。チーム名だけは良かった）

でも追試でfailするし、failしなくても40位とかなので全然だめだ〜

はんせい点

  • 環境準備とかビルド環境でもたもたしてたら、午前中おわっちゃった
  • 一人がgetEventsを見始めたときに、じゃそれ以外で潰せるところ潰しますって２時間くらい使っちゃって、時間のふりかたダメだった
  • goでやったんだけど、ごめん私急いでgo書く力無かったわｗ 変なところで躓いちゃった（perlのコードきれいだったし、perlでやればよかったｗ

かんぜんになめてましたね。アプリの動作把握とコード書く速度の遅さ認識して凹んだ

問題はおもしろかった！

時間が勝負の世界で楽しむ余裕なかったけど、仕事はもう少し余裕あるスケジュールが組めることが多い（仮）ので実世界で遭遇したらきっと楽しい

ポータルやベンチマーカーもしっかりしてるし、これにタダで参加できるのがすごい。