Goのバイナリサイズを削減する — そこはかとなく書くよん。 ドキュメント
あれ、 "-s"では変わってないですね…darwin環境ではでないのかななld周りのなにかだと思うのでそれはあとで追うとして、元々が26MBだったのが、5.2MBまで減りました。 圧縮に upx -9 を使った場合、かかった時間は15.70秒でそこそこ時間がかかりますね。3回ほど実行してだいたい同じぐらいでした。伸長時は0.10秒ほどでした。もちろんメモリなどにも依存しますので、この結果は鵜呑みには出来ませんが、あくまで目安として。 さらにいうと、 upx -1 で圧縮した場合は 0.78秒しかかかりません。それでいて、6.4MBと充分な圧縮効率となりました。この辺りはターゲットとする環境に合わせて決めればいいと思いますが、 -1 で十分な気もします。 まとめ¶ Goのバイナリが大きい問題は、ldflagsとUPXを使うことである程度解決できるのではないか、という話でした。 UPX知らなか
AWS Lambdaで効率的にgoバイナリを実行する — そこはかとなく書くよん。 ドキュメント
lambda_procでは、node側でJSONを整形し、goに対して一行のJSONとして渡します (Line Delimited JSON)。 go側のヘルパーライブラリがJSONを整形し、goのメイン関数に渡します。 返答は、適当なstructを返すとlambda_procのヘルパーライブラリがJSONに整形してnodeに返してくれます。 実際にベンチマークにgoのソースコードは以下となります。標準出力に書いてしまうとnode側に渡ってしまうので、ログは標準エラー出力に書く必要があります。 package main import ( "encoding/json" "log" "os" "github.com/aws/aws-sdk-go/aws" "github.com/aws/aws-sdk-go/aws/session" "github.com/aws/aws-sdk-go/se
(翻訳): Ansibleを使ったデプロイに関する一考察 — そこはかとなく書くよん。 ドキュメント
(翻訳): Ansibleを使ったデプロイに関する一考察¶ (訳注: この記事は Thoughts on deploying with Ansible の翻訳です。著者のRamon de la Fuente さんから許可を得て、翻訳・公開しています。元記事の公開は2014年6月ですが、2015年1月現在にも通用する話だと思います) 私たちのデプロイ手順を簡単にするために Ansible で roleを書きました(以前は Capistrano を使っていました)。このroleは今やかなり完璧で、本番環境に使い始めています。しかし作り始めた当初はいくつかの点で議論する必要がありました。今回みなさんとその議論を共有しようと考えたわけです。 デプロイとは？¶ 最初に "デプロイ" を定義しましょう。デプロイするとき、ユーザーはすでに "Provisioning" を終えており権限なども適切に整って
foursquare API v2 ドキュメント — foursquare-API 2 documentation
この文章は http://developer.foursquare.com/docs/ の和訳です。 著作権はforsquareにあります。forsquareには(まだ)許可を取っていません。問題があれば削除します。(If any problem, I will remove this translation.) 和訳は2010年12月31日に行われました。それ以降の変更は反映されていません。 日本語訳は正確でないことがある点に留意してください。日本語訳の不備に伴う不利益があったとしても訳者はその責を負いません。 連絡先 (Contact) shirou.faw (atat) gmail.com (please replace atat to atmark) 訳語に関する注意¶ 以下の単語はfoursquareでの固有名詞のため、あえて訳していません。 check-in mayor his
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
