2022年2月13日日曜日

蟹の女王

そのてっぺんに女王が眠っていた。(bruce Sterling, Cicada Queen)

ザリガニの次はカニ。
11月初旬、日差しが鋭いむしろ暑いくらいの日に、冬のアクティビティということで有名なカニ釣りスポット葛西臨海公園でカニを釣ってきました。まさかこの歳になって海に糸垂らしてカニを釣ることになるとは思っていなかったけど、ザリガニよりカニの方が大人っぽい。


こういう岩と岩の隙間にサキイカくっつけた糸を垂らしてカニを引っ掛けます。


アホほど釣れます。ザリガニが不調だったのでカニはどうかなーと思っていたら全然心配いらなかった。



ご満悦




たくさん釣れました。

前日に一生懸命食べられるカニと食べられないカニの種類を調べたんですけど、どう頑張っても素人には無理です。食中毒起こしても嫌なので放流。味噌汁とか美味しそうなんですけどね。

アクティビティとしてはとてもおすすめです。冬でもよく晴れていたのが良かったのかもしれないですね。

2022年2月6日日曜日

郡ダム

行き先に困ったらダム。
静か。広い。人がいない。なにもない。いいところです。



ただしトイレが見当たらないので行く前はどこかに寄っていくべきです。どこまで我慢できるか、帰りの距離を測りながらの散歩はなかなか大変でした。

富津みなと公園

富津がいいところなのでついアクアラインを渡りがち。

公園に行くと記録のために看板を撮るのですが、それっぽいものがなかった。





 

三番瀬沿い緑道 日の出海岸デッキ

どこからどこまでが公園で墓地で海なのかわからないくらい広い。とにかく広い。近くのねずみランドよりきっと広い。






ふなばし三番瀬海浜公園

展示が有料のせいかそもそも人気がないのか人がぜんぜんいませんでした。駐車場も千葉なのに有料なんて・・・!(千葉への土地の過度な期待)

干潟がずっと続く。海辺の公園でこういうのは珍しい。

広くて静か。

工事中で立ち入り禁止でした。登りたかった。

 

養老渓谷

千葉は養老渓谷。駐車場がとても混んでいました。見どころが多くて踏破しようとしたら一日かかるぽいです。紅葉と滝のいいとこ取りしてきました。帰りに余りの空腹に売店のコロッケ食べましたね。食べたものだけ妙に覚えている。







 

2021年10月2日土曜日

phpcon2021 day1,day2

コロナ禍の中今年もオンラインで実施されたphpcon2021。
ナマクラPGが自分がエンジニアだということを忘れないようにするためだけの年1回のイベント。オンライン開催でいいのは合間に家事が出来ることだと思う。会場で交流するような性格でもないので、知識のアップデートだけならオンライン開催は便利だと思います。
discord(チャットやチャンネルなどのコミュニケーションアプリ)をはじめて使いました。ボイスチャットとかできるみたいですが、slackみたいなものですね。
いくつかのセッションを拝見しましたが、備忘録も兼ねて少しだけメモ。やっぱり自分の立ち位置上、業務改善だとかバージョンアップ対応だとかに興味が行きがちなんですけどね。
今回は「20年モノの巨大Webサービスの開発継続戦略」が一番刺さりました。3年前から今に続いた失策を叱責されているようでした。よし、タイムマシンだ

●レガシーシステムにおけるPHP8バージョンアップのアプリ対応記録
<大事なこと>
・全量把握し、対策を練る
・品質担保に対し、費用対効果を考慮したテスト設計をする
<影響の多かった変更点>
・緩やかな比較演算子の挙動変更
 文字列が数値形式でない場合数値が文字列に変換され比較結果が反転する
 0 == "" で比較している場合、7だとTRUE 8だとFALSE
  他、演算子や配列関数、ソート関数など
・警告レベルの変更
<対応案>
・以前と同様の挙動をする関数(ラップ関数)を作成しすべての箇所を置き換える→新たなコード負債
・すべての箇所を複数パターンでテストし問題の箇所を修正→膨大な時間がかかる
<選択した対応策>
・演算子に対する対策:修正対象を絞る、チェック関数で調査
・警告レベル:通過テストで確認
 挙動は自動テスト・手動テストで確認
<今後について>
・自動テスト追加(デメリットはコスト面)
・静的な型を意識した実装を行う
・こまめなリファクタリングは重要

●20年モノの巨大Webサービスの開発継続戦略 - ミドルウェアのバージョンアップとの向き合い方
<どうしてMWバージョンアップをするか?>
・サービスが売れるかどうかは企業の生存に直結する
・サービスは売れ続ける必要がある
<サービスの価値とは>
・お金を稼ぐ力
・ユーザにとって価値があること
<2つの開発と価値>
・価値を増やすための開発
 →サービスを増やす
・価値を落とさないための開発
 →脆弱性対応、バージョンアップやリファクタリング
<こんな経験ない?>
価値を落とさないための中身を整理するための改善の開発をやろうとすると
組織から
・コストを回収できない
・コスト外のメリットの可視化が難しい
・過去十数年分の技術的負債、何年も過ぎる納期、増加する不具合、開発組織以外からはつらさが見えにくい
・開発組織への信用の低下(により認めてもらえない)
・顧客から怒られるのは営業や販売、
 →コード上の改善は新規の価値を生み出していない、機会損失ととらえられてしまう
・ポジショントークにとらえられる
<中身の改善のハードルが高い!>
・組織は価値の向上を優先したい、改善のメリットを評価できない
・組織全体の問題。システムの疲弊のリスクが安く見積もられている。こまめに改善する組織はこうなりにくい
<例外はMWバージョンアップ>
・やらないと明確に価値が下がる
 EOL対応はしないと損失になる。脆弱性、売れなくなる、やらないことの損失がわかっているためそれを回避する
・改善は差し迫った損失を避けるモチベーションで承認され、開発者たちはこれが改善のチャンスと誤解してしまう
<MWのバージョンアップがつらい理由>
・影響も規模も大きすぎて途方に暮れる
・問題が大きいのに期間が短い
・過去の作業の経験がない
・つらいPJになりそう
・求められているのはMWバージョンアップ、改善ではない、コストはかけられない
 問題が山積みのソースコードを直せるのに・・・
 →という認識のギャップに気づく
<大事なことは生き残ること>
・今もそのレガシーシステムは価値を生み出している、今ある問題はこれまで解決できていなかったもの。同時に対応するには荷が重い
・とりあえず生き残ることが大事。MWバージョンアップの際は、それ以外を目的とせず、システムが生き延びることを考える。次のバージョンアップまでの時間が手に入る
<MWバージョンアップの際に心がけること>
・バージョンアップ作業は最速で、修正は最小化で、開発案件をバグの洗い出しに活用、修正作業はバージョンアップ案件対応
・修正は最小化する、バージョンアップ以外の修正に囚われたらいけない
・問題はなるべく分割すること

●新規プロジェクトの開発スタート前にやっておくべき環境整備たち

「俺の考えた最強」を目指すことは間違いじゃないが、最初からそれだけに集中したりリーダーだけが突っ走るのは間違い
<やるべきこと>
・ユーザに価値を届けることが最も本質的で重要
・よい技術選定、設計、実装は本質ではないが楽しみを見出す
・開発しやすい環境を整備する
・上の2つに集中しがち、最初のうちに環境整備をするのは肝心
・コードとコミュニケーションの環境整備を行う
<コミュニケーションの環境整備>
README
・ドキュメントのルートとしてREADMEを充実させること
 リポジトリの概要、位置づけ、環境構築の仕方、QAの補足説明など
 リポジトリに置くことで迷子にならない、新規メンバーが入りやすい、レビューできる。
 社内サーバなどに置いてしまうとだんだん迷子になってしまう。ポイントは詳細を書きすぎないこと
Github Discuttions
・QAサイトのようなもの
・TODOリストやPRのレビューコメント
・なぜ?tips、方針、議論などがいろいろなところに散らばってしまうのを集約化する
GitHubテンプレート
・PullRequest, issueのテンプレートなど
サンプルコード
・「俺の考えた最強」を一気通貫のサンプルコードとして用意
 ディレクトリ構成、変数、など・・・
・真似するだけで基本方針は最低限担保される

これらについて、チームの環境や技術力に合わせて環境を取捨選択すること

PHPで書いて覚える非同期処理
<JavascriptとPHP>
・JavaScriptは非同期処理、PHPは同期処理と言われるが向き不向きではなくその目的の違いにより最適化されているだけ
・とはいえPHPの非同期処理はあまり必要とされない
<PHPの非同期処理の成功例>
・Guzzle Promiseを使った非同期処理によるAPIコールの高速化
・PHPにおけるI/O多重化
・同時に実行しても問題ないIO処理を束ねる
・それでもあまり多くはなくPHP単体だと非同期処理の出番はない
 →なぜ非同期フレームワークが必要なのか?
<PHPで非同期実装の感覚を養う>
・システムコールと組み合わせて非同期処理を使う(Socket通信 など)
・IOモデルを理解するためにEchoサーバーをかいてみるといいかも
・写経をおすすめ
・ブロッキングIO、ノンブロッキングIO、IO多重化
 非同期処理はシステムコールやIOと一緒に学ぶと理解が深まります
・Generator:PHPのコルーチンを使ってみる→チャットがつくれるらしい(PHP7系なら動く)

ステップ実行だけじゃないXdebug
<Xdebugの機能について>
・ステップ実行やコードカバレッジだけではない

<Xdebugの導入>
・PHPの拡張
・Xdebug3の設定はxdebug.modeに有効な項目を列挙する
・xdebug_info()を使うと現在のmodeや設定がわかる

<開発ヘルパ>
・var_dump()やエラー、例外情報の表示強化
 HTMLタグ付与、出力情報の追加
・CLIでも表示を見やすく
・xdebug_time_index()
 処理開始からコールされるまでの経過時間を取得する
・xdebug_get_monitored_functions()
 指定された関数の利用状況を取得する
 どこで呼ばれているのか?を知りたいときに

<ファンクショントレーシング>
・関数のトレース情報を分析する
・xdebug_start_trace, xdebug_stop_traceを使用
 実行されたタイミングとメモリ使用量

<プロファイリング>
・実行状況のプロファイリングを行う
・xdebug.start_with_request
・Phpstorm
 path mapping設定によりプロファイルからコードのジャンプが可能

<コードカバレッジ>
・Code Coverage Analysis
・xdebug_start_code_coverage()
・PHPUnitにて利用が多い

<ガベージコレクション分析>
・ガベージコレクションの実施状況の分析
・xdebug.start_with_request

<ステップ実行>
・ステップ実行
・xdebug.start_with_request, xdebug_break()

SPAセキュリティ入門
<SPAとは?>
・SinglePageApplicationのこと
・従来のウェブはMPA(Malti-Page Application)
・MPAはjsで代入した値は次でリセットされる
・SPAはページ遷移をしないのでjsの変数は保持される、ただしページ遷移などではリセットされる→セッション管理あるいはlocalStrageにより認証状態などのデータを引き継ぐ

<SPAとCORS>
・フレームワーク任せのCORS(オリジン間リソース共有)対応は落とし穴がある
・現在のブラウザは邪悪なコンテンツによるjs実行→cookieつきのリクエストを送信してしまう、ただしCORSヘッダーがないと値を返さない水際の対策ができる
・Cookieを伴うXHRは厳しい
・現在のフレームワークはどうなっているか?pythonのFlask, jsのExpressなどは不十分
・Laravelはどう?初期状態では送信されないがcookieを使うためにオンにするとやばい
・cookieよりヘッダーで対応する方が安全

<Firebase REST APIで学ぶJWT (じょっと)>
・Firebaseとはgoogleが提供するサーバーレスプラットフォーム
・自前のサーバを用意することなく従量課金で利用可能
・認証、DB(非SQL)、ホスティングなど
・Firebase Authenticationについて
・JWTの構造:ヘッダー、ペイロード、署名
・JWTとは認証トークンの標準フォーマットのひとつで、base64エンコード
 認証連携をする際に認証情報の持ち運びに利用される
・トークンに署名つけないなんてありえない
 →そんなことない
 セブンペイの不正利用を受けて外部IDからアプリログインを一時停止した措置について、脆弱性のひとつに認証連携の機能の不備があった
 オムニセブンについては署名がない独自のやり方だったためIDの不正書き換えができてしまった
・JWTはサーバ問い合わせなくログイン状態を持ち運びできる
 サーバー側でセッションを破棄できないので有効期限、リフレッシュなどで対応
・FirebaseのJWTのデフォルトの有効期限は1時間
・有効期限が切れた状態でアクセスすると401エラー

<SPAとXSS>
・ウェブAPIの静寂性はContent-type:Application/jsonにしておけば基本的に問題ない
・JavaScriptのXSSは気をつけることが多い
・evalインジェクション
<SPAとCSRF>
・ヘッダにトークンを入れておけば脆弱性は混入しない
 Cookieでセッション管理している場合に注意
・フレームワークの機能で対策しよう
<CookieとlocalStrageはどちらがよいか>
・一長一短
・WebサーバとAPIサーバが一体の場合は古典的なセッションを使うのが比較的無難である
・クロスドメインでCookieは使わないほうが良い