thrakt's tech blog

コードとかやってる事の話。エモい話とかも含める。

今何やってるのと言われた時のための記事 2017/06/19週

ニャオス

新幹線の券売機はどうすれば使ってもらえるか

www.yutorism.jp

b.hatena.ne.jp

えー、下手の考え休むに似たりと昔から申しまして。忙しい時ほどこういうどうでもいい話を掘り下げてしまうものですな。

自分も席の変更で窓口を使ったことがあり、ああこういう時に窓口を使うんだと腑に落ちた記憶があります。そもそも例外ケースが多く、1件あたりの処理時間も長いから並んでるように見える、という感じではないかと。ただ、じゃあ仕方ないで終わらせるのも惜しい。

ここで最近流行りのAIですよ。ある程度複雑でもINとOUTがわりとはっきりしているので、適用できるのではないだろうか。そこで次の2フェーズを考えた。

  1. 窓口業務をビデオ通話ごしにやるようにして、遠隔化する。
  2. 簡単なパターンからAIに切り替えていく。

1.の段階で、コールセンターみたいな所から一括でやる形になるので、全ての駅で人が余ることがなくなり人件費削減の効果がある、はず。そして、やり取りが音声としてデータ化できるので、それでAI用の学習データを収集する。その上で順次AIに切り替えていくというわけ。

でも切符や現金のやり取りが難しいな、と思ったけどそれも券売機のインターフェースをそのまま使えるのか。あれ、行けるのでは? とはいえまずは現場のヒヤリングかなあという感じです。不正防止とかも気になる。

あとこの世界観で行くと最終的には、自動音声にキレる人みたいに人間を出せ! みたいな展開になるかもしれない。アッ! AIの遺伝子で見たやつだ!

相手に「伝わる」話し方 ぼくはこんなことを考えながら話してきた : 池上 彰

面白かった。池上彰氏のこれまでの経験から、どのような試行錯誤をしていったかが書かれている本。それを通して、伝わる話し方とは? という問に答えていく内容でした。池上彰といえば、模型を使ったわかりやすい説明。自分も週刊こどもニュースを見て育ったので、なかなか楽しめる内容でした。

実用書というよりは自伝に近い内容でした。"わかりやすく説明する方法を身につけ"たい人に100%ハマるかというと微妙な印象。アナウンサーの話とかはアナウンサーの技術論な感じがあり、わりと読み飛ばしてしまった。とはいえ、経験談を通して話されるTIPSには見るべきものがあると思います。

個人的には、税金を取られると言ってしまった時の対応の話が


以下振り返り用メモ

  • 抽象的な物言い(丸めた物言い)はわかったような気になったり、「これで相手もわかるだろう」と思ってしまったり、結局伝わらない。

身も蓋もない言い方の方がいい場合もある。相手に伝わっているか考えるように。

  • ひとつの文章は、ひとつの要素だけを伝える。

長い文章を書きがちなので注意。言いたいことを絞る、とも言えそう。

  • 一方的なお知らせでなく、相手の立場に立って語りかけるように

親近感を与え、興味を持ってもらう。

  • 人は互いに共通体験があると話しやすい。
  • 共通体験は、相手に教えを請うことでも得られる。相手を信頼し、尊敬して教えを請う。

  • 相手が何を知りたいかを考える。そこから話す内容に優先順位をつけ、組み立てる。

全く正論なのですが、なかなか難しい。ここにも相手への理解と尊敬が必要なんだなあという感。

  • まずは「とにかく大変なんです」というコメントから始まる文章を考える。話の「つかみ」を作る。

これは面白いなと思った。自分の伝えたいメッセージをまず持ってきて、相手の興味を考えて関心を引くつかみを作る。すぐ使えるのも良い。

  • 専門用語を外部の人に対して安易に使うのは配慮にかける。

  • まず言葉にする。言葉にすることで自分の考えをまとめる。

  • 抽象論より具体論。具体論は相手に興味を持ってもらえる。

  • 相手に何かを尋ねられたら、なぜこの質問をしたか判断する。そうすると適切な回答ができる。

今何やってるのと言われた時のための記事 2017/06/12週

ニャオス

Headless chrome で帳票が作れるのでは

developers.google.com

帳票(納品書や請求書)をシステムから紙で出すみたいな話はよくあると思う。前にそれでSVFというソフトを入れてやっていたりしたんですが、初期導入費が大きく運用コストもかかる。委託するにしても、やはりかなりの費用がかかる。自前でやる方法もあり、HTMLからPDFを作れるような物もあるみたいだが……。

そこでheadless chromeレンダリング結果をPDFで出力できるらしい。そしてディスプレイなしでコマンド打てば実行できる。

chromeから印刷イメージを出せる事の良い所は、何と言ってもシンプルである事。chromeだけ入れてしまえば、後はライブラリを入れたり、使い方を調べる必要がなく、ページと同じように出していけば良いはず。コマンド一発で片付くのも良い。

さらに、ブラウザの表示結果になるはずなので、確認も楽だし再利用もできる。普段はバッチ処理でPDF作って配るけど、いざとなればブラウザでURL開いてそのままプリンタから出すとか。

レイアウトがどれくらいできるかは試してみないとわからない。印刷用CSSとか見るのかな。文章の折り返しとかはどうなるか。webfontとか使えれば、アセットがかなり楽になりそうな気がする。SVFはデザイン用のツールもあったりしてよかったけど、ブラウザでやるとなるとある程度ハードルは出てきてしまい、そこは課題かもしれない。

という事で、できるのでは! という期待が今自分の中で高まっている。場合によっては結構な削減効果見込めるぞ!

問題はPDF作った後、それをどうやってプリンタに持っていくかなんだけど……。プリンタのベンダごとの違いとか気にするのはもう嫌だ。印刷代行の業者使うしか。

AWS内部DNS

今はAWSを使っていて、踏み台サーバを通して各サーバにアクセスするみたいな事をしている。この時都度IPをインスタンス一覧から見ていて、本当になんでこんな無駄な事をやってるんだろうかと。

前にやってた環境でも同様の課題があり、その時はconsulを導入していた。

qiita.com

ただこれは、当時使っていたIaaSが貧弱で、DNSは一度ホスト名を登録するとずっとIPが変わらない、LBを使うと設定変更時に瞬断が起きて本番系に影響が出る、という事情があったため。AWSなら……! と当時は思ったものでした。

そして今はAWS。R53のprivate DNSを使って解決できそう、なんだけど、サーバの増減は手で反映しないとだめそう。結局awscliの呼び出しをどっかに書いたり、別の所で処理がコケた時にゴミが残ることを気にしたりしないといけなくなる。(そう、デプロイ時に動かすシェルに書いてるアレの事ですよ)

その点、consulはよかった。設定ファイル置いてバイナリ立ち上げればあとは全部やってくれるし、プロセスが落ちたら勝手に離脱する。いわゆるサービスディスカバリ的な用途には結構良いなと改めて思った。

今何やってるのと言われた時のための記事 2017/06/05週

ニャオス

時間があるなら仕事を進めなければッという圧があるが、まぁ手が進まず結局時間が無駄になるという悪循環があり、どうしたものか。

正しいreact

react、構造化できるjQueryぐらいの気持ちで使ってしまっているので、正しさの不在を感じている。あとfluxで処理書く場所がよくないのでは? という気持ちをずっと持ちながら書いてしまっている。(とはいえ同じプロジェクトで書き方が混在するのは避けたい気持ちもある)

こういう時はコードリーディングだ、という事である程度見繕ってはいるんだけれど。そのうちチェックしたい。

ESLint

Rubyはrubocop先生に教えられながら書いているが、ES2015側はわりと無法地帯になってしまっている。ということでESLintをやるべきだろう。

eslint.org

今何やってるのと言われた時のための記事 2017/05/22週

ニャオス

業務時間後と休日は仕事が捗るというSIer時代の上司と全く同じことを考えていて、因果応報という言葉を噛み締めている。どちらかと言うと永劫回帰かも。

データマイグレーションナイトに行ってきた

atnd.org

最近Excelの手入力からMySQLに移行するデータマイグレーションをやっており、インスピレーションと癒やしを求めて参加してきました。DMM.com Labo様主催。東京タワーとかすごい近い絶景のロケーションでした。

ChatWork株式会社 赤津 慶太氏

  • ChatWorkの移行プロジェクトで、メッセージングシステムをAuroraからHBaseに移行した話
    • メッセージングシステムと言うとMQみたいな物を想像したが、チャットのメッセージ全体を格納しているシステムの事で基幹
  • Auroraで17億のレコードを移行
  • 基本マイグレーション + 差分マイグレーションという構成
    • ダウンタイムを小さくする工夫。自分も昔やりました
  • 件数が多いため差分はbinlogを参照して出す。スナップショットから差分を取って移行を繰り返し、最後は本番から。本番とスナップショットのbinlogの出方の違いに注意。
  • DBMS側のメトリクスをしっかり見るのが大事。データを移行してもシステムを壊しては意味ない。
  • Sparkの高速化の話をかなり掘り下げて
    • 門外漢なのでまぁ

株式会社CyberZ 黒木 亮太氏

  • 自社プロダクトをオンプレからAWSに移行した話を全般的に
  • コストのモニターが大事みたいな話

なぜクラウド化したかについて、コスト面とアプリ開発に集中したいからと言われていて、インフラ専業エンジニアはやめてアプリ開発者にクラウド覚えてもらったみたいな話もされていた。DevOpsやんけ~ という感じ。

ただ、クラウドに移行したからといってインフラの知識がいらないとは思えず、むしろ高い専門性が必要になってくる印象がある。アプリ開発に集中というのは開発者の夢であり、PaaSを経て大Serverless時代の到来を待ち望んでいるのではありますが。個人的にクラウドのメリットって高可用性とかになるかなぁと思って聞いていた。

株式会社DMM.comラボ 飯田 涼太氏

  • 基幹システムのAPI更新に伴う新旧同期レプリケータの話
    • 字面がやばく、実際ヤバいアツさがあるプロダクトだった
  • 構成は、新旧ともにMySQLのスレーブとして振る舞うデータ取得機があり、そこから一旦RabbitMQに保存してキューイングし、vert.xで作ったマッパで変換して適用。それが新->旧と旧->新の双方向にある
    • アツい!!!
  • レプリケーションは一旦RabbitMQに書き出すことで、途中で落ちても大丈夫なようにする。永続性を確保。レプリケーションMySQLのバージョンが違ってても対応できるようにした
  • マッピングYamlで指定する形にした
    • なんかすごく汎用性が高いぞ
  • 反映順が担保されないが、結果整合性で解決
  • 更新時に、SQLのコメントやデータなどで更新者を明示し、循環更新されないようにした
  • 問題ないかは日々新旧APIを叩いて比較して検証。マッピングのミスなどで不整合が出ないかは、テスト系でしっかり検証して問題が出ないようにした
    • マジかよ……

とにかく絶対に止めたくないし安全完全ご安心にやるんだという強い意志が伝わってきて、そこまでやるかという感動がありました。これものすごいマンパワーでやってそうで、すごい事例だった印象。

株式会社サイバーエージェントクラウドファンディング(makuake) 吉田 慶章氏

developers.cyberagent.co.jp

の内容らしい。とにかく話が面白く、内容も絞られていて良かったです。

印象に残ったのは、あえて無停止移行を避けて安全側に倒した話。しくじった時のダメージも大きいし、ビジネス側の影響も考えて然るべき調整をして実施したと。そういうの大事だなあと。

Amazon Web Services Japan 千葉 悠貴氏

インバウンドは無料なのでじゃんじゃんデータを持ってきてください、という感じでした。

気になったサービス

www.publickey1.jp

えぇ……


とりあえずAuroraとか実のところRDSインスタンスとの違いがわかってなかったので、その辺調べてみようかと思います。あれ、AWSの勉強会に来たみたいな感想に

自分の経験だと、昔オンプレからクラウドに移行しようとなった時に、ついでにDBのスキーマを整理しようとなってマイグレーションをやったことがあります。基本+差分更新という形で、移行前日まで更新日付を見て移行しておいて、停止後に残りを処理して終わらせる形。移行プログラムはJaveで書いてて、JDBCを2系統用意してSQLで読んで変換しつつSQLで書く形。それなりにデータ量ありましたが、それくらいで済む環境ではありました。まぁなんとか無事には終わった。

最初に書いた人力DB移行の件は、移行データがそれ単体で完結しておらず、結局インポート後に人力で修正をしないといけないという状態で、どうしたものかと。今のところ中間データみたいな物を作って、プレ環境で修正して中間データに書き出し、本番移行という感じにできないかなと考え中ですが、はたして。