Raspberry Pi をローカルサーバとして利用できるようにする

(あくまで “ローカルネットワーク上” で運用する)サーバが必要になったので、使っていなかったラズパイを引っ張り出してきてサーバにしました。

その際の手順メモを残しておこうと思います。

0. 環境

ラズパイ周り

作業環境

1. SD カードのフォーマット

前提: 利用できる SD カードについて(ラズパイ公式)

まず SD カードをフォーマット。
公式でも推奨されている SD Formatter を利用しました。

※ 今回は 32GB の SD カードだったので関係ないですが、64GB 以上の SD カードだとラズパイが非対応の exFAT フォーマットになってしまうので注意が必要なようです。
その場合の対応方法(ラズパイ公式)

2. SD カードに OS イメージを書き込む

今回はサーバとしての利用なので、OS はヘッドレスな Raspbian Stretch Lite を使用。

基本的にラズパイ公式のここに手順が丁寧に書いてあるので、これに従って作業。

イメージの書き込みには、上記ページで推奨されている Etcher というソフトを利用しました。

3. 初回起動時から SSH 接続できるようにする

イメージを書き込んだ SD カードに改めて作業 PC からファイルアクセスして、ルートディレクトリに ssh というファイル名の空ファイルを作成。

(Raspbian 初回起動時にそのファイルの有無をフラグとして見ているだけのようなので、ファイル名だけは正確に、最もやり易い方法で空ファイルを作成すればOKだと思われます)

4. Raspberry Pi を電源と LAN に有線接続する

ラズパイに先ほど作成した SD カードを挿入。

さらに、ローカルネットワークに繋ぐための LAN ケーブルと、電源ケーブル(micro USB)を接続。
電源が接続されたことでラズパイが自動起動します。

この後ラズパイに物理的に触ることはないので、良きところに設置しておきます。

5. Raspberry Pi の IP アドレスを確認する

(ラズパイと同じサブネットに所属している)作業 PC から、ラズパイに SSH 接続するために、ラズパイに割り振られた IP アドレスを確認。

以下、管理者権限で実行したコマンドプロンプトでの作業

I. ARP テーブルのクリア

1
arp -d *

II. LAN 内で使われている IP アドレスを ARP テーブルに記録する

1
for /l %i in (0,1,255) do ping -w 1 -n 1 192.168.1.%i && arp -a 192.168.1.%i

xxx.xxx.xxx.%ixxx の部分は、所属しているネットワーク(サブネット)に合わせて書き換える。

III. ARP テーブルの確認

1
arp -a

MAC アドレスが B8:27~ から始まるものがラズパイ

6. SSH クライアントから SSH 接続する

前項で調べた Raspberry Pi の IP アドレスに、SSH クライアントを用いて SSH 接続する。

Raspberry Pi のデフォルトでは、

  • ユーザ: pi
  • パスワード: raspberry

7. IP アドレスの固定

/etc/dhcpcd.conf で下記項目を環境に合わせて設定。

1
2
3
4
interface eth0
static ip_address=xxx.xxx.xxx.xxx
static routers=xxx.xxx.xxx.xxx
static domain_name_servers=xxx.xxx.xxx.xxx

8. raspi-config

https://www.raspberrypi.org/documentation/configuration/raspi-config.md

1
sudo raspi-config

で、設定画面が開く。

とりあえず以下の設定をしました。

  • システム領域を SD カードの容量に合わせ拡張

    Advanced Options > EXPAND FILESYSTEM (再起動が必要)
    初回起動時に自動的に実行されるらしいんですが、念のため手動で実行。

  • 対応言語に日本語を追加

    Localisation Options > CHANGE LOCALE > ja_JP.UTF-8 にチェックを入れて設定を進める
    この手の設定画面あるあるですが、チェックボックスにチェックを入れるのは Enter キーではなく Space キー。

  • タイムゾーンの変更

    Localisation Options > CHANGE TIME ZONE > Asia > Tokyo を選択

9. サーバとして最低限の初期設定もろもろ

ここからはラズパイどうこうというより、Linux サーバの話だと思うので端折り

  • パッケージの最新化
  • 作業用ユーザの作成、 sudo 権限付与、 SSH 接続用の公開鍵の設定など
  • ssh 許可周りの設定(デフォルトユーザや root での接続の無効化など)

などなど

以上

TypeScript + React-Redux なプロジェクトを作ろうとしてる話

https://github.com/wusagi24/agqr-player/tree/d33c50f3f63990506b0d9e36fd62fe6622833e67

React-Redux 構成の SPA を TypeScript で書いてみたいと思って、とりあえず必要そうなものいろいろ組み合わせた雛形(?)を作成してみました。

半年後にはもう参考にならないものになってそうだけども…

ゴテゴテ

ただ使ってみたいってだけだったり、雛形の段階では不要だけど後から入れることになると面倒くさいタイプだったりのパッケージを始めから組み込んであるので、雛形の時点でゴテゴテ感が否めません…少なくとも最小構成ではない。

でもここから、dev 時と prod 時でのビルド処理の振り分けスクリプト書いたり設定ファイル増やしたり、十中八九使うけどまだ入れてないライブラリ足したりで、さらにゴテゴテしていくはずです。

今に始まったことではないですが、「うーん、なんかなー」って感じ。

まぁ、しばらくは web のフロントエンドに寄り添いたいと思っているので、そんなもんかなーと思うことにしています。

あと完全に好みの話ですが、フルスタックなフレームワークよりは、薄いフレームワークやライブラリを積み重ねていくほうがまだ好きなので。

TypeScript + React-Redux

TypeScript で React-Redux 構成を作るのは初めてだったんですが、最小構成での話であれば

[ES next] -> babel -> [JS] の流れが、

[TypeScript] -> typescript -> [JS] になるだけなので、

ややこしさは大差ないかなという印象です。

ただ、(特に Redux 周りの)大小様々なパッケージを追加しつつ実際に作って行く中で、なんやかんや TS ならではの面倒くさいことは出てきそうな気はしています。

いまのきーもち

VS Code だと何かと気が利いていて便利そうなのと、知識欲の観点から TS 採用してみましたが、少なくとも “ひとりプロジェクト” だったら ES next な記法を Babel 通して使ったほうが何かと手っ取り早かったり、将来性があったり、不要な地雷が増えなかったりで、いいんじゃないかなと今のところ思ってます。

一応型がある安心感が分からないわけではないんですが、そもそも JS で独自型ごりごり作っていく設計が個人的にあんまり…
出来る限り、プリミティブ型と、浅い構造のオブジェクトと、ピュアな関数でどうにかしたほうが、JS は活き活きする気がしてる(謎スピリチュアル言葉選び

ブログテーマをいろいろ改変

このブログのテーマは元々 light というものを利用しているんですが、個人的に気になる部分に少し手を入れてみました。

サイドバー(右カラム)

  • 最近の投稿表示を有効化(テーマに元からある機能)
  • プロフィール欄を追加

OGP 周り

  • もろもろ調整

今後も気になったら、適時調整を入れていくつもり。

あと、jekyll を使ってたころに書いた記事を2点ほどサルベージしてきて追加してみました。
古い記事ですし、現在でも情報が有用かの検証は特にしてないので、意味があるかは微妙ですが、まぁ賑やかしということで。

Docker による Ruby on Rails の開発環境

[ Github: rails-dev-docker ]

初めて Ruby on Rails を触る機会があったので、Docker で開発実行環境を立ててみました。

基本的に自分で使うために、急ごしらえででっち上げたので汎用性はないです。

DockerHub の Rails Image には非推奨的なことが書いてあったので、Ruby の Image をベースに自前で Dockerfile 書いてます。

docker-compose を使ってるのは、MySQL や PostgreSQL を DB に利用する場合、別コンテナとして外出ししやすいようにです。(結局 SQLite3 使いましたが…
なにかと便利なので、最近何かしらの開発実行環境を Docker で立てるときには docker-compose 使うようにしてます。

Rails に関しては改めて何か書くかもしれませんが、想像以上に “魔法” が強くて、正直今はよく分かんねーでございます。

Github Pages を Hexo に置き換えてみた

アカウントの Github Pages ( https://wusagi24.github.io/ )を復活。併せてジェネレータを Hexo に置き換えました。

Hexo にした理由としては、最近開発環境を極力 node (npm) で完結させているので、 node 製のジェネレータの中で一番メジャーっぽい Hexo を選んだって感じです。

また何か技術的なことで纏めておきたいことが出てきたら、ここに書いていこうと思います。

CreateReactApp によるReactチュートリアルの写経

今回のゴール

Reactのチュートリアルを、CreateReactApp による開発環境で写経する。

ソース

こちらの記事の内容を実際に書いたソースは こちら になります。

基本的に、チュートリアルに登場するソースごとに、 commit を入れてあります。

はじめに

Reactのチュートリアルを、最近公開された 「Create React App」 というReactプロジェクトのスターターコマンドを利用した開発環境(+ ES2015の書き方)で写経しました。

この場合、写経というより書き換えなんでしょうか。

ということで、基本的に写経なので、 チュートリアルのサイト前項のコミットログ を突き合わせて読めば比較的後からでも追いやすいかなと思うのですが、一部補足的にちょっと書き留めておきます。

プロジェクトの作成

CreateReactApp インストールして、プロジェクトのひな形を作って、サンプル用のファイルを削除する。

create-react-app コマンドのインストール

1
$ npm install -g create-react-app

create-react-app コマンドでプロジェクトを作成

コミット 「create project

1
2
$ create-react-app react_tutorial
$ cd react_tutorial

サンプルのファイルを削除

コミット 「remove default source file

1
$ rm src/*

index.html

コミット 「modify index.html

1
2
3
4
5
6
7
8
9
10
11
<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>React Tutorial by create-react-app</title>
</head>
<body>
<div id="content"></div>
</body>
</html>

index.html を、チュートリアルで出てくるものを元にした上記内容に書き換え。

チュートリアルでは jsパッケージの取得を CDN から、依存関係の解消を html上のタグの記述順 で行っていますが、CreateReactAppでは webpack が入っているので、今回はパッケージの取得を npm で、依存関係の解消を webpack で行うことにします。

というわけで、jsの読み込み部分はチュートリアル記載のものからばっさりカット!

あと、チュートリアルではjsをhtml内に記述していますが、さすがに面倒くさいので別ファイル ( src/index.js ) に切り出しています。

この環境では、index.html 内に scriptタグ を記述しなくても、ビルド時に自動的に src/index.js を読み込むタグが挿入されます。

jsファイルについて

コミット 「tutorial1.js

webpack による依存性解決と ES2015 の class 記法を使用するので、js ファイルをコンポーネントごとに切り分けて作成、import/export にて組み合わせています。

エントリーポイントとなる src/index.js で ReactDOM でのレンダリングを行い、そこでルートコンポーネント(今回は CommentBox )を import しています。

ライブラリの使用

コミット 「add library ‘remarkable’

1
$ npm install -S remarkable

コミット 「tutorial6.js

npm でライブラリをダウンロードしてきて、使用する jsファイル 内で import で読み込んでいます。

APIサーバ

ソースの README にも記載しましたが、チュートリアルで用意されているAPIサーバプログラムを、そのまま同一ドメインのAPIとして利用するのはこの環境だとちょっと面倒くさいので、別ドメインのAPIとして動かしてアクセスすることにしました。

1
2
3
4
$ git clone https://github.com/reactjs/react-tutorial.git react-tutorial-server
$ cd react-tutorial-server
$ npm install
$ PORT=3001 node server.js

コミット 「modify comments api url

幸いこのチュートリアル用APIサーバプログラムは CORS 対応されているので、丸っとサンプルソース持ってきて、別ポートでサーバを起動。APIへのアクセスアドレスをそちらに向けてあげるだけで大丈夫です。

アロー関数の利用

コミット 「tutorial13.js

チュートリアルだと、 $.ajax 内のコールバック関数を bind() していますが、

1
2
3
function (arg) {
// code
}

でなく、

1
2
3
(arg) => {
// code
}

と、ES2015 のアロー関数を使うと、自動的に this がバインドされるのでそっちで書いてます。

あとついでに、コールバックの設定を Deferred の done fail で外に出す書き方に変えてます。

class内メソッドの非同期呼び出し

コミット 「tutorial16.js

class 記法を利用する際、onClickイベントなんかでクラス内メソッドを設定する場合、そのまま

1
onChange={this.handleAuthorChange}

とかやると、対象メソッド内で js名物の this 迷子になるので、

1
onChange={this.handleAuthorChange.bind(this)}

と、 this を bind() しています。

おわりに

CreateReactApp は、ほんと素早く React 開発始められるし、開発・ビルドまわりで必要なものは最低限そろってるし、React 入門にはもってこいだと思います。

参考URL

Windwos の PackageManagement を使ってみる

今回のゴール

PowerShell の PackageManagement を使って、パッケージ管理できるようにする。

はじめに

Windows 10 からは、PowerShell のモジュールとして PackageManagement という パッケージ管理システム がデフォルトで入っているらしい。

ちょうどクリーンインストールしたところだし、それを使って環境構築してみることにする。

ちなみに、win10 より前のバージョンでも、 Windows Management Framework 5.0 とやらを入れれば利用できるようです。

(この記事内では、PowerShell のコマンドを記載するとき可読性のため大文字小文字書きわけてますが、PowerShell 自体は大文字小文字区別しないので、実際に打つ際は全部小文字でも問題ありません。)

手順

  • PowerShellの設定

  • PackageProviderの追加・確認

  • パッケージ(アプリケーション) の検索・追加・確認・削除

PowerShellの設定

PowerShellのスクリプト実行に関するポリシーを変更する。

PowerShell を 管理者として実行する で起動。

現在の設定を確認

1
> Get-ExecutionPolicy

初期値は Restricted (全てのスクリプト実行禁止) になっている。

設定を変更

1
> Set-ExecutionPolicy RemoteSigned

ポリシーを RemoteSigned (署名付きのスクリプトとローカルに保存されているスクリプトの実行を許可)へ変更する。

ポリシーの意味やその他の設定値に関しては、下記参考サイトなど詳しく書いてある。

参考: WindowsでPowerShellスクリプトの実行セキュリティポリシーを変更する - @IT

PackageProviderの追加・確認

PackageManagement では、パッケージの配布元を PackageProvider という形で管理して、そこ経由でパッケージを取得してくる。

で、この PackageProvider として、Windowsのパッケージ管理システムとして定番の Chocolatey が利用できる。

なので、とりあえず Chocolatey を PackageProvider として追加する。

利用できる(未登録の) PackageProvider 一覧

1
> Find-PackageProvider

PackageProvider 登録

1
> Get-PackageProvider Chocolatey

登録済み PackageProvider 一覧

1
> Get-PackageProvider

パッケージ(アプリケーション) の検索・追加・確認・削除

なんとなく nodist で試してみる。

パッケージの検索

1
> Find-Package -name nodist

パッケージのインストール

1
> Install-Package -name nodist

アプリケーション付属のインストーラーを裏で実行しているだけっぽい?

インストール済みパッケージ一覧

1
> Get-Package

パッケージのアンインストール

1
> Uninstall-Package -name nodist

こちらもどうやらアプリケーション付属のアンインストーラーが起動しているだけっぽい?ので、アプリケーションごとに挙動が違ったりする。

ちなみにものによってこれだけではアプリケーション本体は消えないものがあるんで、そういったものはこれに加え通常のアンインストール手順で消してあげる必要がある。

おわりに

これである程度のアプリケーションを Package Management で管理できるようになりました。

通常のGUIインストーラーからインストールするときに選べるインストールオプションが、この方法でインストールするとすべてデフォルト設定になるっぽくて、例えば Git for Windows とかは個人的にインストール時の設定をある程度変えたいので、そういうアプリケーションにはちょっと使いづらい感じ。逆にインストールオプションがあんまり無いようなor重要じゃないアプリケーションはこっちのほうが断然楽だと思います。

まだちょっと触った感じですが、便利は便利だと思うので、なんか「いい感じ」の付き合い方を見つけたいです(windowsのbashはまだしばらく微妙そうだし・・・)。

参考URL

余談

PowerShellデフォルトの、エラー出力が赤字黒背景なのがなんかもうとにかく苦手で、とりあえずそこの設定の変更だけ調べたのでついでにメモ。

下記ファイルが .bashrc 的な存在になるっぽいので作成。

1
%UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

そこに下記の内容を記述。

1
2
$host.privatedata.errorbackgroundcolor = "DarkMagenta"
$host.privatedata.errorforegroundcolor = "Yellow"

これで心の平穏は保たれた・・・