Next.js Layouts RFC in 5 minutes – Vercel
The Next.js team at Vercel released the Layouts RFC a few months ago outlining the vision for the future of routing, layouts, and data fetching in the framework. The RFC is detailed and covers both basic and advanced features. This post will cover the most important features of the upcoming Next.js changes landing in the next major version that you should be aware of. Creating RoutesIn the new app
GitHub - vanilla-extract-css/vanilla-extract: Zero-runtime Stylesheets-in-TypeScript
Zero-runtime Stylesheets-in-TypeScript. Write your styles in TypeScript (or JavaScript) with locally scoped class names and CSS Variables, then generate static CSS files at build time. Basically, it’s “CSS Modules-in-TypeScript” but with scoped CSS Variables + heaps more. 🔥 All styles generated at build time — just like Sass, Less, etc. ✨ Minimal abstraction over standard CSS. 🦄 Works with
【FPS】オンラインゲーム苦手座談会【MMO】 - イーアイデム「ジモコロ」
MMOやバトルロイヤル系のFPSなど、オンラインのゲームが苦手という4人が集まって座談会を行いました。コミュニケーションが苦手でモンスターハンターなどのネトゲにハマれない、勝てないからPUBGやApex legendsについていけないなど、彼らはなぜオンラインが苦手なのか？ こんにちは。ゲーム大好きライターのオケモトです。 みなさんゲーム、やってますか？ 僕は現在、2年前に発売された『キャプテン翼 RISE OF NEW CHAMPIONS』というゲームで翼君のオーバ―ドライブシュートをゴールに打ち込みまくっています。 それはさておき、昨今のゲームはオンラインで協力したり対戦を楽しむものが多くなってきました。 しかしゲーム好きの間でもどうしてもオンラインに苦手意識を持っている人々が存在します。 ・コミュニケーションが苦手 ・自分だけの力で攻略したい ・やりこみプレイヤーには敵わない“雑魚プ
ZOZOTOWN Webフロントエンドリプレイスにおける CSS in JS の技術選定で Emotion を選定した話 - ZOZO TECH BLOG
はじめに こんにちは。ZOZOTOWN開発本部フロントエンドの菊地（@hiro0218）です。 現在、ZOZOTOWNではWebフロントエンド技術のリプレイスプロジェクトが進行しています1。本記事では、WebフロントエンドのリプレイスでCSS in JSの技術選定をした際の背景や課題についてご紹介します。 既存技術スタックの課題 リプレイス以前の環境は、Classic ASPのテンプレートエンジンに依存したUI実装が多く存在しており、新規開発や変更のタイミングで実装をReact + CSS Modulesへ改修しています。そのため、レガシーな実装とモダンな実装が共存した状態です。 こういった背景から、リプレイス以前のUI開発では以下のような課題がありました。 グローバルなCSSが多く、CSSの変更がどこへ影響するのか予測しづらい Classic ASPのテンプレートエンジンに依存したUI実
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化
約1年前にGitHub Copilotのテクニカルプレビューを開始したとき、私たちはこのツールがソフトウェア開発者の役に立っているのかを明確にしたいと考えていました。アンケートと実験を組み合わせた調査を実施したところ、予想していた回答と予想外の回答の両方が導き出されました。 私たちは日々、より少ない労力でより多くのことを実現するために、ツールを活用したり工程を習慣化したりしています。ソフトウェア開発においては、作業の効率化のために非常に多くのツールとテクノロジーが生み出されており、それらを選択することに疲れを感じるほどになっています。2021年にGitHub Copilotのテクニカルプレビューを開始したとき、私たちは、これによって開発者の生産性が向上するだろうという仮説を立てました。実際、初期のユーザーから「生産性が向上した」という報告がありました。リリースから数か月後、私たちは、定量的
特定のユーザーのイベントによるGitHub ActionsのActionを保留状態にしておき、後で手動実行できるようにする - その手の平は尻もつかめるさ
dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは？」と思い、それを試したという次第です。 この記事では例として、renovate
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
| After half a year, what now?