死んでしまったOSたちへ
自分は本の草稿に誤字脱字探しをしつつ好き勝手言う係としてちょっとだけ手伝った。せっかくなので宣伝してみる。 この本はコード読みブログやアーキテクチャ解読ブログをまとめたような体裁になっている。といっても各章バラバラではなく、本としての連続性はある。そして OS というものを包括的に解説するかわりに Android の特徴的なところ、たとえば GUI フレームワークや VM のランタイムなど、をつまみ食いしている。これは正しいアプローチだと思う。伝統的な OS の話をしだすと Android ってだいたい Linux だからね。Android に限らず、この「伝統的な OS の上にあるプラットホームのレイヤ」の中身を説明した本は少ない。 そこが面白い。 この本の欠点は文章がけっこう slippery なところ。悪い意味でブログぽいというか同人誌ぽい。ただそれは「支える技術」シリーズに共通する
定年説をめぐって — 1. ミームの濫用
35歳定年説をめぐる言説がずっと嫌いだった。気になる話題だけれど、その語られ方が好きになれない。 35歳定年(限界)説には大きくふた通りの解釈がある。ひとつ目はプログラマのキャリアにおける「ガラスの天井」が35歳にあるというもの。管理職にならないと給料あがらないとかそういうの。ふたつ目は加齢による衰え。つまり「老衰」のせいで業界の変化についていけなくなるというもの。××おじさんみたいな話。 前者、ガラスの天井バージョンが発祥の言葉だと自分は理解している。このガラスの天井バージョンから人々が徐々に興味が失うのにあわせ、後者の老衰バージョンが目につき始めた。自分も主に老衰バージョンに関心がある。どちらも加齢を気にしているものの、懸念のありかは違う。それでも「35歳」で「定年」という過激さが人々の心を刺激するのだろう。情報産業に広がる老いへの恐怖をとらえ、ふたつ一緒くたに扱われることが多い。 ガ
不確実さを受け入れる — A17Y (1)
ソフトウェア開発に関する認識で大きく変化したもののひとつは不確実性の扱いではなかろうか。古いソフトウェア開発が「複雑さ」を、Agile が「変化」を主要な難しさ、戦うべき敵とみなしたように、今日のソフトウェア開発は「不確実性」との戦いを大きなテーマに据えていると思う。プログラマが不確実性に向ける眼差しは開発プロセスに大小様々な影響を与えている。「達人プログラマー」とその世代は、この変化を捉えていない。 ソフトウェア開発には昔から不確実性がつきものだった。たとえば見積もりでは The Cone of Uncertainty なんて話をする。現代的なソフトウェア開発が昔と違うのは「不確実さは放っておいてもなくならない」ことを認めたことだと思う。The Cone of Uncertainty が象徴する昔のソフトウェア開発では、不確実性は一時的なもので目の前の嵐をやりすごせばいいと考える。極端に
17年後のプラグマティズム (0)
「達人プログラマー」が新装版になり、記念にと一冊いただいた。世間話がてら「Dave Thomas にはこういう本をまた一冊書いて欲しいですね」と伝えたら、Dave Thomas が出版業から引退したことを教わり、新しい話は新しい人が書くべきではと指摘される。別の読者からも今の時代にあわせた達人プログラマを読みたいという感想があったそうな。 原書の Pragmatic Programmer が出版されたのは 1999 年。XP Explained や Refactoring も同じ年に出版されている。Agile movement 元年と呼べなくもない。Pragmatic Programmer 自体は agility そのものに関する本ではない。とはいえ Dave Thomas は “Manifesto for Agile Software Development” 発起人の一人でもあるから、
週報仲間
仲間内で週報を送り合う Snippets メーリングリストをはじめてからもうすぐ一年経つ。仕事じゃなくて課外活動の話。 自分の勤務先では週報のことを Snippets と呼ぶ。(このへんにもうちょっと詳しい意見書がある。) ただし週刊とも限らず報告する相手も決まっていない。だからか weekly report とは呼ばない。 提出は義務でなく、書いていない人も多い。自分もながいことサボっていた。今は書いている。社内のしょぼい週報サイトにテキストを投稿するだけの素朴なもの。仕事の進まなさが直視できていい。他人の記録も読める。似たようなことをしている会社は多いと思う。 その仕事 Snippets の真似を課外活動でもやればいいと思い立ったのが今年のはじめ。友達に声をかけ、数人ではじめた。 毎週日曜の夕方、リマインドのメールが届く。そのメールに返信する形で各々が週報を送る。週ごとのスレッドができ
Soft Skills を読んだ
というか Audible で聴いた。尊敬するひげぽんの推薦書。読まないわけには行くまい。 著者本人がアドリブつきで読む、サービス精神旺盛な一冊だった。著者が読むのはいまいちなものもあるけど、このひとは滑舌がいいね。 作者はほとんど自己啓発の専門家といった風情。だから扱っている話題は網羅的だ。個々の話題は内容の特化した本を読むほうが詳しいけれど、アラカルトとして良い出来だと思う。プログラマの目線で書いてあるから。 そこそこ自己ケーハツ本好きな自分から見ると、すごく目新しくはなかった。でも我が身を振り返る事は多かった。この手の本は、たまに手にとって襟首正すのがひとつの読み方だと思う。 一番詳しく書かれており、説得力もあるのがブログを含めた自分の売り込み方に関する話。その部分の私の感想はだいたいかずよしさんとおなじ。つまり主張はわかるが自分にとってのブログはそういうもんじゃないんで…という戸惑い
意見を持つ
今のチームのプログラマたちは、製品の機能や UX に意見を持っている。 UX デザイナがおらず PM もおとなしいプログラマ中心のプロジェクトから来た自分は、アプリやサービスの世界でデザイナや PM がどう物事を決めるのか、そこにプログラマがどう絡むのかに興味を持っていた。どうも一筋縄でない。 定例ミーティングではデザイナのモックを前にプログラマたちが細かいレイアウトや動きを議論している。各リリースの計画会議では誰かしら自分の欲しい機能を持ち出す。廊下でデザイナと顔を合わせては唾を飛ばし合っている。ランチで PM と同席するたび何かを申し立てている。 自分はそんな意見がない。開発しているアプリに興味はある。自分で使っているから良くなってほしい。でもアイデアはない。速くてバグがなければいい、くらい。 コードの書き方には意見があるし、開発プロセスやインフラにも言いたいことは多い。バグを減らした
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
