Fix typos in the calendar module.

403くらってデータ取れない事多数･･･

Code Review http://codereview.appspot.com/4284066/ Issue 4284066: Fix for RequestError caused by too...

どっちも hg のリポジトリは更新されてるんだけど…。

例によって誰かの役に立つかもなので差分貼っておこう。

diff -urN ./gdata-2.0.14/src/gdata/calendar/data.py ./gdata-2.0.14-kuma/gdata/calendar/data.py
--- ./gdata-2.0.14/src/gdata/calendar/data.py 2011-01-25 08:46:28 +0900
+++ ./gdata-2.0.14-kuma/gdata/calendar/data.py 2011-04-28 14:18:27 +0900
@@ -30,7 +30,8 @@

Nicholas Piël » Benchmark of Python Web Servers

すげー、その調査力に感服。って違うｒｙ

　gevent/libeventが良いですね～。wsgiref.simple_serverだと 2.6TPS エラー有りまくりだったアプリを試しにgevent.wsgi.WSGIServerにするとそれだけで13.7TPS！エラーも無しといい感じ。なんですが個人的なホーム鯖でgevent/libeventは流石にやり杉な雰囲気です。お試しはLinuxでやってますが諸事情からホーム鯖はWindowsです（ドライバがWindowsしかない…）。Internet公開もしないしってことでもうちょっとwsgiref.simple_serverで頑張ってみることにします。

そもそもシングルスレッドを何とかします。

from SocketServer import ThreadingMixIn

class ThreadingWsgiServer(ThreadingMixIn, WSGIServer):
pass

class ThreadingWSGIRefServer(ServerAdapter):
def run(self, handler): # pragma: no cover
from wsgiref.simple_server import make_server, WSGIRequestHandler
if self.quiet:
class QuietHandler(WSGIRequestHandler):
def log_request(*args, **kw): pass
self.options['handler_class'] = QuietHandler
self.options['server_class'] = ThreadingWsgiServer
srv = make_server(self.host, self.port, handler, **self.options)
srv.serve_forever()

bottle.run( server=ThreadingWSGIRefServer, host='0.0.0.0', port=8080,
interval=1, reloader=False, quiet=True )

ついでにログ抑制もやってみたり。後、Windowsだと特に遅くなるクライアントIPアドレスのDNSリバースlookupをhttp://bugs.python.org/issue6085を参考に外します。まー、ログ出さないなら外す必要も無いんですが、出す出さないでパフォーマンスの変化を見るために一応。

def _bare_address_string(self):
host, port = self.client_address[:2]
return '%s' % host

import BaseHTTPServer
BaseHTTPServer.BaseHTTPRequestHandler.address_string = \
_bare_address_string

ぐぐる先生はこんなの↓も教えてくれましたがこれはちょっとやり杉。

def getfqdn(name=''):
return name
import socket
socket.getfqdn=getfqdn

quiet=Falseで8.4TPS、quiet=Trueで 10.9TPSって所まで改善。5倍差があると流石にgeventしかないなと思うものの2倍差も無いところまでくるとまーgevent使うことも無いなに変わるから不思議。ログ出すとパフォーマンスは悪くなりますがまぁ良いかと思えなくも無いのでとりあえず出す感じで。

ちなみにgevent/bottleだとこんな感じのコードに。

from gevent import wsgi
application = bottle.default_app()
wsgi.WSGIServer(('', 8088), application).serve_forever()

と、頑張ったところでSQLAlchemyがちょい重ということに気づいてorzなのですが…。

直感的に感じているのは各端末毎のスペックがばらばらで、端末毎のおもてなしを最適化するのが困難な上に、１端末種類のパイが少ないから最適化にかけた情熱が見合わないと言うこと。端末の画面サイズの違いやタッチパネルの感度・感覚の違いが低いレイヤで吸収できてないから、使い心地を作り込む作業が難しい。直感的操作がメインのスマホなら当然のこと。直感的操作・使い心地という抽象的な指標だから抽象的にしかかけないので伝わるかどうか微妙だけど。

まー、iOSも複数端末有るけどfewで収まる範囲。Androidはmany。あとＨＷの変更サイクルが今のところ推測可能かつ緩やかかつUIというかUXに関してはある程度統一されてるのでiOSの方が安心と言うことか。

おいらはこの記事「The Problem with Inconsistent Button Layouts on Android」読んでAndroidは難しいなーと思いました。

と、書きつつも実は「Androidのアップグレード問題に関してひとこと」には突っ込みたい所満載。

スマートフォンの場合は、それぞれのハードウェアも大きく異なっているし、共通Biosのようなものも存在しない。

んー、今のところARMコアで SoC の系統が同じならそんなに違わない。Biosは無いだろうけどAndroidは基本、Linuxカーネルさえ動けば何とか成る。Androidでgoogleが追加したドライバもちょっと有る物のそれは移植が困難な物ではない。

こう考えてみると、MicrosoftとIntelが作り出した「Windowsパソコン」というプラットフォーム・ビジネスの成功が実はものすごく例外的なものだったんではないかとつくづく思えて来る。

これってバージョンアップの話をしてるんだろうか…。バージョンアップに関して言えば3.1/95/98/ME/XP/Vista/7ってハード買い換えずにアップグレードして満足に使ってた人って少ないんじゃないだろうか。少なくとも普及後近年の状況だと未だに半数以上が１０年前のＯＳのＸＰだし。１０年前のＰＣで７やDirectX11が快適に使えるわけもなく。この辺年のスパンでアップデートするＯＳに比べ日進月歩なAndroidでバージョンアップが難しいっていう話はハード買い換え前提じゃないからあると思う。

最近書評とかも少ないなぁ。

　VPS上（つまりこのサーバ）ではapacheが上がってます。apacheのmod_proxy辺りでGAEから受けてsearch.twitter.comへ転送しても良いんだけどmod_proxyは一般的かつ便利なだけにまじめに設定しないと穴になることも多く…と避けて単純にstoneで転送させる方針で＝つまりapacheの80番ポートとは別ポートで。と思ったらGAEのurlfetchのドキュメントに以下書かれてます。

URL は、HTTP（80）および HTTPS（443）の標準ポートを使用しなければなりません。ポートはスキーマによって決まりますが、ポートがスキーマの標準である限り、URL で指定することもできます（https://...:443/）。アプリケーションはリモート ホストの任意のポートに接続することはできません。また、スキーマの非標準ポートを使用することもできません。

うーん、と思って早半年（笑）ふと思い立って英語のドキュメントを見ると。

An app can fetch a URL using HTTP (normal) or HTTPS (secure). The URL specifies the scheme to use: http://... or https://...
The URL to be fetched can use any port number in the following ranges: 80-90, 440-450, 1024-65535. If the port is not mentioned in the URL, the port is implied by the scheme: http://... is port 80, https://... is port 443.

なんじゃそりゃー。という事でtweepyのsearch apiの投げ先をここにしてstoneをほにゃっ※１て無事search復活。長い半年でしたｗｗｗｗｗ

意欲的に翻訳されてて日本語ドキュメントが存在するのは良いことなんだけど旬なものは更新早いから？と思ったら英語版ドキュメントを確認すべしっていうのは個人的には鉄則なんだけどGAEのドキュメントってAccept-Languageみて自動的に日本語へリダイレクトされちゃうのが難。今は日本語ドキュメントからURL書き換えて飛んでいます。

日：http://code.google.com/intl/ja/appengine/docs/python/urlfetch/overview.html
英：http://code.google.com/intl/en/appengine/docs/python/urlfetch/overview.html

※１ twitter側でHTTPヘッダのHost:フィールド参照しているのでその書換えが必要。書き換えないと301食らいます。これもGAEの制限で飛ばし先とHost:フィールドは必ず一致する仕様なので（Host:フィールドは変更できない）仕方なし。stoneは標準でヘッダ追加は対応していますが書換えは対応していないのでほにゃっとコードでっち上げて…

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

ほぼ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 « ケンタテクブロで先を越されてエントリしていませんでしたが一応記事にしておきます。