Unifa プロダクトデベロップメント本部 副本部長の西川です、こんにちは。
今日は予告通り、前回決め方の数理2:勝率の数理(AND編)の続きです。 テーマは、「ORはANDよりも強し。だが……」です。
こういう思わせぶりなテーマにつられ、長文記事をつい最後まで読んでしまう…
そんな好奇心旺盛なあなたのご参画を、Unifa一同、絶賛お待ちしております!
(という採用PR)
Unifa プロダクトデベロップメント本部 副本部長の西川です、こんにちは。
今日は予告通り、前回決め方の数理2:勝率の数理(AND編)の続きです。 テーマは、「ORはANDよりも強し。だが……」です。
こういう思わせぶりなテーマにつられ、長文記事をつい最後まで読んでしまう…
そんな好奇心旺盛なあなたのご参画を、Unifa一同、絶賛お待ちしております!
(という採用PR)
こんにちは。 午睡チェックのディレクター/スクラムマスターをしている保坂です。社内にいるころは、近くにいる人が今コーヒー飲んでるなとか、なんだか集中してるなとか、何をしているか把握できました。一方リモートワークになると、気軽に話すことも少なくなり、お互いの理解するチャンスも無かったりします。まして、入社してから日が浅いと誰に話しかけて良いのか分からないこともしばしば。。
続きを読むこんにちは、データエンジニアリングチームの宮崎です。
少し今更ですが、最近SageMakerにオリジナルのTensorFlowモデルをデプロイできることを知ったので試してみました。 (これまでSageMakerで学習したモデルしかデプロイできないと思っていました…。)
以前、コチラの記事でAWS Lambda上にTensorFlowモデルのデプロイについてご紹介しました。 しかし、AWS Lambdaですとコールドスタート時は応答に20秒前後かかり、応答速度が求められるタスクには辛いところがあります。 また、常に多数のクライアントから推論リクエストがくるケースにも不向きです。 そういったケースはTensorFlow Servingが良さそうですが、ECSにデプロイしようとすると、ロードバランサなどの設定も必要で少々面倒です。
そこで今回は、マネージドでTensorFlow ServingをデプロイしてくれるSageMakerを用い、オリジナルのTensorFlowモデルをデプロイしてみました。
続きを読むこんにちは、プロダクトマネージャーの田嶋です。
はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト(以降「Rプロジェクト」)において、遅延なく開発を進められたことのプチ自慢です🎉 笑
週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています!
続きを読むこんにちは!サーバーサイドエンジニアの柿本です。
ユニファは5月の末に本社を飯田橋へ移転しました!
開発本部はコロナの影響もあって原則リモートとなり出社をする人数が激減していたため、移転を機にフリーアドレス化されました。
そして全員が出社することは当面なさそうなので、座席数も全員分は確保されていません!開発本部は50名近くいますが、座席数は28席です。
そこで、1つの不安の声が出ました。
仮に全員が出社しちゃったらどうなるんですか?
ですよね。わかります。不安な気持ち。
ですが、普段オフィスに出社しているのはせいぜい3名程度です!なので杞憂です!心配無用です!!
しかし、不安な声がある限り、開発者たるもの無視するわけにはいきません。
座席の予約システムを作ったらいいのでは?
それだっ!!
ということで Hackathon を開催しました。
続きを読むこんにちは、プロダクトエンジニアリングのちょうです。最近天気は暑かったり、寒かったりするので、体調管理に十分気をつけてください。さて、サービスが増えるにつれ、元々大きなサービスをマイクロサービス化するのは珍しくありません。そんな中で、一つ大きなサービスのデータアクセスをデータベースからリモート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のモデルはすくなくともこのような役割があります。