日本のデータベース系のコミュニティ、なぜイマイチ盛り上がらないのか - kuenishi's blog
11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。 現実にアカデミックで起きていること WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベ
7 Common mistakes in Go and when to avoid them – Gotham Go | spf13
Not a generic list of programming mistakes, these are the lessons I wish I learned earlier while developing Go. I’ve spent the past two years developing some of the most popular libraries and applications written in Go. I’ve also made a lot of mistakes along the way. Recognizing that “The only real mistake is the one from which we learn nothing. -John Powell”, I would like to share with you the mi
Goを使い複雑性を回避する | POSTD
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます
そろそろGoについて一言いっておくか - kuenishi's blog
昨日、GoCon（ごうこん）なるイベントに参加してきた。以下に続く話は5割以上がフィクションなので虚実織り混ざっている様を楽しみながらお読みいただけたらと思う。 最初に発表されたニュースを聞いたときは、Goはよい車輪のよい再発明で、結局GoogleはC++やJavaを使い続けるだろうし、世間はGoogle独自言語としてみなすのだろうなという予感はあったし、2010年だから2011年ころはそういう見方をされていたように記憶されている。私もそういうものだと思っていたし、特に関心を持つこともしなかった。いま思えば正常性バイアスだったのだろう。 実際に昨日のカンファレンスで一番興味深かったのは鵜飼さんによるGoの解説だった。比較対象がC++, Python, Javaだったことが最も印象的で、普段からErlangやOCamlといった関数型言語に接していた身として新鮮だった。話を聞くうちにGoogl
kv2jsonというコマンドラインでJSONを組み立てるためのツール作った | おそらくはそれさえも平凡な日々
https://github.com/Songmu/App-KV2JSON 近年Web APIはJSONで投げるものも多いわけですが、コマンドラインとかシェルスクリプトからcurlでそれを叩こうとした時に手でJSONを書いたりするのが面倒臭かったりするのでkv2jsonというユーティリリティを書いた。 % kv2json hoge=fuga {"hoge":"fuga"} と言った感じです。多少複雑な使いかたもできるので、そのあたりはSYNOPSISを見てもらえればと思います。 導入は、 % cpanm App::KV2JSON でも入りますが、https://raw.githubusercontent.com/Songmu/App-KV2JSON/master/kv2jsonとかにfatpackした一枚岩のやつがあるのでそれを直接使うのも良いと思います。 パイプ経由でも値を渡せるので %
ISUCON4ダメでした | おそらくはそれさえも平凡な日々
まずは、ISUCON4の主催・協賛・運営の皆様、素晴らしいイベントをありがとうございました。 ISUCON4ダメでした。こんな悔しく終わると思ってなかった。一応予選通過してそれなりに手応えがあったので、本戦もそれなりに健闘して戦えるのではないかと思ってたけど、その辺完全に甘くて、本戦に出られたちょっとした喜びも吹き飛びました。競技に溺れて本来のサービス運用者視点が抜け落ちていた事に反省しきりです。 何をやったかは、motemenのエントリに書いてありますが、最初にRedisを1台に固めてログの書き込みをRedisのリストにしたのがそれなりに効いたくらいですかね。多分最初に8000点超えをして暫定トップを取ったと思います。ここがクライマックスでここから全く改善しなかった。 Redisはレプリケーション構成にしようかとか@y_uukiに言われたし、他のチームのレポートを見てもそうしていたところ
MackerelにGitHubアカウントでサインインできるようになりました・ほか - Mackerel ブログ #mackerelio
Mackerelは、GitHub アカウントによるサインインに対応いたしました。MackerelにGitHubのOAuth認証を与えることで、GitHubのユーザ情報を利用してMackerelにサインアップおよびサインインができるようになりました。これまでよりさらに簡単にMackerelをご利用になれます。 Mackerelアカウントをお持ちでない方 サインアップページより、「GitHubでサインアップ」を選んで下さい。 GitHubに遷移後、「Authorize application」するとメールアドレス入力画面に遷移します。 GitHubに登録しているメールアドレスがフィルインされていますので、「サインアップ」をクリックすればGitHubアカウントでのサインアップは完了です（アラート通知メールなど送信のため、メールアドレスはご入力いただく必要があります）。 すでにMackerelアカ
ZeroToDocker
Motivation:The NetflixOSS platform and related ecosystem services are extensive. While we make every attempt to document each project, being able to quickly evaluate NetflixOSS is a large challenge due to the breadth for most users. This becomes a very large challenge to anyone trying to understand individual parts of the platform. Another part of the challenge relates to how NetflixOSS was design
Simple Monitoring for Docker (Part I)
Migrating from VMs to Docker containers is quite easy except for the monitoring part. A straightforward approach, running a data collecting agent (such as Zabbix agent), is definitely a not a good solution as it goes against Docker’s philosophy of having one clearly identified task in each container and also because it will require to use custom images. Starting with Gathering LXC and Docker Conta
AWSのデータセンターの中身を、設計総責任者が話した
AWSのデータセンターの中身を、設計総責任者が話した：「ここまで話していいの？」（1/2 ページ） Amazon Web Services（AWS）のバイスプレジデント兼ディスティングイッシュド・エンジニア、ジェームズ・ハミルトン氏は、AWSが11月11～14日に開催した「AWS re:Invent 2014」で、データセンターの構成、サーバーやスイッチの自社設計、SR-IOVなどについて語った。 [2014/11/21訂正]記事の初出時に、ハミルトン氏がAZ間の距離を「数キロメートル」と言ったと記述しましたが、数十キロメートルである可能性もあります。ハミルトン氏はAZ間が「multiple kilometers」であると表現しています。後出のハミルトン氏の議論では、例えばロサンゼルスとニューヨークの間の伝送遅延は74ミリ秒だが、これを1、2ミリ秒に抑えるためにAZ間は近くなくてはならない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Efficient data transfer through zero copy