2016年の振り返り 2017年の目標

2016年良かったこと探し

業務的なおはなし。

2016年は、リリースしたサービスの改善・機能追加に費やした1年だった。

このあたりはブログでも色々話したいけど、サービスのサイト公開準備中なので、公開してからやっていた仕事をアウトプットできればと思っています。

早く作ったものの話ししたい＞＜（知り合いの方はどしどし聞いてね！）

とりあえず言えるのはヨソよりも、Rails Engineを積極的に利用しているサービス（ツール）です。

水面下ではありますが、色々なサイト様で利用いただいております。 2017年からは、5倍プッシュくらいで導入されそうな感じになりそうなので、エンジニアリソース大丈夫だっけ？という感じになりそうです。

まぁ嬉しい悲鳴ですね。

ほかには、転職はしてないけど色々縁があり、勤務地が高井戸から渋谷になった。というところがキモですかね。 3年ぶりの出勤体験なので、なかなか新鮮で楽しんでおります。

2016年よくなかったこと

  • 2016年に立てた目標に関してはほとんど達成できてなかった。
  • 下手にSPAに手を出したせいで、あとで苦労したりするところが色々出てきた。
    • 普通にWebアプリを実装するのにはとても便利であることはわかったけど、たまたま用途が合わなかっただけという話。
  • 2016年後半の進捗が個人的には良くないと感じてて、業務的な成果が少ないんじゃないのかな…と危機感を感じることがあった。
  • 60kg -> 67kgに体重が増量した。

2017年の目標

昨年は目標を立てすぎててほとんど達成できてなかったのですが、願望ということで色々書き出しておきます。 毎月振り返りや年間スケジュールとかあったほうがいいですね。

  • 業務でいよいよ高トラフィックサイトでの用途が検討されており、こちらへの対応をできるようにする。
  • いい意味でも悪い意味でも自分に自信がないので、定期的に自分の仕事を振り返って自信をつけたい。
  • 60kg -> 67kgに体重が増量したので59kgに痩せたい。
  • 大きな成果の方ばかりに注力して、サービスの小さな改善が進まなかったので小さな改善を進めれるような意識改革
  • アルゴリズムや中学・高校数学ちゃんとやる。
    • 低スキルだってディスられない程度には基礎スキルを持っておきたい。
  • LTに登壇してみる。
    • Rails Engine / Azure / Rails + SQLServer というなかなかニッチネタならできそう。
    • もっと素晴らしいスキルをお持ちのエンジニアに上記項目について発表・ブログを書いて欲しいというマクドナルド理論のような願望があるからです。
  • 2月から新婚さんなので、うまくやっていく。

Rails + SQLServer 航海日誌：とりあえず動かしてみた

Ruby

今は仕事で、今までRails + MySQLで稼働しているアプリケーションのデータベースをSQLServerに移行している。

進捗状況としては開発環境上では「ひとまずちゃんと動いているように見える」ということで、 まだProductionで運用しないが、大丈夫そうな気もしている。

どこまで需要があるかも分からないが、 日本語での知見もほとんど見当たらないのでとりあえず書き残しておく。

前提条件

開発環境

  • 普段のPCはMac
  • Ruby 2.2.x or 2.3.x
  • Rails 4.2.x
  • MySQL 5.6.xから移行する事になっている
  • 普通の小規模Railsアプリケーション
  • 移行先はAzureのSQLServerの予定

ちなみに生のSQLも1つしか書いて無いと思うし、 Arelもほとんど使わずに済むくらいには難しいことはしてない。 プロダクトも現状は大規模な案件では動いてない。

自分のスキルについて

  • Rails 2年目くらい
  • SQL Serverは未経験
  • そこまでSQLに詳しくない・難しいSQL書けないし、書きたくない。

SQLServerへの対応に当たって使用したGem

active_record_adapter

github.com

tiny_tds

github.com

  • tiny_tdsを使えるようにするには別途freetdsをインストールする必要がある。

雑なQ&A

ActiveRecordのAdapterあるけど、まともにつかえるの？？

  • starもとりあえず700超えているし、過信は禁物かもだが、まともに動いてる感ある。
  • ただし、ActiveRecordのwhereで文字列を検索するときにエスケープを意識しなければいけないシーンが他のDBシステムよりは増える。（これはActiveRecordの問題ではないが…）
  • AzureのSQLServerを使用する場合は、database.ymlに azure: trueって設定しとくくらい。

Macでしょ、開発用DBとかどうした？？

  • AzureでBasicのDB立ててそこでやってる。 月に500円で安心を手に入れられるならそっちのほうがいいと思ってる。 開発環境がMacだし、Windowsでやるにしても、構築めんどくさくないこっちの方をおすすめしたい。 どうしてもオフライン環境下でも開発したい人はローカルにDB構築すればいいと思う。

  • そこまでちゃんとSpec書いているわけではないけど、 Specで使うためのテストDBもAzure使ってやっているのだけど、なんだかテストが遅くて困ってる。 ネットワークの問題なのか、DBのサイズの問題なのかまだ切り分けできてない。 こういうときにSQLServer on Linuxはいいかもしれない。

SQLServer on Linux/Macはどう？？

  • まだ試してない。枯れた技術になりそうだったら、テストで使う可能性はあるかも。

UTF-8や日本語の文字化けの問題は？？

  # これはNプレフィックスがないまま実行されるので、失敗する
  Subscription.where('status = "success"')

  # これらは実行されるSQLにちゃんとNプレフィックスがつくので動く
  Subscription.where(status: "success")
  Subscription.where("status = N'success'")
  • こういう部分はアプリケーションのコードだけではなく、ActiveRecordを扱ってるGemがある場合は、逐一チェックしたほうがいいかも。

Rails 5は？？

  • Masterブランチでは動かない。（2016/12/02時点）
  • rails5というブランチがあり、そちらでは動くらしいが、まだMasterにMergeされてない。（未検証）

おすすめのSQL GUIクライアントアプリ for Mac

とりあえずRubyMine使っている。 自分はよく訓練されたSQL使いではないので、GUIクライアントはあったほうが良かった。 今までMySQLを使っていたので、同じGUIクライアントで使えたのは本当に大きい。 ただ若干参照できない部分があったりするので、 細かいことをしようとし始めると融通がきかない部分があったりするかも。 他のGUIクライアントはものすごく高いか、画面が残念のどちらかだと思っている。 とりあえずJetBrain製品使いましょう。

雑な感想

  • やる前はぶっちゃけ悲観的な感じだったけど、ActivreRecordのAdapterから実装するという最悪の状況は免れそう。（まだドハマりしてないだけかも…）
  • というかAdapterがいい感じに動いている。
  • Migrationも少し書き直しはあると思うけど(bigintとかその辺)、まぁだいたい大丈夫そう。
  • 生SQLたくさん書いてそうな大規模な案件では大変そうな感はある。
  • とはいえMySQLにはないSQLServer独特のものとかもあるので、SQLServerについての勉強はもっと必要になる。
  • Rails + SQLServerでの開発もメリットがある場合は選択肢のひとつになると思う。
  • AzureのSQLServerの場合、無停止でインスタンスサイズを変更できるのはメリットだと思う。

現時点で気をつけるポイントまとめ

  • どんなに簡単なwhere文でもテストを書いておいたほうが安心できる。
  • ちゃんと普段から本番環境と同じDBシステムを使うべき。
  • 手でNプレフィックスつけるのは面倒だし、うまくActiveRecordを使おう。

TODO

  • これまでは新規で動かしてみた結果なので、ちゃんとMySQL => SQLServerデータ移行できるかどうか
  • MySQLとSQLServerでユニークインデックスの仕様に違いがあったのでそのへんの対処法を書く（参考にしたQiitaの記事のURLがどっかいったのであとで探す…）
  • これだとつらそうとかいう感想もありそうでアレなので、そのうち採用するメリットについてしっかり書いておきたい。

そこまでSQLServerとRailsに詳しくないので、詳しい方々のマサカリをお待ちしております。

日本からの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でちゃんと出来るかどうか心配。色々思い出さないと。
  • あくまで趣味プロジェクトなので期待しないでください。