GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
高速に自作パッケージをGithubにリリースするghrというツールをつくった
高速に自作パッケージをGithubにリリースするghrというツールをつくった tcnksm/ghr・Github ghrを使えば，1コマンドでGithubにリリースページの作成とそこへのパッケージのアップロードが可能になる．複数パッケージのアップロードは並列で実行される． デモ 以下は簡単な動作例． 上のデモでは，v0.1.0タグでリリースを作成し，pkg/dist/v0.1.0以下の6つのファイルを並列でアップロードしている（ghrをghrでリリースしている）．1ファイルあたり，2.0M程度なのでまあま速いかと．アップロード結果は，ここで見られる． 背景 “Go言語のツールをクロスコンパイルしてGithubにリリースする” 上で書いたようにcurl使って頑張ってAPIを叩いていたが，やっぱシェルスクリプトは嫌だし，アップロードが遅い． Githubへのリリースを行う専用ツールでaktau
Golangにおけるinterfaceをつかったテスト技法 | SOTA
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
golang勉強会でGo製ツールの配布方法について話してきた
golang勉強会でGo製ツールの配布方法について話してきた “Ship your CLI tool built by golang to your user #golangstudy” “Golang勉強会”で発表してきた．Go言語で作成したツールをクロスコンパイルして，複数プラットフォームに配布する方法について話してきた．自分がGoをはじめた理由の一つがクロスコンパイルによる配布のしやすさであり，いろいろ実践したりそれ用のツールを作ったりしてきたのでそれをまとめた． 以下の視点で話したつもり， 自動化により開発者の負担を減らす ユーザがツールを使うまでの負担を減らす “わかりやすいREADME.mdを書く”にも似たようなことを書いたけど，自分のような無名なエンジニアの作ったツールであってもユーザに使ってもらうには，2点目のような視点を大切にしないといけないと思う． 発表は以下の記事をも
好きなPodcast
twitterでちょっとつぶやいてたけど，最近自分がよく聴いてるPodcastをまとめてみる．Tech系以外もすこし混じってる．他にオススメあれば教えてください． 日本語 Rebuild - Podcast by Tatsuhiko Miyagawa - Podcastを聴くという習慣はここから始まった．大学院生のころからずっと聴いてる．Liveもできる限り聴いてる．大ファン．取り上げる技術もすごい尖っていて面白い．全エピソード好きだけど，敢えてあげるなら，“3: MessagePack”，“14: DevOps with Docker, chef and serverspec”，“27: Dragon Quest, Docker and AngularJS”，“35: You Don’t Need API Version 2”, “37: N Factor Auth”，“42: When
HomeBrewで自作ツールを配布する
HomeBrewで自作ツールを配布する 複数プラットフォームにGoアプリケーションを配布する 上の記事で，Go言語で作ったツールを複数プラットフォーム向けにクロスコンパイルし，作成されたバイナリをBintrayでホストするまではできた．あとは，ダウンロード・展開・PATHを通す，をやってもらえば，自分の作ったツールを使ってもらえる． OSX向けにツールを配布する場合はHomeBrewのFormulaを作っておけば，これをもっと簡単にできる． TL;DR 以下でインストールできるようにする． $ brew tap <ユーザ名>/<パッケージ名> $ brew install <パッケージ名> ただし作成したツールが，GithubのリリースページやBintrayにホストされていることを前提とする． Formulaの作成 Formulaとは，HomebrewでインストールするパッケージのURLや
複数プラットフォームにGoアプリケーションを配布する
複数プラットフォームにGoアプリケーションを配布する tcnksm/jj 最近試しにGo言語でCLIアプリケーションを作成した．joelthelion/autojumpをシンプルにしただけのツールで，ディレクトリを保存して，どこからでもその保存したディレクトリへの移動を可能にする． Goの環境さえあれば，このようなGo言語のアプリケーションの配布はとても簡単で，インストールは以下のようにするだけでよい． $ go get github.com/tcnksm/jj_ これだけではなく，Goはクロスコンパイルが簡単で，様々なプラットフォーム向けにバイナリを生成することができる．つまり，Goがインストールされていない環境に対しても簡単にツールを配布することができる． Packerなどの最近のHashicorp制のツールは，Go言語で書かれており，OSX，Linux，Windows，FreeBSD
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
Dockerコンテナのおもしろい名前
Dockerコンテナのおもしろい名前 Dockerコンテナを立ち上げるときに，--nameオプションで名前を指定しないと勝手に名前がつけられる． $ docker run -d dockerfile/nginx $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1f29f753eaf6 dockerfile/nginx:latest nginx 2 days ago Up 11 hours 80/tcp, 443/tcp elegant_feynma 例えば，上ではelegant_feynmaという名前がつけられている． で，これどうやってやってるのかなーと思ってソースを眺めていると，docker/pkg/namesgeneratorというパッケージが名前を生成していた． 名前の生成方法はとても単純で，49個
libswarmの現状と将来 | SOTA
libswarmの現状と将来 DockerCon14で新たに発表されたDockerによる新しいOSSであるlibswarmをざっと触ってみたので，現状何ができて，将来的にどういったことができそうになるかを簡単にまとめておく． TL;DR libswarmを使うと複数ホストやサービス（自社サーバー，DigitalOcean，Amazon EC2，Orchardなど）に存在するDockerコンテナを，１つのホストに存在しているかのように扱うことができるようになる．Dockerがホストを抽象化したのに対して，libswarmは複数ホストを抽象化する． libswarmを使ったswarmdコマンドを使って，UNIXのパイプのように複数ホストやサービスを連鎖的につなげる． デモ libswarmで何ができるのかは，DockerCon14でのデモ動画“Orchard + libswarm demo f
高速にGo言語のCLIツールをつくるcli-initというツールをつくった
高速にGo言語のCLIツールをつくるcli-initというツールをつくった tcnkms/cli-init・GitHub cli-initを使えば，Go言語コマンドラインツール作成時のお決まりパターンをテンプレートとして自動生成し，コア機能の記述に集中することができる． デモ 以下は簡単な動作例． 上のデモでは，addとlist，deleteというサブコマンドをもつtodoアプリケーションを生成している．生成結果は，tcnksm/sample-cli-initにある． 背景 Go言語で作られたコマンドラインツールを見ていると，codegangsta/cliというパッケージがよく使われている． これは，コマンドラインツールのインターフェースを定義するためのライブラリで，これを使えば，サブコマンドをもつコマンドラインツールを簡単につくることができる（Usageを自動で生成してくれたり，bash
Dockerとtmuxを連携するdmuxというツールをつくった | SOTA
Docker + tmux = dmux ! dmuxを使うと現在起動中のtmuxのwindowにおいて，新しくpaneをつくりそこでDockerコンテナを起動することができる．使い捨て，かつ高速に起動するクリーンな環境でコマンドを試したり，ツールを入れて使ってみたりなどといったことができる．また，プロセスと途中で止めて，後にそれを再開することもできる． デモ 以下は簡単な動作例． 上のデモでは，以下のことが可能であることを示している． dmux initにより新しいpaneでコンテナを起動し，そこにアタッチする dmux stopでプロセスを停止してpaneを削除する dmux startで停止したプロセスを再開して再びコンテナにアタッチする（for文が途中から再開している） dmux deleteでコンテナとpaneを削除する なぜつくったか Dockerのv0.12.0で追加されたp
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
Go言語のコードレビュー
SoundCloudが2年半ほどGo言語を利用したプロダクトを本番で運用した知見をGopherConで発表していた（“Go: Best Practices for Production Environments”）．その中で“CodeReviewCommentsというGoogleでのGo言語のコードレビューにおいてよくあるコメントをまとめたサイトが紹介されていた． 最近Go言語を書くようになり，使えそうなのでざっと抄訳してみた．“リーダブルコード”的な視点も含まれており，Go以外の言語でも使えそう． gofmtでコードの整形をすること コメントは文章で書くこと．godocがいい感じに抜き出してくれる．対象となる関数（変数）名で初めて，ピリオドで終わること // A Request represents a request to run a command. type Request str
DotenvではなくDirenvを使う
DotenvではなくDirenvを使う Dotenvは，.envファイルから環境変数を読み込むためのツール．他人には共有したくないパスワードやキーなどを.envに環境変数として記述しておき，実行時にそれを読み込むといった使い方をする．例えば自分は，vagrantからDigitalOceanを使う際に，CLIENT_IDやAPI_KEYを.envに記述してVagrantfileでそれを読み込むという使い方をしていた． ただ，Dotenvは汎用性が低い．Dotenvを有効にするには，プログラム内から明示的にDotenv.loadを呼ぶ必要がある，もしくは，dotenvでプログラムを起動する必要がある．例えば，test-kitchenのdigitaloceanドライバーを使う際には，vagrantの場合と同様にCLIENT_IDやAPI_KEYが必要になる．しかし，test-kitchenでユー
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
Vagrant1.6のDocker provider
Vagrant1.6のDocker provider Feature Preview: Docker-Based Development Environments Vagrant 1.6からDocker providerがサポートされた．つまり，VagrantでVMだけでなくコンテナも管理できるようになった． この機能はネイティブでDockerをサポートしてないOSXでも使え，この場合は裏側でProxy VM（boot2docker box）が勝手に立ち上がって，その上でコンテナが立ち上がる．つまり，以下のようになる． OSX -> (Proxy VM) -> Docker Container OSXの場合，これは今までboot2dockerを使ってやってきたのと変わらない．ただ，Docker providerを使うと，boot2dockerの立ち上げまで面倒を見てくれる． 何が嬉しいのか
Dockerコンテナ間のlink，database.ymlの書き方
Dockerコンテナ間のlink，database.ymlの書き方 DockerはLinksというコンテナ同士の連携を簡単に行う仕組みをもつ． これは，DB用のコンテナとアプリケーション用のコンテナの連携を行いたいときなどに有用になる． 例えば，1337ポートがEXPOSEされたcontainer1という名前のコンテナとの連携を行いたいとする． このとき以下のように，-link 連携したいコンテナ名:エイリアス名で新しいコンテナを起動すると， そのコンテナ内に連携したいコンテナのポート番号やIPをもった環境変数が現れる． docker run -d -link container1:alias user/sample bash root@48408a38c9b2:/# env ALIAS_PORT_5432_TCP_ADDR=172.17.0.2 ALIAS_PORT=tcp://172.
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる
Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる Packerは，Vagrantの作者であるMitchell Hashimoto氏によって開発が進められているVirtualBoxやVMWare，Amazon EC2などの仮想マシンのテンプレートの作成を行うツール．VagrantのVirtualBox用のBoxを作るveeweeに置き換わるツールとして知られている．最近のアップデートでDockerのイメージのビルドをサポートした． TL;DR Packerを使えばDockerのイメージをDockerfileを使わずビルドすることができる つまり，Dockerfileの特有な記述を使わず，今まで慣れ親しんできたChefやPuppet，Ansibleのようなプロビジョニングツールを使ってDockerのイメージをビルドできる． 参考 Dockerイメージの
serverspecとdocker-apiでDockerfileをTDD
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた．今書いているDockerfileは短くてシンプルなものばかりだが，もっと長く複雑化した時に不安になりそうだ．不安を解消するにはテストしかない．さらにテスト駆動的にDockerイメージを開発できたら素敵だ．つまり， テストを書く Dockerイメージを作成して，テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して，テストの実行 -> GREEN テストを… の流れができるとよい． ということで，RSpecを使ってTDDでDockerfileを開発するというのをやってみた，tcnksm/docker-rspec．今回実現したのは以下． Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
