golangで、例えばGithubのAPIを叩くような、特定のAPIにアクセスするロジックを書いた時、何も考えずにテストを書くと、テストを実行する際にもそのまま外部のAPIにアクセスしてしまう。この場合、色んなパターンのテストを書きづらい、依存している外部サービスが落ちたらテストも一緒に落ちるなどの問題が起こる。 このような問題から、統合テストではなくユニットテストのときは手元のみで完結して、外部サービスに依存しない状況でテストを書きたくなることがある。そこで今回は外部にアクセスするロジックを、手元で完結させた状態でテストする方法を試したので、その方法について書いてみる。 テストしたいコード 例えば以下のようなコード。Githubの https://github.com/shibayu36/shibayu36 の最新のリリースタグを取得し、そのリリースタグ名を出力する。これはGithubの

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

ブログryuzeeによるブログ記事。不定期更新Homeブログ【資料公開】スクラムプロジェクト開始のベストプラクティス みなさんこんにちは。@ryuzeeです。 2018年1月11日から13日まで開催されているRegional Scrum Gathering Tokyo 2018で登壇いたしましたので、資料を公開します。 今回は、実際にスプリント1を開始する前にどのような準備をしておけばよいかがテーマです。 スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。またスプリント中の次以降のスプリントの準備としてプロダクトバックログのリファインメントを実施します。 つまりプロダクトバックとスクラムチームが存在するところがスタ

Research indicates that carbon dioxide removal plans will not be enough to meet Paris treaty goals

Mackerel で「ECS クラスタ」のメトリクスを取得する mackerel-plugin-aws-ecs を試した．ちなみに mackerel-plugin-aws-ecs を使うためには，去年11月にリリースされた「mkr プラグインインストーラー機能」も使う必要があり，この機能もまだキャッチアップできていなかったので合わせて試してみた． mkr プラグインインストーラー機能 最初に「mkr プラグインインストーラー機能」をザッと紹介しておこうと思う．「mkr プラグインインストーラー機能」によって大きく変更されたことは，今までプラグインを一元管理していた mackerelio/mackerel-agent-plugins リポジトリに，今後新規のプラグインが入らなくなったことだと思う．今後は自分自身の GitHub リポジトリにプラグインを追加し，そのプラグインを「プラグインレジ

HRzine Day（エイチアールジン・デイ）は、人が活き会社が成長する人事のWebマガジン「HRzine」が主催するイベントです。毎回、人事の重要課題を1つテーマに設定し、識者やエキスパードが持つ知見・経験を、参加者のみなさんと共有しています。

Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ

今更ながら、Real World HTTP を読んでみたので、 学習効率という視点で感想を書いてみようと思う。 www.oreilly.co.jp 対象となる読者が広い スラスラ読める 好きなところから読める 一通り目を通すことを推奨 Go言語は関係ない キャッシュの仕様 HTTP2が載っている まとめ その他 レビューをした pospomeという単語が載っている いまさら読んだ理由 対象となる読者が広いこの書籍のテーマは HTTP なので、対象となる読者はかなり多いはず。 さらに、書籍でも言及されているが、 HTTP のようなプロトコルは陳腐化しづらい知識なので、 一度身につけるとずっと役に立つ。 サーバサイドエンジニアに限らず、 アプリエンジニア、 WebFE エンジニア、 HTTP に触れるエンジニアであれば、目を通しておいた方がいい。 特に HTTP Header に指定する属性と

当たり前のことかもしれませんが、ふと忘れがちになってしまうので自戒も込めて記します。 TL;DR 技術の仕組みだけを勉強するのではなく、その技術が解決しようとしている「課題」も意識すると身につきやすい 身についた技術と身につかない技術がある ふと思い返してみると、気づいたことがありました。日頃勉強をしているのに、身についた技術と身につかない技術があるのです。 今回は、「これはなぜだろう？」と疑問に思ったのが発端です。単純に勉強時間と相関があるわけではなさそうです。 身についた技術に対して何をしたか どんなことをしたらその技術が身についたのかを、ざっくり振り返ってみます。 身についた 自作ライブラリを作った 業務で使用した 身につかない 書籍をパラパラと読んだ 仕組みだけを勉強した 惰性で勉強会に参加した 身についた技術には何か共通項があるのでしょうか。 共通項は？ 軽く共通項を考えてみると

社内専用環境とかで“性善説”に基いて運用できる、短縮URLを作ってみた。 github.com 詳細は README に書いているが、 シンプルなUI 命名もできるし、ランダムな文字列もいける 既存の短縮URLの上書き(性善説だし :) DynamoDBがバックエンドで安い Dockerベース ちなみに、イントラネットに置けるようにしたかったので、サーバーレスにはしてない。 モチベーション Google社の勉強会とかにいくと、貼ってあるポスターに http://go/hoge みたいなリンクがあって(あるよね？)そういう“社内専用短縮URL”を実現したかった。 また、Slackのトピックには文字数制限があるが、どうしても制限を超える長いURLへのリンクを貼りたかったという事情があった。かといって、ここに貼りたかったリンクは社内専用の URL なので bit.ly とかの短縮 URL サービ