Android らしい Java - 2. 寿命
寿命、ライフサイクルのはなし。(Part.1 はここ) Android の中には、決められた寿命を持つ重要なオブジェクトがいくつもある。代表例は Activity. View も Fragment もプラットホームによって寿命が決められている。 Java は誰かに決められた寿命を扱うのがあまり得意でない。多くのオブジェクトは Java 自身の GC が寿命を決める。GC があるからプログラマは寿命について悩まなくていい。そんな態度が従来の Java にはある。C++ のように神経質な寿命管理は出番が少ない。 Java でも File のような OS の資源は GC でなくプログラマが寿命を決める。Socket なんかはもう一段厄介で、相手側から閉じられると勝手に死んでしまう。そして死んだオブジェクトを触るコードは呪いの例外に見舞われる。 勝手に死ぬ Activity や View の性質は
不確実さを受け入れる — A17Y (1)
ソフトウェア開発に関する認識で大きく変化したもののひとつは不確実性の扱いではなかろうか。古いソフトウェア開発が「複雑さ」を、Agile が「変化」を主要な難しさ、戦うべき敵とみなしたように、今日のソフトウェア開発は「不確実性」との戦いを大きなテーマに据えていると思う。プログラマが不確実性に向ける眼差しは開発プロセスに大小様々な影響を与えている。「達人プログラマー」とその世代は、この変化を捉えていない。 ソフトウェア開発には昔から不確実性がつきものだった。たとえば見積もりでは The Cone of Uncertainty なんて話をする。現代的なソフトウェア開発が昔と違うのは「不確実さは放っておいてもなくならない」ことを認めたことだと思う。The Cone of Uncertainty が象徴する昔のソフトウェア開発では、不確実性は一時的なもので目の前の嵐をやりすごせばいいと考える。極端に
週報仲間
仲間内で週報を送り合う Snippets メーリングリストをはじめてからもうすぐ一年経つ。仕事じゃなくて課外活動の話。 自分の勤務先では週報のことを Snippets と呼ぶ。(このへんにもうちょっと詳しい意見書がある。) ただし週刊とも限らず報告する相手も決まっていない。だからか weekly report とは呼ばない。 提出は義務でなく、書いていない人も多い。自分もながいことサボっていた。今は書いている。社内のしょぼい週報サイトにテキストを投稿するだけの素朴なもの。仕事の進まなさが直視できていい。他人の記録も読める。似たようなことをしている会社は多いと思う。 その仕事 Snippets の真似を課外活動でもやればいいと思い立ったのが今年のはじめ。友達に声をかけ、数人ではじめた。 毎週日曜の夕方、リマインドのメールが届く。そのメールに返信する形で各々が週報を送る。週ごとのスレッドができ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
