mumumu の日記

Development, Translation, daily life, thoughts, and so on.

update test environment of redis-py

2015年は Redis と戯れていた一年と言っても良い。Redis Cluster を Production 環境に導入し、redis-py-clusterREADONLY 対応の patch を送った りした。

Redis Cluster は Redis 3.0 で加わった新機能であり、もうじき 3.2 が出ようとしている。そんな状態の中で 2.8 でしかテストされていないのはどうなの? と思い、以下の 2つの patch を送っておいた。

特に前者は、2.8 によるテスト環境をごっそり 3.0 に入れ替えるものなので、割とドラスティックである。Redis 側で 2.8 をいつまでサポートするのか、というポリシーが明確ではないので、取り込むタイミングは流動的だと思われる。

ただ、3.x 特有の機能が増えていく中で、一石を投じる必要としては今がいいんじゃないかな、と思った次第である。

Silly patch - could not detect repository update

PEP8 のファイル更新を監視するのに、 Mercurial リポジトリ更新チェックツール というのを書いている。コミットメールや hg.python.org の RSS を見れたりすれば一番良いのだが、前者はPEPの編集者や開発者にしか開放されておらず、後者はファイル単位の更新を見せるようにはできていない(*1) 。このツールはファイル単位での更新があったらメールしてくれるというもので、自分のニーズを満たすための単純なものだ。

ところがこのツール、ちゃんと動いていなかった。更新がリモートリポジトリにあってもちゃんと検知できていなかったのだ。ダメぢゃん!
原因は git pull にあたるコマンド を hg update だと思い込んでいたというもので、単純に Mercurial の理解不足である。

なので、こういうお馬鹿な patch を書いてしまうんですね。ハイ(´ー`; )
誰の役にも立たないんで、ますますお馬鹿度が増すという…

1
2
3
4
5
6
7
8
9
10
11
12
13
diff --git a/rev_update_checker.py b/rev_update_checker.py
index b6109fe..af39899 100644
--- a/rev_update_checker.py
+++ b/rev_update_checker.py
@@ -22,7 +22,7 @@ class TargetRepository(object):

     def update(self):
         os.chdir(self.repository_path)
-        subprocess.check_output(['hg', 'update'])
+        subprocess.check_output(['hg', 'pull', '-u'])


 class TargetFileRevision(object):

(*1) だったら hgweb に patch 投げればいいやん、と思って、投げておきました

restore github page from source branch

github page を Octopress で公開している人は、きっと master が HTML と CSS だけで出来たリポジトリを github に持っており、かつ source ブランチでそれを生成するための Rakefile や _config.yml、ブログエントリの markdown、テーマなどをバックアップしているはずだ。

では、何かの拍子にブログを書く環境を壊してしまい、source ブランチから復活させなければならなくなった場合はどうだろうか。今朝ちょうどそういう状況に陥ってしまい、復旧に少し手間取ったのでメモしておく。

要するに clone した後、 _deploy ディレクトリを生成し、そこで git リポジトリを再初期化し、github page へのリポジトリを remote に加えるだけだ。 要するに、 setup_github_pagesタスクの後半 を真似ただけである。

1
2
3
4
5
6
$ git clone git@github.com:mumumu/mumumu.github.io.git blog
$ cd blog
$ mkdir _deploy
$ cd _deploy
$ git init
$ git remote add origin git@github.com:mumumu/mumumu.github.io

あとは rake new_post["some title"] で記事を書き、rake generaterake gen_deploy の操作でいつも通り記事が公開できるようになる。

こうしたリストアの操作と、 git push origin source というバックアップ操作が面倒くさかったので、以下のような patch を Rakefile に足しておいた。

まずは バックアップの操作が rake gen_deploy後に自動で行われるようにした。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
@@ -252,16 +252,38 @@ multitask :push do
   Rake::Task[:copydot].invoke(public_dir, deploy_dir)
   puts "\n## copying #{public_dir} to #{deploy_dir}"
   cp_r "#{public_dir}/.", deploy_dir
+  message = "Site updated at #{Time.now.utc}"
   cd "#{deploy_dir}" do
     system "git add ."
     system "git add -u"
     puts "\n## Commiting: Site updated at #{Time.now.utc}"
-    message = "Site updated at #{Time.now.utc}"
     system "git commit -m \"#{message}\""
     puts "\n## Pushing generated #{deploy_dir} website"
     system "git push origin #{deploy_branch} --force"
+  end
+
+  cd "#{deploy_dir}/../source" do
+    system "git add *"
+    puts "\n## Commiting: Site updated at #{Time.now.utc}"
+    system "git commit -m \"#{message}\""
+    puts "\n## Pushing source branch as backup"
+    system "git push origin source"
     puts "\n## Github Pages deploy complete"
   end
+
+end

github page のソースを clone した後、_deploy ディレクトリを再生成し、master として remote を足すタスクも追加した。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
+
+desc "restore github pages directory"
+task :restore_github_pages_directory do
+  puts "\n## Re-creating deploy directory"
+  rm_rf deploy_dir
+  mkdir_p deploy_dir
+
+  cd "#{deploy_dir}" do
+    repo_url = "git@github.com:mumumu/mumumu.github.io"
+    system "git init"
+    system "git remote add origin #{repo_url}"
+  end
+ end

 desc "Update configurations to support publishing to root or sub directory"

mini router plan

http://blog.livedoor.jp/connect_staff/archives/1804038.html

自分が使っているプロバイダが突如サービス終了するというアナウンスがあった。代替のプロバイダはもうほぼ決めた のだけど、これを機会にブロードバンドルータもどうにかしようという気になった。RTX1210 を中古で買うか、マシンをもう一台組んで VyOS を入れてしまう案の二つが上がったが、結果として後者、つまりマシンを新たにもう一台組むことにした。

・ ルータに使うマシンなので、大きなマシンは組みたくない
 ・ Mini-ITX がいいんじゃないですかね
・ ファンレスがいいよね。じゃあ前欲しがってた Atom C2000 シリーズあたりでいきますか

という思考から、以下のような構成を考えたのでメモしておく。メモリを16GBにする必要がどこにあるのかというツッコミは禁止します。

Mini-ITX はそのコンパクトさ故に電源やケースの組み合わせに注意が必要で、特にケースと電源選びは非常に面倒であった。電源は SFX電源とか考えるのが面倒だったので ATX 電源、かつ奥行き140mm で300W 以下、となると玄人指向のものしか残らなかった。Mini-ITX のケースは自分が考える最小のコンパクトさと電源のサイズをベースに考えていった結果、バランスのとれたモノとして Silverstone のものを選んだということである。

85k は安くはない。RTX1210 はこれより中古で安く買えるのでかつては迷ったが、やはり手元の自由度を選ぶと自作が最高だ。いつ組もうかなぁ(´ー`;)

パーツ項目 品名 価格
CPU Intel Atom processor C2750, SoC, FCBGA 1283, 20W 8-Core -
マザーボード Supermicro A1SAi-2750F 54,647
RAM SanMax Technologies SMD-N16G28ECTP-16KL-D 17,990
ケース Silverstone SST-SG13B 7,538
電源 玄人志向 80PLUS BRONZE取得 ATX電源 300W KRPW-PB300W/85+ 5,674
合計 85,849

Luvbook J

http://www.mouse-jp.co.jp/m-book/luvbookj/series.html

以前ノートPCを買ってから4年、また訳のわからぬノートPCを買ってしまった。後悔はない。

A) 林檎は嫌 (天の邪鬼的思考)
B) メモリは16GB載せたい (前より上のものを思考)
C) 割とHDDが遅くてイラっとする事案が頻発していたので、SSD 必須
D) 前も13型だったので、それより大きなものは嫌だなー

A) にこだわらなければ 林檎で満たせる事案 である。この点に妙にこだわった結果、かつメモリが16GB載せられるものを探した結果、Thinkpad X230 とか 今回買った BTO パソコンしか道はなかったのである。そして天の邪鬼思考がさらに発揮された結果、マウスコンピューターのものが残ったというわけだ。

2560 x 1440 とかいうかつて経験のない解像度も冒険という意味で後押しした。だが、Linux を入れた結果、林檎には不要な妙な調整が必要なことに気がついた。アプリを通常の状態で使うと、あまりにも小さく見えるのである(´ー`;)

自分は割とフォントを大きめにして使うので調整するのはいつものことなのだが、ブラウザで妙にツールバーが小さくなったりして非常に使いづらい見た目になってしまったり、サードパーティのアプリのアイコンとかがやたらと小さく見えるといった具合である。特にブラウザで適当な動きをするものがなかなか見つからないのには閉口した。

いろいろと探した結果、Firefox の デフォルトのCSS を調整する ことでデフォルトのズームレベルを 1.6 倍にして快適なレベルに調整することで事なきを得た。

フォントはやはり自分的には Migu 1M が相性がよい。 Ricty 使ってる人多いんでしょうけど、ターミナルと相性良いですかねあれ?(´ー`;)

とはいえ、非常にマシンのパフォーマンスは良く、キーボードも押す深さが自分にとっては快適で、ちょっと大きな打鍵音がするがちょうど良い。前の ASUS U31F と同様、長く使うことになろう。しばらく宜しく!