blogシタテルの技術やエンジニアの取り組みを紹介するテックブログです。投稿を表示しています。投稿を表示しています。2018こんにちは、あさのです。Storageの記事を書きましたが、今回もそのネタで行こうと思います。Storage管理に移行したときのお話です。データ構造Paperclipではファイルのデータは各モデルのカラムに保存されています。userクラスのiconというファイルであれば、userテーブルに以下のようなカラムがあります。Storageでは全クラスの全ファイルをまとめて2つのテーブルで管理します。prof.jpgというファイルだと以下のようなレコードになります。関連づけられるんですね。19:23:03データ移行さて、それぞれのデータ構造がわかったのでマイグレーションをしていきます。このあたりの記事を参考にさせてもらい、rakeタスクで実装しました。Storageのテーブルに入れるという繰り返しです。Storage用に書き換えた後ではこのタスクは動かないので、Paperclip時に実行する必要があります。実際にやったところ数万件のデータがあったために5~6時間かかるという大引っ越しになってしましましたが、なんとか乗り切りました。Storageのデータ移行について書きました。Storageネタで書けるかもしれません。2018こんにちはあさのです。Storageに移行したときの話を書こうと思います。PaperclipPaperclipはファイルアップロード用のGemです。https://github.com/thoughtbot/paperclip比較的導入が簡単であり、アプリケーションにファイルアップロード機能をつけるためによく使われています。Storageへの移行が推奨されています。Recordのオブジェクトと紐づけたファイルアップロード機能を提供しています。5.2へのアップグレードが落ち着いたところでこの移行を行いました。そんなわけで、移行にあたっていくつか注意点となったところを振り返っていきたいと思います。今回はモデルのバリデーションの話です。バリデーションPapaerclipにはバリデーション機能があります。以下はiconという名前で扱う添付ファイルのバリデートをする例で、モデル内にこう書いておけば保存時に自動でチェックされます。png]のどれか、ファイルサイズが10MB以下である必要があります。Storageにはこのようなバリデーション機能はありません。Recordのカスタムバリデーションを使いましょう。これで同じようなことができます。ファイルタイプを取得しています。Storageのバリデーションについて書いてみました。Paperclipからの移行はいろいろと作業があったので他のトピックについてもまた書いていきたいと思います。2018こんにちは!SCSチームのいしづかです。Vue.jsにてシステムを開発しています。SPA化によるマイクロサービス化計画も進んでいる中、ここ最近作られている画面はhamlの中にVue.jsを埋め込むという方法が取られています。ついてレポートしたいと思います。表題の通り、いろいろ混ざりました。Railsでは、ネームスペースやクラス名はパスカルケース(ClassName)、それ以外のメソッド名などはスネークケース(method_name)で書きます。定数などはアッパーケース(CONST_VALUE)で書きますね。いつの間にか3種類使い分けていました。私自身、前職ではC#.NETでWindowsアプリケーションを作っていたのでパスカルケースを見ると安心します(笑)Vueを使いだしてから、メソッド名はキャメルケース(methodName)、htmlやcssのidやクラスなどはケバブケース(class-name)が登場してきました。・・・ついに1つのRailsプロジェクトに、ほぼすべての命名規則が揃ってしまったのです。RailsとVueで分かれていればまだよかったかもしれませんが、Railsで書いたAPIのjsonがスネークケースで出力されてしまうため、Vue側にもスネークケースが進出してしまいました。そこで、さすがにルールを設けようということになったのです。統一ルール発令Railsで使っているパスカルケース・スネークケースは崩すことができません。いうルールに統一しました。なんとなく複雑っぽいですが、メソッドとhtml周りはそのままで、データに関わるところだけちょっとRailsに寄せたという形です。これでRails側はこれまでのソースを流用できますし、Vue側ではJsonをパースしてバインドする際、スネークケースが出てきてもOKです。Vueが入ってきて発生した命名規則の混乱は、この統一ルール発令によってひとまずしばらくは沈静化するでしょう。SPA化計画では、フロントはキャメル統一の予定とはいえ!Javascriptは基本的にキャメルケース。APIでは、RailsからJsonを出力する際にキャメルケースに変換するように実装しています。これでSPA側でデータを受け取る時だけスネークケースにしなくても済みそうです。まとめこれまでとは異なる言語やプラットフォームを使う時、既存のものとの整合性が取れなくなるときがありますね。今回、私たちは「命名規則がカオスになる」という形でそれが表れました。シタテルではそんなカオスとも仲良くしながら(闘いながら?)、日々新しいものにも取り組みつつシステムを構築しています。2018どうもこんにちはシタテルでエンジニアをしている朝野です。セキュリティーや開発インフラを担当しています。Railsを使っているプロダクトがいくつかあるのですが、そこでのセキュリティ施策の1つとしてBrakemanというGemを使っています。セキュリティチェック用のGemとしては有名どころですが、理解の確認も兼ねてまとめてみました。BrakemanとはRailsのソースコードを解析し、SQLインジェクションやXSS等の脆弱性になりかねない危険なコードを見つけ出すGemです。brakemanで実行でき、ソースコード内を確認してくれます。脆弱性が見つかった場合の終了コードを0以外にというオプションを使っています。CircleCIのためです。脆弱性が見つかった時ビルド失敗になり、開発中のブランチで脆弱性が見つかっていたらmergeできなくなるわけです。ちなみにその他オプションはこちら。毎回オプションを打つのも面倒なので、設定ファイルにまとめてしまうと便利です。-Cをつけて実行すれば、同時につけたオプションに相当する設定ファイルの内容が出力されます。保存しておけば自動でその設定が読み込まれるので、オプションをつけなくてよくなります。警告に対応しないときBrakemanを実行して出力された脆弱性を修正していくことになります。修正のしようがないときやそのままでも問題ないときというのもたまにあります。実行時のオプションの一つで、名指ししたメソッドは安全だからチェックしなくていいよ!とするものです。メソッド内はスキャンされません。無視する警告のリストです。?)というふうに見つかった脆弱性をどうするか聞いてきます。無視リストに入れられた警告は、以降出力されなくなります。このように不要な警告をスルーする手もちゃんとあるのがbrakemanのよくできているところですが、うっかり対象から外した部分に危険なコードを書き足してしまわないように注意しなければいけないですね。最初からセキュリティを意識してコーディングするのがまずは重要ですが、このようなチェックがあると安心がアップしますね。usシタテルのミッションはテクノロジーとイマジネーションで「ひと」と「衣服」の新しい未来をつくること。クラウドシステムを使うように服作りのリソースを誰でも好きなときに好きだだけ使えるプラットフォームを目指しています。(1)どうも朝野です。Storage移行記:バリデーション編こんにちはあさのです。Storageに移行したときの話を書こうと思います。Paperclipはファイルアップロード用のGemです。https://...SQLite3でWindow関数を試してみた!はじめまして、DevOpsチームの甲斐です。何かブログのネタはないかなーと思っていたところ、たまたま以下のニュースを発見しました。ECSに自動デプロイする(おまけで環境面の切り替えも)こんにちは、シタテルの茨木です。ECR/ECSにデプロイする為の設定例を紹介します。Nuxt.jsアプリ用に作ったものですが、言語やAPサーバが違っても共通の部分がほとんどです。