2017-05-06

フロントエンドフレームワークとかそのあたりの雑な話について

フロントエンドの進化が早いとか、フレームワークとかライブラリの入れ替わり云々の話が再燃している感じがあるので、雑に書いておくと…

単純にそれを学ばないのはもったいないし、フロントエンドを触る機会があるなら考え方は知っておくべき

という一言に尽きる。

そりゃ昔ほど簡単ではなくなったのは当然だけど、それはSPAを始めとした、複雑なUIに対応するための答えというか方法の1つであって、フロントエンドフレームワークを最初から学習コストが理由で毛嫌いして知ろうとしないのって、サーバーサイド側で簡単に例えると、数百万件データが有るようなDBの全文検索を早くする方法として、 ElasticSearchとかApache Solrなどの全文検索エンジンの類いが導入されていない場合は検討する思うけど、それを使わないでDBのチューニングやアプリケーションサーバーの工夫で頑張ってなんとか気合で… みたいな話と基本的には同じ*1と思っている。

ReactやVueの考え方を知った上で使うかどうかは規模の大・小だったり、会社の要件に合わせて取捨選択すればいいだけで、フロントエンドを触る機会のあるエンジニアは学習コストとかぼやいている暇があればさっさとチュートリアルでもなんでもいいので、毛嫌いせずに手を動かしてみるべきである。

少なくとも僕みたいなフロントエンドを少しかじったような雑魚エンジニアでもjQueryだけで頑張るよりも簡単にインタラクティブなUIを実現できる手段を手に入れて、実装の幅が広がったので、皆さんの心配しておられる学習コスト*2も簡単にペイできると思います。

*1:全文検索エンジンなしで全文検索を早くするのは厳しいけど、SPAはノンフレームワークなjQueryでもなんとかなるでしょ？って思っているサーバーサイドエンジニアは実際に手を動かしてから反論して欲しい

*2:付随するライブラリが多く、学習コストが高いという意見があるかと思いますが、Railsでも依存しているGemは結構あるし、非同期処理を行うためのGemはたくさんあると思います。

2017-05-05

2017/05/05の日記

とにかくAzure Functionsについて考えてた1日だった。

Azure Functionsでサーバーレスなメール送信ワーカーシステム

今日はAzureFunctionsでSendGridを利用したメール送信をAzure QueueStorage経由で実行することでメール送信用のWorkerを増やさなくても、サーバーを節約した状態で、メール送信を一斉に行える仕組みを作れるのではないか？と思って色々試行錯誤してた。 AWSだと、SQS (Queue Storage) -> Lambda(Azure Functions) -> SES (SendGrid) という流れで同じことができるのだろうけど、宗教上の理由からAzureで利用している。

Azureの場合は、OutPutにSendGridを選択できるのでSendGrid経由でメールを送信する処理を書く場合はこっちのほうがラクっぽい。まだ未完成だけど、節約しつつメール送信数が数千、数万*1のレベルでもシュッと格安に送信できそうなので、引き続きすすめてみる。多分SendGridの設定がうまくいっていないだけで、Azure Functions自体のコードは数行で完了すると思う。

Azure FunctionsとStorage Fileの連携について

また、Azure FunctionsでStorage Fileにファイルの追加・更新があった場合にバックアップデータを取るような処理を書いてみたかったのだけど、 Azure FunctionsではBlob File（S3相当のサービス）の追加はトリガーにはできるけど、Storage Fileは出来ないそうだ…残念… サポートがされることがあれば便利機能が簡単にできそうだったのだけど…

Azure FunctionsでWebhookを処理する

これが1番簡単で現実的かなーまずはSendgridの送信エラーだけSlackに通知したりとかシュッとできそう。ただし、AzureFunctionsの場合は起動が遅いらしいので決済webhookの用途には厳しそう。

*1:むしろそのレベルになるとQueue Storageにキューを積む処理のほうがボトルネックになりそう。

2017-01-04

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

2016年良かったこと探し

業務的なおはなし。

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

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

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

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

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

まぁ嬉しい悲鳴ですね。

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

2016年よくなかったこと

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

2017年の目標

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

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

2016-12-07

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や日本語の文字化けの問題は？？

http://qiita.com/iijijii/items/783b95f2d981554be91e
- nvarchar型で保存してればOKらしい。
- https://msdn.microsoft.com/ja-jp/library/ms176089.aspx#解説
- RailsのMigrationでstring型とtext型はnvarchar型でカラムが作られるので、あまり意識することはないかも。
- 照合順序はJapanese_XJIS_100_CI_AS_SCにしなくても環境依存文字は化けないような気もするけど、もう少し調べる必要がありそう。
Nプレフィックスについて
- https://support.microsoft.com/ja-jp/kb/239530
- 但しこれはactive_record_adapterでは考慮済みなので、生SQLを書くときとかに気をつければ良い。
そもそもこういったWhere句は良くない気もするが、Nプレフィックスがつかずにエラーになるので気をつけること。

  # これは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されてない。（未検証）

雑な感想

やる前はぶっちゃけ悲観的な感じだったけど、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に詳しくないので、詳しい方々のマサカリをお待ちしております。

2016-10-10

日本からの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も作るのかな…？という感じです。

Webuilder240's Blog