Chromeの拡張機能(プラグイン)を自作で作ってみたので、色々書く。 やってみたこと やった結果 動かせたの? 開発した時の環境 ハマりポイントと解消方法の一覧 そもそも拡張機能を作るために必要な構成や作るべきファイルがわからない 開発成果物のそれぞれの役割がよくわからない 自作したChrome拡張機能の取り込み方法がわからない ツールを修正した時の取り込み方法がよくわからない service_workerが動作しない原因がわからず、デバッグもできない content_scriptsに指定したcssの参照先画像(URL)にアクセスできない 拡張機能アイコンクリック時の動作が定義しても動かない service_workerで外部jsが使えない 自作した拡張機能用HTMLでonclick属性が動作しない Local Storageから読み込んだ情報が想定外にObjectになった Javasc
数年ぶりにChrome拡張のつくりかたを調べた。 本当に何も分からなかったので、Twitterで「2022年にChrome拡張つくりたかったら何見て学べばいい?」とつぶやいてみたところ、何人かの人が教えてくれた。教えてもらった中から幾つかのリンク先を紹介するような形で記述していく。 Create a Vite-React Chrome Extension in 90 seconds - DEV Community 2022年時点だと比較的新しめのフロントエンド向けツールであるviteと、viteのChrome拡張向けプラグインである@crxjs/vite-pluginを使ってChrome拡張をつくってみよう、という記事。今回自分は主にこれを参考にしながら開発を進めた。Reactと言っているが、自分のChrome拡張ではUIは存在しなかったので、Reactに関する部分は読み飛ばして、vite
The bundler configuration for a Chrome Extension can be pretty complex. When I started making Chrome Extensions, they were small projects for clients who wanted to automate a task. I was starting a new Chrome Extension almost every week, and it took too much time to configure a new project. Then I thought, "We already have a manifest; why do we need more config files?" That's the idea behind CRXJS
星野佳路 @skier1960 各地の観光入込数の対昨年の報道が多いが、本当に知りたいのは対2019年比だ。しかし、2019年GWは各地で混み過ぎていた。日本では大型連休に観光需要が集中し過ぎるため、渋滞、高価格、満足度減少などを起こしている。観光先進国がやっているような需要平準化政策が必要であると改めて感じる。 2022-05-04 14:46:30 星野佳路 @skier1960 観光客の皆さまから『いつも渋滞だから道路拡充すべきだ』というご意見をいただきますが、今日のように大渋滞するのは年間20日程度。大半の日はガラガラなのです。そういう意見から道路を増やすのは効率の良い公共工事ではないと考えています。問題は需要集中する休暇制度にあります。 2022-05-05 21:46:14 星野佳路 @skier1960 欧米の観光需要分散策は、地域ごとに休暇をずらす方法だ。フランスでは春の大
B! 2 0 0 0 MacでHomebrewを使って 最近良く使われる ミーティングアプリのZoom をインストールすることが出来ますが、 以前までこのCaskはzoomusという名前でした。 これが先日zoomというCaskに名前変更されました。 zoomus to zoom zoomus v.s. zoom Zoomブームで間違える人続出で変更 zoomusからzoomへの変更方法 Homebrewのアップデート(brew caskがobsoleteに) zoomus to zoom MacでHomebrewは自動でbrew upgradeとかcronで行っているのですが、 その際にZoomが上手くアップグレードされてなくて消えてしまっていて、 でもCaskは登録されたまま、ということで再インストールしてみようとしてみると $ brew reinstall zoomus ==> Ca
B! 2 0 0 0 MacでHomebrewを使ってパッケージを管理していると インストールした覚えの無いパッケージも大量に入っている事がありますが、 それはインストールしようとしたパッケージが必要とするモジュールなどを含むパッケージを自動でインストールしてくれているからです。 パッケージのリストを管理したい時にこういった依存先のパッケージも全て記録していくと 後々元のパッケージが要らなくなっても残ってしまったりします。 Homebrewでは最近パッケージのインストール時に直接インストールされたのか、 依存関係によってインストールされたのか確認出来る様なフラッグが導入されました。 installed_on_request/installed_as_dependency brew-fileでの取扱 leavesとの違い 必要のないパッケージの削除 まとめ installed_on_requ
前提 brewで、自分でインストールしたformulae 以外 = 依存関係として入ったformulae のみを更新しようと思ったのだけど、 自分でインストールしたかどうかは、情報として保持してないっぽい? ので、近似解として、依存されてる側のformulaeだけ更新しようと思った。 のでメモ書き。 ちゃんと制御するならbrew pinとかを使うべきなんだと思う。 誰か/何かの役に立てば。 コマンド $ brew update $ comm -23 <(brew outdated --quiet) <(brew leaves) | column # 確認 $ comm -23 <(brew outdated --quiet) <(brew leaves) | xargs brew upgrade # 実行 って感じ。 解説 brew leaves 依存関係を持たない formulae が取
Howdy folks! I have some exciting news to share, as alluded to in the title. First, some long-delayed closure: Effective today, I am stepping down as lead maintainer of Lerna. I will transition to an "emeritus" status, and largely end any remaining day-to-day responsibilities. I won't be able to pick up any threads dropped, and for that (among many other things), I sincerely apologize. Burnout is
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く