なるほど、これが Git か

実のところ Git によるバージョン管理というのはほぼやったことがなかった。昔むかし、ほんの少しだけ触ってみたくらい。本も軽いものを読んだりはしたのだけれど。

というのも、まあそういう必要性があるようなものを書くことがほぼないというのもあるのか、と思ってはいた。

今回、とある名簿を照合するスクリプトを書くにあたって VS Code と WSL ターミナルを使っていたのだけれど、少しばかり、なんとなくで Git を使ってみることにしたら、ああ、なるほどこういうことかという感じにはなった。

修正しようとするときにブランチ切っておけば確かに安心なのだな。すぐもとに戻せるし、違いもわかりやすい。

まあ、テスト実行してファイルが更新されたりすると都度更新されたからコミットする？　みたいになってしまうのは面倒な気がしないでもない。そのあたりはまあ使い方なのかな。

とりあえずスクリプトは期待通りに動作しているようでなにより。

数独解法に斜め対応させてみた（コードなし）

　ローカルなポイントカードにブルーカードというのがあって、当初は長野県内だけだったのが、その仕組みを他県にもというのがあったようで、いくつかのところでサービスがあるらしい。

　年に二回案内などが届くのだけれど、今回数独のクイズが載っていた。人力で解いてもよいのだけれど、どうせならということで Ruby に解いてもらうことに。

　とはいえいちからコードを書くのはちょっとなので検索すると案外たくさんでてくる。遠藤さんの書かれたものも見つかった。 そのなかのひとつを参考にしてみたのだが、残念ながらこのままでは今回の問題に完全に適合できない。縦、横、ブロックに加えて斜め 2 列もあるのだった。

　手始めに斜めがないままに実行してみるときちんと結果はでるものの、斜め列を見ると同じ数字が出現してしまうことを避けることができない。ほかの縦、横、ブロックは合っている。

　ということでよくわからないままにコードを読んでいっておよその動きを把握したところで斜めの計算も追加してみる。はじめはうまくいかなかったのだが、なんとか動作するようになった。結果を確認してみても問題ないようだ。

　ただ、ここでもう一段考えるべきかというのが、はたして解はこれだけで本当によいのかどうか。あるいは、別解が存在するかもしれないというのをすべて検証するにはもう少し修正しないといけないのだろうなと。さて、どうするか。

　たまの素材なのだから考えてみるべきという感じではあるのだけれど。

　参考にさせてもらったのは、次のページのもの。

[ 【Ruby】【アルゴリズム】数独を解く。プログラミング言語Ruby 学習感想文　～1章 - せかいや ]

＃　コードの差分だけでも gist にあげるべきか否か。

「Re:VIEW+InDesign製作技法」電子書籍版が出た！（達人出版会から）

　[ Re:VIEW+InDesign制作技法 - 達人出版会 ]

　先日あった技術書典というイベントで紙製本された同書を販売されるという話をきいて、達人出版会ででたらよいなあと思ったらほどなく刊行された。ありがたい。

　実は以前（2 年くらいは前か）に idgxml での具体的な使い方のサンプルがあったらわかりやすいのだがということを書いていたら、kmuto さんがサンプルあったほうがやっぱりいいかなと issue を立てられたようだった。が、特に進展のないまま年月が過ぎてクローズされてしまった。

　哀しく思っていたらこういう形が登場した。目次やサンプルを見る限りにおいてだけれど、かなり実際に即した例をあげて（つまり kmuto さん自身が作業されている環境を解説されているようで、かなり有益な情報のように感じられる。

　Re:VIEW についてはEPUB3 の少し前くらいからソースを見たり ML に登録したりもしていたのだけれど、なかでも idgxml 出力による InDesign での利用には可能性を感じていたのだった。といっても使ったこともないし、製版を仕事にしているわけでもないのだけれど、複雑なレイアウトというのでないのであればこれによって作業の効率化が格段に進むのではなかろうという予感だけはあったのだった。

　ことに法令・例規集といった書籍の製版においてはレイアウトはほぼフォーマットがシンプルに決まっているだけなのにひきかえ、内容については随時変更や追加が行われる性質上、Re:VIEW による効果が大きいのではなかろうかと思っていたのだった。まあ、そういう仕事についているわけではないし、希望もしているかなしのつぶてなので携わることもないのだろうとは思うのだけれど。（ということもあって本書の購入にちょっと躊躇している）

　コンピュータ製版といいながら、実態はひどくアナログという印象があるのだけれど、もっともっと自動化というか効率的にできる部分というのは残されているのではなかろうかと。そういうところにはむしろ IT技術者の力が必要なのだろうなと kmuto さんのことを引き合いに出さずとも思うのは間違いではないのだろうなと。

　仕事になるとしたらすぐにでも買おうかと思うのだけれど、どうやらそういう気配はなさそうなのでいずれ趣味として買うくらいになってしまうかもしれない。ということでどちらかというとメモに近いか。

　関係の人には必読といえるかもしれない一冊なのだろうなとは思うのだった。

Cygwin での tDiary がようやく復旧

　復旧中の Cygwin での tDiary。apache2 そのものは起動できているものの、日記ページにアクセスすると index.rb の内容そのものがテキストとして表示されるだけだった。machu さんのおかげで原因はやはり httpd.conf や .htaccess あたりにありそうだということだった。Ruby が実行できていないのは確かだからと。

　で、示してもらったページの情報をつぶさに読んでから確認するとようやく原因が判明。httpd.conf のモジュールロードで cgi がコメントアウトされていた。コメントアウトをはずすとようやく日記が表示された。

　apache 2.24 になってモジュールロードのデフォルトが変更されたというのはほかでも見ていたのだけれど、userdir に関するものだけは修正したものの cgi については気づかなかった。デフォルトを安全よりに変更したということなのか。

　以前のファイルをコピーしたと思っていたけれど、それは tDiary 方面のもので、httpd.conf については過去の記録をもとに修正しただけだったので cgi モジュールのところにまで注意が及ばなかった。あらたな注意点。

　ということでどうにか日記そのものの復旧が完了。このあと全文検索の namazu の復旧にかかることに。

　[ CGIプログラムが動かずにソースが表示される | やってみよう準備室 ]

Ruby-OpenCV をようやくにして試してみる

　先日の NSEG#72 で OpenCV を使った貌認証のデモとか説明とかされたということで、なかなか評判だったらしい。ふと見ていたら ruby-opencv という gem を作られている人があるということで、それならちょっと試してみようと思ったのだった。

　さて、どういう環境でまずは試そうかと思ったのだけれど、Virtual Box の Ubuntu で試すことにした。まずは OpenCV 本体のほうは説明にしたがって必要なライブラリなどをインストールしてから進めれば問題は特になかった。ところが ruby-opencv.gem をインストールする段階でうまくいかない。開発ツールを先にインストールしろとかいろいろ言われたりする。

　調べているとどうやら OpenCV の最新の 3 には対応できていないようだということがわかる。そこで 2 系の最新にしてみたが、どうやらこれでも駄目らしく、確かに GtHub の当該ページの説明には 2.4.10 だかをサポートという記載が。

　ということであらためて OpenCV を 2.4.10 にしなおす。

　このあたりでそういえばと何を血迷ったか rbenv ってあったのだなと思い出し、導入してみることに。（このあたりは先のところ参照）バージョン管理やら異なるバージョンの使い分けなどで便利なのだなと遅ればせながら実感したりしたわけ。

　ということもあり Ruby-2.3.0 をインストール。それではと ruby-opencv.gem のインストールをするがやはり失敗してしまう。検索してみてもこれという解答が見つからない。で、ようやく気づいたのは Ruby のバージョンも少し戻すべきなのではないかということ。

　そこで、2.2.4 にしてみる。ところがこれでもインストールに失敗する。そこで、オプションを指定すればいけるというようなヒントもあったので、それを試すと今度はインストールできた。そういうものなのか。

--with-opencv-include=/usr/local/include/opencv --with-opencv-lib=/usr/local/lib

　上記をつけて gem install ruby-opencv したらインストールできた。ためしに Ruby-2.3.0 でやっても駄目だった。（当然ながら OpenCV をインストールしたパスを指定するわけで、/usr/local 以下にインストールした場合でのこと）

　ようやく使えるようになってまずは手始めのサンプルで画像表示とかさせたところの今ここ。貌認識テストまではまだもう少し。

とある数列のリハビリプログラミング

　きむらさんとこのとある数列を求める関数の話をみて、リハビリにとはじめてみたら腕に覚えなしを自覚しただけだったりはした。

　はじめはまず素直に平方数を除くというチェックをしつつカウントしていって求めるという方式で。ただ、これだとあまりにベタなのでもう少し考えようと思った。

　ということである程度実際に出力させてみて、どのような法則性を持つ数列なのかを考えてみることにした。で、最終的にもう少しシンプルな感じのものができたのだけれど、解答を見たら数式として算出していて「あー、そういう方向か」と。それはなかなかたどりつけない。

　それはそうと、最後のほうでふたつの紹介されている数式で食い違いがあるのだけれどと書かれていて、Ruby で確認したところでは確かにそのとおり。しかも、まるっきりうまく機能していないみたい。ただ、例示されている数式はそこで使っている isqrt という関数を利用してのことなので（平方根を整数にして返すらしい）その挙動いかんで結果が異なるのかもしれないので、なんともいえないなというのは同感。

　とはいえ、そうなると非常に言語設計に依存する解というのは、いまひとつよろしくないのかなと思ったりは。はじめのほうは間違いなく動作するので。

　などとちょっとリハビリになったかしらと思っている節分。豆まきもしなくなって幾年。豆食べることもなくなって幾年。

＃　Gist に置いてみた。

　[ 平方数を除く 2,3,5,6,7,8,10... という数列で、指定番目の数を返す関数 ]

　はじめに考えたのが fig2 でその後考えたのが fig3 。fig4 と fig5 は解答にあった数式ふたつのもの。fig5 のほうは少なくとも Ruby でこれを実行すると正しい答えにならない。

Ruby-2.3.0 x64 にする

　クリスマスリリースされた Ruby-2.3 の MSI パッケージを arton さんが公開してくださったので、いつものようにインストール。ふと思うに今回はいよいよ 32 ビットパッケージは作られないのかなと。実際 OS 方面もかなり 64 ビットが普通になっているようでもあるし、そろそろいいかなということなのかなと。

　で、実は 2.2 のときの 64 ビット版はコンソールを開いたときに異様に時間がかかっていて気になっていた。それを理由に普段は 32 ビットのほうを使っていたりもしたのだった。パッケージのサイズそのものもかなり大きなもので（今回の 2.3 と比べても二倍あまりはあったか）、そんなこんなであれやこれやの処理に時間がかかって遅くなっているのだろうか、などとは思っていた。

　もっとも、一度コンソールを開いてしまえば、終了させてあらためて実行してもそう遅くはなかったのだけれど、なにしろいつもコンソールを開いているというほどには使っていないのもあり、やはり 32 ビットのほうでよいかと思ってしまっていた。

　それが 2.3 では気持ちよく開いてくれるのでこれなら 32 ビットがなくても問題ない。いや、ことによればもろもろ追加されたりすると遅くなったりすることもあるのかもしれないけれど、まあ、そのときはまたそのときということで。

　とりあえずもろもろ普段使いのスクリプトにも問題のないことを確認。長いことためしに動かしていた「点取り虫ゲーム」は、今となっては　Tcl をインストールしていないので動かすこともなく。しかし、いまだに「Ruby/Tk」とかで検索があるので使われることはあるのだろうなとは思いつつ、自分にとってはこのところご無沙汰になってしまったので。

　いずれにしても、arton さんにはいつも感謝しています。

13日の金曜日の出現頻度を調べてみる

　ふと 13 日の金曜日なのだなと思ったら、どれくらいの頻度であるものなのだろうかという疑問が浮かんだので Ruby に調べてもらうことにした。チェックそのものは特に面倒なことはなくて、

if 5 == Date.new(year, month, 13).wday

　であれば出力するとかにするだけ。もろもろの集計をどうするかとか、調べる年代の幅をどう入力するかとか、そういう周辺のところでスクリプトが少し長くなるけれど。

　ひとまず実行してみるとどうやらだいたい毎年一回はあるらしいということはわかった。最大で三回。多くは 2 月、3 月、11 月の組み合わせだが、1 月、4 月、7 月という組み合わせもあるらしい。

　合致しない月というのはなくて、十分に長い期間（15 年くらいでもそれがわかるが）を調べるとおおむねどの月も同じくらいに出現する。

　ざっと見ていると一回だけのときは、必ず決まった月（ひとつというわけではない）である傾向がありそうだったり、二回というときもその組み合わせはほぼ決まっているようには見える。まあ、当たり前といえば当たり前ではあるかも。

　このあたりは少しスクリプトを修正してもう少しきちんと集計してみたいかなと。

　一方で年代を遡って「0 - 2000 年」とかにしたら 1582 年 10 月で不正な日付だといわれてしまった。なにかと思ったら1582/10/15 が暦のいわばゼロ位置とでもいうのかに設定されているので、そのあたりの関係でそこをまたぐとおかしくなるということのようだった（正確な理解ではなくてあくまでも感覚的なものとして）。詳細を知るには暦の世界は深い。

2000-10-13

:2000: 1 times
2001-04-13
2001-07-13
:2001: 2 times
2002-09-13
2002-12-13
:2002: 2 times
2003-06-13
:2003: 1 times
2004-02-13
2004-08-13
:2004: 2 times
2005-05-13
:2005: 1 times
2006-01-13
2006-10-13
:2006: 2 times
2007-04-13
2007-07-13
:2007: 2 times
2008-06-13
:2008: 1 times
2009-02-13
2009-03-13
2009-11-13
:2009: 3 times
2010-08-13
:2010: 1 times
2011-05-13
:2011: 1 times
2012-01-13
2012-04-13
2012-07-13
:2012: 3 times
2013-09-13
2013-12-13
:2013: 2 times
2014-06-13
:2014: 1 times
2015-02-13
2015-03-13
2015-11-13
:2015: 3 times
2016-05-13
:2016: 1 times
2017-01-13
2017-10-13
:2017: 2 times
2018-04-13
2018-07-13
:2018: 2 times
2019-09-13
2019-12-13
:2019: 2 times
2020-03-13
2020-11-13
:2020: 2 times

2000 - 2020 : 37 times
MAX : 3 times, [2009, 2012, 2015]
1 : 3 times
2 : 3 times
3 : 3 times
4 : 4 times
5 : 3 times
6 : 3 times
7 : 4 times
8 : 2 times
9 : 3 times
10 : 3 times
11 : 3 times
12 : 3 times

irb のバックスペースがちょっと変

　久しぶりに irb を使ったら、コンソールの挙動がちょっとおかしかった。バックスペース。

irb> abcd

　と言う感じに入力してバックスペースを打つと、

irb> ab_d

　みたいになる。カーソル位置はアンダーバーのところ。残像みたいに残るのもあってどこまで訂正されているのか心配になりよろしくない。

　で、昔 2009 年の 1.9.x のころにもなにかおかしな挙動があってパッチを作ってもらったようだったのは思い出せた。久々なのでいつからこうなのかはわからないけれど、やはりバックスペースがうまく追随していないと使いにくい。

　以前は readline がどうのこうのという話もあったような、なかったような。さて。

Natto と Ruby バインディングの使用感

　コードを比べると Natto のほうが楽に書けるのかもしれない。

　Natto を使うと、

require 'natto'

sentence = "太郎はこの本を二郎を見た女性に渡した。"

nm = Natto::MeCab.new
nm.parse(sentence) do |n|
print n.surface, "\t", n.feature, "\t", n.cost, "\n"
end

nm = Natto::MeCab.new('-F%m\t%f[0]\t%f[7]')
enum = nm.enum_parse(sentence)
enum.each {|n| puts n.feature if !n.is_eos? }

　とすると、

太郎 名詞,固有名詞,人名,名,*,*,太郎,タロウ,タロー 8614

は 助詞,係助詞,*,*,*,*,は,ハ,ワ 9699
この 連体詞,*,*,*,*,*,この,コノ,コノ 9755
本 名詞,一般,*,*,*,*,本,ホン,ホン 14548
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ 13738
二 名詞,数,*,*,*,*,二,ニ,ニ 16665
郎 名詞,一般,*,*,*,*,郎,ロウ,ロー 21808
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ 20998
見 動詞,自立,*,*,一段,連用形,見る,ミ,ミ 25194
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ 22795
女性 名詞,一般,*,*,*,*,女性,ジョセイ,ジョセイ 25091
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ 24938
渡し 動詞,自立,*,*,五段・サ行,連用形,渡す,ワタシ,ワタシ 28035
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ 27158
。 記号,句点,*,*,*,*,。,。,。 23724
BOS/EOS,*,*,*,*,*,*,*,* 22188

太郎 名詞 タロウ
は 助詞 ハ
この 連体詞 コノ
本 名詞 ホン
を 助詞 ヲ
二 名詞 ニ
郎 名詞 ロウ
を 助詞 ヲ
見 動詞 ミ
た 助動詞 タ
女性 名詞 ジョセイ
に 助詞 ニ
渡し 動詞 ワタシ
た 助動詞 タ
。 記号 。

　といった結果が。

　一方で MeCab の Ruby バインディングを使うと、

require 'MeCab'

m = MeCab::Model.new().createTagger()
puts m.parse(sentence)

n = m.parseToNode(sentence)
while n do
print n.surface, "\t", n.feature, "\t", n.cost, "\n"
n = n.next
end

太郎 名詞,固有名詞,人名,名,*,*,太郎,タロウ,タロー

は 助詞,係助詞,*,*,*,*,は,ハ,ワ
この 連体詞,*,*,*,*,*,この,コノ,コノ
本 名詞,一般,*,*,*,*,本,ホン,ホン
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
二 名詞,数,*,*,*,*,二,ニ,ニ
郎 名詞,一般,*,*,*,*,郎,ロウ,ロー
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
見 動詞,自立,*,*,一段,連用形,見る,ミ,ミ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
女性 名詞,一般,*,*,*,*,女性,ジョセイ,ジョセイ
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
渡し 動詞,自立,*,*,五段・サ行,連用形,渡す,ワタシ,ワタシ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
。 記号,句点,*,*,*,*,。,。,。
EOS

BOS/EOS,*,*,*,*,*,*,*,* 0
太郎 名詞,固有名詞,人名,名,*,*,太郎,タロウ,タロー 8614
は 助詞,係助詞,*,*,*,*,は,ハ,ワ 9699
この 連体詞,*,*,*,*,*,この,コノ,コノ 9755
本 名詞,一般,*,*,*,*,本,ホン,ホン 14548
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ 13738
二 名詞,数,*,*,*,*,二,ニ,ニ 16665
郎 名詞,一般,*,*,*,*,郎,ロウ,ロー 21808
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ 20998
見 動詞,自立,*,*,一段,連用形,見る,ミ,ミ 25194
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ 22795
女性 名詞,一般,*,*,*,*,女性,ジョセイ,ジョセイ 25091
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ 24938
渡し 動詞,自立,*,*,五段・サ行,連用形,渡す,ワタシ,ワタシ 28035
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ 27158
。 記号,句点,*,*,*,*,。,。,。 23724
BOS/EOS,*,*,*,*,*,*,*,* 22188

　という感じに。

　Natto を使うと基本的に Natto::MeCab.new だけすれば、あとは Node ごとに処理するにしても、enum_parse() ですむ。バインディングのほうだと Model を生成して tagger を生成して、Node でパースしてみたいな繰り返しでいろいろ長くなってしまう。

　用途にもよるのかもしれないけれど、あまりこだわったことをしないのならば、Natto を使うほうがシンプルで楽かもしれない。

　用例がまったく同じとはいえないので微妙なところはあるけれど。なんとなく。

Natto で MeCab を試す: つらつらぐさ
久々に MeCab.so を作ろうとしたらいろいろ大変だった（at Windows）: つらつらぐさ