ジャムスタックチョットデキル 2023/09/09
7 principles for rich web apps And how next.js achieves these principles
ジャムスタックチョットデキル 2023/09/09
Port forwarding local services with VS Code
Version 1.92 is now available! Read about the new features and fixes from July. Local Port Forwarding Support for port forwarding is built into Visual Studio Code via Microsoft dev tunnels, no extension required. When running a local web service, you can use the Ports view to make the service accessible to others over the internet. How to use local port forwarding First, you need to have a service
インフラエンジニアはSREではないし、SREとPlatform Engineeringも別物 - inductor's blog
インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ
メンバーに対してチームリーダー(マネージャー)が気をつけるべき点
はじめに 現在ITエンジニア歴16年目でこれまでなんどかチームリーダー(プロジェクトリーダー)を経験してきましたが、数年前は上手くいっていたけど、ここ1年位のチームではなかなかうまく行かないことが多く、メンバーからのクレームが上長経由で伝えられてくることがあります。 クレームを伝えてくるメンバーの多くが経験が浅いエンジニア(若手、未経験中途入社)であり、まだITエンジニアとしての業務や商流が分かってない部分もあるゆえのエゴのようなクレームもあるのですが、中にはリーダーとして気をつけるべきだなと思ったことがあったので、まとめておきたいと思います。 なお、経験が浅いエンジニアと主語大きめに書きましたが、数年前にリーダーをした際にQAから転身したてのITエンジニアや、20台中盤くらいの方もいましたが特にクレームはなかったので「メンバーによる可能性はある」ということは書き添えておきます。 また、上
2023年のシェル環境構築
tl;dr fig starship zsh fzf sheldon なぜ vscode の .vscode/tasks.json が fishと非常に相性が悪い。とくに fish-nvm を使っていると、fish 経由のパス実行時に node と npm へパスが通らない。 そもそも fish を使っていた理由は autocomplete を快適にするためだったが、1年ぐらい Fig を使っていて、補完はこれを任せていいと気づいた。 Fig はこういうやつ そもそも fish の拡張コマンドを使わないように生活していた。方言を覚えたくない。というか bash 拡張や zsh 拡張もあんまり覚えたくない。
Making Sense of React Server Components
IntroductionSo, here's something that makes me feel old: React celebrated its 10th birthday this year! In the decade since React was first introduced to a bewildered dev community, it’s gone through several evolutions. The React team has not been shy when it comes to radical changes: if they discover a better solution to a problem, they'll run with it. A couple of months ago, the React team unveil
★再増枠★Frontend Night 〜アーキテクチャ設計編〜 (2023/09/27 19:30〜)
概要 今回は、フロントエンドのアーキテクチャ設計の工夫を語り合う会です！ Next.jsやNuxt.jsなどのフレームワークは浸透してきましたが、ディレクトリ構造やレイヤードアーキテクチャには、デファクトスタンダードと呼ばれるものはありません。 特に今回はNext.jsを本番環境で運用してきた4社が集まり、なぜそのようなアーキテクチャ設計なのか？どのような工夫があるのか？と言ったことをディスカッションし合います。 実際のフォルダ構成なども公開しつつ、過去に失敗したポイントや今後このように改善したいという展望なども語っていただきます。 LTテーマ一覧 登壇企業 ：ARアドバンストテクノロジ株式会社 LTタイトル：「ちょうど良い」フロントエンドアーキテクチャを求めて ARI では、複数のクライアント様向けの Next.js アプリケーション構築から少しずつ知見を得ながら、フロントエンドのアーキ
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
モノタロウ社内デザインシステムの今までとこれから - MonotaRO Tech Blog
UIUXデザイングループのグループ長を担当させていただいている小田と申します。 一般公開はしていないのですが、モノタロウも一貫したデザインや操作性でウェブサイトを提供するためデザインシステムを作り、現状のサイトに適用しています。 今回はモノタロウのデザインシステムのお話をしたいと思います。 デザインシステムの始まり これは数年前の話です。 何年も運営しているサイトだとよくある話ですが、見た目のスタイルが分散していき、その分のコードが積み重なっていき開発の負荷になります。 また、スタイルが分散していると使っている側のユーザーも、この機能はどういう機能なのかを理解する事に時間がかかります。 サービスの品質を上げるPDCAを早く回す為に土台（図1）を整える必要性があり、スタイルを統一したデザインシステムを構築して、ページに適用していくことが目標になりました。 分散していたスタイル： 作成したボタ
Bun 1.0 | Bun Blog
Bun is an all-in-one toolkitWe love JavaScript. It's mature, it moves fast, and its developer community is vibrant and passionate. It's awesome. However, since Node.js debuted 14 years ago, layers and layers of tooling have accumulated on top of each other. And like any system that grows and evolves without centralized planning, JavaScript tooling has become slow and complex. Why Bun existsBun's g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
