サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
bellflower.dodgson.org
仕事で成果を挙げたいのなら、何かをオウンしろという。 たとえばモジュール。機能。ライブラリやフレームワーク。まとまったコードを書いて、あるいは引き取って、自分の持ち物にする。バクを直し、人のコードをレビューして、持ち場の面倒を見る。 何かをオウンするのが、自分はあまり好きでない。なにしろめんどくさい。 コードをオウンするのは家を買うようなものだろうか。持ち家に憧れローンを組む人はいる。コードの対価として重責を引き取る人もいる。気持ちはわかる。自分にも憧れがあった。でも今は月々の返済に追われない身軽さが勝る。我ながら気が弱い。 オーナーシップには副作用もある。自分の所有権を守りたい心理が働く。領土を壁で囲いたい誘惑に駆られる。執着と責任の磁場に包まれて正気と勇気を保てるのか。 何もオウンせず働くのは借家暮らし。あるいは居候。部屋をひとつ間借りする代わりに家主の仕事を手伝う。コードから虫を追い
自分は本の草稿に誤字脱字探しをしつつ好き勝手言う係としてちょっとだけ手伝った。せっかくなので宣伝してみる。 この本はコード読みブログやアーキテクチャ解読ブログをまとめたような体裁になっている。といっても各章バラバラではなく、本としての連続性はある。そして OS というものを包括的に解説するかわりに Android の特徴的なところ、たとえば GUI フレームワークや VM のランタイムなど、をつまみ食いしている。これは正しいアプローチだと思う。伝統的な OS の話をしだすと Android ってだいたい Linux だからね。Android に限らず、この「伝統的な OS の上にあるプラットホームのレイヤ」の中身を説明した本は少ない。 そこが面白い。 この本の欠点は文章がけっこう slippery なところ。悪い意味でブログぽいというか同人誌ぽい。ただそれは「支える技術」シリーズに共通する
ここまで散々35歳定年説について書いてきたけれど(1, 2)、プログラマのキャリアについて語る今日的なキーワードは「生存戦略」かもしれない。目についたところではWeb+DB Press の連載などで使われている。 「生存戦略」は言葉としてまだ「35歳定年説」ほど汚染されていないし、問題をより的確にとらえた良い名前だと思う。ある世代以降のプログラマが定年説を持ち出すことは珍しくなった。マジックナンバーの呪いが解けていく様は感慨深い。 「生存戦略」というけれど、実態はどちらかというと「自己実現戦略」や「成長戦略」だったりする。「生存」よりずっと高いバーに背筋が伸びる。これがアニメの力か。 自分はより語義に近い意味で生存戦略のことをよく考える: 先に書いた人生の荒波が立て続けに降りかかったり、自身の将来価値が期待に大きく届かなかったとき、自分は文字通り生き残れるのだろうか。ホームレスになる…可能
35歳定年説をめぐる言説がずっと嫌いだった。気になる話題だけれど、その語られ方が好きになれない。 35歳定年(限界)説には大きくふた通りの解釈がある。ひとつ目はプログラマのキャリアにおける「ガラスの天井」が35歳にあるというもの。管理職にならないと給料あがらないとかそういうの。ふたつ目は加齢による衰え。つまり「老衰」のせいで業界の変化についていけなくなるというもの。××おじさんみたいな話。 前者、ガラスの天井バージョンが発祥の言葉だと自分は理解している。このガラスの天井バージョンから人々が徐々に興味が失うのにあわせ、後者の老衰バージョンが目につき始めた。自分も主に老衰バージョンに関心がある。どちらも加齢を気にしているものの、懸念のありかは違う。それでも「35歳」で「定年」という過激さが人々の心を刺激するのだろう。情報産業に広がる老いへの恐怖をとらえ、ふたつ一緒くたに扱われることが多い。 ガ
前の記事ではプログラマ以外の語る35歳定年説について書いた。プログラマ自身はこの話題をどう扱っているのだろう。ふたたびウェブを眺めてみる。 当事者たるプログラマが35歳定年説を語るとき、「ガラスの天井」バージョンへの関心は驚くほど小さい。みな「老衰バージョン」を気にかけている。多くの文章は、まず定年説の真偽を問う。そして様々な形でその信憑性を否定し、35を過ぎても仕事は続けられると結論付ける。経験を活かせばいい、さぼらず勉強すればいい、職場や業界での立ち振る舞いを工夫すればよい。 言うことはわかる。けれど少し滑稽でもある。既に書いたとおり、35は「ガラスの天井」バージョンの定年説から滑り込んだ意味のない数字だ。だからよほど適正や運が無いのでもなければ35歳周辺で能力的に引退を迫られることは稀。そして35歳定年説を語る文章がその先の30年について深く考える様子はない。でも35ならともかく50
寿命、ライフサイクルのはなし。(Part.1 はここ) Android の中には、決められた寿命を持つ重要なオブジェクトがいくつもある。代表例は Activity. View も Fragment もプラットホームによって寿命が決められている。 Java は誰かに決められた寿命を扱うのがあまり得意でない。多くのオブジェクトは Java 自身の GC が寿命を決める。GC があるからプログラマは寿命について悩まなくていい。そんな態度が従来の Java にはある。C++ のように神経質な寿命管理は出番が少ない。 Java でも File のような OS の資源は GC でなくプログラマが寿命を決める。Socket なんかはもう一段厄介で、相手側から閉じられると勝手に死んでしまう。そして死んだオブジェクトを触るコードは呪いの例外に見舞われる。 勝手に死ぬ Activity や View の性質は
ソフトウェア開発に関する認識で大きく変化したもののひとつは不確実性の扱いではなかろうか。古いソフトウェア開発が「複雑さ」を、Agile が「変化」を主要な難しさ、戦うべき敵とみなしたように、今日のソフトウェア開発は「不確実性」との戦いを大きなテーマに据えていると思う。プログラマが不確実性に向ける眼差しは開発プロセスに大小様々な影響を与えている。「達人プログラマー」とその世代は、この変化を捉えていない。 ソフトウェア開発には昔から不確実性がつきものだった。たとえば見積もりでは The Cone of Uncertainty なんて話をする。現代的なソフトウェア開発が昔と違うのは「不確実さは放っておいてもなくならない」ことを認めたことだと思う。The Cone of Uncertainty が象徴する昔のソフトウェア開発では、不確実性は一時的なもので目の前の嵐をやりすごせばいいと考える。極端に
「達人プログラマー」が新装版になり、記念にと一冊いただいた。世間話がてら「Dave Thomas にはこういう本をまた一冊書いて欲しいですね」と伝えたら、Dave Thomas が出版業から引退したことを教わり、新しい話は新しい人が書くべきではと指摘される。別の読者からも今の時代にあわせた達人プログラマを読みたいという感想があったそうな。 原書の Pragmatic Programmer が出版されたのは 1999 年。XP Explained や Refactoring も同じ年に出版されている。Agile movement 元年と呼べなくもない。Pragmatic Programmer 自体は agility そのものに関する本ではない。とはいえ Dave Thomas は “Manifesto for Agile Software Development” 発起人の一人でもあるから、
当方機械学習素人につき大して興味はなかったものの、実は Jeff Dean 案件だと気付き whitepaper くらいは読むことにした。 ぎもん: Jeff Dean といえば MapReduce や GFS を作った Google の神話級プログラマ。そんな分散インフラの達人がなぜまた深層学習に手を出したのだろう。 わかったこと: TensorFlow は、行列(というかテンソル)に特化したデータフロー・プログラミングの分散実行処理系だった。 データフロー・プログラミングとは、データを受け取り何か計算して結果を誰かに渡す、という単位のオブジェクト(ノード、カーネルなどと呼ぶ)をつなぎ合わせてグラフをつくり、より大きな計算を表現する抽象化のパターン。最近はリアクティブの文脈で目にすることが増えた。 そして MapReduce/Hadoop も今はデータフローの枠組みでコードを書くことが多
というか Audible で聴いた。尊敬するひげぽんの推薦書。読まないわけには行くまい。 著者本人がアドリブつきで読む、サービス精神旺盛な一冊だった。著者が読むのはいまいちなものもあるけど、このひとは滑舌がいいね。 作者はほとんど自己啓発の専門家といった風情。だから扱っている話題は網羅的だ。個々の話題は内容の特化した本を読むほうが詳しいけれど、アラカルトとして良い出来だと思う。プログラマの目線で書いてあるから。 そこそこ自己ケーハツ本好きな自分から見ると、すごく目新しくはなかった。でも我が身を振り返る事は多かった。この手の本は、たまに手にとって襟首正すのがひとつの読み方だと思う。 一番詳しく書かれており、説得力もあるのがブログを含めた自分の売り込み方に関する話。その部分の私の感想はだいたいかずよしさんとおなじ。つまり主張はわかるが自分にとってのブログはそういうもんじゃないんで…という戸惑い
仲間内で週報を送り合う Snippets メーリングリストをはじめてからもうすぐ一年経つ。仕事じゃなくて課外活動の話。 自分の勤務先では週報のことを Snippets と呼ぶ。(このへんにもうちょっと詳しい意見書がある。) ただし週刊とも限らず報告する相手も決まっていない。だからか weekly report とは呼ばない。 提出は義務でなく、書いていない人も多い。自分もながいことサボっていた。今は書いている。社内のしょぼい週報サイトにテキストを投稿するだけの素朴なもの。仕事の進まなさが直視できていい。他人の記録も読める。似たようなことをしている会社は多いと思う。 その仕事 Snippets の真似を課外活動でもやればいいと思い立ったのが今年のはじめ。友達に声をかけ、数人ではじめた。 毎週日曜の夕方、リマインドのメールが届く。そのメールに返信する形で各々が週報を送る。週ごとのスレッドができ
脱素人を目指し機械学習のオンライン講義をとっている。 ニューラルネットの宿題が手書き文字の識別をしろという。数字のみ。テストデータは MNIST のデータセットを使う。有名なデータらしい。そういえば TensorFlow のチュートリアルにもでてきたな。 Samples from MNIST Dataset. The image is from Theanets API Document.Wikipedia によると、この手描き数字はアメリカ統計局職員から集めたデータと高校生から集めたデータを混ぜたものとのこと。ただし生のデータは荒々しくて辛いと適当に正規化してあるそうな。簡単な線形回帰を使っただけなのに正解率が 90% を超えたので機械学習スゲーッと感動してたけど、さすがに前処理はしてあったのね…。 顔写真広く使われるテストデータに出会うと、いつも Lenna のことを思い出す。 The
Java にはリフレクションがあり、当時は目新しかった。 人々がリフレクション API を使いこなしだすと遅さが目立ち始めた。ライブラリ開発者はリフレクションを実行時バイトコード生成で置き換えた。こうして Java のバイトコード編集ライブラリが発達した。 言語仕様にアノテーションが追加されたのも同じ頃。アノテーションと実行時バイトコード生成が Java フレームワークのデザインに与えた影響は大きく、モダンなサーバサイド Java は案外簡潔なコードを書けたりする。XML がアノテーションになっただけ、とは言わない約束。いちおう型をチェックできるし、冗長といわれる Java だって XML よりは簡潔だし。 Android Java は実行時に Java バイトコードを解釈できない。だから Java のコード生成資産が使えない。実行時にロードできる DEX にもデータを一旦ファイルに書かな
今のチームのプログラマたちは、製品の機能や UX に意見を持っている。 UX デザイナがおらず PM もおとなしいプログラマ中心のプロジェクトから来た自分は、アプリやサービスの世界でデザイナや PM がどう物事を決めるのか、そこにプログラマがどう絡むのかに興味を持っていた。どうも一筋縄でない。 定例ミーティングではデザイナのモックを前にプログラマたちが細かいレイアウトや動きを議論している。各リリースの計画会議では誰かしら自分の欲しい機能を持ち出す。廊下でデザイナと顔を合わせては唾を飛ばし合っている。ランチで PM と同席するたび何かを申し立てている。 自分はそんな意見がない。開発しているアプリに興味はある。自分で使っているから良くなってほしい。でもアイデアはない。速くてバグがなければいい、くらい。 コードの書き方には意見があるし、開発プロセスやインフラにも言いたいことは多い。バグを減らした
Android プラットホームの API はひどい。 プラットホームというもの一般の API デザインが時代にあわせ少しずつ良くなる中、Android は時代を10年くらい巻き戻した感がある。深い継承。でかいクラス。ヒラより多いマネージャたち。コンサーンもレスポンシビリティもテスタビリティも何もない。 モバイルデバイスには従来の Java が気にかけなかった様々な制約がある。同じように行かない。それはわかる。でもねえ。 過去にもひどい API のプラットホームはあり、人々は大きく二つの方法で立ち向かった: 一つ目は、プラットホームを無視して自分で再発明する方法。Qt や XUL, Swing みたいなクロス OS のツールキットはだいたいこの路線。二つ目は抽象化レイヤをかぶせて隠す方法。Windows API に対する MFC, WTL や SWT. あるいは DOM に対する jQuer
Android らしい Java そのさんは API のひどさ…のつもりだったけれど脇道にそれ、ひどさについて時々思うことを書いてみる。 世の中にはひどいコードがたくさんある。自分もよくひどいコードを書いている。広く使われている基盤的なソフトウェアにもひどい部分は多い。たとえば C++ には理不尽な仕様がいくつもある。Web 標準にもなんだこりゃ、というのがよくある。 ひどさの中にはハンロンの剃刀もあれば、それなりの理由があることも多い。Windows API がひどい歴史的背景については本が一冊書かれているくらい。 一方で理由がどうあれひどいものを使う痛みはかわらない。ところが「ひどいなあ」と口にした途端、そのひどさの由来や理由を嬉しそうに話しだす人がいる。 それがたまらなく嫌だ。 ひどさを前にうんざりしてる人を見てなにが嬉しいのか。落とし穴に嵌ったところを笑われた気分。当人も同じ穴の中
Ruby を書くのが未だに下手だ。10年以上の付き合いなのに、数百行より書ける気がしない。 動的型付けの言語なんかで大きなコードは書けないとうそぶくことも、昔々は出来た。でもそんなのは遠い過去。自分が下手なだけだとわかってはいる。すぐグチャグチャになる。雑用に書き捨ててばかりだから仕方ない。ついでに Python も同じくらい下手なまま。 Ruby に文句があるわけじゃない。でも今から鍛える気力もない。機を逃した。ウェブと Rails が輝いていたゼロ年代の間にもう少し触っておけば良かった、なんて後悔するも後の祭り。自分の中の Ruby はウェブ言語になれず、雑用書き捨てスクリプトのまま今日に至っている。 Ruby でなくてもいい。書き捨てよりも踏み込んだ雑用に耐えるプログラミング力がほしい。迷わず使えるツールがほしい。一方で雑用と銘打った途端に輝きは失われ、やる気がなくなり手が止まる。
“Building Microservices” を読んだ。 薄い本。著者の Sam Newman は Martin Fowler が Chief Architectをするアジャイル大好き ThoughtWorks に勤める。そのせいか論調には馴染みがあった。そして Microservices の必要性も説得された。まあサーバ側の仕事をしてない自分が説得されたところで何も起きないけど。 Microservices は Conway の法則を味方につけるための舞台装置だと著者は主張する。自律的な two-pizza team がフラットにつながり合う今時な組織の理想を叶えたい。だから理想の組織を反映したアーキテクチャを考える。その答えが Microservices なのだと。理想を実現するための苦労なら厭わない。分散システムかかって来い。そんな話。 理想形の細部はさておき、チームが小さいのは
久しぶりに前向きな意味で XML が口にされるのを耳にした。正確には XML-y。 巨大で messy な "MegaController" クラスを小さくテスト可能なクラスにリファクタリングするそのライブコーディング(日本語トランスクリプト)のなか、演者の Andy Matuschak はテストの要らないある種の無難なコードたちを XML-y と評した。エックスエムエリィ。 XML-y なコード。たとえば値をセットするだけ。テーブル駆動的な switch-case. あとは View ツリーの構築もそうだと思う。React 経験者なら JSX を使わずに render() を書くと思えばだいたいあってる。Android 用の Kotlin フレームワーク Anko が View の構築に使う気の利いた DSL もこの仲間といえる。 JSX や Anko DSL が成り立つのは、その処理が
仕事で Android アプリのコードを触り始めはや数ヶ月。少しは理解が進んだ。 今の仕事のコードは、残念ながらそれほど素晴らしくない。その昔 Android Java にまだ慣れていなかった人々が書いたであろう古いコードが目につく。そして古いコードの昔ながらな残念さは、従来の Java とは違う Android Java の「らしさ」を描き出す。そんな話を数回にわけて書いてみたい。 第一回は非同期性のはなし。 Android のアプリはメインスレッドをブロックしてはいけない。だから色々と非同期に書く。ところが従来の Java は非同期がさほど得意でない。多くの API がブロックする。 ブロックする処理は別のスレッドに追い出せばいい。ただし結果はイベントループを通じてメインスレッドに戻さないといけない。これを綺麗に書くイディオムが、Android では最近まで確立されていなかった(Asy
このページを最初にブックマークしてみませんか?
『To Phantasien』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く