2020/04/28 MixLeap Live Study #59 - Reactとその仲間たちの勉強会メモ
2020/04/28(火)にオンラインで開催されたMixLeap Live Study #59 - Reactとその仲間たちの勉強会メモです。
イベント詳細
目次
- 内容
- 質疑応答
- 感想
内容
React + GraphQLで社内の負債を解決した話@藤本 卓哉氏/株式会社Gemcook
GraphQLを採用するまでの経緯
- Miyou というマッチングサービスをつくる
- マッチングサービう=チャットが必要=GraphQL使おう
- GraphQLとは
- あるサーバーに対してデータの問い合わせできるクエリ言語
- SQLはDBに対してデータの問い合わせできるクエリ言語
- 特徴
- 必要な分だけデータを取れる
- 1度でデータをまとめて取得できる
- 型システム
- 導入するとなにがいい?
- 1つのエンドポイントでほしいデータを取れる!
- +AppSyncを導入
- 最初の障壁が低くなり、細かい仕様もカバー
GraphQL(AppSync)の良かった点
- 社内の負債がいくつか…
- エンドポイントが大量発生→エンドポイントが1つになり地獄から開放
- APIドキュメントはバックエンドのしごと→フロントエンドの責務を増やすことができた!
GraphQL(AppSync)の辛かった点
まとめ
- フロントエンドとバックエンドが仲良くなれた
- 技術的負債の解消ができた
- チームの布教と理解、共有は必要
React Hooks公開から1年で得られた知見@西村 爽氏/株式会社Gemcook
React Hooks概要
- 16.8.0 以降で利用可能
- 関数コンポーネントで利用可能
- React Hooksのメリット
GemcookのコンポーネントとHooksの歴史
- Gemcookのコンポーネント
- クラスコンポーネント
↓
- 使っているライブラリ
まとめ
React/ReduxにSelectorを導入したら幸せになった話@松井 真子氏/ヤフー株式会社
入稿ツール
入稿ツールの開発時に困ったこと
- コンポーネント間の依存関係が複雑
- 1からAtomicDesignを導入し、作り直し
- バリデーションの実装が複雑に
- データ構造が複雑&ネストが深め
バリデーションがなぜ難しい?
- バリデーションのタイミングが難しい
- 実装方針としてActionやReducerの中ではロジックをもたせたくない!
- そもそもバリデーションの条件が多かった
そんなとときに助けてくれたselector
- 使うと何がいい?
- stateが渡された際に関心のある値を返すことができる
- 責務分けができた!
まとめ
- 責務分けができた!
- stateが渡された際に関心のある値を返すことができる
- selector機能をつかうと余計なデータを保持しなくて良い
- バリデーションの切り分けできてよかった
React × Unity@青山 広大氏/ヤフー株式会社
Unity?
- ゲーム作れるすごいやつ?
- 対応プラットフォームにWebGL!
- Webにできるのでは?
React Nativeで家計簿アプリを作って得たもの@西仲 幸太氏/ヤフー株式会社
アプリの紹介
- 家計簿アプリ
- メールアドレス/PWで認証
- 月で一覧表示
技術紹介
Redux
- Hooks が2019年6月にリリース
- Hooksを使うことで記述量が減らせる
- Hooks が2019年6月にリリース
React Native
- v5がリリースされ、タグが囲む形式になって可読性が上がった
- Firebase
- Firestoreを利用
- 考えるべきこと
- 必要なデータ加工不要な形式で取得可能
- 機能
- セキュリティルール
- リアルタイムリスナー
- オフライン対応
- 考えるべきこと
- Firestoreを利用
まとめ
- React NativeもReact!
- Reactのよさはそのまま
- React + Expo + Firebaseで迅速に対応!
質疑応答
React + GraphQLで社内の負債を解決した話@藤本 卓哉氏/株式会社Gemcook
@藤本さん GraphQLって中間サーバー(APIとフロントエンドをつなぐ)を設けるというイメージなのですが、そのことによるパフォーマンスって気になりますか?
- きちんと所感では問題なさそう
- 設計次第でそこは解説できそう
GraphQLを知った上で、あえてREST APIを採用した方がいいケースはありますか?
- 画像や動画ファイルでやり取りする場合
2つ質問させてください。 ①クライアントではapolloを使っていますか?使っていたらここのメリデメを知りたいです
- メリット
- Hooksベースで作れる
- コードを簡素化できる
- デメリット
- 教育、布教が大変
②チャット以外でGraphQLを使うことってどう言うユースケースが想定されますか?
- グラフの描画などのサブスクライブなところ
@藤本さん RestからGraphQLへのパラダイムシフトで、「ここは要注意!!」のようなものはありますでしょうか?
- キャッシュの使い方は気をつける/Appsyncで完結
- プラグインを使ってgit管理している
新しい技術のチームビルディング
- 採用で新しい技術のキャッチアップをしたい人を集める
- 当事者意識を持って、布教する
React Hooks公開から1年で得られた知見@西村 爽氏/株式会社Gemcook
@西村さん React Hooksにしてからテストフレームワークは何を使っていますか? - jestを使ってる - React testng Library - React Hooks testing Library
@西村さん HooksによるState管理とReduxによるState管理って全く別の考え方でいいのでしょうか、初学者はやはり両方通るべきでしょうか。
- ReduxとHooksは共存するものなので、両方学んだほうがよい
@西村さん hooksの登場でもうクラスは使わなくなったのでしょうか?あとhooksはuseEffectなど色々ありますが、全種類使ってる感じでしょうか?
- 新しいプロジェクトではクラスをつかっていない
- 基本的なものは使っているが、全種類は使っていない
React/ReduxにSelectorを導入したら幸せになった話@松井 真子氏/ヤフー株式会社
@松井さん 今バリデーションで同じことをするとしたらHooksを使った実装をしますか??
- 使う
- Hooksを使うとコードがスッキリしそうなので、使う
- Hooksメインでselectorも使う
- Hooksを使うとコードがスッキリしそうなので、使う
@松井さん バリデーションが簡単になったとのことですが、コードを書く量が相当減ったということでしょうか? - 記述量はだいぶ減った
@松井さん バリデーションは何かライブラリを使われていますか?
- 使っていない
React × Unity@青山 広大氏/ヤフー株式会社
@青山さん VRやARもできますか??
- SDKがでていればできるが調べたところだとなさそう
@青山さん 今回のデモンストレーション実装にどの程度の時間がかかりましたか?
- 2日
- それぞれになれている人はもっと早そう
React × Unity について質問です。 (1)UnityでC#ソースコードをビルドするとJSファイル変換されるのでReactからメソッドを読めるようになったのでしょうか?
- そのとおり
(2)Unityちゃんがカクカクしていたのはレンダリング結果がリアルタイムのアニメーションではなく静止画の紙芝居になっているからなのでしょうか?
- プロダクトとして出すのであれば、もっとシンプルにしないと重たい
React Nativeで家計簿アプリを作って得たもの@西仲 幸太氏/ヤフー株式会社
@西仲さん 普通のDBシステムと、firestoreの違いで苦労した点はありますか? - データモデルの違い - クライアント側で加工しないようにするにはどうしたらいいかを考えるのが大変だった
@西仲さん Firestoreはアプリと親和性が高く、かつ学習コストも低いのでメリット面が非常に大きいと感じました。逆にFirestoreを使うデメリットです(≒NoSQLのデメリットにもなるかと思いますが)とか、こういう状況ではFirestoreは使うべきではないという場面はどのような場面を想定されますでしょうか?
- サーバーサイドでロジックを持ちたいときはサーバーサイドをかませて使うべき
@西仲さん Firestoreの利点として,リアルタイムリスナー(Reactと親和性が良い)とあったと思うのですがReactのどのような点と親和性が良いのでしょうか?
- データフローを単一化できる部分が親和性が高い
感想
普段はヤフー株式会社の大阪オフィスで開催されているイベントが今回はオンライン配信という形で開催されていました。
ReactからGraphQL、Unityと幅広く紹介されていて、勉強になりました!
今回分のアーカイブは公開されないそうですが、次回以降は検討されるとのことなので、期待したいです。
2020/01/15 Mercari x Merpay Frontend Tech Talk vol.4 に参加してきました!
2020/01/15(水)に開催された Mercari x Merpay Frontend Tech Talk vol.4に参加してきました!
2020年初勉強会でした。
1Fの受付からの18F会場までだいぶ離れていたのですが、迷いそうになるポイント
で看板が建てられてて、迷わず勉強会の会場まで行けました。
イベント運営に慣れてる印象を受けました(もちろん好印象です)
目次
- 内容
内容
様々な方々がフロントエンドの技術に関して共有くださる形式でした。
Pros and Cons of SSR and JAMStack / Yutaka Sasaki氏
資料
ざっくり内容
背景
1ヶ月に1〜2本のLP開発
SSRのパフォーマンスがでない
- 1pod をスケールアウトさせていた
- 単純なLPを配信したいだけなのにコスパが悪い
いろんなパターンで負荷実験
Nuxt.jsがコンテンツの量でLPSの差がでる
Nuxt generate / JAM Stackをやってみる
- ユーザーエージェントで出し分けを実施
- nuxt generate 時にuserAgenent が取れない
- 常にユーザーエージェントを想定しないコードにする必要がアアル
- v-if の条件式にユーザーエージェントを入れると、サーバーサードとクライアントサイドのDOMに差がでる
- errorが発生
- v-showにすることで解決
- nuxt generate 時にuserAgenent が取れない
- ユーザーエージェントで出し分けを実施
開発中のキャンペーンを本番にでないようにする
- nuxt-generateに独自の定義を設定
いくかの nuxt lifecyle がブラウザ上で使えない
migrate the cashless campaign
- 特徴
- 期間が長め
- 運用で試して問題がなければ他の部分も移行していきたい
How to migrate the cashless campaign
環境
A new domain for campagin-web
SSR vs JAMStack
JAMStackのメリット
- MicroServieと比べて削減ができそう
- LPのようなペライチのサイトにはかなり向いている
NoCode で CMS と連携するデザインツールを作っている話 / Masaya Kazama氏
資料
ざっくり内容
STUDIOでやってること
- ホームページ・ビルダー的な
目指しているところ
- WHY: Everyone is creative.
- HOW:Unless your creativity.
- WHAT: ワークフロー改善、NoCodeで機能改善など!
フロントエンドでやってること
- コード → render関数 → ブラウザにレンダリング
現状の課題
- LPには適しているけど、データの概念がないためにブログみたいにできない
動的なサイトをつくる
GUIで環境で動的なページを作ることは複雑なので、人類はまだ発明をしていない
NoCodeでコードの表現力をいい感じに
- 要求を全部作ろうとすると大変
- 内部的には関数定義を保持
ワークフローのイメージ
- GUI:実行→定義をいじる→再計算されればよさそう
再ビルドしなくても表示できるようにする必要がある
- 各DOMのpropにVMにする
アコーディオンメニュー
- GUIの操作=実際のコードを埋め込む
何も考えなくても使えることが大事
- リアルデータをデザイナーも使えるように
CMSと連携する
- STUDIO用のCMSを作成
- 4月ぐらいリリース予定!
TypeScriptで型安全に入門したい / Atsuco Asaoka氏
資料
ざっくり内容
目次
- 型安全なに?/TSで防げるerrorとはなに?ができたら入門できたとする
なあに
どうやってはじめる?
- codesandbox を使って環境構築せずに実装
TypeScript は何者?
- JSとは別物
- コンパイル時にTypeScriptに typechkerが実行される
そもそも型って何?
- 型:値とその値に対して実行できる操作の集合
型の自動変換
- 暗黙的に型を変換をしてくれるので、errorの原因が特定しにくい
例)
1 + [2] // JavaScript は、12になる 1 + [2] // TypeSciptは、errorに出してくれる
- TSの静的型付けっていいよね?
- JSより強力な型付けができて、errorを判定しやすい
型付けって難しそう?
引数をべき乗にして返す関数=数字にするべき
name : type
でできる- いろいろできるけど、基本の形は同じ
TypeScriptで扱える型たち
- any
- ブラックボックス化しがち
- 手動で設定できるがなんのために存在しているのか?
- any
object型の定義
- オブジェクトのプロパティそれぞれに型を設定
- 必須じゃないプロパティの場合はオプションで設定できる
array
- 同じ型の値を入れるべき
- いろんな型を許可することもできる…
型安全ってなに?防げるエラーってなに?
防げるerror
- string を指定してる変数に数字で掛け算するとerrorがでる
- numberを指定してる変数に sliceするとerrorがでる
実際はこっちだった
- ほぼJSのままなので、わりといける
- vue cliなら環境構築簡単そう
- TSを使わなくても開発できてる、そう見えているだけで多分余計はコストが発生してるのでは?
なにに使う?
- 新規プロジェクトに入れるのはよさそう
- 既存に入れるのはつらそう
- 面倒くささ>メリットが逆転すればできるかも?
Web Assembly と画像・動画/Leonardo Ken Orihara氏
資料
内容
JavaScriptだけで画像をしよう
なぜ
- これからPWAアプリ増えそう!
- photoshop がWebで動く日も来るのでは?
- これからPWAアプリ増えそう!
さっそくやってみる
- 画像を横から90度にする
ほかにできること
- diffを取れる
注意
- wsm-imagemagickメンテされてなさすぎ問題
JavaScriptだけで画像をしよう
なぜ
やってみる
注意
- メンテされてなさすぎ問題
- コーデック不足で H.265 などがエンコードできない
- 実用として使うためには、 emscripten でemmake する必要あり
- でもできるよ
感想
多種多様なフロントエンドを聞けて楽しかったです。 JAMStack is なにそれおいしいの?からやりたい目的はなんとなくわかった、な状態になれた気がします。 SUTIDOはVue.jsを使ったサービスとして知っていたので、取り組みに関して詳しく知ることができて、よかったです。 ふんわり理解のTSをしっかり説明して頂けて、面白かった!TS = 型付けしてくれるなんだか便利なやつからもう少し近づいた存在になった気がします。
WebAssemblyも面白いことがよくわかりました😁
今年もいろんな勉強会に参加していきたいと思います!
業務未経験の初心者がエンジニアになるまでの話
はじめに
こちらは、サポーターズCoLab Advent Calendar 2019の13日目です。
書いてあること
- 情報科出身の業務未経験者がエンジニアとして転職した際に考えたこととやったことのお話
- 自分語りが大半なので、ご注意!
手短にまとめ
- いろんな勉強会へ参加
- カンファレンスのイベントスタッフに参加して、Web担当になり、知識を吸収
- とりあえずなにか作ってみる
内容
前提
現在、社会人3年目で、すでに2社目になります。
2018年12月に入社したので、ちょうど丸1年在籍しています。
現在は、フロントエンドエンジニアとして自社サービスの運用・開発を行っています。
現職に転職するまでの振り返りを書いていきたいと思います。
前職では、自社サービスのUIリプレイスの案件を担当しており、コンセプトの設計、Webサイトの情報設計、ユーザービリティテストおよび検証、デザインや開発の進行管理、検証テスト、などと、サービス開発におけるデザイン、開発を除くすべての工程を担当していました。
(担当していた範囲が広すぎて説明がややこしいので、「ディレクションやってました」と聞かれた際にはごまかしがちです…)
もとのスペック
転職前のステータスとしては、以下の通りです。
- 情報系大学院出身
- アウトプットは大学の授業と研究のデータ収集のためにつくった~ゴミ~プログラミングのみ
- プログラムは、調べながらどうにか書ける程度
- 最新技術が好きで、興味のある範囲は広め
転職前の状況
エンジニアとして転職する上で、必要なものは「アウトプット」と継続して学び続られる「努力を証明すること」だと思っていました。
「アウトプット」に関しては、もともと期限のないものは後回しにしてしまうタイプなので、アウトプットができて、期限がきまってる開発がないかな、と考えていました。
(この時点でエンジニアの素質がない、と言われても仕方ないですが…)
受託でお仕事が思いつきましたが、業務未経験の自分がやりきれる自信がありませんでした。
ただの言い訳になってしまいますが、前職では早朝に行って、夜中に帰ってきての生活を送るくらい、仕事が立て込んでいました。(※いわゆるブラック企業ではありません)
継続して学び続られる「努力を証明すること」に関しては、勉強会へ継続して参加していたので、その際のメモをgistに投稿していました。
どうやって「アウトプット」を作るのか
とある日、なにかのカンファレンスに行きたいと思い、いろいろと調べていたところ、ボランティアスタッフの募集を存在を知りました。
ボランティアスタッフの一覧には、システム担当者があり、これだ!と思いました。
カンファレンスは開催日時が決まっており、公開期限が決められています。これならいけると思いました。
ボランティアスタッフとして応募し、システム担当者となりました。
他の担当者には素直に、実装経験はありません、とお伝えして担当をさせて頂きました。
担当していたサイトは、こちら| PyConJP2018 使用していた技術は、Nuxt.jsとUIkitです。
私が担当したのは、レイアウトがないページのUIkitの組み込みや小さなコンポーネントの実装だけでしたが、Nuxt.jsについて教えて頂いたり、レビュー頂いたりと本当に勉強になりました。 皆様ありがとうございました…!
こうして転職へ…
無事に上記の「アウトプット」ともうひとつ別のアウトプットを携えて、転職活動へと乗り込んでいきました。
エージェントに4社登録して、履歴書の添削や相談に乗って頂いていました。
もちろん業務未経験なので、書類選考が落ちる率も高く、面接に行けても実力がちょっと…と言われてご縁がない会社もありました。
いろいろありましたが、ご縁があった今の会社でエンジニアとして働いています。
さいごに
学んだ技術を仕事を活かせるため、エンジニアとして転職できて本当によかったな、と思っています。
エンジニアとしてはまだまだひよこなので、一人前になれるよう精進してまいります。
2019年は、HTML、CSSの基礎技術を学ぶことに注力していました。 2020年は、基礎技術を強化しつつ、言語ももちろんですが、設計思想などの新しい知識を身につけていきたいと思っています✨
下記の技術が最近気になっているので、キャッチアップしていきます🤲🏻
ここまで読んで頂き、ありがとうございました!
2019/12/11 GMO Developers Nightに参加してきました!
2019/12/11(水)に開催されたGMO Developers Nightに参加いたしました!
この年に新しく開業された「渋谷フクラス」にGMOグループのオフィスが入るとのことで、その記念のイベントだそうです。
セッション
3セッションあり、GMOグループに在籍されている様々な方々が登壇されていました!
以下、雑に書いたメモです。
解釈誤りや聞き間違い、誤字脱字が大いにありえます。
あらかじめご了承ください。
アプリケーションセッション
アプリケーション開発者の多様性
スピーカー
- GMOあおぞらネット銀行 櫃ノ上 貴士氏
- 公開APIのマネジメント
- GMOアドマーケティング 石丸 智輝氏
- 広告周り
- GMOペイメントゲートウェイ 橋本 玄基氏
- SRE的なやつ
モデレーター
- GMOインターネット 成瀬 允宣氏
内容
多様性メインで話をしていくそうです。
レガシーとの戦い
- GMOペイメントゲートウェイ 橋本 玄基氏
- レガシーと戦ったからこそアワード受賞できた
- レガシーありがたい
300APIが1つのアプリケーションになっていた
- 長期的に見て、すべてを書き換えるのは難しいので、マイクロサービスにしていく
- 戦えるサービスとして頑張っていく
石丸さん
- Railsは短期で使う分には困らないが、長期的な運用では困る面が多い
GMOあおぞらネット銀行 櫃ノ上 貴士氏
- 新しいサービスなので、レガシーを残さないように設計している
アプリから見たインフラ
- GMOペイメントゲートウェイ 橋本 玄基氏
- 今、インフラなので、聞いてみたい(テーマ発案者)
アプリ側はネットワークの構築を考えなくても使える
-
- オンプレ→クラウドに移行したので、身近
GMOあおぞらネット銀行 櫃ノ上 貴士氏
- クラウドに移行するために検証中
- 使う側としていろいろとやっている
- 今はアプリにはインフラの知識が、インフラにはアプリの知識が必要で、境目がなくなってきている印象
コミュニケーション
- GMOペイメントゲートウェイ 橋本 玄基氏
- Face to Face と チャットとの使い分け
- 拠点が別れてしまっていて、どういう風にやりとりしているか聞きたい
- GMOアドマーケティング 石丸 智輝氏
- 1フロアに全員いる
- 同じフロアにいても、Slackで
GMOあおぞらネット銀行 櫃ノ上 貴士氏
- 2フロアに分かれて働いている
- 前までは1フロアだったので、やりにくさは感じつつある
エンジニアの育成はどうしたらいいのか?
- レビューとかどうしたらいいのか
- すべて文章で書くと、感情が乗らないので大変そう
- きつい言い方にならないように、柔らかくなるように絵文字をつかたり
- レビューをすること=エンジニアの力の見せ所
- レビューとかどうしたらいいのか
登壇まわり
- 毎週金曜にグループでイベントしていきたい✨
最後にひとこと
GMOあおぞらネット銀行 櫃ノ上 貴士氏
- 年を取るごとに失われるエネルギーを奮い立たせている
- 銀行をどんどん使ってもらえるようにやっていきたい
- 銀行だからできるサービスを色々とやっていきたい
GMOペイメントゲートウェイ 橋本 玄基氏
- 決済の会社でより安全できるサービスで
- 世界を取れるまで頑張っていきたい!!!
- GMOインターネットグループのエンジニア、のイメージはあるものの、GMOアドマーケティングとしてやっていきたい
広告のマイナスイメージを払拭したい
GMOインターネット 成瀬 允宣氏
- 情熱大陸にでること!!
感想
登壇者の方々がすでにアプリケーション開発の枠を超えたSREやAPI開発の方と幅広く、領域の広がりを感じました。
リモートにおけるエンジニアの育成はこれからどの企業も悩むポイントなのかなーと思いました。
レビューはエンジニアの力の見せ所は本当にそうだな思いました。
レビュー&レビュイーともに個人が指摘ではなくて、よりよいものを生み出すために共同作業していると思う心が大切なのかな、と思いました。
インフラ/クラウドネイティブセッション
GMOインターネットグループ各社メンバーが語る 知られざるインフラの裏側
スピーカー
GMOインターネット 郷古 直仁氏
- ConoHaやオープンスタックを使ったサービスを担当
GMOクラウド 佐藤 慎治氏
- 新規プロダクトの立ち上げから構築、監視など幅広く担当
GMOインターネット 元内 柊也氏
- コンテナ化、クラウドネイティブを伝えたり、手を動かす担当
GMOペパボ 山下 和彦氏
- 全社の技術基盤を担当
モデレーター
- GMOペパボ 常松伸哉氏
内容
入社のきっかけ
GMOインターネット 郷古 直仁氏
- オープンソースの仕事をしたくて、入社
GMOクラウド 佐藤 慎治氏
GMOインターネット 元内 柊也氏
- オープンスタックの研究をしていたので、商用でやっている会社に入りたかった
GMOペパボ 山下 和彦氏
- 普段は福岡
- 前職でPerlを実装している人にあって、プログラムをやりたいと思った
- Ruby on Railsのアプリを作って、入社した
現職でやってること
GMOインターネット 郷古 直仁氏
GMOクラウド 佐藤 慎治氏
GMOインターネット 元内 柊也氏
- k8sで動くアプリケーションのエコシステムを構築、評価をしている
GMOペパボ 山下 和彦氏
インフラの変化・課題
GMOインターネット 郷古 直仁氏
GMOクラウド 佐藤 慎治氏
GMOインターネット 元内 柊也氏
- 2019年の際の20代前半と35歳以上の方の開発フローが異なっているはず
- 開発環境
- 35歳以上の人:どこからからサーバーを借りて実装
- 20代の人:目の前のMacで開発して、デプロイしたいと思ったときにサーバーを使う
- こういった人たちに対してよきServiceを提供していきたい
GMOペパボ 山下 和彦氏
- 物理サーバーにVM立てるだったから、仕組みそのものを配布できるようになった
- 個人も事業を行っている身でも同じ
- 物理サーバーにVM立てるだったから、仕組みそのものを配布できるようになった
最近のアツイ技術
GMOインターネット 郷古 直仁氏
GMOクラウド 佐藤 慎治氏
- Serviceを使ってる側にServiceを提供している
- Docker、k8sを触ってみたい人は多い
- ローカルで動いているものをそのままサーバーに載せれると思いこんでいる方もいるのもひとつ
- サーバーは優しく有りたい
GMOインターネット 元内 柊也氏
- 『SRE』
- アプリケーションのk8sのエコシステムを使って開発やオペレーションを自動化できるオペレーターを使うことでインフラがやりたかった、Serviceにコミットできることが技術としてアツイ
GMOペパボ 山下 和彦氏
GMOグループのエンジニア交流
(時間が足りず…!!!)
CTO / VPoEセッション
CTO/VPoE 対談 〜技術責任者からみたインターネットの今とこれから〜
スピーカー
モデレーター
- GMOインターネット 稲守 貴久氏
内容
どうして今の立場になった?
GMOメディア 別府 将彦氏
- to Cサービスをメインとして、提供している
- CTOではなく、組織デザインを繰り返しているうちに詳しくなった
GMOあおぞらネット銀行 矢上 聡洋氏
- B to B to Cでサービスを行っている
- 外資系のITベンダーでエンジニアでアーキテクトのリーダーをやっていた
- 縁があって、CTOに
GMOペパボ 柴田 博志氏
GMOグループの技術的な交流がありますか?
- グループ横断で新卒技術研修もある
今までの開発課題とこれからの戦略
GMOペパボ 柴田 博志氏
- 事業部制のとっている
- 事業部でそれぞれ判断できるのがメリット
- 一方で細分化しすぎて、発生した同じ課題を別のソリューションをしてしまう
- 事業部(縦)と職種(横)で見て、調和が取れるようにやっている
- 事業部制のとっている
GMOあおぞらネット銀行 矢上 聡洋氏
- 開発ができない
- 各アプリケーションの自動化ができていない箇所が多く、運用でいっぱいいっぱい
- 足元の作業工数を減らしていくところを考えている
- スタートアップ×金融業の難しさを実感中
- 開発ができない
GMOメディア 別府 将彦氏
強い開発組織デザインとは
GMOペパボ 柴田 博志氏
- 強い開発組織=失敗できる組織
- 成功体験だけだと、学びがない
- 100万円の売上を作ろうとなったときに結果として80万円なったときに、なんでだっけ?どうしてだっけ?みたいなことを考えることが重要
- 失敗を個人に責めるのではなく、チームで考えて解決できるように導いていくカルチャーが大切
- 失敗を許容する、をどうしてる?
- 偉い人が謝るだけで済むなら大したことない
- ユーザーが困っていること、課題の部分をいかに早く、個人の責任ではなくて、チームの課題としてやっていく
- 強い開発組織=失敗できる組織
GMOあおぞらネット銀行 矢上 聡洋氏
- 銀行は、システムのトラブルは問題に発生するのでおいておいて…。
- それぞれの職種の融合って大切
- 意識改革が大切
- エンジニアをリスペクトしながら事業をやっていこうぜ
GMOメディア 別府 将彦氏
- 人や組織の変更・成長できる機会をつくることって大切
- 世の中の変化していく課題に対して解決できるチームを目指していけたら良い
注目している技術トレンド
(時間の都合で省略!)
来場の若い開発者たちにひとこと
GMOあおぞらネット銀行 矢上 聡洋氏
- 働くという観点で、仕事は楽しくないと仕事じゃない
- 8時間×5日×40年=8万時間働いている
- 仕事が楽しくないと、人生楽しくならないのでは?
- A(あかるく)T(たのしく)M(まえむきに)
GMOペパボ 柴田 博志氏
- インターネットってブラウザで見れる、なにかと思いがちだけれども、IoTを代表されるようにいろんなものがつながっていて、これもインターネット
- インターネットって可能性ってこれからももっと幅広く広がっていくはず!
- 調べてみて
- GMOメディア 別府 将彦氏
懇親会
- 300名近い参加者とGMOインターネットグループの技術者で交流しました!
写真はあれですが、とても美味しいお食事とともに久しぶりな方に出会えたり、いろんなお仕事をされている方と話せたり、楽しかったです。
感想
GMOグループって本当にインフラを中心にいろんなサービスがあるなぁと改めて実感しました。
自分がエンジニアとして目指す像っていまいち作れてないなーと思ったので、考えよう。
2020年から毎週金曜にイベントを開催されるそうなので、また遊びにいこうと思います✨
2019/11/20 表参道Web勉強会(OWEB)/Vue.js/PWA/JavaScript…新&定番なんでもあり#9 に参加しました!
2019/11/20(水)に開催された表参道Web勉強会(OWEB)/Vue.js/PWA/JavaScript…新&定番なんでもあり#9 に参加してきました!
感想
今回も先に感想を。
LT登壇者が遺伝的アルゴリズムからVue.jsまで幅広く
それぞれに好きなことを発表していて、皆様イキイキしているなー!という印象でした。
言語を作られている方が登壇されていることにはびっくりでした!
世の中っていろんな人がいるなぁと改めて思い、パワーをもらえました!
私も頑張ろう💪
LT会
ソフトドリンクを頂きながらお話を聞くスタイルでした!
Laravel DB Designer@daisu_yamazaki氏
Laravel DB Designer の紹介
- 開発環境
- FireBaseと連携
- できること
- ER図で設計したマイグレーションファイルを作成
- 外部キーの制約も作れる
- もっと使いやすく
- 前の内容にリバースしたい
参考資料
Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜@KazushiOhhiraさん
Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜のブログの概要紹介
- Vue.jsをサービス設計で困ること
- 関係者で認識があっていない
- 実装してると認識しない
- 迷走した
- それぞれの依存関係や自分の位置もわからない
- 上記から設計地図(造語)を作ろうと思った
- 実例を踏まえてブログを書いているので、読んでみてください
参考資料
AMPの有効な使い方@Azusa Ito氏
AMPとは
- メリット
- モバイルでWebページを高速に表示する技術
- デメリット
- 処理を止めるとリダイレクト処理が必要になるなどと処理が面倒
- いつまで保証されるかわからない
有効利用
- 観光地の飲食店でAMPが有効利用が可能!
- WordPressのThemeにAMPを設定
- トップページのAMP化
- サーバの負荷対策に使える
- 災害時の対応などにも使える
ブラウザについて@YukiOzasa氏
Web業界での一コマ
- それ?キャッシュじゃない?みたいなパターンがある
- どこで、なぜ、キャッシュされているのってところも大切
- ブラウザの理解が必要
Chromeのブラウザの話
- キャッシュには種類がある
- 開発者ツールで見ると「どこで」がわかる
- ブラウザのメモリキャッシュされている画像は、オフラインで見られる
- かの有名な画像たち
- こういったところからどこにキャッシュすると、よいのかがわかるようになるよ
あなたの知らないASP.NETの世界@Sonic氏
- 個人的な見解です
ASP.NETの歴史
- 1996〜 開発が始まっている
ASP
- ActiveServerPage
- ASP .NET WebForm
- 2002〜
- コンパイラ言語
- ASP .NET Core MVC
- 2009〜
- ASP .NET Core SPA
- 2019〜
- typescriptになります
Ma_gician <Vue にはできない事>@StewEucen氏
Ma_gician
- マジシャン(仮)
- 今年末にOSS化、名称決定がされる予定
比較
- Ma_gician は、Scriptがないよ
Vue.jsにできないこと
- Vue.js
- ブラウザの仕様でscriptタグがあるため、開発者ツールで実行してもマウントされない
- Ma_gician
- 開発者ツールで実行して、そのまま動作する
- scriptタグがないため
- 開発者ツールで実行して、そのまま動作する
- メリット
- マウントしたまま、Vue.jsのコードを保存しておける
エンジニアの心の保ち方@goombeer79氏
エンジニアに必要なスキルとは?
- 個別のスキルに「心を保つ力」が必要
- なぜ?
- エンジニアは、不確実性を扱う
- 自分が体験したこと
- 入社してすぐに認証基盤を担当
- 開発後にIE11で動かないことが判明
- モチベーションが下がる
- やったこと
- テストを細かくする
- リリース単位を細かくする
- リリース作業を垂れ流す
node.jsとLaravelで効率な営業ができる@YosukeKinoshita1012氏
営業先リストをスクレイピングで取得
- 営業は数が重要
- 一度開発すれば簡単にできる
自動でメール営業
- とんでもない数のメールアドレスを取得
- node.jsでメール配信
- nodemailer
- 方法を間違うと法にふれるそうです(注意!)
反響率が高い問い合わせフォーム営業
@okita_kamegoro 氏
- 本日はおやすみ…
TypeScript未経験者が社内向けJSライブラリを置き換えた話@pvcresin氏
やったこと
- 学んだこと
- 公式ドキュメント
- がんばらないTypeScript
- 実践TypeScript
- 準備
- 導入方法を検討
- 置き換え
- ESLintを設定
- 型定義ファイルを作成
導入してよかったこと
- 型を決められた
- 関数と向き合えた
遺伝的アルゴリズムを体験できるシンプルなシミュレーションツールを開発中なのでざっくり紹介します@HayatoMatsumoto氏
遺伝的アルゴリズムとは?
- 強い遺伝子が勝ち残る
- 解を探索する方法が必要
- 最適化する必要がある
- なぜ、トーナメント、交差、突然変異ってなぜ必要?
- 局所解にハマる問題に対処
今回とく問題
スポンサーLT@Forkwellさん
- キャリアップエンジニア
- 市場評価≒社内評価が釣り合っている人
- 市場評価と社内評価をうまく釣り合わせている
- 市場評価ってどうやって見極めるの?
- スカウトがおすすめだよ!
2019/10/28 FashionTech Engineering Meetup#4に参加してきました!
Aoyama FashionTech Meetup by WORLD Group が主催されているFashionTech Engineering Meetupに参加してきました。
業界で絞られているカンファレンスに参加するのは初めてだったので、新鮮な気持ちになりました。
感想
あえて先に感想を。
参加されていたどの企業もファッション業界を盛り上げていくぞ!という勢いとエネルギーを感じました。
ただ技術ファーストではなくて、ファッションの中での課題に対して技術をうまく使って解決していきたい、社会へ貢献したいという想いがあるな、と想いました。
それぞれ会社が目指すファッションへの課題解決のアプローチが適切ですごいなーという印象です(小並感)。
あと、CTOや社員の方も日本籍ではない方が多く、グローバルな会社が多い印象でした。グローバルな企業で働きたい(英語勉強しなおさないと…)。
内容
主催企業LT
- 嶌克繁氏@株式会社オムニス
- それぞれのプロダクトに合わせて技術、アーキテクチャ選定を行っているそう
LT
Jin Koh氏@Bodygram Japan株式会社
ざっくり内容
- デジタルの身体データベースが作れる
- 保険、ライフスタイルなどとアパレル外にも展開できる
- エンジニア(DL,ML, Front,Backend) への投資を行っている
和泉 信生氏@シタテル株式会社
ざっくり内容
- 服作りをかんたんに
- Vチューバーと視聴者と一緒に作って、Tシャツを売ったりしています
- ストーリーがあるからこそ売れる服がある
村上 大昌@株式会社Sapeet
ざっくり内容
- 着用のイメージを持ってもらうためのサービス
- 会社で工夫していること
- 作業の効率化
- 時間が一番貴重
- デザイナーにはデザインをしてもらいたい
- 取り組んだこと
- 構成構成のコード化
- 繰り返し処理を自動化
- ノイズ検知プログラムの開発
荒井浩己@株式会社ニューロープ
ざっくり内容
- AIシステムとはなにか、どう作るのか
- 画像認識のSassを作っている
- AIシステムならではの課題も多く存在する
森永マーク氏@株式会社Virtusize
ざっくり内容
どちらの企業も人を募集しているようです。
Bodygramのデモタイム
上記のBodygramのデモタイム!
- 専用の服の着用なし
- 背景には計測する本人以外も写っている
という状況で、正面と横の2枚の画像から計測。
算出までかかる時間は30秒〜40秒で、誤差は数cm〜数mmという精度…すごい。
そもそもブランドや企業によって、首周りの算出の仕方が違うため、撮影した画像から3Dモデルを作り計測したところから値を算出して、どの企業にも合わせられるようにしているとか。
さすがのこだわりです。
パネルディスカッション
質問に対して各企業の方が答えてくださる形式でした!
サービス立ち上げや運営をしていく中での苦労話を教えて下さい
Jin Koh氏@Bodygram Japan株式会社
- メディアではいい話だけが取り上げられがち
- 現状までに至るまで、背景には苦労やたくさんある
- 精度があげてていくため、引き続きデータ収集活動を行って、ポジティブなループを推進している
- 夢を見ることはいいことだけど、足を引っ張られることだってある
- 諦めなければ進むことができるので、諦めずに頑張っていってほしい
和泉 信生氏@シタテル株式会社
- 世の中の投資家たちは「技術」を求めがち
- 投資家が求めていても、ユーザーが求めているのか?を苦悩して考えた
- 解決したい問題にアプローチするためにうまく技術を活用していった
村上 大昌@株式会社Sapeet
- 社員、ユーザーとゴールを共有するのが大変
- テックをファッションに導入したいっていうふんわりな思いをどう汲み取って、価値提供できるかを常に考えている
荒井浩己@株式会社ニューロープ
- 3名で始めた会社で、コワーキングスペースでお仕事していた
森永マーク氏@株式会社Virtusize
- プロダクト面
- エンジニアの好みが全員違う
- コードのマイグレーションでどうやって組み込んでいくか
- FASHION×Techは、nice to have な立ち位置なので大変
使用しているスタックを教えてください
森永マーク氏@株式会社Virtusize
- Frontend
- React/Vue
- Backend
荒井浩己@株式会社ニューロープ
- Backend
- 機械学習
- インフラ
村上 大昌@株式会社Sapeet
和泉 信生氏@シタテル株式会社
- Frontend
- Vue.js
- Backend
- インフラ
Jin Koh氏@Bodygram Japan株式会社
- プロダクトの戦略から考えて技術を選定している
- 正確性
- ユーザーフレンドリー
- iOS/Andorid/Web全ても使っている
- 信頼性
- プライバシーデータを取り扱っているので、堅牢なインフラを使っている
求めるエンジニア像を教えてください!
Jin Koh氏@Bodygram Japan株式会社
- 提供できる環境について
和泉 信生氏@シタテル株式会社
- リアルテックカンパニー
- 同じことをいかに早く正確にできて、ビジネスへの理解があるエンジニア
村上 大昌@株式会社Sapeet
- 泥臭さを追求できるエンジニア
- わりと泥臭いチューニングがあるので、がっつり追求できる人がおすすめ
- 言われたことだけじゃなくて、幅広く
荒井浩己@株式会社ニューロープ
- プロダクト思考/セルフマネジメントができるエンジニア
- 自社のSasSを磨き込めるエンジニア
- 仕事が作っていけちゃうスター★なエンジニアがほしい
森永マーク氏@株式会社Virtusize
- 優秀なエンジニアを採用したい
- グローバルなエンジニアを採用していきたい
- コミュニケーションがしっかり取れる/意見があればなんでも言えるエンジニア
入社する人にFASHIONへの興味は求めますか?
Jin Koh氏@Bodygram Japan株式会社
- FASHIONにこだわっているわけではなく、社会を良くしていきたいという思いが大切
和泉 信生氏@シタテル株式会社
- FASHIONへの興味は必須ではない
村上 大昌@株式会社Sapeet
- 必須ではない
- 技術で課題解決をできる人
荒井浩己@株式会社ニューロープ
- 必須ではない
- 技術が好きな人
森永マーク氏@株式会社Virtusize
- 女性エンジニア採用をプッシュしている
- Women Who Code の主催エンジニアがいるよ
Q and A
Z社に関してどう感じているか
Jin Koh氏@Bodygram Japan株式会社
- 競合だと思っていない
- 驚異よりもシンパシーを感じ、尊敬をしている
- あのサイズでイノベーションを起こし続けているのは尊敬を感じる
- スーツの発表しかり、この分野でのパイオニアだと感じています
- エンジニアにとって働き方の好みがあると思う
- サイズを図る方法のユーザーの体験もいろいろあってよいと思う
村上 大昌@株式会社Sapeet
- 技術に関しては尊敬できる部分がある
- FASHIONだけにこだわっているわけではないので、別の業界にいかしていければよい
- お互いに成長し会える企業でありたい
森永マーク氏@株式会社Virtusize
- VSしている企業さんパターンとZOZOとうまくやっている企業さんパターンがある
- いまのところ困っていない
どれぐらいのプロダクトを回しているの?
村上 大昌@株式会社Sapeet
- あたため技術を含めると5〜6個ぐらい
- メインは、サイジング、姿勢解析
- 10名のエンジニアで担当
- 1名が2〜3プロダクトを担当
懇親会
- 積極的に名刺交換や情報交換をされている方が多く、私自身もあまり関わらない業種の方とお話できてよかったです!
- 提供された軽食がトルティーヤチップスとタコスでびっくりしました(写真取り忘れた…)
- 登壇者の方にお誕生日の方がいらっしゃってお祝いがありました🎉
- おめでとうございました!
2019/09/25 【シューマイ】Tech Lead Engineerから最新技術を学べ!Vue.js編 参加してきました!
2019-09-25(水)に開催された【シューマイ】Tech Lead Engineerから最新技術を学べ!Vue.js編 に参加してきました!
1人30分のLTなので、LongTalkでした!
以下雑なメモです。
「Nuxt.js + Firebaseでの開発と高速化に挑んだ話」
株式会社リビルド 代表取締役 鈴木 孝之氏
ざっくりすぎる概要
Firebase をなぜ導入したの?
- 技術スタック
- 関連ドメイン
- 各画面でチャット機能を作りたい
- どう作っていくのかを議論
- 様々な調査
- ロングポーリング
- WebSocket
- LaravelEchoで実現する方法を調べたものの難しそう
- Firebase の導入前の懸念点(2019年1月時)
- 無料枠だと1GBしか使えない
- 検索クエリに制限あり
FireBaseを使ってみた
- JSONの構成
- usersコレクション
- roomsコレクション
- メッセージなどの情報が入っている
- roomsコレクション
- usersコレクション
- シーケンス図
- フロントだけの図
- Usersにサブコレクション理由
- 実装当時は検索が困難だったので、Usersにサブコレクションをもたせた
- リアルタイムを担保する部分
- 変更を感知してチャットを更新
ビルド高速化でやったこと
- Webpack Bundle Analyzer をファイルの関連性の可視化ができる
- 改善案
- moment.js が重い
- 複数の言語を全部読み込んでいる
- 日本語だけでいいのに他の言語も読み込んでいた
- 必要な分だけに絞った
- 日本語だけでいいのに他の言語も読み込んでいた
- 複数の言語を全部読み込んでいる
- loadsh.js が重い
- ディープコピーにしか使っていない
- クリーンJSに変更
- 1MB軽量化に成功!
- moment.js が重い
まとめ
- 思ったより導入コスト高め
- 少し複雑なアーキテクチャになった
- 知見があれば回避できたかも
質疑応答
「Firestoreから(チャットユーザの)プロフィール画像は取れない」とおっしゃっていた理由が気になります。URLをFirestoreに保存しておくのならできるのでは、と思ったのですが、どんな設計だったのでしょうか?また、RDBとNoSQLの使いわけについて詳しくお聞きできたらうれしいです!
- やり方はある
- DBのS3に画像のURLを付与すれば可能なはず
- Usersによけいな情報を持ちたくない
- DBが分断していたため
Day.js は検討されなかったのでしょうか?
- 日付周りでなにか原因があると思ったので、検討してなかった
ちゃんと聞いてなかったかもなのですがmoment.jsやlodash.jsが遅いっていうのを可視化してた図は何かのツールですか??
- webpack-bundle-analyzer
- コマンドを叩くだけで確認できる
GMOインターネット株式会社 デベロッパーエバンジェリスト 成瀬 允宣氏
Vue.js × フロントエンドのつくりかた
ソースコードを見ながら説明してくださる形式!
ざっくり内容
- BuildersConで登壇されていた内容を寄りコードに関して説明する形でお話されていました!
つつましいエラーハンドリング
- エラーハンドリング
- エラーハンドリングは、ソフトウェアの使い勝手を決定づける
- やりたいことをやってもらうがソフトウェアの本質のはず
- 拾ってあげるべきエラー
- ユーザーが回復できるエラー
- クライアントの回復できるエラー
- バリデーションを表示
- 画面ごとでハンドリング
- サーバーの回復エラー
- 画面ごとにハンドリングしたい→したくない!
- 通信ライブラリ(axios)をラップ
- 細かく制御したいときもある
- オプションパラメータを付ける
- 確認画面から入力画面に戻るエラーを追加
- オプションパラメータを付ける
- 画面ごとにハンドリングしたい→したくない!
- クライアントの回復できるエラー
- ユーザーが回復できるエラー
- エラーハンドリングは場合分け
- 成功したときはハンドリングする
- 失敗/例外
- ハンドリングする?しない?
- ハンドリングするときにオプションで対応する
- 基本的にはなにもしなくてよい状態に
- 必要なときに差し込めるように
- 基本的にはなにもしなくてよい状態に
認証認可の戦略
- 強力な仕組みが必要
- 人力を排除する
- 認証と認証切れ
- 認可が必要ではないページを設定する
- ルートの認可
- すべてのルートは最高権限が必要にする
- 認証が不要な画面は設定
- すべてのルートは最高権限が必要にする
- リソースの認可
- サーバー側で403を発行
全体的なコンポーネント構造
- サーバー側で403を発行
- 子同士がやりとりするのはNG
- 相互参照しあってはいけない
- 親のルートページが司令塔になるべき
- 上から下はメソッドで、下から上はイベントで実装するべき
- ページ遷移や通信をする箇所
まとめ
- 無駄な努力はせず必要な努力をする
- チームで注力するべきところはどこかを考えながらコアな部分を作っていこう
質疑応答
エラーメッセージなんですがサーバーからどれくらい詳細に返しますか??詳しく返しすぎると良くないケースがある場合がある気がしています。
- フロントで返している
wraxiosはかなり作り込んでるように思えますが、どれくらい時間かけて作りましたか?おおよそでいいので教えてほしいです。
- 数時間ぐらい
SPAの認証はJWTでやっていますか??まだなんとなく怖いのですが…
- JWTはSessionとは違うものらしい
- ヘッダーでトークンを返して、ページに埋め込んでいる
stateのバケツリレーしたくない時はvuex使うかな
- 書くときに楽するじゃなくて、読むときにどうなのかを意識して成瀬さんはつかっていない
- コンポーネントが会話し始めちゃうため
複数ページで全く同じ通信内容が発生した場合はどうやってコードの重複を防ぎますか?api.jsなど通信をライブラリ化してページからはそれを呼び出しますか?
- コンポーネントが独立をさせることで重複を防ぐ
懇親会
- シューマイを食べながら懇親会!
感想
- はじめの登壇者の方のBDD=ビーチ駆動開発は斬新で面白いなーと思いました!
- わりと初心者向けの内容だった印象なので、初心者エンジニアとしてはなるほどなーと思うことが多かったです!
- またフロントエンド関連の会があれば参加します🌟