Infrastructure as Dataとは何か
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data（Configuration as Data）」という考えかたを基礎としてそれを推し進めようとしている．それ以外にもKubernetesのEcosystemには（明示はされていなくても）この考え方が中心にある．Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる． （指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data（Configuration as Data）」という言葉を明確に定義した文章はない．この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や，それに反応する@bgra
Service meshとは何か
Microservicesの世界においてService meshは大きなキーワードになった．KubeCon 2017やKubeCon 2018 EUにおいても多くのセッションをService mesh（もしくはその代表格であるIstio）が占めており注目の高さも伺える．もちろんMicroservicesを進めるMercariにおいても導入を検討しており今後重要なコンポーネントの1つになると考えている．本記事ではそもそもなぜService meshという考え方が登場したのか，なぜ重要なのか? その実装としてのIstioとは何で何ができるのか? について簡単にまとめてみる． 参考文献 Service meshを一番理想的な形でサービスに使い始めその考え方を広めたのはLyftだ（と思う）．LyftはIstioのコアのコンポーネントであるEnvoyを開発しそれを用いてService meshを構築
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
GolangでAmazon EchoのSmart Home Skillを書く
Amazon Echo（以下Alexa）はAmazonが開発・販売している音声アシスタント+Bluetoothスマートスピーカーである．音楽を流す，今日の天気やニュースを聞く，Googleカレンダーの予定を聞く，TODOを追加する，家電を操作するなどなど… といった多くのことを全て音声を通じて実行することができる（こちらの動画がわかりやすい）． 現時点（2016年8月）では音声認識は英語のみで対応地域もUSのみとなっている（例えば天気を聞くと地域を指定しない限りUSの天気が返ってくる）．また連携できるサービスも日本で使えるものは少ない．ただ発表当時から「これは完全に買いだ」と思っており先日GopherCon2016で渡米したときにいきおいで購入した（自分は音声アシスタントはSiriなどのスマートフォンに搭載されているものよりも据え置き型のものに未来を感じている．実は大学院では会話ロボットの
Golangの新しいGCアルゴリズム Transaction Oriented Collector（TOC）
http://golang.org/s/gctoc Goの新しいGCのProposalが出た．まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく． GoのGCはGo1.5において単純なStop The World（STW）からConcurrent Mark & Sweepへと変更され大きな改善があった（詳しくは“GolangのGCを追う”に書いた）．先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ（最大停止時間）に重きが置かれいた．数値目標として10msが掲げられGo1.6においては大きなヒープサイズ（500GB）においてそれを達成していた． GCの評価項目はレイテンシのみではない．スループットやヒープの使用効率（断片化の対処）なども重要である．Go1.6までのGCではそれらについて大きく言及されていなかった（と思う）．例えばスル
自宅で美味いコーヒーを淹れる
この記事はコーヒー Advent Calendar 2015の17日目の記事です． コーヒーを淹れること，豆を買いに行くこと，コーヒー器具を集めること，コーヒー関連の本を読むことが好きだ．コーヒーは趣味といっても過言でなない．自宅で美味しいコーヒーを淹れるために今までいろいろ試行錯誤してきたが，最近ある程度固まってきたのでその環境についてまとめてみる． 過去 最初に自分とコーヒーとの馴れ初めをつらつらと． 親がコーヒー好きなので実家では当たり前のように毎日コーヒーが淹れられていた．そのため家で自分でコーヒーを淹れて飲むのは当たり前のものとして育った．実家ではドリップマシンが使われていた．特にこだわりはなく出されるものをそのまま飲んでいたと思う． 自分でコーヒーを淹れるようになったのは大学生で一人暮らしを始めてから．最初は実家にあった使われていないドリッパー（確かHARIO）と近所のスーパー
Apache Kafkaに入門した
Apache kafka 最近仕事でApache Kafkaの導入を進めている．Kafkaとは何か? どこで使われているのか? どのような理由で作られたのか? どのように動作するのか（特にメッセージの読み出しについて）? を簡単にまとめておく（メッセージングはまだまだ勉強中なのでおかしなところがあればツッコミをいただければ幸いです）． バージョンは 0.8.2 を対象に書いている． Apache Kafkaとは? 2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムである．Kafkaはウェブサービスなどから発せられる大容量のデータ（e.g., ログやイベント）を高スループット/低レイテンシに収集/配信することを目的に開発されている．公式のトップページに掲載されているセールスポイントは以下の4つ． Fast とにかく大量のメッセージを扱うことができる Scal
OctopressからHugoへ移行した
このブログは2年ほどOctopressを使って生成してきたが，不満が限界に達したので，Go言語で作られたHugoに移行した． Octopressへの不満は，とにかく生成が遅いこと．100記事を超えた辺から耐えられない遅さになり，最終的には約150記事の生成に40秒もかかっていた．ブログは頻繁に書くのでかなりストレスになっていた． Hugoのうりは生成速度．試しに使ったところ，明らかに速く，すぐに移行を決めた．最終的な生成時間は以下．爆速． 他に良いところを挙げると，まずとてもシンプル．Octopressと比べても圧倒的に必要なファイルは少ない．また，後発だけあって嬉しい機能もいくつかある．例えば，draftタグを記事のヘッダに書いておけば，ローカルでは生成されても，本番用の生成からは外されるなどなど． インストール Go言語で書かれているのでgo getして，デザインテーマをCloneする
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
Dockerの再起動オプション
Dockerの再起動オプション Announcing Docker 1.2.0 | Docker Blog v1.2でもいくつかの面白い機能が追加された．例えば，今まで--privilegedオプションを使うと全権限を与えてしまっていたが--cap-addや--cap-dropオプションでそれを制限できるようになったり，–deviceオプションで利用したいデバイスを指定できたり，コンテナ起動時に/etc/hostsを編集できたり…など． 中でも再起動オプションが良さげなので，実際に触ってみた．docker runを実行するときに--restartオプションに以下を指定するとコンテナの再起動の挙動を変更できる: no - 再起動しない（デフォルト） on-failure - 終了ステータスがnon-zeroの場合に再起動する on-failure:X - 終了ステータスがnon-zeroの場
YAPC::Asia 2014でコマンドラインツールについて語ってきた
YAPC::Asia 2014でコマンドラインツールについて語ってきた コマンドラインツールについて語るときに僕の語ること #yapcasia 語ってきました．言いたいことはすべてスライドに詰め込んだし，参考文献もまとめておいたので興味のあるひとは参考にしてください．また，gihyo.jpさんに素晴らしいレポートを書いて頂いたのでそちらもご覧下さい． コマンドラインツールを作るときに参考にしている資料 YAPC:: Asia 2014 1日目レポート 以下，簡単に雑感を書いておきます． YAPC初参加・初トーク 自分は去年東京に来たばかりです．YAPCの盛り上がりは毎年インターネット越しに眺めており，自分もいつか参加したいなと憧れていました． 初めは参加さえできれば良いと思っていたのですが，インターネットのすごい方々と肩を並べて話す機会が誰にでも開かれてるならぶっ込むぞ！と思いトークに応募
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リク
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
