Importing Ashley Madison CreditCardTransactions CSVs to MySQL
アシュレイ・マディソンのクレジットカード取引CSV を MySQL にインポートする
各CSVの頭にあるヘッダはこうなっている。カード番号は、下4桁のみ。
Each CSV files have the following header. It contains last 4-digits of credit card number.
ACCOUNT,ACCOUNT NAME,AMOUNT,AUTH CODE,AVS,BRAND,CARD ENDING,CVD,FIRST NAME,LAST NAME,MERCHANT TRANS. ID,OPTION CODE,DATE,TXN ID,CONF. NO.,ERROR CODE,AUTH TYPE,TYPE,TXT_CITY%2CTXT_COUNTRY%2CTXT_EMAIL%2CTXT_PHONE%2CTXT_STATE%2CTXT_ADDR1%2CTXT_ADDR2%2CZIP%2CCONSUMER_IP,
これに対応したテーブルを作る。フィールド長がわからないので、適当に varchar(255) にしておく。インデックスも、使いそうなフィールドに適当に付けておく。
I created the corresponding table below. Each field length is unknown, so use varchar(255). Additionally, I added some indexes to maybe useful fields.
OpenID TechNight Vol.13 - ID連携入門
https://openid.doorkeeper.jp/events/29487
ID連携概要 by @nov
- Authentication: ブラウザの前にいる Entity が、サービス側が認識するどの Identity と紐付いているかの確証を得ること。
- Authorization: リソースにアクセスするための条件を定めること。
- Audit
- Identity Proofing: Identity(属性の集合)の確からしさを測ること。
- それ確認したの、何年前?
- 無料じゃない。継続的にコストがかかるものもある。どの属性を proof するかに依存。
- Disqus に FB でログインするとき。
- Entity - Facebook Identity - Disqus Identity の紐付けを確認。
- FBの言うことは信用する。FB が言っているかどうかの確認はする。
- 理想と現実
- 属性連携は最初だけ? コンシューマー領域では問題にならないことが多い。エンタープライズでは、例えば部署異動が反映されずに、アクセス制御が期待通りに動かないことが問題視されることがある。
- OAuth 1.0 / OAuth 2.0 / OpenID Connect で、IdP がユーザーを認証した証拠の表現形式、検証方法が異なる。OAuth 1.0 / 2.0 なら IdP ごとにも異なる。Server-side app / Native app / Native app backend / JS app なのかでも検証方法がことなる。
Rails の migration で references カラムを削除する
「カラム名:references」を指定すればいい。
$ rails g migration remove_カラム名_from_テーブル名 カラム名:references
$ cat db/migrate/20150826023224_remove_カラム名_from_テーブル名.rb
class Removeカラム名Fromテーブル名 < ActiveRecord::Migration
def change
remove_reference :テーブル名, :カラム名, index: true, foreign_key: true
end
end
テーブル名は複数形でも単数形でも動くが、RailsGuides では複数形で記述している。
これを、remove_column でやろうとすると、外部キー制約に引っかかって削除できずにエラーが出る。たぶん index: true, foreign_key: true 付ければいけるけど。
Mysql2::Error: Cannot drop index 'index_テーブル名_on_カラム名': needed in a foreign key constraint: ALTER TABLE `テーブル名` DROP `カラム名`/Users/xxx/git/xxx/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.1/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:299:in `query'
Amazon Linux AMI を 2013.09 から 2015.03 にアップデートした
まず、/etc/yum.conf に releasever=latest を付け加える。
# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum/$basearch/$releasever
debuglevel=2
distroverpkg=system-release
exactarch=1
gpgcheck=1
installonly_limit=3
keepcache=0
logfile=/var/log/yum.log
obsoletes=1
plugins=1
releasever=latest ←これ
そして yum update する。が依存性のエラーが出る。
SPA の設計とアーキテクチャ Chapter 1(SPA Design and Architecture ch1)
Manning の “SPA Design and Architecture”、第1章のまとめです。
- Manning[http://www.manning.com/scott2/]
1. シングルページアプリケーションとは何か
- ウェブアプリ開発者の長年の夢は、デスクトップネイティブアプリに迫ること。
- SPAも同じ。JS、HTML、CSSだけでネイティブのようなアプリを作りたい。
- 2000年代初頭のAJAXから始まった。もともとはデータを非同期に送受信するためのIEのActiveXコントロールだった。それがXMLHttpRequestとして、メジャーなブラウザで採用された。
- ユーザ操作を止めることなくリクエストを出せるAJAXと、動的にDOMを変更できるJS、そして動的にページのスタイルを変えられるCSSによって、AJAXはウェブ開発の最前線となった。
- ページ内の操作だったAJAXをアプリ全体に適用したのがSPA。
- 発展途上の技術のため、様々なやり方があり、様々なライブラリがある。自分のSPAプロジェクトにとって何が最適なのかを見極めるのは難しい。
- SPAについて広い知識を持てば、正しい実装にたどり着きやすい。
- 本書では MV* フレームワークに限定して解説しているが、React や Web Components のような別のアプローチもある。