記事投稿数: 8 Contribution: 1018 フォロワー数: 220

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Goでwebサーバーを作るときに考えたことをまとめておきます。 dockerコンテナで動かす場合を少し考慮してます。 フルスタックフレームワークか軽量系フレームワークか 最初に突きつけられる問題です。 フルスタックフレームワーク revel beego 軽量系フレームワーク goji negroni どんなフレームワークもそうですが、フルスタックなフレームワークならば、 その道に乗っかることで余計なことを考えずにすみます。 だけどその道から外れることをする場合に苦労が伴います。 golangの場合、Go初心者ならばフルスタックでもいいけれど、 ある程度Goに慣れてくると標準のライブラリといくつかのライブラリを使うだけで webサーバーを作る場合、十分な場合があります。 前にrevelを使っていたときは、最初はrevelの機能を使っていたけれど、途中で他のライブラリを使ったほうが楽なんじゃな

はじめに 追加のライブラリを導入することで、Apache DrillからS3上に配置したJSONに対してSQLクエリを発行できます。 S3上のファイルに直接アクセスできれば、データをマシン上に配置しなくて済むので、EBSの領域を確保しなくて済みます。 また、Apache Drillを使いたいときだけスポットインスタンスを立ち上げるといったことも簡単になり、お財布にもとても嬉しいです。 ちなみに、このページで解説していることをやってみただけです。 http://drill.apache.org/blog/2014/12/09/running-sql-queries-on-amazon-s3/ 動画も公開されていますので手順がわかりやすいです。 https://www.youtube.com/watch?v=jNUsprJNQUg セットアップ 準備 Apache Drillを実行できる環境を

id:0422 time:[2013-11-19 02:34:58] level:INFO method:POST uri:/api/v1/textdata reqtime:3.9726677258569842 foobar:LFK6XV1N id:0423 time:[2013-11-19 02:34:58] level:DEBUG method:GET uri:/api/v1/people reqtime:0.49912949125272277 foobar:DcOYrONH id:0424 time:[2013-11-19 02:34:58] level:WARN method:POST uri:/api/v1/textdata reqtime:2.930590441869852 foobar:XEZ5bQsh 設定パラメータ ちょっと長くなるので読み飛ばしてもらっても良いのですが、

Squareがメモリリークを検出するライブラリ square/leakcanary を公開したので、さっそく使ってみたらすごく便利だった話です。 A small leak will sink a great ship Piwaiが書いたLeakCanaryの記事がこちらです。 LeakCanary: Detect all memory leaks! 要約すると、 Squareではビットマップキャッシュに顧客の署名を書いていたが、端末の画面のサイズ分のメモリを確保するので、署名をするときにクラッシュすることがあり、それがOOMの大半を占めていた。 Bitmap.Configを変更したり、OOMをキャッチしてGCを走らせたりしたが、問題の解決には至らなかった。 我々は間違ったアプローチを取っていたことに気が付いた。ビットマップの大きさではなくメモリリークが根本的な原因だったのだ。 通常であれば

@j5ik2o と ElasticBenstalk(以下 eb)の話を飲み屋でしてたら、案外共有したほうが良さそうなことがあったのでそのために共有です。 前提知識のために読んできて欲しいドキュメント http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_docker_console.html http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_docker_image.html Source Bundle の作り方 Dockerfile と Dockerrun.aws.json ファイルの両方を提供する場合は、イメージに関する情報を Dockerrun.aws.json ファイルに含めないでください。E

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野 Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。 専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。 パフォーマンスエンジニアリング パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。 Performance engineering encompasses the techniques applied during a systems

すでにアナウンス済みですが，Treasure Agent(td-agent) 2.2.0を出しました td-agent 2.2.0 - Google Groups パッケージ内の更新は以下の通りです． fluentd v0.12.7 fluent-plugin-s3 v0.5.7 fluent-plugin-mongo v0.7.8 td v0.11.8.2 fluentd-ui v0.3.18 ruby 2.1.5 json 1.8.2 cool.io 1.3.0 Amazon Linux support fluentd v0.12 このバージョンから，fluentdがv0.10ではなくv0.12系が使われるようになりました．その結果，Filter/Label，forwardプラグインでのat-least-onceなどが使えるようになります． これらの機能に関しては，v0.12のリリース

nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser

DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

すごいゆるふわなタイトルですがマジでなんか怒られたので書いときます。 fluentd fails to start because "uninitialized constant Fluent::S3Output::AWS" 事の始まり ログをS3にあげたかったんです。 するとFluentdをインストールするときにAmazon LinuxだったりCentOSだったりすると大体以下みたいなChefのレシピ書くとおもいます。 ## td.repoの設置 cookbook_file '/etc/yum.repos.d/td.repo' do mode 0644 end ## Fluentdのインストール package "td-agent" do action :install end ## 設定ファイルのインストール cookbook_file '/etc/td-agent/td-agent.

Cassandraのストレージには、SizedTierCompactionと、Google LevelDBをもとにしたLeveledCompactionという二つのコンパクション戦略が存在し、ワークロードによって開発者が自由に選択できるようになっています。しかしLeveledCompactionの具体的な挙動がいまひとつ、よく分からず、選択の決め手に欠ける状態でした。 そこで、オリジナルであるLevelDBの実装を調べてみることにしました。インターネット上にLevelDBの解説は多いですが、具体的にどのようなファイルI/Oが発行されているのかはっきりしなかったので、LevelDB開発者向けドキュメントを和訳しました。結果、よく出来てるなーという事がわかったので安心してLeveledCompactionを使おうと思います。 参考 - LevelDB入門 (基本編) - from scratc

HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki

障害発生の際など、やむをえず自宅で就寝中の社長を起こさないといけないことがある。インターネット時代においても遠隔地にいる人間の意識を強制的に遮る有効な方法は一つである。電話だ。 普通の人間なら順番にただ電話すれば良いのだが、我々は電話恐怖症を患うエンジニアである。過去のトラウマから誰かに電話をかけることが不安で仕方ない。 さらにはリモートワークの環境だと、アメリカ西海岸にいる社員が日本の電話番号に電話するのは色々と敷居の高さがある。素早く簡単に社長に電話し不機嫌にすることなく即座に目覚めさせる方法が必要だ。 このような課題を、我々が対処する方法はただひとつ「自動化」である。機械に電話させればよい。行末スペースをただひとつも許せないほど繊細な心を持つ我々と比べて、機械は感情がないので不機嫌な人間に当たられても何も感じない。 今回は、感情のないロボットに社長に電話させる方法を紹介する。 Twi

golangのtestingパッケージはシンプル主義のgoならではといった、最小限の機能のみを提供しています。実際のところこれまでも(ほぼ)充分な機能を提供してきたわけですが、テスト前の初期化を明確に定義できないなど、不満もありました。 そういうわけで、1.4からこの不満を解決するtesting.MとTestMain(*testing.M)が追加されています。これがかなり最高便利です。 従来のテクニック 当然、これまでもテストの"初期化"や"お片づけ"を書きたいという要求は当然ありました。それに対しては、go testコマンドがファイルをabc...順に読みこむことを利用して、ファイル名を工夫するというちょっと裏ワザ的な手法が一般的でした。 すなわち、最初に実行したいテストが書かれたファイルは「a_test.go」にして、最後に実行したいテストを「z_test.go」とするわけです。この方

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Go言語を始めて38日たったので、これからGo言語を始めるプログラマにちょっとでもヒントになるように、どのようにGo言語を始めて、どのような手順で学んできたかまとめておきます。 筆者のバックグランド PHP歴、JavaScript歴10年~ Python 3ヶ月くらい Ruby 1日 静的言語経験ほぼ皆無(Java 3日くらい、Scala 3日くらい、Objective-C 1週間くらい、Cそもそも挫折、C# 1日) 静的言語というと、「コンパイルの一手間が面倒」だとか「環境を作るのが面倒」だとか先入観があり、ほぼ食わず嫌い状態でした。

アプリケーションを作る上でデータベースを避けて通ることはできません。その中で最もポピュラーでパワフル(かつ普及している)のはSQLでしょう。 golangでも快適にSQLを操作したい。 このエントリでやること golangでSQLを操作する方法を、「基本(databse/sql)」から、SQLクエリを自動生成する「クエリジェネレータ」、最後に「ORM」という順序で解説します。 ライブラリの特徴などをいくつか抑えていくだけであって、網羅的ではない。雰囲気だけ。 操作方法 基本(database/sql) 標準ライブラリだけを使って頑張る。基本的にSQLを手書きして、変数とのマッピングも手で当てることになる。 sql.(*DB).Exec()を使うと、SQLクエリをそのまま叩ける。プリペアドステートメントはクエリのあとにガシガシ置いていくカンジ。 db, err := sql.Open("sq