いがにんのぼやき

WEBエンジニアのブログ。IT、WEB、バンド、アニメ。

Railsを使ってサービスの成長を継続させるぞ!(FiNC×みんなのウェディング)に参加してきた

mwed.connpass.com

参加してきました。
その時の雑な自分用メモを公開します。

サービスの成長を支えたRailsとMicroservices

v3/meという巨大なユーザー情報を返すAPI

interegest/prmd
committee

開発スピードの原則と再加速

MobaSiFというフレームワークで開発が始まった
ガラケー向けのフレームワーク
負債がたまりやすい(自由な)ものだった
テストやコードレビュー、命名規則など取り組んだが、改善しなかった
そのためそもそもフレームワークを変えて、開発を一転させることにした

nginxでリバースプロキシで振り分け、1ページずつRails
GithubとCircleCIでテスト
テストとレビューが通ればmasterブランチに反映してテスト、ステージングへ反映
本番へのリリースはステージング環境のリビジョンを使用
採番テーブル(インクリメントではなく、最大の数字を保存したテーブルから取得して+1してIDを登録する)の問題
Shift-JISが残っている問題

OSSの付き合い方

OSS活動ならなんでも可の週一OSS活動会をやっている
基本的にはソースコードリーディング
問題点や悩んでいるところの相談
コミッターたちからPRの返答がわからなかった時は相談したり

コードレビューについて

デザイナ、エンジニア、ディレクタで40人
Rails
Haml Sass ES6

スプリントレビュー
1週間に1回、全部所を集めて実施
青果物、予定を共有する
esaに各チームできたこと、できなかったことを書く
エンジニアからデザインレビューをお願いすることもある
rubocop,hamlintなどはCIでチェックされる
コードレビューにかかる時間を改善したい

※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。

マッチングサービスの運営で大切にしていること【Product Marketing Meetup】に参加してきた

d-cube.connpass.com

マッチングサービスの運営で大切にしていることに参加してきました。
その時の雑な自分用メモを公開します。

pairs

新規登録してきた人をはじめに出すようにしたりを機械学習を導入
しつつもやりすぎないように、パフォーマンスも求めつつ

男性だけ有料なので、男女比を合わせた獲得コストを測っている
LTR

Facebookで登録するため、うまく人を集めることができた
診断や占いなどを取り入れた

出会い系ではない、オンラインデーティングを認知していきたい
いいねだけではなく、そのあとも追えるだけ追っていく

ぽんぽんリリースして間違ってたら戻してみたいな体制だった
Aチーム、Bチーム、Cチームと分けた
連続的成長と非連続的成長を担う
2つのチームのタイプに分ける

なぜその課題をやるのか、解決策を各職種で集い導いていく

キャリアトレック

人材サービスでは企業開拓が大変
ビズリーチから引っ張ってきた

非公開求人が〜〜〜件などは作り手側の気持ち
見ていて面白くない
PCやカメラと同じでコア数などはほとんどの人は興味ない

※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。

RakSul Meetup #05 ~RubyBizグランプリ大賞を受賞した「ハコベル」のすべて~に参加してきた

raksul.connpass.com

参加してきました。
その時の雑な自分用メモを公開します。
大分雑にしか書いていないけど残しておく。

環境

  • Vue.js
  • SCSS
  • iOS/Android/ElectronでほぼWebView
  • Ruby 2.3.1
  • Rails5.0.0

  • CircleCI
  • Sentry
  • Pusher
  • GoogleMapAPI

directions apiで距離

macで開発

トラフィックよりも仕様の複雑さが高難易度
ミドルウェアは安易に増やさず、外部サービスを使用

※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。

Rubyエンジニアが語る、2016年の振り返りとこれからに参加してきた

speee.connpass.com

参加してきました。
その時の雑な自分用メモを公開します。

GMOペパポ

平均31歳 270名 8時間

minne API rails 4.2系

PHPからRuby

asean向け人材メディア 月数百万PV FuelからRails

2016年Speee全社でRuby移行 kage、HTTPリクエストを複製して別のサーバーに流す kageでFuelPHPに全リクエスト、RailsにGETリクエスト 10%くらいを流していた

centry datadog

Rubyの言語としてテストの文化があるので、Rubyを導入したことによってテストの文化が作れたことが大きい

ペパポ三種の神器

motemen/ghq amatsuda/gem-src

※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。

AbemaTV DEVELOPER CONFERENCE 2016に参加してきた

AbemaTV DEVELOPER CONFERENCE 2016に参加してきた
その時の雑な自分用メモを公開

AbemaTV Developer Conference 2016

まとめ記事は以下に公開されています。

developers.cyberagent.co.jp

インターネットにおける動画配信の仕組み

Http Adaptive Streaming

  • HLS
  • HDS
  • Smooth Streaming
  • MPEG-DASH

LinearTVを行うには

APC System(オンプレ)といったものをテレビでは使用するらしい
最初に表示されるテレ朝のニュースだけAPCを使用

映像データの取り扱い

録画コンテンツ

映像データが納品後、管理システムからデータを送る
一旦ジョブキューに格納されて、ワーカーがそれぞれ変換して配信可能形式に

生放送

オンラインで送られてきていてオンラインで変換しなければいけない
その変換では他社のEncoderやPackagerを使用している
それぞれの元の配信形式に合わせるため

セグメントをどう扱うか

録画コンテンツ

GCS
JSONで分割一情報を入れてあり、それを元に今のデータから現在の再生一から放送している

生放送

MongoDBを使用してセグメント情報を登録して、それを元に映像を再生させる

Adaptive Bitrate Streaming

元データを同じ時間単位で各画質ごとに分割しなければいけない
高画質のデータで破損や欠損、位置ずれするトラブルがあった
自動検知できる場合は、下の画質から置き換えるようにした
ポーリング時にセグメントの数などを確認したり

デザイナーとエンジニアの境界線

UIデザイナー

pixateでモックを作成
3人?で3ヶ月でモックを250個
開発初期は技術者の連携が濃くクオリティの高いプロダクトを作り上げられる環境
今は40人で運用フェーズでリモート勤務の方もいたり忙しかったりで最近コミュニケーションが希薄
Sketchでデザイン、エンジニアがSketchを見て実装
Sketchファイルからエクスポートを実行し、PNGの最適化を行うコマンドをエンジニアが開発
デザインガイド(マージンの幅の詳細とか)を用意しなくても成立するようになった
Pixateでデザイナーがアニメーションエージングを試行してからエンジニアに渡していた(具体的に数字を示して)

  • とにかくチーム全員で揉む
  • ファイルのやり取り書き出しは自動化
  • アニメーションを決めてからエンジニアに渡す

テクニカルクリエイター

自分がアプリを作ってることを匂わせる
リアルなプロダクトを重視する流れ
テクニカルクリエイターという社内の流れ
(一人多彩なクリエイター)

インタラクティブなUIのためのAVPlayerベストプラクティス

動画をザッピング後、動画の破棄が重い、現れる動画の準備が重い
AVAssetは場合によっては時効スレッドをブロックしてでもコンテンツの読み込みを行おうとする場合がある
AVAssetからメディアの時間を取得する処理をメインスレッドを使うと他の処理が止まってしまうことがある

読み込み開始時は低いビットレート
両脇の動画も低ビットレートで、再度読み込まれる時に画質をあげたものに

マルチスレッド

UIはマルチスレッドで
やみくもにサブスレッドに投げない
以前はCircleCI、今はJenkins、ビルドはカーストレイン、テストアプリはFabric、本番はテストフライト

AbemaTVの開発スタイル

ベースはスクラム
アジャイルサムライにあるインセプションデッキ

FRESH
開発:20人
以外:10人

AbemaTV
30
100
スクラムチームは奥手も10から15人が限界なので分解が必要

炎上プロジェクト立て直しの風景

WEB業界の炎上経験多数
自社内開発では柔軟な分、あいまいなことが多い

意思決定、情報の集約は一元化しよう
介入が避けられねい場合、影響を局所化しよう

アクセス傾向とCMのところから30万くらいの推定
実際の数字を見せることによって説得した

※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。

Windows10でのVagrantの起動エラー

新規にVagrantのboxから仮想マシンを作成しようとしたときに下記のようなエラーがでて、仮想マシンが作成、立ち上げられなかった。

C:/Users/igani/.vagrant.d/gems/gems/vagrant-vbguest-0.11.0/lib/vagrant-vbguest/download.rb:23:in `unlink': Permission denied @ unlink_internal - C:/Users/igani/.vagrant.d/tmp/VBoxGuestAdditions_5.0.26.iso (Errno::EACCES)

対策としてVagrantの更新、vagrant-vbguestの更新を行うことで起動できた。 Vagrantの更新は公式からmsiファイルのインストーラーを、vbguestはvagrantコマンドでアップデートを行った。

$ vagrant plugin update
Updating installed plugins...
Updated 'vagrant-vbguest' to version '0.13.0'!

 

 

第5回CodeIQ感謝祭「食欲とプログラミングの秋」に参加してきました

第5回CodeIQ感謝祭「食欲とプログラミングの秋」に参加してきました。

印象的なこととか、自分の覚えている範囲で書いていきます。

第一部:増井雄一郎プレゼンツ「さまざまな視点から見る エンジニア採用現場の本音」

IT企業のウルシステムズ、トレタ、Speeeに加え、エージェント目線ということでリクルートキャリアも加わり4社でのディスカッションでした。 それぞれの発言をまとめるとともに感想を織り交ぜてみました。

ウルシステムズ

エンタープライズ業務 全社員260人中240人がエンジニアとのこと。 年に中途25人くらい、新卒5人を採用しているそうです。 年齢層は30歳周り。 カルチャーでマッチしないことが多い。 技術に関しては、後々伸ばしていけばいいと考えているとのこと。 ただし伸び代が見えないのはダメ。 本音が見えないのは厳しい 62歳のエンジニアがいたりもする。ディスカッションの趣旨に合わないから話さなかったのだろうけど、そこらへんの能力とか給与とかどんな感じなのか気になった。

Speee

400人中26人(正社員)、実際フリーなど含め50人くらいがエンジニアらしいです。 Speeeさんはエンジニアに対して、お金をかなり払ってくれるイメージのせいかもっとエンジニアが大勢いるイメージでした。 少数精鋭で強いんですかね。 年齢層は20代後半。 月1万サーバー費用をもらえる 月に20回面接とかしている 技術でマッチしないことが多い かなり印象的で確かにと思った言葉が出てました。 他人を変えるよりも自分を変えるほうが早い 当たり前のことですよね。

これから勉強しますって人は惜しいとのこと。 また、時間を使ってないエンジニアは惜しい。rails興味ありますではなくrailsならチュートリアルぐらいやればいい

トレタ

60名中13名エンジニア 年齢層は35歳周り 社員紹介での採用が多いとのこと。 2つの面接の種類があって、カルチャー面接と技術面接があるらしいです。 また、1次2次といった面接ではなく、同じ階層で別の人が面接を行うといった形をとっているようです。 また、カルチャーでマッチしないことが多いとのこと。 そのカルチャーっていうのも、やはり技術が好きかどうかっていうのは大きいようです。

今まで基本的にGithubでコードを公開していることは必須で、1人だけ社員紹介の方でGithubのコードがなくても取った人もいるにはいるらしい。ただし一人だけ。 もちろん、Githubでコードを公開していなくても、書籍を書いたりとか、本を読んでこんなこと学んだとかをアウトプットしていると印象はいいらしいです。

第二部:【ヨッピー×河西智哉×伊藤直也】ヨッピーさんが、普段聞きづらいあんな質問やこんな質問をぶつけます!

ヨッピー 1980年大阪生まれのライター

伊藤直哉 1977年宮城生まれ

河西智哉 1992年生まれ

河西智哉伝説

KAIZENのRails 3.0 を4に3日くらいで書き換え、1ヶ月でリリース 1000万円のオファーがあったけど受けてはいない。今の年収は不明

伊藤直哉さんは1000万はもらっているらしいです。それ以上の詳細は秘密とのこと。 直哉さん曰くストックオプションよりも株のほうがおすすめらしいです。 株は法律的に会社に剥奪されないが、ストックオプションは規約などで剥奪されることもあります。 例えば退社したときとかに剥奪されたり。 また、オプションも税金がかかるのでストックオプション破産なるものもあるらしいです。 ストックオプションの説明も簡単にあって、簡単に言えばストックオプションをもらったときの値段で株を買うことができる制度で、現在の値との差額で儲けが出るとのこと。

第三部:プレゼンの神・澤円 ×「JAWS-UG」の生みの親・小島英揮が最強のエバンジェリズムを語る

プレゼンの神、日本Microsoftの澤円さんと元AWSの小島英揮さんによる講演です。 前々回の感謝祭のときに澤さんのプレゼンは拝見させていただいて、強く印象に残るプレゼンをしていたのを覚えています。

プレゼンとはファンにすることであると。

PresentationはPresent(プレゼント)という単語から始まっていて、聞いている人にプレゼントをして、ファンになってもらうことだということを念頭におくべきとのお話。

質問の大切さ

また、それに合わせてプレゼンを受ける側の場合、発表者に質問をしましょうとのこと。 日本語での質問という言い方はとてもきつい感じを思わせます。 ですが英語で書くとQuestion。Quest(探求)というワクワクを想像させる単語で始まると。 質問は外国では探求的な意味合いが強く、人によってはプレゼン中に質問が飛んでくることもあるとか。 質問は基本的にみんなが聞きたいなと思っていたことが聞かれることが多いので、質問者、質問を聞いていた人も得をし、みんなが聞きたがっていたことを知ることができ回答する発表者としても勉強になる。 個別で質問を行うときも、澤さん曰く日本は占い師の待ち列のように、外国ではおうぎ形の形で聞くことが多い。日本は自分の質問が恥ずかしいと思う側面があるが、外国では質問をシェアしようという考えが強い。日本でもそういう考えを持つべきとのこと。 また、質問を答えないという選択肢もあり。 その場合はわからないと答えて、何かしら代替の返答を返してあげること。 そして、プレゼンにおいて質問がないのはいいプレゼンではないらしいです。

アウトプットを増やそう

次に発表する機会を作りましょうとのこと。 発表することによって、顔を覚えられるし、実は発表するとインプットが大きく増えるとのこと。 発表した場合、話しかけられることが多くなり、相対的に様々な情報が入ってくる。 それによってまたさらにアウトプットが増え、いい循環が生まれるとのこと。

発表する場所も、ホームグラウンドでしか話していない人よりも外でも話している人ではレベルが違うのでずっとホームに閉じこもらずに見知らぬ場所で発表しましょう。

聞いている人のレベル差のある状態でのプレゼン

澤さんは幅広いレベルの人相手にプレゼンをするときは情報の粒度は一番下の人に合わせるべきと。 この粒度でわかってもらえたラッキーな人と、これを理解して周りに伝えてくれる人といった形に分けてプレゼンをする。 小島さんは先にレベルを知らせてしまう方法、難しい話ですよとか優しい話ですよとか前置きするとつまらなかった人が減る

その他手法

プレゼンで説明して自分ごとにしてもらう、当事者意識を持ってもらうことはとても有効な手段である。

スライドは情報量少なめ、キャッチーに 写真1枚一言とか スライドを印刷して一覧化して遠くから見てみると、俯瞰で見ると情報量がわかる いるものいらないものがわかってくる 画像はフリー画像を検索、Google画像検索は一応著作権あるんで注意 英語だと日本語よりも15万倍の差があるので単語は英語で検索

質問を回答したら答えになってます?っていうのがいいらしい。

まとめ

今回も面白いイベントでした。 第3回から参加させていただいていますが、ただのプログラミングの話ではなく、キャリアや魅せ方、学び方といったことの話が聞けるのでとても楽しいです。