  |
はてなキーワード: Ideとは
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
https://anond.hatelabo.jp/20220214164030
まず真っ先に出てくるのがスマートグラス
Googleがしっかり投資してインチキムービー作ってまで頑張ったけど無理でした
EPSONが頑張って出してくれてるしHololensとか工場系で使われてる（らしい）けど
5Gには2種類あって5GHz帯周辺を使うSub6と、30GHzとかのミリ波帯を使うmmWaveがある
このミリ波帯は高速通信可能なことが知られていてWiFiにも規格がある（IEEE 802.11ad）
ところが指向性が強いし遮蔽されると通信できないとかで全然使い物にならない
ビームサーチ技術とか使うと指向性は大丈夫になるんだけど、遮蔽はどうしようもないのでほとんど採用されず
5Gで10Gbps越え！とか言ってるのはmmWave使った場合なので騙されないように
IEEE802.11adの話が出たので、IEEE802.11aiの話。
これが何者かっていうと、WiFiの接続時間を無茶苦茶短縮できる技術。
WiFiって繋がるまでに結構時間がかかる（といっても数秒）んだが、それを0.1秒ぐらいにしてくれる。
そうすると隣のWiFiに移動しても途切れずに通信できたりするのがメリットなんだけど
あんまりそういうシチュエーションが無い、というか家庭とオフィス以外でWiFiがそもそも使い物にならないからね
こんな感じで802.11系を調べると来なかった技術の宝庫です
SDカードのデータ通信速度が遅くて特にカメラ業界はイライラしてて
読み取り端子を二段構えにしたUHS-IIという規格を作成
一部の高級志向カメラには搭載されたし下位互換性もあるから流行るかな？って思ったが
その手のカメラはXQDとかCFExpressに流れてしまった
まぁ細々と生きてはいる？のかな？
そもそもSDカードの抜き差しがめんどくさいんじゃ！ということで無線通信可能なカメラとかが出現。
TransferJet対応のSDカードとかも出てきて盛り上がるか？と思ったが、流行らず
そもそも高級志向カメラの人達は撮り終わったら家に帰ってゆっくり現像なので、無線でやるメリットがほとんど無いんだよね
と思ったあなたは間違えてないが、実はETC2.0の構想としてはその辺の駐車場でも使えるようにする予定だった
駐車場でETCが使えたらこの上なく便利で仕方がないサービスのような気がするのだが導入が進んでないのはやっぱりコストが高いのかな？
まぁ、承認も何もなしにいきなり「駐車料金は3000円でした」とか言われても困るけど、結局は払うんだから導入してほしい
でもそうなると駐車券処理とか面倒になりそうだからやっぱ無理なのかな
ちなみに駐車場の最近の流行は「ノーガード戦法」のようで、ゲートも何も無く、車両をカメラで撮って、酷い違反があれば後から追いかける、らしいです
だって、導入するイニシャル・ランニングのコストよりバイト雇った方が圧倒的に安いんだもの・・・
VSCodeとLanguageServerProtocolによって、人類は多様なプログラミング言語に対して安価でお手軽なIDE機能を手に入れた。
このような富豪的プログラミング環境において、「一つのファイルは最大400行！」がオールドファッションセオリーと化したことは明らかである。
そも、IDEとは何か。
人類は脳領域をテキストファイルに拡張することに成功したが、その頂きは未だ遠い。
ただ思い出す、と、テキストファイル群中から期待する箇所を装置に出力する、の間の容赦ない時間スケールの隔絶。
IDEはこの隔絶を埋めることができる。
思い出したい、と念じると同時に人はgdとキーを叩き、定義ジャンプする。
この時、人がジャンプしているのはファイルシステムのインデックスではない。
時間だ。
時間を跳躍したのだ。
日本語以外のダジャレ、ダジャレの歴史に興味があって英語版Wikipediaの"Pun"のページを見ていたが、どうにもよくわからん記述がある。
History and global usageの項にある以下の記述がなんともよくわからない。
DeepL翻訳によると「日本では "グラフマニア "もダジャレの一種だった。」と出るが……
graphomaniaってなんだ？というのをぐぐってみるとずばりこれという検索結果は出てこないが、「書字狂、何でも書かずにはいられない症状」のような意味合いか？
書字狂ってダジャレなんだろうか……
仮説１：英語で"Pun"はダジャレ以外の意味もある（まず全文読みましょうということだな）
仮説２："graphomania"の意味解釈が間違っている
参考文献の"The Cambridge History of Japan"の中の記述が元ネタのようなのでこれを読むのが確実か。
---
以下追記。
"The Cambridge History of Japan"の該当部分を引用。
The ultimate in orthographic word games is provided by such a rebus as "on top of the mountain there is another mountain," represented by five characrers that form the verb ide, "come out." The point of this visual pun is that the character for "come out" resembles two superimposed "mountain" characters. Graphomania of this order was not only a Japanese malady. In fact, the "two mountains" rebus derives directly from a much more complicated series of conundrums in Chinese poem included in Yu-t ai hsin-yung.
要約するならこうだろうか。
「山の頂上の上に別の山がある」というなぞなぞの答えが「出」で、このようなGraphomaniaは日本人に限った病気ではなく中国の古い詩に由来する。
なるほど、判じ物、判じ絵のことを指しているようだ。rebusってのがそれだな。
Windowsの中に仮想環境作るのでまったく要らないってわけでも無いけど(なので出来たらメモリ16GBくらいは欲しい)
ローカル(PC)💻がイマイチとか何も入れたくねぇなの場合はAWSとか使ってもいいしね
AWSマンガ第 2 話：快適な統合開発環境( IDE )を手に入れろ！ ( 1 / 4 )
https://aws.amazon.com/jp/campaigns/manga/vol2-1/
上記のは例だから興味なければ忘れていいよ。必要が出たら覚える・調べるだろうから
SSDで最低256GB以上(できたら512GB以上が望ましい)、CPU i5以上、メモリ16GB(予算が足りなきゃとりあえず8GB)で
追記：
あとノートPCは仕事や気分転換で持ち運びする様のものっていう認識の方がいいよ
ゲームで遊んだりゲーム作ったりするにはそこそこのスペックのデスクトップをいつか買うことになると想定した方がいいよ
この人と一緒に働かないといけないの辛すぎて転職考えるレベルだわ。せめて素直な人ならいいんだけども。
辞めてくれないかな。
