2020年に買って良かったもの
お題「#買って良かった2020 」
iPad Pro + Magic Keyboard
これのおかげで文字とか書くためにMBP開けなくて良くなったのは快適。MagicKeyboardが完全に最高です。この記事ももちろんこれで書いてます。
骨伝導イヤホン
まずはAfterShokz Aeropexを買って使っていた。リモートMTGなどが増えて、ヘッドフォンとかをつけて話すと自分の声が聞こえない結果、声量とかが大きくなってしまうのを避けたいというのが第一。あとはヘッドフォンとかよりも楽で便利と聞いたのが後押しになった。
Aeropexを使っていたところ結構良かったので、マイクが生えていてバッテリーの持ちが2倍になったりしたOpenCommをastさんがクラファンで買うと言ってたので、相乗りさせてもらってゲットした。マイクが良くなって完全に最高。買う前に気になってたマイクが耳に当たらないか問題だけど、それは気にならない。マイクが生えている分マスクとかとは絡まりやすくなった。
今年はあとはリングフィットアドベンチャーとかを買ったくらいであんまり大きい買い物はなかった。
家の自分のスペースがもので埋め尽くされてきたのでもう買える余裕がないというのもある。来年はMacbook Proを買い替えたいという気持ちがある。買ったらお知らせします。
良かった1巻アドベントカレンダー2020完走していました
良かった1巻アドベントカレンダー、少しだけ遅刻もしましたが、完走したのでこっちにも貼っておきます。
1週目の様子はこちら
2週目の様子はこちら
15日目
『SA07』はきらら作品のラブコメで良いやつがあると聞いて教えてもらったんですが、ラブコメというよりは日常系って感じではあったもののキャラも立ってて面白かったです。
16日目
『あなたと私の周波数』は感情をしっかり描いた良作揃いの百合短編集でした。
17日目
プールサイドの香りを感じるような画面と甘酸っぱく淡い恋愛の話とSFです。
18日目
しっかりアクション、しっかり百合。百合姫じゃないと描けないSFアクション絶対読んでください。
19日目
知っているおとぎ話をベースにすることで、こういう風に読者に予想させながら読ませる手法は面白いなと思った。
20日目
[
印刷業界を舞台にしたお仕事マンガ。印刷業界トリビアや、同人グッズ・イベントあるあるなど盛り沢山です。
21日目
ドM女子と女王様かと思いきや、それがドンドン逆転・倒錯する様子がテンポよく描かれていて面白い。
22日目
『響け!ユーフォニアム』にも通ずるような熱量のある音楽部活マンガです。親子や部員との人間関係の描き方も良い。
23日目
これだけなんか書いてたら少し恥ずかしくなってきたので有料にしました…
24日目
川見てるアドベントカレンダーとのクロスポストだったので、川推しで紹介しましたが、ストーリーも非常に良く出来ていて、今年の中でも特に勧めたい作品のうちの1つです。
25日目
キミオアライブを紹介しました。うーん、本当に惜しい……
2020年の良かったマンガまとめは多分年明けくらいに公開すると思います。とりあえず、この25冊はオススメできます。よろしくおねがいします!
ウェブブラウザにバグ報告をするときにやること
このエントリははてなエンジニア Advent Calender の19日目です。
昨日の記事はid:onkさんのクエリパラメータのデリミタに ; を使うこともできる - id:onk のはてなブログでした。
そしてこのエントリはKMC Advent Calendar 2020の19日目でもあります。
昨日の記事は id:zekehampくんのハル研プロコン2020に参加しました - zekeの日記でした。
というわけで、こんにちは id:Pasta-K です。僕は普段主にウェブブラウザを介して動作するアプリケーション(これを指して以下「ウェブアプリケーション」や「ウェブサイト」などと揺れるかもしれませんがほぼ同じものを指していると思ってください)の実装などをして暮らしています。
ウェブアプリケーションの中でも特にフロントエンドと言われる領域を主にお世話することが多いのですが、それに関連して半分趣味みたいな感じのモチベーションで、所謂Web APIと呼ばれるJavaScriptから呼び出せるウェブブラウザのAPIの実装状況を調査したり、ときには身近なウェブアプリケーションで取り入れてみたりしています。
先日はそういう活動を通じて把握していたWeb APIを紹介する『面白Web API 100連発』という発表を社内勉強会向けに行た資料を公開していたりもします。
こういった先行的なAPIはexperimentalな状態のものをCanaryバージョンのウェブブラウザで検証することが多いと思いますが、試しているとバグと思われる動作に遭遇することが多々あります。また、日常的にウェブアプリケーションを開発していると、ある日「何もしてないのにウェブサイトが壊れた?」と思って調査してみるとどうやらウェブブラウザのバージョンアップが原因なのでは?と疑ったりした経験が皆さんもあったりすると思います。
このような状況に直面した場合は、その問題がそのウェブブラウザの問題であるかを確認し、ウェブブラウザの問題の場合は修正されるように報告をする必要があります。僕自身も年に2〜3度ほどそのような状況に遭遇し、ウェブブラウザに対して報告をしています。
そのような経験をもとに、このエントリではChromiumの例を中心にウェブブラウザ起因に依るものと思われるバグに遭遇した際の報告方法やその際に僕自身が行っているちょっとした工夫などを紹介しようと思います。
※ この記事の内容は外部から報告する経験を元に書いたものです。バグ修正や報告に関して感覚的に感じていることを記載していることもあります。もし何か誤りや認識の違いなどがあれば教えてください。また各種説明やURL、スクリーンショットなどは2020年12月18日のものを使用しています。
ウェブブラウザにバグ報告をする前にやること
ウェブブラウザにバグ報告をする前にやることとしては大きく以下があります。
- 再現性のあるものかを確認する
- ウェブブラウザのバグであるかを確認する
- どのバージョンで起きているかを確認する
再現性を確認する
まずは再現性のあるものであることを確認します。この際に再現できるミニマムケースを作っておくとこの後バグ報告をする際にも便利に使えます。
多くの場合、発見された問題は大きなウェブアプリケーションの一部分であると思います。そこから問題を再現できる小さなケースを作成します。experimentalな機能やJSを介したAPIなどは比較的再現方法を作るのが簡易であると思いますが、例えばCSSの問題の場合は適切に親子関係を切り出したりすることになりますが、この辺は気合いで頑張ります。
このときの再現例はウェブブラウザの開発チームにも提示することになるので、適当なPublicな場所に置いておくと良いでしょう。自分の場合は一番雑にやる場合はGithub PagesにべたっとHTMLを置いたり、ちょっとSASSとかで書きたい場合はCodePenを使うことが多いです。最近ではGlitchに置いてあるのもよく見かけます。
再現性を確認するミニマムケースを書く際にnavigator.userAgent
をどこかHTML内の適当なところに出力しておくとスクリーンショットなどを撮るときに自然とバージョンやOS情報を含めることが出来るので個人的にはよくやっていてオススメです。
またこの再現性確認のときにブラウザ拡張による影響を取り除きたい場合、プライベートブラウジングを用いることがあると思いますが、プライベートブラウジングは拡張機能の一部が有効になっているケースがあるので、ゲストモードを使うとそれらの影響を完全に取り除くことが出来ます。また個人的にはゲストモードを使うとスクリーンショットを撮影する際にブックマークツールバーに気を配らなくて良くなるのも好印象です。
バグかどうかを確認する
そして再現した振る舞いについて、次はそれが本当にウェブブラウザのバグであるかを確認する必要があります。関係するAPIの仕様を参照して確認できるのが一番ですが、そもそもちょっと手慣れてないといきなりDOMやHTMLなどの仕様から振る舞いを把握するのはまぁまぁ難しいことがあったりもします。その場合はMDNで軽くドキュメントを確認したり、他のウェブブラウザと比較することを通じて、正しい動作を把握し、そのウェブブラウザでの問題であることを確認します。
他のウェブブラウザでも実装されている振る舞いの場合、他のウェブブラウザとの比較はこのあとの報告時にも項目として求められるので確認しておくと良いでしょう。
どのバージョンで起きているかを把握する
どのバージョンで起きているかを把握する必要もあります。BrowserStackが使えると過去に遡ってメジャーバージョンを確認することも出来ますが、そうでない場合は身近な未アップデートの人に見てもらうというテクニック(?)も良いでしょう。このような作業を通じて最新または最近のアップデートの影響の有無を確認しておきます。
また、BrowserStackなどを使える場合はどのバージョンまでは問題が無く、どのバージョン以降で問題があるか把握しておくと報告時にスムーズになります。このバージョンの比較は個人でやるのは難しい場合もあるので、最低限発生しているバージョンさえ分かれば厳密に把握する必要はないと思って大丈夫です。Chromiumの場合はバージョンを比較して動作確認が必要なissueにはNeeds-Bisect
ラベルが付与されて、Chromiumチームの人がBisectな検証をしてくれます。ちなみに僕自身はやったことはありませんが気合いがある場合はこのBisectをするためのツールも公開されています。
僕自身が報告したIssue でChromiumのBisectが行われている様子。
バグ報告を行う
ここまででバグが存在しているということの確認とそれを理解するための情報はほぼ出揃ったので、実際にバグ報告を行うことになります。主要なウェブブラウザエンジンはそれぞれオープンなissue trackerがあるので、対象となるウェブブラウザに応じて選択してください。
- Chromium: https://bugs.chromium.org/p/chromium/issues/list
- ちなみに https://crbug.com というドメインからリダイレクトされます。
https://crbug.com/999913
のようにIssue番号を付けることでそのIssueのページにも飛べるので便利です。
- ちなみに https://crbug.com というドメインからリダイレクトされます。
- Firefox: https://bugzilla.mozilla.org/
- Webkit: https://bugs.webkit.org/
と、ここまで来たらいきなりバグ報告を投稿する前に既に報告済みの問題でないかさっと見ておきましょう。FirefoxのBugzillaの場合、新規バグの登録時にサマリーを入れると検索できる画面が出てくるので、それを利用して探すと便利です。
既存のIssueがあった場合はそのIssueのwatch listなどに自分を追加すると良いでしょう。Chromiumの場合はIssueページの左のサイドバーの上部にある星マークをクリックすると通知を受けることが出来ます。Firefoxの場合はPeopleセクションのCCに自分のアカウントを入れることで追加できます。また、多くの場合はコメントを残すことでその後通知を受けられることもあります。同じ現象に困っているケースが世の中に他にもあることはバグ修正の優先度や再現性などにも貢献できると思うので、自身のウェブサイトで問題が起きているということやどのバージョンで遭遇したかなどをコメントでお知らせしてみてください。
僕自身が報告したCSSに関するバグに中の人からWe haven't seen any reports of this in the wild
というコメントが付いた直後にwe actually started to experience this in the wild 4 weeks ago, but didn't report
というコメントが付いて、なるほど他にも遭遇している人居たんじゃんと思ったことがあります。
既に同様のバグ報告が見つからなければ実際にバグ報告を投稿していきましょう。このエントリではChromiumを主な例としてバグ報告をする様子を紹介します。
バグ報告を行う
まずはアカウントが無い場合は作成しましょう。Googleアカウントで認証することでアカウントを作れます(MozillaのbugzillaはGithubで認証が出来ます)。
New Issueボタンを押すことで新しいバグ報告を登録できます。このときウェブブラウザのバージョンなどが自動で埋められるので、実際に問題が発生している環境でアクセスすると少し楽ができます。
既知の問題でないかは検索済みなので、該当する場所にチェックを入れます。
Nextを押すと報告者の属性とどこで起きた問題かを選択します。
この記事を読んでいる皆さんの多くは自身の開発するウェブサイトに関する問題を報告するのが大半でしょう。その場合は Web developer
を選択してください。その他のサイトで発見した場合やChromiumのUIなどについて報告する場合はEnd user
を選択します。
次に何についてのバグ報告かを選択します。ここまでで言及してませんでしたが、開発者ツールやInspectorなどについての報告もここで可能でその場合はDeveloper Tools
を選択してください。それ以外の場合は API
を選択します。例えば navigator.permission.query
についてのバグを発見した場合でも JavaScript
ではなくAPI
を選択してください。ここでのJavaScript
はインタープリターに関する問題を取り扱う選択肢になります*1ので、API自体に問題がある場合やCSSやHTMLなどの振る舞いに問題がある場合は全てAPI
を選択することになります。
ここではAPI
を選択したとして先に進みます。他の選択肢の場合もAPI
を選択した際のフォームの一部が表示されているという感じのはずです。
3つ目の画面のフォームに実際にバグ報告を記述していきます。
文言に悩んだ場合は僕は他のIssueからそれっぽい表現を持ってきたりもしがちです。大まかな表現などに関してはMDNにオススメのガイドラインが掲載されているので参考にするのも良いかと思います。
Please enter a one-line summary
ここは1行でどういうバグかを記載します。要するにここがIssueのタイトルになります。参考になるか分かりませんが僕自身が過去に投稿したバグだとこういう感じです。(英語がbrokenなのは大目に見てください…)
Sizing <img> element is broken / regression
Chrome will crash on Portals.activate()
- 直球でAPI名をそのまま書いてる
FontAccess: metadata.fullname including CJK Character is garbled
- API名を先頭に書いてみている
Do you have a reduced test case?
テストケースがあればここでアップロードします。CodePenなどにある場合はURLをこの後記載すればいいので、ここではNo
を選んで大丈夫です。
Does this feature work correctly in other browsers?
Experimentalな機能でChromiumにしか実装されていない場合はNot sure
で大丈夫です。他のウェブブラウザで実装されていて、それらの振る舞いがChromiumと異なり正しく実装されている場合は Yes
、他のウェブブラウザでもChromiumと同じ振る舞いの場合はNo
を選択してください。
Steps to reproduce the problem:
ここで作成したミニマムケースを使用した再現方法を記載します。1.にアクセスする先を書いて、その後にクリックするべきものなどがあれば2や3に記載していきます。また、Chromiumのflagを有効にした場合のAPIなどについては念の為どのflagを有効にするかを記載しておくと良いです*2。
What is the expected behavior?
ここには期待される動作を書きます。ミニマムケースがある場合はその結果がどういう振る舞いをしたりレンダリング結果になるべきかを記載すると良いでしょう。
What went wrong?
ここには現状何が起きていてそれがどのように問題があるかを記載します。
ここの項目の下にファイルを添付する箇所があるので、ミニマムケースの様子のスクリーンショットがあればここでアップロードしましょう。またこのファイルアップロードには動画を添付することも出来ます。必要に応じてスクリーンキャストをアップロードしても良いでしょう。
その様子を表示しているウィンドウとchrome://version
を横に並べることで、バージョン情報などを同時に伝えることができます。chrome://version
には各種バージョン情報に加えてコマンドラインオプションが表示されていて、ここからどのようなFlagが有効になっているかという情報などを提供することが出来ます。
Did this work before?
過去のバージョンで正しく動作していたことを認識している場合はYes
を選びます。把握してない場合はNot applicable or don't know
を選びます。
Any other comments?
他になんかコメントがあればここに書きます。追加情報でHi-DPIで再現するなどの補足情報もここに書くと良いでしょう。
以上で送信してバグ報告は完了です。初めはステータスがUnconfirmed
ですが、そこから確認されるとステータスが進んだりアサインが行われたりします。その後必要に応じて追加の情報を求められたりすることもあるかと思いますので、やりとりをしていきます。
まとめ
Chromiumを例にウェブブラウザにバグ報告をするときにやることについて書いてみました。みなさんがウェブブラウザに問題を報告するときのハードルが少しでも下がると幸いです。FirefoxやSafariの場合も順序などは異なりますが概ね同じ内容を記述していくことになると思います。以前はFirefoxの報告時にComponentを選ぶ必要があったりしましたが、現在ではそこは省略されていたりなどバグ報告のハードルが低くなるように工夫されている感じを受けています。
また日本語やマルチバイト文字などに関する問題は意外と報告する人が少ない印象を持っています。Twitterなどで話題になっていても誰も報告していなかったり、Issueにはなっているがコメントなどは付いていないみたいなのを見かけることもあるので、そういったときもバグトラッカー上でやりとりすることでウェブブラウザの開発チームに熱量や問題の影響について伝えることが出来ます。
もし皆さんがこの記事を読んでもウェブブラウザのバグ報告に躊躇することがあるなら、お気軽に@pastakにお声がけください。お手伝いできることはさせていただきます。
そしてそれぞれのアドベントカレンダーの明日20日目の担当は
です!よろしくおねがいします!!!
*1:また、JavaScriptの問題の場合はChromiumよりもV8の方が適切な場合もありますね
*2:ExperimentalなAPIの場合、利用するにはflagを有効にするのが暗黙的に共有されていると思いたいですが、flagを有効にして試してくれと後のコメントに書いたことが何度かあります… bisect などの初動対応してくれる人が開発者ではなかったり該当機能を知らない人であることも多いので、一見自明なことも明記して手順通りにやれば再現できるようになっているとありがたいです とのコメントを頂いたので紹介しておきます。なるほど、目についた方がやってくれているという世界観なのかぁ
masawadaさんに世界的に有名なあの人からメッセージが届きました!!!!!!!!!
この記事はmasawada Advent Calendar 2020の15日目の記事です。
昨日はmasawadaさんのお父様であるid:wabysprgさんでした。
命名の秘密良かったですね。「英俊(えいしゅん)」だったら、masawadaカレンダーはこの世になかったと思うと感慨深いです。ちなみにぼくの名前は父親がサッカー好きだったからことから音は決まっていて、漢字は字画とかから決めたという話をほんのり聞いた覚えがあります。
それでは、本日のコンテンツです。
まずはこちらの動画をご覧ください。
動画を見た人向け情報はここをクリック!!!!!
id:masawada さんは新型コロナウイルスにも負けず2020年も良い子にしていたのでサンタさんからメッセージが届きました。良かったですね。
この動画はfiverr.comというクラウドソーシングサイトで25USDで作成してもらった動画です。思ったよりもmasawadaの発音が機械的でしたね。
試してみたい人向けに20%オフが手に入る招待リンク置いておきます。ちなみにこの動画は以下から注文できます。
Your Access To This Website Has Been Blocked
他にも泥酔サンタやジャングルからのクリスマスダンス、ジャマイカのビーチからのメッセージなどが候補にありましたが、コンプライアンス的なものやその他諸々を吟味しまして、サンタからのメッセージとなりました。
ネタがなかったら僕が1人でやっている良かった1巻アドベントカレンダーでmasawadaさんにオススメの漫画を紹介してお茶を濁す予定でしたが、無事埋まって良かったです。masawadaさんということにかこつけて僕があんまり読まないきららの作品をオススメしようと画策していました。そちらはそちらで投下しましたので、こちらもお収めください。
masawadaアドベントカレンダー、明日はid:Windymeltさんです!
良かった1巻アドベントカレンダー2020第2週目の様子です
ちょっと遅刻しつつもあるけど、なんとか2週目も乗り切って折り返しました。
先週の様子はこちら
または
などでどうぞ。
8日目
『放課後のサロメ』は押見修造作品を彷彿とさせる思春期の危うさを上手い絵と表現力で描いているなという印象です。
9日目
ゴリラスロウ(a.k.a. 玉置勉強)先生自身の経験もふんだんに詰め込まれた青春ロックバンド漫画『ツインズシング』を紹介しました。
10日目
言葉を尽くす必要のないスポーツものの傑作の予感がする『メダリスト』は皆さん読んでください。
11日目
『いなりこんこん恋いろは』のよしだもろへ先生の最新作は過去の恋を追想する少しノスタルジックな雰囲気の作品『あさこ』です。
12日目・13日目
12日目と13日目は連続で今年僕の中でスマッシュヒットだった飯田ヨネ先生の作品を2作紹介しました。
14日目
14日目は『君のことが大大大大大好きな100人の彼女』がラブコメとして如何に素晴らしい仕組みかを書きました。
1日以上は積まないようにこの調子で頑張っていきたいと思ってますが、少ない日数にもなってきたので、どれを載せるか結構悩みつつもあります。もしかしたら延長線するかも?(多分、個別記事は書かずに今年の漫画まとめに書くことになると思うけど)
よかったら、FANBOXで支援お願いします。