タグ

2017年7月18日のブックマーク (31件)

  • ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita

    ActiveRecordでN+1クエリを潰すためにeager loadingを行う場合、preloadやincludesやeager_loadが役に立つ。 Preload, Eagerload, Includes and Joinsという記事にそれらの違いがよくまとめられているんだけど、includesが挙動を変える条件があまり正確に書かれていなくて自信が持てなかったし、そもそも記事が古いのでRails4.1.5のソースを読んで調べた。 せっかく調べたので、全体を通して日語でまとめてみようと思う。 User.joins(:posts).where(posts: { id: 1 }) # SELECT `users`.* FROM `users` INNER JOIN `posts` ON `posts`.`user_id` = `users`.`id` WHERE `posts`.`id

    ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita
  • 開発フロー研修 @ Wantedly - Qiita

    Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

    開発フロー研修 @ Wantedly - Qiita
  • Redis 本番障害から学んだコードレビューの勘所

    Redis不適切利用による問題は番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... (この話は事実ではなくファンタジーです。) 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以

    Redis 本番障害から学んだコードレビューの勘所
  • iexの便利機能 - Qiita

    $ iex Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] [dtrace] Interactive Elixir (0.11.3-dev) - press Ctrl+C to exit (type h() ENTER for help) iex(1)> 1+2 3 iex(2)>

    iexの便利機能 - Qiita
  • PUT か POST か PATCH か? - Qiita

    CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれません。PU

    PUT か POST か PATCH か? - Qiita
  • Railsの再読み込みの仕組みが意外とざっくりしていた - Qiita

    修正されたファイルがピンポイントで再読み込みされると思っていたのですが、autoload_paths以下のファイルやconfig/routes.rb等が修正された場合は全て再読み込みになるようです。非常にざっくりとした流れは以下の通り。 まずリクエストを受けるとreload_dependencies?でautoload_paths以下のファイル等が更新されているかチェック。

    Railsの再読み込みの仕組みが意外とざっくりしていた - Qiita
  • トランザクションをネストしたらどうなる? 内側だけロールバックできる? - Qiita

    トランザクションはRDBに対するひとかたまりの操作です。だから来入れ子も何もなく、始まりと終わりが一個ずつあるだけです。以上。 …で終わらせられないのは、それでもネストが必要になる場面があるからですね。 ありがちなのは、トランザクション開始終了処理まで込みのアプリケーション側関数・メソッドやストアドプロシージャの存在。こうした関数を、まあ関数ですから部品的に扱おうとするとトランザクションが開始した文脈下でこうした関数が呼び出されて入れ子のサブトランザクションスタート、ってことになったりします。 サブトランザクションのコミットは問題ない BEGIN TRANSACTION; INSERT ... 'A'); BEGIN TRANSACTION; INSERT ... 'B'); COMMIT TRANSACTION; INSERT ... 'C'); COMMIT TRANSACTION;

    トランザクションをネストしたらどうなる? 内側だけロールバックできる? - Qiita
  • コードレビューの際に気をつけること - Qiita

    コードレビューをする際と、してもらう際に気をつけるべきだと思っているをまとめておきます。 レビュイーとして大切なこと コードレビューをお願いする前に レビュアーが高いパフォーマンスを発揮するためには、レビューを受ける人の心構えと事前の打ち合わせが実は最も大切です。 特に大きめの変更のコードレビューをお願いする前にすると良いこととしては、 まず、レビュアーを確保する そのレビュアーと大まかな設計の合意をとる という方針でやっていくのが良いです。 レビューしていても、根をひっくり返すような指摘はしにくいですし、したとしても、それなら1から書いたほうがはやくて良い物が出来るといったことが簡単に起きます。 「レビュー後に直せるもの < レビュー前に直せるもの」 ということを意識して、Issueなどを用いて、出来る限り事前に設計、打ち合わせをしましょう。そうすればレビュアーもすんなりレビューできる

    コードレビューの際に気をつけること - Qiita
  • エンジニアでもSketchを効率的に使うためのまとめ - Qiita

    あえてプラグインについては何も書きません。Sketch自体の使い方についてフォーカスして書きます。 はじめに SketchはPhotoshopやIllustraと違い、機能がしぼってあることでエンジニアでもかなり使いやすいシンプルなUIのアプリケーションになっています。UIがシンプルである故に、意外と知られていないかなり便利な機能なども結構あります。隠れた機能を知ることでかなり効率的にSketchを使用できます。 自己紹介 Wantedly Advent Calender4日目を書きます。デザイナーの@usa619_ です。 WantedlyではUIデザインは基的にSketchで行っていて、エンジニアもSketchを使うことでコミュニケーションコストを下げるようにしています ref デザイナーとエンジニア間のコミュニケーションコストを下げる試み 基ショートカット Sketchのショート

    エンジニアでもSketchを効率的に使うためのまとめ - Qiita
  • プロダクトに名前をつける時に気をつけたいこと - Qiita

    私は今まで、数々のアプリケーションやライブラリをつくって GitHub / RubyGems 等で公開してきました。ここで毎回注意しているのがプロダクトの名前の付け方です。この記事では、自分が何に気をつけて名付けをしているのかを紹介します。 ユニークな名前にする ユニークな名前にする、つまり既に公開されているものとなるべく名前が被らないようにすべきです。ユニークな名前にすることでググラビリティ(検索した時のヒットしやすさ)を高めることができますし、エゴサーチもしやすくなります。 同じ名前のプロダクトがすでに存在しないかチェックする 自分はよさ気な名前が思いついたら、まず Google 検索と GitHub の一番上にある検索ボックスに突っ込みます。同じ名前のリポジトリがすでにあるかどうかを調べるためです。ハイフンとかを含めるなら名前をダブルクォートで囲むのが良いでしょう。 幸運にもリポジト

    プロダクトに名前をつける時に気をつけたいこと - Qiita
  • 翻訳: 似て非なる Phoenix と Rails(原題『Phoenix is not Rails』) - Qiita

    Phoenix の開発者である Chris McCord さんが 2015/11/18 に書いた記事「Phoenix is not Rails」の翻訳です。 僕は Rails 未経験の状態で Phoenix を始めたクチなのですが、最近 Rails もやるようになり、両者を比較して考えることが多くなってきたので、いい機会だと思い翻訳してみました。 誤訳があれば編集リクエストを頂けると幸いです。 まえがき 昨年12月、ブライアン1は年次総括で 開発を Elixir と Phoenix に移行する計画を公表しました。それから1年、実際に Rails から Phoenix へ移行してみて分かったのは、この作業はそれほど大変ではないということです。というのも、Phoenix は Rails と非常によく似た作りをしているからです。もちろん、フレームワークのきちんとした理解にはそれなりの学習が必要で

    翻訳: 似て非なる Phoenix と Rails(原題『Phoenix is not Rails』) - Qiita
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

    翻訳: WebAPI 設計のベストプラクティス - Qiita
  • RubyGems 開発速習会 - Qiita

    この記事は、RubyGem 開発速習会@Wantedly の資料として作られたものです この資料は、 Ruby 2.3.1 RubyGems 2.5.1 Bundler 1.12.4 の環境で執筆されました。 この速習会のゴール gem を一から作れるようになる ただ作るだけじゃなく、テスト駆動開発を取り入れた効率のよい開発ができるようにある 開発支援系のサービスに詳しくなる gem とは gem は、最もメジャーな Ruby ライブラリの形式です。 Ruby on Rails も1つの gem として提供されており、rails gem の中でもまた多くの gem が利用されています。 現在公開されている Ruby のソフトウェアや Ruby on Rails 上の Web サービスは、多くの gem を組み合わせることで成り立っているのです。 ちなみに www.wantedly.com

    RubyGems 開発速習会 - Qiita
  • ghq, peco, hubで快適Gitライフを手に入れよう! - Qiita

    はじめに peco, hubは前から使っててghqは存在は知りながらも「別にリポジトリ管理は必要ないかなー」と思ってたのですが、管理するリポジトリ数が増えてきて面倒になってきたので試しに入れてみたらかなり良かったので紹介したいと思います ghq, peco, hubとは? ghqは上でも軽く書いたようにリポジトリ管理ツールになります。 例えばgit cloneの代わりにghq get <repository URL>とコマンドを打つとghqルートディレクトリ(デフォルトでは~/.ghq)以下にリポジトリがcloneされ、 ghq listでghqルートディレクトリ以下のGitリポジトリ一覧を表示、 ghq look <project>で指定したリポジトリに移動する、といったように使います。

    ghq, peco, hubで快適Gitライフを手に入れよう! - Qiita
  • [peco]peco-select-history.zsh で表示されるコマンド履歴の重複を削除する - Qiita

    peco を導入した | DevAchieve でコマンドラインの行選択ツール peco を導入しました。 以下の peco-select-history.zsh を設定したのですが、 使っているうちに同じコマンドが peco の選択候補を埋めるようになりました。 function peco-select-history() { local tac if which tac > /dev/null; then tac="tac" else tac="tail -r" fi BUFFER=$(history -n 1 | eval $tac | peco --query "$LBUFFER") CURSOR=$#BUFFER # zle clear-screen } zle -N peco-select-history

    [peco]peco-select-history.zsh で表示されるコマンド履歴の重複を削除する - Qiita
  • ag の検索で除外設定を使う - Qiita

    ag こと The Silver Searcher、検索が早くてとても便利ですよね。 (ag は 銀の元素記号が由来らしいですよ) なぜか巷では今になって ack が話題になっているようですが、やっぱり ag だよね ag! 詳しい使い方は以下あたりを見て下さい。 ackを捨てて、より高速なag(The Silver Searcher)に切り替えた - Glide Note - グライドノート 除外対象を ~/.agignore に設定しよう デフォルトだと探して欲しくないファイルやディレクトリの中まで対象になってしまうので、困るときも多いかと思います。 (.gitignore 等も見てくれたりするけど、それだけじゃ足りないですよね) そこで、検索してほしくない対象を ~/.agignore に書いておくことで、それらを除外して検索することができます。 これを設定するだけで、かなり使い勝手

    ag の検索で除外設定を使う - Qiita
  • GitHubで自分が関係しているIssueを見逃さないようにするためのページ一覧 - Qiita

    世の中には、いろんなツールがあるけれど、ここではデフォルトでGitHubが用意してくれているページを駆使して、自分が関係しているIssueに気づかない問題を解決する方法を紹介する。 Notificationの活用 まずは、通知を意味あるものにしたうえで、毎日見に行くという習慣付けが大事。 ショートカットとしてはg+nでいける。 運用にあたっては、まず、今までのNotificationを全てクリアして、必要なものだけがNotifyされるようにWatch設定をちゃんとする。 実際、Notificationが多すぎて役に立たなくなっている人は全てUnwatchすることから始めてもいいかもしれない。 そうするとNotificationが結構役に立つようになる。 Watchしてるものの中で、自分が関係しているものだけを見たい場合は、Participatingタブを選べば良い。 なお、全てUnwatc

    GitHubで自分が関係しているIssueを見逃さないようにするためのページ一覧 - Qiita
  • RailsでAPIをつくるときのエラー処理 - Qiita

    例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という

    RailsでAPIをつくるときのエラー処理 - Qiita
  • Rubyでforkを利用したマルチプロセスでコアを使い切りたい気持ち - Qiita

    Rubyで書かれたちょっと重たいバッチ処理があって速くする必要があったので、fork(2)とpipe(2)を使ったマルチプロセス化でコアを活かした並列処理に書き直した話します。 以下の記事に詳しく書いてあるので、TL;DRはそちらを見てな? Forking and IPC in Ruby, Part I Forking and IPC in Ruby, Part II なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 Threadじゃいかんの? — GILについて 並行プログラミングとしてまず最初に思いつくのはマルチスレッド化ですが、RubyにおいてはGVL(Giant VM lock)があるためマルチコアを活かすことは難しいのです。 ネイティブスレッドを用いて実装されていますが、 現在の実装では Ruby VM は Giant VM lock (GVL) を有し

    Rubyでforkを利用したマルチプロセスでコアを使い切りたい気持ち - Qiita
  • 【Rails4.2.x】omniauth(twitter/facebook/github)実装まとめ - Qiita

    はじめに 実装する度に検索するのも面倒なので、この際にまとめます。 理解すべきところはそれについて言及しています。 追記 こちらも参考になります。 Devise+OmniAuthでユーザ認証を実装する手順 対象読者 自分のサービスにソーシャルログインを追加したい人 omniauthとは Webアプリケーションのログイン認証を、複数のプロバイダを通して行うことができるgemです。 新規登録の際によくある、Twitter・Facebookでログインはこれを使って実装できます。 事前準備 Userモデルを作成します。 カラム名は使用したいデータに合わせて変更してください。

    【Rails4.2.x】omniauth(twitter/facebook/github)実装まとめ - Qiita
  • enhanced-ruby-modeの概説 - Qiita

    enhanced-ruby-modeはEmacsのメジャーモードのひとつ。標準で付属しているruby-modeの代替を目指して開発されている。Ripper(Rubyの標準添付ライブラリ)によって構文解析を行うのが特徴。 機能 インデント シンタックスハイライト リアルタイムの文法チェック よいところ Ripperを使っているので、厳密な構文解析を行わないruby-modeではパースに失敗するコードでも正しく扱うことができる。 わるいところ たまにパースが止まる。 ruby-modeとの互換性 enh-ruby-forward-sexp, enh-ruby-backward-sexpなどのコマンドの振る舞いがruby-modeと異なる。 シンタックスハイライトの色の対応が一部異なる。 開発状況 2010年にGeoff Jacobsen氏によってjacott/Enhanced-Ruby-Mod

    enhanced-ruby-modeの概説 - Qiita
  • Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita

    「BigQueryは120億行を5秒でフルスキャン可能」は当か? 先日、kaheiさんがGoogle BigQuery(Googleクラウドの大規模クエリサービス)について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。(Fluentd Meetupでの)プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる(これ、記憶がちょっとあいまい。もう少しかかったかも)。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent

    Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
  • 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を

    ActiveRecordを速くしたいだけの人生だった - Qiita
  • 魔法をとけなくする方法教えます。VR におけるプレゼンスの維持と破壊

    “Presence is VR Magic.”プレゼンスはVRにおける魔法です。これは2014年1月 開発者イベントであるSteam Dev Daysで当時ValveにいたMicheal Abrash(現Oculus チーフサイエンティストオフィサー)が語っていた言葉ですが、VRテクノロジーを使えば、自宅に居ながらにしてまるで別の世界に入り込んだような魔法の体験が可能となりました。その一方でちょっとしたことでこの魔法は溶けてしまいます。まるでシンデレラのガラスののように。 プレゼンスとは何?辞書による定義は presenceとは 主な意味 存在、あること、現存、出席、参列、駐留(軍)、(警察官の)配備、配置、面前、人前 「実在感」「存在感」という感じでしょうか? 「そこにある感」 という感じがイメージしやすいと思います。 没入感とは違うのか? というと、従来の映画でも没入感は自体はあり

    魔法をとけなくする方法教えます。VR におけるプレゼンスの維持と破壊
  • Ruby でラインメモリプロファイラ - Qiita

    プロファイラ好きなモニタの前の皆さんこんにちは。@sonots です。この記事では、Ruby コードのどの行がどのぐらいメモリを消費しているか調べる方法を紹介します。 オブジェクトの数を数える Ruby には ObjectSpace というオブジェクトの情報を集めたり操作したりする module があります。 このモジュールの each_object メソッドを使用すると、RubyVM 上の全てのオブジェクトを取り出すことができます。 このメソッドを使って、以下のようなコードを書くと、実行した地点で、RubyVM 中にどのクラスのオブジェクトが何個存在しているのかカウントできたりするわけです。興味深いですね! ObjectSpace.each_object.inject(Hash.new 0) {|h,o| h[o.class]+=1; h } #=> {Class=>241, Strin

    Ruby でラインメモリプロファイラ - Qiita
  • データサイエンティストを目指す人のpython環境構築 2016 - Qiita

    pythonの環境構築について "python 環境構築"でググると20万件くらいヒットしますが、割と内容が古いです。 タイトルにはデータサイエンティストと書いてありますが、データサイエンティスト以外にもanacondaはおすすめです。 2.x or 3.x? 3.xは動かないライブラリが多いので2.x推奨 > 3.xで動かないライブラリがある、くらいまで来ました。 easy_installでpipを入れて、setuptoolsも入れて、でもwheelというのもあって... > 古いです。 virtualenv 必須 > そんなこともないです。 winでは64bitは不具合が多いので32bit推奨 > 古いです。 winでは非公式バイナリからダウンロードしてインストール > お世話になりましたが、最近は使っていません。 2016版 OS毎python環境構築法決定版 Windows: an

    データサイエンティストを目指す人のpython環境構築 2016 - Qiita
  • RubyでBoolClassではなくTrueClass/FalseClassな理由を理解する - Qiita

    @mattn_jp BoolClassを入れるとkind_of?でチェックしたくなってduck typingを阻害するから。 — Yukihiro Matsumoto (@yukihiro_matz) 2015, 12月 4 30回くらい読みなおしたけど何のことを言っているのか分からなかったので、周りのRubyistに質問して理解を深めたメモ。 まずDuck Typingというのは、Wikipediaによると ダック・タイピング(duck typing)とは、Smalltalk、PythonRubyなどのいくつかの動的型付けオブジェクト指向プログラミング言語に特徴的な型付けの作法のことである。それらの言語ではオブジェクト(変数の値)に何ができるかはオブジェクトそのものが決定する。つまり、オブジェクトがあるインタフェースのすべてのメソッドを持っているならば、たとえそのクラスがそのインタフェ

    RubyでBoolClassではなくTrueClass/FalseClassな理由を理解する - Qiita
  • REST APIの設計で消耗している感じたときのgRPC入門 - Qiita

    REST APIによる設計 最近のシステムは様々なデバイスやスケーラビリティを重視するため、各システムを分割し軽量なAPIで連携するマイクロサービス的なアーキテクチャスタイルが増えてきています。 そして、そのAPI連携で広く採用されているのが、REST APIです。 しかし、こうした設計を行っていくには、適切に考慮、選択しなければならないことも多くあります。 URL、パラメータ、エラーなどの設計 各言語ごとのライブラリや、サーバ、クライアントの選定、設計 認証、認可 ドキュメント管理 ユニットテスト、インテグレーションテスト、モック、Consumer-Driven Contracts 開発用ツール 絶対的スタンダードがない状況下で、こういった問題はシステムやメンバーが増えるにつれ複雑化していき、設計や管理、その仕組み作りに時間を取られ、来の目的となるべき機能開発の時間を失っていくことにな

    REST APIの設計で消耗している感じたときのgRPC入門 - Qiita
  • 巨大なデータを扱う場合のRedisの運用戦略 - Qiita

    はじめに Read/Writeともに高速で,様々なデータの持ち方が可能なことでキャッシュDBとして人気のあるRedisですが,何も考えずに実運用システムで使用しているとデータが肥大化してしまい非常に扱いにくくなることがあります. 今回は,データの肥大化とともに顕在化する問題と,データの肥大化に対する戦略についてまとめたいと思います. データの肥大化時に顕在化する問題 何のキーが入っているか分からなくなる Redisはオンメモリ型のKVSであるため,データがある程度増えてくるとサーバのメモリ容量を圧迫し始めます. このような状態で,プロダクション環境に対して keys * などをやってしまうと,一時的にメモリ使用量が跳ね上がり,メモリ使用量を抑えるためにRedisがキーを削除したり,OOM KILLERにRedis Serverごと殺されてしまう可能性があるため,そういったコマンドはうてなく

    巨大なデータを扱う場合のRedisの運用戦略 - Qiita
  • Coursera / Machine Learningの教材を2度楽しむ - Qiita

    遅ればせながら,CourseraのMaechine Learning (Stanford University, by Andrew Ng)を受講している.もちろん説明動画も有益だが,このコースの良さを際立させているのが,毎回出されるプログラミングの課題である.ただMatlabのコードなので,後で復習できるようにPythonに書き換えたくなってきた.(他の方で,同じ取り組みの紹介例がInternetで見受けられる.) ここでは,"Coursera / Machine Learning"の教材を(Pythonで)2度3度楽しむやり方を紹介する.また関数最小化で用いる,scipy.optimize.minimize() について説明する. コスト関数とその導関数 Machine Learningの教材では,コスト関数を作成し,それを最小化するパラメータを探索する,というものが多い.Matlab

    Coursera / Machine Learningの教材を2度楽しむ - Qiita
  • イカサマコインの例で最尤推定とベイズ推定の違いを理解してみる - Qiita

    はじめに 最近世の中で統計学が流行っています.ITの発展によりデータが容易に得られるようになり,いまや様々な業界のシステムでデータ解析機能の適用を検討しているのではないでしょうか.そうなると,IT技術者は深かれ浅かれデータ解析のプログラムに触る必要も出てくるでしょう.すると当然「推定」というキーワードにぶち当たるわけです.はて,統計的な推定とは如何なものか?と言う疑問が湧くでしょう. そんなわけで,統計学において得られたデータを元にある推定値を得る方法を探してみると,「最尤推定」とか「ベイズ推定」と言う手法は特に目に触れることになると思います. 初学者の小生は,これらの違いについて知りたくて,それっぽいキーワードでWeb検索をしたのですが,門前払いをらってしまいました.何か,条件付き確率の式がウジュウジャ出てくる説明ばかりではあーりませんか!尤度?事前確率?もうーワケかららない!あー!

    イカサマコインの例で最尤推定とベイズ推定の違いを理解してみる - Qiita