2011-09-22 Re: NSObject クラスと NSObject プロトコルが分かれているのはなぜ? 
【Objective-C】NSObjectクラスとNSObjectプロトコルが分かれているのはなぜ?へコメントを付けたが、山カッコがhtmlタグと認識されて全く意味を成さない文になった。それゆえ、ここに書き込んでおく。
id型はNSObject *型ではないので、id<MyProtocol>型のインスタンスであるobjのdoSomethingを呼び出した際には問題がなく、releaseのタイミングで警告されたと思われます。 ただ、id<MyProtocol>型を使う際、MyProtocolはNSObjectプロトコルを継承することに少々違和感を覚えました。クラス定義でNSObjectを継承することは常ですが、プロトコル定義でNSObjectを継承する例を見かけたことが(ほぼ)無いからです。
id<MyProtocol> obj = [[MyClass alloc] init];
ではなく、
静的型定義をするなら
MyClass *obj = [[MyClass alloc] init];
動的に行うのであれば、
NSObject <MyProtocol> *obj = [[MyClass alloc] init];
としたほうが自然だと思えますが如何でしょうか?
2010-08-27 「なぜソニーはアップルになれなかったのか？」を考察してみる。 
8/23に「Life Is Beautiful」上で提起された疑問が、今回のテーマである。
コメントやTwitterを介して反響が寄せられたが、抽象的で的を射ていないものが大勢を占めているようだ。正直いってこんな意見に振り回されることがあれば、ソニーはポピュリズムプロダクトしか生み出せなくなると感じた。唯一的確だと思われるコメントは「経営陣がソフトウェアを軽視したこと」だろう。そもそもソニー社内のことなど推測でしか語れないのだが、これは間違いない。この会社の成功体験である「細部に拘ったモノづくり」はハードウェアに限られたものであるらしい。
「ソニーはアップルを目指す必要などない」という意見もあった。
しかし同業他社の中で一番の成功株を目標にしていなければ、ますます混迷の度合いを深めてしまう。第二次大戦において敵性語を禁止した国と徹底的に研究した国、どちらが戦略的に正しかったのだろう。優れたものは積極的に取り込むべきだ。
何を見据えて家電を造るか。
一般消費者と技術者、どちらに迎合しても優れた製品は生まれないように思う。どちらにせよ双方とも瑣末なカタログスペックが大好きであり、大局的な判断は出来ないだろう。決定権をもつ人間にはバランス感覚とセンスの良さが求められる。現在のテレビリモコンにおけるボタンの数からいって、状況は絶望的であるが。
ここからはアップルの成功に関わった「必要条件」を挙げたい。
アップルは15年以上仔細に観察してきたが、ソニーの動向についてはそこまで掴んでいないからだ。
・他業種との折衝
タフネゴシエーターをCEOに持つことは幸いであった。魑魅魍魎渦巻く音楽業界、映画業界、携帯キャリア等を相手にして、荒れ地に井戸を始めて掘った功績は極めて大きい。ルールを自分に有利に作り替えた。
・平易なユーザーインターフェイス
1997年前後、アップルはWindows勢に追いつめられていた。MacOS Xが発表されてもその構図は大きく変わることはなかった。ユーザー側が乗り換えに対する拒否感を持っていたことが一因だろう。それでも独自OSを捨てずに磨き続けたことが、後に実を結ぶことになる。
・ソフトウェア資産
コモディティ化が進んだハードウェアと極めて戦略性を増したソフトウェア。ソフトウェアの中でも、カーネルやUNIXユーザーランドなど定評があるものはそのまま採用し、アプリケーションフレームワークなどを自社で内製して競争力の源泉にしている。
・続けること
上記に共通することだが、「ユーザーや他社にとらわれず、正しいと思ったことを実行し続けること」が根底にある。アイディアを模倣されることを厭わず(訴訟も辞さないようだが)、先に進み続けてなければならない。
2010-08-11 2020年竣工予定の住宅 <1> 
子供の頃、一家で都会に出ると必ず立ち寄ったのがモデルハウスだった。当然だが、興味がない俺が見学しても面白くもなんともない。父は建築家になりたかったと語るほどなので、しげしげと細部まで観察していた。そのわりには下手の横好きというか、自宅はあまりセンスの良い家ではないと思う。80年代中頃の建物なので仕方のないところか。
一例を挙げてみる。(昔このフレーズをダイエーでよく聞いた。中内功の発案らしい。)
- 動線と照明の関係を考慮していないので、照明スイッチをONにするのに暗い部屋に入っていかないといけない。
- →いまなら、センサーで制御するのが適当。人がいながら照明が落ちると興ざめなので、そのあたりの工夫も必要。
- 居室とリビング・ダイニングが極端にはなれているので、行き来が面倒。俺の部屋であれば片道2分はかかる。
- →スター型トポロジーで。
これから数回にわたって、住みにくい実家で育った俺が、家を建てるならこだわりたい部分について語ってみたいと思う。今の時点で思いついたポイントを列挙して、それに沿って話を進めていく。注文住宅を発注する人たちもこんなことを考えているのだろうか?
- 静的な構造ながらも、綿密な調査に基づいた心地よい環境。
- その土地の気象を長期間にわたって調べる。
- 風や自然光を生かす。
- 鳥害などを避けうる建築。
- 動線を出来るだけ多くのパターンから考察する。
- 静的安全設計(停電、地震など)
- 基礎部分の衛生的な設計。
- 電線類の引き込みは地下から。
- 周囲はかなり広く芝生を張る。カート型芝刈り機が使える構造にする。
- メンテフリーを目指す。
- 段差や壁の凹凸は無くす。
- 照明のような突起物は天井に隠し、調度品も壁に埋め込む。
- 外部配線を目立たないように取り回す。(壁の床上20cm程より下を一まわり掘り込み、その上に配線路とダウンライトを埋め込む。アウトレット部分にはACアダプタスペースを設けて隠す。蓋は電波を通すプラ製。)
- ドアは引き戸を基本に、電動も採用する。
- アトリウムを設ける
- 結露を防ぎ、室温調整を容易にするため、二重にガラスを配置する。(隙間の空間は断熱スペース。)
- 天井部分は格子状にして、積雪にも耐えられるように設計。
- UMU(瞬間調光ガラス)を各所に配置、直射日光を和らげる。
- セキュリティ
- ComputerVisionを活用、危険度判定を自律的に行う。
- LRAD(パラメトリックスピーカー) + 強力なライト?
2010-02-25 Wikipedia専用ブラウザをリストアップ 
これまでにいくつか、Wikipediaをブラウジングするための専用クライアントが発表されてきた。まとめてみたいと思う。(動画はうちで開発中の専用ブラウザ。細かいので直接YouTubeサイトで、大きいサイズのものを観たほうがいいかも..)
Pathway
MacOSXのネイティブアプリケーション。内部リンクをグラフィカルに表現している。しかし、あの方法で内部リンク・逆リンク・カテゴリーなどを全て表すのは無理。記事の関係をネットワーク化しなくても、履歴を1次元の配列で見せればいい。あと記事そのもののHTMLを加工しているわけではないようで、WebView表示はフツーのウェブブラウザと変わらない。記事本文は左側のカラムが消されるが、ノートや編集ページでは消されなかったり。ネガティブな見方をしてきたが、なんだかんだ言って俺がやりたいことに一番近い気がする。残念なことにアップデートは2007年以来止まっているようだ。
Indywiki
画像をメインに据えてWikipediaをブラウジングしようというアプリケーション。PythonとQtベースで構築されているらしく、マルチプラットホーム対応。本文をテーブルビューで挟むという外観はうちのアプリケーションにも似ているか。
Gollum
JavaScriptベースのWikipediaラッパー?。通常のウェブブラウザからGollumサーバを介し、Wikipediaを閲覧する。これ自体はブラウザでない。本文表示は見易く整形されている。だが、表組みやテンプレートが正しく表示されない。本家サイトよりこちらを利用する意義が見いだせない。
発見人生
WIRED VISIONの記事を見かけたと思ったら、一月もせずにアイデアを形にしてきたWindows用アプリケーション。一言で言えば、"Wikipediaおまかせ表示専用ブラウザ(自動リロード式)"。マンガを描くのが上手い方が製作者のようで、羨ましい。
WikiReader
割り切りが素晴らしいWikipedia閲覧専用ハードウェア。通信機能を持たず、記事データをmicroSDに予め格納しておく。単4が2本で約1年利用できるそうだ。いかがわしい記事はフィルタして子供にプレゼントするとかね。
Pedia(本家サイトが潰れてたので、弾さんの記事を)
リンク先にもあるように、トップページがWikipediaなだけの「低性能ブラウザ」。類似品も大して変わらない。
iPhone用のWikipedia専用クライアント各種
記事をキャッシュするとか、加速度センサで記事をランダムに切り替えるとか。腐るほどある。MediaWikiが吐き出すMobile Safari用ページで十分だろう。
以下はブラウザというよりエディタ。
Wikipeditor
Windows用エディタ。ネットワーク接続などは扱わない、MediaWiki記法で書くためのアプリケーションのようだ。
WP Studio
Wikipeditorと方向性は同じか。やはりWindows専用アプリケーション。エディタメインだが、プレビュー用のウェブブラウザも内包しているらしい。エディタ + ビュワー = 専用ブラウザという意味では、俺の目指すモノとも近い。
<追記>
久々にWindows2000環境をVirtualBoxで立ち上げて試してみた。WikiTextを取得して、編集後そのまま投稿できるようだ。しかしAPIを利用しているわけではないらしく、通常の投稿フォームを直接コードから扱っていると思われる。HTMLの加工は行っていないみたい。
Sun Wiki Publisher
OpenOfficeからMediaWiki記法にエクスポートする機能拡張。興味深い。
2010-02-04 PCプラットホーム天気予報 
Microsoft
ハードウェアはオープンアーキテクチャと謳うが、OS市場を実質独占しているためにさしたる意味をもたない。シェアこそが力の源泉。故にその優位性を崩すウェブやオープンなファイルフォーマットを嫌う。"数の論理"が通用しなくなった今、OSの大規模な刷新を行っているが、ポリシーである後方互換性とのジレンマに陥る。晴れのち曇り。
Apple
ハードウェア・ソフトウェアをプロプラエタリなものとして、付加価値を上げることに注力。シェアは小さいため、昨今のプラットホームに拘らない傾向はむしろ追い風。ここは"軒を貸して母屋を取られる"ことを極端に恐れるため、ハードウェアやソフトウェア流通に他社が介入することを拒み続ける。そのために一定以上のシェア獲得は望めない。曇り時々晴れ。
ハードウェア・ソフトウェアともオープンに開発。収益源は広告事業であるために自社プラットホームへ社運をかけるほどでもない。だがウェブ上をアプリケーション稼働環境にしようとする試みは、ネイティブのそれと比較して劣る予想。未だにワープロやスプレッドシートは使い物にならない。晴れ、ところにより落雷。
各種Linuxディストリビューション
相も変わらず使い物になるのはサーバとしてのみ。一般向けプラットホームとして多様性は悪でしかない。ディストリごとに設定やインターフェイスが異なるため、ビギナーがインストールしてもFireFoxを使うのがせいぜい。複雑なパッケージ管理システムを刷新・もしくは予め各種アーキテクチャ向けバイナリを梱包したものを配布・GNOMEとKDEを統合・ディストリ間の差違を無くすこと、などが出来れば普及の芽はあるか。大雨注意報、土砂崩れの恐れあり。
上記は脳味噌が吐き出した蜃気楼
何バカな事言ってんだと一笑に付して頂きたい。
写真は組立中の電気タップ。ケースの加工が終わっていないが、とりあえず基板を載せてみた。韓国WIZnetのイーサネットモジュールとブートローダ&スケッチを焼いたAtmel ATmega328だけのシンプルな構成にしてある。奥にあるのは電源アウトレットを取り付けたカバー部分。鉄板なので、安物のドリルの刃ではすぐダメになった。シールも製作して貼ってみる。SSR部分はまだ。こないだお世話になった東急ハンズのおじさんと相談しなければ。
以前にも書いたが、特に電源タップに思い入れがあるわけではない。ネットワーク対応周辺機器の習作としていい題材になるかと思ったから。そもそもAC100Vを扱うモノは特定製品として経済産業省関連の認可を取らないと売れない。商売にするならネットワーク対応赤外線リモコンでも作るか。売り物として完成度を高いものにするのは難しいだろうなぁ。Sanguino BreakOut ShieldがNYCはBrooklynから到着したので、基板を起こさずに面白いものを造れないか研究する。5枚頼んで、送料を勘定に入れると$21/枚。ブルガリアに発注したとしても、これなら大して安くならない?
