サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
anemone.dodgson.org
Hugo を使ったこのブログ、2015 から更新しているようなしていないような状態のまま使っているけれど、 そろそろ引退させようとおもい作業をしている。 ブログとかを書いていると虚栄心などで気が散り精神衛生を損ねたりするという理由でブログの公開を年一回にしたのが 2016 年。 その後、子ができて忙しくなったりで段々と公開するのがめんどくさくなり、そもそも書くのもめんどくさくなり、書くこともなくなり、読む人もいなくなり、と荒廃が進んで今日に至っている。 友人向けに管をまく雑談はぼちぼち書いており、そういうのはパスワードで保護されたドラフトサイトでだけ公開し、ドラフトのままにしている。 そのほか自分にだけ読める braindump や走り書きなども少しあり、そういうのは draft サイトにすら表示されない特殊な状態で、localhost のプレビューでのみ読めるようになっている。 公開にあ
これは来年の目標や計画をたてるにあたっての braindump である。 メタな話として、長期的な見通しを考えると同時に目先の仕事のがんばりにも気を配らないとだめだな、というのが今年仕事をがんばってみた上での感想。先のことばかり考えると足元を掬われる。あと人生のフェーズ的に将来の話ばっかりしてる段階でもない。 といいつつ大局的な話をまず考える。 Android の仕事について Android プログラマ、もうだいぶ旬を過ぎた感はある。世間的には Android 固有でハードコアなことをするより iOS と両方できるようになったり React Native なり Flutter なりでクロス OS 開発をしてみたり、あるいは Web のフロントエンドもできますよ、みたいな人が重宝されるフェーズに見える。専門家はまだ必要だが、足りてる。 これは少し前に一部のサーバ側の人が「フルスタック」すなわ
最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。 ・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ(などの得意だったおたく分野)はつまらん」というのと同じ現象が自分に起きているだけな気がする。 キャリアの停滞 まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわ
自分の勤務先はいまいちこう、小規模でカジュアルな情報共有がやりづらい。Google Apps を使っているので、まあメーリングリストはある。いちおうチャットもある。Docs もある。Sites もある。社内ソーシャルメディアもある。ソースツリーに Markdown をチェックインする文書化インフラもある。Bugtracker もある。しかし。あれがないんだよあれが。Wiki と Blog がつくっついたみたいな、日本の会社は多かれ少なかれ使ってるアレ。Qiita Team, Esa, Kibela とかそういうやつ。なんでないの? 勤務先は融通の聞かない大企業だから仕方ない面はある。しかし英語圏、似たようなツール全然なくね? グループウェアとか Slack クローンとか Google Docs の亜種は腐るほどあるくせになぜアレっぽいやつはないの?おかしくね。Confluence は違うん
20パーセント制度がどうこういうのは、一歩下がると企業が新しいものを生み出すためにどうすべきかの議論である。20パーセントは下々や現場の人からも新しいものが生まれるといいですねという話だった。このコインの裏に、新しいことを考えるのが仕事の人は現場に出たほうが良いですねという話がある。勤務先のリサーチ部門のトップ(当時)は、それを主張する Hybrid Approach To Research という記事を書いている。すごい雑にいうと、いわゆる研究者も製品開発に突っ込みましょうみたいな話。しばしば「象牙の塔」などと揶揄されがちな大企業研究所モデルのステレオタイプに対するカウンターとなっている。 論文書きや標準化といったリサーチっぽい仕事と製品開発の近接は自分の勤務先での体験と一貫しているし、機能もしている。伝統的な研究所モデルとの優劣は自分には議論できないが、少なくとも研究者たちが専門分野の
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
古いコードの依存関係を整理するなか、"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 では買わずレビューも残さないのだった。技術書の中でも要素技術解説系の
二ヶ月くらい前から家族用に Highrise (Free Plan) を使い始めた。 主な用途のひとつは、コクヨ おつきあいノート みたいなもの(こんなものがあったのか!)。要するに親戚や知り合いに何をもらった、あげたなどを記録しておく。もらった・あげたの記録も義理人情の観点で大事といえば大事なのだけれど、そもそも自分はゆこっぷ(おくさん)の親戚や友達の名前とかを全然覚えられない問題があったので、それを記録しておけるのが助かる。Contact List に timeline がついたようなものだと思えばよい。 人付き合いで自分が抱えているもう一つの問題は、人から聞いた話を覚えていないこと。だから聞いた話のうち重要そうなもの(たとえば: 子供が生まれた、その子供の名前、転職したなど) を記録しておくのがもう一つの使いみち。 こういう情報をまったく忘れない人もいるけれど、自分のように付き合いの
カルマはためすぎないほうが良いと思う。 仕事での貸し、面倒でイヤな仕事を片付けた実績。わかりやすい業績じゃなくて、プロジェクトや製品を支える雑用の見返りがカルマ。ビルド壊れ治し、バグのトリアージ、レビューの球拾い、ツールの改善、トロル対応。そういう仕事をすると貯まる目に見えないポイント。組織のインセンティブデザインなんて完璧でない。道徳心や責任感のある人がその不完全を埋める。そしてカルマを貯める。 カルマは貯めるだけでなく使うこともできる。日頃の行いがよければ、たまに無理したり変なことをしても大目に見てもらえる。そういう形でためたカルマを消化できる。自分は一時期クラッシュバグを直しまくってカルマをためていたため HTML Imports の出荷でやや無理にブランチに変更をねじこんでも見逃してもらえた(気がする)。 そんなカルマだけれど、あまりためすぎない方がいい。 まずカルマは曖昧なものな
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 の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。 問題の特定まではよかった。でもコードをみると直し方
次のページ
このページを最初にブックマークしてみませんか?
『steps to phantasien』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く