iOSエンジニアのしだです。
2018年度 人工知能学会全国大会 が、2018/6/5 〜 6/8に鹿児島の城山ホテルで開催されました。
参加人数が、2572名ととても盛り上がりを感じました。
私は 6/6 と 6/7 に聴講参加してきたので報告したいと思います。
AWS SUMMIT 2018 「Tech上級：データベース入門」にいってきました
こんにちは、Webエンジニアのちょうです。先週開催したAWS SUMMIT 2018に行ってきました。予約が遅くて、２セッションしか取れなかったですが、その中の一つ「Tech上級：データベース入門」について自分の理解と感想をここで記録したいと思います。
セッションのレポートはこちらからご覧になれます。
AWSにおいて、大枠に分けると、RelationalとNon-Relationalデータベース２種類があります。MySQL、PostgreSQLなどのRDBMSはもちろんRelationalデータベース（AWS RDS）に当てはまります。それとDWHに特化したRedshift。Non-Relationalには、NoSQLデータベースであるDynamoDB、KVデータベースのElasticCacheとまだPreview段階のグラフデータベースNeptuneが入ってます。
実際、利用するシーンとデータベースのタイプを見れば大体どれを使うのは分かるでしょう。例えば、PBレベルのデータがあり、SQLを使いたい場合はRedshift、キャッシュとして使いたいならElasticCache。でもRDSの中ではAWSでしかないAuroraというRDBMSがあります。普段使ってるデータベースとなにが違うのかすこし迷うになるでしょう。
セッションでは、普通のRDSはDBサイズが16TB未満という制限を言及していますが、多分これはクリティカル的な問題ではない。AuroraがMySQL 5.6/5.7, PostgreSQL 9.6と互換性がある上で、パフォーマンスとシームレスインスタンスのアップグレードが一番注目される機能でしょう。Auroraの紹介ページでは同じハードウェアの前提でMySQLの5倍、PostgreSQLの3倍早いと書かれています。その原因について、セッションで紹介されているAuroraのアーキテクチャからすこし分かると思います。
- AWSの既存サービス特にS3を利用し、可用性と耐久性の向上
- 複数ノード構成
ここで複数ノードがポイントになるでしょう。普通のRDBMSではシングルノードが想定されていて、パフォーマンスの向上はインスタンスタイプに決められています。つまりスケールアップの方法しかないということです。でも複数ノードになることで、分散実行などが可能になり、一リクエストに対して、並列実行のメリットが得られます。
もちろん、現実はマージソートのような簡単な問題ではありません。Auroraの内部で、分散データベースのように、ノードのダウンを備えて、データブロックは複数のAZにコピーしています。それと、アーキテクチャではノードとストレージが分離されています。つまり、スケールアウトもできるようになります。普通のデータベースがダウンしたら、再起動する段階でものすごくリクエストが入ってしまってまだダウンする問題を考え、キャッシュレイヤーがデータベースのプロセス外に移動されるという施策も紹介されました。
AWSすべてのデータベースを一通り説明するセッションなので、もっと詳しいアーキテクチャが話さなかったです。でもこれでAuroraについて大体なイメージをつかまり、なかなか興味深いです。
それ以外に、HTTPセッションに使えそうなDynamoDBのTTL機能も面白そうです。
いかがでしょうか。AWSのデータベースサービスが多くて、選択が難しいという方が多くいらっしゃると思いますが、ぜひこのセッションを見て決めるようになりましょう。
ユニファのWebエンジニアのテスト事情
こんにちは、Webエンジニアの本間です。
去る2018年5月25日(金)、 株式会社ウエディングパーク の皆さまと合同で勉強会を行いました。 弊社からは以下の2つの内容で発表しました。
- ユニファのWebエンジニアのテスト事情（現状と今後） by 本間
- 新しいスタンダードを作る ユニファのものづくり by 田渕、鶴岡
今回は繰り返しになってしまいますが、自分が発表した1の「ユニファのWebエンジニアのテスト事情（現状と今後）」の内容を紹介しようと思います。
Swift for TensorFlow をさわってみる
iOSエンジニアのしだです。最近はiOSを書いていませんが、iOSエンジニアと言い続けたいと思います。
TensorFlow Developer Summit 2018 にアナウンスされていた Swift for TensorFlow が先日公開されたのでさわってみます。
保育業界に携わるエンジニアが考えていること。
こんにちは。エンジニアの田渕です。 GWで最大9連休！なんて声も聞こえますが、人が少ない時ほど働きたい天邪鬼です。 （いや、単純に電車が空いてるからって話ですが。。。）
ユニファのエンジニアブログも、気づけば開始から一年以上が経過しています。 今回は、保育業界に携わるエンジニアとしての、この一年ほどの自分の活動を振り返ってみました。
ちょうど一年前のこと。
ちょうど一年ほど前のことです。 この「ユニファ開発者ブログ」にて、こんな記事を書かせて頂きました。
この4月から実際に適用が開始されている新「保育所保育指針」に関する内容でした。 読んで頂くと分かる通り、当時出たばかりの新「保育所保育指針」の原文を読んだり、解説している講座に足を運んだり、関連したブログやWeb上の記事を読んだりと、この頃から色々なことを始めました。 自社サービスを持つ会社のエンジニアである以上、ある程度は「顧客」=「保育士や保護者の方々」に対しての理解は必要です。 しかし、これまで黙々と開発していたWebエンジニアがある日突然、保育関連の省庁の文章などを読み出したのですから、前職からの知り合いなどからは「何やってんの？」と盛大に突っ込まれました。
「普通」ってなに？？？
突然そんなことを始めたのには、当然理由がありました。 当時、エンジニアとして様々な機能の要件を定義したり、開発したりしていましたが、自分の中のそれまでの「普通」が通用しないという現実をひしひしと感じていたのです。
「これ、こうしたら喜んでくれるんじゃない？」と思って作ったものが喜んでもらえない。
「こうしたら使いやすくなる。」と思って作ったものが、「使いづらい」と言われる。
明らかに、保育士の方々の感覚に合わせられていませんでした。 新しいプロダクトや機能を開発する際にはヒアリング、テストも行いますので、感覚として分からなくてもそこで調整することで良いものは作れます。 ですが、持って行ったものが全然求められていない/的外れである場合、そこから良いものにするまでには、長い時間と手間がかかってしまいます。 完璧ではなくても、出来るだけ始めから及第点に近いものを持っていけるようになりたい。
「肌感覚として保育士の方々に喜んでもらえるものが分からない」というのは、当時の私には致命的に思えました。
コーディングなどにも当てはまることですが、何かを修正する際、あまりに変更量が多い場合は作り直した方が早かったりもします。 「自分の感覚を保育士の皆さんの感覚に近づける」という行為は、私にとってはまさにそれでした。 ちょっと微修正で辿り着ける気は全くしなかったので、これは一度自分の中の「普通」を壊してやり直そう、と思ったのです。
そんなわけで、黙々と保育所保育指針を読み、関連書籍を漁り、社外の勉強会に参加し、保育士の方々の「普通」を知るため、活動を始めました。
始めから長期戦になるだろうなぁと思っていたので、地道に、コツコツと……。。。
良薬口に苦し
昨今、関連省庁からICTに関する補助金が出ている流れなどもあり、雑誌や勉強会などでも度々保育関連のシステムに関する話題が出ます。 勉強会では特に自分の身分を明かしている訳ではないので、一般的なシステムというものに対する保育士のみなさんの印象や感想をそのまま耳にすることもあります。
「うちの園では最近、なんかシステム導入したんだけど、使い慣れないから時間がかかって子供を見る時間が減った。」
「上の人たちが入れろって言うから入れたけど、全然良さが分からない。」
「これも世の流れなのかしらね。」
正直に言って、ネガティブな言葉の方が圧倒的に多いです。耳が痛い……と思うこともしばしば。 保育システム導入に関しての特集記事などを見ても、現場に近ければ近いものほど「これはもう、避けられない流れなのだから、頑張って受け入れよう！」という、どちらかといえば「諦めて受け入れよう」という論調が多い。 確かに、現時点で様々な技術を含むシステムが保育業界に対して出来ている貢献は、他業種と比べると圧倒的に少ないのです。
ですが、こうして地道な活動を始めて一年、始めた頃に書いた前述の記事を読むと、その頃に比べたら色々なことが感覚として分かるようになったなぁと感じています。 システムに対する印象がネガティブなものになりがちな理由も、わかってきました。
エンジニアが見る夢
最近思うのは、恐らくはシステムを作っているエンジニアが見ている夢が、正しく保育士の皆さんに伝わってないんだな、ということ。 ともすれば、相反し、敵対するものとさえ考えられています。 たぶん、保育関連システムの開発に携わっているエンジニアの中で「保育士さんの仕事を邪魔しよう」なんて考えて開発している人は一人もいないのに、そんな風になってしまう現実は悲しくもありますが、システムを作っている我々の不理解や、力量不足、説明不足な面もあると思っています。
システム化の先で我々エンジニアが夢見ているもの=「本来の目的や将来像」がひとめで伝わり、受け入れてもらえるプロダクトが作れればいいんですが、……なかなか簡単にはいかないものです。
今後も、現場の保育士の方々の声に真摯に耳を傾けながら、少しでもお役に立てるものを作っていけたらと考えています。
それでは。
