2009年1月30日金曜日

今日の読書

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
「データベースリファクタリング」に目を通した。

Peasonのサイト。

やっぱりschema(DDL)の管理がテキスト・コンベンションベースなのが気に入らない。ここは構成管理ツールに突っ込む一手だろう。問題はschemaの変更とそれへのデータの追従、とくにデータがでかい場合が問題なのではないだろうか。あと変更量に比してdown timeが十分にとれないときとか。

schemaをいじる仕組み自体が変更を前提に設計されていないのじゃないかと個人的には思う。
serializeの関係で保持しているdataがmultiversionなdbはあるけど、schemaがmutliversionで、かつrollbackを認めるようなDBはあるんだろうか?

sqliteのファイルをgitに突っ込んですむレベルならいいのですが・・・。でもね~dataのsetupをsetUpとtearDownでやると遅いからなぁ・・・。あとsqlhub.processConnection = connectionForURI('sqlite:/:memory:')でやれば軽いけど今度は本番と違うdbになってしまうのと、本番のschemaが正しく書き換わっていることを検証する面倒がある。

sqlobjectのようなO/R mapperだとschemaとclassのsyncが問題なの。最初に作って終わりじゃないから。

>>> Person.createTable()

createじゃなくてsyncしたいんだよね。

2009年1月27日火曜日

サーバ整備完了

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
バックアップ、OSのupdate(2.6.28.2へ)、内部のダスター吹き。
前開けたのが3ヶ月くらい前だったので、かなり埃がたまっていた。目の細かいメッシュパネルをインテークにつけておくと、埃のたまり方がだいぶ違うようだ。開発機はつけていないので、埃の塊が転がっていた。

今回は先にmac miniのvmwareの上で動いているDNS serverとimageserverにリクエストを流すように切り替えてから電源を落としたのでサービス停止はなかったはず。(Pageは一部見れなかったかもしれないが、nameは引けていたはず。)

2009年1月23日金曜日

PCR07終了

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
悪かった点:

  • せっかく用意したemobileもputtyのフォントがプロジェクタ上で死亡&すぐにfontを変更できなかった間抜けさのおかげで無駄に。

  • atsさんの狙いとずれていた。もっと即効成分配合が望まれていた模様。作る側の話というより、使う側としての話にすべきだった。マフラーぴったりマシンな仕上がり。

  • OOo impressはこの用途にはまったく向いていない。swfに変換したら案外イイかも。

  • 発表している人が時々読み込み中になった。

  • 発表している人が運動不足で足をつりそうになっていた

  • 会場キャパ限界。うれしい悲鳴ではありますが。



よかった点:

  • atsさんのフォローもあり、心理的には楽にこなせた。過去に話す機会があったときは固まってアガるという素敵なコンボが連続してはいるというのはざらだった。

  • 2.5, 3.0など各種パッケージを入れておいたので、トラブル時に二の矢がつげた。

  • vimのデフォルトテーマカラーが意外にもプロジェクタに向いていた。画面では結構しんどい

  • プロジェクタの不具合への対応がすばらしかった

  • 会場が生声で声が通る環境なのがよかった。マイク持ちながらは大変すぎ。

  • 人がいっぱいきていた。audienceの幅が広かった。女性の参加者がいらっしゃった点

google transit

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
そんな乗り換えする人いません。

なんだろうねぇ。

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
ほしいときにはなくて、結果が出るときにはあるという、間の悪さ
#自分で訳して出してしまえ、という突っ込みはナシで。

What's New In Python 3.0 日本語訳

2008/12/03にリリースされたPython3.0の新機能について,Python 2.6と比較した記事「What's New In Python 3.0」の日本語訳がリリースされています.このドキュメントはテキストとスクリプト言語に関する総合的なメーリングリストである「TS Network」の有志によって作成されたものです.


今日しゃべります。中身はこちら

2009年1月22日木曜日

call/cc系?

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
protothreads紹介noteから
関数の先頭には必ずPT_BEGINを書き、最後にはPT_ENDを書きます。 待ちに入りたい場合には、PT_WAIT_UNTILを書きます。

Cのマクロで実装されているので機能に制限がありますが、用途を考えるとマクロで実装されていることが最大のメリットでしょう。

2009年1月20日火曜日

GPU

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

gnubgのホスティングするなら魅力的なパワーである。1400台はどーやっても管理できないからね。もちろん移植コストが発生するが・・・。

CPU以外に並列どの高い計算をやらせるというアイディアは別段あたらしいわけではない。x87の話でなくともGRAPEとかあるし。

2009年1月19日月曜日

name mangling

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
どう説明するのがいいのかしら?Private Variablesとかをわかるように説明しないといけないのか。継承側で__closedをインスタンスごとに持たせるのかどうかは継承側しだい。でもそこでの代入で親クラスのcls.__closedを書き換えちゃまずそうだよね。兄弟間で親を書き換えてコンフリクトがおこるのでは困る。

説明したいコードはこれ。

__closed = False

def close(self) -> None:
"""Flush and close the IO object.

This method has no effect if the file is already closed.
"""
if not self.__closed:
try:
self.flush()
except IOError:
pass # If flush() fails, just give up
self.__closed = True


リンク先のドキュメントを確認していて、こんなくだりを発見。

(Buglet: derivation of a class with the same name as the base class makes use of private variables of the base class possible.)

あ・・・。

import hoge

class X(hoge.X):
....

なコード書いてた。manglingの観点からはよくないのだな。
_ + "親クラスの名前" + _ + "自分の名前" + __ + "変数名"
とかにしてくれればいいのに。


import sys
assert sys.version_info[0] == 2

class A(object):
__a = 1
def foo(self):
try:
exec 'print self._A__a'
except AttributeError, e:
print e
def bar(self):
try:
exec 'print self.__a'
except AttributeError, e:
print e
a = A()
a.foo()
a.bar()

これを実行して見ると、classが生成されたときに代入だけでなくすべての参照が__aから_A__aに書き換わってしまい、それはmethodの中のアクセスも例外じゃない。文字列で持っていれば書き換わらないのでexecで動的に後からアクセスするとattributeが発見できず、エラーになる。

最初にもどると、__closeの意図が理解できない。継承したクラスでcloseをかならずoverrideしなきゃいけないように思える。気のせいだろうか??しかも__closeにTrueを代入しているコードが見当たらないので、if not ...のthen節は実行されることが無い気がする。

2009年1月14日水曜日

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
セキュリティ専門家が「最も恐ろしいプログラミング・エラー・トップ25」を発表とあったので、ソースをざっくり呼んでみることにした。

2009 CWE/SANS Top 25 Most Dangerous Programming Errors


The Top 25 is organized into three high-level categories that contain multiple CWE entries.

Insecure Interaction Between Components


コンポーネント間の危険なやり取り。

These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.


  • CWE-20: Improper Input Validation, 不適切な入力の検証

  • CWE-116: Improper Encoding or Escaping of Output, 出力の不適切なエンコード・コード

  • CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')

  • CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')

  • CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')

  • CWE-319: Cleartext Transmission of Sensitive Information, 平文での機密情報・個人情報の送受信

  • CWE-352: Cross-Site Request Forgery (CSRF)

  • CWE-362: Race Condition, 競合

  • CWE-209: Error Message Information Leak エラーメッセージからの情報漏れ。(「ユーザ名もしくはパスワードが違います。」ではなく「パスワードが違います。」と答えてユーザ名が存在することをもらしてしまう)



Risky Resource Management


危険なリソース管理。

The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.
システム上重要なリソースの生成、使用、転送、破棄・解放が不適切に行われることによる脆弱性。


  • CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer、メモリバッファの領域内に操作を限定できないことによる脆弱性

  • CWE-642: External Control of Critical State Data、競合状態のデータを外から操作可能できてしまうことによる脆弱性

  • CWE-73: External Control of File Name or Path、外部からファイル名もしくはパスを操作できてしまう脆弱性

  • CWE-426: Untrusted Search Path、信頼できない探索パス。(おそらく../../../etc/passedとか。)

  • CWE-94: Failure to Control Generation of Code (aka 'Code Injection')、実行コードの生成の管理の失敗

  • CWE-494: Download of Code Without Integrity Check、検証なしでの実行コードダウンロード

  • CWE-404: Improper Resource Shutdown or Release、不適切なリソース解放

  • CWE-665: Improper Initialization、不適切な初期化

  • CWE-682: Incorrect Calculation 、正しくない計算



Porous Defenses



The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.


  • CWE-285: Improper Access Control (Authorization)、不正な権限管理

  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm、正しくない暗号アルゴリズムの使用

  • CWE-259: Hard-Coded Password、パスワードをプログラムに埋め込む

  • CWE-732: Insecure Permission Assignment for Critical Resource、重要な資源へのアクセス権限の不適切な許可の付与

  • CWE-330: Use of Insufficiently Random Values、ランダム性の不足した値の使用

  • CWE-250: Execution with Unnecessary Privileges、不要に高い権限での実行。

  • CWE-602: Client-Side Enforcement of Server-Side Security。サーバ側の権限をクラアントサイドでの認証で行う

2009年1月10日土曜日

300件目

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
300件目のエントリーのようだ。くしくもpython3000がらみの作業中である。

source codeがたくさん出てくるpresentationって書きづらい。すくなくともimpressは適切な道具じゃない。wikiのようなformatエンジンがあればなぁ。。。tracのpageで作ってしまうかな。あれだとcode簡単に貼れるし。しかしhtmlじゃだめだなぁ。

magicpointはうまくpackageが入らない時点であきらめたし。贅沢を言って、pythonのcode readingに特化するならipythonを埋め込みできて、指定のpackageがimportされてたりstmtが実行済み状態でpresentationのpageが出てくると快適なのだが。そもそもにアプリのwindow切り替えが嫌だ。やるのもだるいし、見ているほうも趣味丸出しのDesktopを見せ付けられてうんざりだ。

スクロールなし全画面表示前提のレイアウトをするのにhtmlは不適切な道具だし・・・あれは縦スクロールがあることが大前提だ。

wikiっぽい文法は適当にやるとして、実装にはpygameあたりでも使うのかな?キーとか画面の処理が楽なはず。探せばありそうだが。ほしいのはtitle, itemize, image, shell(code), note(何をしゃべるのかを文章化したもの。script)だけなんですけどね。outputのformatがpdfとhtmlとかも出せるとうれしい。だからparse+中間表現+backendみたいなありがち構成になるのだろうが。

2009年1月8日木曜日

git on win

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
cygwinする以外にもmsygitという選択肢があるらしい。使ってみるです。
設定周りもunixで使うときのそれとかわらないようです。gitを動かすのに必要な下回りを実装するというスタイルなのでしょう。

いまだにCentOSで日本語を使わない設定(VNC経由なので入力がローカルのwinの入力との兼ね合いでわけがわからない)ですが、emobileがCentOSで使えるなら、HPのNotePCをCentOSにするかもしれません。FreeBSDもあるかも。OOoとemobileが使えることが条件ですね。

2009年1月7日水曜日

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
自分のへやにマシンを置いていると、冬場は部屋があったかくていいのですが、夏はいや過ぎです。

DCはどうなっているのか記事がありました。データセンター省電力化の実像

冷却機が33%をしめていますが、これってどうなんでしょうね。2:1がいいとかどーたらこーたら書いていますが、逆カルノーサイクルで考えたときにTHとTCがどうなんだか。ざっくり300K, 290Kとかでいいのかな?

(COP)R : 冷凍サイクルの理論成績係数

(COP)R = QC / W = TC / (TH - TC)
= 290/(300-290) = 29

これだけみると、2:1とかじゃなくて、20:1とかでもよさそうだ
。この辺は一般のクーラーの性能を引っ張ってこないといけないだろうし、そもそもに冷やしたいものはマシンでそれらの温度は室温と同じじゃない。もーちょっとマシなモデルとしては、computer表面の温度とDCの室温と外気温で考えるべきでしょう。表面の温度と外気温でサイクルが組めない時点で効率が下がっている気もしますが・・・液冷にしたいのもこの辺が理由なんだろうなぁ。詳しい人いないのかな?

約20年前のクーラーと現在のエアコンでは本当に消費電力が違うのでしょうか?なる質問がpostされていて、COPは6とからしい。20はさすがにないようだ。でもそれにしても1:2ってひどくないか?DCは一般家庭と違って密閉できるわけだし、空調システムも大きい分効率がよくていいはずだ。

ちなみに家庭で冷却が必要なものは冷蔵庫のほかには、海水魚の水槽というものがある。まあ、リッチな人しかしない趣味です(水槽用ペルチェ式クーラー自作(V1.0))。しかし、冷蔵庫は中に熱源がないしなぁ・・・。水槽のほうがモデル的には近いだろう。水槽はライトというかなり強烈な熱源がある。冷蔵庫は開けしめのときに入った熱や、新しく入ったものが持ってきた熱を外に「汲み出し」てあとは熱を遮断すればいいが、DCや水槽は、かなり強力なフローが存在する。
そういう意味で、熱に関してDCはひょっとしたら冷凍倉庫よりも鉄工所のほうが近いのかもしれない。