生涯未熟

生涯未熟

プログラミングをちょこちょこと。

オライリーのsafariに関するちょっとアレなところ

とある本が読みたくてオライリーsafariをFree Trialで使っている。

Web上で読むタイプなので、Chromeの翻訳機能使えば洋書でもすいすい読めて使いやすいな、と思ってたのだが一つ重大な欠点を発見した。
それは、Submit Errataが出来ないこと。

Submit Errataは読んで字のごとく、書籍内の誤りを報告する機能なのだが報告の際に該当のページ数の入力が必要になる。
しかし、safariだと肝心のページ数が分からないのだ。

safari独自の報告ページでもあるのかと思いきや特にあるわけでもないので、完全にお手上げである。
暇があったらオライリーのサポートにでもメールを投げるか。

以上、小さな愚痴を書き残しておく。

限界を知りたくてひたすら歩いてきた

GW真っ只中。急に自分の限界を知りたくてひたすら歩くことにした。

ただ歩くだけなのも味気ないので、良さげなスポットをある程度調べてから行くことに。

とりあえず一日歩くと仮定して、20キロちょいを目標とした。
正直この時はハーフマラソンやと思えば余裕やろwww」と高を括っていたが…

出発

モバイルバッテリー、財布という軽装で11時に出発。

最初は東京の大仏がある乗蓮寺を目指すことに。

乗蓮寺

数キロの行程をサクッと終えて乗蓮寺に。

予想の1.5倍はデカくてビビった。
お参りをササっと済ませて、次の目的地松月院へ。

松月院

数百メートル先にある松月院
閑静な佇まいで心が引き締まる場所でした。

お参りを済まし、クルッと振り返ると、

ネオアームストロングサイクロンジェットアームストロング砲じゃねーか、完成度高けーなオイ 。

道中

凄いパンチラインを叩き出す邸宅を見つけた。

赤塚公園

自然が豊かで森林浴が楽しめる公園でした。
都会で汚れた心を癒した。

船渡氷川神社

小さな神社だったのですが、この神社には「十度の宮」という面白いものが祀られていました。

何でも、洪水の度に流された宮がこの地に戻ってきたそうで、それがなんと過去10回もあったとのこと。
僕もこのくらい粘り強い人間になりたいものです。

荒川

暮れ〜なずむ〜街の〜

ひか〜りと〜影の〜なか〜

去り〜ゆく〜あなたへ〜

贈る〜言葉〜

旧岩淵水門

というわけで旧岩淵水門にやってきました。

この水門の横を渡ることが出来るんですが、渡った先が最高でした。

この辺りから「あれ…?足がやべぇぞ…」となってきて、一抹の不安感が。

鯵家

鯵専門店があるという情報を元に行ってきました。

16:30にして、やっとまともな食事にありつけたのと、美味さで泣きかけました。

retty.me

亀ヶ池弁財天

亀〜

道中

途中、人懐っこい猫様に遊んで頂けました。
ありがたし🙏

近藤勇墓所

十条を抜けて

俳句に想いを馳せつつ

到着

どうやらここには近藤勇の胴体が眠ってるらしいです。
板橋駅すぐそこにこんなのがあるとは。

さて、この辺りで時間は既に18:30になり、正直足はガクガク・足裏はキツキツで帰りたくなりましたが心を鬼にして池袋へ向かうことに。

道中

謎のエナジードリンクに助けられました。
死ぬほどしんどい時に甘いものってマジで効果あるんすね。

謎にマットレスが落ちてました。
マットレスと孤独感を共有しました。

旅の終わり

そんなこんなで19:30、ついに…

やったあああああああああああああああ!!!! 池袋だああああああああああああ!!!!

足の痛みと疲れもあって、到着した時マジで泣きかけました。
生きてる証拠だよ!!

結局、11:00〜19:30の約8時間半で28キロ走破することが出来ました。
これが今の僕の限界です、本当にありがとうございました。

祝い

走破記念に一人で焼肉をしました。

A5ランクの肉を食いまくって、疲れからか吐きそうになりました。足るを知れ。

retty.me

こんな馬鹿みたいなことも30代になると出来なくなるかもしれないので、備えよう。

クソ雑魚ナメクジの転職ドラフト結果

medium.com

この記事読んで、転職ドラフトの結果を書くのも面白いなと思ったので書いてみる。
転職ドラフト自体は第2回から参加しているので、参加した回の結果を記載する。

尚、筆者はクソ雑魚ナメクジエンジニアなので、チョットデキルエンジニアの方々の参考にはならないだろう。

第2回

  • 企業数:3社
  • 最高提示額:800万円
  • 平均提示額:686万円

800万とか提示されて完全にビビった。

第3回

  • 企業数:1社
  • 最高提示額:460万円
  • 平均提示額:460万円

有名所でもこんなもんかー、と少しがっかり。

第5回

  • 企業数:1社
  • 最高提示額:550万円
  • 平均提示額:550万円

まぁこんなもんだよね、と納得

第6回

  • 企業数:2社
  • 最高提示額:680万円
  • 平均提示額:590万円

Fintech案件はやっぱり提示額高いなと思いましたまる

第7回

  • 企業数:1社
  • 最高提示額:550万円
  • 平均提示額:550万円

スカウトメッセージがめちゃくちゃ熱かった。
初めて返答して会社まで訪ねた。

第9回

  • 企業数:5社
  • 最高提示額:650万円
  • 平均提示額:610万円

有名な会社からドドドッとスカウト来て焦った。

第10回

  • 企業数:4社
  • 最高提示額:730万円
  • 平均提示額:687万円

こっから「スカウト来たとこ訪ねてみっか」と色々行って疲れた。

第11回

  • 企業数:1社
  • 最高提示額:550万円
  • 平均提示額:550万円

表示年齢が30台前半になったからか、ガクッとスカウト来なくなった。

まとめ

クソ雑魚ナメクジエンジニアの僕の市場価値が丸分かりですね。
こうやって市場価値という現実を突きつけれられると、もっと頑張らんとなという身が引き締まる思いになります。

頑張ってJPYマイニングしていこうな!!!!!

Goの勉強会を開催してみました

エンジニア人生の中で初めて勉強会なるものを主催してみました。

gounconference.connpass.com

なんでやったの?

Go界隈ってあんまり勉強会開催されてないんですよね。
なんか好きな言語の勉強会があんまり無い状況ってのも寂しいので、自分でやってしまおうと。

あと、なんかラフな感じでGoのことを喋る勉強会ってのが一つくらいあってもいいかなと。

やってみてどうだった?

ひたすらに疲れました・・・
勉強会を主催してる人達すげぇなってのが改めて分かりました。

もう一つ、キャンセルされると予想以上に凹むなってことも分かりました。

今後

今後も定期的に、あまり間を空けずにやっていこうかなと思っています。
レベル関係なく参加しやすい勉強会を目指して頑張ります。

ということで、今月2回目を開催するのでよければ是非。

gounconference.connpass.com

lock-freeを考える

考える発端となったのは以下の記事。

stackimpact.com

GoのPerformance Turningに関する記事なのだが、気になる項目が。

Favor lock-free algorithms

ふむ🤔

www.slideshare.net

ほう?🤔

MutexやSemaphoreで排他制御を行なうのではなく、CASなどを使ったlock-freeを実装した方が良いらしい。

CAS

値の書き換えが想定通りのものなら、実際に書き換えを行なう。
書き換えが出来るまで、何度でも繰り返す。
→ 但し、問題もある(ex. ABA問題

上記のCASは有限のステップ数で処理が完了しないため、lock-freeではあるがwait-freeではない。

Goの場合はどうやるの?

Goの場合、atomicパッケージにCAS実装がある。

atomic - The Go Programming Language

package main

import (
  "sync"
  "fmt"
)

var (
  balance int32 = 100
  wg = sync.WaitGroup{}
)

func main() {
  // expect: balance = 55
  var i int32
  for i = 0; i < 10; i++ {
    wg.Add(1)
    go withdraw(i)
  }
  wg.Wait()
  fmt.Println(balance)
}

func withdraw(amount int32) {
  balance = balance - amount
  wg.Done()
}

しかし、この方法だと当たり前だがgoroutineの処理タイミングによって全く違った値が算出される。 そこで、以下のようにCASを用いる。

package main

import (
  "sync"
  "fmt"
  "sync/atomic"
)

var (
  balance int32 = 100
  wg = sync.WaitGroup{}
)

func main() {
  // expect: balance = 55
  var i int32
  for i = 0; i < 10; i++ {
    wg.Add(1)
    go withdraw(i)
  }
  wg.Wait()
  fmt.Println(balance)
}

func withdraw(amount int32) {
  for {
    if atomic.CompareAndSwapInt32(&balance, balance, balance - amount) {
      break
    }
  }
  wg.Done()
}

すると、想定した55の値が常に算出される。

Mutexの中身は・・・

結局、CASを使っていたりする。

// Fast path: grab unlocked mutex.
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
  if race.Enabled {
    race.Acquire(unsafe.Pointer(m))
  }
  return
}

パフォーマンスの差異

実際にパフォーマンスに違いは出るのだろうか? ベンチマークを取ってみる。

  • old: use Mutex
  • new: use CAS
benchmark         old ns/op     new ns/op     delta
BenchmarkDo-4     4028          3670          -8.89%
BenchmarkDo-4     4000          3683          -7.93%
BenchmarkDo-4     4014          2934          -26.91%
BenchmarkDo-4     3516          3043          -13.45%
BenchmarkDo-4     2759          3660          +32.66%
BenchmarkDo-4     4030          2883          -28.46%
BenchmarkDo-4     4025          3802          -5.54%
BenchmarkDo-4     4027          3358          -16.61%
BenchmarkDo-4     4046          3602          -10.97%
BenchmarkDo-4     3749          3363          -10.30%

全体的に早くはなっているが、たまに致命的に遅くなる。

さて、実行するgoroutineの数を増やすとどうなるのだろうか?

  • 1000
benchmark         old ns/op     new ns/op     delta
BenchmarkDo-4     271236        266445        -1.77%
BenchmarkDo-4     275415        267188        -2.99%
BenchmarkDo-4     269019        269459        +0.16%
BenchmarkDo-4     272291        271073        -0.45%
BenchmarkDo-4     273410        269671        -1.37%
  • 10000
benchmark         old ns/op     new ns/op     delta
BenchmarkDo-4     2782914       2831663       +1.75%
BenchmarkDo-4     2712926       2936499       +8.24%
BenchmarkDo-4     2748464       2891509       +5.20%
BenchmarkDo-4     2810436       2844462       +1.21%
BenchmarkDo-4     2738268       2875502       +5.01%

む?なんか段々とMutexに負けてるぞ🤔
何故だ・・・

結局どうすりゃいいのか?

多大なコア数を持つCPUでないと、CASなどのlock-freeの効果は薄そう。
以下のリンク先にも書いてあるが、実際に80coreで動かした場合にMutexがボトルネックになったようである。
そういう時にはlock-freeを使う意味が出てきそう。

texlution.com