僕はサーバをさくらのレンタルサーバのスタンダードプランしか借りていないので、サーバサイドでガシガシプログラムを動かすことができないのですが、Django を使って API を作りたかったので、その設定方法を紹介します。

紹介する範囲

今回は Django の WSGI を CGI を通して利用する方法のみを紹介します。

さくらのレンタルサーバで Python 自体を利用する方法や Django の細かな設定自体は紹介しません。

CGI の設定

さくらのレンタルサーバでは mod_wsgi が設定されていないため、Python を実行するには CGI を通さなければいけません。

そこで、 Django のプロジェクトルートに index.cgi を作成し、以下の内容を書き加えます。
この際、パーミッションを 755 に指定するのを忘れないようにします。

#!/path/to/python

import sys
sys.path.append('/path/to/djangoproject/')

import cgitb
cgitb.enable()

from wsgiref.handlers import CGIHandler
from projectname.wsgi import application

CGIHandler().run(application)

まず、1行目は使用している Python の環境をしてします。
pyenv と pyenv-virtualenv などを使用している場合は #!/home/username/.pyenv/versions/envname/python などですね。

4行目は今使用している Django のプロジェクトへのパスを指定します。
ここは pwd で表示される値をそのまま持ってくれば大丈夫です。

10行目の projectname は自分で設定しているプロジェクト名に変更します。

内部でやっていることは Django が設定している WSGI を CGI ハンドラーに載せて実行しているだけです。

アクセスしてみる

index.cgi を入り口としているので https://example.com/index.cgi がルートになります。
デフォルトの管理画面だと https://example.com/index.cgi/admin になります。

アクセスする際には settings.py の ALLOWED_HOSTS にホストを追加するのを忘れないようにしましょう。

またこのままだと index.cgi が常に入っていてダサいので .htaccess を用いて index.cgi 無しで見れるようにします。

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.cgi/$1 [QSA,L]

おわりに

以上、簡単でしたがスタンダードのさくらのレンタルサーバで Django を動かす方法でした。

macOS で開発しようとすると Xcode Command Line Tools は必須ですが、バージョンなどの問題で入れ直す必要がありました。
その方法をまとめます。

Xcode Command Line Tools のアンインストール

Xcode Command Line Tools は /Library/Developer/CommandLineTools/ に保存されています。
なので、このディレクトリを削除することでアンインストールが行えます。

$ sudo rm -r /Library/Developer/CommandLineTools

Xcode Command Line Tools の再インストール

コマンドラインツールだけ入れれば良いので、以下のコマンドでインストールができます。

$ xcode-select --install

おわりに

最新バージョンじゃない場合など、エラーを引き起こす原因になるので、できる限り最新のものを使用したいですね。

ラズパイの環境構築の一環で Docker 周りの環境を用意したので、記録しておきます。

Docker

Docker の公式に用意されているインストールスクリプトで簡単にインストールすることができます。

$ curl -sSL https://get.docker.com/ | sh

インストールが終わったら Docker のコマンドの権限をユーザに与えます。

$ sudo usermod -aG docker <username>

例えば、ユーザ名が pi ならば sudo usermod -aG docker pi となります。

Docker Compose

Docker Compose は Python の pip を使うと簡単にインストールできます。
Python がインストールされていない人はインストールしてください。
また、公式では環境を汚さないために、仮想環境を使用することが推奨されています。

まず、依存ライブラリをインストールします。

$ sudo apt install libffi-dev

次に Docker Compose 本体をインストールしていきます。

$ pip install docker-compose

おわりに

sudo apt install docker docker-compose で全て入る未来は来ないんですかね？

僕は FF14 をやっているんですが、今まで PS3 → PS4 → Windows と遊ぶ環境を変えてきました。今回はさらに、普段使用している Mac に移行したのでその感想です。

環境

使用環境は以下の通りです。

Mac 本体
    デバイス名: Mac mini 2018
    OS: macOS Catalina 10.15.4
    CPU: 3.2 GHz 6コア i7
    メモリ: 32 GB

eGPU: Razer Core X

GPU: Radeon RX 5700 XT 8 GB

ディスプレイ: 2560 x 1080 px（ GPU から HDMI 出力 ）

FF14 を eGPU でプレイ

※ 公式の動作環境に eGPU でのプレイに関する記載はありませんので、参考にする際には各自の責任でお願いします。

結論として、スペックが見合っていれば、問題なく起動・動作しました。

設定

eGPU を使用する設定に関しては、その他のアプリと同じく、FF14 のクライアントアプリを右クリックし、「情報を見る」から「外部GPUを優先」を選択すればできます。

評価

やはり Windows 版と比べ品質は大きく劣ります。

この記事 によれば Windows 環境で RX 5700 XT は 4K 解像度 / 最高品質 で「非常に快適」が得られるベンチマーク結果です。

これを見て、いけるだろうと思って Mac で 2560 x 1080 px の最高品質（ Maximum ）でプレイしたところ、数分でカーネルパニックを起こし、Mac がフリーズしました。

品質を下げれば動作は安定するので、現在は標準品質（ Standard ）でプレイをしています。

結果、安定してプレイしたいのであれば RX 5700 XT を使ってもフル HD 標準品質（ Standard ）が限界ということです。

おわりに

調べた限り eGPU で FF14 が遊べるかどうかの情報が少なかったので共有してみました。

試して欲しい設定などあればやってみますので、コメントなどお待ちしています。

ラズパイにを操作するのに、ディスプレイやキーボード、マウスを用意するのが面倒なので、macOS から画面共有できるようにします。

x11vnc のインストール

x11vnc は VNC プロトコルを利用した画面共有を実現するためのものです。

Raspbian では以下のコマンドでインストールすることができます。

$ sudo apt install x11vnc

x11vnc の設定

画面共有の認証に使うパスワードを以下のコマンドで設定します。

$ x11vnc -storepasswd

パスワード入力すると Write password to /home/<user_name>/.vnc/passwd? [y]/n と確認されます。こちらは次に説明する自動起動設定に使用するので y で解答します。

また、Raspberry Pi にディスプレイを接続している場合は、画面共有時、そのディスプレイと同じ画面、同じ解像度で表示されます。
ディスプレイを接続していない場合は、「Raspberry Pi の設定」のディスプレイの解像度が使用されるため、解像度を変更したい場合はこちらを変更します。（コマンドラインから変更する場合は sudo raspi-config > Display Options から設定します）

自動起動設定

起動時に毎回、手動で立ち上げるのでは、あまり意味がないので、自動起動の設定を行います。

まず、以下の内容の x11vnc.service というファイルを /etc/systemd/system/ に作成します。

[Unit]
Description=X11vnc
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -forever -auth guess -rfbauth /home/pi/.vnc/passwd

[Install]
WantedBy=multi-user.target

これは systemd という Raspbian で採用されているデーモンの設定ファイルで、それぞれのオプションについてはここでは説明しませんが、x11vnc に限らず、自由に自動起動の設定が行えるので、覚えておくと良いでしょう。

また x11vnc の実行オプションにこだわりのある方は上記の ExecStart の行にオプションを書き加えることで実行オプションを変更することができます。

上記の設定ファイルを保存したら、以下のコマンドで設定ファイルを読み込ませます。

$ sudo systemctl daemon-reload

次に、設定が正しく行えて起動できるかを確認するために以下のコマンドで起動します。

$ sudo systemctl start x11vnc

後述する接続方法で接続ができれば、以下のコマンドで、自動起動を有効にします。

$ sudo systemctl enable x11vnc

画面共有の接続

macOS から確認するには 画面共有.app を使用します。画面共有.app は Spotlight から検索すると出てきます。

アドレスには Raspberry Pi のホスト名か IP アドレスを指定します。

または、Finder からサーバへ接続（ Command + K ）をし、vnc://raspberrypi.local/ に接続することでも画面共有を開始できます。

この際 raspberrypi.local の部分は環境によって IP アドレスやホスト名に適宜変更してください。

おわりに

これでラズパイ用の周辺機器がなくても操作できるようになりました。

ラズパイをセットアップしたので、ファイル共有の設定をしていきたいと思います。

Samba のインストール

Samba は SMB プロトコルを利用したファイル共有を実現するためのものです。

Raspbian では以下のコマンドでインストールすることができます。

$ sudo apt install samba

ホームディレクトリを設定

インストールした Samba の設定ファイルは /etc/samba/smb.conf にあります。これを編集してホームディレクトリにアクセスできるようにします。

お好きなエディタか sudo nano /etc/samba/smb.conf のコマンドで以下のように編集してください。

# の行はコメントなので入力する必要はありません

# [homes] より下を編集
# browsable = no を yes に変更
browsable = yes
# read only = yes を no に変更
read only = no
# create mask = 0700 をコメントアウト / もしくは権限変更
# directory mask = 0700 をコメントアウト / もしくは権限変更

これで設定ファイルを保存すれば、ホームディレクトリにアクセスできます。

Samba ユーザの作成

Samba のユーザを作成するため以下のコマンドでユーザを作成します。

$ sudo smbpasswd -a <user_name>

<user_name> は自分の好きなものにします。例えば pi の場合は sudo smbpasswd -a pi となります。

Samba の再起動

変更した設定を読み込ませるために以下のコマンドで、Samba を再起動します。

$ sudo systemctl restart smbd

これで他のデバイスからホームディレクトリに自由にアクセスできるようになります。

他のデバイスからアクセス。

例えば macOS からは Finder で Command + K でサーバへ接続し、 smb:/raspberrypi.local/ に先ほど作成したユーザで接続すると、ディレクトリが選択できて Home を選ぶと、ホームディレクトリに移動できます。

この際 raspberrypi.local の部分は環境によって IP アドレスやホスト名に適宜変更してください。

おわりに

これでファイルの移動や共有が簡単になりました。

クローゼットに眠っていたラズパイを有効活用すべく、久しぶりにセットアップを行ったので、その記録です。

Raspbian のダウンロード

まずは OS 本体をダウンロードしてきます。

ダウンロードサイト

好きなバージョンを選んでダウンロードします。僕は GUI 環境が欲しかったので Raspbian Buster with desktop を選びました。

SD カードに書き込み

SD カードのアンマウント

書き込みに備えて、SD カードをアンマウント状態にします。

ターミナルから diskutil list コマンドを実行して、SD カードのデバイス番号を取得します。環境にもよりますが /dev/disk0 や /dev/disk1 などは macOS のために使用されるため、/dev/disk2 以降に割り当てられていると思います。

僕の環境では /dev/disk2 であったため、これ以降は /dev/disk2 の表記を使いますが、それぞれの番号に置き換えてコマンドを実行してください。

アンマウントは以下のコマンドで実行できます。

$ diskutil unmountDisk /dev/disk2

OS の書き込み

書き込みは dd コマンドを使用して、dd if=<path_to_os> of=<disk> の様に実行できます。

執筆時点で最新の Raspbian を使用して、カレントディレクトリに解凍してある場合は以下のコマンドで、書き込むことができます。

$ sudo dd if=2020-02-13-raspbian-buster.img of=/dev/rdisk2 bs=1m

ここで、気をつけたいのが、先ほど確認したデバイスは /dev/disk2 であったのに対し、今回の入力では /dev/rdisk2 を使用しています。

/dev/disk2 はバッファリングを使用しアクセスするのに対し、/dev/rdisk2 は直にデバイスへアクセスするため、書き込みを高速化することができます。

またオプションの bs=1m も高速化のために使用しています。

どちらも高速化のために行っているので、 sudo dd if=2020-02-13-raspbian-buster.img of=/dev/disk2 という通常コマンドでも、問題なく書き込むことができます。

時間は記録してませんが 5 – 10 分程度だった気がします。

Raspberry Pi で起動確認

書き込んだ SD カードを Raspberry Pi に戻し、起動させます。ちゃんと起動すれば成功です。

セットアップが始まるので、ガイドに沿って進めていきましょう。

おわりに

前は FreeBSD で使ってたので Raspbian のセットアップは購入時以来だったのですが、ガイドに沿って進めるとめちゃくちゃ簡単に使えるんですね。

もっと苦戦するものかと思ってました。

GitHub Pages などの静的ホスティングサービスでサーバを自由にいじれない環境でもパスワードをつける方法です。

デモ

デモサイト
ハッシュ値チェック
リポジトリ

パスワードは password

概要

GitHub Pages などの静的ホスティングでサーバの設定ができない場合、パスワードによる制限をつけることが難しいです。

それでも、パスワードによって閲覧を制限したい場合に、今回の方法が使えます。

簡単な説明をするとパスワードによって制限したいページをハッシュ化された文字列の名前を持つディレクトリに入れることで、URI を用いた認証をつけます。

これにより、パスワードを知っている人のみがページへアクセスすることができます。

仕組みの詳細

パスワードの入力

あらかじめ正解のパスワードが入力された場合のハッシュ値（ デモサイトでは SHA-256 を使用 ）をそのままアクセスされるディレクトリの名前にしておきます。

訪問者はパスワード入力ページでパスワードを入力します。

パスワードが入力されたら、JavaScript でハッシュ化（ ライブラリは jsSHA を使用してます ）し、XMLHttpRequest を利用してハッシュ値の名前を持つディレクトリの存在を確認します。

正常なレスポンスが返されればアクセスに成功とし、遷移します。

そうでない場合は、再入力を促します。

詳細なコードはリポジトリにある index.html を見れば全てわかります。

セキュリティ

（ 専門ではないので間違いがある可能性があります。 ）
上記の仕組みを見れば分かる通り、URI の存在を確認しているだけなので、それを知られるとパスワード無しで閲覧できてしまいます。

なので、ディレクトリリスティングの設定や noindex などを利用して、リンクを知られないようした上で SSL を利用しましょう。

しかし、簡単なパスワードを利用していない限りは URI を知られてもパスワード自体が知られることはないでしょう。

おわりに

簡易的ではありますが、静的ホスティングサービスでパスワード認証を利用する方法の紹介でした。

ちょっとした認証に利用できそうなので、使う機会があれば使っていきたいですね。

この記事の執筆時点（ 2020年3月 ）で M1 の学年なので、所謂21卒の就活をしていました。無事、内定をいただき、就職先も決まったので就活の体験談を書こうと思います。

そもそもなぜ就活をしていたか

学部の時から タイププロジェクト というフォントを作っている会社でエンジニアのインターンをしていて、来年4月からも是非と言われていました（ フォント会社のエンジニアって何するの？っていう方は是非 こちらの記事 や フォントタグ を参考に ）。

そのため、就活をしなくても、しれっと入社！みたいなルートもありました。

ただ、インターンとして約1年半働いて、ここを新卒で選ぶ会社とすることの良いとことそうでないことがわかってきたので、他の企業も見始めました。

インターン先の良いところ悪いところ

良いところ

好きを仕事にするので楽しめそう

このブログからもわかるようにフォント関係のことが好きなので、単純にそれが仕事になるので楽しめます。

人が良い

社員が10人程度と少ない人数で作業をするので、人間関係が悪いと辛そうですが、そういうことは一切ないので、働きやすいです。

良くないところ

エンジニアが少ない

エンジニアが僕含め2人です。強いエンジニアが多くいた方が成長しやすいし、お互いに良い影響があると考えているので、少ないのは残念です。

アウトプットが減る

趣味でフォント関係のことをやろうとすると、内容によっては NDA や会社でコードを書くので、個人的なアウトプットが減ってしまいます。ただこれに関して言えば、例えば OSS や製品開発、ブログや登壇などを会社でやるといった解決方法もあったかもしれません。

ドメイン知識の偏りが強い

フォントのエンジニアというマニアックな職業は需要がとても多いわけではありません。今後のキャリアを考えると、フォントというドメイン知識の偏りが強く、転職などが困難になりそうな気がしました。

就職先の探し方

上記の良くないところを改善できるような企業を探していました。

ただ、探していたと言ってもすごく積極的に就活をしていたわけではなく、スカウト型（ 逆求人 ）のサイトに登録していたぐらいです。
登録していたのは3つで感想と共に紹介したいと思います。

Wantedly（ プレミアムアカウント ）

一番よかったです。僕のユーザページは こんな感じ です。内定先の企業も最初は Wantedly 経由で連絡をもらいました。

スカウトの届く企業も平均的にレベルが高く、プロフィールも書きやすかった気がします。

OfferBox

良くなかったです。特にプロフィールがすごく書きにくかったです。URL の記入がめんどくさかったり、ポートフォリオを書くところがないので、エンジニアには向いてない気がします。

それとくるオファーも適当なのが多く、全然興味を持てませんでした。

ViViViT

デザイナ向けですが使ってみたかったので使ってみただけで、あまり本格的には使ってないので、なんとも言えません。

上記のサイトで来たスカウトで気になるところがあれば、話を聞きに行ったという感じです。
話を聞きに行く条件としては以下の点をメインに見ていました。

• Web 系
• 給与が月35万以上（ 年収400万強~ ）
• 働き方がある程度自由（ 時間とか服装とか環境とか ）
• アウトプットが多い（ エンジニアが強い ）

事業内容に強いこだわりはなく、まあ興味がある方が良いけどぐらいの感覚でした。

期間としては、2019年11月 – 2020年2月で、就活をしていました。合同説明会や大学主催のイベントなどには一切行っていませんし、リクナビ / マイナビも登録していません。
実際に選考を受けたのは2社で説明を聞きに行ったのは6社ぐらいです。

ちなみに、就活期間中一度もスーツは着てないし、髪も赤だったり青だったり明るい茶色だったりしました。

選考で考えていたこと

基本的に、提出した情報は ポートフォリオ / GitHub / このブログ です。
特別に企業ごとに「ここはこういう企業だから ES / 面接ではここを強調しよう！」みたいなのは一切していなくて、どこの企業の選考でも同じこと（この記事に書いているようなこと）を言っていました。

それで落ちるなら、そもそも僕はその企業に向いていないんだろうし、入ってもどこか無理して働くことになるだろうからです。

なので所謂 ES 対策、面接対策、就活セミナーのようなことは何もしてなく、就活も楽に終えられた気がします。

結局、どこ入るの？

2021年4月から freee株式会社 でエンジニアとして働きます。

決めた理由としては上記で挙げた「話を聞きに行く条件」に全て当てはまるということと、freee が掲げている 「マジ価値」 という考え方にすごく共感し気に入っているからです。

マジ価値指針にあることはどれもある意味当たり前で実現されてたら良いに決まってるっていうことなんですが、それを言語化して会社全体として掲げており、かつそれを実現 / 体現できているように感じました。
それが一番の決めてだった気がします。

それと、オフィスにファミレスみたいなドリンクバー（ サントリーのドリンクディスペンサー ）があるのが良いですね！

まあ、まだ入社したわけでも働いているわけでもないので、実際に入社した頃にまた何か書こうと思います。

おわりに

就活に対する思いをつらつらと書いてきましたが、誰かしらの参考になれば幸いです。

僕なりの macOS で Python 環境を作るためのお話です。

pyenv と pyenv-virtualenv

ここでは Python の仮想環境を pyenv と pyenv-virtualenv で作成する方法を紹介します。

pyenv

Homebrew を用いたインストール

macOS を使用している場合は Homebrew を用いてインストールすることができます。Homebrew をインストールしていない場合はリンク先のインストールコマンドを実行しましょう。

pyenv のインストールコマンドは以下の通りです。

$ brew install pyenv

Git を用いたインストール

pyenv の GitHub リポジトリをクローンしてくることでもインストールすることができます。

コマンドは以下の通りです。

$ git clone https://github.com/pyenv/pyenv.git ~/.pyenv

パスの追加と初期化

インストールした pyenv を使用できるように、パスを通し、シェル実行時に初期化をしてやる必要があります。

今回は最新の macOS 標準の Z Shell( zsh ) の方法を紹介します。
Bash を使用している方は適宜 .zshrc を .bash_profile などに読み替えてください。

実行するコマンドは以下の通りです。

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
$ echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.zshrc

Python バージョンの追加

仮想環境のためのバージョンを追加するにはバージョンを指定し、以下のコマンドで追加できます。

$ pyenv install x.x.x

この際、インストール可能なバージョン一覧は pyenv install -l で確認することができます。

また、アプリケーションをビルドする場合などはフレームワークとしてインストールする必要があります。コマンドは以下のとおりです。

$ env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install x.x.x

pyenv-virtualenv

Homebrew を用いたインストール

pyenv と同じく Homebrew でインストールできます。インストールコマンドは以下の通りです。

$ brew install pyenv-virtualenv

Git を用いたインストール

こちらも pyenv と同じく Git でもインストールできます。コマンドは以下の通りです。

$ git clone https://github.com/pyenv/pyenv-virtualenv.git $(pyenv root)/plugins/pyenv-virtualenv

初期化

pyenv 同様に、初期化のコマンドを追加します。

$ echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.zshrc

仮想環境の追加

仮想環境を追加するには以下のコマンドを実行します。

$ pyenv virtualenv x.x.x <name>

例えば、Python 3.8.2 で test-3.8 という名前の環境を作りたい場合は以下のようになります。

$ pyenv virtualenv 3.8.2 test-3.8

仮想環境の指定

グローバル

特別に、環境が指定されていない、グローバルな環境で使うバージョンを指定するには pyenv global を使用します。例えば先ほど作成した test-3.8 を使用する場合は以下のようになります。

$ pyenv global test-3.8

ローカル

カレントディレクトリで、特定の仮想環境を指定する場合には pyenv local を使用します。例えば先ほど作成した test-3.8 を使用する場合は以下のようになります。

$ pyenv local test-3.8

このコマンドを実行すると、ディレクトリに .python-version というファイルが追加され、そこに、指定した仮想環境が書き込まれます。

また、pyenv activate <name> を使用することで、仮想環境を一時的に起動することもできます。

仮想環境の確認

現在作成されている仮想環境の一覧を取得するには pyenv versions が使用できます。また、一覧ではなく、現在の環境で適用されているものを知りたい場合には pyenv version で確認できます。

おわりに

ここで紹介した他に必要そうなコマンドが出てきたら、追記していきます。