あれ、 "-s"では変わってないですね…darwin環境ではでないのかななld周りのなにかだと思うのでそれはあとで追うとして、元々が26MBだったのが、5.2MBまで減りました。 圧縮に upx -9 を使った場合、かかった時間は15.70秒でそこそこ時間がかかりますね。3回ほど実行してだいたい同じぐらいでした。伸長時は0.10秒ほどでした。もちろんメモリなどにも依存しますので、この結果は鵜呑みには出来ませんが、あくまで目安として。 さらにいうと、 upx -1 で圧縮した場合は 0.78秒しかかかりません。それでいて、6.4MBと充分な圧縮効率となりました。この辺りはターゲットとする環境に合わせて決めればいいと思いますが、 -1 で十分な気もします。 まとめ¶ Goのバイナリが大きい問題は、ldflagsとUPXを使うことである程度解決できるのではないか、という話でした。 UPX知らなか

ソフトウェアエンジニアのための ITインフラ監視［実践］入門 技術評論社様よりご恵贈頂きました。著者のkoemuさん、ありがとうございます。 この本は本当に監視入門にふさわしく、以下のように網羅的かつ、そして何より陳腐化しない、普遍的な監視に対する心構えや考え方に対して非常によくまとまっていました。 レイヤリングと状況分析、システムの把握 監視システムをどのように設計、構築し育てていくか 監視の人員体制と業務設計 実際の障害の際の心構えと対応方法 自動化を見据えた話 監視に対する心構えや、「監視システムをどのように運用していくか、閾値をどのように決めていくか」、そして、なかなか無い観点として「監視体制の業務設計」といった話が印象深かったです。 モデルケースとして、Linuxサーバー上のApache、MySQL、Tomcatの監視などが取り上げられており、実際に Mackerel!!!を使っ

暗号化すれば終わりじゃない 暗号鍵の管理も仕様に入れよ 間違った暗号実装はむしろ危険 「暗号」は、ITを安全に利用する上で必要不可欠の技術です。例えば、PCやスマートデバイスのWebブラウザーからインターネットバンクやオンラインショップを利用する際は、アクセスプロトコルにHTTPではなくHTTPS（SSL/TLSプロトコル）が使われるのが一般的になっています。HTTPSは暗号技術を用いて、通信内容を盗聴や改ざんから保護すると同時に、アクセス先Webサイトの認証を行います。 最近では、GoogleやFacebook、Twitterといった大手のB2Cサービスでも、常にHTTPSが利用されます。皆さんにとって、暗号技術は身近なものになっているといえるでしょう。しかし、暗号技術をきっちり理解して使いこなすのは、結構難しいことなのです。 重要なデータをデータベースやファイルシステムに保管する場合、

生成・使用分離の原則*1オブジェクトは、他のオブジェクトの生成か、使用のいずれかのみを行い、双方を行ってはならない。どういうこと？設計の簡素化のため、オブジェクトの利用、オブジェクトの生成・管理を混ぜて考えてはならない。どうして？この規則に従えば、作業分担が明確化され、結合度が低下する。オブジェクトの使用は概念レベルを取り扱う。オブジェクトの生成は具象レベルを取り扱う。これらレベルの違うものを混ぜて設計すべきではない。これらを分けて考えることで、それぞれに集中できる。特に概念レベルの洗い出しの時、つまりオブジェクトの責任を考えている時、「生成方法や管理方法を後から考えればいい」と思っていられることは、設計を非常にやりやすくする。それに、概念レベルのオブジェクトが出そろってからじゃないと、生成のビジネスルールはわからない。この原則の世界「使用するオブジェクト」（クライアント）は実際に使用する

Other questions about DI Dependency Injection breaks Encapsulation Comments on Disco with Design Patterns: A Fresh Look at Dependency Injection Criticisms by so-called "experts" A simplified definition Conclusion References Amendment History Comments Introduction Way back in 2004 I made the following observation: There are two ways in which an idea, principle or rule can be implemented - indiscrim