helloworlds

色々試してみたくなっちゃうエンジニア 基礎をコツコツ...

【VR】Oculus GoをPCへミラーリングさせる(無線)

先日Oculus Goが家に届きました!

私が購入したのは、これ。

www.oculus.com

64GBの方を選びました。 俗に言うスタンドアローンというVR機器になるようです。

カートに入れて、購入完了して数時間で発送しますね!というメールがきました。 大体到着まで5日間ほどで手元に届きました。

「けっこうはやいな!」

中身を見てみるとけっこうシンプルにまとまっていました。 メガネを日頃かけている方でも安心。 メガネをかけている人用のアクセサリーみたいなのも付いていて、 スマホのアプリからOculusの設定をする時に、装着ムービーも丁寧に紹介されていました。

(※ わかりやすいように、画像を載せようかと思っていたのですが、この記事では割愛します。が、その分丁寧に書いてくつもりです! また、後日画像を掲載させていくかもしれません。合わせて詳細も追記していければと思います。)

ここから、"PCへのミラーリング"について順をおって説明します。 今回は以下の記事を参考にさせて頂きました!さっそく先人の方に感謝...!!

Oculus Goの画面をPCにWirelessでミラーリング表示する

準備

まず、色々準備が必要です。 すんなりいけば大丈夫ですが、私はある設定で少し詰まりました... スマホアプリの開発を経験されている方はけっこうすんなりいきそう...

では、まず環境から。 あくまで私の環境ですので、他の環境では試していません。随時、自分にあった環境の設定方法をググる必要があるかもしれません。

環境: Windows10 (デスクトップPC) ブラウザ: Chrome

1. スマホアプリと連携

iPhoneならApp Storeで、AndroidならPlayストアOculusというアプリをダウンロード。

ログインを行い(アカウントを作成する必要があります)、手順に従って連携完了まで行う。

1-2. 開発者モードにする

ミラーリングするにしても、Unityで開発を行うにしても Oculusに対して開発者モードに設定する必要があります。

まず、以下のURLへ移動しログインします。

https://dashboard.oculus.com

そうすると、「新しい団体の作成」という画面が表示されるかと思います。 任意の団体名を記入し、送信し、完了させます。

完了すると以下の画面が出てくるかと思います。

f:id:o21o21:20180531111157p:plain

一旦これでOKです。

スマホアプリに戻ります。

画面下部メニューの"設定" -> 接続しているOculus(シリアルナンバー付)をタップ

-> ”・・・その他の設定” -> "開発者モード" -> スイッチを"有効化" (青色にする)

これで完了です。

2. Android Studioをインストール

続いては、PCの方です。

色々調べてみると、ミラーリングするだけだったらadbコマンド (Android Debug Bridge)が使用できていれば問題なさそうです。 なので、既にAndroidの開発などをされている方は、不要かもしれません。 ここでは将来的にUnityでOculus Goを開発することを目的にしたいので、一気にAndroid Studioをインストールします。

公式: Android Studio概要

以下のURLに行って、ダウンロードします。

Download Android Studio and SDK Tools  |  Android Developers

f:id:o21o21:20180531114053p:plain

  1. ダウンロードした.exeを開きます。
  2. 特に指定がなければ全部デフォルトでインストール&Nextボタン押下で大丈夫です
  3. 全てのインストールが完了すると、Android Studioを起動します
  4. ウィンドウ下部にある、Configure -> SDK Manager を選択
  5. 左メニューAndroid SDKを押下し、タブSDK Platformを選択。
  6. API Level19以上のものにチェックを入れます
  7. タブSDK Toolsを押下し、LLDBGoogle USB Driverにもチェックを入れます
  8. ウィンドウ下部のOKを押下し、Component Installerが開かれインストールが開始されます

ここまでできたらウィンドウを閉じて大丈夫です。

3. adbコマンドを試す

Android StudioをインストールしてSDKもインストールできれば、 Windowsコマンドプロンプトadbコマンドが使用できているでしょう。

ここで、付属していたUSBケーブルとPCを接続します!

私の場合はここでadbコマンドが使用できず、 "’adb’は内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません"

と、出力...

「なんでやあああああぁぁ!!!」

とか言いながらググりました。

結果、環境変数のPATHが通っていないことが判明。 いつもやってんのに... 普段Windowsあんまり使わないから見落としてた。 (私の場合は早期に環境変数に気づきましたが、PATHがさらに間違っていたから時間とりましたww)

もしコマンドが使用できないなら、コントロールパネルを開いて、 システムとセキュリティ -> システム -> 左メニューのシステムの詳細設定 -> 詳細設定タブ環境変数(N) -> 環境変数PATHを選択して編集 -> 新規

ここで私は2つPATHに対して新規で追加。

C:\Users\ユーザ名\AppData\Local\Android\Sdk\platform-tools
C:\Program Files(x86)\Android\android-sdk\platform-tools

ちゃんとPATHがは自分で確認してください!! 上記のpathを参考にエクスプローラーからポチポチしていけば確認できかと思います。

そして、いざコマンド実行。

> adb devices
List of devices attached
xxxxxxxxxxxxxxxxxx        unauthorized

「NOOOOOOOOOぉぉぉぉぉ〜〜〜!!!」

なんか権限ないですやん...

まあ、ただadbコマンドは使用できていてOculusは認識しているっぽい。

ふむふむ

ってことは、どっかで権限を有効にしてやるかんじかなと、またググる

本来?というかAndroid端末であればどうやらUSBデバッグの許可の取り消しなるオプションがあるらしい。 ただ今回はOculusさんだぞ...

「どこを探してもない.... おおおおおおおおおお」

ってなってたらオキュラスのレンズから光が見えた!!!!www

USBデバッグの許可は、Oculusの画面から許可してあげる でしたwww

すげえバカでしたが、まあよしとする。

一応なのですが、adbサービスの再起動として、以下のコマンドを実行させます。

# 停止
> adb kill-server

# 起動
> adb start-server

ということで、もう一度デバイスの確認実行。

> adb devices

List of devices attached
xxxxxxxxxxxxxxxxxx        device

OK。

続いてOculusのIPを調べる。 無線LANなのでwlan数値を指定します。 ちなみにeth0は有線。

> adb shell ip addr show wlan0

出力された情報のinetの横にIPが確認できるかと思います。 おそらく192.168.xx.xxみたいに出てるかな?

adbでportを開放

portを開いていきます。 portの範囲は、5555~5585の範囲で奇数を指定したほうがよさそうです。 こちらがadb の仕組みです。

今回は公式で紹介されている通り5555で試します。

> adb tcpip 5555

これでUSBを介して、port5555でTCP/IP 接続をlistenするようにOculusを設定しました。

ここで、PCに接続しているOculusをUSBケーブルを抜きます

※ 接続切れている場合は、adb connect <IP>:5555 で接続にトライしてみてください。

Vysorの設定

ここまできたら、あとはVysor(バイザー)のインストールと設定のみです。

Vysorとは、ブラウザChromeで動くアプリケーションです。 スマホ画面をパソコンへミラーリングさせるアプリのようです。わたくし初見でした。

まず、ブラウザにインストールします。

Vysor - Chrome ウェブストア

すると、chrome://apps/ に追加されていると思います。

起動させます。

起動させたウィンドウ上部にOculusの接続が確認できていればOKです。 もし、確認できていなければ、Settingsの上にあるConnectボタンを押下。

コマンドプロンプトで確認したIPとportを指定して接続します。

これでOculus Goを開始すればミラーリングできているかと思います!!!!!

f:id:o21o21:20180601001606p:plain

自分では見えねえよってかんじですがww

Discordの画面共有で友人にみせてあげましたww

当人いわく、「画面見れてるよ!!! ただお前ほどの感動はない」

とのことでしたwww

やはりVRで見れないので、購入してVR体験してもいいかもしれませんね!!

次回は、Unityでのプロジェクト環境構築&作成考えています。

以上.

【インフラ】クラウドについて考えてみた

だいぶ日が空いてしまいました。。。

今回はインフラについてこちらの本を元に学んでいる最中なので、記事にしてみました。 インフラといっても、ほとんどクラウドについての内容になっています。

インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現

インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現

まずは、歴史から

インフラというと、なんだか堅い印象を私は持っています。

社会人出たてで、自社開発が叶わず面談行ったりしているときにも、 1社インフラよりの業務ということでお話を聞く機会がありました。

今の35歳から上の方でサーバサイドとかインフラエンジニアをやっていた方だと、 営業先の帰りに電気屋に行って、サーバーを購入した!とかお話を聞きました。

現在だと、もはや物理サーバー(オンプレサーバー)を使用している会社は、クラウド(Cloud)に移行しているのではないでしょうか?

クラウドサービスでいうと、AWSGCPなどが有名ですね! 私が業界に入ってからだと、クラウドが当たり前で、会社に入ってもオンプレからクラウドへの移行後だったり、 移行中やオンプレはわずかなんて会社が多かったです。

そんなこんなで、ビジネス面ではどういった動向がみられるのか調べてみました。

それぞれ、リソースの単価利用期間リードタイムをメモしました。 (引用:技術書インフラCI)

f:id:o21o21:20181010112044p:plain:w300

メインフレーム

この時代だと、主に銀行などのシステムで活用されていたようです。 きっと大企業のインフラくらいだったのでしょう。

オープンシステム

この頃から、今でも馴染みのあるWindowsUNIX系のOSのが登場しました。 一般な業務システムは、インターネットに接続されたサーバーとして活用されていきます。

クラウド

そして、現代のクラウドですね。 最近では、スマートスピーカーなど、Iotなんかは従来のITの領域を超えてきているといってもいいでしょう。

ここまでで、クラウドという単語を多々使用していますが、

そもそもクラウドとはなんなのか?ということです。

エンジニアの方なら説明できるでしょう。 ここでは詳しくは取り上げませんが、簡単に説明します。

クラウドとは?

クラウドとは、英語ではという意味を指してCloudと言います。 ただし、英語の場合、"Cloud ○○" と何か指すときには言うようですね。(例: Cloud Service, Cloud Computing...)

ちょっと断言できないのですが、日本でいうクラウドは、英語で(正式に)いうクラウド コンピューティングにあたるようです。 それは英語で単にCloudというと、空にある雲という意味にも英語圏の方はとれますよねw 日本語では、クラウド=CloudComputingという認識かな?

まあ、そんな細かいことは置いときます。

(言葉って難しい...)

クラウドとは、簡単に、

インターネットを通じて、ITリソースを必要なときに、必要な分だけ利用するという考え方」のことです。

うむ?どいうことや?

「ソフト(Excelとか)、ハードを購入しなくても使用できる」ということ。

これでなんとなくイメージしやすくなったのではないしょうか。

つまり、GmailEvernoteなどのサービスが該当します。

例えば、Gmailの場合、PCに特別アプリをインストールしたり、クレジットカードを登録して課金して使用するものではなく、オンラインでブラウザさえ使用できればメールのやり取りが可能ですね。

こうしたサービスを、クラウド SaaSとして提供されるものです。 他にも PaaS (Dockerなど)や、 IaaS (AWSなど)という種類を分割してクラウドサービスを分割できます。

そして今回は、この記事の文頭で言った通り、インフラについて学んでいるので、 IaaSの部分がメインになってきます。

さて、AWSが世界的にも有名サービスですが、 いったいどうして物理サーバーを購入しないでAWSの利用者はサーバー(EC2とかのインスタンス)を起動、ターミネイトしたりしているのでしょうか??

もちろんAWSの人たちが、サーバーを逐一起動させているわけではありませんwww (そんなことしてたらAWSの社員はいくらいても足りませんねww)

仮想化

こうした疑問のほとんどが、仮想化で賄われています。 例えば、1台の物理サーバーで複数台の仮想的なサーバーを運用します。

つまり、AWSでは利用者がインスタンスを作成するAPIを叩くと、AWSの世界各国にあるデータセンターの物理サーバーがクラウドサーバー(仮想サーバー)を起動させ、運用がすぐに可能になるということです。

この時のサーバーのスペックなどによって、きっと起動させるサーバーは異なるでしょうが、一気に複数台のサーバーを起動させることも容易になっています。

うん、アマゾンはすごいな〜。 なので、アマゾンの技術者は物理サーバーをメンテすることはありますが、AWSの利用者は物理サーバーをメンテナンスをすることはありません。 オンプレの場合、物理サーバーを設置する場所もセキュリティ上の都合で選ばなくてはなりませんが、クラウドならアマゾンの社員が物理サーバーの保守をしているので、その心配はないということです。世界各国にあるデータセンターの場所は公開されていないですが、日本国内にも存在してます。

そのうち、サーバーの仮想化についてもより詳しくみていきたいと思います!

話を戻します!w

スピード感!

こうした技術の発展で、QCD (Quality,Cost,Delivery)という考え方も変化しています。 なにかシステムを構築する際、QCDの評価軸に沿わないことが多々あります。

AWSのようなサーバーを利用うる場合、意識するのはFFFです。 これは「Fast Fast Fast」です!w

スピード感を持って試行錯誤し、結果的に効率的になり、品質の良い構築が可能になるというこです。 これは私も感じています。 AWSですが、インスタンスの起動はあっというまく間なので、 いろいろ試していた結果、「こっちの方法のほうがうまくいくな!」とか早い段階で気づくことができたりします。

まとめ

今回はほとんど紹介した本の内容には載ってないものになっていますが、 要は基本的なところを抑えた記事になります。

クラウドエンジニアやこれからのインフラエンジニアというのは、技術の移り変わりで 従来設定に時間が取られていたところを簡単に設定できるようになりました。

おかけで仕事が減ったように感じますが、エンジニアとしての価値を上げていかなければなりません。 それは、自動化であったり、従来はできなかったことに挑戦したり、研究したりする時間があるということです。

業務自体と手法も変動しますが、概念や考えた自体も見直し、(違う職種の方などに)共感してもらうことも大切だと思います。

次回は、具体的に自動化について書いていけたらと思います!!

以上.

【macOS】High Sierraでダークモードにした

先日Xcodeをインストールする関係で、OSのアップデートをしました。 けっこう時間がかかりましたが、ダークモードが使用できるとのことだったので、さっそく使用してみることにしました。

今年の頃に、macOS Mojaveという新しいOSが発表されるそうですが、 そのmacOS Mojaveには、完全にダークモードが追加されるようです。

なので、今はベータ版といったところでしょうか? まあ、日頃の操作で困るところがなければインストールしてみてもいいかもしれません。

ちょっと見にくいかもしれませんが、画面上部のメニューが暗くなりました。

f:id:o21o21:20180827122013p:plain

Dockの方も暗めになったかな?? 長時間使用するので、少しで暗い方が助かる...

ダウンロード - macOS High Sierra 10.13.6 統合アップデート

Chrome

私はChromeでもファイルを読み込ませて、GoogleEngineの検索結果画面を白色から変更しています。

そこまでするか!?と思う方もいるかと思いますが、ちょっとでも暗くしたい...ww

f:id:o21o21:20180827122441p:plain

これはChromeプラグインで簡単に設定できます。 ただし、調べたら以下のようなコメントがしてあったので、ここで紹介するのは控えますw

この拡張機能は Chrome ウェブストアのポリシーに違反しています

ターミナル

今までターミナルやiTermからgitで管理されているディレクトリに移動すると、 ブランチ名を表示するようにしていました。

今回、OSのアップデートをかけたら表示されていないことに気づきました。

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

そして、gitコマンドを叩くとこんなエラーが。。

調査したところ、xcode-selectとあんるものをインストールすれば解決するとのこと。

$ xcode-select --install

ちょっと時間がかかりましたが、上記のコマンドでインストール完了したら、元通りになりました。 xcode-selectについて、詳しくはこちらの記事を参照してみてください。

以上.

【海外消費者向けEC】越境型ECサイトを考える

今回は定性的な話です! あんまり意識したことなかったのですが、海外消費者向けのサービスについて少し考えてみます。

f:id:o21o21:20180814180125j:plain

まえおき

ECサイトなんか運営していると、海外在住の方に向けて商品を売りたいと思うのは当たり前な世の中ですね。 また、消費者側も日本のあの商品が欲しいと思っている方が多いと思います。

2020年のオリンピック開催に向け、外国人の観光客も増え、より日本の文化に触れたり、 かわいい商品買って、自国に帰ってからも関心が高くてまた購入したい!など、 ECの競争はより国外に向けれていくのかなとか思います。

ECの業界の革命

最近EC界の帝王Amazonが起こした革命をご存知でしょうか?w

それは、International Shoppingというものです。

技術者でない方にはあまりこの凄さが伝わらないのですが、 簡単に言うと、アメリカで取扱されている商品を日本円で購入できるというもの。

言い換えると、www.amazon.comwww.amazon.co.jpの境界線がなくなった、と言えるのではないでしょうか。

日頃から個人輸入が行えるサービスを利用している方は、そんなに驚くこともないだろう。 Paypalとかebayなどのサービスを使用していたり、仮想通貨なんか使用している人も、 世界共通通貨のようなカタチで商品の売買に慣れているので、まあ世の中そんな流れになってきているかんじですね。

まあ、仮想通貨までいくと少し、ここで話をする主題とズレるのですが、 現状、国内向けECサイトを運営していて、(しかも自前でソースコードを管理していて) これから海外消費者に向けてサービスを展開したい!みたいなところに目を向けてみました。

海外消費者向け購入発送代行サービス

国内にも手軽(企業向けかな?)に利用できるサービスがあるようです。

海外消費者向け購入発送代行サービスと呼ばれるサービスで、 既存のEC既存サイトに簡単なバナーを設置するだけで、商品の海外発送まで代行してくれるという。

自分は初めて知ったので、便利だなーと感心。 たしかに、エンジニアが不足している企業だったりすると助かるサービスかもしれませんね〜。ん〜。

BuySmartというサービスも同様で、基本的にHTMLをviewに埋め込むだけで使用できるという。

手軽さでいうとたしかに助かりますね!

ただ、こうした越境ECになると一番気をつけないといけないのは、発送ではないでしょうか。

購入できても、お客様に商品を届けないと意味がないですよねw

この商品に関して、国内なら簡単では国外に向けて発送になると法律的な面で意外と大変です。

郵送禁止物品として扱われるモノは勿論法律違反となります。 例えば、爆発物・危険物(ライターとかも対象になるのかなあ)や生きた生物などなど。

法律だけでなく、条約にも関係してくるので、いちいち調査する手間がかかります。

ですが、代行サービスではそうした手間も省けるものがほとんどです。 購入された商品を、代行サービスに届けるだけで、あとはお任せできます。

んーこれは楽だな〜

技術者ならば、発送はおれの仕事ではないと考える人も少なくないのでは?w

少し技術的な話

こうしたサービスを利用する際に、考慮しておきたいのはIPの制限とかではないでしょうか? AWSでは、CloudFront (クラウドフロント)というサービスがあります。

CloudFrontには、地理的ディストリビューションの制限が可能です。

AWSコンソール上で、簡単に国単位で設定がポチポチでできてしまいます。

ECサイトを運営する際に、海外にも展開するのはいいですが、 例えばアメリカは駄目とか東南アジアのみにしたいとかあるかと思います。

そうした場合にCloudFrontを利用するとよさそうです。

また、言語化についても考慮しておきたいですね。(一応) 私も経験があるのですが、納期に迫られるとかなり効率の悪い多言語対応をしてしまいます。

負の遺産というやつですねwww ソースコードも読みにくくなるし、いいことないです。 viewで判定したり、そのためにテーブル作成して....とか

今ではそうしたゴチャゴチャにならないように色々サービスが提供されているはずです。 例えば、Amazon TranslateなんかはAPIで自動翻訳してくれます。

最近日本語も対応したようです。 少し文法的に変化もしれませんが、負の遺産を産むよりましかもしれません。 Amazon Translateのヴァージョンアップでより良くなるのを待つほうが楽ですね。

言語で用意されている環境変数とか利用すればいいとか、方法は様々ですが、 できるだけシンプルに将来を見据えて設計していくことがかなり重要といえるでしょう!

【AWS】EC2のリタイア!?

今回はEC2について、ちょっとあんまりみない現象なのかな?と思い調べてみました。

リタイア!?

なにが起こったかというと、こんなメッセージがEC2のメニューで表示されていた。

f:id:o21o21:20180814120153p:plain

なぬ!ってかんじでしたw

このインスタンスAWSコンソールをいじっていたところ、 上記のメッセージを確認。。。

もう少し詳しく調べてみましょう。

詳しく

公式にはこう定義されていました。

インスタンスをホストしている基盤のハードウェアで回復不可能な障害が検出されると、AWS によってインスタンスのリタイヤが予定されます。

ふむふむ。ってことは、なんか致命的なエラーでも出ているのか?

再度EC2のメニューから確認してみたが、そんなことはなさそう。 EB(Elastic Beanstalk)から立てられたインスタンスだったので、ヘルスも確認してみたが別に普通。

なんでだろう?ということで、調査するとどうやらメールが届いているらしい。

確認してみるとこのようなタイトルのメールが届いている。

[Retirement Notification] Amazon EC2 Instance scheduled for retirement.

これですなw

詳しく本文を読んでみると、ハードウェア(インスタンス)の劣化が原因で、リタイアの設定がなされたようです。 納得ですね、特に何もインスタンスに対して変更をかけていないと勝手に起こるものらしい。

対応策

今回はEBなので、ポチッとインスタンスもう1つ増やしておけばOK。 対応策については、ルートデバイスタイプによりけりみたいです。 以下に公式ドキュメントを貼っておきます。ドキュメントの下部にルートデバイスタイプ別のアクションが載っています。 それで、対応してみるのがよさそうです。

docs.aws.amazon.com

くれぐれも日付を過ぎてからでは、面倒なことになりかねないので、メールをちゃんとフィルタしておこうと思いました! いや!そもそもインスタンスをきちんと管理していなと駄目ですねww

ただ沢山あると忘れがちになりますが。。。

以上.

【リアル 7.1ch】Razer Tiamat 7.1 v2のセッティング!?

ちょっと今回はプログラミング系の記事と離れます!!www

今回はオーディオ系!!

プログラミングとは関係ないのですが、ハード、 つまりデスクトップやラップトップ(ノートパソコン)には関係します!

ただ、今回扱うものとしては、ゲーマーの方や、主にデスクトップで 個人的になんかしている方向けってかんじかもしれません。。

しかも、全然オーディオ系に詳しくないので、間違っている部分もあるかもしれないので、ご承知下さい!! ※ 完全素人知識です!

この記事を見て、「お!そんなのあるのかー」と、思って頂けるだけで嬉しいです!

さて、

まえおき

私の趣味で今色々と自宅にあるデスクトップとヘッドセットをいじいじしていました。 一応最低限の設定が完了したので、ちょっとまとめてみます。

というのも、最近新しいヘッドセットを購入しました!

そのヘッドセットをまあ買ってみたのはいいものの...

設定だったり、購入を検討しているときにググってみてたのですが、 なかなか一通りの流れを抑えた記事が見つからなかったので残しておこうと思います!

今まで

今までヘッドセットを自宅で使用していたのですが、 そのヘッドセットは、7.1 バーチャルサラウンドサウンド搭載の

Razer Kraken USBという商品を使用していました。

Razer Kraken USB

Razer商品なので性能抜群だなあ!と、購入当初は思っていました。 接続もデスクトップのUSBにそのまま接続するだけ。

ただ、使用していくうちに、だんだんヘッドセットにも関心が湧いてきて

もっとおもしろいヘッドセット、高機能なヘッドセット使ってみてええええ

と思いまして、今回........

購入したものは

Razer Tiamat 7.1 v2!!!!!!!!

www2.razer.com

「かっこいい... やっぱRazerでいくか」

と、思ったので思い切って購入!(Razer信者というわけではないw)

f:id:o21o21:20180808211140j:plain

こちらがもう、TRUE 7.1 サラウンドサウンド、つまり、

リアル7.1サラウンドを搭載しているのです!

ヴァーチャルとリアルの違い

サラウンドサラウンドというのは主に2種類あると認識しています。 それが、

  • リアルサラウンド
  • バーチャルサラウンド

の2つです。

バーチャルサラウンドとは、擬似的に立体的な音の広がりを再現しているものです。例えば、左右のスピーカーが立体的な音を出力している。 リアルサラウンドとは、複数のスピーカーを配置。各スピーカーは、配置された場所の音のみ(正確にはその場所だけの音のみというわkではないみたい)を出し、ひろがりのある音を楽しむことができます。

リアルサラウンドの方は、よく電気屋のオーディオの隔離されたスペースなんかにあるあれですね、たぶん。

色々と調べるとヴァーチャルの方はもはや一般的?というかソフトを使用しても実現可能な時代になっているようです。

なので、結局リアルサラウンドの方がよりリアルwwwというわけです。

私はすぐに手に入れたくなるので、Amazonで買わず店頭に出向きました。

買う前になにも確認せず行ってしまったのですwww

店頭にあるサンプルを見て、

「あれ? 6本もケーブルあるぞ...」

って気づきましたw

1本はUSBでクローマの電源供給用で、他5本は全てマイク端子とオーディオ出力端子のもの。

自分のデスクトップにどれだけの3.5mmジャックがあるかも確認しなかったのですw なので、スマホでググって型を調べ、デスクトップを購入した店舗にも電話して確認。

3.5mmにジャックが自分の場合、3本のみ。。。 まじかよ、、、とか思っていたら、店員さんが

「余っている2本のジャックはデスクトップのフロントに端子があるので、延長して繋いで、ソフトで調整したらいけるかも」

とのこと。

なるほどーとその時は思っていたので、延長ケーブルを買って帰宅。

さっそく試したら、明らかに無理やんけ。wwwwwww

サウンドカード登場

ヘッドセットを選ぶ前にサウンドカードという機械を頭の片隅に覚えていました。 サウンドカードとは、音質の向上や入出力端子の増設などを目的としているもの。

友人にも聞いてみたらサウンドカード必要じゃね?ってかんじだったので、 Tiamat購入した次の日にさっそくまた電気屋に!w

サウンドカードがある棚に行き観察。

今回は事前に調べてたので、多少商品の目利きができましたw

サウンドカード自体、内蔵型外付けがあります。

外付けは名の通り、USB接続でデスクトップに接続できちゃいます。 内蔵はデスクトップをこじ開けて、デスクトップ内部に設置しないといけません。 ただ、店員さんいわく、今の内蔵型は、わりと取り付けが簡単なものが多いとのこと。 ただし、サウンドカード自体に電源の供給が必要なものには注意したほうがいいらしい。

昨日も高い買い物したのに、今日もかよ...と私は外付けの方を購入。

www.asus.com

「よし、これでTiamat使えるー」

って思いながらXonarを接続していた矢先....

「ん? なんか端子変なのある... 」

f:id:o21o21:20180808194350j:plain

「.............................」

これはよくテレビの裏側のやつに似ている...

そっこうググる

これはどうもRCAと呼ばれる端子らしい。

Tiamatの接続できなかったケーブルは、緑色(フロントのR/L)だった。 フロントスピーカーのライトとレフト。 この状態だと音は出るかもしれないが、フロントR/Lはでないとか推測できる。

あーーまじかよーーーー とか思いながら思いついたのは変換すること。

変換ケーブル

1本の3.5mmステレオミニジャックをRCA端子への変換ということ。

あった!

そっこうで、家の近くに電気屋に走っていきましたw

ケーブル商品を前にしてまた気づいたことが。。

これ、さす方とさされる方があるのか。。 まあ当たり前なのですが、もうはやくTiamat使いたすぎて色々とぶっ飛ばしてますww

これはどうもオスメスという単語で、この領域では言われているらしい。 (ちょっと想像すると変な気持ちになりますw)

わたしが行った店頭に置いてあったのは、変換ケーブルのジャックがメス(言い方正しいか不明)のはなかった。 なのでオスを購入し、中継アダプタも購入。

オーディオ編:中継アダプター|AVコード製品一覧 | JVC

やっと、やっとだと思って試した。

結果、フロントの右のスピーカーが鳴らない........... 意気消沈......

あきらめなかったww

ここまできて知らなかったことが色々とわかってきた。

どうやらこうしたジャックやらプラグというものの仕組みを理解してみた方が良さそうだ。

イヤホンジャックのつなぎ方-電子工作とメモ

この説明を読んでみると、Tiamat側のプラグはステレオで、 サウンドカードのRCAは、アナログ接続に対応している。

電気屋でかった中継アダプタもステレオに対応しているし、 変換ケーブルもステレオ対応。

あれ?とおもってよーく変換ケーブルの説明みたらiPodって書いてある!wwww バカすぎますねw まあいーんです、色々わかってきたので。

翌日、ちゃんとした変換ケーブルを購入しに電気屋へ! わたしはオーディオコーナーに行って、店員さんにやりたいことの説明をし、 JVC CN-140Aというケーブルを購入しました。

これで再度接続してみたら、やっと、ようやく音がでたーーーーー!!wwww

これで、リアル7.1サラウンドを体感できました。

Equalizer APO

最初接続完了してからSUBウーハーが鳴っていないことに気づきました。 どうやら個別に設定が必要なようです。

無料ソフトのEqualizer APOというものをデスクトップにインストール。

設定はわかりやすいこの動画を参考にさせていただきました!! (本当に知識の共有って素晴らしい...!)

youtu.be

あとは、触っていくうちに自分で好みの設定に近づければ良さそうですね!

まとめ

リアル7.1サラウンドのヘッドセットを購入する際に考慮しておきたいことを挙げます! あくまで、最低限ということ覚えておいて下さい!

  • 欲しいヘッドセットの仕様を確認する
  • ヘッドセットのチャンネル数に対して、デスクトップのマザーボードで出力できるチャンネル数を確認する
  • デスクトップのイヤホンジャックの数と役割(色など)を確認する
  • ヘッドセットのケーブルの役割を把握する (ケーブルが複数ある場合は、どのケーブルがどのスピーカーなのかなど)
  • イヤホンジャックに応じて、サラウンドカードの導入を検討する (内蔵/外付け)
  • サウンドカードが外付けの場合、端子に注目する(ヘッドセットのプラグと合うかなど)

マザーボードの取替はよっぽどでないと行わないようなので安易に改造を考えないほうがいいみたいです。

とまあ、長くなりましたがこんなかんじ。 本来変換ケーブルとかかませたくないのですが、一旦はよしとしました。

後々、サウンドカードの内蔵型を導入も考えてみようかなと思っています。

かなりノリで乗り切れると考えていましたが、けっこう設定なりが難しいので、 この記事が少しでも誰か役に立てばと思っていますw

以上.

【Datadog】入門 Amazon Linuxに導入

今回はDatadogについて簡単に、何ができるかと Amazon LinuxにDatadogを導入する方法を書いていきます。

まず、そもそもDatadogってなにってところからおってみます。

f:id:o21o21:20180807090724p:plain

Datadogとは?

サーバなどに関するモニタリング機能(SaaS形式)のサービスです。 ただのモニタリングできるサービスか!ってわけではありません。

使用するとわかるのですが、ビジュアライズが凄い綺麗だったり、 tagを使った多次元解析できて、リアルタイムにサーバーの状況が把握できたりします。

もう少し深追いしてみます。

Datadog Agent

監視を始める前に、ターゲットとなるホスト上にDatadog Agent (ソフト)を動作させる必要があります。 ターゲットホストの情報(イベントやメトリクスなど)を取得し、Datadogに送信します。

Datadogはドキュメントもよく揃っているので、一度は目を通してみてもいいかもしれません。

docs.datadoghq.com

このDatadog Agentは主に3つの要素で構成されているそうです。

  • Collector CPUやメモリなどの一般的なシステムメトリクスとIntegrations(後述)の情報を取得。

  • DogStatsD ホスト上で実行されている、アプリケーションやコマンドラインスクリプトからカスタムメトリクスを送信。

  • Forwader CollectorとDogStatsDのデータを受け取り、queueの順番に従ってDatadogに送信する。

ふむふむ、なんとなく想像はつきますね。 少し出てきた、Integrationsについて確認してみます。

Integrations (インテグレーション)

Datadogが提供しているIntegrationsは、他の監視システムでいうとプラグインみたいな位置づけでしょうか。 たくさんのIntegrationsが用意されています。

こんなかんじ↓

f:id:o21o21:20180807092733p:plain

Integrationsによっては、Datadog Agentの設定ファイルに追記が必要な場合もあるとのこと。 有名なサービスであれば、設定ファイルの記事も多少あったと思います。

Amazon LinuxにDatadog Agentをいれる

別にAmazon Linux(AL)じゃなくてもいいのですが、けっこうAWS使用している会社も多いと思うので例として。 ほんとに説明する必要ないくらい簡単です。

まず左メニューのIntegrationsクリック(選択肢出てきたらAgentでもOK)して、上タブのAgentでOSの選択画面にいきます。

f:id:o21o21:20180807093413p:plain

そしたらALを選択。

f:id:o21o21:20180807093606p:plain

すると、インストールコマンドが表示されるので、コピーして、 ターゲットとなるホストにsshなどで接続からの、コマンド叩いて終了です。

f:id:o21o21:20180807094002p:plain

実に簡単ですね!! 導入したのを確認するには、左メニューのinfrastructureをクリック。 導入したホストが表示されているかと思います。画面上部には、こんなかんじで

稼働中ホストの数 Hosts up / 合計ホスト数

今導入されているホスト数が載っているかと思います。

導入後は、自分が見やすいようにダッシュボードやモニターを設定していきます。

ダッシュボード

私も機能を使い切れていないので、ドキュメントを貼っておきます。

ダッシュボードのテンプレートの作成方法

こんなことできるよ!というのはこの方の記事が日本語でよくまとまっています!

Datadogの本当の魅力とは

こうした設定方法は、後々また記事にできればいいなと思っています! けっこう監視初めてだと、どうした設定をしていけばいいのか、 どこから手をつけていいのかわからない場合が多いような気もするので、 そこらへんも含め次回以降の記事にまとめていけたらと思っています!

以上.

【AWS】シンプルなリリースプロセス自動化 ( Github + CodePipeline, CodeBuild, Elastic Beanstalk )

今回はAWSを使用したシンプルなリリースプロセスの自動化について考えてみます。

リリースプロセスとは、開発から本番サーバーまであげていく(= リリース)ことをここでは指します。 また、たーっくさんのノウハウがあるので、この記事ではあくまでも一部。 やり方、状況1つでけっこうな構成が考えられるので、そこはググってみて下さい。 また、この記事ではAWSコンソールの画像は載せないので、ご自身のAWSコンソールで確認しながら用語など確認してみて下さい。 今回の記事では、本番というかステージサーバーまでというイメージになりますが、一旦構成できてしまえば、本番も簡単ですので、一読頂けたら幸いです。

f:id:o21o21:20180803144307p:plain

まず、Code3兄弟

AWS界隈では、よくCode三兄弟なんて呼ばれているサービスがあります。

そのサービスとは、

  • CodeCommit
  • CodeDeploy
  • CodePipeline

この3つのことです。

DynamoDBやS3は知ってるけど、この3つは使ったことないという方も多数いるのではないでしょうか。 自分の会社でもし使用しているのであれば、是非構築した人にどうしてこの構成にしたのかなど聞いてみると面白いかもしれません! もしかすると、苦悩など聞けるかもしれません。。。w

また、上記のサービスと合わせて、Jenkinsというツールを使用されている方も多いのでは? けっこう記事も多くありますしね。

ただ、私としてはAWS内のサービスでまかなえたらと思います。 理由は、ただ面倒くさいから....w

この3兄弟についてはざっくりこんなかんじです。

CodeCommitは、AWS版Git。 CodeDeployは、EC2へのファイル配置とスクリプト実行を自動で、プラスで環境毎で管理しやすいよ。 CodePipelineは、アプリのビルドやテストのフローを管理・自動化してくれるよー。

みたいなかんじです。

あれ?タイトルのCodeBuildは?

こちらは2016年のre:Inventにて、発表されたサービスのようです。 もう2年くらい経っているので、今ではCode4兄弟になっているようですww

一旦、Codeなんちゃらと言われるサービスは、リリースまでの手助けをしてくれるものとしてざっくり覚えておけばよさそうですね。

(※ コード書くとかほんとに全てAWSで収めたい場合、CodeStarと呼ばれるサービスもあります。参考 )

CodeBuildもざっくり言うと、フルマネージド型ビルドサービス。(自分でビルドサーバーを管理しなくていい)

うんうん。まあ、一旦公式のドキュメントを以下に。

そして今回は、タイトルにもある通り、

Github + CodePipeline + CodeBuild + Elastic Beanstalk

でかるく流れを追いつつ構成を考えてみます。

前置き

いきなり各サービスを作成していってもいいのですが、面倒なことになりかねないので一旦前知識として!

開発環境について

主にWebアプリだと仮定して、開発だとローカルに仮想環境を構築されている方多いと思います。 CentOSだとかDockerとかですかね? ここではDockerということにします。

ローカルでバグ修正なり、開発を終えると大体先輩やらのコードレビューが入ります。

何でコードを管理しているかによりますが、ここではGithubにします。 大体ブランチを切ってプルリク出してmasterにマージします。

まず、ここで把握しておきたいのは、CodePipelineをキックするのはどのブランチになるかということです。

ここでもう、どんなかんじはフローになるのかを見てみます。

いったん構成図をみてみる

f:id:o21o21:20180803113621p:plain

これさえ見たらもうわかるかと思います。 CodePipelineが管理する管轄は、この3つのサービスです。 (上の構成図では、Githubは点線の外ですが基本的には、CodePipelineを作成する際に、認証接続が必要になります。)

ここでもう一度言います! あくまで、シンプルな構成図です! ビルドしてからのテストや、承認アクション、Slackに通知したりなどなどいくらでもできるのですが、まずは基本ということで、シンプルでいきますw このシンプルな構成ができれば、あとのカスタマイズは楽になるかと思います。

Docker Imageを確認してから....

さて元に戻って...

開発でDockerを使用しているならば、必ずDockerfileなるものを管理していると思います。 そのDockerfileを元にdocker buildなどなどしているはずです。

ローカルでdocker imagesで今どんなイメージ使用しているか確認します。 何故確認するかというと、実はもう1つAWSのサービスを使うためです。

CodeBuildで必要になってきます。 現在のCodeBuildでは、ビルドをする環境イメージがUbuntuしか選択できないのです。 なので、せっかくDockerで開発しているならばそのままDockerイメージを選択してそのままテストできた方がいいですよね。

なので、Dockerfileの内容をきちんと確認しておきます。 そしたら新しく使用するサービスは、ECR (Elastic Container Registry)というサービスです。 簡単に、AWSのDockerレジストリサービスのことです。

Docker Imageを管理しておくことができます。

ということで、まずDocker ImageをECRで管理します。

ECRへプッシュ

特に難しいことはなく、コマンドを打てばECRにイメージが登録できます。

基本的にAWSコンソールの方で先にリポジトリを作成します。 作成が完了すると、コマンドの例が出てくるのでそれを順を追って叩いていけば問題ないです。

1つ、aws cliを使用できるように自分設定しなければなりません!

最終的に以下のようなコマンドを打ち終わると登録完了できたと思います。

$ docker push 506445657567.dkr.ecr.ap-northeast-1.amazonaws.com/docker-image-name:version

ちゃんとヴァージョンを指定してあげましょう! もし間違えても完全新規なら特に影響する範囲がないので、間違えたら削除すればいいや程度で叩いてみても大丈夫でしょう。

ECRを加えることで、以下のような構成図になります。

f:id:o21o21:20180803120908p:plain

ようやく、流れを確認 !w

まず、今回の記事の場合だと以下の手順で構成し始めるといいかもしれません。

  1. 開発環境を確認する (Dockerまわり、Githubブランチまわりなど)
  2. ECRにDocker Imageを管理させる
  3. CodeBuildでプロジェクトを作成する
  4. ElasticBeanstalkでアプリと環境(最低1つ)を作成する
  5. CodePipelineでそれぞれのサービスを紐づけしていく
  6. それぞれ動作するか確認〜

どんな環境でどんなサービスなのかによっても左右されますが、ちょっと詰まりやすいのは、 CodeBuildが正常にいくかなのかな〜と思います。

あと、ElasticBeanstalk(以下EB)で先に現状のプロジェクトをEBの各言語のルールに沿ってそのままzip化して、 そのまま手動で挙げてみて、とりあえず正常に動作するか確認してもいいかもしれません。

そしたら、簡単にはなりますがいくつかサービスの詳細を書いていこーかと思います。

CodeBuildについて

記事の前半にある前知識で、Githubの指定したブランチに対して、CodePipelineがキックされて成功なら、次にCodeBuildに流れていくことが大体わかったかと思います。

CodeBuildのプロジェクトを作成するにあたって重要な項目は以下。

  • ソース:ビルドの対象 > ソースプロバイダ
  • 環境: ビルド方法 > カスタムイメージタイプ(Docker)
  • buildspec 名
  • サービスロール
  • VPC (環境によりけり)
  • 詳細設定全般(特に環境変数かな?)

大体想像できるかと思いますが、buildspecが見慣れないかんじがします。 これは、ビルドを仕様をYAML形式で指定できるものになります。

AWS CodeBuild のビルド仕様に関するリファレンス - AWS CodeBuild

主に以下のようなかんじで記述していきます。 術全ての項目が必須というわけではないので、必要なところだけ記入してプロジェクトのプロジェクト直下に配置します。

version: 0.2

env:
    variables:
        key: "value" #環境変数指定
    parameter-strore:
        key: "value" # Systems Managerから取得し、値は暗号化できる

phases:
    install:  # パッケージインストール
        commands:
             - command
    pre_build: # ビルド前処理
        commands:
             - command
    build:  # ビルドテスト
        commands:
             - command
    post_build:  # アーカイブ化(zipなど), ECRへのプッシュ
        commands:
             - command
artifacts:
    files:  # S3へアップするファイルを指定
        - location

node.jsならnpm installとか、PHPならcomposer.phar installをここに書いておけば大丈夫です。

と、同時に、前にDockerfileを確認と言っていましたが、CodeBuildではECRに登録したDockerイメージを使用します。 ちゃんとbuildspec.ymlと合わせて、CodeBuildでもDockerイメージが使用できるように調整しましょう! テストコードもここでコマンドを叩いてテストできるので、1度はとりあえずビルドかけてみるがいいでしょう。

CodeBuildのログ

ログですが、ビルドするとAWSコンソールでビルド履歴が確認できます。 そこの各項目の詳細を開くと、出力:ログからCloudWatchに飛ぶので確認できます。 どこのコマンドでコケているんだ〜とかチェックできます。

Elastic Beanstalk

EBには、大きくアプリとその環境という枠組みを作成することになります。 例えば、1つアプリ作成して、環境を複数作成し、Blue/Greenデプロイ構成を作成することができます。

環境をステージングと本番に分けてもいいですね。

EBの場合はけっこう設定する項目があります。

  • 環境枠の選択 (Web環境 or Worker環境)
  • 基本設定 > プラットフォーム
  • 基本設定 > アプリケーションコード
  • さらにオプションを設定 > ソフトウェア / インスタンス / 容量 / ロードバランサー / ローリング更新とデプロイ / セキュリティ / モニタリング / 通知 / ネットワーク / データベース / タグ

ほんとは全て気にしないといけないのですが、特に気にしたのが、ネットワークロードバランサー(ALB)ですかね〜。

EBだとデフォルトで、Classic Load Balancer (CLB)になってしまいます。なので、ALBに変更します。 CLBではWAFを使用できませんが、ALBは使用できたりします。 ネットワークは、あれです、会社のルール的なやつです...w

上記を設定し、プラットフォームを使用したい言語に合わせてzip化してとりあえず手動であげれば動きます。 ※ 設定内容は環境作成後、変更は可能ですがインスタンスが新規で作成されたりするので、できれば最初の段階で設定値は運用するにあたっての設定にしといた方が後々楽かと思います。 インスタンスのセキュリティグループの追加でも環境の再構築が始まりました。

とまあ、とりあえずこんなもんかなというEBが作成できてしまえば、設定の保存ができるのでいくらでも環境の作成&削除が可能です。 あんまりこだわっても仕方ないのでね。。w 開発する段階で徐々に調整していくのがいいかもしれません。

.ebextensions

EBには、.ebextensionsというその環境のAWSリソースをカスタマイズできる機能(設定ファイル)を持つことができます。 プロジェクトに.ebextensionsというフォルダを作成し、その中にxxxx.configというファイルをYAMLJSON形式で書いて、置いておけばいいです。 .configという拡張子で認識するので、ファイル名は任意で複数置くこともできます。 また、JSONで記述可能ですが、公式ではYAML形式を推奨しているようです。

CodeBuildでも設定ファイルあるのに、EBでもか.... と思ってしました。

例としてこんなかんじかけます。(パッケージ入れたり環境変数設定したり立ち上げ時のサーバーにファイル生成したり...)

packages:
    yum:
         パッケージ名[]

commands:
    01-xxxxx-command:
        command: なんかコマンド
    02-xxxxx-command:
        command: なんかコマンド
        test: なんかコマンド

files:
    "/path/to/you/want/create/file.sh" :
        mode: ""
        owner: root
        group: root
        content: |
            ファイルの内容

EBのTips

1つ私が詰まって1日費やした箇所があります。 EBの仕組みとして、覚えておかないといけなかったっぽい。。

.ebextensionsをもちろん使用していたのですが、ログを確認するとどうもその記述が悪くあるコマンドでこけていた。。。 エラー内容もよくみるものだし、内容は把握していたのに何故かうまくいかない。。

結論としては、.ebextensionsで記述したコマンドが実行される場所に鍵がありました。

EBがの.ebextensionsが実行される場所は、/var/app/ondeckというディレクトリがワーキングディレクトリになっています。 コマンドが正常に全て完了すると、ondeckディレクトリはなくなって、currentディレクトリにプロジェクトがコピーされ、デプロイの完了になります。

おーーなるほどーーと思い、コマンドを修正したら見事EBのヘルスがOkになりました。。w

ここまで

大体山場を抑えたら、あとはCodePipelineで各サービスを紐づけしていくのみです。 特に難しい操作はありません。ポチポチしていけば、大丈夫です。

Githubの指定したブランチにpushされた時に、CodePipelineが発火します。 AWSのコンソールの進捗状況をみていると、今どこで処理されているのかが確認できます。

まとめ

今回はシンプルな自動化のフローを考えました。 この他、承認フローとして、Lambdaをかませて、Slackのあるチャンネルに通知 > Slack上で任意のユーザーの承認を得る > ステージングに変更を適用などできます。またビルド後のテストのフローもビルド先を増やせば複数できるのかな?

ほんとに色んな方法があるので、いろいろ試してみたいものです! ただ、他サービスを入れてしまうと運用コストが高くなってしまうので、できるだけシンプルに簡単にを意識したいと改めて思いました。

以上