JavaScript 長いループ 分割 - hitode909の日記
ブラウザで長いループや、重い処理をともなうループを回したいとき、同期的にJavaScriptを実行するとメインスレッドがブロックしてしまうので、ちょっとずつ細切れに分割して実行したい、ということがある。 昨日久しぶりに書いたら新たなパターンと出会ったので、これまでにどう書いてて今回どうなったかメモ。 setTimeoutする 以前(10年前とか)はこんなのをよく書いていた。 itemsがでかいArrayで、console.logがすごく重い処理だとして読んでください。 function iterateHeavyTask(items) { const startAt = new Date(); while (items.length > 0 && new Date().getTime() - startAt < 10) { console.log(items.shift()); } if (
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
スナップショットテストのうれしさ - hitode909の日記
前提として Viewは状態の写像であるということがわかってきていて、状態さえ与えればViewの状態が再現される どういう操作をすると、どの状態にたどり着くか、はアプリケーションのドメインの知識としてテストすればよい ところでViewをTDDで書いていく人はあんまりいなくて、試行錯誤しながら作っていく人が多いのでは ということをふまえると、スナップショットのうれしさは ああしてこうして、という準備を経ずに状態ごとのテストを書ける 状態の写像である世界観と相性が良い サーバーサイドでこのようなデータをストレージに入れて…月をまたいだらこの操作をして…みたいなデータをセットアップしていくという考えからは切り離せる 実装が完成した段階で、これを正とする、と表明する流れで書けるので、アサーションを手書きしなくてよい この状態のときのViewはこうです、と言ってしまえば以降それがテストとして動く TD
Creating Documentation in an Agile Scrum Environment - hitode909の日記
普段メンテナンスしているプロダクトの仕様について、うまいストック情報を作れていないという課題感があって、世間のノウハウを知ろう、とKindleで適当に買った本を読んでみた。 スクラムチームに所属しながら製品のコンシュマー向けのドキュメントを書くためのテクニカルライティングの本。 読書メモ アジャイル開発について学んでもライターについての記述はなく、ステイクホルダーにも入っていない 包括的なドキュメントよりも動くソフトウェアを、という宣言があるけど、コンシュマー向けのドキュメントが不要になるわけではない ドキュメントを書かずにプロダクトを作り終えたり、完全にプロダクトを作り終えてからドキュメントを書くことができるプロダクトも存在する メールアプリのドキュメントを読んだことがありますか? スクラム環境でドキュメントを作るには2つのパターンがあり、デベロッパのスクラムチームに所属するパターンと、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
