chrome.windows.createで作られるwindowはフレームを含むのでOS毎にサイズを変えないといけない

最近、メインのOSをWindowsに移しつつあって、以前つくったChrome拡張の favurl - Chrome ウェブストアWindowsで使ってみると、URL をツイートするwindowがうまく表示されなかった。ここでのwindowはbrowser_actionで出るpopup、つまりツールバーのアイコンをクリックしたときに出る、manifest.jsonで指定したpopupのwindowではなく、chrome.windows.create()を使って作ったwindowのことである。参考: chrome extentionのpopupを別窓で表示する。 - 脱力系日記

この拡張の場合だと、webページを右クリックして出てくるコンテキストメニューをクリックすると、 f:id:TAKEmaru:20171123230054p:plain

このURLをツイートするwindowが出るが、 f:id:TAKEmaru:20171123230402p:plain

Windowsだとheightが足りずボタンが表示されなくなっていた。 f:id:TAKEmaru:20171123232458p:plain

原因は、chrome.windows.createで指定するheight、widthがフレームを含んだサイズなのに、フレームの大きさがOS毎に違うからだった。異なるOSで見たときにフレームを除いた部分のサイズが変わってしまい見た目が崩壊する。フレームの大きさがOS毎に違うというのがどういうことなのかイメージしにくいが、閉じるボタンや拡大ボタンがあるバーの大きさがOS毎に異なるため、フレーム全体の大きさが変わってしまうということだ。

これにはwindowを作成する前にOSを確認し、OSによってheightとwidthを変えることで対処できる。コードは以下のようになった。

let windowHeight = 107;
let windowWidth = 450;
if (navigator.platform.indexOf("Win") != -1) {
  windowHeight = 140;
}

chrome.windows.create({
  url : 'tweet.html',
  focused : true,
  type : 'popup',
  height : windowHeight,
  width : windowWidth
});

golangでご覧!wて言いたくてgolangでHTTPサーバ書いた

golangでご覧!wて言いたくてHTTPサーバー書いた。PythonのSimpleHTTPServerっぽくなった。名前がgoranなので「golangのgoranでご覧!w」と言えるようになった。

tkmru/goran: simple http server.

雑に以下のようなかんじで使える。localhostにしないと使えないブラウザのAPIとかあって開発のときにシュッとHTTPサーバーを用意できると便利で一応そういう実用的な側面もある。

$ cd DOCUMENT_ROOT
$ goran
2017/11/07 23:22:29 Starting Goran HTTP Server
2017/11/07 23:22:29 Listen : http://127.0.0.1:8888
2017/11/07 23:22:29 RootDir: ./
2017/11/07 23:22:38 127.0.0.1:65208 GET /

いろいろオプションがあって、アドレス、ポート、ルートディレクトリ、configのパスを指定できる。

$ ./goran -h
Usage:
  -a string
        address to use (short) (default "127.0.0.1")
  -address string
        address to use (default "127.0.0.1")
  -c string
        config path to use (short)
  -config string
        config path to use
  -p uint
        port to use (short) (default 8888)
  -port uint
        port to use (default 8888)
  -r string
        root directory to use (short) (default "./")
  -root string
        root directory to use (default "./")

configファイルにはTOMLを使った。以下のように設定できる。

Port = 6000
Addr = "127.0.0.1"
rootDir = "/var/www/hoge"

Golangの勉強になってよかった。暇なときにworkerprocessとかキャッシュとかリバースプロキシの設定をできるようにしたい。

ActiveResourceを使ったRailsアプリをRedisで高速化した

ActiveResource とは

ActiveResourceはRESTful APIマッピングActiveRecord のモデルとして利用可能にするgemで、これを使うとActiveRecordでDB操作を行うのと同じようにRESTful APIを利用できます。

github.com

ボトルネックになることもある

ActiveResourceを頻繁に使うとAPIに過剰にアクセスしているのと同じこととなり、ボトルネックとなりえます。 以下は今回、チューニングの対象となったアプリのNginxのアクセスログkataribeでパースしたものです。

$ cat /var/log/nginx/access.log | kataribe
...
TOP 12 Slow Requests
 1  14.933  GET / HTTP/1.1
 2  14.898  GET / HTTP/1.1
 3  14.722  GET / HTTP/1.1
 4  14.692  GET / HTTP/1.1
 ...

rootへのGETリクエストが14秒台後半で非常に遅いことがわかります。これはActiveResourceを使って取ってきたデータを一覧するページで、ActiveResourceボトルネックとなっていると推測できました。

Redisでキャッシュする

オンメモリ KVSのDBであるRedisにキャッシュすることで高速化を図ります。Redisはメモリ上でデータを管理するため、Read/Writeともに高速でキャッシュとして適しています。ActiveResourceを使ってデータを引っ張ってくるところをキャッシュしてみました。

RedisとRailsアプリケーションの接続にはmperham/connection_pool: Generic connection pooling for Rubyを使いました。コネクションプールというのはDBのコネクションをあらかじめ一定数確立しておいて使いまわす手法で、これを使うとDBへの接続に必要となるオーバーヘッドをカットできWeb/DBの双方の負荷を下げることができます。また、Web/DB間の接続を使いまわすことで同時接続数を節約します。MongoDB gem、ActiveRecord gemは自前でコネクションプールを持っていますが、Redis gemは持っていないので、このgemを使って接続することでコネクションプールを使えるようにしました。以下がRedisへの接続のために追加したファイルです。

config/initializers/redis.rb

# frozen_string_literal: true

# Load the redis.yml configuration file
redis_config = YAML.load_file(Rails.root + 'config/redis.yml')[Rails.env]

Redis.current = ConnectionPool.new(size: 10, timeout: 5) do
  Redis.new host: redis_config['host'], port: redis_config['port']
end

config/redis.yml

default: &default
  host: localhost
  port: 6379

development:
  <<: *default

test:
  <<: *default

production:
  <<: *default

Redisへのアクセス

Redisへのアクセスはcontroller内で以下のように行えますが、ここで注意しないといけないのは、keyがハッシュであるオブジェクトをJSONに変換しRedisにいれると、Redisから取り出しJSONにした際にkeyがstringになるところです。with_indifferent_accessを使うなどして対処しましょう。

Redis.current.with do |redis|
  test_user = { :name => "tkmru", :email => "tkmru@hoge"}
  redis.set('test_user', test_user.to_json)
  test_user = JSON.parse(redis.get('test_user')) # {"name"=>"tkmru", "email"=>"tkmru@hoge"}
  p test_user[:name]                             # nil
  p test_user['name']                            # tkmru
  test_user = test_user.with_indifferent_access
  p test_user[:name]                             # tkmru
  p test_user['name']                            # tkmru
end

結果

$ cat /var/log/nginx/access.log | kataribe
...
TOP 10 Slow Requests
 1  3.566  GET /hoge/231 HTTP/1.1
 2  1.866  GET / HTTP/1.1
 3  1.482  GET /hoge/240 HTTP/1.1
 4  1.479  GET /hoge/226 HTTP/1.1
 5  1.439  GET / HTTP/1.1
 6  1.415  GET /hoge/238 HTTP/1.1
 7  1.410  GET / HTTP/1.1
 8  1.293  GET / HTTP/1.1
 9  1.119  GET /hoge/243 HTTP/1.1
...

14秒台後半だったrootへのGETリクエストが1.4秒ちょっとで終わりました。 /hoge 以下もキャッシュすればもっと早くできそう。

おわりに

今回は原因が自明であったため、kataribeによるNginxのアクセスログのプロファイリングしか行いませんでしたが、pt-query-digestによるMySQLのスロークエリの解析や、stackprofrblineprofによるRubyのコードのプロファイリングを行うとより詳細にボトルネックを見つけることが可能です。 また、Redisでキャッシュすることによる高速化は、ActiveResourceを使ったアプリケーションに限定されるテクニックではなく、様々なアプリケーションで使うことができます。やっていきましょう。

コマンドラインオプションをflagでパースしたとき-hを指定するとexit status2と出てしまう

どういうこと

golangではコマンドラインオプションをflagパッケージを使ってパースすることができる。 しかし、オプションに-h--helpを指定すると、以下のようにexit status2と出てしまう。 なんでこんな仕様なのか分からない...

$ go run flagSample.go -h
Usage:
  -n int
        number to use (default 1234)
exit status 2

これを出ないようにしたい。

対応策

flag.Usage を使ってUsageを表示するときに動かす関数を指定してあげ、その関数内で os.exit(0) を呼ぶと-h--helpを指定したときの statusコードは0となり、exit status2は出なくなる。以下にコード例を示す。

コード

これは、-nで指定した数字を表示するだけのコマンドラインツールのコードである。flag.Usageで指定したUsage()内でos.exit(0)を呼んでいるので、exit status2 は出ない。

package main

import (
    "flag"
    "fmt"
    "os"
)

var number int

func usage() {
    fmt.Println("Usage:")
    flag.PrintDefaults()
    os.Exit(0)
}

func init() {
    const defaultNumber = 1234
    flag.IntVar(&number, "n", defaultNumber, "number to use")
    flag.Usage = func() { usage() }
}

func main() {
    flag.Usage = func() { usage() }
    flag.Parse()
    fmt.Println("flag test")
    fmt.Printf("Number: %d\n", number)
}

実行結果

$ go run flagSample.go -n 6666
flag test
Number: 6666
$ go run flagSample.go -h
Usage:
  -n int
        number to use (default 1234)

複数人のSSHの鍵をGitHubに登録している鍵を使ってシュッと鯖にいれる

各ユーザーがGitHubに登録している公開鍵は公開されていて誰でも見れるのでこれを使う。 大体の人はGitHubに鍵を登録しているだろうし、これを使えばシュッと鯖にSSHの公開鍵を設定することができて便利。 以下のようにcurlコマンド一発で複数人のSSHの鍵を登録することができる。

$ curl https://github.com/{user_id, user_id2, user_id3}.keys >> ~/.ssh/authorized_keys

ISUCONのときにも役立った。ISUCON、あと3000点ちょい....というところで予選敗退したので来年リベンジするぞ!!

Mitamaeでdotfilesの管理をやるようにした

Mitamaeでdotfilesの管理をするようにした。

Mitamaeとは

プロビジョニングツールのitameのmruby実装である。mruby実装にすることで何がうれしいかというとRuby や gem に依存しなくなるというのがある。Mitamaeのバイナリがあれば動くので、curlで引っ張ってきてシュッと使うことができる。ちなみに読みは「見給え」ではなく「えむいたまえ」らしい。

k0kubun.hatenablog.com

これを使うと環境構築のための環境構築を最小限の手間にすることができる。 dotfilesのデプロイにいままで自前シェルスクリプトを使っていたが、やはりitamaeを使うほうが便利であった。 dotfilesのデプロイだけではなく、ソフトウェアのインストールまで簡単にできる。

構成

ぼくのdotfilesはtkmru/dotfilesで、k0kubun/dotfilesakito19/dotfiles をかなり参考にしている。

$ tree -aL 2
.
├── .git
│   ├── FETCH_HEAD
│   ├── HEAD
│   ├── ORIG_HEAD
│   ├── config
│   ├── description
│   ├── hooks
│   ├── index
│   ├── info
│   ├── logs
│   ├── objects
│   ├── packed-refs
│   └── refs
├── .gitignore
├── README.md
├── bin
│   └── setup_mitamae.sh
├── config
│   ├── .bash_aliases
│   ├── .bash_profile
│   ├── .bashrc
│   ├── .gdbinit
│   ├── .gitconfig
│   ├── .profile
│   ├── .tmux.conf
│   └── .vimrc
├── cookbooks
│   ├── gdb
│   ├── git
│   ├── symboliclinks
│   ├── tmux
│   └── vim
├── deploy.sh
├── init.sh
├── lib
│   └── bootstrap.rb
└── roles
    ├── darwin
    └── ubuntu

最初に実行するのはinit.shで、OSがmacだった場合、Xcode Command Line Toolsのインストールやhomebrewのインストールを行い、Mitamaeをcurlでダウンロードする。そして最後にホームディレクトリからdotfilesへのシンボリックリンクを貼るdeploy.shを実行している。deploy.shからMitameを用いてlib/bootstrap.rbを実行し、roles.rbからcookbook以下のレシピを実行している。 また、OSごとに使うdotfilesが違う(ubuntuの.profileとか)ので、deploy.sh内でunameを使ってOSを判定し、roles以下で異なる処理をさせている。

参考資料

GSoC完走できた〜💪

GSoC完走できた〜!!metasploit-framework に3ヶ月間、コントリビュートしていました。


f:id:TAKEmaru:20170910004947p:plain

tkmr.hatenablog.com

linuxのstager周りを触るということでアセンブリ書いてお金💰もらってたけれど、そうそう業務でアセンブリ書かないだろうし、これが人生で最初で最後になる気がする。Googleからお金もらうのもこれ最後か〜と思うとエモくなってきた。

参加前にwebで参加記みたいなの読んでた時は、進捗報告ミーティングがしょっちゅうあるみたいなことを見ていたのでビビっていたけど、Metasploitでは適宜困ったら相談というかんじで平和に進行していった。試験期間はあまりコミットできないって言ったら了承してもらえたりもした。採用されるOSSによるだろうけど、ビビらずに応募するとよさそう。

期間中のおもしろエピソードとしては、チャットツールが最初はIRCだったけど、「ログ取るのにサーバ必要だしやだ〜」って言ったらTwitterのDMになって、それからGoogle Hangoutになって、最終的にslackになったこととか、rapid7から日本語できる人が出てきたというのがある。

書きかけのshellcodeが2つあるのでこれは後々プルリク送りたい〜。OSSに名前を残せたとかより、チャットなら英語でコミュニケーション問題なくとれることが分かったのが一番の収穫な気がする。とは顔本で書いたものの著名なOSSに名前が入るとアガる。

f:id:TAKEmaru:20170910010731p:plain

これからも継続してコミットしていけるといいですね。