他者の生活を変えることのハードル

こんにちは。 エンジニアマネージャーの田渕です。

気付けばコロナ生活が始まって一年半以上、「マスク暑い！」な季節は2回目ですね。 天気予報アプリから「今日の日中は外に出ない方がいいです」なんて警告まで出てしまう昨今、皆様体調管理にはくれぐれもお気をつけください。

さて、本日はそんなコロナ生活の中で、自分に起こった変化と気づきについてのお話です。

SageMakerを用いたオリジナルTensorFlowモデルの推論

こんにちは、データエンジニアリングチームの宮崎です。

少し今更ですが、最近SageMakerにオリジナルのTensorFlowモデルをデプロイできることを知ったので試してみました。 (これまでSageMakerで学習したモデルしかデプロイできないと思っていました…。)

モチベーション

以前、コチラの記事でAWS Lambda上にTensorFlowモデルのデプロイについてご紹介しました。 しかし、AWS Lambdaですとコールドスタート時は応答に20秒前後かかり、応答速度が求められるタスクには辛いところがあります。 また、常に多数のクライアントから推論リクエストがくるケースにも不向きです。 そういったケースはTensorFlow Servingが良さそうですが、ECSにデプロイしようとすると、ロードバランサなどの設定も必要で少々面倒です。

そこで今回は、マネージドでTensorFlow ServingをデプロイしてくれるSageMakerを用い、オリジナルのTensorFlowモデルをデプロイしてみました。

スケジュールにバッファを設けるのは悪か？

こんにちは、プロダクトマネージャーの田嶋です。

はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑

週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！

Hackathon #2 開催レポート

こんにちは！サーバーサイドエンジニアの柿本です。

ユニファは5月の末に本社を飯田橋へ移転しました！

開発本部はコロナの影響もあって原則リモートとなり出社をする人数が激減していたため、移転を機にフリーアドレス化されました。

そして全員が出社することは当面なさそうなので、座席数も全員分は確保されていません！開発本部は50名近くいますが、座席数は28席です。

そこで、１つの不安の声が出ました。

仮に全員が出社しちゃったらどうなるんですか？

ですよね。わかります。不安な気持ち。

ですが、普段オフィスに出社しているのはせいぜい３名程度です！なので杞憂です！心配無用です！！

しかし、不安な声がある限り、開発者たるもの無視するわけにはいきません。

座席の予約システムを作ったらいいのでは？

それだっ！！

ということで Hackathon を開催しました。

Ruby on RailsでデータベースからリモートAPIへ移行する際学んだこと

こんにちは、プロダクトエンジニアリングのちょうです。最近天気は暑かったり、寒かったりするので、体調管理に十分気をつけてください。さて、サービスが増えるにつれ、元々大きなサービスをマイクロサービス化するのは珍しくありません。そんな中で、一つ大きなサービスのデータアクセスをデータベースからリモートAPIに変える際に、かならずいろんな問題が出てきます。今回は私が実際やっていたRuby on Railsのデータアクセス移行で学んだことをシェアしたいと思います。

移行する対象は3つのモデル、A、BとC。これらすべてのモデルをAPIの形に書き換えます。 Railsでしたら、モデルで直接データアクセスできます。例えば

A.find(1)
B.where(a: 1).select('foo')

APIに変えたいなら、そのままなんらかマジック的なgemを使って、APIコールに変えてもいいのかと思うなら、おそらく方向性が違います。私達がやりたいことはこのデータアクセスをAPIコールに変えたいです。そして現在の利用シーンを洗い出してそれにお応じてAPIを作ります。利用シーンの洗い出しはどうしても避けられないです。必須な作業の上にまたそのgemの複雑なマッピングを対応すると仕事量が増えます。既存のコードを変えられない場合以外、やはり正攻法で行きましょう。

Railsのデータアクセスを正攻法で行くには、Railsのモデルはなんなのかを理解する必要があります。あまり意識されていないかもしれませんが、Railsのモデルはすくなくともこのような役割があります。

1. データモデル
2. データアクセス
3. フォーム

決め方の数理2：勝率の数理(AND編)

UniFa プロダクトデベロップメント本部 副本部長の西川です、こんにちは。

最近はなんか妙に暑かったり、かと思えば急に寒くなったりで、大人も子どもも風邪を引きやすいリスキーな季節ですね。 風邪を引きやすい小さなお子さんがいる方々にも安心して働ける環境作りの一環として、弊社では「子どもの看護休暇」という制度を設けています。 1年に10回まで、未就学のお子さんの看病に使うことができるという有給の特別休暇です。

…という採用PRなのですが、弊社では子の有無、婚姻の有無に関わらず多様なバックグラウンドのメンバを絶賛募集中です。 よく聞かれるご質問なのですが、家族の幸せを生み出すあたらしい社会インフラを世界中で創り出そうとしている弊社においても、多くの独身社員が活躍しています。

多様な「家族」のあり方に寄り添い、毎日少しずつ働きやすい環境にしようとがんばっていますので、ちょっとでもユニファでの仕事に興味がある方はぜひぜひお気軽にお声がけください。

unifa-e.com

さて、本日のタイトルは前回の検討の数理に続く「決め方の数理」第2弾、勝率の数理(AND編)です。
まさか本当に書く日が来るとは。

テーマとしてはざっくり「なぜ戦略はシンプルでなければならないのか？」という問いについて考えてみる形で進めていこうかな、と。
(迷い迷い、手探りで書いてます)

Rails 7.0で追加予定のenumerate_columns_in_select_statementsを試してみる

こんにちは、最近柴犬の動画ばかり見て癒されているWebエンジニアの本間です。 いいですよね、柴犬...。ああ、今日もお仕事終わったら見よう（メンタルは全く問題ないのでご安心ください）。

さて早速なのですが、y-yagiさんのブログの2021-04-17のエントリで紹介されていたpull requestで1つ気になったものがありました。

github.com

このpull request、初めは内容がよくわかりませんでした。 ただ内容をよく確認すると、これまでPostgreSQLにカラム追加を行った際、たまに発生するPreparedStatementCacheExpiredエラーを抑制できることがわかりました。 今回、本当に効果があるのか試してみたいと思います。