Node/Deno でソースコードにテストを書く
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
ぼくのかんがえたさいきょうの useState + useContext よりも Redux のほうが大抵勝っている
「Redux は学習コストが高い」などと言って useState（または useReducer）と useContext を組み合わせ 劣化 オレオレ Redux を作ってしまうのを見かけます[1]。よくないことだと思いますが、気持ちは非常にわかります。Redux エコシステムがそういう気持ちにさせてしまう部分は大いにあります。 Redux は それ単体なら 学習コストは useReducer + useContext と同等であることを示してこの気持ち（誤解）を解かしつつ、なぜそういう気持ちになってしまうのか考察してみます。 まず useState と useReducer の違いを押さえておく 知っている方はスキップしてください。 useState と useReducer は本質的には同等で、どちらもコンポーネントにステート（状態）を持たせる役割があります。次のようなカウンターアプリ
PVS‑Studio | Posts: articles
To get the licence for your open-source project, please fill out this form
JavaBeansって言葉に煩わされない - 日々常々
JavaBeansって言葉を目にして、ふと検索してみたらあまりに酷かったので書いておこうかと。対象は「JavaBeansってなんだろ？」と思ってしまった初学者さん。でもそんな人って私のブログ読むんだろうか…… 今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結と+演算子について整理しておく みたいな感じ。 ShortAnswer JavaBeansを学ぶ必要はありません。JavaBeansと説明されているものの多くは、JavaBeansの名前を借りた独自の物体です。 長い説明 「あまりに酷い」と「要らない」だけだと流石にアレなので、仕様を斜め読みしながら説明していきます。あ、EJBには触れません。まぜるなきけん。 仕様について JavaBeans仕様としてげったーせったーがーとか、こんすとらくたがーだとか、しりあらいざぶるがーだとか。よく見聞きするのだけど、仕様って読んだんだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
