Scalaの世界に入門する
Scalaを始めることにした。
去年から考えていたけれど、そろそろ真面目に関数型のアプローチに触れなくては、今までの自分の中で創り上げてきたなんちゃって関数脳から逃れられないと思ったから。なので、オブジェクト指向と関数型の両方のアプローチを採りつつ、関数型が推奨されるというScalaを使うことで、上手くオブジェクト脳を使いながら関数に脳を拡張していこうと決めた。
教材は、コップ本。
あと、勉強を後から見返すために、Githubに勉強用リポジトリも用意。
DebianのChinachu（録画）サーバーにUSBでHDDを増設した
録画サーバーはコンパクトにまとめようと思っていたので、当初HDDは2.5インチの500Gを選んだ。 どうせネットワーク経由でつながっているし、HDDがいっぱいになってきたらどっかの外付けに移せばいいと思っていたが、色々と問題が出てきたので、サーバーに外付けHDDを刺してとりあえずしばらくの間は凌ぐことに決めた。
買ってきたHDDは、Seagateの2TのHDDで、外付けケースはGroovyの35SATA-U3-BK。これで3台目の外付けケースだが、選んだ理由はUSB3.0対応と、並べた時にカッコ良さそうなデザインだから。 だが、録画サーバーはUSB2.0ポートしか無いので、近いうちにサーバーのリプレースか、それとも他の解決策を模索しなくてはいけないだろう。
LinuxにUSBでHDDを繋ぐのは初めてだったので、いろいろなページを見て調べた。概ね、次の手順になるみたいだ。
GithubのWebhookを受け取ってみる
仕事ではGithubを使った開発をやっているので、コードレビューやなんかもGithub上でやっている。
しかし、コメントはGithub上でやっているが、その他の多くのやりとりを他のグループウェアでやっている関係上、Githubに書いてはグループウェア上でURLを張り、コメントを求めるというやや二度手間的な事態が発生していた。
なので、GithubのWebhookを受け取り、PullRequestにコメントがあった場合は、グループウェアの方にその内容を転記するシステムを作ろうと思って、ここ数日なんじゃかかんじゃかコードを書いていた。
その過程で、GithubのWebhookを実際に受け取り、その内容を精読していたのだが、どうもドキュメント類を読んでも「Githubの何のイベントに対応したHookなのか」を知る方法が分からない。 現状で欲しいのはPullRequestに対するコメントだけなので 、その他の雑多なHookはどうでもいいのだが、今後の拡張性を考えると、どんなHookなのかを判別する方法は今のうちに作っておいた方がいい。
MacのGitでmvしたらコケた
前にも一回同じ事で困ったことがあるけど、二度と困らないようにブログにしておく。
gitを使ってファイルを管理しているとき、gitに無断でファイルの移動はやってはいけない。gitがそのファイルを追いかけてくれなくなるからだ。
git mv hoge foo
って感じに、ファイルを移動することで正しく追跡を続けてくれる。
困ったのは、Macを使っているときに、次のようなファイル移動をしようとしたとき。
git mv FizzBuzz Fizzbuzz
こういうエラーがでる。
Fedoraの.bashrcを壊した話
Fedoraというか、Redhat系のお話
.bashrcをGithubで共有するようにしてからしばらく経って、新しいPCにFedoraを入れた。 最初は特にターミナルとかも普通だったのだけど、ひと通り確認終わってからgit cloneしてきた.bashrcに置き換えると、表示が完全に変になった。 ぱっと見てわかる症状は、
-
プロンプトが表示されない（というか、bashのバージョンが出る）
-
カラースキームが変（エディタもそうだし、普通の状態も変）
-
でもなんか.bashrcの内容は反映されてる
って感じ。 一番悩んだのは、.bashrcで設定しているPATHとかAliasとかは反映されているので、どうも.bashrcのエラーって感じではなさそうということ。 だが、新しいPCを買ったのは2月で、2月は地獄のように忙しい毎日を過ごし、3月も別の趣味に一ヶ月を投じてしまったので、ほとんど ターミナルを触ることなく、放置してしまった。
tailfでWebサーバーのログを監視するのがいい加減目が痛い
ステータスコードに色を付けてみた。
tailf /var/log/nginx/access.log | perl -pe 's/ 2\d\d /\033\[1;36m$&\033\[0m/gi;s/ 3\d\d /\033\[1;33m$&\033\[0m/gi;s/ (4|5)\d\d /\033\[1;31m$&\033\[0m/gi'
perlを使って、シェルに出てくる特定の文字列に色をつけてるだけ。
ちょっと楽になる。
NginxでリバースプロクシをしているサイトでWebSocket使ったら、なんか変な感じになった
バックエンドで起動しているMojolicious製アプリにNginxのリバースプロクシ経由でアクセスしたら、WebSocketが即切れるようになった。 考えてみたら当たり前だけど、そりゃ実行している場所とアクセス受けてる場所が違ったら、そうなる気がする。
解決方法は、単純にNginxの設定に
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
を書くだけ。serverディレクティブの下に書いていいのか、それともlocationで縛っておいたほうがいいのかはよくわからない。 nginx websocket reverse proxy configuration
仕組み的には、今のセッションを別のプロトコルに変更するヘッダがhttp1.1にあって、それを追加しているらしい。なので、http_versionのディレクティブは必須。これを書き忘れて、しばらく悩んでいた。 Nginxの最新安定版がWebSocketのリバースプロキシに対応したそうなので試してみた
あと、Nginxのバーションも1.4以上である必要がある。（開発版だったら1.3でも行けるらしいけど、いまさら1.3を使う理由は特にないと思う） CentOSだったので、yumにリポジトリ追加してインストール
rpm -ivh http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
yum update -y nginx
こんな感じで思いっきりばーんとアップデートかけたら、設定ファイルが飛んだ。ワロス。
実際には飛んだわけではなく、.rpmnewという拡張子がついてバックアップされていたが、それにしばらく気づかず、ブログのトップ画面が “ Welcome to Nginx! “ になって焦りまくっていた。二年前に勢いで作ったVPSとリバプロ構成だったので、全然設定覚えてなかったから助かった……マジでちゃんと構成管理やろう。
ともあれ、こんな感じで無事Nginxのアップデートと、WebSocketのリバースプロクシ対応ができたので、この間作ったWebSocketのサンプルをVPSで動かすことができた。 https://github.com/YasuhiroKinoshita/learn_websocket
今日は勉強会という名のもくもく会に出て、ひたすらWebSocketを使ったWebアプリをコーディングしていた（上のGithubのやつとは別）ので、VPS上で動かせてよかった。
ブロガー探偵になりたい
正確に言うと、ブロガーの助手がいる探偵になりたい
X61をアップグレードするかどうか、さくらクラウドで実験してみた（続報）
改めてdstatで同条件で計測してみたところ、どうやらメモリだけじゃなくてSSDのスピードも相当やばいことがわかった。 なんだこの結果
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
5 1 94 0 0 0| 0 32k| 11k 443k| 0 0 | 420 83
2 1 77 20 0 0| 33M 0 |1356B 37k| 0 0 |1189 2150
7 2 56 35 0 0| 58M 0 |3380B 132k| 0 0 |2143 3771
2 1 86 12 0 0| 18M 0 |3378B 89k| 0 0 | 757 1261
3 1 78 18 0 0| 26M 0 |4077B 131k| 0 0 |1032 1722
5 2 62 31 0 0| 51M 0 |3612B 83k| 0 0 |1855 3315
6 3 54 38 0 0| 61M 0 |3148B 77k| 0 0 |2235 3997
5 2 59 34 0 0| 57M 0 |3247B 103k| 0 0 |2071 3714
5 1 63 32 0 0| 47M 0 |1963B 47k| 0 0 |1708 3057
3 1 90 7 0 0| 10M 0 |5131B 134k| 0 0 | 535 740
7 1 83 9 1 1| 12M 0 |9693B 402k| 0 0 | 803 862
3 1 78 18 0 0| 28M 0 |2745B 50k| 0 0 |1085 1892
7 1 74 18 0 0| 28M 0 |8038B 336k| 0 0 |1282 1846
4 1 81 14 0 0| 21M 0 |3696B 120k| 0 0 | 883 1411
4 1 82 14 0 0| 25M 0 |5269B 167k| 0 0 |1049 1683
4 2 74 21 0 0| 33M 0 |6067B 206k| 0 0 |1300 2149
10 2 50 38 0 0| 64M 0 |6456B 261k| 0 0 |2523 4182
10 1 73 16 0 0| 25M 144k| 12k 515k| 0 0 |1381 1677
X61をアップグレードするかどうか、さくらクラウドで実験してみた
さくらクラウドで、2コア6GのSSDマシンでインスタンス作ってみたところ、同等のDBでほぼクエリが一瞬で流れることが判明。むしろ、受け取ったデータを処理するほうがボトルネックになってた。 やっぱり、メモリの量が問題みたいだ。どうしたもんか。