妻の妊娠中に転職するということについて

はじめに

以前の記事にも書きましたが、2017年4月末を以って、通算10年働いたSIerを辞めて、WEB屋に転身しました。 syogo0417.hatenablog.com

実はこの時、妻は第一子妊娠中でした。

※先日9月28日に元気な女の子を産んでくれました。

妊娠中の転職について調べると、妊娠中の転職をタブー視するページはたくさん出てきますが、 実際に転職したページはあまりなかったので遺しておきます。

タブー視しているページの多くは当然女性目線です。

出産の主役は奥さんと子供なので、分かります。

が、男性目線だとちょっと違ったり、業界が違っても考え方はやっぱり違うので、どうすべきか悩んでいる方の参考になれば。

転職までのスケジュール

  1. 決意したのは2016年12月末
  2. 年末年始の休み中に経歴書など作成
  3. 2017年1月中旬くらいからエントリー開始
  4. 2017年2月〜3月に面接ラッシュ&内定・退職意思表示
  5. 2017年5月から新しい会社へ

妊娠がわかった時期

2017年1月20日前後に正式に判明。

年明け早々くらいからほぼ間違いない確度で妊娠したとは言われてました。

なので、転職活動を本格始動した時とほぼ同時期に妊娠が正式に発覚しました。

できたと思うと言われたのは始める前くらいですね。

妻は転職することについてどう思っていたか

勿論快く思ってないです。

転職活動始めた旨を言ったら、「妊娠したかもしれないの判ってる?」とメチャクチャ言われ続けました。

あと、嫁の親からも説得されました。(お住まいは嫁の実家の近くでしたので)

自分の転職に対する認識はどうだったか

収入が現状維持以上なら、転職しようが留まろうがこっちの自由では?という認識でした。

※控え目に収入は現状維持と書きましたが、前職の給料は安すぎなので、上がる以外の未来はないと思ってました。

あと、単純に給与が安すぎるので、子供が生まれたら育てる金ないヤバイ!っていうのもありましたね。 妻からは1年待てなどアレコレ言われましたが、そんなことしたら市場がどうなっているかも判らないですし、 給与下げないからお願いします、とごり押ししました。

転職してどうなのか

収入面などはバッチリUP。子育てに不安はない程度には増えました。

会社の休みも増えたので、めでたし!

とは、諸手を上げて言えません。

もっと考慮しておくべきだったこ

ここからが本題です。
妊娠中、出産中は割とイベントがあります。
私はこの辺がカラッキシなので、かなり揉めました。
なので、奥さんが妊娠中に転職しようとしている方は以下の点も考慮してあげた方が平和に過ごせます。

  1. パパママ教室(月1くらい)
    妊娠中のパパママ向けに出産までどう過ごすかなどを教えてくれる教室があります。
    コレ、夫婦揃って出席する人が多いです。
    なので、妻だけ行かせると、周りの幸せオーラに毒されます。
    「何で家は一人で出席なんだと・・・」
    転職すると有給が半年つかなかったりもするので、それでも不利になることなく(主にボーナスカット)休めるのか、は要チェック事項です。
    ※有給付いて休めるなら文句なしですね。

  2. 妊婦検診(時期による、出産直前は毎週)
    嫁曰く、お腹の子の成長を一緒に感じたいとのこと。
    まぁ確かに。
    一度も一緒に行けないと遺恨を残すので、なるべく一緒に行けるような配慮が必要です。
    これを全て叶えるなら、「転職しない」が正解になります。
    夫婦でよく話合う必要がありますね。(お前が言うな)

  3. 出産の立ち合い&退院
    我が子が出てくる場合の立ち合いと、家に帰る場合のお迎え、この最低2日(出産は1日で終わるとは限らない)の休みの確保は絶対条件です。
    出産に係る特別休暇があるかどうかは確実に聞いておく必要があります。(流石にここは聞いた)
    休みが取れないなら最悪転職を諦める必要もあるという認識です。

  4. 一カ月検診
    退院時の前日くらいに、生まれた赤ちゃんの検診日が決まります。
    大体平日です。
    そして赤ちゃんが初めて外にお出かけをするメモリアルデーでもあります。
    なるべく休むようにしてあげたいですね。
    私の場合は、赤ちゃんが有難いタイミングで出てきてくれたおかげで、有給を使えます。
    休めなかったら、多分やばかった・・・。

こんな感じで外すと夫婦間がヤバくなりそうなイベント盛りだくさんです。

辞める会社のここを確認しておけば良かったこ

給与制度に疎くて、これは完全に私の過失ですが、会社を辞める場合は以下の事象を絶対に確認してください。 最悪、死にます。

  • 給与が前払いか後払いか絶対に確認する必要がある。 辞めようとしているその会社に入って最初の給料日を思い出してください。

新卒の場合、4月に貰っていれば前払い、5月に貰っていれば後払いです。

で、問題になるのは前払いの場合です。

給与を前払いで貰っている場合、退職月は給料が出ません。(残業分は出る)

※後払いなら普通に給与が貰えます。

これにより、転職先の給与が後払いだと、入社月は給与が入らないので、「2か月間」も無給になります。

我が家は自分の認識ミスでこの問題が露呈して、めっちゃ怒られました・・・。

まとめ

私は妻が妊娠中に転職しましたが、全くもっておススメしません!

が、こういうイベントを上手くかわせる場合は良いと思います。

例えば、妊娠発覚時に最終選考まで進んでいる、など。 ※妊娠発覚時にここまで進んでいれば、パパママ教室を少しすっぽかすくらいで済むため。

何にしてもしっかりと話し合う必要がありますね。

補足

妻が妊娠中に対する転職活動が原因で不利になるということは一切なかったです。 転職市場において、出産後は早く帰りたいとか言い出すんだろ?とか夜寝れなくて生産性下がって採用費用をペイできないのでは?など、そういうネガティブ要素を気にされることもなく、関係ないみたいでした。

AWSクラウドロードショー2017名古屋に行ってきたというメモ

午後から重要会議らしい会議を放り込まれたので、午前だけいってきました。 名古屋、スーツ率高いしハッシュタグを教えてもツイッター率少なすぎ。 製造業が主流なだけあって、やっぱ硬いお国柄のようです。(馴染めない)

AWSロードショー 2017/09/27

awsサミットのミニ版の位置づけ

【基調講演】イノベーション創出のためのクラウド活用とは ~クラウドだからできる IoT、ビッグデータ、AI ~

  • 世界で数百万のアクティブユーザー
  • 各社フルマイグレーション、ハイブリッドで使用
  • 東海地区の客でなぜかうちの会社も紹介されてるぞーーーw
  • クラウドファーストは止まらない
  • サービスのロードマップは客からのフィードバックで決まる
  • AWSの規模:1.6兆円規模
  • アメリカ政府専用のリージョンを開設予定
  • アベイラビリティゾーンで30万台以上のサーバーを運用
  • ルーター、チップ、NICサーバーラックは自社開発
    ベンチマークないから性能試験よろしくやれよ!ってことだという風に先輩にお言葉をいただきました。 企業の基幹システムをクラウドへ・・・は、気をつけろよ!と受け取りました。 クラウドファーストらしく、小さく作ってフィードバックを受け取るようにやってけば問題にならないけど、 既存システムをクラウドに乗せ直すだけの程でクラウド使うと、死ぬで?という感じですね! サブシステム、サブセットを物理的に分けられるように作ってれば問題にならないけど、エンプラ系だとそれが割とできていないし、できない。 いい加減、Maven/Gradleくらいデフォルトになった方がいいと思う名古屋近辺。。

その他

  • AWSを入れるのはコスト削減が理由だが、 その後のスピード感やエンジニアのモチベーション向上に役立つという声が多数。 選べる手段がたくさんあるからそこに注力するのは確かに面白いし同意。
  • 日本準拠法を選択可能 大阪ローカルリージョンは、東京との併設前提で開設。
  • AWS使って成功している企業はイノベーションに使用している それは、IoT、AI、ビッグデータなどの利用。
    →データ活用する仕組みを作れるようにしとくことが肝要
  • GooDay:客と従業員の銅線把握どうやってんのか気になる
  • グリーングラスはエッジコンピューティング、フォグコンピューティングの主要技術になりそうな予感がある。
  • Snowball使えば、既存サービスをAWSに移行できそう。そして運用費軽減へ・・・
  • 色々なAI、機械学習フレームワークの最新バージョンがすぐ使えるの有り難い。
  • FM和歌山:Polly使ってニュース流してる(反響がすごいらしい)

テクノロジーアップデート

AWS Greengrass

AWSを使用しているデバイス上に拡張するサービス。

  • ローカルアクション
    Lambdaファンクションを実行可能
  • ローカルトリガー
    バイスからサーバサイドに通信する場合に、 クラウドと繋がっていない場合に、データをキューイングさせ、 繋がったら送信するなど可能。
  • ローカルデバイスシャドウ
    ローカル側でデバイスの状態を確認できる データをローカルとサーバで同期する
  • セキュリティ
    AWSと同様のセキュリティ Greengrass使えばM2Mも可能。

メリット

  • ローカルイベントの高速な応答
  • オフライン処理もOK
  • クラウドと同じプログラミング
  • IoTアプリのコスト最適化
  • AWSと同様のセキュリティ

RioTintoの事例

トラックで悪路を走るとトラックの消耗が激しい。 良いルートを走れば寿命が長くなるから、 最適なルートを誘導できるようにしたい。 ただ、僻地だからネットワークに繋がらない →タイヤにセンサくっつけて、Greengrassにセンシングしたデータを蓄積、 ネットワークに繋がったらサーバーに転送、蓄積、分岐。 毎日数時間おきにルートを更新して、ドライバーがルートを使用。

東京リージョンで使えるようになった! python、nodejs、javaが使える

各社ブース

マカレル

自分のTLでよく話題に出ている「噂のマカレル」が来ていたので訪問してみました。 ダッシュボードとか使いやすそうな印象。 ソリューション頑張って売って来い的な空気もなく、はてなってすごいなと思いました(月並みですみません)。 マカレル、週末でせせこさと遊んでみます。

前職

知ってる人来てないかな~と立ち寄りました。 THE・エンプラ感が半端なかったですw 自分的には、MONOwebを期待して行ったのですが、違った。 www.tis.co.jp

OBなのでリンク貼って貢献しときますw

おまけ

これはじめて知った。

仮想通貨で資産運用をはじめてみました

はじめに

巷で話題の仮想通貨で資産運用をはじめたので、なんではじめようと思ったのかと、はじめて見た所感を残しておきます。 資産運用をはじめた、と云っても、今は実験中なので掛け金は自分のお小遣いでやれる範囲です(泣)

ビットコインに絞って書きます。

あ、これ読んで仮想通貨買おうと思った人は、当然ですが自己責任なのでお願いします。

何ではじめたの?

もともとはブロックチェーンの内容を把握するために、対で語られることの多いビットコインについて勉強したのが発端。 ビットコインブロックチェーン、FinTechを初心者に判りやすく説明している以下の本を読んだら、 「仮想通貨良いじゃん」となり、ちょっと使ってみようという境地に至りました。

Amazon CAPTCHA

この記事は誰向け?

仮想通貨、最近テレビのCMでもやってはいるけど、怪しい感が拭いきれないような人々。

運用を始める前のビットコインの印象はどうだったか?

私自身、ものすごく怪しいものだと思っていました。 だって、資産が持逃げされたとか、運営会社が破産してパーになったとか色々聞いてたから。

この精神状態から、「仮想通貨良いじゃん、投資してみよう」という状態に変わった理由をお伝えできればと思います。

仮想通貨とは

インターネット上にだけある実体のないお金です。 これだけ聞くと、大丈夫なのか?って思いますが、ブロックチェーンという技術と1つの組織や国で管理されるものではないため、 不正が入り込みづらい環境が整っているため、インターネット上にしかないけど、セキュリティ面はどこぞの企業の基幹システムなんかよりも遥かに強力だという印象を持っています。 また、発行枚数に上限が決まっており、自由に発行できるということがないため、ある程度出尽くすと安定するのではないかという印象を持っています。

誰が運営しているの?

上記で、「1つの組織や国で管理されるものではない」と書きました。 これが表すのは、世界中の人、会社の事業に支えられて運営されているということです。 なので、例えば誰かが「金がないなら、じゃんじゃん刷ろう」という政策をしようとしても、仮想通貨ではこれができません。

どうやって運営しているの?

マイニングって呼ばれてるヤツです。 最近日本でもGMOやDMMが仮想通貨のマイニング事業を始めると発表しましたが、この行為に支えられています。 マイニングとは、仮想通貨のやり取りの記録を承認する行為です。

ビットコインなどの仮想通貨の取引は、個人対個人(P2P)で行われますが、取引の承認は第3者が行う必要があります。 これがマイニングというヤツです。

マイニングって具体的に何してんの?

仮想通貨の取引の記録は、ブロックチェーンと呼ばれる技術によって、1つの鎖に全ての取引記録を繋いでいます。 この最後尾にガチャンと新しい鎖を嵌め込むためのキーを見つける作業です。 具体的には、「直前の取引記録のハッシュ値」に、「今回の全取引データ + 任意の文字列」を連結し、これを64桁のハッシュ値に置き換えた場合に、先頭の16 - 17桁が全てゼロになる「任意の文字列」を見つけることです。 この任意の文字列は「ノンス値」と呼ばれています。

マイニングに参加すると良いことあるの?

あります。 ビットコインの場合、マイニングは10分に一度行われます。(ノンス価を見つけるのにそれくらいかかるというだけ、という印象) ノンス値を複数の人が発見することで、取引が承認されるのですが、最初にノンス値を発見した人に賞金が与えられます。 ビットコインの場合は、12.5ビットコイン(単位 = BTC)です。 2017/09/24のビットコインのレートが1BTC = 約40万円ほどなので、マイニングに勝った勝者には日本円で約「500万円」が手に入ります。 これが10分に一度発生するので、勝算があれば事業として始めるのは、自然なことだと思います。

個人でもマイニングレースに参加できるの?

できますが、膨大なマシンパワーとそれを動かすための電気代がたくさんかかるので、個人でやるのは相当気合の入った人ではないと無理です。 仮想通過の資産運用をするだけなら、破産は絶対しませんが、マイニングレースは勝てないと破産する可能性があるため、 個人では手を出さない方が良いと思います。

こんな感じのため、ビットコインやその他大口の仮想通過について云えば、 インターネット上にしかないとはいえ、自分が購入した仮想通過がいきなりなくなって、無一文になりました!みたいなことは発生しません。

とは云え、中国が仮想通貨を禁止するというニュースで大事になってるけど、問題ないの?

私の認識では、今現在はないと思っています。 中国で仮想通貨が流行っているのは、国の情勢もそうですが、電気代が安いのでマイニング事業者が多いという印象です。 中国が仮想通貨を禁止したところで、市場は一時的に売りに走られるため、価値は下がりますが、 発行枚数は変えられない状態で、安くなるというだけなので、買いが進み元に戻ります。 2017/08に中国絡みで、1BTC = 50万程度あったビットコインが30万まで価値が下がりましたが、数日で45万程度に回復しました。

今現在、仮想通貨でデイトレードしている人たちからすると、早よ下がれ!そしたら買い増して上がったら円に戻すか他の仮想通貨に移すから!規制してくれてありがとう!くらいにしか思ってないです。

仮想通貨での資産運用って儲かるの?

今現在で云えば、有名どころの仮想通貨を買っておけば硬いです。 ビットコインの場合、1日で3万程度は増減するため、1万円の投資でもうまくやれれば1日1000円程度は資産を増やしたり減ったりさせられます。

資産が減った場合を書きましたが、 買ったところから価値が下がっても、放っておけばそのうち上がる、という安心感が今はあります。 現状では完全に仮想通貨バブル状態なので、基本的に負けは有りえません。 ただ、放置はしない方が良いです。 基本は、安く買って、高くなったら売って利益を確定させるか、売るときに下がっている仮想通貨を買えば良いです。 ビットコインを持っている場合は、直接他の仮想通貨を買えます。

破産の心配ってないの?

余貯金でやっている場合は、基本的に破産はないです。 クレジットカードで買うこともできるのでそういうことをする人は知りませんが、 仮想通貨を買うためには、仮想通貨用の銀行口座が必要になります。 これは、取引するWEBサイトでユーザーを作れば勝手に作られます。 この口座をウォレットと呼ばれているヤツです。

仮想通貨は、このウォレットに振り込んだ金額分だけしか売買できないので、 自分の資産を超えた投資というのはできないため、破産の心配は先ずありません。 ※給料全額入れたり、クレジットカード振込しなければ、です。

なので、私のお小遣いでもできるというわけです。

資産運用以外に使い道ないの?

海外送金・外貨への両替、募金なんかにはものすごく使えると思います。 通常、海外送金する場合、法外な手数料を取られますが、ビットコインでこれを行うと手数料が送料の1%で済みますし、 海外旅行をするのに円を外貨に両替すると両替手数料がものすごく取られますが、ビットコインを挟むことで格安で済みます。

また、募金については、東日本大震災など災害が起こる度に募金活動が行われますが、その用途は実際不明ですよね? これを仮想通貨で募金を行うことで、その取引はブロックチェーン上に記載され永久に残るため、 本人たちに届いたのか、どういう使われ方がされたのか?などが第3者に分かるようになって透明度が増します。

その他だと電気代をビットコインで払えたりとか、つい先日H.I.Sがビットコインでの決済をはじめました。 今後、どんどん仮想通貨の利用範囲は拡大していくと思います。

どうやって始めるの?

仮想通貨の取引ができるWEBサイトでユーザー作って本人確認証を送付なり、アップロードすると、 本人確認の通知ハガキが届くのでその時点で買えるようになります。 BitFlyerが最近TVCMをよくやっていますが、私は初心者に優しいといろいろな書籍に買いてあったので、コインチェックを使用しています。

インチェックはスマホアプリもあるため、アプリを入れておけば、24/365好きなときに1タップで取引できるようになるのでオススメです。 取引は数秒で成立し結果がメールで送られてきます。 このスピード間も人気の理由だと思います。 ちなみにですが、仮想通貨の売買は手数料がかかるため、しっかり利確したら売りましょう。

いつ買う?

チャート見てると、平日の昼11時 - 15時の間は割と下がって谷がきやすい印象。 夜は21時 - 1時くらいまでの間にピークがあって、それを超えると下がり出す。 明け方(5時くらい)は大体やすい、谷ではないけど、十分利益をあげられそうな程度には低い。

最後に

疲れたので、まとめます。 仮想通貨は、

  • 不正がしづらく安全

  • 破産の心配はない

  • 値動きが速いため、うまくやれば1万円の投資で1日1000円程度は増やせる

  • 海外送金や外貨への両替に良い

これを機に仮想通貨にちょっと手を出してみるか、勉強してみると私が楽し〜!と言っている理由が分かると思います!

JavaエンジニアがPHPer(Laraveler)にクラスチェンジするためにやったこと

はじめに

会社のエンジニアにLaravelを教えないといけないっぽいので、
何をしたかを文章にして参照できるようにしておきます。

今からLaravelを始める人、PHPを始める人には参考になると思います。
※嘘です、プログラム経験が全くない人には参考にならないと思います。

ちなみに、PHPは始めて丸4カ月程度、Laravelは3カ月程度です。
それ以前はJavaやCなどを10年書いてました。

やったこと(時系列)

  1. PHPerになるためにやったこと
    以下の本を読書&写経しました。
    プログラミング言語は色々と経験があるので、文法が判ればとりあえずOKというスタンスで選びました。
    とりあえず、PHPは文字列と配列の表現が豊かというか、ほぼ半分くらいこの説明だったので、あ~こういう言語なのね、というのがよく判って良かったです。

    www.amazon.co.jp

  2. Laravelに慣れるためにやったこと
    当然、素のままPHPを使うこともなく、会社ではLaravelというWEBアプリケーションフレームワークを使用するので、それの仕組みや使い方を知る必要があるわけです。
    それには、以下の2冊を写経しました。(Kindle Unlimitedで無料)

    www.amazon.co.jp


    www.amazon.co.jp


    これで使い方や仕組みは大体判るので、普通に組めるようになると思います。
    あ、Java屋視点だと、APサーバはワーカースレッドで以て処理を行うためマルチスレッドで動きますが、PHPは1リクエスト1プロセスで動くため、
    ここを理解していると一層やりやすいと思います。
    この辺りを理解できていないと、モヤモヤしながら組むことになるので。

では、よきLaravelライフを~。

LINE Messaging APIでできることのまとめ

はじめに

仕事でLINE Botを作る機会があり、休みにドキュメントを読み込んだときのメモを晒します。

たしか、Overviewを和訳して糊付けしたヤツです。

なので、これを読むとLINE Messaging APIで何ができるのかほぼ全部判ります。

Overview

https://developers.line.me/messaging-api/overview

アーキテクチャ

LINE Platformに、企業側サーバのURLを記載する必要がある
ユーザーがあなたのアカウントを友達として追加したり、メッセージを送信したりすると、LINEプラットフォームが登録された上記URLにリクエストを送信する。

メッセージ受信とオペレーション

LINE platformから企業側サーバに情報を送信するパターンは以下。

  • ユーザがメッセージを送信するメッセージタイプ
  • ユーザが(bot)アカウントを友達として追加する操作タイプ

すべてのHTTPリクエストヘッダに署名が含まれているため、
企業側サーバは署名を使用して、リクエストがLINE platformから送信されたことを確認する必要がある。
リクエストがLINE platformから送信されていない場合、リクエストは無効であり、
予期しないイベントが発生する。

Calling APIs

LINEプラットフォームが提供するAPIを使用して、企業サーバーからユーザーに情報を送信することができる。

APIでできること

  • 個々のユーザーまたはアカウントを友人として追加したすべてのユーザーにメッセージを送信する
  • ユーザーのニックネームを取得する

サーバーはいつでもユーザーにメッセージを送信するためにAPIを呼び出すことができる。

API呼び出しが行われると、以下がリクエストヘッダーに設定され、呼び出しが企業サーバーからのものであることを確認する。

  • Channel access token or Channel ID
  • Channel secret
  • MID for your Channel

これらは、LINE Developersサイトから取得できる。

また、APIHTTPS経由でアクセスする。HTTPは不可。

Messaging APIでできること

  • push messages
    Botアカウントを友達に追加しているユーザーに直接メッセージを送信できる。(ユーザーへの単方向)
    これをやるためには、followやjoinなどのイベントが発生した場合に、送信元IDを取ってDBなどに保存しておく必要がある。
    また、unfollowやleaveが発生した場合は、保存した送信元IDなどは削除しておいた方が良い。
    unfollowやleaveした相手にはメッセージは届かないが、こちら側のアプリで余計な処理をしないようにするために入れておくとイイ。
  • reply messages
    ユーザからのメッセージに返信する。Webhooksを使用してBotアカウントへイベント通知を受ける
  • Send Imagemap messages using APIs
    イメージとリンクを含むリッチコンテンツメッセージを送信する。
    Imagemap messagesは、クーポン、特別プロモーション、ニュースアナウンス、ブログ投稿に最適
  • Template messages
    画像、テキスト、複数のユーザーアクションの選択肢、ボタンなど、さまざまな種類のテンプレートメッセージを送信します
  • Use your bot in groups and rooms
    グループチャット、1対1チャットでユーザーと交流できる

APIリファレンス

https://devdocs.line.me/ja/

構成コンポーネント
  • Webhooks
    友だち追加情報やユーザから送信されたメッセージをリアルタイムに受信する仕組み
  • Reply Message
    ユーザから受信したメッセージやイベントに対して返信する
  • Push Message
    任意のタイミングでユーザにメッセージを送信するAPI(要PROライセンス)
  • Multicast
    複数のユーザに任意のタイミングでメッセージを送信するAPI(Push Messageの複数版)
  • Content
    ユーザから受信した画像や動画、音声をダウンロードするAPI
  • Profile
    ユーザのプロフィール情報を取得するAPI
  • Leave
    参加したグループやトークルームから退出するAPI
LINE Bot SDK

for PHP(https://github.com/line/line-bot-sdk-php)

Status Codes list

| Status Code | Description |
| 200 | OK |
| 400 | Bad Request. リクエストの仕方に問題あり |
| 401 | Unauthorized. Authorizationヘッダを正しく送信できていない |
| 403 | Forbidden. APIの利用権限がない |
| 429 | Too Many Requests. アクセス頻度が制限を超えた、超えている |
| 500 | Internal Server Error. LINEのサーバ側エラー |
> Sorryコンテンツ返却時のコードを追加してくれると嬉しい

実装の流れ(Webhook)

  1. リクエストヘッダの署名検証
  2. 受信イベントごとの処理
  3. レスポンス返却
制約
  • WebhookのHTTPS POSTに対しては、常に200 OKを返す
  • WebhookのHTTP POSTリクエストが何れか失敗しても、リクエストは再送されない
署名検証

リクエスト送信元がLINEであることを確認するために、署名検証を行わなくてはいけない。

各リクエストの「X-Line-Signature」ヘッダと
リクエストボディとChannel secretから計算したものが同じであることを必ず検証する。

この部分はSDKでメソッドが提供されているので、それを呼ぶだけで実現できる。

Webhook event object

LINE Platformで発生したイベントを表すJSONオブジェクトで以下がある。

  • Common Fields
    全イベント共通で含まれるフィールドで、以下が含まれる
  1. type
    typeでイベント種別を識別できる。以下がある。
    • message
      メッセージが送信されると発生
    • follow
      イベント送信元に友だち追加 or ブロック解除されると発生
    • unfollow
      イベント送信元にブロックされると発生
    • join
      イベントの送信元グループまたはトークルームに参加すると発生
    • leave
      イベントの送信元グループから退出させられると発生、自分で退出した場合は発生しない
    • postback
      イベントの送信元が、template messageに付加されたポストバックアクションを実行すると発生
      ※選択肢から選んだ、などが起きた場合。このイベントへは返信可能。
    • Beacon event
      イベント送信元のユーザがLINE Beaconデバイスの受信圏内に出入りした場合に発生
      ※一部の企業・ユーザに限定開放しているらしく、今後オープン化していくとのこと。このイベントへは返信可能。
      >> 色々応用が利きそうなので、将来これだけで何かできるかも。
  2. timestamp
  3. Source user
  4. Source group
  5. Source room(複数人トークのこと?)

※1以外は使ったことないので、特に見てないです。

Message event

メッセージが送信されたことを示すEvent Object。
メッセージの種別には以下がある

  • text
    テキストメッセージ
  • image
    画像、別のAPIでバイナリデータにアクセスする
  • video
    動画、別のAPIでバイナリデータにアクセスする
  • audio
    音声、別のAPIでバイナリデータにアクセスする
  • location
    位置情報(住所、緯度経度)
  • sticker
    スタンプ
Reply message

返信可能なイベントには、replyTokenが含まれているため、これを使用してイベント送信元に返信する。
以下の制約がある

  • 一定秒以内に使用しないと無効になる
  • トークンの有効期間は1回の返信まで
    重たい処理を間に入れると事故りそうなので、そういう場合はどこかにuser_idを保存しておき、push messageで送った方が良い
Push message

企業側サーバから任意のタイミングでメッセージを送信するAPI
Push messageに対応するプランでのみ使用が可能

5件までまとめてメッセージを送信できる

Multicast

基本的にPush messageと同じだが以下が異なる

  • 複数のユーザにメッセージを送信可能
  • グループ、トークルームにはメッセージを送信できない
Send message object

送信するメッセージのオブジェクト
reply、push、multicastでこの様式を使用する
送信可能なメッセージ種別は以下がある。

  • text
    2000文字以内のテキストメッセージ
  • image
    オリジナルJPEG画像とプレビューJPEG画像のURL(HTTPSで1000文字以内)を添付する
    画像のサイズはそれぞれ以下
    オリジナル : 縦横最大1024px、最大1MB
    プレビュー : 縦横最大240px、最大1MB
  • video
    MP4動画とプレビューJPEG画像のURL(HTTPSで1000文字以内)を添付する
    動画と画像のサイズはそれぞれ以下
    動画 : 長さ1分以下、最大10MB
    プレビュー : 縦横最大240px、最大1MB
  • audio
    m4a音声のURL(HTTPSで1000文字以内)を添付する
    音声のサイズは
    長さ1分以下、最大10MB
  • location
    位置情報を送る
  • sticker
    スタンプを送る、有料のものは識別子が非公開であるため、買って調べるしかない。(そもそもLINE@で勝手に使って良いのかという問題もある)
  • imagemap
    リンク付きの画像コンテンツ。画像全体を1つのリンクとしたり、画像の複数の領域に異なるリンクURLを50個まで指定できる
    base URLの末尾にクライアントが要求する解像度を横幅サイズ(px)で付与してくるため、そのリソースパスに画像を置いておく必要がある

 

リンクで実行できるアクションには以下がある。

  • URLアクション
    WEBページへ飛ばす
  • Messageアクション
    400文字以内のメッセージを送信する(何に使うのか思いつかない)
    タップ領域はImagemap全体の幅を1040pxとして、左上を原点に座標と長さをそれぞれ指定する
  • template
    あらかじめ定義されたレイアウトのテンプレートに、カスタムデータを挿入することによって構築するメッセージ
    Template messageは、iOS版およびAndroid版のLINE 6.7.0以降で対応
    以下のテンプレートがある。
  1. Buttons
    画像、タイトル、テキストと、複数のアクションボタンを組み合わせたテンプレートメッセージ
    Buttonsテンプレートには表示上の高さ制限があり、text表示領域の高さが一定以上になると領域の下部がカットされる。 このため、文字幅によっては、文字数制限範囲内であってもテキストが全文表示されない場合がある。
  2. Confirm
    2つのアクションボタンを提示するテンプレートメッセージ
  3. Carousel
    Buttonsを複数並べて提示できるテンプレートメッセージ
    > 画像の有無、titleの有無、アクションの数は、全てのカラムで統一する必要がある

また、テンプレートメッセージに付加するアクションには以下がある。

  1. Postback action
    dataフィールドで指定された文字列がpostback eventとしてwebhookで通知される
    また、textフィールドを指定した場合は、その内容がユーザの発言として同時に送信される
  2. Message action
    textフィールドに指定した文字列が、その内容がユーザの発言として同時に送信される
  3. URI action
    uriで指定されたURIを開く
    uriには、http、https、telを指定可能

Content

ユーザから送信された画像、動画、音声のバイナリデータにアクセスするAPI
コンテンツはメッセージが送信されてからある期間経過した時点で自動的に削除される。保存される期間についての保証もない。

Profile

ユーザのプロフィール情報を取得するAPI
以下が取れる

  • 表示名
  • ユーザ識別子(送信元IDなどにセットされるもの)
  • 画像URL
  • ステータスメッセージ(設定で、ひとこと入れられるもの)

Leave

グループまたはトークルームから退出するAPI

実装について

基本的にSDKでメソッドが提供されているなので、そちらを使いながら実装すればOK。
実際に使って実装したが、難しくなかった。

[Github]

GitHub - line/line-bot-sdk-php: SDK of the LINE Messaging API for PHP

[PHP APIリファレンス]

line-bot-sdk-php

 

DynamoDBのドキュメントを結構読み込んだので、必要だと思ったことの要点まとめ

はじめに

仕事でDynamoDBと戯れる機会があり、
そのときドキュメントを結構読んだ(多分8割くらい)ので要点・思ったことをメモりました。

実装面などについての記載は、AWS SDK for PHP視点になります。

基本事項

以下を参照すれば、基本的なことは大体判る
よくある質問 - Amazon DynamoDB | AWS

物理的な特徴

  • パーティション
    自動的にテーブルパーティション全体にデータが分散され、AWS Cloud の複数のサーバーにデータが格納される。
    つまり分散ストレージであるため、データが均一で登録されるような設計・実装が肝になる。
    これは1つのパーティションに対して負荷がかかり過ぎないように調整することと同じであるため、IOのパフォーマンス安定化に繋がる。
  • 読み込みキャパシティーユニット
    最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果的に整合性のある読み込みを表す。
    4KBデータ未満の読出しは切り上げられるため、例えばこの値を「1」に設定した場合は、1秒間に1回の結果的に整合性のある読み取りしか行えない。
  • 書き込みキャパシティーユニット
    最大でサイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表す。
    1KB未満のデータは1KBに切り上げられるため、例えばこの値を「1」に設定した場合は、1秒間に1回の書き込みしかできない。
  • データサイズ
    各データレコードのサイズには、属性値の他に、属性名も含まれる

扱えるデータ型

  • S – 文字列 UTF-8 バイナリエンコードUnicode
  • N – 数値 有効桁数が最大 38 桁
  • B – バイナリ
  • BOOL – Boolean
  • NULL – Null
  • M – マップ
  • L – リスト
  • SS – 文字列セット
  • NN – 数値セット
  • BB – バイナリセット

各型の詳細は以下を参照

docs.aws.amazon.com

設計時に注意すべき特徴

  • Primary Keyは「HASH」 or「HASH + Sort」のどちらかのみで、キーに使用できるものは最大2つまで。
  • 書き込み先のパーティションはPKに依存するため、特定のパーティションに読書が集中しないように、キーにサフィックスを付ける。
  • テーブル名が同じでもリージョンが異なれば別テーブル扱いになる。
  • 時間単位にキャパシティユニットを大きく超えるような高い読み書きを行うとスロットリングが働いて「ProvisionedThroughputExceededException」が返ってくるので、キャパシティユニットを厳密に管理したいことがある場合は、リクエストの流量に注意を払う必要がある。
  • 大量データ書込みを行う場合、その見込みデータ数を書込みキャパシティプランに設定する必要がある。また、マルチプロセス or マルチスレッドで以てデータの書込み要求を行わないとパフォーマンスが失われる。
    処理時間は書込むデータ数を、いくつのプロセスから分散して25件 * N回の書込み要求をかけるか、である。

実装するときの注意事項

  • テーブル作成は、Primary Keyのみ生成。
    RDBだと構成を全部書くけど、DynamoDBはデータ登録時に属性が作られる
  • scanは公式に書いてあるとおりで、データが大量に保存してあるテーブルには使わない。
    scan自体使わない方針にすると良い。(手抜きで使うとコピペされる危険性の排除)
  • BatchのAPI(BatchWriteItem/BatchGetItemなど)を使用する場合、すべての処理がコケない限りは失敗はせず、個々で失敗したものはリクエストのキーと値が返される。
  • 書込みキャパシティプランをケチって、マルチプロセスで大量データを書いた場合、一部のプロセスで書込みエラーになる可能性がある。キャパシティプランをケチる場合は、シングルプロセスから書いた方がエラーの発生率は下がる。
    自分で試したところだと、
    10WCUで1プロセスから1万件データを25件ずつバルクで書き込んでもエラーにならなかった。

運用するときの注意

  • インデックスを後から付けた場合、テーブルの状態のBackfilling がfalseになるまでインデックスは使われない。
  • 大量のデータが登録されているテーブルに後からインデックスを付与すると時間がかかる。

API

  • CreateTable : テーブル作成
  • UpdateTable : テーブルのプロビジョニングしたスループット値を更新
  • DeleteTable : テーブルの削除
  • DescribeTables : テーブルの状態取得
  • ListTables
  • PutItem : データを1件登録
  • BatchWriteItem : データを最大25項目まとめて登録ただしデータ量はMAX16MB、かつ個々の項目は400KBまで
    ここでいう書込みとは、項目の作成・更新・削除を表す
  • UpdateItem : データを更新
  • DeleteItem : データを削除
  • GetItem : データを取得
  • BatchGetItems : データを最大100項目まとめて取得 ただしデータ量はMAX16MB
  • Query : 検索

良いところ

  • JSON作って投げるだけでデータの操作ができるので手軽。
    AWS SDK for PHP使うと連想配列を作って渡すだけ。
  • 基本的にオンラインでテーブルのチューニングができる。
    重たい処理をする前に、キャパシティをオンラインで拡張しておき、その処理が終わったら元に戻す、といったチートプレイが可能。
  • 登録データのパーティション(分散ストレージ)を均一化させることで、データがどんなに増えてもIOのパフォーマンスが安定する。

残念なところ

  • 一括登録、更新、削除のAPI(BatchWriteItem)の使い勝手が悪い
  • 範囲系の条件が作れないのはしんどい。(が、教授するメリットの方が大きいという認識を得た)
  • BatchWriteItemで型指定しないといけない。
  • BatchWriteItemは型指定をしないといけないのに、値は全て文字列でないといけない(AWS SDK PHP)
  • APIドキュメントの読みづらさが異常

他サービスとの連携

  • タグ
    タグをつけておくと、EC2やS3など、他のAWS上のサービスでタグがサポートされているものと連携してレポートを出すときに活用できたりする。
    DynamoDBでは、タグが付けられたテーブルに関連するローカルセカンダリインデックス (LSI) およびグローバルセカンダリインデックス (GSI) は、自動的に同じタグでラベルが付けられる。

    DynamoDB のタグ付け - Amazon DynamoDB

困ったときの回避方法

  • 属性名がDynamoDBの予約語と被ったら
    式の属性名を付ける(DBのas 別名相当)
    Commentは予約語だが、以下のようにするとイケる
     {"#c":"Comment"}
    ※#は必須

補足

色んな解説見て意味不明だったものを記載

  • グローバルセカンダリインデックス(GSI)
    テーブル作成時のPKとは別に、他の属性でPKを作れる。
    テーブルのPK同様、Partision KeyとSort Keyの組み合わせで指定可能
  • ローカルセカンダリインデックス(LGI)
    テーブル作成時のPartision Keyと任意の属性をSort Keyに指定してPKを作れる。

 所感

アプリ屋としてDynamoDBを使うときは、
以下のAPIだけ使えば基本的には良いという印象を持ちました。

  • BatchWriteItem
  • Query

理由

  1. テーブルの作成・削除はアプリ屋では行わない
  2. データの書込みはまとめて送りたい
    ※他のAPI使うと1件しか書込めないので使う理由が見当たらない
  3. データ取得の条件は柔軟性を担保したい

あとは、読書するデータ量が肝なので、このあたりの想定容量をデータの整合性を保つ必要があるときはJSONなど駆使して保ちつつ最小化できるように、テーブル設計してあげれば、地雷はあまり踏まないで使いこなせそう。

書評:レガシーソフトウェア改善ガイド

Kindle版、Amazonポイント50%還元キャンペーン中に、技術書を大量買いしたときの1冊。
ずいぶん前に読み終えたけど、久しぶりにパラパラ眺めながら何が書いてあったか纏めておきます。

誰向け?

* 日々レガシーシステムと格闘していて何とかしたい人
* 新しい技術に興味がある人
* 何か新しいことを学びたいけど、何が良いか判らない人
* 新しい技術を仕事で使いたい人(レガシーシステム関係なく)
* 保守中のシステムに対して改善提案したい人

レガシーシステムを改善するためのガイド本なんじゃないの?
と思われるかもしれませんが、
私が読んだ感想としては、私の中では新しい技術を使うプラクティス本的な位置づけです。

向かない人は?

本書に興味がない人
※勉強熱心な全てのエンジニアに読んでもらいたいです

どんなことが書いてあった?

中途の人が新しい職場に転職して、出社初日に開発環境の構築に四苦八苦したり、
良かれと思って直したコードが、他のところに影響してしまったとか、
システムのリライトしたら、過去のバグを再発させたとか、
そんな、保守案件・保守開発のあるある話に対する改善方法を提示してくれています。

ツール類は?

DevOps界隈で言われているツールが殆どです。

これ見てる人にとっては、当たり前に使っているもの・特に使ってないけど、どんなものかは知っている、というものが殆どです。

新しいモノの使い方について

「とにかく一気にやり過ぎない。何かを始めるのは1つまで。」

これは新しく何かを作るときも同様で、新しいことをやったら大抵の場合地雷を踏んでプチ炎上状態の中、問題をクリアしていくことになります。
これは成長するために必要な失敗と成長を体験するために必要な儀式なので、問題ないです。
ただ、新しいことを複数行うとプチ炎上が重なり、大炎上する可能性が、まぁ指数関数的に上がります。
なので、保守・新規に関係なく、新しいことを始める場合は、1案件1つまでにしましょう。

という、納得のことが書いてありました。

私も、新しいことは1案件1つまでと決めてやってます。
もちろん、すんなりことが運んで、もう1個くらいイケたな!と思うことはありましたが、
嵌れば1週間くらいは簡単に溶けるので、2個以上は手に余るので、上手くいった次も1個しか新しいことはしません。

ただ例外もあります。
自分にとっては新しいことでも、熟練者がいるときです。
多くの組織では、熟練者にその部分を担当してもらうと思いますが、これは自分でぶんどれます。
で、自分の判る領域を別の人に回す。
誰かがプチ炎上状態になっても、その領域の熟練者がいるので即鎮火できるので、ほぼノーリスクで新しいモノのノウハウが溜まりますし、
プロジェクトメンバー間で共有すれば、自分がやってない部分のノウハウも身に付きます。(実際には自分で手を動かさないと厳しいと思いますが、あの人ここでハマってこう解決した、というのを聞いていれば解法を導くのが時短できます)

リファクタリングの仕方について

テストを書きましょう!といういつものヤツが書かれています。
新規開発では、まぁ書きましょう!となりますが、テストコードがないレガシーシステムはどういうアプローチでやるの?
ということが丁寧に書かれています。
レガシーシステムについては、有りものを正義とみなして、仕様化テストを書くと良いよ!ということが書かれています。
この辺はちょっと前にテストコードを書いてこなかった人向けに資料作って発表しているので、参照頂ければ。

www.slideshare.net

 

あまり触れられないコストについて(追記分)

絶対に書こうと思って書き忘れたので追記します。
日々の生産性やリリースまでのリードタイムなどはよく取り上げられますが、
人の受け入れコストについて触れているのが本書の特徴です。
特に開発環境の構築は、無駄コストとして扱っています。
確かに、新しいプロジェクトに入ると1〜2日、酷いと3日は開発環境を構築している人、居ますもんね。
一人なら良いですが、人の出入りが激しいと、この工数はバカになりません。

その解決手法はVagrantやDockerを使って開発環境を自動で構築して手間を省こうというものです。

また、新しい人を受け入れて、どの程度で周りと同じ程度の生産性になるかについても言及しています。

最後に

なんやかんやと色々理想が書かれていますが、作者も言っている通りで、
やれること、やれそうなことを無理のない範囲で行っていけば気付いたら脱レガシーになっているだろうし、エンジニアとして色々知見も溜まって良いですね。
私も立ち止まらないように色々チャレンジしていかねば!

レガシーソフトウェア改善ガイド (Object Oriented Selection) | クリス・バーチャル, 吉川 邦夫 |本 | 通販 | Amazon