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

ボクココ

サービス開発を成功させるまでの歩み

Rails の render で部分的に動的な HTML を生成する

Rails JavaScript

ども、@kimihom です。

Rails で CSS フレームワークとかを使っていると、例えばモーダルウィンドウを出すためにヘッダやフッタで共通の HTML を使うことになるだろう。これらは大抵の場合、共通の UI となる。それでも当然、モーダル内の body の部分はそれぞれ別々の HTML を書けるようにしたい。そんな場合にどうしたらいいのかをご紹介しよう。

共通部分を 別 html で切り出そう

Rails といえば DRY(Don't Repeat Yourself)だ。同じコードをコピペするようなことはしてはならない。それは HTML でも同様のことだ。同じコードが出てくるようなら、まずは app/views/home/_modal.html.erbのように切り出そう。今回のHTML断片は Bulma を使ったモーダルの例。

modal.html.erb

<div class="modal <%= class_name %>">
  <div class="modal-background"></div>
  <div class="modal-card">
    <header class="modal-card-head">
      <p class="modal-card-title"><%= title %></p>
      <button class="delete"></button>
    </header>
    <section class="modal-card-body">
      <%= yield %>
    </section>
    <footer class="modal-card-foot">
      <a class="button is-primary action"><%= action_name %></a>
    </footer>
  </div>
</div>

そんで、呼び出し元の HTML を <%= render %> の引数とブロックで値とHTMLを引数として渡すことができる。

<%= render layout: "modal", locals: {
  class_name: "hello",
  title: "Hello World",
  action_name: "Agree"
} do %>
  <p> Are you agree? </p>
<% end %>

こうすれば、柔軟なモーダルがどんどんと量産することが可能だ。注意が必要なのは、renderlayout オプションで指定してあげること。こうしないとブロックを利用することができなかった。

あとは JavaScript 側で Modal を表示するような処理を書けばOKだ。

モーダル内容を JavaScript で動的に書き換える

まぁたいていの場合ってのはこのモーダル内容をさらに JavaScript で動的に表示したいということがあるだろう。 Rails の View 内でそれが完結できればいいが、 JavaScript 側の値で動的に表示したい場合は、modal 表示前のイベントをキャッチして、HTMLを書き換える必要がある。

  $(document).on("click", "#console-ctrl .open-modal", function() {
    var target = $(this).attr("data-modal");
    var attr = $(this).attr("data-modal-attribute");
    $target = $("#console-ctrl .modal." + target);
    $target.trigger("modal:before-open", attr);
    $target.addClass("is-active");
  });
  
  $(document).on("click", "#console-ctrl .modal .delete", function() {
    $("#console-ctrl .modal").removeClass("is-active");
  });

  $(document).on("modal:before-open", ".modal.hello", function(attr) {
     console.log("hello modal before open");
  });

こんな感じにしてあげれば、 モーダルを表示する HTML 側で共通で書くことができる。

<i class="fa fa-plus-circle add-person open-modal" data-modal="hello"></i>

このフォントをクリックすると、さっきの hello なモーダルが表示されるようになる。そしてその描画前に、modal:before-openのイベントが発火するようになる。

終わりに

特にCSSフレームワークとかを使っていると、共通な部分ってのはよく出てくる。これらをうまく共通化して、テンプレートとして保存するようにすればより美しく汎用性の高いコードを書くことが可能だ。

今回は jQuery の trigger を利用した。この trigger については以下の記事でご紹介しているので、もし知らなかった場合は調べておくと良いだろう。

今更ながら jQuery の trigger の魅力について語らせてもらう

Web サービス提供者は探求者であり続けよう

スタートアップ

ども、@kimihom です。

私は意志を持ったプロダクトが好きだ。そんなプロダクトを使いたいし応援したいし、何より作っていきたい。今回はそれを阻む問題について考えてみたい。

答えは自分の中にしかない

私は手当たり次第ユーザーに聞いてプロダクトに反映するのが嫌いだ。たとえ、それなりのユーザー数が求める機能であってもである。

そんなことを言うと、「ユーザーの意見も聞き、自分でも考えた結果の判断だ」と言う訳だけども、ユーザーの意見が判断材料の大きな要因になっていることは間違いない。私がなぜこの考えが嫌いなのかしばしお付き合いいただけたらと思う。

そもそも人に聞く時点で "自分たちの考えに自信がないです" って表明しているようなものだ。そんな意思やビジョンのないサービスを誰が使いたいと思うだろうか。自信がないなら、自分たちが自信を持てるように勉強や調査をするってのが先決のはずだ。誰よりもそれに詳しくなって、自分たちから新しい道を提案する。本来はそんなサービスを目指すべきだ。「自分たちはこの道が正しいと信じている。」自分たちが常にその先端にいることを自負し先導することで初めて、自らが新しい時代を築いていく人間になることができる。先導するような人間が、困ったらとりあえず人の意見を聞くようなことがあるだろうか(いや、ない)。彼らは自らが学んでそして考える"探求者"なのだ。

本当に成功した人ってのは概してワガママである。そのワガママについていけない人はどんどん辞めていって、信じてついてきてくれる人たちとだけで共に時代を切り開いていこうとする。そしてそういうサービスこそが真に成功するサービスになる。私はそんな環境を何度も目の当たりにしたことがある。独裁者並みの狂ったほどの強い意志を持った人が、プロダクトを会社をそして時代を先導していくのだ。

お金を払ってくれるのはユーザーだから、ユーザーが全て正しいというかもしれない。それは受託脳というか、目の前の利益にしか目がいっていない典型だと思う。その人だけが使うならそれでいいだろうし、人の意見を聞いて真面目に取り込むのはいいように見える。しかし不特定多数の人に提供しているサービスを運営しているなら、それをやってしまうと何の特徴もないサービスに仕上がっていく。ユーザーベースから出た答えなんて、統一性のかけらもない。ああでもないこうでもないと自分の都合のいいように語るだけだ。統一性を持った信念のあるサービスを作る唯一の方法は自分たちの考えのみに従ったサービスだけである。

この考え方は本当にユーザーを無視しているのだろうか?本当に独りよがりの考えで危険なのだろうか?私はそうは思わない。 反対に今の時代にユーザーから求められているのは、自分の考えを変えさせてくれるほどの強い信念の通ったプロダクトだと私は思っている。みんながあらゆることの正解が分からない中、「これだ!」と堂々と言ってくれる人についていきたいと思わないだろうか。たとえそれが無茶に見えたとしても信じ続けて実行する勇気や行動力こそが、あらゆる人々を魅了するのだ。

そんな極端すぎるほどの熱意がこもったサービスが日本からどんどん出てきてほしいし、自分のプロダクトはそうありたいと思っている。

考え続け、発信し続けよ

サービスに対する思いを誰にも伝えなかったら、なんでこんなサービスなのかって思われる。これは完全にミスマッチで、誰も幸せになることはできない。自分の思いを伝える機会をどんどん増やすことで、サービスの思いに共感していただいた方がユーザーとなってくれて、初めて関係者全員が幸せになることができる。

この記事は大してそんなに読まれることはないかもしれない。でも書かないよりは書いたほうがマシなんだ。今まさに、あなたがこの記事を読んでいただいているように。

ブログってのは誰もができる一番手軽な方法だ。それすらもやらずにただサービスを運営しているところは、自分たちの信念をどこで伝えるのだろうか。記事を書いて顧客に伝える努力をしない企業ってのは正直なところ理解に苦しむ。それすらも伝えないで顧客を獲得して、何が得られるというのだろう。

これは本当に辛く地味な作業の積み重ねだ。でも発信し続けることができれば、ベストマッチな顧客にめぐり合うことができる。成功のために与えられた答えや近道なんてないのさ。

オープンソース界隈で有名人になる方法

雑談

ども、@kimihom です。

f:id:cevid_cpp:20160820012330j:plain

今回 Github を中心とした OSS 界隈で有名になるいくつかの方法やメリットを挙げようと思う。私自身はまだまだ未熟者で、できていない部分もあるので、参考程度に読んでいただけたら幸いである。

OSS 界隈で有名になること

OSS界隈で有名になるとは具体的にどんなことかっていうと、「誰もが使っているライブラリを作った人」になるというのが端的な説明である。Ruby on Rails を作った DHH といったように、人気のOSS であればあるほどエンジニア界隈では知らない人はいないくらいなレベルに到達することができる。やがてそれに関しての勉強会やカンファレンスが開かれたりするようなレベルにまで達することもある。ギークなエンジニアの方々であれば憧れの一つとなるだろう。

んで、そうなるとどんな良いことが起こるかっていうと、自分が目指したソフトウェアを他の皆と作り上げることができるのである。これがソーシャルコーディングってやつだ。自分が欲しいと思った機能をプルリクエストによって他の誰かが作ってくれたり、バグを修正してくれたりするようになる。するといいプロジェクトはどんどんいいものになって、さらにみんなが使われるようになる循環が生まれる。

エンジニアのセルフブランディグとしての究極像だ。転職するときだけでなく、自らの自己紹介をするときに「あぁ、あのライブラリを作った方ですね」と思われるだけで一気に評価が高くなる。スペシャリストとしての信頼や信用が生まれ、特にフリーランスであればプレミアムな方として好待遇となることだろう。

オープンソースの作り方

よくある gem や npm ライブラリの作り方、みたいな方法論があるが、あれは結局最初の一歩を示しているだけであって、具体的にどんなものを作ればいいのかを示しているものではない。

私は優れたオープンソースを作るためには2つの方法があると考えている。

最も良い方法は、「自分のプロダクトの中で機能として分割できるものを分割して OSS 化する」ことである。まさに”副産物”という考え方にふさわしい。んで、これって作る最初の段階からある程度意識して作らないと、コアのシステムとライブラリが密結合してしまって切り出すことが困難になるので注意しよう。最初からモジュールとして分けて作るってのは難しいんだけども、作る前から意識するだけで 良い gem や npm ライブラリを公開できるのなら、検討する価値は十分にある。

2つ目に、新しい言語で他の言語の設計思想に基づいた新しいフレームワークを作ることである。ほとんどのプログラミング言語では Web アプリフレームワークがあるのと同じように、その他のあらゆるライブラリが存在する。例えば 機械学習や統計に強い Python のライブラリを Ruby クローンとして実装すれば、かなり有名な OSS 開発者になれる可能性がある。Python でできるなら Python 使えばいいやんって考える方々がほとんどな中で、それをやることに価値があるのである。今なら、 Elixir の Phoneix フレームワークの Rails クローンなライブラリを作れば、今後有名なOSS開発者になれるかもしれない。プログラミング Elixir も発売されるし!

プログラミングElixir

プログラミングElixir

日頃から発信することを意識しよう

んで、それを作っただけでは、他の誰でも知る機会を得ることができない。てことで、テクいブログをひたすら書き続けるってのが重要なアクションになる。その世界では読者数なんてのは関係なくて、ギークな一部の方々に好かれて読まれるような記事を書けばいいのである。自分の好き勝手に書いていいけど、「書き続けなければならない」っていう使命がある。

それすらもやらないと、いつまでもエンジニアとしての Value を高めることはできないだろう。

そうした日々の情報発信を通じて、いろいろなカンファレンスで発表する機会を得たり、何かの記事を書く機会を得たりすることができる。本を書くって方法もあるね。でもこれらはどうしても一時的な情報発信になてしまうので、やはりブログを書き続けるってのが一番大事なことだと私は考えている。

あとは英語。これは避けて通れない道である。日本語で書かれた Github の README は、日本語に特化した何かのライブラリでない限り誰も使おうとは思わないだろう。てことで OSS 界隈に足を踏み込んだら、真っ先に「英語をちゃんと勉強しておけばよかった」と後悔するパターンに陥る。今からでも遅くはない。私も頑張ってるので、共に頑張ろう。

終わりに

私自身が AWS Lambda を使ったオレオレバッチフレームワークを開発していて、これは他の人にも有用なんじゃないかと思うようになったことがきっかけで記事を書いた。腕の立つエンジニアってのは最初からそういうこと前提でソースコードを書いてるんだろうなぁと一つ思ったことがあって、自分への戒めとして書いている。

以上、自分/仕事へのマーケティングやブランディングとしてのオープンソース界隈で有名になることについての記事でした。

Increments ++ Tech Talk に参加してきた

Rails

ども、@kimihom です。

今日は今をときめく Tech 系スタートアップ Qiita さんにて開催されたIncrements ++ Tech Talkに参加した。個人的に最近 Rals 5 でアプリを作り始めていたのでちょうどいいタイミングでちょうどいいテーマだった。

connpass.com

個人メモなのでかなり端折ってるけどメモ内容を上げておく。

# Rails5
## WebSocket と ActionCable

シームレスなRailsインテグレーション
Rails::Engine をマウントする実装なのでWebSocketサーバーを切り離せる
Unicorn と EventMachine が相性が悪い
スケールを考えるとPuma必須

Rails 側で Channel を作成してJS側で購読
- bloadcast で Channel購読者に配信
- bloadcast_to で個別配信


高頻度イベントにまつわる状態は Redis が向いている
リアルタイムデータを Redis で保存して、永続化(ログアウトしたらとか)にデータベースに保存

## Rails 5 アップデート
attr_protected が使えなくなる
submit_tag の disable_with がデフォルトになる

active_record.warn_on_records_fetched_greater_than
たくさんのクエリ結果を返す時に警告を出す

accessed_fields メソッド
どの属性にアクセスしているかを調べられる
select で限定すればちょっとはやくなる


Drop jQuery as a dependency!!
> これヤベェw

ActiveJob の再実行がよりスマートになった

ActionCable は趣味アプリでどんどん使っていくには面白く使えそうだ。たくさんリクエストを裁くことを考え始めるとまだどうなることやら、といったところ。自分がリアルタイム系のを作るんだったら Firebase か Twilio Sync を使うだろうなぁ。餅は餅屋ってやつ?何でもかんでも Rails でやらせるってのは判断に迷うところである。

Rails 5のアップデートに関しては、自分の本業の Rails アプリは 4.1 から作り始めたプロダクトだからあまりアップグレードは大変ではなさそう。それよりも関連Gem のアップデートの方がまだ安全にアップグレードするには時間がかかりそうな感じである。てことでわざわざ荒削りな レールを渡る必要はまだ特にないかなー。

Rails 5.1 で jQuery なくそうぜ 的な話が上がってるのが個人的には割と困るw 自分のコードだけ無くせばいいって話ではなくて jQuery プラグインもどうするかってのを考え出すと、こりゃあ困ったといったところである。 ただ新しい JavaScript は jQuery っぽい書き方が簡単にできて、もはやブラウザ間の誤差も気にならなくなってきたからという背景があるようなので、それらのライブラリも次第に jQuery に依存しない シンプルな JavaScript ライブラリになることだろう。てことできっと時間が解決してくれるだろう、といったところ。

今は ActiveJob とかのバックグランドタスクは全部 AWS Lambda に投げとばしてるんだけど、 DB絡めるところとかが Node.js で SQL 叩くよりかは ActiveRecord で扱えた方が楽だなぁと思うときはある。てことで ActiveJob の利用はそのうち(いつになるかは不明)検討しようと思っている。

俺と David

今日は DHH に思いを巡らせる日にもなった。この写真を拾い出してきた。ちなみに DHH の左が私ねw この笑顔よ。そりゃ嬉しいよね!

f:id:cevid_cpp:20160819000918j:plain

んで懇親会を話している中で、 Rails が好きなだけでなく、 Bascamp の運営や思想そのものに共感している方々がいることに感銘を受けた。 Rails は スモールチームが適切なシステムを作れるようになるために存在するのである。

このスレッドはかなり面白くて micro serivce についての DHH の考えも言及されてある。

こんな そもそもの "Why Rails" のお話や、「小さなチーム大きな仕事」って本を何回も読んで勉強して Rails でスモールチームで 革新的な Webサービスを作ろうとしている方だったり素晴らしい同志とも言える方に会うことができて嬉しかった。

あとは 各地で開催されている ~~.rb 系の勉強会にも機会があれば参加してみようと思った。割とああいうのって初見が1人で行くのは気が進まなかったけど、やっぱり一人で rails とかで悩むよりかは、それを共有してみんなで解決していく。他の誰かが悩んでいた時は私も考えることができるし. そういったことがコミュニティのより良い関係を築くことができるのだろう。

イベントレポートまでが勉強会ってことで、今回はそんな感じの素晴らしい勉強会でした。

エンジニアの副収入を得る方法の選択肢

スタートアップ

ども、@kimihom です。

f:id:cevid_cpp:20151109120202j:plain

せっかく技術を持っているエンジニアたるもの、その技術を使って何か副収入を得られるようなものを作れたら何といいことだろう。誰にも指図を受けず、自分の作りたいものを作って、それがお金に換わる。そんな夢を目指して試行錯誤していることかと思う。かくいう私も何かしらの副収入って意味でいろいろとトライした経験がある。そんなわけで私が実際に試したそれぞれの方法と結果について記してみよう。

アプリを作る

真っ先に思いつくのはこれだよね。iPhone/Android アプリを作って一発を狙う作戦だ。アプリ開発の経験があるのなら、100万DL くらいされれば広告収入だけでも最低限の生活費は稼げるくらいにはできる。アプリ市場は満杯だと思ってあきらめる必要はない。それと同じくらい人々は個々のアプリを「飽きる」からである。何か新鮮味のあるアプリを作り、人々の心を捉え、拡散できる仕組みを作れば不可能なことではない。

実際のところ、私はアプリ開発が最も副収入としてうまくいっている。大した額ではないが、趣味で作ったレベルで小銭が入ってくるのなら有難いことこの上ない。アプリ開発は、自分のスキルの腕磨きの場として、ある時は仕事で使う新テクノロジーの実験の場として多いに役立つ。

個人でアプリ開発をするのなら、3つのことに気をつけよう。

一つは拡散できるコンテンツを徹底的に考えること。拡散できるコンテンツを用意すれば、ユーザーは Twitter や Facebook でシェアをしてくれる。そのシェアが新しいユーザーを勝手に呼んでくれて、広告費を一切かけずともユーザーを獲得できる。何かアプリで達成感を味わえるような何かは拡散してもらいやすい。まぁそもそも拡散したくなるようないいアプリを作ることは大前提だけども。

二つ目に、定期的に使いたくなるアプリを作ることだ。副収入ってことはクレカ取引とかするようなサービスは作りにくい(クレカ審査で法人登録が必要)。なので広告収入に頼ることになる。てなるといかにユーザーがアプリを開き続けて、その広告を見てくれるかが大事になってくる。1回開いて楽しめば終わり、というアプリや、月に一回くらいしか開く場面が想定できないようなアプリはうまくいかない。"〜する時にこのアプリを開く" という何かしらの理由付けが出来るアプリこそがあなたが作るべきアプリだ。

そして最後に、検索ワードを考えよう。これは1つ目の拡散に近いものがあるけど、たいていのユーザーは AppStore や GooglePlay で何かしらのワードを検索してそれを入れる。当然のことながら上位に来れば来るほど、レビューが高ければ高いほどダウンロードの確率は高まる。ただし、ありきたりなワードでは当然検索にすら引っかからないので、ニッチなワードを徹底的に考えてアプリ検索の最適化を行おう。

以上3つのことを満たしたアプリが一人で作れたら、なかなかいけてる副収入になることだろう。

ブログを書く

次に思いつくのはやはりブログだろう。純粋に自分の勉強したことをブログに書いて、読者が増えて広告収入が入れば良いことづくしである。これはアプリには敵わないし、ある程度上限も決まってるけども、ちゃんと続ければ確実に効果があると言える。

ではブログを書く上で注意すべき点を挙げてみよう。

1つ目に必ず更新を続けることだ。エンジニアが書くブログってのは大抵3年も経てば古臭くで誰も読まない価値のないコンテンツになりがちだ。だから常に最新を追ってそれを試し、ブログに細かくまとめていくことが大事だ。新技術の概要をざっくりと知りたい時に、基本的な内容を知るために検索をする人が母数としては圧倒的に多い。スペシャリスト向けはブログで稼ぎたいのならやるべきではない。

2つ目に収入を目的にしないことが大切だ。いきなり収入目的でブログを書くと、1年経っても100円にも満たないのはザラにあるので絶対続かない。それ以外のブログを書き続けられるモチベーションを持とう。私は人に何かを教えるのが好きなので、今読んで頂いているあなたに「教える」ということを意識することで続けることができている。

私の場合は継続して記事を書き続けてそれなりに読者が増えたとはいえ、収入という意味ではアプリの10分の1くらいだ。ブログを書くってのはその程度と思ったほうがいいだろう。

CtoC 系サービスを活用する

最近流行りの CtoC でプログラミングや設計の相談に乗ってあげて収入を得ることができる。または 外出中に Airbnb で部屋を提供することもできるだろう。新しい働き方として今とても注目されている方法だ。

CtoC 系サービスを幾つか利用している身としては、サービスによってはとても良いものだったりするのでまずは試しに使ってみるということが大事だ。それで自分に合わなかったら使わない。クソなCtoCサービスは退会しても迷惑メールを送ったりしてくるけども、最悪でもその程度なので試してみる価値はある。

ただしほとんどの場合は何かのついでというよりかは、そのために時間を割く必要が出てくるのでパフォーマンス的には劣るものがある。その分ちゃんと顧客に価値を提供できれば定期的に確実に収入を得られる方法になりうるだろう。基本的にはどのCtoCもレビューの仕組みがあるので、いいレビューをキープし続けるための努力を惜しまないことが大事だ。

何か自分の中で「もったいない」と思えるリソースを持っていて、それを提供できそうなCtoCサービスがないか探してみよう。意外と見つかるものだ。

終わりに

今回はとてもオーソドックスな3つの方法について掲示した。どれもこれも大切なのは「信じて続ける」ってこと。そうしないと評判を生み出せないので、違うことに浮気するといつまでたっても探し続けるような感じになってしまうだろう。

副収入を得るってことは社会的にも勉強になるし、実際の仕事にも活きてくる。自分に合った方法で頑張ってみていただきたい。

Rails5 でフロントエンドを綺麗に扱う方法を考えてみた

Rails

ども、@kimihom です。

SMAP解散騒動が騒がれる中、新規プロジェクトとして Rails 5 のプロジェクトで色々と遊んでみている。その中でフロントエンドの部分の書き方で自分なりに答えを出しながらやっているので、そこの方法をシェアしようと思う。

JavaScript の書き方

まず、最近よくあるフロントエンドのツール(BrowserifyやWebpack, grunt や gulpなど)は使わない想定。あくまで Rails の提供する範囲内で 最大限 JavaScript を美しく保つ方法を記す。

最初はapplication.html.erb のレイアウトから。

<head>
  <title>My App</title>
  <%= csrf_meta_tags %>
  <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
  <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>

  <!-- CDN -->
  <script src="//....js"></script>
  <!-- app -->
  <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>

</head>

CDN から読み込む系の JavaScript は、jQuery に依存しない JavaScript コードだけを読み込むようにするのが注意。jQuery に依存する場合はapp/assets/javascripts/vendorディレクトリに突っ込む必要がある。jQuery の読み込みは application.js の方でやるため、順番が後になってしまうからである。それさえ気をつければ CDN は1行で読み込みが完了して楽なので積極的に利用していいと思う。

この方法はシンプルが故の欠点があって、JS ライブラリの依存関係とかそういうのを考えないような設計になる。そのため、今後のアップデートで他のライブラリが動かなくなるんじゃないかとかそういう心配をする方にはお勧めできないのかもしれない。ただ、手軽さで言えば断トツでこの方法だろう。

さて、続いて application.js へ移ろう。これは割とシンプルで Rails 搭載の JSライブラリ、外から持ってきたJSライブラリ、自分のJavaScript ファイルの順番で読み込む感じになる。

//= require jquery
//= require jquery_ujs
//= require turbolinks
//= require_directory ./vendor
//= require_directory ./main

続いて個々の JavaScript の書き方。だいたいのイメージがつかめるように、特に意味のないコードを含めている。

let ConsoleCtrl = (function(){
  var localVariable;
  
  function privateFunc() {
    localVariable = "local";
  }

  $(document).on("click", "#console .btn", function() {
    localVariable = "clicked";
  })  

  return {
    publicFunc: function() {
      return localVariable;
    }
  };
}());

いくつか大事な点がある。まず一つ目に(function() {...}()) でくくることで、JavaScript スコープをこのファイル内にとどめるようにしている。結局 Rails は作ったファイルを一つに統合するので、何も考えないでコードを書くと JavaScript のグローバル領域を汚染することになるのだ。function でくくることで、グローバルになるのは、ConsoleCtrl だけになる。そんでlocalVariableを外のJavaScript ファイルから読み込みたい場合は、return で関数を含んだオブジェクトを返すことで対応できる。こうすれば ConsoleCtrl.publicFunc() でメソッドを呼び出すことが可能だ。

そして、 jQuery の書き方は基本的にすべて$(document).on(~~) の書き方になる。これは HTML が常に動的に書き換わるため、ロード完了後のHTMLだけのイベントしか定義できない $("#elem").click(~) の書き方は正しく動作しないためだ。一見動作が遅くなるように見えるけども、何十個もこの書き方をしても、ほとんど速度に関して違和感を感じることはない。

あと最後に、ページを初期化した時に呼びたい JavaScript があった場合にどうするかって話なんだけども、これは jQuery の trigger を使うことで対応している。 Turbolinks にも各種イベントがあるんだけども、全部の JS ファイルに依存するイベントになるので採用しなかった。では実際にどうするのかっていうと、HTMLに triggerを記述する。こんな感じ

<!--  HTML  -->

<script>
  $("#main-ctrl").trigger("main:loaded")
</script>

んで JavaScript 側に通常と同じようにイベントを定義してあげる。

$(document).on("main:loaded", "#main-ctrl", function() {...})

"初期化イベント"っていうくくりで初期化ができるので、割と直感的になっていると思う。

CSSの書き方

これは別に rails 5 に限った話じゃないんだけども、普通に application.css.scss 通りに書くと、変数の読み込みがうまくいかなかったり、Sass をうまく使いこなせていない感がある。てことで、ちゃんと Sass を使う方法として以下のようにしている。

まず application.cssapplication.css.scssに書き換える。そんで以下のようにすべて importでファイルを読み込んでいる。

@import "bulma/bulma.sass";
@import "partials/*";

今回は CSS フレームワークの bulma を使った例。bulma は Sass ファイルのテンプレートを用意してくれてるので、そこに用意されている変数も app/assets/stylesheets/partials ディレクトリ内のすべてのファイルで読み込むことが可能だ。

JavaScript も Stylesheet も、開発時にはキャッシュが効いてしまって色々と面倒なことになりがちなので必ず開発者ツールを起動してキャッシュがかからなくするようにすること。

終わりに

いつまでも Rails のフロントエンドの議論は尽きない。方法は人それぞれだと思うので参考程度にしてみていただけたらと思う。自分のアプリの場合、Gmail のような1ページで収まるシングルページなので、Turbolinks の恩恵はあまり受けないかもしれない。引き続き Rails 5 を触ってみて、Turbolinks 5 や ActionCable などで有用な情報が見つかればシェアしていきたいと思う。

Heroku Dataclips だけで管理画面もどきを作ってる話

Heroku

ども、@kimihom です。

f:id:cevid_cpp:20160809214545j:plain

今回はみんな大好き Heroku の中の Heroku Postgres について。Heroku Postgres を使えば、データベースに関する操作をクラウド上で限りなく簡単にSQLコマンドを実行やデータの移行を行うことができる。

そして今回紹介する Heroku Dataclips を使えば、管理画面っぽいのを気軽に作成することができるので紹介しよう。

Heroku Dataclips とは

Heroku Dataclips とは Web 上で実行可能な SQL 文をまとめられるサービスのことだ。例えば、ユーザーのメールアドレスリストを抽出するリストを予め Dataclips として SQL 文を作っておけば、チームの他のメンバーは SQL を書かなくても Dataclips の URL を知っていれば簡単にユーザーリストを取ってくることができるようになる。もちろんその編集も Web 上で行えるので、何かちょっと条件を加えたいと言った時も専用の pg コマンドなどを打たなくても Web 上で編集が可能だ。つまり誰でも SQL 文の書き方を学べば、ブラウザ上で好きなようにデータをアクセスすることが可能になる。

Heroku Dataclips で管理情報の取得

Heroku Dataclips のおかげで、わざわざ情報表示のために専用の Gem を入れたり管理画面を作っていたような煩わしさからは解放される。Heroku アカウントを持っていれば、ここにアクセスできるかと思う。

私の場合は、何かシステムトラブルが起きた時などでユーザーのメールアドレスを拾って情報をすぐに提供できるように、Dataclips にSQL処理をまとめている。Heroku にログインさえすれば、エンジニアじゃなくてもユーザーの最新情報を取得できるようにした。今までは Rails の rake タスクを heroku run コマンドで実行していたが、こっちならリンククリックで一発だ!

f:id:cevid_cpp:20160809220303p:plain

他にも、参照系だけで済む管理画面の場合は積極的に Dataclips に書き出すようにしよう。Dataclips が増えれば増えるほどサービス関係者は情報を容易に取得できるようになる。みんなが SQL を学べば、誰でも欲しい情報をいつでも取ってこれるような環境を実現することだってできる。

ところでRails で書くと 複雑に入り組んだ長い SQL を書くなんてことはあまりしなくなるのだけども、生 SQL は頑張って出力したい結果が出せた時の喜びがあって良い。パズルみたいに組み合わせて作り上げられるのが SQL の面白いところだよね。

ちなみに作った Dataclips の URL の末尾に .json の拡張子をつけるだけで、JSONの結果を返すこともできる。API のモック用のレスポンスとしての使い方を想定しているみたいだけど、そんなのやるくらいだったらちゃんと API のコードを書いてからやればいいだけだと思うので、個人的にはあまり利用しないかなといったところ。

Dataclips の注意点

注意点として、 Free と Hobby プランの Heroku Postgres にはユーザー認可の仕組みがないので、URLを知っている人なら誰でもアクセスできてしまう点がある。なので機密情報を Dataclips としてまとめたいなら、 Standard 以上のプランに上げる必要がある。$50 にすれば Hobby に比べて一気にできることが増えるので、それなりのサービスを運営しているなら早めに Standard に上げるべきである。

終わりに

管理画面の作成に時間をかけるくらいだったら、ユーザーの価値あるものの開発に時間を注ごう! 管理画面は Dataclips などの ツールを駆使していかに手軽に早く欲しい情報をゲットできるかの勝負だ。そこに HTML や CSS などで調整するなんてことはそもそも必要ないはずだ。更新処理などもできるだけ rake タスクなどで自動化し、コマンド一発で更新できるようにしよう。

てことでこの後やるべきことは、 Heroku Postgres を使っているなら早めに Standard に上げて、Dataclips をどんどん作っていくってことだ。