忘れたときに備えた記録

トップ 追記
2005|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|11|12|
2009|01|02|03|04|05|06|10|12|
2010|06|07|08|12|
2011|07|09|
2012|09|11|
2013|02|03|09|
2015|10|11|
2016|01|08|11|
2017|02|08|10|
2018|11|

2018-11-24(Saturday)

bundlerでgemを入れる環境でcommandline toolを簡単に作る

あららお久しぶり。なんと1年ちょっとぶりでございます。

さて、Thorでどうこうというお話ではありません。いや、試していないんですけど、多分。

Rubyでコマンドラインツールを作るときに、bundlerで入れるgemを使うけど、このgemは他の混ざらないように以下のように入れるとしましょう。

hiraku@shako:~/mytool$ bundle --path=.bundle
Fetching gem metadata from https://rubygems.org/.............

まあ、よくあるパターンです。

こういう状態で、スクリプトを以下のように無造作に書いてしまうと

#!/usr/bin/env ruby

require "bundler/setup"
require "nokogiri"
p Nokogiri

Gemfileを置いてるディレクトリだと問題なく実行できるんですが

hiraku@shako:~/mytool$ ./mytool.rb 
Nokogiri

他のディレクトリから実行しようとするとエラーになります。

Traceback (most recent call last):
	2: from /home/hiraku/mytool/mytool.rb:3:in `<main>'
	1: from /opt/ruby/2.5.0/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
/opt/ruby/2.5.0/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- nokogiri (LoadError)

(今時2.5.0なのは気にしないでください…)

Railsなんかだと、 config/boot.rb で以下のように書いてあったりします

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)

require 'bundler/setup' # Set up gems listed in the Gemfile.

でも個人的にスクリプトの中で環境変数を書き換えるのはちょっと気が引けて(我儘)、もうちょっと簡単にかけないかと思いついたのがこんな書き方です。

Dir.chdir(__dir__){ require "bundler/setup" }

スクリプトの中で一瞬だけchdirするのが気持ち悪いという説がありそうな気もしますが、メリットもあって、bin/sub/foo.rb みたいにちょっと深めのディレクトリに配置しても(するなよ)同じ書き方で通用します。Railsのよりもちょっと短いし、環境変数どれだっけと思い出すのに苦労せずにすみます。

「…あのディレクトリ取る変数、何だっけ」

どっとはらいヽ(´−`)丿

Tags: Ruby

2017-10-31(Tuesday)

Asakusa.rbに出てtranspecを教えてもらうの巻

去年の8月9日から時々Asakusa.rbに行っては自作のgemの近代化と称してrspec2から3への書き変えをしていたのですが、今日、transpecと言うものを教えていただいて試したら、一発ですべて終わってしまいました!!??

hiraku@ikradon:~/work/eim_xml$ transpec
Copying the project for dynamic analysis...
Running dynamic analysis with command "bundle exec rspec"...
...............................................................................................................

Deprecation Warnings:

Using `should_receive` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /tmp/d20171031-16790-naisb6/eim_xml/spec/dsl_spec.rb:36:in `block (2 levels) in <module:M>'.

Using `should` from rspec-expectations' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = :should }` instead. Called from /tmp/d20171031-16790-naisb6/eim_xml/spec/dsl_spec.rb:21:in `block (2 levels) in <module:M>'.


If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
`config.raise_errors_for_deprecations!`, and it will turn the
deprecation warnings into errors, giving you the full backtrace.

2 deprecation warnings total

Finished in 0.27722 seconds (files took 0.37989 seconds to load)
111 examples, 0 failures


Gathering the spec suite data...

Converting spec/assertions_test.rb
Converting spec/dsl_spec.rb
Converting spec/eim_xml_spec.rb
Converting spec/formatter_spec.rb
Converting spec/helper_coverage.rb
Converting spec/parser_spec.rb
Converting spec/xhtml_spec.rb

Summary:

391 conversions
  from: obj.should
    to: expect(obj).to
226 conversions
  from: == expected
    to: eq(expected)
22 conversions
  from: =~ /pattern/
    to: match(/pattern/)
13 conversions
  from: obj.should_not
    to: expect(obj).not_to
11 conversions
  from: lambda { }.should
    to: expect { }.to
10 conversions
  from: obj.should_receive(:message)
    to: expect(obj).to receive(:message)

673 conversions, 0 incompletes, 0 warnings, 0 errors

Done! Now run rspec and check if everything is green.

これはすごい


2017-08-04(Friday)

Visual Studio Code用のUnityDebugger

突然ですが、うまいこと設定すると、UnityのデバッグにVisual Studio Code(以下code.exe)を使えるじゃないですか。Visual Studioよりも起動が速かったり、gitの操作をcode.exeからできたりして、お気に入りなんです。

ところが時々、"Unexpected number in JSON"とか言ってデバッガーが止まっちゃうのです。DateTime型の変数をマウスホバーして表示しようとした時とか。

こんな感じで。

DateTimeにホバーするとエラーで落ちるの図

仕事で使っててちょっとあずましくなかったので、原因を一瞬調べたんですが、結構根が深い感じで、結局報告だけしておいたのです。

でも、ど~にも気になったんで、今日(もう昨日か)帰ってきてから、ちょっと本腰入れて調べてみたのですよ。 すったもんだの挙句、できあがって提出したプルリクが こちら です。 jsでちょろっと直せるっしょ、とか思ってたらUbuntuでMonoのコードをビルドする環境が必要だったりして、いやはや大変でした。

実は1回、間違って修正できていないコミットを送ってしまったのですが、今度は大丈夫なはず…。

手元でビルドしたものをこちらに用意したので、code.exeでUnityの開発をしている方がいたら、試してみてください。

http://www.hiraku.ro/files/unity-debug-1.2.1-fix45.vsix

僕の環境ではこんな感じで、ちゃんとDateTimeをホバーして表示できています。

DateTimeにホバーしても落ちないの図

さ~これでお仕事も捗るぜ!! …えっ、Unityのお仕事はあと1日で終わり!?

どっとはらいヽ(´−`)丿