はじめてのにき

_ 設計ミス

設計ミスってると、ミスってることはわかっても、ミスってるコードに頭がひっぱられて、正しい方針がなかなか出てこない。正しい方針に思い至ってからも、ミスったコードに頭がひっぱられて方針をつらぬけない。全体としてミスったコードが存在しなかった方が速かったんじゃねえのこれってくらいのことになりうる。

こういうのをバイアスかかってない思考の人が強制軌道修正できるのは、コードレビューの良さではあるよなぁ

どっかで設計ちゃんと見直さないと破綻しかない

(09:00)

_ isucon

ひっそりと参加してみたけど、 SQL わかんねえな、って感じで気がついたら終わっていた。サーバ分割とかやろうとしてムダな時間すごして、その後すごい遅いとこいじって一番良かった時で 10000 点くらいの

(20:37)

_ pezy

が今の家からクソ近いことに気付いた

(10:12)

_ 345c 7140cpp 2795py

(20:45)

_ かいしゃ グッドプラクティス

おおむね快適に過ごしてる。普通に粛々とコード書いてる感じなので楽しい

最近少し考えることに、どのくらい前職で良かったぽかったこととかを言うか、みたいなのがある。元々あまりプロセス的なやつ、つまりバグ管理とか、プログラムのコメントとか、コーディングスタイルとか、強い意見がほとんどない。だからプロジェクト変わった時なんかも、新しいところに適当にあわせて生きてると思う

なんかでも、Xはどうしたものか、みたいな会話が行なわれてて、そういえば前職ではXはこういうルールだったなあ、とか思うと、そういう話を紹介したくもなる。ただなんか、その手のルール、そもそも僕は元々好きでなかったもの、正しいかもしれないけど過剰で煩雑だったもの、前職の規模では有用でも他に適用できないもの、実際他でも有用なもの、などあって、はてさてという

あとなんか、有用なプロセスでも人に押しつけられたらイヤじゃない？という話もあると思う。 WebKit でグーグルとアップルが仲良くなかったの、すごく印象的だったんだけど、あれ多分にグーグルの人が「WebKit のこのプロセスはダメだー。グーグルではこうやっているー。このツールを使えー」みたいなことやってたからじゃないかと思ってる。実際、 gyp ゴリ押ししてる時とか、「いいものなんかしらんけど、グーグルがゴリ押ししてる時点で萎えますわ」みたいなこと普通に公言してる人がいたような記憶がある。ここで問題なのは gyp いいものじゃないこともあると思うが(まあでもファイル増やすたびに6つくらいのビルドシステムのファイルいじるよりは当然良い)

そんなこんな。あまり https://twitter.com/imos/status/980764006876028929 みたいに布教するぞ！という気分にはなれないなぁ。しかし何も言わないのもどうかとも思うし、加減がよくわからんな？という感じ

(09:24)

_ kati

もう owner じゃないわけだけど、なんか最近来てた PR が面白い

https://github.com/google/kati/pull/141

GNU make は変数が基本グローバルで色々バグりやすいんだけど、予期してなかった再代入は一つ困りがちなものとしてある。 CXX みたいな変数をトップレベルで定義してたとして、別の Makefile を include したら中で CXX を定義してて上書きされちゃう…みたいな。というわけで kati には

.KATI_READONLY := CXX

とかすると CXX が readonly になる、ってオリジナル特殊変数が導入されていた。これは GNU make の流儀 (.PHONY とかに似てる) にもそってて、 kati で valid なら GNU make で valid であり (GNU make 的には、 .KATI_READONLY への代入は単に無駄な代入)、良いものだったと思う。

でもこの PR は .KATI_READONLY をもっと手軽に作りたいというものらしく、その syntax は

CXX =$=g++

とかいうもの。 $= は普通値が入ってないため、 GNU make でも同じ動きをする、というのは保たれる……んだけど、 =$= の後に空白を入れることは許されていないし、あんまりじゃないかこれって感がある。もうちょっといい syntax 無いものかなあ？

(23:09)

_ NiZ

リアルフォースとかHHK的なやつを作ってる会社らしい。最近の中国はいろんなものを、安く、同じ品質で、カスタマイズ性を高めて、売るなあという感じ

でこれを買ったけどなかなか良さそう

https://www.amazon.co.jp/dp/B075XM7R3W/

レビューにもあるけどリアルフォースとは結構反応は違う。どっちがいいということはよくわからないけど、 NiZ の方が軽い。 NiZ の方があうかもしれない。

カスタマイズ性は、バネを入れれば重さを変えられる、というのと、キーボード側にある(!)ソフトウェアを Windows アプリからいじることによって、キー配置とかを変えられるらしい。ただ Windows 環境がなくてこれは試せてない…

(09:04)

_ 英語

識別子とかまで日本語？と聞かれて。観測範囲では

• 識別子は全部英語
• コメントは入ったチームは英語。まあそもそもコメント少なめ感
• コミットメッセージもチームは英語、別のとこは日本語の人がいたなぁ
• レビューはうちは全部英語、そもそもやってないチームもある
• ドキュメントは日本語が多い感じ
• 重要な手続きとかは日英両方みたいな書き足しを頑張ってるぽい
• TGIF的な会合は英語
• チャットがおおむね日本語たまに英語
• 口頭もほとんど日本語だけど、なんかたまに英語を聞く

くらい

(00:00)

_ PFN

最初の3日の感想

• 想像してたよりは普通に会社だなあという感じ。あまり大きな不満がない
• 仕事はしばらくはすごく楽しそう。まあプロジェクト変えた場合でもそうなるし、これは別の会社にしててもそうだったかなと思う
• 日本語がほとんどなのは、すごく楽…

(18:39)

_ DU

ディスクを整理したい時、長年 DU='du | sort -n' という alias を愛用してたのだけど、止めたくなっても途中経過見られないのが嫌だったのと(まあ止めて走らせなおせばキャッシュに乗ってて十分なことも多いけど)、最近はケタが大きくてぱっと見でよくわからないので、一念発起してスクリプトを書いた

https://github.com/shinh/test/blob/master/DU

• STDERR が tty なら、途中経過を出す
• du の結果を tee に流してるので、 /tmp/du.tmp に途中経過が出る
• /tmp/du.out に最終経過を置いておく
• du と違って 1000 の基数で
• 結果が大きい場合、 Ruby でデータ持ちたくないので持たない
• ソートは万一遅いとイヤなので sort コマンドでやる

というかんじ。まあ便利そう

(16:53)

_ ZenBook 13 UX331UN

いくつか目星つけてたノートPCを見るために秋葉フラフラしてて、ピンと来るやつないなあと思ってたところふっと見つけて、えっこんなのあるの、って買ったやつなんだけど、すごく良い気がする

• i5-8250U: ノートだと i7 は電力的にイマイチな気がする。8世代目はベースとターボブースト時の周波数が全然違う (1.60GHz => 3.40GHz) のでそれも良さそう
• GeForce MX150: 速くはないけど GPU 試すくらいは普通にできるぽい。 X は intel のやつで動かして(たぶん)省電力な感じにしてる
• メモリ8GB / SSD 256GB: もうちょいあると安心だけど、必要十分量
• 13インチ / full HD: 必要十分
• バッテリ: 公称14時間らしいけど、 linux で使ってるとそこまでもつ感じはしない。今度調べるか
• 1.14kg: 普通に軽い。なんか充電器も軽いので良い

20万以上出しても、ここまで僕の要求を都合良く満たすスペックのやつが見当たらないくらいな気がする。安くて良いものが好きな貧乏症としてはとてもいいものだった

(13:09)