今年2020年に見てよかったアニメ・アニメ映画
最初に
もう2021年後半なのですが、下書きのまま放置してたので、放出してみる。
Netflix見てばかりで、アウトプットがないので振り返ってみます。
今年感のあるアニメで面白かったものを書いていきます。
自分が今年と思ってるだけで、去年以前のも混じっているかもしれません。
劇場版「メイドインアビス」-深き魂の黎明-
ドロヘドロ
今年の1月-3月は、『ドロヘドロ』を見ていたようです。
すごく独特な世界で、魔法使いの住む世界と人間の住む世界ホールがあって、
魔法使いは、人間の住む世界のホールにやってきて、人間を魔法の練習台･実験台にして人間をバラバラにしたり昆虫にしたりします。
暴力･殺し合いが日常にあるダークな作品ですが、オシャレで独特な世界にひきこまれました。
アニメ版は全12話でかなり中途半端なところで終わるので、結局完結済みの原作を購入して読みました。
とある科学の超電磁砲T
Tはトリプルでシーズン3。1月-9月にかけて放送。
シーズン3も安定の面白さで安心して楽しめました。 何が安定してるか改めて考えてみると、ちゃんと話をまとめて悪役をやっつけるという王道さがあるんですよね。
レベル5の御坂美琴、食蜂操祈、削板軍覇、レベル0の上条当麻、みんな活躍していて、
あと、フレンダ vs 狙撃手の弓箭猟虎のバトルが、緊迫&白熱で面白かったです。
『とある魔術の禁書目録』の外伝という位置づけですが、禁書目録より超電磁砲の方が面白いという人も少なくなく自分もその1人なので、禁書目録がつまらないという人にも超電磁砲はオススメしたいです。
僕のヒーローアカデミア
ジャンプ作品ですね。今年、第4期が放送されました。 能力バトルもの。
グレイプニル
能力バトルもの。かなり中途半端なところで終わってます。
劇場版「鬼滅の刃」 無限列車編
今年のNo.1話題作ですね。映画は見たのですが、原作はまだ見てないです。
劇場版 ヴァイオレット・エヴァーガーデン
京アニ作品。 アニメ自体は2年前の2018年ですが、今年映画が封切りされました。
自分があげた作品は異能力バトルものが多いですが、これは別ジャンル。
主人公がもともと人の心がわからないような少女兵で、
そんな主人公が人の心を知っていく温かい作品ですね。
呪術廻戦
ジャンプ作品。
主人公が中に化け物を取り込んで、そこから戦う話。
ダイの大冒険
ジャンプ作品の再アニメ化作品。土曜の朝にやってる子供向け作品。
あと、原作者の1人と母校が同じで、ジャンプ好きなら履修しないとなと思って見てます。
ドラクエやったことがないですけど、評判がいい原作ですし、安心して見れそうです。
まとめ
列挙してみて、自分の好きな作品の傾向って変わらないなと思います。 - 個性的なキャラ･能力 - 派手なバトル - 強大な敵 - ちょっとミステリアスだけど、伏線は回収してくれる。
中国語の検定HSKの2級･3級を受験した(たぶん受かった)
今日は、HSKの2級･3級を受験した
一応ちゃんと受験したので、今日の出来事をメモしておく。
HSKは中国がバックの中国語検定試験で、1級が1番簡単で6級が最難関。
なお、将来的には、9級が出来るとか出来ないとか。
午前、2級
朝、コンビニで水やウィダーインゼリーを買ってお金を崩して、通り道で証明写真を撮った。800円。
たしか電車内でハサミとノリで、受験票に証明写真を貼った。
ネットで調べた乗換案内だと多磨駅を降りたらダッシュしないと間に合わなさそうなぐらいギリギリだったが、
武蔵境駅で2分間の乗り換えが上手く行って、少し余裕を持てた。
武蔵境駅は複雑な駅ではないので、ミスらなければ2分の乗り換えも比較的ラクだと思う。
大学の校舎に入る前に検温をしてもらい、教室で受験票･身分証明書(免許証)･自分の顔を見せて入る。
で、2級を受ける。2級はあまり記憶がない。リスニング(30分？)とリーディング(22分)のみ。
スケジュールがキッチリ決まっているわけじゃなくて、リスニングが終わったら｢じゃあ、リーディング始めてください｣って感じで、
自分で持ってきた腕時計でいつ始まったかメモっておかないと、終了時刻がわからなくなってしまう感じだった。
一応、5分前のみ、アナウンスがあった。
試験問題は最後に回収されてしまうし2級は記憶がないけど、筆記が簡単できっと満点だと思う。
一応2級は受けたけど、より難しいことになっている3級が本命なこともあり、ウォーミングアップみたいな感じでした。
午後、3級
2級と違うのは、ピンイン(日本でいう振り仮名)がなくなって、筆記が増えた。
リスニング100点、リーディング100点、ライティング100点。
このライティングは3級だと、並び替え5問、書き取り5問で、あんまり書き取りっぽくない。
2級でも3級でもリスニングは自信がないが、 リーディング･ライティングは本番2日前に解いた5回分の過去問で毎回9割以上だったので受かる期待を持って頑張れた。
2級から3級になると苦手なリスニングの配点割合がグッと下がるので、単語さえ抑えてしまえば3級の方が簡単なのではないかとすら思う。
ただ、本番の3級のリーディングは少し難しく感じたし、ライティングは何問がヘマをした。
3級のリーディング
自分が正しければ、語群にある｢要求｣を名詞として、文章に埋める問題が出題された。
自分の学習で、｢要求｣は動詞として使われることが多かったので、ちょっと迷った。
あと、語群の｢段｣をどこに埋めればいいのか迷った。
自分が正しければ｢这第2( )重要、よく読んでよく声にだして｣みたいな文章に｢段｣を入れるんだけど、
｢段｣は何かの量詞で後ろに名詞が来るのかなって最初考えてしまったので、すぐに決まらなかった。
ここでの｢段｣は名詞で、｢この第2節は重要なので、よく読んでよく声にだして｣みたいな文章らしい。
3級の書き取りの並び替え
｢总想｣｢我就｣｢吃西瓜｣｢一到夏天｣
正解をだしたと思うが、この並び替えが個人的に難しかった。
｢总想｣が、何か特別な接続詞なのかどうかわからず、どの位置におけばいいのか自信が持てなかった。
改めて調べると決まったフレーズではなさそうなので、｢总｣を無視して｢想｣を 能願動詞(助動詞？)として｢吃西瓜｣に繋げるだけだった。
一到夏天我总想吃西瓜。 夏が来たら、西瓜(スイカ)を食べたくなる。
たぶん合っている。
3級の書き取り
5問のうち、｢新｣と｢耳｣を書く問題がでて、書いたけど字体を間違えて点が入らないかもしれない。
書き取りは問題数が少ない分1問あたりの配点がデカイので、部分点とかがあったりするのかな。部分点あってくれ。
日本語フォントが使われてしまう関係で書けないが、中国語の｢新｣は左下が｢木｣じゃなくて｢ホ｣っぽい。 あと、1画目を右下➘に向かうように斜めにすると、中国語の｢新｣ぽくなる。
それから、｢耳｣を間違えた。日本語と違って最後の横棒は突き出ないかなって考えすぎて、止めてしまった。
これは日本語と同じっぽいので、やりすぎた。
ちなみに試験中は｢あれ、中国語の耳って横棒が多かったけ？｣と悩んで、適当に横棒を増やして間違えたら恥ずかしいからと思い、同じ本数にした。
合ってた。良かった。
3級の総合結果
リスニングはわからないけど、ライティングはマーク時間を考慮に入れておらずゆったり解いてて最後の1問をちゃんと読めてなかったが、満点がとれてもおかしくない感じ。
ライティングは、｢新｣と｢耳｣を間違えて点が0でも、8割いっても変ではない気がする。
だから、もしかしたらリスニングとライティングで合格点の180点いっているかもしれない。
まぁいってないかもしれないが、リスニングも合わせれば6割の合格ラインを超えているはず。
まだ結果はでてないが、きっと合格した。良かった。
リーディングは簡単なので、もう4級･5級の過去問を解いてみて、行けそうなら申し込んでみようかと思う。
課題はリスニング。どう勉強したらいいものか。
始めて受けたHSKだけど、大学受験レベルの漢文とか英語よりも全然楽な感じだった。 まぁ、HSKの3級自体が学習2年目とかそのレベルだったはずで、中学2,3年生の英語の試験レベルを漢字のできる日本人が受けていると考えれば、簡単なのもさもありなんという感じ。
学習方法
Duolingo
どれぐらい効いているかわからないけど、中国語を久しぶりに真面目に勉強しようと思い、1ヶ月前ぐらいから始めた。
英語話者向けコースで中国語をとっているが、だんだん小難しくなってきた面倒な感じがある。
音声つきで基礎や単語を抑える上では良かった気がするが、HSKに対応した感じではないので、HSKに出ない単語がでたり、HSKに出る単語がなかったりする感じがある。
Googleスプレッドシートに単語や説明を入れる
Googleスプレッドシートに単語や説明を入れて、自作の単語集的なものを作った。 さらに、公開してないが問題を解く自作Webサービスを作っており、そこにインポートして自分で解いて単語を抑えた。 3級の単語自体、300単語+αといった感じで、全然多くないし、漢字を知っている日本人にとっては楽な感じだった。
過去問
ネットに転がっている1級･2級･3級などのリスニングをちょっとやったりした。 それから、試験の2日前に、リーディングとライティングを全5回分、公式の過去問本で鉛筆で汚しながら時間を計測してやった。
Gemfileの有無で変わる読み込まれる.rubocop.yml、そして優先順位について
最初に
予期せぬ~/.rubocop.ymlが読み込まれいてトラブっているのを見たので、
.rubocop.ymlがどういう順序で読み込まれたりするのかについて調査した。
説明するのが難しいけれど、書いて公開しておかないとせっかく調査したのに忘れてしまいそうなので、書いてみる。
複数の.rubocop.yml設定ファイルを読み込むRuboCop
ここで前提として、rubocopコマンドのコマンド引数で、親ディレクトリなどの祖先は指定しない。
これは、簡単のためというのもあるが、そもそもRuboCop自体想定されてないと考えられるためだ。
rubocop ..みたいな形で親を指定して実行するとエラーが起きたので、そう考えられる。
ルールによっては、優先順位などが変わることもあるようだけど、基本的には以下のような感じ。
- Rubyファイルから見ると、同じ位置か上位にある
.rubocop.ymlのルール適用される。 - 複数の
.rubocop.ymlが見られる場合に、同じCopルールがあれば下にある.rubocop.ymlの方が優先順位が高い。
プロジェクトルートディレクトリというのは、Gemfileかgems.rbという名前のファイルがあるディレクトリ。
(GemfileはBundlerでよく使うけど、gems.rbは知らない)
コマンド実行位置が、ホームディレクトリでもプロジェクトルートディレクトリでもない場合は、
コマンド実行位置の.rubocop.ymlに加えて、
上位にあるプロジェクトルートディレクトリかホームディレクトリの.rubocop.ymlもあれば見られる。
ホームディレクトリのrubocop.ymlでrubocop-railsを読み込むべきではない。
gem install rubocop-railsで、RuboCop本家で開発されているRails用のgemをインストールできる。
これで、(書くべきではないが実験のため)ホームディレクトリの.rubocop.ymlで、 rubocop-railsを適用させる。
AllCops: NewCops: enable require: - rubocop-rails
RailsアプリにはアプリのルートディレクトリにGemfileがあるはずで、
Railsアプリのプロジェクトルートでない位置でrubocopコマンドを打つと、
コマンド実行位置の.rubocop.ymlに加えて、
RailsアプリのGemfileのあるプロジェクトルートにある.rubocop.ymlが読み込まれる。
しかし、Gemfileのない普通のRubyコードに対してrubocopコマンドを打つと、
コマンド実行位置の.rubocop.ymlに加えて、
ホームディレクトリの.rubocop.ymlも読み込まれる。
だから、もしホームディレクトリの.rubocop.ymlにRails用のルールがあれば、
RailsのコードじゃないのにRailsのルールを適用してきてしまうことになる。
だから、「ホームディレクトリに便利かも」みたいに思ってRails用のルールを適用させてしまうのはよくない。というより、誤っている。
Gemfileの有無で変わる.rubocop.ymlとは
上記の話を整理する。
ホームディレクトリに.rubocop.ymlがあり、あるディレクトリにGemfileと.rubocop.ymlがあるとする。
このとき、あるディレクトリでコマンドを実行すると、Gemfileのあるディレクトリの.rubocop.ymlのみが見られる。
ここで、もしGemfileを削除すると、ホームディレクトリの.rubocop.ymlも見られる。
考え方的には、Gemfileがあるディレクトリなら何かのRubyアプリを作っているディレクトリで、そこに.rubocop.ymlがあるなら、
ホームディレクトリにある個人用の.rubocop.ymlは適用されるべきではない、という考え方をとっているのだと思う。
ドキュメントも読んで確かめてみる
As an example, if RuboCop is invoked from inside /path/to/project/lib/utils, then RuboCop will use the config as specified inside the first of the following files: - /path/to/project/lib/utils/.rubocop.yml - /path/to/project/lib/.rubocop.yml - /path/to/project/.rubocop.yml - /.rubocop.yml - ~/.rubocop.yml - ~/.config/rubocop/config.yml - RuboCop’s default configuration
公式ドキュメントに書いてある英語の細かいニュアンスなどがわかりにくいが、優先順位が書いてある。
よく見ると、ホームディレクトリよりルートディレクトリの方が優先順位が高かったりして、必ずしも子の方が優先されるというわけでもないらしい。
ただ、普通はPCのルートディレクトリに.rubocop.ymlを書いたりしないだろうし、気にすることではないだろう。
しかし、公式ドキュメントのどのあたりを読めば、コマンド実行位置の.rubocop.ymlだけでなく、ホームディレクトリかGemfileのあるプロジェクトルートディレクトリのどちらかの.rubocop.ymlが読み込まれるという話が書いてあるのかわからなかった。
最後に
読み込まれる.rubocop.ymlが1つだけなのか複数あるのかとか、どういう順番なのかとか、そういうのを一切知らずになんとなく使ってきていたので、読み込まれる順番がわかってよかった。
【ドキュメンタリ映画】「まったく同じ3人の他人」を見た
最初に
実際にあった生き別れの三つ子のドキュメンタリ映画。
原題は「Three Identical Strangers」。
いっしーさんがオススメしてたので知って見ました。
昨日観たドキュメンタリー映画で感動…ではなく心底震え上がりましたので超オススメです。 あと数日でNetflix配信終了してしまいますが…
(フィヨルドブートキャンプのDiscordの映画チャンネルより)
1961年7月12日誕生し、19歳で再開
1961年7月12日誕生のアメリカで三つ子が生まれ生き別れ、19歳の頃に偶然に再開。
三つ子が生き別れる。そんなことが現実にあるんですね。
再開したあとは、チヤホヤされ時の人となり、TV番組にでたり、映画にもちょい役ででたそうです。
なお、映画名について調べたら、『マドンナのスーザンを探して』（原題：Desperately Seeking Susan） でした。
それにしても、現実で生き別れることなんてどうしたら起こるんでしょうか。
それぞれの三つ子は、各家庭で養子として引き受けられますが、どの親も三つ子であることは知らずに育てました。
実は三つ子であるとした各家庭の育ての親は、当然のように養子縁組機関に怒ったようです。
【ネタバレ】なぜ生き別れたのか
以下、ネタバレを含みます。
事実は小説より奇なり。
なぜ三つ子が生き別れたのか。
それは、別々の家庭で育てられたら、性格などにどういう影響がでるのかを知る壮大な実験だったとのことです。
他にも生き別れになった双子がいて、それを知らないままの双子もいるとのことです。
そんな実験ができちゃうなんて、すごいですね。
三つ子は、同じ年齢差の姉がいて、それぞれ異なる経済環境の家庭に育ててもらって、比較実験されていたようです。
実験の結果
実験の結果は2066年に全てを明らかにする予定はあるのだとか。
そしたら、他にも実験のモルモットにされた双子が明らかになる。
ずっと1人で生まれたとして育った方が、実は生き別れた双子だったと知ったときってどんな気持ちになるんでしょう。
このドキュメンタリの三つ子は、比較的若いときに再開できて結構楽しそうでしたけど、
今だったらそれぞれ別の家庭をもって孫もいそうで、2人とも全く異なる人生を送ってそうだし、別の雰囲気になりそうですね。
それぞれの性格によっても、その事実を受け入れられるかどうかも大きく変わりそうです。
エディと映画の結論について
最後の方、ドキュメンタリー映画側で、遺伝よりも環境が大事みたいな結論にもって行きすぎな感じがしました。
特にエディの自死について、厳格な父親の家庭で育ったから自殺したと責めている風で、エディの育ての父が可哀想になりました。
最後に
現実ってすごいなって思いました。
最近はドキュメンタリー映画って見てなかったんですけど、比較的好みのジャンルだし、ドキュメンタリー映画をもっと見ていきたいなと思いました。
参考
【Rails+Devise】ArgumentError: SMTP From address may not be blank: nil
最初に
開発環境では動くけれど、テストや本番環境では動かず原因がなかなかわからず大変だった。
色々原因はあったけれど、環境変数の乱用が1番よくなかった気がする。
あと、Mailgunの導入でそっち関係のエラーだと勘違いして、実際はDevise側の設定で、問題を正常に切り分けられていなかった。
謎のエラー
「ユーザー登録」のボタンをクリックすると、メールアドレス確認用のメールを送る。
この際に、ローカルではエラーが起きなかったが、CI環境と本番環境でエラーが起きていた。
ArgumentError: SMTP From address may not be blank: nil
エラー文はこのように書かれている。何らかの原因でどこかでnilになってしまい、エラーになっているようだ。
SMTP From address ?
テスト環境でのエラー
rails test:allコマンドを打って、システムテストをしているときに生じたエラー
Rack app ("POST /users" - (127.0.0.1)): #<ArgumentError: SMTP From address may not be blank: nil>
E
Error:
SignUpTest#test_sign_up:
ArgumentError: SMTP From address may not be blank: nil
本番環境(Heroku)でのエラー
heroku logs -t
2021-07-23 app[web.1]: I, [2021-07-23 #4] INFO -- : Rendered devise/mailer/confirmation_instructions.html.erb (Duration: 2.0ms | Allocations: 351) 2021-07-23 app[web.1]: I, [2021-07-23 #4] INFO -- : Delivered mail asdfghjkl1234567890@asdfghjkl1234567890.mail (753.9ms) 2021-07-23app[web.1]: I, [2021-07-23 #4] INFO -- : Completed 500 Internal Server Error in 801ms (ActiveRecord: 8.1ms | Allocations: 7800) 2021-07-23 app[web.1]: F, [2021-07-23 #4] FATAL -- : 2021-07-23 app[web.1]: ArgumentError (SMTP From address may not be blank: nil): 2021-07-23 app[web.1]: 2021-07-230 app[web.1]: mail (2.7.1) lib/mail/check_delivery_params.rb:13:in `check_from'
原因
config/initializers/devise.rb
config.mailer_sender = ENV['SMTP_MAIL_ADRESS']
開発環境・本番環境でメールの設定が別々だからとか、そんな理由で適当に環境変数を設定した。
(まぁ、Deviseの設定ファイルについてもちゃんとした理解をしていなかったし、そんな設定をしたことも忘れていた)
で、ローカルでは環境変数をセットしていたが、CI環境や本番環境では環境変数がセットされておらず、ENV['SMTP_MAIL_ADRESS']がnilを返してしまい、Rails内でnilが渡されていた。
勘違い
最初は、Deviseの初期設定だと思っておらず、Mailgunの設定やRailsのmailerの基本設定を疑っていた。
app/mailers/application_mailer.rb
class ApplicationMailer < ActionMailer::Base default from: 'foo@bar.com' layout 'mailer' end
対策
環境変数を使ってもいいと思うが使ったとしても、環境変数というキーがなかったエラーを起こしてあげれば、どこが問題でエラーが起きているのか浅いところでわかるので、問題の切り分けがわかりやすくなったように思う。
ENV.fetch('SMTP_MAIL_ADRESS')
上記のような感じで、fetchメソッドを使ったりしたらいいように思う。
【余談】開発環境で環境変数が更新されないバグ?
バグを解決する際に、本番環境でしかエラーが起きずMailgun絡みの問題だと思っていた。
(このとき、CIで同じエラーが起きることに気づいていなかった)
とりあえず、開発環境でエラーを起こした方が楽そうなので、開発環境でもMailgunを使ってみることにした。
その際に、dotenv-railsというgemを使って、.envファイルに環境変数を書き込んでいたが、Railsを立ち上げ直しても環境変数が更新されないことがあった。
これについては、spring stopコマンドを打つと、環境変数が更新された。
Railsで持っているcredentialsの機能を使った方がいいかもしれない。
【参考】 Qiita: Railsで環境変数の変更が反映されないときはspring stopを試す
最後に
とりえあえず解決してよかった。
藤本タツキ『ルックバック』を読んで
ルックバックの雑感
ちょうど2年前、京アニの放火事件があった7月18日が終わる24時に公開された読み切り。
『ファイアパンチ』『チェンソーマン』の藤本タツキ先生の読み切り。
何度も読んだり、他の人の呟きなども目にして、咀嚼したので感想として残してみる。
みんな絶賛しているけれど、正直1読目はよくわからなかった
読み急いでしまったこともあり、
あまりにも鮮やかなに「京本が部屋からでなかった話」がシームレスにインサートされ、
正直どういう風に話を受け止めればいいのかよくわからなかった。
なんかこの殺人事件の男の「元々オレのをパクったんだろ!?」の発言、既視感があるような……?
この「京本が部屋からでなかった話」は何なのか。
2読目をしてガクンと味わった衝撃
2読目で、この殺人事件は京アニの放火事件なのだ、と気がつく。
昨日は「京アニの放火事件から2年目なのか」と知ってたのに、鈍くさい自分。
ここで、何もかも紐解かれていく。
これは、まさしく藤本タツキ先生なりの京アニへの追悼なのだと。
Don't look back in anger
最初のコマの黒板の右上に書かれた「Don't」 最後のコマの左下の表紙に書かれた「In Anger」 そして、タイトルの「Look Back」
これらを繋ぎ合わせた一文は「Don't look back in anger」で、
翻訳すれば「怒りで振り返るな」「後ろ向きに過去を見るな」といった具合でしょうか。
これは、藤本タツキ先生の考え方であり、メッセージなのだ。 - 振り返ってもいい。でも、前向きに。 - 怒ってもいい。でも、未来へ進むために。
怒りで漫画にぶつける藤本タツキ先生
2017年のファイアパンチ5巻発売記念のインタビューで「怒りを漫画にぶつけている」と言ってた藤本タツキ先生。
僕は読み切りを描く時は大体怒りで…。例えば、今ネット上で怒っている人が多いじゃないですか。そういう人たちって、Twitterとかで発散できていると思うんですけど、僕は自分の怒りなどをTwitterとかに書く気が知れなくて。漫画にぶつけているんですね。
事件が起きたのは2019年で今は2021年だけれど、この読み切りを書いたときもやっぱり怒っていたのかもしれない。
京アニで働くクリエイターとしての同士が理不尽な理由で命を奪われたことに怒っていたのかもしれない。
もしかしたら、京アニで働いていた友人の命を奪われたことに怒っていたのかもしれない。
それを漫画という形で昇華させた藤本タツキ先生。
タイトルのルックバックって
Weblio英和辞書: look backの意味・使い方・読み方
振り返って見る、(…を)回顧する、追憶する、しりごみする、うまくいかなくなる、後退する
(1) 振り返って見る.
(2) 〔…を〕回顧する, 追憶する 〔on, upon, to, at〕《★受身可》.
He looked back fondly on his school days. 彼は学生時代を懐かしく追憶した.
(3) [しばしば never, not を伴って] しりごみする; うまくいかなくなる, 後退する.
You must not look back at this stage. ここまできて後に引いてはいけない.
いい意味もあれば、悪い意味もある。 京アニへの「追悼」であり「回顧」だけれども、だからといって「後退」してもいけない。 そして、backには背中という意味もあり、物語で「背中」は重要なキーアイテムとなっている。
- 自分より上手い絵を書く京本の背中を追う藤野
- 京本の服の背中にサインしてあげる藤野
- 「京本も私の背中を見て成長するんだなー」と鼓舞する藤野
- 京本の描いた「背中を見て」という4コマ漫画を見る藤野
- 京本に書いた背中のサインを見る藤野
京本も藤野の漫画が好きで尊敬して、背中を見ていたかもしれない。
しかし、同時に、藤野もまた京本の圧倒的な努力と画力を知り、京本の背中を見ていたといえる。
美術の大学でも頑張っていた親友の京本の努力を知っているからこそ、藤野は悔しく悲しかっただろうし、
一方でそんな京本から尊敬されてたからこそ藤野は立ち直って「天国でも私の背中を見てろよ」と背中で語っているようだった。
参考
24時頃に公開された模様
藤本タツキ最新作
— チェンソーマン【公式】 (@CHAINSAWMAN_PR) 2021年7月18日
『ルックバック』
ジャンプ＋にて公開中！
『チェンソーマン』
第一部完結後初の大長編読切、
ぜひお楽しみください。
▼作品はこちらからhttps://t.co/uYymAd6aaV pic.twitter.com/ZSeeDtLBzr
【Ruby】gem / bundle, それぞれのコマンドの違い
最初に
gemコマンド、bundleコマンドの違いを説明できるように覚書き。
いつも何となく使っていたが、本質的な違いは、グローバルなのか、ローカルなのかだと思う。
Bundler
gemの名前がBundlerないしbundler(名詞)で、コマンド名がbundle(動詞)。
意味合い的に、品詞を使い分けている模様。
2.5.9までは完全に外部のgemだったが、2.6.0からはDefault GemとしてRuby本体に取り込まれたらしい。
昔はgem install bundlerでbundlerを取り込まなければならなかったが、今はRubyをインストールすればついてくるので楽。
GitHubではrubygems/rubygemsで管理されている模様。
あと、昔はRubyコア外で管理されていたせいか、Bundler専用のドキュメントページbundler.ioがある。
プロジェクトでの管理以外に、gemを作るときの雛形を作るコマンドも提供している。
gemコマンドとbundleコマンドの違い
- gemコマンドでは、Rubyのバージョン毎にgemが結びつくので、プロジェクトごとに管理できない。
- Bundlerは、RubyのプロジェクトにGemfileを置いて、プロジェクトごとにgemを管理できる。
Gemfile&Gemfile.lockを共有することで、プロジェクト参加者が使うgemのバージョンを共有できる。
色々違いがあるとは思うのですが、プロジェクトで使いたいものか、プロジェクトに限らずどこでも使いたいかになると思う。 プロジェクトで使う = 特定ディレクトリ配下に適用 = ローカルで使う。
npmコマンドとの関係性
npmのグローバルインストールがgemコマンドで、npmのローカルインストールがbundleコマンドに相当している、といえる。
npmのpackage.json, package-lock.jsonが、BundlerのGemfile, Gemfile.lockである。
