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

pblog

pplog.net を作っている @ppworks こと越川直人(Koshikawa Naoto)のブログ

esaカテゴリで検索したり統合したり投稿したりするときのTips

esa

やあだね、esa使っているかい?

カテゴリあんじゃん、あれさ、増えてくるとわけわかんなくね?えっとどの辺にあったっけみたいなアレ。 後逆にどこのカテゴリに投稿しよう、、、みたいな気持ちになるアレ。

便利な検索

検索窓におもむろにin:って入力しようぜ。

f:id:naoto5959:20160621093214p:plain

こんな感じで候補が出るので、カテゴリ名を部分一致で検索できる。

例えば、「吉成」が含まれるカテゴリを検索したい場合、検索窓に「in:吉成」と入力すると

f:id:naoto5959:20160621094542p:plain

ほら便利!でも「吉成」が散らばっていることも分かったね。

ちらばったカテゴリを整理だ

  • イベント/吉成

は階層構造的にこれでいいかなと思うけど

  • ポエム/吉成
  • 吉成/ポエム

これはどっちかに寄せたいな。

吉成/ポエム -> ポエム/吉成

に出来るとヨサソウ。んではやってみよう。吉成/ポエムを開いて、カテゴリ名の横の鉛筆をクリック。

f:id:naoto5959:20160621094310p:plain

フォームに変わるので、ポエム/吉成に変更してUpdateする。

f:id:naoto5959:20160621094500p:plain

すると、2つカテゴリがマージされるのです(( ⁰⊖⁰)/)

f:id:naoto5959:20160621094644p:plain

便利っすねー

カテゴリに投稿する

ついでにポエみが高まってきたのでポエム書いておこう。 てなわけで、ポエムカテゴリに移動。

f:id:naoto5959:20160621094850p:plain

右上の[Create new post here]をくりっくだ。

すると、そのカテゴリに設定されたテンプレートがいい感じに反映されて記事投稿フォームが表示される。

f:id:naoto5959:20160621094948p:plain

便利っすね〜、つーかなんでテンプレート適用されてんだよって感じなんですが、templates/ポエム/ナンカタイトル

f:id:naoto5959:20160621095026p:plain

こんな感じでカテゴリ切ったテンプレートを用意してあるとそれがよしなに適用されるんですよね。

まとめ

esa並びに情報は生き物なので定期的にメンテナンスが必要だし、もっというとカテゴリは整理整頓が必要だなと思うのでesaトロールオジサンが組織に最低1人居ると良いと思うんだよね。

(( ⁰⊖⁰)/)ーな

pplogがキッカケで形になった本があるらしい #わかばちゃんと学ぶwebサイト制作の基本

pplog

pplogがキッカケ?

まじかよッて感じでずっと楽しみにしていた本がやっと届いた!

ので読みました。読みながらの感想はツイッターに書いてたのでその辺を適当に貼っておく。

まとめ

Webデザインという単語は、知っていて何となくカッコイイし興味を持っている人が、Webサイト制作〜運用までの一連の流れを知る取っ掛かりとしては、すごく良くまとまっていると思った。

Webサイトを作る目的をマーケティング視点で考えてからサイトを作り始める流れもちゃんと押さえつつ、最後には運用時のマーケティングにも触れててヨカッタ。

もしかしたら、子供とかにお父さん(やお母さん)はこういう仕事しているんだっていう説明をザックリする時とかにも良いかもしれない。

たぶん、インターネットの事業会社でもクリエイター以外の人がザックリとインターネットのシステムがどうやって動いているのかなどを知る意味でもスゴくいいなと思った。つまりウチの会社とかでもオススメできる内容かなと思ったのと、湊川さんがこの本を引っさげて新人研修の導入とかしに行くとかいう未来も見えた。ヨサソウ。

随所に割と大事なことがサラッと書いてあって、例えばノンデザイナーズ・デザインブックに書いてあるようなこと。割と頭の中でこうやって整理して理解するわな、みたいなことを綺麗にとめてて、ポイント高い。図解が多いのも、そういう理解するときにこうやるよなーという図が最初から書いてある。だからサラッとしてるのにスッと大事なことが入ってくる。

pplogってのは、

自分の思いを好きなように書ける場所が欲しい。 引用元: 俺たちのゆるふわインターネット「pplog」 をリリースしました(してました) - 納豆には卵を入れる派です。

という想いで作った なので、そこで何か思考が整理されたり、何かを始めるキッカケになったり人生の何かが変わるってのはは自分自身でも本当によくある。自分の作ったそういう場所で同じ想いを感じてくれたことがただ純粋に嬉しい。pplogでポエム書いたおかげでナニカを始めようと思った、みたいなことがただただ嬉しい。ありがとう。

Rubyちゃんが登場してたので、Railsちゃんを見てみたいな。「わかばちゃんと学ぶRuby on Rails」だな。

わかばちゃんと学ぶ Webサイト制作の基本

わかばちゃんと学ぶ Webサイト制作の基本

trelloのboardにwebhookを登録する

雑なWebhook Docsの先にあるAPI referenceも、そっすね、という感想しか湧かないドキュメントで、まあ読めば分かるだけどさって感じ。

てなわけで、どう考えても忘れるので、Webhook登録するだけの作業をまとめておく。

ちなみに、この作業では、https://github.com/jeremytregunna/ruby-trello を使う。

gemをinstall

cd ~
mkdir setup_trello_integration && cd setup_trello_integration
bundle init
echo "gem 'ruby-trello'
gem 'launchy'" >> Gemfile
bundle

下準備

bundle exec irb
require 'trello'
Trello.open_public_key_url # API key が表示される以下で渡すkeyはコレ
Trello.open_authorization_url key: 'yourpublickey'
exit

Trello.open_public_key_urlで表示される画面はこんな。ここのKEYを使うので覚えておこう。

f:id:naoto5959:20160402003946p:plain

Trello.open_authorization_url key: 'yourpublickey'で表示される画面はこんな。OAuthのアレ。よろしければ、Allowを。

f:id:naoto5959:20160402003958p:plain

TOKENが表示されるので、こやつを後で使う。

f:id:naoto5959:20160402004008p:plain

webhookを作る

環境変数に、先ほど最初に取得したKEYと最後に取得したTOKENを指定。

echo "export TRELLO_DEVELOPER_PUBLIC_KEY=************************\nexport TRELLO_MEMBER_TOKEN=*********************************************" > .envrc
direnv allow
bundle exec irb
require 'trello'

Trello.configure do |config|
  config.developer_public_key = ENV['TRELLO_DEVELOPER_PUBLIC_KEY']
  config.member_token = ENV['TRELLO_MEMBER_TOKEN']
end

board_id = Trello::Board.find('****').id # TrelloのURLの`/b/:board_shortlink/*`の:board_shortlinkの部分でboardを探す

callback_url = 'http://example.com' # 普段はPOSTで来るが、Webhook登録時はHEADに200を返すようにしておくこと。
webhook = Trello::Webhook.create(callback_url: callback_url, id_model: board_id)
webhook.id # 設定変更したい場合などに使うのでメモっておく

コメントに書いたとおり、受け側のwebhookは初回だけHEADリクエストに200を返す必要がある。なんなの。

わからん

webhookのid忘れたらどうなっちゃうわけ?

githubやesaのmentionをslackでmentionするよ

heroku github esa slack

f:id:naoto5959:20160319010013p:plain

githubesaでmentionがあったら、slackbotにこんな感じのmentionを飛ばさせたいんですよ。

f:id:naoto5959:20160319004631p:plain

やむを得ない理由だったり、ナンカついウッカリだったりで

  • githubとslackのidが違う
  • esaとslackのidが違う

なんてことが、あったりなかったりするわけですが、そんな時でも

-
  github: ppworks
  esa: koshikawa_naoto
  slack: koshikawa.naoto

みたいなidのmappingがあれば

  • githubのmentionをslackで通知
  • esaのmentionをslackで通知

することが出来るんじゃないかなーと思って作ってみました。heroku buttonでササッと構築したかったのでなるべくDBを使わずに設定ができるようにしています。

準備

github.com

へアクセスして、heroku buttonをクリックします。herokuではないどこかにホスティングしたい場合は、怪しげな英語のナニカで書かれたREADMEにそれっぽいことが書いてあります。

heroku buttonで入力を促される以下の環境変数にいろいろ設定していきます。

  • MENTIONS_MAPPINGS_FIlE_PATH
  • SLACK_WEBHOOK_URL
  • GITHUB_TO_SLACK_TOKEN
  • ESA_TO_SLACK_TOKEN

MENTIONS_MAPPINGS_FIlE_PATH

以下の様な感じの、githubesaとslackのmappingをしたyamlファイルを置いたgist(ちゃんとrawにしてね)などのURLを記載します。

-
  github: ppworks
  esa: koshikawa_naoto
  slack: koshikawa.naoto

たとえば、こんな。

https://gist.githubusercontent.com/ppworks/49f6ce44efb09d5fc8e9/raw

SLACK_WEBHOOK_URL

通知したいslackのIncoming WebHooksを作って、埋めます。

たとえば、こんな。

https://hooks.slack.com/services/xxxxxx/yyyyyy/zzzzzz

GITHUB_TO_SLACK_TOKEN

githubのmentionをslackに通知したい場合埋めて下さい。

ruby -r 'securerandom' -e 'puts SecureRandom.hex'

の結果などを入れるとよいです。

githubに設定すべきwebhookは以下のようになります。

https://your-heroku-application-name.herokuapp.com/webhooks/**ここが今作ったtoken**

githubでは以下の様なEventにhookするようにwebhookを設定して下さい。

githubのwebhook設定

  • githubのissue, pull requestでmentionされたとき
  • githubのissue, pull requestでassignされたとき

mappingが存在すれば、slackにslackbotの個別チャットでmentionが飛びます。

f:id:naoto5959:20160319004539p:plain

ESA_TO_SLACK_TOKEN

esaのmentionをslackに通知したい場合埋めて下さい。

ruby -r 'securerandom' -e 'puts SecureRandom.hex'

の結果などを入れるとよいです。

githubに設定すべきwebhookは以下のようになります。

https://your-heroku-application-name.herokuapp.com/webhooks/**ここが今作ったtoken**

esaでは以下の様なEventにhookするようにwebhookを設定して下さい。

esaのwebhook設定

  • esaのpost, commentでmentionされたとき

mappingが存在すれば、slackにslackbotの個別チャットでmentionが飛びます。

f:id:naoto5959:20160319004631p:plain

@allのときは、#general@everyone宛のmentionが飛びます。

感想

ウッカリ勢いで意味もなくRails5で作ってしまったけども、今のところそれなりに便利に運用出来ているのでよしとする。

割と便利です。

要望とかはPR頂ければ喜びますので、何卒(\( ⁰⊖⁰)/)

Circle CIでbundle updateのPull Request作成を自動化する手順

日々、bundle updateしてますか!

circleci-bundle-updatecircleci-bundle-update-prを使って、bundle updateの Pull Requestを自動化する手順をまとめてみます。作者の記事を読めばいいっちゃいいんですが、地味に抜けていた手順と各ステップは何のために必要かを整理してみました。

このgemは、Pull Requestに各gemの差分リンクを貼ってくれるのが便利だな!って思って採用してます。素敵なgemをありがとうございます。

github.com github.com

ステップは

  1. CircleCI経由でbotからgithubにpush出来るようにしておく
  2. CircleCI経由でbotからgithubにPR作れるようにしておく
  3. 外部からCircleCIへbuild指示できるようにする
  4. 外部からcronでCircleCIへbuild実行する
  5. CicleCIのbuild時にPRを送るようにする

といった感じです。

CircleCI経由でbotからgithubにpush出来るようにしておく

CircleCIからgithubgit pushするのが目的です。

  1. githubでPRを送りたいユーザーでログインする
  2. CircleCIにてPRを送りたいprojectを登録する or Followする
    f:id:naoto5959:20151223211412p:plain
  3. CircleCI経由でbotからPR出来るように鍵を登録する。Project SettingsからCheckout SSH keysからAdd user keyする
    f:id:naoto5959:20151223211426p:plain
  4. もし、まだAuthorizeしていなかった場合は、次に「Create and add nekodayo user key」をクリックして鍵を追加
    f:id:naoto5959:20151223211439p:plain
  5. こんな感じでkeyが追加されていればok
    f:id:naoto5959:20151223211447p:plain

CircleCI経由でbotからgithubにPR作れるようにしておく

CircleCIからgithubAPIを叩けるようにするのが目的です。

  1. githubでPRを送りたいユーザーでログインする
  2. access_tokenをrepo grantで作る
    f:id:naoto5959:20151223211458p:plain
  3. 生成されたAccess Tokenをコピーしておく
    f:id:naoto5959:20151223211452p:plain
  4. CircleCIの該当Project SettingsからEnvironment variablesにてGITHUB_ACCESS_TOKENという名前で環境変数を設定する
    f:id:naoto5959:20151223211506p:plain

外部からCircleCIへbuild指示できるようにする

つまり、CircleCIAPIを叩けるようにするのが目的です。

  1. CircleCIの該当Project SettingsからAPI Permissionsで、Allを選択し、bundle update cron用とか適当にラベルを付ける
    f:id:naoto5959:20151223211513p:plain
  2. 出来上がったTOKENをcron botから使う

外部からcronでCircleCIへbuild実行する

  1. ci-bundle-updateのheroku buttonでデプロイ
  2. 指示通りに環境変数を設定
    • GITHUB_USERNAME=botのユーザー名
    • GITHUB_REPONAME=projectの名前
    • CIRCLECI_TOKEN=先ほどのTOKEN
  3. heroku schedulerにbundle exec ruby ci-bundle-update.rbを設定

CicleCIのbuild時にPRを送るようにする

github.com

を参考に、pplogではこんな感じに設定しています。

deployment:
  production:
    branch: master
    commands:
      - |
        if [ "${BUNDLE_UPDATE}" ] ; then
          gem update bundler --no-document
          gem install circleci-bundle-update-pr
          circleci-bundle-update-pr
        fi
test:
  override:
    - |
      if [ -z "${BUNDLE_UPDATE}" ] ; then
        bundle exec rspec --fail-fast
      fi

こんな感じのPull Requestが届くようになります。

f:id:naoto5959:20151223220030p:plain

余談

設定している際に、botACCESS_TOKENを持っている状態でワザワザgithu user_nameとemailを指定している箇所が無駄だなと思ったので、Pull Request送ったりしてました。

github.com

まとめ

Railsを選択するには、「それでもRailsを選択する3つの理由 - pblog」といった理由があるはずで、そのためには

  • テストを書く
  • 周辺gemの更新に追随し続ける

必要があります。そのためにも自動でbundle updateをして日常的に最新のgemを使うようにしたいですね。

pplogの「ちょっと足跡が見えちゃう」機能を偲んで( ˘ω˘)

pplog

f:id:naoto5959:20151216001632p:plain

そこには足跡があった。

そう、名前の下に「最後に読んだよしたあしあと」が出ていたのだ。正確には、「最後のあしあとの最後の20文字」が出ていた。ウッカリおしりが見えちゃっている感じだ。

何故作ったか

ツイッター名前欄にはロマンがあるんですよ。

名前欄とは、Koshikawa Naoto とか書いちゃうところである。しかし、なんでそれ名前欄に書いたのって言う文字列を名前欄に入れている人々がいるのだ。なんていうかMNS MessengerとかSkypeにあったアレ、ムードみたいなアレ。間違ってアレ目的で名前欄を書き換えている。それも頻繁に書き換えている。そんなNAMAE-RAN FREAKSがいるんですよ。

正直ツイッターにおける一番いい機能である名前欄で遊ぶという機能を、我々はそんな機能を、pplogに搭載したくなったのですよ。

(当時の会話です)

f:id:naoto5959:20151216002142p:plain

そうですね、一時期「コントレックス」という文字列を入力していたことがありますね。今はもう飲んでいないコントレックスよ。

どう作るか

名前欄を変更できる機能を作ろう。

違う、そんなんじゃない。pplogに欲しい機能はそんなんじゃない!設定なんてさせるなよ!何が名前の設定だ!アホか!ポエム書きにきてんだよ、ポエム読みに来てんだよ!ふざけんなよ!

そんな気持ちから産み出した機能。

「最後に読んだよしたあしあと」を表示する機能。

気づかない人には、うっかりおしりが見えてしまっているような。しかし気づいた人はふざけて遊べる、そんな機能。くすっと笑えるお遊び機能。コレだ!って思ったんですよ(当時)

どやPull Requestの様子です

どうですか。私のツイッターIDの下には「ほしぶどう」という称号のような何かが。何なんですか、これは!バカバカしい!

f:id:naoto5959:20151216001820p:plain 

成功かと思った

無駄に回遊率が上がった(感覚値です)表示したい文字列を探し集めるためにポエムをあさった。ホネを回し続けた。ホネをフォワードし続けたのだ。そして、皆の名前欄の下を見たくてたまらなくなった。無駄に人のページヘ行った。

f:id:naoto5959:20151216003023p:plain

ヨサソウ、ッテ思った。

いやまて

足跡を必要以上に選び始める自分が居た。今までと違う気持で「読んだよ」していた。違った。それは違った。なんなら最高の「読んだよしたあしあと」のあとは、「読んだよ」したくなくなったりしてた。

思ったのと違う行動をし始めていた。ポエムを読めよ。おもいっきり、心置きなく「読んだよ」しろよ。なにやってんだよ!!!

おれの作りたい世界はコレじゃない。

やめよう

f:id:naoto5959:20151216001632p:plain

ひっそりと始まった機能はひっそりと消えた。それは儚い。ポエムのように、その機能は消えた。pplogの機能はそのコンセプトのように、儚く去っていった。

記憶にだけ残る君よ。

「ちょっと足跡が見えちゃう」機能よ。安らかに眠れ。

nyauthという認証gemを作ってた

MoneyForward Advent Calendar 2015 - Qiitaの14日目」の記事です。

今年、一体何やっていたかなと振り返ってみたところ、nyauthcatというgemを作っていたことに気づいたので、雑に紹介します。

「お前エモい記事しか書かなくなったな」みたいな声もチラホラ聞くのでたまにはプログラミングの記事を。

f:id:naoto5959:20151213124149p:plain

こうして振り返ってみると、何故かコントリビューターも現れ始めて嬉しかったです。

何なの

一般ユーザー向けと管理者用向けといった複数のコンテクストに対応した認証gemです。

猫の「にゃん」(って何)と「Authentication」を合わせて「にゃおーす」つまりnyauthです。

なんで作ったの

個人プロジェクトでとあるWebアプリケーションを作る際に、せっかくだし deviseから卒業しようってのと、単純になるべくメタプロし過ぎないシンプルなものを作りたかったのです。

ただそれだけです。学びが多かった。それが収穫です。

どんなもの

ざっと

  • 登録
  • 認証
  • パスワード変更
  • 本人確認(メールが届くかどうか)
  • パスワード変更

といった機能があります。一般ユーザーにはこれら全てを提供して、管理者ユーザーには、「認証だけ」みたいなユースケースに対応してます。

一般ユーザーの認証URLは

/session/new

管理者ユーザーの認証URLは

/admin/session/new

と言った感じで、現在のコンテクストをURLのパスで判断してます。

ルーティング

config/routes.rb

Rails.application.routes.draw do
  mount Nyauth::Engine => "/"
end

/にマウントすると以下の様なroutesが定義されます。/にマウントした時にはデフォルトでUserモデルが認証の対象となります。

Prefix Verb URI Pattern Controller#Action
nyauth      /nyauth     Nyauth::Engine

Routes for Nyauth::Engine:
              registration POST   /registration(.:format)                             nyauth/registrations#create
          new_registration GET    /registration/new(.:format)                         nyauth/registrations#new
                   session POST   /session(.:format)                                  nyauth/sessions#create
               new_session GET    /session/new(.:format)                              nyauth/sessions#new
                           DELETE /session(.:format)                                  nyauth/sessions#destroy
             edit_password GET    /password/edit(.:format)                            nyauth/passwords#edit
                  password PATCH  /password(.:format)                                 nyauth/passwords#update
                           PUT    /password(.:format)                                 nyauth/passwords#update
     confirmation_requests POST   /confirmation_requests(.:format)                    nyauth/confirmation_requests#create
  new_confirmation_request GET    /confirmation_requests/new(.:format)                nyauth/confirmation_requests#new
              confirmation GET    /confirmations/:confirmation_key(.:format)          nyauth/confirmations#update
   reset_password_requests POST   /reset_password_requests(.:format)                  nyauth/reset_password_requests#create
new_reset_password_request GET    /reset_password_requests/new(.:format)              nyauth/reset_password_requests#new
       edit_reset_password GET    /reset_passwords/:reset_password_key/edit(.:format) nyauth/reset_passwords#edit
            reset_password PATCH  /reset_passwords/:reset_password_key(.:format)      nyauth/reset_passwords#update
                           PUT    /reset_passwords/:reset_password_key(.:format)      nyauth/reset_passwords#update

config/routes.rb

Rails.application.routes.draw do
  mount Nyauth::Engine => "/hoge"
end

/hogeにマウントすれば、Hogeモデルが認証の対象となります。

複数のモデルを認証したいときのルーティング

config/routes.rb

Rails.application.routes.draw do
  # for admin
  namespace :nyauth, path: :admin, as: :admin do
    # concerns :nyauth_registrable
    concerns :nyauth_authenticatable
    # concerns :nyauth_confirmable
  end

  # for user
  mount Nyauth::Engine => "/"
end

本当は、2箇所に違う名前でマウントしたいのだけども

Rails.application.routes.draw do
  # for admin
  mount Nyauth::Engine => "/admin", as: 'admin'

  # for user
  mount Nyauth::Engine => "/", as: 'user'
end

とは出来ません。Railsが2箇所にEngineをマウントはできてもURLヘルパーを上手く扱えず後で定義した方のasで上書いてしまうので、今回はmountは1つ、2つ目以降は

namespace :nyauth, path: :admin, as: :admin do
    # concerns :nyauth_registrable
    concerns :nyauth_authenticatable
    # concerns :nyauth_confirmable
end

と言った感じで定義します。もちろん、1つ目からこの形式でも大丈夫です。

ここで、nyauthでは以下のRouting Conrcenを使えます。

concern :nyauth_registrable do
  resource :registration, only: %i(new create)
end

concern :nyauth_authenticatable do
  resource :session, only: %i(new create destroy)
  resource :password, only: %i(edit update)
  resources :reset_password_requests, only: %i(new create)
  resources :reset_passwords, param: :reset_password_key, only: %i(edit update)
end

concern :nyauth_confirmable do
  resources :confirmation_requests, only: %i(new create)
  get '/confirmations/:confirmation_key' => 'confirmations#update', as: :confirmation
end

コントローラー

application_controller.rb

class ApplicationController < ActionController::Base
  include Nyauth::ControllerConcern
  before_action -> { require_authentication! as: :user }
  helper_method :current_user

  private

  def current_user
    current_authenticated(as: :user)
  end
end

使いたいコントローラーに、include Nyauth::ControllerConcernと書いておくと、require_authentication!というメソッドが生えるので、

before_action -> { require_authentication! as: :user }

てな感じで、フィルターをかけるイメージです。

管理者向けのコントローラーにも同じように、

admin/base_controller.rb

class Admin::BaseController < ActionController::Base
  include Nyauth::ControllerConcern
  before_action -> { require_authentication! as: :admin }
  helper_method :current_admin

  private

  def current_admin
    current_authenticated(as: :admin)
  end
end

テーブル定義

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :nickname
      # Authenticatable
      t.string :email, null: false
      t.string :password_digest, null: false
      t.string :password_salt, null: false
      t.string :reset_password_key
      t.datetime :reset_password_key_expired_at
      # Confirmable
      t.datetime :confirmed_at
      t.string :confirmation_key
      t.datetime :confirmation_key_expired_at

      t.timestamps null: false
    end
    add_index :users, :email, unique: true
  end
end

モデル

適切なカラムを定義した上で、モデルにmoduleincludeしておきます。

app/models/user.rb

class User < ActiveRecord::Base
  include Nyauth::Authenticatable
  include Nyauth::Confirmable
end

app/models/admin.rb

class Admin < ActiveRecord::Base
  include Nyauth::Authenticatable
end

なんとなく見れば分かるかな。更に詳しくは、READMEソースコードを読んで頂けると良いかと嬉しいです。

学び

  • 同じEngineを複数のパスにマウントする事を想定していないようでつらかった。もうちょいソースを読み込んでコントリビュートしたい気持ちはある。
  • そのため、helperの生成がつらかった。実装的にもシンプルじゃないのでいけてない。
  • テスト時に、sign_in(user)みたいなヘルパーを使うために、wardenを大いに参考にさせていただいた。Rack層の段階で次のrequestにhookするという発想がとても勉強になった。
  • generator生成のノウハウを得た。
  • respondersの拡張ノウハウを得た。
  • gemのconfigを用意してゴニョゴニョカスタマイズするノウハウを得た。

個人プロジェクトの進捗どうですか

なんと肝心の個人プロジェクトのWebアプリは、このgemを作ることに寄り道したり、React.jsをこねくり回したり、RailsJavaScriptのモダンな共存などを模索していたせいで公開がまで来てません。個人プロジェクトは、yak shavingばかりしていた1年でしたね。

github.com

今回の記事でnyauthにご興味持たれた方は是非Pull Requestでフィードバック頂けると嬉しいです。