  |
はてなキーワード: アーキテクチャとは
2022年9月中旬に注目を集めた、艦これと舞鶴市、来年の2023年に予定されている市長選挙に関わるお話をまとめました。
事情をよく知らない人にも分かるように書いているため長いのと、当時深掘りした人にはあまり新しい情報はないと思うのでその点もよろしくお願いします。
京都府舞鶴市は2023年2月に現市長の任期が終わり、市長選があります。
それに関わり、既に立候補を表明している松本隆さんという人がいます。
こういう話に個人名を出すのはあれかなとは思ったのですが、公人になろうという人ですし公開情報なのでいいかなと思い直しました。
さて、この松本さん、「やばいぜ舞鶴 森本たかしならこう変える！」というYouTubeチャンネルを開設していまして、日々動画を投稿されています。
このチャンネルで9月中頃に投稿した動画が軽く炎上したことで、にわかに一部界隈で注目されました。
いわく、舞鶴市には古くから海軍文化があり、KADOKAWAは「艦隊これくしょん -艦これ-」というコンテンツで文化盗用をしていると。
にも関わらず、森本さんの尊敬する「Aさん」に対し、知財の侵害をやめるよう警告書を送りつけたと。
私は森本さんの動画に「それはKADOKAWAの方が正しいのではないか」という趣旨でコメントをしていたのですが、この度ブロックされ、コメントができなくなりました（正確に言うとできることはできるのですが、YouTubeの仕様上自分以外は森本さん含め誰も読めないのです）。
そこで、備忘録がてら今回のことをまとめておこうと思いました。
なにぶん市長候補とその周辺の不祥事なので、公共性があるものと考えています。
特定の個人や団体を批判的に扱っていますが、憎悪を煽る目的は一切ありませんのでよろしくお願いします。
*固有名詞がたくさん出てきますが、見やすさを優先し、初出の場合やおおむね5文字以上の長いものにだけかぎかっこを付けています。
とても長いので1行でまとめると、舞鶴には艦これのIPを勝手に使って地域振興を目論む人たちがいて、そのお仲間の森本さんが市長選に出馬しますよ、というお話です。
Aさんに警告書を送ったKADOKAWA（厳密にはグループ会社の角川アーキテクチャ）ですが、2013年から「艦隊これくしょん -艦これ-」（以下、艦これ）というゲームをEXNOA（旧DMM GAMES）のプラットフォームで展開しています。
ゲームやアニメのファンであれば、触れたことはなくても名前くらいは知っているでしょう。
そして「砲雷撃戦！よーい！」という、艦これのオンリー同人イベントがありました。
さまざまな地域で開催されたイベントで、舞鶴も会場の1つだったのですが、2021年3月のイベントを最後に現在は廃止となっています。
廃止の理由は公開されていませんが、舞鶴市内で別の同人イベントは開催されており、別の地域で艦これの同人イベントは開催されており、「砲雷撃戦！よーい！」運営の別のイベントも開催されていることから、「砲雷撃戦！よーい！」だけの事情があったと推測されています。
同人イベントとは、主に個人が制作した作品で一般流通では販売しない（できない）ものを会場限定で販売するというイベントです。
原作なしのオリジナル作品だけを扱う同人イベントもありますが、現在どちらかと言うと主流なのは二次創作、つまり既存の作品をモチーフにした作品を扱ったものでしょう。
オンリーイベントは、参加者が全員同じモチーフを使うというルールを設けたイベントです。
イベントではコスプレのように本やグッズ制作以外で参加できる場合もあります。
既存作品をモチーフにする以上当然なのですが、二次創作は原則として著作権を侵害します。
しかし、同人イベントで販売される二次創作作品は見逃される傾向にあります。
こうしたイベントがクリエイティブな人材を養成する場になっている面があり、多くの版元がそれを尊重しているからです。
権利者側がガイドラインを示し、その範囲で二次創作を認めると宣言している場合もあります。
ガイドラインがない場合は目安すらありませんが、版元が問題視すれば著作権侵害等を問われることになります。
そのためOKとNGの境界はあいまいで、二次創作活動は「版元に怒られないようにしよう」が大原則になります。
常に議論のある部分ではあるものの、建前として「ファン活動であって営利目的ではない」というものがあり、二次創作では作品の「販売」ではなく「頒布」という言葉を使うことが多いようです。
往時の「砲雷撃戦！よーい！」は大変大きな盛り上がりを見せ、開催期間2日でのべ1万人以上を集めたこともあるようです。
最盛期には周辺のホテルが満室になり、地域を走る電車がイベントのために増発するという事態にまでなりました。
ここまで盛り上がった要因の1つとして、地元商店街の協力がありました。
会場のすぐ近くで屋台村を形成し、地元の美味しいものを提供したのです。
最高じゃないですか。
ところが、ここで1つ問題が発生するのです。
するとこの屋台村、艦これに便乗して商売している、法律用語で言うと「冒用」しているのではないか？という点です。
ごく初期は、これを誤魔化すために「同人イベントをやっていたら、たまたま近くに屋台村が出ていた」という体裁でいたと記憶しています。
ところが、いつからか2つは一体化し、「砲雷撃戦！よーい！」は屋台村をイベントの売りの1つとして扱い始め、同じポスターで案内までするようになりました。
ここで出てくるのが「舞鶴クリエイティブアソシエーション（MCA）」というNPO法人です（マカと読むそうです）。
MCAは2014年2月に開催された「砲雷撃戦！よーい！」のにぎわいを見たTさんとMさんが発足した団体です（私人なので一応イニシャルにしておきます。MCAを調べればすぐ出てきますが）。京都府への登録は2015年7月になっています。一応、地域振興や文化振興を目的としたNPO法人ですが、ネット上に残っているインタビュー記事などを読む限り、発足のきっかけは「砲雷撃戦！よーい！」です。
このMCAが地元の事業者を誘い、「砲雷撃戦！よーい！」に併設する屋台村を作ったというのが実情のようです。
なかなか凄いな、と思ったのが、府に提出した活動報告書に堂々と「艦隊コレクションイベント」と記載していることです。
あれ、同人イベントなのでKADOKAWAの許可は取ってないですよね？なんでNPO法人の活動報告にゲームタイトルが出てくるんですか？しかも表記が間違ってる？
さらによく見ると「従事者の人数」という項目に「10人」とあり、MCAから人が派遣されていたことが分かります。
ちなみに「砲雷撃戦！よーい！」の名前も出てくるので、「艦隊コレクション」であって「艦隊これくしょん」ではないという言い訳はできないですね。
また、「砲雷撃戦！よーい！」の前夜祭を委託事業として請け負って20万～30万円前後の報酬を受け取っているので、完全に艦これの名前を使って商売をしてます。
この時点でMCAによる知財の侵害がほぼほぼ確定したと言ってよいかと思います。
ゲームのキャラクターを第三者が描いていれば著作権のうち翻案権の侵害になるでしょうし、艦これの名前を使って人を集めてイベントを行うのであれば不正競争防止法に抵触するでしょう。
森本さんはTwitterで「私達の知識レベルでは一線を超える事は無いとは思います」と仰っていましたが、まあ嘘ですよね。
他社のIPを勝手に使って商売していいなんて法理はありません。
余談ですが、IP（知財、知的財産）は著作権法や商標法、不正競争防止法などいくつかの法律で守られるものをまとめた広い概念です。
今回の件は著作権だけでは語れないため、このワードがたくさん出てきます。
もう1つ余談として、艦これ公式は「砲雷撃戦！よーい！」について発信したことはほとんどありません。
会場でのトラブルで逮捕者が出たという報道があった際に「これは…無許諾の非公式な催しですね。企業が関係しているでしょうか。であれば、問題ですね。少し調べてみましょう。」とツイートしていただけです。
「砲雷撃戦！よーい！」廃止の情報が流れたのはその約9ヶ月後なので、公式もそれまで全く知らなかったということはないだろうと思いますが、この事件が介入の呼び水になった可能性はあるかと思います。
当初メディアに「艦隊これくしょんのイベントで…」と報じられたので、いい迷惑だったのは間違いありません。
MCAがアウトなら「砲雷撃戦！よーい！」もアウトなのでは？という素朴な疑問が生まれると思います。
結論としてはそうなると思いますが、実はもう少し面倒な背景があります。
艦これ運営は2013年の頃から二次創作やIP利用に関するガイドラインを出しています。
正式な文書にはなっていませんが、DMMプラットフォーム内や公式Twitterアカウントで発信したものなので、正式なものとして扱うのが正道でしょう。
このガイドラインでは、個人が楽しむ範囲（同人活動）で、他人や他社、運営等関係者に迷惑をかけなければ黙認するということになっています。
一方、法人や自治体、団体が利用する際は必ず運営に相談するように、としています。
MCAと「砲雷撃戦！よーい！」は、片方は法人、もう片方は個人と両方の要素を持っています。
つまり、MCAの屋台村と「砲雷撃戦！よーい！」が一体になった場合、同じイベントでありながらガイドライン上は屋台村はアウト、「砲雷撃戦！よーい！」はセーフということになります。
まあ、実際は半分だけアウトとはならず、アウトの要素を持っている時点で個人側のガイドラインの「迷惑をかけない」に抵触するわけで、結果的に「砲雷撃戦！よーい！」そのものが廃止となったのは当然と言えば当然のことでした。
冷静に考えればNPO法人が他社のIPを勝手に使って活動をしていいはずがなく、どうしてKADOKAWAにお伺いを立てなかったのかという疑問は残るのですが、残念ながらそうなってしまったのです。
MCAの知財関連の知識や運用はあまりにお粗末で擁護のしようがないのですが、1つだけ気の毒に思うのは、最初に触れたのが「砲雷撃戦！よーい！」という同人イベントだったことです。
実際のところ、MCAが利用したかったのは艦これのIPではなく、舞鶴市内に市外の人が集まっているという状況だったわけです。
実際に人を集めていたのは「砲雷撃戦！よーい！」だったので、手を組むならこちらだという発想を持ってしまったのは仕方がないことだと思います。
問題は、艦これがKADOKAWAのIPであるということは当然分かっていたのに、冷静になってIP侵害であるということに向き合えなかったことです。
同人イベントを隠れ蓑にしているから安全だと思ったのでしょうか。
一緒に盛り上げた以上「砲雷撃戦！よーい！」は仲間であり、仲間を裏切ることはできなかったということでしょうか。
それとも、ここまで大きく育てたのだから、版元と言えども奪うことはできないという奢りがあったのでしょうか。
結果、（おそらくKADOKAWAの介入により）全てを失ってしまったわけです。
ただ、MCAは「砲雷撃戦！よーい！がなくなっても同人イベントとの協業を諦めなかったようで、その後は2019年から始まった「舞鎮駆逐隊」というイベントに傾倒していたようです。
この「舞鎮駆逐隊」は後でまた出てきますが、今年9月に6回目の開催を目前にしてKADOKAWAから盛大に怒られて中止になり、主催者は今後艦これのイベントを行わないと誓約させられました。
そしてこの中止になったイベントのサークルスペースに、MCAの内部組織である「舞鶴鎮守府実行委員会」が割り当てられていました。
KADOKAWAと「舞鎮駆逐隊」の間でどんな交渉が行われたのかは分かりませんが、MCAが絡んでいたことを責められた可能性もないとは言えないのではないかと思います。
もっとも、それ以前に「舞鎮駆逐隊」は主催によるイベント内外におけるグッズ販売が問題視された可能性も高く、確かなことは分かりませんが。
（イベント主催は個人でやるには負担が大きいので、組織を作る、法人が主催になるというパターンが多く、主催が二次創作グッズを販売する＝同人活動の枠を超えたと判定されるリスクが高くなります。）
中編に続く
増田やTogetter、NHKに寡占されているはてなブックマークだが、めったにブクマされないサイトからホットエントリ入りしてくるウェブページはとても面白いコンテンツなんじゃなかろうかと思って調べてみた。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2882 | 【アメリカで話題】ただ座るだけ！股関節がみるみる柔らかくなる「90/90ストレッチ」 ｜ ヨガジャーナルオンライン | yogajournal.jp |
| 1526 | 共感格差 | shioshio3.hatenablog.com |
| 1440 | きゃりーぱみゅぱみゅの 「大人なLADYになるわよコラム」第35回〜『マネーの虎化してるわよ』〜 | hanako.tokyo |
| 1109 | 米津玄師氏の担当の方から連絡がありました。｜つんく♂ | note.tsunku.net |
| 1002 | ちょうどいいWebデザインギャラリー | choooodoii.com |
| 939 | 記念日、赤ちゃん連れ等には向いていません - 星野リゾート リゾナーレ熱海の口コミ - トリップアドバイザー | www.tripadvisor.jp |
| 887 | 【股関節がガチガチに硬い人向け】可動域を無理なく広げる！"揺らすだけ"股関節ストレッチ ｜ ヨガジャーナルオンライン | yogajournal.jp |
| 795 | おいでよ 広告の沼 ｜ 昭和の雑誌広告を中心に | www.citymilk.net |
| 670 | スプラトゥーンの特許 - naoya2kの日記 | naoya2k.hatenablog.com |
| 659 | ネイティブが使うビジネス英語：株式会社日立システムズ | www.hitachi-systems.com |
| 615 | 株式会社リクルート エンジニアコース新人研修の内容を公開します！（2022年度版） | blog.recruit.co.jp |
| 598 | 「1年かけたマンガが、らくがきに負けた」上を見るよりも自分の評価を見る ／カレー沢薫の創作相談 | www.pixivision.net |
| 578 | 書評『つみたて投資の終わり方』取り崩し方考察 - FIRE: 投資でセミリタイアする九条日記 | www.kuzyofire.com |
| 578 | 有志と #ソフトウェアテスト読書マップ を作りました！ - ソフトウェアの品質を学びまくる2.0 | www.kzsuzuki.com |
| 570 | 世紀の謎「カーリングはなぜ曲がるか」を精密観測で解明 ｜ 立教大学 | www.rikkyo.ac.jp |
| 558 | AMD × 藤井聡太 ｜ 「神の一手」の裏側に。 ｜ AMD | fujiisota.amd-heroes.jp |
| 535 | ウェブ制作で React(Next) や Vue(Nuxt)、jQuery が最近どれぐらい使われているのか調べてみた - feb19 | feb19.jp |
| 481 | しみけんの妻・はあちゅうさんに訴えられましたが勝ちました - ゲスで怠惰なブログ | gesugesumi.hatenablog.com |
| 465 | 【海外アニメ】恐怖！ディズニープラスクソダサロゴ展覧会！【カートゥーン】 - コウタロー速報 | kotarodayo1126.hatenablog.com |
| 463 | 22/9/17 小二で全国模試一位を取った男の半生 - LWのサイゼリヤ | saize-lw.hatenablog.com |
| 461 | 「部分的」動員がロシア社会に及ぼす影響 | rusbureau.net |
| 450 | 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ ｜ コーソルDatabaseエンジニアのBlog | cosol.jp |
| 433 | 外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog | product.10x.co.jp |
| 425 | “統一教会”と性教育（前編） | www.knb.ne.jp |
| 400 | 「水着でも男女混浴不可？」の東京都の条例についてあれこれ調べたら面白いことになってきた。 - ヨッピーのブログ | yoppymodel.hatenablog.com |
| 398 | 元・電通マンが地方公務員に転身。湘南から岡山に移住して5年でいまだ感じる4つの葛藤 ｜ OCEANS オーシャンズ｜男の日常を楽しくする情報発信局 | oceans.tokyo.jp |
| 397 | Fit Boxing北斗の拳（フィットボクシング北斗の拳）｜ Nintendo Switch | fitboxing.net |
| 397 | 【睡眠改善の手順】睡眠時間を正して、質を高める | kaimin-times.com |
| 393 | VSCodeをメインのエディタにして半年たったので入れてある拡張機能を紹介します - 壁に飾られた絵画を見ようとしてその絵に近寄ってはいけない | blog.ayako-m.work |
| 393 | キリン、電気の力で塩味・旨味を増す「エレキソルト」。対応カトラリーを2023年発売へ | gourmet.watch.impress.co.jp |
Amazon Clitoris (ACR) は、伝統的なCRを発展させ、より現代のソーシャルアーキテクチャに最適化することで、センシティビティ、アベイラビリティ、レスポンシビネスを向上させ、より豊かなオーガズム創生のソリューションを提供します。
ACRは伝統的なオーガニズム機構をエクステンドし、従来のMNKをセキュアに保ったままACRを直接操作することでコンプライアンスを維持しつつ、瞬間的、または制限された時間以内にオーガズムを発生させることを保証します。
周辺技術である DMM、FANZA、SOD、一部PIXIVなどの既存技術と組み合わせることで、より深く味わい深い体験を構築することができ、業界をリードするオーガズム・クリエイター的世界最高峰の技術を提供します。
また、ACRでは従来、複雑で煩雑なプロセスであったコンプレックスアクメジェネレーションが、シンプルかつイージーに発出され、セーフティーでハイクオリティのオーガズム創出が期待できます。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
以下自分語り。
WEB系事業会社で15年ほどWEBエンジニアやってたけど（転職3回）、色々あって結局SESやってる。SESといってもフリーランスだけど。
「事業会社で技術力でコミットして社会に貢献」なんて若い頃は思ってたけど、よっぽどいい会社に勤めない限り数年でそんな意識の高さはなくなる。
はてな界隈じゃやらたキラキラした退職ブログばかりポストされるけど、退職ブログ書かない（かけない）自分のような雑魚エンジニアは大体こんな感じになりがち。
この界隈がやたら転職多かったりフリーランスが多かったりするのはこういうのが多いから。
普通レベルの技術力があれば転職なんか楽勝だし、フリーランスはもっと楽勝。
むしろ会社員であるメリットは殆どないし（社会保険が安いぐらい）、会社の事業都合やら社内政治やらに付き合うのが面倒になってフリーランスになる。
フリーランス（という名の派遣）に社畜根性を求めてくる現場もまれにあるが、次の契約更新でサヨナラすればいいだけの話である。
自分はWEB系しか経験なくSIがどうなのかはよくわからんけど事業に直結するWEB系ですらこんななので、レガシー大企業が基幹システムを内製しようとたところでWEB系以上に漂流するプロジェクトとエンジニアが増えるだけだろう。
形だけ内製にしながら、事業部門営業部門がお客様感覚で開発部門を下請け化してブラック化->退職者続出する未来しか見えない。
あの野村證券も野村総研使わず日本IBMつかって開発失敗した挙げ句訴訟に負けている。グループ会社に使えてないのに内製化なんか出来るわけない。
読者諸兄にDECという名前の会社を覚えている人はいるだろうか。
ミニコンの名機と言われたVAXを世に出し、結局のところそれが理由で潰れた(正確には買収された)メーカーだ。
要は
その後しばらくしてWindows95の登場と、それをPCで十二分に動かすことを可能にしたPentiumプロセッサが、それまでの状況を決定的に塗り替える結果となった。
そしてカトラーはMicrosoftに引き抜かれてWindowsNTを開発し、後にこれがWindows系OSのメインストリームになったと。
この流れの背景には、MicrosoftとIntelによる革命的なパラダイム・シフトが大きいと思う。
すなわち、従来のコンピュータにおいてソフトは「ハードのおまけ」でしかなかった。
それをビル・ゲイツは
「将来のコンピュータはソフトの出来不出来こそが最も売上を左右する。ハードは優れたソフトを動作させるための部品でしかない」
と予測し、PC用プロセッサを作っていた「マイコン屋」Intelもこれに賛同したと。
そして賭けに勝った。
親友だったジョブズの影に隠れがちとはいえ、ビル・ゲイツもまたこの一点だけ取っても恐るべき慧眼であり、偉大な人物だと思う。
ジョブズといえば「完璧で美しいけど高い」Macintoshの売上がさっぱりだったことを踏まえ、Windowsは「そこそこの値段でそこそこの性能」を落とし所にしたのも巧い。
とはいえ、MSとIntelに何も不安がないといえば嘘だろう。
MSはモバイル分野では今なお見る影もない。ぶっちゃけPCが廃れたらヤバくない？という。
IntelはIntelで64bitアーキテクチャの主導権とZenアーキテクチャの大ヒットにより、少なくとも過去2回AMDに敗れている。
それも開発したのは俗に言うスーパーハッカーとかスタープログラマとかではなく、当時全く無名だった大学院生。
だから開発の目的だって、勉強のためかお遊びなのかもよくわからない話だったり。
そこに来て、型落ちロースペックPCでも動かせるフリーのUNIXライクOSとなると、今だったら
みたいに冷笑されかねない話だ。
実際リリースされて間もない1990年代後半から2000年前後辺りまでは
「流行の追っかけしか能がない、ワナビーのクソガキ共が使うおもちゃ」
くらいの立ち位置だった。
当時流行っていたネットスラングに類似する煽り方をするなら「アンチMS厨御用達」みたいな感じだろうか。
「そんな事があったんだー」
で終わるくらい、Linuxは誰でも、どこでも使うOSになっているのは御存知の通り。
UNIX系OSで最もメジャーと言うだけではなく、システム開発やサーバ構築でWindowsサーバとともにほぼ必ず選択肢に挙げられるようになって久しい。
更に直近の10年で、気がつけば世界中で使われているスマホの殆どがLinuxベース(Android)になっている。
つまり誕生からの四半世紀で爆発的に発展・普及したというわけだ。
本当にLinuxを使うなんて今どき普通すぎて、特に取り立てて言うことではない。
一方でLinuxよりもずっとフリーUNIXとしての歴史があり、かつては定番だったBSD系なんて、今やAppleのお陰で辛うじて延命している状態なのだから、これまた隔世の感がある。
とはいえ気になるのは、何をどうやったらここまで信じがたい躍進をしたのか？という事情。
ホビー用途とビジネス用途では要求される信頼性のレベルが異なるので、誰かがそこに手を入れないとこのような発展は望めない。
そこでは大企業がきちんと専門家を入れる形で関わるならなお良い。
そうなるとやはり、まずIBMが白羽の矢を立て、次いでGoogleが積極的にコミットするようになった流れが大きいのだろうか。
このうちGoogleは「弊社はオープンソースにフリーライドしているわけではない」アピールや自社サービスのコストダウン、更にはモバイル分野への進出という諸々の目的に好都合だったのだと思う。
何しろ元々IBMはAIXという自社製UNIXを売ってる会社であり、これを用いた各種サーバ構築はお家芸だったわけで。
更にこのAIXにDB2やWebSphereを組み合わせる方式は、2000年代くらいまではエンタープライズアーキテクチャの2大巨頭だった。
(もう1つはSolaris+Oracle+WebLogic)
そんな会社がLinuxに手を出して、一体何の得があるんだ？という話なわけ。
一つ考えられるとすれば、AIXもDB2もWASも買えない貧乏人もとい中小規模の顧客から、せめて構築と運用の手数料だけでも取るためとか？
まあ確かに一時期流行ったLAMP(Linux+Apache+MySQL+PHP)なら、ライセンス料なしでハードも安価なPCサーバになるので、導入のハードルは低い。
というわけでLinuxの草創期を知ってる人間からしたら、今の状況は世の中が変わりすぎなくらい変わったという感覚が強い。
Androidの不具合がスマホのメーカー依存or機種依存だったり、そもそもLinuxのデスクトップ用途が未だに少数派なのは今後も変わらないだろうけど、逆に変わらないのは多分それくらい。
あとUbuntuは嫌い。
AEDは日本語で自動体外式除細動器と言うんだけど、除細動器にはプロ（医療向け）と一般（非医療従事者向け）の製品があるよ。
AEDはこのうちの一般向けの製品の事だよ。Aはオートマチックの意味。
医療向け製品は心電図モニタでの監視が行われている事が前提だから単能型で普通の電化製品のようにスイッチを入れると電撃が起きるよ。
一般向けは必ず診断モードが付いてて、蓋を開けると自動的に起動、コンデンサへの充電、電極パッドを付けると診断モードになるよ。（電源ボタンがある機種もある）
だからAEDを使うべき状態かどうかは機械が勝手に判断して実行するから「AED使用すべきじゃなかった状態なのに使用した」という事は起きえないよ。
蓋開ける（IOボタンを押す）と起動して音声ガイダンスが始まるよ。その通りに心臓マッサージしたりパッドつけたりすればいい。付ける場所はパッドや本体に大きく描かれているよ。
自動診断が終わってAEDが必要と判断されたら「全員手を放してショックボタンを押す」と言われるので押すと電撃が発生して患者の体が大きく痙攣するよ（結構ビビる）。
で、バッテリーの問題があるから10年も20年も使えるわけじゃない。使用した事なくても交換が必須なんね。これは消火器と同じやね。
低周波治療器みたいにヌルヌルの導電パッドが付いているんだが、これは数年で経年劣化でダメになる。でもリースだとパッドの交換もしてくれるし、本体も耐用年数で交換されるからバッテリー問題も考えなくていいし本体も新しい製品に更新されていく。
リース料は1万弱/年くらい。
でもリチウムイオンバッテリー+コンデンサ+心電図診断ソフトの組み合わせの製品だからもっと安くできるはず…って事で最近だと10万を切る製品も出てきてるらしい。
AEDは心臓が細動、つまり痙攣しててポンプの働きを無してないって時にフルスイングのビンタを心臓にかます機械だ。
心電図モニタがフラットになるのでこの瞬間は結構ビビるし初めて見たら油汗出るよ。
でも大丈夫。脳が規則的に心拍信号を出してるから、それに従って心臓も規則的に動き出す。時間にして1～2秒程度なんだが、初めて見ると永遠に感じるほど。
AEDや心マが遅れると脳がダメージを受けてしまってこの信号が来なくなっちゃうのだな。だからAEDは早くやらんとだめって事なんであるな。
最初の生物は心臓なんてなくて体を動かす→体液が動くっていういい加減なシステム
↓
体大きくすると体液循環量が足りんぞ→せや体動かさない時でも勝手に動いてる箇所を作りゃいいんや
↓
さっき作った醤油チュルチュルの握るとこの前後にストローさしたら効果あがったやん天才やんワイ
↓
そうや醤油チュルチュル握るとこの前後にワンウェイの弁付けたらもっと効果アップや
↓
握るとこを思いっきり握っても握りに吸入する時になかなか入っていかんで効率落ちちゃうんやんけ。予め圧が高くなってればあっというまに充填されるのに
せや握るとこの真ん中にも弁付けたら低圧圧縮→高圧圧縮で効率アップするやん
↓
あーでも本社の方に指令2つ出せって言っても進化の融通きかんしこっちの現場は現場で勝手に進化してるしで連携とれんな…
↓
せやこうすりゃいいんちゃう？
本社の収縮指令が来るやろ？それを低圧に繋ぐんや。それで低圧連中が動くと電気信号が起きるやん。それを高圧側に繋いで動けば一つの指令で時間差の指令が作れるやん
名付けて「カツオの場所はカツオドリに聞け」作戦や。ジンギスカン作戦に並ぶ名作戦やでこれ
↓
でも低圧連中の出す信号って微弱やな…タイミングにもズレがあるし微弱電流を閾値にするとノイズ拾いまくって大混乱や困った…
せやスター結線や！心房結節で集合させればええんやそっから各部署に分配する
スイッチングハブ（洞結節）→リピーター（心房細胞）→スイッチングハブ（心房結節）→リピーター（心室細胞）
これでいけるで
↓
？？？？あのそれだとブロードキャストストームに弱くない？
↓
あーちゃんと動いてるしもう仕事終わり！クレームもきとらんしうちはパラシュート会社と同じでノンクレームの優良企業や
こういう経緯で、心臓に自律性を持たせる実装にしたせいで、なんか衝撃を受けた場合に心筋のどっかがまとまって拍動するとそれを受けて他の部分が拍動→その刺激で他の部分が…と繰り返して収拾付かなくなってしまうのよ。
ブロードキャストストームですわ。神の実装ミスです。
因みに、心臓はこういう風に自律性がある実装されてるので、体から飛び出しても動いていたりする。
心臓は筋肉の塊で非常に丈夫なうえに、拍動で擦れて傷つかないように心嚢っていうスベスベの膜に入ってるので、交通事故でトラックに踏まれて胸部が潰れてしまっても血管から千切れてシュポンって感じで飛び出してくる。
その状態でも路上で拍動を続けてるんですな。奥多摩のタヌキとか大垂水峠の鹿とかがトラックに轢かれてその近くで心臓が動いてるという現場を何度も見た事があるよ。
これは「倒れてない人、ピンピンしてる人にもAEDが必要なことがある」って話だよ。
例えば江戸時代などには食器洗いのママレモンとかは無かった。キュキュットとかも同じくない。
じゃあ食器洗いはどうしていたかというと竈の灰を水に入れて放置して灰汁を作り、それで洗っていた。
これは水酸化カリウムで強アルカリだ。植物の細胞が燃えて水蒸気と二酸化炭素になり、金属であるカリウムが灰の中に残ったものだね。
筋肉が収縮するには特にカリウムが必要だ。だから筋肉にはカリウムが多く含まれる。
そして血中のカリウムが多すぎると筋肉が過敏になる訳だ。こむら返りとかが起きちゃう。
事故で車の下やブロック塀の下に挟まれててそこから救出すると、挟まれ箇所が足とか腕とかだと筋肉の塊だからしばらく痺れるが血液の循環が回復されると痺れも取れる。なんてことも無く動けるしもうへっちゃらに見える。
圧迫によって潰れた、酸素不足で死んだ細胞の中身が出てるのだ。これはゴミとして掃除しないといけないから血液はこれを拾って持って行く。
で、ここにカリウムが超大量に含まれている訳だ。多すぎるカリウムは腎臓が濾して除去する。
でも大量すぎると処理が間に合わない。大量のカリウムが体内を巡ってしまう。
で、ここに筋肉まみれのマッチョで実装ミスによって痙攣が起きやすい臓器がある。つまり心臓だ。
アーキテクチャ的にブロードキャストストームに弱いのに、高カリウム血によって信号を拾う閾値が思い切りさがる。心室細動が起きないはずがないって状態なのだ。
だから、事故で挟まれていた人が救出されて「大丈夫だ」と言っていても動かないように命じ、救急車を呼んで病院に搬送して欲しいのだ。どんなに元気であってもだ。
そしてこの人は突然心室細動を起こして死ぬ可能性があるからAEDも用意すべきなのよ。
因みに高カリウム血症へのAEDの使用は、蘇生→再び心室細動を繰り返すのでAEDはずっと繋げたままで心電図を注視してないといけない。
何度も細動が起きて何度も電撃で痙攣する患者は見たら肝を冷やすこと請け合い。
そういう訳で医者でもないのに事故や労務災害に出くわす事が多い上に自分も心臓病を患って色々覚えた野良心臓マニアの増田がAEDについて書いてみたよ。
Amazonで半導体で検索をかけると、デバイス特性に関するものは沢山出てくるが、想像するようなチップの設計ではない。
Cadence、Synopsysといった大手EDAツールのトレーニングが手っ取り早い？
クローズド過ぎるわ、書籍などもないわで、半導体復興とかいうが教育手段がない。
ETHのコンピュータアーキテクチャの授業はあるけど、ド直球で合う業務ってなかなかないし
https://safari.ethz.ch/digitaltechnik/spring2021/doku.php?id=start
■ジム・ケラーって、CPU設計で実際どんなことをしてるのか？
日本語のネット界隈だと、ジム・ケラーでCPUを作っているような属人的な説明しかない。
ジム・ケラーのインタビューを読んでも、実際のところ、どういう設計作業をしているのか回答はない。
2点目は、実際、現代的なCPUを作るのにどういう作業をしているのか。
CPUの作り方について書籍はいくつかあるのは知っているが、オレオレCPUであり、市場での設計とは違ってるだろうというのは想像できる。
ジム・ケラーがRTLを書くかというと、そんなことは無い気がする。
アーキテクチャ図レベルだと属人的なことにはならない気がする。
現代のCPUは、いかにメモリーとのデータのやり取りを隠蔽するかは大事だが、こちらもジム・ケラーがするか？というとどうなのだろう。
セルライブラリの電流値と動作速度を見ながら、どこまでクロックを上げ許容電流値に収めるかをチューニングするのか？anond:20220622143458
日本語のネット界隈だと、ジム・ケラーでCPUを作っているような属人的な説明しかない。
ジム・ケラーのインタビューを読んでも、実際のところ、どういう設計作業をしているのか回答はない。
2点目は、実際、現代的なCPUを作るのにどういう作業をしているのか。
CPUの作り方について書籍はいくつかあるのは知っているが、オレオレCPUであり、市場での設計とは違ってるだろうというのは想像できる。
ジム・ケラーがRTLを書くかというと、そんなことは無い気がする。
アーキテクチャ図レベルだと属人的なことにはならない気がする。
現代のCPUは、いかにメモリーとのデータのやり取りを隠蔽するかは大事だが、こちらもジム・ケラーがするか？というとどうなのだろう。
前職と比較すると平均技術レベルはマジで変わったように感じる。
前職だとクリーンアーキテクチャやらCI/CDやらは言葉の意味すら知らない人も多かったけど、
今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。
FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、
凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値もめっちゃ上がるんだろうなって感じもある
コードの品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル。
命名として若干ニュアンスに違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し！」みたいなのは容赦なく潰される。
ペアプロ・モブプロはしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。
会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらいはいる。
開発手法もアジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんとセオリーに則ってる形で管理されている。
ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね？」っていうのもまた感じた。
そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算で10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値を提供できてんのかなこのサービス？っていう感じというか……
前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。
動いてるものが同じなら採用技術がオンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、
NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん？
難易度の高いイケてる技術スタックを使う＝必然的にエンジニアのお賃金が高くなるってことだから、経営者視点から見てもこういう選択って果たして正しいのかなぁって。
なんならエンジニアの賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。
どう思うよ。
比較的高学歴だったり、理系が多いとか、ソフトエンジニアが多いからかチームの雰囲気を良くするためにとか、
こうすれば良くなるってのを比較的見ている層だろう。
5ch、ヤフコメとは違うクラスターだが、自浄作用もなく手に負えない集団になった。
何が悪かったのか？
はてブの価値の1つは「どこからそんな優良記事を見つけてきたのか」ってことだと思うが、
どこでも盛り上がっている記事について斧を投げる。
スルーすれば良いはずが、わざわざコメントを書いて上位になる手助けをしている
(記事を書いている人をタイトルにつけてくれってコメント付くようなものは、スルーでいいはずだが目立つような行動をしてしまっている)
利用者は、それなりに年を取ったはずだが、どうだろうか。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
590あとで/4204users 【詳しすぎる2週間】親の死亡後にまずやること（行動チェックリスト付） | まごころ相続コンシェルジュ
291あとで/1560users Google製のJavaScript教育ツール「Grasshopper」は基礎から学べて初心者に優しい！【どれ使う？プログラミング教育ツール】 | 窓の杜
272あとで/1859users 無料コーディング練習所 | 未経験からWebデザイナーへ！
220あとで/1327users 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
201あとで/1017users 30 分でわかる！アルゴリズムの基本 | E869120 | SpeakerDeck
191あとで/1365users Wi-Fiトラブルの解決に便利！ Windowsの隠れ便利機能「Wlan Report」を活用しよう【イニシャルB】 | INTERNET Watch
175あとで/888users Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
171あとで/2593users (追記あり) 10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp
164あとで/849users AWS初心者向けの教材まとめ、AWS日本法人が公開 | ITMedia
162あとで/1231users 【試し読み】書店員さんから大反響！ 精神疾患を抱えた妻の介護と仕事…約20年にわたる苦悩の日々を綴った傑作ルポ『妻はサバイバー』｜朝日新聞出版さんぽ｜note
159あとで/935users 機械学習が独学できる日本語Youtube難易度別まとめ - Qiita
152あとで/961users 8時間を0.01秒に短縮 「アルゴリズムの素晴らしさが2分で分かる動画」が今すぐ勉強したくなる分かりやすさ | ねとらぼ
142あとで/889users 文春オンラインの記事分析を支える爆速ダッシュボードを作るまで｜Shota Tajima｜note
141あとで/2006users さよなら絵梨 - 藤本タツキ | 少年ジャンプ＋
140あとで/1138users 新電力の中の人です。すべてをお話しします | anond.hatelabo.jp
136あとで/1094users 『ゴールデンカムイ』全話無料！ | ヤンジャン!
135あとで/780users Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に | Publickey
132あとで/575users フロントエンドエンジニアが知るべきキャッシュを理解する | カーーズ | Zenn
132あとで/1232users みんなが知ってる『ちょっとのコツでめっちゃ美味しくなる、楽になる』みたいなの教えて→全然知らなかった有益な情報が集まる | Togetter
131あとで/679users 【個人開発】正規表現を学ぶ狩りに出ませんか？モンスターを倒しながら正規表現が学べるゲーム「Regex Hunting」を作りました - Qiita
124あとで/1217users 先輩に「何かタメになる話してくださいよ〜」と無茶振りしたら『Language Reactor』という2言語字幕を同時表示できるChromeの拡張機能を教えてもらった | Togetter
124あとで/1254users 育休中に相方がめちゃくちゃ売れた｜酒寄さん｜note
120あとで/1114users Google Analytics(UA)が使えなくなるのはどのくらいヤバくて、いつまでに何をしたら良いのかの話。 - フジイユウジ::ドットネット
120あとで/598users 電子情報学特論：Chromiumのアーキテクチャを解き明かす | Kentaro Hara | Google Slides
119あとで/1242users 僕がたどり着いた最強パリパリチキンの焼き方→上手に焼くポイントも「鶏肉好きとしては是非とも取り入れたい」「最高のライフハック」 | Togetter
118あとで/866users 「全クリエイターに広まってほしい」文化庁が質問に答えるだけで『著作権契約書』が作れる超便利なツールを作っている | Togetter
116あとで/897users ちょっと触ったら休日が丸2日消失した 個人的2022年ベストゲーム「TUNIC」を全力で推したい | ねとらぼ
115あとで/798users 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
112あとで/494users 『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動｜note
109あとで/522users 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
109あとで/1047users (続き)10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp
