「Encraft #12 Frontend Quiz Night」に参加してきました

DOM Quiz

  • @yoshikoさん

クイズ

  • eventを一回だけ発火させたい
    • addEventListenerの第三引数に { once: true }
    • { passive: true } はpreventDefaultしない宣言
      • スクロールを監視してる時にパフォーマンスがよくなる
  • event.targetにくるもの
    • クリックが発生した要素
    • event.currenTargetにlistenerで登録した要素がくる
    • event.targetは大量の子にlistenerセットしたい時に親にlistener付与するとか
  • input type="number"を数値でとりたい
    • event.target.valueAsNumber

CSS Quiz

  • @zi-dotさん

クイズ

  • media queryのmin-width
    • 指定した値以上の時に適用される
    • 最近は <= とか使えてわかりやすい
  • flex: 1
    • flex-grow: 1; flex-shrink: 1; fkex-basis: 0;

TypeScript Quiz

クイズ

  • 関数の戻り値の推論
    • 文字列1つだとstring
    • 文字列2種類以上だと 'hello( | 'world' みたいな
  • satisfies
    • 型を満たしているかチェックしてくれる
    • 推論を尊重してくれる

「Figma開発モードで実装との合流点を語る | UI+FE合流点 feat. CyberAgent」に参加してきました

  • 2024/3/27
  • https://gaji-lt.connpass.com/event/310872/
  • FigmaのDevModeはベータの時に使ってましたが、知らない機能がたくさんあることが分かりました
  • デザイナーにとっても嬉しいということを初めて知ったので仕事でも使いこなしていきたいと思いました

Dev Mode

  • 谷 拓樹さん

DevModeとは

  • デザインをプロダクトにつなげる
  • 編集はできなくて参照だけ
    • デザインを壊す心配がない
  • 実装OKのマークを付けられる
    • dev modeで実装OKのものが識別される
  • Annotation
    • 注釈をつける機能
    • コメントだけじゃなくてstyleの値も選択して表示できる
  • 変更差分
    • 2つの要素を選択して差分を確認できる?
    • CSSのdiffも見える
  • Dev resource
    • 各データにリンクをつけられる
  • Component Playground

    - プレイグラウンドを開くとprimary/secondaryとか設定を変更して確認できる

    ハンドオフ

  • デザイナーが作って開発者に渡す

  • 実際は一本道ではいかないことごおい
  • デザイナーと開発者のコラボレーションを助ける

共通言語の採用

  • Align(整える)
    • Variablesで名前をつければ出力されるCSSを見るとそれが反映される
    • Componentに名前をつけて実装とも統一していくといい
  • Inform(伝える)
    • コンポーネント自信のドキュメント化
    • 仕様やStorybookへのリンク
    • ボタンにどのアイコン使っていいかfigma上で設定できたり
    • annotationで注意すべきポイントに注釈できる
  • Connect(つなげる)

座談会

  • 谷 拓樹さん
  • 原 一成さん
  • 出口 裕貴さん

DevMode事情

  • Qiita まだエンジニアは使ってない
    • 編集権限あるデザイナーがannotationとか使ってる
  • Ameba
    • エンジニアは申請したら使えるように使える
      • 10人くらいのうちの半分くらい使ってる
  • プラン
    • DevMode専用のプランはまだない
    • proプランから使えるけど編集もできる

DevModeの推し機能

  • annotationでマークダウンが書ける
    • コードブロックが書ける
  • Annotationにメモを書いてコメントに議論を書いて使い分けられる
  • Compare Changesがない時は差分を伝えるために赤入れしてた

DdevModeの将来性

  • エンジニアがFigmaをさわる機会が増えそう
  • ハンドオフ(引き継ぎ)ではなく一緒に構築していく助けになる

「CI/CD Test Night #7」に参加してきました

業務で役立つ…かもしれない?!GitHub Actions Tips 集

matrix job

  • 似てるけど微妙にパラメータが違うジョブ
    • まとめて並列実行したい
  • matrix jobでパラメータを差し替えながら並列実行できる
    • バージョンとかOSだけ変えてまとめて動かすとか
    • 複数の条件の組み合わせで動かせる
  • inputにjsonを使えるのが便利
    • workflowの外からデータを注入できる
  • secretsを出し分けたい場面がある
    • matrixではkeyだけ指定して使うといい

動的job実行

  • Branch Protection
    • PR作成時にCIが通らないとマージできないとか
    • 条件にjobを指定できる
  • jobをフィルタリングしたくなることがある
    • 実行時間や課金面で毎回全部動かしたいわけではない
  • pathsフィルター
    • 特定のファイルが更新された時に実行させることができる
    • 対象外だった時にworkflowが動かずpendingでマージがブロックされてしまう
      • pathsフィルターとBranch Protectionの相性が悪い
  • paths-filterを使ってworkflowは実行しつつjobをフィルターできる
  • Status Check Job
    • このjobをpass/failさせることでBranch Protectionを機能させる
    • passの条件
      • exit 0で終わる
      • jobをスキップして実行されない

GITHUB_TOKEN

  • GitHub Actions上で利用可能なGitHubのtoken
  • GITHUB_TOKENによるコミットではworkflowをトリガーできない

CI/CD のセキュリティや Developer Experience を改善するツールやプラクティス

  • @szkdashさん

PRコメントでCIの結果通知

  • CIがこけたら原因をPRにコメントしたい
    • ログ見に行くよりすぐ見れてわかりやすい
  • github comment
    • コメントのテンプレートも用意できるので使うと見通しがよくなる
    • 古いコメントを非表示にして新しくコメントできる

複数リポジトリのメンテナンス

GItHub Actionsのセキュリティベストプラクティス

  • ベストプラクティス
    • jobのpermissionsを最小限
    • secretの公開範囲を最小step/job
    • Actionのバージョンをfull commit hashで固定する
  • ghalintでチェックできる
    • CIで実行してセキュリティを担保
  • ツールのバージョン固定
    • ツールが汚染されてもいきなり反映されない
    • コードを変更してないのにCIが壊れるようなことを防ぐ
    • バージョンやタグもあるが変更されることがある
      • フルコミットハッシュが一番安全
    • コードコメントでバージョンを書けばRenovateも見てくれる
      • バージョンはパッチまでしっかり書くと更新時の差分が見やすい

CIで使うツールの管理

  • バージョン固定
    • latestは突然壊れる
  • ツールの自動アップデート
  • shellでやるのは面倒
  • aqua

一歩先のセキュリティ

  • CIを書き換えられないようにする
    • 任意のコード実行を防ぐ
    • 強い権限与えないといけない時特に
    • pull_request_target event
  • feature branchのスクリプトを実行するのは危険

古いrevisionでの実行を防ぐ

  • defaultブランチの最新のHEADかチェック

CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること

runn

runnの機能

  • 1バイナリで作られてる
  • さまざまなプロトコルに対応
  • OpenAPI Specライクなシナリオ
  • 複数のシナリオが想定されている
    • 分割実行
    • サンプリング実行
    • ランダム実行
  • プロファイルの取得
  • ステップ実行できる

APIテストのモチベーション

  • アプリケーションの外側からテストしたいというニーズ
  • スモールテストよりコストが高い
    • 実装コスト
      • 環境整備が面倒
    • 実行コスト
  • CIでの自動実行が前提になってる
    • コンピューティングリソースは気にならなくなった

APIテスティングツールに求められること

ChainingRequestに対応していること

  • 複数リクエストで成り立つテストが求められる
  • 個別に作るより実は低コスト

親和性の高いテストダブル環境

  • 規模が大きくなりがち
  • テストダブルをアプリの外で構築できると望ましいが難しい
  • Postmanはstubサーバのサポートがある
  • runnはないので自前でstubサーバ動かしてやる

テストケースにIDがあること

  • テストを一意にできるIDが必要
    • 全てを毎回実行するのはコストが高い
  • IDとメトリクスの連携
    • 特定のものだけリトライとか
    • 実行時間を特定するためにとか
    • よく失敗するのを先にとか
    • IDを使うと柔軟にできる
  • runnは自動で動的に生成してる

APIスキーマとの連携がある

  • テストケース自体がある程度正しいことを確認したい
  • runnでは各ランナーにAPIスキーマを設定できる

ポータビリティがある

  • 開発環境とCI環境で同一の環境にしやすいこと
  • 負荷試験としても活用できる
  • 本番強への外形監視/計測として使える
  • runnではいろんな環境で使えるようにしてる

リリース戦略を支えるCI/CDパイプライン

  • @katzchumさん

リリース管理のつらみ

  • システムが複雑になり依存が増えると管理が複雑になる
    • リリース判断できる人が固定化されてくる

リリース戦略の事例

  • 複数バージョンが並行するプロダクト
    • クライアントによってバージョンが違う
  • リリーストレイン
    • リリースの日が決まっていて間に合ったものだけリリースする
  • ブランチカットするタイミング
    • リリース日が未定な状態でもタグをつける
    • 開発環境にデプロイするタイミングでタグつける
  • タグはOSSの開発スタイルに倣う
    • セマンティックバージョニング
  • tagpr

「AI4D Gathering @虎ノ門」に参加してきました

  • 2024/3/25
  • https://connpass.com/event/312085/
  • 生成AIの事例をいくつも聞けて、デザインの領域でのAI活用が盛んなんだなという印象でした
  • 自分ももっと活用できるのかもと思えたので工夫してみたいと思った
  • デザイナーの人たちといろいろ話せたのも楽しかったです

生成AIプロダクト開発におけるプロセスシェア

生成AIプロダクト

  • 法人向けに生成AIプロダクトを作っている
  • PoCやって検証して製品を作った

プロジェクトの目的整理

  • 生成AIを使うのが目的か、生成AIがマッチしてそうだから使うのか目線を合わせる
  • 生成AI使ってどんなもんかを検証したいから前者だった

SEPIA法での分類

  • AIに興味ある軸と業務への理解度の軸に分ける
    • システムを使う気があるか、自信を持って使えるか
    • AIへの関心と業務の詳しさで4象限つくると属性ごとに課題感を持っていた
    • 不慣れな人はプロンプト分からない

独自の軸での分類

  • プロダクトに詳しい軸とAIリテラシーの軸に分ける
    • 初心者も対象にしたかった
    • プロダクト詳しくてAIリテラシー低いユーザが盲点だった
    • 1回目と2回目の利用といったUXの時間軸で区切ってみたがしっくりこなかった

プロダクトを理解するための機能設計

  • サービス機能を充実化させてプロダクトを理解させる
  • マニュアルは読まれない
  • プロダクトに詳しくなってもらってからAIリテラシーを高めてもらった

機能の価値を再定義

  • 戦略ターゲットから機能の価値を再定義
  • プロンプトテンプレート
    • プロダクトに詳しいがAIリテラシー低い人を引き上げる

導入担当者のためのUX設計

  • 導入担当者の目線でUX設計する
  • DX推進者は効果を上司へ報告しやすくしたい

生成AIを活用した動画制作による共創アプローチの可能性

  • 有澤寛則さん/富士通株式会社 デザインセンター フロントデザイン部

生成AIを活用した動画制作

  • 日本酒づくり
    • 飲み手を巻き込んで作る
    • 音楽で醸造に参加
  • =>コンセプトムービーをAIで作った

動画作成のプロセス

  • 人の手と生成AIを組み合わせ
    • ChatGPTで絵コンテ作成
    • 人がシナリオ精査
    • AdobeFireflyで画像生成
    • runwayで動画生成

生成AIを使った動画

  • 特徴
    • 人の手で作るよりクオリティは下がってしまう
    • 制作時間は圧倒的にはやい
  • 議論しながら一緒に作るのに向いてそう
    • 余白のあるラフコンセプト動画をもとに進めるといい
    • お客さんのアイデアを上乗せした新しいコンセプト動画を作れる

AIとブランドを作る。UXライティングにAIを活用する方法

分類して使い分ける

  • AIでできること
    • 壁打ち
      • 何もわからない時
    • 起案
    • 発散
      • いいと思ったことのニュアンスが違うものを探す
    • 客観視
      • 客観的なレビューが欲しい時
    • 精査
      • 細かいところの精査
      • 言い回しや文章が変じゃないか

ブランドを守る

  • noteのUXライティング
    • 言い回しが親しみやすい感じで特徴的
    • 80%までAIで作って最後は人間がチェックしている
  • UXライティングやブランドの基準を持っておくこと
    • noteさんという人格を作っている
    • noteさんならそうは言わないでしょとか

情報設計フェーズでの生成AIとの協業

  • 池田拓司さん/株式会社くふうカンパニー

アバターと生成AIの融合、UIの可能性を探る

  • 岩﨑勝利さん/AVITA株式会社

UXライターが語る「生成AIはプロンプトが9割」

ユーザーとシステムを繋ぐエージェントUX

  • 亀田重幸さん/ディップ株式会社

「Object-Oriented Conference 2024」に参加してきました

オブジェクト指向のリ・オリエンテーション ~歴史を振り返り、AI時代に向きなおる~

  • 羽生田 栄一さん

オブジェクト指向の嬉しいところ

  • プリミティブだけじゃなくてドメインに対して操作できるようになった
    • 意味のある領域にクラスを割り当ててプログラミングできるのがいい
    • 概念を使ってプログラミングするのを可能にした

オブジェクト指向の段階

  1. オブジェクト指向ミニマム
    • idを持っていて1つ1つ区別できる
    • カプセル化された状態をもっている
  2. 責務/ロールの概念整理
    • メッセージへの応答能力
    • 存在理由を1つに定めて1つの責務を果たす
    • SRP(Signle Responsibility Principle)
  3. クラス/継承/ポリモフィズム
    • 意味のあるメソッドが体系付けられてクラスの中に閉じ込める必要がある
    • リスコフの置換原則が理解できてないなら継承を使うな
    • 継承はサブタイピングとして強い型付けを意識
  4. 構造主義的なオブジェクト指向
  5. レイヤー化
    • 依存関係の制御

オブジェクト指向と関数型D

生成AIの不確実性と向き合うためのオブジェクト指向設計

  • 菊池 琢弥さん

生成AIのユースケース

  • copilotなどの開発での活用ではなくプロダクトへの埋め込みの話
  • 技術視点から
    • システムで扱いにくかったデータが扱いやすくなる
      • 表記揺れの吸収とか
        • 文脈を意識した分類とか
  • 体験から
    • 自動化(Automation)
    • 代行(Agent)
    • 助言(Advice)
    • 強化(Augment)

生成AIプロダクトの難しいところ

クソコード動画『カプセル化 Mk-II』で考える、上手くカプセル化できない理由

  • ミノ駆動さん

カプセル化と関心

  • データとデータ操作ロジックをひとまとめにすること
  • 正常に操作可能なメソッドのみ公開する
    • setterは不整地も含めて代入できてしまうため避けること
  • 関心ごとに構成を分離する
    • Aを修正してもBに影響がでないように

目的と手段

  • システム手段で実現したい目的があるはず
  • 目的には下位目的が発生する
    • それぞれの目的を達成するための手段を用意する
  • 目的が決まると達成したいことが決まる
    • それぞれの目的に必要な要素は異なる
  • [上位目的]商品を売買したい
    • [下位目的]在庫管理したい/注文したい/配送したい
  • 手段に紐づく目的は1つ
    • 目的外の利用はだめ
    • システムでも一緒とのこと
    • 特定のクラスが多目的に使われると崩壊する
    • 手段からみて目的が1つになるように設計するといい

モデリング

  • ECサイトで「商品モデル」を作ると巨大化する
    • 中心的になるモデルはあらゆる目的に紐づいてしまう
  • 目的論的抽象/存在論的抽象
    • 存在論:魚類
    • 目的論:夕食の素材
    • 存在論では目的に合う要素だけをうまく抽出できない
  • モデル
    • ある目的を達成するために目的に合致した特徴のみを抜き出し他を捨て去ったもの
  • モデリング
    • 特徴を抜き出し他を捨て去る活動

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

  • pospomeさん

DDDを理解する

  • ドメイン
    • 領域
    • ユーザがソフトウェアを適用する対象領域
  • DB駆動設計
    • テーブルと1対1でクラスを作る
    • 複数のクラスにまたがるロジックの置き場所に困る
    • FatModelかドメインモデル貧血症になる

良い良いコード

  • ICONIX
    • 図を書いて設計に落とす
  • 実装ファーストで考えるのが良い
    • 図を書くだけではうまく設計できない
  • 保守性
    • モジュール性
    • 再利用性
    • 解析性
    • 修正性
    • 試験性

設計能力の壁

  • 基礎力が必要
    • よくある原則的なもの
  • DDDの本はプラクティスを教えてくれるだけ
  • 時間を消費する割に品質がそれほど高くないものになってしまう

ビジネスロジックを「型」で表現するOOPのための関数型DDD

関数型DDD

  • 関数型のエッセンスを加えてビジネスロジックを型の力で柔軟にしたDDD
  • 型があると実装ミスをコンパイルで検知できる
  • 例えば特定の条件のときだけ値があるフィールド、みたいなものをコンパイルで検知できる

モデルの状態を代数的データ型で表現する

  • 特定の条件のときだけ必須の項目
  • コンストラクタで検証する?
    • 実装なのでテストしないといけない
  • 状態ごとにモデルを作ると良い
    • 注文取得したときのどの状態か分からないのでanyにするしかないのが課題
    • 各ステータスの注文をまとめて扱いたい
  • 代数的データ型
    • 直積集合と直和集合で表される構造体
    • 継承はどんな子クラスがあるか制限できないのが違う(直和の性質がない)
    • Enumは個別の構造体が持てない(直積の性質がない)

モデルの状態遷移を型と全域関数で表現する

  • ステータスの繊維のダメなルートをコンパイルで落としたい
  • ルールの適用と違反時のハンドリングがある
    • 前者を型で守る
    • 校舎はテストで担保
  • 関数の全域性
    • すべての入力が対応する出力を持つこと
    • inputが決まるとすべてのoutputが同じ挙動をするもの
    • ルール違反になるパターンが有るときはinputの型を絞る
      • 割り算で0以外の整数の方を作ると全域関数になる

ロジック内のDBアクセスを高階関数で表現する

  • DBアクセスの理想
    • 最初に全部読み込み、処理して、最後に書き込み
    • ドメインモデルがシンプルになってテストが書きやすい
  • ドメイン層に隠蔽したいところだけを高階関数にする

設計の知識と技能で駆動するソフトウェア開発

はじめに

  • 開発プロセスの中に開発と設計がある
    • 設計が良いと開発が楽になる
  • 設計は経験則の面も大きい
    • 技能として身につけるには手を動かすことが重要
    • 知識と技能を持ち寄って組み合わせるとさらにレベルアップする

ソフトウェア設計の基礎知識

  • 基本課題
    • 本質的な複雑さ/発展性に対応できない
    • 巨大なモノリス/大きな泥団子
  • 解決アプローチ
    • 関心の分離
    • 部品化
    • モジュール化
      • 交換容易性
      • 交換するかは置いておいてできる状態になってるのがいい状態
  • 基本となる技法
    • モジュラー性
      • モデル(要約)
      • カプセル化(自立性)
      • 直接的な写像(分かりやすい構造)
      • 仕様(意図の伝達)

モジュール設計スタイル

  • モジュールの設計スタイルの分類
    • 抽象化の方向
      • 機能/データ
    • 用途
      • インバウンド/アウトバウンド/演算
    • 状態の扱い
      • 可変/不変
    • システム構築の原理
      • ブレークダウン/ビルドアップ
  • オブジェクト指向の設計スタイル
    • データ/演算/不変/ビルドアップ
    • クラスとメソッドで演算ロジックをモジュール化
  • ドメイン駆動設計の設計スタイル
    • データ/演算/不変/ビルドアップ
    • 複雑な業務ロジックに焦点を合わせる

アプリケーション全体のモジュール構成

  • ポート&アダプターの設計スタイル
    • コア
      • 業務ロジック(データ/演算/不変/ビルドアップ)
      • アプリケーション(データ/演算/可変/ブレークダウン)
    • アダプター
      • プライマリ(機能/インバウンド/可変/ビルドアップ)
      • セカンダリ(機能/アウトバウンド/可変/ビルドアップ)
  • コアの分析設計に投資する
  • コアの実装
    • 高密度/強度/交換容易性
  • アダプターの実装

モデル駆動設計

全体

  • 事業活動モデル/基本設計
    • 事業活動を最適化するのが目的
    • いろいろな制約の中で何が貢献できるか

コア

  • 業務ロジックモデル/ドメインモデルのクラス設計
  • 業務機能モデル/アプリケーションサービスのクラス設計

アダプター

オブジェクト指向は必要なのか

初心者にとってのオブジェクト指向

  • 初心者が目指すべきものみたいになってる
    • 初心者にとってはすぐに学ばなくて良いもの
  • オブジェクト指向という言葉が曖昧
    • その中の要素を別の名前として定義した方が良い

オブジェクト指向の定義

抽象データ型

  • データの操作だけを公開することで変更に強く柔軟
  • データのカプセル化

オブジェクト指向と関数型D

  • 区分けに意味はない
  • オブジェクトと関数は可換

デザインパターン

  • デザインパターンは言語に足りない機能の補完
    • 多くのパターンが言語の機能導入で不要になっている

オブジェクト指向の使い所

  • オブジェクト指向は状態管理技術
    • I/O
    • List
  • 状態管理はモジュールの協会に現れる
    • DOM/HTTP/DB接続

「TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜」に参加してきました

ビジネスとエンジニアリングの接合点 ~ そしてコード品質がそこに及ぼす影響

  • LINEヤフー株式会社/松本 成幸@mtx2sさん

ビジネスとエンジニアリングの接合点

  • ビジネスからエンジニアリングへの相談からスタート
  • ビジネス
    • 計画づくりから始める
    • そのために見積もりしてもらう
    • 完成時期を早めたい
  • エンジニアリング
    • 見積もりをする
    • 計画をする
    • 完了する確率を高めたい
  • 両方が調整されて発足する

プロジェクトの成功に求められる要素と接合点

  • 成功は計画だけでなく価値の提供も含む
    • 期間
    • 予算
    • アウトカム
  • プロジェクトの進行中は様々な困難がある
    • プロジェクトプランニングとプロジェクトコントロールも必要
  • 価値があると信じていても顧客によって検証されるまでには仮説にすぎない
    • 実験と計測を回していく

コード品質がビジネスに与える影響

  • 低品質なコードだと
    • 見積もりが難しい
      • 予測可能性が低くなる
    • 欠陥が多い
      • 欠陥の修正に追われてしまう
      • 潜在的な不具合がどこかで顕在化する
    • 開発時間が長い
      • 期待する価値に到達するために何度も繰り返すことができないので価値がさがるか遅延する
  • => 成功に求められる要素のマイナス要因になる
    • ビジネスに悪影響を与えてしまう

対策の実例

  • 保守性の構成
    • テスト容易性
    • 変更容易性
    • 理解容易製
  • テストコードを書く過程でリファクタリングが進み品質が高まる
  • テストのカバレッジを評価軸に入れた
    • テストを書く文化を作りたかった
  • テストが目的とならなようにその他のメトリクスも評価に入れた
  • ジュニアとシニアでペアプロでテストを書いていく

開発者に感謝される品質チームであるために

内部品質チーム

  • 外部品質(QA)とは別動
  • 機能開発を安心して高速に行える基盤づくり
  • 社内標準を磨きプロダクトに反映

品質向上と標準化

  • 煙たがられるのでは
    • 新機能をはやく作りたい
    • お作法を押し付けることになってしまわないか
  • 実際は感謝されていた

やっていること

安心と高速化

  • 注力領域の妨げになる箇所を先んじてリファクタ
  • モノレポのハマりどころの対応
    • ライブラリや言語のVUP
  • CIの安定化高速化

標準化

  • 共通機能のミドルウェアの提供など
  • 使い勝手に敏感であり続ける
    • ライブラリのアップデートで足かせになっていないか
    • 機能は十分か
    • トラブルシュートで困らないか
    • changelogが読めるものになっているか

コード品質向上タスクの優先順位を判断するために必要な観点を探究する

コード品質

  • 内部品質/外部品質
  • コードは内部品質
  • 内部品質は外部品質に依存し外部品質は利用品質に依存する
  • コード品質は内部品質の中でもメンテナビリティ
    • 理解容易性
    • 変更容易性
    • テスト容易性

なぜ改善タスクが進まないか

  • なぜ進まないか
    • 変化が怖い
    • 知識の孤立
    • ビジネスが止まる
    • 終わりが見えない
  • ビジネスメンバーが判断できない

ビジネスへの説明

  • ゴールを決める
    • いろんな指標があるからそれを使う
    • 基準をどうするかはビジネスドメインによる

「UI UX Camp! 2024」に参加してきました

  • 2024/3/20
  • https://cp.nijibox.jp/uiuxcamp
  • 生成AIの活用が全体的に話題の中心でした
  • 普段Webしか触れてない自分からすると新鮮に感じる話題が多かったです
  • 最初の講演で「フィルターバブル」の話がありましたがまさにその外側に触れた感じでした
  • 参加者は以外とエンジニアもいたし、大学生や高校生もいました

人間性とテクノロジーの未来〜ぬくもりのデザインを考える〜

  • 内田 舞さん
  • 野々村 健一さん

テクノロジーが人間に与える影響

  • テクノロジーによって認知が変わっているか
    • 自分用の情報をみんなが見てると思ってしまうe
      • フィルターバブル
    • 意識的に外に出てみないとわからない
  • ビジネスの中でフィルターバブルの中でトラフィックをドライブさせるのはどうか
    • 儲けたお金の量は語られるが質を語られることがあまりない

デザイナーのスタンス

  • この10年でスマホが定着
    • 今はITが要請といっていいくらいになってる
  • 新しいテクノロジーが浸透していくフェーズと活用してくフェーズが振り子のようになってる
  • テクノロジーが出てくるのは選択肢を増やすこと

次世代生成AIプロダクトのつくりかた〜技術進化のトレンドから予測する生成AIビジネスの未来〜

  • 梶谷 健人さん

優れた生成AIサービスをつくるポイント

生成AIの本質価値をおさえる

  • 創造コストが限りなく0になる
  • 自然な対話の実現
  • 非構造化データのベクトル化
    • 全く整備されてないデータでもいい感じに処理してくれる
  • コンテンツのマルチモーダル化
    • モーダル・・・データの種類
  • 高単価専門知識の民主化
  • 言語障壁の軽減
    • AIの中ではAIだけにわかる状態で保持されてるので言語の壁がない
    • テキストから多言語の発話動画を作れたり
  • 新しいモーダルでのインプット
    • ラフな絵をもとにWebページ作ったり

生成AIを忘れる

  • 生成AIを使うことが目的化して課題設定が甘くなることが多い
  • 99%のサービスは課題解決型
    • 顧客 x 課題 x 解決法
  • 顧客課題を深堀って、生成AIが活きる領域を考える

生成AIならではのUXを作る

  • UXの原則を押さえる
    • UX = u(便益) + e(情緒価値) - f(リフレクション)
  • その上で生成AIならではの体験をいれる

AIの進化によってUXの在り方

環境や情報とのインタラクションがどう変わるか

  • デザインの単位がUserからYouへ
    • 特定の人向けのものを簡単に作れるようになった
    • 今のユーザ中心設計は将来的に大量生産大量消費のように見えるかも

人とAIの間衛生

  • 人間の存在意義はどうなるのかとよく聞かれる
    • これは人とAIを分けて考えている
  • AIが人の脳の第三の新皮質になる
    • 能力が1000倍違うと旧人類と新人類くらいの差がでる
  • 人はAIを内包し両者分けずに考えるべき時代が来る

身体を超える「自分」をデザインする〜ゴーストエンジニアリングで広がる生き方の可能性〜

  • 鳴海 拓志さん

バーチャルアバター

ゴーストエンジニアリング

  • ゴーストエンジニアリング
    • 身体の再デザインによる心と認知のデザイン
  • アバターによる自分事/他人事の切り替え
    • 他社視点の体験を得ることで共感醸成
    • 三人称視点で見ることでひらめきの数が増える
  • アバターの動きの融合
    • 2人の動きを合成してアバターを動かす
    • 熟練者のスキルを伝えるのに使える
  • 身体的自己/物語的自己
    • いきなりスキルを得たり変われると言われても使いたいと思う人は少ない
    • 自分の物語があるので突然変わることは望まない
      • Narrative Self
  • アバターだと誰でもチン室な身体を得られる
    • 身体のままならない多様性を意識しなくてよくなる
  • 身体を通じてどのような「こころ」をデザインしたいか
    • 「こころをデザインする技術」を人生において適切に意味づけるためのデザインは

未来のエネルギーをデザインする〜今、全人類が取り組むべき持続可能な社会の実現〜

  • 紺野 亜紀子さん
  • 田子 學さん

エネルギー

  • 太陽光や風力などは安定的に供給できないかもしれない
    • 地域や地形に密接に関わってる
    • 再生可能エネルギーをやってくなら地域にフォーカスする必要ある
  • 石炭は運べる資源
  • 水力
    • ダムは水力で発電してる
    • 貯水してるだけじゃない
    • SAKUMAが古くなってるので改善しようとしてる
    • 地域に還元できたらその地域の価値があがるのでは
  • 地熱

CO2の削減

  • CO2フリー水素発電
    • 石炭から水素だけ取り出して発電する
    • 再生可能エネルギーは不安定
      • それを補って安定供給させることにもつながる
  • 草本系エネルギー作物燃料化

企業における生成AI導入の実際〜デザイン組織リーダーが考える、これからのプロダクト開発の現場〜

  • 古川 陽介さん
  • 吉川 聡史さん
  • 上田 沙緒理さん

AIの活用状況

  • 開発
    • Copilote
    • v0
      • イデアの種として使ってる程度
    • ChatGPT
  • ディレクション
    • ChatGPT
      • 社内としてセキュリティ担保した上で
    • 自社ナレッジをChatGPT系サービスに入れて困ったときに聞けるようにしてる
    • 分析用途でSQLを生成してもらったり
    • 技術的な質問などの翻訳
    • プロンプトの生成をChatGPTにやってもらう
  • デザイン
    • ChatGPTでアイデアの発散の手助け
    • ライティングやキャッチコピーの手助け
    • デザインそのものを作るところでは活用してない
      • 活用できるほどのものがちょうど生成されない
      • 権利の問題

生成AI普及による課題

  • 楽なタスクはAPIに頼れるから新入者向けの経験を積む簡単なタスクがなくなっていないか
    • 開発ではあえてAI使わずにやらせている
  • AIが出したものをいまいちだと判定できるのは経験によるもの
    • その経験を得る機会が減ってしまっている
  • メンバーが失敗する経験をたくさん提供したい
    • 社内や自社で閉じるところで

今後の展開

  • AI使ってできた気になってる人をどうにかしたい
  • 目より先に手が肥えることはない
  • マネージャーががいいものを作ることで新しい人がそれを見てくれる

ロボティクスとデザインの親密な関係〜社会に溶け込む理想的な身体拡張ロボット開発〜

  • 山村 菜穂子さん

自在肢

  • ロボットの腕を増やす
    • 背負って使う
  • サイボーグ
    • NASA宇宙で活動するための身体の編集
  • デジタルサイボーグ
    • 身体に手を入れずに装着できる
    • 気軽にサイボーグ状態になれる
  • 自在肢のきっかけ
    • デジタルサイボーグが受け入れられるのか
    • どんな時に使われるか
    • 人の身体と調和が取れるデザインがどんなものか
  • 動かし方
    • 今は他の人が遠隔で動かしている

デザインプロセス

  • 人間拡張技術の研究とデザインラボの共同ではじめた
  • 身体の形をじざ員に変化させる研究
  • ロボットアーム
    • どう動かすかにフォーカスしていた
    • 動かしてる人は自分の一部と認識してるか心理学的な面での調査
  • 特徴
    • 身体と調和したスタイリング
    • 人間の身体とのスケールの類似性
    • 工具無しで着脱可能
  • 装着性の確認を工程ごとにこまめに確認

AIのある日常 2024〜「自分流」がカギをにぎる、これからの生成AIとのつきあいかた〜

  • 深津 貴之さん
  • 砂金 信一郎さん

生成AIの追い方

  • 個別の技術をおうよりも全体を見てる
  • どれが勝って負けるとかおってもしかたない

生成AIの失敗パターン

  • AIを使うことが木底になるとだめ
    • ペインがないところとか
  • やりたいことにAIがあってないとだめ
    • AI使うより人のレビュアー増やしたほうがよっぽど効果があるケースとか

生成AIの使い所

  • パーソナライズしたいところ
    • 生成AIを使うにはコストがかかるのでそれくらいやれないとペイしない
  • ある程度の一般知識があるだけでできる業務
  • サービスの裏側で実は使われているというくらいがいいのかも
  • 作業は人間でアシストするのがAIという分担がいいのでは

「Google Developer Expertsが語るWeb技術の最前線」に参加してきました

プライバシーサンドボックスサードパーティCookieの廃止

  • 田中 洋一郎さん
  • 異なるサイトからトップレベルサイトに送信される任意のcookie
  • 広告以外にも使われる
  • ラッキングによるプライバシーの侵害が問題
  • 3rd party cookieを廃止する代わりに主要なユースケースをサポートする技術が用意された
  • 2024/1から1%展開された
    • 2024の終わりには100%展開される予定

準備

対策

ブラウザと仕様のアップデート

  • 矢倉 眞隆さん

HTML/UI

  • JSに頼らないUIが増えてる
    • a11yを標準で担保
  • OpenUI
    • UI標準を提案するグループ

CSS

  • CSSの根幹に手をいれる機能拡張が増えた
    • CSS Nesting
    • :has
    • @scope
    • @property
    • sub-grid
    • align-content

仕様の課題

  • 小さい機能が多い
  • 最小限の機能の実装は早い
  • 仕様の課題の解決に時間がかかってる印象

実装の状況を道知る

  • ブラウザのリリースノート
  • ベースライン
    • 各ブラウザの実装が揃っているかなどの状況が見える

互換性と相互運用性

  • Interop
    • 仕様と実装の互換性を上げるプロジェクト
    • 各ブラウザの実装状況のスコアも見れる
      • web platform testsでスコアを出している
    • 毎年どこに注力するか発表される

ブラウザ動向

  • Chromeの3pcd
    • 2024/1から適用が始まった
  • iOSのブラウザ変更
    • EUwebkit以外のエンジンが使えるようになりそう

Getting started with designing for web accessibility

  • Julia Undeutschさん

Color Contrast

  • テキストを読めるか
  • リンクとして認識できるか
  • 色を認識できるか
  • Color Contrast Checkerで確認するといい

Color Independency

  • 色だけで情報を伝えてはだめ
  • エラーが起きた時に文字色を返るだけで伝えるとよくない
    • アイコン入れたり色に頼らない情報で伝えるといい
  • Read moreClck here だけでは何のリンクか分からない
    • リンク先が分かるようなテキストを入れるのがいい
    • スクリーンリーダーでリンク一覧を見ると Read more が連続されるようなのは避ける

「Repro Tech Meetup: Deep Dive into Browsers」に参加してきました

  • 2024/3/15
  • https://repro-tech.connpass.com/event/311742/
    • ブラウザAPIの話を聞けるのは珍しいので面白かったです
  • Service Worker static routing APIが名前だけ知ってて気になってたので詳細聞けたのがよかったです

No more parser-inserted js

script要素

  • 標準は同期実行 & parser-inserted mode
    • DLと実行待ちでHTMLパーサが停止する
  • これが標準なのは互換性のため
    • JavaScript1.0(1996)
    • document.write
    • 今は警告出るしもう使わない
  • JavaScript1.0

HTMLパーサとJS実行

  • parser-insertedな実行
    • HTMLだけなら普通のパース処理
      • 順番に処理してく
    • JSが入るとややこしくなる
      • JSでHTML入力ストリームにインサートできる
      • JSでDOMツリーを改変できる
    • 当然かなり遅い
  • 今はもうquerySelectorがあれば十分
  • DOM APIがあればパースとめて処理実行する必要ない
    • それを実現するのがdeferとasync

defer/asyncの話

  • defer
    • ダウンロードは並行
    • 入力ストリームの終端で実行
    • document.writeは虫
  • async
    • ダウンロードは並行
    • パーサを止めて実行
    • document.writeは虫

document.write再考

document.write

  • 文字列で渡されたHTMLをHTMLに追加する
    • 壊れてても入れられる

いいところ

  • レンダリングプロセスに介入できる唯一の方法
    • 画面が表示されたときには必ず処理が終わってる
    • 計測タグ
    • レンダリングまでに必ず必要な処理

悪いところ

  • レンダリングプロセスに介入してしまう
    • 同期的でブロックされる
  • 実行タイミングがずれるとページを壊す

何が問題化

  • 適切に使えば問題ないがそれが難しい
  • 文字列渡すので何でも実行されてしまう

document.writeへの介入

  • chromeは介入して止める
    • scriptが実行されない
    • ただし介入するのはいろんな条件を満たした時

Render Blocking

  • 特定の要素にたどり着くまでブロッキングする
    • レイアウトシフトを防ぐのが目的
  • ABテストで画面の表示が確定するまで止めるとか

エディタ付きのReact開発環境をブラウザだけで実装した話

  • steelydylanさん

ブラウザエディタ

  • https://mosya.dev/react
  • StackBlitzのブラウザでnode動かす製品とかあるが有料なので自分で作った
  • lintエラーとか型情報とかちゃんと表示される
    • Biomeのwasm webをブラウザで動かせる
    • workerで動かさないと重すぎる
      • ComLinkが便利

プレビュー環境

  • SWを活用
    • 通信に介入するのを利用した
    • 必要なファイルを通信しにいってSWでァイルを返す
    • 全部mjs化して返して解決させてる
  • reactなどのライブラリはimportmapで対応
  • SWでHonoを動かしてる
  • tsは@swc/wasm-webでトランスパイル

採点機能

  • ブラウザでtesting-libraryを動かしてる
  • jest-liteで実行

Memory leaks in Web Application

メモリ管理

  • アプリの変化
    • SPで滞在時間長期化JSの肥大化
    • ヒープを圧迫すると最悪タブクラッシュ
  • なぜリークするか
    • GC言語なのでメモリは自動管理
    • 到達可能だけど不要なオブジェクトがリークしてるオブジェクト
    • windowから参照されてる
    • listener
  • 頻出パターン

どうやって特定する

  • Memory heap snapshot diffing
    • snapshotをn回とって+nなオブジェクトが怪しい
  • Retainer treeを確認
  • 3snapshot
    • 2回だとキャッシュとか意図的に残ってるかも
  • ノイズが多くて大変

自動化

  • fuite
    • puppeteer使ってる
  • MemLab
    • meta製
  • BLeak
    • Proxy使ってJS書き換えて
  • LeakPair
    • ASTで解析してリークしやすいパターンを見つけてパッチあてる

モニタリング

  • フィールドデータが貴重
    • 実際のユーザがどれだけメモリ使ってるか

Service Worker static routing API

SorviceWorker

  • fetchをproxyするがその時には起動済みでないといけない
  • SWの起動はnavigationにクリティカル
    • Androidだとp95で500ms
    • cold状態からの起動だとp95で940ms
      • 30%くらいでこっちの挙動になる
  • SWが介入しなかった時のコストも無駄がある
    • SWがなにもせずブラウザから通信を改めてするので
  • navigationPreloadを使うとnavigationと起動を並行できる
    • とはいってもswの方が時間かかると待たされて遅い

SorviceWorkerのコスト改善

  • いらない時は動かさない
  • Static Routing API
    • どういうリソースにどう介入させるのかを宣言的に指定する
    • event.addRoutes に定義する
    • confition
      • URLPatternやmethodなどの指定
    • source
      • networkなのかcacheなのかなど
    • or
      • pngかjpgならchacheからといった使い方

Use case

  • navigationはキャッシュしてないとか
  • formのPOSTはキャッシュしてないとか
  • サブリソースはキャッシュにあればキャッシュがいいとか

dev tools

  • networkタブでserviceworker routerと出るようになる
  • 指定した定義も確認できる

「「Tailwind CSS実践入門」出版記念イベント」に参加してきました

出版記念基調講演

TailwindCSSとの出会い

  • https://charcoal-web.pixiv.design/
  • デザインシステムの技術選定
    • プロダクトたくさん
    • 全部Reactというわけではない
    • ->Tailwindがちょうどよかった
  • もともとCSS in JSとかよりCSS Modulesが好きだった

CSSのレビューをしやすくする

  • write-onlyな言語になりがち
    • コードレビューがちゃんとされづらい
  • CSS+StylelintとTailwindCSSでの対比
  • Tailwindの方がレビューしやすい
    • 上書きされてるかもと考えなくていい
    • ArbitaryValuesがあったら警戒
    • モディファイアが少なかったら警戒
    • 機会にわかりやすいコードは人間もレビューしやすい

書籍の執筆

  • WebDBPressでtailwindの特集書いた人から紹介されて書くことになった
  • CSS初心者はターゲットにできない
    • デザインシステムでの活用を期待されているので
  • デザイナやマークアップやサーバサイドの人も読んでほしい
  • ユーティリティファースト vs セマンティックCSS
    • 対立があると議論が見やすくなる
  • 差分ではなくストーリーを書く
    • ブログなら前回からのアップデートで書けるけど本だとそうはいかない
  • フレームワークの入門書は歴史と思想を扱う

大変だったこと

  • 周辺技術全部使ったことあるわけじゃなかった
    • どれが必須でどれが好みの問題かはある程度見えていたしレビューもしてもらった
  • CSS設計の話は古いものもあってBEM以外詳しくなかった
  • tailwindのclassを紹介していく4章を書くのが大変だった
    • 5~10万文字かと見積もったら14万文字になった

文章を書く工夫

  • かっこいいルビを入れる
    • 着脱可能(プラガブル)
    • 修飾子(モディファイア)
    • 日本語と外来語の紐づけを簡単に示せる
  • 傍点を活用
    • 日本語にイタリックがないし太字多様も嫌だった

CharcoalとTailwindCSS

  • mimoさん

Charcoal

Iconify for TailwindCSSのすすめ

Iconify

引数のあるmixinのような仕組みをプラグインとして実装する

  • _yuheiyさん

CSSのmxin

  • matchUtilitiesを使うと引数のあるユーティリティを作れる
    • matchConponentsもある
    • 引数は1つしかとれない
  • tailwindの内部の書き方を真似ると参考になる
  • custom variablesを使うと1つのclassで複数指定するものを個別に指定できる

「メドレー & Ubie 共催:なるほど!人を助けるデザインのひみつ」に参加してきました

メドレーという会社とデザインチームのひみつ

  • 波切 雅也さん (メドレー)

メドレーのデザイン組織

  • 人材と医療のサービスをあってる
  • デザイナー12名
    • 2016: 1-3名
    • 2019: 5-6名
    • 2022: 10-12名
  • 人材PFと医療PFが分かれた
    • デザイナーも2つに分かれた
    • ドメインの課題を解決するため
    • 1つのままだと社内受託みたいになりそうだった
  • 少ない人数でスピードと効率重視
  • 中途半端に運用コストかかり続けるようなものがやらないという選択もとった
  • デザインチームの構造
    • 横断チーム
    • 人材PFチーム
    • 医療PFトーム

Product Design is Parenting

  • 前田 邦織さん (メドレー)

プロダクトデザイン

  • プロダクトデザインは子育て
  • リサーチ
    • 社内に医療従事者がいる
      • ペアプロみたいな感じできける
      • インプットをもらってデザイナーがドメインエキスパートになれるように
    • プロトタイピングをまず作る
  • 検証
    • 医科と歯科でオペレーションが違うとかあった
  • 評価/改善
    • リリース後要望やクレームに対して改善
    • 顧客が少ないと偏りがあって使われない機能があった
  • 子育てもプロダクトも成功失敗を繰り返して愛着がわいていく

ドン・ノーマンを超えていけ!未来のモノのデザイン

  • 畠山 糧与さん (Ubie)

未来のモノのデザイン

  • https://www.shin-yo-sha.co.jp/book/b455872.html
  • 「ひとりごとが2つあっても対話にならない」
  • 患者と医師の対話
    • 言いたいことが言えないとかがある
    • ユビーが翻訳者しての役割
    • ひとりごとではなく対話ができるようにデザイン

なるほど人を助けるデザインのひみつ

  • 吉井 裕貴さん (Ubie)

Ubieのミッション

  • テクノロジーで人々を適切な医療に案内する
    • 病気ではなく患者にアプローチする
    • 早期発見/早期受診につなげる
  • 医療に関する行動の本がいろいろでてる
    • なぜ病院受診しないかとか
    • 行動変容ステージ
      • 6ヶ月以内に行動する気があるって感じのたまにみるやつ
  • 人の行動を促すコミュニケーションのデザイン
    • 高度な医療のデザインもやってるけど特別難しいことをやってるわけじゃない

2024年2月に読んだ本

  • 2024年2月に読んだ本の記録です
  • 3冊目は読み終わらなかったので3月分で

ちいさくはじめるデザインシステム

ちいさくはじめるデザインシステムbnn.co.jp

  • SmartHRでのデザインシステムの事例を紹介した本です
  • 以下の点が印象的でした
    • まずは役に立つものを提供して使ってもらうところから始める
    • ミッション・バリューなど組織ぐるみで取り組まないと決められないことも含まれている
    • コンポーネント集が公開されていて実装を参考にできそう
    • ライティングについてのルールが多いのに驚いた
      • いろいろなパターンの言い回しがルール付けされてる

Tailwind CSS実践入門

gihyo.jp

「JAWS DAYS 2024」に参加してきました

  • 2024/3/2
  • https://jawsdays2024.jaws-ug.jp/
  • AWSからはここ数年離れてたので知らない話ばかりでした
  • IaC周り、データ連携周り、セキュリティ周りが知らないことが多くて聞いてて面白かった
  • 今はAWSは使ってないけど、使うとしたら話に出てきたこれを使うのかなとか思いながら聞けました

Keynote

  • Jeff Barr

ユーザコミュニティの話

  • 日本のユーザコミュニティは10年以上続いてる
  • 土曜日に自発的に参加しようと思う人が1000人いるだけですごい
  • スピーカーになれる人をもっと増やしていくと良い
  • 新しい人を受け入れていくために初心者向けのコンテンツも大事

ぼくのかんがえたさいきょうのAWSへのリソースデプロイ

IaCツール

  • CloudFormation
    • 記述量多くなる
    • Lambdaのデプロイが大変
  • Terraform
    • マルチクラウド
    • 独自の柔軟なyamlみたいな言語で書く
      • 設定値を並べる感じなので誰が書いても同じようなコードになりやすい
    • デプロイがはやい
  • SAM
    • サーバーレスなら便利
  • CDK
    • 中はCloudFormation
    • 抽象化されて便利だがされすぎというのもある
      • いろんなroleが作られてたり
    • TS/JS,Java,Python,C#,goなどいろんな言語で書ける
  • Pulumi
    • 中はTerraform
    • コードを書いていくタイプ
  • other
    • ServerlessFramework -有料になった?

どうデプロイしてるか

  • GitHub Actions
  • Terraform Cloud
    • Terraforの有料版で使える
  • CodePipeline
  • CodeCatalyst
    • 開発に必要な工程をまとめて提供してくれるAWSのサービス
    • CIのワークフローを作れる
    • サンプルがたくさんあるから0から作らなくてもいい
    • 東京リージョン未対応
  • PipeCD
    • GitOpsを実現するツール
    • コンテナイメージが配置されたらデプロイが動く
  • CLI
    • 手動でコマンドたたく

サービスクォータ、ちゃんと監視してますか?

クオーターの枯渇

  • 新しいリソースを建てられなくなる
  • 増加のリクエストが即時に対応されるわけじゃない
  • 監視してモニタリングするのがベストプラクティス

AWSクオーターモニター

  • AWS公式にある
    • 通知してくれるソリューション
    • cloud formationのテンプレート何パターンかある
  • 最低で月12ドルくらい
    • 監視する量による
  • 対応範囲がいのものもある
    • それらはCloudWatchで監視

人材育成専門企業の内製開発の現場から

  • 山下 光洋さん、木村 啓秀さん[トレノケート株式会社]

トレノケート

レーニングで使うシステム

  • 受講者とインストラクターが使うシステム
  • ベースはEC2 - RDS
  • 拡張機能はLambdaとかいろいろ
  • 出席管理をシステム化したり
  • リマインドの電話かけるところをAmazon Conenct使ったり

クラウド黎明期、いかにしてJAWSは始まったのか~熱い歴史をコミュニティ史として語り継ぐ

  • 渥美 俊英さん
  • 竹下 康平さん
  • 得上 竜一さん

JAWSの歴史

  • 2010/2の第0回が最初
    • Jeff BarrがLTしてくれた

コミュニティ

  • 2000年くらいまではエンジニアの勉強は資格だった
  • その後インターネットで様々な技術が広がった
  • OSSのユーザコミュニティが出てきた
    • Seasar2
    • そこに関わってた人でその後AWSに携わってる人多い

3.11

  • 震災時にAWSの力を体感した
    • ユーザコミュニティでの動きも大きかった
    • 募金を集めるようなサイトを短時間で一気に作った
    • サービス継続するITリソースが足りない人に呼びかけてサポートした

Leap Beyond

  • 変わらないもの
  • 変わったもの
    • サービス数10から240超
  • 語り継ぐもの
    • エンジニアが日本を救う

クラウドネイティブなデータ連携の最新動向:AWSサービスアップデートで何が変わった?

クラウドでデータ連携

  • API連携/データ同期/メッセージキュー/クラウドストレージ/ファイル転送

API連携

Amazon AppFlow

  • SaaSアプリやAWS感でデータ転送できるサービス
  • 対応コネクターが増えている
    • SaaS/AWSあわせて80サービスサポート
    • ex. BigQueryからS3へ転送
  • AWSサービスへの組み込み
    • 意識せず内部で使われるケース
    • ex. Amazon SageMaker Data Wrangler

AWS Step Functions

  • いろんなAWSサービスを組み合わえて分散アプリケーションを作成できる
  • JSONでワークフローを作る
  • Workflow StudioでGUIでもできる
  • Stepの中で外部のAPIをたたけるようになった
    • それまでは外部のAPIをたたくLambdaを作ったりしてた
  • ワークフローの失敗したところから再実行できるようになった
    • インプット変えたり編集してからの再実行はできない

データ同期

zero-ETL統合

  • ETLプロセスの家データ移動の課題を解決するもの
  • データ系サービスがニアリアルにつながる
  • AuroraからRrdshiftだとストレージレイヤで同期される
  • RDSからRedshiftはバイナリログに依存して同期される

ファイル転送

SFTP

  • プロトコルが枯れてる
  • 自動化や前処理後処理の作り込み
  • 監視やリトライが必要
  • AWS Trasfer Family
    • マネージドワークフロー機能
      • ファイル受信後に後処理できる
      • 複雑なことしたければLambdaでカスタムフロー
    • SFTP Connectorによる転送
    • EventBridgeへのイベントパブリッシュ
      • 転送成功失敗などフィルタ条件を設定し対応するアクションを実行できる

AWS DataSync

  • オンプレとAWS間でデータ転送するサービス
  • S3とかEFSとか対応してる

サーバーレスで豊島区の緊急設備トラブルを解決するアプリを作った話

サーバーレス

  • マネージドサービス
    • 提供から運用まで面倒を見てくれるサービス
  • サーバーレス
    • サーバー管理が不要(サーバーはある)
    • 実行環境を素早く準備できる
    • オートスケーリング
    • 高可用性
    • 使用量に応じた課金

なぜサーバーレス

  • 開発スピード
  • 売上の見込めない段階で初期コストを削減したいので従量課金がいい
  • 定期的な運用作業を減らしたい

作ったもの

  • 豊島区限定で使える
  • ビル店舗でのトラブル時に手の空いてる作業員とマッチングするアプリ
  • 作業員とチャットでやり取りして見積もりとったりする
  • だいたいサーバーレスだが一部そうでないものも使ってる

モバイルアプリ

管理画面

  • React/TS/SPA
  • CloudFront + S3
  • API Gateway + Lambda

バックエンド

  • golang
  • GitHub ActionsでCI回してLambdaにデプロイ
  • AppSync(チャット機能で利用)

コールセンター

  • Amazon Connectで電話で自動応答し担当割り振る

決済

技術書を書く技術:あなたの知識を世界に届けよう!!

  • 佐々木 拓郎さん

ほんの企画

  • 潜在読者市場
    • 初心者が一番多い
    • カテゴリ内にニッチ市場が存在する
  • 大きな市場で競争するか、ニッチな市場でオンリーワンを狙うか
  • 市場が育ってない分野は初心者向き
  • 大きな市場では大きめなニッチを狙う
  • 上級者向けは茨の道
  • 企画の作成
    • ペルソナとか決める
    • 目次レベルに詳細化

執筆

  • ツール
    • Word
      • 出版社に指定されることも
    • テキストファイル
  • 心得
    • 位置行目を書くのが一番難しい
    • まずは章節項をコピーするところから
    • 文章でなく箇条書きから
    • ChatGPTに相談
  • 校正補助ツール
    • textlint
      • Web+DB Pressで整備されたtextlint-rule-web-plus-dbがお勧め
    • ChapGPT

本の宣伝

  • 増刷しないと出版社の利益は殆ど出ない
  • 初版を売り切ることが大事
  • 執筆に書ける労力の1/10は費やす覚悟

AWSセンセーション私とみんなが作ったAWSセキュリティ

セキュリティ対策の進め方

  • やってることはいろいろ言えるかもしれないがどれくらできてるか表現するのは難しい
  • AWS Well-Architectedフレームワーク
    • 長年蓄積されたベストプラクティス集
    • 6つの柱の1つがセキュリティ
    • 優先度付けや達成度の評価には向いていない
  • セキュリティ成熟度モデル
    • セキュリティの現在地を確認できる

IAMとSecurity HubとGuardDuty

IAM

  • 必ず多要素認証(MFA)
    • すぐにやる
  • アクセスキーを極力使わない
  • roleを活用し一時的な認証情報を使う
  • IAM Access Analyzerで不要な公開を検出
    • すぐに有効化する
    • 公開されてるものを1つずつチェックできる
  • 定期的な店降りし/最小権限

SecurityHub

  • 危険な設定がないか検出してくれる
  • 100%を維持するのが理想

GuardDuty

  • AWS上で発生しているインシデントの検出
    • マイニングされてるよとか

成熟度モデルで素早く強化

  • AWSセキュリティ成熟度モデル
    • 9つのカテゴリに対して4段階のフェーズに区切ってセキュリティ対策をマッピングしたもの
      • クイックウィン/基礎/効率化/最適化
      • Phase1のQuicWinで素早く対処できて効果の高いもの
      • Phase2の基礎が最低限できていてほしいレベル

基礎のレベルまで頑張る

  • AWS公式トレーニン
    • Security Engineering on AWS
      • 3日間のセキュリティ管理者向けのコース
  • AWS Control Towerによるマルチアカウント管理
    • Organizationsを利用する必要がある

「TechBrew in 東京 〜フロントエンド技術選定、その後どうなった?〜」に参加してきました

RemixでWeb標準を学んだ1年

to BプロダクトでVite+React Routerを採用して半年後の感想」

技術選定

  • 背景
    • ユーザごとにUIをカスタマイズするようなサービス
    • 初期フェーズで技術で詰まることはさけたい
  • SSR
    • SSRは特に必要なかった
      • 業務用PCで使うアプリ
      • 認証前のページはログイン画面だけ
    • SPAでよさそう
  • Next
    • Static Exportの選択肢もあった
    • Dynamic Routingがビルド時に決まったidしか使えないのがダメだった
    • Nextの高機能のものはほとんどいらない
  • FWを使わない
    • GraphQLを使うがそこはFW影響ない
    • routingはReact Routerでよさそう
    • Reactとは心中するがそれ以外は切り捨てられるようにしたい
  • Vite + React Router

その後

  • Viteで困ることはない
  • React RouterがSentryと相性いい
  • トップレベルのコンポーネント以外はrouterの情報はpropsでもらって純粋にした方がよかったかも
  • チャンク分割は試行錯誤が合った

フロントエンドのEMが技術選定するときに取り組んだこと

  • 伊代田 大樹さん
  • ウェルスナビ株式会社

EMの領域

技術選定

  • プロダクトの戦略から考える
  • なるべく技術課題と組織課題は分ける
    • 学習コストがどうこうとか
  • フロントエンドエンジニアとしてのキャリアの観点
    • 特定技術にロックインしない
    • いろいろな技術を採用して触れやすい環境
  • エンジニア採用のしやすさ
  • メンバーの成長へのリスクマネジメント
    • レビュー体制とか

レガシーなフロントエンドをReact / Next.jsにリプレースした結果

リプレース

  • リプレース前
    • jQuery使ったり
    • Vue2もあったり
  • 技術選定
    • NextとNuxtを比較
    • 他社事例とか
    • React/Nextに決めた
  • LPなどはNext
  • 新規開発はVite + React

LaravelからフロントエンドをNext.jsに段階的に移行している話

リプレース

  • リプレース前
    • Laravel
    • Vue
    • jQuery
    • 歴史があるので可読性悪い
    • ビルド/リリース時間かかる
    • デザインの統一感ない
  • 負債の解消

フロントエンドの移行

  • 段階的に移行
    • 開発者の負担
    • ビジネス側に段階的に見せたい
    • トップページから段階的に
      • デザインも最新に

技術選定

  • Nextを採用
    • フロントエンド専任はいなかった
    • C向けなのでSEOも意識
    • 情報量が多い
    • チューニングの選択肢が広そう
    • パッケージングされてるのが楽

よかったこと

  • Lint/Formatterはいってて品質あがった
  • Storybookでデザイナーとのコミュニケーションが楽に
  • 情報はたくさんあるから困ることは少なかった
  • App Routerのコロケーションで見通し良くなった

残念だったこと

  • vercel使ってないから使えないものがある
  • Nextへの依存
  • ベストプラクティスがわからなくて試行錯誤

コンパウンドスタートアップにおけるフロントエンド技術選定のこれまでとこれから

今バウンドスタートアップ

  • 創業から複数プロダクト
  • 部署でサービスを区切らずデータを中心にサービス統合
  • プロダクト間で連携
  • 複数のプロダクトを管理

技術スタック

  • VueとNextが共存
    • Vueで型がつかなくてつらいところがあった
    • Reactも使うようになった

Vue3

  • Vue2から3に移行しないといけない
    • React化も選択肢に合ったがコストが高かったし開発を止めるわけにもいかない
    • React行くにしてもVue3を経由して型安全になってからの方がいい
  • Vue3に移行して
    • WebpackからViteにしてはやくなった
    • 型がきいていい
    • 機能開発と並行して進められた
    • bootstrap-vueがVue3の恩恵受けにくいので剥がしてる

React/Vue共存

  • 共存して2年くらい
  • よかったこと
    • 採用の間口が広くなった
    • 既存資産を活かしづらいのでゼロベースで改善できる
  • 困っていること

今後

  • 新規はNext
  • VueもReactに移行
    • 開発が止まらないようにしながら

「花王インハウスデザイナーの「よきモノづくり」 | A11yTokyo Meetup」に参加してきました

  • 2024/2/27
  • https://a11ytyo.connpass.com/event/308749/
  • 普段webだけやってる立場からすると全然違う分野の話でしたが、デザインのプロセスはwebに近いところもあり面白かったです

現在のインハウスデザイナーの視点、役割、デザインプロセス

  • 平田 智久さん
  • 花王株式会社
  • 商品デザイン作成部

商品デザイン作成部

花王ユニバーサルデザイン

  • 2011年に指針として発表
    • 見やすい、わかりやすい、使いやすい
    • 1995年からやってる

デザインの考え方

デザイン手法

  • 以下の2軸でプロトを繰り返す
  • イデア的方法
    • 創意工夫
  • 定量的方法
    • 人間工学/感性工学

ブランド価値

  • 購入前〜購入〜廃棄のライフサイクルがある
    • 後ろに行くほど満足度が高いものがいい

ワークショップ

  • 要介護の人の感覚を体感するワークショップを多くの社員が体験

シャンプーきざみ開発〜現在

  • シャンプーとリンスが紛らわしいという消費者からの声
    • 調査すると間違える人は多かった
    • 色や大きさなどメーカーによって様々なので判別がつかない
    • 目が不自由な人に聞くと触覚にたよった識別をしてると分かった
  • 形を変えたりいろいろ試した
    • ぎざぎざが評価がよかった
    • 一般の人に受け入れてもらえるか
      • アンケートとったら受け入れてもらえそうだった
  • ぎざぎざの形などもパターンを試して1991年10月に第一号発売
  • 業界で統一した方が消費者の利益が大きい
    • 各社数年で導入が進んだ
  • その後日本や国際的な規格になった

インハウスデザイン事例

アタックZEROの容器

  • キャップ計量にさまざまなストレスがあった
    • メモリが見にくい
    • 開け締めを両手でやらないといけない
    • 液漏れして汚れる
  • →正確な計量を片手で使えるようにしたい
  • ワンハンドボトル
    • 親指方とか洗濯バサミ方とか
    • 家庭訪問のべ2756人でどこに置いてるかやどう使ってるかを調査

クイックルワイパーミニ

  • 介護用品の掃除道具として開発
    • 壁や廊下を掃除する商品がなかった
    • トイレ周りの掃除
  • 3Dプリンタでプロトタイプ作ったりして検証
  • ワイパータイプが床の掃除がしやすいくてよかった
    • 膝を曲げなくていい
    • 顔をトイレに近づけなくていい
  • ユニバーサルデザインが商品価値を上げている例