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でほぼクエリが一瞬で流れることが判明。むしろ、受け取ったデータを処理するほうがボトルネックになってた。 やっぱり、メモリの量が問題みたいだ。どうしたもんか。
X61にCentOS6.4を入れてDBサーバーにした
大学生の時に愛用していたX61に、最近とんと触っていなくて寂しくなった。
ので、CentOS6.4を入れて、前々からちょっとずつクラウドで作ってたDBを移植した。しかし、結局SSHで操作するから、あまり触らないことには変わりがなかったが……
ChinachuがTwitterでつぶやいた
Chinachuは、番組の録画が始まると自動でTwitterでつぶやいてくれる機能が有るらしい。
が、開発途中なのかわからないけど、リポジトリのWikiのところでは、まだ項目ができていなかった。 しかし、せっかくその機能があるならば使いたいと思ったので、直接ソースを見て確認してみたところ、上手くつぶやけたのでメモ。
結論だけ言うと、こういう記述をconfig.json内に書けばいいみたいだ。
Chinachuがなんだか変だ
たしかにアニメの方のChinachuも変だったけど、録画サーバーの方のChinachuも少し変だ。
現象としては、昨日の夜のアニメが全部録画できていなかった。 ファイルは作られていたのだが、全部のファイルサイズがアッカリ～ン状態で、 つまり何も録れていなかった。
これはいかんともしがたいので、とりあえずログを見てみると、どうやらチューナーがロックされたままになっていて、解除されること無く録画の時間に到達し、何も出来ないまま終了していたようである。 で、一体どこでロックされたままになったのかというと、同じログをたどっているうちにこんなのが出てきた。