Writing An Interpreter In Goを読んだ
Thorsten Ballによる“Writing An Interpreter In Go”を読んだ． 技術界隈のブログを見ているとたまにSteve Yeggeの「If you don’t know how compilers work, then you don’t know how computers work」という言葉に出会う．その度に学生のときにコンパイラの授業を受けなかったこと後悔し，社会人になって挑戦しようとして挫折したことを思い出して悲しい気持ちになる．@rui314さんのCコンパイラをスクラッチから開発してみたを読んではかっこいいなと思いつつ僕には無理だなあと心が折れていた． どの言語を書いていてもコンパイラ（もしくはInterpreter）は切っても離せないものであり内部の動きがどうなっているかを知っておきたいという欲求はプログラマーなら誰しもあると思う（少なくとも僕に
Apache Kafkaに入門した
Apache kafka 最近仕事でApache Kafkaの導入を進めている．Kafkaとは何か? どこで使われているのか? どのような理由で作られたのか? どのように動作するのか（特にメッセージの読み出しについて）? を簡単にまとめておく（メッセージングはまだまだ勉強中なのでおかしなところがあればツッコミをいただければ幸いです）． バージョンは 0.8.2 を対象に書いている． Apache Kafkaとは? 2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムである．Kafkaはウェブサービスなどから発せられる大容量のデータ（e.g., ログやイベント）を高スループット/低レイテンシに収集/配信することを目的に開発されている．公式のトップページに掲載されているセールスポイントは以下の4つ． Fast とにかく大量のメッセージを扱うことができる Scal
Golangにおけるinterfaceをつかったテスト技法 | SOTA
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
GolangのGCを追う
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された．この変更について「ちゃんと」理解するため，アルゴリズムレベルでGoのGCについて追ってみた． まずGoのGCの現状をパフォーマンス（レイテンシ）の観点からまとめる．次に具体的なアルゴリズムについて，そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する． GoのGCの今 最初にGoのGCの最近の流れ（2016年5月まで）をまとめる． Go1.4までは単純なStop The World（STW）GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された．導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった．Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた． 以下は公開されているベンチマーク．まずはGo1.5を見る． Gophe
Go言語でファジング
この記事はGo Advent Calendar 2015の21日目の記事です． 今年もGoコミュニティーから多くのツールが登場した．その中でも異彩を放っていたのがGoogleのDynamic testing toolsチームの@dvyukov氏によるgo-fuzzである． go-fuzzはGo関数のファジングを行うツールである．このツールはとても強力で標準パッケージで100以上，golang.org/x/パッケージで40以上，その他を含めると300以上のバグを発見するという実績を残している（cf. Trophies）． 本記事ではこのgo-fuzzの紹介を行う． ファジングとは? Fuzz testing - Wikipedia, the free encyclopedia ソフトウェアの脆弱性検出におけるファジングの活用 「ファジング」とはソフトウェアのテスト手法である．テスト対象となる
Go言語でLet's EncryptのACMEを理解する
Let’s Encrypt TL;DR Let’s EncryptのベースのプロトコルであるACMEを理解する． まずACMEをベースとしたCAであるboulderをローカルで動かす．次にACMEのGo言語クライアントライブラリであるericchiang/letsencrypt（非公式）を使い実際にboulderと喋りながら証明書発行を行い，コードとともにACMEが具体的にどのようなものなのかを追う． はじめに 証明書というのは面倒なもの，少なくともカジュアルなものではない，というイメージが強い．それは有料であることや自動化しにくいなどといったことに起因している（と思う）．そのようなイメージに反して近年登場する最新の技術/プロトコルはTLSを前提にしているものが少なくない（e.g., HTTP2）． このような背景の中で登場したのがLet’s Encryptと呼ばれるCAである．Let’s
Hashicorp Ottoを読む
Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで
Herokuの'docker:release'の動き
Herokuの'docker:release'の動き Introducing ‘heroku docker:release’: Build & Deploy Heroku Apps with Docker HerokuがDockerを使ったツールを提供し始めた．一通り触ってコードもちょっと読んでみたので現時点でできること，内部の動きについてまとめる． TL;DR Herokuのデプロイ環境とおなじものをDockerでつくれる Buildpackを使わないでDockerfileからSlugを作れる 自分の好きなDockerイメージをHeroku上で動かせるようになるわけではない． 何ができるのか まず何ができるようになったのかについて簡単に書く．プラグインをインストールするとDockerコマンドが使えるようになる． $ heroku plugins:install heroku-docker
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
CoreOSクラスタにDockerコンテナをデプロイする | SOTA
CoreOSクラスタにDockerコンテナをデプロイする Docker Meetup Tokyo #4 CoreOSの概要とDockerを実際に運用しようと思ったときにDockerが抱える問題をCoreOSがどのようにそれを解決するかについて発表した．デモではTerraformを使ってDigitalOcean上にCoreOSクラスタを立てて，デモアプリケーションコンテナを動的にスケールさせる様子を実演した（ソースは全てtcnksm/docker-meetup-4-demoにある）． 雑感 簡単にMeetupの感想を書いておく． 今回はDockerそのものの発表よりも，オーケストレーションやサービスディスカバリーなどの周辺ツールやサービスの発表が多かった．ツール（もしくはDocker専用のOS）では，CoreOS，Kubernetes，RedHad Atomic host，サービスではAma
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
Dockerコンテナ接続パターン (2014年冬)
本記事はDocker Advent Calendar 2014の1日目の記事です． Dockerによるコンテナ化はリソース隔離として素晴らしい技術である．しかし，通常は1つのコンテナに全ての機能を詰め込むようなことはしない．マイクロサービス的にコンテナごとに役割を分け，それらを接続し，協調させ，全体として1つのサービスを作り上げるのが通常の使い方になっている． コンテナ同士の接続と言っても，シングルホスト内ではどうするのか，マルチホストになったときにどうするのかなど様々なパターンが考えられる．Dockerが注目された2014年だけでも，とても多くの手法や考え方が登場している． 僕の観測範囲で全てを追いきれているかは分からないが，現状見られるDockerコンテナの接続パターンを実例と共にまとめておく． なお今回利用するコードは全て以下のレポジトリをcloneして自分で試せるようになっている．
CoreOSに入門した
CoreOS is Linux for Massive Server Deployments · CoreOS CoreOS + Docker Meetup Tokyo #1に参加してCoreOSにめっちゃ感動したので，CoreOSに入門していろいろ触ってみた． まず，CoreOSの概要とそれを支える技術について説明する．次に実際にDigitalOcenan上にVagrantを使って実際にCoreOSクラスタを立てて，CoreOSで遊ぶ方法について書く． CoreOSとは何か CoreOSは，GoogleやFacebook，Twitterといった企業が実現している柔軟かつスケーラブル，耐障害性の高いインフラの構築を目的としたLinuxディストリビューションである．軽量かつ使い捨てを前提にしており，クラウドなアーキテクチャのベストプラクティスを取り入れている．CoreOSの特徴は大きく4つ挙
DockerHub公式の言語StackをCentOSに移植した
DockerHub公式の言語StackをCentOSに移植した DockerHub公式の言語Stackが出て非常に便利になった．が，これらは全てdebianベースである．やんごとなき理由でCentOSを使わざるを得ないこともあるので，公式言語Stackの一部をCentOSに移植した． とりあえず，ruby，rails，perl，node，javaを作成した．すべて公式の言語Stackをフォークして作成しているので，公式と同様の使い方ができる．また全てAutomated Buildしているので，DockerHubからインストールしてすぐに使える． 上の全てのイメージは，HerokuのStack的なイメージであるtcnksm/dockerfile-centos-buildpack-depsをベースにしている．もし他の言語のイメージを作成したい場合も，これをベースにすることができる． ただ，どう
DockerHub公式の言語Stack
DockerHub公式の言語Stack DockerHub Official Repos: Announcing Language Stacks | Docker Blog DockerHubには公式のレポジトリがある．そこにはUbuntuやCentos，MySQLやPostgres，MongoといったDockerイメージがコミュニティーベースで，つまりより汎用的に使える形で開発され集められており，ベースイメージとして簡単に使えるようになっている． 今までは，OSのディストリビューションや，Webサーバ，DBなどがメインだったが，公式として各種プログラミング言語のベースイメージも公開された．現状（2014年9月時点）では，c/c++(gcc)，clojure，golang，hylang，java，node，perl，PHP，python，rails，rubyがある． 特徴 この公式の言語s
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
好きな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
TerraformでHerokuアプリのセットアップ | SOTA
TerraformでHerokuアプリのセットアップ ちょうど新しくHerokuでアプリケーションを作り始めたので，Terraformを使ってセットアップをしてみた． Terraformとは TerraformはHashicorpの新作．インフラの構成をコード（テンプレートファイル）に落とし込んで，構築/変更することができる．インフラの構成は，複数のプロバイダやツール，例えば，AWSやConsul，DigitalOcean，Herokuなどにまたがって記述することができる． Terraformが良いのは，各設定値を変数としてサービス間で共有できるところ．例えば，Herokuでアプリケーションを立ち上げた際に自動で割り振られるホスト名を，DNSimpleの設定項目に渡してCNAMEを設定するといったことが1つのファイルに書けてしまう（Cross Provider - Terraform） 他
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
