2007-12-11
■ナウなヤング
「ナウい」という言葉が現役だったころをご存知のはずの40代以上の方に質問です。
http://q.hatena.ne.jp/1197293258
そうね。私(30代半ば)が「ヤング」だったころには「ナウい」という言葉はもう現役ではなかったのだけど。
という本がある。
1989年発売で、私が買った時点で世に出てから5年ぐらい経っていたのだけど、そんなこと微塵も感じさせない内容で、タイトルの古くささとはうらはらに大層楽しんで読んだ記憶が。
道具立てこそ古くさくなっているだろうけど、今読んでも案外面白いんじゃなかろうか……?
っていうか読みたくなってきたー! でも実家にあるんだな〜。
■炎上を防ぐには
という記事の末尾。
過去に発生した炎上のパターンはある程度決まっているという。例えば(1)悪いマナーや反社会的な行為を自慢すること、(2)世論が分かれているような微妙な問題に関して発言すること、(3)根拠のないことで非難・侮辱したり、断言すること――などだ。
炎上コンサルタントに聞く:「事実無根」では不十分? 従業員の「炎上」、企業の対応策は - ITmedia News
「多くの従業員を抱える企業にとって、ブログやSNSなどの利用を禁止することは現実的ではない。ブログやSNSを一切書かせないようにするのではなく『書くのなら注意して下さい』と対応するのがいいだろう」
この2段落の間に大きな落差があるんですけど……。
でも後者にはまぁ賛成。
■略語
「バリエーション」と書くことろをつい「バリエ」と書きたくなって一瞬自己嫌悪……。
■いやこれはもう
面白そうな本がいっぱいだ。
2007-12-10
2007-12-08
■テレビはインターネットがなぜ嫌いなのか 読了
ローカル局がキー局の番組を放送すると、ローカル局がキー局から金をもらう、ってのは知らなかったなぁ……。
正確には「インターネットが嫌いな理由」じゃないのではないかと。
「テレビ局が作り上げてきたお金を儲けるためのシステム」とインターネットが相容れない、ってだけのことかなぁ。
追記
p13 序章
そもそも公共の電波を使って私的に稼ぐことこそが、放送ビジネスの本質だ。しかし、世間は否定的にとらえる。テレビ局の業績が好調であればあるほど、世間からは
「電波という既得権益にあぐらをかいて、おいしい思いをしている」
といった、羨望とやっかみの入り交じった批判の対象となる。そんな状況でテレビ局は、
「実はこんなに素晴らしいテレビビジネスの仕組みがあって、それを守るためにインターネット事業には本腰を入れられないんです」
などとは決して言えない。
(略)
決まってテレビ業界のお偉方が表れて、
「東京のテレビ番組がインターネットを通じて全国で見られるようになると、地方テレビ局の番組が見られなくなって、地域文化の発展に貢献できなくなる」
(略)
などと、ていの良い説明を始める。
こんな風に「文化貢献」やら「社会的使命」を強調するわりには、富の象徴の様な社屋を建てたりするものだから、テレビ業界は周囲から胡散臭くみられてしまう。
というのが序文で象徴的なところ。
「実はこんなに素晴らしいテレビビジネスの仕組みがあって、それを守るためにインターネット事業には本腰を入れられないんです」
などとは決して言えない、という件りが可笑しい。
2章で明らかにされるが、東京のつまりはキー局のテレビ番組を地方局が流すと、キー局から地方局にお金が流れる。電波料と言うらしい。
つまり、地方局は「キー局のテレビ番組をただ流す方が儲かる」わけ。ただし、そのためには「報道番組にあたって中継の役割を果たさなければならない」という協定や、まぁ当たり前だけど「他のキー局の番組は(あまり)流さない」とかいうしばりがあったり。そしておそるべきことに電波料には明確な基準がないのだそうだ。
p66
あるときキー局の幹部に取材していると、
「地方局が勝手なことをやったら、電波料を減らすだけですよ」
などと思わず漏らしていたが、こんな言葉を地方局の経営者が聞いたらきっと顔面蒼白になるだろう。
ここでテレビがインターネットを嫌う(というか親しくできない)理由がある。
「東京のテレビ番組がインターネットを通じて全国で見られるようになると、地方テレビ局の番組が見られなくなって、地域文化の発展に貢献できなくなる」
といういいわけは、言葉を変えると「東京のテレビ番組がインターネットを通じて全国で見られるようになると、地方テレビ局を切り捨てるのと同じ」ということになる。
当然、それはできない。地方で番組を流すのに、キー局側がお金を払ってでもするのはそうする理由が――つまりはそれでも十分な利益があがってくるからだ。
地方局を切り捨てて、その利益を手放して、インターネットで流す理由がない。
というのが2章の内容。
ここが大層面白かった。
2007-12-06
■iFox Grapite よ。さようなら
Firefoxのテーマの話なんですがね、iFox Graphiteの最新バージョンが Google Toolbar と見た目がマッチしないわけで使うの止めました、と。
まぁ、自分で直すとかできないこともないんですが、継続的なアップデートがないというのは不安があるってことで、昨日の話ともつながって終わり。
■無限リストの無限リストから要素を全部列挙する
というか、「どんな要素もいつかは出てくる」列挙法を考えよう、という話題。
リストのリストの全要素を列挙したリストを作ろうと思ったら、まあ適当に全部結合すると思います。
d.y.d.
(略)
無限リストの無限リストだとどうでしょう。 単純にflattenしてしまうと、先頭にあったリストの要素以外は永遠に出てきません。
(略)
これだと不便なこともあります。というわけでお題。順番はどう変えてもいいから、とにかく『どの要素もいつかは出てくる(有限ステップ以内には出てくる)』ように列挙したリストを返す関数を作ってみてください。
考え方自体は簡単で、カントールが有理数の濃度が自然数の濃度に等しいことを証明した手法でよいわけだ(リンク先エントリにも当然書かれています)。
あとはプログラミング言語にやらせるには? という話で、
無限オブ無限:反応リンク集
d.y.d.
から、この問題へのレスポンスが紹介されている。
これは面白い。
■色分けされたカーソルで視認性を高める
ほうほう。
私のカーソル設定はこんなん。

通常のカーソルは10年来、このデザイン/大きさのものを使ってきた(ファイル日付が1996年だもんなぁ)。
これを一歩進化させたアイデアになるほどと頷いた。
■能力の罠(Competency Trap)
思い当たる節ありまくり。
プロジェクトリーダーも、プロジェクトメンバーも、どちらの立場でもこのエントリは読んでおくべき。
これは、「正しいプロセスを省いて誤った学習を積み重ねるうちに、能力が頭打ちになる」という内容のこと。
プログラマの思索: 能力の罠(Competency Trap)
「能力の罠」とはつまり「自分が自分自身のできることを知ってしまうことで生まれる限界」みたいなものか。
悪循環に陥った時、その状況を根底から覆さなければ何も変わらない。
そして変化させた時、結局、「機能を新規に作るよりもバグを潰して品質を高めることを優先する」ような正攻法に戻している。
(略)
プロジェクトリーダーとしては、アサインする開発者に、プログラミングを経験させながら1ヶ月前よりも今日、昨日よりも今日、成長することを期待している。
理由は、システムのアーキテクチャや仕様も慣れてくるだろうから、最終的にはもっと工数を短く出来るでしょ、と。でも実際は、同じような失敗を繰り返し、成長しない開発者も多い。
そうすると、プロジェクトリーダーとしては、プロジェクト後半になると工数計算できなくなるからすごく苦しい。
(略)
このとき、プロジェクトリーダーは、ディレクティブ・リーダーではなく、ファシリタティブ・リーダーになってくる。
プロジェクトマネジメント(PM)とプロジェクトファシリテーション(PF)は、プロジェクトを回す両輪。
今回は引用だけですみません。いつか、これを受けて自分なりに考えたことを書きたいです(と宣言しておくことで自分を追い詰める)。
■Javaのアクセス指定の謎
これでメソッドfはOKでメソッドgがNGなのはなんで?
2007-12-06 - きしだのはてな
むしろfがOKな方にびっくり。
継承を外すとg()が駄目なのは当たり前。
public class N{
class A{
private int a;
}
class B {
void f(A ar){
System.out.println(ar.a);//OK
}
void g(){
System.out.println(a);//コンパイルエラー
}
}
}
class B の中で、a と書くと、自身→スーパークラスのprotected, publicメンバ→アウタークラスのメンバの順に探すのかな?
例えば、アウタークラスの方にprivateメンバを置けば、
public class N{
private int a;
class A{
private int a;
}
class B {
void f(A ar){
System.out.println(ar.a);//OK
}
void g(){
System.out.println(a);//OK
}
}
}
はい。コンパイル通る。
継承を戻して、this.a でアクセスすると、
public class N{
private int a;
class A{
private int a;
}
class B extends A {
void f(){
System.out.println(this.a);//コンパイルエラー
}
void g(){
System.out.println(a);//OK
}
}
}
となる。ふむ。まぁそうかも。
B は A のサブクラスだから、Aにアップキャストすると……。
public class N{
private int a;
class A{
private int a;
}
class B extends A {
void f(){
System.out.println(((A)this).a);//OK
}
void g(){
System.out.println(a);//OK
}
}
}
あ。コンパイル通った。
と、いうことは当然。
public class N{
private int a;
class A{
private int a;
}
class B extends A {
void f(){
A ar = this;
System.out.println(ar.a);//OK
}
void g(){
System.out.println(a);//OK
}
}
}
この書き方でも通るな。
へー……。
2007-12-05
■なぜ、エヴァンズに頼まなかったのか? 読了
あー時間がかかった。
人の名前が横文字だからか?
やっぱりミステリ(なのかどうかはちょっと疑問があってこれは冒険小説って言った方がいい気がする)としては古典に俗するものなわけで、展開が最近のミステリに比べてゆったりとしているからか。
主人公はゴルフの最中に崖下に転落した瀕死の男を発見する。そして、一言だけ告げて、息を引き取った。
「なぜ、エヴァンズに頼まなかったのか?」
その言葉の意味を追って主人公とヒロインの探索と冒険が始まるのであった。
という What's happend? もの。
3分の2を過ぎたあたりから面白くなってきて、一気に読めた。さすがはアガサ。
■サービスの終焉という決断・永遠のβバージョンはもちろん永遠ではありえない
運用のフェーズと実験のフェーズでは、割り当てるべきリソースの量も特性も違う。
開発者の立場として考えるに、RUPにも移行フェーズがあるのも当然で、どこかで「運用する人」に引き渡す必要がでてくるわけだ。
新しい手法をテストすることはできても、運用フェーズに持ち込むためには定常的なリソースを確保することが必要になる。それは周囲の協力や合意であったり、予算であったり、人であったりさまさまであるが、個人の力に頼らず、組織として、業務として運用しなくてはならない。特に人的リソースは減少している。時には枝葉を剪定して、全体のバランスを取ってゆくことも必要なのかもしれない。
図書館退屈男: サービスを終了させる、ということ。
さて、ちょっと前――っていうかこの業界ではどのぐらいが「ちょっと」なんだろう?――に「永遠のβバージョン」てなフレーズがWebに顔を出していた。
開発者=運用者でいられる蜜月が「永遠のβバージョン」で、その終焉として2つあって、「運用者に引き渡す」のが晴れてβの文字が取れる時で、もう一つが「開発を停止する」ということなんだろうな。
「運用者に引き渡す」フェーズがないままに「開発を停止」しても運用は続けられるけど、運用にかけるリソースがないわけだからいずれは停まる、と。
■「パターン」って……
日常でつい、「一体どんだけのパターンがあるんじゃ〜」とか叫んでしまうけど、この場合の「パターン」は「組み合わせ」の間違いなことが多くて――例えば「A項目が10パターンでB項目が5パターンでC項目が3パターン」だと 10×5×3 で全組み合わせ数が150なわけで、この「150」「全組み合わせ数」を指してついつい「パターン」という言葉を使ってしまうことがあるなぁ、とか思った。
■極上のおもてなし
うーん。残念。
リッツカールトンのマスコミへの露出にあわせた浅い本、という認識を持ってしまった。
ただ、読み口は軽く、すいすい読める。何度も何度も読み返して書かれていることを「感じ取る」という、そんな読み方をするべき本なのかもしれない。
ハッとさせられたのは、
p118-9
フロントで呼び出してもらってしばらく待っていると相手がやってくる、というのと、あらかじめ相手が玄関で待っていてくれるのと、どちらが好印象か、いうまでもありませんね。
確かに、いうまでもない。
ビジネスビルに入っている会社なら、玄関というわけにも行かないだろうが、「受付まで」とあらかじめ話をしておいて、ちゃんと受付で待っている、というようなことをすれば確かに印象はよい。
あと面白いな、と思ったのは、若いうちから「おもてなし」精神を養おう、というくだり。
p130
若い方は、自らおもてなしをすることとは、あまり縁がないかもしれません。しかし、だれしもいつかはおもてなしをする年齢になります。(略)むしろ若いときの方が恥をかいてもゆるされますから、どんどんチャレンジしてみましょう。
そう。
ここ何年か、法事などが毎年あって実家に帰ったりしてふと、いつかは自分が呼ばれる側ではなくて呼ぶ側になるんだな、と思ったりしたのだ。
日取りの調整から、準備などなど。それもまた経験。
会社などで歓送迎会や忘新年会の幹事を若い者にやらせるのも、単なる慣習じゃなくてそういうことを企画し実行するよい機会だから、という意味もあるのかも。
なんせ参加するのが顔見知りなわけだから、少しぐらい失敗しても許される――と、そういうことなのかもなぁ。

