はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

curl -X POST \ https://{url}/v1/contents \ -H 'Authorization: Bearer {とーくん}' \ -H 'Content-Type: application/json' \ -d '{ "title" : "ブログのタイトルをどうしようかなと思っている", "tags": [ "go" ], "body":"#たいとるが決まりません" }' 訳ありのため, mutationでコンテンツ作成は諦めました。 構成 インフラ GAE/Go111 Datastore GAE Second generation(Go1.11) を使用しました。 これにより、appengineパッケージから解放されました。 datastoreも google.golang.org/appengine/datastore ではなく cloud.google.c

技術選択編 が軽バズりして嬉しかったので続編． TL;DR 便利ライブラリ & CLI つくったよ https://github.com/izumin5210/clig clig を見れば @izumin5210 が普段どうやって CLI を開発しているかがわかるよ いつも使ってる Makefile や .travis.yml もあるよ 開発用ツールの依存は gex で管理してるよ logging zap Blazing fast, structured, leveled logging のとおり，はやくて構造化データを吐けてログレベルも設定できるロガー．これは知ってる人も多いハズ． 自分が使うときはデバッグフラグを定義しておき，cobra.OnInitialize で logger を初期化して global logger にセットしている． cobra.OnInitialize(fun

答え 型チェックです。 次のようなコードが存在するとして、TがインターフェイスIを満たすことを宣言しています。 このチェックが行われるのは実行時ではなくコンパイル時です。また、割り当て先がブランク識別子_であるため、バイトコードにはこのコードに対応する部分は出力されません。 Effective Go - The Go Programming Language それはわかったけど、(*T)(nil)ってキモくない？ というか何してるの？ 型の変換です。普通であればfloat32(1)のように書けますが、前に*がつく場合はカッコで囲む必要があります。*はポインタを現すために使うので、その場合と区別するために必要だとか。 Go's Declaration Syntax - The Go Blog つまり、次の2つのコードは同じことをしています。

この記事は全部俺 Advent Calendar 2018の20日目の記事です。 Goの日付関連の処理についてまとめます。 Goの日付処理チートシート パース編(文字列 → 日付型) フォーマットが明確なとき import "time" time.Parse("20060102", "20181220") // => 2018-12-20 00:00:00 +0000 UTC time.Parse("20060102150405", "20181220123456") // => 2018-12-20 12:34:56 +0000 UTC time.Parse("2006/01/02 15:04:05.000", "2018/12/20 12:34:56.123") // => 2018-12-20 12:34:56.123 +0000 UTC time.Parse("2006-01-02

こんにちは、CI/CDツールなどを活用し、DevOps推進活動などに携わっている横山です。 本記事は、Docker Advent Calendar 2018 - Qiitaの20日目です。 はじめに Elastic Stackを使うと、簡単にDockerコンテナの監視ダッシュボードが作成できるので、今回はその紹介をしたいと思います。 きっかけとしては、「開発環境で立ち上げている複数コンテナの問題調査を楽にしたい」というのがあります。最近、開発環境に複数のコンテナを立ち上げて開発メンバーに提供していますが、開発メンバーから「重たいので環境を確認してほしい」といった声が上がってきます。その際、どのサーバのどのコンテナに問題が発生しているのか確認したいですが、その都度サーバに入って、docker statsなどのコマンドで確認するのはやや面倒です。 そこで、コンテナの監視ダッシュボードを作って、