ときどきVERSIONの定義されていないgemに遭遇するので、備忘録として書いておく。
VERSION の無いgemいくつかのパターンがある。
VERSION は定義してあるのに require されていないケース
VERSION のようなものを定義しているケース
Bundlerで取得すれば、確実に文字列のバージョン情報を得ることができる。
Bundler.definition.specs['database_rewinder'][0].version.to_s #=> "0.9.4"
あとはVSCodeなどでコンテナにアクセスするなどして編集すればOKそうです(もしくはvimとか入れてコンテナ内で編集するとか)
この記事を読んで「ホスト側で編集するようにできそう」と思ったので、試しに開発環境を作ってみた。
まず、Gitリポジトリをクローンします。
$ git clone https://github.com/rurema/doctree.git
rurema/doctree のディレクトリ直下に Dockerfile を作ります。
FROM ruby:2.7.0 WORKDIR /home RUN gem install --no-document bundler:1.16.1 COPY Gemfile ./ COPY Gemfile.lock ./ RUN bundle install ENTRYPOINT ["bundle", "exec"]
次に docker-compose.yml を作ります。
version: "3.8" services: rurema: build: . volumes: - .:/home - html-data:/home/_site environment: HTML_DIRECTORY_BASE: _site nginx: image: nginx:alpine volumes: - html-data:/usr/share/nginx/html:ro ports: - "80:80" volumes: html-data:
htmlを誤ってコミットしないように、 .gitigreno に記載されていた _site にhtmlを出力するようにしてある。
$ docker-compose run rurema rake
複数のバージョンをビルドすると時間かかるので、普段はバージョンを指定してビルドした方が良いかも。
$ docker-compose run rurema rake statichtml:2.7.0
$ docker-compose up nginx
http://localhost/2.7.0/ をブラウザで開くとhtmlを確認できる。
定期的にDevise批判の話が出てくるので、個人的な考えを書いてみます。
「認証自作、 Rails 、 Devise」の記事で以下のような記載がある。
「Rails について深い理解がないならば、 Devise は使うな」とあります。この方針は10 年近く前から書かれています。
これ元の英語とあってない気がするんですよね。
If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we advise you to start a simple authentication system from scratch. Here's a few resources that should help you get started: - Michael Hartl's online book: https://www.railstutorial.org/book/modeling_users - Ryan Bates' Railscasts: http://railscasts.com/episodes/250-authentication-from-scratch and http://railscasts.com/episodes/250-authentication-from-scratch-revised - Codecademy's Ruby on Rails: Authentication and Authorization: https://www.codecademy.com/learn/rails-auth Once you have solidified your understanding of Rails and authentication mechanisms, we assure you Devise will be very pleasant to work with. 😃
私には「最初のRailsアプリではDeviseを使わず、シンプルな認証機能を自作して理解を深めるのを勧める」「Railsと認証メカニズムの理解を深めたら、Deviseが快適に動くのが分かるよ」くらいの内容に読めました。1
試してみた。
require "devise/version" Devise::VERSION #=> "4.7.2" user = User.create(email: 'a@example.com', password: 'password') user.to_json #=> => "{\"id\":1,\"email\":\"a@example.com\",\"created_at\":\"2020-08-16T08:31:36.558Z\",\"updated_at\":\"2020-08-16T08:31:36.558Z\"}" user.attributes.to_json #=> "{\"id\":1,\"email\":\"a@example.com\",\"encrypted_password\":\"$2a$12$ECNX7kXJQKMSBp8xDcy5neVs/2NeuTdcqVnPyUbcy8fp.p4EWfBa6\",\"reset_password_token\":null,\"reset_password_sent_at\":null,\"remember_created_at\":null,\"sign_in_count\":0,\"current_sign_in_at\":null,\"last_sign_in_at\":null,\"current_sign_in_ip\":null,\"last_sign_in_ip\":null,\"confirmation_token\":null,\"confirmed_at\":null,\"confirmation_sent_at\":null,\"unconfirmed_email\":null,\"failed_attempts\":0,\"unlock_token\":null,\"locked_at\":null,\"created_at\":\"2020-08-16T08:31:36.558Z\",\"updated_at\":\"2020-08-16T08:31:36.558Z\"}"
attributesメソッドには全属性が含まれちゃうので、漏れる可能性はありそう。
ただ、これDeviseの問題なのかな...。
IPアドレスがDBに保存されている場合2、認証を自作してたとしても実装ミスると漏れるときは漏れると思うんですよね。
Twitterやはてブで「レビューで防ぐべき」とかあったけど、レビューのような人依存な対策だと漏れがあるので、テストコード書くのが良いかなと思いました。
# spec/rails_helper.rb RSpec.configure do |config| # html/jsonに含まれてたらヤバそうな文字列を列挙しておく secrets = %w[password lastSignInIp] config.after(type: :request) do |ex| secrets.each { |secret| expect(response.body).not_to include(secret) } end config.after(type: :system) do |ex| secrets.each { |secret| expect(page.body).not_to include(secret) } end end
カバレッジがある程度高ければ、上のコードでだいたい防げるんじゃないかなと。
個人的な経験ですが、認証機能が少ないままで済んだ事がないです。
のような要望が後から出ることが多い。
特に認証機能はプロジェクト初期に作られるためテストコードが不足していたり、誰も壊したくないので条件分岐が雑に増えていってAbcSizeが高くなる状況が生まれやすいです。
認証機能を自作する自信がないなら、最初からDeviseを使っておくのが無難じゃないかなーと思ってます。
Deviseのコード読んだ上で認証機能を自作できるレベルの人ならまだしも、「Devise使うのは危ないようなので自作しました！」とかのレベルの人は大人しくDevise使っておけと思う。
— 神速 (@sinsoku_listy) 2020年8月16日
お金あるなら Deviseを使い慣れているフリーランス や 技術顧問 してる人と短期の契約をして、相談するのも良いと思います。
少なくとも以下の調査はしておいた方が良いです。
Deviseにあるような機能は将来に必要になる可能性が高いので、ある程度は考慮しておいた方が良いです。
あと、Deviseを避けて認証機能を自作した結果、Deviseが何年も前に対応済みの脆弱性を再実装するのは勿体ないです。
Deviseが最高の認証ライブラリとは思ってないけど、十分に便利なライブラリだとは思ってます。
認証機能のセキュリティをちゃんと考えて実装できる人はさておき、Rails初心者〜中級者ならDeviseを使うでも良いのかなと。
仕事のコミットメッセージは雑になっていることが多い。
それを解決する方法を考えていたらふと思いついたので、ブログに書いておく。
git show コマンドでコミットのログとdiffを表示するバグ対応で関係あるコミットを見つけたとき、そのコミットの意図を調べる時間が短いほど高得点...みたいな意図で点数を配分してます。
以下のように自分のユーザー名を author で指定しつつ、3ヶ月前のコミットをランダムで5つ選ぶ。
$ git log --author=sinsoku \ --since="4 months ago" --until="3 months ago" \ --no-merges --oneline | sort --random-sort | head -n 5
「3ヶ月前の自分は他人」という言葉もあるけど、自分のコミットは説明できるかどうか？
定期的に合計点を計測しておけば、自分のコミットメッセージの改善を定量的に測れるかも。
authorを指定しないことでリポジトリにコミットしていた人の全員を対象にできます。
（コミット数は5よりもメンバー数にして、1人1コミットを説明する方が良さそう）
$ git log \ --since="4 months ago" --until="3 months ago" \ --no-merges --oneline | sort --random-sort | head -n 5
文字通り「他人の書いたコミット」を git show で表示し、その人の前で説明するのは面白いと思う。
ただ、"レビュー指摘修正" みたいな雑コミットが当たると気まずくなる可能性はある。
2つのリポジトリ（2つのチーム）で合計点を競う。
などチームのメンバーを混ぜると面白いと思う。
これ読んで「他チームの仕様を説明できる必要があるのか？」と思う人がいると思うけど、いきなり別チームに異動することはある。
人事異動はいつだって突然降ってくる。
深夜に思いついたネタを適当に書いた。
仕事のリポジトリで試してみたい。
Twitterの140文字だと説明しづらいので、ブログに書く。
a001から分岐してb001-003まで3つコミットをした後、b001のコミットを修正したいケース。
git rebase -i を使って、b001のコミットを edit にする。
詳細はググれば出てくるので省略。
b001の一部を修正したコミットb004を用意します。
git rebase -i a001 すると以下のような状態でエディタが開く。
pick a001 hello pick b001 foo pick b002 bar pick b003 buz pick b004 fix_foo
これの順番を入れ替えて、b004をfixupに変える。
pick a001 hello pick b001 foo fixup b004 fix_foo pick b002 bar pick b003 buz
保存してエディタを閉じると、b001のコミットにb004のコミットを混ぜる（一部を戻す）ことができる。
git rebase --abort で戻れるcommit --fixup と組み合わせるとより便利git checkout <sha1> -- <path> などで作っても良いgitで変更を部分的に戻す場合、逆マージ的なコミットを作って、rebase -i のsquashで相殺するのが楽。この説明で分かる人がいるか分からんけど。。。
— 神速 (@sinsoku_listy) 2013年5月21日
a001から分岐したfeatureブランチでb001のコミットをした後、別の作業を依頼されたケース。
別ブランチをa001から切って、作業を進める。
とりあえずb001をリバート（b001'）して、別の作業を済ませて c001 のコミットを作ります。
次にc001だけを持つブランチを作ります。
$ git switch -c fix_bug $ git rebase -i a001 # エディタが開くので、c001 のコミットだけ残す
fix_bugのブランチでプルリクを作ったら、元のブランチに戻ってリバートコミットを取り除きます。
$ git switch feature_1 $ git rebaes -i a001 # エディタが開くので、b001'とc001のコミットを取り除く
最終的に以下のようなグラフになって、b001から作業を再開できる。
bundle-install に時間がかかるけど、これを回避できるGitでrevertした後のコミットはcherry-pickしやすい。
— 神速 (@sinsoku_listy) 2020年2月10日
master - A - A' - B(dev)
こういうコミットの時、masterからブランチ切って、Bをcherry-pickする。
次にdevブランチからA'とBのコミットを取り除くとAの状態に戻せる。
読んでみたけど、Twitterだと全く伝わらないな。
ブログに書いてみたけど、やっぱり分かりづらい。
タイトルの通りなのですが、普通にやると意図した動きしなかったのでメモ。
factory_bot が分かりやすいです。
bundle install はしてあるgemfiles/6.0.gemfile を使って "bundle install" したい
具体的なコマンドは以下の通り。
$ git clone --depth 1 https://github.com/thoughtbot/factory_bot.git
$ cd factory_bot
$ bundle install
$ bundle exec ruby -e 'system({ "BUNDLE_GEMFILE" => "6.0.gemfile" }, "bundle check", chdir: "gemfiles/")'
Could not find zeitwerk-2.1.9 in any of the sources
Run `bundle install` to install missing gems.
bundler経由で実行すると RUBYOPT="-r/usr/local/lib/ruby/2.7.0/bundler/setup" がセットされるので、これを上書きすると動く。
$ bundle exec ruby -e 'system({ "BUNDLE_GEMFILE" => "6.0.gemfile", "RUBYOPT" => ""}, "bundle check", chdir: "gemfiles/")'
The following gems are missing
* zeitwerk (2.1.9)
* childprocess (2.0.0)
* aruba (0.14.11)
* simplecov (0.17.0)
Install missing gems with `bundle install`
bundle install する前なので、正しく 6.0.gemfile を参照してる挙動になった。
Bundler.with_clean_system を使う方法を Twitter で教えてもらった。
@sinsoku_listy https://t.co/ad4FKqHnV8
— はくどー (@HKDnet) 2020年1月18日
この記事なのですが、Bundler.with_clean_env/clean_system を使うのがいいんじゃないかなあと思いました
ref: https://t.co/SfW3Pqk7Y2
こっちの方がシンプルで、良いですね！
brew install postgresql でインストールした postgres で pg_hint を使えるようにする方法が分からなかったのでメモ。
OSDN の v1.3.4 の rpm に含まれているのは Postgres 11 用らしく、 Postgres 12 で動くか不安だったので使うのは避けた。
そして、 v1.3.4 のソースも Postgres 11 用なのか、ビルドはエラーになった。
$ make
clang -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2 -I. -I./ -I/usr/local/include/postgresql/server -I/usr/local/include/postgresql/internal -I/usr/local/Cellar/icu4c/64.2/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -I/usr/local/opt/openssl@1.1/include -I/usr/local/opt/readline/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2 -c -o pg_hint_plan.o pg_hint_plan.c
pg_hint_plan.c:20:10: fatal error: 'nodes/relation.h' file not found
#include "nodes/relation.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [pg_hint_plan.o] Error 1
GitHub からソースを取得し、 22a770c で make すると、今度は別のエラーが出た。
$ make clang -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2 pg_hint_plan.o -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/readline/lib -Wl,-dead_strip_dylibs -Wl,--build-id -bundle -bundle_loader /usr/local/Cellar/postgresql/12.1/bin/postgres -o pg_hint_plan.so ld: unknown option: --build-id clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [pg_hint_plan.so] Error 1
よく分からないけど --build-id のオプションがダメらしいので、消してみたら make と make install が実行できた。
$ git diff diff --git a/Makefile b/Makefile index de9f5c5..bde9cdc 100644 --- a/Makefile +++ b/Makefile @@ -31,7 +31,7 @@ TARSOURCES = Makefile *.c *.h COPYRIGHT* \ doc/* expected/*.out sql/*.sql sql/maskout.sh \ data/data.csv input/*.source output/*.source SPECS/*.spec -LDFLAGS+=-Wl,--build-id +LDFLAGS+=-Wl installcheck: $(REGRESSION_EXPECTED)
これで pg_hint_plan は使えるようになったけど、これが正式なやり方かは謎。
