Gunosy Tech Blog

Gunosyの開発メンバーが知見を共有するブログです。

データ分析で可視化を行う際の注意点、AWS Dev Day、人工知能学会、データ分析とラジオ音質など gunosy.fm #4

こちらでははじめまして、かとうです。

これまで第4回までやってきたGunosyのポッドキャストですが、今回からこちらのテックブログに更新情報を載せることにしました。 なお過去3回分についてはこちらです。

今回はGunosyデータ分析部のおおそねさんにAWS Dev Day Tokyo 2017で発表して来た話、スポンサー出展したJSAI 2017、社内の〇〇警察、録音環境について話を聞きました。

ゲストのおおそねさんは過去の回でも録音環境の構築と収録を担当しております。このポッドキャストは「音質がいい」という感想をよくいただくのですが、その環境の話やこだわりについてもふれております。ぜひ楽しみに聴いてください!

トーク中に話題となったリンクは下記にまとめました。

Podcastの購読はこちらからお願いします。
また、感想や話題にしてほしいことなどはTwitterなどで #gunosyfm のハッシュタグでご意見お寄せください。
次回の更新もお楽しみに!

Go Conference 2017 Springにスピーカーとして参加しました。

こんにちは、新規事業開発室のエンジニアの高橋(id: @timakin)です。

先日開催されたGo Conference 2017 Springに参加しました。昨年度も個人的に参加したのですが、LT枠での参加でした。今回は通常トークの枠をいただけたので、もう少し長い時間発表者側として参加することができました。

発表内容

自分が発表した内容は以下のスライドです。プライベートでAPIを叩いたりウェブページをクロールしてくるサーバーを作っていて、途中経過ではあるのですが、その設計について話しました。

また、前回のGo ConferenceではGoogle App Engineの実用に関してのセッションが、大部分を占めていたのですが、自分は今回それを個人規模で使ってみたときの所感について話しました。

speakerdeck.com

他の方のスライドまとめをしようと思いましたが、すでにまとめをされている方のブログ記事がありましたので、こちらの記事をご参照ください。

通常トークとLTの内容で関連する部分も見られますが、どの内容も濃く、最新状況を追ったり、大規模な開発でGoを使う際のソースコード付きの資料が続々と出てきてまして、レアなので時間があるときにでも全体的に目を通したいものばかりです。

感想と今後の方針

他の方の発表内容では、今年はGoの標準パッケージとして採用されたContextの概説や、depによる依存解決、また個別にユニークなテーマでミドルウェアや言語処理系の成果物を持ち合って発表している方が多かったです。

そのため、今まで勉強会で見られた「現場で採用した結果こうなりました」「Goに入門しました」という内容から徐々に脱却し、Goの仕様へのキャッチアップや独自性の見られる発表の流行が感じられました。

個人的には業務でがっつりGoを書き始めたわけではないので、Contextの扱いもまだ不慣れですので、コードが拙い部分もあったのは反省だなと思います。

今後は社内のリポジトリ含めて、メジャーな企業のOSSで、大規模なAPIの元になっているリポジトリを参考に、プロダクションノウハウをどんどん吸収していこう、という刺激を得ることができました。

また、発表明けに出社した際には、弊社Gunosyの社内からも「Contextはこういう使い方にとどめておいたほうがいい」というような、インプットをすぐ受けることができて、Goのノウハウが潤沢に溜まった会社ならではのフィードバックが得られることを感じています。

現在Gunosyでは、Go/Pythonエンジニアの方始め、多方面で積極採用中です。Goのカンファレンスや勉強会での発表等も当然奨励されていますが、単純に使っているだけでなく、現場ノウハウがプールされているか、視点も含めて会社を選ぶとき、弊社をぜひご検討ください。

hrmos.co

広告技術部開発合宿に行ってきました

広告技術部で開発合宿しました

こんにちは、広告技術部のサンドバーグと星です。広告技術部では、入稿から配信まで一通り担当をしています。先日、いつも働いているオフィスを離れて伊豆半島・伊東で広告技術部の開発合宿をおこないました!

今回の開発テーマは、普段は忙しくて手を付けられていなかったタスクや、新規のプロダクト開発をすることでした。

進行中の作業を中断してまで、別のタスクに取り掛からなければいけない事態が起きるのは、技術者なら誰しもが経験したことがあると思います。 いつもの環境から物理的に離れることで、開発しそこねたタスクに集中できるのは、開発合宿の最大のメリットですね。

どこへ行った

伊東までは、東京から電車で1時間30分くらいの距離。宿泊先は、ホテル伊東ハーベストでした。IT健保を使えば安く泊まれてお得ですね。

この季節はまだ若干寒いですが、美味しい魚介料理と温泉などがじっくり楽しめる場所です。

f:id:cou_z:20170617173555p:plain

道中はチーム内で流行っているゲーム「Crash Royale」の対戦に夢中でした。マネージャーの淵脇さんがとくに手強いです。

f:id:cou_z:20170617173605p:plain

駅から15分くらい歩いて宿に到着!駅から宿までの川沿いの道は、春になると桜が綺麗に咲くそうです。

開発風景

到着してからは、ホテルの会議室を貸りてモクモクと開発!オフィスのデスクと違って、一人ひとり好きなスタイルで開発します。個性がにじみ出る開発風景ですね。

f:id:cou_z:20170617173614p:plain

合宿でのエンタメ

開発合宿は決して旅行ではありませんが、せっかく東京を離れてチームで過ごす機会を与えられたので楽しむのは当然。

開発の合間の楽しみといえば……やっぱりご当地グルメ!

f:id:cou_z:20170617173619p:plain

伊東の魅力は、美しい海と川。水産物のグルメスポットが豊富です!東京では食べられないような新鮮なうなぎが最高でした。伊東に行ったら、うなぎはMUSTハブアイテムですね。

f:id:cou_z:20170617173624p:plain

そして、一日中作業した疲れを癒やしてくれるのはやっぱり温泉。伊東も熱海に近いだけあった、温泉は当然最高です!

夜はゆっくり湯に浸かってチームメンバーと歓談して、部屋に戻って寝る。次の朝は、起きて徒歩一分のところが作業場。まさに夢の開発環境でした!

まとめ

f:id:cou_z:20170617173630p:plain

オフィスはオフィスでキリッとした環境で、集中して作業できますが、人に囲まれている分、いつ・どこからタスクが降ってくるかは想像ができません。 だからといって、完全に孤立した環境では、コミュニーケーションの量が減って、チームワークがなくなってしまう。

開発合宿は、集中とコミュニケーションのバランスをうまく取りながら、作業できる環境づくりに最適だと思いました。

新米エンジニアがRubyKaigiに行ってきました

どうも、新米エンジニアの広告技術部サンドバーグと新卒エンジニアの星です!

今回はじめてのRuby会議とあって、会議での情報量に圧倒されつつも自分がおもしろかった話をいくつかピックアップしてきました。

会場は京都

いつもは東京なのですが、今年の会場は京都でした。

f:id:cou_z:20170617173935p:plain

国際会館という自然に囲まれた場所でした。

f:id:cou_z:20170617173940p:plain

Keynoteはやっぱりこの人

最初はやっぱりMatzさん 僕も含め会場の全員がRuby3の話を期待していた通りメインはRuby3の話でした。今回は特に「型」の話が中心でした。

f:id:cou_z:20170617173957p:plain

MatzさんはRubyの今後の型が未来を示す新しいものになれば良いという話をしてくれましたが、我々Rubyistも Rubyがそういった他のプログラミング言語の先駆けになるようなものになってくれると嬉しいですね。

www.youtube.com

Ruby3: Sasadaさんの新しいconcurrency model

いきなりconcurrency modelの話に入っちゃいますが、今回のRubyKaigiはconcurrencyがとてもHOTなトピックでした。

Sasadaさん的にはConcurrencyを話すことにおいて, 言語のトレードオフ, 「パフォーマンス」vs「安全性・楽さ」が存在すると強調していました。Ruby3を考える中で、パフォーマンスを上げるために重要になっているconcurrencyを既存のRubyに当てはめると、あまりにもRubyが「楽」なためmulti-threadに対応しづらいと言うことでした。

Rubyのいいところでもあるmutableなオブジェクトはある意味制限がなく「楽」だが、そのせいでレースコンディション、デッドロック・ライブロックなどの問題が自ずと出てきてしまいます。ただ、「パフォーマンス」を追求するためにそれらをなくしてしまうとRubyではなくなってしまう!

そこで新たなコンセプト「Guild」が登場!

そもそもすべてのオブジェクトを対象に安全性を確認するのではなく、一スレッド単位でオブジェクトを保持すれば良いという、一階層上に行った考え。Guild同士はマルチスレッドを前提として作り、Guild内はそもそもマルチスレッドを許可せず、Guild間でオブジェクトを渡す際はそもそもオブジェクトを新しいGuildに受け渡すか、オブジェクトをimmutableな形式で読ませるかのどちらか。Guild内であれば以前と変わらず自由にmutableなオブジェクトがつかえ、マルチスレッドに対応する必要があるのであれば、スレッド単位でオブジェクトを保証する。

ふむ、、

コンセプト自体は思い浮かぶが実際に自分が使うところがいまいち想像できなかった内容でしたが、聞くだけでワクワクする内容でした!Ruby3の 3x faster を実現するには必要な拡張化かもしれませんし、そもそも multi-threadのプロセスに対応するには既存のRubyだと問題が発生しやすいと言うのも事実。

会議内では実際にSasadaさんがGuild間のコミュニケーションを可能にするためのメソッドなど具体的なところまで話していましたが、サマリとしてはこんなところです。

Sasadaさんプレゼン資料

Modern Black Mages Fighting in the Real World

こんな興味をそそられるタイトルの発表はTreasureDataのTagomorisさん

www.slideshare.net

過去の遺産と戦いながら色々な辛い話を、Rubyの黒魔術メタプログラミングで乗り越えたという内容でした。

弊社のシステムにもレガシーと呼ばれるものはあります。もちろんそのシステムがあったからこそ今の弊社があるのですが、メンテしづらいのも事実です。 それを必死に改善しつつ、新しい機能も加えるという仕事は尽きないものです。ただそういった環境だからこそ多くの学びがあったりします。

Railsを使っているとSQLを意識外において開発してしまうことがあります。 ActiveRecordは非常に強力で便利なライブラリですが、ActiveRecordが作るSQLを意識せずに開発することは危険です。 なぜなら、最適化されていないSQLを作ってしまう可能性があるからです。 そういったことを学べたのも、膨大なデータを扱うサービス開発に携われたからだと思っています。

SciRuby

続いては、MrknさんのSciRubyのお話。

speakerdeck.com

最近、機械学習すごく流行ってますよね。ただ、機械学習で用いられるプログラミング言語といったらPythonがほとんどだと思います。 そこで、Mrknさんを中心としてSciRubyという、Pythonで使える機械学習ライブラリをRubyでも使えるようにしようといった活動です。 もちろん弊社の分析チームでもPythonを使っています。しかし、我こそはRubyで分析したいんだという方がいらっしゃれば弊社でぜひ実現してみてください(笑)

DDD

もう一人個人的に注目した人が 2日目にいたスピーカー、Chis Arcandさん。

彼が話していたのはRuby3・Rubyというよりは、コーディング自体の話で、聞けば聞くほど実際に試したくなる内容でした。

その名も、「TDD」ではなく「DDD」

Delete Driven Development

内容自体は複雑なものではなく、ざっくり言うと「死んでるコードを積極敵に消そう!」でした。彼いわく、多くの死んでいるコードは「後々役に立つかも」メソッドや「このスペシャルケースのためだけ」メソッドの積み重で、基本的には探す手順も消す手順も大体決まっているということでした。コードを追加するだけでなく、なるべくレポジトリをクリーンに保ち、時にはコードを減らすだけのプルリクを出すのも良いのだと!

実際のコードの削除手順をざっくり説明すると、不必要なパターンをもつコードを探すためにコードを言語のようにパースし、消す条件に当てはまるメソッドをバンバン消していこうとことです。そして、このためだけに Arcandさんが不要コード削除用のgem 「debride」を用意してくれました。

ArcandさんのDebride

「debride」自体すごいライトに作られていてまだまだ未完成の状態ですが、すぐに導入でき、チューニングや拡張を前提に作られています。

そこで、実際の仕事に取り入れて試してみました!

Gemをインストールして指定ディレクトリーを選択・実効!

ドォーンといくつかメソッドが早速でてきましたが、なかなか消せるコードが出てこない… メソッドの中身を見ていくと「スペシャルケース」がいくつかあったが、なかなか削除に踏みきれないコードが多かったです。

f:id:cou_z:20170617174319p:plain

振り返ると「debride」に何か問題があったわけでもなく、単純にデフォルトの状態での「debride」をつかっても、明らかに消せるコードしか拾ってきてくらないことがわかりました。そもそも消す基準のコードは個人やチームでチューニングする必要があると思いますし、より高度なコード解析は「debride」のようなライトなgemではできないのだろうと考えました。

ただ「debride」を実際に使ってみて不要なコードや、コードの質のメトリックスを自動的に可視化してくれるツールがどれだけ仕事に貢献できるか考えさせられました。 「debride」を気に、ほかのツールをもっと積極敵に取り込み、無駄なコードをじゃんじゃんなくしていきたい気持ちが高まります!

speakerdeck.com

最後に…GunosyでRuby/Railsを一緒にやりませんか?

今回大きなRubyイベントの参加できて色々と学びがありました! f:id:cou_z:20170617174354p:plain 視野がまだまだ狭いことに気づいたのと、Rubyエンジニアでもいろんなタイプの人がいると実感できた気がします。 Rubyistの中には言語理論の変革から、文法的に正しい流れるようなコードを目指す人と様々ですし、より多くの違うRubyの形を見ていきたいと強く思いました。

GunosyではまだまだRubyを書く人が少ないですが、Rubyを活用して開発ができる環境がいっぱいあります!いろんな思想を持ったRubyistが集まればいいなーっと思うので、興味あったら是非Gunosyを見てみてください!

Gunosy - エンジニア募集

Gunosyエンジニアの他の活動はここで見れるよ!

Blog - Gunosiru

Blog - Gunosyデータ分析ブログ

Facebook - 株式会社Gunosy

connpass - Gunosy Development Div.

Qiita organizations - Gunosy Inc.

GunosyBeerBash#6 を開催しました

f:id:cou_z:20170617175151p:plain

こんにちは! 広報のおだんみつです。今日は、6月22日(水)に開催した勉強会【CyberZ×Gunosy】広告事業の最新開発事例とビールの会【AWS, Go, アドテク】の様子をレポートします。

GunosyBeerBash とは

Gunosyのエンジニアが主催する勉強会です。毎回テーマを設けて、親しい会社さんと共同で運営しています。 今回は、広告技術を展開しているCyberZさんのご協力で、広告事業の最新開発事例を発表しました。

2人のアドエンジニアが発表した

Gunosyからは、開発本部広告技術部の印南と會田の2名が登壇しました。広告技術部は「グノシー」に配信される広告のサーバを開発・運用するチームです。

1. 高速な広告配信サーバの作り方のコツ

www.slideshare.net

質問

Q: Gunosy広告サーバのリプレースは何人で進められましたか?

3-4人です。

Q: Ad Serverは何の言語で書かれていますか?

APIサーバがGo言語、バッチサーバがPythonで書かれています。

Q: Gunosyのアドチームとインフラチームとの協業の仕方について教えて下さい。

アドチームで実現したいことがある時にインフラチームに気軽に相談する形で進めています。進め方は、こちらでインフラの草案を持って行って懸念点がないかを確認したり、ゼロベースでインフラチームとディスカッションするケースも多いです。アドは特殊なドメインですので、インフラチームと要求性能やビジネスニーズなどを共有しつつ、理解に相違がでないように両チームが気をつけて進めています。

Q: Redisはon EC2で管理されていますか?

現在はElastiCacheで動かしています。以前はon EC2で管理していましたが、Full Managedな方が運用が楽ですし、例え一時的に停止したとしても配信に即時影響があるようなデータを入れないようにして運用しています。

コメント

非常に多くの方に来て頂き、広告という分野に対する興味や関心の高さを感じました。想定よりも広告業界の方が多かったため、より具体的な話をしても良かったかもしれません。広告配信に関する技術が、この業界全体により浸透していくように微力ながら努力していきたいと思っています。

2. HTTPプロキシによるゼロダウンタイムなアドサーバー移行

www.slideshare.net

コメント

今回はGo言語製のHTTPプロキシを用いて広告配信サーバをリプレースしたことについて発表させていただきました。結果的にゼロダウンタイムな移行に成功しました。関さんに今回の登壇依頼をされたときは、もっと人数が少ないと思っていたので、発表した時は大変緊張しました。 拙い発表でしたが、最後はオチで笑って頂けたので大変良かったです。

80人くらい参加してくれた

今までに開催した GunosyBeerBash で参加者数が50人を超えたのは初めてでした。CyberAgentさんの広いセミナールームをお借りできたおかげです。 connpassの申し込み人数も100人定員に対して137人の申し込みがあり、予想以上の盛況ぶりにわくわくでした。

かつサンド&ビールが好評だった

「勉強会がはじまる時間って仕事終わりでおなか空いてるよね」と運営メンバーから意見があり、まい泉のかつサンド&ビールを受付で配りました。

一口サイズのサンドイッチが3つ入っていて、ほとんどの方が完食。懇親会は別途ケータリングを用意したんですが、皆さんしっかり食べてくれました。 GunosyBeerBashの定番に決定です。イベント担当の方、受付時のかつサンド提供をぜひ試してみてくださいね!

次回に参加したくなった

参加してくれた方のツイートです。ゲストからも社員からも、毎回こんなコメントがもらえる勉強会をやっていきたいですね。次回も運営がんばります!!

Gunosyエンジニアの他の活動はここで見れるよ!

connpass - Gunosy Development Div.

Qiita organizations - Gunosy Inc.

Facebook - 株式会社Gunosy