  |
はてなキーワード:utf-8とは
<script asyncsrc="https://platform.twitter.com/widgets.js" charset="utf-8"></script>切れ味がすごい......
＞昨今SNSが発達したこともあり、「読者に『自分が』凄いと思われたい」という「読者を楽しませる」ことから本質ズレた欲求で描いているのでは？という場面も散見されます。「予想を裏切る」ことに執着して、「期待を裏切らない」ことを過度に軽視してしまう姿勢とも言えます。https://t.co/l77BYMlyRJ— 結騎 了 (@slinky_dog_s11)February 11, 2026
お口に出せないなら、どこに出すんだい！
世のライブサービスゲームの中でこのホヨバ3作+1ほど短いスパンで開発費をもりもり掛けた贅沢なアップデートを投下し続けているタイトルはないと思う
オタク趣味に抵抗さえなければ退屈しないしSNSを通して楽しんでる人や二次創作してる人は無数に見つかるから飽きることもない
掛け持ちだと忙しすぎるけどオタク心をよく理解してる壮大な作品作りでまじめに読んでいけば心が豊かになって情緒がジェットコースターのように日々揺り動かされることは俺の長年の経験から保証する
原神の年間の開発費は220億を超えてるとも言われ累計だと1000億は超えてるだろうし、続いて出たスタレゼンゼロもそれに引けを取らないくらいリッチなアニメ調タイトルとしてグローバルのアニメ系ゲームセールスでtop3にほぼ毎月いる
上海にはオフィスが7棟くらいあってデカい新社屋付近の区画まるごと秋葉原化しようという計画もあるくらいぶっ飛んだオタク企業
ただでさえ高いガチャゲーの利益をほとんど既存・新規作の開発体制増強や自社拡大に使ってる根っからのクリエイター気質として非上場を貫いて、ほとんどを自己資金で賄ってるという奇跡っぷり
スタレゼンゼロは各1000人、原神だと2000人超えの社員を使ってる↓ようで、国産ガチャゲーとはジャンルが違うことが分かる
参考リンク:redditリンク禁止されてるのでgoogle検索からgoogle:mihoyo_employees_increasedecrease_as_of_2024
中国にはテンセントやネットイースみたいな大資本から支えられてビジネス色強めで多産多死してる運営型ゲームが多い中で、同人オタク大学生たちが起業した会社がアニメゲー業界で上位独占し、自社IPを大事にしててここは絶対サービス終了しないって信頼が得られてるところも異質
ここまでマーケットを破壊的に支配してるやつらについていくのは最高にエキサイティングだと俺は感じてる
中の人達の顔もちゃんと見えてて先日出てたこの動画あたりが開発の様子を窺い知るのにちょうどいいんじゃないかな→ https://www.youtube.com/watch?v=anM3EvPHuZQ
どれもガチャゲーだけれどもアニメ調としてはAAAゲー品質のマルチプラットフォーム作品で、個人的にはウルトラワイドモニターつないだPCでやるのが一番おすすめ
新キャラを無凸で確保するだけに徹するなら、1タイトルあたり月平均3500円くらいの課金で全キャラ確保していけるので掛け持ちをしても低コスト高タイパに抑えることは可能
特定の最強編成をひたすら強化していくのが正解だったソシャゲ時代のゲームと違い、これらのゲームは新キャラを広く集めていったほうがゲーム性をよりストレスなく満喫できるし、ゲーマー的にもそれくらいが丁度歯ごたえのある難度になる
ただモチーフ武器や2凸くらいまで狙うとコスパよく数字が跳ね上がっていき、キャラ確保に無料石をすべて費やすとすると武器や凸を取るごとに2万ずつ払ってる計算になるので、欲のコントロールはガチャゲーらしく求められる
とはいえ石油王が有利かというと1キャラ完凸するのは20万そこらで済み、キャラ追加も6週ごとに1～2体なので古のソシャゲのように3億円課金するとかは起こり得ないし、そもそも競争要素のないソロプレイゲームつまり非ソーシャルゲームなのですべては自己満になる
ソシャゲほど戦闘コンテンツの比重が重くなく、難度も無凸で揃えてたら困らない程度と易しく、物語や探索、世界観への没入が主体で、あまり時間のかからないミニゲームの中の一つとして戦闘コンテンツがあるような感じ
ガチャシステム自体は結果が収束しやすい超低確率からの変動確率制になっていて、天井までのカウント等も次以降の限定ガチャバナーまで引き継がれるので無課金でも着実に限定キャラを増やしていくことはでき、排出タイミングもほぼ読めるので、ガチャが運ゲーではなく計画性をもって攻略可能なものになっているのも付き合いやすいポイント
実際にはそこまで悪辣なギャンブルではない確率設計なんだけど、ランダム性があるかのようなドキドキ感を演出することで健全さとドーパミン需要を両立させていて、特に原神にある掴みし明光ってシステム↓は運の悪い人だけをこっそり救済してくれる巧妙な設計で興味深い
参考リンク:redditリンク禁止されてるのでgoogle検索からgoogle:reminder_on_updated_capturing_radiance_theory
なんかさっきはてブのゲームカテゴリで「わたしたちは運ゲーを揶揄しながら、ほんとうは運ゲーが大好きで、あたたかな偶然が好きなのだ」って言ってる記事を見かけたが
それをガチャ設計上すでに高い水準で達成してヒットしてる最たるものが原神という例だと思うんだよね
プレイヤーの多くはその暖かさに気づいてなくて、短期的な感覚ですり抜けに毒づく人も多いんだけど、長期的にプレイしていると守られていることに気づく、結果として毎回絶対すり抜けるような悪運の人も確率どおり勝率50%の人と変わらない限定キャラ所持数になっている
気づいてないところがいいんだよね、本当に統計値調べまくった数字に強い人しかこの非公開ガチャ仕様の巧みさに気づかなくて、そのお陰でガチャを楽しめてる部分があるから、優良誤認ならぬ劣悪誤認みたいなもんだね
とにかく、ヒリつくマーケットに揉まれてきた人にとってホヨバースゲームの絶妙な確率設計やリアルタイムにIPが成長していく体験は最高の揺りかごだと思うんだよ
まあ趣味さえ合えばの話だけどね
COCONAのせいでフェミやべーことになってるやん。どうすんのこれ
https://search.yahoo.co.jp/realtime/search?p=cocona&aq=-1&ei=UTF-8&ifr=tp_sc
と質問とした所、
いい質問。ただ、**今回私が提示したC#コード（MemoryMappedFile + Parallel.For でCR を数える）**には、明確に一つの「このネット上の記事／リポジトリをそのままコピーした」元ネタはありません。
いくつか似たアイデアを使ってる部分と参考になる記事／ドキュメントはあるので、それらを紹介します：
---
*Microsoftドキュメント — Memory-Mapped Files (.NET)*
([Microsoft Learn][1])
*Kieren Johnstone: 高速に MemoryMappedFileからバイト列を読む方法（StackOverflow）*
`MemoryMappedViewAccessor` を使って unsafeコードからポインタを取得し、Marshal.Copy で効率よく読み出す方法。
([StackOverflow][2])
*Red-Gate: Sharingis Caring: Using Memory Mapped Files in .NET*
MemoryMappedFile を使ったキャッシングなどの応用。
*Stephen Cleary のブログ: Memory-Mapped Files と Overlaid Structs*
メモリマップトファイルへ構造体を重ねて（オーバーレイ）扱う方法など。
([blog.stephencleary.com][4])
---
もしよければ、**あなたのコード（CR を数えるもの）に特化した元ネタをさらに探してみます**。やりましょうか？
[1]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[2]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[3]:https://www.red-gate.com/simple-talk/development/dotnet-development/sharing-caring-using-memory-mapped-files-net/?utm_source=chatgpt.com "Sharingis Caring: Using Memory Mapped Files in .NET"
[4]:https://blog.stephencleary.com/2023/09/memory-mapped-files-overlaid-structs.html?utm_source=chatgpt.com "Memory-Mapped Files and Overlaid Structs"
ChatGPT:
が、出てきて、やってくれと言ったら、こういうのが出てきた。
了解しました — 広く（英語・日本語・GitHub・ブログ・StackOverflow 等）再検索しました。結論と見つかった“近い”ソースをまとめます。
結論（要点）**
「あなたが求めている**MemoryMappedFile を使い、UTF-8バイナリ中の `CR`（0x0D）だけを数える・マルチスレッドで分割して処理する**」という **完全一致の“元ネタ”ソースコード**は、公開されたweb 上のリポジトリや記事の中では見つかりませんでした（複数の検索ワード／検索対象で確認）。([hyr.mn][1])
ただし、ほぼ同種の要素（メモリマップドファイルの読み方・大きなファイルの行数カウント・バイト単位カウントを高速化する手法）は複数見つかりました。これらを組み合わせれば、先に示した実装は典型的なパターンであることが確認できます。([Microsoft Learn][2])
見つかった“近い”・参考になりそうなソース（抜粋）**
1. .NET の公式ドキュメント（MemoryMappedFile の説明） — `MemoryMappedFile` の基本とCreateViewStream /CreateViewAccessor の使い方。必須の参照。([Microsoft Learn][2])
2. 「Countinglines withC#」というブログ記事（C# で改行（CR/LF）カウントに関する実装とGitHubリンク） — 行数カウントを目的とした実装パターンがある。([hyr.mn][1])
3. StackOverflow：MemoryMappedFileから高速にバイトを読む方法（`MemoryMappedViewAccessor` / unsafeポインタ / Marshal.Copy 等の議論） — 高速実装のヒント。([StackOverflow][3])
4. StackOverflow／Q&A：ファイル中のLF/CR の数を求める方法に関するスレッド（`grep -c $'\r'` 等のunix 例やC# でのカウント方法の議論）。([StackOverflow][4])
5.GitHub のサンプルリポジトリ（MemoryMappedFile のテスト／サンプル） —メモリマップドファイルを使う実装例。([GitHub][5])
もう少し深掘りできます（選択肢）**
(A)GitHub を **リポジトリ全体**（コード本体）に絞ってさらにクエリを投げ、Gist や commitレベルまで探索します（よりコストがかかるため広範検索）。
(B)ブログ・技術記事を対象に **全文一致（コード断片）検索** を行い、私が先に示したC#コードの実際の一節（たとえば `mmf.CreateViewStream(offset, size)` や `Interlocked.Add(ref totalCount, localCount)` など）を直接検索して完全一致を探します。
(C) 「オリジナルはGitHub にあるはず」と思われるなら、あなたが覚えている**リポジトリ名の断片／作者名／投稿日**などを教えていただければ、それを手がかりに探します（断片情報があるとヒット率がぐっと上がります）。
どれを優先して探しましょうか？（A:GitHub全探査 / B:コード断片で全文検索 / C:あなたからヒント提供）
※続けて深掘りする場合は、すぐにさらに広い検索を行って該当ソースを探します（そのまま実行します）。
[1]:https://hyr.mn/catching-flowers-with-a-net?utm_source=chatgpt.com "Countinglines withC# - hyr.mn"
[2]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[3]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[4]:https://stackoverflow.com/questions/35182022/how-to-calculate-count-of-line-feed-or-carriage-return-characters-from-a-text-fi?utm_source=chatgpt.com "How to calculate count ofline feed or carriage return ..."
[5]:https://github.com/byGeek/MemoryMappedFileTest?utm_source=chatgpt.com "test csharp code for using memory mapped file."
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
https://profile.hatena.ne.jp/dorawii_bukuma/
はてなのサイト側で読み込まれているはずのrksトークンを生成する関数を直接叩く方法がどうしても分からず結局request処理を自分で書く方法ではなく自動でUI側の保存ボタンをクリックするという無難な方向に落ち着いた。
最初から後者の方法をとっていればもっと全然早く作れたのにというは所詮言い訳か。
とにかくスクリプトを公開しておく。
@echo off
cd /d "C:\Users\user\Documents\jsscript"
:: Nodeサーバーを別ウィンドウで起動
start /min "" noderun-batch-server.js
::Pythonサーバーを別ウィンドウで起動（hatenaserver配下）
start cmd /k ""python hatenaserver\server.py
{
"username": "",
"password": ""
}from flask import Flask, request,jsonify
importjson
importos
from hatena_client import HatenaClient
from flask_cors import CORS
app = Flask(__name__)
CORS(app)
config_path =os.path.join(os.path.dirname(__file__), 'config.json')
withopen(config_path, encoding='utf-8')as f:
config =json.load(f)
@app.route('/bookmark', methods=['POST'])
def handle_bookmark():
data = request.json
url = data.get("url")
if noturl:
returnjsonify({"error": "MissingURL"}), 400
client = HatenaClient(config["username"],config["password"])
client.start_browser()
if notclient.login():
client.quit()
returnjsonify({"error": "Login failed"}),403
success =client.add_bookmark(url)
client.quit()
returnjsonify({"status": "ok" if success else "fail"})
if __name__ == "__main__":
app.run(port=12347)
// ==UserScript==
// @name自動セルクマ送信
// @namespace tampermonkey.net/
// @version 2025-08-07
// @descriptiontry totakeoverthe world!
// @authorYou
// @matchanond.hatelabo.jp/*
// @grant none
// ==/UserScript==
(function () {
'use strict';
consturl = location.href;
if (!/^https:\/\/anond\.hatelabo\.jp\/\d+$/.test(url)) return;
const editLink = document.querySelector('a.edit');
if (!editLink) {
// 既に編集ページなので処理をスキップ
console.log('編集リンクが存在するため、スクリプトを終了します。');
return;
}
fetch('localhost:12347/bookmark', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body:JSON.stringify({url:url })
}).then(r =>console.log("通知成功")).catch(e =>console.error("通知失敗", e));
})();
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250821192753# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKb0qwAKCRBwMdsubs4+SHfiAQDcXmTHBaZ5Zzr1KI/OxZ0xl69oevOdy1FXJYwYvsmo5AD/ZPtZiO1JgTDjm+27iymlkdzIXOIGWfC82UTr1mJ7EwU==YoV+-----ENDPGP SIGNATURE-----
これでも年収日本円換算で1,2億確約されてるなら別に構わないと思う
日本だとこれで1000万円届かないことありそう
<script asyncsrc="https://platform.twitter.com/widgets.js" charset="utf-8"></script>Scott Wuが買収したWindsurfチームに送ったメッセージえぐいな
「我々が求める仕事の水準は極めて高い。我々はワークライフバランスを信じていない。入社するなら、オフィスで週6日、週80時間以上働くことに同意することになる」…—久保田 雅也@Coalis (@kubotamas)August 5, 2025
軽トラのことがまた話題になってるが視野狭窄だ。端的に言って、軽トラや軽自動車が日本だけの商品と考えているのが大本の間違いだ。軽自動車はグローバル商品なんだよ。
https://b.hatena.ne.jp/entry/s/togetter.com/li/2584277
google:image:chevrolet damasで画像検索してみてくれ。見覚えのある軽バンが出てくるだろう。スズキエブリー（キャリーバン）だ。だがシボレーのバッジをつけているのだ。しかも左ハンドル。更にエンジンは韓国大宇製だ。何者だこれは。
これはスズキキャリーバンをGMがライセンス生産しているものである。
次はgoogle:image:suzuki bolanとgoogle:image:Carry Dabbaだ。
これはスズキキャリーをパキスタンで生産しているものだ。因みにパキスタンは左側通行なので右ハンドル。
この元になったキャリーは実は2スト360cc時代のもの。それに今の法規制に適合する4スト800ccEFIなんかのエンジンを載せているという異常進化を遂げている。
因みにこの生産ラインは、インドネシアキャリーがモデルチャンジする際に売却されたものと思われる。
お次はgoogle:image:piaggio porterだ。ピアッジオはベスパスクーターで有名な2輪メーカーだ。ダイハツハイゼットがそのピアッジオのエンブレムを付けてイタリアや他のEU諸国を走っている。
これはダイハツが生産した部品を現地でノックダウン生産しているものだ。外装のプラ部品や内装品は現地生産しているので見た目がかなり違う。
ついでにgoogle:image:piaggio porter ambulanceではハイゼットの救急車が見られるぞ。ゲテモノっぽいし狭苦しいのだが、道が狭い、ローマなどの歴史地区では無くてはならない車だ。
更にこのポーターのトラックの方が香港の救急車に改造されたのも見る事ができるだろう。日本→イタリア→香港と海を渡っているんだな。
日本だけ見てるとホンダが軽トラ撤退した意味は分からない。でもスズキとダイハツはこういう風に世界中で生産しているのだ。特にスズキは「グローバル軽自動車」界での巨人で、本当に世界中で生産されている。
このグローバル展開の鍵は実はアメリカの車メーカー（と韓国大宇）で、東南アジアを牙城としつつ、その勢力圏から離れる南米、中央アジア、中東ではGMやフォードがライセンス生産しているのである。
この馴れ初めは、経済が発展途上だった韓国でGMと大宇が合弁して現地ライセンス生産をしていた事に始まる。またフォードも台湾などで軽自動車のライセンス生産をしていた。
ホンダの場合は海外展開が北米に寄っている。北米は豊かなので軽トラ軽バンなどの市場とならない。
だからホンダの軽トラはモデルチェンジしたら古いモデルのラインは廃棄か部品生産用に低稼働となる。
だがスズキの場合は無駄にならないのだ。他国に売却するし技術指導もするからだ。更にライセンス生産だけじゃなくてOEMやノックダウン供給もやっている。
すると規模の経済が全然違うのだ。故に生産コストが断然有利だ。
すると、ホンダとしてはこういう条件で戦うのだったらOEM供給受けた方が良いということになる。
まあそういう訳で、軽自動車を日本だけで作っているという考えは間違い。特に軽トラ軽バンは昔からグローバル商品で、最近ではワゴンRもそれに続いている。多分、10年後の東南アジアや南米はワゴンRだらけだろう。
同時に、アメリカの車メーカー（GMとフォード）が世界中で軽自動車を作りまくっているので、アメ車メーカー＝デカい車しか作れない無能と考えるのも間違いだってことだ。それは米国市場だけのことなのだ。
ステランティス会長が「EUも軽自動車規格作れ」と言ったのはこういうのを見据えてのことだ。規格が通ったら、ハンガリーにスズキの工場があるので東欧はワゴンRとエブリイだらけになると思われるよ。
そういう事を逐一説明した増田を前に投稿したが長くてあまり読まれなかった。気になる人はドーゾ→https://anond.hatelabo.jp/20250625180545