ssig33.com - Docker で Go で作ったバイナリを実行するなるべく小さいコンテナを作る
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
ssig33.com - Github Flow と組織
github という公的なインフラを使うために必要なこと - アンカテ を盛大に dis っとかなきゃなという気持ちになった。 Pull Request ベースの開発 階層型組織構造 は特に対立するものではないですし、階層型がいいのかフラットがいいのかは場合場合によるでしょう。階層型でばりばりに管理するような開発チームでも ディレクターが issue を起案する 開発リーダーとディレクターがプロダクトマネージャーなどを交えてスケジュールを決定する 開発リーダーがその issue を閉じる Pull Request を作る人とそれをレビューする人を決定しスケジュールを伝達する 所定のタイミングでリリース権限を持っている人がマージボタンを押す みたいなカチカチした運用でいろいろやっていけると思いますし、これでも Github Flow というか Pull Request ベースの開発の恩恵を十
ssig33.com - DHH についての見解
DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話
ssig33.com - Heroku の利用規約をちゃんと読んだ結果意外だったこと
機械的にアプリ作りまくるのは OK 最近 CI 実行毎に Heroku にアプリ作るみたいな蛮行をしている これに関してはいずれ記事をどっかに書く bot に Heroku に大量にアプリを作らせても怒られないということが分かったので、アプリケーションの QA において革命が起きるということが最近分かってきました。 僕と同じ目的を目指して専門にやってる PaaS があったりするんだけど今一なので Heroku で蛮行を働くとよい結果になるという感じです。 Heroku の懐の広さに我々は感謝しなければならない。 あと「PaaS 屋が技術調査の為に Heroku 使ったら問答無用で BAN」とか書いてあって面白かった。 back to index of texts Site Search
ssig33.com - XSendFile でそこそこ高速にファイルを配信しつつなんかやる
ファイルをそこそこ高速に配信しつつ、裏でなんか処理をしたいとか、認証をかけたいとか、そういう事情があることはそれなりにあります。 配信状況を確認したいという程度なら fluentd でログをひろってきてなにかすればいいでしょう。 ファイルをバックエンドから非同期に拾ってきつつ状況にあわせてリダイレクトしたり配信したりする 配信状況の確認処理がえらく複雑かつ同期的にやりたい 認証をかけたい とかなんとか難しい条件があると難しいという話になります。ここで本当に高速なアプリケーションを開発したい場合 nginx に拡張を書くというのが現実的な解となってくるでしょう。そういうことをするには本物の C++ プログラマーが必要ということになってきます。さらにリソースが潤沢ならば HTTP サーバーからなにから自分で書いてもよい。 ただ大体の場合そこまでギリギリの高速さが必要ではないでしょう。そこで X
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
