香港、深圳のネット環境とウェブアプリ開発

香港経由で深圳(シンセン)に来ています。ネット環境が思った以上に快適です。

中国電信(China Telecom)が運営する Wi-Fi で、以下のサービスが利用できました。しかも実用上困らない程度に速い。

  • Github
  • Slack
  • Chatwork(初回アクセスの loading が長いが、終われば普通に使える)
  • Backlog
  • SSH で EC2 のサーバにログイン(キー入力の遅延は問題無し)
  • AWS Console
  • Skype(ちょっと試した分には、音質は問題なし)
  • Yahoo! Japan
  • Outlook.jp

Chrome のアドレスバー検索を Y! Japan にしておけば、検索も困りません。Gmail、Facebook、Twitter は使えませんが、iPhone への通知は生きているので、通知されたものに関してはリアルタイムで気づきます。

そして、中国移動香港(China Mobile Hong Kong)の SIM を使ってスマホでテザリングすると、ローミングで香港経由にできるため、中国本土からも Gmail等が利用できます。ただし 標準で1日72MBまでなので、必要なときに最低限のことがピンポイントでできる程度です。でも、自由な通信ができるとできないとでは、大違いです。データパッケージを購入して上限を増やせます。

中国本土のネット環境を使う場合のウェブ開発

  • 開発対象のサイトでJSライブラリを googleapis.com からロードしていると、ローカル環境であっても動きません。
  • 開発対象のサイトにFacebookボタン、Twitterボタン、Google+ボタンなどを設置していると、タイムアウトまで待つのでブラウザのくるくるが長時間続きます。
  • その他 Google がオンラインで提供する各種ライブラリに注意。
  • 中国本土から日本の EC2 インスタンスに ssh したところ、ほとんど遅延もなく快適です。日本からアメリカの EC2 に ssh するのと同じような感覚。
  • S3 Bucket へのアップロード(s3sync)ができずタイムアウトする。アップロード画像をローカルからS3に置くような処理はできないと思う。

中国本土に入る前にやっておいたほうがいいこと

  • 【超重要】China Mobile Hong Kong の SIM を入手してアクティベーション、接続確認をしておく。香港国際空港の China Mobile HK で購入できる他、日本でも Amazon などで購入可能。これさえあれば、あとは何とかなります。
  • 【次に重要】上述のSIMを使う場合、TD-LTE対応の SIMフリースマホか、ポケットWi-Fiを用意しておく。
  • 【無くてもいい】めんどうな設定を省きたい場合は、海外用の Wi-Fi機器をレンタルしておくと、現地の携帯電話回線を使って、手元のスマホをWi-Fiで使える。何も考えなくていいので便利。Global Wi-Fi(http://townwifi.com/)など。香港と深圳は携帯会社が異なるため、それぞれレンタルする必要がある。今回は利用していない。上述の CMHK SIM を使う場合は、無くてもなんとかなる。
  • Gmail を常用している人は、Outlook などの別のメールアカウントを用意して、Gmail からメールを転送しておく。ただ、Microsoft がメールの内容を中国政府に公開する可能性があるので、機密性の高い業務をしている場合には避けたほうがいいかもしれない。
  • Dropbox、Google Drive の同期を済ませておく。Google Docs にもアクセスできないので、開発に必要な情報を置いている場合は、あらかじめローカルに置いておいたほうがいいでしょう。
  • Dropbox、Google Drive の同期を切っておく。香港ローミング中に大きなファイルを同期されて容量を使い果たすと困るので。
  • Web版の Google Calendar を見れないので、スマホアプリ、デスクトップアプリに同期させておいたほうがいいでしょう。

Capistrano3 で role 指定だと passphrase を聞かれないのに、server だと聞かれる

↓これは通る。

role :app, %w(deploy@xxx.xxx.xxx.xxx:2222)

↓これは通らない。SSH の passphrase を聞かれる。

server 'xxx.xxx.xxx.xxx', user: :deploy, ssh_options: { port: 2222 }, roles: %w(app)

↓これは通った。何故??

server 'deploy@xxx.xxx.xxx.xxx:2222', roles: %w(resque_worker)

AWS AutoScaling group のインスタンス一覧を ruby で取得する

require 'aws-sdk-v1'

AWS::config(
  access_key_id: 'xxxxxxxxxxxxxxxxxxx',
  secret_access_key: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  region: 'ap-northeast-1',
)

auto_scaling = AWS::AutoScaling.new

instance_ids = auto_scaling.groups['staging_web'].auto_scaling_instances.map(&:instance_id).to_a

response = AWS::EC2::Client.new.describe_instances instance_ids:instance_ids
for reservation in response[:reservation_set]
  for instance in reservation[:instances_set]
    puts instance[:dns_name]
  end
end

Kickstarter がベネフィットコーポレーションに

Kickstarter がベネフィット・コーポレーション(Benefit Corporation)になりました。Benefit Corporation は、日本語で公益法人と訳すこともできますが、概念が違うため、ベネフィット・コーポレーションと呼ぶほうが良いでしょう。

これはアメリカの州法で制定されている法人形態で、2010年にメリーランド州で制定されたのを皮切りに、2015年9月現在では31の州で制定済み、5つの州で制定作業中です。アメリカでは、今、ベネフィットコーポレーションを設立する動きが増えています。

アメリカの営利企業は、株主の利益を最大化することを目的としています。その結果、金銭的な関わりのないステークホルダーに対する貢献がしにくくなっています。公益を果たそうとすれば、どうしても株主利益を毀損しがちになります。従来の CSR は、企業市民として、利益を追求する以前に、社会の中で良き市民であるべきという考え方をしていました。 ベネフィット・コーポレーションは、CSR の先を目指す企業形態で、利益と社会貢献の両方を追求する営利企業です。

典型的には、既存企業をベネフィットコーポレーションに転換するには、株主の議決権の2/3以上の同意が必要です。企業のミッションを決め、定款に定め、株主が同意します。経営者が何か判断を下すときには、そのミッションに基づき決定します。株主利益に反する決断をしても、株主から訴訟を起こされることはありません。

一方、日本の公益法人は、税制優遇を受けるための制度です。まず、一般社団法人、一般財団法人、特定非営利活動法人(NPO法人)のいずれかを設立します。これらの法人が、内閣府、都道府県、政令指定都市などから公益認定を受けると、公益社団法人、公益財団法人、認定特定非営利活動法人(認定NPO法人)になります。

株主訴訟を受けずに公益を果たすためのアメリカのベネフィット・コーポレーションと、税制優遇を受けるための日本の公益法人。制度が生まれる基本的な動機が違っているといえるでしょう。

Kickstarter のベネフィット・コーポレーションとしての憲章(https://www.kickstarter.com/charter)には、毎年2.5%の税引き後利益を芸術や音楽へ、同じく2.5%の税引き後利益を不平等への戦いに寄付すると宣言しています。株主の前で、堂々とこういうことができるのがベネフィット・コーポレーションの魅力です。

Ashley Madison のクレジットカードブランド比率

> library(RMySQL)
> con <- dbConnect(MySQL(), dbname='creditcard', user='********', password='********')
> rs <- dbSendQuery(con, 'select * from creditcard_transactions')
> data <- fetch(rs, n=-1)
> nrow(data)
[1] 9685921

> data$brand <- factor(data$brand)
> summary(data$brand)
     AM      DC      DI ERROR_B      JC      LA      MC      MD       N    null      SW      VD 
1034597     573  260283      23    4021       5 2721562    2827       2   39012       1     250 
     VE      VI    NA's 
  22914 5599849       2 

> fac_levels = levels(data$brand)
> fac_levels
 [1] "AM"      "DC"      "DI"      "ERROR_B" "JC"      "LA"      "MC"      "MD"      "N"      
 [10] "null"    "SW"      "VD"      "VE"      "VI"     

> o <- order(table(data$brand), decreasing=TRUE)
> data$brand_fac <- with(data, factor(brand, levels=fac_levels[o]))

> summary(data$brand_fac)
     VI      MC      AM      DI    null      VE      JC      MD      DC      VD ERROR_B      LA 
5599849 2721562 1034597  260283   39012   22914    4021    2827     573     250      23       5 
      N      SW    NA's 
      2       1       2 

> options(scipen=5)
> barplot(table(data$brand_fac))

Credit card brands ratio