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

フロントエンドカンファレンス北海道 2024 の登壇資料です. コードベースに秩序をもたらすため各種 Linter を利用している方も多いのではないでしょうか？一般的なルールについては Linter 内蔵のものや既存の Plugin ですでにカバーできるでしょうが, 一方で事業ドメイン特化であったり UX/DX を向上させるための技術ドメイン特化なルールまではサポートし切れないケースの方が多いでしょう. 日経電子版においてもコードベースにそうした事業ドメイン, 技術ドメイン特化な制約が存在しています. こうした日経電子版特化な制約について日経電子版開発では属人的なレビューで弾くといったアプローチでなく, できるものは ESLint Plugin を開発してそれにより機械的に弾くアプローチをとっています. 本セッションでは事業, 技術ドメイン特化な ESLint Plugin を開発する利点や How To を具体例とともにご紹介します.

Nikkei Tech Talk #3 メディア企業のWebフロントエンド～多様な開発と技術選定～ https://nikkei.connpass.com/event/268793/ で発表させていただいた際の資料です。日経電子版の開発の今についてお話ししました。

処理系フレンドリーなコードによるフロントエンドのコードベース改善のアプローチと, 実際に日経電子版Webにおいて行った事例をご紹介します.

日経電子版は創刊から10年以上続く Web サービスです。そんなサービスを開発する中でアプリケーション要件や技術的な情勢の変遷に合わせ技術の刷新, リアーキテクトなども行ってきましたが迂闊に手を出せない部分というのも存在します. その一例としてサービスの心臓部である CDN レイヤーがあげられます. 日経電子版の CDN は電子版のシステム構成上多くの責務を抱えてしまっていますが、それでも泥臭く開発し続けられるよう仕組み化されていました. しかし長年の運用により段々と Big ball of mud と成り果てました. Big ball of mud でありかつサービスの心臓部でもあるいわば Big heart of mud となっていました. 本トークでは電子版の CDN レイヤーの Muddy な開発や Muddy が故の脆さ, そして Muddy な心臓部と向き合い少しでも地盤を固めていくための Muddy な取り組みについて紹介させていただきます.

In the web frontend development context, we should care about function's side effect not only for simplicity of the function's responsibility, but also for preventing unnecessary/dangerous code from leaking into client side. This slides show why we should care about side effect in frontend development, and introduce treeche, which is the tool to detect side effect in the ESModule

workerd に見出した、Edge を越えてさまざまな場所で動かしうる Edge Proxy としてのユースケースについて紹介します

pnpm で古くなったパッケージを検知する outdated コマンドで, JSON 形式での出力をサポートしました.

bundle size を減らすことに有用な, JavaScript/TypeScript 製 module が tree-shakable かどうかをチェックするnpmモジュール、treeche を開発したのでそれの紹介記事.

コードの表記揺れを縛るESLint Pluginを作ったので供養する.

弊ブログで多言語対応を行なった。その際 cloudflare workers を利用したが体験が良かったのでメモとして残しておく。

自作ブラウザを実装した続きとして, Chrome ブラウザで自作ブラウザを動かす, ということをした際の学習ノートです.

fastly の提供するEdge Computing基盤のCompute@EdgeのJavaScriptの対応が始まったことを受け、Compute@Edgeで何ができるのかをComput@EdgeでGraphQL Serverを立てることを通して考察します。

JSConf JP 2021にてLTさせていただいた時の資料です.

fastifyの `reply.header(key, value)` は header に書き込まれるべき key-value を呼び出されたタイミングで HTTP Response に書き込むのではなく, `res.send` のタイミングで書き込んでいます. Stream を配信する際, `reply.raw.write` を呼び出してしまっていると Header は暗黙的に flush されてしまっており書き込めなくなってしまいます. workaroundとしては, `reply.raw.write` の前に `reply.raw.setHeader` を呼び出し header の書き込みを fastify に任せるのではなく自分で担ってしまいこれを回避するのが良さそう.

サマーインターン前につよつよになっちゃおうの会でWebフロントエンドのパフォーマンスについてLTした際の資料です

今年の一年を一言で表すと「深化」の一年でした, 去年なあなあで理解していた部分など,　細かく突き詰めて理解できそれを元にわかる領域の問題に対して自分なりの意見考察をもって考えられるようになったような気がします.

リクルートで携わった、攻めのセキュリティ対策としてリクルートで行われている web issueの追従、調査の取り組みについて書いています。

ASTイジイジするのはいいぞ！！ * 難しくない * 自分のDXを自分で守るというエキサイティングな体験ができる * 触れる範囲が広がる * プログラミングをやる限りお世話になる と良いことづくめで最高なので布教したい また, このブログは [https://docs.google.com/presentation/d/1Ykka2_NvseClPO2J_oFqRUb_sD6rZfYBU-XWnsdTn9U/edit?usp=sharing](https://docs.google.com/presentation/d/1Ykka2_NvseClPO2J_oFqRUb_sD6rZfYBU-XWnsdTn9U/edit?usp=sharing) の補助資料です. まあこの記事の方を読めば大丈夫です大丈夫です.

Cyber Agent主催のWeb Speed Hackathon Online 4/25, 4/26に参加してきました. 結果は残念ながらレギュレーション違反で選外でしたが, とても楽しく刺激を得られたイベントになりました. この混乱した情勢の中オンラインという形でシステムを整えて実施してくださったCyber Agentの皆さん, ありがとうございました.

世は技術ブログ大時代. みんなはてなブログか[JAMstack](https://jamstack.org/)にその身を委ねていた. お手軽さを求めるならはてなブログ, あるいはそこにカスタマイズ性やスピードを求めてHeadlessCMSにコンテンツを追加して動的に静的サイトを更新していくJAMstackな構成を目指した. 実際今の時代, GatsbyjsなりNextjsでもcontentfulなどを組み込んだJAMstackのテンプレートがあるので, HeadlessCMSからAPIを取得して環境変数として設定して, 適切にCI/CDを組んであげればもうJAMstackによる高速でお手軽な技術ブログが完成します. すごい時代だ.でもそんな中, あえてSSRを用いた動的な構成にロマンを感じ動的なブログを構築しようとした男がいました, いや僕なんですけど. cloud runでNode.jsの上にexpressサーバーを生やして, そこでJSXをreact-domを通してhtmlにしています. しかし一回のアクセスごとにexpressが立ち上がると時間がかかる(特にTTFB), そもそも従量課金制なのでアクセスのたびにサーバーを立ち上げるのでなく, 出来るだけキャッシュを効かせたい. 特にこの場合本質となるブログ記事はCMS上にあるのでそこを参照したい. というのを叶えたく, edge-sideでスクリプトを動かしてキャッシュを動的に管理して更なる最適化を目指す, という取り組みをしてみます.

[Next.js 9](https://nextjs.org/blog/next-9) 7月8日Next.jsのv9リリースが発表されました。 実はこのブログの前身もNext.jsで書かれていて書いた当時はまだv8でした。でv9リリースからおよそ5ヶ月が経ってやっと、重い腰を上げて自分のブログのアップデートを試みました。 ですが蓋を開けるとあら不思議、あまりの~~クソ~~コードぷりになかなか作業が進まない。 具体的に言ってしまうと@ts-ignoreとanyのオンパレードで下手したらJSのまま作業するよりも酷い代物が出来上がっていました。 そんなものをアップデートしようとしても全然コンパイルが通らず、しかもバカ遅い。 ちなみにこれが書き換える前のlighthouseのスコア、無慈悲な0点に涙を禁じ得ません。 そしてもう何もかもが無理になり一から作り直してしまうことにしました()

お久しぶりです、しにゃいです。 TypeScript いいですよね、静的型付けにより今あなたが触っているプロジェクトをより安全に進めて行くことができます。 しかしそんな TypeScript さんもなんだこれは、といってしまうような一見よくわからない挙動をすることがあります。 この記事ではその中の一つともいえよう反変について扱っておこうかなと思います。

この記事は前回の記事の続きという感じです。これまた初学者向け [脱 create-react-app、React アプリの小さめ構築](https://www.shinyaigeek.com/p/22) この記事を読めば create-react-app なしで react アプリを構築できる様になるのですが、その続きとしてこの記事では react-router について扱おうと思います(開発していて思いの外どぶったので) react-router のエラー、割とありますよね. ていうか公式の API なり Document なりがよくわからないって感じはします。 なんかよくわからないけど 404 エラーが出たり、CANNOT GET URL みたいなエラーが出たり、僕もこれでどぶって、いい感じの日本語記事が見つからなかったのもあってじゃあ紹介しておこうかなという感じです。

突然ですがみなさん、React アプリ構築に create-react-app 使わないと出来ないのにフロントエンジニア名乗ってるなんてまさかですけどないですよね？？？webpack の設定いつも適当にコピペしてたりなんてしていませんよね？？？ (まあ僕も割とこんな感じだったので人の事は言えませんが) 今回は上記の煽りであ、やばいかもと思った人向けの記事です。 タイトルの通り create-react-app 無しでの React アプリ構築の手順(というか比較的小さい構築)をやっていこうかなと思います。(思ったより適当な日本語記事がなかったので) webpack,TypeScript あたりを使ってやって行く予定です。 目標は"Hello React"と書き出すとこまでです。 え？？しょぼくない？？と思う方もいると思われますが、これ以降の簡単なアプリ作ったりってのは結構どの記事でもやられているのでそちらを参考にしてほしいなという感じです。 また特にモジュール積みのところでガンガン module についての記事を載せたり、公式のドキュメントを載せていますが、これはイマイチわからない人は読んだ方がいいんじゃない？というくらいの気持ちで載せたので読む体力がないのであれば今は飛ばしても結構かと思われます。いつか思い出した時にでも読んでください。

初めまして、しにゃいこと、林仁と言います。 ブログ始めてみました。 なんでアメブロやはてなブログなど既存のブログサービスを使わずにこんなダサくめんどくさそうなことをしたかというと単純に面白いかなと今日の朝思っちゃいまして