わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
高速に自作パッケージを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
ブログにYoボタンを設置した
ブログにYoボタンを設置した 最近はほとんどのコミュニケーションがYoで完結している．得に日本はハイコンテキスト文化なので助かる．だいたい伝わってると思う．最近だとYoに人生を救われたひともいるくらいだ． さて，ブログを書いたあとにわざわざ「ブログ書いたので読んでください」などと言うのは，粋じゃない．さらっとYoするのが現代のスタイルだ． ということで，Yoボタンをブログに設置した． YoがインストールされたデバイスでこのYoボタンを押すと”SOTABLOG”というアカウントがYoのリストに登録される（PCとかだと手動で..）．すると，ブログ記事が更新される度に”SOTABLOG”からYoされるようになる． 仕組み といっても自分の個人アカウントが”SOTABLOG”で一人一人に手動でYoするわけではない．Yo Developers APIを利用している．やり方は以下． http://yo
高速に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
hikarie.goでLTしてきた+Hashicorpのクールなツール配布
hikarie.goでLTしてきた+Hashicorpのクールなツール配布 “複数プラットフォームにGo言語のツールを配布する” hikarie.goでLTをしてきた．hikarie.goはA Tour of GoとGo研の溝を埋めるために，@7yan00さんと@yosuke_furukawaさんによって始まったイベント．今後Go言語を始めたばかりのGopher達の良い拠り所になっていきそう． 今回自分が話したのは，以下の記事がもとになっている． “複数プラットフォームにGoアプリケーションを配布する” “HomeBrewで自作ツールを配布する” まとめると，Goはクロスコンパイルが簡単なので，バイナリでちゃんと配布して，自分のつくったツールを使ってもらうための敷居を下げていこう！という内容． この辺のやり方は，Mitchell Hashimoto氏のHashicorpのやり方を参考にした
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
Heroku Meetup #12でLTしてきた+Heroku on Docker
Heroku Meetup #12でLTしてきた+Heroku on Docker “Go Web ApplicationをHerokuにデプロイ + Heroku on Docker #herokujp” Heroku Meetup #12でLTをしてきた．MartiniをつかったGo Web ApplicationをHerokuにぶっ込んでみたという内容で，基本は“Martini(+Ginkgo)をWerckerでCIしてHerokuにデプロイ”が基になっている． せっかく最近Dockerを使っているので，HerokuとDockerを絡めた話がしたいなと思い，“building”を使ってDocker Container上にHerokuと同じ環境を作るという話を追加した．以下はその補足． Heroku on Docker Heroku on Docker | CenturyLink La
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
DockerfileのONBUILD| SOTA
DockerfileのONBUILD Docker 0.8においてONBUILDというDockerfile用のコマンドが導入された．0.8ではOSXのdocker clientが脚光を浴びたが，このONBUILDはかなり強力な機能．リリースノートはこちら．ONBUILDの公式ドキュメントはこちら． ONBUILDを使うと，次のビルドで実行するコマンドをイメージに仕込むことができるようになる．つまり，ベースイメージにONBUILDによるコマンドを仕込み，別のDockerfileでそのベースイメージを読み込みビルドした際に，そのコマンドを実行させるということが可能になる．要するに，親DockerfileのDockerfileコマンドを子Dockerfileのビルド時に実行させることができる機能． これは，アプリケーション用のイメージを作るときや，ユーザ特有の設定を組み込んだデーモン用のイメージ
Docker cheat sheet with examples
Docker cheat sheet with examples Docker Cheat Sheet is a nice documentation. It provides us Docker basic commands and system and It’s easy to understand. But there are less exaples, I reconstructed it with real examples. You should refer above document about installation. Set up Pull a base image. docker pull ubuntu It’s annoy to restore Container ID, you may forget to restore. You can set below a
rbdockというRuby/Rails/Sinatra用のDockerfileを生成するgemをつくった
rbdockというRuby/Rails/Sinatra用のDockerfileを生成するgemをつくった tcnksm/rbdock rbdock | RubyGems.org | your community gem host 実験的に作ってみた．RubyやRails，Sinatraアプリケーションを動かすためのDockerfileを生成する． これを作った理由は，今まで自分でRuby/Rails/Sinatraのコンテナを作ってみたり，Web上のRuby+Docker関連の記事などを見ていると，どれも同じようなDockerfileを書いていたため． さらに，Dockerの流れを見ていると， コンテナは必要なものだけを入れるようになりそう．つまり，RedisならRedisの，nginxならnginxの，RailsならRailsのコンテナをそれぞれ作るようになりそう． コンテナの起動やコン
Docker Share
Docker Share Vagrant Shareとngrok Vagrant Share素晴らしい．外部ネットワークのマシンから，ローカルに立てた仮想マシンへのアクセスを実現している． TL;DR ngrokを使えば，Dockerコンテナに対してVagrant Shareと同様のことができる．つまり，Dockerコンテナを外部ネットワークからアクセス可能にすることができる． 以下をやってみた． Apacheコンテナへのアクセス Railsコンテナへのアクセス 準備 OSX上で行った．dockerはboot2dockerで動かす． $ brew install boot2docker 事前にboot2dockerにport forwardingの設定をしておく． $ VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port8080,t
Vagrant + DockerでSinatraを動かす
Vagrant + DockerでSinatraを動かす tcnksm/docker-sinatra 簡単なsinatraアプリケーションをDocker上で動かしてみた． まずはsinatraアプリケーション．特別なことはなく，Procfileとconfig.ruを準備して，foremanで動かす．外部からのアクセスを有効にするため，ListenAddressを指定しておく． #Procfile web: bundle exec rackup config.ru -p 4567 -s thin -o 0.0.0.0 次に，Vagrantの設定．VagrantはDockerのprovisioningが有効な1.4を利用する．vagrantのインストールは以下のBrewfileを準備して，brew bundleする． tap phinze/homebrew-cask install brew-
公式のDocker client for OSXがリリース
公式のDocker client for OSXがリリース 2014.01.02にOSXのdocker clientがリリースされた．DockerはGoで書かれているので，OSX上で自分でビルドして使ってる人もいたが，今回は公式のバイナリリリース．さらに，Homebrewのhomebrew-binaryレポジトリにFormulaも追加され，すぐに使えるようになった． clientなので，VMもしくはリモートに立てたDocker deamonに対してローカルからコマンドが叩けるようになったということ．とりあえず，ローカルにVM立てて触ってみた． tcnksm/docker-osx まず，dokcer clientのインストール． $ brew update $ brew tap homebrew/binary $ brew install docker Vagrantfileは以下のようにす
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
BrewfileでHomebrewパッケージを管理する
BrewfileでHomebrewパッケージを管理する この記事は1分で実現できる有用な技術 Advent Calendar 2013の24日目の記事です． Brewfileを使えば，Bundlerでrubygemsを管理するようにHomebrewのパッケージを管理できる．Brewfileのあるディレクトリで $ brew bundle とすれば，Brewfileに書かれたパッケージがすべてインストールされる．これはHomebrew公式のコマンドであり，特別なインストール等は必要なく，最新版にアップデートすればすぐに使うことができる． これを使えば，dotfilesに加えて自分のbrewパッケージを管理しておくこともできるし（tcnksm/dotfiles/Brewfile），imagemagickのようにプロジェクトで必要になるパッケージをBrewfileとして共有しておくこともできる．
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rakefileに加えるべき7行