Shinobu Hayashi/Shinyaigeek

モノレポ統合により複雑なマイクロサービスの開発を単純化するアプローチ — HACK The Nikkei 日経電子版の技術的な基盤について、莫大なリポジトリで構成されるマイクロサービスをモノレポ化してしまうことにより、開発効率を向上させた事例についてお話しします。

hack.nikkei.com/blog/advent2...

クソデカポリレポを気合いでモノレポに統合したアプローチを僕のそっくりさんが書いたらしい

Next.js's --experimental-https feature solved this issue but I want more universal and reasonable solution

In most cases, we should apply the __Host or __Secure suffix to application cookies. However, using the Secure attribute can cause mismatched cookie attribute issues in localhost environments without SSL/TLS. Hmm...

Thank you for sharing this great feature! Yes, I had heard of this, but I thought a presentational component was enough for storybook's component catalog, and this also solves testing problem so I decided not to use this feature 😭

最近なんかやけにパソコンカタカタへの欲求が学生の頃レベルにマシマシになってきたと同時に、生活習慣とかを一切考えずにパッションだけでパソコンカタカタ出来るよう無職になりたい気持ちも増されてきた

ChatGPTある時代だし tailwindcss 剥がすなんて楽勝やろ！と思ってた時代が僕にもありました

二郎系ラーメン食べたらお腹と頭が馬鹿みたいに痛くて加齢を実感している

In this pattern, the server/client components just handle data and its behavior and pass them to the presentational ones.
So far, this approach has worked well and has even resolved some common testing and Storybook issues typically encountered with RSC.

While exploring the server/client boundary around RSC and RCC(?), I ended up with a (slightly strict) Presentational/Container pattern. I separated component behavior into client and server-specific container ones, while the markup went into universal presentational ones.

We can choose a language of our post in bsky, this is the most desirable feature for me

ライブラリのラッパーやその設定をフレームワークが提供していたりないしはコードベースから生成しているあれこれへの悲しい思い出がインクリメントされてしまった

確定申告、毎年頭が痛くなる

community.fastly.com/t/new-options-…

fastly が polyfill-service folkして更に fastly が hosting している polyfill-fastly.io も提供してくれるようになった, 動きが早い

カクテルとスパイス棚がかなりいい感じになってきた

気づいてしまったけど俺あと2ヶ月で25になるのやばすぎ、、、しにゃいという謎のニックネームで呼ばれるアラサーが爆誕してしまう

Twitter と blsky の使い分け、ポストしたいときに開いていたほうを使うという運用をしてるけど手癖と通知の量によってTwitterが圧倒的に有利になってしまっている

評価ハックがうまいほうという自覚もあるので無意識にしてしまっていないかというのもある

給与なんて事業の業界やなんなら住む土地で変動する曖昧なものだと頭では思いつつ、高い給与を目にすると自分はそれに応えうる価値を提供しているんだろうか、出来るんだろうかという不安にとらわれがち

会社休んで遊びに行く予定を立てたがお相手がインフルになってしまいただただ会社を休んだ人になってしまった

これ笑った、やっぱみんなTwitter呼びの呪縛からまたま離れられて無いんやな、、、

fortee.jp/fec-okinawa-...

対戦よろしくお願いします

京都の飲みべ最高だった

【日経×Cloudflare×Vercel×Fastly】Edgeコンピューティングとフロントエンド (202... ## はじめに NIKKEI Tech Talk #13 のテーマはEdgeコンピューティングとWebフロントエンド。CDNにおけるEdgeコンピューティングについて各社の新しい技術や�...

nikkei.connpass.com/event/296291/

僕のそっくりさんがどうやら edge について議論するそうですな

表参道でかなり最高なワインバーを見つけてしまった、！、かなり美味しいワインとそのうんちくをかなり安い値段で楽しめる

アメリカンドラマとかが好きでよく見る影響でリラックスして話してると口をついてジョークが出るんだけど俯瞰するとおじさん化の兆候なのかもしれない

compute@edgeによってFastly VCLはどんどん下火になっていく、と思っていたけどVCL generative objectsでGUIベースでCDNでの処理を書きたいという需要もそこそこあるっぽく、そのへんのマイグレーションができるVCLはまだ生き残るのではという気もしてきた、service chainingが安くできるようになるとあれだけど、、、

標準packageならそんなドラスティックな変更入れてこんやろ！というのはありそう

依存更新を楽にしたいというモチベーションで標準packageが多い言語を採用する、というの実はそんな効果ない？と思えてきた。結局標準packageでなるべく実装しても、逃れられないランタイムのアップデートに伴ってそれを用いて実装している箇所見なきゃだし、あまり変わらない気もしてきた

技術的には可能という言葉、実際にはそれ単体で言うことはなく無限の工数が掛かる、とかメンテナンス性が著しく損なわれる、とかトレードオフを示して喋ると思うしそうすれば伝わらないこともないのでは、、、という気はする

linter, 個人開発程度ならなんでもいいとなるけど、かっちり目の開発だとterser friendlyにするためprivateメソッドを__始まりにするとか、そういうニッチな制約を入れたくなって結局柔軟で拡張性の高いeslintに回帰してしまう