rubykaigi.org kaigionrails.org RubyKaigi TakeoutとKaigi on Rails。個々の発表に言及するのは数が多すぎて難しいけれども教科書的な理解と実践上の理解の溝を埋めるものからすぐ業務に使えるもの、将来来る非互換変更の予告とその理由について、など参考になるor興味深い内容ばかりだった。
一部反芻しきれていない発表もあるので近いうちに見返したい。

Zen3アーキテクチャなRyzenの新世代

pc.watch.impress.co.jp pc.watch.impress.co.jp pc.watch.impress.co.jp 今PC組み立てるんだったらRyzenかなぁと思いつつも、去年の1月ごろにi9-9900Kで組んで数年はこれで持たせると決めているのでその機会はしばらくなさそう

マルチギガビットイーサ

internet.watch.impress.co.jp 2.5Gbitイーサ、現状メインのデスクトップPCにだけNICが付いているのだけれどハブがここまで安くなってきたのならばそろそろ考えるのもありかなぁ、という気がしてくる。
最大10Gbpsなフレッツ光クロスも始まったことだし…とはいえ10Gbps以上のRJ-45がWAN側だけでなくLAN側にもに1つ以上欲しいが、そのようなルータの選択肢がまだ少なすぎる。

現状NECのAtermの古いやつなのだけれど、Atermにはそのような製品はまだない。WAN側1ポートのみでLAN側は1Gbpsというのが最上位。

Amazon | バッファロー WiFi ルーター無線LAN 最新規格 Wi-Fi6 11ax / 11ac AX5700 4803+860Mbps 日本メーカー【iPhone11 / iPhoneSE(第二世代)メーカー動作確認済み】WXR-5700AX7S/N | バッファロー | 無線・有線LANルーター通販

条件に該当するのは今のところバッファローのみ。そして最上位製品なのでちょっと高い。

デュアル10G LANを搭載するゲーミングWi-Fi 6ルーター、ASUS「RT-AX89X」 - エルミタージュ秋葉原

ASUSのものは国内発売未定らしい。

インターネットポート、有線LANポートどちらも最大10Gbsに対応したWi-Fi 6 Wi-Fiルーター | IODATA アイ・オー・データ機器

と思ったらIO-DATAも今月下旬に出すらしい。これ次第だろうか。

と、ここまで書いておいてなんだが実用上は困ってないんだよなぁ。
でも欲しい。

Modular Monolith

medium.com

blog.kymmt.com

www.infoq.com

engineering.shopify.com

www.jrebel.com

最近ずっとモジュラモノリスについて考えている。
興味はあるので手を出してみたいのだが、今一歩手を出すに至らないこの感じ。
この構造の嬉しさがこの構造を採らなければならなくなるほど大きくならないと実感できないからなのかなあ。

Ruby on Railsの正体と向き合い方

speakerdeck.com

これを読んだの自体はかなり以前だけれども重要な内容なので。

2020-10-10

劇場版ヴァイオレット・エヴァーガーデンを観た

雑記

以下は、劇場版ヴァイオレット・エヴァーガーデンを観た当日である、2020/10/4に書いた文章です。

勢いで書き上げたものの、ネタバレが含まれるため、いつ公開するか迷って、公開日の1か月後まで待てばさすがにネタバレで怒る人もいないだろう、しかし都心ならば見れる劇場も残っているはず、という望みをかけて2020/10/18に予約投稿…しようと思っていたんですが。

公式が冒頭10分を特別公開とかいう~~えげつない~~素晴らしいことをしたので急遽今日、10/10に公開してしまうことにしました。

「劇場版 #ヴァイオレット・エヴァーガーデン」本編冒頭シーン10分をノーカットで特別公開！

ライデンの郵便社に所属していたけれど、18才のときにそこを辞めて以降、彼女の記事を見る事はない。
その“自動手記人形”の名は――https://t.co/BAgpWVvhBc #VioletEvergarden pic.twitter.com/GMahx0ba0K
— 「ヴァイオレット・エヴァーガーデン」公式 (@Violet_Letter) 2020年10月9日

劇場版ヴァイオレット・エヴァーガーデンを観ました。

情感と余韻を与えてくれる、素晴らしい作品でした。

これ以降は完全に作品内容にも触れた、いわゆるネタバレありの乱文なので特に読まずともよいです。

むしろ、まだこの作品を観ていない場合は読まないでください。

この文章を読んでいるということは、少なからず興味があるということでしょうから、もしそうであるならば、この文章の続きを読むよりも先に、ぜひ観てほしい。

できれば、NetflixでTVシリーズと外伝も観たうえで。

2020-10-02

Rails6においてはapp/models/concernsなどのconcernsディレクトリ配下に置かれたファイルの名前空間がConcerns配下にならない

Webサービス開発 Rails Ruby

はい。タイトルの通りです。

仕事中、Rails6を使っているプロダクトでモデルの共通処理をConcernへ切り出そうとしたところ、何度やってもオートロードに失敗してしまっているかのように見える事象に遭遇しました。

# app/models/concerns/models/hogerable.rb
module Concerns::Models::Hogerable
  extend ActiveSupport::Concern
  中略
end

# app/models/concerns/models/hogerable.rb
class Article < ApplicationRecord
  include Concerns::Models::Hogerable #=> オートロード失敗
end

Rails5ではこれで正しくロードできていたはず。
しかしRails6である今編集しているプロダクトでは現に動いておらず、またRails6でオートロードの探索ルールが変わっているのは知っていたのでその辺りに手掛かりがあるはず。

結論としてはRails6.0へのアップグレードガイドに答えが書いてありました。

Concerns::名前空間は、classicモードのオートローダーでは実装の副作用によって動作していましたが、これは意図した動作ではありませんでした。
Concerns::を使っているアプリケーションがzeitwerkモードで動くようにするには、こうしたクラスやモジュールをリネームする必要があります。
Rails アップグレードガイド - Railsガイド

concenrsディレクトリ以下に置いたconcernをConcerns名前空間配下として呼び出せるのは実装都合の副作用だったのか…

今まで /app/models などの、appディレクトリと更に一階層取り除いた後のファイルパスから名前空間上の位置を組み立てられる、という解釈をしていましたが、
Rails.config.autoload_paths から得られるオートロードで探索するパスを取り除いた後のパスから名前空間上の位置を組み立てられる、というのが正しかったようです。

Rails5と6両方触る人は混乱するかと思いますので注意しましょう。

2020-09-15

Rails6のマルチDBで、普段は参照しないスロークエリ用リードレプリカからデータを読み出す

Webサービス開発 Rails Ruby

マルチDB設定をしたRails6で、普段参照するリードレプリカとも異なる、分析クエリ用リードレプリカからデータを読み出すにはどうすればよいかという話。

Rails6.0のマルチDB設定はリリース後に微妙にインターフェイスが変更されていて今となっては推奨されない情報に行きあたってしまうことがあるので(というか僕自身が行きあたったので)、半分メモとして書き残しておきます。

要するに

ActiveRecord::Baseを継承した抽象クラスのconnects_toで、writingロールでもreadingロールでもない第三のロールを作る
第三のロールは普段は使用されない
重いSELECTをするときだけActiveRecord::Base.connected_toのロール指定で第三のロールを使う

詳しく

Rails6.0リリース当初のRailsガイドには、「ActiveRecord::Base.connected_toにdatabaseキーワード引数を渡すと、そのdo～endブロックの中はdatabaseキーワード引数で指定したデータベースを用いる」と書いてありました。 github.com

しかし、これは既に非推奨ならびに削除の未来が決まっていて、英語版のRailsガイドからは既に当該の記述は削除されています。 api.rubyonrails.org github.com

Railsガイドの日本語訳ではまだ残っていたので、該当部分を削除するPRは出しました。

ではActiveRecord::Base.connected_toのdatabaseキーワード引数を使わずに実現するにはどうすればいいかといえば、話は単純でApplicationRecordでconnects_toにデータベース設定を渡すときにwritingでもreadingでもない第三のロールを同時に設定すればよさそう。

database.ymlが

production:
  primary:
    host: プライマリインスタンスのFQDN
    user: root
    adapter: mysql
  replica:
    host: リードレプリカインスタンスのFQDN
    user: root_readonly
    adapter: mysql
    replica: true
  analyze:
    host: 分析用インスタンスのFQDN
    user: root_readonly
    adapter: mysql
    replica: true

となっているとき、

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to database: { writing: :primary, reading: :replica, analyzing: :analyze }
end

class Post< ApplicationRecord 
  中略
end

というようにconnects_to で三つのロールを指定します。

Rails6 のマルチDB機能は特に指定しなければwritingロールを書き込み、readingロールを読み込みに使用するので、analyzingロールは普段使用されません。

そして普段参照するリードレプリカへ発行すると重すぎてサービス自体に影響が出てしまうようなときにだけ、

posts = ActiveRecord::Base.connected_to(role: :analyzing) do
  Post.all
end

などとすればこの時だけ分析用インスタンスへSELECTが発行されるようになります。

2020-08-14

条件に日時を使うような境界値テストのrequest specにrspec-parameterizedとRailsのfreeze_timeまたはTimecopを組み合わせると落ちる

Webサービス開発 Rails Ruby

はい。

皆様ご存知、rspec-parameterizedというgemがあります。
複数入力の組み合わせで出力が決まるような、素のまま書くとcontext地獄になってしまうテストを短く書けて便利なやつです。

github.com

なんですが、仕事のプロダクトのrequest specにおいて、事前状況セットアップに使う値とその結果のレスポンス内容として期待する値がセットになっているような境界値テストをrspec-parameterizedを使って書いたところ、通ったり通らなかったりする。

数人がかりで2時間弱ほど格闘したところ、下記のことがわかりました。

通ったり通らなかったりしたのはDBのDATETIME型が秒単位だったせい
- なのでrspec-parameterizedのせいではない
rspec-parameterizedはwhereの中身をその場で評価してテストケースの組み合わせを生成していそう
- 遅延評価ではない？

最小の再現サンプルがこちら。 github.com

上記の再現サンプルではコード量を最小にするためにTimecopを使っていますが、この現象を発見した時はRailsのActiveSupport::Testing::TimeHelpersのfreeze_timeとtravel_backを使っていました。
また、before :eachを:suiteにしても変わりませんでした。

ruby-jpのslackにて質問したところ、コミッタのsue445さんより

一応これで回避はできるのですが、自分で書いといてなんだけどすごい気持ち悪いですね…
https://github.com/sue445/rspec-parameterized-with-timecop-issue-minimum-reproduce-sample/commit/6b31bc782b29d007a63928f8ae3bd9e02f253c1d

どうやらrspec-parameterizedにパラメータとして渡したDateTime型を返すものはRailsのfreeze_time(またはTimecop)によってDateTimeがモックされる前に評価されてしまうらしいということがわかりました。

これ厳密にはちょっと違ってて、rspec-parameterizedの where ブロックがrspecの before の処理よりも前に評価されるのが原因です。（ where の中で let の値が参照できないのも同じ理屈）

という返答をいただきました。

別の方から下記記事を教えていただきましたが今回のケースはrequest specなのでこれも使用できず。

techlife.cookpad.com

他の方から下記のようにrspecの外側でnowを変数に束縛し、whereブロック中でパラメータとして書く日時はnowからの加減算で表し、テスト時にTimecop.freeze(now)、Railsではtravel_to(now)するという形を提案していただき、これを使うことにしました。

+now = Time.now
+
 RSpec.context 'parameterized spec' do
   before :each do
-    Timecop.freeze
+    Timecop.freeze(now)
   end
 
   after :each do
     Timecop.return
   end
 
-  subject { Time.now }
+  subject { now }
 
   where(:time) do
     [
-      [Time.now],
+      [now],
     ]
   end

https://github.com/takayamaki/rspec-parameterized-with-timecop-issue-minimum-reproduce-sample/compare/fixed

書き方まで完璧とは言えませんが、テストの不確実性は排除できたので一旦よしとします…

反応いただいた皆様ありがとうございました 🙇‍♂️

2020-07-19

ミリシタ3周年イベントで秋月律子4位になった話

アイドルマスター

ミリシタ3周年イベントCHALLENGE FOR GLOW-RY D＠YS!!!、おつかれさまでした。

今回は総合477位、律子4位という結果でした。

本当はここまでの勢いで大爆走するつもりはなかったのですが、走り出したら止まれなくなってしまい。
時勢も相まっての大爆走だったので次回も同レベルで走ることはないでしょうが、貴重な経験だったので記録に残しておきます。

まず、僕の仕事は2月中旬、具体的にはシンデレラ7th大阪の後から完全自宅勤務をしています。
それと弊社は来歴上こういったオタク的諸々に理解がある会社であり、「去年同様アイマスの二週間戦争が始まるので二週間仕事の出力落ちます」と言ったら、苦笑しながらも許してもらえました。
そのため仕事の隙間時間でも走ることが可能でした。(走る隙間時間で仕事していたのではないか、とか言ってはいけない)

要約

長いので箇条書きにします。

イベントアイテムの貯蓄は適当に最短時間で頑張る
イベントアイテムの消費は手首や指の消耗を抑えるために2mix
- 2mixなら音聴きながら中指と薬指で同時タップするだけでスコアSでクリアできるようになる
貯め続けから何時ごろ消費に切り替えれば1日のアイテム収支が釣り合うかの予実管理表を作った
- 後に1日あたりの目標貯蓄数まで考慮できるように改修した
前半終了のタイミングで一旦アイテム全消費するつもりでミスった
最後の1日はアイテム消費だけで走り切るつもりだった
- おすすめ楽曲の巡り合わせにより丸1日貯める日が発生した結果、ほぼ3日走り続けた
これ以上の順位を目指すには端末課金が要りそう

ポイント推移

時刻	累計	日速
2020/6/29 0:00	0
2020/6/30 1:00	384746	384746
2020/7/1 3:00	785962	401216
2020/7/2 1:00	1080546	294584
2020/7/3 1:00	1421672	341126
2020/7/4 1:00	1810024	388352
2020/7/5 1:00	2120756	310732
2020/7/6 1:00	2530706	409950
2020/7/7 1:00	2772172	241466
2020/7/8 1:00	3144187	372015
2020/7/9 0:00	3379933	235746
2020/7/10 0:00	3930778	550845
2020/7/11 0:00	4580545	649767
2020/7/12 0:00	5244259	663714

消費した諸々のリソース量

正直面倒だったので正確な値は記録していません。PLvは309から373になりました。

スタドリは何個だったか覚えてませんが初日のうちに使い切り、ジュエル的にはたぶん14万個くらい、そのうち6万個くらいを貯蓄や未読アイドルコミュからの無償ジュエルで、有償ジュエル84000個をGoogle Playで買い、Google Playポイントなどによる軽減があったので実際に使用した金額は9万3960円でした。

といっても、ミリオンクルーズ、SideMプロミ、シャニスプリングパーティ、シャニ2nd、ミリオン7thなどあらゆるイベントが中止になった関係でそれらの返金がチケット代だけで10万円を超えており、今回の費用は実質無料と言って差し支えないでしょう。

各日について

2020/6/29(月) 1日目

初日。友人たちとdiscordに集まり、ワイワイしながら0時の開戦を迎えました。

この時点ではまだ大爆走する気はなかったのでとりあえず自宅勤務のなか一通りやってみてどれくらいの速度が出るか、というのを試していました。
2時から11時までリフレッシュ、そして翌1時までの16時間、2回支給されたバーストを両方使ったこともあって日速38万4746pt。

あと、この日一番短いおすすめ楽曲は星屑のシンフォニアだったらしいですが、Shooting Starsをやっていましたね…？

2020/6/30(火) 2日目

翌日が事情によりほぼ2ヶ月ぶりの物理出社だったので、リフレッシュタイムを少し後ろにずらして3時まで。
以降、17時くらいからほぼ毎日discordで通話が発生していました。

使用したおすすめ楽曲はGood-Sleep, Baby、10時から27時までの17時間走ったので、日速40万1216pt。

2020/7/1(水) 3日目

この日は物理出社の日でした。
本当に久々に外に出たので、最寄り駅のホームに来た段階で既に少し息が上がってしまっており、体力の危機を感じました。

使用したおすすめ楽曲は虹色letters、時間は12時から1時までの13時間、物理出社の影響もあって日速29万4584pt。

2020/7/2(木) 4日目

日中は特に特筆すべきことはなし。

使用したおすすめ楽曲はHOME, SWEET FRIENDSHIP、時間は11時から1時までの14時間、日速34万1126pt。

この日が終わった後に「なんかこのまま行けば1桁順位は取れそうだ」と思い、その時点までのジュエルの消費ペースより、終了までに使う金額を9万円と推計して覚悟を決めました。

ついでに、ほほえみDiaryを走った友人からバンテリンコーワの手首サポーターを勧められ、ヨドバシ.comで買いました。
東京23区内であれば翌日に届けてくれるヨドバシエクストリーム便は神。
ブルーライトカットな眼鏡は最終的に一切画面を見なくなったので不要でした。

2020/7/3(金) 5日目

バンテリンコーワの手首サポーターが届いたものの、1箱1枚という罠にはまりました。完全に見落としていた。
更に、注文していたふつうサイズでは僕には小さすぎた二重の罠。適切サイズはちゃんと確認しましょう。

どうするか迷いましたが7/5に大きめサイズを2枚注文しました。余ったふつうサイズ1枚は母に献上。

また、本格的に走るのを決めたので手首、指の消耗を抑えるためにアイテム消費は2mixに切り替えました。(クリア回数Sはとっくに終わってたし)
ミリシタは2mixでもイベントptに差がつかないのがありがたいですね。
経験値は違うのでそこは差が出ますが、手指の消耗と経験値とどちらが大事かと言えば僕は考えるまでもなく手指が大事なので経験値は投げ捨てました。

使用したおすすめ楽曲はインヴィンシブル・ジャスティス、時間は10時から1時までの15時間、日速38万8352pt。

リフレッシュタイムに入った後でジュエルを補充しようとしたとき、それまで特に使わず貯まり続ける一方だったGoogle Playポイントの存在を思い出し、投入した日でもありました。

2020/7/4(土) 6日目

この日はリフレッシュタイム終了から貯め続け、何時何分ごろに消費に切り替えれば貯蓄と消費が釣り合うかを計算するような予実管理表を作りました。

が、予実管理表の単位時間が当初30分だったのを15分に変更したタイミングでアイテムの時間当たり消費量を修正し忘れたことにより、ちょうど後半戦切り替わりのタイミングだというのに2倍で貯めたアイテムを余すというミス。 2時間くらい貯めすぎたので、ざっくり40分程度のロスでした。

使用したおすすめ楽曲はランニング・ハイッ、時間は10時から1時までの15時間、日速31万0732pt。

2020/7/5(日) 7日目

4位にいるのでせっかくならば3位に上がりたいと思って考えた結果、最後の1日はアイテムを使い続けるだけの日にしようという方針をこの日に決めました。
それに向け、予実管理表を1日に貯蓄したいアイテム数まで考慮できるように改修していました。

改修後の予実管理表。実績列にその時点での貯蓄数実績を入れると右列で誤差を修正してくれる

使用したおすすめ楽曲はラビットファー、時間は10時から1時までの15時間、日速40万9950pt。

2020/7/6(月) 8日目

予実管理表を日曜日に1日あたりの貯蓄アイテム数を考慮できるように改修したばかりですが、ここにきておすすめ楽曲最短が2分5秒のBigバルーン◎。これはこの日のうちに貯めておかないと損ではないかと思い、バースト使用以外は丸1日貯めに徹しました。

使用したおすすめ楽曲はBigバルーン◎、時間は10時から1時までの15時間、日速24万1466pt。

2020/7/7(火) 9日目

この日のおすすめ楽曲は2分10秒台のSuper Duperだったので、予定通りに必要数の均等割り分だけ貯め、それ以上は消費していました。

それと、会社の追加有給制度を使えばよいのではないかということに気付いた結果、7/8から7/10まで仕事が休みに。ちょうど仕事に余裕があるタイミングだったので助かりました。

使用したおすすめ楽曲はSuper Duper、時間は10時から1時までの15時間、日速37万2015pt。

2020/7/8(水) 10日目

もう2分0秒台の曲は来ないのではないかと思っていた中、まさかのPRETTY DREAMER、2分2秒。
予定を変更して完全に貯めに徹しました。これによりバーストが一つ貯蓄され、最終日はバースト2発の見通しに。

この日が終わった時点で残り3日間(45時間)のうち40時間程度は走り続けられるだけのアイテムが貯まりました。

使用したおすすめ楽曲はPRETTY DREAMER、時間は10時から0時までの14時間、日速23万5746pt。

2020/7/9(木) 11日目

さすがに2分0秒台の曲は来ないのではないかと思っていたにも関わらず、ジレるハートに火をつけて、2分2秒。
しかし前述した通り40時間程度は走り続けられるだけのアイテムが既に貯まっていました。

そのため午前中に少しだけ貯めて、残り時間から計算できる理論上の消費可能数から1時間30分程度の余裕を持たせた数にした後は消費に切り替えました。

この頃には音さえ聴ければ2mixを見ずにクリアできるようになっていました。
死なずにスコアSが取れれば良いので左手の中指と薬指で両方のレーンをリズムに合わせてタッチしていれば十分で、右手が空いた結果諸々のニュースサイトなどを読むなどしていました。

使用したおすすめ楽曲はジレるハートに火をつけて、時間は9時から0時までの15時間、日速55万0845pt。

2020/7/10(金) 12日目

おすすめ楽曲の中で一番短いのは瞳の中のシリウスでしたが、この時点で既に7/11の23時ごろまで走れるだけのアイテムを貯めていたので一度もやりませんでした。

9時から0時までの15時間ひたすら消費し続け、日速64万9767pt。

2020/7/11(土) 13日目

最終日。 10時から夕方まで当初の予定通りずっと消費し続け、そのまま行けば22時50分ごろに消費し終わる見通し。

最終日なこともあってdiscordに人が観戦も含めて二桁人集まる中、美希のSHOWROOMを見てそのあまりの実在性に衝撃を受けたり、 100位1つと1000位2つを狙っていた友人が100位調整芸し始めて5分ごとに各アイドルのボーダーと10分速情報が飛び交うCIC(戦闘指揮所)の様相を呈したり、僕自身は2mixでもう消費しきれば終わりなうえ、前述の通り左手と耳だけでクリアできる状態だったので右手を使って雀魂で四麻友人戦を打ち始めたり。

そのまま走り切れそうだったので、22時ごろに30分程度だけ貯め、それ以降また消費に切り替えた結果、23時56分に全て消費完了し、合計524万4229ptでゴール。

使用したおすすめ楽曲はEpisode. Tiara、時間は9時から0時までの15時間、7/8に貯めたものも合わせ2回ブーストしたので日速66万3714ptでした。

端末性能とiOS対Androidという越えられない壁

負け惜しみと言われても仕方ないのですが、今回4位に着地したのは端末性能の差によるものだと思われます。
今回のイベントで使用したのはドコモのLG-01K V30+でしたが、これはAndroidでSnapdragon 835の端末です。

Snapdragon 835は一応2年前のフラグシップなSoCだったわけですが、これと友人のiPad Pro(まだUSB-Cでない世代のもの)とでGlow map1周にかかる時間を比べたところ私のV30+の2分59秒に対して友人のiPad Proが2分56秒でした。

3秒差あるということは60回、つまり少なく見積もっても3時間で1周差が付きます。

今回の13日間で寝坊したのが合計で50分、それ以外に仕事しながらで理論値から離された時間が1日に45分程度であったことを考えると、それらを全てロスしなかったと仮定しても律子3位との32万pt差は埋まらなかっただろうと思われます。

これ以上を目指すには勤務中にリフレッシュタイムを割り当てて命を削るか、iOSに鞍替えしてiPad Proするか、よくてROG PhoneなどのいわゆるゲーミングAndroid スマホにするかしないとこれよりも上を目指すのは難しそうです。

走り切ってみて

今回からリフレッシュタイムが9時間になったことで、翌日スタートダッシュのためのチケット450枚貯めなどの準備をしても7時間ほどは睡眠時間を確保できたのでかなり人間的生活を保てたと思います。

また、17～18時ごろからdiscordにいると友人たちがわらわらと集まってきてそのまま話しながら走れたので、持つべきは一緒に走る仲間だなと思いました。もっとも、僕以外は各々の担当アイドルの2桁や、3桁という冷静な目標だったので走り慣れた今回は途中から余裕が生まれはじめ、途中で切り上げて別ゲーム(…というかapex)で遊びに行ってしまったりして寂しさを味わうこともありましたが。 ~~apexは3周年イベントが終わった後に始めました~~

来年についてですが、端末課金以外に更に石費用として10万は覚悟しなければならないであろうことを考えると、来年も1桁、はさすがに厳しいかなと思います。来年はアイマスのイベントがいくらか開催でき、それに今年は浮いてしまった分のお金を払えていることを願っています。

ともあれ、ミリシタ3周年おめでとうございます。

ランキング参加中

アイドルマスター

このIP網の片隅で

今週読んだ記事 2020/10/19～2020/10/25

Ruby / Rails

React

AWS

その他

今週までに読んだ記事とか～2020/10/17

RubyKaigi TakeoutとKaigi on Rails

Zen3アーキテクチャなRyzenの新世代

マルチギガビットイーサ

Modular Monolith

Ruby on Railsの正体と向き合い方

劇場版ヴァイオレット・エヴァーガーデンを観た

Rails6においてはapp/models/concernsなどのconcernsディレクトリ配下に置かれたファイルの名前空間がConcerns配下にならない

Rails6のマルチDBで、普段は参照しないスロークエリ用リードレプリカからデータを読み出す

要するに

詳しく

条件に日時を使うような境界値テストのrequest specにrspec-parameterizedとRailsのfreeze_timeまたはTimecopを組み合わせると落ちる

ミリシタ3周年イベントで秋月律子4位になった話

要約

ポイント推移

消費した諸々のリソース量

各日について

2020/6/29(月) 1日目

2020/6/30(火) 2日目

2020/7/1(水) 3日目

2020/7/2(木) 4日目

2020/7/3(金) 5日目

2020/7/4(土) 6日目

2020/7/5(日) 7日目

2020/7/6(月) 8日目

2020/7/7(火) 9日目

2020/7/8(水) 10日目

2020/7/9(木) 11日目

2020/7/10(金) 12日目

2020/7/11(土) 13日目

端末性能とiOS対Androidという越えられない壁

走り切ってみて