「GitHub Actions Meetup Tokyo β」に参加してきました

  • GitHub Actions Meetup Tokyo βに参加してきました。

gaugt.connpass.com

タイトル 発表者
新GitHub Actions のはじめかた @miyajan
GitHub Actionsで WebDriverどこまでやるの? @hiroshitoda
GitHub Actions Parallel Testing @yasuhiroki
GitHub Actionsと(主にreviewdogを使った)Automated Code Review @haya14busa
他のCIサービスと比較してできることできないこと @Kesin
Github Actions でハマった点と解決方法 @kawasin73
自作Github actions入門 @Naturalclar

GitHub Actions のはじめかた

  • @miyajanさん

GitHubActionsをはじめるとき

既存のワークフローを探す時

アクションを作る時

既存のアクションを探す時

予想外の挙動で困った時

GitHub Actionsで WebDriverどこまでやるの?

  • @hiroshitodaさん

GitHubActionsが動く基盤

GitHubActionsで最初から使えるソフトウェア

Appiumの利用とNested Virtualizationの壁

  • Androidエミュレータを動かせるのはmacOSだけ
    • Linux/Windows環境がNestedVirtualizationに対応してないから
  • 公開Dockerイメージを使える
    • AppiumでもDocker使っていい感じにしたい
    • NestedVirtualization問題
    • やるならmacOS
    • budtmo/docker-android
      • 5~6GB
      • 2分くらいでpullできる
    • bitriseio/docker-android
      • 26~27GB
      • キャッシュできない環境では実用に耐えない

GitHub Actions Parallel Testing

  • @yasuhirokiさん

並列テスト

複数のテストを分割して並列に実行したい

  • matrixを使うとできる
    • 自分でコードもちょっと書かないといけない
  • CircleCIは実行時間が均されるように自動で振り分けてくれる
    • knapsackを使うといい感じにできる

テスト結果を集計したい

  • artifactを使う
    • それぞれのノードで見えるディレクトリにファイルをアップロード
    • それらをダウンロードして集計する

Tips

GitHub Actions と (主に reviewdog を使った) Automated Code Review

  • @haya14busaさん

GITHUB_TOKEN

  • secret.GITHUB_TOKENを明示的に指定したときだけ使える
    • forkしたリポジトリからはちゃんと見えないようになってる
  • リポジトリにインストールされたGitHub Appのアクセストーク

Check API

  • コードにコメントをつけられる
  • Review APIより使いやすい
  • reviewdog

他のCIサービスと比較してできることできないこと

  • @Kesinさん

ビルドキャッシュとアーティファクト

マトリックスビルド

  • nodeの複数バージョンでJobを実行といったことができる

マトリックスビルドとconainter

  • マトリックスで指定したイメージ上でテストが実行できる
  • actions/setup-xxxを使わなくてもよくなる

Github Actionsでハマった点と解決方法

  • @kawasin73さん

プライベートリポジトリ

  • プライベートリポのインストールが難しい

3rd Party Action信頼できない

  • 大もとはGitHubリポジトリ
    • 差し替えられても気づけない
  • フォークして使いましょう
    • 中身を確認して使う

git cloneに失敗する

  • サーバ鍵の検証を諦めて無視した
  • GitHubないからGitHubリポジトリにアクセスするので中間者攻撃はないだろう

セマンティクスバージョニングがない

  • v0.1はv0.1.0にならない
  • Actionsのバージョンはタグとの完全一致

自作Github actions入門

  • @Naturalclarさん

actions-toolkit

github.com

  • @actions/core
  • @actions/exec
  • @actions/io
  • @actions/github
  • @actions/tool-cache

「CROSS Party 2019」に参加してきました

  • CROSS Party 2019に参加してきました。

2019.cross-party.com

業務ハック 〜業務効率化にコミットする職人達の世界〜

  • 野秋 拓也さん(DMM.com)
  • 廣氏 宣勇さん(DMM.com)
  • 廣野 美里さん(freee)
  • 髙木 咲希さん(SonicGarden)

業務ハック

  • 業務改善をエンジニアリング行うこと

事例

  • Slackで相手の名前とか入れると参加者の開いてる予定検索して提示してくれる
  • 受託開発で業務ハック
  • slackとかgsuiteと使うようになって業務ハックしやすくなっている
  • 全部自分でゴリゴリに作るとかはそんなない
    • いろんなサービスを組み合わせて解決させる
  • kintone
  • Zpier

[基調講演] 夢を形にする技術 〜 大規模開発におけるサイエンスとエンジニアリングの境界を科学する

はやぶさプロジェクト

  • 無人探査機によるサンプルリターンミッション

ユーザ要求

  • IT
    • 自分たちもユーザ
    • 自分たちが使いたいもの
  • 探査プロジェクト
    • イノベーションは技術が主導して立ち上げるもの
    • 顧客は今しかみてないからそのニーズに答えるだけでは発展しない

技術の継承

  • IT
    • 多くのシステムが負債化している
      • 古い技術が動いているからといって放置されている
      • 開発できるエンジニアを持っていなくて委託しているからノウハウのある人がどこにいるかわからない
      • 人材の流動が激しいと数年でいなくなることを想定して作れる
    • ペアプロ、モブプロ
  • 探査プロジェクト
    • 親方と弟子の関係
    • コーチングして技能は得られるが使えるものは得られない
    • 自ら獲得しないといけない
    • はやぶさはやぶさ2の間は10年以上
    • 若いうちからプロジェクトに参加して見せていきたい

チームビルディング

  • IT
    • 同じ方向を向ける中で多様性を持つことが重要
    • 根本から違う方向向いてしまうのは採用ミス
    • 考え方の違う人を入れてしまうよりも才能をある人を貶してしまう方がましというくらい
    • ローコンテキストを前提にビジョンを共する有
  • 探査プロジェクト
    • 向いているところに向いている人を配置する

緊急企画!漫画村再検証!

漫画村

  • 海賊版サイト
  • 政府がサイトのブロッキングを実施
  • 4つの闇
    • 法解釈の闇
    • 法改正の闇
    • 報道の闇
    • 広告の闇

海賊版サイト対策検討会議はなぜ紛糾したのか

事務局による進行の問題

  • 著作権侵害ブロッキングは世界42過酷で導入されているだから日本もやるべき」
    • 2001年にEUが司令を出してEU各国で法制化
    • 法制化されているが実施したことある国は半分くらいしかない
    • EUで28カ国が法制化17年間実績なしの国が15カ国

被害額3000億円

  • 漫画村の被害額が3000億円という試算は本当か
  • 年間コミック市場は4000億前後
  • 総アクセス数に単価をかけたのが3000億円
    • アクセスが有った分全部売り上げた前提

Coinhive事件/WizardBible事件にみる不正指令電磁的記録に関する罪

法が問題としていること

  • 意図に沿うべき動作をさせず不正な司令を与える電磁的記録

事件

  • Coinhive事件
    • 自分のページにWebブラウザにマイニングさせるJSを貼った
  • WizardBible事件
    • リモートシェルを埋め込み
  • アラートループ
    • アラートを閉じてもアラートが出続ける

この状況が続くと

  • サイバーセキュリティ分野の活動が衰退する懸念
  • 海外に優秀な人材が(今以上に)流出

フロントエンドエンジニアがこの先さらに生き残るには

  • mizchiさん(plaid)
  • lacoさん
  • 奥野賢太郎さん(クレスウェア)

働き方のスタイル

  • フリーランスになった
    • もともとのつながりで仕事を得られた
  • 週1日副業
    • サラリーマン感なくなった
  • フリーランス時代の仕事
    • フロントエンドは管理画面の需要が高い
    • エクセル再実装

フロントエンドエンジニアの尖り方

日本人がOSSにあまり貢献していない

  • 一部貢献している人がいてもスター扱いしてそれで終わってる
  • OSSは大企業が作るものに集約されてきていってる
  • バグバウンティの方がまだある
  • 翻訳のコントリビューションする人はけっこういる
  • GitHubのトレンドに日本人作者のライブラリがのることがほとんどない
    • 最近だとhiroppyさんのfusuma
    • 中国勢が強い

フロントエンドのカバーする領域

  • フロントエンドがサーバーサイドに入り込むようになってきた
    • Next.js, Nuxt.js
    • BFF
    • FaaS
  • フロントエンドの大事なところはフロントエンドであることユーザに最初に触れるところ
    • パフォーマンス
    • デザイン
    • UX
    • その反対側にデータを堅牢にする役割の人も必要
  • SPAを作るのが大変だった時代から当たり前に作れる時代になった
    • 注力できる範囲が広がってきてカバーできる領域が増えてきた

フロントエンドのDeveloperExperience

  • webpackのビルド時間が長すぎて改善の妨げになっていたり

次にくるものは

  • 数年前にReactの仮想DOMに魂が震えた
  • 次はWebWorker
    • off the main thread
    • メインスレッドの奪い合い

Rust

  • 今のWebをRustで書くことは今はなさそう
    • ライフタイムとかフロントエンドとは違った難しさ
    • ゲームとか作るのにはいいかもしれないけどメインでやることはなさそう
  • メインスレッドに登場してくることはなさそう
    • workerで動かす処理を書くとかはありそう
    • Backend in Frontend

フロントエンドの技術選定

  • TypeScriptは大前提
  • フレームワークを使うかどうかから
    • ampを使うとか
  • 複雑にならないからと思っても作り変えるときは絶対来る
  • バックボーンの成り立ちや考え方を気にしてもいいかも

「Meguro.css #7 @ ラクスル」に参加してきました

  • Meguro.css #7 @ ラクスルに参加してきました。

megurocss.connpass.com

  • 初めて知った記法や、普段当たり前に書いている変数名やライブラリへの問題提起など、学びがとても多かったです。
  • 次回もまた参加したいです!
タイトル 発表者
react-nativeにおける、Styleとの向き合いかた Naturalclar
Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか yamanoku
詳細度調整擬似クラス ShoEzawa
Chrome 78 Betaで試すCSS Properties and Values API あらや
Stylelintの取扱説明書 moro
Sassに頼らないCSS設計 takanorip

react-nativeにおける、Styleとの向き合いかた

  • Naturalclarさん

React Native

  • Reactライクな書き方でiOS/Androidアプリが作れる

React NativeのStyle

  • WebではないからCSSではないけど同じような感じで書ける
  • CSS in JSで書くことになる

React NativeとWebの差

  • Displayは基本flex
  • flexDirectionのデフォルトがColumn
  • marginなどのショートハンドが使えない
    • marginVerticleなど独自のものもある

Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか

  • yamanokuさん

デザインシステム

  • 一貫性が保たれたUIUXを提供できるもの

Design Tokens

  • デザインシステムにおけるスタイル変数集
    • CSS variables
    • SASSの変数とか
    • json読み込んだりとか
  • 色の変数名にwhiteとかつけるのはどうなのか
    • Atlassianのデザインシステムはカラー名が色の名前に準拠してない
  • 変数名が教養があるかどうかになるのも何か違う

詳細度調整擬似クラス

  • ShoEzawaさん

詳細度調整擬似クラスとは

  • :where()
  • 引数として与えたセレクタを詳細度の計算で無視する

使い所

  • !importantと同様詳細度に鑑賞するので乱用は危険そう?
  • ちゃんと使えば便利になりそう
  • 擬似クラスや属性セレクタを使うと詳細度が高くなりがちなので使えそう
  • 用途を限定して使うとよさそう

Chrome 78 Betaで試すCSS Properties and Values API

  • あらやさん

CSS Properties and Values APIとは

  • CSSのCustom Propertiesを構造化するためのAPI
  • CSSのCustom Propertyに初期値とsyntax(型のようなもの)を指定できる
  • Chrome78から使える

API

  • window.CSS.registerProperty
  • syntaxにnumberとかcolorとか設定できる
  • 一度定義すると再registerできない
  • syntaxに一致しない値を設定するとErrorがでる
window.CSS.registerProperty({
  name: '--property-name',  // 対象のcustom propertyの名前
  syntax: '*',              // 値をどうパースするか
  inherits: true,           // 親要素の値を継承するか
  initialValue: '',         // 初期値
});

Stylelintの取扱説明書

  • moroさん

Stylelintとは

  • css潜在的なエラーの事前検知や一貫性を保てる

Stylelintの使い方

  • stylelintをinstall
    • npm i -D stylelint
  • configを作成
  • 公式が提供するlintルール
    • stylelint-config-standard

上手な使い方

  • メッセージをカスタマイズできる
  • huskyとlit-staged
    • commitやpush前にタスクを走らせてそこでlintチェックする
    • 必ずlintがかかるようにできる

Sassに頼らないCSS設計

  • takanoripさん

Sass

  • 便利だけど機能が多すぎる
  • 便利だけど注意が必要な機能もある
  • Sassの機能を使うことが目的になってませんか

上書きをなくす

  • 詳細度で値を上書く
    • 詳細度との戦いが始まるのでよくない
  • 過度な共通化をしてると起こりやすい

Custom properties

  • CSSの変数のようなもの
  • 標準のCSSで使える
:root {
  --primary-color: ##ff0000
}
.hoge {
  color: var(--primary-color)
}
  • 色や大きさなど定義しておくことで統一したstyleにできる
  • 上書くだけではないのでよい

ScopedなCSS

フラットなCSS

  • ネストが深いと検索しづらくて開発効率が落ちる
  • 詳細度との戦い
  • Sassはネスト使えちゃうので使っちゃう

「JSUG勉強会 2019その9 Spring&AWS」に参加してきました

  • JSUG勉強会 2019その9 Spring&AWSに参加してきました。

jsug.doorkeeper.jp

  • Springの勉強会ですが個人的にECSの話をきけたのがとても勉強になって嬉しかったです。
タイトル 発表者
Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話 白山 文彦 (Fumihiko Shiroyama)
AWSで作るクラウドネイティブアプリケーションの基本とDevOps 川畑 光平 (APN AWS Top Engineers & Ambassadors)

Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話

  • 白山 文彦 (Fumihiko Shiroyama)

Kotlin

  • いわゆるAlt Java
  • 完結で強力な記法
  • Null安全
    • 型の時点でnullが入りうるかわかる
    • 自然な形で具象型にできる
  • JetBrains製

Spring with Kotlin

  • Spring Initializr
  • Docker化
    • 簡単に捨てられる開発環境
    • ステートレスなアーキテクチャの強制
    • 本番運用を見据えられる
  • DBもDocker化
  • AWSにデプロイ

Spring on AWS

Amazon Aurora

  • 自動でスケールする(RDSでは昔はできなかった)
  • マルチリージョン
  • 1つのライターと複数のリーダ
  • 書き込みエンドポイントと読み込みエンドポイントが違う
  • ローカルからでもアクセスできる

Amazon ECS

概要
  • Dockerコンテナを簡単にデプロイ管理するためのサービス
  • コントロールプレーンはECS or EKS
  • データプレーンはEC2 or Fargate
    • Fargateは中を意識しないで簡単に使える
    • EC2は自分で好きなようにできる
  • Fargateを使うとリソースを意識する必要ない
使い方
登場人物
  • タスク
    • Dockerコンテナ
    • タスク定義から作る
  • サービス
    • タスクを複数束ねる
    • APIサーバ」や「HTTPサーバ」のような役割の単位
  • クラスタ
    • 複数のサービスを束ねる

まとめ

  • ローカルから段階的にDocker化することで簡単にECS化できた
  • Fargeteは簡単にコンテナを扱える
  • CI/CDツールと連携するとECSの作成やデプロイを自動化できる

AWSで作るクラウドネイティブアプリケーションの基本とDevOps

  • 川畑 光平 (APN AWS Top Engineers & Ambassadors)

AWSで作るクラウドネイティブアプリケーションの基本

news.mynavi.jp

「Serverless Meetup Tokyo #14」に参加してきました

  • Serverless Meetup Tokyo #14に参加してきました。

serverless.connpass.com

タイトル 発表者
機械学習MVPにServerless Frameworkがオススメな理由 池田 雄太郎(株式会社 KaizenPlatform)
今Serverlessが面白いわけ(v19.09) 川崎 庸市(Microsoft Corporation)
AWSで開発するサーバレスAPIバックエンド 三宅 暁(フリーランス
F-SecureのServerlessなSecurity 河野 真一郎(エフセキュア株式会社)

機械学習MVPにServerless Frameworkがオススメな理由

  • 池田 雄太郎(株式会社 KaizenPlatform)

ML/DLプロダクト開発におけるストレス

コンピューティングリソースの短期的ダイナミクス

  • 学習などで一時的に大量リソースほしい
    • => 柔軟なスケールイン/スケールアウト機構が必要

コンピューティングリソースの長期的ダイナミクス

  • ビジネス的な成長予測ができないのでどれくらい使われるかわからない
    • => インフラに関する高い知識が求められる

Serverless

  • リクエストに応じて必要なだけのリソースをリアルタイムに確保する
    • リソース確保が柔軟
  • ML/DLプロダクト開発と相性がいい

Serverless導入の悩み

  • 設定/デプロイに関するデメリット
    • 使うBaaSが多くなり勝ち
      • AWSとかいろんなサービスがある
    • DevOps環境構築のハードルが高い
      • ロジックの実装はJupyterNotebookが多め
  • そこでServerless Framework

Serverless Framework

  • Serverlessアプリの構成管理ツール
  • CloudFormationの定義したリソースをLambdaを中心に一括で設定できる
  • ステージング環境の分割など簡単にできる

今Serverlessが面白いわけ(v19.09)

世の中の動向

  • 人類の問題
    • アジリティがほしい
    • 高い生産性効率性がほしい
    • 運用コストを下げたい
  • ビジネスの傾向

FaaSを支える技術

  • インフラ技術の進化の賜物
  • 一般的にコンテナ相当の技術が基盤に使われる
    • 使った分だけ課金
    • 高速にスケーリング
  • データストアの進化
    • ステートフル/データ永続化対応
    • スケーラブルなデータストア
    • NoSQL型がフィット
  • プラットフォームの進化の方向性
    • 自動化
    • 抽象化
    • 標準化
  • Serverlessにおけるクラウドベンダーの実情
  • Knative
  • KEDA
  • Virtual Kubelet

AWSで開発するサーバレスAPIバックエンド

ノーコーディングでバックエンドAPIを作る

  • Amplifyは使わない
    • ベンダーロックインしないように
    • Apollo Clientを使う
  • Cognitoは使うがOpenID Providerとして使う
    • react-oidc-contextを使う
  • serverless-appsync-plugine
    • AppSyncの設定を完結に定義してデプロイできるServerlessFrameworkのプラグイン

F-SecureのServerlessなSecurity

Serverlessでセキュリティ

  • インフラは提供者が担保
  • エンドユーザがアップロードしてきたファイルは安全か?
    • アップロード時にF-Secureと連携してセキュリティチェックしてくれる
    • API連携でセキュリティチェックができる