enumerable-lazyという古いgemがあるのだが、なんかこれのリリースをしてほしいという連絡が来た。deprecatedなgemのライセンスがrubygems.org上で明示されていることにどれほどの意味があるのか分からないが、とりあえずやってみることに。

と思ったがgemのpushが通らない。そういえば、rubygems.orgのアカウントを2つ持っていることを思い出した。rubygems.orgって大昔はgemcutter.orgという名前だったんだけど、サイト名が変わるときに間違って新規登録しちゃったんだよな、確か。

ということで古いアカウントでログインし直す必要がある。面倒だ。とりあえず~/.gem/credentialsをリネームして読めないようにして、以下を実行。

% gem owner enumerable-lazy --add (新しいアカウントのメールアドレス)

EmailとPasswordを聞かれるので、古いアカウントでログイン。これでgemのownerを追加できたので、~/.gem/credentialsをもとに戻してrake release。

ということで無事リリースできましたが、Enumerable#lazyはRuby 2.0から本体に取り込まれているので、いまさらインストールする必要は全く無いですよ！

(2016/10/05追記：issueで教えてもらったのだけど、grape 0.16.2→mustermann19→enumerable-lazyという依存関係だったみたい。そのため古いgrapeを使っているとlicense_finderでエラーが出ると。最新のgrapeではこの依存は取り除かれている。)

Twitterにはスライドを貼ったんですがブログに書いてなかったので載せておきます。

Fluentd meetup in Matsue

fluentdコミッタのtagomorisさんが松江に来られるというので発表してきました。fluentd印の魔剤エナジードリンク美味しかったです。

内容はfluentdと直接の関係はないですが、ログつながりということで…。 文中、RailsのproductionのログレベルがINFOと書いていますが、Rails5からはDEBUGだそうです。

There is a guide for adding basic auth to your Sinatra app. Password is hardcoded in the short example, but in production, you may want a securer way.

bcrypt is the gem for you.

bcrypt

Add gem "bcrypt" to your Gemfile. (Don't confuse it with bcrypt-ruby gem, which is its former name)

Then you can generate a password hash like this:

When you do google search with "sinatra logging file", you may find a solution with Rack::CommonLogger. However I was looking for a different approach because it does not respect interface of the logger stdlib. Instead of calling the usual logger.info, Rack::CommonLogger forcefully inject output with logger.write.

As a result, your log file will look like this. The first line is written by Rack::CommonLogger, which has completely different format with the usual logger output on the second line. This may be a problem when you write a program to parse and analyze the logfile.

::1 - - [27/Sep/2016:02:44:42 +0900] "GET / HTTP/1.1" 200 2 0.0077
I, [2016-09-27T02:44:42.416430 #49814]  INFO -- : hello world

Usually you can install rogue with Homebrew(brew install rogue). However, when you want to read the source code, you may want to compile it by hand. Here's how (based on the recipe file).

1. Download http://pkgs.fedoraproject.org/repo/pkgs/rogue/rogue5.4.4-src.tar.gz/033288f46444b06814c81ea69d96e075/rogue5.4.4-src.tar.gz and extract it
2. (Optionally run git init; git add .; git ci -m "untar" so that you can easily check what you've changed)
3. run brew install ncurses
4. run CPPFLAGS="-DNCURSES_OPAQUE=0" ./configure
5. run make
6. run ./rogue and the game will start.

自分のサーバにデプロイして、外から見えるようになった。実はRubyKaigiの初日くらいにデプロイしてたんだけど、新規記事の作成ができなくなっていて、ちょっと間が空いてしまった。

バグ自体は既知のもので手元では直していたのだが、git pushを忘れていて修正前のものがデプロイされていたのだった。それとは別にSinatraのloggerがログを記録してくれない？という現象があり、原因を把握するのが大変だった。Sinatraのログについては別途記事を書く。

なんか色々やった。だいぶブログらしくなってきたと思う(見た目的にはまだまだだけど、機能として)。この装飾がなさすぎる感じ、逆にいいかもという気分になってきた。redcarpetでmarkdownをレンダリングするようにしたので、リストとかはちゃんと使えている。

タイムゾーンについて

現在はDBにはUTCで保存していて、設定ファイルでユーザ(書き手)の好きなタイムゾーンを設定できるようになっている。こういう構成なので、日付を扱うときはつねにタイムゾーンについて考慮する必要がある。

今日ちょっと問題になったのは、編集画面のdatetime入力欄。前回決めたように各記事がdatetime(記事の日付と、ソートのための時刻)をもつのだけど、これを入力するのにTime.parseを使うと、「2016-09-07」とだけ書いたときにどうなるだろうか？

答えは「デプロイしたサーバのタイムゾーン設定の影響を受ける」で、このままだとトラブルの予感がひしひしとするので、設定ファイルのタイムゾーンと見なしてパースさせたい。調べてみると、ActiveSupportにTime.zone.parseというそのものずばりなメソッドがあったので、それを使うようにして解決。

そういえば日付の扱いについてちゃんと考えてなかったが、思ったより複雑っぽい。

• post.date
  • ユーザが入力する
  • 記事のURLに含まれる
• post.published_at
  • 記事が最初に一般公開状態になったときに設定し、変更はしない
  • フィードのpublished欄に使用
• post.updated_at
  • (ActiveRecordによって)自動的に設定される

これは3番目の記事である。

一応、管理画面ができて、記事を書けそうな感じになってきた。それはいいけど、管理画面の実装とRSpecによるテストとあれやこれやを一度にやってたらdiffがぐちゃぐちゃになってしまった。

まあ一人プロジェクトだし最序盤だからモノリス的コミットになってしまうのは別にいいといえばいいんだけど、現状が把握できなくなると急速にやる気が失われていくという問題があって、それはとてもまずい。

趣味プロジェクトであっても、モチベーションを維持していくためにはちゃんと「やることリスト」みたいなものを作った方が良いのかもしれない。そうすれば「いま何の作業をしているのか」が明確になるし、達成感もより短いスパンで得られるようになるはず。

とりあえず日付を入力する欄がないことに気づいたので次はそれだな(この記事は2016年8月24日に書かれた)

前回からちょっと間が空いてしまった。これは二番目の記事である。

とにもかくにも、記事を書く機能を優先して作ったほうが良さそうだ。前回と同じくこの記事もviews/index.slimに直書きしている。このままでは単なる日記になってしまう。

記事の保存先はRDBにする予定だ。jekyllなどのように静的ファイルをコンパイルすることも考えたけど、「ブラウザ上で記事を書きたい」という要件があるので、普通にActiveRecordでやるのが実装が一番簡単だという結論になった。