ま、ほかの既存の携帯向けサービスでも良いんだけど、
アイコンとか要らんから軽くしてくれというかそういう方向性で。

ほぼtwitter本家のmobile webのパクリです。
ただコメント付きRTというかQT？しやすくしてたりしゃべりやすい対応を入れてたり。
自分が使いやすいようにちょっと機能追加したかんじ。

http://t.kumama.org/　：：tw mode

自分のガラケーSO703iでのみ動作確認していますが、
たぶんAUでもSBでもほとんどの携帯で大丈夫なはず。
なんせSO703i、３年前のモデルですからwww

ソース公開していて http://code.google.com/p/twmode/。

GAEってGoogle App Engine使ってるんでQuotaまではかなり行けるはず。
App Engineのwebappとかtemplateとかtemplateのcustom filterとか
tweepyとかdeferred.delayとか使ってるので、
その辺のサンプルにも良いかも。

iphone 4白出たらMNPしますがそれまでの延命用ってことで。

iphone 4g買う気でいるのでその準備と言うか。
寝てる部屋でもテレビ見たいというか。

要るもの（ハード）：

• OSX(雪豹が望ましい)
• Friio等（生TSが抜ける地デジチューナー）

ってここまでで敷居高杉ですが。

要るもの（ソフト）：

• recfriio改
• tssplitter_lite改
• mediastreamsegmenter

recfriioは終了まわり、tssplitter_liteはパイプ対応など修正。
mediastreamsegmenterはsnow leopard標準で入ってるコマンド。

iphone側はQuicktime playerで見るので特にソフトは不要です。

あ、あとWebのUIをgolangで作ってて、iphoneからはsafariで操作する感じ。

mediastreamsegmenterはオープンソースのsegmenterでも行けそうなんだけど、
AACとの相性が悪いのか成功せず。
トランスコードしてる訳じゃないので、
これさえ動けばlinuxとかbeagleboardでOKなんだけど。

と、需要あるのかないのかなのでとりあえず。

クライアント使ってなくても、でも何となくQTしたいよ。
って時に QT 用のリンクを追加します。

Before:

After:

Click:

なんか、jQuery様々でアンカー要素追加の方向で作ってたけど、
いざ試してみると、onclickのfunctionを変えないとだめだったようだ。

とりあえずは動くんだけど、折りをみて（ブックマークレットデバッグする気力が湧いたら）、
onclick版もなんとかしようと思います。

QT

update:
clickに対応。これでコメント付きRTがしやすくなったと思われ。

そーす？

javascript:(function(){
	$(".status-body").each(
		function( intIndex ){
			$(this).find(".entry-date").attr("href").match(/http:\/\/twitter.com\/(.+)\/status\/(\d+)/);
			var status_id=RegExp.$2;
			var status="QT @" + RegExp.$1 + " " + $(this).find(".entry-content").text();
			var obj = $('
QT

' );
			obj.click(
				function(){
					$("#status").val( status ).trigger("update");
					$("#status").focusEnd();
					$("#in_reply_to_status_id").val(status_id);
					window.scroll(0,0);
					return false;
				}
			);
			$(this).children(".actions-hover").append(obj);
		}
	);
})();

後続エントリ。ガラパゴス問題の論点まとめ。 - My Life in MIT Sloan。

俺はリアルなガラパゴスを思い浮かべて、ガラパゴス島と日本島の違いを考えていた。ガラパゴス島に住む生き物達が島の外で暮らしていけないことを苦には思っていない。ガラパゴス島の問題は独自に進化した種の絶滅問題。その問題は世界的認識で世界的に保護されている。一方、日本で考えると日本から外に出られない事を苦に思ってる人・企業は有ると思うけどガラパゴス島の生物のように気にしていない風潮もある。確かに市場を考えると日本国外に出て行かずに成長曲線をたどるのは難しいが、横ばいで利益を上げつづけることは微減していく市場に合わせてコストを減らしていければ不可能ではないように思う。一方、絶滅に対してという面で世界から手厚い保護をされているかというとされていない。そのことによる絶滅の危惧の方がよっぽど深刻だと考えている。海外製の安い高機能な商品によって国内でもシェアを失う例やたち行かなく例は山のようにある。

IT系の現場寄りで働いているが、いわゆる輸入ソフトウェア無しに仕事が進むことはない。これはエンタープライズに限った話ではなくコンシューマーでもPCのOSがWindowsで有ったり、MacOSXで有ればそれは輸入ソフトウェアを使っているのだ。このソフトの輸入。対米で貿易収支上年間2000億の赤字。割合でも10%も無い状況。エンタープライズ系でもサーバ、NW、Web、DB海外製品ばかり。互換性とか信頼性という面で使いたいと思う製品は海外製の物ばかりでその点では「日本の高い技術」という元記事の記述に疑問を感じる。また既製品の問題以外にカスタムソフト（ようは受託）もオフショアの流れが大きくこちらはこちらで昨年度約1000億程度。今後も増加する見込み。IT系はOJTでのスキル習得も重要だがその1000億分、日本の技術者はOJTで技術習得する機会を失っている。OSSの開発者の平均年齢が海外に比べ高いのはその辺が影響しているかもしれない。またその受託開発比率の日米差も見逃せない。同じような製品ソフトにコストをかけているというのは日本という国で見たときには相対的に損失だ。

携帯電話も日本の携帯が優れているのだろうか。守られていたからこそ日本でシェアを獲得したのであって相対的に優れていたのかどうかは疑問が残る。あまり言われていないし奮闘しているが今ガラパゴス化を推進しているのは地デジだと思う。海外での採用例も有るが北米・EUは別方式。TVといえばCATVな北米と同列でないことは確かだしワンセグとか優れている面も多々あるけどグローバル化を考えると疑問が残る。

と、なんか反対意見ばかり書いてきたけど基本的な「英語でないと」という点には賛成。ただ日本語の議論が主で英語の意見も取り入れるという消極的な姿勢ではなく、英語圏での議論が主で日本語の意見も取り入れるというぐらいに割り切らないと意味がないと思う。そこまでしないと多分駄目。rubyもrailsでグローバル化したけどコアの部分が…。

日本もう駄目だ…と思って海外脱出も有りだけど駄目にした一員であるかもしれないのでもうちょっと頑張るのも良いかと。

*ソフトのオフショア・輸出入の金額に関しては下記URLから辿るとたどり着くはず

http://www.kogures.com/hitoshi/webtext/shakai-kokusai-soft/index.html

http://www.ipa.go.jp/jinzai/itss/activity/2010summary_of_ITHR.pdf

VAIO Pシリーズ│ パーソナルコンピューター “VAIO” - Sony Style

VGN-P90 → VGN-P91 → VGN-P92 と半年毎のアップデート時の雰囲気ではなく、わざわざPやXの初回発表時の様なティーザー展開、VAIO New MobileのキャッチコピーからVAIO New Ultra Mobileへのコピー変更。一方、通常netbook向けatomは世代変更。巷ではipadの話で溢れかえってる。今回はそんな中での発表。期待せざるを得ない状況です。

個人的に内容を見てデジャブ的に頭に浮かんだのがこれ。

Life is beautiful: もし日本のメーカーが iPhone を発売していたら..

なんか似てません？ｗ

IntelのCPU戦略に従わざるを得ない立場なのですね。わかります。

もともとIntel的にZ系のAtomはMIDとかWindows未満の機器での使用を想定していてWindowsのNetbookでの使用は眼中に無かった。予想外。その思想が強化されてというかZ系でのWindows封じか、Atom Z6xx系はWindowsのドライバを提供していない。既に出ちゃってるZ5xx系 Wndowsの後継にはおなざりにSKUでクロックアップ版のZ560ってのも知ってました。しかしZ550に成ったときにはティーザー無しだったからZ560に成ったからってティーザーしないだろーって期待してたんですよ。
グーグルとインテルとソニー、「Google TV」デバイスを共同開発か--米報道:ニュース - CNET Japanの報道後もちらほらと噂が聞こえてくるDragonpoint TVも5月に発表との噂。これはZ6xxを使ってるっていう噂だし。
Moorestown発表後（【PC Watch】 【CES 2010】【Intel基調講演】Moorestownベースのスマートフォンを今年後半に投入）の２月にFCC通過。

なんかこう、Windowsネットブック以上/以外のものを期待していた気がします。

あるいはこの記事（【笠原一輝のユビキタス情報局】 Intel、MoorestownのPC版「Oak Trail」を計画 ～次期VAIO P/X、LOOX Uの可能性が広がる）が出たのも2月。Oak Trail前倒し！？とか。

ここ１年ぐらいP使ってますが、「GMA500の保存用にモデルチェンジ前に投売りの旧モデル確保しなきゃ」とまで考えてました…。

今回大きな変更は無いと思っていたところにティーザー展開されて期待してしまっていただけに残念です。Oak Trailの冬モデルに期待…と言いたいところです。

が、ipadとか出遅れてるTegra2のSlate系も流石に年末には台頭してくるでしょう。クラウドとかFlash離れが進む中、Windowsのライセンス費を含めて割高なVAIO Pを選ぶ理由が無くなっているかも知れません。

って、WebSocket Draft75 « ケンタテクブロで先を越されてエントリしていませんでしたが一応記事にしておきます。

時代の進歩を傍観するんじゃなくて、イノベーションを起こす側に立ちたい

をを、かっこいいって思った。

で、今の自分はどうだろうなぁと考えてみて。時代の進歩に触れて居たいとか単に新しい物好きとかそいういうのか…と、ちょっと凹んだりもしたけど。もう少し冷静に考えてみると実際問題出来る出来ないはともかくとして進歩したプラットフォーム上で何かを作るのではなく、進歩に力を貸したい。と思ってるのかも知れないことに気が付いた。

AppEngine上でアプリ作るのも良いけど、どちらかといえばAppScaleよろしく使ってクラウド自体を作りたいし、AndroidもDalvik上でAndroidアプリ作るよりもAndroid本体側（Linuxカーネル含め）を触っていたい。なんかこう与えられたプラットフォーム上で何か作るのではなく与える側、プラットフォームそのものを作ったり広めたりする一員になりたいというか。

iPhoneはJailbreakしか無かった頃にtry-and-errorでアプリ作るのが楽しかったし。Skypeも標準で用意されていない機能を拡張するのが楽しかった。技術で動かないものを動かす、繋がらない物を繋ぐ、不可能を可能にする、そしてそれが誰かの役に立つという事をやって行きたいんだと思う。

そしてそんな自分ですがリアルには多分そこそこのユーザ系企業に勤めてて俗に言う既得権を得てる方。入力の項目のこの値がこうだから結果がおかしいとか、夜間バッチが遅延して…とか。このスイッチのポートが空いてるからconfig入れて接続…とか。最近新しいことが有るか…と言われると法規制対応とか？（笑）AppEngineのアーキテクチャとか知ってるとVMWare vCenterでプライベートクラウドとか言ってるのが恥ずかしいし。

世の中、技術的な勉強会と起業関連のセミナーは多いけどその中間があんまりない。どっちかに重点を置いた集まりが多いのがちょっと悲しい。勉強会とか言ってもWebで公開されてる情報が多いし、ゆくゆくは独立起業したり転職するにしても、安住の企業で働きつつ副業とか趣味で出来る範囲でそういうところに入っていく方法は無いものか。

自分に足りないのは繋がりと人を褒める技術、後英語。一歩ずつでも足りないところを補っていかなければ。Blog書いてれば誰かが拾ってくれるなんて思ってない。自分からのアプローチが重要。

と、何の話か解からなくなった（笑）

中島さんのBlogで著作権フリーの文書のiPad用PDF化を呼びかけてらっしゃるので興味の有る方は是非ご協力を！

とりあえずこれを。

使ったのは jolicloud の PreFinal。 GMA500 というか poulsbo のドライバは標準で入ってるものの微妙にエラーで X が vesa でしか起動しないので ubuntu 9.10(Karmic) 用のスクリプトでpsb関連を再導入。

HardwareSupportComponentsVideoCardsPoulsbo - Ubuntu Wiki

導入前は非常に遅い。使えない。アイコンのエフェクトとか駄目駄目。画面狭いといい事なしですがドライバ導入でいい感じに。アプリ起動時にアイコンがクルって回るのが可愛くてお気に入り。Firefox, chrome が普通に使えるしインストール後のサイズが2G程度、日本語入力も簡単に設定できる。

Ubuntu notebook rimix とか moblin とか chromeos とか android も色々試したんだけど今ひとつ気に入らず。jolicloud は気に入っています。XMB捨ててでも入れ替える価値あり。

XMBボタンで起動出来るインスタントモードは巷で言われているように kernel.pam と initrd.pam で kernel と initrd が指定されてます。って事でそれを書き換えればOK…。とは行かないのが悩みの種。

インスタントモードの構成ファイル中、 rootfs とか menu が ext2 でマウントできるのに対し initrd だけはフォーマット不明。 tar とか gzip とか bzip2 とか cpio とか lzma とか lzo とか cramfs とか色々試したけど不明。 kernel.pam って corel の Instant on の機能のように言われてるけど本家Instant on自体は grub2 使ってるみたいでこの kernel.pam を利用するブートローダーは EFI の InsydeH2O の機能の様な気がします。

それはさておき windows パーティションに rootfs のファイルを置いて loop マウントしたかったのでどうしても initrd が必要…でも上の通り inited のフォーマットがわからず、試しにcpio+gzなinitrdを置いても読んでくれない。Instantモードでxterm起動して見てみると device ram0 で minixfs なので initrdなのは間違いないんだけど…。

って事で逃げ手で、Linux の 2.6 から使える initramfs を使って kernel に initrd を抱き合わせました。昔ってinitrd.gzを単純に連結したらOKだった気がするんだけどARMだったかな。うろ覚え。initramfs は kernel を再構築する必要が有ります。

kernel再構築時、.configのCONFIG_INITRAMFS_SOURCEにinitrdのディレクトリを指定するだけ。インストールした jolicluod から /initrd.gz を持ってきて展開。後、loopbackマウント用にchroot周りシェル書かないと駄目かもと思ってたんだけどjolicloudの(ubuntuの)/initが優秀でオプションだけでいけました。bzImageサイズが10M超で駄目かとも思ってたけどこれも無事読み込んでるみたいで危惧に終わりました。駄目だったらkernel.pamからgrub起動して(realmodeに戻る必要が有るけど)そこからkernel起動かとかも思ってたもののそこまでせずに済んで一安心。

起動時間短縮のために不要kmod削除しようかと思ったもののまぁ我慢できるレベルって事で。今後の改善点。

ここ一年弱Pがメインマシンです。AndroidとかLinuxとかビルドしたり画像系の作業する時は流石にデスクトップでやってますがpythonのGAEぐらいならPで十分。

現在のwebsocketsのクライアント側の実装でproxy越えをしようとする場合、サーバ側で特殊な考慮をしておかないと繋がらない環境が多いと思います。

ちょっとややこしいので順を追って説明します。

・クライアント側の実装でproxy越えする際にはProxyに対し CONNECT を発行する
・proxyでCONNECTできるのは接続先ポートがhttps(443)に制限されている場合が多い
（squidはデフォルト。443以外のSSLポートをSquidでプロキシするには辺り参考）
・一方、サーバ側はというとhttps使ってるならhttpsの場合が多い。
・websocketsで443に繋いだとしてもSSLのハンドシェークは行われない

以上から、proxy経由でのwebsocketsをなるべく利用可能にするならrawな（SSLでない）websocketsの口をポート443であけて置く必要があります。このblogに張ったwebsockets chatはこの対応をやってます。(httpsは潰してますｗ）

ま、現状の実装（websockets, proxy）での話しなのでこの先は分かりませんが…。

後、思い浮かぶことをつらつらと。

# 元記事の proxy のキャッシュっていうのは、元記事のネタ元Blogの記事でjpegという静的ファイルのダウンロードの高速化を取り上げててそれに反応しての記述です。もちろんキャッシュが効かないコンテンツに対してProxyのキャッシュ云々という話は、websocketsだろうがajaxだろうがhttpだろうが関係ありません。

新技術って何のために有るのかを考える必要が有ります。

既存技術を使って出来ること新技術で置き換える場合、そこには何らかのメリットが必要ですよね。
またデメリットが有るならそのメリットとデメリットどちらが大きいか計る必要も有ります。
単純にメリットデメリットと言っても、立場はそれぞれでサービサー・顧客・開発者色々です。

webの高速化に１台のクライアントからセッションがんがん張ってそのためにwebsockets利用って言うのは違う気がしたんですよね。クライアントからのセッション数がHTTP/1.0で4本、HTTP/1.1で2本に制限されてるのも訳有ってのことなのですよ。

pipelineに関してはもっと低レベルな話でGoogleのSPDYとかがまっとうなアプローチな気がします。サーバ、クライアント、Proxyその他色々インフラ面での対応が必要ですがコンテンツ側は意識する必要が無いという利点が有ります。

websocketsに関して言えばまだまだ出てきたばかり動くようになったところで、websocketsを使って何をするかって言うのもこれからだと思います。そんな中でwebcoskets + pipelineで高速データ転送！っていうのがスタンダードな使い方に成ってほしく無いなと。

所々、文字化け等有るかもorz