2014-01

2014-01-01 

ファッキンニューイヤー。大晦日は電王戦リベンジマッチを見た後実家に戻り、ボクシング見たりなんだりして過ごしてた。ボクシングは2戦ともすげえ試合だったな。

そんでまあ、電王戦リベンジマッチは船江さんが今回はさらに研究を深めて盤石の状態で挑んだようで、結果というか棋譜だけ見れば概ねツツカナを圧倒しての勝利だったわけだが、それまでの研究では勝ったり負けたりだったとも語っているし、実際に何ヶ所か危ない方に倒れそうな場面もあった。例えば53手目で船江さんが「6二歩」と指した直後にツツカナが「9九と」からが結構怖いかなという見方も多かったと記憶しているし、その後もちょっと間違えるとマズい場面は解説でも出てきた。まあ、その辺含めて読みきってた船江さんすげえって事で。(この辺は俺の棋力じゃ詳細の解説は手に余るのでパスな。)

こうなってくると第3回電王戦が俄然気になる。統一ハードウェア、事前のソフト貸与、また対局には貸与したバージョンを使うというソフト側が結構不利なルールに見えるが、これは逆に各ソフトに同一の制限を課す事でハードウェア&開発リソースの調達力勝負を避けるという面では各ソフトウェアの開発者にとって平等ともいえる。極端な話、ハードウェア全部自腹vs企業のバックアップありじゃ有利不利があり過ぎるわけだし。

多分この辺はまだソフトウェアと人間が拮抗気味だからこそ悩ましいところなんじゃないかという気がする。そういう意味でも、今が多分コンピュータvs人間の将棋がかなり面白い時期に思える。

2014-01-04 

Catyを使った案件が落ち着いたので久しぶりに別の仕事をすることになったのだが(Catyプロジェクトが終了したわけじゃないので念のため)、そこでまあJavaFX使うかもみたいに言われているのでちょこちょこと勉強しているのだが。随分と触れてない間に大きく変わっているというか、JavaFXって昔はスクリプト使ってGUI構築みたいな事をやってはずだけど、2.0からは普通のJava APIとして構築する事になってんのな。

しかしGUIプログラミングは随分と久しぶりだ。大学時代にささやかなゲーム作ったり、前の会社で一時期CやC#でちょいと作っていたりはしたが、ここ4年ぐらいはプログラミング言語処理系を作ったり電子書籍関連のあれやこれやをやったりで、GUIプログラミングからは相当遠ざかっていたからなあ。まあ、まったくの未経験というわけでもないのでさっさと勘を取り戻す事にする。

2014-01-05 

未だにBitcoinに夢見てる人たちにどう説明すっかなあと思っていたが、クルーグマンの子守協同組合の話から説明しようというアドバイスをもらった。確かにこの話は経済活動の安定化と通貨について極めてわかりやすいものだ。

というか考えてみりゃ、暗号通貨って有力な奴一個だけある状態はまさにクーポンを発行してない子守共同組合の状態で、有力な競合が複数出現する状態はクーポンが乱立して機能してない状態だから、上記の説明+αでいいんだな。

あと暗号通貨はやはり仮想通貨というよりは仮想貴金属で、実際の貴金属から稀少性以外の要素を剥ぎ取って、

という条件を課した思考実験に過ぎないのだろうな。まあ、結局最初の条件は無限のデフレを、最後の奴は暗号通貨自体の購買力の減少を意味しているということで、どっちにも振れる上に誰もそれを制御できないので、そんなもんで安定した経済活動できないよねと。

2014-01-08 

さて新しい現場に入って3日目だが、まあなんというか久しぶりのSIerの仕事がこれかよという規模のプロジェクトで、例によってExcel方眼紙がちらほらあるが、まあJava8が使えるようだということで我慢しておく。いや本当にJava8は過去のジェネリクスすらなかった頃に比べると見違えるどころか別言語レベルで良くなったよな。(過去がゴミクズだったともいえるが。)

そんでまあさっそく既にできてるコードを読んで手伝っているのだが、プロジェクトがプロジェクトだけに有能な人が集められているようで、そういう面では苦労はしなくて良さそうかな。いや本当に過去のあれとか突然逃亡した仲間の尻拭いで頭抱えたりしてたからな。

というわけでIT業界残酷物語の続編を期待している不埒な連中はいい加減にしてくれ、マジで。あれ読んでる方は面白いかもしれんが、書いてるこっちは肉体と精神を削る日々だったんだからな。

2014-01-09 

どこぞにJava8+JavaFXを使っている奴はおらんのかと思ったが、そういやまだ正式リリースされてないんだった。でもJavaFX自体殆ど誰も使ってないんじゃないかこれ。

というわけで上記の環境のちょっとしたTipsをメモ書き代わりに書いておく。まずJavaFXは描画スレッドがアプリケーションスレッドとは別に走るのだが、描画スレッドのパフォーマンスログはjavaの起動オプションに-Djavafx.pulseLogger=trueを指定することで取得できる。ログの内容はなんかどこにもドキュメントがないのがあれだが、まあ大体理解できるだろう。

ただこれコンソールに出力される関係上ちょっと使いにくいし、例えば各ウィンドウ(というかScene)毎の描画時間を測定したい場合はちょっと困る。そんでこれは実際に正しいやり方なのかイマイチ不明だが、上記のpulseLoggerの結果と突き合わせておかしくはなさそうに見えたのが次のやり方。

PerformanceTracker pt = PerformanceTracker.getSceneTracker(scene); // 測定対象のScene
pt.setOnRenderedFrameTask(() -> {
  // 適当なロギング処理
  :
  :
});
:
:
PerformanceTracker.releaseSceneTracker(scene); //どっか適当なところで

setOnRenderedFrameTaskが多分描画が終わった直後あたりに呼ばれるので、そこで実行時間の測定とかをすればよさげ。ただし描画スレッドで各Sceneは直列に描画されて行くので、描画にかかった時間を上記のsetOnRenderedFrameTaskに入った時間-描画スレッドに入る前の時間で計算すると、例えばScene1, Scene2, Scene3がこの順で描画された場合、Scene3で取れる時間は3つのSceneすべての描画にかかった時間になる。この点にだけ注意。

2014-01-11 

一昨日書いた奴の補足。PerformanceTrackerはSceneオブジェクトに対して1:1でしか対応付けられない。PerformanceTracker.getSceneTrackerは同一のSceneに対して何度でも呼べるが、releaseSceneTrackerで開放されるまでは同一のPerformanceTrackerオブジェクトを返しつづける。そのため、setOnRenderedFrameTaskで設定するRunnerで必要なロギングをすべて行う必要があるが、これは例えば「バックグラウンドで動いているスレッドと同期してのUIの描画」「ユーザーの入力に伴う描画」などが複数種類あってそれぞれ個別にログを取りたい場合などに困る。

このような場合はsetOnRenderedFrameTaskに渡すRunnerを各種のロギング処理を受け付けるデーモンのように作っておくのが良いようだ。ざっくりとしたコンセプトを書くと(細かいところは補って読んで)、

public interface LoggingTask {
  public void log();
}

public class TaskQueue implements Runnable {
  SomeList<LoggingTask> loggingQeue;
  
  public void add(LoggingTask t) {
    loggingQeue.add(t);
  }
  
  public void run() {
    // キューから値を取り出してlog()を呼び出していく
  }
}

public class TrackerFacade {
  public void setLogger(Stage stage, LoggingTask task) {
    PerformanceTracker pt = PerformanceTracker.getSceneTracker(stage.getScene());
    if (pt.getOnRenderedFrameTask() != null) {
      TaskQueue tq = new TaskQueue();
      tq.add(task);
      pt.setOnRenderedFrameTask(tq);
    } else {
      ((TaskQueue) pt.getOnRenderedFrameTask()).add(task);
    }
  }
}

大体こんな感じのクラスとインターフェースを用意しておき、使う方では

Stage stage = ...;
TrackerFacade tf = ...;
tf.setLogger(stage, () -> {...});

こんな感じで設定する。一応PulseLoggerの結果を突き合わせてみたが、この方法でまずまずのログは取れる模様。

2014-01-14 

連休中はずっと既に演奏だけ録ってあった曲に歌入れの作業をしていたのだが、やっぱ俺はヴォーカルやらねえ方がいいのかなと思わなくもない。まあ、ヴォーカルを頼める知人なんぞいないので自力でやるしかないのだが。

それで自分の声とか、あるいはYoutubeで"How to growl"みたいな動画を上げてる人の声とかのスペクトラムを取ってみたりして軽く研究していたのだが、意外とドスの効いたグロウルでもそんなに低域にシフトしているわけではない。グロウルは基本的に様々な周波数成分の混在した歪んだ声なので、絶対的な声の低さはそれほど重要ではないのかもしれん。というか思いっきり低くするとガテラルになるか。Cannibal Corpse〜Six Feet UnderのChris Barnesとかその辺の草分けだが、あれ人間の声とは思えんからなあ。

2014-01-17 

今の仕事では実に久しぶりにGUIアプリケーションの作業をしていて、まだ技術調査を兼ねたプロトタイプなので細かいアーキテクチャは考えていないが、今はどうするのが主流なのかね。俺としてはMVPモデルの派生のうちPassive Viewが一番作りやすいと思う。

Passive Viewの利点はとにかく単純であるのが大きい。外部との入出力インターフェースはViewである。Viewを操作するならPresenterである。他は全部Modelである。場合によってはApplication Controllerのような物でPresenterを取りまとめるのも良い。ViewはModelに働きかけてはいけないし、Modelは他の要素に依存してはいけないし、Application Controllerも他のすべてと疎結合であるべきである。これに従えば、特にかなりPresenterのテスタビリティは上がるはずだ。(Viewの差し替えのメカニズムは必要だが、これは単なるTest Doubleの話になる。) Supervisor Controllerなども聞かれるが、Passive Viewで不都合がないならより単純な方を採用すべきと俺は考える。

ところでこの手のアーキテクチャではM/V/Pなどの水平方向の分割は話題になるが、Presenter同士を疎にするような垂直方向の分割についてはあまり聞かない。本来なら機能毎の垂直の分割がまずあってその中で水平方向の分割があるべきで、その垂直方向の分割を厳密にすると先のようなPassive View+Application Controllerのようなアイディアに行き着くと思う。というか多くのアーキテクチャの説明図ではそれらの役者が1つずつしか登場しないことが多いが、現実のアプリケーションを考えると複数のModel-View-Presenterの塊があってそれらがどうやり取りをするのかというところが問題になるべきだろうに。

なんか抽象的な話に終始してしまったが、まあ極めて大雑把にはこんな事を考えてはいる。

2014-01-21 

とある事情でInkscapeを使ってみたのだが、まず背景色の変え方がわからなくて頭を抱えた。試行錯誤してもわからなかったのでWebで調べたが(参考にしたページとのバージョン違いでまた混乱したが)、ウィンドウの右下の矢印をクリックすると出てくる「ドキュメントの設定」から背景色とその透明度を変える事ができることが判明。わかるか。なんつーか、ツールを使う上で基本的な設定項目が妙なところに隠されてるUIってどうよ。

まあ、それでもGimpよりはマシである。ってかあれはクソUI選手権みたいなのを開いたら優勝確定じゃないか?


少なくともソフトウェア開発者にとってWindowsというOSは悪夢であり害悪であると俺は考えているが、今日はその割とトホホな奴にぶち当たった。

知っての通りWindowsはファイル名の大文字小文字を区別しないのだが、これは特にバージョン管理システムで大文字小文字だけのファイル名の変更を行う際に死にそうになる。というか死んだ。実際にやってみるとわかるが、Subversionでこれをやると作業コピーがぶっ壊れる。(Mercurialとかでどうなのかは知らん。上手くいかんのは同じらしいが)

これについては一度別のファイル名を経由して最終的なファイルにリネームするとかそういうTipsというかバッドノウハウを見つけたが、俺はやらかしたあとだったのでどうにもならず、結局.svnの下のファイルにABC.netbeans.svnだかなんだかそんな名前のファイルがあったので、それをコピー&リネームして本来あるべきファイルを復元、作業コピーを復旧させた。


コンピュータで飯を食ってる俺が難しいと思うんだから、コンピュータを使うのは本質的に難しいのだろう。

2014-01-22 

久しぶりにSIerの世界に戻って3週間めだが、まあなんていうか相変わらず。いやまあ、前に居た現場よりは自由が効くのでその点では相当マシではある。しかし俺が参画しなかったらどうなってたんだろうねというのが早速出てきているので、まあなんていうか相変わらず。もうちょっとスキルシート見て人を集めてくれよ、な?


イルカの追い込み漁というか捕鯨問題は本質的には日本の海洋資源管理の問題であり、文化的な問題に矮小化するべきではない。この事は公の場で「昆虫食とか人間のする事じゃないので禁止すべきだ。」などと言ったらどうなるかを考えれば分かる話で、そりゃ特定の食文化を残酷とか気持ち悪いと思うのは仕方がないが、それを理由に禁止するよう迫るのはダメだろう。あるいは「自国のみならずヨーロッパのウナギもほぼ絶滅に追いやったアホ国家は遠洋に出てくんな。実際マグロとか大変な事になってるし。」などと批判されたら、それはどこからどうみても100%正しいのでそのラインから捕鯨を批判するのは筋が通っている。が、話題に登るのはアホな動物愛護団体の「クジラやイルカは知性のある動物」みたいな話だったりする。

そして捕鯨問題がしょうもない文化摩擦の問題に矮小化されるとどうなるかというと、先に挙げた資源管理の問題が覆い隠されてしまうことになる。海洋資源管理問題という専門の知識が要求される話題と「クジラを殺すなんて残酷vsクジラは食い物だろ」というガキの喧嘩だったら後者の方がわかりやすいのは明白で、実際のところ資源管理問題で下手を打ちつづけている日本にとってはクジラは知性の高い動物だのと寝言を言っているアホの存在はスケープゴートとして便利なのではないかと思う。

要するに、そのような寝言に終始している動物愛護団体は害悪でしかないということ。バカのスタンドプレーに本来主流であってしかるべき議論が覆い隠されるのは散々見てきたので、いつもの事といえばそうだが。

2014-01-24 

国家の国家たる所以は暴力の独占だというのはまあその通りだが、その国家がやらなければならないことは殆どマクロ経済政策に基づいた経済成長と、その結果の再分配になるだろう。さらにいえば両者は相互にフィードバックループをもたらすものである事が指摘されており、つまり再分配政策によって多くの人に社会階層を上がる機会とその元手が与えられればそれだけ熟練やイノベーションへのインセンティヴが生まれ、経済成長というのは殆ど生産性の成長の事なのだから、つまり再分配政策とマクロ経済政策は車輪の両軸・コインの裏表であって一方を軽視するのは理屈の上でありえない。

なので日本の左翼陣営の多くが反経済成長的な価値観なのは大変不思議なのだが、連中の脳みそが70年代で止まっており、その時代の経済成長=大量生産大量消費=環境破壊などの当時の考え方に固執しているのであれば、なんか納得できる気がする。というかこの辺はマスコミも同じかもしれん。あと他の社会運動を見ても、70年代的な野蛮さから未だに脱却できていないケースが見られる事からも、この予測は当たっている気がする。環境保護活動自体は良いことだと思うが、その活動の仕方が反経済成長的な方向に向かってはならんだろう。またデフレ不況下で躍進した企業が安かろう悪かろうな大量生産系だったりするのを見れば、むしろ逆効果とも言える。

実際には大量消費的な成長は限界に達するというか既に達していて、これは生活水準が上がるに連れてエコロジーが非常に重要な付加価値として認められていることからも明らかだし、そもそもサービス業が経済のかなりの部分を占めるようになったのも関連している。むしろこれまた古くさい価値観でサービスの価値を認めていないので、そういった事が理解できないというのであれば、これまた腑に落ちる話ではある。

2014-01-25 

アルバムをリリースした。Youtubeの方で全曲試聴できるので、気に入った人は買ってくれ。いやー、本当にここ1ヶ月ぐらいはこれで大変だった。録音作業もしんどかったし、その後のミックス作業でも死にそうになったし、いやもう疲れた。今日のところは細かいことを書く気力ゼロ。

ちなみにこの極めてクールなジャケットは妹二号に発注して描いてもらった。

2014-01-28 

うーむ、JavaFXはそれなりに筋の良い作りだとは思うが、やはり極めて複雑かつ応答性の求められるアプリケーションになると結構大変だ。どのぐらい複雑かというと、1画面あたりのコンポーネントがシステムの最大値で1000以上存在するような(実際の業務は別だが)アプリケーションになると、JavaFXの描画スレッドにおけるコンポーネント境界の更新処理が無視できない値になってくる。あまり複雑でないアプリケーションならせいぜい5msあるかどうかだが、先のような条件下では20ms以上になり、それが複数画面となると結構キツい。

まあそういうアプリケーションをJavaで作るなと言われれば、まあその通りではあるのだが。正直その辺は俺に権限がないというか、例によってまた現場でテクニカルな理由で火の手が上がる前に何とかするお仕事なのでお察しというか。

2014-01-31 

「動物はあなたのごはんじゃない」とかいってるような連中は基本的にニューエイジだと思っていいんじゃないかな。そんでニューエイジ連中は基本的に「善人かもしれんが知性ゼロ、知性がないので自分のおろかさを認識できない、なので永遠に迷惑を振りまく」というクズだと思ってあまり間違いはないと思われる。新左翼とかアメリカのリベラリズムとかに巣食うガン細胞みたいな思想と思ってもいいだろうな。あるいは保守勢力の宗教的なガンが各種の宗教右派だとしたら、革新勢力のガンがニューエイジみたいなもんだと思う。(いや宗教と言うか信仰やイデオロギー自体がガンみたいなもんだが、ここでは置いておく。)

汎神論的なスピリチュアリズムとかの類はこっからの派生のはずで、ついでに書けばアニミズムの文化圏である日本は本質的にニューエイジに脆弱にも思える。水からの伝言なんてヨーコ・オノが持ち上げた事からもその線との相性抜群だったし、それを教育の現場に持ち込んだ教員の中にもニューエイジ派がちらほらいたようだ。