良いあそなすちゃん

良い方のあそなすちゃんです！

ほげという技術を使いたい

ほげという技術を使うことで事業に対してや日常の開発の効率に関してどれぐらいのインパクトがあるのかを客観的、または多面的に判断しようと思う。

ほげという技術を採用して、例えば、コーナーケースの考慮不足でサービスが落ちる、またはOSレベルの依存で開発環境の構築に失敗するとかとか。そういうの起きないためにも例えば1ヶ月という期間を区切って「いろいろやってみる。ダメだったら諦めるわ」みたいな判断が下せるような余裕は常に持ちたい。

新しい技術の採用に関しては技術研究という名をつけてあげるといいなと思った。未成熟な技術であるほどより深く研究し、今抱えている問題がそれでうまく解決できるのかまたは違うのかを客観的に判断できるようになりたい。客観的なデータだけでは不足刷る場合には多面的に見る。特定の技術にスポットしたくないので例えがふわふわするけど、ほげという技術を採用したために、早い遅いだけじゃなくて、甘い辛いとか、大きい小さいとか、赤い青いとか。

事業やプロダクトが抱える問題を解決するための技術であることを忘れないようにするのと同時に、開発者自身も事業やプロダクトへのコミットの仕方も自由であるべきなのはよしとして、チームに存在しない技術を採用することで、技術的格差が必然的に生まれてくるので、ほげという技術またはその界隈の文化に詳しい人達がそうでない人たちへのキャッチアップなども忘れずにやるのも重要な点のひとつだなと感じる。

採用目的 ラップ まとめ

  素晴らしい音楽たち

 経緯とか

 

 

 

 

 

 

 

 

 

 

 

 

 

 まとめ

サイラマノラッパー久しぶりにみたくなってきた。

やっていきましょう

2週間ぐらい前から連続でやっていきましょう状態になっていて、休息が必要。とりあえず、今日の19時からオデッセイ（火星の人）を見ることにした。この体調で3Dだと酔って吐きそうな気がしたから2Dにした。

最近買ったテレビが3D対応なので、メガネと対応ソフトを買えばPS4で再生できる。コンテンツを家でやっていきましょう。

世紀末付箋タスク管理術 2016

f:id:asonas:20160303161152j:plain

図の通りですが、最近の付箋管理が iMac のアゴ部分だけでは管理できなくなってきたので上の方まではみ出てきた様子です。毎年3月は異様に忙しい。サツバツ！！

 

図の中の画面は弊社が新しくローンチしたSTEERS（ステアーズ）です。

STEERSローンチおめでとうございます。個人的に下記の激ヤバそうなTシャツを応援しています。心理で相場を動かしていきましょう。

steers.jp

コードネーム U.N.C.L.E を見た

仕事で精神が摩耗しきっていてヤバイ感じしたので、隣の席の人が絶賛してた コードネーム U.N.C.L.E をiTSで買って今朝方見てた。

 

f:id:asonas:20160220174336p:plain

ネタバレしない程度に感想とか思ったこととして、アクションシーンなど細々したところで古い撮影手法が使われていて（イリヤがバイクで疾走する場面とかかなりゾクゾクした）どことなく昔の映画を見ている感じがあった。

台詞とか演技とかはガイ・リッチーぽい感じでシャーロック・ホームズ好きな人は多分好きだと思う。特に英語に関しては、ドイツ人の英語、ロシア人の英語語のイントネーションの差をちゃんと演じ分けていてよかった、演者各位凄い。また吹き替えだとこういうイントネーションの差が楽しめないのが残念なのと、吹き替えは吹き替えでいいところがあるので、各社両方バンドルしたデータを配信してくれることを祈ってる。

お話もよくまとまっていて、細かい伏線を回収しつつ最後のシーンでもグッときた。

それにしてもガイ・リッチーはこういうおっさん二人が活躍する作品、最近良く作ってる気がする。個人的にはSnatchのような群像劇が好きなんだがなー。

最近の仕事で得た経験談

重複するデータの直し方

 何かしらの事件によって同一データが重複して登録されてしまっていて誰も気が付かず数ヶ月の間そのまま運用されているアプリケーションがあって、見た目は問題ないんだけど、データを正規化をするタイミングでマイグレートする必要があるときの話です。

また、レコードの重複が発覚するのは、何ヶ月もの先のことが多く、重複する片方のデータだけを修正して、月末処理なんかをしたときに修正されていない方の重複データを使っているデータのほうが壊れる、などしてやっと発覚するので早い段階で気がつけるようにそもそも重複データが入ってはまずいテーブルには適切な制約をはるのがいいでしょう。

以下解決するときにやったこととか考えたこと。

まずはその不整合なデータがどの範囲まで影響しているのかを確かめる。

データベースのスキーマ などをgrepして特定のキーがどのテーブルにあるかを見る。その時にそのテーブル（データモデル）が、あるイベントを機に削除されるなども考慮する必要がある。データモデルがステートメントを持っている場合もあるので、安易にデータを書き換えるのは危険なので、きちんと仕様を確認してから修正をするのが望ましい。

データの不整合の影響範囲を特定できたら、その次に正しいデータを再定義する。その場合も方法はいくつかあり、重複したデータが複数入っている（例えば同一商品が別のidで複数入っているなど）の場合には一つの商品だけ残し、影響範囲のテーブルに対してUPDATEをかける。その後重複したデータは消して、外部キー制約や商品が持つ一意のコード（例えばJANコードとか）でユニーク制約をはり、再発防止に努めましょう。

より厄介だと、例えば外部の値（GPSの座標など）を計算をした結果を距離にしてカラムに格納している場合などはこれはSQLだけでは処理するのが難しいので別の方法で対処することになります。

例えばRuby on Railsをつかっている場合には rails runner などでバッチ処理するなどでActiveRecord そのまま使えたり、座標計算のロジックが詰まっているクラスを再利用することができるので楽ができるでしょう。

新しい仕組みへマイグレートさせる

例えば、アプリケーションの振る舞いが大きくかわり、データモデルも新しいものに書き換える場合に感じ取れたこと。

まず、マイグレートするときにサービスのメンテナンスの時間を取れるのであれば、メンテナンス画面を出している間にデータをマイグレートすればいいでしょう。

逆にメンテナンス画面を出さない場合はいくつかの工夫が必要で 先にマイグレートする処理だけを書いて本番に出します。そのあと、バッチ処理でマイグレートします。そのあと、古いデータモデルの after_createやafter_updateなどをhookしてデータの変更があれば常に新しい仕組みにマイグレートさせるようにします。

この方法だと、余計にINSERTやUPDATEのつどSQLが余計に流れるのでサービスのパフォーマンスなどと一緒に考えてやる必要があります。

小技として、こういうマイグレート系の処理を書くときに息の長いサービスだと、壊れたデータが何年も眠っていたりします。しかし開発時に全てのデータを毎回バッチ処理しているとスクリプトの実装に時間がかかるので、例えば、開発環境では月ごとに100件無作為に取得してそれに対してバッチ処理を走らせるなど、対象のレコードを絞りトライできる回数を増やすことで前進感が演出されます。当然ですが、最後にすべてのレコードに対してバッチ処理をかける必要があるので忘れないようにしましょう。

まとめ 

上で紹介したものでもコーナーケースを見落とすことが沢山あるので、一概には言えませんが、渡ろうとする石橋を何度も爆破しつつ何重にも検証コードを書くのが重要です。

そもそもこういう事態にならないためにも、データベースの制約はきちんとはりましょう。

Webサービスを爆速でつくり始める

日常的に素振りをしなくては〜となって今はGoogle BigQueryやRedshiftとかngx_mrubyで動的画像変換とかお試しで遊んでたりするんだけど、なにぶんビッグデータとか高速な動的画像変換が必要なほどトラフィックのあるアプリケーションを運用していなくてイマイチピンと来なくてモヤモヤしてたのもあって、爆速でWebサービスをつくり始められるようにいろいろとせっせと準備し始めている

元々 id:naoto5959 さんがやっていたことを真似ているんだけど、パブリックなリポジトリで  asonas/rails5base というのをメンテしている（一応rails4baseもあるけど、それほどがんばってメンテはしていない）

github.com

今現在だとRailsのバージョンは 5.0.0.beta2 なんだけど deppbot を使って毎日自動でbundle update してもらってるからとにかく最新のRailsの状態を保てるようになっているのがポイントのひとつ。

www.deppbot.com

その次に、このリポジトリには僕が普段から使っているBootstrapやSlim、RSpec、Fabricationなどの gem や scaffold をしてもhelperやview specを生成しないなどの細かい generator の設定をしている。

こういう設定をいておくことで、 rails new application_name とするよりも git clone git@github.com:asonas/rails5base application_name したほうが、僕にとってのいつものRailsの環境がすぐ出来上がる。

実際に rails5base を使って、家で使うアプリケーションの開発をしていたりするんだけど、beta版というのもありながら結構頻繁に地雷を踏むのでIssuesを見に行ったりする機会が増えたりして、以前よりも新しい情報に触れることが増えた。

仕事とかで簡単なスクリプトを書いたり、既存のアプリケーションを変更することは結構頻繁になんだけど、さて新たなアプリケーションを、となると結構腰が重たくなるので日常的にやっておくことで、いざWebアプリケーションが必要になった段階で素早く価値ある最初のコミットにたどり着けるようにしておきたい。