ツバから採取したDNAから病気の発症リスクなどを教えてくれるMYCODEを(会社の経費で)使ってみました。

MYCODE(マイコード) | これから先の健康のために自宅でできる遺伝子検査を

日本人平均と比べてかかりやすい病気とその対策を教えてくれます。

僕が申し込んだのはオールインワン280+ってやつです。280項目と言われてもそんなに見きれませんが。

Webサイトから購入するとこういう昔のAdobeのパッケージみたいなので検査キットが届きます。

DNAを採取するのにツバってのは確かに便利かもなあという感じ。

「唾液を出しやすくするために、ご覧ください。」

と、こういうカードが入ってるのが面白い。

郵送で送り返してからWebサイトで結果が見れるようになるまで二週間ぐらいかかった気がします。

その間に体や生活習慣に関するアンケートが大量にあって、その回答も結果に影響してくるようです。

こういう非IT系のITサービス(?)のWebサイトはクッソ使い辛いのが常ですが、大量のアンケートもサクサク答えられるような使いやすいUIになってるのはさすがDeNAという感じ。

検査結果

検査結果が出たとのメールが来てアクセスしてみると個人情報についての注意書きが。

DNAは親兄弟・子供の情報も含むことになるので個人情報を超えた一族情報とでも言うべきものなのでクッソ注意しろとのこと。自己責任どころじゃ済まない情報の扱いにちとビビる。

日本人平均と比べて一番なりやすいのが円形脱毛症だってさ!

注視したいのは日本人平均に比べてかかりやすい病気と予防法。僕の場合は極端に倍率の高い深刻な病気はなかったので一安心ですが、他の人の見せてもらったら全然違ったので寿命に関わる場合もあるんじゃないでしょうか。

感想としては、僕の場合、アンケート結果が「うつ病」って感じなので、アドバイスが「時々ハイキングに行け」とかなのはDNAっぽくなくて残念。

また、現時点で予防法が無いものが多いので「って言われてもな・・・」となることが多い点。

あとは、日本人平均1倍だとしてももっと注意すべき危険な病気(いろんな癌とか)がたくさんあるので、そっちが知りたいなとかです。

サービスへの感想

郵送されてきたものにツバ入れて返すだけなので苦痛とかゼロですし人間ドックや健康診断と違って会社を半休したりしなくて済むのが働いてる人的には嬉しいです。

統計とったらちゃんと病気にかかる確率が減ってるんじゃないでしょうか。それで病気が減るなら検査にかかるサービス提供側の手間も少なそうだし、保険が効けば更にみんな使って国の医療費も減るんじゃないの?やっちゃいなよ!って感じでした。

医者の代わりにはならないですが、とにかく手間が無いのがありがたいです。こういう試みはどんどん進んでいって欲しいです。

sass-railsの5.0から、foo.css.sassfoo.sassに変えよというWARNINGが出るようになってました。(エラーが出たらとりあえずGoogle検索欄に放り込む人=俺用のエントリータイトル)
DEPRECATION WARNING: Extra .css in SASS file is unnecessary. Rename /Users/komagata/code/kowabana/app/assets/stylesheets/blocks/footer/_footer-pages-nav.css.sass to /Users/komagata/code/kowabana/app/assets/stylesheets/blocks/footer/_footer-pages-nav.sass
...
...
...

デザイナーの作業とコンフリクトする予感!

% ls app/assets/stylesheets/**/*.css.sass | wc -l
     107

すげーたくさんあってやんなりますよぉ~

% zmv app/assets/stylesheets/**/*.css.sass app/assets/stylesheets/**/*.sass
% zmv app/assets/stylesheets/*.css.sass app/assets/stylesheets/*.sass
% git add 'app/assets/stylesheets/**/*.sass'
% git add 'app/assets/stylesheets/*.sass'
% git rm 'app/assets/stylesheets/**/*.css.sass'
% git rm 'app/assets/stylesheets/*.css.sass'

zmv使うとちょっと楽。

参照:zsh の zmv を使って簡単に複数ファイルを一括リネームする - mollifier delta blog

こちらの記事の解決編です。

ActiveRecord::RecordNotFoundのエラーは放置すべきか? - komagata

@hiroshi3110さんからズバリな答えをいただきました。

怖話で実装

# lib/record_not_found_by_trustless_param.rb:
class RecordNotFoundByTrustlessParam < StandardError; end
# app/controllers/comics_controller.rb:
class ComicsController < ApplicationController
  before_action :set_comic, only: :show
  
  def show
  end

  private
  def set_comic
    unless @comic = Comic.find_by(id: params[:id])
      raise RecordNotFoundByTrustlessParam                                                                                                                                                                  
    end
  end
end
# app/controllers/application_controller.rb:
class ApplicationController < ActionController::Base
  rescue_from RecordNotFoundByTrustlessParam, with: :not_found
  
  private
  def not_found
    render file: "#{Rails.root}/public/404.html", layout: false, status: 404
  end
end

@hiroshi3110さんの言うとおり、信頼出来ない外部からのidを元にしたfindで見つからない場合はRecordNotFoundByTrustlessParamにし、rescue_fromで拾って404を出すようにしました。(404を動的テンプレートで出すのは良くないと思うのでpublic以下の静的ファイルを読む)

自分の中のベストプラクティスにしようと思いました。

Rollbarとかのエラー管理サービス使ってるとActiveRecord::RecordNotFound がWARNINGレベルのエラーでたくさん残るので気になる。

idに適当な数字入れれば必ず出るんだから。rollbarの無料プランは月のエラー数に上限があるのでもったいない。

しかし、特定の存在しないidが何度もアクセスされるのは問題の兆候だったりするから完全にmuteするのも気が引ける。皆さんどうしてるんでしょう?

追記:

ActiveRecord::RecordNotFoundエラーを防ぐ - komagata

wootheeを見習って他reposからgit submoduleしやすいように祝日データをrubyからyamlにしました。(organization化と言語非依存にrepos化はちょっとしたholiday_jpのようなライブラリではやり過ぎかなと思ってやってません。submodule使えば祝日データの一元管理という要は足りるしね。)

komagata/holiday_jp

僕がgemを作る時ってすごく画期的なアイデアが見つかったとかあんまりないので、ほとんどが仕事上で必要だけど既存のgemが存在しない=日本語やi18n関係ばっかりになっちゃうんですよね。

昔に使ったので我ながら設計が変ですが、テストが合ったのでテストに変更が無いように実装を変えただけです。あとはテストにshoulda-contextとか今日び使わないのでtest-unit3に変えたぐらい。

最近gem作る時ちょっと便利だなと思うのはgemspecとか自動生成系ファイルをコーディング規約に合わせるために手作業しなくても$ rubocop -aでほとんどいけちゃうところ。

弊社ではGithub IssuesのWrapperであるHuboardをタスク管理に使っているんですが、ちょっと便利な機能が増えました。

それは複数のreposのissueを一つのカンバンに出せる機能です。

何が嬉しいのかというと、弊社サービス怖話で言えばgithubのreposは

  • fjordllc/kowabana
  • fjordllc/kowabana-ios
  • fjordllc/kowabana-android

というようにweb, ios, androidに分かれてるのですが、それぞれ専属の人がいるわけじゃないのでまとめて見れたほうが都合がいいのです。(そもそもwebviewメインなのでios, androidの方はそんなにissueがない)

(Workingにある「怖話1.5をリリース」ってのはkowabana-iosのissue)

ちょいと高価いですがいい感じの代替サービスが見つかるまでは使い続けそうです。

gemとか作る時の普段使いのtestライブラリ(ファッション誌風)をminitestからtest-unit3にしてみた。

kowabana-parser/test_kowabana_parser.rb at master · fjordllc/kowabana-parser

test runnerの読み込みが要らないところがちょっといい。

minitest:

require 'minitest/autorun'
require 'minitest/unit'
require_relative '../lib/time_compact'

class TestTimeCompact < MiniTest::Test
  ...
end

test-unit:

require 'test/unit'
require_relative '../lib/kowabana/parser'

class TestKowabanaParser < Test::Unit::TestCase
  ...
end

power-assertもblock渡せば使える。

EngineYard日本支社クローズにともなって怖話さくらクラウドに移行しました。

sunziでサーバー作ってcapistranoでデプロイしてるんですが、sunziのshell scriptでちょっとわからない点があります。

debianでLANGとかLC_ALLの設定無しでapt-get installとかやると下記のようなお決まりのWARNINGが出まくります。

$ sudo apt-get install foo
...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

僕の中では下記のエントリーで一応対応方法は決着していたんですが、sunziなどを使う場合はreboot無しで反映されないと気持ち悪い。

Setting locale failedを防ぐ - komagata

現状のrecipeは下記で、これはreboot必要なんですよね。みなさんどうやってるんでしょうか?(en_US.UTF-8でもかまわない)

sunzi-recipes/locale-jp.sh at master · fjordllc/sunzi-recipes

if ! grep -Fq "LC_ALL" /etc/environment; then
  sed -i 's/.*ja_JP.UTF-8 UTF-8.*/ja_JP.UTF-8 UTF-8/' /etc/locale.gen
  locale-gen
  cat < /etc/environment
LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8
EOF
  source /etc/environment
fi

怖話を作っていてインフラを含めた設計で迷っている箇所がいくつか溜まってきたのですが、もしいい方法があったら教えて欲しいという点をブログに書いていきたいと思います。

前提

  • エンジニアは僕一人だけなので極力手間を減らしたい
  • 怖話は広告モデルなのでアクセス辺りの収益が低い。なるべく安く(できれば無料に)したい
  • デザイナーやインターンの人も開発するので複雑にしたくない(例えば怖話をローカルで開発する環境を作るのにredisとかfluentdとかいろんなサーバープロセスを立てないと画面が確認できないとか)

画像の置き場所に困る

怖話はアクセス負荷的にappサーバーの2台目が必要かな?ぐらいの状態にあります。

appサーバーが複数台になると画像などのアップロードされるファイルの置き場を共通にする必要が出る。

一度はappサーバー2台でS3 + CloudFrontにしましたが、転送料が高いからappサーバー1台にもどしてまた普通のFile Systemを使うようにした状態です。(無料のCDNのCloudFlareを使ってるので転送量が大分減った)

でも結局rails appのプロセスは結構メモリ食うのでappサーバー増やしたい。なに?転送量無料のS3互換オブジェクトストレージがあるって?じゃあまた画像をfogを使ってアップするように改修を・・・

とここまで来て、「なんでオブジェクトストレージ使わなきゃいけないんだっけ?」となりました。

アクセスとファイル容量が膨大で1台ではアップロードされるファイルを捌き切れない!という用途向けには必要なんだろうけど、怖話でそういったことにはまずならないと思う。(そんなになってたら儲かってるのでこんなみみっちいことで悩まない)

複数サーバーからブロックデバイスとしてマウントできるnfs的なものでかまわないんだけどなあ。S3用になんでプログラム変更しなきゃいけないんだよ面倒くさい。

でもnfsって古い感じするし、トラブル多発なイメージするしちょっとこわいな。

今どきバージョンのnfsみたいなのってないのかな? ← 今ココ

皆さんだったらどうされますか?もし情報をお持ちの方がいたら教えていただけるとありがたいです。

愚痴

  • AWSの転送量高スギィィィ!
  • S3 + RDSに決め打ちしないところに工夫のしがいがあるのでは!
  • 日本からのアクセス速くしようとすると選択肢狭まりスギィィィ!

よく忘れるので。

通ったり通らなかったりするテストはまずseed指定。

$ rake test:all TESTOPTS="--seed 53163"