squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
Google、脱Cookie技術「FLoC」開発を停止し、新たな「Topics」を発表
米Googleは1月25日（現地時間）、2021年3月に発表したサードパーティーcookieに代わる技術「FLoC」（Federated Learning of Cohorts）の開発を停止し、新たに「Topics」と呼ぶ技術のテストを年内に開始すると発表した。 同社は、ユーザーのWebプライバシーを改善しつつ適切な広告を表示するための取り組み「Privacy Sandbox」の技術としてFLoCを開発してきたが、ユーザーを特定できてしまう可能性を指摘されたり、この取り組みが独禁法に違反する可能性があるとされたりと、批判が高まっていた。 Googleは「Topicsは、FLoCのテストからの学習と幅広いコミュニティからのフィードバックに基づいて、FLoCに代わるものとして開発する」と語った。 Topicsの大まかな仕組みはこうだ。Webブラウザが、ユーザーのWeb閲覧履歴に基づいて、そのユ
僕が考えたChrome拡張機能を作るときのデザインパターン
最近いくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします。 Image collector extension goo.gl URL Shortener extension mixi Check button extension Semantic inspector これだけ作ってると、何となく自分でのChrome拡張機能を作り出す際のデザインパターン・・・っていう大それたものじゃないけど、ようはテンプレが確立されてきます。全く褒められない書き方をしているかもしれませんが、ここでそのテンプレ達を晒しておこうかな、と思います。 manifest.json まずはChrome拡張機能の要であるマニフェストファイルです。これは誰が書いてもさほど変わらない記述内容となるでしょう。 { "manifest_version": 2, "name":
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
