でご紹介したGo言語でのgRPCコード生成の状況の続報(2020年末)をお伝えしたいと思います。 概要としては前回の記事に記載した通りで ・Protocol Buffer側のレポジトリは golang/protobuf から protocolbuffers/protobuf-go に移行 ・gPRC側のレポジトリのgrpc/grpc-goに新たにprotoc-gen-go-grpcコマンドができた なのですが、以下が追加になりました。 ・gPRC用のコードを生成するには Protocol Buffersのメッセージやシリアライズに protocolbuffers/protobuf-go のprotoc-gen-go、gPRCのサーバ/クライアントに grpc/grpc-goのprotoc-gen-go-grpc、と両方を使うことになった 以降で詳細をご紹介します。 経緯2020年3月のpr

電通デジタルでバックエンド開発をしている平沼です。 私は、4/1(水) に電通デジタルに中途入社しました。初日のオリエンテーション以降、入社 2 日目から今までリモートワークをしてきた中で感じたことをお伝えします。私としては、このままリモートワークが続いてもよいと考えています。 入社までの話私は、前職までは SIer として仕事をしており、今までリモートワークをしたことはありませんでした。プロジェクトでは、Mattermost という Slack ライクなチャットツールを立ててやり取りをすることはありましたが、基本的にはメールや対面での打合せがほとんどを占めていました。 今回転職するにあたって、入社直前までフルリモートワークになるということは全く想像していませんでした。弊社は、働き方改革を推進しており、そのなかでリモートワークの導入を計画していたことから、新型コロナウィルスの影響下でも比較

電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。 先日(8/5)に7/22開催のAWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料が公開されました。 資料中では以下の内容を説明しています。 ・AWSではアカウントに個別のIAMユーザを作成してログインする代わりに、IDプロバイダ(IdP)を使用し、シングルサインオンができること ・シングルサインオンは組織に独自のID基盤がある場合や、複数のAWSアカウントを使用している場合に有効であること ・シングルサインオンの実現の方法にはいくつかパターンがあり、運用をふまえながら何を選択するのがよいかであること 弊社の自社開発部署もAWSをマルチアカウント構成-シングルサインオンで運用しています。今回はその事例を上記資料の選定パターンチャート

こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様

帰ってきた optional - Protocol Buffers v3.12 から Field presence が導入 電通デジタルでバックエンド開発をしている齋藤です。 今回は Protocol Buffers v3.12 のリリースで追加された Field presence 機能について調べたことをご紹介します。 前提：v3.12 以前の Protocol Buffers v3 における optional な値の扱いProtocol Buffers v3 (proto3) では v2 (proto2) にはあった optional ながなくなり、optional を扱うにはひと工夫必要でした。加えて、Message の Filed に値を入れなかった場合は、Fieldの型のディフォルト値が送られてきたとみなす仕様になっています(各型のディフォルト値はこちら)。 そのため、開発者は

電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryでUplift Modeling分析を行うための方法について紹介します。 広告効果を上げるためには？ 広告効果とは、広告に接触した場合と接触していない場合とのその後のコンバージョン（CV）の差である、と言えます。 介入が無作為に割り当てられるランダム化比較試験（randomized controlled trial, RCT）において、広告効果は平均処置効果（average treatment effect, ATE）として推定できます。 詳しくは過去記事[1]にまとめています。 Uplift Modelingは「広告施策において、その効果を上げるためには誰を広告配信対象とするべきか」を推定するための方法です。 ユーザーの特徴量を 𝐱𝑖 とすると、Uplift Scoreは下記のように算出されます。 Up