かみぽわーる

kamipo's blog

仕事の近況2026

今日で現職在籍ちょうど一周年🥳

この一年ぐらいの出来事をいくつか振り返ってみようと思って書き始めたら、仕事パートだけでだいぶ量いったからタイトルを「仕事の近況2026」にした。その他の近況については気が向いたらそのうち書く。

あと、2026年9月19日(土)に名古屋Ruby会議05でなんか話すのでよかったら聴きに来てね👂 昔書いたコードの話してもアレなんでたぶん最近Railsコミッターとして書いたコードについてなんか話すと思います🙂‍↕️

仕事

  • Rails 7.0から最新Rails対応企業に
  • 仕事で遭遇した問題の修正をupstreamに

基本的にRailsアプリケーションのPRは全部巡回してて気になるとこあったらコメントしてるので、その際に「ここ排他制約使うといいんやけどなぁ〜〜」と思うことが度々あった。

たとえば入社当初、何らかの機能(契約)の有効期間を管理してるテーブルにはenabled_on, disabled_onというカラムがあって、DBの制約上は各機能毎のenabled_onにユニーク制約を張って開始日の衝突はDB制約で排除して、期間がオーバーラップしてるかどうかのバリデーションはアプリケーション側で独自にやっていた。

それな〜〜、ポスグレではEXCLUDE USING gist (function_id WITH =, daterange(enabled_on, disabled_on, '[]') WITH &&)するとオーバーラップまでDB制約でチェックできるんやけどなぁ〜〜、と思ってコメントしようとすると、なんとRails 7.0(その時点ですでに4ヶ月前にEOL)のDSLでは排他制約をサポートしていない、サポートしてないRailsだとridgepoleから見たときに制約backedなインデックスが漏出してdiffがおかしくなるので使えない…！ということが3回ぐらいあってダルすぎたので、Railsバージョンアップなんぞに必要なのは気合いだけなんでブロッカーを速攻全部つぶしてRails 7.1に上げた😤

これで使えるかと思ったら、ユニーク制約と違って排他制約違反を個別にキャッチできるようになっていなかった。なのでエラークラスも足した(今まで誰も使ってなかったんか？)

あとマニアックなのでいうと、外部APIリソースのデータへの操作ログを保存するPRを通りがかりに見つけた際に、あるリソースはsid="CAabcxyz..."みたいな文字列になってて別のリソースはconversation_id="CON-abcxyz..."みたいになってて、それらの値を同じカラムにぶち込む設計になっていた。

そらまぁデータを肉眼で眺めたりresource_id LIKE 'CA%'みたいなクエリでフィルタリングすれば選り分けられなくもないが、さすがにここはRailsなのでpolymorphic関連にしてそれぞれの外部リソースIDがどのリソースタイプなのか分かるようにしたいやろ。

ということでサクッと修正したろ思ったら、なんとRails 8.1ではpolymorphic belongs_toの外部リソースのIDはプライマリーキーであるかもしくは全部のリソースで指定した同名のカラムでないと動かないようになっていた。なんとかalias_attributeで同名に見せかけて回避しようとしたがRailsのassociationはまさかのalias_attribute未対応…🫩

さすがにちゃんと動いてほしいんでこれも直しときましたわ。

あとRails + PostgreSQLで開発するのはじめてだったから、annotaterbがユニーク制約とか排他制約とか遅延制約の表示サポートしてないなとかridgepole環境下でVALIDATE CONSTRAINTするの面倒すぎるとかいう問題にもはじめて遭遇してそういうのも直してた。

レイルズチョットデキルのが仕事に役立ってよかった🥰

外にコードが出せるやつじゃない成果だと、ルール分岐設定の複雑さが人間の認知の限界を超えてこの世の終わりすぎたので、超絶簡潔な構造にするリファクタリングをしてた。

分岐アクションや設定が五月雨式に建て増しされてきた結果、同じ構造のテーブルが何個もあったり設定テーブルとの中間テーブルが組み合わせ爆発してたりしたのを、ひたすら二重書き込み->データ遡及->参照切り替えを繰り返して中間テーブル約30個を亡き者にして各設定テーブルを各分岐アクションテーブルとのpolymorphic関連にした。

コード側も各ルール分岐設定コントローラーが、作られた時期も実装者も違うが故にそれぞれがまったく異なる音楽性で実装されてたので、なんか実装を追加しようとすると音楽性の違う各コントローラーに実装を追加する必要があり、実装漏れや修正漏れが度々起きていた。

それを、ひたすらコードをソリティアしまくって徐々に何が共通処理で何が個別の処理なのか整理して抽出していった結果大統一ビルダークラスが爆誕し、コントローラーはビルダーを呼び出すだけになった。なんやかんやここまでやるのに半年かかったけど、以前は対照的な実装をしたいだけやのにやたら面倒でバグったりしてたのを、今は逆に非対称な実装をそう簡単にはできないような構造になったので実装漏れやバグは起こすのが難しくなったと思う。

大満足🥰

推しのアイドルのラストを見届けた

去る3月24日、BLACKNAZARENEのラストライブを見届けた。

これはオタクとしての感想エントリーというよりは、これまでの人生を振り返った自分語りを、ひとつの物語を見届けたこのタイミングで残しておきたかったという内容になると思う。

ナザレには推しがふたりいて、どっちかだけに言及するのはSNSではしないようにしてたんだけど、ここではアイドル東出ひみこの物語を語らせてほしい。

2021年5月4日に新メンバー4人を加えて新体制6人のBLACKNAZARENEが始まったとき、ひみこ以外はアイドル経験者でひみこだけがアイドル未経験からのスタートだった。大阪の販売業で働いていて4月から店長になる予定だったけど、実果子からの「BLACKNAZARENEで一緒にアイドルやりませんか」のインスタのDMで、歌もダンスも苦手で自分がアイドルになるなんて1ミリも思っていなかったひみこの人生が一変して、アイドル東出ひみこの物語が始まったのです。

会社の飲み会で自分は物語、関係性のオタクやって話をしてたんやけど、BLACKNAZARENEは実果子がはじめた物語でもあるけど、僕にとって新体制のBLACKNAZARENEは、ヒロアカで例えると歌もダンスも苦手で自分がアイドルになるなんて1ミリも思っていなかったひみこが、オールマイト実果子に出会って最高のアイドルになるまでの物語でもあったんよね。

あらゆる物語には終わりのときがくると思っていて、終わりがあることに美しさを感じてる。BLACKNAZARENEという物語は、いろんな困難を乗り越えて、新体制の始まりからひとりのメンバーも欠けることなくこの景色までたどり着いて(アイドル業界でこれはマジで偉業)、最高の結末を見届けさせてくれた。この日このときこの景色を見られる人生でよかった。

自分はこんなに美しい人生の結末を迎えられるやろうか。

ここで自分語りをするんやけど、人間って社会的動物じゃないですか。その意味において、僕は昔からずっと人間をやるのが苦手やと思ってここまで生きてきて。この生き苦しさをどう言語化するか考えてたんやけど、おそらく「ひとに言われたことを言われた通りにやるのが苦手」ということなんかと思う。自分が納得できないことを納得できないままやるのは本当に苦手で、自分みたいな人間のなりそこないみたいなのに社会に居ていい場所があると思ってこれなくて、社会で生きるより「自分が自分である」ことをなにより優先して生きてきた。「自分が自分である」ことを諦めてしまったら生きる理由もなくなってしまうと思ってた。

「自分が自分である」ことを諦めなかったから成し遂げられたこともある。Oracle ACEに推薦してもらったりRuby Prizeを受賞したりRails Core Teamメンバーに昇格したり。自分が納得できることやからこそ尋常ならざるパワーで取り組み続けられた結果やと思う。

逆にうまくいかなかったこともある。この10年で3回の退職をしてきたけど、そのどれも「自分はここに居ていい人間じゃない」と思うようになって、ここで自分が誰かのためにできる最後のことがあるとしたら、それは自分で自分を終わらせることやと思っての退職やった。自分がひとの期待に応えられない人間であるということが自己肯定感を地の底まで落としてた。

去年の3月に退職を決めて身辺整理をはじめたときにこれまでの人生を振り返って、ここまでよく生きてこられたなと、正直ちょっと生きるのに疲れたなと思った。自分の人生がこじれ過ぎてて、いっそのこと自分のことを誰も知らないところから人生を始められたら、今度はひとの期待に応えられる人間になれるやろうかと思った。

そう考えるようになったとき、生きる理由やと思ってた「自分が自分である」ことへの執着が薄れてることに気がついた。これが歳を取るということなのか。けど逆に今の自分だったら、いままでできなかった「ひとの期待に応えられる人間」をやりようがあるんじゃないか。自分のなかでポジティブな気持ちで今までの自分を終わらせて、新しい自分をはじめられるんじゃないかという気持ちになれた。

いまは新しい環境で、いままで苦手でやってこなかったことを、いまの自分ならどうや、やってやろうやないかの気持ちで向き合ってる。マジで自分がクソ雑魚すぎてウケるなと思う日もある。けど今度は僕が自分の人生で、バッドエンドじゃない最高の結末をここでみんなと分かち合える人間になりたいと思って生きている。

FXで150万円損切りした😭😭😭

人生なにごとも経験…150万円の損切りを経験したからこそ語りたくなることもある😭😭😭

FXに興味をもったのは、Twitter(現𝕏)でこのツイートを見たのがきっかけだった。

これを見た時点ではドル円ロングもスワップも知らなかったので調べてみたら、スワップポイントというのは金利の低い通貨を売って金利の高い通貨を買うと、FXでは営業日ごとに金利差分の差益が発生するということ(逆のことをするとマイナスのスワップポイントが発生する)。

そこでピキーンとひらめいたんやけど、なんか最近日銀の為替介入があるかもとかありそうとかいう機運が高まってて、為替介入でドル円ドカッと下げたタイミングでドル円ロングMAXでぶち込んだら安全にスワップ取れるのでは？と思って、じゃあ為替介入きたタイミングでFXはじめるかぁ(いまはまだそのときではない)、けどそのまえにFXで買ったり売ったりする練習しとくか〜、いうて今日(4月29日)は祝日で個別株は取引できんしなと思ってTwitter(現𝕏)見たらトレンドに為替介入ってあって、やばいなんも準備できてへんけどこの人生に何度あるかわからんビッグウェーブに乗るしかない！って全力レバレッジ25倍ドル円ロングにぶち込んで勝利のガッツポーズを決めた🕺

けど初心者の僕には想定できてなかったけど、僕が155.650円ぐらいで全力レバレッジ25倍ドル円ロングにぶち込んだ3日後には一時151円台まで下がって含み損は360万円を超えてロスカット食らわんように毎日のように入金を繰り返してた。

じつはRubyKaigi 2024一日目にもドル円めっちゃ下がって含み損360万円で死にかけて入金ナンピンしてたんやけど、おなじ理由で何度も死にかけたくないからなにが起こってたのか調べた結果、5月3日にドル円が下がったのは米国雇用統計の影響で、5月15日に下がったのは米国CPI(消費者物価指数)の影響で、為替はこの経済指標発表イベント起因で上がったり下がったりするルールのゲームやという学びを得た。ので今は経済指標カレンダーを見て重要なイベントの日時をチェックするようになった。

しかし、今回外貨が全部ドカッと下がった(円高になった)のは、僕がちょっと仮眠してる2時間のあいだに"日銀の国債買入れ減額に関する報道"があって含み益150万円が寝て起きたら含み損150万円の火の海になってた、今日は経済指標カレンダー的には安全な日だったはずなのに…。

ちなみに、"日銀の国債買入れ減額に関する報道"があったらなんで円高になるんや？って思いませんでしたか？僕は思いましたので調べました。

日銀が国債買入れ減額するらしい

↓

国債の価値が下がって国債の価格が下がる(と思われる)

↓

国債の価格が下がると金利が上がる関係にある

↓

金利が上がると円高になる

ということのようです。

この経験を活かして、どう考えて行動したら次のおなじような事態を防げるのか考えたい。

まずはスワップ狙いで大量にポジション持つのは、スワップ取れてるときはいいけどちょっと下がっただけで含み損エグくなるんで、1円2円さがっても耐えれるぐらいにしときたい。

今回うっかりユーロ、ポンド、メキシコペソがおいしいところで拾えて含み益めちゃよかったけど新規建できる余力がほぼない状態で、いうて1週間に1回あるかないかぐらいのおいしい下がり方したところで拾ってるから、ちょっと寝てるあいだに下がったとてせいぜいプラマイゼロぐらいやろおもてたら信じられんぐらい下がってて、信じられんぐらい下がったということはそこで買うとめちゃくちゃおいしいにも関わらず、新規建できる余力もなく大量の含み損を抱えて指をくわえてのた打ち回ることしかできんという事態になってた。もしこれが半分ぐらい余力を残せてたら、含み損も75万円ぐらいでそのぐらいならまだ反発するまで耐えれる精神的余力もあったし、そこで新規建できれば逆にチャンスにもなってたわけで。

あとは"ちょっと寝てるあいだに下がったとてせいぜいプラマイゼロぐらいやろ"が成り立たないことが実証されてしまったので、これを防ぐ方法を調べてたどり着いたのは、いうて大丈夫やろ思っててもその期待はいともたやすく打ち砕かれるので、もうぜったいマイナスいかんように逆指値注文を一週間帯で入れとくようにした。

正直FXはじめた当初は、プラスになるように買っとるのに、マイナスになること考えて注文いれるやつおる！？(いねえよなぁ)と思っていたがとても浅はかだったわ。守るものがあればひとはどこまででも強くなれる。

新しいことをはじめると、昨日までの自分が知らなかったことを毎日経験して学ぶことがあってめっちゃ充実してるし、この年になっても昨日の自分より今日の自分のほうが強いと思えることがうれしい、生を実感してる。

昨日より強くなった自分で、余裕で150万円ぐらい取り返したるぞ💪

HPVワクチンを接種してきた

先日、HPVワクチン(ガーダシル9価)を接種してきた。

HPV(ヒトパピローマウイルス)は、性的接触のあるひとはだいたいが生涯で一度は感染するとされている一般的なウイルスで、子宮頸がんを始め、肛門がん、膣がんなどのがんや尖圭コンジローマ等多くの病気の発生に関わっています。特に、近年若い女性の子宮頸がん罹患が増えていると言われていて、年間約1万人が疾患して、約2900人がこの病気で命を落としているそうです。

HPVワクチンは小学校6年～高校1年相当の女の子は定期接種といって無銭(公費)でワクチンを接種できます。が、2013年にいろいろあって定期接種の積極的勧奨を差し控えるという事態になってしまい、アメリカやオーストラリアでは接種率が約8割に達する中、日本での接種率は1%以下となっていたそうです。が、約9年のときを経てついに2022年4月に積極的勧奨が再開されました！

積極的勧奨が差し控えられた当時、ワクチンの副反応がやべえみたいな感じでメディアで煽られたために、親御さんがそんなやべえもんうちの子に打たせられるか！みたいな感じで定期接種を受けられずに大人になってしまったひともいるかと思うんですけど、ただいまキャッチアップ接種キャンペーン期間中(2022年4月〜2025年3月)につき、誕生日が1997年4月2日～2006年4月1日の16歳〜25歳の女性も無銭(公費)でワクチンを接種することができます！

定期接種を受けられなかったキャッチアップ接種対象のひとには予診票が届くことになってるんですが、このキャンペーンけっこう急に決まって対応に手が回ってない自治体もあるらしいんで、キャッチアップ接種受けたいけどまだ予診票届いてないってひとは自分がお住まいの自治体にキャッチアップ接種受けたいんで予診票送ってもらっていいですか？って問い合わせしてみるといいかもしれないです。

www.mhlw.go.jp

あとキャッチアップ接種のこと知らなくて自腹でHPVワクチン接種してもうたわってひとも、任意接種の費用を助成してくれる自治体もあるので自分がお住まいの自治体に確認してみるといいかもです。ちなみに僕が住む新宿区は任意接種の費用を助成してくれるみたいです。

www.city.shinjuku.lg.jp

あと日本ではまだ定期接種は女性だけが対象なのだけど、アメリカやイギリスとかでは男子も定期接種の対象で、オーストラリアでは15歳の男女の接種率は80%超えてて子宮頸がんの原因になるハイリスク群の型のHPV感染がめちゃくちゃ減少しているそうです。

日本でも、男性のHPVワクチン接種を助成する自治体も出てきてて、この流れがいろんな自治体に広まっていって、いずれは性別に関わらず定期接種できるようになったらめっちゃいいと思う！

nlab.itmedia.co.jp

僕はもういい年したおっさんなので、いまさら僕がHPVワクチン接種したところで、僕自身がHPV感染を予防するという意味での効果は正直あんまりないと思うんだけど、ひとに勧めるワクチンを自分は接種してないというのもどうかと思うし、こういうのは気持ちの問題なんでね、おっさんにはあんまり効果ないと思うけど若ければ若いうちに接種したほうが予防効果は期待できるんで、キャッチアップ接種とかあってお得な今がHPVワクチン接種を検討するビッグウェーブに乗る絶好のチャンスなんじゃないかなと思います僕は。

MySQL 8.0のクライアントでMySQL 5.7のサーバーに接続するとcharsetが設定されないかもしれない

methaneさんにMySQLのハンドシェイクパケットにはcollation_idが入ってることを教えてもらったので、本当にHandshake Response Packetからcharsetを設定しているのか調べてみた。

MySQL :: MySQL Internals Manual :: 14.2 Connection Phase

Handshake Response Packetのペイロードの構造を見ると先頭から8バイト目にたしかにcharacter_setのidを1バイト入れられるっぽい。

MySQL :: MySQL Internals Manual :: 14.2.5 Connection Phase Packets

MySQL 8.0のdefault collationのid一覧はこれ。

MySQL :: MySQL Internals Manual :: 14.1.4 Character Set

このパケットは、サーバーからのInitial Handshake Packetをパースしたあと、最初にレスポンスするときにmysql_fill_packet_headerで作られてサーバーに送られる。

https://github.com/mysql/mysql-server/blob/mysql-8.0.23/sql-common/client.cc#L4060

サーバーはparse_client_handshake_packetでクライアントからのレスポンスの先頭から8バイト目をcharset_codeとして取り出している。

https://github.com/mysql/mysql-server/blob/mysql-8.0.23/sql/auth/sql_authentication.cc#L2476

https://github.com/mysql/mysql-server/blob/mysql-8.0.23/sql/auth/sql_authentication.cc#L2581

最終的にthd_init_client_charsetで取り出したcs_numberから現在のスレッドハンドルのcharsetを設定している。

https://github.com/mysql/mysql-server/blob/mysql-8.0.23/sql/sql_connect.cc#L422-L423

これにより、mysql_options(mysql, MYSQL_SET_CHARSET_NAME, cs_name)してmysql_real_connect(mysql, ...)するとcs_nameのdefault collationがコネクションのcharsetとして設定されるわけですね。

ここで表題の "MySQL 8.0のクライアントでMySQL 5.7のサーバーに接続するとcharsetが設定されないかもしれない" についてなんですが、MySQL 8.0.1からutf8mb4のdefault collationがutf8mb4_general_ci (id: 45)からutf8mb4_0900_ai_ci (id: 255)に変更されたため、MySQL 8.0のクライアントがuff8mb4でサーバーに接続するとid: 255のcs_numberを送るけどMySQL 5.7はid: 255のcs_numberを知らないのでサーバー側のデフォルトの設定が採用されるという仕組み。

理想的なケースでは、サーバーに接続したらcharsetは適切に設定されるけど、最悪のケース、サーバーはMySQL 5.7でサーバー側のcharsetはutf8mb4に設定されておらずMySQL 8.0のクライアントからutf8mb4で接続するケースではコネクションのcharsetはutf8mb4に設定されない。

一応、接続後にSET NAMES utf8mb4すればサーバー側のutf8mb4のdefault collationが設定されるが、最悪のケースをカバーするために適切に設定してるひとには必要ない処理が増えて損をすることになるのでなんとか回避したい気持ちがあるけど、現状はそういう感じ。

新宿うまいカレー屋多すぎん？

いろいろあって自由な時間を活用してなんか人生が充実するようなことしたいなということで、ランチのおいしいお店を開拓しようというのをやっていた。その中でも新宿うまいカレー屋多すぎん？と思ったので行ったことのある新宿のカレー屋さんを紹介します。

三丁目と御苑前のあいだぐらいでちょっと遠いんだけど新宿でいちばん好きなカレー。🍆🍅🐔がうますぎるので🍆🍅🐔ばっかり食ってる。

  • 東京ドミニカ

草枕うますぎるけど遠いので、近場でうまいスープカレー食いたいときによく行く。

  • 魯珈

ランチタイムに限定35食ぐらいしか提供してなくて朝ノートに記帳して整番ゲットしないと食べられない貴重なお店。つぎいつ来れるかわからないのでこの日はルーとライスおかわりしました🍛

  • 半月

魯珈の近くにあるお店。整番ゲットしなくても入れてうまい。お店の名前の半月はお皿に盛ったルーが半月の形だかららしいです🌛

  • FISH

なんかどこからともなくすごいいい匂いしてくるから気になって調べたら人気店だった。激辛チキンがマジで激辛すぎて震えた:;(∩´﹏`∩);:

  • 極哩

野菜の彩りがオシャレで映え重視で来た。かわいい店員さんにおすすめされてグアバジュースも頼みました(ちょろい)

  • アチャカナ

ここで紹介した中だと唯一ライスかナンか選べるお店だったのでナンにしました🇮🇳

  • イエローカンパニー

めっちゃオーソドックスなスープカレーという感じ。カレーに合いそうなビールがけっこうある🍺

  • 酔っこら処

ほりさんのカレーおいしいです(^q^)

他にもおいしいお店あったら教えてください行ってみます🍛

2021年はブログを書くのをがんばろうという話

5ヶ月前に退職エントリを出してから、いろんな会社さんだったり個人的にだったり、いろんな人と話させてもらった。

blog.kamipo.net

もともと、Railsを改善する活動をずっとしてきて、僕は悲観的なところがあるので、Railsを改善することの価値は将来的には下がっていくだろうなと思っていて。なので、常にいまがRailsを改善する最も価値ある瞬間で、だからこそいまそれをやる意義が僕にはあって、いまやらないとその機会を失ってしまうだろうと思って、いまに至っている。

とはいえ、僕は価値があると思ってやっている活動もその継続性を考えると、経済的な価値に転換するポイントを見いださないと、僕の資金が続く限りはやります、資金が尽きたら終わりますになってしまうので、これまで"個人の趣味"としてやってきて改善すること以外はマジでどうでもいいと思ってそういうこと何も考えてこなかったから(ぜんぜんどうでもよくなかった)、継続性という点についてはこれからもいろんな人の意見だったりを聞いて考えていきたいところです。

まだコロナ禍になるまえ、オフラインでやってたころのESM, Inc.さん主催のOSSパッチ会の体験が僕にとってはとてもよく、Railsのユースケースや改善点に関するフィードバックが得られて、それによって僕の活動が誰かにちゃんと届いてるという実感も得られる。

その体験をもっと広げられないかという思いもあって、いま、Railsのことに関するフィードバックだったり相談だったり(べつにRailsのことじゃなくてもいいし雑談とかでもいい)を受けられるように、SlackのGuestアカウントをもらってる会社さんが何社かある。

実際やってみると、あの体験を再現するのはなかなか難しいのだなと感じていて、そもそも、OSSパッチ会に来るような人はすでにOSSを改善しようって意識を持って集まってる人たちで、そんなみんな毎日「よーしOSSを改善するぞ〜！」みたいな感じで日々の業務をしているわけじゃないという、考えてみたらそらそうやなというのがまず最初に感じたこと。

あと、関係性的に業務のコードを見れるわけではないので、コード見たら「あ〜そういう感じか〜それはRails側で改善されてくれるとうれしい案件やな〜」ってわかりそうなことも、そういう感度をもった人が相談してくれない限り察知のしようがないというのも感じた。

たとえば前職でのケースでいうと、クソクエリでDBが死んでしまうのをMAX_EXECUTION_TIME()で対処したときに、これMySQL使ってたらマジで超絶有用な機能やしBasecamp, Shopify, GitHubもMySQL使っとるねんからふつうにみんな必要やろってRails 6.0でOptimizer Hintsサポートを入れたり。

github.com

これ以前にもMAX_EXECUTION_TIME()使いたいねんけどどう思う？ってプエルトリコ人の同僚(プランテインが大好き)に相談されたときに、ええと思うけどクエリがタイムアウトしたときのハンドリングしたいよな〜ってことでStatementTimeoutエラークラス入れたり。

github.com

他にも僕はuniquenessバリデーターのcase_sensitive: false警察をやってたんですが、フィロソフィーのダンスのオタクの同僚(おとはす推し)に「Rails側でなんとかしてくださいよ〜」って言われて、既存アプリに影響ある変更をするのは気合い要るけどまあ気合いだけの問題なんでやるか〜ってことでuniquenessバリデーターの挙動変えたり。

github.com

他にもそういう感じのはいっぱいあって、こういう話はコードが見れない側からだとちょっと難しいなと感じた。

あとはまあ、「Railsコミッターだけど何か質問ある？(雑談でも可)」って人がいきなり現れても、話題ないよな、僕も自分から雑談するタイプじゃないし、というのも感じてる。

そんなこんなで、そういう状況を改善したく、ひとつには僕がいままで自分の活動だったり改善だったりを宣伝してこなかったことも一因だと思っているので、普段からRailsの動向をウォッチしてない人にも僕の活動だったり改善だったりが伝わるように、できるところからということでひとまずブログでアウトプットするのをがんばっていこうというのを今年の抱負としたいと思います。