似たような技術系の記事を書くことについて - らせんびより
はじめに 先日、フィヨルドブートキャンプ内のQ&Aにて、 調べれば出てくる技術系の記事を、アウトプットとしてもう一度書くのは、アリなのか？ という質問を立てた。 なぜこのような質問をしたかというと、以下の二点がずっと気になっていて、アウトプットの手を止める原因になっていたから。 調べれば似たような記事が出てくるし、自分はそれで理解できたのに、自分が書く意味はあるのだろうか？ 他の優れた記事を探す上での邪魔になるという点で、マイナスになるのではないか？ この、 似たような記事がある中で、自分が書く意味があるのか問題 に対し、フィヨルドブートキャンプのメンターの方々から、たくさんの意見をいただくことができた。 今後、自分がアウトプットをする時の指針として、ここにまとめる。 補足：このまとめは、フィヨルドブートキャンプというプログラミングスクール内の、掲示板でのやり取りをまとめたものです。そのた
Next.js が CSS Modules を推奨する真相に迫りたい
Next.js 9.2 から CSS Modules がビルトインサポート対象になった。 CSS最適化に関して、組み込みサポートのレールから逸れると、ページ単位で最適化された静的CSSの生成不全に陥る。少しでもパフォーマンスの良い Next.js App を構築したいのなら、CSS Modules 一択というのが現状で、CSS in JS に慣れ親しんだ身からすると正直辛い現実だ。 CSS in JS よりも CSS Modules の方が、ロードタイム・ランタイムともに、パフォーマンス面で有利なことは知られている。こちらのベンチマークテストが参考になる。 しかし、本来であるなら皆 CSS in JS を使いたいのではないか。あえてレガシーな CSS Modules 推奨とする理由は、CSS という難儀な仕組みを乗り越えるため、技術的に「そうせざるを得ない」理由が他にもあるのではないか。真
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
そうです。わたしがReactをシンプルにするSWRです。
この記事について SWR について色々と学んだので、その知見をここで共有したいと思います 💪 ※ 基本的に以下の公式サイトの情報を参考にしています 📖 そのため、この記事で出すサンプルコードなどは主に上記の公式サイトから引用させてもらっています。予めご了承ください 🙏 SWR とは何か？ SWR は、Next.js を作っているVercel 社が開発しているデータフェッチのための React Hooks ライブラリです。"SWR"と言う名前は、 stale-while-revalidate の頭文字をとって名付けられています。そのため、SWR はstale-while-revalidateに基づいた処理と設計になっています。 stale-while-revalidateについて解説したい所ですが、解説するとすごく長くなってしまうため、ここでは「 キャッシュをなるべく最新に保つ機能 」
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
Blitz.jsの議論から学ぶ，formik vs react-final-form vs react-hook-form - Qiita
const { register, handleSubmit } = useForm(); const firstNameRef = useRef(); const onSubmit = data => console.log(data); return ( <form onSubmit={handleSubmit(onSubmit)}> <input name="firstName" ref={(e) => { register(e) // hook-form register firstNameRef.current = e // manually assign your ref }} /> ref={ref}で渡したいのに…。 react-final-formのデメリット render propsが初心者には難しいのではないか？というコメントがいくつかあった。 基本的にrender
ログラスのReactの技術選定について🐳
はじめに こんにちはログラスのフロントエンドエンジニアの @Yuiiitoto です。 「次世代型経営管理クラウド」のSaaSを開発しています。 今回Reactを使って開発しているログラスのフロントエンドがどういう技術を使っているのか、なぜそれを選んだかについて解説していきます。 Reactはライブラリの数が豊富な反面で群雄割拠している領域が多く、技術選定がとても大変です。 同じ悩みを抱えるフロントエンドエンジニアの方に少しでも力になれればと思って記事にしました。 ログラスのフロントエンド 似たようなサービスの場合に特に参考にできる場合が多いと思うので、記事の前提としているサービスについて少し説明します。 ログラスはいわゆるtoBのSaaSの業務システムみたいな立ち位置です。 ほぼ全てのページに認証が入り、画面の中の要素はtoCのサイトより多めです。 Next.jsで構成されていて、SSG
不確実性・複雑性の高い業界とキャリアにおける「信仰」／オンラインサロン、一部スクールの勢力拡大の背景｜久松剛／IT百物語の蒐集家
組織をマネージメントする上で避けられないものの一つにマインドや志向性への対峙があります。以前、この志向性を分類してお話したことがありますが、今回はその根幹に横たわる「何を信じるのか」ということについて宗教学の専門家の言葉を交えながらお話したいと思います。 前提 今年9月に話題になった芦田愛菜さんの舞台挨拶について興味深い言及がありました。 「でも、その揺るがない自分の軸を持つのは凄く難しいじゃないですか。だからこそ人は『信じる』って口に出して、不安な自分がいるからこそ、成功した自分だったりとか、理想の人物像だったりにすがりたいんじゃないかと思いました」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - chanzuckerberg/axe-storybook-testing: Command line interface for testing Storybook stories for accessibility.