はてなブックマーク

自分は Twitter や Facebook などのソーシャルメディアが好きではないが、これらが発明した良いアイデアには目を向けたほうが良いと最近は心を改めた。 Twitter の良さ: 文章は可能なら短い方が良いと示したこと。そして短い文章を映えさせるためにコンテンツ本体以外の装飾を取り払ったこと。 Twitter 以前は、文章は長い方がエラかった。これは単純化しすぎた主張だが、長い文章を書いたり読んだりする方が偉い風潮は少なくとも一部にはあった。今やオンラインでそういう立場を取る人はマイノリティになった。これは Twitter だけの功績ではないかもしれないけれど、果たした役割は大きいと思う。 長い文章はしばしば読むよりも書くほうがラクなので、短い文章は書き手の負担が大きい。コンテンツが希少な時代は書き手に権威があったので長文を書き散らすことができたが、コンテンツ過剰な現代は書き手がエ

最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。 ・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ（などの得意だったおたく分野）はつまらん」というのと同じ現象が自分に起きているだけな気がする。 キャリアの停滞 まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわ

少し前に JIRA is an antipattern という記事があり、盛り上がっていた。どうも ticket を assign するという形で micromanage されることがあり、それが嫌という話らしい。 これはツールの濫用/誤用であるというのが主要な反論で、そうだろうとは思う。一方でツールやプロセスが暗に促す方向というものもあり、JIRA は micromanagement を遠ざけるような力を持っていない。それはそれできっと事実なのだろう。 自分は勤務先内製の bug tracker に長いこと不満を持っているわけだが、ひとつだけ良いこともあると気づいた。このツールは管理職が下々を micromanage するには出来が悪すぎるのである。一方、むかし Pivotal Tracker を使っているチームの TL/M によるものすごい micromanage を目撃したことがあり

C++ を書いていると、数年のブランクがあるにもかかわらず妙な安心感がある。自分は間違っていない、というと語弊があるが、自分の間違っている程度を自分はわかっている、というような。コードの質もなんとなく高い気がする。 仕事で Android アプリの Java を書いているときはそこまでの confidence を感じない。そこそこだろうとは感じている。 Python とか JS を書いていると、我ながらこのコードはダメだなと思う。しかしどう良くしていいか検討もつかない。似たような話を前に書いた気がする。 最近のモダンメインストリーム言語、すなわち Go, Swift, Rust, TS とか全然使えない。Kotlin は Better Java として使っている範囲ではそこそこだと思いつつ、Kotlin を活かしている感じはない。 自分は学生時代、 C++ の習得に莫大な時間を費やした。学

単なる「プログラマ」でありたいと願っていたが、その夢が破れつつあると感じる。今の自分はモバイル・プログラマである。今から他のものになるのはだいぶ大変。 気のせいかもしれないが、世の中からも単なる「プログラマ」は姿を消しつつあるように見える。だいたいもうちょっと限定がついている。Frontend engineer, backend engineer, SRE, data scientist とか、いわゆるインターネット企業の中だけでもこれだけある。自分が学生だった 15-20 年前にこうした細分化はなかった気がする。もちろんゲームとエンタープライズのような業種の壁はあったけれど、それ以上は細分化していなかったような。 自分の視野が狭かっただけで、昔からそれなりに色々あった可能性はある。逆に、自分と同年代の知り合いにもたとえばガラケー向け組み込みから現代的なモバイル、ウェブ、今はクラウドバック

On 20-Percent を読んだ知り合いから反応があった。自分の考えをもう少し整理し、「20パーセント制度」の語りをめぐる自分の中のわだかまりを三つの論点にまとめてみる。 ひとつ目は、勤務先の中の人の語りは盛り過ぎではないかということ。20パーセント制度の成功例としてよく Gmail が引き合いに出される。Gmail はユーザ数が 1B を超える超大成功製品である。そんな成功を生んだ制度ならたしかに自慢の甲斐もある。しかしこの主張の信憑性は薄い。Paul Buchheit はインタビューの中でこう話している: [Larry] and Wayne Rosing, who was the VP of Engineering at the time, would sit down with engineers and give them projects. When they sat dow

しばらく前から仕事のログ解析に Google Analytics をエクスポートした BigQuery を使っている。BigQuery を Jupyter 経由の Python から呼び出し Pandas で整形可視化する。久しぶりにするモダンぽい仕事で楽しい。 アプリのログ解析は大半が内製のシステムを使っているのだけれど、クライアント側の開発者が勝手に使う部分では歴史的経緯で GA が使われている。自分はもともと GA のダッシュボートなんてしょぼすぎて使い物にならないと思っていた。でも BigQuery にエクスポートできると知り試したら別物のツールになった。 SQL と Pandas を組み合わせて使うのはちょっと不思議なかんじだ。たとえば histogram を描きたいとする。Pandas だけなら hist() を呼ぶわけだけれど、SQL を使うと bucketing は Big

Amazon, Play Books 余暇に Python を使っている都合から読んだ。なんとなくでしか Python を使えない人向けに、もうちょっと真面目に理解すると色々良いことあるよ、というスタンスで書かれた本。自分は書捨てのぶんにはなんとなくの理解でいいと思いつつ、ライブラリなどオープンソースのコードを読むとわからないことが多く苦労していた。この本のおかげでその不安が和らいだ。 トピックの選択が見事。自分が知りたいと思いつつ面倒で放置していた話題を軒並みカバーしてくれている。具体的には Unicode, generator, metaclass. それ以外にも色々知らないことがあった。自分は Python について、今となっては特に新しいところのない退屈な言語という印象を持っていた。「新しいところがない」という部分の印象は変わらないけれど、退屈というほどで もないとわかった。それな

Packt, Amazon, Play. Scikit-learn の使い方が知りたくて読んだ。TensorFlow は cross validation とかを手伝ってくれないので別の道具がほしかったのと、 Keras が scikit learn 互換だと何かで読んたため。 Scikit-learn を知るには良かった。知りたかったこと (Pipeline の使い方や GridSearch などの話題) がきちんとカバーされていた。コードは割とちゃんとしていると思う。著者は scikit-learn にちょこっとパッチを書いたりもしているらしい。 Machine learning 自体の学習にはいまいち。アルゴリズムや数式の説明の仕方がよくないと思う。知ってる人の復習にしかならない。アルゴリズムの説明は飛ばし読み。そのほか Web アプリを作りましょう、みたいな話も飛ばし読み。最後にで

古いコードの依存関係を整理するなか、"utils" というパッケージが依存関係の mess になっているのに気付く。Utils. そういえば昔はよく目にしたけれど、最近はあまり見なくなった。なぜかと考える。 プログラミング言語が強力になったのが理由の一つだろう。昔だったら Verb-er や NounUtils などと銘打ったクラスに追い出したくなる boilerplate ぽいコードが、今なら短くインラインで書ける。あるいは同じファイルの中に小さなクラスを定義するだとか適当に extension method を生やすとかでしのげるようになった。 あとは文法だけでなく標準ライブラリも充実した言語が増え、それまで各人が再発明していたコードが標準でついてくるようになった。これは言語デザインの主流が委員会ベースからコミュニティベースに移り、割と荒削りなものでも便利なら標準につけてしまうことが増

次に読む本を探すべく Amazon.com をうろうろしていたのだけれど、技術書は少し Amazon で探しにくくなった気がする。電子書籍重視な新興出版社の本は Amazon に無い・・・わけではないにせよ、O'Reilly とかと比べいまいちレビューが伸びない傾向を感じる。具体的には PragPub, Manning, No Starch Press あたり. Packt も新興のはずだけど、なぜか割とレビューついてるね。 自分は PragPub や Manning からよく本を買うのでややバイアスがあるかもしれないけれど、彼らの出版社の本を買うときってだいたい promotion mail 経由なのだよな。しかも Beta/MEAP として最終版ができる前に買う。こういう相対的に熱心な読者は、結果として Amazon では買わずレビューも残さないのだった。技術書の中でも要素技術解説系の

ここ数年で使っているやつが２つ増えたのでふと紹介してみる。 OneTab - Chrome Web Store TabCopy - Chrome Web Store OneTab は開いているタブを全部閉じた上で開いていたタブのリンクへの一覧を一つのタブに表示してくれる。閉じると必要な URL がわからなくなる漠然とした不安からタブは開きっぱなしにしがちだけれど、リンクを一覧に残してくれるので安心して閉じられる。そして必要なものはタブの一覧からよりページにまとまったリストからの方が探しやすかったりする。 TabCopy はページのタイトルを URL をリンクした状態でクリップボードにいれてくれる。ので Blog とかを書くときに便利。リンクは Markdown 形式でもコピーできる。 自分は最近は仕事の journal を Google Docs につけているので、必要な資料へのリンクとか

自分は丁寧に(大げさに)コードを書きすぎる傾向があって、それは premature-optimization であったり over-engineering であったりしてよくない。でもガっとでかい関数を書いたりクラスを定義せず tuple で済ませたりする脳の負荷が苦手で、大げさに書く方に逃げてしまう。結果として見通しの悪いコードができあがることが多々ある。 逆の傾向を持つ人もいるだろう。雑に書きすぎて、いわゆる「汚いコード」になってしまう。世の中的にはこっちが多いことになっているけれど、自分は大げさサイドなので正直そうなる人の気分はわからない。 そのバランスは最終的にはリファクタリングして正せばいい、というのはその通りなのだけれども、自分の傾向を把握して意識的に初期値を決めてやるのも自分のバイアスを治していく上では必要に思える。大げさに書く傾向のある人は意識的に雑に書き、逆もしかり。 あ

The ChangeLog で CNCF の話を聞いた。CNCF, できたときはどうせ形だけの組織なんでしょと斜めに見ていたら割とまじめにやっており、かつうまくいってるらしい。Google のように control freak ぽい会社が Kubernetes といういかにも戦略的なコードをわざわざ第三者に明け渡す。誰が決めたのか知らないけど、よくやったと思う。 ここで年来のファンタジーが頭をもたげる: Chrome も Chromium Foundation になっていたら良かったのになあ。WebKit Foundation でもいい。そしたら Electron とかもみなそこにあつまったろうに。 そうならなかった理由はわかる。なにも動機がない。彼らには巻き込みたい他人というものが特にいなかったろうし、そもそもウェブには標準というものがあり、そっちで協業してる。それに Chrome を始

Blog の話を書いたついでに。 Social media 全盛の時代にプログラマがブログを書く意味はあるのだろうか。もっというと、それは職業的な役に立つのか。そして役に立てたいならどういう前提で書くのが良いのだろうか。 この手の議論では、なんでも知見を書いておくと検索経由で誰かの役に立つかもしれないという話がよくある。それは一理あるが、人の視線を気にするのは slippery slope だとも思う。 まずひと目を気にしだすと、たとえば social media で buzz りたい、みたいな誘惑に弱くなる。Social media での人気は内容の有用性とは必ずしも比例しない。人目を求めると程度の差はあれ延焼性を高めたり clickbaity になりがち。そういう記事ばかり書いている世の中の冴えない "blogger" たちも、当人らが特別ダメな人間だというよりメディアの構造があの人た

もし次のプロジェクトを探しているならコードベースの依存関係を整理して小さいモジュール (Maven 的な意味で) にわけてビルドを速くする仕事はどうかと TL がいう。人にいわれたことをやるのは基本的には嫌だけれど、これは動機を共有できる。今の spaghetti monolith を殺したい。 社内ではモジュールの単位として Java のパッケージをつかう流儀で、モジュール間に cirular dependency があってはいけない。なので適当に class file をパースして dependency graph を作り、circle を探しつつ殺していけば最初のステップとしては良い気がする。そこに ASM とかがある Java のエコシステムはさすがに成熟してるなと思う。 とはいえ Java でグラフいじりみたいなコードを書きたくないなーどうせ移行が済んだら捨てるコードだし手元で動

ランダムなマネージメントの話。マネージャはコードを書くべきか。 なおここでいうマネージャは Engineering Manager で、TL は他にいるものとする。この前提だと、conventional wisdom は「マネージャも重要なものはともかく少しはコードを書いた方がいい」くらいな気がする。 自分は個人的にはマネージャにはコードを書いてほしくない。全然。なぜならマネージャの書いたコードは扱いがめんどくさいから。そしてどうせならコード書き以外の面倒に時間を使ってほしいから。 例。あるとき上司の上司が crash bug の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。 問題の特定まではよかった。でもコードをみると直し方