非同期プログラミングにてRxを使って思ったメモ
サーバーサイドの非同期呼び出しを含む処理を簡潔に書くためにRxJavaを使用していて、もっとうまくやれたらなと思うところが見つかったのでメモ。 ざっくり書くと early returnみたいなことがRxJavaだとやりにくいなと思った。
DBやAPIの呼び出しが同期呼び出しだったらこんな感じで書きたい処理も
// DBからなにか取ってくる value = xxRepository.find() // 空だったら NOT_FOUND返す if value is null return NOT_FOUND // サポートされてない値だったら NOT_SUPPORTEDを返す if value.getX() == ppp return NOT_SUPPORTED // API呼ぶ response = xxClient.call(value) // レスポンスが失敗だったらエラーを返す if response is not success return ERROR // 成功したら記録する yyRepository.save() return OK
非同期だとそうもいかないので、こんな感じで今は書いていて、nestが深かったり、本来は最初の値が取れない時点でreturnしたいのに結局最後にその分岐の処理を書いていたりしていてイマイチだなとおもっている。
// DBからなにか取ってくる
xxRepository.find()
.flatMapSingleElement(value -> {
// サポートされてない値だったら NOT_SUPPORTEDを返す
if value.getX() == ppp
return NOT_SUPPORTED
// API呼ぶ
return xxClient.call(value)
.flatMap(response -> {
// レスポンスが失敗だったらエラーを返す
if response is not success
return ERROR
// 成功したら記録する
yyRepository.save()
return OK
})
// 空だったら NOT_FOUND返す
}).toSingle(NOT_FOUND)
Coroutine使えば、↑の同期処理のときみたいにかけて幸せになりそう。
素数のプログラミングへの応用 (hash function)
hash functionの計算に素数のマジックナンバーが使われているけど、31の理由がはっきりはしなくて、モヤモヤする記事です。
素数みんな好きですよね。ただ、あまり多くの開発者はで素数判定のアルゴリズム使うことはないかも。どんなとこで使われているのか気になって調べてみました。 素数のプログラミングへの応用で多くの人が最初に思いつくのは、暗号かと思います。共通鍵暗号で使われているのは素数というより素因数分解の難しさですが、素数がめちゃくちゃ日常に入り込んでいると言えるかもです。
そしてもう一つパッと見つかったのが、hash function。JavaのString#hashCodeには素数31が使われています。
こちらはJava8の例
/**
* Returns a hash code for this string. The hash code for a
* {@code String} object is computed as
* <blockquote><pre>
* s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
* </pre></blockquote>
* using {@code int} arithmetic, where {@code s[i]} is the
* <i>i</i>th character of the string, {@code n} is the length of
* the string, and {@code ^} indicates exponentiation.
* (The hash value of the empty string is zero.)
*
* @return a hash code value for this object.
*/
public int hashCode() {
int h = hash;
if (h == 0 && value.length > 0) {
char val[] = value;
for (int i = 0; i < value.length; i++) {
h = 31 * h + val[i];
}
hash = h;
}
return h;
}
この31はどこから来たのでしょうか？ この記事にあるように確かに数字に対するmodを計算してhashを計算するのであれば、素数の方が良さそうです。
しかし上を見てわかるように、JavaのString#hashCodeでは s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] のように一つ一つの文字にかけ算をして足し合わせています。
ただ、こちらの記事には、
Primes are unique numbers. They are unique in that, the product of a prime with any other number has the best chance of being unique (not as unique as the prime itself of-course) due to the fact that a prime is used to compose it. This property is used in hashing functions.
「素数はユニークだからかけ算をした値も元の素数ほどではないがユニークである」と書いてありますがいまいちピンと来ません。
以下の記事は31じゃなくて109の方が衝突少なくていいよってのを確かめている面白い記事。
なんとなくもっともらしいのはこちらの論文。 526pageに以下のような文があります。
We have done some experimental studies that suggest that 33, 37, 39, and 41 are particularly good choices for a when working with character strings that are English words. In fact, in a list of over 50,000 English words formed as the unionof the word lists provided in two variants of Unix, we found that taking a to be33, 37, 39, or 41 produced less than 7 collisions in each case! I
ただ、31と書いてないような。。
Effective Javaの第二版に以下のような文があり、衝突が少なく、計算が高速であるということで選ばれている雰囲気はあります。
A nice property of 31 is that the multiplication can be replaced by a shift and a subtraction for better performance: 31 * i == (i << 5) - i. Modern VMs do this sort of optimization automatically.
私が思うエンジニアリングマネージャーの役割と特性
同僚のエンジニアリングマネージャーの方が約半年を振り返った考えさせられる記事を書いていたのに触発されて、周りの何人かの方とエンジニアリングマネージャーに関して話しました。 その会話を踏まえて、今いる会社に近い会社ではエンジニアリングマネージャーにはどんなことが期待されてて(役割)、どう言う人が向いていそうか(特性)を考えて文章にしてみました。
役割
- チームのアウトプットを会社にとっての成果として最大化する
- メンバーの向き先と会社の向き先をそろえる
- メンバーの持つエンジニアリング力を100%出せるようにする
- チームで取り組むべき課題や方向性を示す
- チームが課題解決出来るようにする
- メンバーの成長やキャリアを考える
- 新しいメンバーを採用することを考える
- チームメンバーを評価する
- 説明責任を果たす
特性
- 目的志向である
- 視座が高く、視野が広い
- 課題解決能力が高い
- 問題解決の手段にこだわらない
- 「選択肢＝自分ひとりでできること」となっていない
- 特定の解決策に固執しない
- 自分や自分の状況と相手や相手の状況に合わせてコミュニケーションできる
- 不完全な状況でも意思決定ができる
マネジメントと言うのは管理ではなくて「なんとかする」みたいな意味だとするとなんとかすれば方法は色々あるよなと思いますし、どう言うメンバーがいるのかや会社からの期待というのも会社によって違いそうです。 そして、人それぞれのマネジメントスタイルがあるかもなーとも思います。 自分がマネージャーだった時を思い出すと以下のような感じかも
自分のマネジメントスタイルは問題を見つけて、それをチームの問題だと認識してもらうようにして、メンバーに解決可能であると思ってもらうみたいな感じだなと思う
— nakaly (@nakaly) July 30, 2020
マネージャーの読書会を開いた話
概要
今年3月から、マネージャーたちに声をかけて、希望者で読書会を始めました。 読みたい本はslackで募集して決めました。 読書会は、ABD (Active Book Dialog)的に読む時間+共有の時間で構成される1.5hで行いました。 マネージャー同士でもあまり話したことないパターンもあるので、初回には参加者のお勧め本を共有するのをアイスブレイクとしました。 読後の感想はこちら
基本情報
ざっくりアジェンダ
- 5 min 集まる & 雑談
- 20-30min それぞれ読み読んだ内容をまとめる
- 15min * 3-4 読んだ内容の共有とコメント
人数
5人 (ただそれぞれ来れない時もあったので、それぞれの回に来ていたのは3-4人)
場所
zoom
頻度
週一
共有時に出た話題メモ
- 評価やOKRの話
- 前職で品質向上のための標準化をしてた話
- ある部署で機能していた測定指標を無理やり横展開しようとしていた
- マネーボール
- 塁をどれぐらい奪うか/ 打球の角度などを計測
- 合理的・合理主義者
- 自分の今捉えている前提における合理を正しいと思い込みすぎる弊害
- サービス開発のKPIの話
- 大学の測定実績のリアルな話
- ソフトウェア開発における指標とは
- Deploy / Developer /Day
- LeanとDevOpsの科学［Accelerate より
- Deployment Frequency
- Lead time for changes
- Time to restore service
- Change failure rate
- PRのmergeされるまでの時間を計測していた話
やってみての感想
どうやったら勉強会/読書会の満足度が上がるかという質問に以下のようなフィードバックをやったマネージャーからもらいました。
- ケーススタディやロールプレイなどの自分たちの状況を踏まえた上でどうやるかのディスカッションの時間を作るなど
- 辞めずに継続的にやっていけば自然と上がる気がしています
- やはり1時間半の時間をどう捻出するかというところが一番気になるところです。自身も、新しい本を皆で読みたいという気持ちと、貴重な1時間半を業務に使えないというジレンマが正直ありました。 実際参加すると自分一人で読んでいては気づけなかった視点や、情報を聞くことができ、とても有意義でしたので、まさに長期的視野に立てるかどうかの部分だと感じています
その場で読むので、宿題として読んでなくてもいいから脱落しづらいというのはあったと思うのですが、忙しい方達を毎週1.5hというのはなかなか難しいとこではありました。 また、共有の時間とコメントは特にやり方を決めてやってたわけではないのですが、より実戦に取り入れていけるようなやり方でできると多くの人にとって費用対効果がいい形にできるかもと思いました。
測りすぎとサービスのKPIそしてデータとファクト
測りすぎを読んでサービスとKPIの関係が気になっていました。 KPIはないとせっかく色々やっても反省できそうにないから必要でしょって思ってたんですが、測りすぎを読んで弊害もあるよねということで改めて考えてみました。
もともと何かしらの施策をやる前はKPIばかり気にして、ユーザーの課題を解決する的な側面が薄い施策はなんだかなーって思ってしまうけど、施策やった後はKPIでどんな変化があったかをみたい的な考えていました。
そんな時にめちゃタイムリーなpodcast/youtubeがあって、自分の理解ではそこでこんなことを言っていました。
人間の脳もある刺激に対して、報酬を与えるようになっていて、それがあるから人間は素早く学べる。KPIもサービス開発における脳の報酬系のような役割を果たす。 でも、人間の脳もバグっているから、砂糖とかを取りすぎて太って不健康になって死ぬみたいなことがある だからと言って、脳にある報酬を与えるシステムがいらないってわけではなくて、まずいことは理性で止める必要がある。 会社も同じでKPIがないと改善していくのは難しいけど、KPIだけを追いかけるとまずいことが起きるので、ビジョン・ミッションみたいなところで本当に大事なところは判断する。
いやーなるほどという内容だし。実際にメルカリで働いて、その後企業している人から聞くと説得力がある。その中で、さらにデータとファクトに関して話していて、
データとファクトは違う。データ分析した結果はファクトとは限らない、違う前提でデータを集められても結局一番やりたい判断に使えない
という話がめちゃ共感できると思いました。去年読んだデータ分析のめちゃ基礎の本でもデータ分析はデータを集める前から何かしらの仮説を持って始めるという話をしていて、データを分析した結果ってさもファクトのようにいう時もあるけど、それすらもこの世の事実のある側面を捉えようとしているということだから、結局何かしらの意思や意図が含まれているだろうし、むしろ含まれているべきってのはあるなと思いました。
それにしてもこの回のKPI警察の癖が強いw
測りすぎを読んで
測定結果と報酬/評価を結びつけることの弊害
書いてあったこと
本には様々な弊害が書いてあるが一つ大きな問題としては、測定した結果を直接個人や組織の評価と報酬に結びつけることだ そうすると、個人や組織は測定結果を上げることにのみ集中してしまい本来やるべきことをやらなくなる 例えば、病院において「術後30日の生存率」を測定しそれを元に評価してしまうと、病院は直すのが難しい患者を避けるようになったり30日は無理やり生存させるようにしたりする
感想
“What measured gets managed”という言葉を聞いたことがあって、いわゆる人事評価に定量的な指標のみを使うとそれだけを上げようとしてしまうということの弊害は認識していたけど、たくさんの事例とともに紹介されてて、例えば、googleのpagerankや食べログの評価などは本来は良いwebpage/良い店を見つけるための指標だし、単一の指標ではないはずだけど、どうしてもそれだけを目的にランキング操作されてしまう。例えば、人間をAIが置き換えるという話をした時に、いわゆる強化学習といったなんらかの価値関数を最大化する機械学習を使った時に、価値関数のみ(e.g. 売上)を最大化させちゃったら持続可能でなかったりなんらかの弊害を生みそうだなと思った
測定とマネジメント
書いてあったこと
組織がより大きく多様になっていく中で、経営トップと実際の活動を取り組む人との間の隔たりがますます大きくなって、組織が複雑な構成要素で作り上げられるようになると、全てを理解することが不可能になる。トップにいる人々は時間や能力が限られた中で判断を下したり、過剰な情報を処理したりしなければならない。その際に、測定基準は魅力的な手段に見える。 経営するために雇われただけの、組織について無知な経営陣が現場に実績測定を要求することがある。無知は現場知識がない中で組織にぽんと入ってきたことが原因である場合が多い。経験と現場知識は重要なので、経営陣は内部から選ぶべきだ。
感想
人間の認知や認識にもバイアスがあるため、トップが完全に感覚で意思決定している場合は、例えば意思決定に一貫性がなかったりして、働く人は困りそう。例えば、アマゾンのジェフベソスが「意見で決めるなら、私の意見が常に勝つ。しかし、データは意見に勝つ。だからデータを持ってこい」というようなことを言った話聞いたように。データは組織の中の権力構造の外側にいるので説得する上でも有用な手段になりそうだが、トップが自分の無知や経験のなさを隠すための手段として、数字だけを見て経営するようになると上手くいかなくなるんだろうなと思う。
効果のある測定
書いてあったこと
作業を行う当人たちが実績を内部で監査する目的で使うデータと、第三者が報酬や懲罰のために使うデータとを区別することが重要。テストなどの測定ツールは貴重だが、現場での制約などを理解することができない第三者による外部評価よりは、現場の人間が内部で分析を行う際にもっとも役立つ。測定実績のシステムが機能するのは測定される対象の人々が測定の価値を信じている場合のみ。
感想
例えば、ソフトウェア開発においても、ベロシティ(開発速度)を自分たちの中でどのように変化していったかというのを理解するのに使うのは意味があるが、複数のチーム間で比較したり、それに基づいて報酬を与えたりするようにするとその数字に対して嘘をつくようになるのは実感としてもわかる。チームや組織において、現状を把握しようとして、測定したりするはずなのに、それを元に評価しようとすると、結果数値が偽物の数値になって現状がわからなくなるという状況に陥ってしまうことはありそう。
透明性の弊害
書いてあったこと
我々が自我を持てるのは、我々の考えや欲望が他人に対して透明ではないからだ。誰かと親密になれるかどうかはその人間に対して、他の誰かよりも自分をもっと透明に魅せられるかどうかによって決まる。政治においても、政治家のやりとりが完全に透明になっていたら、率直な対話と独創的な駆け引きをすることができなくなる。政治において、アウトプット(=社会的・経済的傾向について政府が作成するデータや法規制などの政府の行動の結果)は可能な限り一般に公開すべきだが、インプット(=政策決定者や公僕たちの議論)は公開すべきではない。ブラッドリー・マニングが軍や国務省の機密情報を公開したが、これによって、アメリカの外交官が招待的に機密情報を集めにくくなっている。会話の機密性が信頼できないとなれば、話すことができなくなる。
感想
自我が保てるのは、秘密の部分があるからというのは考えたことなかったけど面白い考え方だなと思う。情報をすべての人に公開するというのはやはり弊害も大きいし、信頼関係がないと公開したくない情報というのは絶対にあると思う。なので、1on1だったり少ない人数でより率直な意見を共有できる場所を作るのかなと思う。また、slackなどのチャットツールで1to1のチャットDM(Direct Message)を禁止すると結局他の手段でやりとりが発生してしまうという話もあったけど、やはり必要悪的なところはあると思う。
