  |
はてなキーワード: xcodeとは
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
最新のXcodeからBig Surが未対応になり、渋々上げることとなった。
興味本位で手を出したハッキントッシュだが、OpenCoreのバージョンが上がる度に試すような熱心さはなく、動いてるしいいや位の完成度で使っている。Debug版を使い続けてるし、OpenCanopyなど楽しいものも入れてないカジュアル野郎だ。
まずそのままでも動くかなと思って試してみたがダメだった。ブートメニューにMontereyのインストーラーが出てこない。
OpenCoreのバージョンを最新にし、sample.plistを参考に設定を更新して再トライ、さらにkextも更新してまたトライ。やっぱりダメ。ブートループやフリーズが起きる。
sample.plistとのにらめっこで見逃した項目を潰したらすんなりとアップグレードできた。このコマンド前からあった？何はともあれ、めでたしめでたし。
それにしても、OpenCoreでもCloverでもそうだけど、開発してる人はすごいなあと思う一方、何のためにやってるんだろうと思う。
OpenCoreの作者（複数？）は寄付したいならその金チャリティーに送れとすら言っている。
ハッキントッシュの為のツール開発なんて永遠に日の目を浴びないだろうし、ただの好奇心が原動力だとしても多くの構成のマシンに対応する意欲に繋がるだろうか。
Chrome/Firefoxのはてブ機能拡張は配布されているが、Mac版Safariの機能拡張は数年前から配布されていない。
Safariに乗り換える際の個人的な障壁であったが、Chrome版機能拡張をSafari向けに変換して利用する事ができたので、メモ代わりに記しておく。
1. Chromeのアドレスバーに「chrome://extensions/」と打ち込み、機能拡張の画面を表示する。
3. 同画面内の「はてなブックマーク」の欄に表示されている「ID：xxxxxx」を次手順で使用する。
4. FinderでChromeのはてブ機能拡張がインストールされているフォルダが存在する事を確認する。
/Users/(ユーザー名)/Library/Application Support/Google/Chrome/Default/Extensions/(手順3のID名)/(バージョン番号)
5. ターミナルを起動して、以下コマンドを入力後にReturnキーを押す。この際に「Is this correct?」と表示されたら「yes」と入力後にReturnキーを押す。
6. XCodeが起動されるので［▶］ボタンを押して、Safari向け機能拡張をビルドする。（ビルド後に起動されたアプリは終了して良い）
7. Safariを起動して、「開発」＞「未署名の機能拡張を許可」を押す。（「開発」メニューは、「Safari」＞「環境設定」＞「詳細」＞「メニューバーに“開発”メニューを表示」で表示される）
8.「Safari」＞「環境設定」 ＞ 「機能拡張」にてはてブ機能拡張のチェックを入れ有効化する。
9. Safariのアドレスバーの横にはてブのアイコンが表示されていればインストール完了。
1. はてブのアイコンに [▲] のアラートが表示されている場合、アイコンを押して「すべてのWebサイトで常に許可」を選択する。
2. はてブのアイコンを押すと表示される利用規約画面で「同意する」を押す。（なお「同意する」を押しても何もリアクションがないので、手動でタブを閉じる必要がある）
3. はてブのアイコンを押して見慣れたはてブコメント一覧が表示されていれば設定完了。
上記手順では基本的にSafariを再起動する度に「未署名の機能拡張を許可」を行ってはてブ機能拡張を有効化する必要がある。
メニューから選択するだけの手間であるが、頻繁にSafari/Macを再起動するので面倒という場合には以下手順にて機能拡張に署名を行っておく。
1. 上述したインストール手順の「手順6」にてXCodeが開いている状態で画面内サイドメニューから「はてなブックマーク」を選び、画面中央上部の「Signing ＆ Capabilities 」タブを押す。
2.「Signing」＞「Team」で自身のApple IDを選択する。（選択リスト内に存在しなければ「Add an Account…」でアカウント追加後に選択する）
3.「Signing」＞「Signing Certificate」で「Developement」を選択する。
4. 手順2-3を「Target」の「はてなブックマーク」と「はてなブックマーク Extension」の両方で実施後、［▶］ボタンを押して、Safari向け機能拡張をビルドする。
5. Safariにて「開発」＞「未署名の機能拡張を許可」を外した状態でもはてブ機能拡張が表示されていれば完了。
デジタル庁自体が菅政権の最大の施策の一つであり、また担当大臣の平井大臣が癒着やパワハラ、ネット工作などの疑義が前から掛けられてた事もあって関心は高かった。その中で、事務方トップである「デジタル監」の人事も少し話題から紛糾しており、カリブ海のロリータ島をセレブに提供していて最終的に消されたエプスタインとの金銭関係があった人物が一時候補になったが、流石に身辺調査したらやばくねということで見送られて、結果的に72歳の石倉氏が就任する運びになった。
しかし、就任会見(?)のときに、彼女の発言の一部が報道されて、デジタル庁のトップとしての適正がいきなり疑問視された。
Twitterなどでは主に石倉氏の経歴を理由に「彼女は優秀に違いない！！」バイアスが掛かった擁護が繰り広げられた翌日、彼女がインターネット上の基本的な著作権を理解しておらず、ガビガビの画像をブログに掲載するほどWebデザインにも無頓着ということが明るみに出てしまい、「スーパー72歳」とか「デジタルに超詳しい百戦錬磨の敏腕素人」と祭り上げていた人達は一夜にして梯子を外されてしまった。
https://twitter.com/KAZE/status/1433268216235630599
https://twitter.com/mesotabi/status/1433399709566062594
https://twitter.com/Benzman_TAKE2/status/1433308767442006018
5ちゃんねる、ヤフコメ、はてななど、右翼、左翼系のコミュニティーでは、一晩にして否定的な声が多数を占めてしまい、ここから挽回が期待されている。中には、「警視総監が万引きしたようなもんだ」という痛烈な皮肉まで展開されていて厳しい船出である。その中でもTwitterだけは、著作権侵害を告発した被害者であるPIXTA社がなぜか糾弾されるという被害者の二重レイプまで起きており、政府が力をいれているインターネット対策の中心地はここなのではないかとも勘ぐらされたのである。
日本人はとにかく学歴や権威に弱い。ショーンKとか齋藤ウィリアム浩幸とか竹花貴騎とかそうだけど、ちょっと豪華な学歴と経歴があれば、真偽はともかく「この人はすごいんだろうな」バイアスがかかる。このデジタル監の石倉女史も「経歴がものすごいんだから超優秀に決まってる！」という主張が相次いだ。一部では「プロ社外取締役」「渡り鳥」ではないかという意見もあったし、少なくともITやデジタルに関する業務はほとんど経験ないのは明白だったけど、とにかくすごい大学出てすごい会社の社外取締役経験してるんだから、お前等は何も言うな的な論調が高まっていた。
しかし、「誰が言ったか」ではなくて「何を言ったか」が問題なのである。たとえ華やかな経歴があっても72歳のお婆ちゃんだ。普通ならもう年金生活している段階の高齢者を引っ張り出してくるなら、相応のデジタルに対する知識や造詣、情熱が必要なのではないか。もちろん、彼女は実質前前任の桜田義孝サイバーセキュリティ担当大臣よりは数千倍マシであろうが、それでもデジタル後進国の日本のITリテラシーを高める急務が求められているときに、この人が本当に適任なのだろうか。同じマッキンゼー云々なら、南場智子氏の方が全然適職ではないのだろうか。経団連も兼任してるから厳しかったかもしれないが。普通にTwitterやブログやってるお婆ちゃんが事務方トップになれるなら、数百万人レベルで候補者が出てくるだろう。
そして、石倉氏に対する反応については、もう一つ大きな問題が有り、彼女が「ワードプレス」とか「Python」とかいう言葉を出しただけで、超敏腕のスーパー天才ITエンジニアではないか、という受け止め方がされていること。
https://twitter.com/youyakuya/status/1433449570134990853
もちろん非ITエンジニアにとっては「ワードプレス? Python? なんかよくわからんけどとにかく凄いんだろ！！」みたいな反応になってしまうことはある程度は仕方ないと思うのだが、そもそも彼女は「Pythonを勉強していいたけど難しくて挫折した」のである。これはむしろ氏のデジタル適正の完全否定他ならないと思うのである。アセンブラ言語やC++ならまだわかるよ。人には向き不向きあるからね。でもPythonができないのって普通に才能ないと思うよ。数ある言語の中でも平易なもの。だからこそ世界の主要言語に躍り出た。ワードプレスなんてただのブログ作成ツールだし、そのご自慢のブログでも早速やらかしてしまったんだけど、そこでも「本人はワードプレスには一切触れてなくて、部下やスタッフが勝手にやった」みたいな擁護までされて、WPバリバリに使いこなすスーパー72歳という設定はどこにいったの感がある。
「72歳なんだからプログラミングできないのは仕方ないだろ！」という声もある。しかし日本には石倉さんより15歳ぐらい年上なのに、Pythonより遥かに難解なObjective-CでiOSアプリを開発している女性がいるのだ。xcode使いこなすのはWPの数千倍難しいぞ。高齢者に対するデジタルへの抵抗感をなくすのが目的なら、彼女のほうがデジタル監に相応しいと思う。
https://style.nikkei.com/article/DGXMZO37707280T11C18A1000000/
要は「石倉さん? よく知らないけどwikipedia見たら経歴すごいし、PythonとかWordpressとか触ってるようだから、凄い人なんだ！！！」という思い込みと脊髄反射がされた一件である。我々もJavaやPHPやObjective-Cしか書けない底辺エンジニアであるのだが、恐らく世間的には増田さんって頭いいんですね～デジタル得意なんですね～みたいな受け止め方がされるのかもしれない。日本人は権威に弱く、日本人は「よく分からないもの」は「畏怖」を覚えてしまう。
しかし、石倉氏はデジタル監に完全に不適任かというと定かではない。というのも、こういうポジションは実務はほとんどなくて、ただのお飾りポジション、それこそ彼女が歴任してきた「名誉教授」とか「社外取締役」と同じなのではないかも思えるのである。実務がないのであれば弊害もないだろう。実際、Twitterのウヨ勢力はこぞって彼女を熱烈支持することに決めた。それこそ著作権侵害であってもさっさと謝罪したからむしろ素晴らしいというアクロバット擁護まで。
なんでだろう
これまで改良はされてきたし、最新のは知らんのだけど、
プロジェクトの設定とかとりあえず必要最低限だけ表示すればいいのにドバーッと全部表示してしまってて、
しかも結局はコマンドラインのオプションをGUIでチマチマ書くような感じになってしまってて、
これIDEの意味あんの？みたいになるわけだけど、Xcodeを使わないと基本的にMacやiOSのアプリを開発できない縛りもあるわけで、
あと、うろ覚えだけど昔たしかInteface Builderのnibファイルとかバイナリだったんじゃなかったかな
バージョン管理しづらい、差分が分からない、うっかりマウスを滑らせてどこか変更してしまっても分からない、
NeXTはそれでも良かったのかもしれないけど、なんだかなあと思って、できるだけ使いたくなくなる不思議なIDE
