100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す MySQLはNoSQLよりも優れています。Key-ValueストアといったNoSQLのユースケースを考えてみると、パフォーマンスや使いやすさ、安定性の点でMySQLの方が合理的です。MySQLには、オペレーションや障害に関することからレプリケーションや異なる使用パターンまでと、多くのオンラインマテリアルが用意されおり、堅実なエンジンです。こういった理由から、比較するまでもなく、MySQLは最近のNoSQLエンジンよりも優れていると言えます。 ここ最近では、NoSQLエンジンが主流になってきています。多くの開発者が、MongoDBやCassandra、Redis、HadoopといったNoSQLエンジンをアプリケーション構築の第一候補としており、それらが全て昔からのSQLエンジンを上回

JAWS-UG福岡 2016/3/21「また濃い目にAWSの話をしてみよう」でお話した資料です。

歌舞伎座.tech#9 異種プログラミング言語格闘勉強会 http://kbkz.connpass.com/event/26677/

2017/01/17追記 Herokuのプランが変更されたようです。 詳しくは、コメント欄を参照してください。 追記ここまで みなさん、bot活用していますか？ どんどん便利なスクリプトを追加し、日々の業務や生活になくなてはならない存在になっていると思います。しかしながら、botをどこで運用するかという悩ましい問題があります。少し前ならheroku一択でしたが、herokuのプランが変更され24時間完全に無料で運用することが難しくなりました。 herokuで運用する問題点 herokuは素晴らしい環境です。が、無料でbotをつくるとなると話は少し変わってきます。 30分アクセスしなければスリープ 24時間連続で動かすことができない(6時間のスリープ) hubot-heroku-keepaliveによって30分のスリープの問題はいいですが、24時間稼働できないのはどうしようもありません。まあ

私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? pythonの環境構築について "python 環境構築"でググると20万件くらいヒットしますが、割と内容が古いです。 タイトルにはデータサイエンティストと書いてありますが、データサイエンティスト以外にもanacondaはおすすめです。 2.x or 3.x? 3.xは動かないライブラリが多いので2.x推奨 >　3.xで動かないライブラリがある、くらいまで来ました。 easy_installでpipを入れて、setuptoolsも入れて、でもwheelというのもあって... > 古いです。 virtualenv 必須 > そんなこともな

Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点

先月中途で入社した卜部です。 中途入社したタイミングでちょうどよいので環境設定を見直していました。 たぶん全部捨てて書き直したのは8年ぶりくらいでした。 今回の感想を忘れないうちに書いておきます。 Emacs Emacsを使い続けている理由はauto-save-buffersです。これと同じような機能を提供しているエディタは(RubyMineとかなくもないが)とても少なく、移行先として選択肢があまりありません。Atomのautosaveはどうやら求めているものと違うようですし。 auto-save-buffersで救われたファイルは数知れず、というか保存とかいう前世紀の遺物を計算資源に下請けさせることで考えることが減るので、本当は他のエディタにも是非あるべき機能です。下にzshでpredict-onの話も書いてありますが、自分は0クリック革命をわりと実践している派だと思います。 パッケージ

米Lifehacker編集部がRaspberry Piの大ファンであることは皆さんもご存じですよね。先日、新モデル「Raspberry Pi 3」が発売されました。新しいモデルはプロセッサの刷新により高速化を図っていますが、もっと重要な改良があります。それは、Wi-FiとBluetooth機能がついにオンボードで標準搭載された点です。しかも価格はこれまでと同じ35ドルです。 Raspberry Pi 3 Raspberry Pi 2 Model B+ Model A+ SoC/CPU

2016-08-20 追記 下記の問題により共有ライブラリのリンクに失敗するケースがあります。 Template Haskell / GHCi does not respect extra-lib-dirs Nixのようにextra-lib-dirsを追加する環境下でTemplate HaskellやGHCiを起動すると、 GHCが共有ライブラリを見つけられないという問題です。 現在私はstackとdockerのintegrationで回避しています。(つまりNixは使っていないという。。。。) 問題点 stackはいいんだけれど 私はHaskellを使ったプロジェクトのビルドにはstackをよく使います。 stackを使うとStackage上のパッケージを利用してビルドされるため、パッケージ間の依存関係が壊れてビルドが失敗することが減ります。 stackについての充分な説明 stackの

本当の良書とは、内容が何らかの形で自分の血肉になり、引き出しをいくつも増やしてくれるようなものだ。 そのような良書は、得てして何十年前も昔の本に多い。何十年も読まれ続け、検証され続けてきた理論や法則は、たとえ現代では通用しなかったとしても知っておくだけの価値がある。 もちろん、相対的にヒット率は低くなるが、近年発売された本の中にも良書はある。過去から現代までの経済や科学、ビジネスのエッセンスを分かりやすく体系化したものや、世の中の新しいトレンドや最先端の科学について事細かく言及したもの。それらの良書を読むことは、インターネットに細切れに散りばめられた良質な情報をかき集めるより、ずっと効率的に学びが得られる。ここでいう学びとは、必要な知識を増やし、思考をブラッシュアップし、あるものごとにたいして考える視点をひとつ増やしてくれることだ。 そんな学びを得られる良書をここでは１０冊紹介する。 濃密

転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い

« golang で画像アップロードが簡単に出来る go-imageupload を使ってみた。 | Main | SQLite3でカジュアルにズンドコキヨシ » コマンドラインから JSON を扱うツールとしては jq が一般的ですが、例えば ls を実行した結果を JSON の Array にしたいであったり、コマンドライン引数から簡単に Object を作りたいといった場合には一旦考え込まないといけないくらい使い方が難しかったりします。そんな中でひょいと現れたのが jo です。 GitHub - jpmens/jo: JSON output from a shell JSON output from a shell https://github.com/jpmens/jo 作者である jpmens さんがなぜ jo を作るに至ったかをブログに書いています。 Jan-Piet Mens

新車発表シーズンなので、芸スポやニュー速にF1スレが立つことがあります そこで「なぜF1がこんな形をしてるのか」を中心に、F1について書こうと思います ちょっとでもF1やモタスポに興味を持ってもらえればこれ幸い できるだけ、全く知らない人でもわかりやすいように専門的な所は大雑把に書きます 間違いもあると思うんで詳しい諸兄は補足訂正お願いします 大雑把な目次 ■空力とは ■ウィング ■グラウンドエフェクト ■ボディ形状 ■パワーユニット（エンジン）ついて ■ルール、レースについて 2年前に立てたスレの改訂版です（だいぶ変わったので） ※書き溜めです ※わからないことは聞いてください。自分も答えますが、詳しい方もお願いします

気づいたら自宅でもオフィスでもすっかりWindowsユーザーになっちゃって、Win10情報にも一喜一憂してるという、完璧なる転びマカーぶりを発揮してるドリキンです。 基本的にWinである不便もほとんどなくなってしまった（というかむしろ快適に感じる）今日この頃なんですが、唯一にして最大とも言えるWindowsの弱点はいうまでもなくまともなターミナルコンソールがないことですよね? とはいえ、最近はコンソールではNodeJSだけが動けばいいやという状態だったので、コマンドプロンプトでごまかしたりはしてたんですが、流石にコマンド履歴どころかコピペすらまともに出来ないのはどうかなと一念発起してWindowsでZshくらいは使えないかなとググってみたらよさげなモノを発見！ Babun | A windows shell you will love! それがBabunというWindows用のターミナルア