はてなブックマーク

io.Readerのファイルタイプを判定する を拝見してちょっと気になったので調べました。 io.MultiReaderではWrite関数しか実装されておらず、 WriteTo(w Writer) (n int64, err error)関数が存在しません。 そのため、みんな大好きio.Copyで積極利用されるWriteTo(w Writer) (n int64, err error)関数が働かず少し残念な気持ちがありました。 もしかすると気持ちだけの問題かもしれないのでBenchmarkしてみました。 bufio.Readerには WriteToが実装されいたので、こちらを元のReaderに被せてる事にしました。そうすると都合よくまさにリード位置を進めず先頭から指定バイト数だけ読むbufio.Peek関数が用意されていたのでそちらを利用しました。 元のisGzip関数を書き直したのが以下

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 golangでdaemonを作成しそれをWindowsに移植することになったので、golang製daemonをwindowsサービス化させるためのメモです。 手段 NSSM (the Non-Sucking Service Manager)を使う方法 kardianos/serviceを使う方法 の2通りの手段があるがあるようです。 前者は、NSSMというサービス登録ツールを利用してプログラムをサービスぽくWindowsに認識させる方法と、 後者は真面目にサービスプログラムらしく実装できるパッケージを使う方法となっています。 今回はkardianos/serviceを使う方法を紹介します。 kardianos/service このパッケージは、Windowsサービスを作ることに特化したパッケージではなく、Linuxのupstartを使ったdaemonの作成や、MacOSのdaemon

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

influxdbのコードを読んでいて出てきた hash/fnv ってなんだ？と思って調査 概要 非常に軽量でありながら比較的高い分散を持つという特徴がある（ただし，セキュリティ用途に用いることができるほどの耐衝突性は無い）。 速度 最後に簡単な速度の比較を行った。結果として， CRC-32 よりも FNV-1 の方が 3% ほど速いという値が得られた。ただしこの結果については，厳密な測定方法を用いなかったことや，測定環境のセットアップの問題などがあり，あまり深い意味を求めることはできない。 FNV-1 と CRC-32 は，いずれもシンプルなアルゴリズムでありながらも特徴があり，プロセッサによっては速度に差が出る可能性も考えられる。 FNV-1 は乗算と XOR のみから構成されるが， CRC-32 は XOR が 2 回と AND とビットシフト，それにテーブル参照から構成されている。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 googleカレンダーをgolangで取得、追加、更新をやってみます。 Goolge Calendar API v3を使うのですが、OAuthなので、まず以下の前準備が必要です。 google APIの Client IDの取得 OAuth認証でアクセストークンを取得する ただし、アクセストークンの取得部分は goauth2の認証手順をもっと簡単にを参考に、プログラム側で作りました。 環境 OS X 10.9 (or Windows7 まだ動作確認していないけど、多少の手直しで動くはず) golang 1.3 google API Client IDの取得 https://console.developers.google.com/project から、 Create Projectをクリック それぞれ適当な名前をつけてCreate Project Dashboardから Enabl

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 importするだけで使えるgolang製kvsのboltdb で、インスパイアされて、 golang製kvsのgoleveldbを紹介します。 goleveldbとは goleveldbとは、leveldbのgolang portです。(完全に同じかどうかは調べきれてません・・・) levigo等のleveldbラッパーとは違い、native golangで書かれているので、Cのleveldbライブラリを必要とせず、golangでimportするだけで簡単に利用できるのでお手軽です。 個人的には、sqliteの組み込みDBとして利用するような感覚で、組み込み永続化KVSとしての用途が向いているように思います。 leveldbについてはLevelDB入門 (基本編)が詳しいですが、そこから特徴を引用させてもらいます。 keyとvalueが任意のバイト列である データはkeyでソートさ

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:schedule="http://wsdl.cybozu.co.jp/schedule/2008"> <soap:Header>・・・・・</soap:Header> <soap:Body> <schedule:ScheduleGetEventsResponse> <returns> <schedule_event id="1351459" event_type="repe

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:base_services="http://wsdl.cybozu.co.jp/base/2008"> <SOAP-ENV:Header> <Action SOAP-ENV:mustUnderstand="1" xmlns="http://s

asciiでの平文メールはnet/smtpで簡単に送信できるようですが、 http://kwmt27.net/index.php/2013/09/26/how-to-send-mail-with-golang/ utf8になると本文とsubjectのエンコード処理の面倒な部分を やってくれるパッケージを探したんだけど見つからなかった。 本文はbase64でエンコードすれば良いんだけど、 subjectが若干面倒 http://d.hatena.ne.jp/y_fudi/20090501/1241173690 で、メールに関するお約束のRFC2822にこんな規定がある。ヘッダーに限定されているわけではないが、メールの1行に並べていい文字数には制限があるようだ。 http://www.puni.net/~mimori/rfc/rfc2822.txtより引用： 行の長さの制限 この標準では１行中

概要 ログの収集にfluentdを利用して一カ所に集めるというよくある構成の場合、 収集するログの量と対象のサーバーのスケールアウトでログの量が急増した時に ログ転送先がスケールできなかったり下手すると単一障害点になることもあります。 そこで、fluent-plugin-forward-awsで疎結合なログ転送 で、「スケールし、落ちないログ転送先」として紹介されている 各サーバーから直接S3にログを転送し、SQSを使ってログの収集元と収集先を疎結合にする という方法が良さそうだなあと思ったんです。 しかし、肝心のS3のリクエスト数に制限は無いのかどうか心配になり調べてみました。 S3のリクエスト数の限界 Amazon S3のパフォーマンスをあげるコツ によると、秒間50リクエストを超えるような場合は、この記事中のベストプラクティスに従わないとパフォーマンスが出ないようです。 fluent

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

if self.runner.sudo or sudoable: shcmd, prompt, success_key = utils.make_sudo_cmd(sudo_user, executable, cmd) elif self.runner.su or su: shcmd, prompt, success_key = utils.make_su_cmd(su_user, executable, cmd) vvv("EXEC %s" % shcmd, host=self.host) sudo_output = '' try: chan.exec_command(shcmd) if self.runner.sudo_pass or self.runner.su_pass: while not sudo_output.endswith(prompt) and success_key

ansibleは、インベントリファイルに記載されているホストを認識するのですが、実はInventoryファイルは静的なテキストファイル以外に、実行可能なスクリプトファイルを指定できます。 やり方 Dynamic Inventory に詳しく記載されていますが、以下のようなjsonを返すスクリプトファイルを用意し、実行権限を付けて保存したファイルを ansible-playbookコマンド等の　-iオプションに渡せば良いだけです。 { "databases" : { "hosts" : [ "host1.example.com", "host2.example.com" ], "vars" : { "a" : true } }, "webservers" : [ "host2.example.com", "host3.example.com" ], "atlanta" : { "hosts"

$ ansible-playbook -i <(curl -s https://raw.github.com/masahide/playbook-sample/master/localhost) <(curl -s https://raw.github.com/masahide/playbook-sample/master/sample.yml) -e dir=`pwd` PLAY [localhost] ************************************************************** TASK: [create directories for ansible files.] ********************************* changed: [localhost] => (item=/home/masahide/work/pl

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

ansible-lssd Murderという twiiterの人が作ったBitTorrentを利用したデプロイツールがありました。 動作を試してみたところすばらしく高速にデプロイできて感動したのですが、 Capistranoの拡張として書かれおり、使い辛い部分があったので、 Ansible のPlaybookで書き直してみました。 名前は何でも良かったんだけど、とりあえず、Large scale server deployの頭文字でansible-lssdにしてみました。 Murderについては、 http://www.publickey1.jp/blog/10/twitterbittorrent.html の解説が詳しい。 http://qiita.com/yamasaki-masahide/items/a4281dbbe0d4ebcbfdeb にMurderのレビューを書いた。 説明

概要 Murderとは TwitterがBitTorrentを利用して高速にデプロイするのに使っているツール。 http://www.publickey1.jp/blog/10/twitterbittorrent.html の説明が一番わかりやすい。というか日本語ではこれしか無い。 特徴 Capistranoの拡張のように動く(?) Capistrano(ruby)とPythonスクリプトで構成されており、Capistranoのdeploy_via:として動く Capistranoを使ったことがあればその延長で使えるかも BitTorrent等のライブラリの配布は自動 BitTorrentは同梱されており、必要なスクリプトやライブラリは、すべてのサーバへCapistranoで自動配布される コマンド一発でデプロイ Capistranoを使って、tracker,seeder等必要なプロセスの