僕の考えた最強のデッキ 〜オムツ替え編〜

早いもので出産してからそろそろ4ヶ月が経とうしています。
オムツ替えも1日8回換算だとすると千回くらいやっていることに🙄回数こなしてようやく慣れてきました。

「離乳食始まるとうんち臭くなるよ〜それまではそんなに臭くないよ〜」なんて話を聞いていたんですが、まぁ今でもそこそこ臭いですよねww 離乳食始まったらどうなってしまうんだ…😇

今回はオムツ交換で使ってる品々の紹介です。

紙オムツ

これがないと始まりませんね。

パンパースのテープタイプのオムツを使用中です。立てるようになったらパンツタイプに移行するといいらしいですがまだまだ先の話です。
最初は新生児サイズ(〜5kg)を使用し、2ヶ月たったくらいで4kg超えてきつくなってきたので、Sサイズ(4〜8kg)にレベルアップしました。(目安サイズはメーカごとに異なります)

産院で使っていたのがメリーズだったのでしばらくはメリーズを使っていましたが、足が細いせいか足回りからうんちが漏れることが度々ありました。足回りがスリムと噂のパンパースに変更したところ、気持ち改善した気がします。

おしりふき

赤ちゃん本舗のものを使っていましたが、途中からムーニーのものに変更しました。

後述のおしりふき保温器との相性は、赤ちゃん本舗の方が良いです。水分をたっぷり含んでいて乾きにくく、生地もしっかりして厚みがあるため取り出すときも生地が伸びずにすっと取り出せます。
ただ、ムーニーの方だと最後から5枚目だけに青い印がついていて、オムツ替え中に「うそやん!このタイミングでなくなる!?!?」と大慌てで新しいおしりふきを出すという心配がないので、こちらを使うことにしました。ちょっとした気遣い大事。

ビタット

おしりふき用の蓋です。既存のビニールシールの蓋だと片手での開け閉めが大変なので、あると便利です。おうち常設用、外出用、予備用で3つ持っています。

タヌキとキツネのビタットもあります☺️ ロフトのネットストアで買えますよ☺️☺️☺️

f:id:uspcent:20190403214924p:plain

おしりふき保温器

里帰り先の東北の冬の寒さで冷え切ったおしりふきで拭くと、いやがってちょっと暴れたので使ってみました。
たしかにこれで拭くと嫌がらずにおとなしくしてくれました。

ただ、東京に戻ってきてからは比較的温かいせいか、私のオムツ交換スキルが上がって多少のことじゃ動じなくなったせいか、使っていません😇

防臭袋

名前のまんま臭いがもれない袋です。
友人に勧められたBOSというメーカーの袋を使っています。うんち付きのオムツもこれに入れさえすれば匂いが漏れません。

我が家ではオムツ専用のゴミ箱は買わず、これに都度使用済みオムツをいれ、入り口をねじってきゅっと結んでそのまま捨てています。出先でも大抵はオムツ持ち帰りなので、これを持っていっています。

オムツに限らず生ゴミなど匂いが気になるものにはなんにでも使えそうです。

育児、始めました

昨年の2018年12月7日に第一子を出産しました。

産む前は陣痛がどんだけ痛いのか不安だったし、
産んだ直後は子育てできるのか不安だったし、
里帰りから戻るときには家事を回せるのか不安だったし、
節目節目でいろいろ不安はありましたが、
どうにかなるもんですね。

健康体で生まれてきた息子と、 夫や(義)両親、友人、近所の方々など周りの人や環境に恵まれていることに感謝しつつ、 のんびりやっていきます。

2ヶ月過ぎて少し余裕が出てきたので、 育児で使っているアプリをまとめておこうと思います。

みてね

mitene.us

最初はGoogle フォトの共有アルバムにひたすら突っ込んでいたのですが、まー写真が増える増えるww
いまだかつてないペースで写真を取りまくり、整理するのも面倒なくらいに写真が激増したため、みてねに移行しました。

月毎にアルバムを作成し、3ヶ月毎に1秒動画を配信してくれるので、成長の過程をいい感じにつまみぐいして見れるので最高です。

私の親世代はアプリ版を使いこなして少なくとも一日一回は見ているようです。
流石に祖父母世代になるとアプリ版は難しかったのですが、ブラウザ版なら見れているようなのでこのまま様子見してみようと思います。
遠方でなかなか会えないため、写真でも動画でも見れると嬉しいようで助かっています。
(遠方と言いつつ、私の実父は出張のついでと言って3月に2回も会いに来る予定です。。。w)

育児ノート

nighp.com

授乳時間や粉ミルク、おむつ交換など子どものライフログを記録するアプリです。

毎日十数回同じ作業を繰り返すので、いつ何をやったのかわからなくなってきます。
特に夜中の授乳はうつらうつらしてる状態でやるので、夢か現実か区別がつかなくなっていき、アプリで記録を見て「あ、夢じゃなかった」と確認することが度々ありました。
授乳のときはタイマーとしても使えますし、データの共有もできる(まだ使ったことはない)ので夫に子供を任せるときも困りません。

類似のアプリはたくさんあるのですが、このアプリは記録したデータをCSVとして出力できます。
妊娠中にライフログアプリを途中まで作っていたので、もし使える状態になったら移行したいなーなんて淡い期待を持っての選択です😇
出産後はほとんどPCに触れてないので完成はいつになるやら。。。

ママパパマップ

mamamap.jp

授乳室や調乳用のお湯が提供されている場所などを検索できるアプリです。

おむつ交換であれば多目的トイレでもできますが、授乳はその辺でやるわけにはいかないので長時間のお出かけの前には授乳ができる場所を下調べしておく必要があります。
このアプリだと授乳室の有無はもちろん、他のママさんパパさんのクチコミも見れるため、曜日・時間による混雑状況の傾向や「管理人さんに声かければ調乳用のお湯がもらえる」などの細かい情報もわかるので、初めての場所でも安心して出かけることができます。

ママリ

itunes.apple.com

ママさん向けのQ&Aアプリです。

はじめての育児だと疑問に思うこと・戸惑うことがたくさんあるので、日常生活のちょっとしたことを質問するのに便利です。
ベビーベッドと布団とどっちにしようかとか、抱っこ紐はどのメーカーがいいのかとか、寝かしつけどうやってるのかとか、首のすわっていない子供でも連れていける飲食店はないのかとか、日々疑問だらけ。。。。。

子供も親も個性があるので他の人の正解が自分たちにも当てはまるとは限らないのですが、色んな人の意見を聞けるので判断材料の1つとするにはよいアプリだと思います。
あと、返答がめっっっっちゃ早いのもありがたいです。

Kindle

Kindle

Kindle

  • AMZN Mobile LLC
  • ブック
  • 無料
itunes.apple.com

(育児に役立つ。。。というわけではないのですが)
1回20~30分くらいかかる授乳の間は脳みそと片手がとても暇なので、読書がはかどります。

THE AI 2018 2nd に行ってみた

六本木ヒルズの森ビル内にあるアカデミーヒルズにて開催されたTHE AI 2018 2ndに参加しました。
AIというお題目ではあるものの、 データ分析の話がメインだったり、 インタフェースの話がメインだったり、 製品紹介()の話がメインだったり、 講演者により内容は様々でした。

一番の収穫は、サイバーエージェントさんのブースでCS系の課題解決の話をちらっと聞けたことです。
悩みどころは同じ業界だから共感するところもありましたが、アプローチの仕方は会社それぞれのようです。 名刺交換もしたし今度お話を聞いてみたいと思います。

他のブースでももっと話を聞けばよかったなぁと思いつつ、コミュ障なので聞けたのは2, 3ブースだけでした。
ちゃんと人と喋れるようになりたい…。

以下、私が見た講演のうち2講演の感想(+小話)を載せておきます。

基調講演

落合さんの講演。
名前はよく聞いていたけれど、講演を聞くのはこれが初めてでした。

メモはGithubにあげています。
memo/fundamental.md at master · upscent/memo · GitHub

とにかく話の密度が高い。

現状のデバイスを利用できない・しづらい人にどういうソリューションを提供していくかとか、 日本が人口減少・高齢化がより進んでいく中で今後どういう戦略をとっていくべきかとか、 AIという話題に限定しない視野の広い話題が多かったです。

ちなみに、落合さんの一番言いたいことは

世を捨てよ、クマを狩ろう

です。
もともと狩猟民族だし、短期スパンで課題解決できるような何かをやってみよう!ということらしいです。

個人的に気になったのは Ontenna (耳の聞こえない人のための振動デバイス) 。

これを見て、以前耳で聞かない(!?)演奏会をやっていたのを思い出して 行けばよかったーーーーと後悔していたのですが、 好評だったようでなんと8月27日も演奏会があるらしい…!

www.japanphil.or.jp

これは行くしかない。

日本の事業価値を(再)創造するマイクロソフト AI

創業100年以上の老舗「ゑびや大食堂・ゑびや商店」の事例集。

定量的なデータを集計して来客数予測をしたり、来店するお客さんのデータを画像解析で自動集計するようにしたりして、今まで勘でやってきてたところを根拠付けてやっていったというお話でした。

BIツールの使い方にも触れているところがありました。
経営者と現場ではやってるタスクが違うから見たい情報が異なるのは当たり前で、BIツールでもそれぞれの立場から見たい情報がちゃんと見れるようになっているそうです。

カスタマーサポートスタッフ向けの管理ツールを作っている身としては、この辺の話はたしかになと思うところがありました。
to Cの CRE(Custmomer Reliability Engineer) の場合は現場のオペレーションをエンジニアがやるわけではないため管理ツールで出してる情報と現場スタッフの欲しい情報に乖離が発生しやすいのは課題です。
現場が欲しい情報のみを表示するように心がけてはいるものの、定期的にヒアリングするなりして現状のツールが問題ないか & 足りない部分はないかは常にチェックしていかないとなと思ったところでした。

小話

森ビルの前に大量発生していたドラえもん

f:id:uspcent:20180727230652j:plain

夏休みのせいかちびっこも多くて賑やかでした。
六本木には会社の用事があるとき以外ほとんど行ったことがないので、今度遊びに行ってみたいです。

ビットコインのアービトラージを(半)自動で行うアプリを作った

アービトラージで一儲けしようぜ!!」

という夫の誘い文句に乗って、半年前くらいに半自動取引アプリを作りました。

cronで5分毎に市場の状況を確認して、アービトラージの取引チャンスがあったらSlackで通知を飛ばし、取引OKと返答すると注文を入れてくれます。 (Slackのログのスクショがあればもう少し分かりやすかったのですが、無料プランで使っているため古すぎて参照できませんでした。。。)

この記事ではこのアプリの取引の仕組みについて書きます。

雑な実装でつくったわりには、チリツモですが利益を出すことができました。

ただし、ビットコイン自体の価格変動により発生する損得のほうが圧倒的に大きいです😇
下記のようなリスクを許容できる方のみお試しください。

アービトラージとは?

裁定取引/アービトラージ│初めてでもわかりやすい用語集│SMBC日興証券を見ると

裁定取引アービトラージ)とは、同一の価値を持つ商品の一時的な価格差(歪み)が生じた際に、割高なほうを売り、割安なほうを買い、その後、両者の価格差が縮小した時点でそれぞれの反対売買を行うことで利益を獲得しようとする取引のこと。

と書いてあります。

なるほどわかりません。

簡単な例で見てみましょう。
古本屋がA店・B店と2つあったとします。 ある本がA店では100円で売られており、B店では200円で買い取られている場合、その本をAで100円で買って、Bで200円で売れば100円儲けることができます。
これがアービトラージてす。

これと同様のことをビットコインで行います。

アプリの実装

実装はシンプルで

  • 現在の市場から取引すべきか判定を行う
  • 取引すべきと判断した場合は各取引所に注文を入れる

の2ステップです。

現在の市場から取引すべきか判定を行う

一定額以上の利益が出ると判断した場合に、取引すべきと判断します。
式で表すと下記の通りです。

(X)[アービトラージによる利益] - (Y)[取引手数料] > (Z)[閾値]

(Z)閾値
自分で適当に設定します。
今回は後述の (X) アービトラージによる利益 の計算方法がかなり雑なので余裕を持って大きめの値に設定しておきます。

(Y) 取引手数料
Aでビットコインを買うための手数料、Bでビッドコインを売るための手数料の2つかかります。 手数料は取引所によって異なりますが、取引量に応じて手数料も増えていくように設定されているところがほとんどです。

例: 手数料一覧・税 - ビットコイン(Bitcoin)の購入/販売所/取引所 【bitFlyer】

(X) アービトラージの取引による利益
大雑把に最良askと最良bidで計算します。 *1
最良askは他の人が出している買い注文の中で最も高い値段(=自分から見たら最高の売値)、最良bidは他の人が出している売り注文の中で最も安い値段(=自分から見たら最安の買値)です。

取引所がA・B2つあったとして、Aでビットコインを買い、Bでビットコインを売るとします。 仮にAで最良bidで1BTCを買い、Bで最良askで1BTCを売ることができた場合の利益は

[取引所Bの最良ask] - [取引所Aの最良bid]

となります。

しかし、実際取引できるのは自分の口座にある分だけなので、

([取引所Bの最良ask] - [取引所Aの最良bid]) * min([取引所Bにあるビットコイン], [取引所Aにある日本円] / [取引所Aの最良bid])

となります。

取引すべきと判断した場合は各取引所に注文を入れる

取引すべきか否かは最良bid、最良askを見て判断しましたが、実際この価格で注文を入れると取引の成功率がかなり低いです。
「安い値段で買いたい!」「高い値段で売りたい!」のは他の人も同じななので、すでに注文が成立してるケースが多々あります。

ということで、余裕を持たせて最良bidよりちょっと高い値段で買い注文を、最良askよりちょっと低い値段で売り注文を出し、ちょっとでも成果効率が上がるように小手先の調整をします。

ただ、どんなに調整したとしても注文が成立しないときはもちろんあるので、
その時は手動で注文キャンセルするか*2、しばらく待てば成立するだろうと高をくくって待つか、なにかしら対処しましょう。

今後の課題

実際に取引を行うトリガーや取引が成立しなかった場合の処理を人手でやっているので、まだまだ改善の余地がありそうです。時間があれば直したいです。

ただ、昨年8月ごろに稼働させていたときは bitFlyer と conicheck を使っていたのですが、conicheckどうなるんでしょうね。。。。。。
当時見た限りでは他の取引所だと取引数がかなり少なかったので、取引チャンスの判定や注文方法を改善してから出ないと厳しそうです。

*1:より正確に利益を予想するため、また、取引の成功率をあげるためには、板情報(どの価格にどれくらいの注文がはいっているのか)を見た方がいいですが、今回はかなり雑です。

*2:これも本当はbotでやれるといいですね。

Slack-Ruby-Bot のログをファイル出力できるように修正を入れた

OSSコミット╭( ・ㅂ・)و ̑̑ グッ !

github.com

以前まではSlack-Ruby-Botが吐くログはすべて STDOUT に出力されていましたが、この修正によりログの出力先を任意に設定することができるようになりました。

設定例

SlackRubyBot.configure do |config|
  config.logger = Logger.new("slack-ruby-bot.log", "daily")
end

この設定は v0.10.4 より利用できます。

修正を入れようと思った経緯

Slack-Ruby-Bot では SlackRubyBot::Loggable というモジュールを用意しており、ログを吐き出す際はこのモジュールをそれぞれのクラスやモジュールでインクルードして利用しています。
SlackRubyBot::Loggable.logger の出力先は STDOUT で固定されていたため、 Slack-Ruby-Bot 側でエラーが発生した場合は bot を起動したプロセスの標準出力にログが吐き出さます。そのため、ログをファイルに残すにはプロセス起動時に出力先をリダイレクトする必要がありました。
自分の利用する範囲では Slack-Ruby-Bot 側のログを残す必要はなかったためリダイレクトしていなかったのですが、別のある問題が度々発生していました。

長時間プロセスを起動しっぱなしにしていると、botが落ちるのです。
長いときは1週間程度、短いときは数日で落ちてしまいます。
あまりに頻繁に落ちるので、毎朝毎朝 bot の生存状況を確認しては落ちていたら起動するという介護生活が始まりました・・・・。

業務効率化のために作ったbotなのに、botの介護作業を毎日しなければいけない状態では本末転倒です。

OOM Killerに殺されたのか?

ファイルディスクリプタが足りなくなったせいで落ちたのか?

いくつか可能性の有りそうな事象を挙げてみましたが、サーバのログを見ても上記の事象が発生していた形跡はありません。

そこで、原因特定のために botruby プロセスが死ぬタイミングでログを吐くようにしました。

#<Errno::EIO: Input/output error @ io_write - <STDERR>>

backtrace: [
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:610:in `write'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:610:in `warn'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:610:in `rescue in write'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:594:in `write'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:378:in `add'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/2.2.0/logger.rb:452:in `error'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/server.rb:82:in `rescue in handle_exceptions'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/server.rb:86:in `handle_exceptions'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/server.rb:27:in `block in run'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/server.rb:26:in `loop'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/server.rb:26:in `run'", 
"/home/xxx/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/slack-ruby-bot-0.9.0/lib/slack-ruby-bot/bot.rb:6:in `run'",
"hogehoge-bot.rb:22:in `run'",
"hogehoge-bot.rb:58:in `<main>'"
]

これがbotの遺言です。 SlackRubyBot::Server#handle_exceptionsでエラーログを吐く際に落ちていました。

(予想ですが)長時間プロセスを起動していると標準出力が閉じられてしまうため、エラーログを吐こうとするところでEIOエラーが発生しているようです。

そのため、冒頭に書いたように Slack-Ruby-Bot にてログの吐き出し先を任意に変えられるように修正を入れ、 bot に反映したところ

_人人人人人人_
> 突然の死 <
 ̄YYYYYYYYY

が発生しなくなりました!

ということで一件落着、介護生活から開放されました。

LINE BOT API Trial & bluemix を使ってbotを作る

qiita.com

を見ながらherokuでオウム返しbotを作ってみた。

がしかし、herokuは無料版だと

  • herokuだと24時間連続起動できない
  • 30分アクセスがないとスリープになる

等の問題があるので、

qiita.com

を参考にbluemixでlinebotを作成してみたい(まだやってない・・・)。