たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
概要 Sliceの構造を始め、関数で呼び出した場合の挙動やappendなどsliceを操作した場合どうなるかをまとめました。 環境 golang v1.9.0 Sliceの構造 Sliceは以下のような3つの要素でなりたっています。 配列へのポインタ length capacity 図示すると以下です。 ref: Go Slices: usage and internals - go.dev 関数の引数として渡した時 Goの関数の引数は基本的に値渡しです。これはsliceも同じです。なので渡した変数のポインタは異なります。 func main() { s := []int{1, 2, 3} fmt.Printf("%p\n", &s) // 0x1040a0b0 someFunc(s) } func someFunc(s []int) { fmt.Printf("%p\n", &s) //
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 先日、社内向けサービスの新規開発でGraphQLを採用することになりました。 今回はその経緯や実装方法についていくつか参考記事を交えながら紹介していきます。 なぜGraphQLか 今回新規で開発するサービスは以下のような特徴があります。 MF KESSAIの内部は複数のサービスに分かれていて、それらをふんだんに利用する 社内向けなので直近でそこまで高負荷になる見込みはない フロントエンドとバックエンドのすり合わせにあまり時間をかけたくない(そんなに時間はない) まず複数サービスとの協調という点について、マイクロサービスをベースとしたGraphQLとGoによる開発を紹介した記事Using GraphQL with Microservices in Goにある内容をそのまま適用できそうだなというところからGraphQ
A few months ago, a really nice Go package vektah/gqlgen for GraphQL became popular. This article describes how GraphQL is implemented in "Spidey", an exemplary microservices based online store. Some parts listed below are missing, but complete source code is available on GitHub. Architecture Spidey encompasses three services that are exposed to the user through a GraphQL gateway. Communication wi
はじめ 仕事でGORMを使うことになったので、学習目的で記事を書いていくので、 アドバイスがあると大変助かりますm(_ _)m GORMについて GO言語用のORMフレームワーク。 DB周りの処理を実装する時にこのフレームワークを使うと便利。 ・公式サイト http://jinzhu.me/gorm/ ・ORMについて こちらの記事わかりやすいので、 わからない方は軽く覗いてみて下さい〜 必要なもの 1.必要最低限のSQLをかける(SELECT,CREATE,INSERT,UPDATE,DELETE,DROP) 2.Go言語を公式ドキュメントを読みながら実装できる(ポインタ、複数戻り値、型宣言など) 3.気合と根性(いらないかも) 準備
はじめに 趣味でネイティブアプリケーションのAPIをGo言語で開発中の駆け出しエンジニアです。 普段は機械学習周りのデータサイエンスを勉強しています。ということもあり、最近初めてORMという存在を知ったので、ORMは何なのか、またGo言語のORMであるGORMの最低限の操作をまとめておこうと思います。 少しでも役に立てれば幸いです。 ===2018/2/19_追記=== 最近、この記事のいいねが伸びてきているのでGo言語でRedisというKVSを触った記事を書いてみました。よろしければ、そちらもどうぞ。 【Redis】Go言語で高速呼び出しKVS【Redigo】 また、pythonのORMにもまとめてみました。 【dataset】pythonでDB処理を楽チンに!【ORM】【python】 ===2018/12/21_追記=== Gormを使ってAPI開発してみました。 フレームワークはe
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の
オプション パッケージを作る際、柔軟性を持たせるためにオプションを持たせたい時がしばしばあります。 しかしオプションは知っての通り設定しないことが少なくありません。 単にコンストラクタに並べるようでは無用な複雑さをはらむことになります。 JavaなどではOptional Parameterなどのように、デフォルト値が指定できる機能があります。 機能の厳選されたgo言語ではそのような機能はありませんが、 "Self Referential Functions Design"というテクニックがあり、 それについての記事がRob Pike氏の記事を筆頭にいくつか説明されています。 オプションと相性が非常に良いため、合わせて"Functional Option Pattern"とも呼ばれています。 Dave Cheney氏の記事を参考におおまかに説明したいと思います。 様々な解決策 あるServe
参考URL 上記リポジトリにはGOプロジェクトでのスタンダードとなるディレクトリ構成の説明が書いてある。一つずつ見ていくことにします。 /cmd 一番メインとなるディレクトリ。このディレクトリの中にアプリケーションのエントリーポイントを作る。 注意点としてはmain.goに多くのことをさせないことである。各処理は基本的に後述する/pkgなどで実装していくのでそれをインポートする形を取るべきだとある。 /internal /cmdで作ったエントリポイントで使いたいライブラリをおく。だが、このライブラリは各アプリケーション毎に書かれるものとなるので他のアプリケーションと共有するライブラリは置かない。そうゆうのをおくとすれば、後述の/pkgに置く。
はじめに 『Standard Go Project Layout』と『ヘキサゴナルアーキテクチャ』を参考にサンプルプロジェクトを作ってみました。 トランザクション周りも取り扱います。 『Standard Go Project Layout』とは ↓これです。 Standard Go Project Layout 上記の内容を日本語で簡潔にまとめてくださってる記事もありました。 Goにはディレクトリ構成のスタンダードがあるらしい。 別の記事になりますが、こちらもとても参考になりました。 Practical Go: Real world advice for writing maintainable Go programs ヘキサゴナルアーキテクチャとは ↓これです。 ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) 本家サイトへのリンクも張りたかったのですが、現
この記事は Go3 Advent Calendar 2017 の13日目の記事です。 はじめに goでwebサーバを書く際にはいろいろやり方がありますが、ざっくり分けて以下のような感じだと思います。 net/http で十分。必要に応じてルーティングに gorilla/mux 使ったりする 軽めのwebフレームワークを利用する。 gin, echo, gojiなどを使う 全部入りのrailsみたいなやつが欲しい。Revel などを使う パフォーマンスとか書きやすさとかそれぞれ違うので、各自好きなの使えばいいと思います。ちなみに自分は、一つ前のプロジェクトでは gojiを使っていて、今はechoを使っています。 個人的にはechoよかったんですが、 GoogleAppEngineで go1.8と echoのver.3以降で使おうと思うとcontextの扱いがいまいちきれいに書けない感じになり
The idiomatic way to use a SQL, or SQL-like, database in Go is through the database/sql package. It provides a lightweight interface to a row-oriented database. This website is a reference for the most common aspects of how to use it. Why is this needed? The package’s documentation tells you what everything does, but it doesn’t tell you how to use the package. Many of us find ourselves wishing for
はじめに Go 1.12 がリリースされましたね! TLS 1.3 の対応や Go Modules の改良がされたようです。 Go 1.12 is released - The Go Blog 今回は Go Modules が含まれている Go 1.12 を使用して、開発環境と本番環境の Dockerfile の作成を考えてみます。 開発環境は docker-compose、本番環境は Kubernetes などのオーケストレーションツールにデプロイすることを想定した Dockerfile の作成を考えます。 アプリケーションは、Go Modules を利用してライブラリ管理し、外部に HTTPS 通信するアプリケーションを想定して Dockerfile を作成しています。 Listen ポートは 8080 ポートです。 macOS High Sierra Version 10.13.6
こんにちは、アプリ部の門多です。 GoモジュールはGo 1.11から利用可能な公式の依存性管理ツールです。これはgo.modファイルにモジュールとバージョンを記録しておき、ビルド結果を固定するために使いますが、通常は、参照するモジュールのバージョンが公開されている必要があります。例えば、 module github.com/lufia/mod require ( github.com/lufia/backoff v1.1.0 github.com/lufia/httpclientutil v1.0.0 ) のような依存関係を持つ場合、2つのモジュールは適切な形で参照できる状態でなければいけません。手元の $GOPATH/src に存在していたとしても参照されないので、リポジトリで公開され、適切なタグが必要です。 一般的にはそれほど困りませんが、オリジナルのパッケージにバグがあって修正したけ
こんにちはpo3rinです。実装していると通信のリトライを実装したくなることがあると思います。(僕は実際に LINE BotのRate Limitに引っかかり、リトライ機構を実装する必要がありました) 今回は、通信先サーバーに過度の負荷をかけないようにするためのリトライ手法「Exponential Backoff」の実装方法について説明します。 Exponential Backoff とは 少しCloud IoT Coreよりですが、GCPのドキュメントに良い解説がありますので参考に。 https://cloud.google.com/iot/docs/how-tos/exponential-backoff リトライの際に一定間隔で処理を再試行すると、通信を受け取る側のサーバーに大きな負荷がかかる可能性があります。そこで「Exponential Backoff」という考え方が出てきます。「
はじめに Goのcontext.Context はリクエストスコープにおいてキャンセルの情報の伝播や値の受け渡しに利用するためのものですが、使う上でいくつかの注意が必要です。 Go Doc - Package contextに以下のような一文が存在します。 Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx: Contextは構造体の中に保存せずに、Contextを必要としている関数に渡してください。コンテキストは変数名ctxとして第1引数に渡すべきです。 func DoSomething(ctx
DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
この記事は The Go Blog - Using Go Modules の和訳です。 はじめに Go 1.11および1.12には、依存バージョン情報を明示的で管理しやすくする、Goの 新しい依存管理システム である モジュール の予備サポートが含まれています。このブログ記事は、モジュールを使い始めるために必要な基本的な操作を紹介するチュートリアルです。この次の記事では、他の人が使用するためのモジュールのリリース方法について説明します。 モジュールは、そのルートに go.mod ファイルを持つファイルツリーに格納された Goパッケージ の集まりです。 go.mod ファイルは、モジュールのモジュールパス(ルートディレクトリに使用されるインポートパス)とその依存関係の要件(ビルドを成功させるために必要な他のモジュール)も定義します。各依存関係の要件は、モジュールパスと特定の セマンティックバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く