サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
anemone.dodgson.org
テクニカルな理解が低いと良い意思決定ができない。でもそういうのが必要な場面はしばしばあって辛い。という話。 去年の今頃、テストやベンチマークの自動化を強化するプロジェクトをはじめた。そのときは隣に QA チームがいたのでおすすめの自動化フレームワークを聞いたところ、彼らの作っているツールを勧められた。QA チームが保守しているベンチマークを自分たちの都合良いように書き直したい思惑もあったし、彼らはこのツールでテストを書き直すというし、他によい当てもなかったのでそのツールで自動化に着手した。 のだが・・・とにかく使いにくい。やばいレベルで使いにくい。ほんとにこれでテストとか書き直せるの?無理じゃね?どうしてこんなものが存在してるの?と思ったものの、専門家であるはずの人々がそれでいくというのでがんばって使い続けた。しかし全く捗らない。ツールを自分に勧めてきた A 氏は席を外していることが多かっ
Hugo を使ったこのブログ、2015 から更新しているようなしていないような状態のまま使っているけれど、 そろそろ引退させようとおもい作業をしている。 ブログとかを書いていると虚栄心などで気が散り精神衛生を損ねたりするという理由でブログの公開を年一回にしたのが 2016 年。 その後、子ができて忙しくなったりで段々と公開するのがめんどくさくなり、そもそも書くのもめんどくさくなり、書くこともなくなり、読む人もいなくなり、と荒廃が進んで今日に至っている。 友人向けに管をまく雑談はぼちぼち書いており、そういうのはパスワードで保護されたドラフトサイトでだけ公開し、ドラフトのままにしている。 そのほか自分にだけ読める braindump や走り書きなども少しあり、そういうのは draft サイトにすら表示されない特殊な状態で、localhost のプレビューでのみ読めるようになっている。 公開にあ
これは来年の目標や計画をたてるにあたっての braindump である。 メタな話として、長期的な見通しを考えると同時に目先の仕事のがんばりにも気を配らないとだめだな、というのが今年仕事をがんばってみた上での感想。先のことばかり考えると足元を掬われる。あと人生のフェーズ的に将来の話ばっかりしてる段階でもない。 といいつつ大局的な話をまず考える。 Android の仕事について Android プログラマ、もうだいぶ旬を過ぎた感はある。世間的には Android 固有でハードコアなことをするより iOS と両方できるようになったり React Native なり Flutter なりでクロス OS 開発をしてみたり、あるいは Web のフロントエンドもできますよ、みたいな人が重宝されるフェーズに見える。専門家はまだ必要だが、足りてる。 これは少し前に一部のサーバ側の人が「フルスタック」すなわ
自分は 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++ の習得に莫大な時間を費やした。学
自分の勤務先はいまいちこう、小規模でカジュアルな情報共有がやりづらい。Google Apps を使っているので、まあメーリングリストはある。いちおうチャットもある。Docs もある。Sites もある。社内ソーシャルメディアもある。ソースツリーに Markdown をチェックインする文書化インフラもある。Bugtracker もある。しかし。あれがないんだよあれが。Wiki と Blog がつくっついたみたいな、日本の会社は多かれ少なかれ使ってるアレ。Qiita Team, Esa, Kibela とかそういうやつ。なんでないの? 勤務先は融通の聞かない大企業だから仕方ない面はある。しかし英語圏、似たようなツール全然なくね? グループウェアとか Slack クローンとか Google Docs の亜種は腐るほどあるくせになぜアレっぽいやつはないの?おかしくね。Confluence は違うん
単なる「プログラマ」でありたいと願っていたが、その夢が破れつつあると感じる。今の自分はモバイル・プログラマである。今から他のものになるのはだいぶ大変。 気のせいかもしれないが、世の中からも単なる「プログラマ」は姿を消しつつあるように見える。だいたいもうちょっと限定がついている。Frontend engineer, backend engineer, SRE, data scientist とか、いわゆるインターネット企業の中だけでもこれだけある。自分が学生だった 15-20 年前にこうした細分化はなかった気がする。もちろんゲームとエンタープライズのような業種の壁はあったけれど、それ以上は細分化していなかったような。 自分の視野が狭かっただけで、昔からそれなりに色々あった可能性はある。逆に、自分と同年代の知り合いにもたとえばガラケー向け組み込みから現代的なモバイル、ウェブ、今はクラウドバック
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
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 では買わずレビューも残さないのだった。技術書の中でも要素技術解説系の
自分のキャリアとかを考える時期は終わって、自分は子のために生きてるのだなと感じる瞬間がある。たとえば。 ある晩、奥さんの勤務先主催の holiday party に子を連れて出かけた帰路の車内、いつもの就寝時間過ぎまで起こされぐずっていた子が静かになり、やっと寝たかと顔を覗き込む。窓から街灯が差し込み、カーシートの上で静かに宙を見つめている子の顔が浮かび上がる。その表情はぎょっとするほど大人びている。ああ。 この子の前には無限にたくさんの可能性が広がっていて、自分の前には可能性の搾りかすだけがあって、それならこの無限の可能性から子が素晴らしい何かを選び取れるよう手を貸す方が圧倒的に妥当じゃん。諦めでも熱狂でもなく、すべての謎が解けたように、ただ腑に落ちる。 この感覚は白昼夢として過ぎ去っていく。 けれどそのあと、いつものように自分の仕事やプログラマとしての先行きを思い悩むとき、自分の中にあ
二ヶ月くらい前から家族用に Highrise (Free Plan) を使い始めた。 主な用途のひとつは、コクヨ おつきあいノート みたいなもの(こんなものがあったのか!)。要するに親戚や知り合いに何をもらった、あげたなどを記録しておく。もらった・あげたの記録も義理人情の観点で大事といえば大事なのだけれど、そもそも自分はゆこっぷ(おくさん)の親戚や友達の名前とかを全然覚えられない問題があったので、それを記録しておけるのが助かる。Contact List に timeline がついたようなものだと思えばよい。 人付き合いで自分が抱えているもう一つの問題は、人から聞いた話を覚えていないこと。だから聞いた話のうち重要そうなもの(たとえば: 子供が生まれた、その子供の名前、転職したなど) を記録しておくのがもう一つの使いみち。 こういう情報をまったく忘れない人もいるけれど、自分のように付き合いの
ここ数年で使っているやつが2つ増えたのでふと紹介してみる。 OneTab - Chrome Web Store TabCopy - Chrome Web Store OneTab は開いているタブを全部閉じた上で開いていたタブのリンクへの一覧を一つのタブに表示してくれる。閉じると必要な URL がわからなくなる漠然とした不安からタブは開きっぱなしにしがちだけれど、リンクを一覧に残してくれるので安心して閉じられる。そして必要なものはタブの一覧からよりページにまとまったリストからの方が探しやすかったりする。 TabCopy はページのタイトルを URL をリンクした状態でクリップボードにいれてくれる。ので Blog とかを書くときに便利。リンクは Markdown 形式でもコピーできる。 自分は最近は仕事の journal を Google Docs につけているので、必要な資料へのリンクとか
自分は丁寧に(大げさに)コードを書きすぎる傾向があって、それは premature-optimization であったり over-engineering であったりしてよくない。でもガっとでかい関数を書いたりクラスを定義せず tuple で済ませたりする脳の負荷が苦手で、大げさに書く方に逃げてしまう。結果として見通しの悪いコードができあがることが多々ある。 逆の傾向を持つ人もいるだろう。雑に書きすぎて、いわゆる「汚いコード」になってしまう。世の中的にはこっちが多いことになっているけれど、自分は大げさサイドなので正直そうなる人の気分はわからない。 そのバランスは最終的にはリファクタリングして正せばいい、というのはその通りなのだけれども、自分の傾向を把握して意識的に初期値を決めてやるのも自分のバイアスを治していく上では必要に思える。大げさに書く傾向のある人は意識的に雑に書き、逆もしかり。 あ
カルマはためすぎないほうが良いと思う。 仕事での貸し、面倒でイヤな仕事を片付けた実績。わかりやすい業績じゃなくて、プロジェクトや製品を支える雑用の見返りがカルマ。ビルド壊れ治し、バグのトリアージ、レビューの球拾い、ツールの改善、トロル対応。そういう仕事をすると貯まる目に見えないポイント。組織のインセンティブデザインなんて完璧でない。道徳心や責任感のある人がその不完全を埋める。そしてカルマを貯める。 カルマは貯めるだけでなく使うこともできる。日頃の行いがよければ、たまに無理したり変なことをしても大目に見てもらえる。そういう形でためたカルマを消化できる。自分は一時期クラッシュバグを直しまくってカルマをためていたため HTML Imports の出荷でやや無理にブランチに変更をねじこんでも見逃してもらえた(気がする)。 そんなカルマだけれど、あまりためすぎない方がいい。 まずカルマは曖昧なものな
The ChangeLog で CNCF の話を聞いた。CNCF, できたときはどうせ形だけの組織なんでしょと斜めに見ていたら割とまじめにやっており、かつうまくいってるらしい。Google のように control freak ぽい会社が Kubernetes といういかにも戦略的なコードをわざわざ第三者に明け渡す。誰が決めたのか知らないけど、よくやったと思う。 ここで年来のファンタジーが頭をもたげる: Chrome も Chromium Foundation になっていたら良かったのになあ。WebKit Foundation でもいい。そしたら Electron とかもみなそこにあつまったろうに。 そうならなかった理由はわかる。なにも動機がない。彼らには巻き込みたい他人というものが特にいなかったろうし、そもそもウェブには標準というものがあり、そっちで協業してる。それに Chrome を始
一年以上前にゼロ秒思考という本を読んだ。 この本は、頭に浮かんだことはすぐ書き出せ、そして箇条書きで書けと主張している。 なんでもすぐ書き出せというのは「考えるために書く」に近いものがある。一旦書き出すことで脳の負荷が下がり、考えを前に進められる。 書き出すのは、考えないためでもある。テキスト形式で考え事の snapshot を取って認知的ノイズを捨て、心置きなく先にすすむ。基本的には GTD の人たちがタスクを書き出すのと一緒。ただし中身が TODO である必要はない。 書き出したことの多くは特にそれ以上追求されることなく流れ去っていく。それでよい。Google Photos の全自動 backup が保存やよりわけの悩みをなくしてくれるように、思いつきの書捨ては考え事取捨選択の悩みを減らす。写真と一緒で、頭をかすめるアイデアの大半はゴミだから。 書き出すのは悩まないためでもある。この本
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 の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。 問題の特定まではよかった。でもコードをみると直し方
プログラマと英語 1 というのを去年書いたのを思い出した。これは 2 です。プログラマは英語で blog を書くべきか。 自分は過去に何度か断続的に書いたことがあるが、最近は「多くの人にとってはあんまし意味ない」という結論になった。特に日本語で blog を書くような感じでは書けないね。 Blog を書くにあたって、いくつかの期待があるとおもう。 まず昔ながらの、ソーシャルメディアとしての blog, 個人的な話。多くの日本人は交友関係の大半が日本人である。となると個人的な話を英語でかいても読み手には迷惑なだけだし、読まれないことも多い。だから個人的なことを英語で blog に書くのはあまり嬉しさがない。 ただしあまり読まれたくないが口にせずにはいられない話題を書くのには良い。言語バリアの力で無駄にゴシップ化しないから安心。 テクニカルな話題、professional portfolio
kzys がなんか書いていたのに便乗して記録しておく。 今年のあたま、発音をなんとかしたいなと思いなぜかアプリを作った(が出したっきりほっといたら one star rating になってしまった。すまぬ・・・buggy だけど fake じゃないよ・・・) がその後色々立て込んで何も出来ず、それでも6月くらいから二ヶ月くらいこのアプリの dogfooding をかねて American Accent Training という本をやっていた。半分くらいで挫折。 自分は以前 Mastering the American Accent もやったことがあり(これはいちおう最後まで行った気がする)、ESL 向けアクセント矯正本は二冊目。 対照的な二冊ではあれど、どちらも悪い本ではなかった。AAT に挫折したのは自分の忙しさとかの問題で、本の内容がどうこうではない。 AAT はマクロな発音 (文全体
Bob Martin の Clean Architecture を読んでいたのだが、あまりに価値観が違いすぎる上にその主張の説得力がなさすぎかつすごいエラそうな文章にムカつきが限度に達してしまい、半分くらいで脱落。後半もパラパラ眺めたけど同程度にむかつくかんじだったので自分向けの本ではなかったらしい。 Architecture というのはプログラマの世界ではだいぶ強い言葉で、Architecture だの Architect だのを名乗るなら語られるべきことは色々ある。でもこの本は基本的に依存関係を整理して testable にする話しかしない。Bob Martin はつまるところ SOLID の人なのでそういう話になるのは仕方ないと言えなくもないけれど、そんなら Architecture とか大層な語を使って新刊を書いたりせず昔書いた本を改定しときゃいいともうのだよな。 色々ムカつくとこ
次のページ
このページを最初にブックマークしてみませんか?
『steps to phantasien』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く