読者です 読者をやめる 読者になる 読者になる

satococoa's blog

Web や iOS アプリを作るエンジニアの日記です

じっくり味わう本を読むには読書会が有効だと思う

ポエム

タイトルで言いたいことは言い尽くしたので、そう思う理由を挙げたいと思います。

その本、読んだはいいけど理解できてる?

電子書籍のおかげで、物理的なスペースを気にすることなくつい気になる本を買っては積んでを繰り返してしまいます。 そうすると積ん読を消化するだけで消耗しがちです。

最近本を読むことをおすすめするエントリを書きましたが、やっぱりただ大量に本を 消費する だけでは効果は薄いと思います。 読んだ内容を自分の言葉、もしくはコードで表現できるようになって、初めて 理解した と言えるのです。 (本の種類によってはざっと斜め読みして、後で詳しく知りたくなったときのために頭の中にインデックスを構築すれば十分なものもありますが。。)

理解するためのひとつの方法として、本の中身について語り合うことが有効だと思っています。 その相手は同じ知識レベル、もしくは自分より上のレベルの人と話すことが好ましいです。 その機会として読書会を開く・参加することは非常に有意義だと最近特に感じているのでポエム書きます。

読書会って何?

まず僕が参加している読書会について、どんな感じにやっているのかをお話しします。 読書会に参加したことのない方はびっくりするかもしれませんが、基本的に音読します。 もし英語の本を読んでいるのなら一文、もしくは長い場合は適当なフレーズで区切って和訳しながら読みます。

そして1節程度読んだら音読する人を交代します。 また途中で気になるところがあったら音読を止めて、その内容について語ります。

その繰り返しです。

今までの読書会の思い出ほろほろ

まずは会社で リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 読書会をもう3年くらい前ですがやっていました。 「良いコードってどんなもの?」について同僚と意識と認識を合わせることができたのが非常に良かったです。あと、いろんな言語をやっている人がいるので「Java だとこう」「Ruby だとこんな感じ」など、言語の文化に基づいた議論ができたのも良かったです。

次も会社でですが、 Working With Unix Processes (English Edition) の読書会をやりました。 今なら なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 で日本語版も買えますが、当時は英語版しかなかったので交代で和訳しながら読みました。 英語の本って一人で読もうとするとモチベーションを保つことが難しいですが、みんなで読むことで楽しく読むことができました。 あとは一人で読むと英語の理解でいっぱいいっぱいになってしまうかもしれませんが、そこは仲間の知恵を借りて英語を理解するだけにとどまらず、内容についてもちゃんと理解できたと思っています。

あとは @1syo さん、@miyohide さんが タネマキ | 横浜 コワーキングスペース - シェアオフィス でやってる読書会に一昨年の年末から現在も参加させてもらっています。 この読書会は毎週土曜日の10:40から、しかも英語の本というなかなか意識高い感じの読書会になっていますが @1syo さんと @miyohide さんがいるおかげでなんとかくじけずに続けられています。

読む本も3冊目に入りました。 ちなみに1冊目は Objects on Rails、2冊目は Working With TCP Sockets (English Edition)、そして現在読んでいるのが The Pragmatic Bookshelf | Growing Rails Applications in Practice です。

もちろん3人とも同じ会社で働いているわけではないのですが、本を触媒にして Rails の設計の話だとか、実物のコードがないとなかなか語れない深いレベルでお互いの知識を覗き合うことができるのでとても楽しいです。これは普通の勉強会だと体験できない経験だと思います。 そして、「みんな勉強してるんだなぁ。。。」と自分の勉強不足を毎回思い知らされるわけです笑

ご提案

ここまでこのエントリを読んで「読書会やってみたいな」「読書会に参加してみたいな」と思った方向けに、僕の経験を基にしていくつかご提案したいと思います。

読書会に向いている本はこんな本

レシピ本の様にリファレンス的につまみ食いして読む本よりは、何か一つのテーマについて一貫して書いてある本の方がいいと思っています。 レシピ本は一人で斜め読みして速攻で頭にインデックスを構築しておく方が役に立ちます。 (補足: レシピ本の読書会は、参加人数が多かったり参加者が開催日によって異なる場合には有効です。)

また基礎について書かれた入門書よりは実践、応用レベルの本の方が良いと思います。 入門書は一人で読んでサクッと次のステップに向かう方が良いのに対して、実践・応用レベルの本になると書いてある内容に関して賛否両論がある箇所があったり、疑問に思う箇所があったり、自分のこれまでの習慣に反することが提唱されていたりします。 そういう箇所を仲間と話し合うことによって、本の理解に対するレビューを行うことができます。

英語が苦手な人はぜひ英語の本の読書会に参加しよう

一人じゃくじけますからね。。 たとえ英語が得意な人がいなくても、数人で「これはこういう意味じゃない?」などと話しながら進めれば十分モチベーションを保つことができると思います。

一緒のチームじゃない人と積極的に読書会をしよう

一緒のチームの人とは読書会をしなくても実際のコードをもとにしていろんなことを話すことができます。 「このクラスはこう分割した方がいいんじゃない?」とか「変数名がちょっとアレだよね」とか。。

しかし一緒のチームで働いていない場合はなかなかお互いの知識を共有することができません。 教え合おうにも何を教えればいいのかわからないですし。。。

本を読みながらその内容に沿って、時には脱線したりしながら話すことによってコードを肴に話をするときと似た様な効果を得られると思います。 うまく説得力のある文章にできないのですが、本の内容をガイドに使うことによって、浅い意見交換に終わらずにちゃんと議論するレベルまで話をできる実感があります。

以上です。参考になれば幸いです。

RE: どんなことを勉強すればいいですか?

ポエム

仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか?」です。 それについてちょっとポエムを書いてみようかと思います。

主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。

専門家であるという視点から

エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。

僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な知識を積み重ねるだけの非常に頼りないエンジニアになってしまうだけです。

本を読もう

そこでおすすめするのが、まずは本を読むこと。 Web で検索すれば断片的な知識はいくらでも手に入ります。 Qiita とか stackoverflow などはとても頼りになるサイトだと思いますし、ブログを熱心に書いていらっしゃる方もたくさんいるので大量の情報が手に入ると思います。 でも断片的な知識をつなぎ合わせたところでどこか必要な知識が抜けてしまったり、整合性の取れていない知識になってしまったりするとやっかいです。

言語に関わらない知識ならまずこれを読んでください。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

チーム開発でコードレビューを受けるようになると、ここに書かれている内容はもはや前提知識になります。 当たり前すぎてそのうち指摘すらしてもらえなくなるかもしれません。 僕も最近再度読み返しましたが、無意識のうちに「良いコードってこんなコードかな」って思っていることをきちんと具体例とともに言語化してくれている本なので、これを読んでおくことでコードについてのコミュニケーションがスムーズになります。

Ruby なら以下のあたりを押さえておくといいと思います。適当に Amazon のリンクを貼りますが、電子版もあったりするので適宜探してください。

初めてのRuby

初めてのRuby

初めてのRuby

ちょっと古い本になりつつありますが、他の言語の経験がある人が Ruby らしさを知るにはとても良い本。薄いのであっという間に読めますし。

プログラミング自体も初心者であるなら スタートアップRuby の方が易しくていいかも。

たのしい開発 スタートアップRuby

たのしい開発 スタートアップRuby

Ruby のコミュニティ含めた文化についても知ることができます。幸い身近にコミュニティがある場合は、この本を読んでから ⚪︎⚪︎.rb みたいなところに飛び込んでいくと、継続的にモチベーションや情報を得るきっかけが得られます。

Rails についてはまずは電車本だと思います。

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

そこから先は パーフェクトRuby (PERFECT SERIES 6)パーフェクト Ruby on RailsメタプログラミングRuby などなどたくさんの本がありますが、まずは上述のあたりから入るといいと思います。

iOS なら本ではないですがまずは Apple Developer で公開されている公式のドキュメントから始めるといいと思います。

チュートリアル Start Developing iOS Apps Today: Setup

その他のドキュメント 日本語ドキュメント - Apple Developer

特に iOS View Controller プログラミングガイド に一通り目を通しておくと、iOS 開発の勘所はなんとなくわかります。

そのあとの書籍ですが、以下がおすすめです。

UIKit徹底解説 iOSユーザーインターフェイスの開発

UIKit徹底解説 iOSユーザーインターフェイスの開発

主に View について書かれた本ではありますが、View, View Controller 周りで何ができるのかをちゃんと知ることによって、ようやく MVC を意識した設計が出来ると思いますので。

アンテナを張ろう

次におすすめするのが、新しい情報にアンテナを張ること。

ただアンテナを張るだけではなく、情報を鵜呑みにせずに自分で確かめることも必要です。 Web にある情報は特に玉石混交で、誤った知識をそのまま業務に適用してしまうのは非常にまずいことです。 また、必ずその記事の書かれた日付を確認してください。技術情報には鮮度があります。

その前提の上で鮮度の高い情報を得る方法は以下のとおり。

1. 信頼できる人をフォローする (Twitter, GitHub, はてなブックマーク)

GitHubTwitter で有名な人とか信頼できる人をフォローしておくことで、非常に鮮度の高い情報を得ることができます。 はてなブックマークの場合は、「お気に入り」っていう機能ですね。

例えば

  • ブログ書いたよー とか
  • こんなリポジトリの Watch を始めた / Star をつけた
  • ⚪︎⚪︎でハマった
  • このエントリにブックマークつけた

一度習慣にしてしまえば気になる人を見つけるたびにフォローを増やせばいいので楽ですが、まだやっていない方はこの休みのうちにガッとやっておくといいと思います。

GitHub の Star は http://starseeker.so っていうサービスを使っておくと、自分がフォローしている人がスターをつけたリポジトリが毎朝メールで配信されてくるので超絶便利です。

はてなブックマークのお気に入りは iOS 限定ではありますが HBFav2- Hatena-Bookmark Reader for iOS を使うと、自分がお気に入りに入れているユーザがブックマークした URL が随時 iPhone に配信されてくるのでこれも超絶便利です。

2. 一次情報にまず当たるクセをつける

なるべく一次情報にあたるようにするのも時間節約のコツです。 鮮度の落ちた日本語のブログエントリよりも、githubリポジトリ上にある README を読む方をまず優先するといいと思います。

3. 実践してみよう

最後にその情報を自分のものにするために手を動かすことも大事です。 書籍や Web の情報源から得た情報をきちんと自分のものにするには、ちゃんと手を動かすことだと思います。コードにして自分のリポジトリなり gist に置いてみて初めて「自分のものになった」と言えるかもしれません。

なので、ぜひ試してみてブログなり GitHub なりにコードを載せてみて欲しいと思います。

チーム開発という視点から

チーム開発においては、会社で使っているコミュニケーションツールに慣れておくことも大事だと思います。 例えば Git / GitHub を普段から使って、その機能に慣れておくこととか。

今までコードレビューを受けられる環境にいなかった人は、「人に読んでもらう」ことを前提としたコーディングを心がける必要があります。

なかなかこれは意識してやるようにしないと身につかないのですが、コミットの粒度とかコミットログの書き方、コード内のコメントとか関数名、変数名などあらゆるところに読む人の目を意識する必要があります。 詳しくは前述のリーダブルコードで。

あとは仕事の優先順位のつけ方にも考慮が必要です。 タスクが複数あるときにどのタスクから手をつければいいのか。 それは状況によって違ってきますが概ね以下のようなことを考えるといいと思います。(そして困ったらチームメイトにすぐ相談することも大事)

  • このタスクを {始めること or 終わらせないこと} によって誰かの仕事を止めてしまわないか?
  • 技術的なリスクや検証が必要な項目が含まれるタスクの場合、早めにやっておかないとその他のタスクに影響を及ぼしてしまうのでは?
  • 作ろうとしている製品にとって、このタスクの優先度はどのくらいなのか?(実装に時間はかかるけどなくてはならない機能だったら、すぐ終わるなくてもいい機能より先に実装した方がいいのでは?)
  • ユーザにとって自分がこれから行うタスクはどんな影響を与えるのか。

ちょっと抽象的な感じになってしまったし、普段無意識で行っていることを網羅はできていないと思うのでちょっと頼りないですが、参考にしていただけると幸いです。

社会人としての視点から

ここから先はさらにポエム度が高まってしまうのですが、要は「一緒に仕事してて楽しい」って思われる人になりたいな!ってことです。 普段から僕も気をつけていることではありますが、日常の中でついつい雑になりがちな部分なので気をつけたいです。 Team Geek ―Googleのギークたちはいかにしてチームを作るのか の HRT: 謙虚 (Humility), 尊敬 (Respect), 信頼 (Trust) も参考になると思います。

同僚として敬意を払う

「親しき中にも礼儀あり」です。 必要以上に踏み込み過ぎず、かといってよそよそしくなりすぎず、同僚としての適度な距離感を取れるといいと思います。

また意見の相違がある場合は意見についての厳しいやりとりは必要ですが、人格の否定をしてはいけません。

「あの人、全然システムのことわかってないからな」って諦めてしまうのはまずいです。 (ついつい自分が詳しい分野については上から目線になっちゃったりもしますが...。)

そうではなく、ちゃんと相手に教えるべきことを教えていない、または相手にとってわからないことを聞いてもらえる関係を築けていない自分になっていることを反省すべきです。 そして逆に自分が知らないことをたくさんその相手は知っているはずです。お互いの知らないことをきちんと質問しあえる、そしてその上で意見を交わせるようになりたいですね。

不平・不満と付き合う

仕事をしていると、大小さまざまな不平・不満が出てきます。 全てが自分の思い通りに進むわけではないので当然だと思います。

その不平・不満をどのように解決しますか? SNSで愚痴ったりしていると何の解決にもならないし、偶然同僚がそれを見かけると非常に嫌な気分になると思います。 同僚じゃなくても、大抵そういう愚痴って見かけるたびに見る人の心を重くするものです。

確かにその愚痴は正論で「正しい」ことかもしれませんが、それを声高に唱えて周りに威圧感を与えることは必ずしも正しい方法だとは思いません。 解決すべき問題なら解決策を考え自ら動く、もしくは解決できる権限を持つ人に相談をする、など前向きな態度で挑むことが必要だと思います。

とはいえ、愚痴ってすっきりする程度のものごとも多いので、それはそれで人に見えないところでこっそりお酒の肴にでもしながら楽しい時間に変えてしまえればいいと思います。結構そういうのも僕は好きです。

人を頼る

人を頼ることってなんとなく自分のダメさを認めてしまうことだったり、人に迷惑をかけてしまうことだったりしそうでなかなか勇気が要るものです。 でも全てを自分一人でこなそうとするとタスクの量か質の問題で必ずどこかで限界がきます。だからチームで仕事をしているんだと思います。

チームメイトにはそれぞれ強み・弱みがあります。自分一人で閉じてしまって、個々がブラックボックスになってしまうのはもったいないと思います。 常に気軽に相談ができる状態にチームを保ち続けられるといいですよね。

そのためにはあまり関係なく思えるかもしれませんが、普段から雑談したり、ご飯を一緒に食べたり、くだらない話をチャットでやりとりしたりして心理的な距離を近めておけるといいなと思います。

そして、いざとなったらきちんと頼る。そして自分もどこか一部でいいから誰かに頼ってもらえる。そうなりたいです。

まとめ

途中から論点がズレてまとまりが無くなった感じもしますが、何かの参考になれば幸いです。 僕がこういう気持ちで仕事をしているっていうことだけ伝われば十分なのかもしれません。。という自分のためのポエムでした。

Webエンジニアのためのデータベース技術[実践]入門

誕生日から1週間位過ぎたダメなタイミングでウィッシュリストをこっそり晒してみたら id:a2ikm さんが送ってくれたので読みました。 ありがとうございます!! (ちなみにこちら -> http://www.amazon.co.jp/registry/wishlist/16JH79VDRKUVM )

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

どんな本?

この本は「データベース技術」と題してはありますが主に MySQL を使っている人向けと考えて読むのがいいと思います。

第9章 "MySQLに学ぶデータベース管理"、第10章 "MySQLソースコードを追ってみよう" は掲題の通り MySQL に特化した内容なのですが、その他の部分も「MySQL だと...」というように MySQL について述べられたところがたくさんあります。

その上でインデックスの基本的な仕組みや正規化などのテーブル設計のトピックもありますので初心者にとっても役立つ本だと思います。 また、最近のトレンドである NoSQL とかデータウェアハウスについても軽くではありますが述べられています。

個人的に役立った部分

正規化とかインデックスの仕組みとかその辺は理解していたので、基礎知識の再確認という意味ではよかったです。 それ以外にどちらかというと運用面が僕は知識が不足している (そして RDS にお任せっきり) の部分だったので、以下の項目について知れたのがよかったです。

まとめ

以上のように、MySQL を中心にデータベースについて広く浅くという本なので、比較的 DB にあまり親しみの深くない経験の浅いエンジニアはなるべく早い段階で読んでおくと良いと思います。逆に mysqld のチューニング、SQL のチューニング、運用について自信のある方には少し物足りないかもしれません。(僕はあまり自信がなかったので知識の再確認も含めて役に立ちました!)

DB 関連の本はたくさんありますが、テーブル設計・運用・周辺知識までざっくり押さえるには良い本だと思いました。

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Web制作者のためのCSS設計の教科書を読んだ

読書 css

久しぶりに仕事で Web 側の view を作っていて web のフロントエンドの技術からだいぶ遅れてしまっていたことを実感したので、キャッチアップするために以下の本を読みました。

例によって PDF が欲しかったので達人出版会で買いましたが、ちょうどポチった翌日から kindle 版が半額以下になるという悲しい現実。(いや、でもどうせ PDF が欲しかったのできっとどちらにせよ達人出版会で買ったと思いますが...。)

以下感想です。

どんな本?

CSS の "設計" について書かれた本です。

フロントエンドの "設計" というと JavaScript のことと勘違いしがちですが、CSS も無秩序にセレクタを書いていくとあっという間に破綻してあちこち意図しない見た目になってしまいますよね。 サービスをリリースした経験がある方のほとんどはこんな経験を一度はされていると思います。

最近は sass とか less があるので途中まではそれなりにうまくモジュールに切り分けて整理できていても、そのうち「なんでこのセレクタが優先されちゃうの?」とか「こっちにはこのスタイル効いて欲しくないのに!」って困るのはあるあるネタだと思います。

その辺のよくあるやりがちな間違いをきちんと実例を挙げながら原因を解説するところから始めて、最近よく聞く OOCSS とか BEM とか SMACSS とかの CSS の設計技法についても満遍なくフラットに解説してくれている本です。 また、SASS を使った設計方法についても記述があるので Rails 使いの人にとってもすぐ役立つ知識をすっきりと手に入れられる本です。

最後には Web Components についても概要を紹介してくれています。

どんな人にオススメ?

CSS の本だからと言ってコーダーとかデザイナ向けだと勘違いしてしまうと損です。むしろプログラマにオススメです。 特にフロントエンドにあまり縁がなかったバックエンドを主に扱っているプログラマにとっては、プログラマ的な考え方で CSS を整理するという観念とその設計の手がかりを得ることができるので、CSS に対する苦手意識や「なんとなくわかってるけど、よくわからない」感をだいぶ減らせると思います。

「Bootstrap のカスタマイズで十分間に合うから CSS を一から自分で書くとかほとんどしないしー」っていう方も、この本を読了すればどうして Bootstrap があのような設計で作られているのかがなんとなく理解できて、Bootstrap ってよくできているんだなぁと実感できるようになると思います。

僕も以前は「Bootstrap を使うとなんか HTML の class が bootstrap 臭くなって汚れる」とか思っていた方なのですが、Web アプリの CSS の設計という観点から見て非常に綺麗によくできているフレームワークなんだな、としみじみ感じさせられました。

あとは BEM とか SMACSS とか最近話題だからちょっと調べてはみたけど、あまり具体的なメリットがわからないな、っていう方は是非読んでみてください。 @ken_c_lo さん曰く、それぞれのフレームワークについてこれだけ網羅してきちんとわかりやすく書いてあるものは存在しない、とのことなのでデザイナさんのお墨付きと言っても過言ではないと思います。

あとは実案件でどうやってこの知識を活かせるか試すのみですが、「sass でなんとなくページごとにファイル分けときゃいいんじゃない?」なんて思っていた頃よりはきっと納得のいく設計ができるようになっていると思います。がんばります。

AWS CloudSearch を使ってみた

aws CloudSearch

Elasticsearch を調べたあと、最近は CloudSearch も機能強化されて日本語の検索も簡単にできていることを知り、いろいろ試して使ってみました。 結果、すごく良さそうなので今開発中のプロジェクトで採用することにしました。

調査しつついろいろコツというか知っておくべき点があったのでメモを残しておきます。 Elasticsearch との比較という観点で調査・検証していたので、Elasticsearch をある程度知った状態で読んでいただいた方がいいかも。

CloudSearch と Elasticsearch の比較

  • Elasticsearch ではシャード数は index 作成時に決定しなくてはならないが、CloudSearch なら自動でスケールアップしてくれる。
  • 検索のパフォーマンスに関しては Elasticserch でもあとから replica 追加可能なのでスケールアウト可能。しかし、インデックス更新のパフォーマンスは上げられない。
  • 日本語検索は両者とも ok
  • 特定の条件を重要視したスコアリングなども両者とも ok
  • CloudSearch の場合、インデックスの作成や構造を変更するとき (カラムの追加とか) にはかなり時間がかかる + 別途料金 (1GB あたり 0.98 USD) がかかるので注意が必要。

CloudSearch を使う上で知っておきたいこと

インデックスの更新について

  • インデックスの更新は "add" と "delete" の2種類で、それぞれ JSON をアップロードすることで更新する。
  • add は常に上書き更新となり、一部のカラムだけ更新とかはできない。
  • 複数の add, delete の操作をまとめて送ることができて(その単位をドキュメントバッチと呼ぶ)、なるべくドキュメントバッチのサイズ上限である 5MB に近いデータを送るようにした方がパフォーマンスがいいらしい。
    • 僕はいったん更新/削除用の json をデータベースに貯めておいて、一定時間おきに sidekiq で最大 5MB ずつのバッチに分けてアップロードしています。
  • json 以外のデータもアップロードできるらしいけど、そのユースケースが自分にはないので調べてないです。
  • インデックス上のドキュメントを識別するための id は ActiveRecord のオブジェクトの id でももちろん ok

料金体系

  • 次の 4つで課金されます。 -> インスタンス料金、ドキュメントの更新、インデックスの再構築、データ転送
  • うち、インスタンス料金以外はかなり安いので無視してもよさそう。
  • ちなみに最低で 0.082 * 24時間 * 30日 = $59.04/月 くらい (マルチAZ無し)

参考文献

Elasticsearch メモ

Elasticsearch

最近仕事で使いたいと思い、Elasticsearch で遊んだりしています。

$ brew install elasticsearch したらローカルで動いたのですが、そこから何すればいいのかさっぱりわからなかったので急がば回れということで本を読みました。

高速スケーラブル検索エンジン ElasticSearch Server

高速スケーラブル検索エンジン ElasticSearch Server

epub 版は以下から。

高速スケーラブル検索エンジン ElasticSearch Server【委託】 - 達人出版会

上記書籍は Elasticsearch 0.90.11 を元に書かれているので、実際に使う前に差分を公式のドキュメントで確認することをお勧めします。(そんなに大きくは変わってないですし、概念を学ぶにはぜひ書籍を)

雑多なメモ

elasticsearch-head

elasticsearch-head プラグインを使うとブラウザから elasticsearch の状態を見たり操作したりできます。これがないといちいち curlAPI を叩かないとクラスタの様子がわからない。

$ plugin -i mobz/elasticsearch-head # インストール
$ open http://localhost:9200/_plugin/head/

Rails から使うには

以下の gem を使う。ちなみに以前は tire という gem が主流のようでしたが、現在そのリポジトリkarmi/retire · GitHub という名前になって引退しています。(お茶目)

elasticsearch-model を使って、適切にインデックスの mapping をしたり query を組み立てたりすることができますが、デフォルトでは as_json メソッドの値をそのままインデックスに登録しているので、雑に使う分にはそれで十分かもしれません。

このへん。 https://github.com/elasticsearch/elasticsearch-rails/blob/4a61f1786696045561864567e0921db9b318aeaa/elasticsearch-model/lib/elasticsearch/model/serializing.rb#L26

あとは Article.search('title: hoge').records とかすれば、タイトルに hoge を含む検索結果に基づいて where id IN (1, 3, 4) みたいな SQL でレコードを取得できます。

ちゃんとインデックスを定義したい場合はモデルで mapping を定義して as_indexed_json をオーバーライドすることで Elasticsearch に登録する情報を定義したりできます。

クラスタリング

config/elasticsearch.yml の cluster.name が同じ elasticsearch の node がネットワーク上に存在すると、勝手にクラスタ化されます。すごいですね。 ちなみに Homebrew でインストールした場合は network.host: 127.0.0.1コメントアウトしないとクラスタに参加してくれませんでした。この辺検証するときは Vagrant でやるとか、公式からアーカイブ落としてきて起動するとかした方が楽かもしれません。

AWS 上で運用する際は以下のドキュメントが参考になります。 (node が参加するべきクラスタを EC2 API を叩いて探してくれたりする)

elasticsearch on ec2

ただ、このドキュメントだいぶ古いので注意が必要です。

シャード数はインデックス作成時にだけ指定できるみたいですが、レプリカ数はあとから足したり引いたりすることが可能なようです。 検索のパフォーマンスが足りなくなったなぁと思ったら増やす感じですね。

シャードやレプリカの配置は Elasticsearch に勝手配置してもらったり、任意の routing を定義したりもできるようです。

日本語全文検索

kuromoji というトークナイザーを使えば日本語での全文検索が可能です。

詳しくは以下。

パーフェクト Ruby on Rails を読んだ

読書 rails ruby

パーフェクトRuby on Rails を読みました。

いまさら!?という感じですが、しばらく仕事では iOS をメインでやっていたのですが、最近またサーバーサイドに戻ってきたそのタイミングで電子版が発売されたので。

ちなみに epub 版は 以下の URL から買えます。

Rails で仕事をしている人にはこの辺がオススメ

全体的には仕事、趣味を問わずバリバリ Rails を使っている人にこそ必要な本だなーという印象でした。 特に4章と9章が今後の自分の設計指針にとって非常に参考になりました。

4章の “Railsのロードパスとレイヤーの定義方法” は Model, View, Controller 以外の層 (Worker とか Service とか) を定義して使うための方法について書いてあります。ジョブキューでよく使われている sidekiq が例に出ているのでわかりやすくて実践的です。

そして9章の “より実践的なモデルの使い方” では4章で得た知識を使って、どうやって複雑になりがちな ActiveRecord::Base を継承したモデルを整理しきれいな設計をするか、という内容を具体的なコードを挙げながら説明してくれています。

rails がデフォルトで持っている app/models, app/controllers, app/views での MVC ではモデルないしコントローラが複雑になってしまってなんだかうまくいかないなーと感じている人は、ぜひ4章と9章を読んでみることをオススメします。

書籍とは関係ありませんが、最近 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) | TechRacho を読んで、自分が rails がデフォルトで作る models, controllers, view ならびに concerns に無理やりコードを収めようとし過ぎて、レールの下敷きになってしまっていたことにようやく気付き反省したところでした。 この パーフェクト Ruby on Rails を読んでさらに設計に対する姿勢を柔軟にすることができたと感じています。

Rails を勉強中の方にはこの辺がオススメ

6章の “Railsアプリケーション開発” は具体的なアプリケーションを実際に作りながら rails の機能をどのように使えばいいか、そしてどのようなところに気をつければいいか、について解説されている章です。

この章に従って一通りアプリケーション作りをしてみることは Getting Started with Rails — Ruby on Rails Guides (和訳: Railsをはじめよう — Ruby on Rails Guides) や Ruby on Rails Tutorial (3rd Ed.), Learn Web Development with Rails - Michael Hartl | Softcover.io (和訳: https://www.railstutorial.jp) を終えた人にとって非常によい練習になると思います。

この章を教材にすると中級者向けの Rails 講座とかやれそうですね。

まとめ

最近の Rails 周りの情報を一気にキャッチアップできるよい本だと思います。 読んでよかったです。

パーフェクトRuby on Rails

パーフェクトRuby on Rails