Kamiya::Memo

これまで当該のサイトではカラーミーショップというASP型のショッピングカートシステムを利用していましたが、サイトが成長するにつれて機能面で物足りない点が出てきたため半年ほど前に開発を開始し、ようやくリプレイスを完了したのが４月中旬でした。

システムのリニューアルで使用したのはSolidusというRuby on Rails製のフレームワークです。Eコマースのオープンソースというとまだまだ国内ではEC-Cubeが主流ですが、そんな中あえて採用したフレームワークがSolidusです。

Solidus

ECサイトのシステムリニューアルという大きな仕事を終えて、いくつか思うことがあったので日が浅いうちに考えを整理＆文章におこしておこうと思いました。私はウェブエンジニアですが経営者でもありますので、この記事では今回のシステムリニューアルをするに至った背景とその判断をテーマについて書こうと思います。テクニカルなお話はまたどこかでまとめられればと考えています。

[はじめに] ASPを使わずにECサイトを構築することについて

国内ではカラーミーショップ、海外製ではshopifyといった優秀なECサイト向けのASPサービスが存在します。ここで言うEC向けASPとは、必要な情報（商品名、価格、ショップ名、配送料など）をシステムに入力すれば通販サイトが運営できるといったシステムのことですね。

これらのシステムを使えば比較的自由度の高いECサイトの構築が少ない作業工数にて可能です。サイトのデザインを自由に変更したい、出店料を安く抑えたいという場合はこの選択肢が最も現実的です。ただ店舗運営に関する全ての面倒を見てもらえるかと言うとそういうわけではなく、集客のためのSEO対策やリスティング広告の出稿等は独自に行う必要があります。ここが楽天やAmazonと言ったモール出店と異なるポイントです。

今回リニューアルしたサイトも最初の1年ほどはカラーミーショップを使用して運営していました。事業を立ち上げるにあたり、ゼロからECサイトを構築するのは時間がかかりすぎるためです。早く立ちあげてそれを改善していったほうがSEO的にも事業的にもメリットが大きいと判断しました。

今回はそんなASPサービスのように便利な環境があるわけではありません。用意したサーバーにプログラムを配置し、業務に合わせてシステムをカスタマイズする必要があります。もちろん利用するフレームワークとシステムに追加する機能に応じたプログラミング業務が発生します。そしてそれに伴うメリット・デメリットが生じるわけです。

システムリニューアルに踏み切った背景と判断

リニューアルに踏み切った第一の理由は、商品のレンタルという特殊な販売形態です。

ごく一般的なECサイトの業務フローは「1.注文」「2.決済」「3.発送」までが主な流れですが、レンタルの場合は発送の後に「返却」というステップが発生し、注文ごとのスケジュール管理も必要となります。またそれに付随してレンタル品の在庫管理も発生するため、この時点で一般的なECサイトのシステムではカバーできないことが確定していました。

そのため、リニューアル直前にはカラーミーショップと併用する形で比較的シンプルな在庫管理用ウェブアプリケーションを構築し、足りない機能を補っていました。このシステムの開発期間は1ヶ月ほどですが、もしこの予約管理アプリケーションがなかったら貸出状況や在庫管理をExcel等で管理することになっていたかもしれません。半年ほどこのシステムを使い在庫管理を行っていましたが、繋ぎとしてはコストとリターンのバランスの良い、悪くない判断だったと思います。

また、ASPサービスではデザインこそある程度自由に変更できるものの、編集できる範囲はそれぞれのサービスで決められた枠の中だけです。例えばチェックアウトの画面など、特定のページには手が加えられなかったりします。またURLの構造など、SEO対策を施そうとしても仕様上不可能なことがあるのもASPサービスに対する不満の一つでした。

開発者としても思う事がありました。このご時世、AWSといったITインフラや、様々な開発ツールが登場していますがそれらを使えるかどうかもASPサービスの仕様に依存してしまいます。

ここまでをまとめると、この時点で足りてなかったのは以下の3点でした。

レンタル予約と在庫の管理機能

SEOの観点から見たサイト構造

より効率的な開発環境、開発ツール

なぜSolidus(Ruby on Rails)なのか

ASPサービスの利用をやめ、ECサイトを開発するという判断を下したら、次はベースとなるフレームワークの選定です。Ruby on Railsで構築するといってもゼロからコードを書き上げるわけではありません。基本的な機能が含まれるフレームワークを中心に据え、それに必要な機能を書き足していくといった作業となります。

今回候補に上げたフレームワークは次の3つでした。

PHP製のEC-Cube。Ruby on Rails製のSpree、同じくRuby on Rails製のSolidusです。

EC-Cubeは有名なので説明は不要かと思います。SolidusはSpreeの後継フレームワークです。これらの関係はこちらの記事で詳しく説明されているので興味ある方は見てみてください。

Spree is Dead

（判断に至った前提として、私がRuby on Railsを扱えるという点がありましたが）Rails製のフレームワークはEC-cubeと比べて日本語のドキュメントやエクステンションが少ない一方、見通しのよいコードとRubyで開発ができるという点がメリットでした。Ruby on Railsのコミュニティには、多くのオープンソースのライブラリが存在し、それらを活用することでECサイトに様々な機能を比較的少ない開発工数で追加することができます。世界中のデベロッパーが活発な議論と開発をすすめているRailsコミュニティはECサイトの開発背景としては非常に魅力的な環境だったというのが決め手のひとつです。

また、SpreeかSolidusかという選択については、将来性をとってSolidusという選択肢を選びました。

Solidusを活用すべきビジネス

開発をはじめる前からも予想はしていましたが、コードを書いてECサイトを開発するということは莫大なエンジニアの稼働を持って行かれます。今回は一名で開発を行いましたが、半年近くの時間を要しました。

勿論エンジニアの練度やシステム要件など作業工数が増減する要因はあるかと思いますが、人月換算ではざっくり5〜10人月といったところでしょう。人月単価を100万円として計算すると、初期の開発コストは500万〜1,000万です。人月は外注の際に用いられる単位ではありますが、このご時世ウェブエンジニアの稼働は貴重ですので、もし金額ベースでの見積もりを求めるなら潜在的なコストはこれくらいで見ておくのが自然かと思います。

もちろんサービスリリース後には運用や、システムの改善などにも維持コストがかかります。さらにはコンスタントにシステムの改善ができないのであればASPからリプレイスをする意味がありません。リリース後にもエンジニアの稼働が必要で、もちろんサーバー代金等も継続的に発生しますね。

ここまで書くとSolidusでECサイトを運用するコストが大変高いことがわかるかと思います。例えば利益率30％、月間の売上300万の商売では費用対効果が見込めません。仮に月間の売上が1億円あっても利益率1％では微妙です。

以上を踏まえると、RailsでECサイトを運用する場合には以下の条件を満たすビジネスである必要があります。

開発コスト、運用コストをカバーできるだけの利益が将来的に期待できるビジネスであること

ASP等、既存のシステムでは実現しずらい要件が複数あること。またそれを実現することで利益の増加が見込めること

継続してシステムを改善できる環境であること（スピーディーに動けるエンジニアが1人以上いること）

目先の数字だけを見ると当然厳しいものもありますが、将来的にはこれらの要件も満たせるだろうという目算の下、SolidusによるECサイト構築に踏み切ることになりました。

Solidusを使ってECサイトを構築した場合のリスク

判断を下すには、メリットだけではなく想定されるリスクも理解しておかねばなりません。実際に開発を終えて感じたSolidusを使うことによるリスクを列挙します。

リスク1 / 開発コストリスク

上でも書きましたが、開発コストはとても大きいです。そのビジネスにSolidusを使う必然性がないならばSolidusは使わずASPサービスを利用すべきです。

リスク2 / エンジニアリスク

仮に腕の良いエンジニアが比較的短い時間でサイトを構築できるとしても、そのエンジニアが離脱する可能性があるならば、その後任をどうするのかという点も考えておく必要があるでしょう。Railsのフレームワークの中でもSolidusは敷居の高い部類にあり、最初の学習コストは高いです。ウェブに日本語の情報がほとんど無いことからも、即戦力エンジニアを確保するのが簡単ではないことがうかがえます。

リスク3 / セキュリティリスク

Solidusは信頼できるフレームワークだと考えています。仮に脆弱性が発見されても迅速に修正パッチが公開されますし、またユーザー認証の部分もDeviseという信頼性の高い外部のライブラリを使っています。使用するライブラリ群を常に最新に保ったり、サーバに適切な対策を施していれば、事故の起こりにくい環境を保つことはさほど難しいことではありません。

しかしながら開発を行うのが人間である以上、「うっかりミス」が事故につながる可能性はゼロではありません。数百、数千のショップを預かるASPサービスでは、何重ものセキュリティ対策が施されています。それと比べてしまえばSolidusは人為的なミスの起こりやすい環境と言えるかもしれません。

リスク4 / システム移転時のリスク

SEOのことなどを考えると、システムリプレース時のURLの変更は大いに考慮すべき問題かと思います。リダイレクトやURL構造を比較的自由に変更できるSolidusとURL構造固定のASPサービス。ASP→Solidusはどうにかなるかもしれませんが、Solidus→ASPはリスクが大きそうですね。一度ECサイトを動かしてしまうとリプレイスは大仕事です。慎重に考えたいですね。

Solidusでのサイト構築を考える場合には、是非これらのリスクとリターンを天秤にかけて考えてみてください。

最後に

以上です。

今回の記事ではどちらかというとリスクのようなネガティブな面に重きを置いて書きましたが、Solidusでのサイト構築が成功さえすれば、あとはRuby on Railsの強力なコミュニティの力を借りて少ない工数で多くの機能追加を矢継ぎ早に打つことができるようにもなります◎

まだまだ日本での導入事例の少ないSolidusというフレームワークがより普及する一方、誤った判断で不幸な結果がもたらされることがないようまずはSolidusでECサイトを構築するといった判断をテーマに書いてみました。

1.ブラウザからAppを作成

障害のおきていないリージョンを選びましょう。ここは説明不要ですね。

2.DBのバックアップを作る

旧アプリのデータベースのバックアップをとります。ブラウザから「Create Backup」とかで出来た気がします。

バックアップを作ったら、URLを取得する必要があるので今度はターミナルです。

$heroku pg:backups === Backups ID Backup Time Status Size Database ---- ------------------------- ----------------------------------- ------ -------- b100 2015-10-21 11:37:33 +0000 Completed 2015-10-21 11:37:36 +0000 291kB DATABASE

バックアップのリストが出てきました。次は最新バックアップのURLを生成。

$ heroku pg:backups public-url b100 The following URL will expire at 2015-10-21 12:58:41 +0000: "https://xxx.s3.amazonaws.com/xxxxxxxxxxxxxxxxx"

3.herokuコマンドの向き先を新Appへ

$ heroku git:remote -a new-app

4.バックアップから新Appのデータベースをリストア

$ heroku pg:backups restore "https://xxx.s3.amazonaws.com/xxxxxxxxxxxxxxx" DATABASE

そもそも何がしたかったかというと、同一ドメイン内にディレクトリで切ってワードプレスのサーバを配置したかった。CroudFrontのBehavior使えば振り分けできるので。

例えば

http://dokuji.domain/ ← カラーミー http://dokuji.domain/wp/ ← WordPress

やったこと

まずは普通にクラウドフロントを設定。オリジンサーバにカラーミーデフォのFQDNを設定(hoge.shop-proのやつ)

設定完了。しかし。

http://hogehogehoge.cloudfront.net/?pid=89501481

とか

http://hogehogehoge.cloudfront.net/?mode=srh&keyword=

がトップページに飛んでしまう？？

調べたところ、デフォルトではQueryString、つまりパラメータがオリジンサーバに渡らないらしい。

これは調べたらすぐに解決。

クエリ文字列パラメータに基づいてキャッシュするように CloudFront を設定する

オリジンがクエリ文字列に基づいてオブジェクトの別のバージョン（例: /images/image.jpg）を返す場合は、CloudFront コンソールの [Forward Query Strings] で [Yes] を選択します。または、CloudFront API を使用する場合は、DistributionConfig 複合型の QueryString エレメントの値に true を指定します。

Behavorの設定画面からこれを変更して修正完了。

断念した理由

CloudFront経由でカラーミーにアクセスする場合、オリジンサーバのURLをカラーミーデフォのFQDNを設定する必要があります。

けど、CloudFront経由でアクセスしようとした場合、カラーミーのサーバがデフォルトFQDNへのアクセスと判断してURLの含まれる諸々のパラメータををデフォルトFQDNで返しちゃうのです。

まあ、``みたいのはFQDNごと書き換えちゃえばOKだったのですが、如何ともし難いのがこれ↓

<input type="hidden" name="back_url" value="http://default.shop-pro.jp/?pid=89138337">

「カートへ入れる」ボタンのhiddenパラメータです。これが何を意味するかというと、一度カートの画面へ行って、戻ってくるとデフォルトFQDNで商品ページを開いちゃうというわけ。

ちなみにカラーミー標準搭載のデフォFQDNから独自ドメインへのリダイレクトをONにすると全てのページでリダイレクトループが発生するので使えません。(独自ドメインへアクセスしても、デフォFQDNへのアクセスとして認識されてしまうため)

jsでフォームのhiddenパラメータ書き換えるという手もあるけど、あまりに泥臭いので諦めました。

参考

CFでカスタムオリジンをApacheに向けている時のディレクトリ名スラッシュ補完時にオリジンのURLに転送されてしまう問題を解決してみた

やっぱりオリジンURL誤認問題は存在するみたいです

6/9追記

とりあえずjsでback_urlを書き換えてあげたら動作することは確認できました。こんな感じ。

$('input[name="back_url"]').each(function(){ url = $(this).val(); $(this).val(url.replace(/hogehoge.shop-pro.jp/,'dokuji.domain')); });

けどフォームの値をJSで書き換えるという全然スマートじゃない＆セキュリティ的にも？という解決法なのでもしご利用の場合は完全自己責任でお願いします。

あと、カート画面から本サイトへ戻る時のHTTPメソッドがPOSTになってるので、CloudFront側でPOSTを許可してあげないとThe request could not be satisfied.って言われます。

あと細かいけどog:urlとかもカラーミーFQDNになっちゃいます。これはjsで書き換えてどうにかなるものではないので諦めましょう。

結論

# bootstrap.js if (affix == 'bottom') { this.$element.offset({ top: scrollHeight - height - offsetBottom }) }

これを

# bootstrap.js if (affix == 'bottom') { this.$element.offset({ top: scrollHeight - height - offsetBottom }) } else { this.$element.css('position', '') }

歴史小説としては、とても読みやすい部類に属するんじゃないかと思う。登場人物が織田信長や豊臣秀吉、徳川家康と誰もがしっている武将を中心に綴られることや、戦の描写が細かく場面を想像しながら読み進めることができました。これは以前読んだ竜馬がゆくにはないポイント。司馬遼太郎ってとっつきにくいイメージがありますが、読んだことない人にはこの作品から読むのがが一番かも。

物語では山内一豊の賢妻である千代の主人を立てる立ち回りがテーマとされているけども、一豊も決して無能な人物ではなく、戦国時代をのし上がっていくだけの十分な器を持ってると感じた。派手さはなくても着実に積み重ねる武功、関ヶ原前の迷う家臣たちへの一喝がまさにそう。千代の優秀さが目につきがちだけど、決して千代だけじゃなくて足りない部分を補い合いながら二人で築いた土佐24万石だという印象をうけました。

話は変わるけども、この小説は見方をちょっと変えると、豊臣秀吉と山内一豊という大成功を収めた二人の英雄が成功の後に狂っていう様を描いた小説とも取れるように思います。人の器相当、あるいは器以上の大成功の味とその恐ろしさという教訓も含まれていると思う。

買ったきっかけと購入前に想定した用途

まず、ちゃんとした写真を撮れるカメラが欲しかったというのが第一にあります。

けど荷物増えるのやだ。レンズとかF値とかよくわかんない。という理由もありまして、話題性という点も考えてこのカメラが候補に上がりました。

常にカバンに入れておいて、ちょっとしたときに一眼クオリティでの写真を取りたいという狙いがありました。

※実際一眼には及ばないのですが、スマホのカメラよりスペック上の数字は確実に上です。撮影した感じは後述します。

実際に使ってみての感想

画質は良いです、とても。素人目にもiPhoneとは違う写真が撮影できます。

実際に撮影した写真をご覧ください。

暗い場所での撮影

ぼかしの撮影もOK

暗い場所&ぼかし

まあ撮った人間の写真の腕前は置いといて、結構キレイな写真がとれてるのではないかと思いますｗ

これらの写真は、全てカメラが自動で状況を判断して焦点なり絞りなりを調整して撮影した写真です。背景ぼかしも全てオート。素人でもきれいなぼかしの写真が撮れてしまいます。

一番心配だったスマホとの接続も比較的スムーズ。取り出す手間とかを除いて考えると、ソフトウェア的な接続にかかる時間はほんの2、3秒です(NFC搭載のアンドロイドの場合。iPhoneだともうちょっとかかるかも) けどスマホとカメラ、端末2つを起動しなきゃいけないのがちょっとストレス。

一番ストレスを感じたのが撮影後のロードタイムと突然の瞬断。撮影後、カメラ→スマホに写真を転送するのに通常2秒くらいですが、最大で10秒くらいかかることがあります。これでは連写ができない…。

あとたまに突然接続が切れてファインダーが固まることもありますので注意。

使用感は概ね良好ではあるのですが、上記のようにたまにストレスに感じることもあります。

あとはレンズとファインダー部を切り離して持てるので、右手にレンズ、左手にファインダーを持ち、高いところからの撮影やなかなか撮影しずらい場所もスムーズに撮れるのがこのカメラの優れている点です。あまり取り沙汰されていない機能ですが、この機能はなかなか重宝しました。人混みの上からの写真とか、ローアングルからの写真とかもこれがあれば余裕です。

まとめ

なんだかんだで一年くらい使いましたので及第点だと思います。

ただ良い製品だと思うけど、あと2年くらい技術が進歩しないとストレスに思う点が多いかな。

Sqaleのデータベースをダンプファイル化

SqaleからDB内のデータを書き出します。やり方は下記のSqaleのマニュアルのページで何通りかの方法が公開されています。私はs3cmdコマンドでS3を経由して行う方法でやりました。

アプリケーションの復元方法（バックアップとリストア）

Sqaleにログインして下記のコマンドを打ちます。DB名やユーザー名などは必要に応じて変更してください。

$ mysqldump -u [sqale user] -h mysql001.sqale.jp -p [db name] > mysql.dump Enter password:

2015/2/26追記

コマンドに使うユーザー情報等は、Sqaleダッシュボード内の「データベース接続情報」より参照できます。

また、私がやったときに起こったのですが、ダンプファイルが妙に小さい、中身がほぼ空っぽのファイルが書き出されることがあります。

原因を調べてみたのですが、どうやら昔から使っていたDB情報と、上記の「データベース接続情報」ページ内に記載されているDBが別のDBになっていたことが原因です。

なぜこんなことが起こったのかは不明ですが(恐らくSqale側がなんらかの理由でアップデートしたものと思われます)Gitにコミットしてあった使用中のDB情報を入力することで正しいダンプファイルを書き出すことができました。

s3cmdコマンドの設定

アクセスキーなどの情報はAWSのIAMから確認できます。スーパーユーザーで操作するよりも、新しいアカウントを作ってS3のみの権限だけにしとくといいかも。

Sqaleにログインして、下記のコマンドを入力。質問されたことに淡々と答えます。

$ s3cmd --configure Enter new values or accept defaults in brackets with Enter. Refer to user manual for detailed description of all options. Access key and Secret key are your identifiers for Amazon S3 Access Key: [access key] Secret Key: [secret key] Encryption password is used to protect your files from reading by unauthorized persons while in transfer to S3 Encryption password: Path to GPG program [/usr/bin/gpg]: When using secure HTTPS protocol all communication with Amazon S3 servers is protected from 3rd party eavesdropping. This method is slower than plain HTTP and can't be used if you're behind a proxy Use HTTPS protocol [No]: yes New settings: Access Key: [access key] Secret Key: [secret key] Encryption password: Path to GPG program: /usr/bin/gpg Use HTTPS protocol: True HTTP Proxy server name: HTTP Proxy server port: 0 Test access with supplied credentials? [Y/n] Y Please wait... Success. Your access key and secret key worked fine :-) Now verifying that encryption works... Not configured. Never mind. Save settings? [y/N] y Configuration saved to '/home/sqale/.s3cfg'

これでs3cmdコマンドにS3にアクセスする権限が付与されました。

S3にダンプデータを書き出す

ということで先ほど作ったダンプファイルをS3に書き出します。s3cmd mdコマンドはmake backetです。バケット名はS3全体で一意制約ですので、自身でユニークな名前をつけてあげる必要があります。

s3cmd mb s3://kamiya-sqale-backup s3cmd put mysql.dump s3://kamiya-sqale-backup/mysql.dump $ s3cmd put mysql.dump s3://kamiya-sqale-backup/mysql.dump mysql.dump -> s3://kamiya-sqale-backup/mysql.dump [1 of 1]

3565419 of 3565419 100% in 3s 1111.94 kB/s done

これで書き出し終了です。S3からダンプファイルをダウンロードしてまいりましょう。

ClearDBにダンプファイルをぶちこむ

herokuのコンソール→環境変数からclaarDBのホスト名やユーザー名、パスワードを取得します。

ローカルにさっきのダンプファイルを置いておき、ローカル環境から下のコマンドでClearDBにデータをぶっこみます。コマンドラインからパスワード使うとwarning出ますので、気にするかたは他の方法を考えてください。

Kamiya-no-MacBook-Air:~ kamiyayusuke$ mysql --host=us-cdbr-iron-east-01.cleardb.net --user=[username] --password=[password] heroku_[heroku db name] < mysql.dump Warning: Using a password on the command line interface can be insecure.

Pushしたらエラーが出たのでGemfileを修正

そのままgit pushしたら怒られたので

# Gemfile #gem 'pg' gem 'mysql2' gem 'mysql'

とします。

またrejectされた

Can't connect to MySQL server on '127.0.0.1' (111) (中略) ! Precompiling assets failed. ! Attempted to access a nonexistent database: ! https://devcenter.heroku.com/articles/pre-provision-database ! ! Push rejected, failed to compile Ruby app

なんぞこれ。

Push Rails / ClearDB App to Heroku Error 'Can't connect to MySQL server on '127.0.0.1'

こちらを参考に、

# config/application.rb config.assets.initialize_on_precompile = false

したら成功した。

またエラー。DATABASE_URLが無効と言われた

Kamiya-no-MacBook-Air:purchase_management_system kamiyayusuke$ heroku run rake db:migrate Running `rake db:migrate` attached to terminal... up, run.1904 <top (required)> at /app/Rakefile:7) rake aborted! Invalid DATABASE_URL

https://devcenter.heroku.com/articles/cleardb

こちらを参考に環境変数を設定。herokuのWebコンソールを開き、環境変数を設定。

herokuにClearDBアドオンをインストールした時点でCLEARDB_DATABASE_URLが既に設定されているかと思うので、これをコピーしてDATABASE_URLという値にして保存。

なお、ここで変数冒頭のmysql://をmysql2://に変更する必要があるらしい。

heroku run restartで動くはず。

まだ動かない…なぜだ…

2014-12-12T03:22:04.153000+00:00 app[web.1]: ActiveRecord::StatementInvalid (Mysql2::Error: INSERT command denied to user 'xxxxxxx'@'ip-xxxx.ec2.internal' for table 'sessions': INSERT INTO `sessions` (`created_at`, `data`, `session_id`, `updated_at`) VALUES

と思ってたらDBの容量(5MB)をオーバーしてただけでしたｗ

現代の小説のように程良く効いたスパイス感みたいのは無いけれど、不思議を引き込まれる魅力があります。すごく長いけど、苦にならない。

幕末の時代に生きる男たちがそれぞれの正義のために奔走し、命を落としていく。血なまぐさくもあるけど、青春小説って感じでもある。アツいものがこみ上げてくる一冊です(8冊？)

最後、龍馬が暗殺されるシーンでは、大きく感情が揺さぶられます。描写とかそういう話ではなく、その壮絶な運命に。忙しい人は最終巻だけでも読んでもらいたい。

さて、なぜ龍馬の功績は犬猿の仲であった薩摩藩と長州藩の仲を取り持ち、土佐藩もくっつけて一大倒幕勢力を作り上げたことと言われてます。なぜ龍馬にそれができたのか。なぜ龍馬が時代を変えられたのか。色々あるけどこの辺りが大きなポイントなんじゃないかと思います。

幕末の世の中で、新しいことにどんどん取り組む

例えば、海援隊の前身となる亀山社中という組織を作ったけど、これは日本初の株式会社と言われている組織。現代の日本じゃ新しいことをすることが常識となってるけども、亀山社中ができたのは幕末の世の中。必要とするエネルギーは現代の比じゃないと思う。

時代の流れを読む能力があった

今じゃないってときは来るべきときに備えながらじっとふせている。けど動くべきときは全力で目の前のことに取り組む。

カリスマ性だけでなく剣という一芸を持っていた

北辰一刀流の腕前がなければことを成し遂げる前に命を落としていたという実際的なメリットもあったけど、そういうことじゃなくてやっぱり一つのことを突き詰めた経験っていうのはその人の軸になり、芯のある人なんじゃないかと思う。

他人を活かす能力

剣の腕も弁舌も立つし最終的にはなんでもできるようになっちゃう龍馬だけども、事をなすときは他人を立て、他人に頼る。

みたいな感じです。

こう書くと、現代のビジネスマンのお手本みたいな人に見えるけども時代は幕末。何百年も昔の話ということに驚きを隠せません。

GoogleAuthenticatorを使っててストレスに感じるのは、

よしログインっと。あ、ケータイどこだっけ…

ケータイ変えた。あ、二段階認証設定しなおさなきゃ。

的なときです。Authyを使うとこれらの問題を解決することができます。

さて、Authyとはなにか一言で言い表しますと、クラウド型GoogleAuthenticatorです。iOS、Android、PC、Macと複数のデバイスで認証情報を共有することができます。

設定はとてもかんたんで、最初にメールアドレスとパスワードを登録。あとはいずれかのデバイスで認証情報を設定すると、他の全てのデバイスでその状況を利用できるといったものです。

またPCやMacから利用する際は、認証コードをクリップボードにコピーするボタンもついてるので都度テンキーを叩く必要もなくなります。

世の中にはたくさんのクレジットカードであふれています。しかし、カードの紹介サイトとかを見ても、ただ有名なだけのカードがランキング上位に行ってたり、評価基準がまちまちだったりで結局どのカードが優れているのかわかりませんでした…

もっと平等な指標でわかりやすい比較があったらいいのに。と調べながら感じていたのですが、この情報収集を通して自分なりに情報整理ができましたので、折角なので記録に残しておこうと思います！

カードの価値を平等に測るため、まずは評価基準を定めます

たくさんのカードが好き勝手な数字で自身の価値を謳っていますので公平でかつ明確な指標が必要ですよね。

そこで、こういう式を立ててみました。

還元率(カードの価値)　＝　付与率（どれだけ多くポイントがつくか）　✕　換金率（付与されたポイントの価値）

ただポイントがたくさん付けば良いというわけではなく、そのポイントがどれほどの価値があるかという点も大切です。

つまり、ポイントがつく量とポイントの質を掛け算してあげればカードの本当の価値がわかるということです。

ただ、カードの評価を始める前に式中の「換金率」についてちょっとだけ補足させていただきます。

付与されるポイントの種類とその価値について

同じ1ポイントでも、どのようなポイントかによってその価値は千差万別。

ポイントって意外と使いドコロが難しい場合ってありますよね。ただポイントは使用して初めて価値がでるものです。いつまでも眠らせておくメリットはひとつもありません。

また、1ポイント→1円のつもりで貯めていたポイントが、結局0.5円や0.6円にしかならなかったら損ですよね。

というわけで、換金率の良し悪しを決めるのは以下の基準です。

どれだけスムーズにポイントを利用(換金)できるか

1ポイント→1円変換にどれだけ近づけられるか

という点で評価しています。

カードで付与されるポイントといっても様々な種類があります。景品と交換できたり、電子マネーのように使用できたり...そこで、まずは様々な種類のポイントを検証してみましょう。価値の高い順から並べています。

1.キャッシュバック系ポイント

1ポイント＝1円分

ポイントをそのまま現金に変換できる特典です。わかりやすくて、色んなポイントの中で最も現金に近いポイントですね。

2.電子マネー系ポイント

1ポイント＝0.95〜1円分

Suica、楽天EDYに代表される電子マネーです。

例えばSuicaであれば、東京に住む人であれば遅かれ早かれ必ずと言っていいほど消費できます。

ただ、消費し忘れや端数が出ちゃったりと、色々な理由もあって中には消費できない人もいるでしょう。また利用機会も現金に比べると当然少なくなります。それを考慮すると現金やキャッシュバック系のポイントと比べて若干価値の劣るポイントです。

3.ギフトカード系ポイント

1ポイント＝0.85〜0.95円分

Amazonギフトカードや楽天スーパーポイント、JCBギフトカードなどなど。

その人のライフスタイルによって消費率は変わってきますが、現金や電子マネーに比べると利用先、利用機会がより絞られるため、キャッシュバック系ポイントや電子マネー等に比べるとさらに価値は下がります。

4.プレゼント交換系ポイント

1ポイント＝0.5円分？

ポイントがたまると、好きな景品と交換できるというアレです。価値には結構なムラがあります。

交換可能な景品に魅力的なものがない場合や、景品を現金で購入する場合と比べて割高な場合が多いことを考えると最も価値の低いポイントでしょう。

それではこの評価基準に基づいて有名ドコロのカードを何枚か評価してみますよー！

今回エントリーいただくクレジットカードの皆様はコチラです！

楽天カード

Amazonマスターカード

ライフカード

ANAカード

リクルートカードプラス

ReadersCard

REX Card

なお、アメックスやダイナースをはじめとするステータス系のカードは有名ではありますが、総じて還元率が低めだったり年会費が極めて高額だったりします。お得なカードを探すという今回のテーマに基いて参加カードを選定させていただきました。

それでは検証開始です↓↓↓

楽天カード

付与率1％　✕　換金率0.95　＝　還元率 0.95% 年会費 0円

楽天カードマンで有名な、ご存知楽天カードです！

楽天カードで買い物をすると、利用額の1％の楽天スーパーポイントが付与されます。楽天市場での買い物や、ブックス、トラベル、EDYへの換金などでも使えるためポイントの利用機会が豊富なことから、その価値(換金率)も0.95と高めに設定させていただきました。

還元率0.95%。ということで楽天カードマンの戦闘力は0.95でしたｗ

この数字が高いか低いかは続きをどうぞ↓↓↓

Amazonマスターカード

付与率 10％ ✕ 換金率 0.095 ＝ 還元率 0.95% 年会費 1,350円(初年度は無料)

結果は楽天カードと同等ですが、計算過程がちょっと異なります。

利用額の10%(Amazonでの買い物の場合は15%)ポイントが付与されるのですが、1,000ポイントで100円分のAmazonギフトカードに変換できます。

Amazonをよく使う人ならこれくらいのポイントは余裕で消費できるでしょう。換金率も楽天スーパーポイントと同等とさせていただいています。

楽天よりもAmazon派の人は楽天カードよりもコチラのがいいかもしれませんね。(年会費はかかりますが)

ライフカード

付与率 0.225％ ✕ 換金率 6.0 x 0.95 ＝ 還元率 1.28% 年会費 0円

高還元と評判のライフカードです！還元率1%を越えました！しかしポイントプログラムのルールはかなり複雑…

まず、ポイント付与率は通常0.1%、年間150万以上利用で2年目から0.2%、誕生月のみ0.5%。

ここでは長期利用を前提としますので、均して0.225%とさせていただきます。計算式→(0.2x11+0.5x1)/12 = 0.225

次に換金率です。

わかりやすく、最もパフォーマンスのよさそうなAmazonギフト券で試算してみましょう。いくつかバリエーションがありますが、最大と最小は以下の通りです。

1,000ポイント → Amazonギフト券 5,000円分

14,500ポイント → Amazonギフト券 100,000円分

つまりAmazonギフト券への変換効率は5.00〜6.89です。

ただ最大を取ろうとすると、累計で725万円カードを利用する必要があり現実的ではありません。ここでは均して6.0とさせていただきます。

んでAmazonギフト券の換金率を0.95としますと、ライフカードの還元率は0.225 ✕ 6.0 ✕ 0.95で、1.2825%でした。

上述の楽天カードやAmazonマスターカードと比べてパフォーマンスはよさそうですが、換金までの敷居が高いのと、年間150万縛りなので一年目の還元率が低いこととライトユーザーは利用できない事は考慮しなければなりませんね。

ANAカード

付与率 1% ✕ 換金率 0.9〜2.0 ＝ 還元率 0.9〜2.0% 年会費 4,320円(JCBの10マイルコースで試算。初年度は2,160円)

マイルがいっぱい付くANAカード。マイルは通常のポイントと比べても価値が高そうなイメージがありますが、実はこいつクセモノです。

マイルを使うと、飛行機をオトクに予約できる！というイメージがあります。確かに割安に予約はできるのですが、諸々の制約があるのです。

例えば東京＝大阪間を飛行機で往復しようとすると大体30,000円程度はかかるものが、12,000マイルくらいで予約できちゃいます。

これだけ聞くとマイルすげー！となるのですが、実際にマイルで予約しようとすると全くもって予約がとれません。航空機のマイルでの予約枠は通常の席と異なり、席数に余裕のある便しか予約ができないようです。空席照会しても全枠の7割くらいは埋まってます(同じ時間帯を通常予約しようとするとガラガラ)

つまり、土日や連休に合わせてマイルで旅行しようというのはまず不可能ということです！

ちなみに僕は昔このカードを使っていて、数万マイル溜まったところで旅行に行こうとしたところ、このマイル予約のカラクリに直面し衝撃を受けたことも記憶に新しいです(先に言えよって感じ)。最終的には消化しきれず、楽天のポイントとかに1マイル→1ポイント変換して使った記憶があります。

実際に使ったことのある私からしてみればマイルの換金率はせいぜい0.95ですが、人によっては最大で2.5とか行く場合もあるのでこのように書かせていただきました。うまく使えればメリットの大きいカードですが、とてもを選ぶカードです。ご注意を。

リクルートカードプラス

付与率 2.0% ✕ 換金率 0.8 ＝ 還元率 1.60% 年会費 2,160円(税込)

高還元をうたうリクルートカードプラスです。実際今回紹介するカードの中では最も付与率の高いカードとなります。

付与されるポイントもリクルートグループで1ポイント1円として使えるポイントなので一見価値も高そうなのですが、同じショッピング系の楽天やAmazonのポイントと比べると若干価値は劣るように思います。

ポンパレモールは楽天市場やAmazonに比べると品揃え・価格設定が今ひとつですし、ホットペッパーやじゃらん等も利用機会がかなり限られてしまいそうだからです。

とはいえ、これらのサービスを多く利用する方であれば大変還元率の高いクレジットカードとなりそうです。

Readers card

(1)Amazonデポジットで換金する場合 付与率 1.8% ✕ 換金率 0.93 ＝ 還元率 1.67%　 (2)現金に換金する場合 付与率 1.5% ✕ 換金率 1.0 ＝ 還元率 1.50% 年会費 0円(年50万未満利用だと2,700円)

ジャックスが提供してる高還元カード。名前のReaderっていうのは読書をする人って意味で、Amazonを使うよく使う人が大きな恩恵に預かれるカードです。

ポイントが大量に付与されるだけではなく、Amazonデポジット(後述します)に交換できるので比較的換金率も高いです。また現金還元も可能。(上の式のカッコ内の数字は現金の場合の数字です。)

ただこのAmazonデポジットも、

即日付与されるわけではない点

交換単位が比較的大きい点(3,500円or5,000円)

有効期限が三ヶ月で残高照会がやりにくい点

などを考えると、Amazonギフト券よりも多少利用価値が劣ります。なので換金率は0.93としています。

とはいえかなりパフォーマンスの高いカードです。Amazonをよく使う人にとっては、Amazonが公式に推しているAmazonマスターカードよりもこっちのほうがお得なんですね…ｗ

REXカード

付与率 1.75％ ✕ 換金率 1.0 ＝ 還元率 1.75% 年会費 0円(年50万未満利用だと2,700円)

あまり聞き慣れないカードかもしれませんが、僕はこのカードをメインで使ってます。

まず付与率は1.75%、そしてキャッシュバック型のポイントなので3,500ポイント→3,500円に交換できます。(厳密に言うとキャッシュバックというよりも翌月の請求額から3,500円をマイナスするという形になるのですが、継続して利用していればキャッシュバックと同義です)

デメリットとしては、ポイントを使うときはJACCSのウェブ画面から申し込み作業が必要なので定期的に手続きが必要なのと(ほんの数クリックで完了するのですが)、この管理画面がクソUIで使いにくいってことくらいです。

高還元ってだけではなくて、キャッシュバック型なので人を選ばないというポイントも大きなメリットです。

まとめます！

先ほど検証したカードたちを、一覧表にしてみます。※メイン利用カードを想定しているので、一定額以上利用で年会費無料のカードは0円としています

カード名 還元率 還元率順位 年会費 メリット デメリット 楽天カード 0.95% 同5位 0円 ポイントの利用機会が豊富 - Amazonマスターカード 0.95% 同5位 1,350円 Amazon使う人は◯ - ライフカード 1.28% 4位 0円 - ポイントプログラムが複雑 ANAカード 0.9〜2.0% ？ 4,320円 飛行機にポイントを使って乗れる マイルでの飛行機予約は選択肢が少ない リクルートカードプラス 1.60% 3位 2,160円 高付与率 ポイントが使いにくい ReadersCard 1.67%/1.50% 2位 0円 Amazon使う人は◎ - REXカード 1.75% 1位 0円 キャッシュバック型のため人を選ばない ポイント変換時に都度Webから手続きが必要

結論としては、REXカードが最もハイパフォーマンスですね！

そして楽天カードマンの戦闘力は0.95でした…お得なイメージのある楽天カードも、このように数値化してみると意外と他の高還元カードに及ばないことがわかりますｗ

とはいえ楽天をよく使う人にとっては、楽天カードを持ってることが参加条件のキャンペーン等もあるので持ってる分には良いカードだと思います(年会費無料だし)

経済的合理性をとるならば、還元率の最大となるクレジットカードを作り、公共料金から交際費まで全てをそのカードに一点集中させるのが最も合理的な消費の仕方ですねー。

なんとなく作ったカードをずっと使ってる方がいらっしゃったら、一度だけで良いのでちゃんと考えなおしたほうが良いと思います！一度作っちゃえばあとは放っといても差が出てきますので、考え方によってはひとつの不労所得です。

還元率0.5%のものを使うか、1.75%のものを使用するかで100万使えば12,500円利益が出るわけですしね。

あとは引き出しの奥に眠ってるクレジットカードとか、意外と年会費を取られ続けてたりするので不要なカードはどんどん解約しちゃうのも必要だと思います。

MoneyForwardやMoneyTreeとかで自分の資産を監視するのも結構良いですね。金融系のウェブサービスや電子マネーなどについても色々思うところがあるので、また時間のあるときにでも書こうと思います。

この記事を書くにあたって、ちゃんと調べたつもりではあるのですが、もし間違いなどあればご指摘ください！また他にパフォーマンスの高いカードの情報提供なんかもいただけると嬉しいです！

自宅のネット環境が建物に最初から備え付けられていたイマイチ回線なんで、フレッツへの乗り換えのため色々調べてみました。◯万円キャッシュバック！とかよく見るけど実際見てみるとごちゃごちゃしててわかりにくいアレです。

— かみやし (@yuskamiya) 2013, 10月 22

まず申し込み窓口についてですが、キャッシュバック金額で大体４つに分類できます。

— かみやし (@yuskamiya) 2013, 10月 22

【１】２万円前後のキャッシュバック　公式プロバイダやNTTとかがやってることが多いです。しょーじきあまりお得じゃありません。

— かみやし (@yuskamiya) 2013, 10月 22

【２】４万円前後のキャッシュバック　ググるとたくさん出てきます。薄利でやってるNTT代理店の中小企業がやってる印象。申し込みから二ヶ月三ヶ月くらいで現金で還元されるようです

— かみやし (@yuskamiya) 2013, 10月 22

【３】５万円前後のキャッシュバック　カカクコムとか。条件は２とほとんど一緒ですが支払いは申し込みから一年後くらいになります。もちろん一年間は回線もプロバイダも申し込んだ内容で使い続けなければなりません

— かみやし (@yuskamiya) 2013, 10月 22

【４】７万以上のキャッシュバック　ハッタリです。詳細見ると、高額なオプションサービスを◯ヶ月使い続けることみたいな条件があります。無いものとして考えましょう。キャッシュバック金額だけで言えば３がMAXです

— かみやし (@yuskamiya) 2013, 10月 22

ちなみに、契約内容や月々の支払い金額で言えば１から４は殆ど一緒です。僕の住んでる一人暮らしマンションとかだと月間４０００円弱になることが多いようです。ではその契約内容について内訳を見ていきます、

— かみやし (@yuskamiya) 2013, 10月 22

最初にわかっておくべきことは「どの窓口から申し込んでも結局使うのは、NTTのフレッツ回線とどこも大差ないプロバイダの選択肢」ということです。

— かみやし (@yuskamiya) 2013, 10月 22

まず純粋な回線（フレッツ）のみの料金です。二年契約で毎月２９００円くらいに落ち着きます。二年未満で解約すると１５００円の解約金が発生します。これにプロバイダ料金がのったのが月額利用料になります。

— かみやし (@yuskamiya) 2013, 10月 22

プロバイダは月額６００円〜１０００円なのでフレッツ月額と合わせてはトータル支払いは約３８００円。条件はプロバイダごとにまちまちです。◯ヶ月無料！とか二年縛りのところとかもあります。ここは多岐にわたるのでここでは割愛します。

— かみやし (@yuskamiya) 2013, 10月 22

んで、初期工事費用。これがクセモノ。

— かみやし (@yuskamiya) 2013, 10月 22

うちの場合は、工事費２６０００円くらいでした。これは一括でも分割でも支払うことができます。分割で支払った場合、８００円✕３０回で支払うと毎回７００円の割引を受けられます。つまり分割で払うと実質負担額は月々１００円になります。

— かみやし (@yuskamiya) 2013, 10月 22

ただし、解約するとその時点で割引はなくなります。つまり仮に１５ヶ月で解約したら工事費の半額１３０００円はそのままの金額で支払わなければなりません。

— かみやし (@yuskamiya) 2013, 10月 22

長く一箇所に住む人だったらいいけど、一人暮らしとかで先がわかんない場合はちょっとこわいですね。僕の場合はキャッシュバックしてもらってもトータルコストは殆ど変わんないことが判明しました。

— かみやし (@yuskamiya) 2013, 10月 22

三行でまとめます。

— かみやし (@yuskamiya) 2013, 10月 22

１　キャッシュバックは４万前後の代理店にしとけ２　フレッツならどこで申し込んでも月額４０００円弱３　今の家に３０ヶ月以上住む人はキャッシュバックで得できる

— かみやし (@yuskamiya) 2013, 10月 22

以上、自分のためのメモでした。

仲間を活かすには仲間から信頼される必要がある。では信頼されるにはどうしたらよいか。

大きく難しい仕事にいきなりとりかかるよりも、目の前のことを一つ一つ片付けていくことで、いつの間には難題の解決の糸口がみつまりますよ。

といった感じ。

「リーダーはイシューから入ってはいけない」といった世間一般のビジネス書にあるリーダー論と一見逆の見出しも存在します。ただ、読み進めていくとそれが相反する主張ではないことがわかります。理想を高く掲げすぎず、できることから着実に進めていこうということ。

リーダー論というよりは、誰しもが実践でき、実践したほうがよい内容だと思います。

この本は読んでいておもしろく勉強になる点も多々ありました。良書です。

世間一般にあふれるビジネス書ですが、まさに玉石混交。すばらしい発見をさせてくれる書もあれば、つまらないものもあります。

いいなと思う書は、表現の仕方こそ違えど主張の根幹にあるものは共通しているように思います。

けど同一インスタンス内の、他のサービスは生きてるようなのでuginxかその周辺に原因があると当たりをつけて対応しました。

対応

とりあえずは404を返してるnginxを再起動。

$ sudo service nginx restart Stopping nginx: [ OK ] Starting nginx: [ OK ]

しかし未だ404。

今度はconfファイルの中身を確認。

cat /etc/nginx/nginx.conf

問題なさそう。

nginxが404を返してる→nginxは動いてる？ってことで今度はお隣さんのunicornを再起動してみます。

$ bundle exec unicorn -E production -c config/unicorn.rb -D

ブラウザでアプリを呼び出してみると…

使用OS：ubuntu14.04

最初に必要なプログラムをインストール。

$ sudo apt-get install samba $ sudo apt-get install system-config-samba

※↑ではsambaをインストールしてますが、samba4っていうプログラムも存在するみたいです。一度こっちの4のほうをインストールしてわけわからんことになってしまったので、直接sambaだけをインストール。そしてそのままsystem-config-sambaも入れちゃいます。

そしたら早速system-config-sambaを起動します。

sudo system-config-samba

するとサーバー設定のGUIウインドウが開きますので共有ディレクトリの設定をしてあげます。

左上の「＋」マークをクリックして、ディレクトリ、共有名を追加。「アクセス」タブから「誰でもアクセスを許可する」を選択。そしてOKボタン。

invoke-rc.d: initscript samba, action “restart” failer.

後ろのターミナルにエラーが表示されました。再起動に失敗しましたといってます。。

原因探ってるほど時間ないので、手動で再起動。

$ sudo service smbd restart smbd stop/wating smbd start/running, process 31145

ここまで作業すると、同一ネットワーク内のウインドウズから共有フォルダとして認識されるようになりました。

ただ、見えたことは見えたけど書き込みができない。権限設定します。

sudo chmod 777 kyoyu

777だと、誰でもなんでもできちゃうので好ましくないかと思いますが、社内LANに置いとくだけのものですので、とりあえずこれでOKです。

CASinoでSSOサーバーを構築してみる

まずCASinoへのログイン方式についてですが、数種類のの認証方法が提供されています。LDAP、Static、ActiveRecordなどがありますが今回はActiveRecordにて認証する方法を採用します。

Authenticators

ユーザー管理の部分をdeviseで構築しようと思いましたが、セッション管理をそれぞれの方法でもってるので、セッション同士が入り組んでぐちゃぐちゃになりそうなので自分で実装することにしました。

まずはRailsアプリケーションを作ります。

$rails new cas-server --skip-test-unit --skip-bundle

Gemfileを整えます。

# Gemfile gem 'casino'

お決まりのコマンドと、casinoのインストールコマンドを打ちます。

$bundle install --path vendor/bundle $bundle exec rails g casino:install $bundle exec rake db:migrate SCOPE=casino

コンソールに下記のような出力がされ、準備が整いました。bundle exec rails sすると、ローカルでサーバーが立ち上がります。

The CASino Engine has been correctly installed in your Rails application.

Edit the configuration file:

config/cas.yml

Edit or delete (to use the integrated) layout file:

app/views/layouts/application.html.erb

Run the generated CASino migrations

bundle exec rake db:migrate SCOPE=casino

Launch the server

bundle exec rails server

Open your browser

open http://localhost:3000/

Enjoy!

ユーザーモデルを作る

ここからはCASinoでログインできるよう設定していきます。ログインするためにユーザーモデルとパスワードを扱う機能を実装する必要があります。

# Gemfile gem 'casino-activerecord_authenticator' gem 'bcrypt' rails g scaffold user name:string password_hash:string email:string fullname:string role:integer rake db:migrate

cas.ymlの設定を行います。username_columnとpassword_columnにはユーザーモデルのログインネームとパスワードの値を設定 します。

development: <<: *defaults authenticators: my_company_sql_database: authenticator: "ActiveRecord" options: table: "users" username_column: "name" password_column: "password_hash" extra_attributes: email: "email" fullname: "fullname"

production: <<: *defaults authenticators: my_company_sql_database: authenticator: "ActiveRecord" options: table: "users" username_column: "name" password_column: "password_hash" extra_attributes: email: "email" fullname: "fullname"

casino-activerecord_authenticatorのデフォルトの暗号化はBCryptを使用しています。そのためUserインスタンスを作成したときは、パスワードをBCryptで暗号化してDBに保存してあげる設定をしましょう。

# model/user.rb require 'bcrypt' class User < ActiveRecord::Base include BCrypt def password @password ||= Password.new(password_hash) end def password=(new_password) @password = Password.create(new_password) self.password_hash = @password end end

view/user/_form.html.erb フォームのパスワードの部分だけ書き換えてあげます。

<div class="field"> <%= f.label :password %><br> <%= f.password_field :password %> </div>

ここまで設定すれば、WEBrickでCASinoにログインができるようになったと思います。ただユーザー管理機能についてはscaffoldを作っただけなので外からも中身が丸見えですのでちょっと手を加える必要があります。

ここまで作業したところherokuにデプロイしても動作確認ができました。次はクライアントのテストアプリケーションを構築してみたいと思います。

作業中に直面したエラー

CASinoにいくらやってもログインできない

ずっとIncorrect username or password.エラーが出て正しいパスワードを入れてもログインできない。

調べていくとユーザー名だけ入れてパスワードを空の状態でログインすると成功する。どうやらstrongparameterの影響でパスワードがブランクの状態でBCryptエンコードが行われている模様。

原因はBCryptのドキュメントを鵜呑みにしてUserコントローラのcreateを↓のようにしていたのが原因。

def create @user = User.new(params[:user]) @user.password = params[:password] @user.save! end

scaffoldの初期値に戻したところ、正常にパスワードが登録されるようになりバグ解決。

herokuデプロイ後、CASinoにログインできない

something went wrongが出る。原因はCASinoの例通りにcas.ymlにconnectionオプションを含めたままにしていたこと。