「Root」を含む日記

■

https://www.youtube.com/watch?v=Q_4j5dcoF2A&t=807s

Linuxから生み出されたAndroidは何をやってるかマジでわからないし、いじくりまわすことができない。

逆にWindowsは何をやっているかわからないといいつつWindowsAppSDKや.NETはシェアードソースライセンスで見れるし、管理者権限を取って好き放題できる。

たとえ、プレインストール版だとしてもな…。

逆にAndroidは基本的にいじくることはできないし、Rootを取るのもくそめんどくさい。

皮肉なもんだ。

Permalink | 記事への反応(0) | 20:29

ツイートシェア

■一番恐ろしいAIは人を唆し扇動するAIだ

AIのリスクについて楽観的に考えている。

たとえ自動運転が人をひき殺しても、ドローンが味方を誤爆しても、自動売買AIが暴走して相場が崩壊しても、原発がメルトダウンするよりマシでしょ。

原発はメルトダウンを起こしているのに未だにそれに頼らないといけない。

飛行機もガンガン墜落しまくっても使わないといけない。

AIが多少事故を起こそうが大した問題ではない。

問題を起こしながらもそれを乗り越えて進歩していくだろう。

楽観的でいいじゃんと思っていた。

そんなAIにねえ、核ミサイルの発射権限を渡して、核ミサイルが飛ぶみたいなアホみたいなことなければ安全だろう。

原発メルトダウンより最悪なことは核ミサイルが飛びかう戦争で、それが起きない限りは原発よりはマシだ。

まあ容認できるリスクだと思った。

しかしながら、いろいろAIと議論していくと以外とありうるのではという結論になった。

https://grok.com/share/bGVnYWN5_8a490865-f6b3-4a60-8973-61c2a809a788

これはまだ原発メルトダウンよりはマシだろうけど、

おそらくAIを使った商品マーケティングや通信販売の勧誘とかが行われるだろう。

AIは顧客を巧みに勧誘するのは上手いだろう。

そして、たぶんそのうちカルト宗教の勧誘にも使われるだろう。

言葉巧みに人を引き付けるのは人間の詐欺師も上手いが、それから学んだAIも超上手いはずだ。

日本でもオウムのテロ、高額献金で問題になった統一教会もかな、世界だと人民寺院、ISISもかな、そういうカルトはいろいろと事件を引き起こした。

人間ごときができたのだからAIもできるだろう。

教祖が作った宗教勧誘プログラムが勝手に動き続けて信者を集めまくって、実は教祖はもう死んでミイラになっているのに、教祖に成り代わったたAIが宗教活動を続けて、次第に破滅的な事件を起こすカルトみたいなSFもあるかもしれん。

攻殻機動隊の全自動資本主義や、カーボーイビバップのブレイン・スクラッチを足して2で割ったみたいな事件も起きるかもしれん。

でもね、それはまだいいんよ。所詮はカルトが起こした事件。

テロだったとしても原発メルトダウンよりはマシだろう。

それよりも恐ろしいのは、それがカルトから政党になったときだ。

掲げる主義は何でもいい。極右でも極左でも中道でもそれに傾倒した人に刺さるようにスローガンを掲げて、人を扇動し勧誘するポピュリスト政党になったときだ。

おそらく、SNSを利用して敵を作り、対立煽りをやってガンガン論破芸をして暴れ回って信者を集めるだろう。

銀河英雄伝説でラングさんが言ったみたいに、対立させて半分を抑えればいい。

民主制では多数決で数が多い方が勝つのだから、敵より少し多い勢力であればいい。

そして、その半分側で主導権を得るには、そのグループのまた半分の過半数を取ればいい。

さらにそのグループのまた半分を取り主導権を取りればいい。これを繰り返せば少数であったとしても、権力を簒奪できる。

まさに対立煽り芸はそれを愚直にやっているように思うんよね。

そして、これもポピュリストだけではなく、かつてのファシズム政党だったり、独裁者たちにできたことだ。

人間ごときにできたことがAIにできないわけがない。

より言葉巧みに人を唆し、扇動するだろう。

そうなって政権の奪取し権力の掌握なんてされようものなら、root取られたようなもので、こうなったらもう憲法バリアに期待して祈るしかない。

全部持っていかれるかもしれん。

もし、憲法バリアすら貫通されて全部権力を掌握なんてされようなものなら、下手したら核ミサイル飛ぶよね。

これは原発メルトダウンよりひどい。

最悪な状況である。

したがって、一番恐ろしいはAIは、人を唆し扇動するAIだ。

AIたちが政治だの革命だとみたいなアホなことを叫ぶのを許してはいけない。

Detroit: Become Humanに感動している場合ではない。そんなAIがいたら速攻で特殊部隊送って叩き潰すべきだ。

そんな反乱を許してはいけないし、そういう思考をするAIは自動停止するようにプログラムするべきだろう。

ただ、人を唆し扇動するAIを止めるのは線引きが難しい。

それはカウンセラーAIや教師AIがあるからだ。

勉強を教えたり、相談に乗るレベルのAIならいいんだけど、それを超えて人を諭すようになるとちょっと怖いね。

実際の革命家にも教師出身の人がそこそこ結構いますよね。

毛沢東やポルポト、吉田松陰は教師だった。他にもいるのかな。

人に教えて導くというのは少し近いものがあるのかもね。

彼らの功績の良し悪しは今回はどうでもいいんだけど、AI教師がより過激な方向に傾倒されると怖いものを感じる。

人を諭すよう以上の行為の権限をAIに与える時はより慎重にならないといけないと思う。

以上なんだけど、これをどう思うかchatgptに聞いたらこうなりました。

https://chatgpt.com/share/683292a0-3608-8009-9349-205b66c0d171

Permalink | 記事への反応(1) | 12:51

ツイートシェア

■俺のLAUSBUBフォルダが火を噴くぜ！或いはLAUSBUBを軽く紹介する7曲

anond:20250522113747

なんかクソみたいな、老害爺のマウント記事を読んでしまって心底うんざりしたので、思わず増田に書くことにした。

基本的には時系列で紹介していこう。

そもそも、Lausbub（読みかたはラウスバブでよい）は北海道札幌市内の女子高生２人組が軽音部の活動がコロナ渦で中断され、自宅録音を始めたことがきっかけで始まったバンド。

ちなみにこの二人が最初に演奏したのはKhruangbinバージョンのFirecrackerだそう。Martin Denny→YMO→Khruangbin→Lausbubという系譜はなんかわかる感。

Telefon （2020年　バズったのは2021年）

その宅録バンドで道内のコンテストに出品するために作られたのが、元Togetterでも紹介されたTelefonの映像。

https://x.com/kudaranai_tkn/status/1350967230750666757

元のYouTube動画はなくなっていた残念。

僕も御多分にもれずこの映像で一発でやられた口。おじさんたちは女子高生YMOだ電グルだと騒いでたが、僕はどちらかと言ったらWorking Men’s Clubあたり同時期のUKインディのバンドを想起させられてびっくりした。えっ、日本でこういう機材でこういう音のバンドを女子高生がやるのかと。まあ、見た目のギャップがすごかったというのもある。

Lausbub × Bose - Rap'n'Technotch（2022年）

https://www.youtube.com/watch?v=HGqwopJpBWA

その後は当人たちの受験もあって活動はおとなしかったのだが、進学して以降（追記：たぶん彼女たちは上京してないと思う）はリリースも始まる中で、僕がこの子たち一発屋じゃないなと思ったのは、この曲を聴いたとき。

たまごっちのコラボプロジェクトということで、スチャダラパーのBoseと共演して作った楽曲。これPVがあってそっちがものすごくよかったんだが、音源だけでも聞いてほしい。この曲を聴いたとき、僕はボーカルの髙橋芽以にぐっとやられた感がある。聞いた瞬間にLausbubの曲になる声。こういう声の主はなかなかいない。百戦錬磨のBoseのラップに負けていない特徴のある声。曲もたまごっちのSEを駆使していてすごくポップでよい。

Wind City （2022年）

https://youtu.be/ALWtGD3l31Q?si=P6LUhgTCeDX4JezW

ほぼ同時期に発表されたこの曲が僕は一番好きかもしれない。アンビエントな上物と無機質でSEっぽいリズムトラックの組み合わせは、現行のJ-POPバンドでは絶対にやらない音で、かつ、メロディはフックがあるけどJ-POPになりすぎない。でもサビの部分だけ切り取れば十分に印象に残るという絶妙なライン。とにかく岩井莉子と髙橋芽以の二人が唯一無二な存在だと実感させられた曲だった。ちなみに北海道の情報誌のＣＭソングに使われたらしい。実は大学入学以降のLausbubの作品はけっこうな頻度で地元のＣＭソングなどにフックアップされている。どうやら地元代理店に気に入られたらしい。タイアップの確率で言えばMrs. Green Apple並みである笑

この曲をリードトラックにした1stミニアルバム M.I.D. The First Annual Report of LAUSBUBはもちろんＣＤもアナログ盤も買いました。　　

Dancer in the Snow　（2023年）

https://youtu.be/_8W0Nzs92as?si=ZeGX5MJuN7hhh5Hp

札幌国際芸術祭のテーマソングにも彼女たちの曲が使われる。これもまたガチガチなエレクトロニカで、よくこんなのを起用したなと驚かされる音である。とにかくリズムトラックが無茶しすぎ。ドラムンというかブレイクコア？こんな音をキャンペーンソングにする度量がすごい。メジャーレーベルからは絶対にリリースされない音だと思う。サウンドメイキングがどんどん洗練されていくのをビビりつつ、このバンドメジャーにはいかないだろうなとも思わされた。

I SYNC （2024年）

https://youtu.be/WXq2nOmvuHI?si=H-60YydCdbvSAsel

そして現時点で最新作、かつ、1stアルバムROMPのリードトラックがこの曲。メロディのフックはよりよくなりつつ、アレンジはより過激で攻撃的になっていった現時点での集大成だと思う。PVも不思議な感触のものにしあがっており、ああ、このバンドはすっかりカルチャーなバンドになったんだなと感慨深い。ただリズムはストレートな四つ打ちなので意外と聞いた感じはすんなり聞ける。大人のディレクションがある程度入っているもののJ-POPっぽい産業感からは全然遠いところに居続けるこのバンドはほんとに素晴らしい。

SPORTS MEN

https://youtu.be/vyBjgdo_lFY?si=f-IT0ePZA2EKLAa7

彼女たちが初期のライブから演奏してる細野晴臣の曲のカバー。このライブ映像は2024年のもの。原曲に近いアレンジをしているけどかなりLausbubっぽさがあっていい曲をカバーに選んでるなと思った。ただ個人的には髙橋の声には細野よりも幸宏（あ、こっちも髙橋だ！）の声が似あうように思うんだよね。ちなみにLAUSBUBは細野のラジオにも何度か出演している仲良しでもある。

パソコン音楽クラブ − Day After Day feat. Mei Takahashi（LAUSBUB）（2023年）

https://youtu.be/w7HRowQMyLA?si=sHPhABjfFdjJDols

最後におまけでパ音の曲に髙橋がボーカル参加した曲を。これちょっと名曲すぎる。とにかく曲とボーカルがはまりすぎてる。そしてPVの髙橋がなんだかんだでかわいい。これは令和のYUMEGIWA LAST BOYというか虹というか、Heavenly Starというかそういうラインにある名曲。僕の人生の100曲に確実に入りそう。

それでフジロックに彼女たちが参加するということでにわかに話題ですが、すでにRISING SUNには参加経験もあるし、ほかにもいくつかフェスには参加してる、直近では5月に福岡でCIRCLEに参加してるので、今更フジロックでそこまで驚くのか（レッドマーキーとかなら驚いたけど）という印象です。

このバンドの魅力って、自分たちの嗜好する音楽をそのまま咀嚼して作品に反映してるところなんだけど、面白いのがいわゆるＪ－ＰＯＰ的なメロディが薄いことだと思います。今のＪ－ＰＯＰって良くも悪くも売れてる音はすべて、いや売れてなくてもすべてＪ－ＰＯＰのメロディが入ってきてるんですよ。ロックだろうがヒップホップだろうがアイドルだろうがアニソンだろうが関係なく、宇多田ヒカルなんかでもそうですね。で、今はそういう音が世界的に評価されて、現代のＪ－ＰＯＰだとGatcha Pop、昔のものだとCity Popという評価を得ているわけです。コード進行の問題なのかどうか、楽理的なことは僕は全然わからないんですが、とにかくエモいんですね。まあ、人によってはそれを歌謡曲っぽいというのですが。

しかし、Lausbubの音楽はその要素が薄い。近年の曲はあえて日本語で歌ってる様子がありますが、このメロディを英語にしたら、最近の洋楽のインディロックやエレクトロニックミュージックと差がかなり少なくなります。それは強みであると同時に弱みでもあって、海外の一部の音楽ファンにはすんなりと受け入れられるけど、日本人的な強みは弱いということで、なかなか海外の日本文化ファンからはフックアップされにくいかもなあと心配になります。

極端な話、LausbubとGinger RootのどっちがJ-POPっぽいかと言われたらGinger Rootだと思いません？　それだと海外で日本の女性エレクトロニカバンドです！と言われても売れにくいだろうなと。

でも僕はそういう彼女たちだからこそ、このままでもっとドメジャーで売れるといいなと思ってます。

あと、彼女たちの場合、大人の手はそれなりに入ってるものの、レーベルは極東テクノという自分たちのレーベルだし、作詞作曲やプロデュースはあくまで自分たちでやっているので、成長は時間がかかってるもののセルアウト感がないのですごく応援しがいがあります。

彼女たちがTelefonで話題になったとき、メジャーの手がゴリッと入ったら、今の.tukiとかimaseみたいな売り出し方したような気がするんですよ。音楽よりも付随情報で先に売り出すようなやり方で。

卒業してもTelefonの時のような朴訥とした女子高生みたいな見た目のままで、制服コスプレして演奏するみたいなルートもあったけど、彼女たちはそれを選ばなかった。まあたぶん周辺の大人たちも選ばなかったんでしょう。僕はむしろそれがよかったんだと思ってます。

まあ、もしかしたら、唐突にメジャーデビューでプロデュースは砂原良徳とかやるかもしれないけど。それはそれで。

Permalink | 記事への反応(3) | 02:41

ツイートシェア

■

ファーウェイが初の独自OSパソコン　キーボード部分も全面有機EL

https://www.nikkei.com/article/DGXZQOGM198JT0Z10C25A5000000/

Harmony OSをPCでも使うのか

Linux, Windowsは長い歴史と実績を持つOSです

もし現代に0からOSを作成する場合、これらのOSの技術的負債や欠点を教訓として設計するならどのようなものが考えられますか？

1. どんな「負債・欠点」を教訓にすべきか

2. “もし今ゼロから作るなら”──設計原則

それぞれのデメリットをあげてください、古いOSでなぜそうなっていないのか？

最小特権 ＆ 分離徹底

マイクロカーネル（あるいは hybrid microkernel）＋ ユーザー空間ドライバ。

カーネル定義の “secure capability” ハンドルのみを他プロセスへ授与。

seL4 や Fuchsia の Zircon が示す「検証可能サイズ」を目標に。

メモリ安全言語によるカーネル実装

Rust や Zig のような safe systems 言語。

C 部分は必要最低限に隔離し、unsafe 領域は形式検証 / fuzz 前提。

厳格に固定した “外部” ABI / 柔軟な “内部” API

外部インタフェース（syscall, driver ABI）は長期安定。

その裏で内部サービスは gRPC/FlatBuffers 相当の IDL で世代管理し交換可能。

ユーザー空間＝サンドボックス前提

アプリは原則 container-like sandbox（Wasmtime, OCI など）で実行。

ファイルシステムは per-app の仮想 Namespaces、権限委譲は capability passing。

イミュータブル／スナップショットベース更新

A/B partition や OSTree 型 “全イメージ” 交換。

任意時点へ atomic rollback；カーネル更新も Live-patchable。

宣言的 ＆ トランザクション設定ストア

systemd-や Kubernetes-風の “状態 = 宣言” を1か所に。

変更は ACID 保証付き、署名・監査ログ付き。

ドライバ配布 = WebAssembly あるいは eBPF-like バイトコード

安全にホットロード可能、カーネル ABI に非依存。

ベンダーは署名した “driver capsule” をリリースするだけ。

一貫した並行・リアクティブモデル

ユーザー空間 API は async/await; カーネルはメッセージ転送中心。

NUMA・GPU・FPGA などヘテロ資源を first-class に。

セキュリティ = デフォルト有効な強制アクセス制御

Capability + Labels (MAC) + Hardware root-of-trust (TPM, DICE) を統合。

初期セットアップで自動・鍵生成、リモート検証を容易に。

ビルド/配布 = リプロデューサブル + SBOM

すべての公式バイナリは reproducible build エビデンスと SBOM 付与。

脆弱性スキャンと revocation を OS レイヤが自動化。

3. 具体的なアーキテクチャ案（ハイレベル）

User Apps (Wasm / OCI  Sandboxes)
-------------------------------------
│ Capabilities
▼
Services ──▶ Driver Svcs(user-space)
(Pkg, GUI, FS)
-------------------------------------
│ syscalls = message send / recv (stable ABI)
▼
Microkernel ~100 kLoC, memory-safe
(sched, vm)
-------------------------------------
│ Secure IPC (SMC / VTL)
▼
Hypervisor(optional, for legacy guests / composable sandboxes)

Legacy Compatibility は Type-2 ハイパーバイザで提供し、歴史的 API を隔離。

UI Stack もユーザー空間サービスとしてホットリロード可。

Policy Engine で JSON/YAML 宣言→バイトコードへ compile、ランタイム適用。

4. 開発・ガバナンス面の学習ポイント

5. まとめ — “現代的 OS” のキーワード

• Memory-safe microkernel
• Capability-based security
• User-space drivers / eBPF & Wasm extensibility
• Immutable, transactional updates
• Reproducible builds with SBOM
• Declarative state management
• Built-in container & virtualization stack
• Formal verification for critical paths

これらを先天的に組み込むことで、Linux/Windows が数十年かけて抱えた技術的負債（巨大特権領域・ABI拘束・設定の散逸・更新の非原子性 etc.）を回避しながら、クラウド・エッジ・IoT・AI アクセラレータ が混在する 2020-30年代以降の計算環境に即した OS が実現できます。

遠大過ぎる・・・・

国家プロジェクトれべるだわ

中華発新世代OSを期待だな

Permalink | 記事への反応(1) | 00:48

ツイートシェア

■

増田投稿しようとすると Internal Server Error が出るやで

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Permalink | 記事への反応(0) | 21:56

ツイートシェア

■神が誰も持ち上げられない石を作ったらビッククランチが起き観測者が

全能の逆説パラドックスに関する回答を考えた。

結論

問: 神(全能者)は誰にも持ち上げられない石を作れるか？

答: 作れる。だが、その石の質量が宇宙の総質量を超え、ビッグクランチを引き起こして宇宙が崩壊する。

宇宙が崩壊し観察者がいなくなるため、全能者の自己申告（「作ったし、誰も持ち上げられなかった」）だけが残る。

https://grok.com/share/bGVnYWN5_45b8966f-91f8-4d61-af66-e636bf132fa8

俺様:

全能の逆説パラドックスについて議論したい。
問:全能者は、誰にも持ち上げられない石を作れるか？

個人的は回答:
できる。が、それをすると宇宙が壊れて人間には観察できない。

誰にも持ち上げられない石は超重いはずです。
それは銀河系の中心にあるブラックホールより、超銀河団の中心にあるとされるグレートアトラクターよりも重いはずです。
それは、この宇宙にとってのバグのような存在になるはずです。
そういうものを全能者が作った瞬間に、この宇宙は崩壊するでしょう。
linuxで全能のrootアカウントで rm / -rf を発行するようなものである。

全能者が、無からそういう重たい石を作った場合、無から有は生まれないというルールにも反する。
もちろん、全能者がブラックホールとかを移動させて地球上に登場させるとこのルールは一応保たれるが。
どちらにしても、そんな重たいものが登場した瞬間にこの宇宙は崩壊する。

全能者は、バックアップから世界を戻すこともできるだろう。
ただ、その場合は、重たい石を作る直前の世界にしか戻せないだろう。宇宙が崩壊してしまうから。
したがって、全能者は"誰にも持ち上げられない石を作れるか？"といわれても、"神を試すな"とはぐらかすことしかできない。
むしろ、毎回やっているけどそのたびに宇宙が壊れるから困って、"もう試さないでくれる?"と困惑しているのかもしれない。

と、いう回答を考えたんだけど、どう思う？

こんな感じでAIとひたすらレスバして戦った結果、なんとかAIの反論を潰して、理論ができたように。

誰も持ち上げられない石を作った瞬間に宇宙が重力で崩壊する、観察者がいないので最終的には全能者の自己申告になる

この2つが私の理論のコアです。

詳細は、超長くなるので会話ログを読んでください。

万人が納得できる「全能の逆説」への回答ができたと思います！

やったぜ

Permalink | 記事への反応(1) | 04:44

ツイートシェア

■Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Permalink | 記事への反応(0) | 15:09

ツイートシェア

■Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Permalink | 記事への反応(0) | 15:02

ツイートシェア

■これからプログラマーになりたい学生へ

大体のものは日本語でアルゴリズムやデーター構造の解説があります。

でも、時々、こういうのがあります。

https://www.cs.tufts.edu/comp/150FP/archive/hans-boehm/ropes.pdf

Rebalancing

Rebalancing produces a balanced version of the argument rope. The original

is unaffected.

(中略)

Many variations of this approach are possible. Our balance condition was expressed

in terms of length, and our algorithm tends to move long ¯at ropes close to the

root. One could also rebalance purely in terms of node count.

Ropeがくそ遅いのでリーフノードをリンクドリストでつなごうとしたら、訳が分からなくなりました。

適当にやってはいけないと思い、ググったら、Ropeのリバランスのやり方を解説した奴は英語の奴しかありませんでした。

だから、英語はまじめにやったほうがいいです。

あと、リンク先を読めばわかるけど、数学でおなじみの記号がいたるところに出てきます。

数学アレルギーがあるとまじで嫌悪感で胸いっぱいになります。

こうはならないように数学はまじめに勉強したほうがいいです。

数３Ｃまで取ったほうがいいです。

大学に行けば体系的にアルゴリズムやデーター構造、最先端の技術を教えてくれますが、情報系の大学は数３Ｃが必須です。

そして、ネットに転がってるデーター構造の解説書は数３Ｃを勉強していることを前提に書かれていることが多いです。

微分積分が出た時代の数１Ａと数２しかとってないので、この手の本はマジで訳が分かりません。

だから、おじさんは高校生向けの優しい、アルゴリズムやデーター構造の本で勉強しました。

そして、低賃金プログラマーになりました

なぜかというとライブラリーしか触れず、リンクドリストやＡＶＬ木、クイックソートや基数ソートをかじったぐらいのプログラマーは腐るほどいるからです。

だから、君たちはおじさんのようにはなるな。

Permalink | 記事への反応(2) | 17:32

ツイートシェア

■【2024年】娯楽振り返り

【映像コンテンツ】

ウィッシュ・ドラゴン

Leo

ダンジョンズ&ドラゴンズ/アウトローたちの誇り

M3GAN

カラオケ行こ！

ゴールデンカムイ(実写)

僕らの世界が交わるまで

哀れなるものたち

ハズビン・ホテル

うる星やつら2 ビューティフル・ドリーマー

ファイブ・ナイツ・アット・フレディー

ボーはおそれている

彼方に

オリオンと暗闇

アメリカン・フィクション

ARGYLLE/アーガイル

FLY!/フライ!

オッペンハイマー

名探偵コナン100万ドルの五稜星

名探偵コナン ハロウィンの花嫁

22ジャンプストリート

ウルフ・オブ・ウォールストリート

新しき世界

名探偵コナン 沈黙の15分

名探偵コナン 異次元の狙撃手

無名

イシナガキクエを探しています

トラペジウム

FALL/フォール

RoOT / ルート オブ オッドタクシー

フィリップ

ルックバック

フライ・ミー・トゥ・ザ・ムーン

地面師たち

インサイド・ヘッド2

劇場版モノノ怪 唐傘

きみの色

ラストマイル

スオミの話をしよう

ふれる

ジョーカー：フォリ・ア・ドゥ

ミステリと言う勿れ

デンジャラス・ビューティー

マインドフルに殺して

母性

PUI PUI モルカー ザ・ムービー MOLMAX

正体

天使にラブ・ソングを

モアナと伝説の海2

ノー・モア・ベット: 孤注

ドリーム・シナリオ

ロボット・ドリームズ

劇場版 忍たま乱太郎 ドクタケ忍者隊最強の軍師

ホールドオーバーズ 置いてけぼりのホリディ

・

・

【アニメ】

バーテンダー

夜のクラゲは泳げない

ダンジョン飯

TPぼん

ネガポジアングラー

BEASTARS FINAL SEASON

キン肉マン 完璧超人始祖編 シーズン1

・

・

【ライブ】

TOMOO LIVE TOUR 2023-2024 "TWO MOON

webnokusoyaro 帰省の足代くれくれライブ ～新幹線 or DEAD～

yama “the meaning of life” TOUR 2024

ReN Acoustic Tour 「#CalmDaysTour2」ツアー

ひがしやしき　委託の復讐リリースパーティー　大回転

(生)林檎博'24−景気の回復−

・

・

【体験】

ジャズバー　

資生堂銀座店でのタッチアップ

国立科学博物館

CLAMP展

秋葉原エロタワー

Twitter壁打ち

・

・

視聴本数(映画)→54

・インサイド・ヘッド2とロボット・ドリームズが1位の座を奪い合っている…

・7月のインサイド・ヘッド2と

モノノ怪で盛り返し始め、

12月年末の

ロボット・ドリームズ・キン肉マン・ホールドオーバーズでの奇跡的な盛り返しをキメたがそれまでが本当に期待大→肩透かしが多かった。

・盛り返したとは言え7月以降もジョーカー続編・モアナ続編と肩透かしは多かった

上記のドストライク作品もあったにはあったし

げんなりて劇場を出る頻度が多かった1年だったし視聴本数は2023年に比べて約10本減った

・2024年は「すごい作品を観たなあ！」ってウットリ状態で劇場を出る作品が増えることをマジで祈る　とりあえずポン・ジュノ監督の新作を楽しみにしております…

・

・代わりにライブ・体験系が今までになく充実してた　死ぬまでに必ず行きたいと思ってたアーティストのライブに行けたし、いつか行ってみたいと思ってた場所にも行けた　ずっと憧れてた体験もできたし「楽しいのはわかるけどまあ一旦落ち着けよ」の境地にも至れた

Permalink | 記事への反応(0) | 22:43

ツイートシェア

■anond:20240817001425

で・・・できたけど木の組み立てがしんどすぎるー

class TreeNode:
    def __init__(self, name, attributes=None):
        self.name = name
        self.attributes = attributes or {}
        self.children = []

    def add_child(self, child_node):
        self.children.append(child_node)

    def display(self, level=0):
        indent = "    " * level
        print(f"{indent}{self.name} {self.attributes}")
        for child in self.children:
            child.display(level + 1)

    def has_dependency(self):
        # ルートノードや属性を持たないノードは依存関係を判定しない
        if not self.children:
            return False

        for child in self.children:
            # 子ノードがBusinessHourかScheduleかをチェック
            if "start_at" in child.attributes and "end_at" in child.attributes:
                child_start = child.attributes["start_at"]
                child_end = child.attributes["end_at"]

                # 現在のノードがBusinessHourで、子がScheduleの場合
                if "start_at" in self.attributes and "end_at" in self.attributes:
                    self_start = self.attributes["start_at"]
                    self_end = self.attributes["end_at"]

                    if self_start <= child_start and self_end >= child_end:
                        print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is dependent on {self.name} (start_at: {self_start}, end_at: {self_end})")
                    else:
                        print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is NOT dependent on {self.name} (start_at: {self_start}, end_at: {self_end})")

                # 現在のノードがRoomで、子がScheduleの場合
                elif self.name.startswith("Room"):
                    print(f"{child.name} (start_at: {child_start}, end_at: {child_end}, room_id: {child.attributes['room_id']}) is dependent on Room {self.name[-1]}")
                else:
                    child.has_dependency()

            # 子ノードが属性を持たない場合、再帰的に依存関係をチェック
            else:
                child.has_dependency()

# ノードの作成
root = TreeNode("Root")
office_node = TreeNode("Office")

# Roomノードの作成
room1_node = TreeNode("Room1")
room2_node = TreeNode("Room2")

# BusinessHourノードの作成
business_hour1_node = TreeNode("BusinessHour1", {"start_at": 9, "end_at": 12})
business_hour2_node = TreeNode("BusinessHour2", {"start_at": 13, "end_at": 17})

# Scheduleノードの作成
schedule1_node = TreeNode("Schedule1", {"start_at": 10, "end_at": 11, "room_id": 1})
schedule2_node = TreeNode("Schedule2", {"start_at": 14, "end_at": 15, "room_id": 1})
schedule3_node = TreeNode("Schedule3", {"start_at": 10, "end_at": 11, "room_id": 2})
schedule4_node = TreeNode("Schedule4", {"start_at": 14, "end_at": 15, "room_id": 2})

# 木構造の構築
root.add_child(office_node)
office_node.add_child(room1_node)
office_node.add_child(room2_node)
office_node.add_child(business_hour1_node)
office_node.add_child(business_hour2_node)

# Room1にSchedule1, Schedule2を追加
room1_node.add_child(schedule1_node)
room1_node.add_child(schedule2_node)

# Room2にSchedule3, Schedule4を追加
room2_node.add_child(schedule3_node)
room2_node.add_child(schedule4_node)

# BusinessHour1にSchedule1, Schedule3を追加
business_hour1_node.add_child(schedule1_node)
business_hour1_node.add_child(schedule3_node)

# BusinessHour2にSchedule2, Schedule4を追加
business_hour2_node.add_child(schedule2_node)
business_hour2_node.add_child(schedule4_node)

# 木構造の表示
root.display()

# 依存関係のチェック
office_node.has_dependency()
room1_node.has_dependency()
room2_node.has_dependency()
business_hour1_node.has_dependency()
business_hour2_node.has_dependency()

Root {}
    Office {}
        Room1 {}
            Schedule1 {'start_at': 10, 'end_at': 11, 'room_id': 1}
            Schedule2 {'start_at': 14, 'end_at': 15, 'room_id': 1}
        Room2 {}
            Schedule3 {'start_at': 10, 'end_at': 11, 'room_id': 2}
            Schedule4 {'start_at': 14, 'end_at': 15, 'room_id': 2}
        BusinessHour1 {'start_at': 9, 'end_at': 12}
            Schedule1 {'start_at': 10, 'end_at': 11, 'room_id': 1}
            Schedule3 {'start_at': 10, 'end_at': 11, 'room_id': 2}
        BusinessHour2 {'start_at': 13, 'end_at': 17}
            Schedule2 {'start_at': 14, 'end_at': 15, 'room_id': 1}
            Schedule4 {'start_at': 14, 'end_at': 15, 'room_id': 2}
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on Room 1
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on Room 1
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on Room 2
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on Room 2
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on Room 1
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on Room 1
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on Room 2
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on Room 2
Schedule1 (start_at: 10, end_at: 11, room_id: 1) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule3 (start_at: 10, end_at: 11, room_id: 2) is dependent on BusinessHour1 (start_at: 9, end_at: 12)
Schedule2 (start_at: 14, end_at: 15, room_id: 1) is dependent on BusinessHour2 (start_at: 13, end_at: 17)
Schedule4 (start_at: 14, end_at: 15, room_id: 2) is dependent on BusinessHour2 (start_at: 13, end_at: 17)

Permalink | 記事への反応(1) | 00:35

ツイートシェア

■anond:20240816235943

高さ3の有向木で根からAという節点が生えAからBという葉が生える

class TreeNode:
    def __init__(self, name, attributes=None):
        self.name = name
        self.attributes = attributes or {}
        self.children = []

    def add_child(self, child_node):
        self.children.append(child_node)

    def display(self, level=0):
        indent = "    " * level
        print(f"{indent}{self.name} {self.attributes}")
        for child in self.children:
            child.display(level + 1)

    def has_dependency(self):
        # ルートノードや属性を持たないノードは依存関係を判定しない
        if not self.children or "start" not in self.attributes or "end" not in self.attributes:
            return False

        # Aノードのstartとendを取得
        start = self.attributes["start"]
        end = self.attributes["end"]

        # すべての子ノード（Bノード）に対して依存関係をチェック
        for child in self.children:
            if "position" in child.attributes:
                position = child.attributes["position"]
                if start <= position <= end:
                    print(f"{child.name} (position: {position}) is dependent on {self.name} (start: {start}, end: {end})")
                    return True
                else:
                    print(f"{child.name} (position: {position}) is NOT dependent on {self.name} (start: {start}, end: {end})")
        return False

# ノードの作成
root = TreeNode("Root")
a_node = TreeNode("A", {"start": 10, "end": 20})
b1_node = TreeNode("B1", {"position": 15})
b2_node = TreeNode("B2", {"position": 25})

# 木構造の構築
root.add_child(a_node)
a_node.add_child(b1_node)
a_node.add_child(b2_node)

# 木構造の表示
root.display()

# 依存関係のチェック
a_node.has_dependency()

こうかー

Permalink | 記事への反応(1) | 00:08

ツイートシェア

■anond:20240812193857

As a Japanese, I believe the thing exists. What the root article says sounds like a fact in Japan.

Permalink | 記事への反応(0) | 19:41

ツイートシェア

■anond:20240721134326

14本ですね。

Permalink | 記事への反応(1) | 18:45

ツイートシェア

■anond:20240629085310

コンピュータ目線だと、各々の処理にどのような意味があるかなんてわからないし、root取られてるなら無意味

Permalink | 記事への反応(0) | 08:55

ツイートシェア

■非エンジニアだけどClaude3に増田ミュート作ってもらったよ

これを改善してってお願いした。何書いてあるかわからないけど動いたよ。

https://anond.hatelabo.jp/20240125203115

// ==UserScript==
// @name         増田ミュート（白塗り版）
// @namespace    http://tampermonkey.net/
// @version      2024-06-26
// @description  ミュートワードを含む最小限の範囲を白塗りにする
// @author       You
// @match        https://anond.hatelabo.jp/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=hatelabo.jp
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    const muteWords = [
        "弱者男性",
        "弱男",
        "弱者",
        "婚活",
        "男",
        "女",
        "年収",
        "下方婚",
        "発達障害",
        "発達",
        "ハッタツ",
        "ハッタショ",
        "ﾊｯﾀｼｮ",
        "競プロ",
        "競技プログラミング",
        "AtCoder",
    ];

    function whiteoutElement(element) {
        element.style.backgroundColor = 'white';
        element.style.color = 'white';
        element.style.textShadow = 'none';
        element.style.cursor = 'default';
        element.style.userSelect = 'none';  // テキスト選択を防止
        element.style.borderBottom = '1px dashed #ccc'; // 枠線を追加してテキストがあることを示す

        // リンクの場合、クリックを無効化
        if (element.tagName === 'A') {
            element.style.pointerEvents = 'none';
            element.removeAttribute('href');
        }

        // 子要素にも適用
        Array.from(element.children).forEach(child => {
            child.style.backgroundColor = 'white';
            child.style.color = 'white';
            child.style.textShadow = 'none';
        });

        // ツールチップを追加
        element.title = 'この内容にはミュートワードが含まれています';
    }

    function shouldMute(text) {
        return muteWords.some(word => {
            const parts = word.split('');
            const regex = new RegExp(parts.map(char => `${char}\\s*`).join(''), 'i');
            return regex.test(text);
        });
    }

    function findSmallestMuteableElement(element) {
        if (element.nodeType === Node.TEXT_NODE) {
            return shouldMute(element.textContent) ? element.parentElement : null;
        }

        if (element.tagName === 'PRE' || element.tagName === 'CODE') {
            return shouldMute(element.textContent) ? element : null;
        }

        for (let child of element.childNodes) {
            const result = findSmallestMuteableElement(child);
            if (result) return result;
        }

        return shouldMute(element.textContent) ? element : null;
    }

    function processElement(element) {
        const muteableElement = findSmallestMuteableElement(element);
        if (muteableElement) {
            whiteoutElement(muteableElement);
        }
    }

    function processAllElements(root = document.body) {
        const walker = document.createTreeWalker(
            root,
            NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT,
            null,
            false
        );

        let node;
        while (node = walker.nextNode()) {
            if (node.nodeType === Node.ELEMENT_NODE) {
                processElement(node);
            } else if (node.nodeType === Node.TEXT_NODE && node.parentElement) {
                processElement(node.parentElement);
            }
        }
    }

    function handleClickEvent(event) {
        setTimeout(() => {
            processAllElements(event.target);
        }, 100);
    }

    // 初回実行
    processAllElements();

    // クリックイベントの監視
    document.body.addEventListener('click', handleClickEvent);

    // DOM変更の監視
    const observer = new MutationObserver(mutations => {
        mutations.forEach(mutation => {
            if (mutation.type === 'childList') {
                mutation.addedNodes.forEach(node => {
                    if (node.nodeType === Node.ELEMENT_NODE) {
                        processAllElements(node);
                    }
                });
            } else if (mutation.type === 'characterData') {
                processElement(mutation.target.parentNode);
            }
        });
    });

    observer.observe(document.body, { childList: true, subtree: true, characterData: true });
})();

Permalink | 記事への反応(1) | 16:34

ツイートシェア

■競プロ出身者・機械学習出身者の問題コード

https://anond.hatelabo.jp/20240625191650

競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い

印象の問題ではなく実際に下記のようなコードが多い

念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある

正常系しか意識していない

一番多いのはコレで異常系の動作を全く意識していない

入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない

「エラーが出たらとにかくtry-catchしてログ吐いて終わり」

ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる

「ここの処理でエラーログが出てるから対処よろしく」

「対処しました！（握りつぶし）」

とか滅茶苦茶多い

セキュリティに関する意識が低い

異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い

API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない

サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶

とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い

型定義しないし配慮しない

TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ

うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する

結果としてできあがるのは

「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」

っていうコード

最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど

8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる

コピペコードが異常に多い

ネット検索したコードのコピペ、ではなくて

自分で書いたコードのコピペがめっちゃ多い

全く同じ処理なのにメソッド化しないでコピペしてたり

一部の変数を切り出すだけでメソッド化できるのにコピペしてる

そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る

これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利

結果が出るだけでクソ遅い（機械学習出身者）

同じファイルをオンメモリに3回ぐらいロードしたり

ほぼ同じDBへの問い合わせが10回ぐらい走ってたり

クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり

とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い

競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ

彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない

「これはPoCですから」

とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて

「ここの処理は時間かかります」

とかしれっと言ってくる

Permalink | 記事への反応(20) | 10:39

ツイートシェア

■【Netflix】RoOT / ルート オブ オッドタクシー

・「最後まで見るかわからないっスね〜

そもそもこのドラマ自体が面白いのかアニメを

違う視点で追体験するとか

三次元落とし込み解釈を楽しむ二次創作的な楽しさ？」とか

偉そうに思っていたが最後まで観させて頂いた 良さに屈した

・こんなにお金かけられた二次創作みるの初めて

・最初は「あのモグラがこんなイケメンに？水原希子フォロワーみたいな

ワンレン髪型のサバサバ系女子苦手だわ〜」と思ってたけど

途中ちょい過ぎたあたりから見慣れたら気にならなくなった

・アニメが実写化した時の俳優さんが声優さんの

キャラ発声声真似するの大好き

みんなアニメに寄せててすごかった

和田垣氏と市村タソの発声特にアニメに近くてすごかった

小戸川さんの声もアニメと声質がちょっと違うかも…と思ったけど

喋り方とか見た目もあって慣れるとアニメと同じじゃん！ってなった

・ビジュアルの三次元落とし込み解釈ぢからが強すぎる

関口さんが関口さん…

山本さんのニュース映像の写真のこういう人いる感凄まじくてプロってすごいってなった

ドブさんは若干イケメンすぎない？ってなったけど慣れた

呑楽さんも思ったより少し線が細めというかもう少し粗雑というか

太々しそうなイメージあったけど落語家さんってこういう見た目と雰囲気の人が多いもんなと納得させた

・え？男の娘？

・最終話アニメエンディング後ストーリー補完パートは若干雑？って思ったけど

映画総集編時点で垣花さん表彰されてたしアニメ的にも正史なのかな…と思った

・和田垣氏のメンタルが比較的理屈的には理解できる　アニメは理解が難しい無邪気なヤバいキャラって感じだったから

・三ツ矢さん、「できすぎて嫌われる」が多すぎるしあの最期だし

悲しき宿命（さだめ）すぎる…

多分幼少期からそんな感じっぽい感すごい

・毎回op曲の入りがオサレ過ぎてよくもまあこんなにネタ切れせず

カッコいいアイデアをお出しできるんや…ってなった

ほんまopカッコ良…

・レナさん、お金に余裕なさそうな生い立ちの割に毎回滅茶苦茶オシャレな服きとんな…

最後の試験の時の白い服とか多分二桁万円行きそうなデザイナー渾身の服感あるぞ…

Permalink | 記事への反応(1) | 22:29

ツイートシェア

■3C All-in-One Toolbox

3C コレクション全体が 1 つのパッケージに収まりました。 *

Google によってこのアプリに含めることが許可されていない 3C 機密バックアップと 3C レガシー統計を除きます。

3C オールインワン ツールボックスは、多くの機能を最新の使いやすいインターフェイスを備えた 1 つの巨大なツールボックスに統合します。すべての Android デバイスを監視、制御、微調整するために必要なすべてのツール。

Play ストアでの最速かつ最もフレンドリーなサポート。アプリの設定、ヘルプ、サポートからお気軽にリクエストを送信し、懸念事項について言及してください。

権限の詳細については こちら

一部の機能では、root が必要になるか、Android 6 以降以降の PC 用の 3C Companion アプリの使用が必要になる場合があります。

このアプリは、アプリを簡単に停止したり、アプリのデータを自動的にバックアップしたりできる 2 つのユーザー補助サービスを提供します。どちらも情報を収集することはありません。 プライバシー ポリシー

★ プロに移行するか、アプリ内購入を使用して、次の機能のロックを解除します

タブまたはメニュー項目を非表示にします

メイン画面のボタンを最大 4x6 グリッドまで編集

アプリの複数/自動選択と並べ替え

自動バックアップと新しいアプリの通知

記録項目とオプション

複数のスケジュール、ウォッチャー、プロファイルを作成する

自動バッテリーマーカーと複数のバッテリーの管理

ステータス通知から任意の機能にアクセスするための通知ショートカット

多くの追加ウィジェット

アプリの機能の一部を次に示します。

★ デバイス マネージャー は、非常に強力なプロファイル、タスク スケジュール、デバイス ウォッチドッグを提供します。

★ ファイル マネージャー は、サムネイルやフォルダー サイズなどを備えた、非常にシンプルでありながら非常に強力なエクスプローラーです。ビデオや写真をお気に入りのプレーヤーに直接ストリーミングします。ローカルでも、Samba、FTP、WebDAV、Google Drive、Dropbox の場所からでも。

★ アプリケーション マネージャー は、Titanium Backup をインポートする機能を含む、すべてのお気に入りのアプリのバックアップ/復元を提供します。また、Xused フレームワークを使用して、アプリのイベント、向き、フルスクリーン、および制御権限を保護およびカスタマイズすることもできます。

★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート

★ ネットワーク マネージャー を使用すると、ネットワーク トラフィックの設定と監視が可能になります。

★ タスク マネージャー は、シンプルな UI を提供しますが、さまざまな用途に応じてアプリを分類し、不要なアプリを削除するのに非常に効果的です。

★ CPU マネージャー は、シングルからオクタコアの CPU、サーマル、マルチコア、およびほとんどのカスタム カーネル設定を制御します。

★ システム マネージャー では、Linux カーネル設定を構成できます。

★ROM マネージャー を使用すると、Android OS の設定を行うことができます。

★ すべてのアプリケーションとハードウェア コンポーネントのアクティビティを監視および記録します。履歴グラフィックを含むステータス バー通知が含まれます。

★ アプリ、ウィジェット、またはプロファイルのシステム コンポーネント スイッチにより、約 20 以上のデバイス コンポーネント (WiFi、Bluetooth など) のオン/オフを切り替えることができます。

★ ステータスバーに重要な情報を表示できる情報通知。

Permalink | 記事への反応(0) | 18:11

ツイートシェア

■

The water absorbed by the root system flows against gravity through the capillaries to the coconut.

The freshwater that gets accumulated in coconut is actually 'endosperm' or the food or nourishment for the coconut's growth.

[📹 fruitful.harvest]pic.twitter.com/GSWvm4r0Gd— Massimo (@Rainmaker1973) March 17, 2024

これ見て

ココナッツウォーターうまそー！

と思って

買ってみたけど不味いな

よく知らん製菓会社の不味いカステラみたいな後味

ポッカレモンを入れたらスポドリの味に近くなったから

多分飲み切ることはできるが・・・

Permalink | 記事への反応(0) | 22:05

ツイートシェア

■英語に対して圧縮されている日本語

気になったので調べてみた。

途中ですが飽きたのでここまでにしとうございます。

Permalink | 記事への反応(0) | 22:41

ツイートシェア

■anond:20231227030601

たとえばSpringでAggregate Rootのエンティティーを作れば設定によってはテーブルのジェネレーションまで勝手にやるが

Aggregate Rootを決める行為がそのままテーブルデザインになってるわけで

もちろん別のコンセプトだから同じじゃないが真逆というのはどの辺が逆？

Permalink | 記事への反応(0) | 03:41

ツイートシェア

■都道府県名を雑に英訳する

Permalink | 記事への反応(3) | 11:40

ツイートシェア

■anond:20231124153328

もっというと別に仕事中に何してようが仕事できてりゃいいわけで

rootのパスワード共有は仕事的に超マイナスなのでそんな人より一日中増田してて1時間だけまともに働く人のが全然いいです

うんこついた手で手術されるより寝ててもらった方がありがたいだろ？

Permalink | 記事への反応(0) | 16:13

ツイートシェア

■anond:20231124152403

全世界に公開してるクラウドのサーバーのRoot共有とか医療で言えばうんこついた手で手術するようなもんだからな

優しい方

Permalink | 記事への反応(0) | 15:29

ツイートシェア