Raspberry Pi の Raspbian (debian系) で apt-get すると、Nginx は結構古いやつが入る。 やっぱり新しいのが使いたいと思って試したことをまとめる。 今回は結構 experimental なネタなので、at your own risk でお願いします。 初心者向けではないです。 あと、タイトルは Raspberry Pi だけど、一般の Debian / Ubuntu でも使えるネタだと思います。 (未検証ですが) 作業時間は、3B で 2時間くらいか。 片手間で十分だけど、時間を確保してください。 3B以外の機種では。。。結構な忍耐が必要そうです。。。クロスビルドを検討しましょう。 HTTP/2 も使いたいので、TLSのための openssl の新しいバージョンを使う。 システムワイドの openssl をアップデートするのはリスクがあるので、 nginxに内包して、ここだけで使用するように、ビルドする。 今回は、debian の deb のソースリポジトリから取得したソースをビルドするけど、一旦古いやつをaptで入れて `nginx -V` で表示されたオプションを、configure に指定するという方法でも割といける。 準備 なんにもビルドしたことがない環境の人は。。。

1
2
3
4

sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install git

など。。。 後々、必要に応じて、ビルドに必要なライブラリをインストールする必要があるかもしれない。 ビルド中に `error: libなんとか` や `warning: libなんとか` と出たら、 `sudo apt-get install libなんとか` とか `sudo apt-get install libなんとか-dev` とやってみる(いい加減..)。 ソースの取得

1
2
3
4
5
6
7

pwd
/home/pi

mkdir nginx-latest
cd nginx-latest
git clone https://anonscm.debian.org/cgit/pkg-nginx/nginx.git

ちなみに、このリポジトリのパスは `apt-get source nginx` したら、 こっちから取りな。と出てきたパス。 `apt-get source nginx` だと、 1.10 あたりが落ちてくる。 ビルドにオリジナルのソースが必要で、かつ、別名で参照されているので

1
2
3

wget https://nginx.org/download/nginx-1.13.3.tar.gz
ln -s nginx-1.13.3.tar.gz nginx_1.13.3.orig.tar.gz

(ハイフンがアンダースコアになっているので注意) openssl のソースを取得、展開

1
2
3

wget https://www.openssl.org/source/openssl-1.1.0f.tar.gz
tar xzvf openssl-1.1.0f.tar.gz

ビルドオプションの調整

1
2
3

cd nginx
vi debian/rules

configure の オプションを指定する箇所 `common_configure_flags := \ `(の後の72行目くらい) があるので、そこに

1
2
3
4

--with-thread \
--with-openssl=/home/pi/nginx-latest/openssl-1.1.0f \
--with-openssl-opt=-fPIC

を追加。 もともとある `–with-thread` の後にバックスラッシュ付加。 お好みで makeに -j3 オプションを追加。 ビルドコマンド

1
2

dpkg-buildpackage -us -uc

エラーが出たら、パスを確認したり、最初のライブラリインストールを試す。 `dpkg-buildpackage`を使うと、また最初の clean, configure からになってしまうので、 参照URLにある、ビルドコマンドを活用すると多少時間短縮できる。 無理そうだったら、スパッと諦めて、また、体力のある時にリトライするのもいい。 ビルドが終わったら、

1
2
3
4

cd debian/nginx-full/usr/sbin
./nginx -v
./nginx -V

でビルドできたか確認する。

1
2
3
4

nginx version: nginx/1.13.3
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled

(ドットスラッシュ無しの現行nginxとの比較もしてみよう) 設定ファイルなどのバックアップを取って、

1
2
3
4
5
6
7

cd ~/nginx-latest

sudo dpkg -i libnginx*.deb
sudo dpkg -i nginx-common_1.13.3-1_all.deb
sudo dpkg -i nginx-doc_1.13.3-1_all.deb
sudo dpkg -i nginx-full_1.13.3-1_all.deb

これで完了。 HTTP/2 を試したいときは、SSL(TLS) が必須なので、HTTPS の設定をしよう。 多分、HTTPS の設定をすれば、勝手になる。 Chromeの機能拡張 HTTP/2 and SPDY indicator というのを使うと、HTTP/2 使用時に青い稲妻が出て面白い。 参考URL https://www.debian.org/doc/manuals/maint-guide/build.ja.html

表題の通り、Surface Book (i5モデル) の GPU で Deep Learning を試してみた話。 (2017/08/02 さらに追記) (2017/07/25 末尾に追記。有効なケースについて) 最近、ふと deep learning について勉強したくなって、ちょっとしたサンプルプログラムを動かしたりしている。 まだ理論をきちんと理解していないので、サンプルを書き換えるのも、ままならない状態だが、何かの役に立てば面白いかなと思っている。 演算には結構時間がかかるが、GPU を使えば高速化できるらしい。 そういえば、Surface にも GPU 入っているのを思い出したので、試してみることにした。 Surface Book の i5/8GB/256GB のモデルには、dGPU という NVIDIA製の無銘GPUが搭載されている。 一応、CUDA も動くみたい。

• Windows 10
• Cuda 8.0
• CuDNN 5.1
• Tensorflow GPU 1.2.1

どれも普通にインストールしただけ。CuDNNはシステム環境設定のPATHをbinに通しておく。 TensorFlow も公式の手順で pip install しただけ。 インストールして、以下サイトのサンプルを動かしてみると。。。 RNNで来月の航空会社の乗客数を予測する：TFLearnでLSTMからGRUまで実装しよう なんと、GPU より CPU のほうが早かった。。。 (ひどいオチだ。。。) なんかね、3000 x 2000 pixel の表示を高速化するために搭載されてはいるが、そういうことには使わないでくださいって感じ。。。 一応認識されたし、動きはしたけど、演算は無理でした。残念。。。 ちなみに、deep learning の参考書はこれ。いい本だと思う。 Surface でこれなので、お得意の Raspberry Pi では。。。インストールする気も起きないです(笑) (2017/07/25 追記) サンプルプログラムによっては、速くなるものもあることが分かった。 スピードは倍くらいになる。 GPUのメモリが1GBしかないので、メモリに関する部分でパフォーマンスに差が出るようだ。 とりあえず、GPU版を入れておいて、Windows の場合、システム環境変数で切り替えるのがよさそう。 CUDA_VISIBLE_DEVICES=-1 で無効、CUDA_VISIBLE_DEVICES=0 で有効。 (2017/08/02 追記) GPUのメモリが少ないので、バッチサイズは小さめにする必要があるが、うまく調整すれば、3～4倍程度のパフォーマンスが出ることを確認。 調整には、nvidia-smi や NvGpuUtilization ツールを使うとやりやすい。

前前回のツイッター編と手順はほぼ一緒。 まずは、はてなブックマークのアプリのページに行って、リンクを作ります。 http://b.hatena.ne.jp/guide/bbutton 保存するURL の項目には、なにか分かりやすいダミー文字列を入れておく。 コードをコピーして。 Wordpress の [外観] - [テーマの編集] の content.php ファイルから

1
2

</div><!-- .entry-content -->

という、タグを見つけて、その直前にリンクの文字列を入れる。 先ほどの URLを共有のダミー文字列を含む href の部分を

1
2

href="http://b.hatena.ne.jp/entry/<?php str_replace('http://', '', str_replace('https://','s/',the_permalink())); ?>"

に置き換えて保存。 今度は、content-single.php ファイルで、再び、先ほどと同じ div の閉じタグを検索し、その直前にリンクの文字列を入れる。 今度は、href の部分を

1
2

href="http://b.hatena.ne.jp/entry/"

にして、保存する。 手順は以上です。

。。。こんなタイトルで書いたけど、実質、ちょっとしたビルドタスクを動かすくらいの話。 仕事として、プログラムを組んでいるわけではないし、ビルド、テスト、デプロイにツールを使うほどの状況ではないのだが、環境構築遊びとして、ビルドツール / CI ツールを検討。 試したたのは、Jenkins と Strider と Rundeck  。。。と Git の hook。 動かしてみると、Jenkins も Strider も Rundeck も Raspberry Pi には重すぎた。。。(結論早いw) 一応、Raspberry Pi 3B だったら、多少の我慢で動くけど、アクションを起こしたときにしか動かないツールに、普段から400～600MBものメモリを使う気にもならず、結局、あきらめた。 Strider が、若干軽いが、ほんの少しの違い。 で、結局、Git の hook を使うことにした。 同期処理になってしまうけど、gogs の常駐以外にメモリも使わないし、元々 gogs が動いていたのだから、追加コストなしで動作というのは大きい。 hookの注意点としては、

• gogs / Git のユーザで動くので、それでできるように仕掛けておく必要がある。 事前に `sudo su - git` して、一連の操作を手動で実行できるか試すといい。
• スクリプト中で、Git を使う場合、例えばワーキングディレクトリ内にいったん、clone もしくは pull したりするときは git に --git-dir=.git のように Git ディレクトリの明示指定が必要。
• 普段ログインするユーザではないので、PATH とか ~/.ssh/id_rsa とかがいつもと違うので注意。

ということくらいか。 スクリプト中でエラーになると、クライアント側の push の際に画面にエラーが出るので、よく見ること。 もし、非同期でやりたかったら、gogs で Webhook を飛ばして、github-webhook-handler を使って、node.js で書いたコードで受けるのが Raspberry Pi らしいかな。ビルドに失敗したら、パトランプ点灯とか(笑) cron で数分おきに監視する手もあるけど。 しょぼいが。。。 マルチユーザーで重なった時に、キューイングする事とかは、全く考えてません。悪しからず。 ワーキングディレクトリをタイムスタンプ名で作って clone してビルドで結構いけそうだけど、そこまでしたくないねえ。

しばらくソフトウェアの仕事から離れていて、ここ数ヶ月の間に、再履修みたいな感じで、オープンソース界隈を眺めていた。 自分の興味の対象とかもあって、偏りはあるけれども、おおむね感じたこととしては。。。 最重要なソフトウェアの、重要なポジションに日本人はいる。頑張ってる。 でも、荒削りでも、新しく、元気なソフトウェアプロジェクトのコミッターには、中国の人のパワーを感じる。 ということ。 国内で人気サイトを運営しているところのエンジニアさんの blog なんかを見ると、頑張っている人も沢山いるのも分かるけど。 もっと、日本人も積極的に出て行かないと、終わるよ。。。 というか、終わりの始まりを見ているのかも。 自分が現役でソフトの業界にいたときは、日本ローカルの SI 活動は、責任のなすりつけあいのために、信頼性はあるけど、たいした機能も無い、化石みたいなソフトウェアをありがたがって使っている傾向があったけど、今でもそうなんでしょうかねえ。

スイッチサイエンスさんのページによれば、ようやく技適とれたようです。 1296円は魅力だけど、処理速度は、かなり遅いので、ファースト ラズパイは3Bがお勧めです。 3Bでプロトタイピングして、組み込みの何かの見通しが立ったら、実装系として買う感じかなあ。 なんというか、処理速度の閾値みたいなのが自分の中にあって、3Bはありだけど、Zeroは厳しいなという印象です。 ハードウェア制御のエンジンにするなら、充分リッチな環境だと思いますが。

Windows でよく使うアプリ Git for Windows ソースコード管理以外にも、Bash 環境がバンドルされていて、ほぼ、これだけで疑似 UNIX/Linux 環境が整う。 サーバー系は Docker かエミュレーター もしくは実機(私の場合は Raspberry Pi 3B)でまかなえばいい感じ。 基本的に ssh もここで繋げてしまうので、ssh クライアント使わなくなった。ssh の設定は C:\Users\ユーザ名\.ssh\config に書いておけば OK。 ConEmu コンソール環境の強化。 コマンドプロンプト、PowerShell、Git Bash、Docker どれもこのコンソールエミュレーターに集約している。 bash と cmd と ssh(Git bash)をタブで同時使用とか、かなり便利。 日本語を使う場合、安定版(stable)よりも、preview とか alpha の方が良かったりすることも多いので、動作に不満があったら試してみるといい。公式サイトのおすすめは preview らしい。 Docker Windows に限らないけど、仮想環境は便利。 どーでもいいけど、イラストがかわいい。 イラストのかわいさだと yarn もいいけど。 Atom これも Windows に限らないけど便利。最近、ようやく Git 機能が入った。 日本語化すると起動が遅いので、英語メニューで使っている。 Cyberduck ftp, sftp, webdav クライアントとして良く出来ているし、DropBox や Google drive なども同期クライアント無しで集約できるので楽。 Chrome 入っていて当然。 デベロッパーツールは本当に奥が深い。 node.js node そのものもいいけど、これをベースに作られたツール関係も便利。 http-server とか、ちょっとしたコンバーターとか便利だわ。 awesome node.js h_network21氏による日本語訳 とかで探すと面白い。 この辺は、python とか ruby とか Go でもいいと思うけど。 このあたりと、フォントくらいを入れれば、一通り揃った感は出てくるようになった。 Mac だと、コンソールとか bash とかフォントについては、揃ってるけど、Windows も、かなり環境構築の作業量は減った感がある。

前回のツイッター編に続いて、Facebook 編。 前回、今回ともに Twenty Eleven という少し古めのテーマを使っていますが、公式デフォルトテーマは、新しいものでも同じような構造になっているので、同じ手法で行けることも多そうです。 今回は、header.php, content.php, content-single.php の3つのファイルに手を入れます。 まずは、header.php の HEAD のタグの中に以下のコードを追加

1
2
3
4
5
6

<meta property="og:url" content="<?php the_permalink(); ?>">
<meta property="og:type" content="website">
<meta property="og:title" content="<?php the_title(); ?>">
<meta property="og:description" content="<?php bloginfo('description'); ?>">
<meta property="og:image" content="投稿用画像のURL">

Facebook のボタンはクリックした後に、Facebook 側からクローラーがこちらのサイトのURL(後で指定する個別投稿ページのパーマリンク)を読みに来て、各種の情報を取得するようになっているようなのだが、このクローラーが正しい情報を読めるとは限らないので、個別投稿ページのヘッダーに、情報を埋め込んでおく。 無しでも動くし、シェアプラグインの類でもこのタグは使ってないものも多いが、安定動作のためには入れて置いた方がいい。イメージのURLも適当に明示指定するのがお勧めです。 ある程度のサイズ(260 px 角以上とかそのくらい)が必要なようです。 このヘッダーは、各ページに使用されるものなので、個別投稿ページ以外では正常に動作しない可能性があるが、悪さはしないので、これでいいかなと考えている。 また、Facebook のクローラーには、キャッシュが入っていて、一度失敗すると、しつこく失敗し続けることもあるようなので、もし、Facebook ボタンを追加するのであれば、面倒がらずに最初からちゃんとやった方が良いようです。 間違った情報がキャッシュされると Facebook 側のデバッグツールを使わないとなかなか消えなくて鬱陶しいです。 Facebook の SDK を読み込んでおきたい場合は、BODY の開きタグの直後に書いておけばいいです。 ちなみに Google Analytics のコードもここに置きます。 保存したら、次に、Facebook のボタンコード生成ページでコードを作ります。 https://developers.facebook.com/docs/plugins/share-button# IFRAME 版の方のコードの方が、ずれたりしにくいように見えるので、こっちを使います。 通常版の方は SDK の読み込みコードが必要です。 IFRAME 版は無くても大丈夫そうです。 生成したコードを、前回同様に content.php および content-single.php の以下のタグ

1
2

</div><!-- .entry-content -->

の直前にコードを貼り付けます。 次に、URL が入っている部分を、以下のコードに書き換えます

1
2

<?php urlencode(the_permalink()); ?>

ちょうど、href= から & layout の間になると思います。 これで保存して、完了です。 今回の記事では、以下のページを参考にしました。 WordPressでFacebookのいいね！ボタンを不具合無く設置する際のポイント

WordPress のテーマをシンプルな Twenty Eleven にしてみた。 以前使っていた simplicity2 と比べると、大幅に機能ダウンだが、何となくシンプルなテーマにして、カスタマイズするのもいいかなと。 一番の問題は SNS のボタンがなくなってしまったので、とりあえず twitter のボタンだけ自分で追加してみることにした。 ページのソースを Chrome の [検証] 機能を使って探してみると、 content.php と content-single.php をいじれば良さそう。 twitter の公式ページに行って、リンクを作る。 https://about.twitter.com/ja/resources/buttons#tweet URLを共有 と ツイート本文 の部分には、何か適当にダミー文字列を入れておき、リンク文字列を作る。 content.php ファイルから

1
2

</div><!-- .entry-content -->

という、タグを見つけて、その直前にリンクの文字列を入れる。 先ほどの URLを共有のダミー文字列を

1
2

<?php the_permalink(); ?>

に、 ツイート本文のダミー文字列を

1
2

<?php the_title(); ?>

に置き換えて保存。 再び、twitter のページに戻って、 ・URLを共有をページのURLを使う ・ツイート本文をページのタイトルを使う に設定して、リンク作成。 content-single.php ファイルで、先ほどと同じ div の閉じタグを検索し、その直前にリンクの文字列を挿入して保存。 これで使えるようになってるはず。 have fun!!

サイトを引っ越した。 引っ越しページも何も無く、唐突に動かしたので、元々、独り言ブログだったのが、さらに極まることに(笑) 以前、dynamic dns サービスの mydns と Let’s Encrypt の組み合わせで、制限に当たってうまくいかないという話と、格安 SSL に関する調査の話を書いた。 今回はそれの続き。 色々考えたんだけど、ドメインを取って、Let’s Encrypt を使うのと、無料DNSで格安SSLを使うのとで、どっちがいいかと考えると、金額的には変わらないし、同じくらいの金額でシンプルなドメイン名がとれるならと、結局、ドメインを取って無料SSLという、非常にオーソドックスな解決法に落ち着いた。 ドメイン名を買って、mydns に登録して、Let’s Encrypt で暗号化して今に至っている。 ドメインは某有名格安業者だが、dynamic dns の更新が Windows にしか対応していないので、DNS サーバは継続して、mydns を使うことにした。 Let’s Encrypt の更新も cron に登録したが、実際に更新されるのは 2ヶ月後になる。 サイト全体をSSL化することができたので、ついでに HTTP/2 にも対応した。 サーバーは Raspberry Pi だが、サクサク動いて、ちょっと感動的である。