日本からのEMSの配送手数料を算出するGemを作りました

Ruby

概要

重量を引数（現状はグラムの単位のみをサポートしています。）にして、 EMSの各種配送エリアへの配送手数料を算出するGemを作りました。

jp_ems_fee | RubyGems.org | your community gem host

  JpEmsFee.asia(100) => 1200
  JpEmsFee.oceania(30000) => 36500

配送手数料について

なお、配送手数料については

www.post.japanpost.jp

上記サイトから、クローラーを使用してyamlファイルを生成して、参照しています。

少し工夫したこと

まず郵便局の公式サイトから料金データのyamlを作成するクローラーをまず作成することにして、 EMSの料金表に更新があってもある程度の速度で追いつくことができるようにはしています。

今は手動でクローラーを実行していますが、 今後はCircle CI or Travis CI経由でyamlの生成クローラーを自動で回すことができるようにしたいですね。 :)

あとはholiday_jpを参考にして、 yamlをGitのSubmoduleで参照できるようにしておけば他の言語での実装も容易になりそうです。

参考記事: http://docs.komagata.org/5401

クローラーはyamlファイル単体共々、後々公開する予定です。 また、JSでyamlを取り扱うのは少々面倒な気がするので、JSON形式でのデータも作成する予定でいます。

今後について

ぶっちゃけプロダクションではまだ使ってないです。（使う機会があるかと思いきやまだ無い。） これを使用するライブラリを作る予定なので、そのときには使うかと思います。

このライブラリを色々な言語のFizzBuzz的な代わりにしようかと検討してて、 色々な言語のサポートを予定しています。（サポートって言うほどやる実装なんかないじゃん。というツッコミはなしで）

もちろん、代わりに作ってメンテしてくれる方がいればとてもありがたいです。 :)

直近ではライブラリの公開にも慣れてるphpでの公開を目論んでいます。

言語が増えてきたら、Organizationも作るのかな…？という感じです。

Webアプリケーションの一番弱いところ

JSがどうこうとか、技術的観点の話は言及しない。

よくわからない人への説明がむずかしい

これだけだと思う。

別にiphoneに限った話ではないけど、 「iphoneで使っているものは全部アプリ。」 そう思っている人は一定数存在している。

Webブラウザで…ここからどうこうで…という説明は到底伝わらないのだ。

「URL・Safari・Webブラウザ…ナニソレ？？　えっ、アプリじゃないんですか？」という人たちも一定数存在している。

「じゃあ、QRコード経由でWebページにアクセスさせればいいじゃん。そうしたらSafariが立ち上がって…」

というような解が出てくると思うけどこれは最適解ではない。

AndroidではデフォルトでQRコードリーダがプリインストールされているけど、 iPhoneには入ってない。これでアクセスしてもらうにはQRコードリーダという「別にアプリ」が必要になるのだ。 とにかく不便。できれば1つのアプリで解決させたい。

そういう人でもいろいろAppStoreからアプリ入れてるから、アプリの入れ方については説明は不要だと考えてて、 アプリ名伝えて、検索してもらって、インストールの後に起動すればそれでおしまいなのだ。

Webアプリケーションの場合、最初にサイトに入ってもらうだけでも説明が必要な人が一定数存在するくらい大変なのだ。

アプリってすごいですよね。

まとめ

  • Safariを始めとした、Webブラウザを知らない人は一定数存在している。
  • Webアプリケーションオンリーで頑張るのは、エンジニアリングコストが低くなるメリットあるけど、ITリテラシーの低いユーザーには厳しい。
  • 本当に老若男女に使ってもらうアプリであれば、高コストを払ってでもアプリ化は避けられない。
  • アプリにすると最初に入ってもらうまでの説明がとにかく簡単になる。

僕の思う最強のEC CMSの条件

基本的な用途としては物販を想定して書いています。

デザイナーが迷わずにすぐつかえる仕組みかどうか

これに尽きる。 wordpressなんかはこれに近い感じ。

ここでいうデザイナーの定義を以下に列挙しておく。

  1. メインのお仕事は、HTMLやらCSSやらイラレ・フォトショップ
  2. wordpressのテーマに作り方ならわかる。
  3. phpはwordpressである程度だけど、そこまでできない。
  4. gitもしらない。
  5. FTP等の温かみのあるデプロイしかしらない。
  6. 黒い画面大嫌い。

ということなので、今回はWordpressでテーマを作ったことあるようなデザイナーをペルソナにして考えてみました。

Railsのテンプレートなんか書けるデザイナーなんかはごくごく少数であることを念頭においておきましょう。 そんなエンジニアに都合の良いデザイナーばかりではありません。 デザイナーにRailsやその他のテンプレートの書き方を覚えさせるなんて言語道断。 雑にView層に生php書かせればいいではありませんか。

以下に実現したい細かな目標を列挙しておく。

1.だいたいのレンサバで問題なく動く

ということなので、Herokuボタンは反則。却下である。

デザイナーがHerokuなんか知ってるわけ無い。

そもそもFTP使えないし、gitもしらないし。無理。あきらめろ。

それにそこまでお客さん来ないしVPSとか大げさな事しなくても、レンタルサーバーでいい。

redmineのクローンプロジェクトのCandyCaneなんかは、 レンタルサーバーで簡単に動いてくれることもあって、海外での需要も結構高いらしい。 まだまだレンタルサーバーは元気なのだ。

具体的には、

このあたりはサポートしたい。

2.1分インストーラー

デザイナーに黒い画面を叩かせたら負け。 ということになるので、wordpressやCandyCaneにも実装されている1分インストーラーが必須。 ちゃんと、php拡張が入っているかどうかをチェックする画面も必要。

3.Composerは使わない

使わないというのはウソかもしれない。（開発環境とかでは流石に使いたい。） でもレンタルサーバーで使うとまずデザイナーがハマるので、無理。却下である。 lib/ファイルに固めてしまって問題なく、ハマらないならやってしまいたいけど、 RubyGemにあるような鉄板な良いプラグインなり、ライブラリってPackagistにあるの？ オススメのライブラリ教えて下さい＞＜。

というのが正直な感想。 ハマりそうだし、どうしても使いたいのがなければ本番環境では使わない方向。

4.php5.3サポート（ある程度

CMSとしてはCentOS6系ではまだサポートしている5.3系をサポートするべきなんだけど、 普段Ruby書いてる身からすると、ただでさえコードが長いのに、 おまけにショートアレイシンタックスで書けないのは趣味プロジェクトとしてはマジで辛い。 気持ちが続けば5.3対応は続けたい。 やっぱり作る上で、フレームワークは使いたいので、 現状php5.3に対応しているFuelPHPあたりが筆頭候補になると思う。

5. 送料は簡単かつ柔軟に

送料は、クール便だったり、その他の対応だったりで結構しんどかったりする。 そういうのをベースの機能でカバーするのは絶対に無理だと思っているので、各々のエンジニアの実装力に任せようとは思ってる。

下手に都道府県別とかにしちゃうと、 海外ECの時にどうするかとか、 商品別にどうとか、いろいろマジで面倒なんで、 送料はhook的なものを作っておいて、そこに各々の処理を書けるようにしようかなと。 もちろんデザイナー向けに、 都道府県別の場合、 海外の場合（EMS）

くらいは入れておきたい。

6. 自動アップデート機能

なにかと嫌われがちな機能だけど、これはこれでセキュリティを守っていくうえでは重要な機能。 Wordpress並に後方互換性をもたせるのはつらそうだけど。

徹底的に敷居を下げる という意味では、本当はmysqlの対応を見送って、sqliteでやりたいところなんだけど、セキュリティに不安が残るので、やめる感じにしている。

内部仕様的には、 そこそこレガシーなphpなので、油断するとコードがカオスになりそうなので、注意したい。 CIはすぐに導入する。

まとめ

  • プログラミングができない人の立場になって考えて、使う人の学習コストを徹底的に下げる
  • レンタルサーバー万歳
  • これから最強のEC CMSに向けて頑張って作る
  • でも、BASEとかstores.jp使いたくないけど、某立方体は難しいし、使いたくないって人がそこまでいるのかわからないので、モチベーションを保てるかどうか心配
  • 普段Ruby書いてるので、phpでちゃんと出来るかどうか心配。色々思い出さないと。
  • あくまで趣味プロジェクトなので期待しないでください。

GitLab CIを触って暫くたったので雑な感想

いろいろどっかにGitlabCIについての知見をまとめてたはずなんだけど、なくしてしまったので書くのに時間がかかってしまった。

とりあえずどんな感じなのか雑に眺めたい方もいることなので、雑にまとめた。

Gitlab CI 3行まとめ

  • Gitlab CIはGitLabで使える。CircleCIみたいなもん。最初にちょっとセットアップすれば、Jenkinsより簡単・便利。カバレッジとか成功時にデプロイとか出来る。
  • GitLab RunnerというCIで使うコンテナを動かすサーバーの構築が必要になるが、必要な作業は大体これだけ。あとはアプリケーション側で設定する。
  • GitLab使ってたら使っていいと思う（特にアンチJenkins）

GitLab CIについて

  • Ruby + Go, Dockerを使っている
  • 8.2位からGitLabの機能に統合された。
  • .gitlab-ci.ymlにcircle.ymlっぽいDSLを書いていく
  • Push/MergeRequestをきっかけにCIが勝手に走る。
  • 後述する、GitLab Runnerの構築が必要になる。

GitLab CIで Railsプロジェクトをテストするまで

GitLab Runnerの構築

GitLab RunnerはCircle CIやTravis CIでいうところのコンテナを動かすサーバみたいなもん。 GitLabと連携して使う。

今回は、GitLabとは別のVPSサーバにRunnerを構築するという構造を想定している。

ほとんど手順に書いてあるまんま作業した。 gitlab.com

気をつけないといけないのはGitLabとGitLab Mulit Runnerの紐付け位なので、ここの解説だけしておく。

sudo gitlab-ci-multi-runner register

# Runnerを使用したいGitLabのURL + /ci を入力する。
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci ) 
https://gitlab.example.com/ci

# https://gitlab.example.com/admin/runners にRunnerに対して入力するTokenが存在するのでそれを入力
Please enter the gitlab-ci token for this runner 
xxx

# Runnerの説明を入力する。
Please enter the gitlab-ci description for this runner 
my-runner

INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh? # 実行方式を選択する
docker

# デフォルトで使用するDocker Imageを入力する
Please enter the Docker image (eg. ruby:2.1):
ruby:2.1

これでGitLab Runnerの設定は完了。 GitLabのAdminAreaにさっき構築したRunnerが表示されてればOK。 今回は説明は割愛するけど、リポジトリ専用で使用するRunnerを作成したりということも可能。

これは別のサーバにRunnerを構築するときの手順だけど、GitLabが入っているサーバにRunnerを構築することも可能だと思う。

並列実行とかについてはよくわからない。

GitLab CI Multi Runnerの設定は /etc/gitlab-runner/config.toml にはいってるので、なにか変更したいときは覗いてみよう。

Railsアプリケーション側の設定

構成としては自分が身近に使っている Rails(4.2.4) + mysql (5.6)+ rspec(3.4)という感じでとりあえずテストできるようにするところまでをまとめた。 GitLab CIに関わる設定・実装以外は割愛しています。

正直、mysqlに接続できないところで一番はまってたので、多分これ見てやればハマらないかと。

  1. CI用に config/database.ci.ymlを作成しておく。
default: &default
  adapter: sqlite3
  pool: 5
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

# (確かこの辺はDocker Imageに依存している設定。)
test: &test
  adapter: mysql2
  encoding: utf8
  pool: 5
  username: root
  password: sample_repo
  host: mysql
  port: 3306
  database: sample_repo

production:
  <<: *default
  database: db/production.sqlite3
  1. .gitlab-ci.ymlを以下の内容で作成。
image: ruby:2.2

services: (ここに使用するミドルウェアのDocker Image等を書いていく)
  - mysql:5.6

variables: (ここでDocker ImageのMysql Root Passwordを設定するようなイメージ)
  MYSQL_ROOT_PASSWORD: sample_repo

before_script:
  - cp config/database.ci.yml config/database.yml
  - bundle install --jobs $(nproc) --path=/cache/bundler

test:
  script:
    - bundle exec rake db:setup RAILS_ENV=test
    - bundle exec rspec
  tags:
    - ruby
    - mysql

あとは、コミットして、Pushすればよい。 既に連携されているので、実況状況や結果もすぐに眺めることが出来る。

あとは、カバレッジなんかも計測できる。 これはリポジトリの設定画面かなんかで設定するものだった気がするけど。

commit messageに [ci-skip]って入れとくとCIが走らないようにもなっている。

bundle installのところでおまじないチックなコマンド書いてるけど、これはbundle installの結果をcacheさせるため。 Gemfile.lockが更新されているときはちゃんとアップデートしてくれる。

あとのやりたいことはドキュメント見ればなんとなくわかるので、こちらを参照して欲しい。 GitLab Documentation

herokuのデプロイ例なんかも載っているし、EngineYardでもCapistranoでも問題ないと思う。

Jenkinsと比べた時によいところ

良かったところは、Jenkinsを使ってDockerを使ってクリーンな環境でテストがやりたい時にちょっと面倒だったのが、 これだとパッケージインストールするのと少しの設定だけであっさり出来てしまうこと。

CIとGitLabとの連携も、GithubとCircleCIのそれよりは面倒だけど、Jenkinsより圧倒的にラク。 介護する人は必要かもしれないけど、Jenkinsより管理コストは低い気がする。

総括

正直なところ、おすすめできるかどうかは微妙。 使ってて壊れたり、ハマったりっていうのは今のところ無いけど、壊れない保証はない。0.7.xでまだまだ開発中だし。 僕はこれを結構気に入ってて(選択の余地なくて)、人柱になってますが。

不安定な可能性があることが問題ないと思えて、GitLabを使ってて、CIに凝った設定とかしてなければマジでオススメ。 管理しなきゃいけない項目もそんなに無いし。

知見はそこまで無いけど、Docker知ってる人がいれば大体大丈夫だと思う。 正直なところ、なにかコンテナ関連でハマるとすれば、凝ったテストとかをやりだそうとした時だと思う。

初めてCodeIQをやってみた感想。

前提条件

  • 24歳文系エンジニア
  • Javaの授業の時にJavascriptやってるような、ゴミみたいな専門学校卒。
  • 運用系の仕事をやってたので、2年くらいブランク期間あった。
  • いまは一応仕事でもやっているということにしている。
  • エンジニアに向いてないって言われたこともあるくらいのポンコツ
  • 最近Ruby入門したばっかり。
  • コードが汚いことで定評がある。
  • CodeIQとか、課題を解く感じのWebサービスは知ってたけど、どうせ時間かかるし、解けないし敬遠してた。

ということで、まずはめっちゃ簡単そうなのからはじめてみた。

挑戦した問題

https://codeiq.jp/q/2495

やってみた感想

  • とりあえず、解くことができた。けど、時間は確実に20分くらいはかかっていた。（未計測）
  • 自動採点では正解してたけど、もしかすると不正解な可能性ある。
  • やっぱりポンコツエンジニアなので、Specやtestファイルを事前に準備してあると、今後回答していくうえで時間短縮できると思うけど、チートなんじゃね？
  • Rubyのメソッドでやりたいことがわからなくて、ググってしまってつらい。
  • これを2分位で解くことが出来るスーパーウェッブエンジニアになりたい。
  • 週に1回くらい、気分転換を兼ねてこういう問題を積極的に解いていきたい。
  • でも、できそう、できないで取捨選択しがちなので、自動でこれやれーってアラートしてくれる方が、エンジニア的には嬉しいのかなぁと思ったり。
  • 現実的な問題として避けてきてた部分だったけど、これを続けることで自分の良くないところがはっきりすると思うので、辛くなっても歯をくいしばって頑張ってみる。