AWS Solutions Architect ブログ
A1:コンテナ内で複数のプロセスが動く様なデザインは、12-factor Appとしては良くないので避けるのがベストです。また、古典的なWEB+APの構成を取る必要があるかどうかというところから検討すると良いです。Dockerを使ったシステムではAPサーバのみの構成もよく見られます。 Q2:イメージは作成したOSに依存（そのOS上でしか動かないなど）しますか？ A2:イメージがどのOS(プラットフォーム)をベースにしているかは注意が必要です。元々DockerはLinuxのイメージのみで、Docker for Mac/WindowsではLinux Kernelをエミュレートする様な形を取って別OS上でもLinuxイメージが実行可能となっています。Linux Kernelのみをホストと共有する形になるので、ディストリビューションという意味でのOS(Ubuntu, CentOS, Amazon
『Apache Igniteとのインメモリーコンピューティング』
初めに 全世界に無数に散らばったサービスやデバイスから生み出されるデータ量の急激な増大に伴って、ストリーム処理とインメモリーコンピューティングは避けられない近未来であり、重要なデータ処理パラダイムでもあると言える。ストリーム処理とインメモリーコンピューティングの融合により、多様なデータから新しい価値を発見し、新たなビジネスチャンスを引き出した利益拡大が可能である。なぜなら、データの価値はデータの新しさ(freshness)と強い相関関係を持つ。 インメモリーコンピューティングは、Hadoopのようにスポットライトを浴びるテクノロジーではないが、以前数回も期待の技術としてハイライトがされることがあり、メモリーの大容量化と低コスト化が進められる今こそ、その期待度が高まっている。 低価格DRAMは、ディスクより速い。さらに、DRAMのI/Oは一般的にフラッシュメモリーのI/Oより1000x倍速い
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
英語で書いてあるコミットログの動詞が現在形のわけ - その手の平は尻もつかめるさ
僕はgit とかのコミットログを英語で書く時、動詞を過去形にする癖があったんですが、*1 先日、@saturday06 さんから「コミットログの先頭に動詞を持ってくるときは現在形にするのが一般的っぽいよ！」*2 という事を言われたので、最近は過去形ではなく現在形で書くように心がけています。 郷に入っては郷に従え、というかスタンダードに則っておいて悪いことはそんなに無いはずなので。 ただ、「なぜコミットログは現在形で書かれるのか」という疑問が残ったので、 (コミットログに書かれている内容はすべて過去の事のはずなのに…) 知り合いに尋ねてみました。 彼いわく、 「HAHA！ コミットログは『過去の事』を書くものでしょ？ そんなのみんな知ってる当たり前の事だからわざわざ過去形にしないで現在形で書くわけヨ！」 との事だったので、なるほど合点がいきました。 これからは特別な理由がない限り、コミットロ
2016年のJ1リーグ全試合データを機械学習し、2017年の展望を予測する（１） | データによってサッカーはもっと輝く | Football LAB
富士ゼロックススーパーカップが終わり、いよいよ2/25から明治安田生命J1リーグが開幕する。 本稿では、データスタジアムが保有する、2016年のJ1リーグ全出場選手の試合ごとのスタッツデータ※401項目を、機械学習手法を駆使して解析、各チームの勝敗予測モデルを作成することによって、2017年のJ1リーグの展望をデータから予測してみる。 ※ここでのスタッツデータとは、選手の走行距離やスプリント回数といったトラッキングデータと、インターセプト、パスやシュート、ドリブルの回数といったプレーデータを指す。 サッカーの勝敗予測はどのように行えばよいだろうか。サッカーは、ゴールが対戦相手よりも多いチームが勝利するスポーツだ。サッカーにおけるゴール数は、野球やバスケットボールなど他のスポーツと比較し、一般的に少ない。2016年J1リーグでは805ゴールが生まれたが、1試合における、各チームのゴール数は平
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Spark MLlibではじめるスケーラブルな機械学習
2014 11-20 Machine Learning with Apache Spark 勉強会資料