サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
deeeet.com
Amazon Echo(以下Alexa)はAmazonが開発・販売している音声アシスタント+Bluetoothスマートスピーカーである.音楽を流す,今日の天気やニュースを聞く,Googleカレンダーの予定を聞く,TODOを追加する,家電を操作するなどなど… といった多くのことを全て音声を通じて実行することができる(こちらの動画がわかりやすい). 現時点(2016年8月)では音声認識は英語のみで対応地域もUSのみとなっている(例えば天気を聞くと地域を指定しない限りUSの天気が返ってくる).また連携できるサービスも日本で使えるものは少ない.ただ発表当時から「これは完全に買いだ」と思っており先日GopherCon2016で渡米したときにいきおいで購入した(自分は音声アシスタントはSiriなどのスマートフォンに搭載されているものよりも据え置き型のものに未来を感じている.実は大学院では会話ロボットの
Go1.7ではSubtestsとSub-benchmarksという機能がtestingパッケージに導入される.これを使うとテスト関数/ベンチマーク関数の中にテスト/ベンチマークを定義できるようになる.テストの場合はテストに階層を持たせることができ,ベンチマークの場合はTable Driven的にベンチマークを記述することができるようになる.さらに一連のテスト/ベンチマークに対して共通のsetupとtear-downを持たせることもできる. テストの場合はTable Driven Testsで十分なことも多く恩恵は少ないかもしれない.それよりもベンチーマークで効果を発揮することが多い. 例えば以下のように異なる設定値を使ってFooのベンチマークをとるとする.今までであればそれぞれ設定値ごとにベンチマーク関数を準備する必要があった. func BenchmarkFoo1(b *testing.
Go1.7ではgolang.org/x/net/contextがcontextパッケージとして標準パッケージに仲間入りする.そしていくつかの標準パッケージではcontextパッケージを使ったメソッド/関数も新たに登場する.contextパッケージは今後さらに重要な,Gopherは普通に扱うべき,パッケージになると考えられる.本記事ではそもそもcontextパッケージとは何か?なぜ登場したのか?なぜ重要なのか?どのように使うべきか?についてまとめる. contextパッケージが初めて紹介されたのは2014年のThe Go Blogの記事 “Go Concurrency Patterns: Context”である.この記事ではなぜGoogleがcontextパッケージを開発したのか,どのように使うのか具体的な検索タスクを例に解説されている.まだ読んだことがない人はそちらを先に読むと良い. co
GopherCon 2016でLTをした.@tenntennさんがやった通常トーク(50分)はなかなかハードルが高いがLTは初めの一歩として良いと思う.来年もDenverで再び開催されることがアナウンスされているので来年以降に発表するひとのためにどんな感じだったかを簡単に書いておく. モチベーション 発表スライドを見てもらえばわかるが特に新しい話をしたわけではない.日本のミートアップなどで話したこと,ブログに書いたことを英語にしただけにすぎない(ただ実演デモをするという挑戦はした). 「大御所たちと同じステージで喋る機会を逃すのはもったいない」(ちなみに当日のLTは僕の次がRobert Griesemer氏でその次がBrad Fitzpatrick氏だった!),「日本のGo界隈にこんなやつおるでってのを知ってもらいたい」というモチベーションで発表した.あとなんとなく自分の中でここでぶっ込ま
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ではそれらについて大きく言及されていなかった(と思う).例えばスル
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである. 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドが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とは何か? なぜ必要なのか? を解
“Systems Performance: Enterprise and the Cloud” をずっと読んでいる.この本はNetflixのBrendan Gregg氏がJoyent時代に書いた本である.その名の通りLinux(とSolaris)のシステムのパフォーマンスの本である(とにかく一つ一つが丁寧かつ深く解説されておりページをめくるごとに学びしかないのでパフォーマンスに関わるひとは今すぐ読むと良い). この本で一貫して現れてくる,通底するのが,known-knowns,known-unknownsそしてunknown-unknownsという概念である.元ネタはDonald Rumsfeld 氏の会見でのコメントだが(cf. There are known knowns),複雑なシステムのパフォーマンスの重要な原則を集約している.良い概念なので簡単に紹介する. それぞれをパフォーマン
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
GoConでは毎回エラー処理について面白い知見が得られる.Go Conference 2014 autumn においては(実際のトークではないが)居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた. Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite(やRead)のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった. そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から(僕にとっては)新たなエラー処理テクニックが紹介された. Gocon Spring 2016 実際に使ってみて/コードを読ん
2015年の振り返りとして自分が好きだったもの,影響を受けたものを雑多にまとめる.それに合わせて自分の活動についても振り返り,2016年の展望を書く(fogus: Send More Paramedicsの形式が良かったのでそれを真似ている). Blog posts read 今年読んで印象に残った,影響を受けたブログ記事.順不同. Japanese コードを書くことは無限の可能性を捨てて一つのやり方を選ぶということ 7年働いた時点での私の仕事の極意 志低く ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話 食べログの口コミに見る人間心理 -麻薬と性とトラウマと- 運用を楽にするためのアプリケーションコードを書くということ Webオペレーションエンジニアのアウトプットと開発力 我慢の期間 2015年Webサーバアーキテクチャ序論 A Million Hello Worl
この記事は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 ソフトウェアの脆弱性検出におけるファジングの活用 「ファジング」とはソフトウェアのテスト手法である.テスト対象となる
この記事はコーヒー Advent Calendar 2015の17日目の記事です. コーヒーを淹れること,豆を買いに行くこと,コーヒー器具を集めること,コーヒー関連の本を読むことが好きだ.コーヒーは趣味といっても過言でなない.自宅で美味しいコーヒーを淹れるために今までいろいろ試行錯誤してきたが,最近ある程度固まってきたのでその環境についてまとめてみる. 過去 最初に自分とコーヒーとの馴れ初めをつらつらと. 親がコーヒー好きなので実家では当たり前のように毎日コーヒーが淹れられていた.そのため家で自分でコーヒーを淹れて飲むのは当たり前のものとして育った.実家ではドリップマシンが使われていた.特にこだわりはなく出されるものをそのまま飲んでいたと思う. 自分でコーヒーを淹れるようになったのは大学生で一人暮らしを始めてから.最初は実家にあった使われていないドリッパー(確かHARIO)と近所のスーパー
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
http2 in Go 1.6; dotGo 2015 - Google スライド 2015年の5月にRFCが出たばかりのHTTP2が2016年の2月にリリース予定のGo1.6で早くも利用可能になることになっている.HTTP2の勉強も兼ねてGo言語におけるHTTP2実装を追ってみる. 以下ではまず実際にHTTP2サーバを動かしChromeで接続してみる.次に現状コードがどのように管理されているかを追う.最後に実際にコードを動かしながらHTTP2の各種機能を追う.なお参照するコードはすべて以下のバージョンを利用している(まだWIPなのでコードなどは今後変わる可能性があるので注意). HTTP2とは? HTTP/2に関してはスライドやブログ記事,Podcastなど非常に豊富な情報がインターネット上に存在する.そもそもHTTP2とは何か?なぜ必要なのか?などを理解したい場合は参考に挙げた記事など
最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた.理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ. cryptoパッケージは他の標準パッケージと同様に素晴らしい.Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる.なお本文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある. 共通鍵暗号 まずは共通鍵暗号をみる.共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である.共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる.ブロック暗号は特定の長さ単位で暗号化を行う方式であり,ストリーム暗号はデータの流れを順次処理していく方式である. Go言語にはブロック暗号としてDES(Data Encryption Standard),DESを繰り返すtriple-D
Hashicorpから2015年秋の新作が2つ登場した. Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ,Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる. バージョンは 0.1.0 を対象にしている(イニシャルインプレッションである) Ottoとは何か? 公式はVagrantの後継と表現されている.が,それはローカル開発環境の構築も担っているという意味で後継であり,自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備,デプロイまでを一手に担うツール」である.ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと. なぜOttoか? なぜVagrantで
僕はカンファレンスで喋るのが好きだ.好きだが決して得意ではない.むしろ喋るのは苦手なほうだと思う. 実際に自分でやるまではプレゼンは才能だと思っていた.大学の研究発表などで実際に自分でプレゼンをするようになり,大学の研究室で指導されまくった結果,プレゼンは技術だと認識した(もちろん才能もある).技術であるということは学ぶことができる.それに気づいてからはたくさんプレゼンに関する本を読んだ.昔は発表前に必ず何か一冊プレゼンに関する本を読みそれを積極的に取り入れるようにした. 得意でないなりに学んで,発表を繰り返した結果なんとなく毎回考えること/意識することが固まってきた.今後のために簡単にまとめておく. 聴衆は貴重な時間を割いて会場に来る オーガナイザーは貴重な時間を割いてカンファレンスを準備している 聴衆が誰かを妄想する 早めに準備する.早めに準備する.早めに準備する.早めに… Keyno
エンタープライズ向けのKubernetesサポートを行っているkismatic Inc.による“Omega, and what it means for Kubernetes: a Q&A about cluster scheduling”が非常に良いインタビュー記事だった.Google Omegaとは何か? 今までのスケジューリングと何が違うのか? 何を解決しようとしているのか? 今後クラスタのスケジューリングにはどうなっていくのか? をとてもクリアに理解することができた. 自分にとってスケジューリングは今後大事になる分野であるし,勉強していきたい分野であるのでKismaticの@asynchio氏と論文の共著者であるMalte Schwarzkopf氏に許可をもらい翻訳させてもらった. TL;DR 2013年に発表されたOmega論文の共著者であるMalte SchwarzkopfがG
Apache kafka 最近仕事でApache Kafkaの導入を進めている.Kafkaとは何か? どこで使われているのか? どのような理由で作られたのか? どのように動作するのか(特にメッセージの読み出しについて)? を簡単にまとめておく(メッセージングはまだまだ勉強中なのでおかしなところがあればツッコミをいただければ幸いです). バージョンは 0.8.2 を対象に書いている. Apache Kafkaとは? 2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムである.Kafkaはウェブサービスなどから発せられる大容量のデータ(e.g., ログやイベント)を高スループット/低レイテンシに収集/配信することを目的に開発されている.公式のトップページに掲載されているセールスポイントは以下の4つ. Fast とにかく大量のメッセージを扱うことができる Scal
1コマンドでkubernetesを立ち上げるboot2kubernetesというツールをつくった tcnksm/boot2kubernetes kubernetes 1.0がリリースされた.これから実際に試す機会も増えそうなのでDockerを使って簡単に(1コマンドで)kubernetesクラスタを立てるコマンドをつくった. デモ 以下はOSX上でシングルNodeのkubernetesクラスタを立ててkubectlでリクエストを投げるデモ. 使い方 以下のコマンドでクラスタを立ち上げる. $ boot2k8s up このコマンドで必要なDockerイメージがPullされコンテナが起動する.boot2docker上でDockerを動かしている場合ローカルからkubectlでクラスタにアクセスするにはport forwardが必要になる.その場合boot2k8sはport forwardサーバ
Go1.5はクロスコンパイルがより簡単 Cross compilation just got a whole lot better in Go 1.5 | Dave Cheney Go 1.5: Cross compilation — Medium Go言語の良さの一つにあらゆるOS/Archに対するクロスコンパイルがとても簡単に行えることが挙げられる.今まで(Go1.4以前)も十分に便利だったがGo 1.5ではさらに良くなる. 今までの問題を敢えて挙げるとターゲットとするプラットフォーム向けのビルドtool-chain準備する必要があるのが煩雑であった(cf. Go のクロスコンパイル環境構築 - Qiita) $ cd $(go env GOROOT)/src $ GOOS=${TARGET_OS} GOARCH=${TARGET_ARCH} ./make.bash --no-clea
Go言語のDependency/Vendoringは長く批判の的になってきた(cf. “0x74696d | go get considered harmful”, HN).Go1.5からは実験的にVendoringの機能が入り,サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している.なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる. Dependencyの問題 最初にGo言語におけるDependecy(依存解決)の問題についてまとめる.Go言語のDependencyで問題なのはビルドの再現性が保証できないこと.この原因はimport文にある. Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する.このimport文は2通りの
サンフランシスコでたくさんコーヒー飲んだ Google I/O 2015のためにサンフランシスコを訪れた.サンフランシスコといえば対岸のオークランドにサードウェーブの代表格となったBlue Bottle Coffeeの焙煎所があり,サードウェーブコーヒーの流れを受けた様々な有名ロースターが存在している.コーヒー狂としてはロースター巡りをせずにはいられず滞在中は時間があればロースターに行っていた.以下は行ったところまとめ. Four Barrel Coffee.Valencia St.にある.Drip Coffee(Pour-over)のために別途スタンドが準備されていて店員が豆の説明をしながら丁寧にドリップをしてくれる.COLOMBIAのla CABANA農場のものを飲んだがこれが圧倒的に美味かった(今回一番美味しかったと思う).衝撃を受けた.ここは“Four Barrel, San Fr
Google I/O 2015のためにサンフランシスコを訪れたついでにDocker社に遊びに行った.Docker社はサンフランシスコのダウンタウンを南に下った475 Brannan St.にある(ちなみに275にはGitHub社がある). 迎えてくれたのはNathan.Nathanとは昨年東京で開催されたCommunities meetup Chef, Docker, Openstack, Puppetで出会った.その後もtwitterで絡んでおり今回訪問させてもらうことになった. まず,近くにカフェ(Blue Bottleで焙煎された豆を使っていた)がありコーヒーを片手に近況などをゆっくり話した.NathanはDocker Machineをメインに担当していて,最近追加した機能や今後の予定などについて語ってくれた.今はv0.3.0に向けてRCを出して絶賛テスト中とのこと.Docker M
Golang Cross Compiler on Heroku (with Docker) Heroku unveils new CLI functionality heroku docker:release (cf. “Heroku | Introducing ‘heroku docker:release’: Build & Deploy Heroku Apps with Docker”). You can run Heroku’s Cedar environment on Docker container and test your application in local environment (Environment parity). In addition to that, you can create Slug from that docker image and deplo
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
dullgiulio/pingo Go言語でのプラグイン機構の提供方法は実装者の好みによると思う(cf. fluentd の go 実装におけるプラグイン構想).Go言語はクロスコンパイルも含めビルドは楽なのでプラグインを含めて再ビルドでも良いと思う.が,使う人がみなGo言語の環境を準備しているとも限らないし,使い始めてもらう障壁はなるべく下げたい.プラグインのバイナリだけを持ってこればすぐに使えるという機構は魅力的だと思う. Go言語によるプラグイン機構はHashicorpの一連のプロダクトやCloudFoundryのCLIなどが既に提供していてかっこいい.net/rpcを使っているのは見ていてこれを自分で1から実装するのは面倒だなと思っていた. dullgiulio/pingoを使うと実装の面倒な部分を受け持ってくれて気軽にプラグイン機構を作れる. 使い方 サンプルに従ってプラグインを
Content Addressable DockerイメージとRegistry2.0 Docker 1.6: Engine & Orchestration Updates, Registry 2.0, & Windows Client Preview | Docker Blog Docker1.6が出た.コンテナやイメージのラベリング(RancherOSの“Adding Label Support to Docker 1.6”がわかりやすい)や,Logging Driversといった新機能が追加された.今回のリリースで自分的に嬉しいのはDockerイメージがContent-addressableになったこと(#11109). 今までDocker Regitryを介したイメージのやりとりはイメージの名前とタグ(e.g., tcnksm/golang:1.2)しか使うことができなかった.タグは
コマンドラインツールについて語るときに僕の語ること YAPC::Asia Tokyo 2014 語ってきました.言いたいことはすべてスライドに詰め込んだし,参考文献もまとめておいたので興味のあるひとは参考にしてください.また,gihyo.jpさんに素晴らしいレポートを書いて頂いたのでそちらもご覧下さい. コマンドラインツールを作るときに参考にしている資料 YAPC:: Asia 2014 1日目レポート
次のページ
このページを最初にブックマークしてみませんか?
『Taichi Nakashima』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く