FANCOMI Ad-Tech Blog

株式会社ファンコミュニケーションズ nend・新規事業のエンジニア・技術ブログ

CTR予測と精度向上をやってみた

初めまして、8月5日より5日間インターンでお世話になっている安村です。
今回、業務で蓄積された実データに触れてみたい!アドテク業界を知りたい!という思いでインターンに参加させていただきました。

1日目

午前は入社手続きや事業内容についてのお話や、社内案内などがありました。
午後からはインターンでの目標を設定し、本格的に業務が始まりました。
初めに頂いた入門資料をもとに、データベースからのデータの取得からロジスティック回帰を用いたCTR予測までの一連の流れを学びました。
この時、業務で蓄積された実データを扱えることにワクワクしつつ、1億行もあるデータに圧倒されていました。。。

2日目

学習データの傾向を掴むためにデータの可視化などをしていました。
ある特徴量において出現頻度に偏りがあることを発見し、説明変数が無駄に多くなっているのでは?などと精度向上のアイデアを考えていました。

3日目

説明変数が多くなっている問題があったため、ロジスティック回帰の代わりにLasso回帰を用いて学習を行ってみました。
学習データは5週間前から1週間前のデータ、テストデータは直近の1週間のデータを使用しています。また、データは不均衡データ(ほとんどクリックされない)であるので、学習データはダウンサンプリングしています。
下の表はテストデータにおけるロジスティック回帰とLasso回帰の評価指標を比較したものとなっています。

AUC LogLoss NE ECE
ロジスティック回帰 0.6862465 0.0285730 0.9784192 0.1156183
Lasso回帰 0.6375969 0.0290539 0.9948855 0.1114336

ECE(期待カリブレーション誤差)とは、予測確率と実際のクリック確率の誤差を間接的に表したものとなります。CTR予測では、クリックの有無の予測よりクリック確率が重要視されています。
実験結果より、AUC・LogLoss・NEの誤差が増加したもののECEが小さくなっていることより、CTR予測の精度が向上していることがわかります。

また、お昼にはピザランチがあり、エンジニアの方々とキャリアなどのお話が聞けて、非常に有意義な時間となりました。

4日目

他のモデルでも試してみようと新たにSGDにて学習を行いました。

AUC LogLoss NE ECE
ロジスティック回帰 0.6862465 0.0285730 0.9784192 0.1156183
Lasso回帰 0.6375969 0.0290539 0.9948855 0.1114336
SGD 0.6377311 0.0290611 0.9951336 0.1097917

Lasso回帰より精度が向上しました!

また、学習させている間にもデータの分析をしており、下図のように曜日によって学習データとテストデータのクリック数の分布に偏りがあることを見つけました。
テストデータの木曜日に急激にクリック数が増加していことがわかります。この日は8月1日で学生が休みに入ったため分布に偏りが出たのかもしれないなどと色々と考えていました。

f:id:r_yasumura:20190809184119p:plainf:id:r_yasumura:20190809184057p:plain

5日目

最終日の午前は、曜日によるクリック数の分布の違いについての検証を行いました。
新たに6月のデータを取ってきてSGDで学習させた結果が以下の表のようになります。

AUC LogLoss NE ECE
SGD (学習期間 : 7月) 0.6377311 0.0290611 0.9951336 0.1097917
SGD (学習期間 : 6月) 0.6375969 0.0290539 0.9948855 0.1004191

ECEの精度が向上していることがわかります。このことから、学習期間とテスト期間の特徴量の分布の違いが精度の悪化に影響していたと考えられます。

午後は、カリブレーションの改善方法であるProbability calibrationについて調べていました。
下記はその簡単なまとめとなります。

カリブレーションの改善について

Probability calibrationには主に二つの手法があります。

  • Platt Calibration
  • Isotonic Regression

ここでは、Isotonic Regressionによるカリブレーションの改善について説明します。

Isotonic Regression

Isotonic Regression(単調回帰)とは、あるデータに対して非減少関数を適合させるモデルのことです。
入力値f_iから予測値y_iを推定する式は以下のようになっています。
f:id:r_yasumura:20190809190113p:plain
ここで、mは単調増加関数です。
Isotonic Regressionの学習では、データに適合する単調増加関数mを求めることとなっています。

f:id:r_yasumura:20190809190256p:plain
[引用] : 1.15. Isotonic regression, https://scikit-learn.org/stable/modules/isotonic.html>

カリブレーションプロット

CTR予測では、クリックの有無(0/1, 目的変数)があるものの、クリック確率(真の予測値)は未知となっています。そこで、カリブレーションの評価方法としてカリブレーションプロットを用います。
カリブレーションプロットは、あるモデルからの出力結果を複数のグループにまとめ、グループ内での予測確率の平均と実際のラベル比率をプロットしたものです。対角線に近いほどカリブレーションが達成されていることを示しています。
また、カリブレーションの改善では予測結果を対角線に近づけるための処理を行います。

f:id:r_yasumura:20190809190939p:plain

Isotonic Regressionによるカリブレーションの改善

Isotonic Regressionによるカリブレーションの改善では、上記のグラフにおける予測確率の平均値を入力値f_iとし、実際のデータのラベル比率を出力値y_iするようなモデルの学習を行います。
これによって、あるモデルから出力された予測確率をIsotonic Regressionによって実際のデータのラベル比率に近づけることが可能となります。

参考文献

[1] Alexandru Niculescu-Mizil, Rich Caruana, "Predicting Good Probabilities With Supervised Learning", Appearing in Proceedings of the 22nd International Conference on Machine Learning, Bonn, Germany, 2005.

おわりに

今回が初めてのインターンで色々と不安を感じていましたが、メンターの片桐さんや内田さん・長田さんのおかげで楽しいインターンとなりました。本当にありがとうございました!
また、データ分析をしていく上でもっと技術があればもっと面白いんだろうなと思うことが多々あり、今後より勉強していきたいと思いました。

1週間お世話になりました!

新規サービスインターンに参加しました!

5日間新規サービスインターンに参加させて頂いた高橋です。
インターンでは、Nuxt.jsを使用して開発を行いました。

スケジュール

1日目 インターンの手続きと新規サービスの説明

午前中はインターンの手続きと説明を受けました。
午後からは新規サービスの説明を受け、何の技術で開発を行うのかを検討しました。
私は、普段からNuxt.jsを使用する機会が多く、また、配属された先でもNuxt.jsでよく開発しているとのことだったので、Nuxt.jsで開発することになりました。
支給されたPCの環境を整え、Nuxt.jsの環境をGitHubのリポジトリにあげました。

2 ~ 4日目 新規サービスの開発

2日目から新規サービスの画面の作成が始まりました。
午前中は必要なライブラリなどを調べました。
2日目から毎日12時から朝会(昼会ではない)を行いました。朝会では今日やることだったり、UIや機能面での疑問点などを出し合ったりしました。発言もしやすく、チーム一体となってサービスを作っていくことを体感しました。
午後からは画面の作成を開始しました。
認証にはFirebaseを使用しました。Firebaseを使用したことがほとんどなかったのでidTokenを取得するのに時間がかかりました。また、GAEにデプロイもしました。

3日目はFirebaseから取得したidTokenをvuex-persistedstateを使用してログインの永続化を行いました。Local Storageは使用したことはありますが、Cookieを使用したことがほとんどなかったので色々と調べながら開発を行いました。また、トップ画面も作成しました。

4日目はmiddlewareを使用しログイン画面へリダイレクトさせるように実装しました。middlewareもほとんど使用したことがなかったので、Nuxt.jsのライフサイクルや、どういう処理を行うのかを調べながら開発を行いました。
また、詳細画面も作成しました。詳細画面ではリロードをするとデータが消えてしまうため、nuxtServerInitを使用し、リロード時にAPIを叩くようにしました。

5日目 退社手続きとフィードバックとデプロイ

5日目の午前中に退社手続きをしました。もうインターンが終わってしまうのかという寂しさを感じました。
午後からはnuxtServerInitの修正をし、次にマイリストを作成しました。最終日は手続きなどで時間があまりなかったですが、トップ画面と詳細画面で使用したコンポーネントを使用したのでなんとかマイリストを作成することができました。
メンターの方からフィードバックを受けました。貴重な意見が聞けたので、今後に活かしていきたいです。
最後に自分の作成したものをGAEにデプロイし、インターン終了です。

感想

今までNuxt.jsで開発を行っていましたが、認証周りはあまりやってこなかったので技術力が上がった気がします。また、FirebaseやGAEなども触ったことがほとんどなかったので、いい経験になりました。
昼食時は、色々な部署の方と話す機会を設けて頂き、貴重な話を聞けたこともよかったです。
新規サービスのインターンは私が初めてだったことを知り、驚きました。
実際の業務を通して、やりがいを感じました。仕事の楽しさが少しわかった気がします。

1週間あっという間でしたが、内容の濃いインターンになりました。

ミニDSP構築インターンに参加してみた

インターンに参加したs_kakimotoです。最終日のタスクとしてブログ執筆が設定されていましたので記入します。
検閲により削除されないよう注意しながら書きたいと思います。

概要

  • 株式会社ファンコミュニケーションズさんのインターンに参加した
  • 開催地は東京オフィス
  • 5日間
  • いくつかコースがあるが自分はミニDSP構築コース的なものに参加した
  • 有給

自己紹介

アルバイトで生のPHPを書く生活を2年ほどしていたこともありこのコースとなりました。
サポーターズさん主催のマッチングイベントにて社員の長田さんとお話をさせていただき、そこで伺ったインターンに参加という流れです。

タスクについて、やったこと

お給料がでると聞いていたのでガッツリスキルを求められるかと身構えていましたが、このコースで実際渡されたタスクは既存業務に影響を与える訳ではなく、むしろ新人研修的な印象を受ける内容でした。
5日間の課題として渡されたものは以下のような要件を満たしたDSP(APIサービス)と呼ばれるものの実装です。

  • PHPをベースに使う(最終的に1/3ぐらいはJSで書いたけど)
  • POSTリクエストを受けてJSONレスポンスを返す
  • 3つのAPIエンドポイントを用意して、それらに処理を実装する
  • それぞれのリクエストとレスポンスは指定されたJSON形式でログとして保存する、保存先は自由
  • レスポンス時にMLと呼ばれる別サービスで導出された広告価格決定処理を行う、このMLとメインAPIは疎結合にして、ホストを分ける
  • 目標レスポンス時間100ms以内

DSPが何かということについては各自ggってください。
レスポンス100msの性能要件で泣きをみることになるのですが、それは後述します。

使った技術

PHP

後述するDockerで諸々を担保しました。ちなみに7.3をベースイメージに使いましたが、実業務で生きてるサービスのPHPバージョンは自主規制*1らしいです。つらい。

Laravel

唯一使ったことがあったPHPフレームワークなので用いました。ルーティングとかDB接続やマイグレーション/シーディングを楽にしたいな〜と思って脳死で選んだのですが、ローカルで動かしたらレスポンス1000ms(10倍)とかかかって泣きました。デプロイ環境では多少ましになったものの150msぐらいかかってました。
クエリ発行の効率が悪いだろうなーと思いつつ完成重視で実装してしまったのが原因です。

Docker

正直よくわかってないまま使うことに決めたのですが、ちょうどいい機会だと思って普通に使えるレベルにできるよう勉強しました。
デプロイ先とローカルとでいい感じにサービス立ち上げようとするならポートフォワードとか概要を覚えておくとよかったです。
一番技術面で成長できた分野と思います。Docker最高!🐳🐳🐳

Express / Node.js

正直よくわか(略)
MLとして使うことにしたJSフレームワークです。なるべく楽にAPIをぶち上げたかったので選んでみました。ぶっちゃけここがボトルネックの可能性も否めないのですが、デプロイ先環境のログをみたら0.4msとか書いてて禿げそうになりました。ほんまか?

MySQL

脳死で選んだ。遅いっぽい。というかメンターさんにはNoSQL使わないとスピード出せないっす的なこと聞きました。

Nginx

PHP(Laravel)を動かすWebサーバーとして使いました。普段Laravel使うときは php artisan serveとかApacheとか使うんですが参考にしたページでNginx使ってたのでそのまま使いました。Nginx.configをなんとなく把握できてよかったです。
ちなみにちょっと前までンギンクスって読んでました。

Makefile

バイト先で先輩社員が「docker-compose upとかbuildとかrun php bashとか打つの長いからエイリアスみたいなの用意したで!」って経緯で知ったので作ってみました。ローカル開発時は大変便利だったのですがデプロイ先AWSではコマンドが用意されてなくて直打ちしてたのでつらかったです。

AWS

AWSを公開テスト用に用意してもらいました。
中入って操作するのは問題なかったのですが思った以上に何も入ってなかったのでDocker使っててよかった〜ってなりました。Docker最高!🐳🐳🐳

Git / GitHub

一応privateにしてねって言われたのであんまりガチガチに環境変数保存しないようにとか意識しなくても良さそうでしたが、最低限clone, commit, push, pullはできる方がいいよね〜って感じの空気感でした。
他のコースはもっとプルリク駆動してるっぽい声が聞こえてきましたが。
インターン終わった後も継続して使ったりしてしっかり覚えようね!(戒め)

性能要件について

LaravelをDockerで立ち上げてNginxでサービスするんですが、普通にめっちゃ時間かかるのでつらかったです。隣のI君は生PHPの実行でサービスしてたんですが、そっちはAWS環境に乗せて40msとか出てるらしくて無力感というのを味わいました。
正直令和時代にレスポンススピードとか意識して開発することないやろとか思っていたのでいい刺激になりました。

つらかったこと

  • 初日からになりますがMacの操作がわからなくてつらかった。

- Macのターミナル見辛い
- 日本語の変換がトリッキー

  • GitとかVScodeの設定を完璧に普段と同じにできなくてつらかった。

- 貸与PCなので仕方ないです。

  • 普段のノリでノートPC担いで出社して、一切使わず持ち帰る生活でつらかった。

- 特に不要とも書いていなかった気がするので持ってきたが1.2kgの筋トレをするだけになった

主にMacが悪い買おうか割と迷ってます

その他

オフィス環境について

青山学院の近くにオフィスがあるんですが、まさか2拠点あると思ってなくてメールの「ここにきてください!(地図のリンク)」の指す場所とそのメールの署名欄に書いてる本社ビルの住所も建物名もズレてるな〜と思いながら初日は本社に向かいました。
もうお分かりかもしれませんが地図リンクが正しくて、そっちでみなさんをお待たせしてしまいました。初日から遅刻をやらかすという悪い例です。
主に作業するフロアはバスケットコートを横に2面あるかないかぐらいの広さで、それが2フロアと本社のビルという感じでした。
休憩スペースがまあまあ広くて、デロンギのエスプレッソマシンとか給茶機とか、あとモンエナ170円の自販機とか無人コンビニの小さいやつみたいなのがあります。無人コンビニは小腹空いた時とかにちょうどいい感じの品揃え+冷凍食品とかカップ麺とかもあるので外出たくない時も食事できるな〜って感じです。

デスクについて

案内されたデスクにはMacBookPro15”が置いてて貸与されました。キーボードがペチペチじゃない一つ前の型のなので神でした。その他23”の外部モニターも使えましたし、デスクは驚きの電動昇降でした(!)  これが””””人権””””なのか。。。?

日本酒会

なぜかインターン期間中、終業後に日本酒を持ち寄って休憩スペースで飲むという集まりがあって、
なぜか気づいたらご相伴にあずかっていて、
なぜか日本酒もワインもおつまみも、あと机の上にあった(苦手なはずの)ウイスキーや芋焼酎まで口に入れていて、
なぜか終わって気づいたら二次会のチャーハンの食券をいただいて食べてました。ごちそうさまです。

今後インターン生で日本酒会に興味があるひとはご注意ください。

まとめ

初めてのインターンでしたが、最初の課題説明で大体の構成をイメージできる難易度感とタスク量で、無事作りきることができてよかったです。
タスクの難易度については各コースやチームによって変わると思いますが、その辺りは他の参加者の記事を参照してもらえると嬉しいです。
大企業(規模的に)に新卒で入ることについては消極的だったのですが、こういう働き方や空気感の大企業もあるんだな〜と知ることができました。
技術的にもDockerやAWS、Expressなど触ったことの少ない技術も使ってフィードバックを得ながら開発できたのでとてもよかったです。

ありがとうございました!

*1:載せ替えようと頑張っていらっしゃるみたいです

楽しいインターン SSP

おはようございます!!
3月25日から29日までの5日間インターンシップに参加させていただきました瀬川です。
楽しいインターンです!!
もう一度言います。楽しいインターンです!!

内容

Mini-SSPサーバの開発

1週間の振り返り???

1日目(初日)

初日ということもあって、入社書類等の提出書類の処理、社内見学?探検?、アドテク(DSP,SSP等について)の説明などなど。
自分はもともとSSP、DSPに興味があったのでSSP、DSPがどういうものかある程度知っていましたが、丁寧にDSP、SSP等について説明していただけるので全く知らない人でもわかりますし、自分も詳しいところまでは知らなかったので、詳しい中身まで理解して開発を行えます。 そのあとMini-SSP開発にあたって、言語選択から開始(ここで8~9割1週間の苦しみ具合が決まる)。
残り時間もあまりなかったので、残りは環境構築が主でした。

環境

OS - CentOS 7 (Centかubntでどちらでもいいと伝えたら、Centになった)
たぶん言えば別のOSでもやらせてくれるじゃないかな?・・・知らんけど

言語 - Scala (2.12.7) (最新版を使いたくないある程度安定版使いたい派なので、バージョンがちょっと古いのは許してくだせう) Scala触ったことなかったので挑戦を兼ねてScalaを選択

ビルドツール? - sbt (1.2.8)

エディタ - emacs (宗教戦争をするつもりはないです・・・でも、emacsのほうがいいですよですよね?)

のちにこのemacsが悲劇を生むことをこのときは知るよしもなかった・・・

[オススメ言語一覧]

  • c++
    dspとかssp用のライブラリーがある。並列処理をそのライブラリーでやってくれるので脳死で書ける。処理速度も早い。C++使ってる会社もある。
  • scala
    純粋に並列処理(リスト処理)が楽。処理速度も早い
  • python
    簡単に書ける。処理速度は遅い。
  • golang
    ゴルーチンは神。ゴルーチンとチャンネルのおかげで並列処理楽。処理速度はそこそこ速い。
  • Rust
    並列処理がいいんじゃない?・・・知らんけど
  • erlang
    並列処理向けの言語だから並列処理に向いてる。erlang使ってる会社も多い。
  • Assembler !? 高速通信ならアセンブラでしょ??できるのかわからないけど・・・
  • nginxモジュール !? Webサーバ本体が処理したらそっちのほうが早いに決まってんじゃんwww(誰もやらないだろう・・・)
  • Shell オススメはしてない。できそうだけど、速くはないと思うよ・・・ でも、誰かやってみてほしい。。。

余裕ある人は変わった言語で試してもらいたいなぁ|ω・`)

2日目

実装内容の確認

SDK -> SSP -> DSPの流れでリクエストが送られる。
そのレスポンスとして、DSP -> SSP -> SDK で送られる。

f:id:fan_h_segawa:20190411183414j:plain 

scalaが初めてで、sbtも初めて・・・
sbtのことをよくわかっていなかった。

とりあえず、リクエストを受けて、レスポンスを返すというものを作ったが・・・
ライブラリのエラーでずっと動かない!!
でも、コンパイル時ではエラー出てない!?
ずっと試行錯誤を繰り返していた。。。

3日目

ライブラリーのエラーで動かないという話をScalaのできる人に聞くと・・・
ででーん!!!!!!!!!!!!!
そもそも実行コマンドが間違っていた!!

sbt はコンパイルするためのツールと思っていた私( ́・ω・ )
sbt compileでコンパイルしたあとにsbt run で実行するんだってさ(;´Д`)
sbt compileでコンパイルしたあとに scala hogeで実行しようとしてた。。。
scala hogeでもできなくはないが、ライブラリをsbtで用意しているから当然scalaのライブラリの方にはないよね・・・
当然といえば当然なんですよね・・・

とりあえず、リクエストが送られて来るとレスポンスを返すようにできた。

4日目

3日目までに単一の処理しか実装できていないため、SDK,SSP,DSPで流れるようにしようとしたら、関数の使用時に別の関数を使用しろとエラーが起きていたが・・・

エラー内容がよくわかん( ́・ω・ )

時間かかっても自分で限界まで考えたいマンの僕は無駄に時間を消費した。。。(ただコミュ症なだけ)

そうここでemacsでの悲劇だったのだ。
ここまでサーバ上の素emacs(no package)でやったきたため、どれが関数かパッとわかりにくいのである!!

結果、IntelliJで開発することにした(最初からそうしろ!!)

IntelliJで書きだしたら、見える見える関数がどれか見える!!!!!!!!! コーディング速度がめっちゃ上がった。

Javaはやってたが、eclipseでやってたので知らなかったがIntelliJめっちゃいいね♥ ここまでScalaが嫌いになりかけていたが、なんとか持ちこたえたのである。

5日目(最終日)

IntelliJのおかけでなんとかSDK->SSP->DSP->SSP->SDKと流れるに動作するよにでき、 複数台DSPに対して、リストで処理するようした。 でも、残念なことにDSPからのレスポンスをSSPで受け取り、1位のDSPに勝利報告をするところがよくわからず時間内には実装しきらなかった・・・・・(帰って自宅鯖で完成させた)

感想

昇降机など自分にあった物理的開発環境を整えることができるのは長時間働く上ですごく大事だなと思った。高さがあってなければ、腰や首、目などに多大な影響を与えるため働き安い環境であると思った。 ただ、正直オフィス内の温度は暑かった・・・・ 大体のオフィスがそうなんだろうが、夏は寒く!!、冬は暑い!! ここだけは本当に辛かった。 ただ、それ以外に不満はなく本当に自由にできる最高のインターンでした。 ありがとうございました!!!

GoでSSP構築をやってみた

こんにちは。
3月25日〜3月29日までの5日間、インターンでお世話になりました澤です。
9月にもSDKインターンでお世話になりましたが、今回またお誘いをいただき、今度はSSP構築インターンに参加させていただきました。

課題

課題は、SSP(Supply Side Platform)を構築するというものでした。
よくWebサイトを閲覧したり、スマホでゲームをやったりする時に広告が出ていると思います。
Webサイトにその広告を配信しているのがSSPです。

簡単に言えば、SSPとは、Webページに広告を掲載したいという時に、いい感じに処理して、広告を配信してくれているサーバのことです。

前回、SSPやDSPに関する説明を受けた時に、アドネットワークの世界にはこんな物語があるのかと感動した記憶があるので、今回SSPというアドネットワークの一部に触れることができる課題で非常に楽しみにしていました。 

5日間の流れ

1日目

いくつかの書類を書いて、会社についての説明を受けました。
そして、今回の課題についての説明を受け、課題をスタートしました。
僕自身サーバサイドのプログラムの経験は乏しいのでとても不安なスタートでした。
どの言語で書くかを自由に決められたので、Goを使うことにしました。
理由としては、
・比較的速度が速い
・並列処理に強い
・ライブラリなどが充実していて書きやすい
というのが主な理由です。

ネット上の記事を参考にしながら、何となくですが触りの部分は実装することができました。

2日目

Go言語を書くのも初めての経験だったので、非常に苦戦しました。
 
例えば、このような構造体があったとします。
 

type DSPRequest struct {
	ssp_name     string
	request_time string
	request_id   string
	app_id       int
}

何とこのままでは、他のパッケージからアクセスすることができないのです。
他のパッケージからのアクセスを有効にするには、以下のように要素の初めの文字を大文字にしないといけないのです。

type DSPRequest struct {
	Ssp_name     string
	Request_time string
	Request_id   string
	App_id       int
}

Javaのようにpublicをつけるという訳ではないので、知った時は目から鱗でした。
これに気づくのに2,3時間かかってしまい、非常に痛いミスでした。

SSPの話ではなくGo言語の話になっていますが、Go言語の仕様に悩まされつつSSPの構築を進めました。
サーバサイドのプログラムだけでなく、Go言語の学習にも繋がったので良かったです。

3日目

SDKからSSPにアクセスし、SSPからDSPに広告を要求し、その結果である広告のURLをSDKに返すという一連のSSPの処理を完成させることができました。

Goもサーバサイドも初めてで苦労しましたが、何とか形にはできて嬉しかったです。

ソースコードが読みづらかったので、少し綺麗にしようと試みました。
しかし、結果10行程度の削減にしかならなかったので、もう少しコンパクトに書けるように訓練していきたいと思いました。

4日目

この日はローカルの環境ではなく実際のサーバ上で動くかどうかを確認しました。
結果、サーバ上でも動作したので良かったです。

また、DSPから100ms以内に返事がもらえないときにタイムアウトする処理の実装を忘れていたので実装を行いました。
しかし、タイムアウトの実装が非常に難しく一日行いましたが、終わりませんでした。
ネット上で色々探して、実装してみましたが、どれも上手くいきませんでした。

やっぱりGoはあまり好きではないと感じたので、時間があれば他の言語でも書いてみたいと思いました。
(あるいはサーバサイドのプログラムが好きではないのかもしれない)

5日目

引き続きタイムアウトの実装を続けて、昼前には何とかそれっぽいものが完成しました。
良いか悪いかは別として、チャンネルを使いこんな風に(取得する値の数次第では、修正する必要あり。)書いてみました。(全体像はこちら

ch := make(chan string)
for i := 0; i < 1; i++ {
	go func() {
		Request_id, Url, Price, err = communicateDSP(url, dspRequestJson)
		ch <- "ok"
	}()
}

// タイムアウトを設定する
timeout := time.After(100 * time.Millisecond)

for i := 0; i < 1; i++ {
	select {
	case result := <-ch:
		fmt.Println(result)
	case <-timeout:
		err := errors.New("timeout")
		return "", "", 0, err
	}
}


書いたものの、不安定なので、それからもどうしたらいいのだろうかと考えてました。
負荷をかけてみても結果はよくありませんでした。

色々後悔することはありますが、レビューをいただいて、ブログを書いてインターン終了しました。

まとめ

今回、実装したコードはGitHubに公開しているので興味のある方は是非ご覧ください。
github.com

初めてGo言語を触ったので言語仕様にもなれず非常に苦戦しましたが、良い経験になったと思います。
また、サーバ構築を本格的にしたのも初めてだったので勉強になりました。

時間がなくて取り組めなかったことや後悔していることとしては、

・捌けきれない量の通信が来てもいいように作成したプログラムの前にnginxなどを置くこと
・コードが綺麗ではなかったり、無駄なところ多かったりしたので綺麗に書きたかった
・もう少しサーバサイドの知識やGo言語の知識を身につけてインターンに臨みたかった
・英語が苦手だが、英語から逃げずに英語の文献やページも読んで実装したかった
・分かりやすいログを出してどこで詰まっているのかを明確にして取り組むべきだった

といったところです。

最後に

インターンを受け入れてくださり、ありがとうございました。
会社の雰囲気もよく、非常に過ごしやすい1週間でした。
特に机の高さが自由に変更でき、立っても座っても作業できるのは新鮮で良かったと思います。

メンターのy_kawasakiさんをはじめとしてサポートしていただいた社員の皆さんありがとうございました。

非常に楽しく自分のペースで進めていくことができたので、おすすめです。

F@Nのインターンに応募するか迷っているのなら、ぜひ応募することをおすすめします。

5日間という短い期間でしたが、ありがとうございました。