2017/05/06の日記

築地に行った

GWっぽいことをあんまりしていない気がして、今日は早起きして築地に行ってきた。 色々食べ歩きしてたけど、朝の9時過ぎには観光客で賑わって来たので早々に退散。 ゆっくり色々食べ歩きしたい人は7時 - 8時くらいに行くのがいいかも。 f:id:oh240:20170506191343j:plain f:id:oh240:20170506191349j:plain

日枝神社ビックカメラで時間つぶし

その後、ジャパニーズテクニウム展に行きたかったので、13時から開始だったのでそれまでの時間どうするかー と悩んでいたので、赤坂見附にある日枝神社に行ってみたけど、なかなか良かった。 一眼レフカメラを持っていないので、少しだけ欲しくなった。f:id:oh240:20170506191435j:plain

たまたま見つけたビックカメラで前から考えていた音声通信付きの格安SIMをシュッと作成。 元々SMS送信できる番号が無かったのでこれでPagerdutyなどでSMSを送る体制が整った。

ジャパニーズテクニウム展に行った

その後にヤフー株式会社に行って、 もう一つの本命であるジャパニーズテクニウム展をみてきた。f:id:oh240:20170506191447j:plainf:id:oh240:20170506191452j:plain

無料だったのでそこまで期待してなくて、20分くらいの小さい展覧会みたいなのかなーって思ったけど、もっと大げさな感じで1時間くらいいてた。

色々あって面白かったけど、作品の性質上仕方ないが、 お金を積んででも実際に作品の体験をしてみたいという気持ちがあった。

それにしても落合陽一さんはまだ洗練の余地がありそうな作品も幾ばくかあるとはいえ、 結構な数の作品が置いてあって、作品発表のスピードがすごいなぁと思った。今まで作ってきた物からすればそれも一部なのかもしれないけど。

代表者の身分証明書があれば無料で入れるので、機会があれば行って良いと思う。

僕はまた行くかもしれない。

お出かけしたあとは、Playground · TypeScriptでTypeScriptの入門をしてみて、プロダクトに導入するべきかどうかを検討しているところ。 随分昔に書いたjQueryでDOM操作なトレードオフスライダーの実装を試しにTypeScriptで書いてみようと思う。

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

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

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

という一言に尽きる。

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

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

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

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

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

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にキューを積む処理のほうがボトルネックになりそう。

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 航海日誌:とりあえず動かしてみた

今は仕事で、今まで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データ移行できるかどうか
  • MySQLSQLServerユニークインデックスの仕様に違いがあったのでそのへんの対処法を書く(参考にしたQiitaの記事のURLがどっかいったのであとで探す…)
  • これだとつらそうとかいう感想もありそうでアレなので、そのうち採用するメリットについてしっかり書いておきたい。

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