gitコミットしぐさ
はいどうも。最近気をつけているコミットのやり方について備忘録的に書きます。1
前提として、現在はある程度成熟しているアプリケーションについての話です。新アプリの新画面ばーんってつくっていくぞみたいなときはもっと雑にコミットしてもいいんじゃないでしょうか。不具合修正であったりちょこちょこした機能追加だったりがメインな文脈です。
commit を verbose にする
いいコミットの第一歩はたぶんこれです。git CLI使っている人は git config --global commit.verbose true
でOKです。あるいは git commit -v
って打つか。2
これはどういうオプションかというと、コミットメッセージを書くときに下にdiffが出ます。
-v, --verbose Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. Note that this diff output doesn't have its lines prefixed with #. This diff will not be a part of the commit message. See the commit.verbose configuration variable in git-config(1). If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged changes to tracked files.
説明にあるように、なんの変更をコミットするのかを見せてもらえるのですごくいいです。ざっと眺めることで「これってどういうタイトルつけよう?」とか「あれ、これ入れたくなかったんだけど」みたいなことが起きます。おすすめ。
リファクタリングと変更を分ける
たとえば以下のようなものを考えましょう。
SELECT * from users WHERE foo = 1 LIMIT 100;
「普通の select 文ですね。でも order by がないですね。あと from は予約語なのに小文字ですね。直しちゃいましょう。」
$ git diff diff --git a/tekitou.sql b/tekitou.sql index a9a1810..f852f3c 100644 --- a/tekitou.sql +++ b/tekitou.sql @@ -1 +1 @@ -SELECT * from users WHERE foo = 1 LIMIT 100; +SELECT * FROM users WHERE foo = 1 LIMIT 100 ORDER BY id;
はいアウトー3
from -> FROM
は動作を変更しませんが、 ORDER BY
の追加は動作を変更するので分けたほうがいいと思います。
まあこの例はさすがに極端なのですが、例えば以下のような変更をするときも2コミットに分けます。
class Foo def foo obj.some_method(another_obj.some_method) end end
ここで another_obj.some_method
を更に加工する必要が出てきたとき
まずは「リファクタリング: ローカル変数にとるようにする」のようなコミットを積んでから変更を積みます。
$ git show commit 786849cff921477a463fe7fcd59000d3ce84c0a3 (HEAD -> master) Author: hkdnet <xxx> Date: Sun Jan 28 14:12:18 2018 +0900 リファクタリング: ローカル変数にとるようにする diff --git a/tekitou.rb b/tekitou.rb index c910df5..faa7b7b 100644 --- a/tekitou.rb +++ b/tekitou.rb @@ -1,5 +1,6 @@ class Foo def foo - obj.some_method(another_obj.some_method) + tmp = another_obj.some_method + obj.some_method(tmp) end end
これの何がいいかっていうと、レビュアーが楽なんですよね。GitHubのPRにはコミットを順番に見る機能があるので4、リファクタリングって書いてあるコミットは軽く見れます。機能が変わったコミットに集中できます。
コマンドを打ったときにコミットしておく(例外あり)
たとえばこんな感じ
$ npm install foo $ git add . $ git commit -m '$ npm install foo'
npm install
で package.json
と package-lock.json
が更新されるのでそれだけでコミットします。
Gemfile
の更新は、Gemfile.lock
の更新を伴うのでだいたい一緒にしてます(例外)
$ vim Gemfile # ここではコミットしない $ bundle install $ git add . $ git commit -m 'Install awesome_gem'
Rails で generate したときもそれだけでコミットしてます。db:migrate とかも。
$ bin/rails g model User name:string $ git add . $ git commit -m '$ bin/rails g model User name:string' $ bin/rails db:migrate $ git add . $ git commit -m '$ bin/rails db:migrate'
モデルとかマイグレいじるときもコミット後に積んだほうが無難かなー。
コミットメッセージにいろいろ書く
書いておくとGitHubのPRを作るときにもコピペできて便利です。
最近だと国内向けのハイフン区切り電話番号の検証をやったのですが、こんな感じのコミットメッセージになりました。
意識してるのは、正しい仕様の根拠を示すこと。なにか機能を落としてるなら明記すること。5
$ git show commit 9a2b1b3c57308adbb2c08daaaff1459d60c2ea55 (HEAD -> master) Author: hkdnet <xxx> Date: Sun Jan 28 15:02:04 2018 +0900 xx画面での電話番号のjs検証を追加 ref: http://www.soumu.go.jp/main_sosiki/joho_tsusin/top/tel_number/q_and_a.html#q2 電話番号は以下の仕様となる。 国内プレフィックス: 1桁(0固定) 市外局番 : 1〜4桁 市内局番 : 1〜4桁 加入者番号 : 4桁 ただし市外局番と市内局番は合計で5桁となる ハイフンは市外局番と市内局番の間、市内局番と加入者番号の間にいれる。 そのため (2-5)-(1-4)-(4) が正しいフォーマットであるといえる。 「ハイフン区切りの第1項と第2項の桁数の和が必ず6桁である」 という検証は今回は行わない ...
ハイフン区切りの第1項と第2項の桁数の和が必ず6桁である
やらなかったことが明記されてるとあとで助かります。
コミットは rebase で整形しとく
PR出す前に Fix a typo とかは rebase で何事もなかったかのように消し去ってます。
$ git commit -m 'fix a typo on xxxx' $ git rebase -i origin/master # さっきのコミットを xxxx のコミットの下の行にもってきて fixup しとく
これは好みだから別にどっちでも。僕が間違えたことやメソッドの使い方を勘違いしていたことも1つの情報だから、コミットとして残っててもいいのかもなーと思いつつ、blameで遡っていくときの邪魔になるので消しちゃうほうが最近の好みです。
TaPL読書録 #1
2018年はmediumで記事を投稿しようと思っていたのですが、はてなブログのほうがなんだかんだ流入がいい気がしたので戻ってくることにしました。乗り換えのきっかけは、ブログのエディタの使い勝手があまりよくないことによっていたのですが、 kibela で書いてからコピペで貼ればいいや、という気持ちになって出戻りです。
mediumでは以下の3記事を書いていました。
『ふつうのLinuxプログラミング』 読了 – hkdnet – Medium
『白と黒のとびら』『精霊の箱』『自動人形の城』読了 – hkdnet – Medium
ある日 Entity Attribute Value に出会った – hkdnet – Medium
さて、今回の記事はTaPL読書録です。おそらくシリーズものになります。
- 作者: Benjamin C. Pierce,住井英二郎,遠藤侑介,酒井政裕,今井敬吾,黒木裕介,今井宜洋,才川隆文,今井健男
- 出版社/メーカー: オーム社
- 発売日: 2013/03/26
- メディア: 単行本(ソフトカバー)
- クリック: 68回
- この商品を含むブログ (11件) を見る
PFDS勉強会から派生してTaPL勉強会ができたのでそこでの疑問や得られた知識、派生して調べたことなどをまとめる予定です。1なお、記載内容に誤りがあった場合、原因の多くは私の理解不足であろうことを先に いいわけ 謝罪しておきます。
第1回は1, 2章が対象でした。ざっくりまとめると、型にまつわる概略とプログラミング言語とのかかわりが1章、集合などの数学的な基礎知識が2章でした。
ラッセルのパラドックスは、事前学習をしたのですが、wikipediaを見てもよくわからない状態でした。 R = { x | x ∉ x }
という集合の定義をみたときに、 x
は要素でありながら( x ∉ x
の右辺)、集合である( x ∉ x
)ということを考えると、 x
が要素であるような集合の要素の集合の要素の集合の……と無限ループになってしまってとらえどころがなくて……。
という話をしたところ、右辺の x
と左辺の x
の「型」が違うはずなのに区別しないから矛盾が導けるよね、というのがラッセルのパラドックスであると教えてもらいました。
定義2.1.8
あまりにも関数に馴染みがありすぎること、関係というと関数が思い浮かびやすいことから案外つまづきました。部分関数の定義を読んでも、これは何であって何でないのか、というのがイメージしにくかったです。いまの私の理解では、「常に t1 = t2
である」が満たされないのは参照透明でない関係のことを指しているのだと思っています(例えばランダム性のあるものなど)。
定義2.2.1
s R t かつ t R s ならば s = t であるとき、Rは反対称的である
というのは少しわかりにくいなーと思います。仮定部分の仮定では「s R t
かつ t R s
」で非常に対称的に見えるので。しかしその場合は「s = t
である」という強い制約が導かれるので、ああたしかに反対称的と言われればそうなのかもな、という感じ。
定義2.2.3
上限と下限(結びと交わり)については「S = { 1, 2, 3 }, s = 1, t = 2
のとき 結び j = 2
」など具体例を挙げて確認しました。どうにも「結び」「交わり」という単語に苦手意識があるのですが、英語では "join" と "meet" らしいですね。そっちのがまだニュアンスがわかるような気がする。
演習2.2.6
反射的閉包の定義をみると「R を含む最小の反射的関係 R' のことである」とあります。
関係 R' を R' = R U { (s, s) | s ∈ S }
とした場合に、R' が R を含むことは明らか。 U
の右オペランドが反射的閉包の必要条件であることも明らか。 R
の左右のオペランドである集合はそれぞれ何かの要素を抜いた瞬間に R' が R の反射的閉包であるための必要条件が満たされなくなるので、それらの和集合は最小であるといえます。
最初、反射的閉包のイメージが掴めなかったのですがイメージが掴めると、これ同じことしかいってねーなという感じ。
画像では R = { R1, R2 }, R' = {R1, R2, R3, R4, R5}
です。関係とは図中の矢印の集合であるというのがわかればまあなんとかなるかと。
演習2.2.7
R0, R1, ... というのは下図のようなイメージ。点線をひいてあるところがその関係で追加されるところです。
演習2.2.8
推移的に追っていけばなんとかなるでしょ、という感じ
2章まではこんな感じでした。次回から本編に入るので楽しみです。
-
と大風呂敷を広げましたがめんどくさくなったら派生して調べたことがなくなり疑問のまま放置されるでしょう。↩
2017年を振り返って
3331 contributions
仕事とプライベート両方見えてるので結構すくなめかも。
一応草活は続いてる。
言語別のコーディング時間
定性的な振り返りとして隔月のことを思い出して適当に書く。
……予定だったんだけど1-6月のことを思い出すのがめちゃくちゃ難しいのでやめた。
今年一番のニュースは、うーん、やっぱり転職ですかねえ。
転職したことでいろんな人に会って、いろんなことを教えてもらって、世界が広がったなーと思いました。
具体的には Ruby コミッタの人と話すようになって、crubyのソースを普通に読むようになったことですね。
「やればできる」の幅が広がったのが嬉しいし、C言語とかを普通に読み書きできるようになりつつあります。
言語とかOSとかのレイヤまでちゃんと降りていって話ができるようになるよいきっかけだったと思います。
他には、いろんな知り合いが増えたのですが、新しい人と会うとなんとなく多面的になる気がしますね。
「ある人との関係性における自分」というのが人ごとにできるのでその分だけ。
そういう意味でしがないラジオ関連、特にずっきーさんとの交流ができたのは大きい気がしました。
昨年の振り返りを見てみるとこんな感じ。
- ブログもっとかくぞ
- ✗: 42記事 → 37記事
- 定量的にはかれるようにするぞ
- △: 作ったけどそんな使ってない
やはり大晦日に入れた気合はアテにならない……。
chrome拡張 OneTab が便利
Firefox 57が出た後、しばらく浮気をしていたもののなんだかんだあって結局 Google Chrome に戻ってきました。
思えば IE で育ったあとに unDonut を使い始め数年、10年くらい前にchromeの存在を知ったあとはずっと使い続けてきた一番のお気に入りソフトであるわけです。しかし、その長きに渡るインターネット生活を一変させる chrome 拡張に最近出会いました。
それが OneTab です。
使い方はかんたんで、いれたあとは「タブ多くなってきたなー」というときに押すだけ。
開いているタブ(のうちピン留めされていないもの)をすべてリスト化して1ページにまとめてくれます。
すげー単純なんですがこれが割りと便利です。
タブの整理をするときって、すでに狭くなってる中で要不要の判定をしていたので、それがわかりやすいタイトルで並ぶだけでも結構価値があります。
さくっと試せるのでいれてみてはいかがでしょうか。
Speee×Asakusa.rb Ruby2.5リリースパーティー に参加してきました
行ってきました。
twitter に適当に投稿はしましたがだいぶはしょっているのでそれの補完を。
「突然CentOSが落ちるコードをコミットする人はちょっと」とか聞こえた
— はくどー (@HKDnet) 2017年12月26日
なんか別方面にささったらしく妙にRTされましたが。これはnobuがCentOS6で落ちるコードをコミットしたことをネタにしていたそうです。コミッタ同士の仲が良さそうで微笑ましいですね。
最初は Matz からの挨拶がありました。無事リリースできましたねーというところと反省点。
2.5の反省。ギリギリのゴーサイン
— はくどー (@HKDnet) 2017年12月26日
知り合いのコミッタも12月になってからも気合いれていろいろやっていて、11月にはもうフィーチャーフリーズしてるもんだと思ってたのですがそうでもないんだなあと思っていました。どうもコミッタ陣にとってもさすがにちょっと、という感じがあったようで2.6では余裕をもたせたいですねという話がありました。
Rubyユーザーにとっては 2.5 が出たばかりですが、コミッタ陣はもう2.6を見据えているようです。
こちらは当日の朝に投げられた k0kubun さんのPRです。これをネタに 2.6 で mjit をいれるぞー、はやくなるぞー、と盛り上がりました。
2.6はjltはいるかもなんでpreviewはやくだしたい、とのこと
— はくどー (@HKDnet) 2017年12月26日
スピードネタでいうと、某メディアの記事で「3倍速い」という噂のRuby2.5なので1速度ネタが続きます。
Speee さんでのイベントの前にあった開発者会議では、 block.call
形式の場合にも safe level を考慮しないようにしてもよいという意思決定があり、よりはやく実行できるようになる見通しが立っているようです(ちょっと曖昧です)
このあたりから safe level や tainted など、知らない人もいるような機能の話に深掘りされていきました。個人的なお気に入りは mame さんが放った以下のフレーズ。
「taintはすべてのオブジェクトに1bitのデータをのせられる便利機能」
— はくどー (@HKDnet) 2017年12月26日
その他、2.5で強化されたカバレッジの話や binding.irb
の話が続きました。
binding.irbはrequire 'irb'したくないというチケットをなかださんがrejectしてなぜかパッチをいれてた
— はくどー (@HKDnet) 2017年12月26日
座談会の後の懇親会を細かにレポートしてもアレなのでこのへんで。
非常に楽しい会でした。ありがとうございました。
#しがないラジオ とキャラ付け
この記事は しがないラジオAdventCalendar 5日目の記事です。
すでに2回もゲストとして出演させていただきまして、自分のキャリアについては話しきった感覚があります。そのため今回はしがないラジオに出会って何が起きたのか、何を考えることになったのかということ書こうと思います。
転職ネタが知りたい方はどうぞ過去の sp3 と sp5 をどうぞ(宣伝
最初にぼくとガミさんの関係性を確認しておこうかと思います。
1年ほど前の僕にとってのガミさんは、小中高の同級生であり、ときたま酒を飲むような仲でした。どっかのSIerに就職したらしい1と思っていたのですが、いつの間にかweb系に転職することが決まっていて、そこからまた交流が増えた気がします。これがたぶん去年の9月くらい。Rebuild.fm の話をしたり、青春のアフター1〜3巻をガミさんにその場で購入させたりというイベントがあった喜ばしい飲み会でした。
その後の今年3月、 twitter を見ていたらいきなりガミさんが「podcast始めました」とツイートしていて大変驚いたのを覚えています。当時は Rebuild.fm チルドレンと呼ばれるように新規 podcast が登場したあとで、うわー俺もやりたいと思ってたけどめんどくさくて足踏みしてたのに、ガミさんはちゃんとやっていってるなあと思いました。
ポッドキャスト始めました https://t.co/3YzWwU1hVu
— j_ikegami (@jumpei_ikegami) 2017年3月13日
さて、そんなこんなでガミさんには先を越されてしまったわけですが、逆に自分で始めずにゲストとして出れば podcast に出たい欲を満足させつつ、定期的にやるのめんどくさいという気持ちに抗う必要もないことに気づくのにそう時間はかかりませんでした。雑に話させてよというと二つ返事でOKが出たのでゲスト出演が決まりました。
1回目のゲストのときは、特に深く考えずに今までのキャリアと、今何やってるかと、あと青春のアフターのおすすめをしようと思っていました。だいたいその通りになったと思います。
ですが続く2回目のゲストのときはいろいろ考えました。自身の2回目の転職というトピックはありますが、番組的にどう立ち回ろうかなあということを意識しはじめたのです。僕はパーソナリティの2人と比べると2年ほど長くこの業界にいます。また、しがないラジオへのフィードバックの中には「ガミさんとずっきーさんのキャラが似てる」というようなものがありました。
というわけで2回目のゲストの際には「自分の意見を強く主張する」ことを意識していました。
個人的な感想としては、ずっきーさんもガミさんもそんなに主張が強くなく(「〜〜って思ったんですよね、違うかもしんないけど」くらい)、また自分たちの考えたことや試してみたことが正しくないんじゃないかということを気にしているように感じていました。2
彼ら2人の意見に「それはそう」「それは違う」とはっきりいう役割が必要なんじゃないかと思って話そうとしていました。
結果的にはどうだったんでしょうか。
僕も彼らと同じで悩みながら生きていくタイプの人間なのでそれほど強く言えてないんじゃないかなーと思っています。反省点としては、ちゃんとやりきれなかったというより、違うキャラ付けを選んじゃったかなという感じ。
また話したいことが溜まったら33回目のゲスト出演したいと思っていますが、どういう風に話すか、あるいは素で喋るのか。しがないラジオに限らず今後のパブリックなアウトプットの方向性を考えたほうがいいのかも、という話でした。
LOLIPOP! マネージドクラウド触ってみた
昨日オープンβとしてリリースしたロリポップ!マネージドクラウド、まだまだどなたでも無料でしばらくご利用可能ですので、お気軽にお試し下さい。βのフィードバックも継続的に改善していきますのでご要望もどしどし頂けると幸いです。ひとまずアプリをシュッと試すなど是非。 https://t.co/LhKq9v9mn4
— 松本 亮介 / まつもとりー (@matsumotory) 2017年12月1日
↑を見たので触ってみました。
マネージドクラウドの特徴としては以下の3つが挙げられています。
- 自動セットアップ
- いろいろプリセットが用意されてて選んだらポチで立ち上がる
- 数秒で立ち上がるらしい
- いつでもサイト表示
- オートスケールのことっぽい
- 常にセキュアな環境
- セキュリティアップデートとかが自動だという意味
コンテナという単語が出てきているのでLXCをベースにしたなにかなのでしょう。
とりあえずメールアドレスとパスワードをいれて登録していきます。
登録するとプロジェクト作成画面に進みます。
そういえば登録した覚えがないけどアイコンついてますね。gravatar かな。
どうも下部を見ると Rails 推しっぽいので Rails にしておきます。
まだ灰色で選択できませんが hubot とかあって適当に chatbot をデプロイするのにもよさそうです。
プロジェクトURLがあるのでうれしいですね(って書いたけど heroku も OpenShift もあったわ)
ベータ期間なので無料だしクレカ登録もなく使えるのは嬉しいのですが、ベータが終わったらどんくらいのコスト感なのかは気になるところですね。
さて、プロジェクトを作成するとプロジェクトのダッシュボードにいきなり放り出されます。
ここたぶん何をどうすればいいのかわからなくなる人が多そうですね……。
とりあえず ssh するために ssh 公開鍵を追加しておきましょう。画面が単純なので割愛します。
というわけでプロジェクトトップに書いてある ssh コマンドを叩いてみるのだ
$ ssh -p XXX YYY@ZZZ Last login: Fri Dec 1 17:02:43 2017 from 10.1.1.1 __ __ ____ _ _ _ | \/ |/ ___| | | ___ | (_)_ __ ___ _ __ | |\/| | | | | / _ \| | | '_ \ / _ \| '_ \ | | | | |___ _| |__| (_) | | | |_) | (_) | |_) | |_| |_|\____(_)_____\___/|_|_| .__/ \___/| .__/ |_| |_| ******* Welcome to Lolipop! Managed Cloud ******* YYY@WWW:~$ pwd /var/app YYY@WWW:~$ ls 0000000000000000 current shared user_command.sh.sample YYY@WWW:~$ ls current Gemfile Gemfile.lock README.md Rakefile app bin config config.ru db lib log package.json public test tmp vendor
普通にはいれますね。
オートスケールの設定はこんな感じ。
rails だとイメージ1個しかないんですね。nginx はさもうとかしたときにどこで何すればいいかはよくわからず。
とはいえたぶんそのへんってマネージドクラウドのサービス側でラウンドロビンとかはしてくれるんだろうなー。
static file の配信をうんぬんというのはいまんところ難しそう?CDN使えって感じかな。
ラウンドロビンするって考えると sticky な設定とかがあるのか気になります1
デプロイとかは medium にあるヘルプから察するに push すればよさそうです。
でも remote add したあとに push するだけだと --force いるんじゃないかなあ……。
という気持ちをもとにとりあえず git init して remote を追加した状態で fetch してみましょう
# local $ git init $ git remote add lolipop xxx # 表示されているやつをうつ $ git fetch lolipop fatal: '/var/lib/lolipop/projrepo/.git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
実はまだリモートレポジトリは存在していなかったようです。
念のためマネージドクラウド側のコンソールでも確認
# managed cloud $ ls /var/lib/lolipop/projrepo/ ls: cannot access /var/lib/lolipop/projrepo/: No such file or directory
仕方ないので rails new しておきましょう。
データベースを選んだ記憶はありませんがホスト名が mysql なのでおそらく mysql なのでしょう。
# local $ bundle init # Gemfile を適当に編集 $ bundle install --path vendor/bundle $ bundle exec rails new --database=mysql .
database.yml もなんかいい感じに編集すればいいんじゃないでしょうか
記載内容はダッシュボードから拾ってきてください。
diff --git a/config/database.yml b/config/database.yml index 0c61325..1a636b9 100644 --- a/config/database.yml +++ b/config/database.yml @@ -49,6 +49,7 @@ test: # production: <<: *default - database: tmp-rails_production - username: tmp-rails - password: <%= ENV['TMP-RAILS_DATABASE_PASSWORD'] %> + database: your_database + username: your_username + password: your_password + host: mysql-1.mc.lolipop.lan
password はベタ書きせずに環境変数にいれたくなりますがどーもその機構はない気がするので強い気持ちでコミットします
dbつかえるか確かめたいので適当に scaffold しておきましょう
$ bin/rails g scaffold Comment text:text $ git commit -m 'comment' $ git push lolipop master
と、これは別に意図してなかったのですがうっかり db:create, db:migrate を打つのを忘れてました。てへぺろ
なので db/scheam.rb は更新がない状態でデプロイされましたが db:create, db:migrate されたログが残って普通に起動しましたね
$ git push lolipop master (中略) remote: Database 'XXX' already exists remote: == 20171202150523 CreateComments: migrating =================================== remote: -- create_table(:comments) remote: -> 0.0046s remote: == 20171202150523 CreateComments: migrated (0.0047s) ========================== remote:
普通にアクセスできますね。
最初は、レスポンスが返ってくるまでに13秒くらいかかってましたが、dev tool開いたあたりからいきなり早くなりました。なぞい。
謎いなーと思いながらダッシュボードを見てたらコンテナ数が増えてたみたいです。
うんうん、そしたらはやくなるかもねって思ったのですが、コンテナの数が増えたからって1ユーザーのリクエストがそんな早くなるわけないですよね。
うーん、増えたコンテナに性能の善し悪しがあるのでしょうか?
あと適当にさわってるとときたま落ちます。落ちたときに ssh してログをみてみましょう。
適当にエスパーして $HOME/current/
が現在のアプリケーションだと考えるとその先の $HOME/current/log/production.log
を見ればよさそうです。
vim が入ってるので適当にひらいておきます(less はなかった)
I, [2017-12-02T15:56:45.157297 #4] INFO -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Started POST "/comments" for x.x.x.x at 2017-12-02 15:56:45 +0000 (略) W, [2017-12-02T15:56:45.159596 #4] WARN -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Can't verify CSRF token authenticity. I, [2017-12-02T15:56:45.159979 #4] INFO -- : [de41a671-8b69-4771-8c0e-83187b2c6456] Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms) F, [2017-12-02T15:56:45.161589 #4] FATAL -- : [de41a671-8b69-4771-8c0e-83187b2c6456] F, [2017-12-02T15:56:45.161650 #4] FATAL -- : [de41a671-8b69-4771-8c0e-83187b2c6456] ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
うーん、CSRF対策のトークンの検証で死んでますね。
たぶんなんですけど画面をレンダリングしたコンテナと違うところにいったら死ぬのかな……。
まとめ
現状での懸念点は以下でしょうか
- 環境変数を管理するクチがない?
- プロジェクトに対してミドルウェアを挟む余地が今のところなさそう
- いずれちゃんと対応されそう
- コンテナベースなんだけどライフサイクルがわからない
- テクニカルなドキュメントが充実すれば……
- デプロイ時に何が起きるのかブラックボックス過ぎて気になる
- 知りたいし変更したい
- そもそも ssh してる先ってどこなんだろ?
- コンテナの中なの?コンテナのホストなの?
- これもまあドキュメントが充実すれば
- ssh先のディレクトリ構成がよくわからん
- cap っぽい雰囲気を感じたけど
- ログみたいときにいまのところ ssh するしかない
- いずれちゃんと対応され……るのだろうか?
- 他サービスに流しちゃうほうが楽かも
- どんくらいのコスト感なのか知りたい
- 有料化が決まる頃にはわかるので待つだけ
正直、いまのところはお手軽感よりブラックボックス感がつよい印象です。今後に期待ということで。
追記:
つかったプロジェクト削除しようとしたらできなくて困っている……
削除確認用にプロジェクト名をいれたあとパスワードをいれても削除に失敗しました、と出てしまう。
変な文字列いれるとパスワードが違うと言われるので認証はできてるみたいなんだけど。
時間課金とかになるだろうから、削除リクエスト自体はこの時間で受けてほしいなーとおもいつつリソースはまだ使えちゃうからどうなんだろうなと思っている
-
(フラグ↩