タグ

ブックマーク / deeeet.com (33)

  • SREとしてMercariに入社した | SOTA

    1月16日よりMercariにてSRE/BSE(Backend System Engineer)として働いてる. これまではとある会社で社内向けのPaaSエンジニアとして働いてきた(ref. PaaSエンジニアになった).PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた.Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ,かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった. その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない(だからこそScalabilityを実現できるのだが).よりサービスに近い部分,サービスの成長に直結す

  • GolangでAPI Clientを実装する

    特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ(SDKと呼ばれることも多いが記事ではClientと呼ぶ)を使うことが多いと思う.広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている.例えば以下のようなものが挙げられる. https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う(まともなものなら互換性などをちゃんと考慮してくれるはずなので).一方で小さなサービ

  • Golangにおけるinterfaceをつかったテスト技法 | SOTA

    最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく.まずはinterfaceを使ったテストの基について説明し次に自分が実践している簡単なテクニックをいくつか紹介する. なおGolangのテストの基については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ! 前提 自分はテストフレームワークや外部ツールは全く使わない.標準のtestingパッケージのみを使う.https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language(DSL)を導入することと変わらない.最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ

  • Go1.7のcontextパッケージ

    Go1.7ではgolang.org/x/net/contextがcontextパッケージとして標準パッケージに仲間入りする.そしていくつかの標準パッケージではcontextパッケージを使ったメソッド/関数も新たに登場する.contextパッケージは今後さらに重要な,Gopherは普通に扱うべき,パッケージになると考えられる.記事ではそもそもcontextパッケージとは何か?なぜ登場したのか?なぜ重要なのか?どのように使うべきか?についてまとめる. contextパッケージが初めて紹介されたのは2014年のThe Go Blogの記事 “Go Concurrency Patterns: Context”である.この記事ではなぜGoogleがcontextパッケージを開発したのか,どのように使うのか具体的な検索タスクを例に解説されている.まだ読んだことがない人はそちらを先に読むと良い. co

  • Golangのエラー処理とpkg/errors

    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 実際に使ってみて/コードを読ん

  • Go言語と暗号技術(AESからTLS)

    最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた.理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ. cryptoパッケージは他の標準パッケージと同様に素晴らしい.Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる.なお文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある. 共通鍵暗号 まずは共通鍵暗号をみる.共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である.共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる.ブロック暗号は特定の長さ単位で暗号化を行う方式であり,ストリーム暗号はデータの流れを順次処理していく方式である. Go言語にはブロック暗号としてDES(Data Encryption Standard),DESを繰り返すtriple-D

  • 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言語とHTTP2

    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とは何か?なぜ必要なのか?などを理解したい場合は参考に挙げた記事など

  • Go言語のDependency/Vendoringの問題と今後.gbあるいはGo1.5

    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通りの

  • Go言語のCLIツールのpanicをラップしてクラッシュレポートをつくる

    mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない.普通はちゃんとテストをしてそもそもpanicが発生しないようにする(もしくはトップレベルでrecoverする).しかし,クロスコンパイルして様々な環境に配布することを,もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると,すべてを作者の想像力の範疇のテストでカバーし,panicをゼロにできるとは限らない. panicが発生した場合,ユーザからすると何が起こったか分からない(Go言語を使ったことがあるユーザなら「あの表示」を見て,panicが起こったことがわかるかもしれない).適切なエラーメッセージを表示できると良い.開発者からすると,そのpanicの詳しい発生状況を基に修正を行い,新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい. mitchellh/panicw

  • 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して自分で試せるようになっている.

  • PaaSエンジニアになった

    今まではモバイルアプリ向けのAPIの開発に携わりつつ,CIやデプロイ自動化といったDeveloper Productivity的なことをメインとしていたが,PaaSチームにジョインした.後に自分がどういうことを考えて舵を取ったかを見返すために簡単に今思っていることを綴ってみる. PaaSという選択 “実践Heroku入門”の’はじめに’にしつこく書かれているようにPaaSの大きな目標は「アプリケーション開発者の効率を最大化」することにある.もともとDeveloper Productivity的なことが好きでいろいろやってきたが,その究極的な形がPaaSではないかと思う. PaaSといってもプライベートPaaSだが,素晴らしいアイディアがあり,それを簡単にリリースでき,かつスケールもできる,そういうプラットフォームを社内にもっているのは大きな強みになると思う.どうすれば開発者にとって使いやす

  • CI-as-a-ServiceでGo言語プロジェクトの最新ビルドを継続的に提供する

    CI-as-a-ServiceでGo言語プロジェクトの最新ビルドを継続的に提供する Go言語で作成したツールのリリース方法について,最近実践していることを書く. リリースは,ローカルから人手で行っている.具体的には,自分のローカル環境でクロスコンパイルし,セマンティック バージョニングによるタグをつけ,CHANGELOG.mdを丁寧に書いた上でリリースをしている.クロスコンパイルにはmitchellh/gox,リリースには自分で作成したtcnksm/ghrを使っている(ghrについては,“高速に自作パッケージをGithubにリリースするghrというツールをつくった”を参考). その一方で,開発中の最新のビルドも提供するようにしている.例えば,こんな感じで,Pre-Releaseとして提供している.Go言語での開発なので,go getしてくださいと言える.しかし,環境によってビルドが失敗する

  • Werckerの仕組み,独自のboxとstepのつくりかた

    Werckerの仕組み,独自のboxとstepのつくりかた WerckerはTravisCIやDrone.ioのようなCI-as-a-Serviceのひとつ.GitHubへのコードのPushをフックしてアプリケーションのテスト,ビルド,デプロイを行うことができる. Werckerは,TravisCIのように,レポジトリのルートにwercker.ymlを準備し,そこに記述された実行環境と実行コマンドをもとにテスト/ビルドを走らせる. Werckerには,その実行環境をbox,実行コマンド(の集合)をstepとして自作し,あらかじめWercker Directoryに登録しておくことで,様々なテストからそれらを呼び出して使うという仕組みがある.実際,Werkcerで標準とされているboxやstepも同様の仕組みで作成されている(wercker · GitHub). 今回,WerkcerでのGo

    kyokomi
    kyokomi 2014/10/16
    めちゃくちゃわかりやすかった
  • "Microservices"を読んだ

    James Lewis氏とMartin Fowler氏による“Microservices”を読んだ.以前ざっと目を通したが,最近よく耳にするようになったのでちゃんと読んだ.以下はそのメモ. 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており,軽量な機構(e.g., HTTP API)を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア

  • YAPC::Asia 2014でコマンドラインツールについて語ってきた

    YAPC::Asia 2014でコマンドラインツールについて語ってきた コマンドラインツールについて語るときに僕の語ること #yapcasia 語ってきました.言いたいことはすべてスライドに詰め込んだし,参考文献もまとめておいたので興味のあるひとは参考にしてください.また,gihyo.jpさんに素晴らしいレポートを書いて頂いたのでそちらもご覧下さい. コマンドラインツールを作るときに参考にしている資料 YAPC:: Asia 2014 1日目レポート 以下,簡単に雑感を書いておきます. YAPC初参加・初トーク 自分は去年東京に来たばかりです.YAPCの盛り上がりは毎年インターネット越しに眺めており,自分もいつか参加したいなと憧れていました. 初めは参加さえできれば良いと思っていたのですが,インターネットのすごい方々と肩を並べて話す機会が誰にでも開かれてるならぶっ込むぞ!と思いトークに応募

    kyokomi
    kyokomi 2014/09/01
    「CLIツールにもUI/UXが存在する」が衝撃的な一言でした。
  • コマンドラインツールを作るときに参考にしている資料 | SOTA

    コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた. 今年のYAPCで,そのコマンドラインツールをつくるときにどういうことを意識して作っているのか?どのような流れで開発しているのか?といったことを語る機会をもらえた. 具体的な内容については,是非トークを聴きに来てもらうとして, スライドをつくるにあったって過去に読んだ資料や,よく参考にしている記事を集め直したので,その一部を参考資料としてまとめておく. UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた.古いが全然色あせてない. コマンドラインツールの作り方を書いたではないが,これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う.何度も読んで考え方を染み付かせた. 小さい

  • 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