たつのおとしごのしっぽ

技術に楽しくしがみつく えんじにあ の備忘録

(今更)Frontend Study #1を見たのでメモ

イベント参加 Web開発

はじめに

ずっと#1だけまだ見てなかったので見たついでにメモをとります。

Front-End Study #1「Cloud Native時代のフロントエンド」 - YouTube

『フロントエンド領域』を再定義する

ブラウザのシェア率ってこんなふうに簡単に見れるのか・・・。
Browser Market Share Worldwide | Statcounter Global Stats

2020年度のフロントエンドの傾向

  • パフォーマンス指向の向上
  • 設計より規約

SSRはほとんどのケースで必要ない

  • Google BotのCSRコンテンツに対するインデックスが数時間遅れる時のみ

WebAssembly (モダンなウェブブラウザーで実行できる)が追従するのに期待
WebAssembly を使うならRust

フロントエンド開発者も知っておきたい AWS Lambda とサーバーレス

AWS Amplify: フロントエンド向けツールセット。AWS各サービスが使いやすくなる
（ハマるとCloudFrontが分かってないと辛いとか、TwitterのTLにて）

SSRにLambdaを使うとリクエスト分サーバーを起動する水平スケールによってCPU負荷が高まってもレスポンスが返せる
しかし、静的ファイルも実行されるのでデプロイサイズがコールドスタートへの影響がでる
静的アセットはS3＋CloudFrontが良い。
Next.jsではプラグインがある。

STUDIOのデザインツールとホスティングの仕組み

デザインツールからWebサイトを作れるデザインツールに変更。
（リリースして使ってみて方向性を決めるのアジャイルっぽくてよい）

画像の最適化として

  • 画像のアップロード時にサイズ別に書き出して描写時に適切なサイズを読むようにしている
    • フロントエンドで分割してアップロードしている
  • WebPに対応していてサイズが小さくしている
  • Intersection Observer API - Web API | MDN を用いたLazyLoad

SSRのレンダリング前に取得するものをJson Static化してヘッダーだけSSRにする、DOMtreeはレンダリング 時に別途取得することでパーフォーマンス改善を行っている
OGデータのためにheadだけSSRにしている

【Engineering Team Presentation】各社の事業を支えるアーキテクチャの感想

イベント参加

【Engineering Team Presentation】各社の事業を支えるアーキテクチャ - connpass

日経電子版のキャッシュ戦略

  • API-Secret発行のルール
    • APIkeyの中に検索して出にくい文字列を入れておく
    • Secretの種類判別が可能
    • GitHub検索をかけて流出に気付ける
  • 表示速度によるWebの離脱率が上がっている
  • 性能チェックはサーバーログではなくフロントエンド側でやるのが望ましい
    • サーバーログだと正しく測定できない
  • レイヤーごとに色々なキャッシュがある
    • ブラウザキャッシュ
      • 再利用時の通信量が減らせる。最速
    • CDNキャッシュ
      • 配信目的なら高効率
    • Appバックエンドキャッシュ
      • バックエンドAP Iが落ちたときの代用が可能
  • push通知後はアクセス数が増える(10倍近く)

Mercari iOSクライアント Re-Architectureのその後

micro view controller

  • ViewControllerを分割する
  • UIStackViewで繋げてUIScrollViewに載せる
  • iOSのAtomicDesignのような印象(感想)

Stateの管理が大変

  • Fluxライクな方法、Store、Action、Dispatchで管理する

Declarative UI　についてはこの辺りをみると良さそう
https://old.black/2020/10/06/what-is-declarative-ui/
https://stackoverflow.com/questions/33655534/difference-between-declarative-and-imperative-in-react-js

新規事業「Bill One」を加速させる技術選択

  • バックエンド

    • Kotlin＋Ktor

  • DDD

    • エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) を読もう

クリーンアーキテクチャ脱却とSwiftUI導入までの道のり

  • MVP、MVVM、CleanArchotectureなどの混在設計

    • 長いプロダクトではありがちらしい

  • MVVM＋CleanArchitecture から MVC＋Storeパターンに

    • -> UIの変更の修正がしやすくSwiftUIに移行しやすい
    • CleanArchitectureから脱却したのはアプリ側にビジネスロジックがなく単純であったため
    • 複雑な画面はStoreパターンやFluxに近い設計になる。State構造体で管理する

質問の回答も興味深かったです。
Androdiの設計

Androidは基本をMVVMにして、Repositoryを用意するような設計になっている
Androidの設計にあたってはGoogle推奨の設計ドキュメントが公開されているため
iOSは表示周りはFrameworkに依存していて共通化が難しい

会計 freee バックエンドの今後

  • 開発者がみるべきスコープを決める
    • 機能をマイクロサービス に切り出す
    • 機能を分離する目的だけだとまずい

巨大なモノリスで辛かったためModular Monolith で設計する
-> アプリ内をドキュメントごとにモジュールに分解する

https://www.infoq.com/jp/news/2019/10/shopify-modular-monolith/ より Shopify の Modular Monolith について

拡大に伴ってShopifyは保守不能になり始めたため、新しい機能を提供することが難しくなった。例えば、ひとつのコードの変更によって、一見無関係なコードに意図しない副作用が発生したり、アプリケーションのビルドとテストに長時間を要したりするようになったのだ。
...

私たちがモノリスの望ましい部分として考えていたことのすべては、コードの所在とデプロイ先がひとつの場所であることの結果である、ということが分かりました。同時に、私たちが問題だと考えていたことのすべては、コード内の異なる機能間にバウンダリが欠けていたことの直接的な結果である、ということが分かったのです

モノリスのような単一で展開可能なユニットを維持しながら、マイクロサービスのようにシステムのモジュール性を高めることが設計目標であるという認識に達したのだ、とWesteinde氏は説明する。これを実現するため、Shopifyでは、モジュラモノリス(modular monolith)パターンを採用した。この方法では、コード間のバウンダリは可能になるが、コードは同じ場所に配置され、同じ場所に展開される。

下記の記事なども良さそう
https://qiita.com/tkyowa/items/ae9fa550237cb6f48318

Web開発におけるアクセシビリティについて学ぶ

Web開発 イベント参加

はじめに

Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass を見て、アクセシビリティ面白いと思い、色々調べたり実際にアクセシビリティ改善を行ってみました。

アクセシビリティとは

Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass の基調講演「Webエンジニアとしていま知っておきたいWebアクセシビリティ」より、
アクセシビリティとは「状況を広げることを追求する。使いやすさに比重を置いていない」ことです。

ユーザビリティとの違いは簡単にいうと下記のように話がありました。

欧米では法律で義務化されていたり当たり前のように考慮されているため日本もそうなっていくのではないかと思います。

アクセシビリティのガイドライン

Web Content Accessibility Guidelines (WCAG) Overview | Web Accessibility Initiative (WAI) | W3C があります。
今の最新はWeb Content Accessibility Guidelines (WCAG) 2.1 のようです。
ガイドラインに解説書Understanding WCAG 2.1 があって合わせて読むのが推奨のようです。
日本語訳WCAG 2.1 解説書 を読んでたら気が遠くなりそうなぐらい長文ですね。
GitHub - waic/wcag21: WCAG 2.1 Japanese で管理しているようです。

WAI-ARIA

デフォルトと異なるUI実装をした場合にセマンティクス(意味)を伝えることができるHTML属性のこと。

Accessible Rich Internet Applications (WAI-ARIA) 1.1
WAI-ARIA オーサリング・プラクティス 1.1
上記のサイトからメニューを見て合う要素を探して実装してみるのが良いとのことです。

さらに、マークアップを進化させる WAI-ARIA の基本 より補完できるものは以下の3点。

役割 : role
状態 : aria-
プロパティ : aria-

また、WAI-ARIAの仕組みをざっくりと説明すると

WAI-ARIAが補完したセマンティクスはアクセシビリティAPIを通じて支援技術に伝わる

だそうで、すごく分かりやすかったです。

他社のアクセシビリティの事例

WCAG難しいよーってなる場合は他社さんのガイドライン見た方がまだ分かりやすいし手を出しやすいと思いました。
Ameba Accessibility Guidelines
freeeアクセシビリティー・ガイドライン — freeeアクセシビリティー・ガイドライン Ver. 202101.1 ドキュメント

検証ツール

aXe: 定番なチェックツール。CIに組み込むことも可能 (axe-core)
Lighthouse: Chromeに搭載されている。パフォーマンスも測定できる

eslint-plugin-jsx-a11y, eslint-plugin-vue-a11y: eslintでアクセシビリティのチェックを行う

@storybook/addon-a11y: コンポーネントでアクセシビリティをみる

Visible: Webサイトのアクセシビリティ診断。あなたのサイト、見えますか？ - Visible
acot: Accessibility Testing Frameworkとして現在開発が行われている。acot-a11y/acot: Accessibility Testing Framework. More accessible web, all over the world.

Puppeteer と ARIA Handler: ARIA情報をもとにブラウザ自動化を行う。Puppeteer と ARIA Handler | Medium

VoiceOver: Mac OSであればVoice Overを使って、簡単にスクリーンリーダーを扱うことができます。macOS の VoiceOver で Web サイトのスクリーンリーダー対応をはじめよう - Qiita

Webアクセシビリティの適用の考え方

Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass の基調講演「Webエンジニアとしていま知っておきたいWebアクセシビリティ」で話していた内容になりますが、
作り手の目線で考えるとこのサービスを多くの方に使ってもらえるようにする普遍的な改善、そして段階的に改善するものというのが、いい考えだなと思います。
また、主要な画面に絞って実施する、最初は手動で試すというのもハードルを下げるという意味で重要だと思います。

アクセシビリティの問題のあるサイトとして駒瑠市という架空のWebサイトがあるそうです。
https://a11yc.com/city-komaru/

実際にアクセシビリティ改善を行ってみた

今回改善するのはこのサイト。

cinderella-color-quiz.web.app

やはり好きなコンテンツは、たくさんのユーザーに楽しんでもらいたいですからね！
早速Lighthouseを測ってみました。

Lighthouse(アクセシビリティ改善前)
Lighthouse(アクセシビリティ改善前)
77%と低いですね…。
Lighthouseで測った時に出てくるリンクLearn moreで原因を見つつ改善していきましょう。

Buttons do not have an accessible name

ボタンのアクセシビリティに関する名前がついていないと言われてます。
確かにイメージカラーを選択するボタンにはコンテキストがありません。

<button class="ui circular button circle-btn " style="background: rgb(247, 161, 186);">

aria-labelで別途名前をつけることにします。

Background and foreground colors do not have a sufficient contrast ratio.

リンクのコンストラスト比が十分ではない、つまり背景と色が似てて見づらいと言われています。

<a href="https://sparql.crssnky.xyz/imas/">

aタグを使っているだけなのですが、デフォルトの色だとコンストラクト比足りないんですね。

上記の対応で100%になりました！
他にも自動テストでカバーできない項目も書いてあります！
適宜参考にしましょう。

Lighthouseでは最低限のところのチェックのみなので、改善するにあたって、
accrefs - Webアクセシビリティの参考資料まとめ
で情報を仕入れつつ、
Reactなら初学者は
アクセシビリティ – React
今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界
を見て、aria属性に困ったらWAI-ARIAのガイドラインを見るという方法で進めてみるのが良いのではないかと思いました。

UIT meetup vol.11『フロントエンド紅白LT合戦』を聞いた感想

イベント参加

はじめに

UIT meetup vol.11『フロントエンド紅白LT合戦』 - connpass
ここ最近見たLTの中で一番面白かったです。

Twitterのつぶやきはこちら。
https://twitter.com/search?q=%23uit_meetup%20since%3A2020-12-18_19%3A00%3A00_JST%20until%3A2020-12-18_22%3A00%3A00_JST&src=typed_query&f=live

セッション

Chakra UI ではじめる Tailwind CSS へのささやかな抵抗

Headless Components Design

  • Headless UI
    • Tailwind CSS のクラスを渡して使う
    • Utility-firstのCSSを使って機能だけ持ったコンポーネントを作っていくのではないか

選ばれたのは Next.jsでした - Next.jsによるServer Side OGP ⽣成 / Next.js was chosen - Server Side OGP generation with Next.js - Speaker Deck

  • OGPとは、サーバー側へリクエストした際にOGP用のmetaタグ(og:image)を含む

  • HTMLを生成することでOGPカードを生成するようになっている

  • Next.jsはデフォルトでSSG対応が可能(pages下のページコンポーネントをプレレンダリングする)

  • SSGはビルド時のみデータ取得を行うため変化のあるデータには向かない
  • SSRはリクエストごとにデータ取得を行う

Build you a static site generator - Speaker Deck

SSGの自作の話でした。

  • SSGはブログ利用が初めに思いつく
  • 学ぶなら自作しよう
  • SSGはファイルのパイプラインになっている
  • いくつかのパイプラインを作って組み合わせて実現していく

Roconで実現する超型安全なルーティング / Super Type-safe routing with Rocon - Speaker Deck

ルーティングの説明がわかりやすいので、そこだけでもすごく価値があるなと思います。

  • SPAを作るときページが動くたびにアドレスが変わっていく部分は標準はHTML5HistoryAPIだが、生では扱いにくい
  • URIに対してコンポーネントを表示するということの橋渡しをやるのがRouteingライブラリ。
  • Reactではreact-routerがデファクト。
  • Next.jsはファイルシステムベースなのでファイル名がパスになる。

画面間のデータ受け渡し方法のメリットデメリット

  • グローバルなステートに入れる
    • 簡単で型安全
    • フロー特有のステートをグローバルに入れるなどステート設計の悪化する恐れ
    • 再読み込み時に消える、進む戻るに連動しない
  • URLに入れる
    • 耐久性のあるURLになる
    • 大きいデータは入れられない
    • 型制限できない
  • History Stateに入れる
    • 再読み込み、進む戻るに連動する
    • URLに入らず耐久性のあるURLにならない
    • 型制限できない

  • =>現状のデファクトになっている画面遷移の実装方法だと間違ったURLに飛ばす可能性がある

  • Roconなど型安全に作ることができる

  • Next.js/Nuxtはファイルシステムベースのルーティングで固定のためルーティングの型安全は保障できない

Reactルーター選定術 2020年のファイナルアンサー - Speaker Deck

  • OGPのためにSSR時にコンポーネント呼び出し前のfetch処理が必要…
    • (OGPは苦労しそうなイメージ)
  • react-routerなどはCSRだけでなら有力
  • TwitterのクローラーがJSの実行に対応していなためog:imageの設定が必要
    • =>SSRが必要
    • =>SSR時は事前fetchが必要

  • React SuspenseはSSR対応できていない。CPU負担大。

  • CSRだけでいいならuseSWRを使うほうがReduxよりお手軽

  • そもそもuseSWRとは、Reactでデータフェッチを行えるHooks
  • stale　while　revalidateの略で、古くなったデータは再取得するというキャッシュ戦略の略称なんだそう。

嬉しいことに、useSWRは第二引数で与えたfetcherが一度取得したデータをクライアント側でキャッシュしてくれます。これで、APIを通じて取得したデータをstoreに格納せずに済むのです。

【React】useSWRはAPIからデータ取得をする快適なReact Hooksだと伝えたい - パンダのプログラミングブログ より

  • なんと…べんり…。
  • 素のReduxでSSRは大変
  • Next.jsを使おうということでやはりモダンな開発環境はベストプラクティス詰まっているからパフォーマンスや諸々含めて良いってことですね。
  • SSR/CSR/SSGに対応できるってすごいですね。

Front-End Study #2「Performance Tuning in depth」を聞いた感想

イベント参加

はじめに

下記のイベントに参加したため感想をつらつら書きます。
Front-End Study #2「Performance Tuning in depth」 - connpass

どのセッションもレベルが高く楽しかったです。
Twitterでも沢山つぶやきがあって参考になるので、イベント時間帯の記録を下記URLにのこしておきます。
https://twitter.com/search?q=%23FEStudy%20since%3A2020-12-15_19%3A30%3A00_JST%20until%3A2020-12-15_22%3A00%3A00_JST&src=typed_query

セッション

メタ・パフォーマンスチューニング

メタ・パフォーマンスチューニング - Speaker Deck パフォーマンスチューニング について普段考える機会が少なかったので勉強になりました。
以前携わっていたテーマで開発終盤で起動が遅い目標に達していないということでミリ秒単位でもいいから起動早くなるように四苦八苦して色々大変だった記憶が蘇りました。

まず、Core Web Vitalsとは状態だったので簡単に調べてみました。

上記の基準などの説明の後にパフォーマンスを考慮することについて話がありました。

  • パフォーマンスは生き物で、ユーザー体験を向上させるために考えるもの
  • エンジニアがすべきこと
    • パフォーマンス 指標を可視化する
    • Reactだとデフォルトで入っている
  • UIが高度化して単純な尺度だけで足りないと感じたら自作も視野に入れる
  • パフォーマンス 改善を職人芸にしない
    • 知見を共有して文化にする

パフォーマンス 可視化ツールの紹介もありました。今後使ってみたいですね。

他にもTwitterで下記の話をされていました。

  • 手軽な方法としてGoogleのデベロッパーツールもパフォーマンス確認に使える
    • Peformanceタブからパフォーマンスを見る
    • MemoryタブでHeapdumpを取得してメモリリークが起きてそうかチェックする
    • Coverageタブから現在の表示には何%のJSが使われているかチェックする
  • 非同期読み込みの際はキャッシュ戦略が大事
  • パフォーマンス をあげるのは大変だから最初から設計は意識しておく
    • 時間が経ってからタグマネージャーでたくさん3rd party JSが入っていると改善するのは大変
  • 全てのページで一通りパフォーマンス 測定しないとパフォーマンス が下がったことに気付けない

パフォーマンスについて調べていて下記の記事は初学者にも分かりやすく説明されています。 Webページ描画までのクリティカルパスは何でどのように最適化すればよいか具体的に書かれています。
Web パフォーマンスのための HTML 最適化 | メルカリエンジニアリング

Webページ描画までのクリティカルパス

  • HTMLをロードする
    • URLに対してリクエストするとHTMLをサーバーが用意する
    • ブラウザはHTMLをダウンロードする
    • ブラウザはHTMLを上から評価していきDOMと呼ばれるオブジェクトモデルに変換する
    • SSRならばサーバーのソフトウェア内部から更にリクエストを実行してデータを取得する
  • サブリソースをロードする
    • HTMLの評価時にサブリソースへの参照がある度にリクエストし、サブリソースをロードする
    • CSS ファイルと JavaScript ファイルのロードは特に影響大
      • CSSは非同期でダウンロードしてCSSOMと呼ばれるオブジェクトモデルに変換する
      • JavaScriptは同期的にロードする。この間HTMLの評価がストップする
  • DOM と CSSOM を組み合わせてページを描画する
    • DOM と CSSOM を組み合わせてレンダーツリーと呼ばれるスタイル情報を持った DOM ノードのツリーを構築
    • レンダリングツリーが構築されると描画が開始する
    • レイアウト→ペイントの順に実行

Web フロントエンドのパフォーマンスと、WebAssembly。期待できることと、できないこと。

festudy02-wasm - Speaker Deck

そもそもWebAssemblyってなにというレベルだったので調べてみた。

  • WebAssemblyとは、ブラウザ上で動くバイナリコードの新しい仕様とのこと。WebAssemblyとは - Qiita
  • 資料上は、安全でポータブルなコンパイラターゲット、ソースコードをコンパイルして作るバイナリファイルと説明がありました。
  • WASMと略す。
  • 仕組みとしては
    • Goなどの言語からWASMでビルドする。
    • WASMモジュールからエキスポートされた関数をJSから呼び出して使うことができる。
  • 下記で試すことが可能

WebAssemblyとパフォーマンスに関する話についての話は

  • WASMは必ずJSより早い訳ではなく、パフォーマンスにばらつきがない(ブラウザごとに違いが少ないなど)とのこと
  • パフォーマンスという面で見るとWASMは最後の手段として使う。CPU由来のパフォーマンスをあげたいなど

高速なメディアを実現させるための戦略と戦術

frontend強いといえば日経のイメージありますね。

Windows10でブルースクリーンが表示されて起動しなくなった時の対応記録

使用PC

機器: DELL INSPIRON
OS: Windows10 Home

現象

Windowsのある機能を有効にしたところ起動直後しばらくするとブルースクリーン「IRQL NOT LESS OR EQUAL」が表示されるようになってしまいました。再起動してみましたがやはり表示されます。
そこでセーフティモードで起動してWindowsの機能を無効化しましたが同じようにブルースクリーンが表示されてしまうため、復元ポイントによってWindowsの機能を有効にする手前まで戻ったら使えるようになりました。これで良かったと思って一日使ってシャットダウン。
次の日、Windowsを立ち上げようとするとブルースクリーン「MEMORY MANAGEMENT」が出て再起動を試みたのですが、一切動かず。
強制終了後に再度立ち上げたところDELLのロゴが繰り返し表示されるようになりました。セーフティモードで起動してみましたが、やはり結果は同じでした。

DELLのSupportAssistは起動できるため、ハードウェア診断を行った所バッテリーのみに問題がある様子。
ということはWindowsの問題っぽい…ということで、BIOSの初期化やRTCリセット、BIOSRecoveryを実施したのですが、RTCリセットをした途端なにやらBitLockerの調子がおかしくなりました。
正しい回復キーを入力しているのにBitLockerが解除できない…これはデータ救出が難しくなるまずいと思い、フォロワーや専門家に助けを求めました。 BitLockerの解除はトラブルシューティングからコマンドプロンプトを起動して行いました。
これでとりあえずBitLockerの解除はできるようになりました。

このまま設定の初期化などして状態が悪化したら辛かったので、ここからデータサルベージ最優先で動きます。
別のPCでWindows10Homeの別のPCを用意して外付けSSDとして認識させ、データサルベージを試みました。
*因みに別のOS(Windows7)などだとBitLockerの解除してても解除ができないとエラーが出るみたいなのでなるべくOSはそろえた方が良さそう。
開こうとすると「ファイルまたはディレクトリが壊れているため、読み取ることができません。」とダイアログが表示されてしまったため、チェックディスクをコマンドプロンプトから実行したところ表示されました…！データ残ってた！

さらにSSDを戻して元のPCで起動したら普通にWindowsが立ちあがりましたので、記念カキコです。
PINの設定が初期化されていたり挙動に不安要素は残っているため改めてPCの状態を見てもらって問題があれば初期化する予定です。

何かの拍子にファイルか何かが壊れてWindowsが起動できなくなったのでしょうか？何がともあれ良かった！
幸い、トラブルシューティングやDELLのサポートアシストは表示されたため診断やコマンドプロンプトが叩けて良かったと思いました。

教訓

  • ハードウェアの問題かソフトウェアの問題か切り離して考えよう
  • ブルースクリーンが出たら対応していくうちに状況が悪化する可能性もあるためデータサルベージ優先で動こう
  • 常にバックアップはしておこう！
  • こんなこともあるので個人的にはサポートは入っててよかった。この後、無料でPC見てもらえ問題あればSSDも交換してもらえる。ただし問い合わせは電話対応を選択しよう
  • Windows10ProのノリでHomeを使ってはいけない

Developers Boost 2020 に参加した感想

イベント参加

はじめに

デブサミは参加したことがあったのですが、今回始めてデブストに参加しました。
面白かった内容がいくつかあったので感想を記載したいと思います。

セッション

【Developers Boost 2020】凡人エンジニアの生存戦略 - Speaker Deck

共感の嵐でした。今もエンジニアとして生きていけるか不安に思うことがあり、その糸口が見つかった気がします。

平凡なエンジニアが生き残るためには自分の知名度をあげることが重要として語っていてました。
それは、自分を知ってもらうことで価値が上がり、例え優秀じゃなくても雇ってもらえる、ポートフォリオになり自分を売り込めることができるといったことから精神が安定するのではないか？ということです。
また、習慣にしたいことを継続するために目標をできるだけ小さくして、記録してグラフ化したそうです。

さらに、パーキンソンの法則の第一法則「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」から人は時間をあるだけ費やしてしまうため仕事を区切ることが非常に重要だと感じました。
例えば、この記事もかけようと思ったら時間いくらでもかけてしまいますよね…。でも綺麗な記事が書けるより紹介された記事を読んだり、実践してみたりした方がよっぽど有意義ですね。

また、話の中でいろいろなセミナーなどの話も引用されていたので、それも一通り読みました。

【まつもとゆきひろ氏　特別講演】20代エンジニアのためのプログラマー勉強法のまとめ 2019/3/30 - Qiita

【まつもとゆきひろ】20代のためのプログラマー勉強方法を聞いてきた。 - Qiita
成功するには知名度を上げる、ニッチなところを攻めて横展開するというのがとても納得しました。なんせWeb開発はもう猛者だらけで知名度上げられそうにない…。

【若手向け】成長を加速させる「一人のふりかえり」を学ぼう - connpass

繰り返し振り返ると知識が引き出しやすくなる。
振り返りとして自己防衛本能に逆らうために良いところを書くように毎日書くようにしようと思いました。
毎日同じ場所同じ時間にやることでルーチン化すると良いとあったため髪を乾かしている間にスマホでGoogleスプレッドシートに振り返りを記載するようにしようと思います。

また自分にしっくりくる振り返り方法が探したいと思っているのでチートシートを見て色々試してみたいと思いました。
ふりかえりを拡張する「ふりかえりチートシート」 - Qiita

エンジニアとしてこの先生きのこるために - Speaker Deck

エンジニアとしてこの先生きのこるために t_wada さんの講演を聞いてきた。 BIT VALLEY -INSIDE- Vol.10 #bvinside - noratoraのエンジニアログ
技術の学び方を学んだ方が良いとのことで、手を動かして学ぶや毎年少なくとも1つの言語を習得する、身の回りをプラグラミング対象としてwebサービスを作るなどを挙げています。

ここでもアウトプットは大事とありますね。エンジニア成長の話で聞かないことないくらいアウトプットは当たり前なのでしょうね。

技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018 － Publickey

Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition / Worse Is Better - Understanding the Spiral of Technologies 2019 edition - Speaker Deck

技術の変化は螺旋になっていて、流行はバージョンアップしながら行き来する、これTwitterで話しているの見たと思いました。
生き残る技術は制約が大きいこと、抽象的であることと話しています。

スルーしたくない学びたい技術はGame Changerな(流れを一変させた)技術としています。

Game Changerな技術をスルーするかしないか。例えば、具体的なGame Changerの技術、RailsやReactなどをスルーするのはかまわないと思いますが、それらがなにをもたらしたか、変わった後の世界は知る必要がある。
例えば、開発に関わる労力やコストを圧倒的に短くするもの、あるいは構造を大きく変えてしまうものや、そのものを不要にするもの。
そういったインパクトのあるGame Changerは世界を変えていくもので、スルーしがたい。そういったことを見極める必要がある。
逆に言えば、そこまででないものは、「お好みで」。

#RSGT2020 テックリードは未来の話をしよう / Tech Lead in Scrum - Speaker Deck

TLは最初は開発チームの先頭に立ち引っ張っていってるけど最終的には支える側になる。
TLはありたい組織になった時に他部署のやりとりなど前面に出る、ディスカバリー、リファインメントなどを行う技術者として必要です。

また、学びとして　「心を否定しない」そう考える元になった部分を取り除くことや誰かのせいにしたくなったときは期待で動いているため現実を受け入れて次をどう良くするか考えるというのは大事な考えだと思いました。

不確定要素の強い時代の生存戦略 ー U30が好きなコトで突き抜けるためには？[Session17] - Speaker Deck

生存戦略の流れで以下の話をしていました。

  • 自分のありたい姿を言語化する。なければとにかくやってみて楽しかったこと好きなことを選ぶ
  • 自分のスキルを棚卸しする
  • 生存戦略を考える。自分が提供できる価値は何か？明確にする。攻めたアウトプットをする。自分の強みを掛け算する

自分もローモデル探していたのですが社外の人でも良いしローモデルは時代によって変わるもの！という話が心に響きました。
技術発表は間違っていても今ベストなら良い、あとで訂正すればいいという話も覚えておいてどんどん発信していきたいです。
人に依頼するときは相手のメリットを明確にするのも重要ですよね、上司などに提案するときは意識したいです。

他に興味深かったセッション

コミュニティ活動で差別化をめざすエンジニアの一手/Distinguish by community for engineers career - Speaker Deck

これは、便利そうなので今度使ってみたいです。

技術が好きで好きで好きでたまらないエンジニアが「取締役」になって思う、マネジメントキャリアパス 技術が好きで好きで好きでたまらないエンジニアが「取締役」になって思う、マネジメントキャリアパス

話で出てきていた書籍やWebサイトなどもマネジメント学ぶ時に見てみようと思いました。

Google re:Work - ガイド: 優れたマネージャーの要件を特定する

Twitterで実況をしていたらフォロワーにセルフマネジメントが大事と言われてWebサイトを紹介してもらいました。
セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!

タスクばらし、30-60分に分解して進捗をチェックするのは意識的に取り組めていなかったので今実践中です。
タスクをする前に30分ごとにこれくらいまでやるなど書きます。それ専用のWebサイトとかあっても良いかもと思いました(作りたい)。
でもいまだに結構ずれます。自分は詰め込む癖があるので、考えた時間の1.5倍で組むように試してみようと思っています。
タスクの優先順位は間違っていないか、どの仕事にどれだけリソースを割くのか、そもそもなぜこれをやるのかなど考えることも忘れないようにしたいです。
やっていけばそのうちできるようになると言われたことがあったので、常に意識していきたいです。

まとめ

自分のキャリアプランに迷っているときはデブストの発表を聞いて考えるのが良いなと思いました。
過去のデブストの話ではちょまどさんの話も好きです。
好きで打ち込めることを探すこと――ちょまど氏のキャリアを形成した「オタ駆動開発」とは【Developers Boost 2019】 (1/3)：CodeZine（コードジン）
自分に合うローモデルを見つける機会がデブストなのかもしれません。

「Developers Boost 2020～U30エンジニアの登竜門～」講演関連資料まとめ：CodeZine（コードジン）

自分のことを考えてみた

【まつもとゆきひろ】20代のためのプログラマー勉強方法を聞いてきた。 - Qiita

好きなものを見つけるためには、インベントリ（棚卸し）、つまり自己分析をするべき。
得意、趣味、興味、思考、背景といった自分の特性について理解を深めることが大切。

少し考えてみました。
得意: UI作成？デザインの違いなど細かいところに気づくでも抜けている
趣味: 漫画読むこと、アニメ見ること、考え苦しみながらアプリ作ること
興味: 仕事ではWPF、Reactだけど仕事以外だとVUI、Unity、Web
思考: 新しいことを学ぶのが好き、時々頭使いながらプログラミングしたくなる
背景: フロントエンド中心のキャリア
より、生存戦略もあとでゆっくり考えていきたいです。

【Developers Boost 2020】凡人エンジニアの生存戦略 - Speaker Deck より
私も習慣の目標として以下を実施します！

  • 運動 1分
  • 読書 1分
  • 開発 1commit/1page(今書籍に沿って開発をしているため)