yunomuのブログ

趣味のこと

SSHがつながらない

前回と同じネットワーク構成で。
f:id:yunomu:20140311120402p:plain
AからVPN経由でCへのSSH接続を試みる。

% ssh 192.168.2.11
ssh_exchange_identification: read: Connection reset by peer

つながらない。

Aからインターネット経由でC(eth0)へのSSH接続は普通にできる。

% ssh server_public_ip
Last login: Fri Mar 14 14:36:19 2014 from 192.168.1.2
[yunomu@host ~] $

だいたいこういう感じ。

/var/log/secureで関係ありそうなのは以下の1行だけ。

Mar 14 13:41:41 host sshd[30405]: Did not receive identification string from 192.168.1.2

他の/var/log/messagesとかは何も出てなかった。

TCPWrapperやxinetdは使っていなくて、生sshdで動いている。
なのでhosts.allowやhosts.denyは空で問題ないはず。

死んだsshdのプロセスがウヨウヨいたりして新規接続の確立ができてないのかなと思ったけど特にそういう気配も無し。

というかそもそも/var/log/secureの通り一応sshdが動くところまでは行ってるわけで。sshdが動いた上で、クライアントからのデータが何も来ないからしばらくしてコネクションが切られているっぽい。

さらに面倒くさいことに、2日前まではインターネット経由でもVPN経由でもつながっていたし、この記事を書き始めてから試したらつながった。
つながったじゃないか! なんなんだこれ!

というわけで、またよくわからないうちに事件が解決してしまった。いや解決してないんだけど。

ネットワークがつながらない

基本がわかっていないとなにもかもわからなくなる。

出来事

外で借りてるサーバ(C)を使ってこんな感じのネットワークを作った。
f:id:yunomu:20140311120402p:plain

  • AはWindows 7
  • Aの隣に何台かノート(D)やら携帯(E)やらがある
  • BはUT-VPNクライアントが動く程度のLinux(CentOS 5系だったと思う)
  • CはVPSLinux(これもCentOS 5系のはず)
  • BとCはUT-VPNで接続していて、仮想HUBはCにある
  • ルータはなんか数千円の安いやつ
  • 白い四角はルーティングテーブル

この状態で、CにはDBやらWebサーバやらいろいろ置いてあって、AからVPN経由で触って遊べるようにしたつもり。

で、しばらくなんの問題もなく遊んでいたんですが、なんかAのネットワークとCの通信がうまくいったりいかなかったりする。
症状はこんな感じ。

  • AとEからはCのサービス(HTTP)が見られる
  • DからはCのサービス(HTTP)が見られない
    • Bのeth0ではHTTPのrequest/responseパケットをキャプチャできる
  • A, D, EからC(192.168.2.11)にpingを飛ばすと全て応答する
  • CからAやDにpingを飛ばすとどちらも応答しない
    • Bのeth0ではicmpパケットのecho/replyをキャプチャできる

何がうまくいかないのかさっぱりわからん。なんでDのTCPだけ通信できないんだ。

よく見てみると、DからCにTCPで通信する時、行きはルータ->B->Cと経由しているけど、帰りはBからルータを経由せずにDに帰るようになっている。
ということでBのルーティングテーブルを変更して192.168.1.0/24を192.168.1.1に向けてみた。
するとDはCとTCPでも通信できるようになったが、今度はAとEがCと通信できなくなった。

まあそういういい加減な対処は無かったことにして。

なんとなく、ルータを経由したりしなかったりするのが良くないんじゃないかという気がするので、さしあたりDに192.168.2.0/24->192.168.1.10のルーティングを追加して、まあなんとか使える感じにしてみた。
一晩寝ると、CからAへのpingは通るようになっていたけども、CからDへは通らず。

なんか、何年も前に何か問題が起きたわけじゃないけども、こういう感じの問題に対処するために何かした記憶がおぼろげにあるような気がしないでもないけども、全然思い出せない。

よくわからない

問題は、何が悪いかよくわかっていないこと。割とつながってるやつもいるし、ネットワーク的には間違っていないようにも見える。
つながったりつながらなかったりするってことは、ARPテーブルがどうのこうのいう感じかなぁとも思ったものの、いじってみても特に変化はなさそう。

こういう時に、これがIPとして正しい動きなのか、TCPとして正しい動きなのか、Ethernetとして正しい動きなのか、それともそれぞれの機器の実装の問題なのか、そのあたりの切り分けができない。
自信を持って「これはIP的にはちゃんとできてるハズなんだけどねぇ~」みたいな事が言えない。
本当に教科書的な意味で、基本がよくわかっていない。

私のネットワークの知識はなんかルータいじってる過程でいつの間にか身についたものなので、プロトコルに関しては実のところよく知らなかったりするのです。誰だよ私がネットワークに詳しいなんて言ったボンクラは。(私です)

そろそろTCP/IPの本を一冊くらい読んでまともに勉強してみようかなぁと思いました。

それはそれとして件の問題は片付いていないんですが。

haskell-relational-recordとMySQLの識別子の大文字小文字

haskell-relational-record(hrr)とMySQLを使ってプログラムを書いてみようと思った。

書き方自体はこのあたり。
https://github.com/khibino/haskell-relational-record
https://github.com/krdlab/haskell-relational-record-driver-mysql

元々haskell-relational-recordはPostgreSQLのために作られているので(訂正:IBM-DB2 + ODBCで動かしていたのが最初だそうです)、MySQLから使おうとするとちょっと詰まるのかもしれない。
まずdefineTableFromDBが動かなかったんですけど、それはちょっと原因がよくわからないので保留。

そもそもの問題が適当に作られたテーブルの形式だったりするわけなんですが、おおむねこういう感じになっている。

mysql> connect myapp
Connection id:    126780
Current database: myapp
mysql> desc USER;
+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| NAME         | varchar(32)  | NO   | PRI | NULL    |       |
| MAIL_ADDRESS | varchar(128) | YES  |     | NULL    |       |
+--------------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

MySQLではスキーマとデータベースの区別が無いというか、同じ物を指すっぽいので、データベース名もスキーマ名も同じ"myapp"になっている。そして、テーブル名とフィールド名を大文字のスネークケース。どこの常識だこれはという感じ。まあこれはそういうものなので仕方ないものとする。

これを元にテーブル定義を作るとこうなる。defineTableFromDBが動かないので自分で定義する。

{-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, FlexibleInstances #-}

module User where

import Database.HDBC.Query.TH (defineTableDefault')
import Database.Record.TH (derivingShow)
import Language.Haskell.TH
import DataSource

defineTableDefault' "myapp" "USER"
    [ ("NAME", conT ''String)
    , ("MAIL_ADDRESS", conT ''String)
    ] [derivingShow]

でき上がるテーブルとクエリの定義はこうなる。

*Main> :i USER
data USER
  = USER {nAME :: !String,
          mAILADDRESS :: !String}
     -- Defined at User.hs:10:1
instance Show USER -- Defined at User.hs:10:1
instance TableDerivable USER -- Defined at User.hs:10:1
instance ProductConstructor (String -> String -> USER)
  -- Defined at User.hs:10:1
*Main> uSER
SELECT NAME, MAIL_ADDRESS FROM MYAPP.user

とてもきもちわるい。その上この時点で既に破綻している。

  • データ型名が全部大文字で気持悪い
  • フィールド名の'_'が消えて先頭だけが小文字になっていて気持悪い
  • クエリの関数名が同様に"uSER"て何よ
  • クエリの中身のデータベース名が大文字に、テーブル名が小文字になっている

この、最後のやつが困る。他はまあ気持悪いだけなのでいいのだけど。
どう困るかというと、このクエリを発行するとそんなテーブル無いよと言われる。MySQLはテーブル名の大文字と小文字を区別することがある。

MySQLのドキュメントにはこういう事が書いてある。

5.2.2. 識別子の大文字小文字の区別
MySQL において、データベースはデータディレクトリ内のディレクトリに対応しています。データベース内の各テーブルも、データベースディレクトリ内の少なくとも 1 つ(記憶エンジンによってはそれ以上)のファイルに対応しています。トリガーもファイルに対応しています。そのため、ベースとなるオペレーティングシステムで大文字と小文字が区別される場合、データベース名とテーブル名でも大文字と小文字が区別されます。
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 5.2.2 識別子の大文字小文字の区別

つまりMySQLのデータがWindowsファイルシステム上に置かれている場合はデータベース名やテーブル名の大文字小文字は区別しないけれど、UnixLinuxの多くのファイルシステム上に置かれていた場合は区別しますという事。なんじゃそりゃという感じだけども、これも仕方ない。

これをなんとかしてhrrを使うためには、ソースをいじる必要がある。
問題はテーブル定義と同時に作成されるクエリ関数なわけなので、それを定義している場所を探すと、tableSQLという関数が見つかる。場所はここ。
haskell-relational-record/relational-query/src/Database/Relational/Query/TH.hs at master · khibino/haskell-relational-record · GitHub

tableSQL :: String -> String -> String
tableSQL schema table = map toUpper schema ++ '.' : map toLower table

とてもわかりやすいですね。
これの"map toUpper"と"map toLower"を消してあげればいいのです。PostgreSQLでは基本的にテーブル名は小文字なのでこうなってるんだと思います。スキーマ名は忘れたけど大文字なんだっけ?

ということで、hrrはまだhackageに登録されていないので皆様各々githubからcloneして使っておられると思いますので、この辺りをいじる心理的障壁は比較的少ないんじゃないかと思います。やっちゃいましょう。branch作ってcommitしておくと本家が更新した時に追随が楽だと思います。いや検証してPull Request送れという話はもっともなんですが。

ともあれこれで一応クエリは利用可能になります。めでたしめでたし。

*Main> uSER
SELECT NAME, MAIL_ADDRESS FROM myapp.USER

ところで実はMySQLはデータベース名とテーブル名についてはなんか面倒な仕様があるんですが、フィールド名の大文字小文字は区別しないので、テーブル定義のところはフィールド名を小文字のスネークケースにすると少しだけ幸せになります。

defineTableDefault' "myapp" "USER"
    [ ("name", conT ''String)
    , ("mail_address", conT ''String)
    ] [derivingShow]

ごらんよ、焼け石に水って感じだけども。これでも普通に使えます。

*Main> :i USER
data USER
  = USER {name :: !String,
          mailAddress :: !String}
     -- Defined at User.hs:10:1
instance Show USER -- Defined at User.hs:10:1
instance TableDerivable USER -- Defined at User.hs:10:1
instance ProductConstructor (String -> String -> USER)
  -- Defined at User.hs:10:1
*Main> uSER
SELECT name, mail_address FROM myapp.USER

Frappuccinoの使い方

前回、Frappuccinoの件をあまりにももののついでみたいに書いてしまったんですが、使おうとすると例によってドキュメントが無くてソースを読む事になって、なったので、その時の足跡です。
https://github.com/steveklabnik/frappuccino

Source

前準備として、streamとイベント発生装置(Source)を作る。公式のReadmeではButtonとなってるやつ。

class Source
  def send(event)
    emit(event)
  end
end

source = Source.new
stream = Frappuccino::Stream.new(source)

このemitは、ソースを見てみると、まずStream.newで渡されたインスタンスにFrappuccino::Sourceを継承させてる。
frappuccino/stream.rb

module Frappuccino
  class Stream
    include Observable

    def initialize(*sources)
      sources.each do |source|
        source.extend(Frappuccino::Source).add_observer(self)
      end 
    end
(略)

それでemitはSourceに定義されている。中では変更フラグを立てて、イベントをObserverに通知している。
frappuccino/source.rb

require 'observer'

module Frappuccino
  module Source
    def self.extended(object)
      object.extend(Observable)
    end 

    def emit(value)
      changed
      notify_observers(value)
    end 
  end 
end

というわけでSource.sendの中でemitを呼び出すことができるようになっている。Observableは標準添付のobserverに入ってるやつです。そんなの標準であったのかという感じですが。

Streamにはmap, drop, take, select, zip, merge, scan, count, inject, merge, update, on_valueというメソッドがあって、分類すると以下のような感じになります。

  • Streamを返す
    • map
    • drop
    • take
    • select
    • zip
    • merge
    • scan
  • Proptertyを返す
    • inject
    • count
  • その他
    • update
    • on_value

Stream系

Streamを返すやつらは、分類したり変換したり統合したり、まあメソッド名を見ればでわかるような事をやります。Java8のStreamと同じような感じです。
mapは変換、dropは指定した個数のイベントを無視、takeは指定した個数のイベント以降を無視、selectは条件に合うイベントのみを拾うようなStreamを返します。だいたい想像通りに動くと思います。

mapはブロックじゃなくてHashを取ることもできて、

  def map(hash = nil, &blk)
    blk = lambda { |event| hash.fetch(event) { hash[:default] } } if hash
    Map.new(self, &blk)
  end

みたいになってて、

stream.map(:e1 => 1, :e2 => 2, :default => 0)

みたいなHashを渡すと、キーと一致するイベントがきたら特定の値に変換するというのが簡単に書けるんですが、まああんまし使わないと思います。

zipとmergeはStreamの統合で
zipは

stream3 = stream1.zip(stream2)

とやると、stream1とstream2の両方のイベントが1つずつそろった時にstream3が発火するような感じ。ソース見ると本当に単にバッファを2つ作って、両方そろったら発火させているだけで、あーこんなに簡単に作れるのかーという気がする。

mergeは

stream3 = Stream.merge(stream1, stream2)

zipと似てるんですけど、これはstream1とstream2のどちらかが発火したら発火する。

scanは畳み込みみたいな感じで、前回のイベントを参照しながらmapみたいな処理ができる。
例えば、イベントの数を数えるのはこう。

stream2 = stream1.scan(0) {|a| a + 1 }

イベントとして飛んでくる整数の合計値を取る場合はこう。

stream2 = stream1.scan(0) {|a, v| a + v }

ブロックの第一引数が蓄積変数というか前回の値で、第二引数が今回のイベントになってる。集計以外では、値のストリームを前回との差分のストリームに変換したりとか、そんなふうに使うんじゃないでしょうか。

Property系

Property系は、StreamではなくPropertyオブジェクトを返します。

module Frappuccino
  class Property
    def initialize(zero, stream)
      @value = zero
      stream.add_observer(self)
    end 
        
    def now
      @value
    end
    
    def update(value)
      @value = value
    end
  end
end

ご覧の通り、nowとupdateがあって、nowは現在の値を返します。updateはどうでもいいというか使わないと思います。
「現在の」と言ったのは、イベントが発生するとnowの値が変わるからです。公式のReadmeにあるとおりなんですが。

injectは、scanの結果をPropertyにしたやつで、scanの合計値を数えるのと同じ事をやると、

counter = stream1.inject(0) {|a| a + 1 }

これでcounter.nowで現在のイベントの個数が取得できます。以下と全く同じです。

stream2 = stream1.scan(0) {|a| a + 1 }
counter = Frappuccino::Property.new(0, stream2)

countはinjectのラッパーで、個数を数えるのに特化しています。引数を渡すと内部でselectされます。

counter = stream1.count #=> イベントの個数を数える
counter1 = stream1.count(:event1) #=> :event1の個数を数える
counter2 = stream1.count {|e| e[:value] >= 2 } #=> 条件に合うイベントの個数を数える

その他

updateはイベントを発生させます。
Source以外の場所からemit相当の事をするために使うっぽい。というかこれがあれば実はemitを使わなくてよくて、実は前回の例はこう書ける。(Emitterクラスを定義してない)

ws = WebSocket::Client::Simple.connect url
stream = Frappuccino::Stream.new
ws.on :message do |msg|
  stream.update msg
end

公式のReadmeの例に引っ張られすぎだった。

on_valueは、イベントが発生したら引数で渡したブロックを評価する。Streamをイベントに変換するメソッドです。便利!

おわり

実装が思いのほか単純で、読むのが楽なのが素晴らしいですね。まあドキュメントあるにこしたことはないんですけど。
ところでこのライブラリって何に使うんでしょうね。

Chrome remote-debuggingの話と見せかけてWebSocketとかfrappuccinoとか

最近ちょっとブラウザで遊んでいたので、共有というか。

Google Chromeにremote debuggingという機能があります。
https://developers.google.com/chrome-developer-tools/docs/debugger-protocol

要するにJavaScript開発者にはおなじみのDeveloper toolsが使っているAPIなんですが、最近モバイル対応だのなんだののために整備されて使いやすくなったとかなんとか。最近て、何年前の話か知りませんけども。

使うためには、remote debugging portを有効化してChromeのプロセスを起動する必要があります。Chromeのプログラム名は環境によって違うので、それらしいやつを起動してください。

% google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp

とやると起動します。9222はなんか、デフォルトのポートらしいです。
user-data-dirはプロファイルのディレクトリで、指定しないと既存のChromeプロセスがforkするだけでremote-debuggingは有効になりません。既存のプロセスが無ければうまくいくんですが。

起動すると、
http://localhost:9222/
にアクセスできるようになります。このトップページは現在開いているタブの一覧です。それぞれのページを開くと、おなじみのdeveloper toolsが開きます。developer toolsってJavaScriptで書かれてたのかよという。

http://localhost:9222/json
にアクセスすると、開いているタブの情報がJSONで取れます。
この中にある”webSocketDebuggerUrl”というやつが、remote-debugging APIのエンドポイントです。その名の通り、WebSocketで通信します。

ここからは手打ちでは辛いのでRubyで操作します。
まず、どうでもいいんですがwebSocketDebbuggerUrlの取得部分。

require 'json'
require 'open-uri'

# ページ一覧のJSONを取ってくる
def pagelist(host = "localhost", port = 9222)
    JSON.parse open("http://#{host}:#{port}/json") {|f|
        f.read
    }   
end

# とってきたやつからタイトルに”GitHub”が含まれる最初のものを探す
w = pagelist.find {|e| e["title"].include? “GitHub }

# webSocketDebuggerUrlを取得
debugUrl = w["webSocketDebuggerUrl"] || begin
    puts "debugUrl is nil"
    exit 1
end

ここではタイトルに”GitHub”を含む最初のタブのdebugger urlを取得していいます。これとは別にdeveloper toolsを使っていたりするとこのインタフェースが無くなったりするので、念のためにエラー処理を入れてます。

で、WebSocketでの通信ではwebsocket-client-simpleを使います。たぶんこれが一番楽です。

% gem install websocket-client-simple
# (さっきの続き)
require 'websocket-client-simple'

# 接続
ws = WebSocket::Client::Simple.connect debugUrl

# 以下はイベントハンドラ

ws.on :message do |msg|
    data = JSON.parse(msg.data)
    print "response: ", data["params"], $/
end

ws.on :open do
    puts "open"
end

ws.on :close do |s|
    puts "close"
end

基本はこんな感じ。イベントドリブンになっていて、message, open, closeというイベントが起きます。messageは受信した時、openは接続完了した時、closeは閉じた時。
それとは別に、sendというメソッドがあります。

試しにTimelineで流れてくるイベントを取ってみます。
https://developers.google.com/chrome-developer-tools/docs/protocol/1.1/timeline
ここに載ってるstartというメッセージを送ると、ブラウザ側からイベントのログがドロドロと流れてきます。
WebSocketのopenのタイミングが微妙なのでopenハンドラに直に送信処理を書きます。

ws.on :open do
    ws.send JSON.dump("id" => 1, "method" => "Timeline.start")
end
sleep 5

こうすると5秒ほどイベントが流れてきます。流れてこないという人はJavaScriptイベントが起きていない可能性があるのでブラウザのページ上でマウスを動かしたりなんたりしてみてください。
あと、このidというのは、まあなんかidらしいです。適当に決めてます。

{
  "record"=>{
    "startTime"=>1388377232581.642,
    "type"=>"Program",
    "data"=>{},
    "children"=>[],
    "endTime"=>1388377232581.6663
  }
}

イベントの1個の形式がこんな感じで(Rubyに整形済み)、いわゆるTimelineの情報が入っているんですが、このstartTime/endTimeというやつが、エポックからのまさかのマイクロ秒で、ミリ秒じゃねーのかよってつまんないところでつまづきました。

frappuccino

messageイベントのハンドラを書くのが面倒くさい。ので、frappuccinoでイベントをストリームに変換してみようと思いました。いわゆるFRPライブラリです。
https://github.com/steveklabnik/frappuccino

% gem install frappuccino
require 'frappuccino'

# イベントストリームを作るやつ
class Emitter
  def send(data)
    emit(data)
  end 
end
emitter = Emitter.new
stream = Frappuccino::Stream.new(emitter)

# debug: 送られてきたイベントを画面に出力する
#stream.on_value do |v|
#  puts v
#end

# eventRecordedだったら画面に出力する
stream
  .select {|d| d["method"] == "Timeline.eventRecorded"}
  .on_value {|d| puts d } 

# eventRecordedじゃなかったら"log"というファイルに書き出す
stream
  .select {|d| d["method"] != "Timeline.eventRecorded"}
  .on_value {|d| open("log", "a+") {|f| f.puts d } } 

# (中略: 最初に書いたWebSocketを接続したりする処理)

# データを受け取ったらストリームに流す
ws.on :message do |msg|
  emitter.send JSON.parse(msg.data)
end

これはわかりやすくなったんだろうか?
でもまあ、今回みたいにselectが複数あったりとか、あと畳み込みをしたくなった時には結構いいかもしれません。この例だとzipやmergeはあんまし使わないかなぁ。

しかしストリームをイベントに変換してそれをまたストリームに変換とういのもなんか妙な話ですね。

ノートの使い方

ノートの話をたまに書いているので、じゃあ次はペンの話でも書こうかと思ったけど、ノートの使い方の話は書いてないよねと指摘を受けたので書いてみます。そういやそうだよね。断片的には書いてるけど。

まず基本として、ノートは記憶の補助として使っています。というかそれ以外で何かあるのかな。
その、記憶の中でもかなり短期、1日とか数日とか、おおむね1週間以内の情報を置くために使っています。読み返すとしても数ページ、多くても10ページとかそういう感じで、それ以上前の事はあまり覚えてもいません。それと関係あるかは微妙ですが字は雑です。

それと、1ページの中で日付をまたぐ事もめったにしないので、1〜2行で終わってたり、タイトルだけだったり、ヘタすると日付だけだったりもします。
まあもったいない使い方のような気もしないでもないですけど、余白も情報だと思いますし、詰めて書いて追記できないのもバカバカしいし、「もったいないと思うならリサイクルに出せばいい」と解決になってるんだかなってないんだかわかんない理屈もあります。単に何も気にしていないというだけですが。

書いている内容は、リストです。テーマごとに項目を列挙しているだけです。そのテーマというのが日記(と呼んでる今日の仕事)だったり開発の検討項目だったり議事録だったり作業ログだったりする。で、だいたい1日に数ページ進む。
これを、今自分が何をやっているかを思い出すために使っています。あー議事録だけは普通のメモですけども。

基本的にはスタックというか、気が散ったり別の仕事をしたり飯を食ったり帰って寝たりした後でも作業を迅速に再開できるように残している感じです。なのでまあ、数日前の内容にあまり意味はありませんし、割り込みが無い時や無視していい時、あと割り込まれても復帰が簡単な時はそもそもノートを使ったりしません。
実際就職してから去年くらいまではあんまし使ってなかった。逆に大学でソースコード読みとかしてた頃は数日で1冊とかのペースで消費してる時もありました。call traceとか一瞬目を離したら忘れるし。

あとは、暇つぶしだったりやる気無い時の仕事してるふりだったり、まあそれにしてもリストですね。やりたくない事リストを書いて渋々覚悟を決めたり、やらなくていい理由を考えたり。

それ以外の情報は、予定や締め切りはGoogleカレンダーや会社のグループウェアに書きますし、もう少し広いプロジェクトや進捗状況や議事のまとめは別の資料に書きますし、検討項目も別の資料やプロジェクトのtracとかRedmineとかに書きますし、思いつきはGithubのissueとかTwitterとか、ブログのネタは溜まるとストレスになるから書かないで忘れるに任せる。いや書きかけのテキストファイル結構ありますけども。

というわけで、本当に今やってることや今からやることや今考えたことを書いているだけです。
なのであまり職場以外で持ち歩く必要がなくて、ノートの記事とかで忙しくなったら小さいノートがほしいとか言ってるのは外で仕事の事を考える必要が出た時の事を考えていました。今のところ職場にいる時間を使えば済む程度だからまあいいかなぁと。
あと、こういう使い方なので持ち歩くにしても切り替え時期に2冊持つくらいで済むので、カバンにやさしい。

ノートっていうのは非常に自由度が高い道具なので使い方はそれこそ千差万別で、私とは逆に長期の記憶として使ったり、メモ帳だったり、スケジュール帳だったり、プロジェクト管理だったり、いや後半はノートっていうより手帳かな。違いはよくわかりませんが。
長期の記憶として使う場合は鉛筆で下書きをしたり、下書き用のノートを別に持ってたりするらしいですよ。重要な事は何回書いてもいい。気持ちはわからんでもないけど私は面倒くさい。

ノートなんぞ使わなくていい生活がしたいものです。

アルゴリズム問題

最近、CodeIQというサイトの「今週のアルゴリズム」を解くのが楽しい。元々私はこういうアルゴリズム問題を解くのが非常に苦手なんですが、まあこの「今週のアルゴリズム」の問題は簡単だし。20分とはいえないかもしれないけど1時間もかかんない感じだし。

で、この問題
第2回「今週のアルゴリズム:日付の2進数変換」解説 #ruby|CodeIQ MAGAZINE
日付を例えば2013年12月7日なら20131207という整数値にして、それを2進数に変換して、そのビット列が左右対称になるような日付を、1964年10月10日から2020年7月24日までの間で全て列挙しろ、と。

解き方はおおまかに2種類あって、
(案1) 1964/10/10から日付を加算しながら、数値や2進数に変換して対称の判定をする。
(案2) 左右対称なビット列を列挙して、それぞれが日付として解釈できるかを判定する。

案1の方はまあ簡単です。ああでもHaskellで書いたんで、10進2進変換を自前で書かなきゃいけないのが面倒だった。「日付+1日」というのも無くて、これは+1すればいいだけなので簡単だったんだけど、Rubyにすりゃよかったとちょっと思った。
探索空間は60年分くらいあるのでちょっとアレだが、1年400日としても2万4千個くらいになると見積もった。

案2の方は、左右対称なビット列を作るのが若干面倒だし、Haskellだと文字列を日付として正しいかどうかを判断するのが結構面倒(Data.Time.parseTimeが19656617を平然と1965年12月31日と読んだり。Rubyにすりゃよかった)なので採用しなかったんですが、解説によるとこっちの方が圧倒的に速いらしい。
私の感覚的には10進8桁は30ビット弱くらいだから、左右対称なので半分の15ビット弱くらいになって、まあ3万もいかないだろうけどもどっこいどっこいかなぁと思ったんですが。

本当に簡単だったので案1で5分くらいで書いたと思う。

フィードバックのメールを見ると、アルゴリズム問題なのでできるだけ速い案2で解いて欲しかったと書いてあって、そこまではまあそりゃそうだなんですが、模範解答で「19641010から20200724までは2進数にすると25桁で、12桁と真ん中1桁、12桁も全て1001から始まるので8桁+真ん中1桁の合計9桁、512個の数字を調べればいい」というようなことが書いてあった。
いや、そういうの考えるのが面倒だからコンピュータを使っているんじゃないのか。それにそんなこと言ってたらどこをとっても再利用できないプログラムができてしまうんじゃないか。一般化されてないコードを書くのは苦痛じゃないのか。
と思ったけどもよく考えたら問題文にプログラミングで解決しろとは書いてなかったのでどっちでもよかった。実際過去問見たら手計算で解いてる人もいるみたいだし。

ということでこれはただの自己主張なんですが、私は頭を使うのが面倒なのでコンピュータを使っています。あと、性能より一般化だ。遊びならなおさら。
私はアルゴリズムの高速化問題には向いてないかもしれない。

それはそうと、試しに案2の方も実装してみました。パーサを改造してちゃんとした日付しか読まないようにするのは簡単だったというかパース後の文字列比較で簡単にやった。左右対称なビット列を作るのは意外に面倒でした。小さい順に並べようとすると偶数桁の時と奇数桁の時で分けないといけないし、桁上りのタイミングを見ないといけないし。どうなんだろう。
でもそれらができれば簡単だし、速かった。いやちゃんと測ってないですけど、4倍くらい? 0から20200724までの対称なビット列の数は9027個しかなかった。これだけでも案1の日付数え上げの半分弱くらいで、19641010以上だと137個だから8890個は日付の判定までもいかないから、そりゃ速いわ。

誰か私の代わりにこういうの考える役をやってください。

これコードのネタバレいつまでダメなんでしょうね。