週刊Railsウォッチ(20181105)DBマイグレーション9つのコツとハマった話、Railsのモデルとディレクトリの設計ほか

こんにちは、hachi8833です。ハロウィーン色に染まったGitHubの草を見そびれてしまいました(´・ω・`)。


つっつきボイス:「お、こんなイベントやってたんだ」「他の人の日報で気づいて、見に行ったらもう緑に戻ってました😢」「毎年やってるみたいですよ?😆」「かぼちゃ色🎃」



つっつきボイス:「ハロウィンデバッグ、最初何だろうと思ったらネタでした😆」「diff芸というかマージリクエスト芸🧶」「修正後は常にtreatしそう😆」

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

「それでは公開つっつき第5回、やっていきで始めたいと思いますー😃」

Rails: 先週の改修(Rails公式ニュースより)

今回もコミットリストから見繕いました。ドキュメント更新がますます増えています。

Update authorization.rb by esquith · Pull Request #34355 · rails/railsのような1文字のタイポ修正もありました。こういうのだったら自分にも投げられるかも?

i18nロケール設定はaround_actionを使うようドキュメントを修正

#34356はドキュメントの更新ですが、#34043のissueがきっかけになっていました。

参考: rails/callbacks.rb at fc5dd0b85189811062c85520fd70de8389b55aeb · rails/rails*_actionコールバックのソース


つっつきボイス:「あら、あらら?今日の昼にプルリクメッセージにあったthread safeという言葉↓が取り消されてる😳」「早技😆」「コメントで『これはスレッドセーフにするためじゃないし』と教えてもらって訂正したのか」

#34356より

「まあswitch_localeするんだったらaround_actionで囲む方がスマートだろうし」「#34043は?」「そのissueが元でこのプルリクが投げられたようです」「なるほど、Railsガイドのとおりに書いたら期待と違ってたみたいな話がスレッドセーフ云々とに発展してたと🤓」

「お、ロケール情報を書き換えてるし↓」「へー!😳」「I18nのこういう罠って一度は踏むんですよ🤣」「🤣」

# guides/source/i18n.md#L
```ruby
-before_action :set_locale
+around_action :switch_locale

-def set_locale
-  I18n.locale = extract_locale_from_tld || I18n.default_locale
+def switch_locale(&action)
+  locale = extract_locale_from_tld || I18n.default_locale
+  I18n.with_locale(locale, &action)
end

「ぱっと見スレッドセーフでないように見えるんだけど、以前どこかのタイミングでスレッドセーフになるようにI18nが修正されたような覚えがあるし、随分前のRailsガイドでもI18n.localみたいなところを直接上書きしてロケールを変更できるという記述があったような覚えや、I18n入ってきたのはRails 3あたりだったような覚えもありますね(この辺記憶ベースですが)」「へー!😳」

「お、with_localeって何だろう?: RailsのI18nを追ってみるか」「んー見当たらない…🤔?」「I18nってそういえばサードパーティgemだった気がする」「それだ!Rails本体には入ってないんだった😅」

with_localあった↓: 指定の間ロケールを変える: まさにaround系アクションのためにあるようなメソッド😋」「やっぱり直接上書きしてる🤔」

# i18n/lib/i18n.rb#L278
    # Executes block with given I18n.locale set.
    def with_locale(tmp_locale = nil)
      if tmp_locale
        current_locale = self.locale
        self.locale    = tmp_locale
      end
      yield
    ensure
      self.locale = current_locale if tmp_locale
    end

「お、config↓がスレッド対応してる: だから直接上書きしても大丈夫ということか」

# i18n/lib/i18n.rb#L39
  module Base
    # Gets I18n configuration object.
    def config
      Thread.current[:i18n_config] ||= I18n::Config.new
    end

    # Sets I18n configuration object.
    def config=(value)
      Thread.current[:i18n_config] = value
    end

    # Write methods which delegates to the configuration object
    %w(locale backend default_locale available_locales default_separator
      exception_handler load_path enforce_available_locales).each do |method|
      module_eval <<-DELEGATORS, __FILE__, __LINE__ + 1
        def #{method}
          config.#{method}
        end
        def #{method}=(value)
          config.#{method} = (value)
        end
      DELEGATORS
    end

「少々横道にそれましたので次へ〜」

ActiveJob::Arguments.deserializeHashWithIndifferentAccessサポートを復活


つっつきボイス:「お、HWIAなんてのが出てきたし☺️」「ウォッチ読者にはお馴染み?のHashWithIndifferentAccessですね: 略語で見たのは2回目ぐらいかな」「何でしょうかこれは?😆」

参考: ActiveSupport::HashWithIndifferentAccess

「あ、HashWithIndifferentAccessはハッシュのキーにシンボルを渡しても文字列を渡しても同じようにアクセスできるようにするモジュールです: Railsのparamsってまさにこういう挙動ですよね」「あー言われてみれば機能として使ってるけど名前知らなかった😅」「長いですからねー名前😆: 長い名前といえばHABTM(has and belongs to many)という今や滅びた書式があります↓」「はぶとぅむ」「見たことなかった〜😅」「こういうのってチームで開発してないとなかなか知る機会がないですよね: 自分も『名前の長いヤツ』って覚えてるし🤣」

参考: has_and_belongs_to_many (ActiveRecord::Associations::ClassMethods) - APIdock

「でコードはというと、#to_hしたことで必ずハッシュになるようになった↓」「Railsで開発しているとHashWithIndifferentAccessは普通に使いますね😋」

# activejob/lib/active_job/arguments.rb#L149
      def transform_symbol_keys(hash, symbol_keys)
-       hash.transform_keys do |key|
+       # NOTE: HashWithIndifferentAccess#transform_keys always
+       # returns stringified keys with indifferent access
+       # so we call #to_h here to ensure keys are symbolized.
+       hash.to_h.transform_keys do |key|
          if symbol_keys.include?(key)
            key.to_sym
          else
             key
           end
         end
       end

ActionController::APIはcookieやセッションをサポートする」が正しい

# actionpack/lib/action_controller/api.rb#L13
  # An API Controller is different from a normal controller in the sense that
  # by default it doesn't include a number of features that are usually required
- # by browser access only: layouts and templates rendering, cookies, sessions,
+ # by browser access only: layouts and templates rendering,

つっつきボイス:「サポートしないかと思ったらサポートする、でした😅」「確かにActionController::APIはcookieとかセッションをサポートするのが普通だろうし、ドキュメントは間違ってたけど誰も使えないとは思わなかったでしょうね☺️」「修正よりプルリクメッセージの方が長い😆」「よく気づいたなーって思うし」「APIモードだからcookieやセッションが使えないなんて、そんな発想なかったし😆」「APIでもログインするし😆」

fixtureのHABTM関連付けで起きていたキー制約の違反を修正

よく見たら2015年に投げられたプルリクでした。

# activerecord/lib/active_record/fixture_set/table_rows.rb#L41
       def initialize(table_name, model_class:, fixtures:, config:)
         @table_name  = table_name
         @model_class = model_class

        # track any join tables we need to insert later
        @tables = Hash.new { |h, table| h[table] = [] }
+       # ensure this table is loaded before any HABTM associations
+       @tables[table_name] = nil
+       build_table_rows_from(fixtures, config)
      end

つっつきボイス:「お、言った端からHABTM出てきた🍄」「ハッシュの内容の順序が保証されるようになったのってRuby 1.9からでしたっけ?」「たしかそうだったと思います」「Ruby 1.9はいろいろbreaking changesがありましたからね👷」

参考: Hash#keysの順番は保証されるのか? - Qiita
参考: class Hash (Ruby 2.5.0)

「Ruby 1.8も影響を受けるだろうってあるけどとっくにサポート外だし」「fixtureの書き方によってはこういうエラーが起きることがあるんだろうか?」「この修正で直る理由がよくわからない😭」「謎🤔」

WARNING: Rails was not able to disable referential integrity.

This is most likely caused due to missing permissions.
Rails needs superuser privileges to disable referential integrity.

    cause: PG::InsufficientPrivilege: ERROR:  permission denied: "RI_ConstraintTrigger_c_3340781" is a system trigger

ActiveRecordのconnected_toでハッシュやURLをサポート

# activerecord/lib/active_record/connection_handling.rb#L108
     def connected_to(database: nil, role: nil, &blk)
      if database && role
        raise ArgumentError, "connected_to can only accept a database or role argument, but not both arguments."
      elsif database
-       config_hash = resolve_config_for_connection(database)
-       handler = lookup_connection_handler(database.to_sym)
-        with_handler(database.to_sym) do
-         handler.establish_connection(config_hash)
-         return yield
+       database = { database => database } if database.is_a?(Symbol)
+       database.each do |role, database_key|
+         config_hash = resolve_config_for_connection(database_key)
+         handler = lookup_connection_handler(role.to_sym)
+          with_handler(role.to_sym) do
+           handler.establish_connection(config_hash)
+           return yield
+         end
        end
      elsif role
        with_handler(role.to_sym, &blk)
       else
         raise ArgumentError, "must provide a `database` or a `role`."
       end
     end

つっつきボイス:「connected_toは最近のActiveRecordに入った複数接続先をサポートするヤツでしたっけ」「そうだったと思います(参照: Railsウォッチ20181015: ActiveRecordにconnects_toconnected_toを実装)」

「お、何とpostgres://fooみたいな形式でも指定できるようになってる↓: このナンチャッテURLみたいな書き方、データベースの世界では割とメジャーです」「へぇぇ!😳」「コロンでパスワードを渡したりもできるし」「PHPのフレームワークでもこの書き方使うものがあったし(なつかし)、あとは、んーとJDBCだったかな」

User.connected_to(database: { writing: "postgres://foo" }) do
  User.create!(name: "Gannon")
end

config = { "adapter" => "sqlite3", "database" => "db/readonly.sqlite3" }
User.connected_to(database: { reading: config }) do
  User.count
end

「↓これこれ」「おー😳」

参考: Connection URL Formats and Examples

# 上記事より抜粋
jdbc:mysql://localhost:3306/HerongDB?user=Herong&password=Secret

jdbc:oracle:thin:Herong/TopSecret@localhost:1521:XE

jdbc:sqlserver://localhost;user=sa;password=Herong

「たぶんですけど、これってRFCみたいな仕様に則ったものじゃなくてその世界で編み出された書式なんじゃないかな?」「そういえば私もJavaでEclipseで書いてたときにこういうURLっぽい書式よく使ってましたし、あとsshなんかでもユーザー名やホスト名なんかをURLっぽく書けたりするんで、そういうのって統一されてるんだろうって思い込んでましたね😅」「URI(URL)そのものは仕様がきっちりありますが、URLのプロトコルというかスキームで使っていいものについては仕様では言及されていないので、上みたいなデータベース接続のスキームが正式に認定されているかどうかですね🤔」

参考: Uniform Resource Identifier (URI): 一般的構文

後で調べると、URL schemeの一覧には「すべてのスキームを網羅したリストはない」とありました。Stackoverflowを見ると、以下のIANAのリストがそれだということですが、このリストにはpostgresoraclemysqlといったスキームはありませんでした。

「ちなみにconfig = { "adapter" => "sqlite3", "database" => "db/readonly.sqlite3" }みたいなハッシュで渡せる形式もハッシュを1つ渡せば済むので便利ですね😋」

ActionControllerのいくつかのpublicメソッドをprivate化

「タイトルに気持ちのこもったamatsudaさんのコミットです」「new_controller_threadlog_errorがprivateになったと: 誰かが悪さしたんだろか😆」「log_errorは確かにpublicだと無理やり叩こうとする人が出かねないという気持ちは伝わってきますね」「response_bodyは逆にpublicになった?」「いや、response_bodyは移動しただけでpublicのまま変わってない」「あそうか💦」

番外: ActiveStorageのhas_one_attachedhas_many_attachedが NoMethodError


つっつきボイス:「たまたま上のツイートが目に止まったんですが、モジュールの読み込み順とかそのあたりの問題らしくworkaroundしか示されてないので時間があればという感じで」「オートローダーとかに絡んでたらつらそうなヤツ😅」「苦戦してそう…😥」

Rails

特集「肥大化したActiveRecordモデルをリファクタリングする7つの方法」今ならどうなる?続編

肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)

先週の続きです。

前回の個人の感想のおさらい:

  • そもそもGoF以外の設計パターンの名前がまちまち
  • 「肥大化した…」記事は意味が広がったりしたパターンもあるが有用性が増しているパターンもある
  • Form ObjectとQuery Objectは今も有用性高そう
  • View ObjectとPolicy ObjectとService Objectは意味と名前がばらつきがち
  • Policy ObjectはPunditやCanCanCanに任せる方がよいかも
  • Decorator(Presenter)は最近あまり使われてないかも?
  • Railsのapp/の下にディレクトリを増やそうとすると「レイヤが違う」気がして仕方がない
  • モデルばドメインモデルと考えたいのに、Railsのmodels/はActiveRecordを継承するクラスの置き場に使われている
  • Railsがシンプルなアプリから複雑なアプリまでシームレスに拡張できれば理想
  • Trailbrazerはいいけど最初から大規模になるとわかっていないと導入しづらそう
  • 少なくとも案件単位では設計用語を揃えるとよさそう

つっつきボイス:「お、先週の続き」「要点を簡単にまとめてみました」「ちなみに『肥大化…』の記事は読んだことあります?」「どうだったかなー😅」「要するにActiveRecordモデルがfatになったときの切り分け方パターンです: 当時かなりPVあったはず」「今もPVかなりありますね😋」

「この辺ってみなさんのところではどうされてます?Form Objectとかぐらいは使うとか?」「Value Objectは使ったかも🤔」「Value Objectは受け取られ方が相当ばらついてますね😆」

「『肥大化…』の記事のValue Objectは割と軽いcomparableなオブジェクトを作る感じですが、Structになれるものをクラスで展開することをValue Objectとみなす人もいたりするし」「以前VirtusっていうgemがValue Objectに使われるっていう話を聞いた気がしましたけど」「たぶんそのときはVirtusをForm Objectとして使う話だったんじゃないかな」「そうだったかも😅」

参考: class Struct (Ruby 2.5.0)
参考: solnic/virtus

「社内勉強会で自分が作ったスライドにMartin FowlerによるValue Objectの定義があったはず(探す)…あった🎯↓」

参考: マーティン・ファウラー - Wikipedia
参考: ValueObject

「上はあくまでMartin先生による定義ですが、Value Objectは等価性の比較で値だけをチェックするもので、(これもMartin先生の言う)参照オブジェクト(Reference Object)と違ってobject idを見ない」

「Value Object、仕事では使わないけど、以前個人の小さなプロジェクトで使って見事にどハマりしたことがあります😩」「おぉ?」「ピュアなオブジェクト同士を比較している分にはいいんですけど、Rubyでハッシュとかeql?とかを書き換えることがあるじゃないですか: 自分しか使わないからいいだろうと思ってValue Objectにしてみたら、純粋なRubyの部分はたとえ正しく動いたとしても、たとえばActiveRecordのクエリの中でuniqとか使うとそういう部分まで書き換えられて軒並みぶっ壊れて参ったことはあります😇」「南無🙏」「少なくともValue ObjectはピュアなRubyオブジェクト以外ではやらないと強く思いました」「いわゆるPORO(Pure Old Ruby Object)ですね: Arelとかに落とすとおかしくなる」

「ちょうど上のスライドにもありますけど、どうしてもArelに落としたければ組み込みバリューやシリアライズLOBに保存するという手はありますね: でもシリアライズしたら同値比較はできても大なり小なりの比較はできないからあまり意味はないかもですが☺️」「Arelとか他のライブラリがちょっとでも絡んでくると独自の比較をやり始めるんで、自分以外は絶対に誰もちょっかいを出さない自分だけのクラスじゃないと使えないかもって思いました😤」

「ActiveRecordはデータベースとのマッパーをやっているので、ActiveRecordが絡むとどうしても厄介になりますね: マッパー意識してまで書こうとするとつらくなるばかり😨」「ActiveModelまでだったらまだピュアなオブジェクトなので何とかなるかもしれないけど」「Hashie::Mashみたいに同質性をいじるgem使うと壊れそうだし、ましてや仕事だと怖いので愚直に値を比較しまくるみたいな方向に逃げがちですね😅」

「まさにそういうときにapp/の下に置くディレクトリをたとえば『ここにあるオブジェクトはActiveRecordには使うなよ!』『ここのはActiveRecordと結合していいぞ』みたいにわかりやすく示せたらそういう事故が減るよね、という話を先週してました😆」「まああの後自分もまた考えてみたんですけど、どちらかというと自分が本当にやりたかったのはActiveRecordのモデルをDAOに移すことだったのかなって思ったり」「データアクセスオブジェクト!」

参考: Data Access Object - Wikipedia

「つまりmodels/にはアプリケーションオブジェクトを置いてdao/の下にActiveRecordを置いたらすっきり分けられるんじゃないかなーって思ったわけですよ🤓」「あえて分けるとしたらそうかなー?🤔」「どうですか?」「…自分はやらないと思う🤣」「まあね🤣」

「ともあれ、現状だと同じmodels/の下にActiveRecordとアプリケーションオブジェクトがひしめき合いがちになるんですけど皆さんはつらくないですか?」「ルール守らないヤツがいるんでひしめき合いまくってます😇」「🤣」「🤣」「そういうのは静かにマージリクエストをcloseする🤣」

「さっきのパターンで言うと、View Objectとか自分も使わないですし、そういうのが使われたときに自分がやらかさないという自信はあんまりないかも😅」「名前空間掘るとかもですね☺️」「ちょっと意識高くconcerns使うと今度はディレクトリをまたいでconcernsしたくなったりとか: 自分はあまりconcernsとかモジュールのincludeとかしないんですが😆」

参考: Rails/Model(Active Record)のConcern | 酒と涙とRubyとRailsと

「concernsで下にさらにディレクトリを掘るとeager loadingのときに特定のタイミングでモジュールが読み込まれてるというエラーが出たり出なかったりするんであまりconcernsを掘り掘りしたくないですね😅: だったらもう純粋にmodels/viesw/controllers/だけにするのがいいのかなとも思いますし🤔」「すると今度はmodels/の下がごっちゃになるのをどうするかですよね」「…もうごっちゃでいいと思います🤣」「マジで🤣」「🤣」

models/の下に200個ぐらいあるとつらくありません?」「つらいです😭」「10個20個なら我慢できるけど100個200個になるとmodels/の下を見る気が失せる🤮」

「自分は基本的に30個ぐらいしか作らないし、例のattributes APIができて楽になったかなというのはありますね」「y-yagiさんの記事↓にあるヤツですね」「そうなってたらmodels/の下が混じっててもいい?」「いいと思います」「2、30個までならいけそうですね🤔」「自分たちのチームは受託が多いんでそれこそ限界まで膨れ上がったアプリがやってきたりしますが😩」

参考: Rails 5のActive Record attributes APIについて | 日々雑記

「今もしRailsアプリを最初から作れるんだったら、DiscourseとかMastodonとかRedmineあたりの大規模CMS系アプリを参考にするかもしれないですね: この人たちがこうやってるならこうするか、みたいな」「Redmineは設計の古い部分もぼちぼちあるんで、自分はDiscourseとかMastdonあたりがおすすめかなと」「世界のすごい人に習う☺️」「それは正しいかも☺️」

「Eコマース系のSpree↓もRails系でしたっけ?」「そのはずですね」「お、Spreeのリポジトリ見ると既に標準のRailsアプリの構成と違ってる🤣」「🤣」「backend/とかfrontend/とかある」「エンジンで分けたんでしょうね」「ルートディレクトリにapp/がないから、サブディレクトリにapp/がある感じ: おーこういう設計かー」「これはこれでフロントエンドとバックエンドで同じモデル使いたいときどうするんだろう?とか思ったり😆」

spreecommerce.orgより

「お、Spreeのサブディレクトリは薄くできてる」「core/もある」「最近フロントエンドを分離することが増えてきましたね☺️」

「ところで先週も少し話しましたけど、どなたかTrailblazer↓って使ったことあります?」「知らなかったー😅」「このgemシリーズは、エンタープライズな方向に拡張しても大丈夫そうなディレクトリ構造になっていますね」「たしかoperation/の下でアクションがファイルに分かれてたりとか」「小さいアプリを書くにはトゥーマッチな雰囲気なんですが、大規模アプリにはいいんじゃないかという気がしています」「Trailblazer使ったことある人がいたら話聞きたいなと思ってるんですけど、まだ使ってる人に出会えたことがなくて💦: RubyKaigiで見かけた気もするんですが」


trailblazer.toより

# trailblazer/trailblazerより
app
├── concepts
│   ├── song
│   │   ├── operation
│   │   │   ├── create.rb
│   │   │   ├── update.rb
│   │   ├── contract
│   │   │   ├── create.rb
│   │   │   ├── update.rb
│   │   ├── cell
│   │   │   ├── show.rb
│   │   │   ├── index.rb
│   │   ├── view
│   │   │   ├── show.haml
│   │   │   ├── index.rb
│   │   │   ├── song.css.sass

「Trailblazerとかできちっと設計すればいいエンタープライズアプリになりそうなんですが、アプリってだんだん育っていくものだから最初から導入はためらわれるし、Railsでこれが欲しくなった頃にはもう移植するには手遅れになったり😅」「ははは😅」「Javaでエンタープライズアプリをやってきた人にはTrailblazerがしっくりくるのかなとも思ったり」

「お、このコピペここ数日あたりやたら見かけますよね😆:『いや本当さ』で始まるヤツ」「やっぱりあったかー」

「まあ設計が壊れるかどうかはやっぱりモラル次第かな〜😆」「😆」「PHPの某フレームワークの上にオレオレの設計が積まれているシステムを手がけたことあるんですけど、かなりきちんとメンテされてて感心したことありますね」「ああアレですね☺️」「今思えばメンテナーの治安維持が効いていたんだと思うし😆」「愛のある治安維持がポイント😆」「そういう嫌われるのを覚悟で愛をもって治安維持する人がいることが大事なのかも」「名奉行ですね」「だめなプルリクをちゃんとrejectする人も必要😆」

「設計って確固たる正解というものがないのが常ですが、それでも『これは絶対おかしい』みたいなパターンは踏まずに生きていきたいですよね☺️」「この辺の話はエンドレスになりそうなので、この後の懇親会で飲みながらでも」「☺️」

Hyperstack: Ruby DSLだけで書けるクライアントサイドWebアプリ(Ruby Weeklyより)


同サイトより

Opal、Webpack、Reactを動員してます。

とりあえずRails向けHyperstackテンプレートにあるrails new MyApp -m https://rawgit.com/hyperstack-org/hyperstack/edge/install/rails-webpacker.rbを実行して動きました。


つっつきボイス:「はいぱーすたっく?」「どうやらJavaScriptを一行も書きたくない勢のようです」「RubyでDSLを書くとJSが生成されて、HTMLが出力される..と?」「生成されたJSがめっちゃ長い」「何かのギャグだったり?😆」「とりあえず動きました」

class HelloWorld < Hyperloop::Component
  render(DIV) do
    # try changing 'world' to your own name
    H1 { 'Hello world' }
    P(class: 'green-text') { "Let's gets started!" }
  end
end
/* Generated by Opal 0.11.3 */
(function(Opal) {
  var self = Opal.top, $nesting = [], nil = Opal.nil, $breaker = Opal.breaker, $slice = Opal.slice, $klass = Opal.klass, $send = Opal.send, $hash2 = Opal.hash2;

  Opal.add_stubs(['$render', '$H1', '$P']);
  return (function($base, $super, $parent_nesting) {
    function $HelloWorld(){};
    var self = $HelloWorld = $klass($base, $super, 'HelloWorld', $HelloWorld);

    var def = self.$$proto, $nesting = [self].concat($parent_nesting), TMP_HelloWorld_1;

    return $send(self, 'render', [Opal.const_get_relative($nesting, 'DIV')], (TMP_HelloWorld_1 = function(){var self = TMP_HelloWorld_1.$$s || this, TMP_2, TMP_3;


      $send(self, 'H1', [], (TMP_2 = function(){var self = TMP_2.$$s || this;

      return "Hello world"}, TMP_2.$$s = self, TMP_2.$$arity = 0, TMP_2));
      return $send(self, 'P', [$hash2(["class"], {"class": "green-text"})], (TMP_3 = function(){var self = TMP_3.$$s || this;

      return "Let's gets started!"}, TMP_3.$$s = self, TMP_3.$$arity = 0, TMP_3));}, TMP_HelloWorld_1.$$s = self, TMP_HelloWorld_1.$$arity = 0, TMP_HelloWorld_1))
  })($nesting[0], Opal.const_get_qualified(Opal.const_get_relative($nesting, 'Hyperloop'), 'Component'), $nesting)
})(Opal);
<div><h1>Hello world</h1><p class="green-text">Let's gets started!</p></div>

「Opalって使ったことあります?」「いいえ〜」「OpalはRubyのコードをJavaScriptにトランスパイルするものなんですが、両者の型とかが違うので等価なコードにはならないという」「へぇ〜😳」


opalrb.comより

「最終的なHTMLのためにJSを経由する理由って何なんでしょう?🤔」「はて…JSでdocument.write()したいからとか?」「Rubyでここまでネストして書くぐらいなら最初からHTMLで書いた方がいいような気も😆」「Opalを使う理由…もしかするとReactコンポーネントを生成したいということなのかも?」「あーそれあるかも」「だからJSにしたいのか」「この生成JSをフロントエンジニアに見せたら何と言われるか😆」「『後生だから全部Reactで書かせてください』って言われたりとか😆」

参考: Reactコンポーネントへの理解を深める (1/2):CodeZine(コードジン)

「Hyperstackの作者をここまで駆り立てるものって…」「JS絶対書きたくないマンなんでしょう😆」

Hanami 1.3.0がリリース(Ruby Weeklyより)


つっつきボイス:「お、Hanami登場🌸: Hanami使ったことある人います?」「うーん😅」「後発のRuby製Webフレームワークで、最近のRubyKaigiにもよく登場してますね」「Railsよりはクリーンに書けるというのが売りだそうです」「何をもってクリーンとするかですけどね😆」

「もしかするとですが、案外Rails 6あたりでHanamiと合体したりして😆: Railsは過去にもそういうことがあったので」「そうなったらうれしいかも😋」「そういえば何と合流したんだっけ…?🤔」

後で調べると、Rails 3でMerb↓と合流してました。

参考: Ruby on Rails - Wikipedia
参考: Merb - Wikipedia

Rails 5.2とDalliのキャッシュストア(Ruby Weeklyより)


つっつきボイス:「お、ダリ」「以前のウォッチでも取り上げたキャッシュストアですね」「使ったことあります?」「うーん😅」「memcache的に使う感じでしたっけ」

リポジトリにはmemcache-client gem(現在は非推奨)の置き換えとあります。


同リポジトリより

「そういえばmemcached最近全然使ってないなー: 以前は使ってましたけど」「Redisが出るまでは使ってたかも」「Redisはどんどん強くなってますよね💪」「そういえば未だにKyoto Tycoonで動いているシステムありますよ😆」「懐かし!」「クラスタ化もしてないのに今も動いてるという」


redis.ioより

Railsのマイグレーション9つの秘訣(Ruby Weeklyより)


つっつきボイス:「9つの秘訣」「1はとりあえず基礎を押さえとく感じ: 既にお馴染みのものっすね」

マイグレーション中のカラムデータをどう更新するか

「2.はActiveRecordのクラスを臨時に作るか生SQLを書くかという話🤓: こういう↓書き方にするかどうかはともかく、マイグレーションの外でActiveRecordを継承するオブジェクトを作って操作すると後で詰むことがあるんですよね」「全然知らなかったけどそうなんですね😅」「きっと皆さんも一度は踏んだんじゃないかなっと😎」

# 同記事より
class DoThisAndThat < ActiveRecord::Migration[123]
  MyObject = Class.new(ActiveRecord::Base) # Barebones model bound to table `my_objects`

  def up
    MyObject.where(foo: :bar)
  end

  # ...
end

「どういうことかというと、後になってマイグレーションを走らせるときにそのActiveRecordを継承するクラスがなくなってるかもしれないということなんですよ」「へぇえ!🤯」「ほら、テーブル名を変更したりテーブルを再統合したりすると当然models/の下のActiveRecord継承クラスは消しちゃうじゃないですか」「なのでActiveRecord継承オブジェクトを作るなら上のコードみたいにマイグレーションの(updownとかの)中でやるか生SQLを書かないといけない🧐」

「ところでどういう場合にこういうコードを書きたくなるんでしょうか?」「たとえばですが、マイグレーションで新しいカラムを作りつつ既存のデータから計算した値を入れたいときとか」「はーなるほど」「たとえば顧客ランクみたいなカラムを追加するときって過去の取引データを集計して指定の額を超えたらランクをAにしたいなんてことがあるわけですよ」

「ちなみに私が使ってるのは最近のRailsなんでupdownじゃなくてchangeでやってて、値を入れるときは別途rakeタスクを書いたりしてますね」「でもchangeでは書けない場合があるじゃないですか: そういうときはupdownで書かないといけない」「ああ確かに: changeはちょっと話がずれちゃいましたが、カラムのデフォルト値でどうにかできないかなとも思ったり」「CREATE TABLE直後ならデフォルト値でもいいんですけど、マイグレーション実行後にデータの一貫性を保証したい場合は計算ベースでデータを入れないといけなくなりますよね」「もちろんrakeタスクを作っておいて、マイグレーション後には必ずこれを実行するようにという運用にするのもありです: でも本来はマイグレーションの一部としてやりたいタスク」「そうできたらいいですよね😂」

「ともあれこの2.は知っておいた方がいいですね: よくあるのがdb:migrateは通るのにdb:migrate:resetが通らないというパターン」「あーありそう…😅」

ロールバック

「3.はロールバック前にテストせいと」「そもそもロールバックってしないな〜😆」「あんまりやりたくない作業の代表かも😆」「理想はいつでもロールバックできるようにすることなんでしょうけど😅」

カラムをdropする前にdeprecate

「4.はカラムをいったんdeprecateして、本当に安全だとわかってからdropせいと」「Railsに限らないエンタープライズアプリあるあるな感じ」

トランザクショナルなDLLコマンドのサポート

「5.のDDLって?」「Data Definition Languageでしたっけ」「CREATE TABLEとかのあたり」「そういうときのDDLがトランザクショナルかどうかをチェックせいと」

参考: データ定義言語 - Wikipedia

「CREATEとかROLLBACKとかをトランザクショナルに書かないといけないことってあるんでしょうか😅」「たとえば今のテーブルとまったく同じテーブルコピーを作っておいてトランザクショナルにリネームして差し替えることはありますね」「(Perconaの)pt-online-schema-changeの中でやってるような作業ですか」「こういう作業ってDBMSに依存するので、トランザクショナルかどうかは知っておけということですね」

参考: pt-online-schema-change

途中のテーブルの様子をコメントするかエラーをraiseする

# 同記事より
class MyCoolMigration < ActiveRecord::Migration[5.1]
  def change
    # change_table :foobars do |t|
    #   t.references :baz, polymorphic: true, index: true
    #   t.integer :cool_number, null: true
    #   t.boolean :awesome, null: false, default: false
    # end

    # change_column_default :foobars, :this_thing, '123'

    reversible do |dir|
      dir.up do
        update "update foobars set blablabla complex SQL" # Troubleshooting this bit..
      end

      # ...
    end
  end
end

「ところで6.のこのreversible↑って??見たことないんだけど」「何だっけ…?」「updownを別々に書かなくていいヤツかな?と思ったら、changeの中に個別にupdownを書けるってことか!😳」「やーこれはマジ知らなかった💦」「これ知ってるとはスゴイですね😍」「言われてみればこう書ける方が( ・∀・)イイ!!: changeでできることもあるので」「お、記事の7.でもreversibleが説明されてる」

参考: 3.9 reversibleを使用する — Active Record マイグレーション | Rails ガイド

schema.rbやstructure.sqlが肝心

「8.のschema.rbね…..ワイルドすぎるRailsプロジェクトなんかでカラム順序がschema.rbとズレてることってありますよね😇」「😇」「『誰がやった!』みたいな😆」「productionとdevelopmentとかでschema.rbのカラム順序がズレてたりするのマジ勘弁😤」「生SQLでSELECT *とかやったときに発覚したり」「とても悲しい気持ちになれる😭」

「schema.rbの型が違ってたことならあります😇」「それもヤダ😆」「そうそう、詳しい方いたら聞きたいんですけど、Rails 4あたりまでは確かschema.rbでidのintegerbigintじゃなかったんですよね?」「あぁぁぁそれあった!😫」「あれもツライ😇」

参考: Rails5.1からidカラムがbigintになるのでその対応 - koukiblog
参考: Rails 5.1: Default Primary Keys Are Now BIGINT

「カラム順序の話に戻りますけど、MySQLだとafterとか使ってカラムの挿入場所を指定できるのにPostgreSQLだとできないんですよね🥶」「それはできないっ…ぽすぐれではっ🥺」「どうしてもやりたかったら、さっき話したように別テーブルを作るときに欲しい順番でカラムを作ってからリネームして差し替えるぐらいしかないかと😓」「ぽすぐれユーザーは過去に軽く100回ぐらい検索したことあると思う🤣」「🤣」「🤣」

参考: MySQLでカラムの順番を変更する - Qiita
参考: PostgreSQLでカラムを指定の位置に追加・変更する2つの方法 | Minory

マイグレーションのタイムスタンプ

「cognisant…?」「辞書には『精通する』とありますね」

「そうそう、マイグレーションファイルの名前に刻まれる時間って、生成した人のローカル時間が使われるんですよ」「むむ?」「だからコミットでマイグレーションの間に他人のマイグレーションが差し込まれることって平気で起きますよね🤣」「なぬー🤣」「🤣」

db:migrateは今存在するマイグレーションファイルを上から順に実行することは当然保証されるんですけど、コミットで間にマイグレーションが差し込まれてしまうとdb:migrateのたびに巻き戻って実行されてしまう可能性は常に残ってる😎」「ふぇえ」「なかなかマージされなかったコミットなんかでそうなりそうでしょ?😅」「そういう可能性があることを認識せいということなんでしょうね」

「CIがちゃんと書かれて回っていればCIでも同じ状態になっているはず」「CIの書き方にもよるかな」「CIでのdb:migrateを毎回頭から実行するんじゃなくて、必ず前回からのdiffで実行するようにしないとずれそう…はっ、そうやってカラム順がズレるのかっっっ🎃」「犯人いた〜👮‍♂️」「マイグレーションの地雷を踏めば踏むほどマイグレーションの仕様に詳しくなれる😆」

マイグレーションよもやま話

「質問: 開発当初でたとえばテーブルが3つしかないときってマイグレーションファイルの中身を書き換えたりしてて😆、その時点では何の影響もないからいいんですけど、その後カラムが増えてくるとそれもコワイからちゃんとマイグレーション生成してカラム追加してるうちにマイグレーションファイルが際限なく増えていくじゃないですか: 皆さんその辺ってどうやってます?意地でもCREATE TABLEを書き換えるか、マイグレーションでやり続けるか」「自分は、いったんマージされたマイグレーションファイルの書き換えはダメだと思っている派」「あーやっぱり」「featureブランチで作業している間とかならやってもいいけど、マージされたマイグレーションファイルはいじらない方がいいと思ってます😎」

「それはproductionリリース直前でも?」「直前でも、です🧐: stagingとかもあるんだし、チームメンバーの手元にもそれぞれデータベースがあるし」「そうでしょうね〜」「だってgit pullしてdb:migrateしたときにマイグレーションエラー出たらテンション下がるじゃないですか🥶」「😆」「あとマイグレーションエラーを解決するために、手元の一時的なデータを消さないと巻き戻せなかったりするのもテンション下がる😥」

「そういうのをやりたかったらRidgepole↓を使うべきですね」「えっそれ知らなかった😳」「Ridgepoleは確かクックパッドさんも使ってて、出来上がりのスキーマファイルしか扱わないようにするgemです」「マイグレーションを使わなくなるヤツですね」「Ridgepoleは、現在のデータベーススキーマと、Ridgepoleが把握している最終スキーマとの差分をチェックしてその差分を反映するので、どんな状態からでも最新のスキーマが得られる😋」「おぉお〜よさそう😃」「今質問したようなことをやりたかったらたぶんRidgepole使う方がいいですね🤔」

参考: クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ

「でなかったら、過去のマイグレーションをスカッシュするgemも確かありますよ↓」「へぇ〜」「使ったことある!」「個人的にはどうかなぁ〜と思いますが😆」

「マイグレーションファイルって増えれば増えるほどマイグレーションに時間かかりますし」「自分も個人プロジェクトで大規模なデータベースのマイグレーションが増えすぎて30分もかかるようになったことがあって、そういうときは仕方なく手動でALTER TABLEとかやって切り抜けました😅」「Railsでそのサイズになると最悪マイグレーションのせいで本編のサービスが止まりますね😇」「デプロイで止まるのヤダからそうやって切り抜けました😭」「マイグレーションファイルの中身を生SQLでALTERするなんてのもやったり: みんなこういうところでは悩んでます」「やはり〜」


「今日はデータベースの話がいっぱいできて嬉しいです: データベース好きだから😍」「😆」

minitest-mock_expectations 1.0.0をリリース(Ruby Weeklyより)

記事の中で、今年の夏にMochaをRails内部のテストから削除したという話が気になりました。


つっつきボイス:「あれ、このMochaってJavaScriptの?コネクションプールの話とか出てて変だな」「え😳」「どうやら上で外したと言ってるMochaはfreerange/mochaの方で、これはRubyのモック/スタブのライブラリですね」「ありゃー失礼しました💦」「どっちもテストに使うものだからややこしいですね☺️」

以下がJavaScriptのテストフレームワークの方のMochaでした🙇。


mochajs.orgより

「ところで皆さんはRSpec派?minitest派?」「RSpecが多いかー」「minitestは玄人感ある😆」「ちなみに自分はRSpec使ってますが実質ほぼassertしか使ってないという😆」「😆」「いわゆるイコールマッチングで押し通す感じ😆」「たまにminitestでもいいかな?って思ったり☺️」

その他Rails


Ruby

Gemoji: Rubyで絵文字を扱うライブラリ

Railsで使えるようです。

# 同リポジトリより
>> Emoji.find_by_alias("cat").raw
=> "🐱"  # Don't see a cat? That's U+1F431.

>> Emoji.find_by_unicode("\u{1f431}").name
=> "cat"

つっつきボイス:「Slackの絵文字補完機能みたいなものを作るときによさそうかなと思って」「げもじって濁音が多い響きが何というか😆」「★3000超えてて、しかも何年も前からやってるって初めて知りました☺️」「確かにカスタマイズ絵文字ってたまに欲しくなるときあるし: これは★押しとくか😋」

RubyのReadline(Ruby Weeklyより)


つっつきボイス:「なるほど、GNU ReadlineをRubyで実装したものは前からありますね☺️」

参考: GNU Readline - Wikipedia

そういえば私がGobyREPL機能を実装したときはchzyerのGo言語向けreadline↓のお世話になりました。

エラーになりにくいRubyコードを書くには(Ruby Weeklyより)


つっつきボイス:「Thoughtbotさんの記事です」「お、Thoughtbotの記事久しぶりに見る」

「Timecopをまとめて呼ぶ↓と期待どおりにならないことがあるという話とかかな」「後は三項演算子より普通にif文の方が読みやすいという話とか: 短い三項演算子なら別にいいと思いますけど」

# 同記事より
RSpec.describe "holiday promotions" do
+ after { Timecop.return }

  context "on Independence day" do
    before { Timecop.freeze Date.parse("2017-07-04") }
-   after { Timecop.return }

    it "displays the fireworks banner" do
      # ...
    end
  end

  context "on Thanksgiving" do
    before { Timecop.freeze Date.parse("2017-11-23") }
-   after { Timecop.return }

    it "displays the turkey banner" do
      # ...
    end
  end

  context "on Black Friday" do
    before { Timecop.freeze Date.parse("2017-11-24") }
-   after { Timecop.return }

    it "displays the TV banner" do
      # ...
    end
  end
end

参考: 演算子式 (Ruby 2.5.0) — 条件演算子

Falcon: HTTP/2、HTTPS対応のRuby製高性能Webサーバー(Ruby Weeklyより)


同リポジトリより


つっつきボイス:「h2o↓はmrubyだけどこのFalconはRuby?」「のようです」「rackで動くようだ」


h2o.examp1e.netより

Priority Business Supportというのもやっているそうです。このsockertyはasync-何とかというgemをいろいろ出していて、Falconはその上で構築されているそうです。


socketry/asyncより

そしてそのasync gemはnio4rとtimersというこれまたsocketryのgemの上に構築されているそうです。徹底的にモジュール化するあたり、dry-rbを連想しました。


socketry/nio4rより

Ruby: Dry-rb gemシリーズのラインナップと概要

Salus: セキュリティチェッカーをまとめて動かす(Ruby Weeklyより)


同リポジトリより


つっつきボイス:「BundlerAuditBrakemannpm searchPatternSearchをサポートしてるようです」「あーDockerになっててまとめて動かせるってことか」「今後ちゃんと更新されるかな😆」「いわゆるホワイトボックス系テストをひととおり回してくれると」「ホワイトボックスだからソースコードの中身をチェックするタイプ」

参考: みんな知ってるホワイトボックステスト、ブラックボックステスト。でもグレーボックステストとは…? | ハートランド・ザ・ワールド

Ruby正規表現のパフォーマンスを測定してみた(RubyFlowより)


つっつきボイス:「つい自分の好みで選びました😅めちゃ長い記事なので後で追ってみます」「正規表現といえば☺️」

RubyWorld Conference 2018開催: 10周年!


018.rubyworld-conf.orgより

この日の公開つっつき会はRuby World Conference 2018の初日でした。10周年おめでとうございます🎉🎂🎁!そして今年のRuby Prize受賞者はk0kubunさんでした。おめでとうございます🎉🍶🍺!

その他Ruby


つっつきボイス:「コードハイライトエンジン!そういえば皆さんはコードハイライトに何使ってます?自分はIDEAとかRubyMineですが」「Vimで色付けるときはSolarizedとか」「カラースキームですね: これはこれで好みが色々ありそう」「シンタックスハイライトには?」「VimのRubyモードとか」

「何となくですが、カラースキームって瞳の青い系の好みの色で作られている感じがして、そのせいなのか何なのか暗いんですよね」「あーそれある!」「瞳の黒いアジア系には暗すぎる感」「Vimのデフォルトの青もとっても暗い」「目を凝らさないとわからなかったり」

「それで思い出したんですけど、英語圏というか米国だとピンクは基本色らしいんですよ: 日本人の感覚だとピンクって追加の色って感じなんですけど」「へぇ〜」

「おっと時間がないのでここからは駆け足で🦵🏻」


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

Kinesis Data FirehoseとSplunk

Splunkはサードパーティでした。

参考: Amazon Kinesis (フルマネージド型リアルタイム大規模ストリーミング処理) | AWS
参考: Amazon Kinesis Data Firehose とは - Amazon Kinesis Data Firehose
参考: Amazon CloudWatch(AWS リソースのモニタリング)| AWS
参考: AWS ソリューション | Splunk


つっつきボイス:「よく知らない名前が出てきたので: firehouseかと思ったら馬のfirehoseでした」「Kinesis周りはまだ使う機会なかったな〜」

AWS RDS for MySQLがMySQL 8.0をサポート


つっつきボイス:「お、RDSなら対応するでしょうね: もしAWS AuroraのMySQLが8.0になれば結構なニュースかも🤓」「Auroraはまだ5.65.7ですね」

参考: Amazon Aurora(MySQL、PostgreSQL 互換のリレーショナルデータベース)|AWS

※訂正(2018/11/06)

お知らせありがとうございました!🙇

その他クラウド


つっつきボイス:「そういえばGCPのPythonってまだ2?」「あ、どっちだったけ?」「まだ3じゃなかった気がする」

と思ったら今年7月にPython 3をサポートしたそうです↓。私がGCPやってた頃はPythonの2と3の共存で割と苦しみました🥺。

参考: GoogleAppEngineスタンダード環境のPython3サポートはもう少し話題になっていいと思う - Qiita



つっつきボイス:「よくあるDockerのレイヤー図は違うんじゃないかっていう記事です」「Dockerの図にコンテナエンジンの層を置いていいのかどうかってことか: うーん、Dockerのcgroupsがサンドボックス化されているのをレイヤと呼んでいいんだったらこの層があっても別にいいんじゃないかって気はするけどなー🤔」「OSのプロセスという視点なら確かにこっちの図になる: そりゃそうだ」「でもPIDの変換とかもやってるからそういう意味では概念上レイヤがあると考えてもいいんじゃないかな☺️」「難しい😅」「自分は上の図で別にいいし」

参考: Docker内部で利用されているLinuxカーネルの機能 (namespace/cgroups) - Qiita

SQL

PostgreSQLでユーザーデータをanonymizeする(Postgres Weeklyより)


同記事より


つっつきボイス:「む、むむ、むむ?すげー、PostgreSQLってこんなことできるんだ!😍」「お、どの辺でしょう?」「ざっとしか見てないけど、Extensionを作ってそれを既存のカラムに適用してからMASKED WITH FUNCTIONで使えるっぽい!さすがぽすぐれ、何でもできる💪」「??🤔」

記事が短いので全部は引用しません🙇。

-- step 1: マスキングエンジンを有効にする
=# CREATE EXTENSION IF NOT EXISTS anon CASCADE;
=# SELECT anon.mask_init();

-- ...

-- step 3: マスキングルールを宣言
=# COMMENT ON COLUMN people.name IS 'MASKED WITH FUNCTION anon.random_last_name()';

=# COMMENT ON COLUMN people.phone IS 'MASKED WITH FUNCTION anon.partial(phone,2,$$******$$,2)';

「つまりデータベース内のデータは一切変更しなくても、SELECT文でこのMASKED WITH FUNCTIONを通すことでそのルールに従ってマスクできるということらしい」「おぉ~😳」

「もしかすると、これを使ってproductionのデータベースをマスクすれば、たとえばproductionのデータを安全に開発側からアクセスするなんてこともできるかも: しかもfunctionだからパフォーマンスもそんなに落ちないはず」「やっとだんだんわかってきた気が😅」「ぽすぐれは常に新しい発見があるなっ🧐」

「ついでに皆さんはPostgreSQLとMySQLどっちを使ってます」「どっちもかなー」「どっちも使う」「やっぱそうですよね☺️」「Oracleは?😆」「元おらくらーの人が少なくとも約2名」「おらくらーでもないヨ😆」「業務だとOracleは不可避」「RailsだとOracleは1、2個ぐらいしか見たことないな〜」

この後PostgreSQLがらみで親睦会以後もずっと盛り上がり続けたのですが割愛いたします🙇。

PostgreSQL最大の過ち(Postgres Weeklyより)


つっつきボイス:「って何のことかと思ったら名前のことでした: post-GRES-que-ellって書いてあるから『ぐれ』のところを強く発音するってことみたいです」「へぇ〜😆」「雑学でした😆」

JavaScript

JavaScript製AI・MLアプリ7つ


つっつきボイス:「JavaScriptはあまり関係ないかも?」「確かに〜」

IronDB: ブラウザ向けのキーバリューストア(JavaScript Weeklyより)


同リポジトリより


つっつきボイス:「relentless?」「容赦ないとか無慈悲な、みたいです」「cookieとIndexedDBとLocalStorageとSessionStorageを冗長化に使ってキーバリューを保存すると言ってます」「IndexedDBともうひとつよく似たやつでえっと」「Web SQL Database: たしかSQLiteをベースにしてる」「それですっ: でそのWeb SQL Databaseを知ったと思ったらもうIndexedDBに移ってたことを今頃知りました💦」

参考: IndexedDB - Web API インターフェイス | MDN
参考: HTML5 - Web SQLデータベース

「昼にタバコ吸いながら雑談してたときに、『ブラウザに欲しいのはSQLデータベースというより容量を気にしなくていいキーバリューストアじゃないかな』って話になったんですが、ちょうどこのIronDBを見つけたので」「LocalStorageは割と容量大きかった気はする」

↓こんなページを見つけました。

参考: LocalStorageの容量や動作を調べるページ

「まあこういう容量はいくら増やしても足りないって言われがちですよね😆: MS-DOSの640KBの壁じゃないけど、そこにリソースがある限りみんな使い切ろうとするし」「😆」「😆」

参考: 640Kバイトの壁 ‐ 通信用語の基礎知識

関係ありませんが、IronDBの画像でつい少女鉄仮面を思い出してしまいました。

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

gRPC-Webとは


grpc.ioより


つっつきボイス:「お、gRPC-Web💖」「よくわかんないんですけど、JSのAPIがブラウザにも生えてる感じなんでしょうか?」「gRPCはまさにRPCで、gRPC自体はHTTP/2でも動くし、あとgRPC独自のプロトコルでも動いたはずで、gRPC-Webは、それを直接叩けるAPIがブラウザにできたと理解してる」「おぉ〜」

参考: 遠隔手続き呼出し - Wikipedia — RPC

「gRPCのメリットは、RPCなんでデータのスキーマが作れること: そういえばJSON Schemaとかあるけど流行ってるかというと🤣」「🤣」「🤣」「そんなものもありましたねー☺️」「JSONはスキーマの夢を見たけども…というか☺️」

「ちゃんと追わないとわかりませんが、gRPCはRPCなんで相当バルクかつ細かいやりとりにも耐えられる作りになってるんじゃないかと推測」「ふーむ」

「話逸れますけど、このPublickeyさんは的確な情報が多くていいなと思います😃」「POSTDさんも頑張ってる感」「お、今気づいたけどPublickeyって個人で運営してるんだ!😳」「マジで!?」「だとしたらPublickeyってスゴすぎる」

言語よろずの間

Python < Go < Rust


つっつきボイス:「もろ無双系の記事ですが、タイトルの不等号が小なり<なんだなと思って: 2ちゃんだと>が多い気がして」「Rustは低レイヤやってる人には人気高いですよね☺️」

Ruiさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」


つっつきボイス:「作り中みたいですが、はてブで1000超えてました」「すげぇ~」「この方はどうやって食べてるのか何となく不思議で」「たとえば研究職なんかだとサバティカルみたいな長期休暇を取ったり、博士号取るためにある程度休暇を取ってその費用も会社持ちなんてことが割とありますけどね🧐」「そういえばこの間も中間試験受けたとか言ってた気がする😃」

参考: サバティカル - Wikipedia

「それで言うと自分が今もっと知りたいのはLLVMかな」

参考: The LLVM Compiler Infrastructure Project

その他

シストリックアレイアーキテクチャとは


つっつきボイス:「これはたまたまsystolic(=心臓の収縮期、最大血圧値など)っていう単語を見かけて検索して見つけました: アーキテクチャというよりアルゴリズムかなと思いつつ」「何となくだけどニューラルネットワークが双方向になってるような」「そんな雰囲気で、えらく自由に組み合わせられるようです」「このPDF、1992年か」「え😳そんなに古かった?!」「スキャン画像が既に古いですしね😆」「確かに網掛けの部分が真っ黒だったりするし」「昔はこういう図を手書きしてたみたいですし」

警戒しよう


つっつきボイス:「普通の商売だったら注文増えてチャンス!って思うところなのに誰も思わないという😆」「自分たちも受託開発なんで今だと軽減税率の行方が気になるところ😆」「あと平成の次の年号も」「年号を表示しないといけないシステムがだいぶ減ってるからそれほどでもないと思うんですが、サマータイムや軽減税率はテーブル設計にかかわるので、ね」「そうでした💦」(以下延々)

番外

細胞サイズのナノロボットの量産

AIとかよりこっちの方がいろんな意味でクリティカルな気が。


つっつきボイス:「へー、量産できるようになったんだ☺️」「これが暴走したときにディアクティベートできるんだろうかと思って」「この手のは無理かも🤣」「硫酸かけるとか」

参考: 大きさは細胞並み「ナノロボット」量産する新技法が発表される…MIT研究チーム | ROBOTEER


今回は以上です。つっつき会にご参加いただいた皆さま、社内の皆さま、遅くまでお疲れさまでした!🙇

バックナンバー(2018年度後半)

週刊Railsウォッチ20181029: 特集『肥大化したActiveRecordリファクタリング7つの方法』今ならどうなる?Redis 5のストリーム機能他

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

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

Rails公式ニュース

Ruby Weekly

RubyFlow

160928_1638_XvIP4h

Hacklines

Hacklines

Postgres Weekly

postgres_weekly_banner

JavaScript Weekly

javascriptweekly_logo_captured

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ