OSSへの貢献
私信電信(https://shishindenshin.vercel.app)、二回目のテーマは「OSSへの貢献」
1
自分は厳格なFreeSoftware 主義者というほど極端ではないかもしれないがそれよりだと思う。
今まで過程を考えると、高校までまわりにプログラミング言語と英語の区別もついてない田舎でインターネットの情報を頼りに勉強するしかなかったので、OSS特にJavaScriptがメインとなっていく。 そのうちWebFrontendを特に専門に仕事を始めるがこれもOSS無くして成り立たないわけで(最近はSREをやっているがこちらもOSS無しでは成り立たない)、
そういった環境で生きてきたことからOSSに還元すべきという考えに至るのは当然のように感じる
2
とはいえOSSに貢献するということはめちゃくちゃ難しく感じるが、それは難しく考えすぎているのだと思う。
貢献の仕方として例えば、「GitHubのIssueの中からバグや不足している機能を探してきてPRを作成してmergeする」というものがあるが、 このレベルのものはこれが解決しないと業務が進まない事象に直面してようやくできることで、そもそも詳しくないと無理。 「なりたい職業？そうですねぇ。不動産収入の不労所得で暮らしたいですねぇ」ぐらい夢。
だからもっと簡単をする、バグ報告とかドキュメント書くとかブログ書くとか勉強会で{発表,参加}するとかtwitterするとか。 OSSの中の再頒布の自由に近いかもしれないけど、情報を頒布して自由な技術を広めるのもは貢献という意味でも価値が高い。それも気力がいる。
だからもっともっと簡単できて、少しでもOSSに対して貢献できるように大事にしていることは
「わからないことを聞く」「聞かれたら答える」
そもそも人が何をわからないかってわかんないんで、自分がわからないこと、という情報を広めるのは大事。 それと同様に聞かれたら答える。答えたことをブログに書くとかすればベストだけど、一人増えるだけでも良いかなと。
ヒヤリハットのハインリッヒの法則に近いところはあるかなって思っていて、一件の重要なPRは３００件の"わかんない"からみたいなね。
3
ちょっと別の話にはなるけど、OSSの開発者が十分な報酬を受けていないというのは「まぁそうだよね〜〜」って感じで今の会社の方でもスポンサーするにはしているけど（以下のリンク参照）金額の妥当性みたいなところは難しい
いろんなOSSにスポンサーしてる時雨堂とかはすごいなって思う
4
ちなみに自分のここ最近のOSS活動は「NixOSをmac book pro(16.1)で動かす」ということをテーマに空き時間にやっているが、去年の冬ぐらいからやっていてあんまり時間を避けていなのはあるが進捗が乏しい
その活動の中で若干反省があって、
とあるドライバのための以下のnixファイルを書いたんだけど、本家の方にPRを送っていなかった。正直自分しか使わないと思っていたのもあるが、完成してから出そうとしていた
ところが、その後にPRを送った人がいてmergeされていた。
最終的にこっちの方が良くできているから結果としては問題ないんだが、これは本当に良くなかったなって、もっと行動をちゃんと起こすべきだなって反省している。
5
本当に難しいことはApex Legendsに割いている時間をその活動に日々割くことだ。 つまりはモチベーションの維持ということだが。
実際、競技プログラミングって採用時にどうよ？
これは？
私信電信という共著ブログ(?)を友人たちと始めた。
今回「実際、競技プログラミングって採用時にどうよ？」というお題で書く
現状の解説
実際今いる会社ってHRの会社なので、採用側の視点で。
会社の規模はエンジニアが15人ぐらい（全社員で40人中）
採用時のフローは、 カジュアル面談→技術面接→社長面接→トライアル（最近はあんまやってない）
ちなみにトライアルは業務委託契約で1~7日ぐらい既存の課題を手伝ってもらう感じで、互いの負担は大きいがミスマッチは防ぐのが目的でやってる（やってた？）
今のところコーディングテストみたいなのは導入してない。
現職であるところの株式会社HERP では全社員で採用に取り組む「スクラム採用」を推していて、エンジニア全員が面接に出たりする。 面接も出るけど、最近はカジュアル面談をやることの方が多い。
余談だけど、面談した人の面接は出ないようにしている。以下のような理由。
- ジャッジしない体で話を聞いた後にもう一回ジャッジする体で話を聞くのはなんか違う
- アニメもそうなんだけど、性格的に2回目はかなり興味が薄れている
そういえば、構造化面接みたいなことは一瞬やろうとしてたけど結局やってなくて、面接の評価が構造化されているわけではない ジュニアかシニアみたいな区別は今のところ明確には無くて、業務経験のある「ある程度できる人」を採用する感じになってる気がする
競技プログラミングどう？
競技プログラミング関係なく趣味がエンジニアリングに関係することはかなりプラスよね。 土日（平日の夜とかも）の時間の使い方として何かしらやっている人の方が評価されるのはそらまぁ。
競技プログラミングの特性として、コンテストとかへの参加というわかりやすい形で残るのは評価しやすそう。OSSとかに貢献しようとしても土日そのコードを読んでいるだけだと形としてはのこんなかったりするからね。
余談ですが、最近とあるOSSに自分の書いてたコードの上位互換みたいなのがmergeされてて悲しかった（単純にプロジェクトの途中だったのでPRを出していなかった）
これらはあくまでやってるかどうかっていう話なんで、年齢が上がるにつれて可処分時間は減る気がしてて難しい問題ですね、今と比べると大学生のときはめちゃ時間あったので。
とはいえ、転職のために別に趣味でもない競プロやるっていうのはもったいないよね、時間の使い方として。 いい会社に入るためにいい大学に入るために勉強するみたいで、つまらん上にけしからんですね。
転職のために、業務委託でやっていた会社のコードをGitHub上にあげちゃうのも、けしからんですね
今後、コーディングテスト（面接）する？
自分はした方がいいと思っている。 けど、会社の人材要件定義に合うような問題を作るコストがデカくね？みたいな感じになっててやってない気がする 弊社だと、やるとしたらHaskellの型合わせ問題を解くとか特定の言語のサブセットのパーサーを作るとか、フロントエンドだったら簡単なアプリケーションを用意して改造してもらうとかになりそう
既存サービスについて
とはいえ問題を作るのがめんどいので、既存のサービスを使うというのはある。 けど、プログラムがほとんどできない人に対しての足切り的な使い方になちゃうんじゃないかな 競プロの難しい問題が解ける能力を採用時の評価の上で差をつけれないと思う。
AさんとBさんどっちを取りますか？っていう話になった時に、現状カルチャーフィットの方が重視されてる。
今後応募が増えてきた際に使うことはあるかもしれないけど、必要になるほど応募が来るのか？
採用、募集して〼
CockroachDB壊れちゃった話
概要
社内で使っていたツールのDatabaseに実験用途でCockroachDB(v20.1.3)を使っていた。構成は以下となる。
「AWS EKS1.6上にStatefuleSetで3Podで運用。StorageClassはEBS gp2（kube masterのin treeの中にある実装）のPVでデータを保存」
実はこの構成はそこそこ問題があって、Nodeの入れ替えなどでPodの再配置が起きた際に過去のPVと新しく配置されたPodのAZが一致しないとStatusがPendingになりコンテナが作られない。
これはAWSのEBSがAZを跨げないためであるが、 kube1.7以降の環境でVolume Binding Modeを WaitForFirstConsumer にして、CSI Driverがいい感じであればうまく行くという説がある（参照：Storage Classes | Kubernetes）
これは、あんまり興味がない点だったので認識が間違っていて嘘の可能性もある。
そんなこんなで、PendingになったPodを動かすためには以下の２通りのオペをする必要がある。
- Podを削除して、過去のPVと同じAZに配置されることを祈る
- PVかPVCを消すなりして、新しいPodに新しいPVが作られるようにする。
ただ、2のオペレーションをした場合はデータが消えるので、CockroachDBの新規のNodeとしてClusterにJoinすることになる。
経緯
実は詳細な原因が特定できていないので、省かせてもらうがNodeの入れ替え作業中に """いろいろあって"""Clusterが起動しなくなってしまった
以下は現在わかっていること
X日の15:00(JST)ごろに入れ替え作業をして一旦は動いていた
16:00ごろまで以下のログが出始める。
W210126 07:17:43.388615 906 server/node.go:830 [n2,summaries] health alerts detected: {Alerts:[{StoreID:2 Category:METRICS Description:ranges.underreplicated Value:11}]}
上記のWarningが出ている状態でなんらかの原因で再起動がかかり、
server drained and shutdown completed
おそらく正常に終了はしたが、他のPodも以下の状態になってしまう
W210126 07:18:57.177231 201 kv/kvserver/node_liveness.go:488 [n2,liveness-hb] failed node liveness heartbeat: operation "node liveness heartbeat" timed out after 4.5s
17:00(JST)ごろアプリケーションが動いていないことで気づく
エラー内容はこれに近いように感じた。
色々と修正しようと頑張っている内に以下のエラーを吐くようになった。
W210126 13:32:11.928294 156 kv/kvserver/store.go:1631 [n2,s2,r6/3:/Table/{SystemCon…-11}] could not gossip system config: [NotLeaseHolderError] r6: replica (n2,s2):3 not lease holder; lease holder unknown
W210126 13:32:12.743191 127 kv/kvserver/replica_range_lease.go:554 can't determine lease status due to node liveness error: node not in the liveness table
現在振り返って考えると17:00ごろはなんとかなったかもしれないが、21:00ごろから上のエラーがで始めた時点で厳しい感じがする。（＝よくない操作をした）
データ復旧に関して
CockroachDBは様々な方法でバックアップやデータのdumpができるようになっているが、Clusterが起動している状態でないできない。
上のVersionでは内部のストレージ部分にRocksDBを使っているので（最近のVersionはPebbleになっている）RocksDBと向き合いながら頑張ればデータを復旧できるという説がある。自分の認識では理屈上2Nodeのデータがあればいいはず
今回はデータは捨てる判断にしたが、大事なデータを保存していてバックアップもとっていない人はチャレンジするための資料を置いておく
Goを使ってRocksDBから復旧を試みる
データ構造に関しては、以下のスライドが参考になる
以下のソースコードのコメントもデータ構造に関してわかるかもしれない
余談
ちなみにcockroach debug rocksdb でデータを直接操作することができる。
cockroach debug rocksdb scan でK/Vっぽいものを取得できるが、cockroach debug rocksdb get KEY_NAME にscanした結果のkeyを使うことができない。
あまり理解していないが、cockroach debug rocksdb scan は CockroachDBの内部でてくるKey (例：/Local/Store/gossipBootstrap) で、RocksDB側で使われているKeyは別のbinary表現のkeyに変換しているようだ。RocksDBの私が理解していない機能を使っている気がする。
なので、 cockroach debug rocksdb scan と cockroach debug rocksdb scan --hex のvalueを比較することで、同一のkeyを取得することができ、cockroach debug rocksdb get --hex HEX_KEY_NAME でCLIから値を操作することができる。
cockroach debug rocksdb scan はほとんどデータがないはずのDBから数GBのファイルを生成してくるので、地獄みたいな作業になる。
RocksDBの操作はかのブログで雰囲気を察することをお勧めする
CloudFrontが更新前の証明書を返す
事象
なんか会社の テックブログ的な存在の証明書が切れた？？
.@herp_inc https://t.co/PTPR2HARfi の証明書の有効期限が切れています
— 青木華絵 (@aereal) 2020年10月17日
が、しかし普通に繋がる人もいるようで
しかし私のiPhoneからは繋がらない...
上記のブログはCloudFront+S3で構成されているので、AWSの管理コンソールを見に行ったところ、ACMとCFの設定は特に問題はなさそう
どうやら証明書ガチャ（厳密にはCloudFrontのEdgeガチャ）が起きている？？
経緯
確かに、現在の証明書の設定は問題ない、問題はないが実は10/2に証明書の更新に一度失敗している
You have an SSL/TLS certificate from AWS Certificate Manager in your AWS account that expires on Oct 17, 2020 at 12:00:00 UTC. This certificate includes the primary domain herp.co.jp and a total of 2 domains.
で、諸々対応した結果、 10/7に更新された旨の連絡がきて、確かにACM上は更新されていた
This is to notify you that AWS Certificate Manager (ACM) has completed the renewal of an SSL/TLS certificate that certificate includes the primary domain herp.cloud and a total of 2 domains.
対応
これは、CloudFrontの裏側のインスタンスというかエッジロケーション的なSomethingの証明書が更新された場合と更新されていない場合があるぞい、という排中律的な感じがしてきたので裏側をエスパーして対応を考えてみる
まず、Cache Invalidationを /* を対象にやってみる
結果、駄目
次に、同じドメインを対象とした新しいCertificateを作ってCloudFrontの証明書を変えてみる。
結果、会社のメンバーのうち見れてなかった人が「見れるようになった」と報告
う〜ん、直ったんじゃね？
感想
俺たちは悪くないという自信がそこそこあるんですが、AWSさんどうなんでしょう？？？？
これはCFの正常な動作だよ的なことを知っている人がいたら連絡お願いします
はてなサマーインターン行ってきました
はじめに
まず最初にdisclaimerを書かせてもらうと2015年の話です。この記事はインターンに参加したあと5年の月日が流れた30歳の労働者が書いている。 ちょうどはてなインターンが終わって「今から就活だな〜」みたいに考えている人が書いた記事ではない。
なぜ書いたか
事の発端といえば、何の因果か、今ははてなインターンのチームで同じだった id:SWIMATH2 と働いている。
別に急な話ではなくてもう3年以上一緒に働いているのだが、逆に3年働いていると世間話をする機会が出てくる。 そこで急に当時のインターンの話になったので過去サイトを見ながらを振り返っていたら、「（インターンの）参加記録を書いてくれると思ってたのに〜」と言われてしまった。
最初、自分の記事リンクされてね〜〜〜って思ったけどそもそも書いた事実がなかった。疑ってすみませんでした。
そして、懐かしさを感じながら当時のチームメイトのブログを読んだ。
自信がないからといってはてなインターンに応募しないというのは絶対にやめましょう
結構いいことが書いてあって、普通にいいことが書いてあった。
私は当時に25才だったので少し参加を迷ったりしてはいたんだよなぁ、そういう人間にも参加した方がいいと伝えるためにも今からでも参加記事を書いた方が良いな、という優しい気持ちになった。
振り返って
振り返ってみるといろんなシーンを断片的ながら結構覚えていた、自分は結構記憶力ある方なんで。 ただ、上記のブログを読むとなんか大体書かれてて、当時の自分も書くことないな〜ってなって書かなかったのかもしれない、これはおそらく言い訳だが。
以下インターン良かったことリスト
振り返ってみると、やっぱ研修がちゃんとしてるのがすごいんだなぁ。 Perl書いたことがなかったけど、なんだかんだ何とかなる（という気持ちにさせてくれる）というのは研修がよく出来ているということだ。
つまり参加ハードルが実質0なんだよ。あと、5年たっても参加記録を書くというハードルも0だ。
謝辞
当時ののメンターの id:t_kyt id:shiba_yu36に感謝を。
あと過去を含めインターン参加者へ,
時間がたったからと言ってはてなインターン参加記事を書かないのは絶対にやめましょう
そういえば完全に私事だけど印象深いことがあって、当時デパスを飲んでたがなんか覚えてないけどインターン中に飲まなくなった。そのあと今までベンゾジアゼピンは摂取してない。 あれは働きながら飲むもんじゃないなって思ったし、今もそう思っている。
Static Named Directoryの話
abst
Static Named Directoryの話をします。historyに../../とかが入って嫌な人は解決する可能性があります。
困り
おおよそのケースでcwdに依存したビルドは開発体験が悪くなる傾向にあると言われている（私に）
うまくMakefileを書いている場合はそれはまぁ最高なんだけど、適当にcdしてcommandを打っていると引数の中に ../ が混じってきたりする。
混じると何が困るかってhistoryの再利用性が低くなる。怠惰寄りの人間なので過去に打ったcommandを手で打ちたくないのだ。
提案手法
shellの ~ みたいにいい感じにしてぇ~って思って調べたら ~ はexpansionと呼ばれる機能らしい。
zshにはexpansion周りの機能が複数あって、Static named directoriesを使うことにした。
static named directory
~hoge のようなものがparameterにあった際にzshは hoge と呼ばれるnamed directoryを探して展開しようとする。
named directoryは以下の方法で定義される
/から始まる shell のvariablehashcommandを使う (ex.hash -d hoge=/hoge/fuga)
example
今回は git のtop levelをnamed directoryにした。
なので chpwd のhookを使いながらnamed directoryを変えていくことになる。
chpwd_static_named_directory() { local gitroot=$(git rev-parse --show-toplevel 2>/dev/null) if [ ! "$gitroot" = "" ]; then hash -d "git=$gitroot" return else hash -d git= fi } chpwd_static_named_directory add-zsh-hook chpwd chpwd_static_named_directory
これによってgit 管理下においてはどの位置であっても~git をprefixにつけることでgitのtop levelを使うことができる
ex. hoge ~git/src/fuga
評価
top levelにいる際は ~git をつける手間が面倒なのであまりつけないが、それ以外にいる場合 ../をつけなくていいのは便利だしhistoryもclean
git submoduleは使うつもりがないので試していない
あと、 git repoをおくディレクトリを named directoryにしても便利 (ex. hash -d dev=$HOME/git/atsumeta/directory )
僕はmacからiPhoneに通知を送りたいだけなのに
序
macはappleで連携がiphoneで最高、そう思ってました。
時間のかかる長いコンパイルはtwitterをiphoneでみたい。
つまり、人はコンパイルが終わったらiphoneに通知がきてほしい。
破
調査した結果３パターンの提案手法を公開する。
リマインダー.app
リマインダーをmacから登録することで、icloudを経由してiphoneに通知させる手法である。
ただ問題点があってリマインダーの仕様上1分以内のリマインダーを登録することができないらしい。
上のツールの作者が言ってた。ちなみにこれは雑に書かれたリマインダーにswiftで予定を登録するcli toolsで、サンプルとして使ってあげてほしい。
1分ぐらいの誤差を気にしなければこれでok
Universal Clipboard
macos iosのデバイス間でclipboardを共有できるOS標準の機能とショートカットアプリを使った手法である。
ざっくり言うと、mac側からclipboardにcopyして、ios側のショートカットを使ってクリップボードをポーリングする。
以下の画像を見るとショートカットがいかに悲しいか伝わると思う。
ただこれのメリットはmac側のwifiを切っていても成功することである。Universal Clipboardすごい。
下記のリンクからiosの方は取得できる。clipboardにnotificationと言う文字が含まれていた場合、ショートカットが終了して通知される。
https://www.icloud.com/shortcuts/5c275d7f4dc74040960998816f13fe6d
おおよそのmacユーザは使い方を察してくれると思うが、わからない人は pbcopy とかで調べて察してほしい。「どうやってCmd+Cを自動化するんだ？」とか聞かれても困るので。
macos http server化手法
ショートカットとmacosにhttpサーバーを立ち上げてポーリングする手法である
うーん、多分できるけどめんどくさいよね。
SSH
面白い奴だな、気に入った。試すのは最後にしてやる
Q
Universal ClipboardやAirDropはwifiもしくはbluetoothを使っていい感じに通信できているっぽいが、それを開発者に使わせてくれないAppleとか言う企業は一旦OSをGPLで公開すべきである。
