Markup from hellA collection of bad practices in HTML, copied from real websites. skip code sample<label for="textinput">First name</label> <input type="text" id="textinput" aria-label="First name" placeholder="First name" title="First name">
MySQLの order by と index の仕組みがわからなくなったので調査。 前提の自分の仮定 MySQLは降順インデックスをサポートしないので order by desc にインデックスを使用できない (user_id, point)という複合インデックスがあれば、where user_id = ? order by point ascというクエリはインデックスを最大限に使用できる 準備 MySQLのバージョンは 5.1.61 CREATE TABLE `sample` ( `id` int(10) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL, `point` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `i1` (`user_id`,`point`) )
TL; DR (要約) Jestの実行時オプション(CLIオプション)と、テストメソッド(it,test)の書き方で、並行処理と順番(逐次)処理をコントロールする方法について、以下の4パターンを図で説明します。 複数のテストファイルを並行処理し、ファイル内のテストは順番に実行する 複数のテストファイルを順番に処理し、ファイル内のテストも順番に実行する 複数のテストファイルを並行処理し、ファイル内のテストも並行実行する 複数のテストファイルを順番に処理し、ファイル内のテストは並行実行する はじめに Jestでは、パフォーマンスのために複数のテストファイルが並行に処理(テスト)されます。しかし、並行処理が思わぬエラーを生むこともあります。 たとえば、データベースへ接続するテストやpuppeteerを使ったE2Eテストなど副作用を生じさせるテストの場合、テストの書き方や実行タイミングによってはテ
経緯 社内でのプロジェクトマネジメント手法について標準となるものが欲しいという声があったので、半年以上前から暇を見て取り組んできている(あまり宣伝してきてないけど、2012年に今の会社に入ってから社内にアジャイル開発を普及させる活動を細々と続けてきているのです)。 3月くらいのときに自分がドキュメントをつくってみたものも、どちらかというと読み物という雰囲気のものになっていてそれを参照しながらプロジェクトマネジメントをしていこうというものにはなってなかった。 しばらくそのまま放置してしまったのだけど、その後6月頃に認定スクラムマスター研修を受けて熱をもらってもう一度やるぞ!という気持ちになったりしたこともあって、反省を踏まえてテンプレートとなるようなドキュメントの作成を改めてすることに決めた。 ちょうど6月末ごろに社内の開発合宿があったのでそこで協力者を募ったところ、2人が協力を申し出てくれ
はじめに 「テストが大事」 これは生産性と品質を高めるための基本的な考え方です。なので 「テスト書かないと」 ってことはみんな同意するのでUnitTestらしきものが書かれてることは多いのですが、役に立たなかったりむしろ有害ですらあるテストがあふれているプロジェクトもあります。作った人に罪は無いのですが、頑張ったのに悪い方向に行ってしまうのはもったいない これはユニットテストを有効活用するための最低限のルールが守られてないためです。あまり学校で習う類のものでもないかもしれないですし、大事だと思うので個人的な見解をまとめておきました。 ポータビリティを大事にする 繰り返し実行できるように作る Unit Testですべての自動テストをしない モックやスタブを過度に使わない ひとつのテストケースにはひとつの観点しか検証しない テスト内容が分かる名前をつける ログや標準出力は極力出さない Java
Goが未使用のパッケージインポートの記述をエラーにするという挙動は多くの非難を浴びました。 「コンパイルエラーでなく警告にすべき」 または 「コンパイルオプションで選べる様にして欲しい」 というような意見はたくさん寄せられましたがGo開発コアメンバーはこれらの要望に応えることはありませんでした。その理由を解説します。 Goの依存解決のアプローチ Goの依存ツリーはコードの中に記述します。これはメジャーなパッケージマネージャとは異なる手法です。 多くの処理系では依存解決に必要な情報を言語仕様には含めず、別途ファイルに依存情報を列挙して記述しておき、それらの情報を辿ることで依存ツリーを構築しそのツリーに基づいて依存を解決するというアプローチを採用しているものがほとんどです。 Goは依存解決に必要な情報をコードの中に記述するというレアなアプローチを採りました。 ESモジュールのアイディアに近い考
概要 Firebase Authentication はユーザー認証に関するサービスです。様々な認証方式をサポートしており、活用することで認証に関する実装を大きくサボることが可能になるものです。 一方で、パフォーマンスには難点があることが知られており、firebase auth 遅い - Twitter 検索 / Twitter を見ると、いくつかの人が遅さについて言及しています。 そこで、パフォーマンスについて測定したので、その結果をまとめます。 環境 実験を行った環境は以下の通りです。ネットワークによる影響を調べるために、2 つのリージョンで実験を行いました。 NodeJS v14.12.0 firebase 7.21.1 firebase-admin 9.2.0 EC2 インスタンス t2.micro リージョン ap-northeast-1/us-east-1 コード odan-s
転職先探してます(簡易版).md 転職先探してます(簡易版) 簡易版です。詳細版はそのうち作るんじゃね。たぶん。 転職先探してます。フロントエンドエンジニア探してる会社ないですか。 連絡先 kotofurumiya@gmail.com あるいはTwitter( https://twitter.com/kfurumiya ) のDM お前 is 誰 ハンドルネーム: 古都こと GitHub: https://github.com/kotofurumiya Qiita: https://qiita.com/kfurumiya Twitter: https://twitter.com/kfurumiya ブログ: https://sbfl.net/blog スライド: https://slides.com/kotofurumiya ブログはこの辺りが有名記事だと思う。 JavaScriptの「コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く