インターネットの情報とどう向き合うか (子供向け)

普段、子供には iPad を使わせていますが、ちょっとしたゲームや学習アプリを使う程度で、YouTubeSafari には制限をかけて自由には使えないようにしていました。とはいえ、そろそろ自分でインターネットを使って調べたりできるようになった方がいいのかなと。それなら、インターネットの使い方やインターネット上の情報とどう向き合うか、親として伝えないといけないかなと思ってまとめました。


インターネットが広く使われるようになって、自分の知りたい情報が簡単に手に入るようになりました。分からないことを自分で調べて解決できるのは、とても大事なことです。インターネットはそういうときに役に立ちます。

インターネットの難しいところは、そこに書いてある情報が正しいとは限らないということです。

今、目の前にある情報が本当に正しいのか、もしかして間違っているんじゃないか、しっかりと疑って自分の頭で考えることが大事です。

もう1つインターネットの難しいところは、インターネットに残した情報は残り続けることです。インターネットに流した情報は簡単には消せません。

自分や家族、友達の個人情報写真を安易にインターネットに流してはいけません。

インターネットにはいろいろな情報があります。それらの情報はたくさんの人が見ることができます。知らない人がどこかで自分の情報を手に入れているかもしれません。インターネット上でやったことや言ったことは常に誰かに見られていると思って行動しましょう。

もちろん、誰かの悪口や批判をインターネットに書いてはいけません。直接、その人や家族に言えないようなことは書かないようにしましょう。

インターネットにはいろいろなことが書いてあります。自分もいろいろなことを書くことができます。同じ文章でも読む人によって捉え方が違います。ある人はその文章を読んで笑うかもしれません。別の人はその文章を読んで悲しくなるかもしれません。自分は悪口だと思っていなくても、相手は悪口と感じるかもしれません。誰かに何かを伝えるということは難しくてデリケートなことです。

ちなみに、これはインターネットだけではなく、実際に人と話をするときも同じです。相手が言ってることは正しいとは限りません。自分はおもしろいと思っていることが相手もおもしろいと感じるとは限りません。もちろん、それはパパやママが相手でも同じです。

インターネットにはいろいろな情報があります。それはとても役に立ちます。しかし、その中には見てはいけないものもたくさんあります。もし、「これは見てもいいのかな?」「見てはいけないものを見てしまったかな?」と思うことがあれば、迷わず相談してください。そのあとどうするかは一緒に考えましょう。

そして、インターネットに書いてあることがすべてではありません。本を読むことも大事です。人と話をすることも大事です。インターネットを上手に使ってください。

マージリクエストにラベルを付ける

以前、GitLab の運用についてこんな記事を書きました。

kntmr.hatenablog.com

現在もだいたい同じような運用をしているのですが、最近、少しだけマイナーチェンジしました。タイトルの通りなんですが。

現状

これまでのメンバーの作業の流れはこんな感じ。

  1. チケットで作業を振られる
  2. feature ブランチを切る
  3. 実装 & commit
  4. 実装完了次第、マージリクエストを投げてレビュー依頼する

ちなみに弊社で使ってる GitLab のバージョンはとても古いです。お察しください。

課題

メンバーが作業途中でも適当なタイミングでレビューしたい。特に、朝会などで昨日までの実装分をお互いに見ながら軌道修正しつつ開発を進めたい。そのためには、作業着手して feature ブランチを切るのに併せてマージリクエストを投げてもらえばいいが、作業途中のブランチを誤ってマージするのは避けたい。昔の GitHub の PR みたいにタイトルに「WIP」とか付けてもらってもいいけど、もっと機械的にフィルタして作業ミスを防ぎたい。というか今の GitHub なら Draft Pull Request とかあるのにね。

ラベル

今さらですが、デフォルトのラベル以外にカンマ区切りで任意のラベルを設定できることに気が付きました...。ラベルを使えばいい感じに整理できそう。

f:id:knt_mr:20200702105709p:plain

運用

feature ブランチを作成したらマージリクエストを投げて in progress ラベルを付ける。in progress ラベルのブランチはマージしない。

実装が完了してレビューするタイミングになったら in progress を外して review ラベルを付ける。レビュワーは review ラベル (とマイルストーン) でフィルタして、必要なブランチだけをレビューしてマージする。


余談ですが、master や開発のメインブランチなど、feature ブランチのマージ先となるブランチは Protected にする。Git に不慣れなメンバーが勝手にマージリクエストを Accept しちゃうので...。このあたり、権限設定とかもう少し細かくできるんだろうか。他の現場ではどうやってコントロールしてるんだろう。

伝える情報をどのように整理するか

開発チームのメンバーに作業を依頼するときに、どのような情報を伝えるかは重要なポイントになります。メンバーが十分に理解して納得して作業に取り組んでもらった方が、認識齟齬によって生じる手戻りを防げるし、メンバー自身にも主体性が生まれるだろうと思っています。

で、伝える情報をどのように整理するか。例えば、次のような観点で整理してみます。

Why

なぜこの作業が必要なのか、エンドユーザーが困っていることは何か、全体を俯瞰して概要や影響範囲を説明します。これから自分が取り組む作業にはどんな意味があって、これをやることでどんな効果があるのかを認識してもらいます。さらに、メンバー自身がこのチームに存在する意義を見出して欲しいと思っています。「自分は誰かの役に立っている」と認識することで、主体性と責任感を持って作業に取り組んでもらえればと考えています。

What

Why の課題を解決するために何が必要か、これから何を作るのか/改善するのかを説明します。Why の内容と対になるように説明することでより理解しやすくなると思います。

How

What をどのように実現するか、どうやって作るか、そのためにどのような前提知識が必要になるかを説明します。メンバーのスキルレベルによって伝える情報の粒度を変えたりします。すでに独力で進められるメンバーであればざっくり説明して任せるし、経験の浅いメンバーであれば図解して説明したりドキュメントに落とし込んで説明します。いずれにしても、何かしらの形で設計のレビューはします。

When (How much)

作ったものはいつリリースするのか、そのためにはいつまでに作業を終えて欲しいかを説明します。リリースやテスト/レビューの時間を考慮していくつかマイルストーンを置きます。あらかじめ無理のないスケジュールを設定しますが、朝会などで進捗を確認して必要に応じて都度調整します。

Who

なぜこの作業をあなたに任せるのかを伝えます。「仕様を把握しているから」「過去に類似の作業をやったことがあるから」「フロントエンド、あるいはバックエンドが得意だから」「詳細なドキュメントを作って欲しいから」など、こちらから伝えられることは伝えるようにします。ただ、このあたりはメンバーの性格や仕事の進め方などを分かっていないと、なかなかこちらの意図通りに伝えるのは難しいかもしれません。

とはいえ、だいたいいつも「今、手が空いてるひとがあなたしかいないのでぇ~」みたいな雰囲気になりがち。


このような観点で情報を整理すると自分の理解にも役立ちます。当然、自分がきちんと理解していないとメンバーに正確に伝えられないので。現場からは以上です。

JSUG勉強会2020その5 Spring Boot 2.3 徹底解説 に行ってきた #jsug

JSUG勉強会2020その5 Spring Boot 2.3 徹底解説 に参加しました。今回はオンライン開催。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

Wavefront は初めて知りましたが、VMware が提供するサービスなんですね。k9s や コンテナ向けの機能がどんどん追加されていきますね。ヒープメモリの割り当ての説明が参考になりました。Memory Calculator は便利そう。

YouTube の URL はこちら。

https://youtu.be/mQC7yPTAE5oyoutu.be

以下、メモから抜粋。

Deep dive into Spring Boot 2.3

docs.google.com

  • Boot 2.3 からは半年に1回リリースに
    • Spring Data のメジャーアップデートに対応するため
    • Gradle バージョンアップ (6.3+) が必要
  • k9s Support
  • /actuator/health エンドポイント
    • HealthIndicator
    • 外部サービス向けのヘルスチェック?
    • k9s コンテナのヘルスチェックには不向き
  • Liveness State
    • プロセス内部の状態のヘルスチェック
    • NGの場合はプロセス再起動する (コンテナ再作成)
    • /actuator/health/liveness
    • 外部サービスのヘルスチェックは含めない☆
      • コンテナを再起動しても外部サービスが復旧するわけではない
  • Readiness State
    • トラフィックを受けられるかどうか
    • NGの場合はトラフィックを遮断する
    • /actuator/health/readiness
    • 外部サービスのヘルスチェックを含める
      • アプリ側で対処できるものは含めない (Circuit Breaker, Fallback, ...)
  • Liveness と Readiness の間に任意の処理を入れられる☆
    • リクエストを受ける前にキャッシュをロードしたり
  • k9s 環境ではデフォルトでエンドポイントは有効
    • k9s 以外では明示的に要設定
  • HTTP エンドポイントの他に、イベントの終了結果に応じてコマンドで状態を変えられる☆
  • Graceful Shutdown
    • レスポンスを返す前にシャットダウンするとエラーになったり
    • 高負荷な状態でシャットダウンすると不整合が起きたり
    • Boot 2.2 までは自前で実装
    • server.shutdown=graceful
    • spring.lifecycle.timeout-per-shutdown-phase
      • シャットダウンまでの猶予時間?(デフォルト30s)
    • 新規リクエストは受け付けない
  • Docker Image Support
    • チュートリアルの Dockerfile では不十分
    • Dockerfile 以外でも Docker Image は作成可能
  • Cloud Native Buildpacks
    • OCI イメージを作成できる Maven/Gradle Plugin
    • Paketo (Buildpack 実装)
    • 使われる JRE は BellSoft Liberica☆
    • ヒープサイズとノンヒープサイズを自動設定☆
  • Buildpack の Docker Image ではロード済みのレイヤー (ミドルウェア) は再利用される?
    • push/pull されない
  • コンテナのメモリサイズと -Xmx の設定値を同じにするのはNG
    • ノンヒープの分を考慮する必要あり
    • Memory Calculator
      • ヒープサイズ = コンテナメモリ - ノンヒープ
      • jar 内のクラスファイル数, MetaSpace, Thread Stack など
    • ノンヒープがコンテナメモリを超える場合はエラー
      • スレッドや Reserved CodeCache の分を減らしたり
    • Memory Calculator のパラメータと Tomcat などのパラメータは合わせる
  • Head Room
    • Java 以外のプロセスが利用するメモリ
  • Memory Calculator は個別に利用可能
  • JVMKill Agent
    • OOME が発生したときにプロセスを kill する
    • k9s のときに適宜コンテナを再作成してクリーンな状態に
  • Layered Jar Format
    • アプリのレイヤーをさらに細分化 (application/dependencies)
    • 依存ライブラリの更新頻度は高くないので push/pull 不要
    • Dockerfile multi-stage builds と組み合わせると Dockerfile でも可
  • デフォルトではレスポンスに例外メッセージを含めなくなった
    • server.error.include-message, server.error.include-binding-errors で変更可
  • spring-boot-starter-validation が含まれなくなった
    • Bean Validation を使う場合は個別に依存を追加
    • メモリフットプリントが大きいから
    • Hibernate Validation 6.1 から自動でロケールを見てメッセージを表示
  • spring-boot-properties-migrator
  • Wavefront
    • SaaS モニタリングサービス
    • Sleuth, Micrometer からメトリクス/トレース送信
    • Spring Boot から Freemium アカウント作成可
    • ワンタイムリンクでダッシュボードにアクセス可
    • 2回目以降はプロパティに設定
  • GraalVM Native
    • Actuator, JPA, Cloud Function, Jafu
    • メモリフットプリントが小さく
    • AWS Lambda 上で動かすためのアダプタ?
    • ネイティブのコンパイル時間は CI のサンプルのビルド結果を参考に

Remote.vue #1 に行ってきた #remote_vue

先日、Remote.vue #1 に参加しました。オンライン開催。簡単に所感をまとめます。

lapras.connpass.com

所感

アーキテクチャから API までいろいろ知見のある内容でした。特に、アーキテクチャではどういう判断基準があってその構成になったのかを聴けるのはとても参考になります。今回、初めて知ることもいろいろ...。Vue.config.errorHandler とか。

あと、SSR もまともにやったことがなくて、恥ずかしながら初めて hydration を知りました。ただ、こういうのをまったく知らずに引き出しもない状態だとハマったときに抜け出せなくなるので、知見として話を聴いておくことができてよかった。

最近、Vue をがっつり使った開発から少し離れてしまっているけど、ちゃんとキャッチアップしておかないと...。とりあえず、このあたりから調べようかと。

  • Vue 3 (Composition API, ...)
  • Nuxt.js
  • TypeScript

YouTube の URL はこちら。

https://youtu.be/rx249I9JmNUyoutu.be

以下、メモから抜粋。

超高速devサーバーvite

  • Native-ESM powered web dev build tool
  • 開発ビルドツール
    • dev: ネイティブ ES モジュールに最適化
    • prod: rollup を使ってビルド
  • vue-loader がサポートしているものはサポートしている
  • VuePress
    • サーバーの起動が遅い
    • ES モジュールの HMR
    • SFC を ES モジュールで動かしたい
    • ES モジュールに最適化されたバンドラがない
  • Snowpack
  • サーバーの起動が速い
  • オンデマンドコンパイル
  • HMR (他のバンドラより速い)
  • 開発モードのときはバンドルしない?
  • esbuild
    • 他のバンドラより速い
  • HTTP リクエストごとにコンパイル
  • HMR は画面単位で動く
  • キャッシュ
    • 変更がないものは304で返す
    • Service Worker
      • サーバー側のキャッシュを破棄するのに Service Worker を使ってたり
  • Koa
    • Express より高速な HTTP サーバー
  • プラグインアーキテクチャ
  • Module Rewrite Server Plugin
    • 相対パスから絶対パスに書き替える
    • import のパスに timestamp が付く
    • import しているモジュールのsグラフを持っている
  • HTML Rewrite Server Plugin
  • Vue Server Plugin
  • HMR Server Plugin
    • サーバー側の変更が WebSocket を経由して通知される
    • dynamic import で変更されたモジュールをダウンロード
    • HMR グラフを解析
    • 木構造を遡って対象を探す
    • HMR 対象のファイルが見つからない場合は index.html をリロード
  • VitePress?React?Preact?

ぼくのかんがえたさいきょうのVueあーきてくちゃ

  • ディレクションの知識
  • コンポーネント150個&API100個以上の規模の事例
  • フロントの責務 > 遷移と参照☆
    • Vue Router
    • 一覧の処理 ⇒ ロジックとして共通化する
    • 詳細 ⇒ 愚直に作り込む (共通化の余地がない?)
  • フロントの責務 > 権限と操作☆
    • 権限は参照/操作における DOM 表示とAPIリクエストに関わる
    • バリデーションも権限のひとつと言える?
  • 見通しのよい構成☆
    • SetupContext (this が持っているコンテキスト?)
      • これに依存する処理は切り出す
  • ディレクトリ構成☆
  • enums
    • 定数が扱えるなら enum でも union でもいい
    • namespace をオーバーライドしてメソッドを生やせる☆
    • 文字列で扱えばデシリアライズしなくても比較できる
  • models (BaseModel)
    • APIクライアント
    • Vuex の store の action に API リクエストを入れない
    • BaseModel は基本的な CRUD のメソッド
    • レスポンスはデシリアライズを通す
    • extend したクラスでは CRUD は書かない
  • modules
  • mixins
    • SetupContext を利用した処理
    • Composition API の SetupContext を切り出したロジック
    • ビジネスロジックに近いけど SetupContext がないと処理しづらいもの
    • emit, $router, $store はここで呼ぶ
    • 一覧系の共通ロジックを入れたり
  • views のコンポーネントは画面と1対1に
  • 汎用的なコンポーネントは components に
  • ドメインビジネスロジックを持つコンポーネントは templates に
  • Vuex に API クライアントの責務は持たせない
    • 画面共通リソースとの store, およびその永続化に留める☆
    • ログインユーザー情報, 権限, など
  • moment.js のロケールファイルを除去してファイルサイズ縮小
    • day.js がよさそう?
  • v-bind.sync☆
  • 部分型☆

Vue.observable で状態を管理する

  • Nuxt.js + TypeScript
  • ページをまたいでグローバルな状態を管理したい
  • Vuex (モジュールモード)
    • ディレクトリ構成に対応するプロパティが動的に生える
    • TypeScript と相性がわるい
  • Vue.observable☆
    • Vue 2.6+
    • js のオブジェクトをリアクティブにできる
    • Vue の data 関数の仕組みも同様
    • Composition API の reactive 関数とほぼ同じ?
  • Vue.config.errorHandler☆
    • 例外発生時に登録した関数が呼ばれる
  • エラー状態を Vue.observable で定義
  • Vue.config.errorHandler の関数でエラー状態を変更する
  • SSR の場合、Vue.observable だけでは hydration できない?☆
  • Vue.observable は状態を変更する口が少なくなる
    • 見通しがよくなる

NuxtでSSRしている時でもGoogle Optimize(ABテスト)を動かしたい

  • Google Optimize
    • A/Bテスト, GUIでテストの設定ができる
    • GAなどの連携
  • Nuxt で SSR しているサイトで Optimize を使いたい
  • hydration☆
    • 場合によっては DOM を破棄して再構築する
  • hydration が終わってからテストを起動/実行する
    • app.mounted (Vue)
    • window.onNuxtReady (Nuxt) ※ドキュメントに書いてない...
  • vue-server-renderer

終わりゆく Vue 2.x 時代の状態設計の答えと Vue 3 の Provider への期待

  • Inject を軸に構成する
    • Vuex への依存は抑える
    • HTTP 通信など SPA 外部への依存は Inject を通して DI 的に実装する
  • モーダルのフラグ > portal-vue, Teleport (Vue3)
    • 仮想 DOM 上の親子ツリーとは別のところに状態をマウントできる?
  • Vuex を使わないだけライフサイクルフックに乗れる☆
  • ストア使いたいけど Vuex じゃなくてもいい
  • Inject☆
    • Nuxt.js の Plugin に同梱されるオブジェクト注入の機能
    • アプリケーションの this に生える依存を DI できる
    • vue-test-utils でモック化しやすい
    • TypeScript の型定義を追加する余地がある
  • 必要最小限の API と依存で状態が管理できる
  • inject 関数の第2引数に入れているもの以外は外に露出しない
  • Recoil
  • Vuex の型定義 (Vuex.Store<any>)
    • 次期バージョンから改善される
  • vue-test-utils と相性がよい
    • this に依存が生えるので mocks が使える
  • Inject は粒度が小さいものになるので取り回しやすい☆
  • Vuex を HTTP リクエストのキャッシュに使わない
    • HTTP キャッシュ or Inject でオンメモリ
  • Prototype 拡張や provide / inject は Vue 2.x 自体にある
    • provide / inject は Vue 3 でより扱いやすくなる
    • Composition API と合わせて使う
    • React のカスタムフックみたいな
  • Vue.observable + Inject で Composition API に近い書き方になる☆
  • inject の粒度を考えて使わないと $ が煩雑になりそう
  • スコープを狭めることを自分で考える☆
    • Vuex では仕組みとして提供されている部分?
    • state を直接いじらないとか mutation を通すとか...

改めて考えるフロントエンドライブラリ共有LT会に行ってきた #ouchi65

先日、改めて考えるフロントエンドライブラリ Angular, Vue, React, jQuery etc... 〜何を利用してる?共有LT会〜 に参加しました。オンライン開催。簡単に所感をまとめます。

techplay.jp

所感

今回、Angular, Vue, React, jQuery etc... ということでしたが、ほとんど Vue だったような...。ただ、取り組んでいる課題や工夫の話が聴けてとても参考になりました。個人的に TODO<T>: any は興味深かったです。

あと、分類のグラデーションというのも面白かったです。自分はパターン2と3かな。確かに段階的に移行できるのは Vue のメリットかもしれないし、これがいわゆるスモールスタート可能と言われるやつですかね。

途中、アンケートを取るところがいくつかありましたが、自分の環境ではできず...。ブラウザから Zoom に参加しているからだろうか?

YouTube の URL はこちら。

youtu.be

以下、メモから抜粋。

LINEサービスをTypeScriptに置き換えた際のノウハウ&苦労話

  • テストコードがない
  • 環境が古い
    • webpack, Babel, ...
  • ビルド環境が違う
    • Browserify, module.exports/require, import/export
  • TypeScript
    • 型の安心感, コードレビューの負荷軽減
  • テスト
  • ts 運用基盤の構築
    • 中長期的にプロジェクトに適応させる
  • 小さく適用する
  • ts コンパイル
    • 既存 js ファイルのビルド結果は変えない
    • 正しくトランスパイルできているか
    • 小さいファイルから ts 対応, ビルド生成物の差分を確認
    • tsconfig の allowJS オプション有効化 (jsDoc で型チェック)
    • tsconfig の target を es2019 に
      • これまで通り Babel で Polyfill を入れたい
      • ts 側で Polyfill を入れることも可
  • Vue の SFC を ts 対応
    • Vue.extend
    • vue-class-decorator や vue-class-component は変更が大きい
  • ビルド時間短縮
    • fork-ts-checker-webpack-plugin
    • 型チェックのプロセスを分離
  • ビルド環境をシンプルに
    • ts-loader で js/ts をビルドできるように
  • テスト
    • Karma ⇒ Jest
    • window オブジェクトを書き替えるテストがやりやすい
    • jest.resetModules
    • まずはユーティリティ系から
  • 移行中にリファクタリングや修正はしない
    • 問題が起きたときに切り分けしづらい
  • TODO<T>: any
    • とりあえずビルドを通してあとで直せるように
  • computed の返り値の型を明示的に書く
  • target 以外に transpileOnly=true を設定

Frontend負債返済の野望 @ Repro

www.slideshare.net

  • 負債返済によって開発コストを下げる
  • フロントエンドとバックエンドの切り離し
    • BFF
    • フロントエンドのロジックを Rails 依存から切り離す
  • フロントエンドだけで適切なアーキテクチャ設計が必要
    • 関数型言語の影響が入ってきている
    • 過去の js のノウハウは基本的に使わない (混ぜない)
  • Vue.js にはモデルレイヤがない?
    • MVVM が難しい?どうやって状態を持つか?
    • immutable な state を考えると関数型のアプローチがよい
  • Vue 3 を待つ余裕がない ⇒ React に転換?
  • 余談) うさぎのプレゼンツール

ビザスクliteなVue.jsの使い方

様々なプロダクト環境から垣間見るVue.js

  • Rails + Vue
    • helper でカバーできない動的処理を Vue に任せる
    • Vue は jQuery の代わり?
    • SSR にできる
    • SFC の仕組みが生かしにくい
      • Lint, UT
      • テストは E2E 頼み
    • Vue 以外が DOM に触れる
  • Vue + Rails
    • コンポーネントの mount と props に値を渡すのみ
    • Rails と Vue のインタフェースが限定される (props/API)
    • SSR にできない
    • 渡したい値は props に詰め込む
  • Vue
    • Rails と Vue のインタフェースは API のみ
    • バックエンドとフロントエンドが分離される
    • API を mock すれば画面実装可能
    • E2E テストが難しい
  • 完全 Rails から徐々に Vue にシフトしたり
    • Vue の Progressive さがいい感じにマッチしている
    • テンプレートベースだから?テンプレートエンジンに組み込めるから?

TechTrain しくじり先生 - Nuxt.js, Vue.jsにおけるしくじり

  • ページをまたがるグローバルなストア
    • ログイン, ログアウト, Firebase 以外の処理, ...
    • pages に書いてある
    • ⇒ Nuxt.js + ts, Action から状態を触る
  • 他ページ用の store が冗長にロードされる
    • 肥大化した data プロパティ
    • API通信でN+1
    • ⇒ 余計なロードを削る
  • SSR
    • SPA, meta タグなし, リッチカード対応なし
    • ⇒ client タグなど
  • ページ遷移で UI がチラつく
    • API通信でローディング表示なし
    • ⇒ v-cloak, loadingindicator
  • SSR がどのくらい SEO に影響するか
    • Google が SPA に対応しているけど...

Amazon Transcribe + Amazon Translate + α

Amazon Transcribe と Amazon Translate を題材にしたハンズオン。

ハンズオン3の文字起こし + 翻訳パイプラインで、とりあえず、文字起こししたテキストを翻訳して S3 にアップロードするところだけ。

gist.github.com

日本語テキストをそのまま json.dumps すると Unicode エスケープされるようなので、第2引数に ensure_ascii=False を指定する。

参考

AWS Lambda でS3にファイルがアップロードされたら、加工して別フォルダにファイルを作成する(Python) - 株式会社CoLabMix