はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? まずはこちらの動画をご覧ください。 こちらは娘が２歳半の頃に児童館で撮影したものです。 かわいい・・・ 生後1000日近くともなると、子どもは自分で絵本を読むようになります。 並行してひらがな覚え始めるので、親としてはガンガン絵本を読んでほしいのですが、実際には挿絵に合わせて適当な話を創をして遊んだり、まじめにひらがなを音読し始めたかと思えば数ページも読まないうちに次の絵本を引っ張り出してきては読んで、飽きてまた違う絵本に手を出すだけで、一向にちゃんと読んでくれません。 ちゃんと読まない原因として、もしかして絵本に動きがないから飽きてし

はじめに Go言語で作るプログラムはほとんどの場合、そのままでも十分高速に稼働しますが、場合によってはキャッシュを使用して高速化を図る場合があります。 Goにはgocacheという強力なローカルキャッシュパッケージが存在しますが、gocacheだと下記の点でまれに問題が発生することがあります。 ホスト・プログラム・サービスなどをまたいでキャッシュを参照させられない プログラムが終了するとキャッシュが消える これらを回避するため、ローカルで済むキャッシュについてはgocacheでキャッシュしておき、それ以外のキャッシュはmemcacheやredisなどに載せる、といった戦略を採ることが多いと思いますので、memcacheパッケージについて比較してみます。 Goのmemcacheパッケージ Goのmemcacheパッケージは何があるのか、まずgithubで登録されているリポジトリを検索したとこ

最近GoでWEBアプリケーションを運用するにあたってどこに気をつけているかをメモしました。 WEBサーバ GoでWEBアプリケーションを作る場合、net/httpパッケージを使うことになります。 Go製のWEBフレームワークを使用する場合であっても、HTTPリクエストの処理部分はnet/httpを使用していると思います。 GoでWEBアプリケーションを書いた場合、すべてのリクエストをGoで受けるというケースはあまり想定されず、殆どの場合はリバースプロキシとしてWEBサーバを配置し、そのバックエンドにアプリケーションサーバを配置する構成になると思います。 このような構成を取る理由として、下記のようなものが挙げられると思います。 ロギング ヘッダの柔軟な扱い 静的ページのリクエスト処理 URLのパースやrewrite処理など キャッシュの利用など WEBサーバを利用する場合、多くの場合でngi

package main import ( "github.com/zenazn/goji" "github.com/zenazn/goji/web" "github.com/zenazn/goji/web/middleware" _ "github.com/go-sql-driver/mysql" "gopkg.in/yaml.v2" "io/ioutil" "os" ) var db gorm.DB // main()はルーティング情報だけ記述する func main() { user := web.New() goji.Handle("/user/*", user) user.Use(middleware.SubRouter) user.Get("/index", UserIndex) user.Get("/new", UserNew) user.Post("/new", UserC

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

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

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

この記事はMongoDB Advent Calender2013の21日目です。 MongoDBで手軽にMapReduceする方法について書かせていただきます。 #MongoDBでMapReduce 世間的にMongoでM/Rするのは情弱、世間知らず、自殺行為などと色々disられてはおりますが、やはりスキーマレスで好きなデータを突っ込んでおいて、あとで集計をかけるというお手軽さからいうとMongoのM/Rも充分選択肢としてありだと思います。 #前準備 実際に自分が今やっているプロジェクトのうちの１つに、apacheのアクセスログをfluentd経由でMongoに書き出しているものがあります。 ちなみにデフォルトのfluentdのプラグインだとpathが１フィールドに登録されてM/Rしずらいので、クエリストリングスをパースして１クエリを１フィールドに入れるout_exec_filterを自作

この記事はMongoDB Advent Calendar 2013の6日目です。 mongoidについてはnaru0gaさんの大変わかりやすい説明がありましたので、今回はmongoidのまともじゃない使い方をご紹介させていただきたいと思います。 mongoidについて ruby用のODMマッパーです。くわしくはこちらを御覧ください。 MySQLと共存させる リレーションが必要なモデル、飛んだら困るデータの格納はMySQLで、それ以外はMongoDBを使いたい、という場合にリレーショナルデータベースと共存させる方法です。 MongoDBのAdvent Calenderに何書いてんだと罵られそうですが、MongoDBだけで生きていくにはガッツの足りない方（自分含め）向けにMySQLと共存させる方法を紹介します。 まず、プロジェクト作成時、普通にMySQLをドライバとして指定します。