2017/05/06の日記
築地に行った
GWっぽいことをあんまりしていない気がして、今日は早起きして築地に行ってきた。 色々食べ歩きしてたけど、朝の9時過ぎには観光客で賑わって来たので早々に退散。 ゆっくり色々食べ歩きしたい人は7時 - 8時くらいに行くのがいいかも。
日枝神社・ビックカメラで時間つぶし
その後、ジャパニーズテクニウム展に行きたかったので、13時から開始だったのでそれまでの時間どうするかー と悩んでいたので、赤坂見附にある日枝神社に行ってみたけど、なかなか良かった。 一眼レフカメラを持っていないので、少しだけ欲しくなった。
たまたま見つけたビックカメラで前から考えていた音声通信付きの格安SIMをシュッと作成。 元々SMS送信できる番号が無かったのでこれでPagerdutyなどでSMSを送る体制が整った。
ジャパニーズテクニウム展に行った
その後にヤフー株式会社に行って、 もう一つの本命であるジャパニーズテクニウム展をみてきた。
無料だったのでそこまで期待してなくて、20分くらいの小さい展覧会みたいなのかなーって思ったけど、もっと大げさな感じで1時間くらいいてた。
色々あって面白かったけど、作品の性質上仕方ないが、 お金を積んででも実際に作品の体験をしてみたいという気持ちがあった。
それにしても落合陽一さんはまだ洗練の余地がありそうな作品も幾ばくかあるとはいえ、 結構な数の作品が置いてあって、作品発表のスピードがすごいなぁと思った。今まで作ってきた物からすればそれも一部なのかもしれないけど。
代表者の身分証明書があれば無料で入れるので、機会があれば行って良いと思う。
僕はまた行くかもしれない。
お出かけしたあとは、Playground · TypeScriptでTypeScriptの入門をしてみて、プロダクトに導入するべきかどうかを検討しているところ。 随分昔に書いたjQueryでDOM操作なトレードオフスライダーの実装を試しにTypeScriptで書いてみようと思う。
フロントエンドフレームワークとかそのあたりの雑な話について
フロントエンドの進化が早いとか、フレームワークとかライブラリの入れ替わり云々の話が再燃している感じがあるので、雑に書いておくと…
単純にそれを学ばないのはもったいないし、フロントエンドを触る機会があるなら考え方は知っておくべき
という一言に尽きる。
そりゃ昔ほど簡単ではなくなったのは当然だけど、 それはSPAを始めとした、複雑なUIに対応するための答えというか方法の1つであって、 フロントエンドフレームワークを最初から学習コストが理由で毛嫌いして知ろうとしないのって、 サーバーサイド側で簡単に例えると、 数百万件データが有るようなDBの全文検索を早くする方法として、 ElasticSearchとかApache Solrなどの全文検索エンジンの類いが導入されていない場合は検討する思うけど、 それを使わないでDBのチューニングやアプリケーションサーバーの工夫で頑張ってなんとか気合で… みたいな話と基本的には同じ*1と思っている。
ReactやVueの考え方を知った上で使うかどうかは規模の大・小だったり、会社の要件に合わせて取捨選択すればいいだけで、 フロントエンドを触る機会のあるエンジニアは学習コストとかぼやいている暇があればさっさとチュートリアルでもなんでもいいので、毛嫌いせずに手を動かしてみるべきである。
少なくとも僕みたいなフロントエンドを少しかじったような雑魚エンジニアでもjQueryだけで頑張るよりも簡単にインタラクティブなUIを実現できる手段を手に入れて、実装の幅が広がったので、皆さんの心配しておられる学習コスト*2も簡単にペイできると思います。
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の用途には厳しそう。
2016年の振り返り 2017年の目標
2016年良かったこと探し
業務的なおはなし。
2016年は、リリースしたサービスの改善・機能追加に費やした1年だった。
このあたりはブログでも色々話したいけど、サービスのサイト公開準備中なので、公開してからやっていた仕事をアウトプットできればと思っています。
早く作ったものの話ししたい><(知り合いの方はどしどし聞いてね!)
とりあえず言えるのはヨソよりも、Rails Engineを積極的に利用しているサービス(ツール)です。
水面下ではありますが、色々なサイト様で利用いただいております。 2017年からは、5倍プッシュくらいで導入されそうな感じになりそうなので、エンジニアリソース大丈夫だっけ?という感じになりそうです。
まぁ嬉しい悲鳴ですね。
ほかには、転職はしてないけど色々縁があり、勤務地が高井戸から渋谷になった。というところがキモですかね。 3年ぶりの出勤体験なので、なかなか新鮮で楽しんでおります。
2016年よくなかったこと
- 2016年に立てた目標に関してはほとんど達成できてなかった。
- アルゴリズムや中学・高校数学ちゃんとやろうとか。
- 詳しくはこちら webuilder240.hatenablog.com
- 下手にSPAに手を出したせいで、あとで苦労したりするところが色々出てきた。
- 普通にWebアプリを実装するのにはとても便利であることはわかったけど、たまたま用途が合わなかっただけという話。
- 2016年後半の進捗が個人的には良くないと感じてて、業務的な成果が少ないんじゃないのかな…と危機感を感じることがあった。
- 60kg -> 67kgに体重が増量した。
2017年の目標
昨年は目標を立てすぎててほとんど達成できてなかったのですが、願望ということで色々書き出しておきます。 毎月振り返りや年間スケジュールとかあったほうがいいですね。
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
tiny_tds
- 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されてない。(未検証)
おすすめの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を使おう。