今書いているプロダクトはPHPで書かれた現行サーバソフトウェアのリプレイスであることもあり、当初はドメイン知識が不足していてどこまでがドメインモデルが持っているべきロジックで、どこからがユースケースに該当するロジックなのかが判断できなかった。
そこで、リクエストされたときの動作としては現行サーバの動作を再現するようにドメインモデルの外側でロジックを書いてしまい、それらの中で頻出する処理をドメインモデルのpublicメソッドへ移す、というリファクタをしている。
こういうときにrequest specはリクエストされたときの動作が変わっていないことを保証してくれるので便利だ。
EC2に対するLightsailのFargate版っぽい。
speakerdeck.com 新卒で入ったのがB2Bのサーバホスティングサービスの障害対応チームだったので障害に起因する辛みはそこそこ身に沁みていることもあり、SRE的な立ち回りは以前から多少興味がある。
今の会社は専任でSREを置くほどの規模ではないのでサービスのコードを主に書きつつ、サービスインフラの改修などはできる範囲で、となっているが。
その状態でもSLI/SLO/SLAの話とか、観測性(observably)の話とか、色々活かせる話はある。
Service層を設けること自体は良いが、Service Classの命名にServiceという単語を含めるのをやめよう、という話。
Serviceという単語を含めると、Userに関するServiceだからUserService、といったようにカテゴリ分けのような扱いになってしまい、Userに関するロジックが雑多に放り込まれるゴミ捨て場になってしまう。
そうならないようにするためには、命名で用途を狭めて、当初想定していた用途とは関係ないロジックが放り込まれようとしているときに違和感を持つような命名にしよう、という話。
これの本筋とは関係ないが、20枚目のスライドでsignIn関数とsignOut関数を持つAuthServiceの改名候補がAuthorizerになっていたのが気になってしまった。signIn, signOutなら認証なのでAuthenticatorでは？
techracho.bpsinc.jp 上記のスライドと合わせて。
命名について、動詞から始めると十分に用途を狭めつつ変な命名になることが少なそう、というのは確かにその通りだと思った。
これに書かれていて納得した一方で仕事のコードではこれに従えていない箇所がいくつか思い当たるので週が明けたらPR出せそう。
ipfs-book.decentralized-web.jp
デバイスの空きストレージを貸し出すとコインが貰えるブロックチェイン通貨、という話。 背景としてIPFSが出てきてなるほどと思ったと同時に、微妙な噛み合わなさも感じた。
IPFSを知ったのは、修士の頃に研究していた情報指向ネットワークの周辺技術として。
ある程度動いているのは凄いと思った反面、ストレージの確保はどうするんだろうかと思った記憶がある。
その答えがこのFilecoinということなのだろうが、記事中では 断片にアクセスするには、ファイルをアップロードした人物の持つ秘密鍵が必要になる と書かれつつ、IPFSではコンテンツのアドレスさえわかれば誰でも取得可能、というのはどういうことなのだろう。
コンテンツのアドレスさえわかれば誰でも取得可能なのがIPFSであるならば、ファイルをアップロードした人物の持つ秘密鍵は内容の取得には必要ないのでは？
という疑問を抱いたところで頭が疲れたので興味が続けばまた今度。
github.com
jbuilderが遅すぎるので最近使い始めたjb、v0.8.0がリリースされた。
MRI2.7.2や、Rails6.1でのAPI変更への追従が主。
既存利用者がアップデート時に必要な変更として、jsonシリアライザとしてojを使っている場合、Oj.optimize_railsが必要になった。
これまではojが読み込まれている場合、multi_jsonによって自動で使ってくれていたが、jbuilderがmulti_jsonをやめたのに追従してjbもmulti_jsonを依存から外したため。
最新版のjbuilderと同様、Active Supportのto_jsonを使うようになったので、Oj.optimize_railsすれば引き続きojを使うようにできる。
ma2k8.hateblo.jp
Shopify以外のモジュラモノリスの事例をやっと見つけられた。
ドメイン間の循環参照を防ぐためにShopifyではbundlerを使っていたが、この事例はscalaなのでsbtを使っている。
プライマリアダプタとセカンダリアダプタとの間の違いがまだ想像できていない。
Shared Libraryから各ContextのUse CaseまでのDB書き込み等の部分は依存関係逆転の法則を使ってインターフェイスに依存させておいたDBや外部APIリクエストの実装詳細を注入するのがセカンダリアダプタ、
外部に対してHTTP APIを提供したり、Producer-ConsumerモデルのConsumer側のふるまいを実装したりしてUse Caseを呼び出すのがプライマリアダプタ…
という理解でいいのだろうか。
github.com
ruby-jpのslackで見かけた、これもモジュラモノリス的な構造を採っているアプリケーション。
スペインのオープンソース行政システム(?)らしい。
中身ちゃんと見きれていないので後で改めて読みたい。
長時間かかるE2Eのようなテストと比較的短時間で終わるユニットテストのようなテストがあるときに、短いほうが通ったら一旦マージを許し、マージ後に長いほうが落ちたらそのPRのauthorに修正をリクエストして、修正されるまで本番デプロイを禁止する、という内容だと理解した。
図を見るとマージ時にデプロイもしてしまっていると読めるが、長いテストが落ちているということはどこかで壊れが発生しているはずで、それは変更頻度を優先するために一旦飲んでいるのだろうか…と思ったが文中に書いてあった。
The two long running test suites were added to the CI workflow to ensure a pull request did not break the GitHub experience for our Enterprise Server customers.
この二つの長いテストスイートはPRがGitHub Enterpriseの顧客の体験を壊さないことを保証するために追加されました。It was also clear that these 45-minute test suites did not provide additional value blocking GitHub.com deployments that happen continuously throughout the day.
同時に、この45分かかるテストは日に何度も行われるGitHub.comのデプロイを止めるほどの付加価値は発揮していないことも明白でした。
このこの45分かかるテストは日に何度も行われるGitHub.comのデプロイを止めるほどの付加価値は発揮していないというのがどのように判断されたのかが少々疑問ではある。
15分かかる短いほうのテストをpassしてマージしたあと、長いほうのテストがpassするのを待ってから自動でデプロイしてしまえばエンジニアがそれを覚えている必要はなくなるのだから十分なのではと思うけれども、それよりもデプロイまでの時間が短いことを選んだのは、カナリアリリースしようとしてエラー率上昇などで切り戻されたとき、エンジニアの頭を45分も前のPRについての状態に戻すのが大変だからなのだろうか。
www.nichepcgamer.com 既に存在そのものは明言されてたけどついに出荷開始されたと。
Acerがこれを載せたノートPCを出荷するとか。
Destiny2くらいは動くということなので、これが1.37kgくらいのノートPCに積めるのであればピーク性能はともかく電力性能比的には良いのかも。
デスクトップ向けCoreシリーズの11000番台の情報が出てきた。
GPU部分はXe Graphicsの演算ユニット削減版ということは、マイクラくらいならこれだけで動くんじゃなかろうか。
現状のi9 9900Kで全く困ってないので買いはしないのだけれどこういうの見てるとやっぱり欲しくはなってくる。
gigazine.net
モバイル回線を複数束ねて安定性を上げる製品は既に出てたけれど、オープンソースでもできるらしい。
実際に使う機会が来るかは別として。
k-tai.watch.impress.co.jp RANというコンポーネントがどこからどこまでをカバーしているのかわかっていないのだけれど、各基地局の各アンテナから送出する信号を演算する部分なのだとすれば、その辺の分野は行列演算の塊らしいのでGPUと相性が良いというのは想像できる。
僕自身の専攻は無線通信ではなかったので想像が正しいのかわからないけれども。
www.publickey1.jp
PC自作関連に含めるか迷ったけれどサーバ向けCPUの話なので。
数年前にIntelがALTERAを買収したのに続いてAMDがXilinxを買収するという話。
前前職でFPGAを載せたXeonの話は何回か聞いたが、触ることはなかった。
使われる分野が限られ過ぎていて使われているのかもよくわからない。
先日今週読んだ記事のパイロット版を書いたはいいが、全ての記事に短めでもコメントを付けるのは意外と大変ということに気付いたので、とりあえず羅列していってコメントは気が向いたらということにする。
ついでに日曜日の17時に強制的に予約投稿されるようにしてしまうことにした。
aws.amazon.com
最近ElasticacheやRDSにも広がり始めたAWSのGraviton2。
Appサーバはx86から急には変えられないだろうけど、マネージドサービスならば導入しやすいかもしれない。
でもRDSはまだプレビューだし、いわんやAuroraは。
www.highriskrevolution.com 元記事だと「簡単に解ける方のアルゴリズム」の表現が少しわかりづらかったが、要するに
ということらしい。
確かに見落としがちだが コロンブスの卵というか、シュレディンガーの猫ならぬシュレディンガーの牌というか。
なんとなーくネット上の記事を読んだりすることはそれなりにあるのだけれど、あとから「あの記事どこだっけ…」とか「何で読んだんだっけこの内容…」とか思うことがそこそこあるので、週単位くらいでまとめてみることにした。
そのパイロット版的な感じで10月中くらいに見たものを覚えてる範囲で。
rubykaigi.org
kaigionrails.org
RubyKaigi TakeoutとKaigi on Rails。
個々の発表に言及するのは数が多すぎて難しいけれども教科書的な理解と実践上の理解の溝を埋めるものからすぐ業務に使えるもの、将来来る非互換変更の予告とその理由について、など参考になるor興味深い内容ばかりだった。
一部反芻しきれていない発表もあるので近いうちに見返したい。
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というのが最上位。
条件に該当するのは今のところバッファローのみ。そして最上位製品なのでちょっと高い。
デュアル10G LANを搭載するゲーミングWi-Fi 6ルーター、ASUS「RT-AX89X」 - エルミタージュ秋葉原
ASUSのものは国内発売未定らしい。
インターネットポート、有線LANポートどちらも 最大10Gbsに対応したWi-Fi 6 Wi-Fiルーター | IODATA アイ・オー・データ機器
と思ったらIO-DATAも今月下旬に出すらしい。これ次第だろうか。
と、ここまで書いておいてなんだが実用上は困ってないんだよなぁ。
でも欲しい。
最近ずっとモジュラモノリスについて考えている。
興味はあるので手を出してみたいのだが、今一歩手を出すに至らないこの感じ。
この構造の嬉しさがこの構造を採らなければならなくなるほど大きくならないと実感できないからなのかなあ。
これを読んだの自体はかなり以前だけれども重要な内容なので。
以下は、劇場版 ヴァイオレット・エヴァーガーデンを観た当日である、2020/10/4に書いた文章です。
勢いで書き上げたものの、ネタバレが含まれるため、いつ公開するか迷って、公開日の1か月後まで待てばさすがにネタバレで怒る人もいないだろう、しかし都心ならば見れる劇場も残っているはず、という望みをかけて2020/10/18に予約投稿…しようと思っていたんですが。
公式が冒頭10分を特別公開とかいうえげつない素晴らしいことをしたので急遽今日、10/10に公開してしまうことにしました。
「劇場版 #ヴァイオレット・エヴァーガーデン」本編冒頭シーン10分をノーカットで特別公開！
— 「ヴァイオレット・エヴァーガーデン」公式 (@Violet_Letter) 2020年10月9日
ライデンの郵便社に所属していたけれど、18才のときにそこを辞めて以降、彼女の記事を見る事はない。
その“自動手記人形”の名は――https://t.co/BAgpWVvhBc#VioletEvergarden pic.twitter.com/GMahx0ba0K
劇場版 ヴァイオレット・エヴァーガーデンを観ました。
情感と余韻を与えてくれる、素晴らしい作品でした。
これ以降は完全に作品内容にも触れた、いわゆるネタバレありの乱文なので特に読まずともよいです。
むしろ、まだこの作品を観ていない場合は読まないでください。
この文章を読んでいるということは、少なからず興味があるということでしょうから、もしそうであるならば、この文章の続きを読むよりも先に、ぜひ観てほしい。
続きを読む
はい。タイトルの通りです。
仕事中、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両方触る人は混乱するかと思いますので注意しましょう。
