用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R

はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

作った。 Qronoの特徴 🎨 タイムゾーンとロケールの対応を捨てた軽い日付時刻ライブラリ。 他のライブラリはタイムゾーンとロケールに対応するためにコードベースが巨大になったり使い方が複雑になったりしがち。 ロケール対応はECMAScript® Internationalization APIを使うだけで良い。 ほとんどの場合、クライアント環境のタイムゾーンにだけ対応できれば十分。 Luxonによる説明は、まさにその核心をついている。 Don't make servers think about local times. Configure them to use UTC and write your server's code to work in UTC. Times can often be thought of as a simple count of epoch millise

WebRTCのSDPについて、WebRTC Meetup Tokyo #10 にて説明した際の資料です。 音声つき解説はコチラから： https://www.youtube.com/watch?v=cUquMAf9Ayw

現在ベンチャー事業で、日本-タイでビデオチャットを行ってます。 2国間で利用で、下記の現象について考えられる可能性をご教示いただきたいです。 【現象】 映像は非常にきれいな画質(高ビットレート)で受信できていながらも、 音声がとぎれとぎれになってしまっている。 【状況】 今のところ1対1なので、ビデオ接続自体はPeer.callで繋いでいます。 しかしpeer_idを取得したい関係で、ビデオチャット中はチャットルームも使っています。 近々getStates()で詳細情報を取得するように予定していますが、 現状はその情報がない中で推測する必要があります。 回線速度が遅い場合は映像・音声ともにビットレートを下げることになるかとは思いますが、 映像が非常にきれいなので、回線速度以外の可能性があれば考慮に入れたいです。 【その他の状況】 1対1callのほうか、チャットルームのほうか、急に接続が切

aspect-ratioを利用しない場合は、以下のように、beforeにpadding-top: 56.25%;を指定し、親や子の要素にpositionを設定するという面倒な対応をしないといけない .parent { position: relative; width: 100%; &:before { content: ''; display: block; padding-top: 56.25%; /* 16 : 9 */ } .child { position: absolute; top: 0; left: 0; } } min(), max(), clamp() 便利css関数 例えば以下のようなコードをminを利用すると1行で置換可能 追記：minとmaxの認識が逆になっていました。。申し訳ありません。 ↓この様な認識が正しいですね。 min('基本幅', '最大幅') max

先日アップデートされたSafari 15とSamsung Internet 15により、すべてのエバーグリーンブラウザでaspect-ratioプロパティがサポートされました。 ※エバーグリーンとは、最新版に自動アップデートされるブラウザのことです。 aspect-ratioプロパティを使用することで、レスポンシブ対応の画像をアスペクト比を維持したまま簡単に実装できます。 CSSでアスペクト比を実装する今までとこれからの実装方法を紹介します。 CSS ways to Create Fixed Aspect Ratio aspect-ratioプロパティとは 1. Padding Hack 2. Viewport width solution 3. aspect-ratioプロパティ デモ aspect-ratioプロパティとは aspect-ratioプロパティは名前の通り、アスペクト比を

For every successful technology, there is a moment where its time comes. Something happens, usually external, to catalyze it — shifting it from being a good idea with promise, to a reality that we can’t imagine living without. Perhaps the best recent example was what happened to the cloud as a result of the introduction of the iPhone in 2007. Smartphones created a huge addressable market for small

Modern web technologies provide ample ways to work with video. Media Stream API, Media Recording API, Media Source API, and WebRTC API add up to a rich tool set for recording, transferring, and playing video streams. While solving certain high-level tasks, these APIs don't let web programmers work with individual components of a video stream such as frames and unmuxed chunks of encoded video or au

概要 WebCodecsにて登場したAPIであるVideoTrackReaderはVideoTrackからVideoFrameを取得することができるようになるクラスです。 ですが、MediaStreamTrackProcessorという別のAPIが良いという内容のChromiumのissueやGitHubのissueが存在し、M91でVideoTrackReaderは削除されるようです。そのため、新しいAPIを使って書き換えてみます。 具体的にやること 現在のVideoEncoderがチャンクを生成するまでの流れは以下のとおり navigator.mediaDevices.getUserMedia()でカメラからMediaStreamを取得 getVideoTracks()でMediaStream内のVideoTrackを取得 new VideoTrackReader()でVideoTra

はじめに ブラウザのリアルタイム通信の仕組みとしてWebRTCがありますが、より細かい制御を行うことができるWebCodecsやWebTransportといった仕様が提案されれています。今回はその関連仕様であるVideoTrackReaderや、さらに新しい仕様であるMediaStreamTrackProcessorを映像合成/映像加工に使う例を取りあげます。 映像加工のこれまで Canvasを使った映像加工 ブラウザでの映像加工は、従来は次のような流れになります。 (1) 映像を<video>要素に表示する (2) <video>要素から、1コマ分の静止画を<canvas>要素に転写する Canvasからcontextを取得し、context.drawImage()を利用する (3) <canvas>要素上で、追加の描画、画像の加工を行う ここで (2)-(3) を繰り返すことで、<ca

フォーム要素のチェックボックス・ラジオボタン・レンジスライダー・プログレスバーのカラーを簡単に変更できるCSSの新しいプロパティ「accent-color」の基礎知識と使い方を紹介します。 CSS accent-color by Adam Argyle, Joey Arhar 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 CSSの新しいプロパティ「accent-color」 「accent-color」にサポートされている要素 コントラストの確保 他の要素のカラーを変更するCSS 今後の可能性 CSSの新しいプロパティ「accent-color」 現在のHTMLフォーム要素は、カスタマイズが難しいと言われています。カスタムスタイルをほとんどまたはまったく使用しないか、inputのスタイルをリセットして一から作り直すかのどちらか

前書き この記事は翻訳記事になります。 近年、JSで書かれてるプロジェクトをTSに書き直すことが業界内で一種の風潮になって、 この記事で敢えてTSからJSに戻そうとする事例が目新しいと思ったので、翻訳してみました。 出処: 5 reasons why Deno will stop using TypeScript - StartFunction 原作者: eliorivero Denoの紹介: V8 JavaScriptエンジン及びRustプログラミング言語に基づいた、 JavaScript及びTypeScriptのランタイム環境である。Node.jsの作者であるライアン・ダールによって作成され、セキュリティと生産性に焦点を当てている。 --ウィキペディア 最近、Denoが内部コードでTypeScriptの使用を停止することを指摘する文書が浮上しました。 言及されている問題には、TypeS

CoW とは CoW = Copy-On-Write [ CoW - Wikipedia ] プロセスのコピーを作成 (fork) するとき、書き換えることのないメモリページは、両方のプロセス（元のプロセスと生成されたプロセス）で共用し、書き換える可能性のあるメモリページは、新たなメモリページを割り当ててコピーを作成する 鉄則 fork するプロセスを生成する場合、親子間でメモリ共有した方が良い forkする前に確保したメモリ領域は子プロセスとの間で共有される 共有されたメモリ領域に対して書き込みを行うと共有は解除（コピー）される forkした後に確保したメモリ領域は子プロセスごとに確保される（共有されない） どのプロセスでも同じように参照するだけの(書き換えない)データは、fork前に確保して共有した方が全体でのメモリ使用量を小さく保てる。つまり、fork 数を多くしたりできる。そして、

Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に

しかし、実際に M92 がリリースされてからは、この機能が壊れたことによる影響が多数報告されていたため、実装者が想定していた以上に影響はあったといえるだろう。 他のブラウザの反応 実際にロールアウトしたのが Chrome/Edge であったため、いつものように「また Google が勝手にやっている」と思う人もいるようだが、実際には他のブラウザも Positive を表明している。 Firefox: https://github.com/whatwg/html/issues/5407#issuecomment-606417807 Safari: https://github.com/whatwg/html/issues/5407#issuecomment-760574422 また、この合意が取れているため、既に仕様にもマージされている。 Add early return to JS dia

Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別

2021年7月27日 DMM meetup #31 での発表内容です