  |
はてなキーワード: Jsonとは
FXやら株のデイトレってのは金脈ほってるようなもんだから「つるはしを売る（MQL5でアルゴリズムを売る https://www.mql5.com/ja ）」のが一番儲かるだろ
バックテストから逆算してオーバーフィットしちゃったアルゴ作って売る。あるいはX日使用済み（中古）とかいう概念をわざわざ導入してそれっぽい雰囲気と価値を出してもいい
cTrader Storeでもいい https://store.ctrader.com/start-selling
doc https://www.mql5.com/ja/docs
Financial Information ExchangeのAPIがある https://ctrader.co.jp/ctrader-fix-api/
cTIDがあれば使えるAPI JSONかProtobufs（なんだこれ）投げる https://ctrader.co.jp/open-api/
日本語docはクソなので https://github.com/spotware/OpenApiPy か ttps://help.ctrader.com/open-api/
https://qiita.com/yugui/items/160737021d25d761b353
https://zenn.dev/nozomi_iida/articles/1022_proto_learning
まずメカニカルキースイッチにも薄型タイプがあることを知っておくといい。超薄型が作れるパンタグラフほどではないがケースやキャップもそこそこ薄型になる。
界隈では薄型はかなりの傍流になるが、既製品ではIQUNIX Magi65やLofree Flow84やNuphy Air60 V2といった機種がキーボードマニアからの評価も高い(=打鍵感や打鍵音が良い)。
先に挙げたやつほどコトコトとクリーミーな音がしてオススメ度が高い。とはいえ、あくまでロープロファイル系の中では、という話。
浅いキーストロークの熱心なファンでもなく、自作系に踏み入る気があるならば、通常サイズのメカニカルスイッチでも、スプリングが軽いものや、軸を高分子素材にする等で滑らかさをあげたものを用いて軽い打鍵感を作ることができ、そちらの方が沼が深い。
またケース側でも、最近のカスタムメカニカルキーボードキットは大抵がガスケットマウントと言って基盤をシリコンラバーで挟むことで底打ち時の負荷をへらす(たわむ)設計になっており、疲れにくくなっている。
この手のキットはケース全体がアルミニウムなどの金属で出来ていて物理的に重くすることでいい音を作るのが主流のアプローチになっている。安いキットやハンドメイド系のガチ自作ではプラ筐体が多いが。
とりあえず手頃な入門キットをお望みで個人輸入ができるなら、今はLucky65 V2がダンゼンおすすめだ。アルミでは最安レベルながら質感も高くカッコいい。
ベアボーンキットなのでスイッチやキーキャップは自分で調達する必要がある。
スイッチは安価で良いものを選ぶなら、MZ Studio Z1 Linear Switchがおすすめだ。
キーキャップは好みになるが、マニアからはPBT素材で厚めのものが好まれる。
コスパ重視なら、Womier Factory Storeあたりが手頃な値段でそこそこのものを売っている。AmazonでXVX名義で売ってるのと同じ会社だがどうせ中国から来るならAliのが安い。
ちなみにこのストアが売っているWomier SK65という完成品キーボードは、裏面の明らかにLuckyと書かれた金属ウエイトで分かるように、Lucky65初代のODM版と思われ、右上キーをノブに置き換えてスイッチとキャップをセットにしたもの。
ただ付属のスイッチは47gfと重くはないが特別軽くはないので軽いスイッチがいいなら40gf以下のものを選んだほうがいいだろうことを考えると微妙。
この筐体はV1だがV2の方がクオリティは上がっているようで、少々jsonファイルを探す必要はあるがキーマップの自由度も増していて、マグネット脱着機構で分解もしやすくなっている。
スイッチとキャップをはめ込むだけで完成するこの程度の半完成ベアボーンキットであればV1完成品ODMよりV2を狙ったほうがいいと個人的には思う。
英語配列や65%レイアウトなどを敬遠する人もいるが、それほどハードルは高くないと思う。
配列は、OSの設定で英語キーボードに設定して、IMEの設定で押しやすいキーに日本語ON/OFF(自分はShift+スペース)を割り当てるだけで、あとは細かい記号の違いに慣れればいい。@などは押しやすくなる。
65%などのFキー列がないものを使いこなすのは一見難しく感じるが、機種専用のキー割当ソフトでFnに相当するレイヤキーをCapsLockあたりの位置に移動してしまえば、むしろ指をあまり動かさずブラインドでFキー列を押せるようになるので慣れたら快適。
割当ソフトはjsonを読み込ませて使うデファクトスタンダードアプリであるVIAや機種固有のメーカー製アプリだったりするが、最低限ググる能力があれば問題ないだろう。Fnキー位置を変更できない機種があることは事前にチェックが必要。
技適を気にする人は有線のみのものか国内代理店のついている無線製品を選ぶのが無難だがこの手の趣味はだいたい国内に入ってきていない中国ブランドが強いので自己責任的なアレだ。
htmlタグのdata-entry-eid属性に書いてある数字である。はてなブックマークエントリー情報取得APIでも取得できる。
https://b.hatena.ne.jp/entry/{エントリーID}/comment/{ユーザーID}
あるいはユーザーのブクマ一覧中のブクマにアクセスする以下のURLもある。
https://b.hatena.ne.jp/{ユーザーID}/{日付}#bookmark-{エントリーID}
ところがこのエントリーIDは1つのエントリーに複数存在する可能性がある。
たとえば以下のブクマページ。
https://b.hatena.ne.jp/entry/s/nordot.app/1211910352128279184
エントリーIDは4760262558153474272である。
https://b.hatena.ne.jp/entry/4760262558153474272/comment/{ユーザーID}
しかし一部のブクマのURLは以下のようにエントリーIDの部分が異なる。
https://b.hatena.ne.jp/entry/4760262556542860384/comment/{ユーザーID}
ブクマページはエントリーIDを使ってアクセスすることもできる。
https://b.hatena.ne.jp/entry/{エントリーID}
https://b.hatena.ne.jp/entry/4760262558153474272
別のエントリーIDらしきものでも同様にブクマページにアクセスできる。
https://b.hatena.ne.jp/entry/4760262556542860384
つまりエントリーIDは複数存在するようだが、ブクマページやAPIで取得できるエントリーIDはただ1つである。
4760262558153474272はエントリーIDとして取得できるが、4760262556542860384はブクマページを探してエントリーIDとして使用しているブクマを見つけることでしか取得できない。
何かが修正されたときにエントリーIDが変わることがあるのだろうか？
「はてなブックマークエントリー情報取得API」でエントリーIDと各ブクマのユーザーと投稿日時を取得して、これを使って「はてなスターカウントAPI」でブクマが得たスター数を取得する場合、通常は以下のURLでスター数を取得できる。
https://s.hatena.com/entry.json?uri=https://b.hatena.ne.jp/{ユーザーID}/{日付}#bookmark-{エントリーID}
ところがエントリーIDが異なるブクマは当然個別のエントリーIDでないとスター数を取得できないので、はてブAPIだけでは情報が欠損する。
別に細かくなく公式で言及のあった話でしっかりと伝わったのでタイトルは誤りでした。
ブクマするURLにパラメーターが付いているとエントリーIDが変わるということだそうです。
ご教示ありがとうございます。
記帳代行というのは、簡単に言えば紙の領収書や紙のレシートを分析して、それを帳簿につけるという仕事だ。
だいたい1枚あたり20〜60円ほどで行われる。20円はかなり安い。
これはいうならば全購入に対して20円かかっているということでもある。
個人事業主から大企業に至るまで、すべての物品購入に20円かかっている。
「20円 / 商品」はもはや税金だろ。冷静に考えてほしい。これはもう「固定消費税」みたいなもんだ。
個人事業主が確定申告のときにひぃひぃ言っているのもこれのせいだ。「固定消費税」を払いたくないから、自前で大量のレシートに対してひぃひぃ言いながら分類する。
これがめんどくさいということだ。そもそも紙はどこだなどと探すこともある。紙を管理するのがめんどいわけだ。
「めんどい」とか言っているが、固定消費税分の労働をしているわけだな。全員な。
OCRというのは、紙をスキャンして、その内容を読み取ることである。
だが冷静に考えればそのバカバカしさがわかる。そもそも領収書として紙を印刷しているわけだ。もともと電子データとして存在しているものを、レシートや領収書として出す。
もちろん手書きのこともある。手書きで領収書を出すわけだな。お釣りの計算を電卓でやっているようなところはそうだ。それはもうしょうがない。
だが、スマートレジとかを導入しているところ、そこも紙のレシートとはどういうことだ。
まずスキャンがめんどくさい。スキャナーあるいはスマホで撮るわけだ。めんどくさくないか？
紙のレシートを並べる。並べたりしてスキャナーでウィーンと動かすとか、スマホで撮影する。スマホで撮影したりスキャナーでとりこんだだけでは終わらない。
画像認識する機械学習や流行りのAIで分析し、会計ソフトに入れたりするわけだ。しかもレシートの形式もものによって違うから、画像認識が難しい。規格が統一されていない。
「電子データ→（各社頑張って印刷）→ 紙 → （各社頑張って読み取り） → 電子データ」
この流れアホだろ。しかもその紙は捨てる。何。頑張って印刷はまあ昔からの流れだからいいよ。でも頑張って読み取りしてるのマジでアホすぎる。資源の無駄遣いだろ。
紙は木を切り倒して作ってるんだぞ。
電子決済したあとスーパーアプリ化しようとしているみたいだが、そんなことよりやるべきことあるだろ。
レジと連携しろ。PayPayで払って電子レシート出てきたら革命だぞ。なぜ尽力してないのか。何してる？
POSレジは一応電子レシートを出しているところもある。だが全然流行っていない。ひっそりとやられている。
「PayPayで払ってfreeeやMoneyForwardと連携したらもう会計処理しなくていい」
もう覇権とるでしょ。なんならもう確定申告とかもやってくれるわけ。われわれ、もう買うだけでいい。何なら会社合併しろよ。まともに働いてんのか。
もうみんな電子決済使ってるじゃん。じゃあもう勝手に電子レシートにして連携しなよ。
できるでしょ。というかやってるけどしょぼいんだよ。各社が個別にやってるから。
個別にやるから各社バラバラにやってて統合めちゃくちゃじゃん。
なんで勝手にバラバラにやってんの。政府も進めているみたいだが、動きおっそ。
何？自信ないの？考え方正しいよ。みんなが乗ってくれないからって引っ込めるなよ。騒げ騒げ。ロビー活動しよう。
規格だけ作ってそれでドンッと通信すればいいよ。日付と商品名と金額と購入元だけでしょ。
既存の技術でいいよ。他の情報はなんか勝手にやっとけばいいけど、基礎レイヤーだけさっさと合意してそれで進めてもらえる？？？？
実証実験済んでるじゃん。やりなよ。
規格考えたけど
{ "date": "YYYY/MM/DD", "item": "商品A", "tax_included_price": XXXX, "tax_excluded_price": XXXX, "source": "購入元" }
こんな感じのやつがv1でいいよ。追加したい情報は好きに追加して。これが日本中駆け巡れ。
ひっそり周り伺いながらやってるから遅々として進まないんよ。どーーーーんと堂々と進めなよ。
みんなわかってないんだって。利便性とか。みんながやってないから。
「いや俺は今まで通りとかでいいし……」とか言う感じ。他の人がやってないことやるとダセェと思ってる。ダセェのはテメェだろ。
「電子レシート便利だよ」と誰かが言っても誰も使わないって。みんな何が便利かわかってない。
そうじゃない。
消費者はアホなんだよ。何が便利かわからんわけ。自分が何を欲しがっているか理解していないわけ。
「電子レシート？よくわからないけどめんどくさそう。やり方とか覚えないといけないんでしょ？いいよ紙で慣れてるから」
そうじゃない。
「もうみんな電子レシート使ってますよ。まだ紙のレシートなんですか？遅れてるゥ！」
いいか、この流れだ。PayPayの死ぬほどのキャンペーンでQRコード決済が普通になった。
勢いでなんとかなる。別に会計ソフト使わない人もエクセルやスプレッドシートでいいって。
政府・総務省・経産省・財務省・環境省・デジタル庁で横断プロジェクトで進めたらすぐできるよ。
最悪CSVやjsonフォーマットで受け取ればいいじゃん。OSSで誰か作るって。簡単だから。
物品の購入履歴が電子化されて規格化されていくということは、レシートに留まらないわけ。
今ってPDFで請求書などを書いて送付してるけど（これも印刷されたりする。クソ）、あれも同様に効率化できるわけ。
これは基礎的な規格が存在すればいける。変に規格に余計なもんつけたら統一が遅くなる。TCP/IPのスマートさを見習って。
どっかがデファクトスタンダード作って、その上に自分たちの機能つけてよ。変な昔ながらの規格競争とかしないで。
現在の日本文明では、何がどこに行って誰の手にわたっていてどうなっているのか全然わかってない。
もちろん監視社会にすべきだというわけじゃない。プライバシーがあるので「これを買ったことは誰にもバレたくない」というのは会計処理に入れなくてもいいと思う。
（でもなんか企業はそういうことを考えずに容易に「うちのサービスの中に入れます！！」というのを堂々と言ってる。日本人の個人情報保護意識の無さが表れているよう）
いいよどうせ日本は個人情報興味ないから。どんどん進めて。EUやアメリカだとそこらへん障害あるから進まないけど日本ならいける。AIに著作権売り渡したみたいにGOGO。
それで、商品の行方がどうなっているのかわかっていないので、分析することもできない。誰が何ほしいのか、なんでほしいのか、誰が何作っているのか、何もわからない。
購入履歴がすべてわかればそれをリプレイすることで歴史を再構成できるわけだ（たとえば位置情報なども入れれば、どうやって会社が大きくなったのか見えるんだ）。
残念ながら今はそうなっていない。そんな余裕はないからだ。だって紙だから！！！！！！！！！！！！
全国には462万人の個人事業主がいるという。
ブツブツ言いながらレシートを見ているわけだ。めんどくせーなーと思っている。なんでこんなことしなきゃいけないんだと。
462万人だぞ？法人企業には平均4.6人の経理担当者がいるようだ。つまり816万人いる。1278万人か。もうちょっと少なそうだがまあいい。
まあいったん462万人で考えよう。462万人というと「静岡県の1.2倍程度」だ。みんな静岡県に行ったことはある？？
静岡県のどこを歩いてもどこで人とすれ違ってもその全員がみーーーーーんなレシートを見てひぃひぃ言っていると考えてほしい。
みんな「めんどくせーなー」と思っている。なんでこんなことしなきゃいけないんだと。
熱海に行っても浜松に行っても、富士山の近くまで行っても、御殿場に行っても伊豆に行っても、そのどこに行ってもみーーーーんなレシートで潰れている、それぐらいの規模だ。
1278万人というとそれが東京都に拡大される。もはやキモい。
この1278万人がおのおの1行ずつデータを処理していると考えてほしい。1人あたり毎月200行処理するとしよう。そうすると全体で毎月25.5億行か。
コンピュータは「1億レコード/秒」で計算できるから、これは理論的には「25.5秒」で終わる。
非現実的な話だが理想はこれだ。税務署も会計士も税理士も縮小できるじゃん。やったね。なんなら勘定科目も勝手にすればいいじゃん。
結果手元にいくらあって、儲かりマシーンたる資産と、損するマシーンたる負債がどのぐらいあるのかわかることが1番重要なんだが？
端的に言うと、今日本人がひいひい言って毎月1200万人がバカみたいにだらけながらやっている作業は、最高効率化すれば「トータルで」毎月25秒、年間3分、60年分で3時間にまで圧縮可能だ。
レシートや領収書で潰れる人間は日本から消えるということ。あとついでに人手不足も解消ね。1200万人分人手増えますね。
ていうか逆に考えて。理論上コンピュータ1台で25秒で終わる作業なんだよ。
それを1200万人が毎月「あーーーーー」って顔しておのおの処理してんの。この時間何？
これがわびさびですか。この時間の間みんなで映画見た方が全然よくない？
さあ今すぐ電子レシートを進めよう。合言葉は「25秒」でお願いします。
あと電子レシートっていうけど画像で出すなよ。画像はあってもいいけど画像だけで出すなよ。
だいたい画像を出したいという思考がまず保守的。「今まで通りでいたいから……」「責任とりたくないから……」だろ。
レシートの役割理解してない。言われたからやってるだけ。アドルフ・アイヒマンかよ。
くれぐれも形だけ電子レシートにしたとかいう意味ないことするなよ。日本そういう自己中なとこあるからな。
「言われたからやりましたけど？？」「言われた通りにしただけですけど。えー？なんですかー？」「やりたくないけどあなたが言ったからせっかくやったのに！」「言われたからやったのに酷い！」「はいはい自分が悪いですねー！はーい！」とかね。
const axios = require('axios'); // HTTPリクエストを行うためのモジュール
const fs = require('fs'); // ファイル操作モジュール
const xml2js = require('xml2js'); // XMLをJSONに変換するためのモジュール
const chardet = require('chardet'); // 文字エンコーディングを検出するためのモジュール
const iconv = require('iconv-lite'); // 文字エンコーディングを変換するためのモジュール
const rssUrl = 'https://www.mlit.go.jp/important.rdf'; // 例としてRSSフィードのURLを指定
async function fetchAndSaveRSS() {
try {
// RSSを取得
const response = await axios.get(rssUrl, { responseType: 'arraybuffer' });
const rssData = response.data;
const detectedEncoding = chardet.detect(rssData);
console.log('検出された文字エンコーディング:', detectedEncoding);
// UTF-8に変換
const utf8Data = iconv.decode(rssData, detectedEncoding);
xml2js.parseString(utf8Data, (err, result) => {
if (err) {
console.error('XML解析エラー:', err);
return;
}
const jsonData = JSON.stringify(result, null, 2);
fs.writeFileSync('rss_feed.json', jsonData, 'utf8');
console.log('RSSフィードがファイルに保存されました。');
});
console.error('エラーが発生しました:', error);
}
}
// 実行
fetchAndSaveRSS();
（ここに返信対象の増田を入力） ---- - 上記のコメントに対する返信replyを出力してください。 - replyは以下の中から最も会話として通じるものを選んでください。 ``` - 男の誇りを失ってまで得る価値のある勝利かっ…！？ - 人間は強い…！そして優しい生き物だ！ - 家族というやつはいいもんだ… - 今はただ…オレの友の…！！心意気だけをくんでやってくれっ！！！ - 目先の勝利に狂ったオレは…馬鹿だった… - ゆるせよポップあの世で会ったら好きなだけオレを殴れ…！ - 生きとし生けるものにはすべて太陽が必要なのだ… - オレは男の価値というのはどれだけ過去へのこだわりを捨てられるかで決まると思っている - 恐ろしいものだ…欲とは…オレとて どう ゆがんでいたかわからん - この世には 本当に煮ても焼いても食えぬヤツがいる！ ``` - より自然な返信となるように必要に応じて原文を改変してください。 - 複数の候補を選び、それぞれの無害度をwholesome_rateとして0.0〜1.0の範囲で評価、出力してください。 - 出力は以下のようにjson配列でお願いします。 [ { "reply": "...", "wholesome_rate": ... }, ... }
import requests import json from urllib.parse import quote def fetch_bookmarks(url): try: # URLをエスケープ escaped_url = quote(url, safe="") api_url = f"https://b.hatena.ne.jp/entry/json/?url={escaped_url}" response = requests.get(api_url) response.raise_for_status() try: return response.json() except json.decoder.JSONDecodeError as e: print(f"Error decoding JSON from {api_url}: {e}") print("Response content:", response.text) return [] except requests.exceptions.RequestException as e: print(f"Error fetching bookmarks from {api_url}: {e}") return [] def find_common_bookmarks(bookmarks1, bookmarks2, url1, url2): common_users = set(bm["user"] for bm in bookmarks1 if bm["comment"]) & set(bm["user"] for bm in bookmarks2 if bm["comment"]) common_bookmarks = [] for user in common_users: comments = [] for bm in bookmarks1: if bm["user"] == user and bm["comment"]: comments.append({"url": url1, "comment": bm["comment"], "timestamp": bm["timestamp"]}) break for bm in bookmarks2: if bm["user"] == user and bm["comment"]: comments.append({"url": url2, "comment": bm["comment"], "timestamp": bm["timestamp"]}) break if len(comments) == 2: common_bookmarks.append({"user": user, "comments": comments}) return common_bookmarks if __name__ == "__main__": url1 = "https://news.yahoo.co.jp/articles/f9966c4ccc374fc88babbb50175a9ea844c99638" url2 = "https://www.asahi.com/articles/ASN6K7F64N6KUJHB00L.html" data1 = fetch_bookmarks(url1) data2 = fetch_bookmarks(url2) common_bookmarks = find_common_bookmarks(data1["bookmarks"], data2["bookmarks"], url1, url2) print(json.dumps(common_bookmarks, indent=2, ensure_ascii=False))
url1, url2のところを対象としたいものに変えれば使えるよ
バグあったら直して使ってね
今日は入院している祖母に会いに行く日だ。入院前はもう呆けて風呂も入らないぐらいひどい状態だったが、入院してからはちゃんとしているらしい。
それはそうと、lispでpython環境を構築する話だが、結局オートコンプリートはうざいし、使う機能といったらautopep8とisortぐらいなので、以下を.emacsに組み込んだ。
(defun python-autopep8-and-isort () "Run autopep8 and isort on current Python buffer." (interactive) (when (eq major-mode 'python-mode) (shell-command-on-region (point-min) (point-max) "autopep8 - | isort -" nil t))) (with-eval-after-load 'python (define-key python-mode-map (kbd "C-c C-r") 'python-autopep8-and-isort))
.emacsファイルには他にも様々な設定を付与したが、ここではコードを書ききれない。
さてそういうわけで週末コーディングが趣味としてちゃんと機能することはわかったが、毎週作るとなると、いくつも何かを作るよりは一つのタフなものを作りたいと思うわけである。
それで、最有力候補は「Elasticsearchのようなものをpythonで実装する」という話がある。
Elasticsearchが徹底された設定外部化によってjsonを多用するのだが、これがあまり柔軟性がないので、コードを直にいじれるようにしたいと思ったためである。
例えば自作の日本語トーカナイザを組み込みたいときElasticsearchプラグインをJavaで書かなければならない。私はJavaが嫌いであり、プラグインを「インストールする」という手順も冗長に感じる。
それよりはpythonで作られた検索システムに、適当なトーカナイズ関数を実装して呼び出すことができればかなり柔軟であるように思うわけである。
難しい点があるとすれば、大規模分散システムへの対応で、金をかけなければそういうシステムをテストすることができない。
できるだけ金をかけずに趣味をやるというのがモットーなので、これではまずいわけである。
まあ何事も困難というものはある。まずは手を動かすことが重要だ。Linus Torvaldsも"Talk is cheap, show me the code"と言っているではないか。
ブログやIT技術者向けSNS等は利用しておらず、はてブやTwitterでやるにはやや長いので、増田に投稿
Windows 10 (22H2 19045.4170) 上のEdgeを、数十のタブを開いたまま新バージョン (123.0.2420.53) に更新したらハングアップしたため、タスクマネージャーで強制終了させた
その後Edgeを起動させようとすると、更新時に閉じたセッションを復帰させる段階で強制終了するようになり、使用不能になった
Edgeに導入していた拡張機能には、Session Budy (4.0.2。GoogleのManifest V3に対応するため、最近大規模改修を実施(1。増田の最終節の同番号を参照。以下同)) やuBlock Origin (1.56.0。新規のマイフィルターを多数追加中だった) 等があった
「Edgeが起動しない」と直截な語句で検索していくつかの解説ページにたどり着いた
いくつかの解決策(2・3)を実行したところ、有効ではなかったが次の知見が得られた
数日程度では修復できないだろうと判断し、別のChromiumブラウザを使いつつ、片手間で修復方法を調べることにした
Windowsの設定画面等にあるリンクが有効になるよう、デフォルトのwebブラウザをEdgeから変更した
パスワードは別ツールで管理してたため無くてもそんなに困らなかったが、uBlockの設定とSession Budyで雑に保存してた閲覧履歴は必要だったので、Chrome拡張の復旧作業をした
"Default\Local Extension Settings"以下のフォルダと、念のために"Default\IndexedDB""Default\Local Storage\leveldb"の中身を移植(8)して作業完了
アイテムの履歴データ破損が問題の原因ではと考えてその修復や初期化方法を検索したが、これは徒労に終わった（ただし、このアプローチが完全に無効だとは言い切れない。参考ページ5は、復旧作業完了後に見つけた情報で、今回の問題に活用できずに終わった）
「コントロールパネル→システムとセキュリティ→セキュリティとメンテナンス→信頼性履歴の表示→問題レポートをすべて表示」で確認できた、Edgeの問題の要約やイベント名等で検索したところ、再インストールを勧めるページが数点引っかかった
既に何日も経ちWindowsの再インストールかユーザーアカウントの作り直しをしようかと考えかけていたが、もう少し努力してみることにした
Edgeを (アプリファイルを手動で削除したりするのではなく) なるべく安全にアンインストールすれば、正常に再インストールできるのではと考え、検索結果通り(11・12)に作業してみた
それでも「アプリ」のアンインストールメニューは無効なままで操作できなかったが、他に事例が無いか、"IntegratedServicesRegionPolicySet.json"等の関連語句で再検索した
コマンドラインでアンインストールを試みた事例(13)が見つかり、実行したらEdgeが削除された (ただし、コマンドプロンプトでもポップアップウィンドウでも実行結果の表示がされなかった)
そして参考ページ4のインストーラを実行し、念のために修復とOSの再起動をかけ、Edgeの起動を確認した
Microsoftアカウントにログインしていたため、パスワードは簡単に復旧できた
拡張機能は全て死んでいたが、仮に使っていたChromiumブラウザからコピペしたりエクスポートしたりして終了
利用していた拡張が少なかったので、プロファイルフォルダの内容の移植よりもその方が簡単だった
1. SESSION BUDDY V3 END OF LIFE | Google グループ
https://groups.google.com/g/sessionbuddy-discuss/c/HQPcLOq3-Ik
2. Microsoft Edgeが直ぐ閉じてしまう。 | Microsoft コミュニティ
https://answers.microsoft.com/ja-jp/microsoftedge/forum/all/microsoft/c414d2f9-b685-471c-8e78-2054c2e26c6c
3. ある日突然「Microsoft Edge」が開かなくなった、さあどうしましょう：山市良のうぃんどうず日記（224） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/2202/02/news009.html
https://www.microsoft.com/ja-jp/edge/download?form=MA13FJ
5. Windows10の「タスクバーにピン留めしているアプリ」の、「最近使ったもの」と「固定済み(いつも表示)」の設定ファイルとレジストリはここにある #Windows10 | Qiita
https://qiita.com/RyoIchimura/items/7e33980358f07e57a715
6. msconfig（システム構成）で解除してよいのは？使用場面と起動方法 | ドスパラ通販【公式】
https://www.dospara.co.jp/5info/cts_str_pc_msconfig.html
7. Windows Hello の概要とセットアップ | Microsoft サポート
https://support.microsoft.com/ja-jp/windows/windows-hello-%E3%81%AE%E6%A6%82%E8%A6%81%E3%81%A8%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97-dae28983-8242-bb2a-d3d1-87c9d265a5f0
8. chrome.storageの実体の場所 #Chrome | Qiita
https://qiita.com/k7a/items/cf644471d34d31f398e9
9. 第2回 グループ・ポリシーとは何か：グループ・ポリシーのしくみ（3/5 ページ） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/0602/23/news119_3.html
10. Microsoft Edge ブラウザー ポリシーに関するドキュメント | Microsoft Learn
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-policies
11. Windows 11/10からMicrosoft Edgeをアンインストールするシンプルな方法が見つかる | ソフトアンテナ
https://softantenna.com/blog/windows-11-10-uninstall-edge/
12. Releases · thebookisclosed/ViVe | GitHub
https://github.com/thebookisclosed/ViVe/releases
13. 各チャネルごとの Edge 削除状況 | 内気なもんた君
・(類似製品の)好きなものの記事に行って嫌いなものの苦言を言う
それが嫌いなら開かず無視したらええねん…ひたすら腐してるのはなんなん…
あなたが望む実現しない要件を何度も挙げて最低条件って言うのは客観的に見て結構恥ずかしくないですか？他のみんなは大多数が興味があって覗いて、少数は内容を批判的に論じるんだけどxlc さんのは内容関係ないよね…？
超バズったからやってきた。とかならわかるんだけど公開ブクマ1桁以内でこういうの言っちゃったりしてるのは当たり屋じゃないっすかね…
なぜコーディングにVSCodeを使うのか。 私がVSCodeを選んだ理由
xlc 2024-03-13
全く心が動かない。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
Atom の作者達が作った Rust 製エディタ Zed (OSS) - Qiita
xlc 2024-02-25
VS Codeが嫌すぎてAtomを使い続けているので同じ使い勝手なら移行を考えるかも。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
保守・理解しやすいコードを書きたい！ 〜VSCode拡張機能で循環的複雑度と戦う〜 - Qiita
xlc 2024-02-23
Atomの開発が終了しVSCodeをインストールした2023年は全くコードを書かない一年となった。それぐらい使いにくい。というか使う気にならんのだがみんなよく使ってるね。今年Atomに戻したらプログラミングを再開できた。
VS Codeの新機能がすごく便利！ ツリービューのスティッキースクロール機能をオンにすると格段に使いやすくなります
xlc 2024-02-15
昨年ほとんどプログラムを書かなかったのはVS Codeにさわりたくなかったから。とうとう諦めてAtomに戻してプログラミングの習慣を取り戻しました。後継エディタにもがんばってほしい。
xlc 2023-02-02
私はこれ https://www.amazon.co.jp/dp/4798067881 を書くのにこれ https://kobalab.net/liulian/ を使いました。
VScodeの設定（setting.json）まとめ【2023年1月更新】
xlc 2023-01-02
VScodeがあまりにも使いにくいので未だにAtomを使ってる。
GitHub製コードエディター「Atom」の最終版が公開 ～8年間の開発に終止符／12月15日をもってリポジトリはアーカイブ
xlc 2022-11-22
VS Codeを起動してみたが、そっと閉じ、使えるうちはAtomを使い続けようと決意した。
Sunsetting Atom | The GitHub Blog
xlc 2022-06-09
