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でのプロジェクト環境構築&作成考えています。

以上.

【キャリア設計】FIRE とは!?経済独立と早期退職

こんにちは。

今まで技術的な記事しか投稿していませんでしたが、 今回はキャリア設計について思ったことを書いていこうと思います。

といっても、私自身経歴が豊富で優秀ということではありませんので、どういったことを主軸にするかといいますと、

とある頭文字からとったFIREという今アメリカのGEEKな若手の間で話題になっている動きについて考察してみます。

FIREとは??

FIREとは、「Financial Independence, Retire Early」の頭文字をとったものです。

この意味は、「経済独立、早期退職」という意味です。

先日目にとまって関心があったので、記事に残そうと思いました。

至ってシンプルですね。 そして話題となるのであれば、ただ「ニートになろう!」ということではなさそうですw

Pete Adeney

Pete Adeneyという現在ブロガーとして生活している方が、このブログで自分の経験を記事にしたのが火種のようです。

www.mrmoneymustache.com

このブログのモットーは、「倹約は解放であり、剥奪ではない」 彼は元ソフトウェアエンジニアで奥さんもエンジニアだったそうです。そして、職場は30歳で退職したそうな。 では、いったいどういった内容がFIREなのか、どうしてこの動きが話題になっているのかを見ていきましょう。

4%ルール

この動きの中で一番重要なのが、4%ルールというもの。

簡単に言うと、毎年の引き出し額を総資産の4%に抑えるというルールです。

例えば、資産が3,500万円だとすると、140万円を毎年引き出して使うということです。 この計算でいくと、25年間もつことになりますね。

もちろん、この総資産を毎年引き出すだけではありません。 なんらかの手段で資産を維持していかなければならないということです。

なんか期待し過ぎて、結局「働くのかい!」と思う方もいるのではないでしょうか笑

ただ、この4%ルールを実行することで、総資産を増やしたりすることができる、 増やすことができるという言い方より、私は、効率的にストレスなく稼ぐことに注力できるのではないかとかんじました。

では、先人たちは如何にして生活を維持させているのでしょうか?

現実的に考えて

ここからは私の個人的な意見も盛り合わせていきます。

4%ルールは素晴らしいと思いますが、これを日本で現実的に実行できるか考えてみます。

第一人者である、Pete Adeneyさんはインデックスファウンドを運用しているとのこと。

インデックスファンド - Wikipedia

わたしは特に投資に詳しくないので、どれくらいの時間をかけたりお金をかけたりするのかよくわからないですが、 投資と聞くと自分の容量で運用できるイメージなので、理にかなっていますね。

また、他のFIREの先人の中には、元ウォールストリートで勤務していた方や、インテルでエンジニアをしていた方などの情報がありました。

んー単純に経歴が素晴らし過ぎて実感が湧かない...

ただ、趣味をそのまま稼ぎにしている方も多いそうです。

そこに焦点をあてます。

エンジニアだとしたら、友人と組んで何かプラットフォームを作成したり、Webアプリやスマホのゲームなどを作成して収入を得るということも考えられますね。 サーバーの運用費はそのまま4%ルールを適用すれば、コスト面も考慮しながら開発できます。

また、アクセサリーをつくって販売とかでもいいですね。ハンドメイドの作品を販売できるサービスもすでに存在します。

これらのことって、今の時代だからこそできることなのではないでしょうか!

このFIREの動きは、この時代だからこそ必然的に起こったのでは?とも考えられます。

もう少し具体的に数字を元にして考えてみましょう。

より具体的に

(※ ちょっとググっただけなので、本当に正確な数字でないことはご承知下さい。)

東京都の平均年収を調べました。

厚生労働省発表の「賃金構造基本統計調査」によると、約615万でした。 これは、平均年齢42歳、平均勤続年数12.2年ということです。

大体30歳までにリタイアということを考えると、年収600万を超える人は稀でしょう。

若手、大体20歳〜29歳でいうと、250〜400万くらいでしょうか。

上記の例で出した3500万円の資産をつくろうとしたとして、この平均年収を元にFIREを実現しようとすると、どういう計算になるでしょう。

かなり数字を大雑把で計算しますw

例: 年収350万 (内ボーナス60万、基本給額面24万) (=月々手取り19万) 一人暮らしの費用: 家賃6万、光熱費1万、食費2万、定期代1万、ケータイ/ネット代1万 (=計11万)

この年収が毎年ということではないでしょうが、これを元にすると、 月々の余りは、約8万円といったところでしょうか。個人差で、交際費やもっとここ抑えられるといったところもあるでしょうが、ここではこの数字だとします。

この8万円を毎月貯蓄し、ボーナスを全額貯蓄したとすると、約155万円を毎年貯蓄できる計算です。 これで3,500万を貯めようとすると、約22年ほどかかりますww

これでは既に定年退職のほうが近いということになってしまいますね笑

Pete Adeneyさんは、奥さんと750万円を稼ぎ、無駄遣いを一切やめて家を購入してリタイアしたそうです。 確かに、二人でと考えると現実的な数字になってきそうです。

単純に350万×2=700万円で、単純に費用が2倍かかるとして毎年310万円貯蓄できるとすると、約11年で3,500万円に到達します。

確かにちょっとは現実的な数字になってきましたね。

これを調べているときに面白い統計を見つけました。 日本における子供を出産〜大学にあげるまでの養育費をまとめたサイトです。

一人の子どもの出産から大学卒業までの総費用 : 関連資料 : 子ども応援便り

これによると大体3,000万円/1人くらいでしょうか。 総資産3,500万円だとしても子供1人育てる養育費で消えてしまうので、やはり総資産の維持は重要なようです。

さて、計算はかなり大雑把でしたが、具体的に考えてみたところでかなり実現するには難易度が高いようにも思います。

ですが、ここでようやくこの記事の大事なところです笑

自由だからこそ

Pete Adeneyさんは優秀でお金を稼げるからFIREを実行したというわけではないということです。 毎日同じ職場、同じ時間に出勤し、同じ顔を見て仕事をするというライフスタイルを、自分のしたいようにするにはどうしたらいいかを考えた結果なのではないでしょうか。

アメリカではエンジニアの地位が高いです。日本では真逆なかんじですね笑 でも、国内ばかりみていては、一向に先が見えないままです。エンジニア(デベロッパー)やプログラマーというのは、皆さんが毎日使用してるといっていいシステムなどを開発し、日々イノベーションを起こす職業でもあります。YouTuberのように、好きなことで生きていくというわけではないですが、また違った側面から新しい働き方を提案&実行できる人たちでもあるような気がします。

また、どんどん国内におけるルーティング作業はコンピュータやロボットに代替されていき、より市場で自分の価値を証明していくことが困難になっていくのではないかとも思います。

FIREという動きも日本国内では、また違ったかたちで実現できるかもしれませんね。

以上.

【Python】Djangoのsettings.pyって2回読み込まれてる!!???

今回は、Djangoのプロジェクトでちょっとハマったことがメインです。 ※ 日本語の記事なくて、結果ですが断定して言えないのでご承知下さい!

経緯

Djangoのプロジェクトでローカル環境開発をしていました。 前回少し記事にしたやつですね。

o21o21.hatenablog.jp

こちらけっこうイジっていて、DBの設定を見直していたところ、 環境毎の切り替えが必要やん!って思って調べていました。

できるだけプロジェクト構成はシンプルにしたいので、settings.py内で収めようとしました。

環境変数を使用して、環境ごとにDBの設定を変更しようと、以下のようなかんじになりました。

SET_DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'xxx',
        'USER': 'xxxx',
        'PASSWORD': 'pwd',
        'HOST': 'db',
        'PORT': 3306,
    },
    'staging': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'xxx',
        'USER': 'xxxx',
        'PASSWORD': 'pwd',
        'HOST': 'db',
        'PORT': 3306,
    }
}

env = os.environ.get('DJANGO_ENV', 'default')
print('Running on "{}".'.format(env))

if env in SET_DATABASES:
    DATABASES = SET_DATABASES[env]
else:
    print('ERROR: Unknown environment for database settings.')

ちょっとif文があるけど、まあこれくらいならいいかと思い、そのままdocker-compose upで立ち上げ。

するとそんなすんなりいきませんでした。

エラー

...略...

if self._databases[DEFAULT_DB_ALIAS] == {}:
KeyError: 'default'

...略...
 django.db.utils.ConnectionDoesNotExist: The connection default doesn't exist

ん、なんかdefaultがないって言われている... でもdefaultも記述してあるなあ〜と思ってログを見てみました。

そしたらなんかsettings.pyが2回読み込まれてる疑惑が浮上。

ログのなかでprintしている内容が2回実行されていたのです。

なんだろうと思いながら調べてみると、以下の質問を発見。

stackoverflow.com

結果的に...

結果的にこの質問からすると、Djangoの起動時には、プロセスが2回別々で起動され、settings.pyが読み込まれてるらしい。 (ちょっと細かいことは調べてないです。。。)

なるほど〜、ここが大きく関係していそうだな〜

ということでした。

あんまりsettings.pyにはゴチャゴチャコード書かない方が良さそうでした。。

なので、settings.pyをちょっとファイル名を変更してもう1ファイル作成し、 起動時のsettings.py自体の読込を環境ごとに変更する方法を検討しようかと思います。

以上.

【Docker】Django + REST framework + mysql with docker-compose

今回は、DjangoのREST frameworkのローカル環境に挑戦してみました。

初めてPythonフレームワークを触るので、浅はかなところもあるかと思いますがご了承下さい!

ゴールは、ブランチでこれが表示されるところまでいきます。

f:id:o21o21:20181119195642p:plain

docker-composeを使用するので、インストールしてない方はインストールしましょう。 この記事ではインストールの説明は割愛します。(「docker for mac インストール」で検索すれば出てくると思います。)

さて、さっそく取り掛かっていきます。

※ 私の環境は、macOS

作業場作成

適当に今回のプロジェクトを作成するディレクトリに移動します。

$ cd /path/to/project
or
$ mkdir project_name

任意ですが、一応README.mdを作成。

初期データ、ディレクトリ作成

今回、DB(mysql)と接続するために、初期データを置いておく必要があります。

$ mkdir mysql
$ cd mysql
$ mkdir init

上記を作成して、mysql/init/というディレクトリを作成します。 このディレクトリ配下に、.sqlをファイルを置いて置きます。

※ この.sqlファイルですが、既存の運用で使用されているDBのdumpファイルでも可能です。 ちょっと試したいというかたは、テーブルを作成するsql文などを適当に記述してもOKです。

ここまでのプロジェクト構成は以下です。

<project_name>
├── README.md
├── mysql
│   └── init
│      └── test.sql

主要なファイルを作成

次にDockerfiledocker-compose.ymlをプロジェクトディレクトリで作成します。

$ touch Dockerfile
$ touch docker-compose.yml

重要なのは、この2つのファイルの記述です。

  • Dockerfile
FROM python:3.5

ENV PYTHONUNBUFFERED 1

RUN mkdir /code

WORKDIR /code

# install Libraries
COPY requirements.txt /code/
RUN pip install -r requirements.txt

# to be consistent versions of between "Django and PyMySQL"
RUN pip install -U PyMySQL

ADD . /code/
  • docker-compose.yml
version: '3.0'
services:
  db:
    image: "mysql:latest"
    container_name: <container_name>
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_DATABASE: <db_name>
      MYSQL_ROOT_PASSWORD: <db_root_pwd>
      MYSQL_USER: <db_user>
      MYSQL_PASSWORD: <db_pwd>
    ports:
      - 3306:3306
    volumes:
      - type: bind
        # source: ./docker/db/init.sql
        source: ./mysql/init/<file_name>.sql
        target: /docker-entrypoint-initdb.d/<file_name>.sql
      - type: bind
        source: /tmp/docker/tmpdata
        target: /tmp/tmpdata
  web:
    container_name: <container_name>
    build: .
    command: python manage.py runserver 0.0.0.0:8080
    volumes:
      - .:/code
    ports:
      - 8080:8080
    environment:
      DJANGO_SECRET_KEY: $DJANGO_SECRET_KEY
      DJANGO_DEBUBG: $DJANGO_DEBUBG
    depends_on:
      - db

ほとんど公式と同じ記述です。 ただ、公式では、PostgreSqlの場合ですし、先程作成したDBの記述はありません。 シンプルに詳細を確認したい人は、一読するといいと思います!

クイックスタート・ガイド:Docker Compose と Django — Docker-docs-ja 17.06.Beta ドキュメント

Dockerfile

こちらはシンプルですね。python ^3.5をベースにpipでrequirements.txtを元にライブラリをインストールさせています。 ここで一番注目したいのは、PyMySQLアップグレードです。

私が環境構築をしている時に、何時間もつまったのがこれ。 なんてことないエラーでしたが、どうもうまくいかなかった...

知っていればなんてことないことなのですが、どうやらDjangoのversionが2.0以上になって発生するエラーのようでした。 色々ググってみると、色んなやり方で解決されているみたいでしたが、アップグレード1発で解決されるのが一番シンプルですよね!

docker-compose.yml

こちらもいたって普通の記述です。 初期データを必要とすることで、volumesの設定(特にtarget)が重要です。

docker-entrypoint-initdb.dに注目します。 これは、mysqlのイメージがコンテナの起動時に自動的に初期データを読み込んでくれる機能を使用しています。

下のbindは、初期データがなかった場合に代用できる記述です。

ここまで作成して、足りないファイルが2つあります。

requirements.txt

このプロジェクトで必要なPythonのライブラリを記述します。

Django==2.1.1
djangorestframework
django-filter
psycopg2
psycopg2-binary

.env

docker-compose.ymlで使用されている変数があると思います。($DJANGO_SECRET_KEY) これは、Djangoのプロジェクト作成時に発行されるキーなのですが、環境変数に設定しようかと思って普通に記述すると、以下のエラーが発生。 (何故環境変数に、DjangoのSECRET_KEYを設定しようと思ったかというと、毎回毎回Docker環境を作成しては削除していると、Githubでのヴァージョン管理の際に、settings.pyは管理したいけど、SECRET_KEYは別で管理したいということになりました。)

ERROR: Invalid interpolation format for "environment" option in service "web": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

どうやらエスケープしなければならない記号が入っていて、environmentに直接値を記述できませんでした。(やり方はあるが面倒くさい..w) なので、.envというファイルを作成し、これをヴァージョン管理。

え、ヴァージョン管理するの?って思うかもしれませんが、これには理由があります。 1つ目としては、他の人に同じ.envを提供できる。(= 同様な環境構築を目指す。)また、開発環境においては他の値で代用できたりしますね。 2つ目は、STGや本番では、OSの環境変数を見に行くので大丈夫ということ。ただし、これはあくまで、本番サーバーでDockerを稼働させないことになります。 まあ、とりあえずローカル環境はDockerで!みたいな人向けになってしまいますが...(でも会社とかで作業していると、新機能作成で本番はDockerじゃないけど、機能追加のためにDocker流行ってるし今回のローカル環境はDockerにしよう!って人も多いのでは?w)

それはさておき、.envには以下を記述

DJANGO_SECRET_KEY=-<今は適当な値をとりあえずいれておく>
DJANGO_DEBUBG=True

ProjectとAppを作成

コマンドを実行してプロジェクトとアプリを作成します。

プロジェクトルートにて、以下を実行。

# プロジェクトを作成
$ docker-compose run web django-admin.py startproject settings .
# アプリケーションを作成
$ docker-compose run web python manage.py startapp src

これを実行すると、プロジェクト構成は以下のようになるかと思います。

<project_name>
├── Dockerfile
├── README.md
├── db.sqlite3
├── docker-compose.yml
├── manage.py
├── mysql
│   └── init
│       └── <file_name>.sql
├── requirements.txt
├── settings
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-35.pyc
│   │   ├── settings.cpython-35.pyc
│   │   ├── urls.cpython-35.pyc
│   │   └── wsgi.cpython-35.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── src
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── migrations
    │   └── __init__.py
    ├── models.py
    ├── tests.py
    └── views.py

一気にファイルやらディレクトリが作成されたかと思います。 今回、プロジェクトとアプリの作成コマンドの名前をsettingsとsrcにしました。 これは任意です。ディレクトリ名としてわかりやすいものでいいと思います。

mysqlとの接続

/settings/settings.pyを編集します。

  • DBの設定
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql,
        'NAME': <db_name>,
        'USER': '<user_name>,
        'HOST': 'db',
        'PORT': 3306,
    }
}
  • PyMySqlの読込 同ファイル、任意の箇所に以下を記述
import pymysql

pymysql.install_as_MySQLdb()

また、このファイルにSECRET_KEYが記述されているかと思います。 この値を.envのDJANGO_SECRET_KEYに追記し、 settings.pyのSECRET_KEYの部分に、os.environ.get('DJANGO_SECRET_KEY')を代わりに書いて、OSの環境変数を参照するようにします。

合わせて、DEBUGもos.environ.get('DJANGO_DEBUBG')として書き換えます。

その他、プロジェクトに合わせて、LANGUAGE_CODEとTIME_ZONEも合わせます。 (体外が、jaAsia/Tokyoでしょうか。)

INSTALLED_APPSにもこちらを追記します。'rest_framework'

DBとのシンクのために、マイグレーションファイルを作成します。

models.pyに対象のテーブル(class)を記載して実行すると、src/migrations/ディレクトリが作成され、 0001_initial.pyのようなファイルが作成されます。 はじめにmodels.pyが空の状態でmigrateをしても大丈夫ですが、src/migrations/配下にはini.pyしか作成されません。

# ホストからマイグレーションファイルををDBに適用
$ docker-compose exec web python manage.py makemigrations

# Dockerコンテナの中に入ってマイグレーションファイルをDBに適用
$ python manage.py makemigrations

# ホストからmodels.pyに書いたclassを読み込んでマイグレーションファイルを作成
$ docker-compose exec web python manage.py makemigrations <app_name>

# models.pyに書いたclassを読み込んでマイグレーションファイルを作成
$ python manage.py makemigrations <app_name>

ググってみるとほとんど記事が新規でお試しテーブルみたいなかんじでmodels.pyに記述していますが、 既存のdumpファイルから作成されたDBから以下のコマンドで、models.pyに自動でclassを作成してくれます。

$ python manage.py inspectdb tabbel_name >> models.py

実行

最後に実行です。

$ docker-compose up

.
.
.
<container_name> | You have 15 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
<container_name> | Run 'python manage.py migrate' to apply them.
<container_name> | November 19, 2018 - 19:51:55
<container_name> | Django version 2.1.1, using settings 'settings.settings'
<container_name> | Starting development server at http://0.0.0.0:8080/
<container_name> | Quit the server with CONTROL-C.

このような出力されればOKでしょう。

http://localhost:8080/

ブラウザでlocalhostにアクセスし、Welcomeページが表示されていれば、あとはもう開発を開始できます!

まとめ

だいぶ駆け足で書きました。 うまくいかない場合は、もちろん公式を参照してみて下さい。

確認としては、Dockerのコンテナにはいることで解消できる場合もあります。($ docker exec -i -t コンテナ名 bash) また、Dockerのコンテナは何度削除しても大丈夫です!($ docker rm <CONTAINER ID or NAMES>)

1からのやり直しも簡単にできるのはDockerのいいところでもあるのかなと思います。 今回私は、初期データとして、5GBのdumpファイルを用いましたが(ちょっと最初のイメージコンテナ作成時時間はかかりますが、)問題なく動作しています。

後先考えると環境構築はほんとに大変... ですが、とりあえず構築させていくことが大事ですね!

以上.

【Go】簡単!使い捨て、GoのDocker開発環境を構築

以前は、macOSでのGoのプロジェクトについて考えました。

o21o21.hatenablog.jp

今回はGo (golang)のDocker開発環境を考えてみます。 拡張性を意識して、docker-composeを利用してみます。

想定として、なる早で環境構築し、GoのWebアプリを開発していこう!みたいなノリです。 ちなみに、Goのフレームワークとして、echoをインストールしていきます。 ゴールは、ブランチでのHello Worldを目指します。

私の環境は、macOSです。 事前にDocker (macならDocker for macをインストールしましょう!)

さて、順をおってみていきましょう!

プロジェクトの作成

今回、Dockerなので特にGOPATHを意識する必要はありません。 (Docker上でのGOPATHは指定します。) 気になる方は、この記事の冒頭であげた過去の記事を参考にしてみて下さい。

なので、任意のディレクトリに新規プロジェクトを作成しましょう。

必要なファイルを作成

コマンド docker-compose upで起動させるために、必要な設定ファイルを新規作成します。 この記事では必要最低限の記述にします。portの指定などご自身のやりたいことに合わせて設定してみて下さい。 ※ 自分の使用しているdocker及びdocker-composeのversionにも注目!

Dockerfile

FROM golang:latest                                                                                                                                                                                    
  
WORKDIR /go/src/go-app2
COPY . .
    
# "Go" Environment variable
ENV GO111MODULE=on
    
# install Go web framework
RUN go get -u github.com/labstack/echo
   
# install "Fresh" restart tool
RUN go get github.com/pilu/fresh

CMD ["fresh"]

上からみていきます。

goのヴァージョンは最新のものを取得しにいってます。(ヴァージョン指定も勿論可能)

GO111MODULEというGOの環境変数をonに設定します。 これでモジュールを自動的に読み込むことができます。

これをDockerfileに記述しないと、docker-compose upした時に以下のWARNINGが出ました。

go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
    ignoring go.mod;
    see 'go help modules'

GO111MODULEを記述した際に、プロジェクトディレクトリに自動的にgo.modというファイルが作成されます。 (= 今回のプロジェクトに依存したgo.modファイルが生成される。)

そして、フレームワークのechoとホットリロードをするためのFreshをgo getでインストールします。 go getを使用するということは、今回作成されるDocker上には、複数のプロジェクトを共存させる目的ではないことを覚えておいて下さい。 仮に、go getをすると、GOPATH配下にインストールされて2つ目以降のパッケージの依存関係を管理しにくくなるからです。 (goから離れていたので、間違ってたらごめんなさい...!!!!)

GO111MODULE

さきほど定義した環境変数GO111MODULEについてです。 こちらヴァージョン1.11から追加された、モジュール管理モード環境変数です。(正式リリースは、1.12かららしい)

on : モジュール対応モード off : GOPATH モード(今まで通り) auto : GOPATH以外のみモジュールモード

今までdepなどを使用していたと思いますが、これは便利! depからの乗り換えも楽みたいですね!

ちなみに、今回のDocker環境で開発中に新しいモジュールを追加すると、freshが検知し自動的にモジュールがインストールされます。 そうすると、go.modに require package/name v1.1x.2x のように追記されていることが確認できました。 また、go.sumファイルも生成されます。これは、モジュールの依存関係を示すファイルのようです。

そして最後にコマンド実行です。

ホットリロードについてですが、どういうことかというと コンパイル不要な言語ならいいのですが、一旦コンパイルしてから動作させる言語において、 よくDockerで起動させられたけど、ファイルの編集をした際にもう一度docker runとかしないといけない...ということが起こります。

かなり面倒なので、タスクランナー的なものが必要です。 厳密に今回使用するFreshはタスクランナーとは書いてないようですが、 要はファイルを監視し変更が検知されると、自動的にrestartしてくれるものです。

なので、Dockerfileでは、最後にfreshというコマンドで起動させます。

Freshについては、以下の公式を参照してみて下さい。 Fresh自体の設定ファイルも作成できるようです。

github.com

docker-compose.yml

続いてdocker-compose.ymlですが、そんなに記述がないので説明を割愛します。

   version: '3'                                                                                                                                                                                        
   services:
     app:
       build: .
       container_name: <projecrt_name>
       volumes:
         - ./:/go/src/<project_name>
       ports:
         - "8080:8080"
      environment:
          GO111MODULE: "on"

ここまで作成できれば、ほぼ完成です。 Dockerfileを基に、1つのコンテナと1つのイメージが作成されるはずです。(golangのイメージ含めるなら2つかな?)

あとは適当にmain.goを作成します。

goファイル

  • main.go
package main

import (
    "log"
    "net/http"
    "path/filepath"
    "sync"
    "text/template"
)

type templateHandler struct {
    once     sync.Once
    filename string
    templ    *template.Template
}

func (t *templateHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    t.once.Do(func() {
        t.templ = template.Must(template.ParseFiles(filepath.Join("templates", t.filename)))
    })
    t.templ.Execute(w, nil)
}

func main() {
    http.Handle("/", &templateHandler{filename: "top.html"})

    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal("ListenAndServe", err)
    }
}
  • templates/top.html
<p>Hellooooooooooooooooo World!!!!!!!!!!!!!!</p>

実行

いざ実行です!

$ docker-compose up
Building app
Step 1/7 : FROM golang:latest
 ---> d817ad5b9beb
Step 2/7 : WORKDIR /go/src/go-app2
Removing intermediate container 816a33af9a01
 ---> bb3d6012e557
Step 3/7 : COPY . .
 ---> e38c75d754d3
Step 4/7 : ENV GO111MODULE=on
 ---> Running in 57345b25fb4f
Removing intermediate container 57345b25fb4f
 ---> d9500cf1f5cd
Step 5/7 : RUN go get -u github.com/labstack/echo
 ---> Running in 01dc8d6ebd6c
go: finding github.com/labstack/echo v3.2.2+incompatible
go: downloading github.com/labstack/echo v3.2.2+incompatible
go: finding github.com/labstack/gommon/log latest
go: finding github.com/labstack/gommon/color latest

... 略 

Creating goapp2_app_1 ... done
Attaching to goapp2_app_1
app_1  | 11:2:58 runner      | InitFolders
app_1  | 11:2:58 runner      | mkdir ./tmp
app_1  | 11:2:58 runner      | mkdir ./tmp: file exists
app_1  | 11:2:58 watcher     | Watching .
app_1  | 11:2:58 watcher     | Watching templates
app_1  | 11:2:58 main        | Waiting (loop 1)...
app_1  | 11:2:58 main        | receiving first event /
app_1  | 11:2:58 main        | sleeping for 600 milliseconds
app_1  | 11:2:59 main        | flushing events
app_1  | 11:2:59 main        | Started! (8 Goroutines)
app_1  | 11:2:59 main        | remove tmp/runner-build-errors.log: no such file or directory
app_1  | 11:2:59 build       | Building...
app_1  | 11:3:00 runner      | Running...

あとは、ブラウザでアクセス。

http://localhost:8080/

htmlの内容が表示されていたら成功です。

また、docker-composeを起動したまま編集してみましょう! リロードし、変更が反映されていたら大丈夫です。

Dockerコンテナの中へ

以下のコマンドでDockerコンテナの中に入って、ローカルとのファイルのシンクがされているか確認できます。

$ docker exec -i -t <container_name> bash

今回の例だと、ディレクト/go/src/<project_name>が存在し、 $GOPATHは、/goになっていることが確認できます。

まとめ

いつもホットリロードに悩まされていましたが、Freshは楽ですね! 他にもGoのプロジェクトで使用されているタスクランナーがあります。

github.com

github.com

※少しdockerで個人的に気になることがあるので、解決したら更新します!

以上.

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

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

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

インフラ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のヴァージョンアップでより良くなるのを待つほうが楽ですね。

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