サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
junchang1031.hatenablog.com
はじめに この記事はGo2 Advent Calendar 2018 23日目の記事です。 タイトルの通りWritten A Compiler In Go (以下Compiler本)を読んで、とても面白かったので、その内容を紹介したいと思います。 compilerbook.com Writing An Interpreter In Go Compiler本の話をする前に、まずWriting An Interpretor In Go(以下Interpreter本)の説明をする必要があります。 なぜなら、Compiler本は実質Interpreter本の続編であり、そこに書かれている内容を理解していることが前提となっているためです。 interpreterbook.com Interpreter本(Compiler本でも同様、後述)では、Monkey というjavascriptやRubyっぽい
はじめに golang でのWeb開発では、RubyにおけるRailsのようなデファクトスタンダードなフレームワークがないので、 パッケージ構成に関して、開発者に大きな裁量があります。 通常、Web開発では多くのフレームワークが採用しているMVC + Service的な形のパッケージ構成にすることが 無難ではないかと思います。 しかし、標準パッケージやOSSのコードでは結構フリーダムな構成(に見える)が多く、 一時期私も「こういう感じがGoっぽいぜ!」と若干厨二的な発想に陥り、 あえてMVC + Service的な構成を取らずに開発をすることがありました。 結果、表題の import cycle not allowed に悩まされることが増え、 最近またMVC + Serviceの形に戻すようになりました。 (この戻す作業が本当に大変でした...) パッケージ構成についてはそれはそれで面白
Docker Container Imageのダイエット 先日こちらに参加してきました。非常に興味深い内容ばかりだったのですが、その中でもこのスライドの内容はとても印象に残りました。 私自身は残念ながら今の職場がオンプレミス環境(一部ハイブリッド)なこともあり、Dockerの本番運用は出来ていないのですが、 Dockerを使ったImmutable Infrastructureな環境下では、Dockerレジストリからpullする際の時間の割合がDeployの多くを占めること、 その時間を短縮することが重要であることは容易に想像がつきます。 サーバー - レジストリの物理的な距離によるレイテンシは自前でレジストリを建てるなり、 AWSではAmazon EC2 Container Registryを利用するなりで解決できる問題ですが、 Container Imageのサイズに関しては、作る際に必
Docker (Compose) の 自動再起動について ホストOSを起動したタイミングであるアプリケーションを自動で立ち上げたい、 あるいは何らかの問題で落ちた時に、自動で再起動して欲しい、というニーズは何処にでもあるかと思います。 今回は Docker Compose (以下単純にComposeと記します)に関して、コンテナの再起動や、他コンテナとの依存関係が設定されている場合に どのような挙動をとるのかを調べてみました。 なお、今回検証に使用した Compose バージョンは 1.6.0 です。 restart policy Docker 及び Compose では、 run/upの restart policy の設定することにより、 コンテナが停止した際の再起動にまつわる設置を行うことができます。 オプション 意味 no 再起動しない (デフォルト) on-failure[:ma
何をしたか Docker Swarm + Composeな構成を、VPNなどネットワーク的な制約が幾つかある環境に構築しました。 その際にいくつかハマり、学びがあったので記事にしたいと思います。 バージョンなど ホストOS cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) docker docker version Client: Version: 1.11.0 API version: 1.23 Go version: go1.5.4 Git commit: 4dc5990 Built: Wed Apr 13 18:40:36 2016 OS/Arch: linux/amd64 Server: Version: 1.11.0 API version: 1.23 Go version: go1.5.4 Git comm
ZooKeeper ZooKeeperとは、CoreOSのetcd や Hashicorpのconsul等とよく並び称される、 いわゆるCordination Serviceツールです。 詳しく知りたい方は、公式ドキュメントを、とりあえずおおまかな特徴を抑えたいという方は こちらの記事が非常によくまとまっていて わかりやすかったので、ご参照頂ければと思います。 尚、本エントリーではZooKeeperの説明は(ほとんど)行いません。 予めご了承下さい。 Service Discovery 従来、Service Discovery といえば service discovery protocol (SDP)や、DNS-SD など、 インフラ、ネットワーク周りのプロトコルやそれらが提供する機能を指すことが多かったかと思います。 昨今は Micoservices という、サービスを細かく分け、それぞ
はじめに Goの依存パッケージ管理といえば、以前から以下のような問題点が指摘されており、 総じてイマイチ、というのが通説である気がします。 外部依存ライブラリのバージョン等が指定できないためビルドの再現性が保証されない 複数prjの開発を同一環境で行う場合 GOPATH が汚染される、あるいは個別に切り替える必要があり面倒 こういった問題点を解消するため、バージョン1.6から(試験的には1.5から) Vendoring という機能が導入されました。 以前から存在しているパッケージ依存管理ツールもこの機能に絶賛対応中(あるいは対応済)といった状況のようです。 今回はこのVeondroing機能と、代表的なパッケージ管理ツールの特徴を調べてみましたので、ご紹介したいと思います。 Vendoring Vendoringというと大層な機能に聞こえますが、言ってしまえば依存ライブラリの参照先(PAT
このページを最初にブックマークしてみませんか?
『junchang1031.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く