Example of the application of layered architecture style in go.
This application is based on the post.
File structure is...
$ tree $GOPATH/src/example.com/layered-arch-in-go
| func TestFoo(t *testing.T) { | |
| tests := []struct { | |
| in string | |
| out string | |
| }{ | |
| {in: "foo", out: "FOO"}, | |
| } | |
| for _, tt := range tests { | |
| got := Foo(tt.in) | |
| if got != tt.out { |
Example of the application of layered architecture style in go.
This application is based on the post.
File structure is...
$ tree $GOPATH/src/example.com/layered-arch-in-go
place the file terminalrc into ~/.config/xfce4/terminal/terminalrc.
※本記事は2016/09/12 時点の情報をもとに構成しています
GoのWeb開発のためのフレームワークやライブラリについて、整理してみました。
整理するにあたり、いくつかのコンポーネントの分割単位を把握する必要があります。それを単体で提供しているのももあれば、複数の機能をまとめたツールセット(コンポーネント群)、全部入りのフルスタックまで幅広く存在しています。フルスタックなものは各コンポーネントを独自実装している場合が多いです。DBまでカバーしているのはbeegoくらいで、あとは利用者にお任せという仕様。Ruby on Railsのような巨大なものは存在しないと思います。
ライブラリを使わずに標準パッケージのみで構成するのも選択肢として考慮すべきでしょう。選ぶ基準はさまざまだと思いますので、ここではどのあたりが選択基準となるのかを考える材料を提供できればと思います。
| enum { | |
| KONAMI = 1, | |
| }; | |
| [BASE] = KEYMAP( | |
| M(KONAMI), // 好きなレイヤーのポジションに設定 | |
| ); | |
| const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) | |
| { |
エラーの階層化って深くなることはあまりないだろうし、ライブラリの中でWrapされることも少ないだろう。
| # boot2docker ssh | |
| # cd /Users/yoshida # mounted volume | |
| # Can write text file into the vboxsf volume | |
| docker@boot2docker:/Users/yoshida$ docker run -it --rm -v `pwd`:/tmp ruby:2.0 touch /tmp/foo && ls foo | |
| foo | |
| docker@boot2docker:/Users/yoshida$ rm ./foo | |
| # Cannot write sock file into the vboxsf volume |
| package main | |
| // 写経 from: https://github.com/youtube/vitess/blob/master/go/memcache/memcache.go | |
| // * エラーハンドリングをできるかぎり省略して実装. | |
| // * statsコマンドだけ実装 | |
| import ( | |
| "bufio" | |
| "flag" | |
| "fmt" |