【UE4】Android向けビルドを行うとrungradle.batでエラーが出る問題
環境
Windows10
UE4.21.2
現象
こちらと同様です
https://answers.unrealengine.com/questions/720605/android-packaging-build-fail-ue-418.html
私の場合はOculusGoのビルド環境を整えていた時にこの現象に遭遇しました
LogPlayLevel: Error: ERROR: cmd.exe failed with args /c "C:\UE4_Prj\TestVR\Intermediate/Android/APK\gradle\rungradle.bat" :app:assembleDebug
いろいろ調べて解決方法はブログでまとめられている方がいらっしゃいましたが、断片的になってしまっておりまとめている人がいなかったので備忘録的にまとめておきます
↑のAnswerHub通りに
1. run NVPACK/android-sdk-windows/tools/android.bat
2. click on "Deselect All"
3. update Extras/Android Support Repository
を行っても解決しない！なぜだ！
という現象が発生します
Ant使えばBuildできちゃう
一応
Project Setting > Android > Enable Gradle instead of Ant
のチェックを外すとビルドは成功できちゃいます
しかし、これは根本的な解決になっておらず単純にGradleを使わずにAntでビルドしちゃいましょうという話なのでそれはちょっと・・・という感じなのでこれはダメ
原因と解決方法
原因はGoogleがライセンスを更新したのですが、その対応がUE4.21では間に合っていないことらしいです
なので
- こちらのpackage.xmlから中身をコピーする
- Engine/Source/ThirdParty/Android/package.xml にコピーした内容を上書き
- プロジェクトを立ち上げ「Project Setting > Android > Accept SDK License ボタンを押す
これで無事ビルドできました
詳細なことは↓のepic gamesのおかずさんのブログで解説してくれているので目を通しておくといいと思います
追記
1のリンクが404になる場合があるようです このリンクを開くにはGithubアカウントをEpicGamesのUnealEngineリポジトリを開けるようにする必要があります その方法は以下のリンクを参照してください 公式ドキュメント-GitHubとは？
参考
【UE4】プラグインを追加する場合の手順
はじめに
プラグインをUE4に認識させるまでは結構いろいろなブログなどで取り上げられておりBPだけならそれでも良いのだが、実際仕事をしていればC++で作業することになると思う
その場合は自分で追加したC++のコードからプラグインのAPIを使用することになるが、モジュール参照を追加しなければincludeすることができない
ちゃんとそのあたりも含めて手順をまとめている記事が少なかったのでまとめてみた
足りない手順または間違っている場合はコメントしてください
作業環境
Windows10
UE4.21.2
VisualStudio Community 2017
追加手順
0.前準備
1.プラグインのソースをプロジェクトに追加
プロジェクト直下に「Plugins」フォルダを作成してその中にプラグインのソースを追加する
2.UE4にプラグインを認識させる
〇〇.uprojectを右クリックし「Generate visual studio project files」を選択する
こうすることでslnファイルが再生成される（ちなみに、バージョン管理ツールなどの都合でslnファイルがない場合もこれで0から生成される）
3.VisualStudioを立ち上げてモジュール参照を追加する
UE4のソースコードはモジュールと呼ばれる単位ごとにUnrealBuildToolがビルドを行っている
なのでこの作業を行っていない場合includeに失敗するので気をつけよう
まず、VSを起動してソリューションエクスプローラから「(プロジェクト名).Build.cs」を開く
PublicDependencyModuleNamesに追加したプラグイン名を追加して完了
参考
AWS学習レポート①VPCを使ったネットワーク設計について
AWS学習レポート書いた経緯
最近全然アプトプットできていないのがとても嫌なのでレポート形式でちょっとずつ書くことにしました なにもしていなかったわけではないのです,AWSの本読んだり実際に触ってみたり、英語の勉強したり、マネジメント本を読んだりしていました。 正直個人製作のほうはほとんどできていません。新しいPCが届いたらUE4の記事書こうとは思ってます
で、AWSの勉強っていっても範囲はすごくひろくてそのすべてをうまいこと記事にする能力はないのでAWSが提供する基本的なサービスを一つずつ備忘録的に書き記していこうかなと思ったわけです 最終的にはAWSSAアソシエイトの資格を取得できるといいなって思ってます（とれるかな・・？）
AmazonVPCとは
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 ※AWSユーザガイドより引用
よくわからんですね。 要するにAWS上にプライベートネットワーク環境を構築できるサービスで AWSを用いてサービスを運用する場合、かなり多用することになる代表的なサービスの一つです
VPCを使ってネットワーク設計をする際のポイント
リージョンの選択
リージョンとはデータセンターのある場所だと考えていればいいと思います（東京とかオレゴンとか）
リージョンはAZ（アベイラビリティゾーン）と呼ばれる複数のデータセンターで構成されており、東京には現在4つのAZが用意されています
リージョンを選択する際には以下のポイントを気を付ける必要があります
法規や社内規定を満たすか
データには保存先の国の法律が適用されるため、社内規定には触れないかどうか、保存先の国では問題ないかなど考慮する必要がありますユーザとの距離
データセンターとユーザーの距離が物理的に離れていると、通信速度がどうしても遅くなってしまいます。
そのため、サービスの内容によっては設置したリージョンから離れた場所にいるユーザだと満足のいくサービスの提供ができない可能性がでてきます。
ちなみに東京リージョンとアメリカバージニア北部リージョンのレイテンシーの差は200ミリ秒ほどあります。使いたいほかのAWSのサービスが使えるかどうか
VPCはネットワーク環境を構築するサービスなため、多くの場合ほかのAWSのサービスと連携させます
しかし、新サービスなどは一部のリージョンでしか利用できない場合があるため、そもそも利用できるリージョンを選ぶ必要がありますコストパフォーマンス
AWSのサービスの価格はリージョンによって異なるため、価格の安いリージョンを選ぶことでコスト削減が見込めます
サブネット
サブネットとは大きなネットワーク環境をさらに小分けに分割したネットワークのことです
サブネットは基本的に独立しており、明示的に関係性を明らかにしない限り干渉しあうことありません
なぜ分割するかというと主な理由は以下の通りです
障害を広げないため
物理的に隔離することで一つのサブネット内で障害が発生してもその影響を全体に広げない効果がありますセキュリティ上の理由
サブネットをわけることで別々の設定ができるため「特定のサブネットのみアクセスが可能にする」といったことが可能になります
また、インターネットに接続するサーバーだけのサブネットを作り、ローカルネットワークから隔離することでセキュリティを高めたりすることができます
Internet Gateway
サブネットを作成するだけではインターネットに接続することができません
インターネットに接続するためにはInternet Gatewayへのルートを設定したカスタムルートテーブルを作成してサブネットに関連づける必要があります
なので、作成するサブネットはインターネットに接続する必要があるかなどを考える必要があります
また、インターネットに接続できるようにしたサブネットを「パブリックサブネット」、接続できないサブネットを「プライベートサブネット」と呼びます
パブリックIPアドレス/Elastic IPアドレスの割り当て
インターネットに接続するにはパブリックIPアドレスの割り当てを行う必要があります
AWSのパブリックIPアドレスプールからランダムに割り当てられ宇パブリックIPアドレスを使用してもよいのですが、この場合インスタンスが再起動するたびに変化してしまいます(それで問題ない場合もある)
もう一つの方法はElasticIPアドレスです。ElasticIPアドレスはAWSアカウントごとに割り当てられた固定IPアドレスでインスタンスに紐づけて使います
独自ドメインのホスト名とIPアドレスを関連付ける場合など、インスタンスのパブリックIPアドレスを変更したくない場合はこちらを使います
Security GroupとNACLの設定
Security Groupはインスタンスレベルで動作するのに対して、NACLはサブネットレベルで動作します
用途によって使い分ける必要があります
詳細は長いので以下のリンクを参考してください
まとめ
ようやくVPCについてだけでもブログにすることができました
基本的なサービスは随時アウトプットしていきたいです
正直結構端折っているので詳しく知りたい方は本を読むなり、気になったワードを検索したほうがいいと思います
参考文献
Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版
- 作者: 玉川憲,片山暁雄,今井雄太,大澤文孝
- 出版社/メーカー: 日経BP社
- 発売日: 2017/04/13
- メディア: 単行本
- この商品を含むブログを見る
Amazon Web Services エンタープライズ基盤設計の基本
- 作者: 堀内康弘,三浦美緒
- 出版社/メーカー: 日経BP社
- 発売日: 2018/10/04
- メディア: 単行本
- この商品を含むブログを見る
給料を上げたい人が勘違いしやすいこと
「給料を上げたい」
というのは誰しも同じだと思うのですが、その際に
「スキルを上げれば/会社内で評価されれば給料あがるはず」
と思っている人が結構な数いるなぁと感じます
実際すべて間違ってはいないのですが、ちょっと間違っています
正しくは
「お金を持っている会社でスキルを上げれば/評価されれば給料があがる」
が正しいと思います
そりゃそうだろ？と思った人はいると思いますが、これをわかってない人が実際多く存在します
例えば普段
「うちの会社はブラックだ、給料がやすい」
と愚痴りながら転職しない人や
「給料上げるためにがんばるぞ！」
と言ってるが、所属している会社は赤字だったり・・・
赤字の理由にもよりますが、多くの場合は赤字の企業でどんなにがんばって出世しても給料は上がりません
上がったとしても思っていたほど上がりません、それどころか
「出世して給料も少し上がったけど責任がすごい増えた、割に合ってない」
という状況になります
簡単な話、無い袖は振れないのでめちゃくちゃ優秀ではない限り、財政状況がよくない会社に所属している限り給料なんて上がるわけがないのです
給料を上げたいなら儲かっている企業に行くしかありません
なので、自身の今の給与に不満があるのなら所属している会社で評価されることに注力するのではなく、儲かっている会社に転職するためのスキルアップ/キャリアパスに注力するべきなのです
所属している会社で評価されることに注力するのは儲かっている会社に所属していることが前提です
簡単にまとめると
「黒字の会社に転職するために努力し、黒字の会社に所属してから会社に求められるスキルを磨くことが給料を上げる最短の道」
だと私は思います
DevelopersBoostにて登壇してきました
本日行われたDevelopersBoost（
https://event.shoeisha.jp/devboost/20181215/session/1900/）にて「スーパーエンジニアではなくても好きな分野で生きていくには」というタイトルで発表させていただきました
予想以上にたくさんの人に来ていただいてびっくりしました・・
ご来場くださった皆様ありがとうございました
【Unity】UnityのIKを試してみた
そういえばIKをちゃんと使ったことないということに気がついたので触ってみました
