nori's tech days: 5月 2009

2009年5月31日日曜日

Tsudaったー対応

世界で一番簡単な対応 with tweetdeck.
「group: tsuda」をつくる

2009年5月28日木曜日

本棚

送信者 0528

本棚を組み立てた。これで床に積まれている本を収容できるはず。

matrixぽくないか、これ

フォントの色を蛍光緑にしてみるか。pixelの使い道かとしてどうなのさ、これは。

2009年5月23日土曜日

python 2.4以降が必要です。2.5以降が望ましいです。

まずGoogle App Engine(以下、GAE)の開発環境本体のダウンロード
http://code.google.com/intl/ja/appengine/downloads.html

次にwsgirefをインストールする(2.4な人)、2.5以降の人はそのまま進んでください
pypiから入手
http://pypi.python.org/pypi/wsgiref
私はrpm/yumで管理する派なのでpython setup.py bdist_rpmします。

そのほかの依存
PIL、python-imaging-library(GAE stubの実装が依存)
http://www.pythonware.com/products/pil/

お薦めのコンボ
webtest、テスト用のアプリを書くために必要
http://pypi.python.org/pypi/WebTest/1.2

nose、テストツール
http://somethingaboutorange.com/mrl/projects/nose/0.11.1/

NoseGAEはnoseのpluginで、GAEの環境を再現してくれます。http://code.google.com/p/nose-gae/

covoerはnoseのpluginで、unittestでどれだけの範囲を叩いたかを調べることができます(最新のnoseには含まれている模様)。http://somethingaboutorange.com/mrl/projects/nose/0.11.0/plugins/cover.html

プロジェクトを始めるには、googleから持ってきたものを解凍したdirにいってtemplateをコピーしてみましょう。細かい話はgoogleのドキュメントを読みましょう。

google_appengine% cp new_project_template sample
google_appengine% chmod -R +w sample/*

そのままではread onlyなので変更

google_appengine% nosetests --with-gae --gae-lib-root=. --gae-application=sample --with-coverage --cover-package=main sample

とするとnoseでunittesができて、かつcoverageの情報が得られます。

2009年5月22日金曜日

XMPP/AMQP @ BPStudy

VoluntasさんのBPStudyの発表を観に行った。
以下メモ。

XMPP xml base
AMQP binary

Erlang
Open Telecom Platform プロセスを監視できるこれが一番大きい。(実際に作るとなると並列、分散はどうでもいい）
まあ、エリクソンが作って使っている集大成だから。

メジャーアプリ。
Facebook Online Chat
AWS imple DB
Apcache CouchDB IBMが力をいれているC++から移行。
分散ハッシュDB Jai /Scalaris gooをpowerしている。Amazaon Key Value Storage実装

higempon 20090509/1241863278
このエントリのせいでErlang

情報処理学会に出ている2009/3のErlangの解説記事

XMPPとは
XMLベースのプロトコル
RFCで
Jabber -> XMPP
Google Talkが採用（完全準拠？）
動きはMail serverと同じ
TCPコネクション張りっぱなし

仕様はがちがち
拡張もいっぱい、まあXMLですから

基本：Client同士がMessageを直接やりとりする。
しかしportがつぶれていると

googleのライブラリはHole panchingしている。
すげー力業 10万行のC++

状態をXMPP Serverが状態を配る。

message サーバは1 domainを担当する。
google じゃなくて自前もできる。

Serverがコネクションをリレーしてくれる。
日本では流行っていないが、海外では１ユーザ月額課金のサービスがある。

接続
XMPP Serverにログイン
XMPP ServerにIDとIPを伝える
XML目っ正ー時
別のXMPPサーバに転送
別サーバはDNS検索

セキュリティ
SSL/TLSによる通信を暗号化
DNSでドメイン名を逆引き確認
SASLによるチャレンジ型検証

SASL RFC2222

XMPPの未来
googleがさいようしたのは大きい
プッシュベースのアプローチは大事
非同期メッセージは必要
ソリューションという形が進みそう
OpenFireという「製品」がある→チャットルームが作れる。ただしクライアント側が対応していないといけない。

同時接続クライアントは？
10KはOKでしょう。
　そもそもにスケールを前提に仕様が作られている
クラスターベースでやる

ejabberd
XMPP
Erlang
Unbutuならapt-get

Ejabberd "cloud Edition alpha"
データベースをS3に配置
将来的にはSQSを使うようだ

AWS import/export
HDDをアマゾンへ送る（！、ハードのスペックが指定されている、重量等
アマゾン側でS3にインポートする

1TByteでupで$100,
日本のクレジットが通ったが、アメリカに郵送。
帯域の問題でFedexの方がやすい。時間を買っている。

AMQP

Advanced Message Queue Protocol
MQの保湯順規格を目指すプロトロコる
メッセージ指向ミドルウェア
アプリケーション菅野通信プロト古老
言語や環境に関係なく相互接続を実現
今年中に1.0が公開されるはず

バイナリプロトコル
PubSub型
ストア・アンド・フォワード
TCPであることを利用した信頼転送
非同期なのにトランザクション、コールバックしない（これがメリット）。
マルチキャスト

Publish
Exchangeがqueueにひたすら突っ込む

Direct Exchange Type
ルーティングキーがきも

funout
ルーティングキーすらなし。
さらのキー。ただひたすら他得られる

パターンを使用したルーティングキー
a.b.c.dといったキーパターン
#や*のワイルドカードが使用可能
AMQP 0.8まで実装済み

Rabbit MQ
130万request/s (1つのサーバで！）・・・他の部分が持たない？
10K line
ただし、Erlangのundocumentedな機能を多用なので、VMのコードを読まないとダメ。

金融機関とかが使うらしい。
ニュースの配信、電話会社等。

XMPP gatewayやSTOMP gateway

作っている会社はL shiftはこれで食っている

Kay App Engine / Python 専用フレームワーク
kayはtmatsuoさんの息子の名前

非同期と純関数は計算としてはうれしいのだが、人間にやさしくない。

とんがったパーツなのだが、クライアントが手書き。
clientの実装作業を受注しているのではないだろうか。

金がかかっている。AMQPは。

GAE上でXMPPを使えるようになるらしい。
googl
e IOで発表されるかも

XMPP
ルームチャットはN:Nになる？？
その負荷を面倒を見たくないからgoogleはgroup chatなし(googleはstar型になっている)

SQSがアマゾンにある

rabittmqはqueueのバックエンドはmnesiaを使っている。
2Gの制限はぶった切ることで対応、基本全てメモリ。
基本的に永続化しない。

mnesiaはよく使われているのか？微妙
　ただ分散dbなので設定ファイルを蒔くのに使う
　制限がきついのが痛い→wrapperを書くことになる。
tokyo cabinetを後ろにつないだひとがいるらしい。でもなんかメモリリークしてる。

gihyoで記事書きました

ここです。
お目汚し失礼。

AR Magicを見て思った

配線の変更、パンチカード、CUI、GUIと進歩してきたが、次はAR UIだろう。
いま、UIはタイプ速度に支配されている。ARやカメラ・マイク・GPSを賢く使えば、もっと速い速度でもっと細かいニュアンスを拾ってコンピュータを賢く振舞わせることが出来るだろう。ハードよりもソフトとアイディアと＄の問題だと思う。

冷蔵庫の扉に液晶を貼ってネットショッピングさせるより、冷蔵庫の中でARして、無いものを買うことが出来るほうが使い勝手がいいだろう。靴箱に液晶を貼るより、ARで新製品を立体表示したほうが楽しいだろう。コンピュータの前に座って何を買うかを指定するより、場所で買うものが必然であるほうがいい。

でも冷蔵庫の中が温まりそうだな、この仕組み。

2009年5月21日木曜日

githubをはじめた

Gravatorもはじめた。
GravatorとかOpenID、GAEを見ると、「ちょっとしたものだがuserに対して気遣いのあるwebapp」を作る労力が減っているのがわかる。

本が届いた。

amazonから注文していた本が届いた。

キャパシティプランニング

CDNプロトコル入門

Interconnections第２版

アクセスログ解析の教科書

集合知インアクション

ThoughtWorksアンソロジー

Release It!

未来のモノのデザイン

キャパシティプランニングは、「ハイパフォーマンスウェブサイト」（犬本）と「サーバ負荷分散技術」とあわせて読むといい感じです。でかいweb site構築三連星。たぶんスケーラブルウェブサイト（魚本）も取り合わせとしてよいだろう。

原因は

statusのセットしもれ。明示的にセットする必要がある。
headerは明示的に消さなければならない。


  def relay_response(self, src, status):
    assert status
    self.response.set_status(status)
    for key in src.headers:
      self.response.headers[key] = src.headers[key]

    if status in ENTITYLESS_STATUS:
      for key in PROHIBTED_IN_ENTITYLESS:
        del self.response.headers[key]
    else:
      self.response.out.write(src.content)
      for key in PROHIBTED:
        del self.response.headers[key]

httplibで叩いてみた

まずはサーバ側の出力が正しいこと＋gae stubの実装に使われているhttplibが正しいことを検証。
コード。


import httplib

PATH = '/image?format=png&gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal'
HOST = 'image.backgammonbase.com'
ADDR = '192.168.2.64'

conn = httplib.HTTPConnection(ADDR)
conn.request("GET", PATH, headers={'host':HOST})

r = conn.getresponse()
print r.status
print r.getheaders()
etag = r.getheader('etag')
print etag
conn.close()

conn = httplib.HTTPConnection(ADDR)
conn.request("GET", PATH, headers={'host':HOST, 'If-None-Match':etag})

r = conn.getresponse()
print r.status
print r.getheaders()
conn.close()

実行結果

[nori@asama]~/Desktop/study/python/httplib% python test.py
200
[('content-length', '17877'), ('age', '102'), ('expires', 'Thu, 21 May 2009 01:39:27 GMT'), ('server', 'Apache/2.2.3 (CentOS) mod_python/3.2.8 Python/2.4.3 DAV/2 SVN/1.6.2 mod_wsgi/2.1-BRANCH'), ('etag', 'code:6bf600612d854254f2d17b68682de576620b5257+css:c484f9e5d8c595e9c0d36f7889d651e21f06e4f7'), ('cache-control', 'public'), ('date', 'Thu, 21 May 2009 00:41:09 GMT'), ('content-type', 'image/png')]
code:6bf600612d854254f2d17b68682de576620b5257+css:c484f9e5d8c595e9c0d36f7889d651e21f06e4f7
304
[('date', 'Thu, 21 May 2009 00:41:09 GMT'), ('cache-control', 'public'), ('etag', 'code:6bf600612d854254f2d17b68682de576620b5257+css:c484f9e5d8c595e9c0d36f7889d651e21f06e4f7'), ('expires', 'Thu, 21 May 2009 01:39:27 GMT'), ('server', 'Apache/2.2.3 (CentOS) mod_python/3.2.8 Python/2.4.3 DAV/2 SVN/1.6.2 mod_wsgi/2.1-BRANCH')]

ヘッダをつけ間違えたかな？

2009年5月20日水曜日

bug found

200 OK
HeaderDict([('Content-Type', 'text/html; charset=utf-8'), ('date', 'Wed, 20 May 2009 10:50:11 GMT'), ('server', 'CherryPy/2.3.0'), ('cache-control', 'public'), ('Content-Length', '0')])

げー。200を返してContent-Length 0ってなんだよ。ハァ。

- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=jpeg HTTP/1.1" 200 16036 "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 200 17877 "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 304 - "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 304 - "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=jpeg HTTP/1.1" 200 16036 "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 200 17877 "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 304 - "" ""
- - "GET /image?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA&height=300&width=400&css=minimal&format=png HTTP/1.1" 304 - "" ""

サーバ側は304してる。

GAE app 'reverse proxy'のunittestで

WebTestをインストールしてテストを書いていたが、


    response = self.app.get('/image'
                     '?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA'
                     '&height=300'
                     '&width=400'
                     '&css=minimal'
                     '&format=png')
    assert response.status == '200 OK'
    print response.headers

とかしたら


HeaderDict([('Cache-Control', 'no-cache'), ('Content-Type', 'image/png'), ('Content-Length', '17877')])

とか出力されて萎えた。no-cacheはどこが原因だ？

NoseGAE

rootとappの指定の仕方で戸惑った。rootは見ての通り。appを指定しないと設定ファイルが無いのでテストできない。


[nori@asama]~/Desktop/work/gae/google_appengine% nosetests --with-gae  --gae-lib-root="/home/nori/Desktop/work/gae/google_appengine" --gae-application=reverse_proxy reverse_proxy/test.py
WARNING:root:Could not read datastore data from /tmp/nosegae.datastore
WARNING:root:Could not read datastore data from /tmp/nosegae.datastore.history

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

2009年5月19日火曜日

reverse proxy on GAE

本体をローカルで動かしてなぜGAE上でアプリを作らないのは、PILが使えないとか、いろいろ。注意点はurllib.urlopenがsocketを使うので、GAE上では使えない。そのため、urlfetchを使う。あとは、ハンドラで.*を指定してリクエストを全部持ってくること。

普通のproxyもつくれるね。もう作った人がいるだろうけど。

#!/usr/bin/python

import urlparse
import wsgiref.handlers

from google.appengine.ext import webapp
from google.appengine.api import urlfetch

cache_related = ('if_match', 'if_modified_since', 'if_none_match', 'if_range', 'if_unmodified_since')

NETLOC = 'image.backgammonbase.com'
SCHEME = 'http'

debug = False

class ReverseProxyHandler(webapp.RequestHandler):
  def get(self):
    scheme, netloc, path, query, fragment = urlparse.urlsplit(self.request.url)
    t = urlparse.urlunsplit((SCHEME, NETLOC, path, query, fragment))
    if debug:
      self.response.out.write(t)
    else:
      response = urlfetch.fetch(t)
      self.response.headers['Content-Type'] = response.headers['Content-Type']
      self.response.out.write(response.content)

def main():
  application = webapp.WSGIApplication([('.*', ReverseProxyHandler)],
                                       debug=True)
  wsgiref.handlers.CGIHandler().run(application)

if __name__ == '__main__':
  main()

GAEはじめた

自分のサーバにrequestを出してみた。
決め打ちのurlの代わりになにか別のものを割り当てないとね。


class MainHandler(webapp.RequestHandler):
  def get(self):
    response = urlfetch.fetch('http://image.backgammonbase.com/image'
                              '?gnubgid=4HPwATDgc%2FABMA%3AMAAAAAAAAAAA'
                              '&height=300'
                              '&width=400'
                              '&css=minimal'
                              '&format=png')
    self.response.headers['Content-Type'] = response.headers['Content-Type']
    self.response.out.write(response.content)

2009年5月18日月曜日

ついでなのでサーバ負荷を見てみた

初回のリクエスト時。がんばって画像を生成しているので負荷が高い。

mem_cacheされた画像をネットワークに書き出しているだけなので、ネットワークだけが重い。

メインテナンス終了

メンテナンス内容：

内部清掃

REX SATAの配線

2009年5月16日土曜日

Wolfram|Alpha

ここより

気づいた点：
水平をちゃんとだしてますね。

エンクロージャ：PowerEdge 4210 でしょうか？ 42Uです。
なかみ：１台2Uでしょうね(1Uが1.75インチ(約44.5mm)に相当))。前面3.5inch HDDのラックがが12台はいるなぁ、これは一体どういうことだ？on lineで見ても8台って書いてあるがこれはボードのSATAの口が８個っていう意味なのか？サーバ屋ではないのでわかりませぬ。

2Uの１台で最低4~5k$とかかな？エンクロージャ１台で200K$とかかなぁ？エンクロージャ6台とネットワークのコストを含めると1~2M$かな。私にとってはほとんど妄想の世界。マシン台数は120台。gのコンテナの1/10。もっとも、wolframの場合はHDDにかなり偏っているように見える。

2009年5月15日金曜日

MySQLの後継？

MySQLがフォークか、オープンアライアンスが誕生

ウィデニウス氏は、すでにMySQL互換の「MariaDB」をコミュニティベースで開発している。MariaDBの公式ページによれば、MariaDBはMySQLの「ブランチ」と表現されている。MySQLはコアになるストレージエンジンが入れ替え可能という特徴があるが、 MariaDBはMySQLをベースに、Mariaストレージエンジン、PBXTというエンジンを搭載。Mariaストレージエンジンをデフォルトとしたものだという。ほとんどのケースでMariaDBはMySQLと同じ挙動を示し、すべてのコマンド、ライブラリ、APIなどを備えているという。

各言語でのbindingとかはどうなっているのだろう？対応はそれほどタフでは無いだろうが。

2009年5月13日水曜日

okyuu.comとfriend feed/twitter

http://okyuu.com/ja/の新着のrssってどこ？
あと思ったのだが、わざわざPostするより、ハテぶしたりblogに書いたりしてfriendfeed/twitterにそれが流れて御仕舞いというのがこれからの情報の流れだと思う。とここ数ヶ月での自分の変化を振り返って思った。ただ、よりナマな編集がすくない密度の低い情報になる傾向があるとすると、そこにおいて技術はどういう役割があるのかなぁ思ったり。

emobile 速度測定

よくわからね。測定結果がころころ変わる。帯域割り当てがかなり動的なのかもしれない。

■速度.jp スピードテスト高機能版回線速度測定結果
http://zx.sokudo.jp/　v3.0.0
測定時刻 2009/05/13 04:29:47
回線種類/線路長/OS：光ファイバ/-/Linux/東京都
サービス/ISP：-/その他
サーバ1[N] 2.34Mbps
サーバ2[S] 2.11Mbps
下り受信速度: 2.3Mbps(2.34Mbps,292kByte/s)
上り送信速度: 390kbps(393kbps,49kByte/s)

きになったのででかいファイルを落としてみた。平均速度が先の計測結果を上回っているので、使っているとより帯域が割り当てられるのではないだろうか。


[nori@kongoh]~/Desktop/bearoffdb% time wget http://bd.backgammonbase.com/gnubg_twoside_6x11.bd
--04:34:16--  http://bd.backgammonbase.com/gnubg_twoside_6x11.bd
bd.backgammonbase.com をDNSに問いあわせています... 124.155.113.117
bd.backgammonbase.com|124.155.113.117|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 1225323048 (1.1G) [application/octet-stream]
Saving to: `gnubg_twoside_6x11.bd'

100%[====================================================================================================>] 1,225,323,048  484K/s   in 51m 46s

05:26:04 (385 KB/s) - `gnubg_twoside_6x11.bd' を保存しました [1225323048/1225323048]

wget http://bd.backgammonbase.com/gnubg_twoside_6x11.bd  4.26s user 22.20s system 0% cpu 51:47.80 total

googleを騙るspam

Google Online Promotions

詳細を表示 1:51 (4分前)

返信

Follow up message
From Google Online Promotions
返信先 mrf.henson@8u8.com
To
日付 2009/05/13 1:51
件名 Google Online Promo © 2009
送信元 youseepost.dk

GOOGLE GIVE-AWAY WINNING NOTIFICATION!!!
This E-mail is to inform you that your e-mail emerged as a winner of £500,000.00 GBP (Five Hundred Thousand British Pounds) in our online Give-away draws. GoogleUK has successfully organized for the second time a Cash Give-Away in the UK. Over £20,000,000.00 (Twenty Million British pounds) is to be given out for this Anniversary Draws. No purchases of tickets were required. Participants for the draws were randomly selected from a world wide range of web searchers who use the Google search engine (Googler) and other Google ancillary services. Google is now the biggest search engine worldwide and in an effort to make sure that it remains the most widely used search engine, Google is running an e-mail beta test.

Your email address was linked with our Computer Generated Profile Numbers(CGPN) and attached to the following details: Computer Generated Profile Numbers (CGPN):7-22-71-00-66-12, Ticket number: 00869575733664, Serial numbers:/BTD/8070447706/06, Lucky numbers: 12-12-23-35-40-41(12), was picked among our lucky winners to receive £500, 000.00 British pounds. Winners were selected randomly through a computer ballot system from worldwide users of the Google search engine.

YOUR WINNING DETAILS ARE AS FOLLOW:
Computer Generated Profile Numbers (CGPN):7-22-71-00-66-12
Ticket number: 00869575733664
Serial numbers: / BTD/8070447706/06
Lucky numbers: 12-12-23-35-40-41(12)

To claim your give-away prize, send the following
Your full names................. , sex...............................,
Location............................
Alternate e-mail address..................Your winning details.................

To your processing agent (Mr. Francis Henson) who have been assigned to handle your winning file and payment processing.

Your Processing Agent contact:
Mr. Francis Henson,
Email: giveaways.promoonline02@gmail.com

We wish you the best of luck as you spend your good fortune. Thank you for using Google.

Sincerely,
Mrs Susan Johnson.

2009年5月9日土曜日

UI

ファミコンはこうして生まれた
試すこと。

十字ボタンでいけると確信していた沢野は，ゲーム＆ウォッチからリード線を引っぱり出してファミコンの試作機につなぎ，開発スタッフに操作してみるように促した。真っ先に試したのは中川だった。驚くほど手に馴染み，なんの違和感も感じなかったという。

UIの出来はきわめて重大

操作に忠実に反応しないゲーム機は，ユーザからそっぽを向かれることは開発スタッフの全員が身にしみていた。

簡単らしい

超簡単な問題を朝食後にやってみた。13:39。。。遅い！！しかもpythonというよりlisperが好みそうな答えだ。しかしtest caseの書き間違いとn==0のケースで時間を無駄にした。


def deal(n, deck):
  '''
    >>> deal(3, '123123123')
    ('111', '222', '333')

    >>> deal(4, '123123123')
    ('12', '23', '31', '12')

    >>> deal(6, "012345012345012345")
    ('000', '111', '222', '333', '444', '555')

    >>> deal(4, "111122223333")
    ('123', '123', '123', '123')

    >>> deal(1, "012345012345012345")
    ('012345012345012345',)

    >>> deal(6, "01234")
    ('', '', '', '', '', '')
    >>> deal(2, "")
    ('', '')
    >>> deal(0, "")
    ()
  '''
  if n < 1:
    return ()
  if len(deck) < n:
    return ('',) * n
  xs = deck[:n]
  ys = deal(n, deck[n:])
  return tuple((xs[i] + ys[i] for i in range(n)))

if __name__ == '__main__':
  import doctest
  doctest.testmod()

OpenID

tcの記事

普及はいまいちみたいね。OAuthとか出てきちゃったし。こういうのって技術的問題じゃなくて、「政治的」問題だからなぁ。

2009年5月8日金曜日

速度測定

また違う場所ではかってみた。
おっっせー。でもどういうわけだか体感速度は速い。レイテンシがちいさいようだ。


■速度.jp スピードテスト 高機能版 回線速度測定結果
http://zx.sokudo.jp/　v3.0.0
測定時刻 2009/05/08 19:08:39
回線種類/線路長/OS：モバイル回線/-/Linux/東京都
サービス/ISP：-/-
サーバ1[N] 1.67Mbps
サーバ2[S] 621kbps
下り受信速度: 1.6Mbps(1.67Mbps,209kByte/s)
上り送信速度: 360kbps(369kbps,46kByte/s)

emobile 速度測定

http://zx.sokudo.jp/

■速度.jp スピードテスト高機能版回線速度測定結果
http://zx.sokudo.jp/　v3.0.0
測定時刻 2009/05/08 11:50:13
回線種類/線路長/OS：モバイル回線/-/Linux/東京都
サービス/ISP：-/-
サーバ1[N] 2.00Mbps
サーバ2[S] 2.29Mbps
下り受信速度: 2.2Mbps(2.29Mbps,286kByte/s)
上り送信速度: 370kbps(378kbps,47kByte/s)

2009年5月7日木曜日

テクノロジではなく流通。

Kindle版書籍の売上げ数は印刷版書籍の35%に達している

iTune/iPodのような成功のpathに入りかけているのかもしれない。iPodがなくてもなんらかの音声ファイルをポータブルな機器に入れることは別にできたが、コンテンツの流通の観点からはなにも新しいことは無かった。

電子ブックリーダは死屍累々だという認識ですが、ついにキャズムを超えられそうな製品がでたといえるでしょう。アマゾンは書籍を売るサイトから、物販のサイトという方向に進化していたが、印刷物という「ドリル」が提供する書籍という「穴」をkindleという別の方法で提供することができたことを、成功したフィールドでルールを買えるようなことに柔軟な取り組みができたことに驚かないのは変だろう。

QR code生成

ちょっと検索してみた。まあ、google chartのapiを使うのが一番自然で、クオリティとスピード、大量リクエストへの対応能力が一番期待できるでしょう。

http://chart.apis.google.com/chart?cht=qr&chld=H&chs=100x100&chl=jPPgACbYzsEBIQ:cAn1ACAACAAA

をimgで呼びます。

backgammonbaseのentryでもprinter friendlyな出力にはqrcodeを埋め込みたいですね。

ところで、qrcodeを返すサーバを実装している人はネット上に山盛りいるのですが、どういうわけだかjpegで画像を返すサーバがいます。こういうのを見つけると、なんか頭が痛いのは僕だけ？

2009年5月5日火曜日

でかいキンドル

でっかいキンドルが出るらしい。

アマゾンはデジタル書籍の流通を支配するのだろうか？キンドルに情報を流す仕組みは解放される日が来るのだろうか・・・。

2009年5月3日日曜日

あったらいいシェルの機能

複数の端末で、シェルの履歴を共有

補完を履歴から拾う

レイテンシ隠蔽のためにリモートの補完をローカルで計算する

2009年5月2日土曜日

cname

ちょっと投げるqueryの回数が気になったが多分１回だろう。


[nori@asama]~% dig @192.168.2.64 www.tonic-water.com

; <<>> DiG 9.3.4-P1 <<>> @192.168.2.64 www.tonic-water.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11004
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;www.tonic-water.com.           IN      A

;; ANSWER SECTION:
www.tonic-water.com.    86400   IN      CNAME   tonic-water.com.
tonic-water.com.        86400   IN      A       124.155.113.117

facebook needle

haystack @ facebook engineering blogを読んだときのメモ。

The Photos application is one of Facebook’s most popular features. Up to date, users have uploaded over 15 billion photos which makes Facebook the biggest photo sharing website. For each uploaded photo, Facebook generates and stores four images of different sizes, which translates to a total of 60 billion images and 1.5PB of storage. The current growth rate is 220 million new photos per week, which translates to 25TB of additional storage consumed weekly. At the peak there are 550,000 images served per second. These numbers pose a significant challenge for the Facebook photo storage infrastructure.

needle以前の構成

* Upload tier receives users’ photo uploads, scales the original images and saves them on the NFS storage tier.
アップロードを受け取ってNFSに書き込む層

* Photo serving tier receives HTTP requests for photo images and serves them from the NFS storage tier. HTTPリクエストを受け取ってNFSから画像を読み出して返す層

* NFS storage tier built on top of commercial storage appliances. 一般商用ストレージの上に構築されたNFS層。

NFSのmetaデータ読み出しがbottle neckになった。対策としてはCDNを使ったり、NFSのfile handleをcacheしたりしていた。

で、新しいheystackはどういう構成かというと

The new photo infrastructure merges the photo serving tier and storage tier into one physical tier. It implements a HTTP based photo server which stores photos in a generic object store called Haystack. The main requirement for the new tier was to eliminate any unnecessary metadata overhead for photo read operations, so that each read I/O operation was only reading actual photo data (instead of filesystem metadata). Haystack can be broken down into these functional layers

Haystackという汎用objectサーバを用意した。メタデータは読まない。リクエストしたらデータ自体を返す。

5つの機能からなる。

HTTP server

Photo Store

Haystack Object Store

Filesystem

Storage

Storage

10TBの容量が手に入る。2U storage blade。ハード構成なので割愛。

* 2 x quad-core CPUs
* 16GB – 32GB memory
* hardware raid controller with 256MB – 512MB of NVRAM cache
* 12+ 1TB SATA drives

raid6. raidカードのcacheはwrite用に使う。hddのキャッシュは殺してある。

File System

XFSだそうだ。extent baseなFile Systemはブロックを連続配置しやすいので、保存のためにブロックを複数必要とする画像ばっかりもつような用途では、有利ということらしい。

haystack

Haystack is a simple log structured (append-only) object store containing needles representing the stored objects. A Haystack consists of two files – the actual haystack store file containing the needles, plus an index file. The following figure shows the layout of the haystack store file:

Haystack = index file + needle file
needleは物理的に上書きされない。論理的に上書きされる。（同じkeyを持つneedleがappendされるとそちらが見えるようになる）

The main purpose of the index is to allow quick loading of the needle metadata into memory without traversing the larger Haystack store file, since the index is usually less than 1% the size of the store file.

index fileはメモリ上に持っておく。実体にはoffsetでアクセス。

データ書き込みは、データを同期で書き込んで、indexをあとから非同期で書き込む。indexは時々hddに書き込んであげる。クラッシュしたときはlast valid needle(推定するにまともにindexが保持されている範囲）まで、needle fileを読み進んでそこからindexに対して非同期書き込みを再開する。

空き領域はコンパクションをして回収。コンパクションとはdeleteやduplicatedな領域をskipしながらcopyすること。

Photo Store

needleのidをon memoryでもっている。scale済みを持つようにしている。

HTTP server

I/Oバウンドなので特になし。

gnubg configure

configureで渡すpathがbinaryに埋め込まれる.

そのpathは絶対path.

そのpathから起動に必要なデータを読み込む

rpmbuildしたい

なので


         --datadir=${RPM_BUILD_ROOT}%{prefix}/share \

とかするとRPM_BUILD_ROOTがハードコードされてちまうんでこまったものだ。
fileをrpmbuild時に配置するpathと、埋め込みのために渡すpathを別々に渡したいんだよね～。

2009年5月1日金曜日

デジカメ高解像度に意味が無い？

ここより

個人的には別の視点から高解像度に意味は無いと思っていた。
1. 暗くなりすぎ。（素子が小さいと感度が下がる、S/N比が悪化する)
2. データが重い。
3. jpegカラーでしか紙に焼けない。

300万画素以上だとfilmを超えているといわれていたが、そこの領域ではfilmと同じメカにはなんの保障も無かったとも言える。逆に言うと新しいメカが必要なのかもしれない。3に関しては高解像度な出力システムがほしい。

登録: 投稿 (Atom)

あわせてよんでみます？

FriendFeed widget

JBL rating

ブログ アーカイブ

アクセス解析

pretty print