タグ

2018年1月23日のブックマーク (5件)

  • 検索システムだって高可用性にしたい!SolrCloudを用いた高可用性構成の紹介 - ZOZO TECH BLOG

    こんにちは、バックエンドエンジニアの塩崎です。 最近のTECH BLOGではMatzさんのインタビュー記事を書いたり、RubyKaigiの発表まとめを書いたりして、他人の褌で相撲を取っていました。 今回は心を入れ替えて(?)、自分自身が取り組んだ内容について書きます。 VASILYでは検索用のミドルウェアとしてApache Solr(以下、Solr)を使用しています。 全文検索や、ファセット機能などはMySQLだけでは不十分なために、Solrを併用しています。 Solrのサーバー構成例にはいくつかのパターンがありますが、今回はその中でも最も可用性の高いSolrCloudをサービスインしたので、それについて紹介を行います。 Solrの構成例を幾つか紹介 Solrの構成例は大きく以下の3つに分けられます。 まずは、それぞれについて詳しく説明していきます。 スタンドアローン構成 master s

    検索システムだって高可用性にしたい!SolrCloudを用いた高可用性構成の紹介 - ZOZO TECH BLOG
    atomicmap
    atomicmap 2018/01/23
  • 社内ISUCONを開催しました! ( 解答例あり ) | PSYENCE:MEDIA

    はじめに こんにちは!リクルートマーケティングパートナーズ リファラルGの浅井です。リファラルGでは組織活性を目的として社内イベントの運営や勉強会のサポートを行っています。その取組の一環としてリクルートマーケティングパートナーズとQuipperのエンジニアを対象にISUCONを開催しました! ISUCONとは? Iikanjini Speed Up Contest(いい感じにスピードアップコンテスト)の略です。チーム対抗でお題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです。 開催のきっかけ リファラルGでは組織活性のアイデアを常に探しています。そんなある日、とあるメンバーが定例ミーティングにて「社内ISUCONやりたいっす」と呟いたのがきっかけです。その場で開催が決定し、プロダクトディベロップメント部1)リファラルGが所属する部署であり、リ

    社内ISUCONを開催しました! ( 解答例あり ) | PSYENCE:MEDIA
    atomicmap
    atomicmap 2018/01/23
  • 研究者からエンジニアに転生して1年経ちました

    昨年の1月にDeNAに転職し、研究者からエンジニアに転生してから1年経ちましたので、色々振り返ってみたいと思います。ついでにMediumとやらを始めてみました。書いていて気持ち良いです。 前置き転職前は、KDDI研究所にて10年ほど画像検索・画像認識の研究をしていました。その間に、Stanford Research Instituteに共同研究で半年間滞在させてもらったり、事業部でスマホの企画開発やったり、同時期に博士課程に進学したり、育児休職を取ったりしました。その辺りについては下記に書きました。

    atomicmap
    atomicmap 2018/01/23
  • ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try

    はじめに 「プロを目指す人のためのRuby入門」を出版して以来、で学んだ内容をブログに載せてくれている方をよく見かけます。 それ自体は著者として大変嬉しいのですが、たまに「ん?これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。 具体的にいうと、の内容を丸写ししているだけのブログ記事です。 このエントリではの丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。 の内容を丸写ししているブログの例 の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。 具体的なイメージを共有するために「こんな感じ」という例を載せておきます(特定の誰かのブログを意図しているわけではありません)。 タイトル「第2章 2.2.3 文の区切り」 「プロを目指す人のためのRuby入門」を読んでいるので、勉強した内容をメモ

    ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try
    atomicmap
    atomicmap 2018/01/23
  • Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita

    背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル(Skinny Controller, Fat Model)という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設計という認識となりました。 「ファットモデル問題」の登場 ところが、原因はわかりませんが、次第にファットモデルが問題があるものとしてみられるようになりました。 界隈では「ファットモデル問題」として取り上げて解決するという方法が紹介されるようになります。 20

    Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
    atomicmap
    atomicmap 2018/01/23