何となく半端な日付だけど，今年の誓いを

その前に、振り返り

• 仕事にもう少し気力を充実させて取り組む
  見通しを誤ったりエスカレーションのタイミング/やりかたにしくじったりで多方面に大迷惑をかけてしまった
• ちょっとカラダ絞りたい、標準体重ぐらいまで
  標準体重は知らないけど、30代最軽量になったことがあった。今は1年前と同じぐらいまで戻ってる
• ネタ繰りを頑張る
  K*BUG 研究会に小ネタを出す程度で終ってしまった

そんなわけで、今年も大体同じく

• 仕事にもっと気力を充実させて取り組む
  いろんな意味で勝負していく
• 運動する習慣をつけたい、軽くでもいいから
• ネタ繰りを頑張る
  K*BUG 研究会で自分が喋ってるときに寝る人がいないぐらいにしたい。今年は K*BUG 研究会は広く参加者を募りながらやる予定。

[ひとつまえ]

2011-07-16 追記: CIFS ボリュームには sparsebandle イメージが直接作れないことが色々不具合の原因となってるぽいので、結局 Netatalk の tm option を使うように変えた。

検索したらいっぱい出てくるし、だいたい Mac OS X Hints の記事のとおりなので、ここに書く意味ないんだけどメモ。

Mac OS X 10.6.7(Snow Leopard), で無線の向こうにいる CIFS ボリューム disk1_pt1 にバックアップするとする

1. AFP ボリューム以外でも Time Machine が有効になるように設定を変える

   defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

   2011-06-25 追記: Network Attached Storage (NAS) devices のあたりの注意書きも読んでおくといいかも。平たくいうと、HT4076 の現象が起きやすいみたい。

2. バックアップデータを入れるイメージファイルを作る

   hdiutil create -size 1T -fs HFS+J -volname 'Time Machine Backups' -type SPARSEBUNDLE _HOSTNAME_.sparsebundle

   HFS拡張(ジャーナリング),スパースバンドル・ディスクイメージ ってあたりが大事っぽい. サイズは結局イメージファイルのあるボリュームの空き容量にあわせて適当に変りそう(根拠なし)
   Disk Utility.app から作ってもよい

3. バックアップをとる Mac の Hardware UUID を System Profiler.app などで確認して com.apple.TimeMachine.MachineID.plistに記述して、さっき作成したボリュームイメージにコピーする

   cp ~/Desktop/com.apple.TimeMachine.MachineID.plist _HOSTNAME_.sparsebundle/

   これしないと、バックアップが開始されなかった

4. 作ったイメージファイルをバックアップデータを保持するボリュームにコピーする

   cp -fpr _HOSTNAME_.sparsebundle /Volumes/disk1_pt1/

5. システム環境設定で Time Machine 対象として disk1_pt1 を選ぶ
   あとは待つ

初回バックアップが完了するまでが長いので結構不安

やっとバックアップとるようになったという話でした

そっちも斜め読みじゃと指摘されたの巻

これはたしかに Base-32 と呼ぶと混乱する

3. Base-32 Encoding

Sometimes DNSCurve communicates arbitrary byte strings inside domain names. While the DNS protocol is 8-bit safe for names and labels (except for case-insensitive handling of ASCII alphabetic characters), many tools have trouble with arbitrary characters in domain names, in particular domain registrar software. To cope with this limitation, DNSCurve encodes byte strings using a set of safe alphanumeric characters.

In DNSCurve's base-32 encoding, a byte string is interpreted as a number in little-endian form. Each 5-bit sequence of this number, from least significant to most significant, is encoded as one of the standard "digits" "0123456789bcdfghjklmnpqrstuvwxyz". A final sequence of fewer than 5 bits is zero-extended before encoding. Decoders MUST accept "BCDFGHJKLMNPQRSTUVWXYZ" as synonyms for "bcdfghjklmnpqrstuvwxyz".

For example, the two-byte string with bytes {0x64,0x88} (i.e., {100,136} decimal) is interpreted as the integer 0x8864 (i.e., 34916). The bits 1000100001100100 of this integer are divided into 5-bit parts 00100, 00011, 00010, 00001, which in turn are encoded as "4", "3", "2", "1". The original string is therefore encoded as the string "4321".

N.B., this is not the same encoding as defined in [RFC4648]. In particular, the byte string is chunked into 5-bit sequences differently, and a different alphabet is used. The first allows DNSCurve public keys to be encoded slightly more compactly (see Section 4), and the second helps to further prevent false positives when searching for base-32 encoded strings in domain names.

会社ブログでやっつけネタにしたんだけど、やまやさんとこの見落としてた。

指摘はだいたい正しいんだけど、BASE36ってどこに書かれてるんだろ、BASE32 でしょ。

あと、信頼の「連鎖」は考慮されてるとは思わない。
NSが正しいかどうかわからないのはまったくそのとおり。

DNSCurve では鍵の更新できないんじゃないかってのは、DNSSEC やめる手順ないじゃんみたいに考慮する必要なしとしてるんじゃないかな

使ってみるといいよとは言わないけど、調べる必要なしと捨て置くわけにもいかないかなぁ、といったところ。

何となく半端な日付だけど，今年の誓いを

• 仕事にもう少し気力を充実させて取り組む
• ちょっとカラダ絞りたい、標準体重ぐらいまで
• ネタ繰りを頑張る

[ひとつまえ]

opendkim は 2.0.1 が出てるけど、freebsd ports から入れたのでちょと古い。

諸般の事情で lua 記述の設定ファイルとか、ldap 対応とか手許で動かせてないので古いままです_( )_

最近の状況とか聞いてから、情報量の差もあり心配している
「がんばれ」とか「だいじょうぶ」と声を掛けるのも、なんとなく安易な気がしてできずにいる

とはいえ、今の時点で諸々のリスクについて備えてると聞いているので、そういう体制をとれた「幸運」がそのまま続けばいいとおもう

何となく半端な日付だけど，今年の誓いを
# おっと日付変って12420日目だ :(

• コードとそれを書く他の人たちともともに
• 音楽と昨年同様に取り組む
• 昨年後半アクティビティが低下したので、息切れしないようにする

[ひとつまえ]

第09回 まっちゃ４４５勉強会に行ってきました

講師がたくさんいたこともあり、わたしははじめにイントロみたいな話[PDF](といつもの話[PDF])をしました。
話の内容もほとんど講師間で重複することなく網羅的になったのではないかと思います。

技術的な制約など環境面ではここ数年でたいして変化する要素がないということもあり、「想像し得なかった最新対策」みたいなのはそうそうでないだろう(あぁ、でも標準化の動向とかは新しい話もあるか)とか思ってたりします。
そういう意味で動向をある程度追いかけている人にとって目新しさに欠けたかもしれませんが、色々な対策を並べて特徴を比較する機会はそうそうないと思うので「ちょっと興味がある」ぐらいの方々を上手くヒットできてたらいいなぁという思いです。

個別の演題の感想も。

• 浅見さんの「スキルが高くなくても導入できる」というのは嘘ではないけれどもたとえばログを見る習慣がない人には(ツールが用意されているのだけれども)やっぱりちょっとハードルが高いのではないかと感じた
• 佐藤さんは、6月の静岡のときは概要と各論をお願いしてて詰め込みきれない感があったけれども、今回はトピックをフォーカスして Rgrey, Starpit, taRgrey の違いを整理して伝えられたのではないかと
• 須藤さんは、プレゼンスキルが向上してて、話がおもしろくなってた。わたしが話したいと思いつつ時間その他の都合でやめたことを伝えたわけでもないのに、近い流れの話をされたので気負いすぎたかとちょっと恥ずかしくなった
• いいむらさんは、POPFile Core team で現状一番アクティブに活躍されているということで、参加求むということでした
• 滝澤さんは今度こそは前日までに資料を作ろう！という宣言通りおやつ休憩の前にはしっかり完成されてました :)
• 松田さん、個人でやってる強みが存分にでてて痛快。企業セミナーでは絶対に聞けない話。

``今の枠組みでのメールだけで考えて「届く」とか「受け取らないようにする」とか悩んでるけど、見方変えてみたら?'' みたいなことを言われたのがちょっと印象的。
そっち興味あるけど、ちょっと出遅れちゃった感が。

「face to face 重要」って言われたので、やっぱり広島行きたくなってきた。

# 「悪いことした」わけじゃなくて、アウトプットがそれなりにあって、律儀に言及に対応してるからじゃないかなぁ

see also: b:t:matcha445#9

2009-09-01: 資料へのリンクを追加しました

第09回 まっちゃ４４５勉強会でメールの話をします。

LLTVのちょうど裏番組ですが、こちらはこちらで楽しめるようにネタ繰りをしたいとおもいます。