TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
TypeScriptのError Handling - mrsekut-p
TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
freee 会計に残る 400ファイルの CoffeeScript を decaffeinate を使って書き換えた話 - freee Developers Hub
こんにちは、freee会計でエンジニアをしている jaxx です。 freee 会計におけるメイン業務とあわせて、会計フロントエンド委員会というフロントエンドに思い入れのある有志で集まった委員会にも所属しており、フロントエンドの技術的負債と向き合ったり、新しい技術導入に向けて意見を交換し合ったりしています。 今回はその改善の一環として freee 会計に残る 400ファイルの CoffeeScript を decaffeinate を使って書き換えた話をします。 freee 会計と CoffeeScript 参考:「10分でわかるfreee エンジニア向け会社説明資料」 freee 会計の開発が始まった 2012 年ごろ Ruby on Rails3 では CoffeeScript が標準サポートされており、freee もそれにならってフロントエンドでは CoffeeScript がメイン
eslint-plugin-import-accessではじめるディレクトリ単位カプセル化
こんにちは。この記事は筆者が製作した ESLint 向けプラグイン eslint-plugin-import-accessを紹介する記事です。 このプラグインにより TypeScript プログラムに擬似的なpackage-private exportの概念が生まれます。JSDoc で@packageとアノテートされたexport宣言は、そのファイルが属するディレクトリの外からインポートすることができなくなります。 従来、TypeScript で可能なカプセル化の最大の単位は「ファイル」であり、ファイルからエクスポートしない変数はそのファイル（モジュール）の中に閉じている一方で、一旦エクスポートしたものはプロジェクトのどこからでもインポート可能になります。これでは不都合な場合がありました。 最近の具体的な例としてはRecoilが挙げられます。筆者の以前の記事では、Atom や Select
JavaScript/TypeScriptの高速フォーマッター「Rome Formatter」リリース。Rust製でPrettierより約10倍高速と
JavaScript/TypeScriptの高速フォーマッター「Rome Formatter」リリース。Rust製でPrettierより約10倍高速と JavaScriptのツールチェインを統一的に提供することを目指した「Rome Tools, Inc.」（以下、Rome Tools）は、JavaScriptおよびTypeScriptのコードの書式を高速に整えるフォーマッター「Rome Formatter」をリリースしました。 Release of the Rome Formatter, a super fast formatter for JavaScript, with a focus on Prettier compatibilityhttps://t.co/2iXq5Gm5K3 — Rome Tools (@rometools) April 5, 2022 Rome Toolsは、
lernaからlerna-lite + turborepoに移行する
Secretlintはmonorepoとなっていて、パッケージを公開する際にlernaを利用していました。 しかし、lernaは現在メンテナンスされていないため、publish機能だけを取り出したlerna-liteと効率的なmonorepo向けのビルドツールであるTurborepoへ移行しました。 Lerna is largely unmaintained · Issue #2703 · lerna/lerna 追記: NxによってLernaがメンテナンスされるそうです。 Announcement: Passing the torch · Issue #3121 · lerna/lerna Lerna is dead — Long Live Lerna. If you’re in a hurry, here’s the TL;DR: | by Juri Strumpflohner | M
Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
「たかがJavaScript」のその先 #TECHPLAY
フロントエンドと自分のキャリア形成について。このスキルツリーとセットで見るといいかもです。 https://whimsical.com/oPYtoDPyho6uWK1gDmD9e
JSの非同期処理を理解するために必要だった知識と学習ロードマップ
はじめに JavaScript の非同期処理を学習してみて「ある程度自信を持って理解できたと言える」状態に到達したので、その感想とまとめの学習ロードマップとその中でどのような知識が必要になるかを紹介したいと思います。 あるいは、自分が実際に学習してきた道筋に基づいているのでショートカットとして参考にしてもらったり、使えるリソースなどの情報が共有できると思います。もしくは「JavaScript 初心者が非同期処理を理解できるようになるまでの道筋」というストーリーで１つのサンプルとして見ていただけるといいかもしれません。 ChangeLog 大きな変更のみをトラッキングしています。 2022-11-16 本の内容を反映させた追記・修正を追加 2022-05-21 構成を修正 「V8 エンジンから考える」の項目を追加 2022-04-30 「イベントループの共通性質」の項目を追加 「ロードマップ
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
TypeScriptのmoduleSuffixesについて考えて納得した - Qiita
みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri
React 18に備えるにはどうすればいいの？ 5分で理解する - Qiita
React 18はReactの次期メジャーバージョンで、2021年の6月にalpha版が、11月にbeta版が出ました。また、Next.js 12でもReact 18のサポートが実験的機能として追加されました。React 18の足音がだんだんと我々に近づき、アーリーアダプターではない皆さんの視界にもいよいよReact 18が入ってきたところです。 特に、React 18ではServer-Side Rendering (SSR) のストリーミングサポートが追加されます。現在ReactでSSRを行いたい人の強い味方としてNext.jsが存在しているわけですが、Next.js 12でもReact 18を通してストリーミングの恩恵を受けることができます（Next.jsではSSR Streamingと呼んでいるようです）。また、厳密にはReact 18とは別ですが、React Server Comp
なぜMozillaはXULアドオンを廃止したのか？（翻訳） - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? （原著：David Teller, 2020年8月20日、CC BY-NC 4.0で公開されている内容の全訳。自サイトとのクロスポストです。） 要約：Firefoxはかつて、XULとXPCOMに基づく偉大な拡張機能の仕組みを持っていました。この仕組みは長い間私達によく尽くしてくれました。しかし、Firefox開発者と拡張機能開発者の両方にとって、メンテナンスコストは増大し続けるばかりでした。ある面では、増大していくコストは、Firefoxをセキュアにしたり、高速化したり、新しい事を試したりするための努力を、少しずつ破壊していきました。ま
Firefoxは危険なJavaScriptに対応しない - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important
Prettier のサイズを減らすテクニック
実は先日リリースした Prettier 2.6 では前のバージョンである 2.5.1 と比べてバンドルサイズが 3MB ほど減っています。 Prettier 2.5.1 のサイズ(20.0MB) Prettier 2.6.0 のサイズ(16.9MB) リリースブログで言及したとおり Prettier 2.6 ではモジュールバンドラーを Rollup から esbuild に移行したので、その影響かと思われるかもしれませんが実はそれだけではありません。esbuild への移行によって減ったバンドルサイズはそれほど大きくはありませんでした。 バンドルサイズが 3 MB 減ったのは泥臭いチューニングをいくつか行った結果なのです。 この記事では Prettier 2.6 で実施したバンドルサイズを減らすテクニックを紹介します。 きっかけ ライブラリのサイズは大きいより小さい方が当然良いですが、その
Intl.Segmenter
const segmenterFr = new Intl.Segmenter("fr", { granularity: "word" }); const string = "Que ma joie demeure"; const iterator = segmenterFr.segment(string)[Symbol.iterator](); console.log(iterator.next().value.segment); // Expected output: 'Que' console.log(iterator.next().value.segment); // Expected output: ' ' Constructor Intl.Segmenter() Creates a new Intl.Segmenter object. Static methods Intl.Se
JavaScriptのIntl.Segmenterで文章の意味分割を行う
コンピュータ上で文字列を扱う時、データ上は単にコードユニットの羅列でしかなく、そこに単語や文としての意味合いはありません。 しかし我々は人間であり、単なる文字列ではなく文章として処理したい場合があります。そんなとき、 Intl.Segmenter が役に立つかもしれません。 文章の分割と仕様の標準化 プログラムを書く上で、文字列の処理、というより「文章の処理」をしたくなることがしばしばあります。文章というのは単語や文で構成された、単なる文字コードの連続ではなく、人間的に意味を持つ単位が連続したものとなります。 今まで文字列の意味的な分割は Intl.v8BreakIterator を用いて行っていました。これはChromeやNode.jsで使用されているV8エンジンの独自の仕様であり、一般的な物ではありません。なおかつNode.jsでは意図的に無効化されています。 Intl.v8Break
Web パフォーマンスとプロダクト KPI の相関を可視化する話 2022ver - ドクターズプライム Official Blog
@1000ch (id:hc0001) です。技術顧問業としては広報周りの戦略を考えていることが多いのですが、今日はエンジニアリングの話です。 ドクターズプライムのプロダクト開発の中でも、パフォーマンス上の課題を発見して改善に取り組むことがあります。今回は @oinume (id:oinume) さんから 「この辺りの実装が問題になっていそう…」 という相談があったので、私がアプリケーション全体を眺めてボトルネックになっている箇所をいくつかピックアップし修正方針を提案したのですが、 実装を修正する前に 「まずは継続的にモニタリングできる環境を準備してパフォーマンスの前後がわかるようにしましょう」 ということで原点回帰した話です。 Core Web Vitals でリアルユーザーモニタリング パフォーマンス指標とプロダクト KPI の選定 リアルユーザーモニタリングと合成モニタリング データ
Next.jsにおけるSSG（静的サイト生成）とISRについて（自分の）限界まで丁寧に説明する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事では、Web アプリケーションにおけるデータ取得（データフェッチング）やレンダリングに関する各手法について比較・整理することを目的として、特に最近注目度が高まっている **Next.js における SSG（静的サイト生成）や ISR（インクリメンタル静的再生成）、それ以外の手法（SSR、CSR 等）**を具体的なテーマとしてお話しします。 Twitter もやっているのでよかったらフォローおねがいします！ @_thesugar_ 記事内の解説は正確性を期すよう注意を払っておりますが、誤っている部分などがございましたらコメント欄や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Semgrep App Security Platform | AI-assisted SAST, SCA and Secrets Detection
GitHub - nuxodin/dialog-polyfill: "insert and thats it"-dialog-polyfill
