<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>kumama</title>
	<link>http://kumama.org</link>
	<description>go言語とかgolangとかGAEとかネットサービスとかその他色々・・・</description>
	<lastBuildDate>Thu, 28 Apr 2011 09:39:08 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.2.1" -->

	<item>
		<title>gdata-python-client 2.0.14</title>
		<description><![CDATA[gCalのnsの項目が拾えない… uidが拾えないのが致命的…。 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 @@ GCAL_NAMESPACE = 'http://schemas.google.com/gCal/2005' -GCAL_TEMPLATE = '{http://schemas.google.com/gCal/2005/}%s' +#GCAL_TEMPLATE = '{http://schemas.google.com/gCal/2005/}%s' +GCAL_TEMPLATE = '{%s}%%s' % [...]]]></description>
		<link>http://kumama.org/2011/04/gdata-python-client-2-0-14/</link>
			</item>
	<item>
		<title>Python simple_server tuning</title>
		<description><![CDATA[　GAE/PythonでごそごそやってますがたまーにGAEじゃ出来ない事をしたくなるときが有ります。ローカルのデバイス操作したりファイルごにょごにょしたり。そんな時は…Apache入れてmod_wsgi入れて…って言うのが王道にも思いますが結構大変。いっそのことdev_appserverで逃げようかとか思ったりもするもののライセンスも良く解からん上、シングルスレッド動作のwebサーバなので気が引けます。 　で、Pythonに漏れなく付いてくるwsgiref.simple_serverとbottle+sqlalchemy/sqlite+flaskで落ち着いてたんですがやっぱりパフォーマンスが…。って事でちょっとぐぐる先生に聞いてみるとこんなページを紹介されるのでした。 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, [...]]]></description>
		<link>http://kumama.org/2011/02/python_simple_server_tuinig/</link>
			</item>
	<item>
		<title>Androidは複数形</title>
		<description><![CDATA[「Androidのアップグレード問題に関してひとこと」を読んで。 直感的に感じているのは各端末毎のスペックがばらばらで、端末毎のおもてなしを最適化するのが困難な上に、１端末種類のパイが少ないから最適化にかけた情熱が見合わないと言うこと。端末の画面サイズの違いやタッチパネルの感度・感覚の違いが低いレイヤで吸収できてないから、使い心地を作り込む作業が難しい。直感的操作がメインのスマホなら当然のこと。直感的操作・使い心地という抽象的な指標だから抽象的にしかかけないので伝わるかどうか微妙だけど。 まー、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でバージョンアップが難しいっていう話はハード買い換え前提じゃないからあると思う。 最近書評とかも少ないなぁ。]]></description>
		<link>http://kumama.org/2011/02/android_is_androids/</link>
			</item>
	<item>
		<title>英語で読もう</title>
		<description><![CDATA[GAE(Google App Engine)上のTwitterクライアント、一つ放置してた問題に対応。それはsearch apiの回数制限。他のAPIはユーザベースでrate limitされているのでログインしていればAPI制限に引っかかる事はまずないんだけど、search apiだけはTwitter側でリクエスト元のIPアドレスベースでrate limitしている・・・のでGAEのインスタンス共有している他ユーザーがsearch api叩きまくってるとすぐにlimitにひかっかる。ちょっとネットを彷徨った感じsearch apiだけは別鯖へproxyしろっていうのがgoogle様のお告げの様でその様に。 とはいえ別鯖ってOpenProxy使うって訳にも行かないのでVPSに飛ばしてと思ってたら…という所で本題。 　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, [...]]]></description>
		<link>http://kumama.org/2011/02/read-in-english/</link>
			</item>
	<item>
		<title>求ム：挑戦者w</title>
		<description><![CDATA[ガラケー用の twitter クライアントweb作っています。 一応DoCoMoで動いてますがAUとかSBMで試してもらえると助かります。 ま、ほかの既存の携帯向けサービスでも良いんだけど、 アイコンとか要らんから軽くしてくれというかそういう方向性で。 ほぼ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しますがそれまでの延命用ってことで。]]></description>
		<link>http://kumama.org/2010/07/need-challenger/</link>
			</item>
	<item>
		<title>ワンセグを http live streaming して iphone で見る</title>
		<description><![CDATA[って、試してるのはipod touch (1st gen)なんだけどw。 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なんだけど。 と、需要あるのかないのかなのでとりあえず。]]></description>
		<link>http://kumama.org/2010/06/1sg-http-live-streaming-iphone/</link>
			</item>
	<item>
		<title>twitter本家に QT 用のリンクを追加するbookmarklet</title>
		<description><![CDATA[普通にクライアント使ってAPIでっていうのが正解だと思うんだけど、 公式RTとか、非公式RTとか、QTとか in_reply_toが付くとかつかないとか、 色々ある訳で。 クライアント使ってなくても、でも何となく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; } [...]]]></description>
		<link>http://kumama.org/2010/06/add-qt-link2twitter-bookmarklet/</link>
			</item>
	<item>
		<title>日本のガラパゴス問題</title>
		<description><![CDATA[ガラパゴス問題をガラパゴスに閉じるのはやめよう - My Life in MIT Sloanにコメントしてたんだけど後続のエントリが書かれていたので俺も書いてみます。 後続エントリ。ガラパゴス問題の論点まとめ。 - 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]]></description>
		<link>http://kumama.org/2010/05/japan-is-the-galapagos/</link>
			</item>
	<item>
		<title>新！？VAIO P</title>
		<description><![CDATA[４月末からティーザーを展開していたわけですけど5/10に正式発表されました。 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を選ぶ理由が無くなっているかも知れません。]]></description>
		<link>http://kumama.org/2010/05/new-old-vaio-p/</link>
			</item>
	<item>
		<title>WebSocket Draft76</title>
		<description><![CDATA[１周半ぐらい周回遅れですが、WebSocketのDraftが更新されていて76に成っています。 Handshake周りが変わっていて前バージョンとの互換性が実装次第なので注意が必要。 って、WebSocket Draft75 « ケンタテクブロで先を越されてエントリしていませんでしたが一応記事にしておきます。]]></description>
		<link>http://kumama.org/2010/05/websocket-draft76/</link>
			</item>
</channel>
</rss>

