AWS ECSでDockerコンテナ管理入門（基本的な使い方、Blue/Green Deployment、AutoScalingなどいろいろ試してみた） - Qiita
はじめに Dockerを本番環境で利用するに当たり、私レベルではDockerのクラスタを管理することはなかなか難しい訳です。凄くめんどくさそうだし。 ということで**AWS ECS(EC2 Container Service)**ですよ。 記事書くまでも無いかなと思ったんですけど意外と手順がWEBにない（気がしました）。ということで、今回は社内でハンズオンでもやろうかと思って細かく書いてみました。 こんな感じのシナリオをやってみたいと思います。 Dockerのイメージを用意する ECSの使い方の基本 コンテナのリリース Blue/Green Deployment AutoScaling/ScaleIn 前準備：Dockerのイメージを用意する DockerhHub上にpush済ですので、そのまま使って動かしてみましょう。 push済のコンテナは8080で起動しますので80にポートをマッピン
Rails 5.1 以降で attribute_was, attribute_change, attribute_changed?, changed?, changed 等が DEPRECATION WARNING - Qiita
Rails 5.1 以降で attribute_was, attribute_change, attribute_changed?, changed?, changed 等が DEPRECATION WARNINGRails 何が起きたか? Rails 5.1 へアップデートして大量に DEPRECATION WARNING や spec エラーが起きたので、調べてみると Rails 5.1 で ActiveRecord::AttributeMethods::Dirty の attribute_was attribute_change attribute_changed? changed? changed 辺りが非推奨になった。 参考: https://github.com/rails/rails/blob/ce93740a5e4437dfc1cf9b0b13da1bad06a2a598/
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
ブロックチェーン技術は本当に有望なのか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? （2017年6月時点において）ここしばらくでのブロックチェーン技術の盛り上がりには圧倒される一方で、いざ、その技術的な実装内容について調べると共に、期待と現実との間での若干のギャップにとまどうところもあります。この記事ではそうした（個人的な）とまどいの内容を、「ブロックチェーン技術の有望性」という命題を軸とする形で、簡単な解説を交えつつ共有させていただきます。 （本記事の筆者と同じく）「熱狂の只中にあるブロックチェーン技術に飛びついて良いものか？」と自問されている各位にとっての参考としていただければ幸いです。 本記事のまとめ ブロックチ
いい結婚相手を見つける最適な方法を検証してみた - Qiita
現在の日本の生涯未婚率によると、男性の4人に1人、女性の7人に1人は50歳まで一度も結婚したことがなく、そうした人たちの割合は今後も増えていくそうです（出典: ハフィントンポスト）。原因は様々あるようですが、やはり**「適当な相手にめぐり合わない」**という理由は上位に来るようです。 ですが、適当な相手とは、一体全体どういう相手なのでしょうか？ 年収、容姿、性格、家、などなど人によって様々相手に求める条件があるものですが、「人の出会いは一期一会」ともいうように、いい相手とめぐり合えたとしても「もしかしたら今後もっといい人と会えるかも……」などとうじうじしているうちに、機会を逃すことも多いかもしれません（涙 この問題は、結婚相手を探しているA君がいるとすると、 A君は、これから結婚相手の候補となるN人と女性と出会う 候補となる相手は、１人ずつ次々に現れる 候補となる相手は、それぞれ違うスコア
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
Deep Forest :Deep Neural Networkの代替へ向けて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術動向についていくことは多くの労力を必要とする。次々に新しい論文が発表されるためだ。 一方で最新論文さえも長年の地道な積み重ねの上にあることを、その引用文献から気付かされる。 ディープラーニングブームの流れも変わるのだろうか？ 勉強のため、2017年2月28日付けでarXivに投稿されたZhi-Hua Zhou, Ji Feng「Deep Forest: Towards An Alternative to Deep Neural Networks」を翻訳した。 訳には誤りがないよう注意を払いましたが、完全であることを保証できないため、
Stacking - 計算編① - - Qiita
1. はじめに データコンペ界隈主導で、数%の精度を高める手法としてstacking・blendingが非常に流行っております(言わずもがなですが)。実務家として着目したいのは、数%の改善をする方法論だと思います。数%でチャリチャリ度合は全然違いますので、技術により利益貢献をするという目線で大変頼もしい手法です。StackingがKaggle主導で誕生した理由も、以下を覗くとうなずけます； [http://goo.gl/T0OlsV より引用] 1位と2位の差が2bp(∝10^-4)とは全く驚きです。そこで本エントリーでは、Stackingの概要を整理した後、sklearnを使って実験を行い、Stackingにより得られる示唆を考察してみたいと思います。 2. Stackingとは 実のところ、何が正しいのか不明瞭なのですが、[4]を参照し解釈すると視点としては以下が挙げられると考えていま
GAN(Generative Adversarial Networks)を学習させる際の14のテクニック - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この記事は"How to Train a GAN?" at NIPS2016を、ここを参考にして、私なりに解釈して、重要そうな部分を引用して翻訳したものです。役に立つことが多かったので共有致します。 ※GANの説明は省略します。G=Generator、D=Discriminatorとして説明します。 ※それぞれのテクニックに根拠はあまり書いてないですが、ほとんどが論文に書いてあった「こうすればうまくいった」というものです。GANの学習がうまくいかないときに試してみると良いと思います。 1. 入力を正規化 (Normalize the
自然言語処理における前処理の種類とその威力 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? **自然言語処理に前処理は不可欠です。**テキストは文字の羅列であり構造化されていないため、そのままでは処理するのが難しいです。特にWebテキストの中には HTMLタグ や JavaScript のコードといったノイズが含まれています。このようなノイズは前処理して取り除かなければ期待する結果は得られないでしょう。 出典: [Deep learning for computational biology](http://msb.embopress.org/content/12/7/878) 本記事では自然言語処理における前処理の種類とその
Convolutional Neural Networkとは何なのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 機械学習の世界において、画像といえばConvolutional Neural Network(以下CNN)というのは、うどんといえば香川くらい当たり前のこととして認識されています。しかし、そのCNNとは何なのか、という解説は意外と少なかったりします。 そこで、本記事ではCNNについてその仕組みとメリットの解説を行っていきたいと思います。 なお、参考文献にも記載の通り解説の内容はStanfordのCNNの講座をベースにしています。こちらの講座はNeural NetworkからCNN、はてはTensorflowによる実装まで解説される予定な
ChainerとRNNと機械翻訳 - Qiita
自然言語処理とニューラルネット ここ数年で、自然言語処理の分野でもニューラルネットが非常に頻繁に使われるようになってきました。 自然言語処理で主に解析対象となるのは単語の配列や構文木などで、これらの内包する情報を表現するためにrecurrent neural network1やrecursive neural network1などに基づくモデルが頻繁に使われます。これらの最大の特徴はニューラルネットがある種のデータ構造を持っているという点で、1レイヤあたりのノードはそれほど多くない代わりにネットワークの接続が複雑で、しかも入力されるデータごとにネットワークそのものの形状が変化するという特徴があります。このため、伝統的なfeedforward neural networkを前提としたツールキットでは構築が難しいという問題がありました。 Chainerは、そのような問題を概ね解決してしまう強力
シェルスクリプトの罠を避ける三つの tips
シェルスクリプトは、Unix 系環境で仕事をするエンジニアなら誰もが一度は書くであろうにもかかわらず、書き方や特性を熟知している人が少ない言語です。この記事は、シェルスクリプトを書くときに罠を踏まないようにするために最低限あなたが気を付けるべき tips 集です。「たかがシェルスクリプト」とは思わないでください。生半可に書かれたシェルスクリプトはあなたの (チームの) 生産性をかえって低下させます。 Shebang に bash を明示しろ Bash でしか使えない機能のことを俗に Bashism と言います。Bashism はもちろん Bash 以外のシェルでは動きません。これに関するありがちな罠は、以下のように発生します。 Bash が /bin/sh として使われている環境でシェルスクリプトを書く。うっかり Bashism がシェルスクリプトに含まれていても、 /bin/sh は何も
Chromeのヘッドレスブラウザがやってくる。というわけで試してみた。 - Qiita
注意：この記事は古いです。2016年06月06日に書いた記事です。 2017/04/14 追記： Chrome59から正式にヘッドレスモードが搭載されます。 ヘッドレスモードではPhantomJSなどのようにJavaScriptでヘッドレスブラウザを制御することも可能です。 https://chromium.googlesource.com/chromium/src/+/master/headless/ 2017/06/07 追記： NightmareJS風に操作できるライブラリをリリースしています。 ヘッドレスChromeをもっとも簡単に操作できると思われるNightmareJS風ライブラリ http://qiita.com/devneko/items/3689b46fc2bcdb8121a8 先日、Googleの人が「Headless Chrome is coming so soon」
Rails のアーキテクチャ設計を考える - Qiita
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2021.2.11追記：DateTimeクラスは非推奨なクラスになりました DateTimeクラスは非推奨なクラスとなり、DateTimeクラスではなくTimeクラスを使うよう、公式にアナウンスされました。 参考1 But we consider use of DateTime should be discouraged. - matz (Yukihiro Matsumoto) https://bugs.ruby-lang.org/issues/15712#note-4 参考2 DateTime は deprecated とされているた
ActiveRecordを速くしたいだけの人生だった - Qiita
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluentd入門 - Qiita
Rubyで外部コマンドを実行して結果を受け取る方法あれこれ - Qiita
ES2016 / ES2017の最新動向を追ってみた - Qiita
