satococoa's blog

主にサーバーサイド、Web 系エンジニアのブログです。Go, Ruby, React, GCP, ...etc.

Reactとかgulpとかfirebaseとか色々いじってみた

色々一気にやりすぎてちょっとパンク気味ですが、以下のリポジトリにおいて最近興味があったものを色々試してみました。 iOSAPIサーバの仕事ばかりやっている間に大きく遅れてしまったWebのフロントエンド技術にキャッチアップしたいというのが狙いです。

satococoa/react-firebase-chat · GitHub

今できているものは単純なチャットアプリみたいなものです。ページングとかは手を抜いています。

試してみたこと一覧

Reactは最近流行りのJSのライブラリですね。最近仕事でVue.jsを導入してみてとても良い感触を得ているのですが、それと比べてどうなんだろう?という比較もしたいと思い。

FirebaseはいわゆるMBaaSの一つで、だいたいParseと同等の機能があるようですね。FirebaseがGoogleに買収されたことから興味を持ったのでした。

Web Starter KitはGoogleが公開しているWebのベストプラクティス集であるWeb Fundamentalsを元にした静的Webサイトのテンプレート(boilerplate)ですね。HTMLのテンプレート+UIコンポーネント+gulpタスクって感じです。

BourbonはSASSのフレームワークです。仕事ではCompassとかBootstrapとかを使っているのですが、他のものも一応知っておきたいなと思い。

感想

React良さそう

コードはほとんど Tutorial | React にあるものを真似てサーバとのやりとり部分をFirebaseのAPIに置き換えただけのものなのですが、それだけでもReactいいなぁという感触を得ました。特に以下のあたりが好みです。

  • stateとpropという概念で、Model (ViewModel?) が持つ状態と属性がはっきり分かれている
  • コンポーネントという単位への分割と再利用がわかりやすい
  • ドキュメントが豊富

唯一気持ち悪いと思うのが、JSのrenderメソッド内にべたっとHTMLを書いちゃうところですが、コンポーネントを構成するロジックとviewとが一箇所でカプセル化されていると考えればまぁ、アリなのかもしれません。

JSXのコンパイルとか既存ライブラリとの共存とかが難しそうなので、ガッツリJSでガリガリ動くアプリを書くときはReact、そうではなくて便利なViewModelが欲しいだけならVue.jsといった使い分けが個人的にはしっくりきています。

Firebase良さそう

特にはまりどころもなくすんなり使うことができました。提供されている機能はほぼParseと同等ですが、料金体系が結構違うのでアプリの性質によって使い分けるのが良さそうです。Parseはリクエスト数による課金、Firebaseは同時接続数による課金というざっくりしたイメージです。

今回作ったサンプルプロジェクトはfirebaseのhosting機能を使ってデプロイしています。静的ファイルを置くだけだからかもしれませんが、全くハマることなくすんなりデプロイできました。

Bourbon良さそう

Compass と比べても遜色ないと思います。ドキュメントもわかりやすく、機能的にもFlexboxとかAnimation、Modular Scaleなんかもサポートしているので十分使えそうです。

また、Bourbonベースで作れらたneatというグリッドフレームワークbittersというスタイル集もbootstrapほど何でも揃っている感じではありませんが、自前でスタイルをある程度頑張るつもりであれば足がかりとして使えそうな印象を持ちました。

gulpつらい

Web Starter Kit には最初からgulpのタスクが付いています。そのまま使うのなら良いのですがデフォルトで既に秘伝のタレ化していて、理解するのが若干辛かったです。具体的にはJSXをコンパイルするタスクを挟み込むのに結構苦労してしまいました。 middlemanとかを使ってrubyのasset pipelineに逃げたくなりました。 調べれば調べるほど、webpackだとかbrowserifyとかいろんなツールが出てきて大混乱でした。実際、今回のサンプルプロジェクトを作るにあたってFirebaseやReactでは全くハマらず、gulpで無駄に時間を費やしてヤクの毛刈りしている気分でした。

個人的には npm run を使う方法の方が gulp のお作法を覚えるよりもシンプルで unix 的だなーと今のところは感じています。 参考: npm で依存もタスクも一元化する - Qiita

モバイルデザインパターン 第2版を読んだ

アプリ開発者として UI デザインについてもより理解を深めたいと思い、モバイルデザインパターン第2版を読みました。 職業柄普通の人よりはたくさんのアプリを試しているつもりではありますが、iOS 以外のプラットフォームだったり、英語圏のアプリだったりはあまり試せているわけではないので、もう少し包括的にトレンドを知っておきたいなーくらいの気持ちで。

どんな本?

モバイルアプリ (ネイティブアプリが前提) の UI について実際のアプリのスクリーンショットを見ながら様々な実装パターンを紹介している本です。 読み物というよりは UI カタログみたいな感じだと思って購入すると丁度良いと思います。 ありがちなアンチパターンも掲載されていて、耳が痛いというか「あちゃー。。。」って何回も思いながら読み進めました(笑) ネビゲーション、フォーム、テーブル... といったようにカテゴリ分けして掲載されているので、UI 設計をしながら必要な項目だけつまみ食いして読むのも良いと思います。

また、OS は iOSAndroidWindows Phone をカバーしています。

それぞれの UI 設計についての原則 (iOSiOSヒューマンインターフェイスガイドライン とか AndroidMaterial design とか) の詳細は各公式ドキュメントを参照して知識を補った方がいいと思いますが、ちゃんとそれらを踏まえた上での解説になっているのでためになります。

誰にオススメ

デザイナだけじゃなく、ネイティブアプリを作っている人なら職種問わず手元に置いておきたい本だと思います。 UI について設計するときの共通理解を深め共通言語を増やす目的では、チームで頻繁に参照できるようにしておくと効率が良いかと思います。 僕の勤める イグニス でも会社の本として購入してもらいました。

デザイナ・プロデューサ視点では「技術的にどんなことが可能なのか」を知るいい資料となりますし、エンジニア視点では UI に関する提案力を手っ取り早く上げることができると思います。

しかし、贅沢を言えばこれは電子版で欲しいところです。。。

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

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

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

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

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

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

読書会って何?

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

そして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設計の教科書を読んだ

久しぶりに仕事で 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 を使ってみた

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無し)

参考文献