#2こんにちは、エンジニアの中村です。Up#2を開催したので、その様子を書いてみました!今回も前回に引き続き沢山の人がきてくださいました。前回よりもかなり盛り上がってとてもいい会になりました。社外の人に自社のシステムを紹介しようという目的の元開催いたしました!今回のイベントの発表内容はこちらです。obara_tさんの発表「UUUMエンジニアの日常」UUUMエンジニアの日常obara_tさんは、社内システムについてと、UUUMエンジニアの日常を紹介してくださいました。技術選定の話や、技術的なチャレンジは責任持ってやってくれればOKなど、自由なシステムの雰囲気を紹介してくださいました。ピザパや焼肉をみんなで食べに行ったりなど、とても楽しそうな雰囲気が参加者に伝わったように思います。ishihara_kさんの「UUUM攻殻機動隊に入隊しました」UUUM攻殻機動隊に入隊しましたishihara_kさんはUUUMに入ってまだ2ヶ月目ですが、入ってすぐの目線で見たシステムについて話してくださいました。ishihara_kさんの1つ前の会社がとてもブラックで、1年で300日オフィスで寝泊まりで作業していたという話を聞いて恐ろしいなぁと思いました。UUUMはめちゃめちゃホワイトなので安心してくださいね!次に、fujisawa_yさんの「UUUMと開発の話」UUUMと開発の話fujisawa_yさんはCREASという、UUUMクリエイター限定サイトの紹介と、エンジニア×YouTuberについて発表してくださいました。CREASを支える技術や、実際の作業内容を話してくださいました。CREASについて詳しく知りたい方は、「UUUM限定サイト」と検索してみてください!また、エンジニア×YouTuberの話では、Githubのフォロワー数7位はエンジニアであったり、海外ではエンジニアでYouTuberの人のチャンネルがとても伸びていることを初めて知りました。最後は、nazoさんの「レガシープロダクトを改善していくための戦い方」レガシープロダクトを改善していくための戦い方nazoさんは元UUUMエンジニアの方で、初期からずっとシステムを支えてくださった方です(とてもすごい人です)。今回は、レガシーコードとの向き合い方・心構えについて発表してくださいました。気をつけておかないといけない部分を紹介してくださり、自分が見えていない部分を色々と学ばさせていただきました。ためになりました!登壇してくださり、本当にありがとうございました!懇談会では、ケータリングを囲んでわいわい技術の話で盛り上がりました。今回のイベントでUUUMに興味を持ってくださった方も沢山いて、とても楽しかったです。懇談会での様子ケータリングケータリング全体写真イベント参加者の皆さま本当にありがとうございました。1回目よりもとてもいいイベントになりました。#2Tweetコメントを書くもっと読む2019-11-23プロダクトマネージャーカンファレンス2019PMこんにちは。PMチームのしだです。会社のカンファレンス参加精度を利用して、2019年11月12、13日に行われたプロダクトマネージャーカンファレンス2019に参加してきました。「PMが学ぶべき、最低限のデータ活用スキルとは」についてレポートします。晋一郎データは分析するだけでは意味がなく、ユーザーのために活用されてはじめて価値が生まれます。ユーザーのことを日々真剣に考え、新たな価値提供を生みたいと常に思っているPMの人たちこそデータ活用スキルを身につけるべきです。いって統計学を一から学んで、、、とか、機械学習の講座を受けて、、、では遠すぎます。必要最低限のデータ活用スキルを身につけて、ユーザーへの価値提供力を高めましょう。初参加でしたが、普段知ることができないたくさんの企業の様々な事例とその対応を知ることができ、大変有意義な勉強をさせて頂きました。)をお招きし、LEGOブロックでスクラム入門の勉強会を行いました。弊社ではスクラム開発しているプロダクトとそうでいないプロダクト双方あり、私が担当しているプロダクトではスクラムを導入していなかったため、いろいろ発見のある勉強会でした。第1部ではアジャイル開発の歴史から始まり、現在の複雑化したシステム開発の実態、スクラム開発とはどういったものなのか、わかり易く説明がありました。その中でアジャイルとは傘に喩えられるように骨組みであり、特に中身は無いものであると言うこと。それを補完すために様々な開発手法が存在し、スクラムもその中の一種であると説明がありました。スクラムをすることでチーム内の知識・経験を蓄積することができ、より強固なチームへ進化させていくものだということがわかりました。座学終了後、レゴを使用してのスクラム開発の体験です!この勉強会では開発側・顧客側を体験できるように設計してあるため、自分たちが設計した街を他チームが、他チームが設計した街を自分たちが作っていきます。各チームが家族という設定で欲しい建造物をカードに書き出していき、模造紙を使い理想の街の設計図を作っていきます。設計図作りが終わったらカード毎に優先度をつけて並び替えていきます。その後、開発者として他のチームへ移動します。私達チームの街は商店街は駅近に、公共施設は自然の近くに配置しました。他のチームのイラストレベルが高すぎてびっくりしたり。移動したら、他チームの設計図を元に、1見積もり、2スプリント、3レビュー・振返りを繰りを繰り返して街を完成させていきます。プランニングポーカーでざっくりと工数見積もりをします。見積もる際に出てきた疑問点は相手チームのプロダクトオーナーに相談して進めていきます。その後、3回のスプリントで全てを完成できるように、Velocityを算出。予想値ピッタリになるように、プロダクトバックログの上から順番に実現できそうなころまでストーリーを引き、開発していきます。1回目のスプリントでは顧客の要望をきちんと把握できておらず、顧客の望む通りの建物をうまく作り上げることができない人が出てきました(私です)。その結果、Velocityの予想値をかなり下回り、不本意な結果に終わってしまいました。2回目のスプリントでは1回目の振り返りを基に再見積もりをし、新たにVelocityを設定していきます。前回の反省を踏まえ、工数が大きなものは複数人で開発するように変更しました。前回中途半端に終ってしまったモノは顧客が求める建物としての要素を追加していき、また工数が大きいモノも複数人で開発することで時間内に完成することができました。顧客レビューでは全ての建物に対して合格をいただき、予想値通りの開発をおこなうことができました。最後に、チームで作成した傑作の油田です。まとめ勉強会を終えて、1回目ではバラバラだったチームに一体感が生まれるのを感じ、開発スピードも上がっているのを実感することができました。顧客の要望を適切に理解する必要性、どう叶えるかをチームで考えることで一体感が生まれたのを感じました。JupyterLabによる分析環境の構築こんにちは、分析チームの門脇です。日頃クリエイターに関するデータ分析業務を行う際、環境ごとのライブラリの管理が面倒だったり、形態素解析エンジンの導入、notebookの設定をやり直す必要があるなど何かと不便でした。そこで今回は、Dockerを利用して、簡単にクリエイター分析環境を構築してみました。DockerについてDockerはコンテナ型の仮想化環境のことで、Dockerfileに仮想環境に取り入れたいものの処理を記述することで、簡単に同一環境を再現でき、環境ごとに設定をやり直さなくて済むといったメリットがあります。Dockerによる環境構築ついて詳しく知りたい方はこちらにわかりやすくまとめられています。今回は記事の中でも紹介されているKaggleが提供しているDockerイメージをベースにDokerfileを作成していきます。MeCabについてクリエイターについて分析を行う際に、テキストデータを単語ごとに分割して関連ワードを取得したいことがあります。MeCabは日本語の形態素解析エンジンの中では最もよく使用されていて、mecab-ipadic-NEologdというシステム辞書があり、新語・固有表現に強い単語を分割する際に有効です。ハローYouTube、どうもヒカキンです!』を調べてみます。MeCab標準辞書のとき『ブンブンハローYouTube』についてブンブンハローYouTubeそれぞれ別の単語として認識されてしまいます。mecab-ipadic-NEologdのとき『ブンブンハローYouTube』として固有名詞として分割でき、『ヒカキン』も固有名詞として認識されます。日々新しい用語が生まれるYouTubeにおいて、mecab-ipadic-NEologdを使うことで、簡単に対応することができます。notebook』の後継機のIDEで、オープンソースとして公開されています。notebook』をより使いやすくしたものであり、こちらで便利機能が詳しく紹介されています。自分好みに拡張機能を追加することができ、作業効率を上げることができます。実際にDockerfileへ拡張機能の導入を取り入れてみました。jupyterlab_code_formatterKaggleが提供しているDockerイメージは最新のものを指定しています。(2019/10/17時点)また、こちらから適宜最新のイメージを確認していただければと思います。mecab-ipadic-NEologdのインストールはこちらに記載されているライブラリを入れます。mecab-python3もインストールします。JupyterLabの拡張機能の利用についてはNode.jsが必要となるのでインストールします。今回は個人的に便利だと思ったものを拡張機能としてインストールしています。labが起動するよう設定しています。下記コマンドで、コンテナを作成して、起動します。--buildを指定することで事前にイメージを作成してくれます。--buildするとコンソール上に結果が表示されます。あとはホスト名をlocalhostにして、ブラウザでログインするだけです。MeCabをPythonで使うとき辞書のインストール先はJupyterLab上で下記コマンドにより確認できます。--dicdir`"/mecab-ipadic-neologd"今回は、/usr/lib/x86_64-linux-gnu/mecab/dic/mecab-ipadic-neologdにインストールされたことが確認できたのでコードを書く際は、インストール先を指定します。/usr/lib/x86_64-linux-gnu/mecab/dic/mecab-ipadic-neologd')print(tagger.parse('ブンブンハローYouTube、どうもヒカキンです!'))すると、先ほど示した例のようなmecab-ipadic-NEologdを使用したときの結果が出力されます。まとめDockerを利用することで自分好みの分析環境をサクッと作れちゃいます。#1こんにちは、エンジニアの中村です。その様子を書いてみました。uuum.connpass.com今回は約30人以上もの人がイベントに参加してくださいました。社内外の技術者たちと交流を深めたい!という目的の元開催いたしました。イベントの発表内容はこんな感じです。」UUUM満開~なんで私が登壇に!?~オタサーの姫を作ると営業と仲良くなれるという話や、UUUMのことを面白おかしく紹介してくださったりと、会場もとても盛り上がりました。機械学習を用いてクリエイター間の類似度算出を行うという発表でした。機械学習をあまり知らない私でも雰囲気を掴めるようなわかりやすいスライドで、機械学習って色んなことに使えるんだなぁという気付きにもなり、とても楽しかったです。再生回数のデータを予測するお話sabomasaさんもmyaunraitauさんに続いて、機械学習を用いたデータ解析の発表でした。内容は機械学習を用いてYouTubeの再生回数を予測するという感じでした。私もGASマスターしたいと切実に思いました!懇談会はピザを囲んでわいわい技術の話などで盛り上がりました。UUUM以外のエンジニアやPM、デザイナーの方とお話ができて本当に楽しかったです。全体写真とても楽しいイベントとなり、本当に良かったです。#1Tweetコメントを書くもっと読む2019-10-02秋の開発合宿を開催しました!こんにちは!今回開発合宿のブログ担当する、インターンの鷲見です!システムユニットでは年2回、開発合宿を行なっています。今回行なった場所は湯川原にある「おんやど恵」という旅館です。開発合宿(旅行)ではよくお世話になっているのでところです。都内から二時間ほどで行ける開発合宿用のプランがある24時間使える会議室があるWi-fi環境が整っている温泉と足湯といった環境がおんやど恵は整っているので、開発合宿をするのにとても便利です。実際にどんな旅館なのか紹介していきます!会議室こちらが会議室です。一人、一人スペースが用意されているので、場所に困ることはありません。食事はコースで出てきます。味もボリュームも十分あるので大満足です。このお肉と味噌組み合わせはとても美味でした!開発は何をしたのか?今回の開発合宿はテーマは「自由開発」です。日頃業務ではやらないことに挑戦したり、技術をより理解すること、PMの方達はチームが力を最大限発揮するための研究にたくさんの時間を使うことができました。お昼の2時ごろから着々と取り掛かっていきます。深夜の追い込み食事をした後、会議室組は深夜の追い込みをかけてきます。支給品も届き、仕上げに取り掛かっていきます。朝に少し作業した後、成果発表を順番にしていきます。中には徹夜して限界を迎えてしまう人も。皆さん短い時間の中で高い成果を上げていました。日頃の業務外の技術を使って作られた作品が多かったので、発表はとても面白いものとなりました。まとめ2日間に渡り開発に集中できる素晴らしい環境を整えてくださったおんやど恵の皆様ありがとうございました。すばらしい環境だからこそ、短い時間の中でもそれぞれ成果を出すことができました。開発と発表を通して、それぞれ知識を共有できたのでとても有意義な時間を過ごせてよかったです。最後は集合写真終わろうと思います。(Terraform)でいい感じにファイル上のデータを集計しようシステムユニットのt_u_a_kです。ブログ登場は初めてです。私は業務で少々大きめのデータの集計ということをやっていますが、その際にはAWSのAthenaとGlueを試しました。手軽でよかったので紹介します。AthenaとGlueについてまずAthenaについてですが、これはS3上のデータに対するクエリサービスです。データベースに対するクエリサービスではなく、S3上のテキストファイル(もしくはそれらを圧縮したりしたもの)に対してデータ構造を定義し、いわゆるSQLを使って普通にクエリが書けます。この時点でAthenaのようなサービスや仕組みに触れたことがない人にとっては「は?」って感じですね。AthenaはPrestoというFacebookが開発したクエリエンジンを使っていて、大きなデータでも爆速で結果が返ってきます。Presto公式ではFacebook自身が300PB以上のデータの分析に利用していると書いています。ここまで来るとでかすぎて想像もつきませんが、通常の利用であれば本当に驚くほどのスピードでクエリの結果が返ってきます。aws.amazon.com次にGlueです。GlueはいわゆるETLサービスというやつです。最近だとデータウェアハウスを構築するところも多いと思いますが、いろんなところにいろんな形で存在しているデータを変換したり移動させたりいい感じに集めるときに使うサービスというのが非常に雑な説明です。Glueにはデータカタログという機能があり、これがAthenaと一緒に使える機能です。Athenaはクエリサービスと書きましたが、Glueで定義したデータカタログをいわゆるデータベースやテーブルと見てクエリをすることができます。これではわかりにくいと思うので下で説明していきます。aws.amazon.com今回使うデータ例えばこんなデータがあったとします。hikakin.csvvideo_id,title,channel_id,views,datezW4HJkuFFtc,【ランキング】ヒカキンがガチでウマいと思うセブンの商品トップ3!【2019年5月編】,UCZf__ehlCEBPop-_sldpBUQ,1826863,20190518VY0EXQqSeRc,顔面が大変なことになりました...,UCZf__ehlCEBPop-_sldpBUQ,1650048,20190517MgeD8MB6fyg,金属アレルギー検査したらまさかの結果が...【1900万円の時計のその後】,UCZf__ehlCEBPop-_sldpBUQ,1906878,20190515皆様ご存知のヒカキンさんのチャンネルHikakinTVの動画について、2019年5月のある時点でのデータです。1行目が動画IDや動画タイトルといったヘッダー、2行目以降がデータになっています。他にもこのような似たデータを用意しました。0214mexがはじめしゃちょーさんでtsuriyokaが釣りよかでしょうさんの動画に関するデータです。釣りよかでしょうさんに関してはサブチャンネルのデータも混ざっています。これらがそれぞれhikakin.csv、hajime.csv、tsuriyoka.csvという名前で存在している、もっというとUUUM所属の各チャンネルごとにこのようなデータがあると仮定して、Athenaでクエリをかける準備をしていきます。(※0214mexなどを見ても何のこと?と思う方もいらっしゃるかもしれませんが、はじめしゃちょーさんのYouTubeチャンネルについてはhttps://www.youtube.com/user/0214mexというURLでもアクセスできるようになっており、他のチャンネルでもこれに似た形でURLが表記されることがあります。0214mex.csvvideo_id,title,channel_id,views,datedmpYE9u3cr4,"【50,000枚】3年間集めた遊戯王カード全部売ったら金持ちになったwwwww",UCgMPP6RRjktV7krOfyUewqw,1280160,20190520xUFNcNQ24Ho,家に隠されたドラゴンボールがガチで見つからない件。tsuriyoka.csvvideo_id,title,channel_id,views,dated0XrWwauyQY,むねお船は初心者に優しいらしい,UC4QadOSsJu54Qs8z99shRiQ,136100,20190521dwXSckt1lM4,庭でイカを料理してたら変なの来た,UC4QadOSsJu54Qs8z99shRiQ,215405,201905201AuvYVUMNGs,リフォームした家の壁に缶スプレーでらくがきしてみた!,UCD7-Ocp4InwPKzwiq_U-Abg,230155,20190519ew0HdXG3SKQ,ドラム缶でオリジナルBBQコンロを作る!,UCD7-Ocp4InwPKzwiq_U-Abg,168260,20190521j5aQ_Y3_I_U,新居キッチンの紹介します!,UCRT-74ovdMKOFBC96w_gfyQ,105864,20190521YC1OnPK2fWE,ミルフィーユカツで新潟のB級グルメ作ってみた!,UCRT-74ovdMKOFBC96w_gfyQ,73117,20190520S3へのデータの保存AthenaはS3上のデータに対するクエリサービスなので、まずはデータをS3に置かなければいけません。今回は2019年5月のデータチャンネルごとに別ファイルとなっているので、仮にデータが増えるとすれば別の月のデータだったり、違うチャンネルでファイルが作られるということが考えられます。このような場合にはS3に保存する際にs3://my-bucket/year=2019/month=5/channel=hikakintv/hikakin.csvs3://my-bucket/year=2019/month=5/channel=0214mex/hajime.csvs3://my-bucket/year=2019/month=5/channel=tsuriyoka/tsuriyoka.csvというふうに/key=value/のパーティションを作ってあげることで、Athenaでクエリをかける際にまるでyearやchannelといったカラムがあるようにクエリをすることができます。channelのカラムが1チャンネル1つに対応していないじゃないかとかchannelキーに対するvalueのルールがおかしいんじゃないかといった意見もあるかと思いますが、今回tsuriyoka.csvに複数チャンネルのデータが入ってしまっているため、ファイルの中を見る前はパーティションを厳密にチャンネル単位で分割することができません。パーティションについては細かくすればするほどクエリの条件を細かく設定できるので料金面で有利になる一方、ファイルをS3に設置するコストが高くなってしまうなどもあるので、どの程度の粒度で分析や集計を行いたいかによってパーティション設計は考えていくべきだと思います。自動的にS3にファイルが流れてくるような状況から作るのであれば、パーティション設計はますます重要です。docs.aws.amazon.comデータ構造を定義する今回のデータを見たときに、どういうクエリがかけるでしょうか。(本来はどういうことを知りたいかが先に来るべきですが今回はちょっと置いておきます。5などがあるでしょうか。別の年月やチャンネルが増えればもっといろんなパターンが出てくるとは思いますが、共通しているのはs3上のデータをテーブルとして、CSVの各カラムやパーティションをselect文に入れたいということです。これをやるためのデータ構造をGlueで定義してみましょう。Glueでデータカタログを定義するAthenaでクエリをするためにGlueでデータカタログを定義しますが、データカタログを定義するとはデータベースとテーブル(およびその中のカラム)を定義することです。Glueにおけるデータベースとはいろんな場所にあるデータを統一的に扱うためのメタデータストアになりますが、データベースが必ずどこかのバケットと紐づくなどは無いので、実際あまり意識する必要はありません。必要に応じて作っておけばいいものになります。今回作成したデータベースについても名前以外は何も決めていない状態です。今回のようにAthenaでのクエリを目的としたテーブル作成においては、テーブルとバケットが1:1だと思っておくのがよいと思います。テーブルに指定する内容は大きくわけてスキーマとそれ以外のオプションになります。オプションの項目としてはどのようにデータを解釈させるかを決めるHadoopのフォーマットなどがあります。細かく指定できるようですが、私もすべては把握できていません。いろんな形式のデータを使ってみたりすることでだんだんわかるようになってくるのだと思います。今回作ってみたblog_test_tableは以下のようなデータカタログ設定になっています。↑の画像に出したデータカタログの内容をAWSコンソール上から設定することは可能です。設定の初期などはパーティションを変えることがあったり、なぜかAthena側でデータカタログのロードにうまくいかなかったりと、最初から作り直したほうがいろいろと楽な場合が多いです。(個人的にはHadoopだったり分散処理に関する知識が足りないと十分にエラー調査していくことが難しいのかなと思っています。作り直すたびにAWSコンソール上でポチポチやっていたこともあったのですがつらすぎるので、データカタログはTerraform化してしまいましょう。apply一撃で済むようになることでかなり作業が楽になるのと、クエリを書いて調査・分析をするという本質的な作業に時間を割くことができるようになります。Formationもありだと思います。データカタログ部分のterraformコードはこのような感じです。v0.11系で動くように書いていたのですが、今回ブログを書くにあたってv0.12.9で動作するように書き換えました。0.12updateコマンドがあるので基本的には自動で書き換えてくれましたが、一部自分で直すような感じになりました。ポイントとしてはstorage_descriptor.ser_de_infoかなと思います。S3に保存してあるファイルの形式によってここが変わってきます。今回はCSVを使っていますが、TSV、JSON、Hadoop形式などにも対応していて、形式に合わせてSerDeというシリアライズ/デシリアライズライブラリにオプションを与えることになります。}}データカタログ部分についてはこれだけです。CSVの形式の変更などがあったときもコード変更とterraformの適用だけです。S3バケットもterraform化できていればより完璧です。docs.aws.amazon.comAthenaでクエリするあとはAthenaでクエリをするだけです。CLIからだと結構柔軟に設定できますが、今回はAthenaのコンソール上からやります。test_catalog_db.blog_test_table;というSQLを流しておきましょう。これをやらないとAthenaが新たに追加されたファイルを認識できなくなります。blog_test_tableをしてみると、3.22秒と出ました。仮にこれがRDSであればどう考えても遅すぎますが、Athenaはあまりに小さいデータに対してはRDBMSよりもパフォーマンスが悪くなります。逆に大きいデータに対してはとんでもないスピードで結果を返してきます。今回についてはクエリを投げられるようになることが目的なのでここまでにしておきますが、実際にやったことはバケットとデータカタログの設定だけなのでかなり簡単にCSVのようなデータに対してもクエリが投げられることがわかったと思います。形式はCSVだけでなく、多様な形式をサポートしています。料金についてAthenaはスキャンしたデータに対する従量課金のため、スキャンデータを減らすことが利用料金を減らす一番の近道です。同時にスキャンデータを減らすことは処理速度を上げることにもつながります。データは圧縮形式でも扱えるため圧縮してS3に入れる、Parquetなどの列形式へ変換するなどの方法も役に立つと思います。まとめAthenaとGlueのデータ集計での利用について書いてみました。今回ほど小さいファイルであればSQLiteを使うのもありだと思いますが、実際にはそこそこのサイズがあると思うので、ファイル上のデータについて単純なクエリをしたいということだとこれが一番簡単な気がします。AWSマネージドなので管理コストも最小限です。最後にやっと1回ブログ書けた、、、。システムユニットでは一緒に働いてくれる方を募集中です。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。