2012-10

2012-10-01 

危うく9月の日記に追記するところだった。危ない危ない。

本日を持って改正著作権法の一部が施行され、その二大ネガティブ要件として違法ダウンロード刑事罰化とDVDリッピングの違法化(まだ罰則はないが)があるが、これマジでもうどうしようもねえな。とりあえずこの辺の詳しいところは以下の記事が参考になる。

そんでこの違法ダウンロードの刑事罰化だけど、まあこれまともに運用すんのは無理だろ。まずどうやって「違法と知りつつダウンロードした」かを判断するのが問題で、これって相当警察が無茶をしないと立証できないんじゃないの。それこそPCなどの機器を押収して調べでもしない限り無理でしょ。まあ、そんなことせずとも自白を強要するとかで面倒な事抜きにやっちゃいそうだけど。「バカの要求をクソな政治家が実現させてたら、警察が拡大解釈&別件逮捕し放題」という最悪のケースに思えるのだが。今回の一番マズい部分がこれ。

他にも問題はあって、例えば「Lマークの付いてないサイトは違法コンテンツを配信してる」みたいな誤解が広まると、Lマークを取得しないことがディスアドバンテージになるよな。今の時代CDを販売しないでネットでのみ配信してるミュージシャンなんてアマチュアやインディーズには腐るほどいるし、メジャーでも配信メインの流れになりつつあるわけだけど、そういう「Lマークの対象外の形で配信している」けど「配信している物のジャンルがLマークを取得してる業者と被る」ケースはいい迷惑だろう。文化庁の違法ダウンロードの刑事罰化についてのQ&Aの子供向けの説明なんかでは「Lマークが付いてなくても即違法ではない」という説明が抜け落ちているので、この危惧が現実の物となる可能性は十分ある。

なんというか、違法アップローダーをしょっ引く一方でまともなWebでの試聴サービスなど消費者のニーズを満たすという当然のことを延々サボりつづけた挙句の果てに消費者を泥棒呼ばわりしてんだから、音楽業界が衰退すんのは当たり前だ。

2012-10-02 

豚肉の生食の危険性を認識していない飲食店というのは相当ダメだな。とっとと営業停止にでもなった方がいいんじゃないか。

そもそも豚ってヤバい寄生虫や細菌に感染する可能性があって超危険だから、きっちり火を通して食べないと本当に命にかかわる事もありうるわけで、さらに二次感染で本人以外にもその危険が及びうる。規制されてないのは単純に牛のレバ刺しと違って危険性が周知されているだろうという事だったのだろうけど、こうなってくるとこれも規制せざるを得ないだろうなあ。

2012-10-05 

あくまでも俺自身に限った話だが、心身に余裕があるかどうかは自炊しない日が続くかどうかで判断してる。正確には、過去を思い返すとそう判断しても良さそうに思える。

過去にデスマーチプロジェクトに巻き込まれた時は全然料理してなかったし、その後の暇な期間もバーンアウト→ボーアウトのコンボで超無気力、飯なんてコンビニ弁当と松屋でいいじゃんみたいな状態だった。ここで相当健康を損なったと思う。再び料理するようになったのは、仕事変えて新居に移って心機一転してから。

今はまあ概ね自炊しているので、過去を考えれば大分余裕のある生活だろうな。

2012-10-07 

やはりギターやベースのダウンチューニング専用弦はもう少しバリエーションがあってもいい気がする。

俺が知っている限りでのダウンチューニング専用弦のメーカーは大体このぐらい。

D'Addario
ダウンチューニング用の特別なセットをいくつか売っている。ただし、通常のセットに比べると入手はやや難しくWebショップ頼みになるか。あと結構激しいダウンチューニング専用のセットになるので、ドロップD程度だとちょっとキツい。バラ弦で対応しろということか。
Ernie Ball
多分最もよくみかけるダウンチューニング用の弦がここの極太弦。
gallistrings
D-Tunedというダウンチューニング専用シリーズがある。gallistringsを取り扱っている楽器店が石橋楽器のみなこと、結構癖のある弦セットでドロップCに使えそうなセットはあるけどドロップDに最適なのがなかったりするのが難点。
skullstrings
ステンレス製の弦。ドロップD〜BまでできそうなDrop Line、スタンダードCまでできそうなStandard Line、バリトンギターや7弦ギターに使うXtremeLineと取り揃えている。全然見かけないのが難点。
Jim Dunlop
ダウンチューニング用にHeavy Coreシリーズがある他、アーティストモデルとしてKerry KingやZakk Wyldeモデルの弦がある。入手はかなり容易。
Roto Sound
数は少ないがダウンチューニング専用のDarkzoneとMichael Ammotモデルの弦がある。これもあまり見かけない。

他のメーカーも弦のセットとして太いゲージを出しているけど、ダウンチューニング用にカスタマイズしてあるわけではないので、「太いゲージの弦はダウンチューニングにも使える」ぐらいの認識の方がいい気がする。いやそれで特に問題ない事も多いだろうけど、例えばドロップCとかだと弦のバランス取るのが大変で、ライトトップ・ヘヴィボトムみたいなのだと4, 5弦のテンションがキツすぎたりする。なのでダウンチューニング専用のセットを出しているところが理想ではある。

値段的にはErnie Ballが最も安く、続いてJim DunlopとgallistringsのD-Tunedといった感じ。gallistringsは通常のセットの弦は非常に安いのだが。skull stringsはElixer並に高いが、その分長持ちするなら一度試してもいいかな。というかラインナップだけならskull stringsが魅力的なのだが、全然見かけないのがなあ。Webショップでも取り扱っているところは稀。特にXtreme Lineは国内での取扱いは0じゃないかな。

とりあえず今のところ、ミディアムスケールのギターをスタンダードDまで落とす場合はJim DunlopのHeavy Core Heavier、バリトンギターをBにチューニングする場合はgallistringsのD-Tuned D612を張ってる。Ernie Ballは昔使ってたけど、最近は全然使ってない。ってかNot Even Slinkyの3弦が太すぎないか。

というわけで、弦についてはずっと試行錯誤してる。

2012-10-08 

ダウンチューニングに付いてもう少しメモ書き。

ロングスケールのギターを基準に考えると、多くの場合レギュラーチューニングは.009からのスーパーライトか.010からのライトが使われる。仮に全弦2音半下げのスタンダードBに合わせる場合、レギュラーの2弦=スタンダードBの1弦であり、レギュラーの6弦=スタンダードBの5弦となる。となると、スタンダードBに合わせる際の弦のセットは.011〜.013あたりから始まるセットであり、6弦はだいたい.052よりも太いセットになる。

意外と問題になるのが2〜3弦のテンションで、ヘヴィゲージだと2弦が.015で3弦が.019ぐらいなので、1弦の.012に比べると若干テンションが緩い気がする。バランス的には3弦が巻弦で.024ぐらいが最適なのだろうが、ちょっとそれだと演奏性に難がある。3弦がプレーン弦で.024のNot Even Slinkyでもちょっとやりすぎな気がする事、巻弦とプレーン弦ではプレーン弦の方が太さに応じて素直にテンションが上がる事を考えると、もう少し3弦が細い方が良さそう。

などと考えると、スタンダードBはgallistringsのD-TunedのDB11 Baritone Guitarが最適に思える。若干低音弦が太く感じるが、まあ巻弦は見た目ほどテンションが上がっていかないのでこんなものかもしれない。しかしこれは国内ではどこでも取り扱っていないっぽい。

あれか、もうバラ弦買ってカスタムセットを作るしかないのか? ああ面倒くせえ。

2012-10-10 

bitbucketのIssue Trackerがまたしても改悪された。これまではCreoleで書けていた所が、全部Markdownに変更になった。Creoleに戻す方法は現時点では存在せず、過去のIssueを更新するとそれらはMarkdownとして再解釈され、結果として極めて残念な結果になる。ふざけんな馬鹿野郎。

こういう非互換性のある変更を行う際は過去のデータを変換するか(余程の無能でない限り構文の変換はできるだろ)、複数の構文を選べるようにするか(一番常識的)、あるいは最悪の自体に備えてポータビリティを考慮した何らかの形式で元データをダウンロードできるようにするかのどれかだろう。そしてbitbucketはどれも持ち合わせていない。CreoleとMarkdown両方サポートという意見は先月行われたらしい投票で却下されたようだ。(というか「両方サポートしてくれ」という意見が無視されてた気がする。)

ちなみに俺はMarkdown記法は大嫌いで、その理由はコードブロック(HTMLのpre)の記法がタブ1つか空白4つでインデントという大馬鹿な代物だから。もうこの一点だけでMarkdownはダメだ。Creoleのように{{{

というわけでどうしたもんかなあと。俺も檜山さんも他はともかくコードブロック記法については耐えられないので、最悪Issue Trackerを移すことになるだろう。もっとも既にIssueは数百件たまってるし、仮にスクレイピングでもしてそれらを手元に持ってきた所で、じゃあどこのIssue Trackerを使うのかという問題がある。実に困った。

2012-10-11 

在宅での仕事は体調が悪い時に即座に休めるのが俺の感じている最大の利点で、これはもう何事にも換え難い。一番これを痛感したのはヘルニアの手術をした後で、腰を労るために立って仕事が出きるよう、机というかモニタを置くための台を自前で作って、それで1年以上は仕事をしていたのだった。

仕事をする能力はトータルではあるけど、会社勤めで周囲と時間や環境を合わせるのが難しいという人には、在宅ワークは割と魅力的な選択肢だろう。できる職種がある程度限られるし、個人の合う合わないという問題もあるにしても。

在宅ワークで懸念事項にあがるサボリに付いては、まあサボって成果が出なかったら即座にバレるからそれはあまり長期的には心配しなくていいだろう。それが常に問題になるのはちょっと進捗のチェック方法などに問題ありすぎだ。それよりも長期的な観点からは「家で仕事が出来るからついついオーバーワーク」という事の方が問題な気がする。仕事をしなかったのは一目瞭然な事が多いだろうけど、仕事のし過ぎはわからん事が多いだろうからな。仕事の時間が少なくて成果が出てるなら、それはそれでWin-Winの関係なのでまあいいだろう。

2012-10-12 

判決によると、女性はシステム移行などを担当し、2007年2月の時間外労働が約127時間に上った。3月に仕事上のミスなどが原因で自殺未遂し、約1か月間休養した。その後復職したが、深夜残業など過酷な勤務が続き、5日後、東京出張中に致死性不整脈で死亡。福岡中央労基署は09年、労災認定した。

自殺未遂から復職した直後に深夜残業させるというのは殺人と扱ってもいいのではないか? まともな会社なら、本人と面談しつつ復職のタイミングを決めて、復職後も激務になるような現場には向かわせないだろう。もしもそのような現場が無かったとしたら、それはそれで経営陣や現場のマネジメントがかなりダメなんじゃないか。自転車操業の零細企業ならともかくさ。

いやでも零細企業の方が万が一死なれたときの損害賠償金がヤバいということで、ギリギリのところで死なないようにするかもしれない。仮に会社の存続のために従業員に無茶をさせねばならんとしても、死なれたら死なれたで会社が傾くわけでな。

今回の損害賠償金の6800万円というのは、死ぬほど大雑把に計算すると月あたりの単価68万円のエンジニア100人を1ヶ月派遣したときの売上で、まあ当然だが本人への給与や諸経費を差っ引くと事業利益は1ヶ月で数百万円台か? とまあこういう見積りをしたうえでアドバンストラフィックシステムズの売上高や社員数を見ると、到底会社が傾くには程遠いと思われる。

仮に従業員が数人死んで賠償金を払うことになっても、他の連中が耐えていればその分の売上で損害賠償を支払っても安いみたいな会社があるとして、どうやってそういう会社から人を使い潰すインセンティブを奪うか。過労死などの労災の認定件数と企業規模に比例したペナルティみたいなのは果たして有効になるか?

2012-10-14 

手持ちのギターのうち1本がすげえボロボロなので、ギターのリフィニッシュに挑戦してみた。というか、やってる最中。これは相当面倒なので、挫折する可能性が十分ある。いや、これに比べたら前にやったフレットレスバリトンへの改造なんて全然楽。

この作業ができるのは休日ぐらいだろうから、まあ完成までは相当かかるのではないかと。

2012-10-18 

リピートアフターミー。「IPアドレスが判明すれば、捜査は半分終わったようなものだと思っていた。」

ウィルスなどを利用したという可能性を一切想定せずに誤認逮捕し、さらに自白を強要したとは恐れ入る。前者も問題だが、後者はさらに大問題。一体どれだけの冤罪が発生しているのか見当も付かん。どんなに捜査体制を見直したところで取調べの可視化などの抜本的な対策を取らん限り、似たような事例は続くだろうな。

で、こんな薄ら馬鹿連中がサイバー犯罪の捜査をしている状態で違法ダウンロード刑事罰化ねえ。一体なんの冗談だ。

2012-10-19 

bitbucketのIssue Trackerが俺と檜山さん的に大変不便に改悪されてしまってどうしたもんかと思っていたので、試しにTracをインストールしてみた。

以下はハマったところ。あとでちゃんとまとめるかも。

で、今回やりたかったことの一つに「各Issueより登録、Issueの内容の更新、コメントのうちもっとも新しい日付をチョイスしてそれでソート」という、要するに何か変更のあったIssueを上に持ってくるというのがあったのだが、これはTracのデフォルトのクエリー一覧にはない。俺としては一番これが使用頻度高いくて前まではbitbucketもこれだったんだがなあ。

それでこれは以下のようなクエリーにすればTracでも可能。とりあえずSQLite版。一応これでいけるはず。

SELECT DISTINCT p.value AS __color__,
   id AS ticket, summary, component, version, milestone, t.type AS type, 
   owner, status,
   t.time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  LEFT JOIN ticket_change c ON c.ticket = t.id
  WHERE status <> 'closed'
  ORDER BY max(ifnull(c.time, t.changetime), t.changetime, t.time) DESC

bitbucketとの連携は、以前にも紹介した下記のスクリプトを改造すればいける。(簡単なんでソースは載せない。面倒だし。)

ちなみにTracにした理由は、TracのWiki記法がcreoleとmoinmoinの折衷案みたいな感じで、bitbucketのWiki(及びこれまでのIssue Tracker)の記法に近いから。というか、ソースコードやコンソールの出力をそのままpreとして張り付けたいのにインデントを付けさせられるのがバカらしいので、とにかくそうでない記法なら候補に上がるという感じ。正直この点でMarkdownって特にformから入力される事の多いWebアプリじゃ致命的だと思うんだが。でもかなり広く使われてるのは事実なんだよなあ。

一応textileはこの点はクリアしてるが、それが<pre></pre>で囲めというのはなあ。他の部分も全体的にどうにも気に食わん。それさえなければRedmineを試してみる気になれたのだが。


追記: bitbucketでもバックスラッシュ三つによるpre記法の拡張がサポートされてた。なのでしばらくはbitbucketのIssue Trackerを使いつづけることにする。でもIssueなどの機能の仕様変更についてbitbucketの方針は一切信用していないので、次何かあったらIssue Trackerについては乗り換える公算が高い。

2012-10-20 

「アクセスしてから2秒で掲示板に書き込み」という不自然なログが残っているのにそれをガン無視して逮捕に踏み切ったとは恐れ入る。そしてこの記事から読み取れる範囲では、捜査員による誘導の有無に付いてはもう真っ黒なんだが、それでもなお認めないとはねえ。


そういや昔、チャットに人工無能が紛れ込んでいるかどうかを書き込みの速度で見抜くみたいなのが俺の周囲であったな。その時は人工無能以外の参加者が電波な事を書き込みまくっていて文面からは大半が人間に思えなかったのだが、結局1人だけあまりに早く発言してる奴がいて、そいつが人工無能だとバレたという。

2012-10-23 

檜山さんによるCatyの紹介動画。簡単なパイプライン処理の実演だけど、雰囲気は伝わるかな。


これは難しい問題だ。「直ちに本震に繋がる証拠はない」のに「でも本震が起こった」としても仕方がないので、じゃあ常に余震が起こったら逃げ出すべきかというと、そんなことしていたら社会が麻痺しかねない。なので即座に逃げ出すか、ある程度逃げる準備をしておくか、それとも普段通りの日常を過ごすか、そういったところの判断は最終的に個々人に委ねられるところがある。

でも「安全宣言」が出されちゃったら何も警戒しない人が相当増えるだろうから、やっぱこれは科学者の問題と言うより、政府の発表の仕方の問題だなあ。

2012-10-25 

kindlegenを使ってゴニョゴニョやっているのだが(理由は秘密)、一個わけわかんない挙動があったのでメモ代わりに書いておく。

ダミーファイルなどの目的で空のファイルを置いておくことはよくあることなので、こういう挙動はちょっと迷惑。

2012-10-26 

コメント欄で始めてAPIがあることを知った。ってかIssue TrackerのヘルプからAPIリファレンスに飛べたっけ? 俺が見たときはなかったような。(だからすげえ怒った。) まあ、APIがあっても大変な手間ではあるのでやはり怒っているが。大激怒が激怒に変わったぐらいで、やっぱもうbitbucketはIssue Trackerをはじめリポジトリ以外のサービス部分では何一つ信用してない。だってこんな互換性を盛大にぶっ壊す変更をしてるんだから、また何かやらかすと思っていいだろ。細かい改悪は前から続いていたわけだし。というか何で自動変換機能を付けてくれなかったんだろう。

ついでにそのWiki記法の変換は単に知的作業ではないのでタルかったり、両者の一方が対応していない記法への変換が原理的に無理なだけで、そんなに難しいわけではない。習作だとか適当に書き捨てたとかでないかぎり、普通は一旦中間データに落としてからHTMLにしているはずで、最後の出力部分を別のWiki記法にすりゃある程度は自動でいけるだろ。

というわけでもしかしたら過去のIssueを全部変換することになるかもしれないので、とりあえず俺のcreoleライブラリで実装を始めることにした。

src/creole/util/markdown.pyを参照。まだ大雑把で未完成にも程があるが、まあ目処は立っている。まったくもって楽しい作業ではないが、まあ仕方がない。


ぶっちゃけ事前に連絡があって、尚且つその時にAPIの存在とかを教えてくれていれば、ここまで怒り呆れはしなかったと思う。予告なしに変更されて、それで混乱しつつ調べたらとんでもないことになってるのを知ったという、それが不味かったんだな。

いや、どっちにしろふざけんなとは思っただろうけど。結局のところ過去に積み上げてきたデータと互換性がないのが大問題なわけだから。

google groupsで行われていたディスカッションでは割と今回の変更は歓迎ムードだったんだけど、あそこにいた連中は一貫性とか互換性とかそのディスカッションを知らないユーザが直面するトラブルとかについて、ほんの少しでも考えなかったのだろうか。まあ、考える頭があったらこんな事にはなってないんだろうけど。

2012-10-30 

bitbucketの件は檜山さんのところにAtlassianの方がコメントしているので、まあ基本はその成り行きを見守るかといったところで、過去のデータの変換が検討されているのは、まあ嬉しいニュースではある。万が一の事を考えて、俺の方でもデータの変換もしくはエクスポートの準備はしておくが。

既にIssueの中で古いCreole記法と新しいMarkdown記法が混在しているので、その辺の判別コードを書くのも面倒っちゃ面倒。結局俺のライブラリでもMarkdown記法に対応し、CreoleとMarkdown両方に通して結果を判定みたいな事になりそう。となるとIssueのエクスポートか? 妥協案として、過去のIssueを編集するときのためにCreole->Markdownの変換プログラムをWeb上に置いておくというのがあるか。


RGX-A2のペグがぶっ壊れてしばらく休眠状態だったのだが、ようやく修理できた。専用ペグなので楽器店でパーツ取り寄せかなあと思っていたのだが、店員にペグの破損部分がプラスチック製のワッシャーだと言ったら、「ホームセンターで売ってる奴で代用できると思います」とのこと。

そんで試しにプラスチック製の座金(10数個入って150円)を買ってきてやってみたのだが、拍子抜けするぐらい上手くいった。他のペグよりもワッシャーが一回り大きいが、透明なのでそんな目立たないというか、誰もペグのワッシャーなんて凝視しねえよ。おかげで修理代がほぼ丸々浮いた。