  |
はてなキーワード: Android Studioとは
これまでいろいろな開発環境を使ってきたけど、Android Studioは本当にダメだ。
別途Javaの環境も構築しなきゃいけないし、おまけにJavaのバージョンによってはAndroid Studioとの相性が悪くてエラーが出ることも多い。
最初から最低限必要なものは揃えてくれればいいのに、後からどんどん障害物が出てくるから本当にイライラする。
アプリをリリースするためには署名が必要なんだけど、これがまた本当に面倒。
Android Studioには「キーを生成する」機能があるけど、これが直感的じゃない。
手順を調べるのに何時間も費やしたことか。コマンドラインからキーを生成するのか、GUIでやるのか、どっちにしても「なぜこんなに複雑にするのか」と思う。誰が得するんだ、この面倒くささは。
が、これまた問題が出てくる。ビルド時にエラーが出ることが多い。
何が悪いのか全然分からないし、エラーメッセージもわけがわからない。
ググって出てくる情報も正解とは限らない。結局時間だけが無駄に過ぎていく。無限ループに入った気分。
こうやってひたすら環境構築と闘ってきたわけだが、実際にアプリ開発に入ると今度はAPIの変更やライブラリの依存関係でまた地獄が待っている。
新しいバージョンが出るたびに、対応しなきゃいけないことが山積みで、これをやっていると「何のためにこんな苦労をしているのか・・・」と思わずにはいられない。
結局Android Studioを使っていると常に試行錯誤の連続で、楽しいというよりはストレスがたまるだけ。
正直、他の言語やフレームワークに目を向けようかとも思ったこともある。
React NativeやFlutterなんかは環境構築がスムーズで、すぐに開発に入れる印象がある。
なのにAndroid Studioに戻ってくるのは、Androidの市場の広さが魅力的だからだろうか。
でも何度もこの環境で悩まされると、本当に心が折れそうになる。
なるべく手持ちのPC（以下、ホストPC）の環境をレジストリとか環境変数とかで汚したり悩まないよう
Windows10 ProとWSL2とVSCodeとDockerでやる感じかな
UnityとかVisual StudioとかintellijとかAndroid Studioを使う場合はどうしようもないので諦める。
Android開発はVSCodeでビルドはコマンドラインでとかはできそうだけど。
あとはUSBなどでシリアル接続する必要のあるarduinoとかもちょっと難しいかもしれない
これが基本的なところだけど、WSL2をホストPCに入れるので若干汚れるのとWSL2上のlinuxも同じく汚れるところ
Hyper-VでWindowsの仮想マシンを作ってそのうえでWSL2を動かすのが一番汚れずクリーンに使えそう
ただRyzenとWindows10の組み合わせだと、Hyper-Vの入れ子ができないので仮想マシン上のWSL2は動かないらしい。
Windows11だとできる
手元じゃないのでクリーンに使えるが、ビルドなどはリモートのスペックに依存
そこをよしとすれば楽そう
教えてください。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
黎明期当時の技術に対してドコモの要求が多く、かえって足枷になったことはあながち間違いでは無いし、ハードウェア構成の変なこだわりもあったと思う。
1つは、少なくとも今までの日本向け端末で採用され続けているチップセット（主にQualcomm Snapdragon）が、モデム部分を除いた処理能力でAppleから何周か遅れているようなものばかりである（特にGeekbenchのComputeスコアはVulkanを利用しても悲惨な結果ばかり）。
たとえ同じアプリをリリースしても、同じ価格帯の携帯電話なのに体感速度で明らかに劣ると言うことがよく起きている。ゲームで顕著だ。
偉大なるUnity（IL2CPP）やCRIなどのミドルウェアのおかげで、ある程度は演算や音声再生能力の差が吸収されるようになったとはいえ、3D描画APIがOpenGLESからMetal/Vulkanに移行したために描画性能の差が余計に広がってしまった。
純粋にチップセットメーカーの技術力の問題もあるが、視覚で訴えかけるゲームのパフォーマンスで差がついてしまった以上Appleのプラットフォームを選ぶ人は減らないだろう。
おそらく、まともなデベロッパーであれば、できる限り理想を実現しやすいプラットフォームを選ぶので、既に普及率が高いうえパワーに余裕のあるiPhoneを基準にアプリを作る。後はわかるな？
2つ目は、一時期流行を見せたいわゆる「格安スマホ」すなわちローエンド端末（エントリー機）の存在だ。
これは、（非常に少ないが）特にこれからスマホを使い始めるという人には非常におすすめできないし、型落ちハイエンドスマホからの買い換えもやめておくべきだ。
自分含め、購入する際には安くてもスマートフォンだと思っているので、あのアプリを入れよう、あのサービスも使ってみようなどと期待して操作をするが、スマートフォンとしてのメリットをほとんど享受できない場合がある。処理能力やストレージが全く足りないからだ。
iPhoneの場合、概ね処理能力を差別化していない（廉価グレードのSEは存在するが中身は「型落ちハイエンド」）のでどれを選んでもそれなりには動いてくれるが、「格安スマホ」は最新機種でもチップセットメーカーがコストを下げるために処理能力をかなり抑えて差別化を図っているので悲惨である。
ようやくSnapdragon 480 5Gで一気に底上げされたが、少なくとも日本市場に関してはもう手遅れだと思う。
また、スピーカーやディスプレイ、カメラなどの部材も必然的にグレードが低いものを用いるので、型落ちハイエンドスマホより体験が劣ることもあり得る。
パソコン同様、初心者に安物を買わせてはいけないのである。売り方をもう少し考慮して欲しい。
以上のように問題はたくさん抱えているが、辛うじてAndroidというプラットフォームには救いがある。
オープンだという点。
x86-64のパソコンさえあれば開発環境が無償で使用可能で、作ったアプリはサイドロードができるのでストアなどに登録しなくても配布できる。
自力で機能を実装して、ちょっとした不便や問題を解決していく強い意志を持てるならば、どんどんAndroidを使うべきだと思う。
理想としては、Android StudioやFlutterなどの開発環境がAndroid上で走るようになれば、敷居も下がってコミュニティも活発になるだろう（なってほしい）。
※ 再ポストを許してくれ。どうしても、聞く人がいないのだ。
当方は、元プログラマー。今となっては、家庭の都合で引退した身。嫌なことがあって、久しぶりにプログラミングを勉強したら楽しくて仕方ない。
たとえば、Ruby on Rails, Next with React on TypeScript とか最高にイカしていると思ったし、Kubernetes や Terraform で AWS, GCP を触れば IaC に感銘したし、Kafka や Elasticsearch といった NoSQL が RDB が進歩した上で共闘している様は夢のようだ。PHP や Java も元気にしていて、おじさん嬉しいよ。（最近の流行りだから Docker も触ったが、Vagrant なんかを触れた身からすると、正当な進化だよね。）ただ Python が人気なのは理解できないし、そんでもって C は苦手なままだけどな。あと、CSS と HTML のナレッジのアップデートについていけないのは歳のせいだろう。
閑話休題。それでタイトルの質問なんだけど、今のモバイルアプリの開発手法について知りたいのだ。もちろん React Native といったものがあるのは知っているが、この手のものは好きになれないのよね。どうしても無理から生じる齟齬が気になっちゃうし、もっと言えば「プログラミングを介して、設計思想に触れたい」からね。
まず、iOS の話題から。今は iOS は SwiftUI だけで書けば良いのかしら？昔は Objective-C と Storyboard を使っていたけど、新規のプロジェクトだと無視してもよいのよね？いや、だめだったら追加で勉強するだけだから良いのよ。その、加減がわからなくてね。自分としては Swift言語が好きで、SwiftUI は StoryBoard よりマシだと思うから、そこは問題ないのよね。10年前より、絶対に良くなったと思うし。あと SwiftUI と Swift言語の example 集とか、CocoaPods のまとめサイトなんかを教えてほしいな。公式だけじゃ物足りない。
次に Android なんだけど、現行なのは Kotlin言語 + Android Studio の UI ビルダーを強制なんでしょ？昔は Java言語 + XML の MVC という感じで、当時としては iOS よりまともなイメージだったけど、最近ふれたら蕁麻疹が出そうだった。なんというか、ちょっと体が受け付けない感じがする。だから、Android は昔の開発手法で良いのかを教えてほしい。あと、iOS と同様に example を大量に載せたページをお願いします。
こんな感じかな。追加で知っておくべきことがあれば、嬉しい。たとえば、PWA とか。自分としてはモバイルのプログラミングが理解できたら、ブロックチェーンや人工知能を除くと、ここ10年のナレッジはキャッチアップできたつもりなので満足なんだよね。あと気力があれば、作成物を増田に晒すかもしれないです。
現状ではそう捉えてもらって構いません。
しかしながら開発環境のAndroid StudioはARMアーキテクチャー向け以外にもx86(x86_64)アーキテクチャー向けにもコンパイル＆ビルドが可能です。
ゲームなど高度なグラフィックス機能を用いた場合に問題となるのはARMアーキテクチャー固有の機能へ強く依存する設計を行っているアプリですね。
ARMの機能へ強く依存しないように心がけて高度なグラフィックスを実現するとx86アーキテクチャーでも軽快なアプリは実装できます。
Chrome OSデバイスはAndroidスマートフォンと比較して大画面であることが多く、ゲームの需要も比較的高いことが予測されます。
広いプラットフォームへ配信することを考えてもアーキテクチャー固有の機能へ依存しすぎることは開発にとって技術的負債になりかねないので広範な実装をしたほうが良いでしょう。
このあたりは3Dゲームの開発環境ではデファクトスタンダード化しているUnityにも気をつけて貰いたいところです。
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
Linuxフリークでもそうでも無い人でもLinuxへ多少の知見があればエントリのタイトルが目に入った時の声はたった1つだろう。
「は？」
これは良くも悪くもLinuxのデスクトップOSとしての評価を如実に表している声だ。
不便・不安定・不親切、おおよその一般ユーザには全く推奨できず、不具合の解消はLinuxユーザ自身の問題解決力が問われる。
しかしそんなLinuxは不気味なほど一部のパワーユーザからは絶大な支持を得る。
Chrome OS上のLinuxはProject Crostiniと呼ばれるプロジェクトの成果によりChrome OS上でLinuxの動作が可能となってきたが、これまでBeta版扱いだった。
正直に言って誰しもがChrome OS上で動作するLinuxは永遠にBeta版であろうと考えていたと思う。
結局は好きものなLinuxフリークのために用意してくれていたお遊びであって、GoogleとしてはProject Crostiniを本気で活用する気なんて無いのだと知った気になっていた。
なに、そもそもChrome OSもAndroidもLinuxベースOSだ。Linuxの上でLinuxを動かしているに過ぎないし、Googleはすでに我々へLinuxデバイスを多くリリースしてくれているではないか。高望みはいけないのだと諦めていた。
しかし違った！違ったのだ！GoogleはProject Crostiniへ本気だった！
ついに、ついに、ついに！家電量販店でLinuxデバイスがいつ行っても買える時代がやってきた！
Androidのように自身がLinuxディストリビューションであることを一般ユーザのために隠しているOSとは意味合いが全く違う。
むしろAndroid StudioをインストールしてAndroidアプリを開発するOSだ。足りないパッケージをAPTからインストールするLinuxディストリビューションとしてのOSなのだ。
あぁ何とでも言えば良い！
Chrome OSのLinuxレイヤーはChrome OS側のIMと連携できなくてLinuxレイヤーは独自にFcitxなどのIMを導入する必要があるって？
んなもん知っとるわ！それがどうしたぁ！！！
仮想環境であるLinuxレイヤーへKVMなどを導入しLinuxレイヤーを重ねて構築すると不安定になり全てのLinuxレイヤーが致命的に壊れることがあるって？
もうそんなことは何度も繰り返してんだよ！壊す前提で実験しとるわい！！！
バカにされたって罵られたってChrome OSのLinuxが正式版になったんだよ！！！
ありがとうLinuxフリーク！ありがとうお前ら！ありがとうGoogle！ありがとうドザー！ありがとうマカー！
LenovoはBIOSを書き換えた前科があるから買わないことにした
でも、中国企業はともかく中国が関係しない製品はもうほぼ存在しないと言ってもいいのではないだろうか
それが最初から彼らの狙いであって、つまり、みんながやりたがらない仕事、汚れ仕事をかってでることで、
純粋な中国企業製品というと、手元にZTEの古いAndroid端末が1つある
しかもこの端末、開発用に買った端末の1つなのだけど、Windowsに接続すると特殊なデバイスドライバのインストールを要求してくる
しかし、同端末をMacに接続するときは要求されず、しかしながらAndroid Studioでちゃんと開発できる
で、Windows側のデバイスドライバもアンインストールしてみたら、なしでもAndroid Studioで問題なく開発できた
この辺の前後関係や詳細を忘れてしまっているのだけど、変な話だなあと思ったことだけは覚えてる
ただ、家にはArduino Miniの中国コピーをまとめ買いしたものもあるのだけど、
これは特殊なドライバを入れないとUSB接続で認識さえされなくて、
しかし、これは一応理由があって、Arduinoの本来のUSB周辺のチップや回路を安いものに置き換えることでコストカットを狙っているらしく、
その代償として特別なデバイスドライバがなければ使用できないことになってしまってる
こういうコストカットは中国製品には多く、同じ型番でさえ別の回路、ソフトウェアの構成になっていることがある
要は、同じように動作すれば、型番が同じでも構わないよね、みたいな杜撰な感覚なのである
それから、このまとめ買いしたArduino Miniはどれもピンが曲がってはんだ付けされてる
仕方がないのでピンを曲げて刺すしかない
ただ、この手の中国コピーは単価がクソ安く、壊してもラジコンみたいなのに積んでロストしても損した感じがしない
というか、玩具とかラジコンとか、台湾、中国製品が手頃な値段なので大きく入り込んでいる
日本製品はいいけど高い、ちょっとした実験とかに使うには高い、そんな感じになってる
簡単に壊れてしまっても設計とか試作段階では重宝するのではないだろうか
いやはやまったく、はてブにあがってたので読んでしまったが、久々にあまりにも酷いレビューを読んでしまった。あぁそうそう引用している記事にはアクセスしなくても良い。時間とトラフィックリソースの無駄だ。
記名は編集部となっているが、Business Journal編集部員の質はこの程度なのか？まるで「私たち編集部はWeb検索すらしないで又聞きした情報を記事にしています」と宣言したいがために記事を公開したのかと邪推したくなる。
1つの記事へ膨大な時間を掛けて執筆することは生産性を考慮すると悪手であるのは間違いない。しかし、いくらなんでも"ほど"があるだろうと言わざる得ないのだ。
下記の理由からBusiness Journal編集部は当該記事の編集部員へ二度とゲーム記事は書かせないほうが良いと"ご意見"をよせさせて頂く。
当該記事では太正100年が既存のサクラ大戦シリーズとの歴史的連続性の無さを指摘しつつ、蒸気エネルギーが排除され主要エネルギーが採用されたことへ対して非難の声がよせられていると書いている。
しかし、太正100年は西暦で言えば2011年である。半世紀以上の時間が経過していながらサクラ大戦シリーズはいまだ蒸気エネルギーへ依存し続けなければならないと本気で思っているのだろうか？
そして、歴史的連続性の無さを指摘しているが現在公開されているサクラ革命のシナリオは、チュートリアルと九州編と中国編(そして九州を舞台としたサイドシナリオ特別イベント)のみだ。
サクラ革命は47都道府県を舞台としようとしているのは現状で明確にわかる。つまり素直に受け止めれば45シナリオが残されている。全体のシナリオ進捗は約4.25％であり、この状況ではサクラ革命がサクラ大戦シリーズでどういう立ち位置なのかほぼわかっていないとWeb検索するまでもなく察することが出来るので、なぜこれを"爆死＆大炎上"の理由としたのか本気で謎である。
サクラ革命を現状で物凄くやり込んでいるプレイヤーすら何もわかっていないのに、何をわかったつもりで居るのか。
サクラ大戦シリーズにおいて蒸気エネルギーは主要エネルギーとして確かに重要であり、サクラ大戦シリーズを彩るスパイスとして無くてはならない存在であるのは間違いない。
しかし、サクラ大戦シリーズにおいてスチームパンクはスパイスであってメインの素材ではなく、あたかもサクラ大戦シリーズはスチームパンクだからこそ支持されていたかのように描くのは誤解である。
サクラ大戦シリーズファンへはわざわざ説明するまでも無い話だが、申し訳ないけれども知らない読者のためにも付き合って頂きたい。
端的にかつ簡潔に述べるならば、サクラ大戦シリーズは「アイドルマスター」シリーズのご先祖様である。
サクラ大戦シリーズは宝塚歌劇団をパロディした作品であり、その痕跡はキャラクター名や帝国華撃団など各名称に現れており、歌って踊り、企画段階で強くメディアミックスを意識され、当時の声優業界すら巻き込んで現在にもその影響を残しているターニングポイントだった作品だ。
霊子甲冑のデザインを著名なメカデザイナーが手がけているなど日本のSFとして決して軽視できるものではないが、宝塚歌劇団のパロディとしてゲームに落とし込んだという要素に比べればスチームパンク要素は些細と言って過言ではない。
だから「戦うアイマス、アイドルマスター XENOGLOSSIAかよ」と一部のユーザがそう感じてしまうのも仕方ない。ご先祖様なのだから。
ついでに誤解なきよう言及しておくと、蒸気エネルギー要素はディスコンされていない。当該記事の書き方では蒸気エネルギーがディスコンされてしまったものと誤解する読者が出てきそうなので。
これにはサクラ革命プレイヤーとプロジェクトセカイプレイヤーの双方が怒って良い。というか既に怒っているだろう。
どういう神経でプロジェクトセカイを持ってきたのか呆れて果ててしまう。
現代のサブカルシーンでは主題のコンテンツを貶めるため他のコンテンツを持ってくるのは禁じ手とする傾向が強くなってきているのを読み取れていないのか。
作品Aはカワイイ、作品Bもカワイイ。どっちもカワイイ。どちらがカワイイのではないどちらもカワイイ。
これが現代のサブカルシーンであり、当該記事の書き方はまるで10年前のゲームハード戦争真っ直中の素人レビューのようだ。
他のコンテンツを貶める暇が在るなら推しコンテンツを布教しろ。
Business Journalとかいう質が低すぎる文字同人サイトの誤りを指摘したので、次は実際にサクラ革命プレイヤーである筆者がサクラ革命が非難される理由を書こう。
ネタバレになるので詳細は控えるが、サクラ革命で現在配信されている3つのメインシナリオであるチュートリアル、九州編、中国編すべてでお涙頂戴が展開される。
しかもお涙頂戴の起因が3つとも同じだと言って良い。どれだけライターはこのシチュエーションが好きなのか。流石に3連続、というか配信されているすべてのメインシナリオがコレなのはおかしいだろう。
この繰り返される同じお涙頂戴シチュエーションについてはTwitterでちょっと検索するだけで出てくるので当該記事を書いたBusiness Journal編集部員はおそらくWeb検索すらしてないと思われる。
Twitterユーザーの100文字に満たないツイート、例えば「お涙頂戴繰り返すからサクラ革命のシナリオは微妙」みたいなレビューよりも質が低い上に、あれだけの文字量なのだから執筆時間もTwitterユーザーのツイートより掛けているだろうから生産性まで低い。圧倒的な質の低さである。お前Twitterユーザー以下だぞと。
サクラ革命の戦闘シーンで敵ユニットが毎ターンほぼ確定で自ユニットへ弱体化補正(いわゆるデバフ)を決めてくる。
つまり、敵ユニットが自ユニットへ対して攻撃力や防御力、必殺技ゲージの低下を(自ユニットが弱体化耐性を持っていない限り)毎ターンほぼ確定で決めてくるのだ。
ディライトワークスが開発するスマートデバイス向けの別ゲームタイトル「Fate/Grand Order」のプレイヤーならば慣れているゲーム設計と言えるが、ディライトワークス製ゲームを初プレイするプレイヤーに取っては不快なゲーム設計だろう。
サクラ革命はスマートデバイス向けRPGでありがちな、いわゆる「育成周回」が必須のゲーム設計となっている。
そしてサクラ革命には攻略ステージ毎へ親切にも自ユニットの適正レベルが記載されているのだが、どうやらこれは自ユニットの攻略ステージ開始時の初期ステータスを基準にしているらしく、適正レベルへ至っていてもターンが進む毎に敵ユニットから弱体化補正をかけられ続けると攻略が困難になってくるのだ。
当然、非常に高度な立ち回りをすると苦戦しつつも結果的に勝利を収められるが、忘れてはならないのがサクラ革命は「育成周回」が必須のゲーム設計なのである。
「育成周回」しなければならないのにターンを膨大に重ねるのは非効率なので、ここに矛盾が生じて慣れていないプレイヤーはストレスを感じてしまう。
「Fate/Grand Order」プレイヤーはこのゲーム設計に慣れているので即座に「最短ターンで編成を組むのがサクラ革命の最適解」と察して行動を取れたが、ディライトワークス製ゲームを初プレイしたプレイヤーはより一層のストレスを抱えているだろう。
これは完全にディライトワークス製ゲームのプレイヤー間の内輪ネタだが、ディライトワークス製ゲームにとってバグは"お家芸"である。何も笑えないが、ネタにして笑い飛ばすくらいの胆力がないとディライトワークスには付き合っていられない。
「Fate/Grand Order」でもローンチ直後から様々なバグがあり、その伝統は本作にも引き継がれ、大いにプレイヤーを笑わせてくれている。・・・その笑いは失笑かも知れないが。
筆者が笑ってしまったのはローンチ初日、サクラ革命もアプリ初回起動後に追加データダウンロードというゲーム系アプリにはありがちな仕様(初回起動時に追加データダウンロードが発生するのは各アプリストアの仕様上の制限である)で、ダウンロードプログレスバーが表示されている間に、登場キャラクターの簡易プロフィールが読めるという演出になっていた。ダウンロード中にプレイヤーが飽きてしまわないよう配慮された仕様だ。
しかし、この簡易プロフィールのデータがどうやら初回起動後の追加データに含まれていたらしく、1人目以降まったく簡易プロフィールが読めないというバグがあった(現在は修正済み)。ゲームプレイする前からわかりやすいバグが発見できる。これがディライトワークス。
サクラ革命を実際にコーディングしている開発者からすると変な汗が出る初歩的なバグであるのは筆者も情報技術者の末席に連ねる者としてお察し出来るので心身痛み入る、まぁそういうこともあるさという言葉を送りたい。
こうやってディライトワークス製ゲームプレイヤーが開発元ディライトワークスをイジるのが内輪ネタというわけである。
「Fate/Grand Order」のバトルシステムは登場当初スマートデバイスでもバトルっぽいことができると示した素敵なエコシステムだが、サクラ革命のバトルシステムはそのエコシステムのエコさ加減を最大限に活かしつつ、ちょっと戦略性を上げましたというバトルシステムである。
サクラ革命という新しいゲーム開発へ関わったのだから「もうちょっとなんかあったやろ」というツッコミが方々から聞こえてくるが筆者としては1周回って「ディライトワークスだしコレで良いんじゃね？」と思えてきている。
詳細なバトルシステムが気になる人はYoutubeか何かで観たほうが早いだろうし割愛する。所詮はポチポチゲーですよ。
筆者としては歌劇シーンを観ることができると思ってサクラ革命をインストール事前予約してまで期待して待っていた(ディライトワークスなのでバトルシステムは鼻から期待してない)のだが・・・観れないんだなぁ・・・(遠い目)。
いやコチラが勝手に期待したのが悪いっちゃ悪いんだが、3DCGでやるって言うんだもんアイドルマスターみたいな歌劇シーンを期待しちゃうじゃないですか。もしかしたら初代サクラ大戦のメンバーとかもスペシャルゲストとして動いてる様子が観られるとか思っちゃうじゃないですか。
このあたりが怨嗟を生んでる気がするんですけど、ディライトワークスさん1周年イベントで良いんで歌劇シーンやりましょうや。
悪いところばかり挙げるのもアレですし、とりあえずプレイせず様子見している"司令"も居るでしょうから良い点も挙げておく。
初代サクラ大戦のイメージを引っ張っている司令からすると違和感が物凄いけれども、慣れてくるとこれはこれで良いものなのではないかと思えてくる。
ただモーションは固定なので高く期待するほどでも無い。
サクラ革命ではガチャゲーで、アイテムや装備も一緒に排出されるいわゆる"闇鍋ガチャ"であるが、☆5キャラの排出率が恒常ピックアップ☆5キャラが0.375%で「Fate/Grand Order」と比較すると悪くはない(FGOの恒常ピックアップ☆5キャラは0.029%)。
筆者もそうであるが、コレクター的な性質を持つプレイヤーならば出費少なく結構簡単に現行でガチャ実装されているキャラが揃ってしまうので、その辺は気持ちよさがある。
ちなみにガチャで所有キャラが被ると必殺技の性能が向上するという仕様。最大でLV20。
前述したとおり、ガチャで所有キャラが被ると必殺技の性能が向上するという仕様だが、ガチャでなくとも必殺技の性能を挙げるためのアイテムが存在する。
いわゆる"箱推し"でなく"嫁"を愛でる性質を持っているプレイヤーであるのならば自由意志で集中してアイテムリソースを注ぎ込むことが可能だ。
一部の読者からすると途端にマニアックな話になって申し訳ないが、サクラ革命はChrome OSのAndroidエミュレータで動作可能で、Chrome OS上のGoogle Play Storeで普通に配信されている。
これはおそらくAndroidアプリ開発の統合環境Android Studioの仕様で、デフォルト設定だとChrome OSでの動作が許可されているためだ(ちなみに「Fate/Grand Order」も動作する)。
筆者は細かな検証をしていないが、どうやら新しいApple Sillicon M1を採用したMacでは動作しないようなので、この点だけはほんの少し新しいMacbook Airよりも一歩、いや半歩だけ進んでいると言って良い。
ただ、どうやら配信されるバイナリはARMアーキテクチャ向きのものであり、x86(x86_64)アーキテクチャ向きのものではないようで、そのためかレンダリングへ一部不具合を抱えている上に動作が重い。これが半歩の理由。
Chrome OS上でサクラ革命の動作を検証した筆者のChrome OS環境で最大スペックのものはCPUがCore i7-10510U(第10世代)でワーキングメモリ16GB、M.2 SSD 512GB(PCI Express 3.0)であり、それでも「軽快さはないがプレイに全く支障はない」くらいの重さを感じるので、現状でサクラ革命をChrome OSでプレイするならこの程度のスペックは必要になると思われる。
情報技術者としては今後デスクトップおよびラップトップコンピュータでスマートデバイス向きアプリケーションが動作するのが一般的なのは目に見えているので、アプリ開発者はデスクトップおよびラップトップ向きのハードウェアサポートを検討する時代へ突入し始めていると多少の意識を向けたほうが良いのかも知れない。
例えば、各アーキテクチャへ最適化されたバイナリや、スマートデバイスではあまり意識されてこなかったハードウェアキーボードのサポート、シングルタップ時とマルチタップ時のトラックパッドの振る舞いの違い、変動するアスペクト比など挙げればキリはないので頭が痛い話だ。
<
・ おひとり様
・ Visual StudioこみゅにてぃやIntelliJ IDEAこみゅにてぃやAndroid Studioで、C#/UnityアプリやKotlinアプリやAndroidアプリを作ってあそびたい
・ Gitは入れて動かして出すくらいならできる
・ Gogs（https://gogs.io/）は使ってたんだけど、他にないかなーと思って
金融系SIerと一緒に仕事してるが、そこのエンジニアは原則ネット接続出来ない環境で開発している。
ホストシステムの開発なら別に構わないが、そんな環境でBtoCのインターネット公開サービスを開発しようとしてるのがタチが悪い
Android studioとか、インターネット接続下でないとインストールすら出来ない開発ツールがデフォルトなのに
そんなんだから生産性が上がらない。開発ツールのインストールだけで１ヶ月かかることもあるし、オフラインインストールが出来るかなり昔のツールを使わざるを得ないこともある
文字コードも今時shiftjisである。ホストと連動するからunicodeは使えないし第二水準までの文字しか使えない。
ITベンダの俺の職場のパソコンがとにかく低スペックなのである。予算がないだのなんだのいいながらちっとも買ってくれないのである。2018年も半分以上過ぎているのに、メモリは4GBしか乗ってないし、画面も狭いノートパソコンが、ただあるだけである。
会社は働き方改革を推進している。定時で帰らなければならない。作業を効率化して、生産性を上げて。もちろん、会議を削ったり、タスクの優先度をつけたりして生産量を上げる努力はしている。でも開発効率はなんともならない。だってパソコンが重いんだもの。でもパソコンは買ってくれない。
とかくフリーズするのである。rails s でデーモンを立ち上げてChromeでみたいし、インスペクタでDOMも解析したいんだけど、そうするとフリーズするのである。もちろんRuby Mineなんてない。買ってもらえないし、あっても動かないからである。
新技術も使ってみたいのである。できればdockerなんかも使ってみたい。CI組んでみたい。でもパソコンが耐えないのである。
同時にスマホアプリ開発は死ぬのである。Android Studioを立ち上げると、パソコンが。とまるのである。
動かない場合はどうするか。
ひたすら「待つ」のである。
ブラウザがとまると、要するにスワッピングしてるんだけど、そうすると数分待たされる。もちろんSSDなどでなくHDDだ。スワッピングならまだいい。パソコンがフリーズしていたら、さらに待たされる。そもそも画面に反応がないので、スワッピングしてるんだかフリーズしてるんだかわからない。とりあえず再起動するしか方法がない。
なぜパソコン、ひいてはエンジニアの環境に投資しないのだろうか。環境が整えば、1日に1時間は効率化できる。ざっと30万の投資としても、2ヶ月程度で損益分岐点に達する。精神面でいってもエンジニアは安心・満足するし、そうすると意欲的な開発ができる。使える技術の幅が広がることは管理職にとってもメリットがあるはずだ。こんなに簡単な判断をなぜ会社はしないんだろう。
我々はどうも苦労がどこかで報われると思っているようだ。これだけ苦労しているのだから、いずれなにかよいことがある。今苦労しておけば、明るい未来が待っている。贅沢しないのだ、敵だから。欲しがってはいけない、勝つまでは。
富豪的環境でなく貧者な環境で開発していると、最新環境でなくレガシー環境で開発していると、IDEでなくEmacsで開発していると、そのうちその努力は報われると思ってしまうのである。
競合は常にいろんな最新兵器を使っている。鎖国している俺の職場からは何も聞こえない。聞こえないフリをしている。攻め入られても竹槍でやりかえせばいいのだ。だから、今のこの環境で頑張る意味はあると。
教えてもらえるのは効率すっごく良いからそれが羨ましいんです 一人だと一つのバグ消すのに数時間かかったりして、調べても出てこなかったりして、そういうとき先生がいたら一発で分るのにって思って羨ましいんです androidアプリとかまるっきり意味わからん… いきなりandroid studioの意味不明なマニフェストファイルとかグラドルとかネット上で言われてもちゃんと説明してくれてる人いないし、いきなりよく知らんonなんとか関数使ったり、急に別のなんか意味わからない関数使って画面遷移してたり、そういうのバージョン違うとすぐ情報古くなるし、コピペしても動かないし、辛すぎ！！！！！！！！！！！！！やっぱ教えてくれる人いたほうが圧倒的にはやい！！！！！！！！！！
Android Studioをダウンロードして公式のチュートリアルやってるんだけど、いきなりつまづいたし。
アプリ実行できないし。
https://developer.android.com/training/basics/firstapp/running-app
まで来たけどビルドが出来ないし。（ビルドじゃないのか、gradle sync？とかいうやつ？）
org.gradle.internal.resource.transport.http.HttpRequestException: Could not HEAD 'https://jcenter.bintray.com/org/ow2/asm/asm-analysis/5.1/asm-analysis-5.1-sources.jar'.
とか言われとるし。
上のjarのドメインにping送ってみたら100%ロスしとるし。
そのせいか、
Android Studio で、[Project] ウィンドウの [app] モジュールをクリックしてから、[Run > Run] を選択します
グレーアウトしとるし。
分からないのは、ネット環境がないとアプリを実行することすら出来ないということだ。
サーバーが死んでたらその間何も出来ないのか。
そしてツイッターで誰も何も言ってないの見ると、誰も大した問題だと思ってないのか。
もう良い。俺にはAndroidアプリ開発は合わない。
Android開発者はこんな地獄の中頑張って開発してる自分を褒めたほうが良い。
