Tech Racho エンジニアの「？」を「！」に。
  1. TOP
  2. 開発
  3. 週刊Railsウォッチ（20181217）Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか
  • 開発

週刊Railsウォッチ（20181217）Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか

こんにちは、hachi8833です。先日のRailsdm Day 4ではルームAで終日配信担当だったのでルームBの出し物がわからずじまいです。

  • 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
  • 「つっつきボイス」はRailsウォッチ公開前ドラフトを社内有志でつっついたときの会話です👄
  • 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください

⚓Rails: 先週の改修（Rails公式ニュースより）

⚓コレクションプロキシのdelete_allがcountを返すようになった

# activerecord/lib/active_record/associations/has_many_association.rb#L99
          count = delete_count(method, scope)
          update_counter(-count)
+         count
        end

つっつきボイス:「ActiveRecordのdelete_なんちゃらメソッドはcountを返すんですが、それがdelete_allの場合返ってなかったので修正したということですね」「コレクションプロキシというのが今ひとつわからなくて」「自分も何が違うのか今までよくわかってなかったので調べたんですがどうやら以下みたいです」

  • CollectionProxy: has_manyとかを単独で呼び出した時のインスタンス
    • user.posts.class => Post::ActiveRecord_Associations_CollectionProxy
  • Relation: whereとかで絞った時のインスタンス
    • user.posts.where('id > 5').class => Post::ActiveRecord_AssociationRelation

「このcountって『10件殺した』みたいな数なんでしょうか？」「ふむむ...affected countということだからそうでしょうね」

「ちなみにRailsの影響の及ばない低レイヤだと、DAO（データアクセスオブジェクト）やデータベース系の関数は、削除や更新に成功したときに1、失敗したときにそれ以外の数値を返すという挙動のものが多いですね」「へぇ〜😳」「この場合Rails側で吸収してそれっぽくしてるのかも」

参考: Data Access Object - Wikipedia

追いかけボイス

⚓unpermitted paramsログのメッセージに色を表示

# actionpack/lib/action_controller/log_subscriber.rb#L
    def unpermitted_parameters(event)
      debug do
        unpermitted_keys = event.payload[:keys]
-       "Unpermitted parameter#{'s' if unpermitted_keys.size > 1}: #{unpermitted_keys.map { |e| ":#{e}" }.join(", ")}"
+       color("Unpermitted parameter#{'s' if unpermitted_keys.size > 1}: #{unpermitted_keys.map { |e| ":#{e}" }.join(", ")}", RED)
      end
    end

つっつきボイス:「colorメソッドってこうやって使えるのか！」「paramsはいわゆるstrong parametersでしょうか？」「だと思います」「色が付くようになったのはいいな☺️」

参考: color -- ActiveSupport::LogSubscriber

⚓ActiveJob::Base#enqueueがfail時にfalseを返すようになった

このパッチを当てる前は、before_enqueueでコールバックチェインがabortされた可能性がある場合にジョブが実際にenqueueされたかどうかを確認する手段がなかった。 

class AbortBeforeEnqueueJob < ActiveJob::Base
  before_enqueue { throw(:abort) }
end

> AbortBeforeEnqueueJob.new.enqueue
=> #<AbortBeforeEnqueueJob:0xXXXXXX @arguments=[], @job_id="0d5ef7b9-d32b-4c83-b8cf-44ec31e9d6d9" ...

このパッチを当てることで、ジョブがenqueueされなかった場合にfalseを返すようになる。 

> AbortBeforeEnqueueJob.new.enqueue
=> false

この部分はActiveSupport::Callbacksの設計に従った。

コールバックチェインが停止した場合はfalseを返す。それ以外の場合はブロックの結果を返す。コールバックが設定されなかった場合はnilを返す。コールバックが設定されたがブロックが与えられなかった場合はtrueを返す。

#enqueueの戻り値が変わるのでbreaking changeと考えられるであろうことは承知しているが、よりよい制御のために変更する価値があると思う。
同PRより大意

つっつきボイス:「#enqueueに失敗したらfalseを返すと」「before_enqueueでコールバックチェインがabortされた可能性がある場合に...ってややこしい😅」「まあ確かにキューが溢れている場合なんかに#enqueueが失敗する可能性がまったくないわけではないから必要なのかも: ということは返り値もチェックしないといけないのかなー、#enqueue失敗したら例外出して欲しい気もするけど」

「お、テストコードを見るとActiveJob::Base.return_false_on_aborted_enqueueっていう設定があるし: configで挙動を変えられるようになったってことか」「return_false_on_aborted_enqueueがtrueならfalseを返し、そうでなかったらwarningを返す」

# activejob/lib/active_job/enqueuing.rb#L
      run_callbacks :enqueue do
        if scheduled_at
          self.class.queue_adapter.enqueue_at self, scheduled_at
        else
          self.class.queue_adapter.enqueue self
        end
+       successfully_enqueued = true
+     end
+     if successfully_enqueued
+       self
+     else
+       if self.class.return_false_on_aborted_enqueue
+         false
+       else
+         ActiveSupport::Deprecation.warn "this will return false, set config.active_job.return_false_on_aborted_enqueue = true to remove deprecation."
+         self
+       end
      end
-     self

「しかし#enqueueの戻り値とかいちいちチェックしたくないなー😆」「キューを投げたら忘れたいと」「でも非同期タスクではした方がいいんだろうなー🤔」

⚓Ruby 2.6でBigDecimal互換問題を修正

# activesupport/lib/active_support/xml_mini.rb#L61
     # TODO use regexp instead of Date.parse
     unless defined?(PARSING)
       PARSING = {
         "symbol"       => Proc.new { |symbol|  symbol.to_s.to_sym },
         "date"         => Proc.new { |date|    ::Date.parse(date) },
         "datetime"     => Proc.new { |time|    Time.xmlschema(time).utc rescue ::DateTime.parse(time).utc },
         "integer"      => Proc.new { |integer| integer.to_i },
         "float"        => Proc.new { |float|   float.to_f },
         "decimal"      => Proc.new do |number|
           if String === number
            begin
              BigDecimal(number)
            rescue ArgumentError
-             BigDecimal("0")
+             BigDecimal(number.to_f.to_s)
            end
          else
            BigDecimal(number)
           end
         end,

つっつきボイス:「お、2.6に対応」「『早速2.6で動かしてくれてありがとうー』ってメッセージがありました」「BigDecimal("0")が問題だったのか」「このxml_mini.rbって何だろう...?あ、XMLパーサーか」

⚓左マウスボタン以外のクリックでイベントをトリガしないよう修正

つっつきボイス:「これはrails_ujsの更新」「asyncTestなんてメソッドがあるのか↓」

# actionview/test/ujs/public/test/data-disable.js#L253
+asyncTest('right/mouse-wheel-clicking on a link does not disable the link', 10, function() {
+ var link = $('a[data-disable]')
+  App.checkEnabledState(link, 'Click me')
+  link.triggerNative('click', { button: 1 })
+ App.checkEnabledState(link, 'Click me')
+  link.triggerNative('click', { button: 1 })
+ App.checkEnabledState(link, 'Click me')
+  link.triggerNative('click', { button: 2 })
+ App.checkEnabledState(link, 'Click me')
+  link.triggerNative('click', { button: 2 })
+ App.checkEnabledState(link, 'Click me')
+ start()
+})
+

「マウスの左ボタンをクリックしたときだけ発火するようになったってことみたいですね」「Changelogを見ると、Firefoxだと右クリックやスクロールホイールのクリックでも発火するってある」「ブラウザで挙動違ってる...！」

⚓番外: 今週のContributors

つっつきボイス:「普段はあまり見てないところですが」「うん、これはいつも出てますね」「kamipoさんは2位、y-yagiさんは4位、などなど」

⚓Rails

⚓Railsdm 2018 DAY 4にて

きりがないので絞り込みました。あとRailsには昔skip_validationオプションがあった説を現地で聞きましたが今も一応unless: :skip_validationと書けるようです。

参考: validate -- ActiveModel::Validations::ClassMethods

dependabot


同サイトより

つっつきボイス:「このdependabotが評判良かったので」「おー、これは今日の勉強会で話したセキュリティ系のgemみたいなやつで、しかもプルリクまで自動で上げてくれるのね: これを入れておけばMRをマージするだけでセキュリティに対応できるというのはなかなかよさそう😍」「そんな感じです」「見た感じGitHub縛りっぽいかな: GitLabも対応してればいいんだけど」「#676を見るとGitLabにも対応はしているっぽいですが、submoduleの更新で少し問題があるみたい」

pixivさんの「Railsアップグレードガイド」

つっつきボイス:「これも評判よかったので」「新しい話題はなさそうだけど、アップグレードで困っている人は常にいるので『Rails滑らない話』の定番ですね☺️」

Gry

つっつきボイス:「今のコードで通るrubocop.ymlを生成してくれるのか！これもなかなかよさそう😍」「コードを忖度してくれるのっていいかも」「手で書いているときりがないですしね」

⚓Railsプロジェクト初期にやりがちな失敗トップ5（RubyFlowより）

つっつきボイス:「そんなに大きな記事ではないかなと思いつつ」

⚓after_*系フックは要注意

「あーafter_createは結構ツライよね😅」「というと？」「after_createは、フックでエラーが起こったときに何が起こるかを考えると割と地獄感伝わると思う💀: after_createでうっかりcreateを実行するとselfでエラーになってどうやってもcommitできなくなったりとか（あるいはロールバックがループするとかかな）」「ひょえ～😱」

「記事にはafter_updateの話もあるみたいだけど、after_*系フックはよ〜く考えて、何が起こっても大丈夫なようにしておいてから使わないと、割と簡単に死ねます🎃」

「そういえば1つのフォームで複数のモデルをsaveしたいときにafter_create使おうとしたことがあるんですけど、やったらマズイんでしょうか？」「やってもいいんだけど、結構注意深くやらないと簡単に死にますね: 少なくともバリデーションは事前に全部通しておかないとヤバい」「そうでしたか！」

「after_createで何かをsaveするということは、親はcreateに成功してcreate処理が完了した後にバリデーションがかかるということになるので、絶対とまでは言わなくても基本的によくない場合が多い」「ふむぅ〜」

「記事のサンプル↓にあるみたいに単にメール送信に使うだけでもダメな感じでしょうか？」「これもたぶんダメでしょうね〜: これだけ見て言うと、メール送信に失敗した場合にロールバックしちゃうんじゃないかな？: メールを送る前にロールバックするならいいんだけど、メールを送った後でロールバックされてしまうと当然問題になる😎」「あーやっぱり」「つか本来メール送信とかはafter_createでやるべきじゃない」

# 同記事より
after_create :send_welcome_email

「『ユーザーの作成が完了しました』メールなんかは、面倒なんだけど、create処理とメール送信処理は分けておく方がよい結果になることが多いっすね」「モデルのフックじゃなくてコントローラでやる方がいいと」「少なくともコントローラではcreate処理とメール送信処理を分けておく方が、安全🏥」「記事を見るとCommandパターンとか使うといいよって書いてありますね: ちゃんとしたやり方だとServiceObjectっぽいものにまとめる、めっちゃ簡単にやりたいならコントローラにprivate method定義ってイメージ」

「after_createはafter_commitの手前のフックなんですが、何らかの理由でcommitに失敗することは十分ありえるので、after_*フックでメール送信はできれば避けたいっすね」「そうそう」

「たとえばメール送信は非同期ジョブの形にするといいかもですね: そうしておけば、メール送信の時点でユーザーのレコードがなければジョブがfailするだけで済むので、安心できる😌」「いずれにしろ、メール送信はデータベースで確実に永続化が完了して、もうロールバックしないことが確定してから行うべき」「メールは送信してしまったらロールバック不可ですからね」「大量のメールが送られたり送られなかったりしたら悲惨😭」

「deliver_laterで送信するならありかも？」「それはありだと思う: でもそれをモデルでやるのはちょっとね😅」「そうかも☺️」

参考: deliver_later -- ActionMailer::MessageDelivery

「いずれにしろ、after_createみたいなフックは確実に冪等に書くべき: さもないと、データメンテ作業のはずみで、二度と更新できないカラムができてしまったりするというありがちなパターンに陥る」「before_*系のフックはそこまでひどいことにはならないことが多いかな」

⚓早すぎるDRY

「記事の続きに戻ると、次はDRYをやりすぎるなという話」「これは早い段階でDRYな最適化をやりすぎるなということでしょうね: wrong abstractionとか書いてあるし」「ふむふむ」「コードの書き始めの頃に、あっこことここは一緒だと思ってDRYに書いてみたら、先に進んでみたら実はその粒度ではなかった、なんてことはとてもよくある話☺️」「最初は素直に書いて後からDRYにするぐらいでいいのかも🤔」

「ちょうど今日出してもらったRSpecえかきうた記事↓もそうですが、『お前はDRYにせいと言うけど、お前の見ているスコープ、狭すぎじゃね？』みたいな😆」「ははは😆」「広い範囲で見るとDRYにすべきじゃなかったなんてことはよくあるし」

RSpecえかきうた

⚓YAGNI判定の落とし所

「早すぎるYAGNIもそうですね: ちょうど最近社内で設計を巡って軽く殴り合う微笑ましい光景を目にしたんですが、自分視点で言わせてもらえば、二人ともYAGNIなんじゃね？って🤣」「🤣」「🤣」

「自分の考える設計上のスイートスポットからプラマイどこまでが許せるかって人それぞれ違うんだなって🤣: そのときは絶妙に二人のYAGNIがプラマイで収まりきらない範囲の違いになってて、でも自分はテストがあって動いているから別にいいんじゃね？って思ったり🤣」「🤣」「テストがないとさすがにつらいけど」（以下延々）

「でYAGNIの話だけど、記事ではproblemとは書いてあっても確固たる答えがあるものでもないので、結局YAGNIについては相談できる人がプロジェクトにいるかどうかがポイントかなと思うわけです」「落とし所」「決めてくれる人がいれば、たとえそれがYAGNIであってもやりやすい」「考える時間が少なくて済む方が重要」「よほどのYAGNIならともかく🤣、たいていのYAGNIはちょっと頑張れば達成できる程度のものだし」「最終的に決めてくれる調停者が重要」

YAGNIを実践する（翻訳）

「次のキャッシュもまあ同じような話だからいいか」

⚓なくならないTODOコメント

「いつまでたってもなくならないTODOコメント😆」「😆」「TODOって乱用されがちなところがあって、TODOなのかFIXMEなのかNOTEなのかはもう少し決めて使い分けた方がいいと思う」「Rubyスタイルガイドにも一応ありますね↓」「TODOは修正しないとリリースできないレベルのものにして、そうじゃないものはFIXMEとかREFACTORとかで書くとかね」「そうしないと何でもTODOになっちゃうし」

Rubyスタイルガイドを読む: コメント、アノテーション、マジックコメント

TODO
後日追加が必要な、不足の機能
FIXME
修正の必要な箇所
OPTIMIZE
パフォーマンス低下の原因となる箇所
HACK
リファクタリングの必要なマズいコード
REVIEW
意図したとおりに動くかどうかチェックが必要

「個人的にはFIXMEをよく使うかな」

⚓Rails 3.2を5.2.2にアップグレードしてわかったコツ（RubyFlowより）

つっつきボイス:「この間のGitHubのRailsアップグレードに匹敵する大ジャンプ⛷」「これは5.1から5.2が遠いだろうな」「あ、そこも遠いんですか？」「Webpackにするかどうかで変わると思いますが」

「zeusなんて懐かしい！」「今はbootsnapがあるから要らないヤツですね」「これは取り替えるだけでいいからラク」

「記事ではjquery-railsも外してますね」「jquery-rails、そんなものもあったな〜」

「ここでのアップグレードはそんなに大仕事ではなさそうかな☺️」

⚓Active Storageチートシート（RubyFlowより）

つっつきボイス:「短いメモ書きですが」「お、ストリーミングのサンプルコード↓があるのはちょっといいかも😍」「ストリームでうまくできるものだったらストリームで出したいし」

# 同記事より
# Stream from controller to show in browser (when supported)
response.headers["Content-Type"] = @model.image.content_type
response.headers["Content-Disposition"] = "inline; #{@model.image.filename.parameters}"

@model.image.download do |chunk|
  response.stream.write(chunk)
end

# Stream from controller to download
response.headers["Content-Type"] = @model.image.content_type
response.headers["Content-Disposition"] = "attachment; #{@model.image.filename.parameters}"

@model.image.download do |chunk|
  response.stream.write(chunk)
end

⚓その他Rails


同サイトより

以下のツイートで知りました。

Rails方面であまり見かけないのは、Capistranoが強いから？

つっつきボイス:「Rundeckって初めて見たんですが、RailsやRuby以外でデプロイに使われてるみたいですね」「いわゆるジョブのツールっぽいかな？」「cronの立派なヤツかなと思ったんですが」「というよりはJenkins↓に近いツールに見える: プロシージャとか書いてあるし、Capistoranoみたいなこともできそうだけど、それも含めてJenkinsっぽく思える」


jenkins.ioより

「Rundeckにはジョブ実行の管理↓とかACL（Access Control List）とかあるからやっぱりJenkins的かな: そういえばJenkinsのACLって割とイケてないから、後発の分テンプレートとかがよかったりするのかも？🤔」


rundeck.comより

「Jenkinsでアクセスコントロールってどの辺にあるんでしょうか？」「ユーザーに制限をかけたりとかそういうあたり: このRundeckにもLDAP云々と書いてあるぐらいなので、どのユーザーがどのプロジェクトを参照できるとか、この人はビルドはできるけど設定変更はできないとか、その辺ですね☺️」「なるほど！」「Jenkinsはその辺があまり痒いところに手が届いてない感」

「ツイートでも『sshでscript叩いて』とあるし: それで思い出したけど、Webistrano↓ってもう誰も更新してないんだろうか？」「お、そういうのがあるんですね！」「リポジトリ見ると8年前から更新されてない...😢」「ドメインも売りに出されてる😢」

「例のCapistranoのWeb GUI版なんですが、出来がどうも今ひとつで、しかもずっと更新されてないなと思ってたらやっぱりそうだったし😅」

「実は社内でもごく一部でWebistranoがデプロイシステムとして使われてたことがありますよ: WebistranoってCapistranoの用語がそのまま使われているところが多くて、capコマンドがある程度分かる人じゃないと結局デプロイ手順が煩雑になってしまうという」「あー、わかりみ」「もうちょっと誰にでもわかるようなデプロイボタンが欲しかったんだけどなー😢」「Webistranoが社内で普及しなかった理由も結局それ」

「その意味で、最近のGitLabはデプロイもできるようになってきているから、そっちに寄せた方がいいかなとも思ったり」「結局Web GUIってコマンドラインが使えない人が使うものなので😅、とにかく簡単かつ失敗しないものでないと困る」


gitlab.comより

「ybot（BPS社内Slackで使われているSlack bot↓）は、そのSlackチャンネルを見られる人なら操作できるからラクといえばラクですね」「あれはアクセス制御という面ではかなりユルいので、あくまで社内限定ですね: 本来なら誰がデプロイできるかまで管理されるべき」「たしかに」

BPS社内Slackに棲まう和みのSlack botが実は優れものだった件

⚓Ruby

⚓Querly

以下のツイートで知りました。

つっつきボイス:「くぅえーりー？」「これ、TechRachoがRailsdmで発表したとき↓の翌日に発表されてましたよね」「あーそうだったかも💦」「発表してたhachi8833さんが知らないのが逆に疑問でした😆」「面目ないっす: たぶん2日連続の長丁場で体内のブドウ糖が底をついてたかも...🍬」

「TechRachoの舞台裏」をRails Developers Meetup 2018で発表してきました

↓こちらがsoutaroさんの発表でした。

「そういうわけで、先週のRailsウォッチのupdate_columnみたいなのはquerlyでチェックするといいというツイートで今頃気づきました」「このツールのメンテナンスをどのぐらい頑張れるかがポイントかも: 自社サービスでがっつりメンテしているなら十分やれると思うんですが、BPSみたいにバラエティに富んだ案件を抱えていると、すべての案件に通しでかけられるチェックって意外と手頃なものがなかったりするという😅」「update_columnみたいに、これは使うのをやめようというアンチリストを作ってやるのにはquerlyはいいかも🤔」「それならrubocopに一括で面倒見て欲しいなとも思ったり😆」

「soutaroさんの発表は割とプロジェクト固有の使い方で、このメソッドはこのプロジェクトでは使うのをやめよう、みたいな用法だったと思う」「プロジェクト固有の書き方とか、プロジェクトでしか使ってないDSLを扱おうと思ったら、rubocopの手に余るので、こういうASTベースのツールでさばかないといけなくなる」

「こう書くのはやめようみたいなアンチリストを3つとか4つぐらいにうんと絞ってquerlyで通しでかけるというのはどうでしょう？」「そういうのはどちらかというとrubocopでやるべき」「その逆に、プロジェクトの中の人でないとわからないようなものすごくコンテキストに依存した書き方についてquerlyを使う方がいいんじゃないすかね」「同意: querlyはプロジェクトに依存したものを対象にチェックする、逆にBPS社内案件共通でかけたいものはそれ用のrubocop.ymlを作ってインクルードすべきだと思う」「なるほどー！」

「querlyにはDSLも処理できるというメリットもあるから、RubyのコードだけどDSL化されてしまっているところでも対象にできる😍」「テストコードにも使えるってことですね😃」「もしかしたらReadme.mdなんかもチェックできたりして？🤔さすがにRubyコードじゃないとだめかな？」「RubyのDSLまでみたい」

「querlyはプロジェクト固有のチェックに向いていて、大規模プロジェクトになるほど欲しいヤツだと思いますね」

「そういえば似たような話で、たしかShopifyがコードをチェックするプロジェクト固有のテストを書くようにしているという話をこの間のRubyKaigiでしてた気がする: 確かあるメソッドを特定の方法で呼んだときにはdeprecation alertを出す、みたいな感じで」「探しときますー↓」

参考: [RubyKaigi 2018] Avoiding Cognitive Overload: Tests For Productivity and Education -- スライドと動画とレジュメがあります
参考: RubyKaigi、shopifyのテストの話が良かった · hoshinotsuyoshi.com - 自由なブログだよ

「Shopifyには100人以上エンジニアがいるんですが、そのときにShopifyが言ってたことをかいつまんで言うと、ドキュメントを読んでそれに従えというのはその規模だともう不可能なので😆、規則違反のときにwarningなりalertなりを出す仕組みを作るべき、ということでしたね」「それ、わかりすぎる！」「そりゃそうだ😆」

⚓mruby 2.0が公開

つっつきボイス:「mrubyはRuby本家とは違ってリリースが割とアドホックな感じ😆」

⚓その他Ruby

つっつきボイス:「SOLIDの5つのショートコードを紹介するという記事なんですが、コード例が3つしかなくて後の2つは外部の一般的な説明にリンクされてたので、書いてる途中なのかと思っちゃいました😆」

⚓Ruby trunkより

⚓object_idと_id2refを非推奨にしたい

参考: module function ObjectSpace.#_id2ref (Ruby 2.5.0)

これらのメソッドはRuby 3.0で削除できるようただちに非推奨化すべき
* 開発者の期待することを行っていない
* 主張しているほど信頼がおけるわけでもない
* どのユースケースでも診断の難しいバグにつながる
同issueより大意

つっつきボイス:「_id2refって初めて知りました」「object_idはあまりにRuby内部に立ち入りすぎていると」「urabeさんは全面同意してますね」「まあ触るべきでないものには触らないという話かな」「他にもっと適切なメソッドってあるんだろか？🤔」「アンダースコア_で始まるメソッドって？」「システム系のメソッドで基本触るな、みたいなものに使われてますね: __id__とか」「おー」

参考: instance method BasicObject#__id__ (Ruby 2.5.0)

「話逸れるけど、urabeさんがこうやって書いてるアスキーチャート↓、何かツール使って書いてるのかな？」「手書きだとしんどそう」


同issueより

追記（2018/12/17）

同issueへのMatzのコメント:


同issueより

⚓クラウド/コンテナ/インフラ/Linux/Serverless

⚓Linuxのプロセススケジューラのしくみ

つっつきボイス:「この間Slackに貼っていただいたスライドです」「ああスケジューラ周りの話: これは結構大事な話」

「なにしろ『詳解linuxカーネル』が古すぎて使い物にならないので😆: 読んで意味がないことはないんだけど、何しろ第3版が出たときはスケジューラが新しくなる前だったので」「おー！」「スライドにはO(1)スケジューラも紹介されているけどこれですら古いという」「前はO(1)じゃなかったのか...」

参考: ランダウの記号 - Wikipedia -- O(オー)記法についての解説

「O(1)より前の頃はコンパイル時にスケジューラを指定する仕様だったんですが、その後でスケジューラを差し替えられるようになってたはず」「おぉー！」「しかもスケジューラを複数登録できるようにもなったはず」「マルチスケジューラ！」

「とにかくこのスライドはざっと見ておくといいと思います: 例の『Linuxのしくみ』↓に通じるいい内容❤️」

⚓その他クラウド

つっつきボイス:「Istioって何だろうと思って」「オープンソースとして開発が続けられてきたソフトウェア...ってなんやねん😆」「同じPublicKeyの別記事↓がよさそう」

そしてIstioはサービス間を安定的かつセキュアにつなぐためのサービスを提供します。サービス間のトラフィックの管理やルーティング、ロードバランシング、暗号化通信や認証サービス、モニタリングなどを実現するのです。これが「サービスメッシュ」です。
同記事より

「あー、この間AWS reInventでまさにこれと似たものが発表されてたなー、何だっけ...App Mesh！↓」

参考: AWS App Meshが発表になりました。 | Amazon Web Services ブログ

「結局マイクロサービスって、多数のマイクロサービス同士の接続をどう管理していくか、失敗した通信をどうログに出すか、とかが問題になってくる」「ふぅむ〜」「PublicKeyの記事を読んだ限りではそういうものに見える」「他にも、密結合されたマイクロサービスをどうやってきれいに更新するか、なんてのもそのままだと難しいし」

サイトには由来が見当たりませんでしたが、Istioは以下のもじりなんでしょうか？KubernetesやDockerと同じく海にちなんだ命名の気がしました。

Istiophoridae {名} : 《魚》マカジキ科

「Googleのこういうプロジェクトはオープンソースでやってるのがいいですね👍: AWSはどうしてもAWSに身を任せることになるので自前でホスティングとかはできないし☺️」

⚓SQL

⚓ActiveRecord+MySQLで巨大テーブルをiterateしたときのパフォーマンス（RubyFlowより）

つっつきボイス:「condition付きでiterate、これはいろんな人が何度となくやってきたことですね」「そしてこれをやるには、orderedのサロゲートキーが必須: でないとやり残しができちゃうので」「ふむふむ」「なのでこういうときにはidカラムが割と便利😋」「確かにー: やったことあったかも」

「サロゲートキーは一部地域で目の敵にされることがまれによくあるようですが😆、実用的にはこういう使い方もあるということで」「3日ぐらいかけてデータベースに更新かけるときに使った気がする: 今日はここまで、みたいな😆」「2ちゃんの『ここまで読んだ』ですか😆」

「それはそれで厄介なこともあって、サロゲートキーは変わらないとしても、作業中にアップデートがかからないことだけは保証しないといけないっすね」「そうなんですよ〜」「開始と終了でタイムスタンプが合ってない可能性だってあるし: まそれは別の問題ですが😎」

⚓PostgreSQLのcitextでslugをいちいち小文字にしなくていいようにする（RubyFlowより）

つっつきボイス:「えらく短い記事です」「citextってのを使うと」「これ、case insensitiveなテキストのことか！」「PostgreSQLのテキスト型は何もしないと大文字小文字を区別すると」「常識ですね🧐」

参考: PostgreSQL: Documentation: 11: F.8. citext

「citext、でもあんまり使わなそう😆: RFCレベルではcase insensitiveなメールアドレスぐらい？」「日本人にはあまり縁がないかも」「メールアドレスに絵文字を使う人もいるから油断ならない😅」

「話は逸れますが、日本語だと大文字小文字と表せば済むところが、英語だとuppercaseやlowercaseだったり、case (in)sensitiveだったり、capitalize（頭だけ大文字）とかいろいろあって面倒ですね😓」

⚓JavaScript

⚓Flutter 1.0の日本語ドキュメント

Dartで書かれるのでJavaScriptとは別ですが。

参考: Dart - Wikipedia
参考: Googleが「Dart 2」発表、Dartを再起動。iOS/Android用ライブラリ「Flutter」と共にWebとモバイルのクライアント開発にフォーカス － Publickey

つっつきボイス:「さてFlutterは流行るだろうか？🤔」「社内でもFlutterラブ❤️の人がいますね」「今更だけどFlutterってGoogleが作ってるのか！」「これでFirebaseと戦うんでしょうか、ってこっちもGoogleだった💦」

Flutter: 標準ウィジェットをコピーして改造する

「そしてDartが生まれ変わると: Dartはやっぱり"来る"言語だったんだなー😆」「Hummingbird！って何だっけ」「FlutterでWebアプリを作れるヤツ↓ですね」

参考: Google、FlutterアプリをWebアプリへ変換する「Hummingbird」発表。Web開発言語としてDartが帰ってくる。Flutter Live '18 － Publickey

「記事をスクロールしてたら哀愁あふれる昨年の見出しが↓😆」「年に一度は思い出すから、みたいな😆」

参考: TypeScriptが標準言語になっても、Dartのことは忘れてませんよとGoogle担当者がフォロー － Publickey

「KotlinやSwiftやGoogleのDartみたいに、すべてを忘れて新しい言語に行きたい！っていう流れを何かと見ますね〜」「みんなもすべてを忘れて先に行きたいんでしょうね👋」

「よく言われる話ですが、結局キラーアプリがあるかどうかなんでしょうね」「自分たちだってRailsがなかったらRubyをこんなに触ってないだろうし😆」

⚓CSS/HTML/フロントエンド/テスト

⚓デザイナーが教える、Rails UIを簡単に改善するコツ

これもこの間のRailsdmで評判になっていました。

つっつきボイス:「これ、BPS社内のWebチームで即役に立ちそう！って思いました: Webデザイナーの方が、CSSアニメーションとかのいい感じのデフォルトパラメータを教えてくれます」「Akatsukaさんの昔の『ズルいデザイン』↓の現代版みたいな感じかな」

「なるほど、CSSアニメーションとかイージングのデフォルト値！」「とりあえずどれを選んどけばいいのか知りたいヤツ」「具体的な数値で？」「ですです: ディズニーアニメのノウハウとかも参考にした、おおむねいい感じになれる値だそうです」「おーそれいいかも😍」

「そうそう、最近学生にanime.js↓を紹介したんですが、これは割とよくできていて、vanilla jsで使えて、しかもCSSアニメーションを使っているという😋」「おー！筋がよさそう」「アニメーションの動きもなかなか色っぽい😍」


同リポジトリより

「anime.jsならjsでanimeと書けばすぐ使えるのでとっても便利: ただイージングのオプションなんかめちゃめちゃいっぱいあってどれにしようか迷う😆」「😆」「😆」「そういうときにさっきの発表が役に立ちそうですね😋」

var cssSelector = anime({
  targets: '#cssSelector .el',
  translateX: 250
});

「冒頭の発表では、確か人間の認知は1秒間に約4回変化をチェックするポイントがあって、じゃ250msecでいいかというと、そこからさらに別の考察で調整して...という感じで値をおすすめしてました」「今のオレたちが欲しいのは、まさに今使える最大公約数的なデフォルト値！」「それだけのためのチートシートが欲しい〜😆」

⚓言語

⚓文章圧縮AI

昔のMac OS 8あたりのSherlockにも要約機能があったらしいです。ちっとも気づきませんでした。

参考: すげー！！！AIの今北産業、超優秀！！！

つっつきボイス:「はてブで浮かび上がってたので」「これは文章を要約するやつ...？」「という触れ込みです」「適当にTechRacho記事食わせてみっか」「やべ、要約がコードだけになった😆」「もうちょい文章だけのものを食わせた方がいいのかも」

「出現頻度が高いものが出てくる？」「たぶんそんな単純なものではないと思うけどなー: AIなり回帰分析なりを経ている気はする🤔」

作者によるマニュアルを後で見つけました↓。

参考: 長文を３行ぐらいで纏めてくれるエンジン IMAKITAを作ってみました - コンピュータ将棋 Qhapaq

⚓その他

⚓Google Sheetsでドメインチェック


同記事より

つっつきボイス:「Google Sheetsでwhoisするみたいなやつ？」「そんな感じでした」「Google SheetsはこうやってJSがすいっと動くのがいいっすね😋」「同意！😤（VBAキライ〜）」

「ところで、Google Spreadsheetっていつの間にかGoogle Sheetsに名前が変わったんですね（その割にはおおっぴらなお知らせが見当たらない...）」「Google Spreadsheetという名前がドキュメントからだいぶ除去されつつあるし、API名もSheets APIだし、新しめのドキュメントではだいたい置き換わってますね」「短すぎると心もとないというか可読性が落ちる感もあるかな」「GoogleSheetsみたいにくっつけて欲しい😤」

「ただねー、日本ではSheetsっていうと布団のシーツかと思っちゃう😆」「😆」「😆」「日本では単数形のシートにしとけばいいのに😆」

「どうしても日本語で書きたい人いますからね〜新聞社とか😆」「シーツAPIとか書くと新しいIoTか何かかと😆」「たまに新聞読むとカタカナ表記で見てびっくりすることありますね: ギットハブとか😆」「読めない😆」

⚓番外

⚓Deep life

参考: 地下深部に広大な「生命体の森」 国際研究で発見　写真1枚　国際ニュース：AFPBB News

つっつきボイス:「海底のそのまた下に生息してる生物だそうです」「海底のさらに2500m下！」「どんだけ気圧高いんだと」「地底人出てくる⛑」「うかつに地上に持ち込んだら生物たちが急に元気付いたりしないといいけど👽」

今回は以上です。

お便り発掘

バックナンバー（2018年度後半）

週刊Railsウォッチ（20181210）update_columnは要注意、DBカラムコメントは書こう、個人情報扱いの注意点、Capistranoはやっぱりいいほか

今週の主なニュースソース

ソースの表記されていない項目は独自ルート（TwitterやRSSなど）です。

Rails公式ニュース

RubyFlow

160928_1638_XvIP4h

Publickey

publickey_banner_captured


タグ
この記事を書いた人

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版のコンテンツ監修、Railsガイドのコンテンツ作成を担当。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.comに移転。Amazonウィッシュリスト: https://bit.ly/32aAmiI

hachi8833の書いた記事一覧へ

本記事の内容へのお問い合せはTwitterで@techrachoへMentionまたはDMにてご連絡頂くか、運営会社であるBPS株式会社のお問い合せフォームよりお問い合せ下さい。

CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。
CONTACT FORM