読書メモ アプレンティスシップ・パターン
以前から持っていた本なのですが、久々に読み直したのでその内容をメモっておきます。 それほど世間一般で有名でない本かと思うのですが、個人的にエンジニアの心に刺さる名著です。
アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)
- 作者:Dave H. Hoover,Adewale Oshineye
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/07/08
- メディア: 単行本（ソフトカバー）
概要
卓越したソフトウェア開発者になることを切望する駆け出しエンジニアに心構えを説く本。 中世の工房で働く徒弟制度に倣って、それらの弟子(アプレンティス)の日々己の技芸を磨いていた世界をモデルとして、 ソフトウェア開発で技術を磨きたいエンジニアに日々直面する課題と解決策をパターン形式で解説しています。
所感
この本では 駆け出しエンジニア向けの心構え指南本と書いていますが、結構抽象的な内容が多いため、駆け出しエンジニアには実はそれほど 実感が湧かないのでないかと思います。 しかし、ある程度ソフトウェア開発の現場で辛酸をなめ、苦労したエンジニアが読めば、ここに書いてある内容は心に刺さると思います。例えば、 技芸の習熟を志すが、年齢を重ねるにつれて、自分の思ったようなキャリア選択肢が見当たらない.. 現場があまりにも混乱している.. 管理職への昇進を命じられ、世間はそれを歓迎している.. ソフトウェア開発でない別の道の方が向いているような気がする.. などなど、ソフトウェア開発に従事している以上一度は体験するお悩みとそれに対してどのような行動が推奨されるのか、見事に記載されています。先人の筆者たちも同じく苦悩して、どう決断したが書かれています。
この本の良いところは、自分の漠然とした悩みを言語化し、パターン化してくれていることです。言語化されていることにより、 自分の悩みがエンジニアにとってある程度の普遍性を持つこと、そして言語化されていることによりこの内容を上司や同僚との会話することが可能になります。
非エンジニアのビジネスチームの人にもエンジニアの悩みとかこういうものだ、ということをかいつまんで説明するのにも使えます。 内容自体は抽象的な説明も多いので、自身や周りの人たちの現場経験にうまく適用して説明するのが良いかと思います。
冒頭でも書きましたが、それほど有名ではない(と思っている)し、あまり売っていない本ですが、 ソフトウェア開発に関する技術の向上を志し、将来に悩むエンジニアにはバチっとくる本ではないかと思います。
Auth0の管理画面から ユーザ検索する方法
Lucene syntaxに慣れていない方向け。 ぱっと検索したいときになかなか出なかったので、メモっておきます。
名前完全一致
name:"AAA"
名前部分一致(正規表現)
name:/AAA/
メールアドレス一致
email:"sample@auth0.com"
auth0id一致
user_id: "xxx|xxxxx"
詳しく知りたい方は
lucene syntax
読書メモ 入門 監視
掲題の本の読書メモを残しておきます。 最近はインフラ系の本のネタが多めです。普段JavaScriptばっかり見てる反動かもしれません。
- 作者:Mike Julian
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本（ソフトカバー）
概要
監視に関する考え方とその方法論について広く解説しています。ざっくりまとめると、
- 昔ながらのオンプレミスのシステムでなく、クラウドで動作しているシステムに関して監視の考え方とその方法を解説
- ビジネスKPI, フロントエンド, サーバサイド, ネットワーク, セキュリティ のそれぞれで監視すべき内容と方法を説明。ただし、 個別のフレームワークや製品の使い方についてはほとんど立ち入らない。
といった感じでした。
所感
自分は監視と言うとメトリクス収集したり、エラーログ見つけてアラート投げるんでしょぐらいの理解でしたが、もっとビジネスKPI含めてシステムの何の振る舞いを監視すべきか、どう監視すべきかなど、 監視に関するそもそもの考え方から説明されており、非常に参考になります。
さらにフロントエンドやサーバサイド、ネットワークなどそれぞれの技術領域ごとの監視の基本戦略を解説しているので、 実務での監視の導入や見直しの前に見ておくと有用かと思います。
ちょっと余談ですが、ネットワークの部分だけやたら詳細な気がしたのですが、これは筆者がネットワーク好きなんだろうなと勝手に思いました.
また、副題にモダンなモニタリングと書かれていましたが、コンテナで動くシステムの解説はあまりなく、このあたりの監視方法ももう少しあればよかったなと思います。 個別のフレームワークや製品には立ち入ってないレベルでの説明なので、(あえて言うとLinux前提なのでWindowsユーザには少し微妙かもですが) 使用している製品に関わりなく役立つ内容かと思います。
AWS API GatewayのLambda Proxy Integration 使用時にLambdaのタイムアウトとその検知の扱い
掲題のやりかたについてちょっと調べたので、その内容をメモしておきます。
Lambda プロキシ統合とタイムアウト
API Gatewayから Lambda連携する際に、Lambda Proxy Integration(プロキシ統合)という機能を使用すると、 API GatewayからのLambda呼び出しと、そのリクエストとレスポンスをよろしくマッピングしてくれるので、いちいちマッピング定義を書かなくても LambdaとAPI Gatewayを連携できるのでよく使うのですが、Lambdaのタイムアウト(実行時間超過)の扱いについてちょっと困りました。
Lambda プロキシ統合を使用すると、統合レスポンスのマッピングが自動化されるので、個別に設定することができません。
さらに、LambdaがタイムアウトしたときのメッセージはLambda側でいじることができないので、API Gatewayからは
以下に説明されているような 502 不正な Lambda プロキシ応答 として認識されてしまい、 API Gateway呼び出し側からは非常に分かりづらい
ものとなってしまいます。
いろいろ試行錯誤しているうちに、以下のような方法で落ち着きました。
- API GatewayのLambda プロキシ統合使用時にLambdaのタイムアウトをハンドリングするのは諦めて、基本的に API Gatewayのタイムアウト時間 < Lambdaのタイムアウト時間 になるように設定する。
- 上記の設定により、Lambdaがタイムアウトする前に、API Gatewayが
504 Gateway Timeoutを返してくれるので、それで分かるようになる。
タイムアウトの検知
次に、Lambda or API GatewayでのタイムアウトをCloudWatchに書かれるログを見ながら、指定した時間枠に一定数以上発生すればアラートを投げるという処理を考えます。タイムアウトをログから検知する方法は以下の２通りが考えられます。
- Lambdaのログから検知する。Lambdaのタイムアウトメッセージは変更できないので、 "Task timed out after xxx" という文字列を引っ掛けてCloudWatchで集計する
- API Gateway の ログから検知する。 API Gateway がタイムアウトした場合は、 以下のような
504 Gateway Timeoutが記録されるので、このステータスと、resourcePath を使って、どこがタイムアウトしたかを検知する。
{
"requestId": "xxxx",
....
"requestTime": "06/Feb/2020:10:32:29 +0000",
"httpMethod": "GET",
"resourcePath": "/test",
"status": "504",
}
また、API GatewayのログをCloudWatchへ書き込むには以下の手順を行う必要があり、デフォルトでは出力されません。
今回は後者のAPI Gatewayでのログ集計と検知を採用しました。理由としてはLambdaの変更できないメッセージを検索文字列として引っ掛けるのは気持ちが悪いのと、API GatewayとLambdaのタイムアウト時間は微妙に異なるので、Lambdaが応答返したけどAPI Gatewayはタイムアウトを返しているケースなどが拾えないなどがあるからです。
...と まあやってみると普通に至極当たり前のような内容を書いただけになっているかもしれませんが、一応調べてこういう内容になったということを記録として残しておきます。
PWA Night CONFERENCE 2020 メモ
PAW Night CONFERENCE 2020
以下のイベントに参加したので、聞いた内容をメモしておきます。 後半ほど集中力が切れてメモが少なくなっているような気がします笑。
基調講演
Edge of the Web
基調講演 ： Edge of the web(えーじ氏) | PWA Night CONFERENCE 2020
Edge of the Web - memo.md · GitHub
もともとPWAという用語がくる前からService WorkerやPush Notificationの概念はあった。 PWAという用語ができてから、説明しやすくなった。
今あるWebと違うものではない、ちょっとづつ進化させていく。
Forget abount PWA. Just build a "better" website
PWAは上司を説得するにはいい言葉。
一番素晴らしいのはホーム画面にアプリが追加できること。
アプリストアからインストールできたら素晴らしくない？ Miscrosfoftがアプリストアに登録できるようになる。
Trusted Web Activities(TWA)
AndroidアプリにPWAを埋め込むことができる。 ストレージが使える！！！
llama-pack
簡単にTWAを作ることができる。
shortcut
ホーム画面からショートカットを埋めることができる。
Web Share
アプリからアプリにデータを渡すことができる。 AndoridでいうIntent
SMS Receiver API
インドはほとんど電話番号入力-> SMS で完了している。 SMS通知から入力を自動化するような仕組み Appleと合意が取れつつある。
Clipboard API
クリップボード上の画像を扱えるように
Native File System API
ブラウザからOSのストレージにアクセスできる。
Web Authentication
物理的なセキュリティトークンを使用して、簡単に二要素認証が実現できる
この後のWeb
Privacy Aware Web
- 個人情報にセンシティブなWeb?
- Privacyをもっとケアするような動きになる。
3rd party cookie
- ブラウザで開いているURLが 1st party widgetなどは開いているURLと違うので、 3rd party
- 3rd partyにむけて、1st partyのcookie を送るのを防ぐ動きがある。3rd party cookieを制限すると、利便性が損なわれる。 SameSite=None
Mini apps
プログラムのなかで動かせる小さなプログラムが多い みにアプリを動かすプログラムをスーパーアプリと呼ぶ WeChatなど
Webでできる体験を考える会
Webでできる体験を考える会(折原 レオナルド賢氏) | PWA Night CONFERENCE 2020
audio ... Web Audio API 動き ... WebGL URL踏めば遊べる。Webというインスタント性がいい。 Bluetoothあれば色々できる。
Web Assembly と Web Worker - Web Assembly は instanciateStreaming が一覧楽。 - AssemblyScriptがお手軽
WebWorker - 重い処理をJSのメイン処理から外せる - 重いデータはTransferaObjectを使うと良い！
Push API - Firebase Cloud Messageing がお手軽
ScrapboxでのServiceWorkerとCacheの活用
ScrapboxでのServiceWorkerとCacheの活用(飯塚 大貴氏) | PWA Night CONFERENCE 2020
PWA Night Conf: ScrapboxでのServiceWorkerとCacheの活用 - daiiz
Serviceworker
FetchEventでresponseと間に存在するプロキシ
CacheStorage
キャッシュ保存戦略 - Network - Network First - Cache First
静的Assetなど、寿命が長いコンテンツは cache firstが良い。 Promise.raceでTimeoutと競う
PWA x PlayCanvasについて
PWA x PlayCanvasについて(羽賀 流登氏) | PWA Night CONFERENCE 2020
PlayCanvasとは - Javascriptのゲームエンジン。3Dに強い - Three.js と比較される。
進化するHTTP
進化するHTTP(奥 一穂氏) | PWA Night CONFERENCE 2020
HTTP1の限界 - 回線速度が早くなっても、ページロード速度の速さは頭打ちになる。 SPDY(HTTP２の全身) - １本のTCPコネクションで多重性を確保 -> HTTP2に
HTTP2とは - Push - 大量のレスポンスを流せる - HTTP2か1かの判断は、TLSのハンドシェイク時にやってる - HTTP2の方が遅くなる場合もある。特にネットワーク環境が悪い(パケットロス率高い時) -> パケットロスに弱い！！ -> 最適化が肝要
そもそもTCPも限界. TCP, TLS で 2RTT いる - TCP汎用化しすぎて、古いけど変えられない。ファイヤーウォールとかネット機器も見てる。OSも使う。
QUIC - もうTCPはいらん。UDPの上に全てのせる。 - ネットワークの環境が悪いところほど効果が出やすいという結果あり
HTTP3どうやって判断する - 初回はHTTP1or2でそのレスポンスヘッダにHTTP3が使える旨の内容が送られる。
Webブラウザは開発版が対応開始 WebTransport
まもなくやってくるVue3
まもなくやってくるVue.js 3(川口 和也氏) | PWA Night CONFERENCE 2020
もまなくやってくる Vue.js 3 - Speaker Deck
Composition API - 関数ベースでのAPI - 大規模環境でコードの再利用性が損なわれる。
Vue2同様, DI(Inject)も提供される。
ポータル - Wdigetを作成できる仕組み
Taking your web app offline (in a good sense)
Taking your web app offline (in a good sense)(Maxim Salnikov氏) | PWA Night CONFERENCE 2020
- ServiceWorkerをマネジメントするの大変
- Workbox を使う。
PWA on Windows
ChromiumベースのEdgeについて
エンディング講演 ： PWA on Windows (物江 修氏) | PWA Night CONFERENCE 2020
確定申告の都合上、４月リリース Edgeと違いUWPでなく、Win32なので、昔のアプリケーションでも動かせる。 内部で実はIEプロセスもあげられるので、IEがないと発狂する人でも安心
所感
どのセッションもとても有意義なトピックで、いかに自分がPWAについて理解していないかと、UXを上げるために 試したいことが増えました。２セッション制でしたが、どちらのセッションに行くか迷うものばかりでした。 manifestだけ入れてPWAを言い張っていた自分が恥ずかしくなりますね。
