なぜ私達は Python から Go に移行したのか - Frasco
新しい言語に移行するのは常に大きな決断です。その言語をよく知る人がチームメンバーに1人しかいない時などは特にそうです。今年の初め、我々は Stream の主要言語を Python から Go に切り替えました。この記事では、なぜ私達が Python から Go に移行しようと決断したのか、その理由を説明します。 Go を使う理由 理由1 - パフォーマンス Go は速いです! Go は極端に速い。そのパフォーマンスは Java もしくは C++ に匹敵します。私達のユースケースでは、Go は Python より30倍速いです。Go と Java を比較したベンチマークはこちらです。 理由2 - 言語パフォーマンスの問題 多くのアプリケーションにとって、プログラミング言語は、単にアプリとデータベースを繋ぐものにすぎません。言語そのもののパフォーマンスは通常あまり重要ではありません。 しかしな
5 Reasons Why We switched from Python To Go
Gophers from golang.orgPython is awesome! Especially Python 3 with async functionality. But really Go is not giving any chances to survive in enterprise world… If you got the idea of this quote, then you probably tried or just looked around Go programming language. Which is I think easiest programming language that can fit in any kind of application development. Yes! you read that right, for me Go
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
35歳定年説より怖いフルスタックエンジニアしか生き残れない未来とは - paiza times
Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術（開発）を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか？という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か？ まずStackって何だろう？、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerl、Python)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった
実用段階に入ったNoSQLをおさらい 「Cassandra」の概要と導入手順・基本設定
ビックデータとは はじめに、Cassandraが得意としているビックデータについて解説します。ビックデータという言葉が一般的に使われていますが、実際のところ何を指すのか、これまでとの違いは何かを説明します。 何に使われているのか 「ビックデータ」とは、通常の処理では処理不可能な膨大な蓄積データを指す言葉です。これまでは、処理することをあきらめていた膨大なデータを処理対象とすることで、新しい答えを見出すことを目指しています。しかも短時間で処理することで、タイムリーな活用を目指すのです。 これまでは、ばらばらに発生していたデータが、通信環境の発達でリアルタイムに収集することが可能になりました。個々のデータは小さくても、大量に集まれば膨大なデータです。せっかく集めた膨大データを活用するために時間が掛っては何もなりません。大量に集めたデータを短時間に効率よく処理して、処理結果を得られる必要がありま
Happy Elements Labs: 新MBP(Mavericks)への開発環境移行について
エンジニアの上田です。 MBAを使っていたのですが、そこからMBPへ開発環境を移行しました。 そこでいくつかつまづいたので解決した経緯をblogに記載しておきます。 同じ状況で困ってる人の参考になればと思います。 移行前PC Mac Book Air (OSはLion) 移行後PC Mac Book Pro (OSはMavericks) 購入直後の状態です 移行環境 Xcode5系最新 Homebrew JDK6 ruby 1.9.3 memcached最新 Cassandra 1.1.6 MySQL 5.5 Redis 2.6 手順 command line toolsなど他のインストールに影響するものから最初にいれていきます 1. Xcode5インストール APP Storeからダウンロードしてインストールします インストール後、一度起動してライセンスに同意しておいてください 同意して
NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る
データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。 ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか？ 身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション「間違った方向にCassandraを使ってみた」が公開されています。 NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか？ とても分かりやすくまとめられています。ご本人の承諾もいただいたので、その内容を紹介しましょう。 NoSQLを使ったときに起こる恐ろしい事例 プレゼンテーションのテーマは「NoSQLを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News