転職した

調べた事、学んだ事、思った事、考えた事を個人的にまとめているだけなので内容は保証しないYO!

最速でHomebrewをインストールする

$ java -version
$ ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go/install)"

を実行するだけ。

Command Line Toolsのインストールは?

Homebrewをインストールしようと思ってググってみると色々と情報が出てきて、Command Line Toolsなるものをインストールしなければならないと言われています。ただ、このインストール方法についても紆余曲折あって情報が混乱しています。

  • Xcodeからインストールできるよ!(現在はできなくなっています)
  • https://developer.apple.com/downloads/index.action からダウンロードできるよ!(アカウント登録が必要だけどね)
  • Xcodeをインストールしてxcode-select --installコマンドでインストールできるよ!

など。

しかし、現状では上記の操作をしなくてもHomebrewのインストール処理中にxcode-select --installが実行されるためCommand Line Toolsのインストールで悩む必要がなくなりました。また、OS X 10.9.4ではXcodeを入れずともxcode-selectはインストールされていました。

詭弁論理学を読んだ

詭弁論理学 (中公新書 (448))

詭弁論理学 (中公新書 (448))

ぼくはよく反省をする。反省と言っても「反省しろ!」といわれてシュンとするということではなく、辞書的な意味の振り返って考えるという意味で。先月末に退職した会社での会話とか出来事を退職の節目ということもあって色々考えていて、ことごとく多勢の詭弁で押し通されていたことに気づいて、もうすこし詭弁にうまく対処できるようになれればなあと考えていた。そんなとき、ブックオフで見つけたのが詭弁論理学だった。

笑い話と詭弁・強弁

この本には色々な詭弁・強弁のエピソードや例文が載っているが、笑い話になるものも多い。

【例1】お酒を飲むと、酔う。ビールを飲んでも、ウォツカを飲んでも酔う。ところで、お酒にも、ビールにも、ウォツカにも、水が入っている。ゆえに、水が酔っぱらう原因である。

【例2】「石森は酒を飲まないらしいね。あいつが酒を飲んでるところを見たことがないもの」「そういえば、おれはラムちゃんがトイレに行くのを見たことがないぜ。あの子はトイレに行かないんだな」

詭弁論理学 84p

この例は、大真面目に主張されたら詭弁だが、ジョークとして言うなら笑い話になる。そういう意味で、詭弁も笑いのテクニックの一つなんだなと思った。ほかにも、

ジェームズ一世の『欽定訳聖書』については、こんな話がある。

詩篇第四十六篇を英訳したのは、シェークスピアに相違ない。なぜなら、この詩のはじめから四十六番めの単語はシェーク(shake)で、終わりから四十六番めの単語はスピア(spear)である」

(中略)

なお『欽定訳聖書』が完成した一六一〇年、シェークスピアは四十六歳だったという。

詭弁論理学 74p

という話が載っており、これは思わず(理論破綻しているのはわかっていても)「おおっ!」と思ってしまう。DHMOやパンは危険な食べ物のような間違っているんだけど、間違ってないタイプのジョークというのは詭弁だけれども面白い。

過去のアレはどう詭弁だったのか

もちろん、笑い話のテクニックを磨くためにこの本を読んだ訳ではないので、この本を活かして過去の反省を改めてしてみる。

愛の飴と鞭の話

曰く「彼にとっては私の対応は厳しいムチでしょうが、私の思いとしてはアメを与えているのです。(ゆえに私の行動は正しい)」と言われた事がある。あまりにハチャメチャな理屈なので、「当人がムチと思うんなら、そりゃ当人にとってはムチでしょう」と間髪入れずにツッコミいれて笑い話になったのだが、今改めて考えればこれは不当肯定の虚偽だろう。

しかしこの虚偽はあまりにも見えすいていて、詭弁術には使えそうもない。

詭弁論理学 92p

と評されているが、勢いに任せて言われたらスルッと通してしまう人もいるんじゃなかろうかと思う。

ある人が望むかもしれないし、ある人は望まないかもしれない、だからなんだという話

NDAは関係ないが話をぼかして書くと「Xを提供されることは重要であるという人がいる。Xを提供するためにはYを用意する必要がある。ゆえに、ある人のためにYを用意しておく必要がある。」という主張をしたところ、「(反論1)ある人にとってXは重要でないかもしれない」「(反論2)Xが提供されることによって得られる影響αがなくなるかもしれない」という反論をされた。これについては、多勢に無勢の詭弁で押し通されてしまった。改めて考えれば(反論2)は

Xを提供されることによって得られる影響αがなくなったためXを提供されることは重要であると思う人はいなくなる。

Xを提供するためにはYを用意する必要がある。

ゆえに、ある人のためにXを提供するためにYを用意しておく必要はない。

となるのだが、これは理屈が間違っているので詭弁である。一段目が部分より全体に及ぼす誤りであって影響βが重要であると思う人の存在を無視している。

問題は(反論1)で

ある人にとってXは重要でない。

Xを提供するためにはYを用意する必要がある。

ゆえに、ある人のためにXを提供するためにYを用意しておく必要はない。

と筋の通った三段論法で別に間違っていない。でも、これは詭弁である。おそらく、私の主張の仕方が悪かったのだろうが、私の主張は本来こうであった。

ある集団AのうちaにとってXは重要である。

ある集団Bのすべての人にとって、Xを提供するためにはYを用意する必要がある。

ゆえに、集団Bの人が集団Aの人に対応するときaの人の可能性を考えてYを用意しておく必要がある。

こう記述すれば(反論1)は反論になっていないことがよくわかる集団Aの構成員a1が重要でないとしても重要とする構成員aがいる限り私の主張は間違っていない。

この話の教訓としては「ある人」という言葉によって揚げ足取りを食らったということで、別の意味に解釈されないように注意する必要があるということか。

Mac作ってる会社はアップル、アップルはリンゴ、つまりMac作ってる会社はかじって食えるってことさ

「うちのは開発スタイルはアジャイルじゃないですよ。」「なにいってんだ。アジャイルってのは素早いって意味だ。素早く要件を取り入れ、素早く修正しているんだから、うちはアジャイルだ」というやりとりがあった。これは、媒概念曖昧の虚偽というやつだ。agileという英単語は確かに素早いとか敏捷とかいう意味だが、アジャイル開発のアジャイルとは関係のない話だ。ただ、これに関しては、アジャイルでないと説得できる自信が未だにない。「テスト自動化とかでコード保全につとめないとアジャイルなんてできませんよ。」といっても「ツールの導入は各PMに任せる話だ(だからアジャイルとは関係ない)。」となってしまったりして、お手上げだった。

そうかといって、ムダに時間を費やすことはない。相手が強弁・詭弁を弄してきたら、もはや正しい議論は望めないので、惜しまず議論を打ち切ればよい。

詭弁論理学 122p

とあるように、この件についてはとっとと議論を投げ出すのが正解なのだろうなぁ。

自宅のwikiをBitbucketのwikiに移行した

書くまでもないですが、自宅でwiki運用をすると外出先で編集どころか閲覧すらできないというデメリットがあります。いずれ解決したいなーと思っていたのですが、せっかくの休みなので片付けることにしました。

自宅WikiMediaWikiを利用しているので、MediaWikiの形式からMarkdown形式に変換してやる必要があったり、変換がうまくいかなかったりで少し苦労しました。

 

MediaWiki形式からMarkdown形式に変換

幸い、Pandocという変換ツールがあったのでコレを利用しました。Haskellで作られたコマンドらしく、Haskellをインストールしてから、cabalコマンドでインストールします。

wget http://sherkin.justhub.org/el6/RPMS/x86_64/justhub-release-2.0-4.0.el6.x86_64.rpm
rpm -ivh justhub-release-2.0-4.0.el6.x86_64.rpm
yum install haskell
cabal update
cabal install pandoc

CentOSにHaskellをインストール - Qiitaを参考にPandocをインストール。なお、cabal install pandocだと~/.cabal/bin/以下にインストールされます。システムにインストールするには--globalオプションを付ける必要があるようです(Haskell パッケージのインストール方法 | サイト運営の私的メモ)。

 

その後、mediawikiフォーマットのファイルをin.mediawikiとして保存しておいて下記のコマンドを実行することでout.markdownファイルにmarkdown形式で出力されます。

pandoc -f mediawiki -t markdown_github in.mediawiki -o out.markdown 

-tオプションにはmarkdown_githubを指定します。BitbucketはGithubの方言にも対応しているみたいです(どれぐらい対応しているのかは知りませんが)。ただし、これでスルッとうまくいくかというと、やはりうまくいきません。

いくつかの問題

テーブル関係

{| class='wikitable'
| rowspan='2' | Japan || HOGE
|-
| PIYO
|-
| rowspan='2' | USA || FOO
|-
| BAR
|}

テーブル関係の問題は特に酷く、上記のMediaWiki形式で書いたテーブルを例に説明します。

class='wikitable'と記述している部分ですが、このままだと下記のようなエラーが発生して変換がうまくいきません。class="wikitable"に直す必要があります。消してしまっても構いません。

pandoc:
Error:
"source" (line 733, column 10):
unexpected "'"
expecting "\""

つぎに、列見出しがないため、Markdownのフォーマットに合わず、変換結果をBitbucketのwikiに登録してもうまくパースしてくれません。列見出しをつける必要があります。

最後に、rowspan='2'を認識せずにセルの値としてPandocが変換してしまい、テーブルがガタガタになってしまうため、rowspan='2'を消して空白セルを追加するなど、整形しておく必要があります。修正内容を適用すると下記のような感じになります。

{| class="wikitable"
! Country !! メタ構文変数
|-
| Japan || HOGE
|-
| || PIYO
|-
| USA || FOO
|-
| || BAR
|}

 

ヘッダ

テーブルの問題に比べれば可愛い問題ですが、下記のようにヘッダに=が含まれている場合は、MediaWiki構文がそのまま出力されてしまうため、手作業で直す必要があります。

=== --color[=WHEN] ===

 

ひとまず、これで問題なさそうでした。

 

pandocコマンドについてはここらへんを参考にしました:HTML - 多様なフォーマットに対応!ドキュメント変換ツールPandocを知ろう - QiitaPandoc ユーザーズガイド 日本語版 - Japanese Pandoc User's Association

 追記

その後、プレビューなどの表示でHTMLに変換されずにそのままテキストが表示されてしまう問題に遭遇しました。再現性がなく、同じテキストでもうまく変換されるときがあったりなかったり、登録時には変換されても数時間後に表示するとテキストになったりという具合でした。今回の移行データがテキストのみで260KBなのでまあ、パースに時間がかかってしまい、途中でタイムアウトしてテキストそのまま表示するという感じなんでしょう。

SQLのNULLはなぜIS NULLで比較するのか

今年度に入ってから(毎年度のことだが)ろくな仕事がなく、新人にいらんことを色々吹き込んでいる。

課題としてOracleの資格取得を命ぜられているらしいので、たまに質問に答えるついでに、NULLを許可すると色々面倒だからNOT NULLつけとか*1、サングラスをかけた人の眼の色と自動車の眼の色の話をしたりとか*2、なぁなぁで仕事してるとまず行き着かない話をしている。

そんな中で出てきた質問が、「なぜNULLはIS NULLで比較しなければならないのか」という質問。なんと答えたかは後述するけど、そのまえに3値論理でこのことに言及されていたので引用する。

理由は、NULL に「=」を適用した結果が必ず unknown になるからです 

 

以下、遠回りに上記の一文を説明しているだけだけど、皆さんの新人教育の参考になれば幸い。

yellowringなりの「なぜNULLはIS NULLで比較しなければならないか」に対する回答(面倒なので実際に新人に説明した感じの話口調)

まず、NULL = col では1行も結果が返らないことについての説明から。

NULLというのはサングラスをかけた人の眼の色(未知)か自動車の眼の色(適用不能)なわけだけど、例えば「タモリと同じ眼の色の人はこのオフィス内に何人いる?」と質問されたら、なんて答える? 「わからない」だよね。タモリの眼の色がわからない、わからない物とわかっている物を比較しても一緒かどうかなんてわかりようがない。逆に「タモリと違う眼の色の人はこのオフィス内に何人いる?」という質問に対しても「わからないと答えざるを得ない。一緒かどうかわからないのだから、違っているのかどうかもやはりわからない。だから、NULL = colもNULL <> colも結果が0件になってしまうわけだ。

次にNULL = NULLについてサングラスをかけた人の眼の色の例を当てはめてみよう。

(適当に画像検索したサングラスをかけた人の画像を見せて)「タモリの眼の色とこの人の眼の色は一緒ですか?」と質問されたら、なんて答える? これも同じく「わからない」だよね。わからない物とわからない物を比較して一緒かどうかなんてわからない。だから、NULL = NULLではNULLを検索することができない。

これの回避策として、「xxxは未知ないし適用不能ですか?」という演算子が必要となったわけだ。そして、それがIS NULLというわけさ。

 

SQLで増分の一覧から積算された一覧を取得する

この間の記事とは逆に増減の一覧があるが、そのレコード時点で合計するといくつになるのか一覧取得したい場合というのもやはりある。

mysql> select * from foo;

+---------------------+--------+

| created_at          | in_out |

+---------------------+--------+

| 2014-06-26 00:00:00 |   10.0 |

| 2014-06-26 00:01:00 |  -10.0 |

| 2014-06-26 00:02:00 |   30.0 |

| 2014-06-26 00:03:00 |  200.0 |

| 2014-06-26 00:04:00 | -100.0 |

| 2014-06-26 00:05:00 |   10.0 |

+---------------------+--------+

 こんなテーブルがあるとする。

 

今回の場合、考え方は極めてシンプルで、そのレコードのcreated_at以前のin_outをsumすればその時点までの積算が取得できる。SQLもとても単純である。

select
  F.created_at,
  (
    select
      sum(F2.in_out)
    from foo as F2
    where F2.created_at <= F.created_at) as total
from foo as F; 

 

実行例

mysql> select

    ->   F.created_at,

    ->   (

    ->     select

    ->       sum(F2.in_out)

    ->     from foo as F2

    ->     where F2.created_at <= F.created_at) as total

    -> from foo as F;

+---------------------+-------+

| created_at          | total |

+---------------------+-------+

| 2014-06-26 00:00:00 |  10.0 |

| 2014-06-26 00:01:00 |   0.0 |

| 2014-06-26 00:02:00 |  30.0 |

| 2014-06-26 00:03:00 | 230.0 |

| 2014-06-26 00:04:00 | 130.0 |

| 2014-06-26 00:05:00 | 140.0 |

+---------------------+-------+

 

 

SQLで増分の一覧取得する

Rails ActiveRecordでの増分の計算方法について。 - QA@IT

こういう類いの問題はRailsでごにょごにょやるより、SQLを直接書いてしまった方が後で理解しやすいと思うんだけどどうなんだろ。個人的にはSQLを直接書く派。

 

まあ、ともかく、この質問(一時間ごとの行同士の増分の計算を行う)のような順序のあるデータが格納されたテーブルから直後のデータとの差を取得したいという要望は基幹系システムだと結構ある。逆に増分データは保持しているから累積計算した一覧が欲しいという場合もあったりするが、それは今度書こう。

 

この問題の考え方としては、

  1. あるレコードのcreated_at(G.created_at)以降で最小のcreated_at(G3.created_at)のレコードのkilowatthour(G2.kilowatthour)を取得すれば次のデータのkilowatthourが求められる。
  2. あるレコードのcreated_at(G.created_at)のkilowatthour(G.kilowatthour)と先ほどのkilowatthour(G2.kilowatthour)との差分を求めれば増分を求める事ができる。

の2点。

SQLで書くとこんな感じ。

select 
  G.created_at,
  (
    select min(G2.kilowatthour)
    from genreps as G2
    where
      G2.created_at = (
          select min(G3.created_at)
          from genreps as G3
          where G.created_at < G3.created_at)
  ) - G.kilowatthour as zoubun
from genreps as G
order by G.created_at;

ポイントは相関サブクエリで次のデータのcreated_atを求めている部分(G2.created_atと比較しているサブクエリ)、min(G2.kilowatthour)とすることでcreated_atに重複があってもとりあえずSQLがコケないようにスカラサブクエリにしている部分ぐらいかな(結果は要件としては正しくないだろうけど)。あと、created_atにインデックスを付ける必要があるだろうなぁ。

 

実行例

mysql> select * from genreps;

+---------------------+--------------+

| created_at          | kilowatthour |

+---------------------+--------------+

| 2013-04-12 08:00:00 |          0.0 |

| 2013-04-12 09:00:00 |          2.0 |

| 2013-04-12 10:00:00 |          3.5 |

| 2013-04-12 11:00:00 |          4.7 |

+---------------------+--------------+

4 rows in set (0.00 sec)

 

mysql> select 

    ->   G.created_at,

    ->   (

    ->     select min(G2.kilowatthour)

    ->     from genreps as G2

    ->     where

    ->       G2.created_at = (

    ->           select min(G3.created_at)

    ->           from genreps as G3

    ->           where G.created_at < G3.created_at)

    ->   ) - G.kilowatthour as zoubun

    -> from genreps as G

    -> order by G.created_at;

+---------------------+--------+

| created_at          | zoubun |

+---------------------+--------+

| 2013-04-12 08:00:00 |    2.0 |

| 2013-04-12 09:00:00 |    1.5 |

| 2013-04-12 10:00:00 |    1.2 |

| 2013-04-12 11:00:00 |   NULL |

+---------------------+--------+

4 rows in set (0.00 sec)

 

 

sayコマンドであのネタフラッシュの音声

下記のコマンドを実行すると指定できる音声が色々でてくるのだが・・・

say -v ?

 

http://timidmacer.s5.xrea.com/error_img/404.swf

この「お探しのファイルは見つかりませんでした」の音声って、sayコマンドで作られたんじゃなかろうか。

say -v 'Bad News' anata gaosagasino file hamitsu kerimasendesita

 というコマンドを実行するとほとんど同じ音声になる。

 

ほかにも、

なつかしフラッシュ「ゴルゴの吉野屋」コピペで流行ったアレ ‐ ニコニコ動画:GINZA

say -v Whisper son nakoto yori ki-te ckure ichiyo

とか。

 

このフラッシュ見た当時、機械音声なんてどうやって作ってんだろう? って不思議に思っていたけど、10年越しで謎が解けるとは思わんかったな。