「コード」カテゴリーアーカイブ

Rails: Cells 3 から Cells 4 へのアップグレード


Rails のアプリケーションで Cells gem を 3.11.3 から 4.0.2 にアップグレードしました。 一緒に Rails も 4.1.9 から 4.2.4 にアップグレードしました。 ここでは Cells についてやったことを書きます。

基本的なやり方は From Cells 3 to Cells 4 Upgrading Guide に説明がありますので ご参照ください。 バージョン 4 に変更するのは結構大変です。

環境

  • Ruby 2.2.3
  • テンプレートエンジン: Slim

経緯

ある人が外注に出していたプログラムを なぜか私がデザイン、マークアップ含めて更新することになり、 Rails と Gem のバージョンを更新しました。

その Rails のアプリケーションにテストコードは一切ありませんでした。

リリース前のプログラムに対して変更を行いました。

やったこと

  1. ApplicationCell 作成
  2. helper を include に変更
  3. render_cell を cell に変更
  4. ファイル名変更
  5. app/views 内のテンプレート呼び出し部分を変更

ApplicationCell 作成

cell のテンプレートの中で device 関連のメソッドを使っていたり、 フォームタグ関連のメソッドを使っていると途端に動かなくなります。 そこで、 ApplicationCell を作成して 全ての Cell がそれを継承するように変更しました。

アプリケーションを見ながら 次のような ApplicationCell を作りました。 include で取り込んでいるモジュールは、 エラーが出る度に順次取り込んでいったものです。

self.helper_methoddevise が呼び出しているため、 呼べるようにしておくために作っています。 Cells では 既に意味のないメソッドになっているので、 何も処理は行いません。 この記述については 一部 Rails: Cells 3 から Cells 4 への アップグレード時に遭遇したエラー にも関連情報を書きました。

helper を include に変更

各 Cell クラス に helper ApplicationHelper というのが記述されていました。

Webrick を実行してページを開くと undefined method と表示されました。 そこで、 helperinclude に変更しました。

sedコマンドを使って、 複数ファイルを一度に変更しました。

render_cell を cell に変更

Cells 4 から メソッドが変わりました。 ビューの中で使用されている render_cellcell に書き換えました。

いままで書いていた人がコードを綺麗に保っていたので、 sedコマンドを使って簡単に変更できました。 書き方が何通りもある場合は、簡単にはいきません。

変更前コード

変更後コード

ファイル名変更

cell のテンプレートが method_name.html.slim となっていましたが、 cell(:cell_name).(:method_name) で呼び出した場合、 method_name.slim のテンプレートを探してエラーとなりました。

cells/lib/cell/view_model.rb 内の find_template メソッド でテンプレートの名前を組み立てていますが、 そこでは 文字列 'html' を結合していません。

そこで、 テンプレートファイルの名前から html を抜きました。

app/views 内のテンプレート呼び出し部分を変更

こちらも間に合わせの対応でした。

過去のコードでは過去のコード cell のテンプレートから app/views/shared/something.html.slim を呼び出していました。

変更前コード

この呼び出し方だと、 Cells 4 ではうまくいきません。

cells/lib/cell/templates.rbcells/lib/cell/view_model.rb を見ながら次のようにコードを変更しました。

変更後コード

prefixesview を作るだけではなくて、 view の値も変える必要があります。

app/views内のテンプレートを呼び出す際のメソッドを ApplicationCell に作ったほうがよかったかもしれません。

Cell の中に self.view_paths += ['app/views'] を加えると、 app/views/cell_name の中でテンプレートを探すようになります。 つまり、次のように変更しても動くようになります。

コード変更案


Bitbucket と Slack を連携させる方法


Bitbucket で Pull Request(プルリクエスト) や コメント、 Issue(イシュー) が追加・作成されたときに Slack に連携するコードを書きました。

経緯

Bitbucket で Issue 作成など が行われた際に 外部 に連携する仕組みは Bitbucket で提供されています。 それは 各プロジェクトの設定画面 Webhooks から 設定ができます。

Slack でも 設定画面から 簡単に Bitbucket と連携することができました。 しかし、 そのとき (頃) は Bitbucket の push しか Slack が対応していませんでした。

push よりも Issue 作成や Pull Request や コメント を連携してほしい と思った私は、 Google Apps Script を使って Bitbucket と Slack を繋ぐスクリプトを作ったのでした。

コード

本当なら オブジェクトモデルを作って Factory を作ってとやりたいところだったのですが、 業務が忙しくてそんなことやってられなかったため 間に合わせの品質でコードを作りました。

下記のスクリプトを Google Apps Script で作成し、 メニュー Publish から Deploy as web app をクリックして公開します。 すると ウェブアプリ の URL が表示されるので、 それを Bitbucket の設定画面から Push 先 の URL として登録します。

Bitbucket で何らかの操作が行われるたびに Google Apps Script の処理が実行され、 Slack に 投稿されるようになります。

(コードは Github Bitbucket To Slack Gas にもあります。 Contribute 歓迎です。)

まず Bitbucket から通知(Post Request)が来ると、 doPost が実行されます。 そして Post されたデータから、 Slack への ペイロード データ を作成します。 上では createSlackMessage がその処理を行っています。

createSlackMessage では、 届いたデータから 操作内容を割り出し、 通知したい情報をまとめます。

送信したいデータがまとまったら、 Slack に送信します。

注意点

createSlackMessage では、 Issue の場合、 Pull Request の場合などパターン分けしていますが、 上で分けてある以上に 細かくパターンが分かれます。 今回は私の業務上必要だろうと思われる分岐にとどめています。 そのパターンを正確に判断するには Bitbucket から送信されるヘッダの中を確認するのがいいのですが、 Google Apps Script ではリクエストヘッダを確認することができないため ペイロード部分のデータで分岐を行っています。

実際のところ Pull Requestapproved のあたりはまだ検証中のため、 正しく判別できているという保証がないです。

もし、 Heroku や AWS 、 その他レンタルサーバ など 自由に使えるサーバがある場合は、 PHP, Ruby 等 で作成したほうが リクエストヘッダも使えて便利だと思います。


crontab をコマンドで登録する方法


Rails などで、 setup を自動にしている人は多いと思います。 Rails だと whenever という gem を使って crontab をプログラムから設定してしまうことができるのですが、 メールサーバなど Rails をインストールしていない、 インストールするのも煩わしい環境だとそうはいきません。 そこで本記事では、 shell を使って crontab を設定する方法を紹介します。

続きを読む crontab をコマンドで登録する方法