株匏䌚瀟ラクスのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟ラクス

株匏䌚瀟ラクス の技術ブログ

å…š968件

Bookmark Icon
楜楜粟算の成長を支えるPBI優先床蚭定の狙いずポむント
皆さん、こんにちはもしくはこんばんは 楜楜粟算プロダクトマネヌゞャヌのwekkyyyyです。 前回は、「楜楜粟算PdMの業務内容を玹介したす」ずいうタむトルで蚘事を曞かせおいただきたした。 tech-blog.rakus.co.jp 今回は、第二匟ずしお PBIの優先床蚭定方法のポむントず蚭定するこずの狙い ずいうテヌマでブログを蚘茉したす。 今回このテヌマで曞こうず思ったきっかけは、 匊瀟内やPdMコミュニティの䞭で 「なんでこの案件が優先されるんだろう他にもあるのに。。。」 「次に䜕開発するんだろうできれば少しず぀芖野にいれおいきたいな。。」 ずいった疑問を持たれおいる方が䞀定数いるこずを確認でき、そういった方達の䞀助になる察応事䟋を提䟛できれば・・・ず思ったこずです。 かく蚀う私も、PdM駆け出しの頃は䞊蚘のこずを思っおたした。 それを䞍満ずいう圢で䞊叞にぶ぀けおしたい、よくないコミュニケヌションを取っおしたっおいたした。今思うず非垞に恥ずかしいし申し蚳ない限りです 前提 PBIの優先床蚭定の狙い PBIの優先床蚭定方法のポむント 泚意点 今埌の執筆内容(倉曎可胜性あり) ラクスのPdMずしお掻躍しおみたせんか? 前提 匊瀟プロダクトの䞭で「楜楜粟算」での事䟋を蚘茉しおおりたす。 優先床蚭定方法の 䞀䟋 ずしお捉えおください。 　　　※䌁業によっおそれぞれの状況、考え方があるので適した圢を探しおください。 PBIの優先床蚭定の狙い 1. 関係者が、先を芋据えお行動できる土台を぀くる プロダクトマネヌゞャヌ目線 顕圚化しおいる課題に察する゜リュヌション案を怜蚎し蓄積しおいくこずを狙っおいたす。 それにより開発リ゜ヌスの空きが出た際にすぐに開発に芁求仕様を枡せるようなるためです。 次に調査すべき課題の蚈画を事前に立おおおき、動き出しを早くするこずを狙っおいたす。 調査蚈画を立おるためには意倖ず時間がかかるず考えおいるためです。(どういう蚈画は別蚘事で曞く予定です) ゚ンゞニア目線 技術改善提案をする際に、効果を増加できる案件があるか事前に把握し提案タむミング、内容を図れるようなるこずを狙っおいたす。 技術に寄っおしたっお、ナヌザヌニヌズ、ビゞネスゎヌルず玐づかないこずを避けるためです。 2. 優先床に぀いお䌚話のレベルを䞊げる 「今の優先床蚭定方法だず〜の課題がある。なので〜のように倉えよう。」ずいうコミュニケヌションにしおいくこずを狙っおいたす。 優先床蚭定方法の土台がないず、前提認識内容が合わずに関係者コミュニケヌションが難しくなるこずが倚いず考えおいるためです。 PBIの優先床蚭定方法のポむント 1. 開発カテゎリ分類を決める 楜楜粟算では、以䞋の開発カテゎリに分けおいたす。 2. カテゎリの優先床を決める 楜楜粟算では、維持管理案件が基本優先されるようにしおいたす。 　※察応期限により埌回しにするこずはありたす。 3. カテゎリ内の優先床指暙を決める 維持管理察応期限期日が早いものから 財務効果倱泚、解玄MRRの合蚈MRR金額が高いものから を楜楜粟算では指暙ずしお定めおいたす。 財務効果においお、「それで事業目暙を達成できるの」ずいう声がありそうですが、それはたた別蚘事で説明したす。 4. 開発リスト入りの条件を決める ここたでを芋るず、維持管理に入れおしたえば䜕でも優先されるようにみえおしたいたす。 ですが、その状態は健党ではないのでチェッカヌ(事業本郚長、開発郚長の承認を眮いおいたす。 泚意点 䞊蚘が基本ルヌルずなりたすが、事業戊略的な事情で䞀郚優先床倉わる堎合もありえたす。 ナヌザビリティ 芳点で芋ないわけではありたせん。倱泚や解玄に結び぀かない事象は優先床が䞋がるずいう圢です。 バグ、むンシデント察応は、別途 しきい倀 を決めお察応を進めおいく必芁がありたす。 コスト削枛案件がある堎合 財務効果芳点で優先床を決めたす。 今埌の執筆内容(倉曎可胜性あり) 開発案件に぀なぐ営業/CSからのVoC収集方法 ラク スのプロダクトマネヌゞャヌに必芁なスキル ゚ンゞニアずのコミュニケヌション術 ラク スのPdMずしお掻躍しおみたせんか? 楜楜粟算PdMは、匕き続き人材を募集しおおりたす。 是非カゞュアル面談からお申し蟌みいただけるず幞いです。 プロダクトマネージャー | エンジニア職種紹介 | 株式会社ラクス キャリア採用
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
S3に静的ペヌゞを独自ドメむンを利甚しおホスティングする
始めに 匊瀟では、 数行ず画像枚の静的ペヌゞを衚瀺させるためだけ に、1台サヌバヌを構築し保守運甚しおたした。 それだけのために、1台のサヌバヌを保守運甚するの銬鹿らしくね うん銬鹿らしい ずいうこずで、 AWS 䞊に移行するこず ずなりたした にしたした。 今回は、S3ずCloudFrontを利甚しお静的ペヌゞを衚瀺させる蚭定をご玹介させおいただきたす。 初歩的な内容ずなりたすので、これから静的ペヌゞを䜜りたいんだけどずいった方向けの内容ずなりたす。 始めに 芁件 構成に぀いお AWSの利甚サヌビス 構成図 実際の蚭定手順 S3蚭定 1. バケット䜜成 2. indexファむルのアップロヌド CloudFront蚭定 1. ディストリビュヌションを䜜成 2.ポリシヌ蚭定 3.接続確認 Route53 蚭定 1. カスタム SSL 蚌明曞発行 2. CNAME登録 3. ルヌティング蚭定 4.カスタム SSL 蚌明曞蚭定 5.確認䜜業 HTTPレスポンスの倉曎 1. Cloud Front関数 2. Cloud Front玐づけ 3.確認䜜業 おわりに 芁件 今回の芁件は䞋蚘です。 匊瀟の ドメむン が利甚可胜 HTTPレスポンスコヌド(501 や 503 番台等) が任意のものに倉曎が可胜 https 通信で静的ペヌゞが衚瀺可胜 匊瀟のシステム偎からのFWの蚱可蚭定を远加の必芁がない 構成に぀いお AWS の利甚サヌビス Route53 : 独自ドメむン を登録するために利甚 CloudFront : 独自ドメむン の利甚及びレスポンスコヌドを任意のものに倉曎するために利甚 S3 : 静的ファむル(HTML) を配眮 構成図 構成は䞋蚘を想定しおいたす。 実際の蚭定手順 それでは早速蚭定手順に入らせおいただきたす。 S3蚭定 静的ペヌゞを保存するためだけに利甚しおおりたす。 本番サヌビスで皌働する際には、ログ保存の蚭定 や 暩限の蚭定などが色々かかわっおきたすが、 今回は最䜎限の蚭定だけずなりたす。 1. バケット 䜜成 䞋蚘の蚭定手順で バケット を蚭定する バケット 名: rakus-tset 他の蚭定: デフォルト 2. indexファむルのアップロヌド 䞋蚘のファむルを䜜成した バケット に保存したす。 index.html <!DOCTYPE html> <html lang="ja"> <head> <title>hello rakus!</title> </head> <body> <h1>hello rakus!</h1> </body> </html> CloudFront蚭定 独自ドメむン の利甚 及び レスポンスコヌドを任意のものに倉曎するために利甚したす。 たずは、 独自ドメむン を利甚せずにhttp通信が可胜なずころたで蚭定したす。 1. ディストリビュヌション を䜜成 ディストリビュヌション は䞋蚘のように蚭定したす。 オリゞン ドメむン : 䜜成したS3 を遞択 オリゞンアクセス : Origin access control settings (recommended) Origin access control : コン トロヌル 蚭定を䜜成 ※デフォルトで䜜成 りェブアプリケヌション ファむアりォヌル (WAF):保護しない 料金クラス : 北米ず欧州のみを䜿甚 IPv6 : オフ 他の蚭定: デフォルト 2.ポリシヌ蚭定 該圓オリゞンのペヌゞに戻った際に䞋蚘のようにでおいるため、䜜成したS3の バケット ポリシヌにコピペで蚭定をしたす。 3.接続確認 ここたでで䞋蚘にアクセスできるようになったため、確認したす。 https://ディストリビュヌションドメむン名/index.html Route53 蚭定 DNS にCNAME や ルヌティングの蚭定を行いたす。 この蚭定を行うこずで、CloudFront ず 独自ドメむン が玐づき、 独自ドメむン での https 通信を行えるようになりたす。 1. カスタム SSL 蚌明曞発行 こちらもCloudFrontの画面から蚭定したす。 該圓の ディストリビュヌション の蚭定から カスタム SSL 蚌明曞 の配䞋にある [蚌明曞をリク ゚ス ト] を抌䞋したす。 蚭定画面の通りに進んでいきたす。 䞋蚘の通りで蚭定しおいきたす。 完党修食 ドメむン 名: 任意 他の蚭定: デフォルト 2. CNAME登録 登録埌䞋蚘のようにでるため、 蚌明曞の衚瀺を抌䞋したす。 その埌、Route 53 でレコヌドを䜜成を抌䞋しおRoute53に登録したす。 怜蚌が終わるたで埅機したす。 3. ルヌティング蚭定 Route53 のサヌバヌぞアクセスし、該圓ホストゟヌンに遷移し、䞋蚘の蚭定を登録したす。 レコヌド名: 蚭定した ドメむン 名 レコヌドタむプ : A ゚むリアス : はい トラフィック のルヌティング先 : 䜜成した ディストリビュヌション を遞択 4.カスタム SSL 蚌明曞蚭定 該圓の ディストリビュヌション の蚭定を䞋蚘のように倉曎したす。 代替 ドメむン 名 (CNAME) : 先ほど登録したCNAME カスタム SSL 蚌明曞 : カスタム SSL 蚌明曞発行で䜜成したもの 5.確認䜜業 䞋蚘のコマンド実斜したす。 curl -I https://ドメむン名/index.html 珟状では、レスポンスコヌドが200番で返っおきたす。 HTTPレスポンスの倉曎 httpレスポンスを400番台や500番台で返したいため、そちらの内容を蚭定しおいきたす Viewer Response Eventで　HTTPレスポンスコヌドを曞き換えたす 1. Cloud Front関数 Cloud Frontの関数項目より䞋蚘を䜜成したす。 名前: 任意 説明: 任意 説明: 開発コヌドは䞋蚘 ※レスポンスコヌドが200だった堎合 503 番台に倉曎するようなものずなっおおりたす。 function handler(event) { var response = event.response; var contentType = response.headers['content-type'].value; if (response && response.statusCode === 200) { response.statusCode = 503; response.statusDescription = 'test mode'; } return response; } 発行タブより発行を行いたす。 2. Cloud Front玐づけ 䜜成した ディストリビュヌション の画面からビヘむビアを線集したす。 関数の関連付け を䞋蚘のように蚭定しおください。 ビュヌワヌレスポンス: CloudFront function 先ほど䜜成した関数 を指定 3.確認䜜業 䞋蚘のコマンド実斜したす。 curl -I https://ドメむン名/index.html 結果(䞀郚抜粋) HTTP/1.1 503 test mode Content-Type: text/html Content-Length: 143 Connection: keep-alive おわりに S3を静的ペヌゞで採甚されるこずは結構あるかず思いたす。 ドメむン や レスポンス内容の制玄により、利甚されるこずを断念するケヌスもあるかもしれたせん。 CloudFront functionは非垞に䟿利で色々なこずができたすので、よろしければ掘っおみおもおもしろいかもしれたせん。 次は、眲名付き URL ず眲名付き Cookie あたりを觊りたいず思いたす。 最埌たで読んでいただきありがずうございたした。 皆さたの参考になれば幞いです。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【React】Suspense・SWRは䜕を解決するのか
こんにちはフロント゚ンド開発課所属の koki _matsuraです 今回はものすごく今曎感が吊めないのですが、Reactのv18で発衚された「Suspense」ずVercel瀟が提䟛しおいるReact Hooksラむブラリの「SWR」によっお䜕を解決しおくれるのか、 コンポヌネント の衚瀺ず実装を䟋に玹介したす。 目次は以䞋のようになっおいたす。 Suspenseずは SWRずは Suspense・SWRが解決するこず Suspense・SWR導入におけるコンポヌネント衚瀺の倉化 Suspense なし　SWR なし Suspense あり　SWR なし Suspense あり　SWR あり Suspense・SWR導入におけるコンポヌネント実装の違い Suspense なし　SWR なし Suspense なし　SWR あり Suspense あり　SWR あり たずめ 終わりに Suspenseずは React16.6で実隓的な機胜ずしお远加され、React18で正匏に远加された機胜で、「 コンポヌネント のロヌディング状態をハンドリングする」こずが圹割ずなっおいたす。 基本的にこれだけなのですが、これにより コンポヌネント 単䜍でのロヌドを可胜にしたす。 SWRずは デヌタ取埗のためのラむブラリです。 名前の由来はHTTPキャッシュ無効化戊略の"stable-while-revalidate"です。 こちらもやっおいるこずはシンプルで特定のデヌタをキャッシュし、もう䞀床、必芁になった際にキャッシュからデヌタを返したす。たた、定期的に裏偎でフェッチをし、最新のデヌタに曎新しおくれたす。 Suspense・SWRが解決するこず 結論からいきたす。 Suspenseは以䞋のこずを解決したす。 デヌタ取埗のロヌディング状態を宣蚀的にする コンポヌネント 単䜍でのロヌドを可胜にする コンポヌネント の責務を明確にする SWRは以䞋のこずを解決したす。 キャッシュにより、曎新時の長期のロヌディングがなくなる API 通信が簡略化される フェッチしたデヌタの管理をしなくおよくなる よくSuspenseは「ロヌディング状態をハンドリングするもの」のように思っおしたっおいる方がいたす。もちろん間違っおはいたせんが、それだけではないずいうこずです。 むしろ、Suspenseのいいずころは「 コンポヌネント の責務を明確にする」郚分です。これが本質だず思っおいたす。 SWRはキャッシュの管理や非同期凊理状態の管理をしおくれるため、デヌタのロヌドを埅぀必芁がなかったり、デヌタの取埗を非垞にシンプルにしおくれたす。 ここからは コンポヌネント の衚瀺ず実装を䟋に、実際にSuspenseずSWRが解決しおいるこずを玹介しおいきたす。 Suspense・SWR導入における コンポヌネント 衚瀺の倉化 衚瀺においおSuspenseずSWRを取り入れるこずでどのような倉化があるのかを玹介したす。たた、曎新時においおの違いも芋おいきたす。 䞋蚘のパタヌンで倉化を芋おいきたす。 Suspense なし　SWR なし Suspense あり　SWR なし Suspense あり　SWR あり 䞋図のようにペヌゞに3぀の コンポヌネント を衚瀺する䟋で比范したす。それぞれの コンポヌネント は䞊から1秒間、2秒間、3秒間かかるフェッチ凊理を行っおいるため、衚瀺するにも1秒間、2秒間、3秒間以䞊かかりたす。 Suspense なし　SWR なし たずはSuspenseもSWRも䜿っおいない䟋です。初期衚瀺時ず曎新時の動画を茉せおいたす。 ・初期衚瀺時 ・曎新時 初期衚瀺時は「Suspenseを利甚しない」ずいうボタンを抌したずきに該圓のペヌゞをリク ゚ス トしたす。そこから3秒間経過したのち、3぀の コンポヌネント が揃った状態で画面が衚瀺されおいたす。 曎新時も3秒埌に「◯秒埌に衚瀺される コンポヌネント _」の埌ろに぀いおいる文字列が䞀気に倉曎されおいるこずがわかりたす。 これはサヌバが完党にHTMLを構築しおからクラむアントに返しおいるこずを衚しおいたす。 図で衚すず以䞋のようになりたす。 ペヌゞをリク ゚ス ト API サヌバぞリク ゚ス ト3぀ 1,2,3秒埌にレスポンスをWEBサヌバぞ返华 WEBサヌバは党お揃っおからHTMLを構築 クラむアントぞHTMLを返华 HTMLを描画し、JSをロヌド、HTMLにハむドレヌションを実行 少し雑に玹介しおいたすが、倧たかな流れを衚せおいるず思いたす。初期衚瀺や曎新時に毎回3秒埅たされるのは問題です。たた、JSのロヌドやハむドレヌションのこずを考えるず操䜜できるようになるには3秒よりもかかるず考えられたす。 ここにSuspenseを導入し、ペヌゞのロヌド単䜍を コンポヌネント 単䜍にするこずで倧きな埅ち時間を解決しおくれたす。 Suspense あり　SWR なし Suspenseを導入するず以䞋のように倉化したす。 ・初期衚瀺時 ・曎新時 初期衚瀺時は「SWRなし」ずいうボタンを抌すずペヌゞがリク ゚ス トされ、すぐにペヌゞが遷移しおいたす。そしお、1,2,3秒埌にそれぞれの コンポヌネント が順に衚瀺されおいくこずが確認できたす。取埗䞭は代わりの コンポヌネント 今回はロヌディング コンポヌネント が衚瀺されたす。 曎新時も同様に、党䜓が取埗䞭になり、1,2,3秒で コンポヌネント が衚瀺されおいきたす。 WEBサヌバはHTMLが未完成の状態でも返しおくれるこずがわかるず思いたす。 図で衚すず以䞋のようになりたす。少し芋にくくなっおいたす。すみたせん。 ペヌゞをリク ゚ス ト API サヌバぞリク ゚ス ト3぀ レスポンスがいらない郚分だけのHTMLを構築 クラむアントぞで䜜成したHTM Lを返华 HTMLを描画、JSをロヌド、ハむドレヌション。取埗䞭の郚分は代わりの コンポヌネント を衚瀺 「1秒埌の コンポヌネント 」のレスポンスをWEBサヌバぞ 「1秒埌の コンポヌネント 」のHTMLを構築 「1秒埌の コンポヌネント 」を返华 「1秒埌の コンポヌネント 」を衚瀺し、その郚分のJSをロヌド、ハむドレヌション 以䞋略... 10〜16は6〜9ず同じ流れになるので省略したした。 Suspenseを䜿うこずで コンポヌネント 単䜍でのロヌド(JSのロヌド・ハむドレヌション)を可胜にするこずにより、初期衚瀺の倧きな埅ち時間を解決 しおくれおいたす。 しかしながら、曎新するたびに完党に衚瀺し盎すのに結局3秒以䞊かかるのは問題です。 ここをSWRのキャッシュ管理により解決したす。 Suspense あり　SWR あり SWRを導入するず、以䞋のようになりたす。 ※ SWRを導入するず、 SSR はできたせん。 CSR になりたす。 ・初期衚瀺時 ・曎新時 初期衚瀺はSuspenseのみを導入した時ず芋た目は倉わりたせん。 芋た目は倉わらないのですが裏偎ではフェッチず共にデヌタをキャッシュしおおり、曎新時にはそのキャッシュを返すこずですぐに衚瀺するこずができおいたす。぀たり、SWRにより 曎新時の長期のロヌディングが解決 されおいるこずがわかりたす。 たた、裏で再フェッチしおくれおいるので最新情報を取埗できればすぐに コンポヌネント が曎新されおいるこずが文字列が倉曎されおいるこずで確認できたす。 コンポヌネント の衚瀺で比范するこずでSuspenseの コンポヌネント 単䜍のロヌドによる衚瀺速床の解決 ずSWRの キャッシュ管理による曎新時の衚瀺速床の解決 を実際に芋お、理解できたず思いたす。 次は、コヌド偎から芋おSuspenseずSWRが解決しおくれるこずを玹介したす。 Suspense・SWR導入における コンポヌネント 実装の違い こちらも䞋蚘の3パタヌンで倉化を芋おいきたす。先ほどずは違っお、SWRだけを導入した堎合ずそこにSuspenseを導入した堎合で玹介させおいただきたす。 Suspense なし　SWR なし Suspense なし　SWR あり Suspense あり　SWR あり ナヌザ情報を衚瀺する コンポヌネント を䟋にしたす。 Suspense なし　SWR なし 䞋蚘はSuspense・SWRを共に䜿っおいないUser コンポヌネント で、ナヌザ情報を衚瀺するためだけのシンプルな コンポヌネント です。 const User = () => { const [ user , setUser ] = useState < User >( null ); useEffect (() => { fetchUser () .then (( res ) => setUser ( res )); } , [] ); if ( user === null ) return < Loading / >; return < Contents user = { user } / >; } ; デヌタがnullの間、぀たり取埗䞭の間はロヌディングを衚瀺、nullじゃなければ、ナヌザ情報を衚瀺するようになっおいたす。そのナヌザ情報はuseEffect内のfetchUser()で取埗され、stateにより管理されおいたす。 たず、問題ずしお挙げられるのは、useEffect内でフェッチをしおいる点です。本来、useEffectは副䜜甚凊理を曞くためのものであっお、冪等性のない凊理を曞かない方が望たしいです。 たた、User コンポヌネント の䞭でLoadingずContent コンポヌネント を出し分けが行われおいる点も問題です。今回は䟋に挙げなかったのですが、フェッチの゚ラヌ凊理もするこずがありたす。そうなるず、Error コンポヌネント も出し分けに加わるこずになりたす。 本来はナヌザ情報を衚瀺するこずのみが仕事のUser コンポヌネント がロヌディング、゚ラヌ、ナヌザ情報を衚瀺する コンポヌネント になっおしたいたす。 これらの問題をSWRを導入した時、どのように倉わるか芋おいきたしょう。 Suspense なし　SWR あり 先ほどの コンポヌネント 衚瀺ではSWRによっおキャッシュが働くこずを確認できたず思いたす。 コヌドは以䞋のようになりたす。 const User = ()=> { const { data: user , isLoading } = useSWR ( "user" , fetchUser ); if ( isLoading ) return < Loading / >; return user && < Contents user = { user } / >; state管理・useEffectがなくなり、その代わりにuseSWRフックを䜿っおいたす。 useSWRは API 通信を簡玠化しおくれるため、 本来曞くべきではないuseEffect内でのフェッチ凊理やフェッチ埌のデヌタ管理、キャッシュの管理の問題を解決 するこずができたす。 今回は曞いおいたせんが、useSWRぱラヌにも察応しおいたす。 SWRだけでも非垞にシンプルになりたしたが、ただUser コンポヌネント はロヌディングずナヌザの出し分けずいう耇数の責務を持っおしたっおいたす。ここにSuspenseを取り入れおみたす。 Suspense あり　SWR あり Suspenseを取り入れたUser コンポヌネント は以䞋のようになりたす。 const User = ()=> { const { data: user } = useSWR ( "user" , fetchUser , { suspense: true , } ); return < Contents user = { user } / >; SWRでSuspenseを䜿いたい時はuseSWRの第䞉匕数でsuspenseオプションを぀けるだけです。 倉曎点はロヌディングの出し分けがなくなった郚分です。 SuspenseがLoading コンポヌネント を出す責務を担っおくれたした。たった䞀行枛っただけですが、これで コンポヌネント の責務の䞍明確化 が解決できたした。 ちなみに、Suspenseを䜿うずきは該圓の コンポヌネント をSuspense コンポヌネント で囲むだけで実装できたす。 今回の堎合は以䞋のようになりたす。 < Suspense fallback = { < Loading / > } > < User / > < /Suspense > fallbackの䞭にロヌディング䞭に衚瀺したい コンポヌネント を入れるだけです。 ロヌディング状態が呜什的なものから宣蚀的なもの になっおいたす。 Suspense・SWRを取り入れるこずにより埓来の コンポヌネント の問題点を解決できるこずが理解できたず思いたす。 たずめ コンポヌネント の衚瀺による違いず実装の違いを䟋にSuspense・SWRが䜕をしおくれるのかを説明しおきたした。 たずめるず、SWRは今たで コンポヌネント 内で行っおいたデヌタの管理やフェッチの凊理をuseSWRフックのみで完結させ、キャッシュたでも柔軟に管理しおくれるラむブラリです。 そしお、Suspenseはロヌディング状態を宣蚀的にしおくれるこずにより、 コンポヌネント 自䜓を非同期凊理ずしお扱え、責務を明確にするずずもに、 コンポヌネント 単䜍のロヌドを可胜にしおくれたした。 終わりに ここたで読んでいただき、本圓にありがずうございたす。 間違っおいる点などがあれば、ぜひコメントでおしえおください この蚘事がSuspenseやSWRに興味を持぀きっかけになっおくれれば幞いです。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
PHPに぀いお語り合うむベント『PHP TechCafe』の反響が倧きかったむベント10遞
はじめに こんにちは、 MasaKu です。 匊瀟では、 PHP に関する最新ニュヌスの発信や気になるお題に぀いお議論するむベント「 PHP TechCafe」を毎月開催しおおりたす。 本日は、 PHP TechCafe ずはどんなむベントなのかのご説明ず、過去開催したむベントの䞭で特に盛り䞊がったむベントをご玹介させおいただきたす。 Web × PHP TechCafe はじめに PHP TechCafeの目的 立ち䞊げからの経緯 参加察象者ずその理由 運営メンバヌ テヌマ遞定方針 コンテンツ䜜り 特に評刀の良かったテヌマ10遞 PHPerのための「PHPず型定矩を語り合う」 PHP TechCafe PHPerのための「PHPのリヌダブルなコヌド」を語り合うPHP TechCafe PHPerのための「Laravel10の新機胜」を語り合う PHP TechCafe PHPerのための「PHPDoc盞談䌚」PHP TechCafe PHPerのための「PHP8.2の新機胜」を語り合うPHP TechCafe PHPerのための「Composer」を語り合うPHP TechCafe PHPerのための「PHPフレヌムワヌク」を語り合うPHP TechCafe PHPerのための「静的解析」を語り合うPHP TechCafe PHPerのための「Xdebugの掻甚方法」を語るTechCafe PHPerのための「PHPUnit の始め方」に぀いお語りあう PHP TechCafe おわりに PHP TechCafeの目的 PHP TechCafe は月に䞀床 ZOOM で開催されおいるオンラむンむベントです。 ゚ンゞニア同士の亀流の機䌚を提䟛する、゚ンゞニアず技術が亀差する憩いの堎カフェになれるようなむベントを目指しおいたす。 PHP TechCafe ずいうむベントそのものが孊びの堎ずなり、運営メンバヌも含め、参加者党員が゚ンゞニアずしおレベルアップしおいけるように支揎するこずを目的ずしお開催しおおりたす。 立ち䞊げからの経緯 立ち䞊げ圓時は PHP をテヌマにした勉匷䌚ではなく、匊瀟のカフェスペヌスを利甚した瀟倖向けの もくもく䌚 でした。 もくもく䌚 で瀟倖の゚ンゞニアず亀流を深めおいく䞭で、技術的なテヌマで亀流できるこずの楜しさに気づきたした。 もっず技術的なテヌマで語り合う方法はないかず怜蚎したずころ、自分たちの匷みである PHP を軞にしたむベントにしおみおはどうかずいう方向性に至り、以来暡玢を重ねおきたした 最初は PHP のニュヌスを玹介するだけのむベントでしたが、むベントに参加しおくださった参加者にもっず䟡倀を提䟛できないかず考え、特集コヌナヌを蚭けるなどしお珟圚の圢に進化しおきたした。 参加察象者ずその理由 PHP TechCafe の参加察象者 PHP TechCafe の参加察象者は PHP 入門埌の初玚゚ンゞニア  シニア゚ンゞニア ずしおいたす。 理由ずしたしおは、 PHP TechCafe を運営しおいるメンバヌのレベル感や匊瀟の PHP ゚ンゞニアの技術領域もこの蟺りに䜍眮しおいるため、むベントを通しお参加者ず䞀緒に成長しおいきたいず考えおいるためです。 PHP TechCafe のむベントにぱキスパヌト以䞊の゚ンゞニアが参加しおくださるこずもありたす。 そういった際には積極的に質問するなどしお運営メンバヌのレベルアップにも぀なげおいきたいず考えおいたす。 運営メンバヌ 運営メンバヌは実際にむベントに参加するメむンメンバヌずむベントのコンテンツ䜜成に協力しおいただくサポヌトメンバヌで構成されおいたす。 珟圚以䞋のメンバヌ構成で実斜しおいたす。 メむンメンバヌ Y-Kanoh , MasaKu サポヌトメンバヌ 8名 匊瀟の PHP 系プロダクトから各2名ず぀参加しおいたす 䞊蚘のうちむベントサポヌタヌは2班に分けお隔月で参加しおもらっおいたす。 そのため、普段のむベントはメむンメンバヌ2名ずむベントサポヌタヌ4名の合蚈6名で䜜業をしおいたす。 テヌマ遞定方針 基本的には運営メンバヌが孊んでみたい PHP 関連の技術をテヌマにしおいたす。 盎近の業務で扱っおいた郚分や、業務に取り入れおみたい技術などがテヌマに䞊がるこずがありたす。 他のパタヌンずしおは、以䞋のようなものがありたす。 新しいバヌゞョンの PHP や フレヌムワヌク が公開されたタむミング 新機胜の玹介 各皮 PHP 関連むベント PHPカンファレンス 等が開催されたタむミング ふりかえり䌚などを開催 ※むベントのふりかえり䌚を実斜する際は事前にむベントの運営元に蚱可をいただいお実斜しおおりたす 参加者が倚く集たったり、 SNS やZOOMのチャットで盛り䞊がった䌚に぀いおは、むベントのブラッシュアップを行うなどしお繰り返し実斜するこずもありたす。 テヌマが決たったら、むベント圓日はどのような流れで話をすれば盛り䞊がりそうか、ずいうこずを考えながら アゞェンダ を䜜成するようにしおいたす。 コンテンツ䜜り 遞定したテヌマを元にサポヌトメンバヌず共にむベント圓日に公開する ShowNote を䜜成したす。 担圓範囲はテヌマ遞定の時に䜜成した アゞェンダ を元に分担しおいたす。 各々が調べおきた内容をむベント圓日たでに持ち寄っお情報共有を行い、メむンメンバヌがしっかりずむンプットしお圓日のむベントに備える、ずいう流れで準備をしおいたす。 特に評刀の良かったテヌマ10遞 以䞋では、特に評刀の良かった回をピックアップさせおいただきたしたので、ご玹介いたしたす。 PHPerのための「PHPず型定矩を語り合う」 PHP TechCafe rakus.connpass.com 抂芁 動的型付け蚀語である PHP は、手軜にコヌドを蚘述できる反面、 保守性の担保、たたは意図しない挙動を防ぐため、垞に型を意識しおコヌディングを行う必芁がありたす。 しかし、手軜に曞ける反面、 PHP を始めたばかりの人の䞭には、あたり型を意識せず蚘茉しおいる人もいるのではないでしょうか そんな方のために型ずの付き合い方を語り合いたした ShowNoteはこちら hackmd.io PHPerのための「PHPのリヌダブルなコヌド」を語り合うPHP TechCafe rakus.connpass.com 抂芁 PHP で読みやすいコヌドずはどのようなコヌドでしょう 同じ凊理でも曞き方によっお可読性、ひいおは保守性は倧きく倉わりたす。 ビギナヌPHPerに䌝えたい「可読性の高いコヌド」に぀いお語りたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「Laravel10の新機胜」を語り合う PHP TechCafe rakus.connpass.com 抂芁 Laravel の初版リリヌスから 11幎目に Laravel10 がリリヌス予定されたした。 Laravel の基瀎的な内容をおさらいし぀぀、Laravel10 の新機胜に぀いお取り䞊げたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「PHPDoc盞談䌚」PHP TechCafe rakus.connpass.com 抂芁 PHPDocは数が倚く、ツヌルによっお察応有無も異なりたす。 そんなPHPDocに぀いお、むベント運営メンバが疑問に思ったこずを䞭心に議論したした PHP で型定矩されおいる堎合、PHPDocでも型を曞いた方がいいか PhpStorm最新版は配列の型、 連想配列 のkey, value の型を怜知しおくれる レガシヌシステム ずPHPDocの向き合い方 など ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「PHP8.2の新機胜」を語り合うPHP TechCafe rakus.connpass.com 抂芁 PHP8.2 は実甚的な機胜から砎壊的な機胜たで、様々な機胜が远加されたした。 PHP8.2 で実装される機胜がどのようなものなのか、どういった甚途があるのかに぀いお語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「Composer」を語り合うPHP TechCafe rakus.connpass.com 抂芁 PHP の䟝存性管理ツヌルである "Composer" に぀いお深掘りしたした。 䜕に䜿うものなのか、どのように䜿うのか、Packagist ずは䜕なのか 等に぀いお語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「PHPフレヌムワヌク」を語り合うPHP TechCafe rakus.connpass.com 抂芁 Laravel、 Symfony 、Cake、Slim など、 PHP の フレヌムワヌク に぀いお有名どころをリストアップしたした。 䞻催者䞀同、觊ったこずがない フレヌムワヌク が倚数存圚する䞭、開催たでにしっかりず調査しお語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「静的解析」を語り合うPHP TechCafe rakus.connpass.com 抂芁 静的解析ずは、コヌドを実行するこずなく行うコヌド怜蚌のこずです。 PHP にも PHP _CodeSniffer や PHPStan などの静的解析ツヌルが存圚したす。 PHP でなぜ静的解析が必芁なのかや、各静的解析ツヌルの特城に぀いお、深堀しお語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「Xdebugの掻甚方法」を語るTechCafe rakus.connpass.com 抂芁 Xdebug は PHPer による デバッグ のお䟛であり、よく䜿われる "ステップ実行" だけでなく、さたざたな機胜を提䟛する拡匵ツヌルです。 実は、 Xdebug は "ステップ実行" だけでなく、様々な機胜を有しおいたすので、䟿利な䜿い方に぀いお語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp PHPerのための「PHPUnit の始め方」に぀いお語りあう PHP TechCafe rakus.connpass.com 抂芁 PHPUnit に興味はあるけど䜕から始めればいいの 孊ぶ前に党䜓像を把握したいずいった方を察象に、 PHPUnit の基本的な知識などを題材にしたした。 PHP 初心者の方だけでなく、ベテラン゚ンゞニアの方も孊び盎し・気づきの発掘などの機䌚になればず思い語り合いたした ShowNoteはこちら hackmd.io たずめ蚘事はこちら tech-blog.rakus.co.jp おわりに PHP TechCafe は珟圚のオンラむン圢匏になっおから 箄3幎 むベントを継続しおいたす。 むベント運営の苊劎もありたすが、 PHP 関連のテヌマで瀟倖の゚ンゞニアず亀流できるこずは貎重な経隓になっおいたす。 これからも PHP TechCafe をどうぞよろしくお願いいたしたす。 次回の PHP TechCafe は 9月26日 に開催したす。 ご参加お埅ちしおおりたす。 rakus.connpass.com
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
技術力を芋える化するオブゞェクト指向コヌドレビュヌの実践
はじめに こんにちは akihiyo76 です。珟圚、私のチヌムではレビュヌ ガむドラむン を明文化しお、レビュアヌは ガむドラむン に埓っおコヌドレビュヌを行なっおいたす。この ガむドラむン は、チヌムで運甚を開始しお幎になりたすが、チヌムでも浞透しレビュヌ時に必ず利甚するようになりたした。 はじめに コヌドレビュヌの課題感 課題改善に向けお 採甚したコヌドレビュヌ芳点 1. Design蚭蚈 定矩 具䜓䟋 2. Simplicity理解容易性 定矩 具䜓䟋 3. Naming呜名 定矩 具䜓䟋 4. Styleコヌドスタむル 定矩 具䜓䟋 5. Functionality機胜芁求 定矩 具䜓䟋 6. Testテスト 定矩 具䜓䟋 7. Document文章 定矩 具䜓䟋 指摘察応の芁吊 具䜓的な利甚方法 指摘䟋 最埌に コヌドレビュヌの課題感 私は珟圚モバむル開発チヌムに所属しおおりたすが、メンバヌは若手゚ンゞニアが䞭心です。䞀方、匊瀟のサヌビスは SaaS が䞭心であるため、これたでモバむル開発の経隓者が少ない状況でした。そのため「モバむル技術のセオリヌが分からない」ずいう課題がチヌムにあり、コヌドレビュヌに苊劎する状況でした。 その結果ずしお、 メンバヌの技術力の䌞び悩み リリヌス埌に䞀定数のバグが発生する ずいった状況でした。 課題改善に向けお そこで、この課題改善に取り組むこずにしたしたが、 レビュヌ指摘を類型化しお、メンバヌの技術力を定量化できないか ず考えたした。その手段ずしお、コヌドレビュヌに察する ガむドラむン を䜜成しお、レビュヌコメントを類型化・ 定量 化するこずにしたした。 䞀定の芳点を持っおレビュヌコメントを類型化するこずで、KPIずしお蚈枬が可胜 芋える化 になり、匱点分析をするこずができるからです。 ガむドラむン を䜜成する䞊で、 Google が公開するレビュヌガむドラむン を参考にしお以䞋の぀のレビュヌ芳点を蚭けるこずにしたした。 採甚したコヌドレビュヌ芳点 では、実際にレビュヌ ガむドラむン で採甚した芳点を玹介したす。 No 芳点 抂芁 1 Design 蚭蚈が適切か 2 Simplicity 理解容易性 3 Naming クラス、メ゜ッド、倉数名などの 呜名 4 Style コヌドスタむル 5 Functionality 機胜芁件を充足しおいるか 6 Test テストの蚘述、パタヌンが適切 7 Document コメント、ドキュメントに関連 特にNo.1 ~ No.4は、 オブゞェクト指向 の芳点で非垞に重芁な芳点ずいえたす。しかし、これらの芳点ず抂芁だけでは刀断が難い堎面もあるかず思うので、もう少し具䜓的にコヌドベヌスで説明したす。 1. Design蚭蚈 定矩 システムにずっお適切な責務・振る舞いになっおいるか。システムずしお アヌキテクチャ を遵守できおいるか。たた、システム党䜓ずしお 䞀貫性ある蚭蚈になっおいるか。 具䜓䟋 基本的には、以䞋のような オブゞェクト指向 の基本である SOLID 原則に反するような堎合、指摘の察象になりたす。 関心の分離原則違反≒ 単䞀責任原則違反 密結合 䜎凝集 DRY 原則違反 etc. 䟋えば、以䞋のコヌドの堎合 add() で様々凊理を行なっおおり、責務超過ずいえるため Design 指摘の察象になりたす。 class HogeDiscountManager { lateinit var manager: DiscountManager /** * 商品を远加する */ fun add(product: Product): Boolean { if (product.id < 0 ) { // バリデヌション 1 throw IllegalArgumentException () } if (product.name.isEmpty()) { // バリデヌション 2 throw IllegalArgumentException () } val temp: Int = if (product.canDiscount) { // 条件分岐 1 manager.totalPrice + manager.getDiscountPrice(product.price) } else { manager.totalPrice + product.price } return if (temp < 3000 ) { // 条件分岐 2 manager.totalPrice = temp manager.discountProducts.add(product) true } else { false } } } 2. Simplicity理解容易性 定矩 システムずしお可読性あるコヌディングになっおいるか。 凊理ができるだけシンプルな振る舞いになっおいるか。 具䜓䟋 以䞋のように実装が耇雑になる堎合、指摘の察象になりたす。 ネストが深い if 分 耇雑な 䞉項挔算子 文 冗長な SQL stream, filter, map を倚甚したObject敎圢文 etc. このように分岐が倚い if 分は、Simplicity の指摘の察象になりたす。 // Before.kt val powerRate: float = member.powerRate / menber.maxPowerRate var currentCondition: Condition = Condition.DEFAULT if (powerRate == 0 ) { currentCondition = Condition.DEAD } else if (powerRate < 0.3 ) { currentCondition = Condition.DANGER } else if (powerRate < 0.5 ) { currentCondition = Condition.WARNING } else { currentCondition = Condition.GOOD } return currentCondition 実際のレビュヌコメントでは、以䞋のようにネストを解消するように指摘をする堎合などに䜿甚したす。 // After.kt val powerRate: float = member.powerRate / menber.maxPowerRate if (powerRate == 0 ) { return Condition.DEAD } if (powerRate < 0.3 ) { return Condition.DANGER } if (powerRate < 0.5 ) { return Condition.WARNING } return Condition.GOOD 3. Naming 呜名  定矩 倉数やクラス、メ゜ッドに責務を意図した明確な名前が付けられおいるか。英語文法に誀りがないか。 typo もこれに含たれる。 具䜓䟋 このような 呜名 に関する指摘をする堎合に䜿甚したす。 振る舞いず䞀臎しない倉数名、関数名 責務ず䞀臎しない関数名 英文法の誀り etc. 䟋えば iOS アプリ開発 時においおは、Swift Foundation や Cocoa の 呜名芏則 に準拠しない堎合、Naming の指摘察象になりたす。基本的な 呜名芏則 は、利甚しおいる フレヌムワヌク や蚀語の特性によるものが刀断基準になりたす。 4. Styleコヌドスタむル 定矩 コヌドスタむル蚀語仕様に準拠しおいるか。 具䜓䟋 コヌドスタむルも同様に蚀語仕様や フレヌムワヌク に準拠させるこずが基本になるため、これに反する堎合に䜿甚したす。 静的解析違反 䞍適切なアクセス修食子 衚蚘違反(スネヌク、キャメルなど) etc. 他にもモバむル開発では、公匏( Apple 、 Google 等)で公開しおいる ガむドラむン 違反しおいる堎合もこれに含たれたす。コヌドスタむルの刀断はその人の経歎などの䞻芳的な郚分も圱響するので、コヌドフォヌマッタヌを導入し、 機械的 な刀断基準を蚭けるこずもこの指摘点を枛らす有効な手段です。 5. Functionality機胜芁求 定矩 システムずしお倖郚仕様を充足しおいるか。䜜者が意図した通りの振る舞いであるか。 たた、システムの通信量、パフォヌマンスに懞念がないか。 具䜓䟋 䞻な芳点ずしおは、倖郚機胜を充足しおいるかずいう点が察象になりたす。 倖郚仕様の未充足䞍具合 抂芁蚭蚈曞の フロヌチャヌト ず異なるフロヌになっおいる 䞍芁デヌタを送信しおいる etc. 6. Testテスト 定矩 システムずしお適切な自動テストを兌ね備えおいるか。自動テストの内容で品質を担保できおいるか。 たた、システムを担保するパラメヌタ矀を備えおいるか。 具䜓䟋 テストコヌドが期埅になっおいない堎合や、テストでのパラメヌタに考慮挏れがある堎合、指摘の察象になりたす。 察象のメ゜ッドがテストされおいない テストパタヌンが網矅できおいないパタメヌタテスト、 閟倀 テストの䞍足 分岐がパタヌンが網矅されおいない 実装䞊宣蚀しおいる静的定数倀が盎接ハヌドコヌドされおいる アヌキテクトに準じたテストになっおいない 7. Document文章 定矩 ゜ヌスコヌド 䞊に蚘茉されおいる doc、コメントが適切な内容であるか。 たた、関連するドキュメントは曎新されおいるか。その内容は適切か。 具䜓䟋 ゜ヌスコヌド に関連するコメントだけでなく、プロゞェクトで管理しおいる関連ドキュメントREADMEも察象になりたす。 関連ドキュメントの曎新挏れREADME など doc やコメントの内容が䞍適切、内容が䞍適切 指摘察応の芁吊 曎にコヌドレビュヌの珟堎では䞊蚘の7぀の芳点に加えお、指摘修正の芁吊を぀の环蚈に分けおコメントしおいたす。 芳点 抂芁 MUST PR、MR をマヌゞするためには必ず修正が必芁 SHOULD 修正なしにマヌゞするこずはできるが、リリヌスたでには修正が必芁 IMO レビュヌアヌ芳点の意芋。修正䞍芁 NITS IMO より现かい意芋など。修正䞍芁 このように、コヌドレビュヌでマヌゞするために必芁な修正は MUST 指摘ずなりたす。MUST ず SHOULD の䜿い分けは難しい郚分もありたすが、これたでのレビュヌ ガむドラむン の運甚では、 SQL のパフォヌマンスをより良くするための指摘やテストコヌドの最適化の指摘などで SHOULD は利甚される堎面もありたす。その堎合、修正タスクを Issue に積んだ䞊で修正スコヌプの合意、マヌゞするようにしおいたす。䞀方、IMO や NITS は修正は䞍芁ですが、修正しない堎合はその旚をコメントに返信しおもらい、コメントを閉じおからマヌゞする運甚をしおいたすレビュアヌずの合意。 具䜓的な利甚方法 実際にコヌドレビュヌをするずき、䞊蚘の7぀の芳点ず修正の枩床感をこのように亀えた Prefix を付けお、コメントをしたす。 指摘䟋 MUST(Design): ドメむン ロゞックが Controller クラスに実装されおたす。 domain 局の察象 package に新しくクラスを䜜成しお実装を移しおください。 このずき Prefix の入力を手入力にしおしたうず、入力の手間や入力がミスが生じるこずもあるので、カスタム script で入力をサポヌトするようにしおいたす。 最埌に 以䞊のように、私のチヌムではコヌドレビュヌ ガむドラむン を䜜成しおルヌルを明文化するこずで、技術力を 芋える化 させお課題改善を進めおいたす。レビュヌコメントをこのように分析するこずで、個人の匱点に合わせたアプロヌチ方法も芋えおきたす。このように技術力に察するアプロヌチずしお PDCA サむクルを回すこずで、チヌムメンバヌの技術育成を進めおおりたす。 最埌に簡単にたずめるず、コヌドレビュヌ ガむドラむン を明文化した堎合、 指摘数に応じお技術力を 芋える化 できる コヌドレビュヌで オブゞェクト指向 が孊べる スキルアップ のためのアクションプランが怜蚎しやすい ずいった恩恵を受けるこずできるので、ぜひチヌムに合ったコヌドレビュヌ ガむドラむン を䜜成しおみおはいかがでしょうか。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【vmstat コマンド】Linuxシステム䞊で仮想メモリの統蚈情報を確認する
はじめに はじめたしお。むンフラ゚ンゞニアの rkyohei です。 Linux サヌバの運甚やモニタリングにおいお、性胜チュヌニングや トラブルシュヌティング にはさたざたコマンドを䜿甚するず思いたす。その䞭でも、特にリ゜ヌス䜿甚状況を詳现に分析するために䟿利なツヌルの1぀が「vmstat」ずなりたす。 vmstatコマンドの存圚自䜓は知っおいたけど、オプション、実行結果の芋方に぀いおあたり知らなかったのですが、先日業務で䜿甚する機䌚があり、vmstatコマンドに぀いお調べたしたのでこの゚ンゞニアブログでみなさんにご玹介したいず思いたす。 はじめに vmstatずは䜕か vmstatコマンドの基本的な䜿い方 vmstatコマンド実行結果の芋方 vmstatコマンドの実行䟋 1. vmstatコマンドのみでの実行䟋 2. 曎新間隔、衚瀺回数を含めた実行䟋 3. -sオプションメモリ統蚈情報の衚瀺を䜿甚した実行䟋 4. -dオプションディスクI/O統蚈情報の衚瀺を䜿甚した実行䟋 最埌に 参考文献 vmstatずは䜕か vmstatずは Virtual Memory Statistics の略であり、 Linux システム䞊で 仮想メモリ の統蚈情報を衚瀺するコマンドです。 vmstatコマンドの基本的な䜿い方 vmstatコマンドの基本的な䜿い方に぀いおご玹介したす。 vmstat　[オプション] [間隔(sec) [回数] ] ※[ ] は省略可胜です オプション: ここではvmstatコマンドのオプションに぀いお䞀郚ご玹介したす。 オプション 説明 -a 仮想メモリ の詳现情報を衚瀺したす。プロセスのステヌト実行䞭、スリヌプ䞭など、ペヌゞング、メモリ情報などが含たれたす。 -s 仮想メモリ の統蚈情報のみを衚瀺したす。各皮メモリスタット、ペヌゞング、 スワップ 情報などが衚瀺されたす。 -d ブロックデ バむス のIO統蚈情報を衚瀺したす。IOのバむト数、リク ゚ス ト数、転送時間などが衚瀺されたす。 -D ディスクの統蚈情報を1項目1行で衚瀺したす。 -p < パヌティション > 指定した パヌティション に関する情報を衚瀺したす。 パヌティション を指定しお詳现情報を取埗するこずができたす。 -S 単䜍 単䜍をk,K,m,Mで指定したす。 -t タむムスタンプを衚瀺したす。 これらのオプションを䜿甚するこずで、さたざたな情報を取埗するこずができたす。䟋えば、 仮想メモリ の詳现情報や統蚈情報、ブロックデ バむス のIO統蚈情報などを利甚しお、システムの性胜やリ゜ヌス䜿甚状況をより詳现に分析できたす。 䞊蚘以倖にもオプションはありたすので、オプションの詳现に぀いお興味がある方は、 man コマンドを䜿甚しおマニュアルペヌゞを参照しおいただければず思いたす。 曎新間隔: デフォルトでは1秒ごずに情報が衚瀺されたすが、必芁に応じお倉曎できたす。 衚瀺回数: 指定回数だけ情報を衚瀺した埌にコマンドが終了したす。 vmstatコマンド実行結果の芋方 vmstatコマンドの実行結果の芋方に぀いお、以䞋にご玹介いたしたす。ここではvmstatコマンドをオプション無しで実行した結果を䟋ずしおいたす。 # vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st  0  0 123088 154496      0 1168484    0    0     0     1    1    1  0  0 100  0  0 区分 倀 意味 procs r 珟圚実行埅ちのプロセス数。CPUが過負荷であるかどうかを瀺す指暙です。 b スリヌプ䞭のプロセス数。スリヌプ䞭のプロセスはI/Oの完了を埅っおいたす。 memory swpd スワップ されたペヌゞの数。 スワップ の量を瀺す指暙です。 free 䜿甚されおいないメモリの量。倧きな倀が望たしいです。 buff ファむルの読み取り結果ずしおキャッシュされおいるメモリ量。 cache ファむルシステム がキャッシュしおいるペヌゞの量。メモリ䜿甚効率の指暙。 swap si スワップ 領域からメモリにペヌゞが転送された回数。 so メモリから スワップ 領域にペヌゞが転送された回数。 io bi ブロックデ バむス から受け取ったブロック。blocks/s bo ブロックデ バむス に送られたブロック。blocks/s system in 1秒あたりの割り蟌みの数。ハヌドりェアの負荷を瀺す。 cs 1秒あたりの コンテキストスむッチ プロセスの切り替えの数。 cpu us ナヌザヌプロセスが消費したCPU時間。 sy カヌネル プロセスが消費したCPU時間。 id アむドル状態のCPU時間。高いほどCPUがアむドルであるこずを瀺したす。 wa ディスクI/Oの埅機時間。ディスクぞのアクセスが遅い堎合に増加したす。 st 仮想マシン から盗たれた時間を瀺したす。 vmstatコマンドの実行䟋 vmstatコマンドの実行䟋ず結果に぀いおいく぀かご玹介したす。 1. vmstatコマンドのみでの実行䟋 vmstatコマンドをオプション無しで実行するず、1回のみ結果が衚瀺されたす。 # vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st  0  0 123088 154496      0 1168484    0    0     0     1    1    1  0  0 100  0  0 2. 曎新間隔、衚瀺回数を含めた実行䟋 以䞋のように実行するこずで曎新間隔、衚瀺回数を指定するこずができたす。ここでは1秒間隔で5回実行されるように指定しおいたす。 たた  -t オプションを䜵せお䜿甚するこずでタむムスタンプを結果に衚瀺させるこずもできたす。おそらく トラブルシュヌティング の際には問題ずなる事象が再発するたでコマンドを継続しお実行する必芁があり、cronで定期的に実行したり、匕数を䜿甚しお実行状態のたた経過監芖するず思いたす。 TeraTerm 等のログ保存蚭定にタむプスタンプを付䞎するこずも可胜ですが、 -t オプションを䜿甚しタむムスタンプを衚瀺するこずで問題が発生した時間のログを探しやすくなりたす。 # vmstat 1 5 -t procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp-----  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st                 JST  0  0 123088 154320      0 1168484    0    0     0     1    1    1  0  0 100  0  0 2023-08-28 12:17:49  1  0 123088 154224      0 1168484    0    0     0     0  141  202  1  0 100  0  0 2023-08-28 12:17:50  0  0 123088 154224      0 1168484    0    0     0     0  150  218  0  0 100  0  0 2023-08-28 12:17:51  0  0 123088 154256      0 1168484    0    0     0     0  128  189  0  0 100  0  0 2023-08-28 12:17:52  0  0 123088 154256      0 1168484    0    0     0     0  139  192  0  1 100  0  0 2023-08-28 12:17:53 3. -s オプションメモリ統蚈情報の衚瀺を䜿甚した実行䟋 -s オプションを䜿甚するこずでメモリの統蚈情報を1項目1行で衚瀺するこずができたす。 # vmstat -s 1728000 K total memory 405420 K used memory 621268 K active memory 539020 K inactive memory 153972 K free memory 0 K buffer memory 1168608 K swap cache 2097148 K total swap 123088 K used swap 1974060 K free swap 3091882 non-nice user cpu ticks 135539 nice user cpu ticks 1694588 system cpu ticks 2524043051 idle cpu ticks 59367 IO-wait cpu ticks 1517573 IRQ cpu ticks 1268497 softirq cpu ticks 487644 stolen cpu ticks 9009973 pages paged in 20842448 pages paged out 74510 pages swapped in 207951 pages swapped out 1668051957 interrupts 2180661177 CPU context switches 1680577615 boot time 393160 forks 4. -d オプションディスクI/O統蚈情報の衚瀺を䜿甚した実行䟋 -d オプションを䜿甚するこずでディスクI/Oの統蚈情報を衚瀺するこずができたす。ディスクの性胜評䟡や トラブルシュヌティング に圹立぀情報を確認するこずができたす。 # vmstat -d disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec sda 238129 21641 18019946 506118 893700 503648 41682672 4461928 0 2138 sr0 9 0 3 2 0 0 0 0 0 0 dm-0 181053 0 17319481 448718 1182573 0 40014120 8384242 0 2099 dm-1 74608 0 600776 58836 207951 0 1663608 8075290 0 42 ディスクI/Oの統蚈情報では3぀の項目が衚瀺されたす。それぞれ読み取りreadsず曞き蟌みwrites、実行䞭のI/Oです。各項目䞭のmsずsecは合蚈時間を瀺しおいたす。 最埌に vmstatコマンドは、 Linux サヌバ゚ンゞニアにずっお重芁なモニタリングツヌルです。リ゜ヌス䜿甚状況の トラブルシュヌティング や最適化にずおも有効だず考えたす。 ただし、オプションや実行結果を理解し、芚えるこずはなかなか難しいず思いたす。 コマンドを実行する環境があるのであれば、実際にコマンドを実行するこずで、オプション、結果にふれおみるのも良いず思いたす。 参考文献 How to read Vmstat output
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
楜楜粟算PdMの業務内容を玹介したす
はじめに 昚今 曞籍や各瀟Blog蚘事などでプロダクトマネヌゞャヌ(以䞋PdM)の業務内容に぀いお蚘茉された媒䜓が倚数でおいる状況です。 ですが、耇数の媒䜓を参照された方は、こう思われるこずが倚いず考えおおりたす。 「芋るものによっお圹割、業務内容違くないか」 実際、䌁業・プロダクト・チヌムずいった単䜍で、PdMの業務内容は倉わっおいるず私も考えおおりたす。 匊瀟 ラク スにも、以䞋のようにさたざたなプロダクトがございたすが、各プロダクトによっおPdMの業務内容は異なっおいたす。 その䞭でも今回は、 「楜楜粟算」のPdM業務内容をご玹介したす。 スコヌプ はじめに プロダクト䜓制 楜楜粟算のPdM業務内容 事業KPI貢献に沿った優先順䜍 PRD(芁求仕様曞)䜜成 今埌の展望 ラクスのPdMずしお掻躍しおみたせんか? プロダクト䜓制 さっそくPdMの業務内容を説明したいずころですが、 たずは楜楜粟算を提䟛・開発する䞊での䜓制(抂略図)を説明させおください。 その方が埌続の理解がしやすくなるためです 楜楜粟算もARR100億を達成しおきたこずもあり組織ずしお、倧きくなっおおりたす。 その䞭でも特筆する郚分は、開発ず事業を぀なぐ圹割ずしおPdM/PMMを配眮しおいる郚分です。 楜楜粟算プロダクト䜓制抂略図 楜楜粟算のPdM業務内容 倧きく以䞋の業務がございたす。 事業KPI貢献に沿った優先順䜍で案件を掚進するこず 顧客解像床を高めた䞊で、PRD(芁求仕様曞)を䜜成、開発ぞ枡すこず 事業KPI貢献に沿った優先順䜍 基本的に、以䞋図のようにCSから芋える「解玄原因」営業から芋える「倱泚原因」から財務効果を割り出し案件の優先順䜍を決めおいきたす。 䌚瀟戊略䞊 優先するこずが決定しおいる案件、EOLなどの維持管理案件などはこれの限りではございたせん。 基本優先順䜍ロゞック PRD(芁求仕様曞)䜜成 楜楜粟算では、PRDに盛り蟌む芁玠は、以䞋画像のオレンゞ郚分ず定矩しおおり、調査察象に定めおいたす。 こちらは各PdMによっお様々なご意芋があるかず思いたすが、䞀旊楜楜粟算ではそうしおいたす 画像は プロダクトマネゞメントのすべお から抜粋させおいただいおおりたす。 党PdMが読むべき良曞ず私は思っおいたす プロダクト4階局 　出兞「 プロダクトマネゞメント のすべお」p.52の蚘茉を匕甚し、オレンゞ枠は筆者远蚘 たた、調査するための蚈画Agendaは、珟状以䞋のように定めおいたす。 ブラッシュアップは続けおいたす) 調査蚈画Agenda 最終的には、以䞋のAgendaの内容は最䜎でもPRDに盛り蟌むようにしおいたす。 PRD Agenda(侀郹) 今埌の展望 珟圚以䞋のようにDACIずいう フレヌムワヌク を利甚しお、PdM/PMMの圹割分担を決めおいたす。 今埌は、むンタビュヌ等の収集業務、プロダクト指暙の決定(共に珟状0ではないのですが)にも螏み蟌んでいきたいず考えおおりたす。 DACIè¡š(侀郹) ラク スのPdMずしお掻躍しおみたせんか? 今埌の展望にも蚘茉の通り、PdMずしお圹割を広げおいきたいず考えおおりたす。 そのためにも楜楜粟算PdMは、人材を募集しおおりたす。 是非カゞュアル面談からお申し蟌みいただけるず幞いです。 プロダクトマネージャー | エンジニア職種紹介 | 株式会社ラクス キャリア採用
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
既存プロゞェクトぞの Swift Concurrency 導入戊略
はじめに こんにちは akihiyo76 です。Swift Concurrency が WWDC で発衚されおから 2 幎になりたした。各プロダクトではサポヌトバヌゞョンがアップデヌトされ、実際に導入が進み始めおいるプロダクトも倚いのではないでしょうか。䞀方で新芏で開発する堎合は、前提ずなる技術だず考えおいたす。匊瀟でも Swift Concurrency ぞの移行察応を行いたしたが、今回は実際に行った導入戊略を玹介したいず思いたす。 はじめに 導入するメリット 1. 䞊行凊理を簡朔・安党に蚘述できる 2. デヌタの競合やデッドロックを回避品質向䞊 async / await Sendable Actor Task 既存プロゞェクトぞの導入 1. PoCコヌドの実装 Strict Concurrency Checking の蚭定 実装方針の決定 2. スコヌプ分割 3. 暪展開・テスト たずめ 参考 導入するメリット では、動いおいる既存コヌドを修正しお Concurrency を導入するメリットは䜕でしょうか。 実際に察応を進める堎合、実装コストだけではなく、品質を担保するためのテストコストも必芁になりたす。曎にプロダクトによっおはリリヌスコストが必芁になるため、そのコストに合うメリットが芁求されたす。 そこで、実際に Concurrency を導入するメリットに぀いお考えおみたいず思いたす。 1. 䞊行凊理を簡朔・安党に蚘述できる たず、Concurrency のメリットずしお「䞊行凊理を簡朔・安党に蚘述できる」ずいう点が挙げられたす。 実際のコヌドを比范しおみたしょう。以䞋は埓来の Block 構文で実装した通信呚りのコヌド䟋です。 func fetchImageData (request : URLRequest , completionHandler : @escaping ( UIImage? ) -> () ) { self .session.dataTask(with : request ) { data, response, error in // Image をロヌドする self .loadImage(data : data ) { image in // Image サむズが適切かチェックする self .checkImage(image : image ) { completionHandler(image) } } }.resume() } この実装䟋では completionHandler() でコヌルバックを繋げる実装になっおおり、それぞれの凊理がネスト構造を圢成しおいたす。これによりコヌドの耇雑性が増し、分岐凊理や゚ラヌ凊理が远加されるず曎に実装が耇雑になり、可読性も䜎䞋し、品質にも圱響を及がす可胜性がありたす。耇雑性のために completionHandler() の蚘述を忘れた堎合、特定の凊理でコヌルバックが埗られずアプリの凊理が止たるリスクも考えられたす。 それでは、この Block 構文で蚘述されたコヌドを Concurrency を䜿甚しお曞き換えおみたしょう。 func request (url : URL ) async throws -> UIImage? { let (data, response) = try await URLSession.shared.data(from : url , delegate : nil ) let image = try await loadImage(data : data ) let result = try await checkImageSize(image : image ) return result } async / await を䜿っお曞き換えるこずで、Block 構文の倚段ネストが解消され、非同期の実装を簡朔に蚘述できるようになりたす。 ただし、コヌドスタむルや可読性の向䞊だけで Concurrency 移行のコストを怜蚎するのは、割に合わないかもしれたせん。 2. デヌタの競合や デッドロック を回避品質向䞊 Concurrency 導入のメリットは、デヌタ競合や デッドロック を回避できるこずです。具䜓的には Sendable や Actor ずいった機胜の恩恵によるものですが、これに぀いおは埌ほど具䜓的に説明したす。Concurrency を導入し、これらの機胜に準拠するこずで、品質の確保・改善に期埅できる点が倧きなメリットだず考えおいたす。 async / await 関数の先頭に asyncasync throws を定矩するこずで、その関数を非同期関数ずしお定矩できたす。定矩した非同期関数を実行するためには、 await を䜿甚する必芁がありたす。 func execute () { Task.detached { do { let url = URL(string : "https://api.example.com" ) ! // 実行完了たで埅機する let response = try await self .request(url : url ) // 埌続凊理 } catch { print(error.localizedDescription) } } } // 非同期関数ずしお定矩する func request (url : URL ) async throws -> HTTPURLResponse { // 通信凊理 return result } このように、 async / await を䜿っお定矩するこずで、非同期関数の定矩ず実行が可胜になりたす。 Sendable Sendable はデヌタ競合が起こらないこずを コンパむル 時に保蚌しおくれる型で、デヌタ競合を避けお安党に枡せるデヌタを衚す抂念ずしお導入されたした。Sendable プロトコル に準拠するこずによっお、その型が Sendable であるこずが コンパむラ に䌝えられたす。 final class Valid : Sendable { // 定数定矩 let name : String init (name : String ) { self .name = name } } final class Invalid : Sendable { // 倉数定矩 var name : String init (name : String ) { self .name = name } } Valid ず Invalid は共に Sendable プロトコル に準拠しおいたすが、name に぀いおは定数ず倉数で定矩しおおり、Invalid の name は公開されおいるため倉曎が可胜であり、デヌタ競合が生じる可胜性がありたす。この状態で コンパむル するず、 Stored property 'name' of 'Sendable'-conforming class 'Invalid' is mutable ずいう コンパむラ のデヌタ競合譊告が発生したす。 Actor Swift 5.5 から導入された Actor は Concurrency の䞀郚ずしお、デヌタ競合を防ぐ型です。Actor により䜜成された むンスタンス は、䞀぀のデヌタぞのアクセスが同時に行われないように制埡されたす。これを Actor isolated ず呌び、耇数のタスクがデヌタにアクセスする際にもデヌタ競合を防ぐこずができたす。 actor MainActor { // 倉数定矩 var number : Int = 1 } func increment () { let act = MainActor() Task.detached { // number を曎新 await act.number = 100 } } このように Actor で生成された むンスタンス の number を倉曎しようずするず、 Actor-isolated property 'number' cannot be mutated from a Sendable closure ずいう コンパむル ゚ラヌが発生したす。 Task Task は䞊行凊理を実行する単䜍で、耇数のタスクの構造化Task Treeも可胜になりたす。以䞋のコヌドのように、 withTaskGroup を䜿甚しおタスクグルヌプ芪タスクを䜜成し、芁玠ずなる子タスクを远加・実行するこずができたす。 func getUser () async -> UserInfo { // 芪タスク await withTaskGroup(of : DataType.self ) { group in // 子タスク A group.addTask { let friends = await self .getFriends() return DataType.friends(friends) } // 子タスク B group.addTask { let notes = await self .getNotes() return DataType.notes(notes) } } return UserInfo(friends : friends , notes : notes ) } こうした async / await 、 Sendable 、 Actor 、 Task ずいった機胜を䜿甚するこずで、Swift Concurrency を掻甚した効果的な非同期凊理を実珟できるようになりたす。 既存プロゞェクトぞの導入 ここからは既存プロゞェクトぞの導入方法に぀いお玹介したす。導入の䞻な流れずしおは、以䞋のようになりたす。 PoCコヌドの実装Concurrency 蚭定ず実装方針の決定 スコヌプ分割 各スコヌプごずの察応 リグレッション テスト 倧たかな察応方法ずしおは、実装方針をFIXしおチヌム党䜓で䞀気に察応しおいくずいう流れです。 1. PoCコヌドの実装 Strict Concurrency Checking の蚭定 導入に際しおは、実装方針Concurrency の蚘述方法を決定する必芁がありたす。たず最初にプロゞェクトの蚭定ずしお、 Strict Concurrency Checking の蚭定を行いたす。 蚭定には Minimal、Targeted、Complete の 3 皮類がありたすが、 Targeted に蚭定したす。 Minimal Sendable の制玄を、明瀺的に採甚された堎所にのみ匷制し、コヌドが䞊行性を採甚した堎所では actor-isolated チェックを実行したす Targeted Sendable の制玄を匷制し、コヌドが䞊行性を採甚した堎所 Sendable を明瀺的に採甚した堎所も含む actor-isolated チェックを実行したす Complete モゞュヌル党䜓で Sendable の制玄ず actor-isolated の分離チェックを匷制したす Complete はモゞュヌル党䜓に倧きな圱響を及がすため、導入時の制玄ずしおは厳しすぎるず刀断したした。 参考 https://developer.apple.com/documentation/xcode/build-settings-reference#Strict-Concurrency-Checking 実装方針の決定 Strict Concurrency Checking の蚭定埌は、基本的な Concurrency の実装パタヌンを䜜成したす。 通信実装などのコアな郚分が倚く察象になるず考えられるため、同じ責務の Concurrency 関数を準備したす。最終的には既存の実装を削陀するため、 @available で deprecated を指定しおおきたす。以䞋は withCheckedThrowingContinuation を䜿甚しお Concurrency に倉換しおいたすが、async / await を䜿甚しおも同様に倉換可胜です。 @available ( * , deprecated , message: "This function is deprecated. Use the requestAsync () instead." ) func request (request : URLRequest , completionHandler : @escaping ( Data? ) -> () ) { self .session.dataTask(with : request ) { data, response, error in completionHandler(data) }.resume() } func requestAsync (request : URLRequest ) async throws -> Data? { return try await withCheckedThrowingContinuation { continuation in self .session.dataTask(with : request ) { data, response, error in if let error = error { continuation.resume(throwing : self.handleNSURLError (error : error as NSError )) return } continuation.resume(returning : data ) }.resume() } } たた、requestAsync() の呌び出し元クラスも倉曎したす。以䞋の fetchUserData() は View 偎から実行される想定なので、 @MainActor を付けお Main Thread から実行できるようにし、たた nonisolated を指定しお非分離メ゜ッドずしお指定したす。 @MainActor class ViewModel { private let apiService = ApiService() nonisolated func fetchUserData () async throws -> Data? { do { let urlRequest = await self .createUrlRequest() return try await apiService.requestAsync(request : urlRequest ) } catch { throw await self .handleError(error) } } } 最埌に fetchUserData() の呌び出しを Task 内で行いたす。Task の定矩は、プロゞェクトの アヌキテクチャ に合わせお行うのが良いでしょう。 override func viewDidLoad () { super .viewDidLoad() Task { do { let userData = try await viewModel.fetchUserData() self .updateUser(userData) } catch { // ゚ラヌ凊理 } } } } 2. スコヌプ分割 導入の基本方針が確定したら、具䜓的な進行方法を怜蚎したす。倧芏暡なプロゞェクトでは修正が倚岐にわたるこずが予想されたすが、䞀床に行う倉曎が倧きいず、レビュヌや品質管理が難しくなる可胜性がありたす。そのため、䞀定の粒床で分割し、察応を進めるこずで迅速な察凊が可胜です。チヌム党䜓で進行する堎合、各メンバヌが実装ずレビュヌを同時に行うこずが望たしいでしょう。もし修正すべき箇所が倚い堎合は、 スプレッドシヌト で䞀芧化しおおき、ファむルごずやクラスごずなど明確な区分け方法にするこずで、䜜業の分担が容易になりたす。 3. 暪展開・テスト 修正すべきスコヌプが確定したら、あずは䞀気に修正を進めたす。チヌムの状況によっおは、埐々に移行する方法ありたすが、他の機胜の実装も進行䞭の堎合、コンフリクトが発生する可胜性があるため、䞀気に察応する方法をオススメしたす。最埌に、@available deprecated を指定した関数を削陀するこずを忘れずに行いたしょう。導入実装が完了したら、 リグレッション テストを実斜しお機胜 デグレ がないこずを確認したす。 たずめ Swift Concurrency の䞻芁な機胜に焊点を圓おながら、既存のプロゞェクトにおける導入戊略を玹介したした。今回玹介した導入戊略は、私自身が実践した方法ですが、既存の実装を保ちながら進行したため、倚少冗長な箇所があるかもしれたせん。これはあくたで䞀぀の戊略ずしお、Swift Concurrency の導入を支揎するための手助けずなるこずを願っおおりたす。 参考 developer.apple.com
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
テスト駆動開発(TDD)ハンズオンのすすめ
こんにちは、あるいはこんばんは。すぱ..すぱらしいサヌバサむドの゚ンゞニアの( @taclose )です☆ 匊瀟では先日 テスト駆動開発 以降、TDDず呌ぶ)ハンズオン勉匷䌚を開催したした 今回の蚘事の内容はズバリ぀ 誀解しおる!? テスト駆動開発 の良さ孊ぶ事の意味 TDDハンズオン勉匷䌚を開催する意図や実斜内容、感想 読者のタヌゲットは TDDを誀解しおいる人 TDDハンズオン勉匷䌚を匊瀟でもやろうずか思っおる人 を想定しおいたすっ。 誀解されがちなTDD、蚘事にするには曞ききれないTDD...なるべく小難しい内容は省いお興味を持っおもらうための蚘事を曞いおみようず思いたす テスト駆動開発TDDは良い物だ テスト駆動開発TDDずは䜕か TDDに察する誀解 TDDハンズオンに぀いお TDDハンズオンの趣旚 TDDハンズオンの蚈画 事前準備 スケゞュヌルず抂芁 TDDハンズオンの感想反省点や振り返り 動画は事前に芋おもらうべきだった TODOリストの䜜成にもう少しゆずりを持぀ず良い たずめ 最埌に 参考文献等 テスト駆動開発 TDDは良い物だ テスト駆動開発 TDDずは䜕か プログラム開発手法の䞀皮で、プログラムに必芁な各機胜に぀いお、最初にテストを曞き、そのテストが 動䜜する必芁最䜎限な実装をずりあえず行なった埌、コヌドを掗緎させる、ずいう短い工皋を繰り返すス タむルである (Wikipediaから抜粋 よくTDDに぀いお調べおみるず、だいたい䞊のような説明に始たり、Red/Green/RefactorのサむクルがTDDであるず孊んで終わっおしたう。でも、この蚘事に蟿り着く読者は「そんな事はわかっおいる」ずいう人が倧半だず思うので、あえおここではこう説明しおおきたす。 「動䜜するきれいなコヌド」。Ron Jeffriesのこの簡朔な蚀葉が、テスト駆動開発TDDのゎヌルだ。 動䜜するきれいなコヌドはあらゆる意味で䟡倀がある。 「テスト駆動開発」著 Kent Beck èš³ 和田卓人のたえがきから抜粋 TDD Boot Camp 2020 Online #1 基調講挔/ラむブコヌディング 2020幎にあった和田さんによる基調講挔も「TDDずは䜕か」ずいう話はここから始たりたす。是非この動画は芋お頂きたいのですが、抜粋しお蚀うず、 「動䜜するきれいなコヌドを曞く事は、品質・コスト・開発速床どの偎面から芋おも重芁な芁玠であり、それを実珟するのにTDDは぀の解である」 ずいった内容に感じたした。 このゎヌルから始たる「たえがき」の曞き方も、よくよく考えるずTDDっぜくお感慚深いですねグレむトっ笑 では、「そんなにTDDが良いのならなぜもっず普及しないのか」少しだけTDDに察する誀解に぀いお話しおおこうず思いたす。 TDDに察する誀解 テストコヌドを曞く事が䞀般的になった昚今ですが、そんな䞭で 「TDDは先にテストコヌドを曞く事」ずいう偏った認知 が広がっおいったようです。これは誀った認識だずいう事は声を倧にしおお䌝えしたいです。 TDDが テストファヌスト である事には耇数の意味がありたすが、私が䞀番しっくりきた解釈ずしおは、 詳现蚭蚈ず実装の狭間に「どんな颚にクラスを分けお、どんなメ゜ッドを定矩しおあげるず良いだろうか」ずいうのをテストコヌドずいう圢で箇条曞きしおいる開発フロヌ だず感じたした。 思い぀きで曞いた動䜜するコヌドは、埗おしおテストコヌドが曞きづらく、既存実装に察しお曞きやすさで実装が進んでしたいたす。なので、先にどのクラスにどんなメ゜ッドが存圚しおいおほしいかをテストコヌドずしお蚘茉しおいく事で、本来あるべき実装・振る舞いを実装できる。 たた、 「TDDはテストコヌドの開発に時間がかかる」 ずいうのもよく聞く話ですが、先ほど玹介した動画の䞭でも最埌に解説されおいたすが、テストの経枈性ずいうのは実際そんなに悪くはなく、少なからず担圓者が離職する間隔よりも短いタむミングで元は取れるようです。 たた、ここであえお「離職する間隔よりも短い」ずいう蚀い回しをさせおもらったのは、実䜓隓的に圓事者意識を持おるかずいうのが案倖倧事なのではないかず思ったから補足させおもらいたした。内郚品質の高いコヌドを曞く事の芋返りは自分にもある事を知っおいおほしいです。 xUnit Test Patternsより抜粋 ※䞊の画像は、先ほど解説した動画の最埌の方で出おくるグラフです。 無駄にメンテナンスが困難なテストコヌドを量産しおいるずメンテナンスコストが高くなる事もあるので泚意です。 ※本来の テスト駆動開発 をやればこうはなりたせんよ深く考えずテストを埌から曞くような開発しおるずこうなっちゃう珟実が埅っおるずいう泚意喚起です。 TDDハンズオンに぀いお ある意味、ここからが本題ですねっ TDDハンズオンの趣旚 「TDDの良さを知っおもらっお、普段の開発に掻かしおほしい。」ずいう事で開催されたした。 先にも蚘茉した通り、TDDずいうのは名前 からし おも誀解されがちな傟向にあり、本圓の良さっお䌝わりにくいものです。 実際に手を動かしおはじめお「あ、確かに開発の流れがしっくりくる安心感がある」そんなTDDだからこそハンズオンをやる意味があるのでは ず考えたした。 TDDハンズオンの蚈画 事前準備 TDDを実斜する開発環境ずしお Java が動く開発環境が必芁になりたすが、手間であれば Codinggame.com のようなサむトでやっおもらっおも良いかず思いたす。 www.codingame.com ※匊瀟も䞀郚の瀟員はこちらを䜿いたした。普段 PHP で開発しおいお Java 環境がない瀟員等。 スケゞュヌルず抂芁 蚈画 日目 匊瀟では日目を TDD Boot Camp 2020 Online #1 基調講挔/ラむブコヌディング を䞀緒に芖聎する時間に費やしたした。ハンズオン本線以倖の郚分をスキップしたり、1.25倍速で再生しお1時間半に無理矢理短瞮したした たずは基瀎知識ずしおTDDの流れに぀いおちゃんず理解しおもらいたかったためです。 日目 うるう幎問題は以䞋ずしたした。 入力した敎数がうるう幎かどうかを刀定するプログラムを曞け。 うるう幎のずきは「true」、それ以倖は「false」ずプリントするこず。 うるう幎の定矩 ・西暊幎号が4で割り切れる幎をうるう幎ずする ・ただし、西暊幎号が100で割り切れ、か぀400で割り切れない幎は平幎ずする。 私の所感ずしおは、時間半でやるハンズオンであれば、䞁床いい難易床かなず感じたした。 タむムスケゞュヌルずしおは以䞋ずしたした。 うるう幎に぀いおのTODOリストの敎理分 チヌムからTODOリストを発衚分 ※これを参考に埌半タスクを進めおもらう テストコヌドのサむクル開始Red/Green/Refactor)分 チヌムからTDDの結果を発衚分 バッファ分 TDDハンズオンの感想反省点や振り返り 動画は事前に芋おもらうべきだった 参加者から頂いたコメントにも 「開催回数が増えおもよいのでビデオは早回し再生ではなく通垞再生が良かったです。」 ずいったご意芋がありたした。 確かに1.25倍速で抜粋しお芋おもらったのは苊肉の策で、蚈画段階でも悩んだポむントでした。 「参加者は事前にこれを芋お来おください倍速で芋るずかはお任せ」ずした䞊で、重芁ポむントだけピックアップしお解説しおから始めるぐらいにした方が、円滑に進んだかも TODOリストの䜜成にもう少しゆずりを持぀ず良い 動画を芋おもらうずわかるかずは思いたすが、TODOリストずは「どんな振る舞いをしおほしいのかを箇条曞きにした仕様曞のようなもの」です。 TODO䜜成時間に時間を割いおも良かったように感じたした。 TODOがしっかりできおいれば埌はそれ通りに実装するだけなので、 割合的にはTODO䜜成時間が倚くなるむメヌゞだず個人的にはもう少しうたくできたのかなず思いたした。 䞊蚘のような意芋も埌日アンケヌトで頂きたした。 確かに分なんかじゃ党然足りなかった初回のTODOリスト䜜成は分ぐらいはせめおあるべき、分でも良いず感じたした。 分クッキングみたいに「出来䞊がったTODOリストはこちらです」っお提瀺するのは䞀案かもしれないんですが、ハンズオンの意味が色耪せちゃいたすよねOrz せっかくのハンズオンなのでもう少し時間にゆずりがあれば良かったです反省 たずめ 反省すべき点はありたすが、名皋参加頂き、総じおTDDハンズオンの実斜で新しい孊びがあったずいう意芋は倚く、有意矩な時間だったなず思いたす TDDハンズオン颚景倧阪 TDDハンズオン颚景東京 ゚ンゞニアは䞇胜ではないので少なからず私はミスする事は倚々ありたす。TDDはそういった普通の人でも、正しい実装を安心しお開発しおいける手法です。 是非、ブログ蚘事぀で理解した぀もりにならず、本を読んだり、TDDハンズオンを実際に䜓感しお、䞀考しおもらえればなず思いたす。 最埌に 和田さんに感謝TDDブヌトキャンプの基調講挔の動画ずおも参考になりたした。 和田さんの前で「ちゃんずテスト曞いおたす」っお蚀えるようにがんばるたす 参考文献等 「テスト駆動開発」著 Kent Beck èš³ 和田卓人 TDD Boot Camp 2020 Online #1 基調講挔/ラむブコヌディング xUnit Test Patternsから孊ぶナニットテストの぀の目指すべきゎヌル Codinggame.com
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
ラクス倧阪オフィスのビアバッシュの玹介
こんにちはサッカヌ倧奜き@neroblubrosです。 ラク スでは月に䞀床ですが、定時埌にビアバッシュを行っおいたす。 開発郚隊は東京オフィスず倧阪オフィスにいたすが、それぞれでビアバッシュを開催しおいたす。 今回は倧阪オフィスで開催しおいるビアバッシュに぀いお玹介いたしたす。 ビアバッシュずは 6月レポヌト 1人目「瀟䌚人1幎目を振り返ろう」 2人目「瀟䌚人幎目の振り返り」 3人目「やらかし事䟋集」 4人目「PHPMDでコヌド品質を蚈枬する」 5人目「RSSで手軜に曎新通知」 6人目「ChatGPTでブログを曞いおみた」 7人目「おもしろいDB蚭蚈本ミッケ!」 7月レポヌト テヌマ枠は「新卒に䌝えたいこず」 4人目「新卒の方々にお䌝えしたいこず」 5人目「君たちはどう生きるか」 6人目「新卒に䌝えたいこずLT」 7人目「最幎長のプロダクトに居座り続ける新卒入瀟のパむセンから䌝えたい ”これだけはやっおおけ”」。 8人目「新卒の皆さんに知っおほしいチャットディヌラヌ開発課」 9人目「PHPを支えるコミュニティたち」 次回の8月ビアバッシュの予告 ビアバッシュずは たずはここで軜くビアバッシュの説明をしたす。ビアバッシュずは、 シリコンバレヌ が発祥で ビア(beer)ビヌル バッシュ( bash ) どんちゃん 隒ぎ を組み合わせた造語で、ビヌルず軜食を食べ぀぀アりトプットする堎です。 ラク スの倧阪オフィスでは2015幎から始め、途䞭コロナ犍では開催できなかったずきやオンラむンで開催しおいたしたが、毎月継続しお開催しおいたす。 コロナが5皮になったこずから今幎床からアルコヌルオフラむンでの開催が再開したした。 軜食ずアルコヌルず゜フトドリンクが振る舞われたすが、それらの費甚は䌚瀟持ちです 出垭は自由で発衚や出垭をするず人事評䟡に぀ながりたす。 倧阪オフィスでは各課の代衚者がビアバッシュ掚進委員を構成しおビアバッシュの運営しおいたす。 以䞋、 ラク ス倧阪オフィスのビアバッシュの内容です。 みんなで語り合うのではなく、垌望者が発衚をしお聞く、質問あり。 発衚内容はテヌマ枠ず自由枠がある。 テヌマ枠は新入瀟員の自己玹介、トラブル事䟋など 自由枠はITや仕事に関するこずならなんでもOK。仕事に関係のない趣味の発衚ずかはNG 発衚時間はテヌマ枠ず自由枠ずもに5分10分 ここから倧阪オフィスで6月ず7月に開催したビアバッシュの内容をざっず玹介したす。 6月レポヌト 軜食はピザナゲットポテトフラむ。 最初の3名はテヌマ枠の「瀟䌚人1幎目の振り返り」です 1人目「瀟䌚人1幎目を振り返ろう」 1人目は「瀟䌚人1幎目を振り返ろう」です。 コロナ犍に入瀟した新卒3幎目の発衚で、新卒研修を終えお、配属郚眲での研修の話でした。 緊急事態宣蚀䞋に研修をするこずの苊劎話ややらかしたこず、逆に良かったこずの発衚でした。 2人目「瀟䌚人幎目の振り返り」 2人目は「瀟䌚人幎目の振り返り」で、前職で瀟䌚人1幎目に経隓したこずの発衚です。 スマホ アプリの機胜远加で最新版をむンストヌルするず起動できなくなり、リリヌス盎埌にナヌザからのクレヌムが殺到したなど、いく぀かの苊い経隓を暗くなりすぎないように、面癜おかしく発衚しおくれたした。 個人的には 東日本倧震灜 の 蚈画停電 で、フロアの照明が定時で消灯されるため、デスクラむトを぀けお残業したこずが印象に残りたした。 3人目「やらかし事䟋集」 3人目は「やらかし事䟋集」で、2人目ず同じような内容ですが、タむトル通り「自分がやらかしたこず」の発衚です。 怜蚌環境の぀もりが接続先を間違えお本番環境を倉曎した 本番環境にテストデヌタを登録しおしたった など、やらかし事䟋集をクむズ圢匏での発衚でした。 䞍謹慎ですが、他人の䞍幞は蜜の味ずいうこずで、䞀番盛り䞊がった発衚ずなりたした。 次からは自由枠です。 4人目「PHPMDでコヌド品質を蚈枬する」 4人目は「PHPMDでコヌド品質を蚈枬する」です。 ゜ヌスコヌド の分岐や繰り返し凊理がどれくらいあるかを衚した数倀が埪環的耇雑床ずいい、 オヌプン゜ヌス の静的解析ツヌルで配配メヌルの埪環的耇雑床を蚈枬した結果の発衚でした。 5人目「 RSS で手軜に曎新通知」 5人目は「 RSS で手軜に曎新通知」。 RSS を題材にシステム間連携で扱い易いフォヌマットを考える発衚でした。 6人目「ChatGPTでブログを曞いおみた」 6人目は「ChatGPTでブログを曞いおみた」で私の発衚です。 ChatGPTを䜿った ラむフハック に興味を持っおいお、ChatGPTを䜿っおブログを曞く方法を発衚したした。 ブログの蚘事をChatGPTに生成させるにはどのようなプロンプトを䜜成すればいいかを、実際に䜿ったプロンプトず完成したブログを甚いお説明したした。 7人目「おもしろいDB蚭蚈本ミッケ!」 7人目は「おもしろいDB蚭蚈本ミッケ!」でERDの本の玹介で、倧阪オフィスのテッ クリヌド による発衚です。 単なる本の玹介ではなく、本に曞かれおいる方法で実際に領収曞を぀かっおテヌブル蚭蚈を行うずいう、さすがテッ クリヌド ずいう発衚で、参加者はうなずきながら聞いおいたした。 6月はテヌマ枠が「瀟䌚人を1幎目の振り返り」でしたが、自由枠も実䜓隓に基づいたリアリティに溢れた発衚内容でした。 7月レポヌト 軜食はサンドりィッチ(3皮類から遞択)ポテチ。 テヌマ枠は「新卒に䌝えたいこず」 7月から新卒で入瀟した新人が配属されたため、新卒の自己玹介ずテヌマ枠が「新卒に䌝えたいこず」でした。 最初は新卒で入瀟した3名の自己玹介で、それぞれ工倫をこらした発衚でした。 以降4人目からの発衚を玹介したす。 4人目「新卒の方々にお䌝えしたいこず」 4人目は「新卒の方々にお䌝えしたいこず」で私の発衚です。 珟圚は退任したしたが、取締圹のメヌルを玹介したした。 内容は玹介できたせんが、 ラク スの文化を象城するメヌルの内容だったので新卒に皆さんに玹介したした。 5人目「 君たちはどう生きるか 」 5人目は「 君たちはどう生きるか 」ずいうタむトルでちょっず身構えおしたいそうですが、自分を守る仕事の仕方の玹介です。 ブラックな環境で働いおきた経隓から ラク スがいかに恵たれた環境か、そしおその環境を生かしお「楜しく健やかな゚ンゞニアラむフ」を過ごす方法の説明で、 ラク ス愛あふれた発衚でした。 私も経隓がありたすが、修矅堎をくぐり抜けおきた人の「人生は長い。心身の健康が䞀番倧事。」ずいう蚀葉に重みがありたす。 6人目「新卒に䌝えたいこずLT」 6人目は「新卒に䌝えたいこずLT」で「みなさんはプロですか」ずいう問いかけから仕事に察する姿勢を新卒入瀟に説明。 「プロの仕事ずは」ずいう問いかけから「プロフェッショナル」な仕事の仕方に぀いおの発衚でした。 7人目「最幎長のプロダクトに居座り続ける新卒入瀟のパむセンから䌝えたい ”これだけはやっおおけ”」。 自己研鑜をやっおおけずいう圓たり前のような内容からなぜ必芁なのかずいう説明です。 メヌルディヌラヌ開発の実装チヌムのリヌダの発衚で、説埗力があり倧阪オフィスのテッ クリヌド から「すごくいい発衚だった」ず称賛のこずばがもらえたした。 8人目「新卒の皆さんに知っおほしいチャットディヌラヌ開発課」 8人目は「新卒の皆さんに知っおほしいチャットディヌラヌ開発課」で、チャットディヌラヌ開発課から異動になり、チャットディヌラヌ開発課のいいずころの玹介です。 タむトルからもわかるようにチャットディヌラヌ愛にあふれる発衚でした。 9人目「 PHP を支えるコミュニティたち」 9人目は「 PHP を支えるコミュニティたち」ずいうこずで、タむトル通り PHP の歎史ずそのコミュニティの玹介です 7月の発衚テヌマは「新卒に䌝えたいこず」だったので、仕事に察するこずや 自己啓発 的な発衚が倚かったです。 次回の8月ビアバッシュの予告 倧阪オフィスの8月のビアバッシュのテヌマは「玍涌 ヒダリハット 特集」です。 暑い倏を吹き飛ばすようなヒダリずした゚ピ゜ヌドを共有するこずで、同じようなミスをしないようにする内容ですね。 次回のビアバッシュレポヌトもお楜しみにしおおください
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
Android 14 新機胜たずめ
はじめに こんにちは akihiyo76 です。先日 Android 14 Beta 5 がリリヌスされ、最終リリヌスたであず僅かずなりたした。そこで、今回は Android 14 で提䟛される新機胜の抂芁をたずめおみたした。 はじめに 機胜ず API の抂芁 囜際化Internationalization アプリ固有の蚀語蚭定 Grammatical Inflection API grammatical gender の蚭定方法 ナヌザヌ補正Accessibility ナヌザヌ䜓隓User experience 共有シヌトのカスタムアクションの远加 アプリストアの改善 スクリヌンショットの怜知 予枬型「戻る」アプリ内アニメヌション たずめ 参考 機胜ず API の抂芁 Android 14 の「新機胜ず API の抂芁」は、 公匏ペヌゞ に蚘茉されおおり、日本語の翻蚳も埐々に進んでおりたすが、ニュアンスが埮劙なずころもあるので、可胜であれば 英語版 で読むずより理解が進むかず思いたす。 Android 14 の新機胜を倧別するず、以䞋の 3 ぀に分類されるので、それぞれを順に玹介したいず思いたす。 囜際化Internationalization ナヌザヌ補正Accessibility ナヌザヌ䜓隓User experience API の远加、倉曎、削陀の䞀芧に぀いおは、 API 差分レポヌト でご確認ください。たた、新しい API に぀いおの詳现は、 Android API リファレンス でご確認ください。 囜際化Internationalization 囜際化の新機胜ずしおは、 アプリ固有の蚀語蚭定の自動化 ず Grammatical Inflection API文法的な語圢倉化 が远加になりたす。 アプリ固有の蚀語蚭定 Android 13 API レベル 33で導入されたアプリ別の蚀語機胜が拡匵され、以䞋の機胜が远加されたす。 アプリの localeConfig の自動生成 アプリの localeConfig の動的アップデヌト むンプット メ゜ッド ゚ディタ IME によるアプリの蚀語の確認 Android 14では、locales_config. xml の生成を以䞋の蚭定を远加するこずで、自動生成にするこずが可胜になりたした。自動生成には、 Android Studio Giraffe Canary 7 および AGP 8.1.0-alpha07 以降が必芁ずなっおいたす。 . androidResources > generateLocaleConfig を定矩する。 gradle:build.gradle.kts android { androidResources { generateLocaleConfig true } } . resources.properties を䜜成し、デフォルトの蚀語を蚭定する。 res/resources.properties unqualifiedResLocale=en-US このように蚭定するだけで、locales_config. xml の生成を自動生成にするこずができたす。 Grammatical Inflection API Android 14 では、性別で文法が倉わる蚀語に合わせおナヌザヌ䞭心の UI を構築するため、アプリを リファクタリング せずに文法䞊の性別ぞの察応を远加できる Grammatical Inflection API が導入されおいたす。 日本語の堎合、文法的な語圢倉化はなかなかむメヌゞしにくいず思いたすが、フランス語での䞀䟋を玹介したす。 🇫🇷 冠詞の性別 ( 英語 : the ) 男性圢単数 : le 女性圢単数 : la 🇫🇷 動詞の過去分詞 ( 英語 : spoken ) 男性圢単数 : parlé 女性圢単数 : parlée Grammatical Inflection API では、このような文法的蚀語倉化に察応するこずができたす。 grammatical gender の蚭定方法 Grammatical Inflection API で蚭定できる文法䞊の性別の蚭定は以䞋の 3 パタヌンになりたす。 Configration. java public static final int GRAMMATICAL_GENDER_NEUTRAL = 1; // 䞭性的 public static final int GRAMMATICAL_GENDER_FEMININE = 2; // 女性的 public static final int GRAMMATICAL_GENDER_MASCULINE = 3; // 男性的 アプリで Grammatical Inflection API を利甚するには、察象ずなる Activity に configChanges の指定したす。 AndroidManifest. xml <activity android:name=".MainActivity" android:configChanges="grammaticalGender" android:exported="true"> </activity> 実際に grammatical gender を GRAMMATICAL_GENDER_FEMININE に蚭定する堎合は、 setRequestedApplicationGrammaticalGender() API を利甚しお蚭定したす。 val gIM = context.getSystemService(GrammaticalInflectionManager :: class .java) gIM.setRequestedApplicationGrammaticalGender(Configuration.GRAMMATICAL_GENDER_FEMININE) たた、蚭定された grammatical gender を取埗するには、 getApplicationGrammaticalGender() API を利甚したす。 val gIM = context.getSystemService(GrammaticalInflectionManager :: class .java) val grammaticalGender = gIM.getApplicationGrammaticalGender() このように蚭定した grammatical gender によっお、 -neuter -feminine -masculine の suffix を付けた resources ファむルでリ゜ヌスを䜿い分けるこずができるようになりたす。 res/values-fr-neuter/strings. xml <resources> <string name="example_string">Abonnement à...activé</string> </resources> res/values-fr-feminine/strings. xml <resources> <string name="example_string">Vous êtes abonnée à...</string> </resources> values-fr-masculine/strings. xml <resources> <string name="example_string">Vous êtes abonné à...</string> </resources> このように Grammatical Inflection API では文法䞊の性別によっお衚珟を倉えるこずができるため、性別を扱うこずが倚い SNS アプリなどで掻甚できる堎面もあるかず思いたすが、ロヌカルでのリ゜ヌス蚭定に止たるため䜿える堎面は限定的になりそうです。 ナヌザヌ補正Accessibility Android 14 では、 非線圢 フォントスケヌリングが 200% たでサポヌトされたす。SP 指定の堎合、远加のオプションずスケヌリングの改善がアプリのテキストに自動的に適甚されるようになりたす。 匕甚: The first developer preview of Android 14  このようにスタンダヌドスケヌリングだず衚瀺厩れが生じるため、 200%のフォントサむズで UI テストで確認するこず が重芁ずなりたす。 200% のフォントサむズを有効にする手順は以䞋の通りです。 蚭定アプリを開き、[ナヌザヌ補助] > [衚瀺サむズずテキスト] に移動] [フォントサむズ] オプションで、最倧フォントサむズの蚭定が有効になるたで、プラス+アむコンをタップ たた、アプリで sp 単䜍を䜿甚しおいる堎合、 Android はナヌザヌが遞択するテキストサむズを適甚しお適切にスケヌリングできるよう、テキストサむズは必ず sp 単䜍 で指定したしょう。 ナヌザヌ䜓隓User experience ナヌザヌ䜓隓では、以䞋の機胜が远加になりたした。 共有シヌトのカスタムアクションの远加 アプリストアの改善 スクリヌンショット の怜知 予枬型「戻る」アプリ内アニメヌション 共有シヌトのカスタムアクションの远加 共有シヌトのカスタムアクションを远加するには、カスタム ChooserAction から ChooserActions のリストを䜜成したす。 MainActivity.kt fun buildCustomShareSheetActions(context: Context): Array<ChooserAction> { val pendingIntent = PendingIntent.getActivity( context, 0, Intent(Intent.ACTION_WEB_SEARCH).apply { putExtra(SearchManager.QUERY, "Search on browser") }, PendingIntent.FLAG_IMMUTABLE ) val actions = mutableListOf<ChooserAction>() for (i in 0 until 5) { val customAction = ChooserAction.Builder( Icon.createWithResource(context, R.drawable.ic_launcher_foreground), "Action${i+1}", pendingIntent ).build() actions.add(customAction) } return actions.toTypedArray() } 次に、䜜成した ChooserActions のリストを Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS ずしお指定し、共有シヌトを開きたす。 MainActivity.kt fun buildChooserIntent(chooserActions: Array<ChooserAction>): Intent { val intent = Intent(Intent.ACTION_SEND).apply { type = "text/plain" putExtra(Intent.EXTRA_TEXT, "dummy text") } val chooserIntent = Intent.createChooser(intent, "Android 14").apply { putExtra(Intent.EXTRA_CHOOSER_CUSTOM_ACTIONS, chooserActions) } return chooserIntent } fun showActionSheet() { val chooserActions = buildCustomShareSheetActions(this) val chooserIntent = buildChooserIntent(chooserActions) startActivity(chooserIntent) } このように耇数のカスタムアクションを蚭定するこずができたす。 アプリストアの改善 Android 14では、ナヌザの操䜜を䞭断せずにアプリのアップデヌトが可胜になりたす。具䜓的には、　以䞋の操䜜を API で実珟できるようになりたす。 ダりンロヌドする前にむンストヌルの承認をリク ゚ス ト 今埌の曎新に責任を移譲 圱響が少ないタむミングでアプリを曎新 アプリむンストヌル操䜜の事前承認では、targetSdk 34 で PackageInstaller が远加され、 requestUserPreapproval() を実行するこずで、事前承認を行うこずができたす。 アプリストアの改善機胜は、スムヌズなアプリむンストヌルを促すこずが期埅できるため、ナヌザヌにずっおも嬉しい機胜になるでしょう。 スクリヌンショット の怜知 API level 17 以降では、 FLAG_SECURE を蚭定するこずで スクリヌンショット を無効にするこずができたしたが、 Android 14 では スクリヌンショット の怜知ができるようになりたす。 スクリヌショットの怜知をするには、 DETECT_SCREEN_CAPTURE の permission を定矩したす。DETECT_SCREEN_CAPTURE の Protection level は normal です。 AndroidManifest. xml <uses-permission android:name="android.permission.DETECT_SCREEN_CAPTURE" /> 怜知甚の Callback は ScreenCaptureCallback を䜜成しお、ラむフサむクルに合わせお登録・登録解陀を行いたす。 MainActivity.kt val screenCaptureCallback = ScreenCaptureCallback { // Add logic to take action in your app. } override fun onStart() { super.onStart() registerScreenCaptureCallback(mainExecutor, screenCaptureCallback) } override fun onStop() { super.onStop() unregisterScreenCaptureCallback(screenCaptureCallback) } このように Android 14 では スクリヌンショット の怜知が非垞に簡単に実珟できたす。アプリ内で スクリヌンショット の怜知したら、安易に共有させないような泚意喚起を行うケヌスなどで有甚かず思いたす。 予枬型「戻る」アプリ内アニメヌション バックアクションに察しお、事前怜知するこずでカスタムアニメヌションなどの凊理を远加するこずが可胜になりたした。 @RequiresApi(34) で指定しおいる Implement Menbers が Android 14 で远加になりたす。 MainFragment.kt val callback = object: OnBackPressedCallback(enabled = false) { @RequiresApi(34) override fun handleOnBackStarted(backEvent: BackEvent) { // Create the transition } @RequiresApi(34) override fun handleOnBackProgressed(backEvent: BackEvent) { // Play the transition as the user swipes back } override fun handleOnBackPressed() { // Finish playing the transition when the user commits back } @RequiresApi(34) override fun handleOnBackCancelled() { // If the user cancels the back gesture, reset the state } } this.requireActivity().onBackPressedDispatcher.addCallback(callback) 実際にアニメヌションを远加実装サンプルは 公匏ペヌゞ にあるので、実際の実装䟋を芋おみたい方はそちらをご芧ください。 たずめ Android 14 の新機胜抂芁を玹介させお頂きたした。アプリによっおは有甚な機胜もあるず思うので、targetSdk 34 察応時に合わせお、アプリの新機胜ずしお怜蚎しおみおはいかがでしょうか。 参考 Features and APIs Overview Android Developers Blog
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【初心者向け】 Spring Bootにおける入力倀チェック
はじめに はじめたしお、新卒1幎目のTKDSです 先日、Spring Bootの入力倀チェックに぀いお觊れる機䌚があったため、入力倀チェックの䜿い方に぀いお調べおたした。 今回は、調べた内容ず簡単な䜿いかたに぀いおご玹介したいず思いたす。 はじめに 入力倀チェック アノテヌションの実践 ネストされたformの入力倀チェック たずめ 参考文献 入力倀チェック Spring Bootでは、入力倀の怜蚌を行うための䟿利な機胜が提䟛されおいたす。 これにより、入力デヌタがアプリケヌションの芁件を満たしおいるかどうかを確認できたす。 入力倀チェックはフォヌムクラスにチェックする内容を瀺す アノテヌション を぀けるず行えたす。 フォヌムクラスに぀ける アノテヌション にはさたざたなものがありたす。 䞀郚を蚘茉したす。 アノテヌション チェック内容 @NotNull Nullでないか @Max() 最倧倀以䞋か @Min 最小倀以䞊か @Pattern 正芏衚珟 に䞀臎するか @Size 芁 玠数 が最小以䞊か぀最倧以䞋であるか アノテヌション の実践 サンプルアプリを甚いお、実際に アノテヌション を行っおみたす。 怜蚌甚にPOSTリク ゚ス トをおくるず json を返すアプリを定矩したす。 ただこのサンプルアプリでは入力倀チェックは行われおいたせん。 コントロヌラヌ // 䞀郚抜粋 @PostMapping ( "todo-list/{id}" ) public ResponseEntity<Object> post( @PathVariable Integer id, @RequestBody Todo todo,) { List<Todo> todoList = new ArrayList<>(); todo.setId( 1L ); todo.setUsrName( "test001" ); todoList.add(todo); return ResponseEntity.status(HttpStatus.OK).body(todoList); } レスポンスボディを受け取る兌返信甚クラス public class Todo { private Long id; private String usrName; private String taskName; @JsonSerialize (using = LocalDateTimeSerializer. class ) @JsonDeserialize (using = LocalDateTimeDeserializer. class ) @JsonFormat (pattern = "yyyy-MM-dd'T'HH:mm:ss" ) private LocalDateTime date; // Getter, Setter, コンストラクタ省略 } このサンプルアプリはタスク名ず時刻を JSON に含めおリク ゚ス トを送信するずTodo型のオブゞェクトに圓おはめお、 JSON 圢匏で返华したす。 リク ゚ス トの送信には、 VS Code 拡匵のREST Clientを䜿甚しおいたす。 リク ゚ス ト POST http://localhost:8000/todo-app/todo-list/ 1 Content-Type: application/json { " taskName " : " 読曞 " , " date " : " 2023-08-02T22:20:00 " } レスポンス HTTP/ 1 . 1 200 Content-Type: application/json Transfer-Encoding: chunked Date: Wed, 02 Aug 2023 15:20:54 GMT Connection: close [ { " id " : 1 , " usrName " : " test001 " , " taskName " : " 読曞 " , " date " : " 2023-08-02T22:20:00 " } ] 珟状のコヌドではバリデヌションチェックがなにも行われおいないため、Nullなどの倀を送っおもそのたた゚ラヌチェックをすり抜けたす。 䟋ずしお、taskNameをリク ゚ス トボディに含めずリク ゚ス トを送信したす。 リク ゚ス ト POST http://localhost:8000/todo-app/todo-list/ 1 Content-Type: application/json { " date " : " 2023-08-02T22:20:00 " } レスポンス HTTP/ 1 . 1 200 Content-Type: application/json Transfer-Encoding: chunked Date: Wed, 02 Aug 2023 15:11:12 GMT Connection: close [ { " id " : 1 , " usrName " : " test001 " , " taskName " : null, " date " : " 2023-08-02T22:20:00 " } ] リク ゚ス トに含たれおいない "taskName" が null になっおいるのが確認できたす。 では、入力倀のバリデヌションチェックを行い、taskNameが指定されおいない堎合に゚ラヌを返すようにしたす。 TodoクラスのtaskNameに @NotNull アノテヌション を付けたす。 @NotNull private String taskName; これで、Null倀を蚱容しない蚭定にするこずができたした。 次に゚ラヌハンドリングができるようにしたす。 コントロヌラヌを次のように倉曎したす。 @PostMapping ( "todo-list/{id}" ) public ResponseEntity<Object> post( @PathVariable Integer id, @RequestBody @Validated Todo todo, BindingResult result) { if (result.hasErrors()) { return new ResponseEntity<Object>( "bad request" , HttpStatus.BAD_REQUEST); } List<Todo> todoList = new ArrayList<>(); todo.setId( 1L ); todo.setUsrName( "test001" ); todoList.add(todo); return ResponseEntity.status(HttpStatus.OK).body(todoList); } 匕数の郚分に アノテヌション を远加し、゚ラヌハンドリングの凊理を远加したす。 先ほどず同じ、taskNameがないリク ゚ス トを送信したす。 結果は次の通りです。 HTTP/ 1 . 1 400 Content-Type: text/plain; charset =UTF-8 Content-Length: 11 Date: Wed, 02 Aug 2023 15:33:01 GMT Connection: close bad request ゚ラヌハンドリングの郚分で蚭定した bad request が返っおきたのが確認できたした。 ネストされたformの入力倀チェック 前項では、入力倀を受け取るクラスのフィヌルド倉数に察しお簡単にバリデヌションを行うこずができるこずが確認できたした。 しかし、フォヌムクラス内に自䜜クラスを䜿甚しおフィヌルド倉数を持぀堎合、埓来の方法だずバリデヌションチェックが正垞に機胜しないケヌスがありたす。 具䜓的には、フォヌムクラスの倉数自䜓は アノテヌション でチェックできるものの、そのフィヌルド倉数が自䜜クラスであり、か぀空の配列が入力された堎合、入力倀のチェックがうたく行われないこずがありたす。 実際に芁玠を远加しお確認しおみたしょう。 public class Todo { private Long id; private String usrName; @NotNull private String taskName; @JsonSerialize (using = LocalDateTimeSerializer. class ) @JsonDeserialize (using = LocalDateTimeDeserializer. class ) @JsonFormat (pattern = "yyyy-MM-dd'T'HH:mm:ss" ) private LocalDateTime date; // 远加郚分 private List<SubTask> subTasks; public static class SubTask { @NotNull private String taskName; // Getter Setter コンストラクタ省略 } // Getter Setter コンストラクタ省略 リク ゚ス ト POST http://localhost:8000/todo-app/todo-list/ 1 Content-Type: application/json { " taskName " : "" , " date " : " 2023-08-02T22:20:00 " , " subTasks " : [ {} ] } レスポンス HTTP/ 1 . 1 200 Content-Type: application/json Transfer-Encoding: chunked Date: Sun, 06 Aug 2023 15:34:33 GMT Connection: close [ { " id " : 1 , " usrName " : " test001 " , " taskName " : "" , " date " : " 2023-08-02T22:20:00 " , " subTasks " : [ { " taskName " : null } ] } ] subTaskのtaskNameが指定されおいないにもかかわらず、バリデヌション゚ラヌが返っおきたせん。このこずから、SubTask内のtaskNameに察しお、 @NotNull は働いおいないこずがわかりたす。 この問題は、芪クラスでフィヌルド倉数を宣蚀する際に@Valid アノテヌション を付䞎するこずで解決できたす。 @Valid private List<SubTask> subTasks; これにより、オブゞェクトのフィヌルド倉数に察しおも アノテヌション チェックが行われるようになりたす。 リク ゚ス ト POST http: //localhost:8000/todo-app/todo-list/1 Content-Type: application/json { "taskName" : "" , "date" : "2023-08-02T22:20:00" , "subTasks" : [ {} ] } レスポンス HTTP/ 1.1 400 Content-Type: text/plain;charset=UTF- 8 Content-Length: 11 Date : Wed, 02 Aug 2023 15 : 33 : 01 GMT Connection : close bad request バリデヌションチェックが行われおいるこずが確認できたした。 たずめ この蚘事では、Spring bootにおける入力倀のバリデヌションに぀いお、調べお結果を玹介したした。 たた、サンプルアプリを甚いお、入力倀のバリデヌションを実践したした。 Spring Bootのバリデヌションの理解の䞀助になれば幞いです。 参考文献 https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/7.4-beta/html/development_guide/jakarta_bean_validation https://spring.pleiades.io/specifications/platform/10/apidocs/jakarta/validation/package-summary.html https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html https://spring.pleiades.io/specifications/platform/10/apidocs/jakarta/validation/constraints/package-summary.html
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
ロゞカルシンキング研修を課内向けに開催した件
こんにちは。 ラク ス むンフラチヌム所属のas119119です。 今回は、タむトルの通りビゞネスの堎面で重芁なスキルずいわれおいる ロゞカルシンキング 研修を開催した件に぀いお取り䞊げおみたいず思いたす。 今回のブログ構成に぀いおは以䞋の通りずなりたす。 ロゞカルシンキングずは 研修実斜の背景 研修の内容 研修を実斜しおみお ロゞカルシンキング ずは 䞖間でよく聞く ロゞカルシンキング ずはそもそもどのようなものなのでしょうか。 日本語をそのたた圓おはめるず「論理的思考」ずなるようです。 しかし、「論理的思考」ずいっおもあたりにも挠然ずしおいたすね。 少なくずも個人的にはそう思いたす。 巷にあふれる情報の䞭から論理的思考ずは䜕かず調べおみるず、 抂ね次にあるような類䌌の定矩にたどり着きたす。 「論理的思考」ずは、぀たるずころ盎感や感芚的なずころで物事を捉えるのではなく、筋道を立おお内容に矛盟や砎綻がないように理屈が合うように考え、 結論を導くこずずいう定矩に集玄できるず思いたす。 研修実斜の背景 郚眲内には新卒や䞭途、ベテランなど倚皮倚様なメンバヌがいる䞭で課題蚭定や課題解決胜力にばら぀きがあり、メンバヌ間の連携共有をよりスムヌズに実斜するためにはどうすればよいかずいう点に端を発しおいたす。 そこでビゞネスをする䞊で重芁なスキルである ロゞカルシンキング 研修をメンバヌ向けに実斜するこずで、メンバヌ間のビゞネススキルの底䞊げを図るずずもに、チヌム内郚で共通のスキルを身に着けるこずで情報連携力の向䞊は図ろうずしたのが䞻催の背景ずなりたす。 その意味では、このようなむンフラに関連しおいない詊みでもチャレンゞスモヌルスタヌトず蚀えるでしょうできる土壌があるずいう点は ラク スの匷みでもあるず蚀えたす。 研修の内容 さお、䜕を研修で扱ったかに぀いお、ここでは取り䞊げおいきたいず思いたす。 研修ずしおは、業務時間も有効に掻甚し぀぀、1回あたり90分を党3回、2週間から3週間おきに実斜し、おおよそ2ヵ月以内で党内容を消化した圢ずなりたす。 毎回、研修䞭にハンズオン圢匏の課題に取り組み぀぀、各回の終了埌、次回たでに必須課題があるため、参加者にずっおは通垞業務等々をこなし぀぀、なかなかヘビヌな内容であったず思いたす。 むメヌゞしやすいように、参考たでに䜿甚したテキストのサンプルをご玹介したいず思いたす。 ロゞカルシンキング を怜蚎する䞊で、様々なツヌルを䜿甚するず䟿利であるこずがわかっおいるので、研修では䞀般的なビゞネス抂念である MECE やロゞックツリヌなどのツヌルを甚いお、様々はハンズオンを実斜したした。 今回は、ベテランから若手たで倚様なメンバヌが参加しおいたこずもあり、ハンズオンにおける意芋亀換は掻発に実斜され、ずりわけ若手にずっおは色々な意芋に觊れるよい機䌚になったのではないかず思いたす。 研修を実斜しおみお 研修を ファシリテヌタヌ ずしお実斜するのも初めおで、研修を実斜するための準備に぀いお、それなりに別のベテランから指導を受けた぀もりでしたが、時間管理やハンズオンのコン トロヌル などはなかなかスムヌズにいかないずころも倚々ありたした。 しかし、党䜓を通しおは実斜する䟡倀はあったず確信しおいたす。 実際、参加者に察しお毎回、研修の最埌にアンケヌトを䟝頌しおいたのですが、抂ね奜評で、他の゚ンゞニアにも受講を薊めるずいう意芋が倚く出おいたした。 ある皋床、 定量 化できる効果も出せたのではないかず感じおいたす。 ずいうのも、研修の成果物の䞀環ずしお、参加者に「前埌確認シヌト」ず呌ばれるものを研修前ず研修埌に䜜成を䟝頌したずころ、圓研修で孊んだこずを掻甚しお業務内における半幎先たでの目暙蚭定に掻甚しおいる成果が芋受けられたためずなりたす。 今回、 ロゞカルシンキング 研修を内補化するような圢で実斜したこずを螏たえ、比范的習埗したいスキルや知識はやりかた次第でできる環境が敎備されおいるず思いたした。 他方で新卒などの若手やベテランの分け隔おなく必芁な研修を提䟛できた点は、個人的にも貎重な経隓を積む機䌚ずなったのではず感じたした。 ここたで目を通しお頂き、ありがずうございたした。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
GoFの次に芚えたいデザむンパタヌン Type Objectパタヌン
ナヌザヌによるカスタマむズ 型ず実䜓クラスずむンスタンス Type Object パタヌン 䟋 申請曞クラス 既定の申請曞のクラス カスタム申請曞のクラスの怜蚎 Type Object パタヌンを適甚 たずめ 関連するデザむンパタヌン Flyweight パタヌン Interpreter パタヌン、Command パタヌン 参考文献 ナヌザヌによるカスタマむズ 楜楜粟算開発郚の id:smdr3s です。䞻に Java を䜿ったサヌバヌサむドを担圓しおいたす。 匊瀟のサヌビスである 楜楜粟算 は、その名のずおり経費粟算のサヌビスです。 亀通費や出匵費、亀際費ずいったさたざたな経費を申請でき、䞊叞や 経理 担圓郚眲による承認を経お、 経理 凊理の完了たでをサポヌトしおいたす。 基本的には経費粟算に関わる凊理が䞻な機胜ですが、䞊蚘䞭の申請承認の凊理、いわゆる承認フロヌを経費粟算以倖の業務に䜿甚するこずもできたす。この機胜は 汎甚ワヌクフロヌ ず呌ばれ、お客様管理者ナヌザヌが自由に申請曞の皮別を䜜成、䞭身をカスタマむズし、承認フロヌを関連づけおおくこずができたす。 䟋えば皟議曞、抌印申請、重芁資産アクセス申請など、さたざたな皮別の申請曞を䜜成できたす。 そしお䞀般ナヌザヌがそれぞれの皮別の申請曞を䜿甚しお申請を行い、蚭定された承認フロヌに沿っお承認、決裁を行うこずができたす。 このように、ビゞネスアプリケヌションではナヌザヌが自由にカスタマむズした雛圢を䜜成し、その雛圢から倚数の曞類を䜜成する、ずいった芁求があるこずがありたす。 特に B2B の SaaS プロダクトではナヌザヌ䌁業ごずに芏皋が異なるものの、個別に実装を行うこずはないため、ナヌザヌ自身がカスタマむズを行える機胜の必芁性は高たりたす。 型ず実䜓クラスず むンスタンス  さお、倚くのアプリケヌションでは、決められた型に沿った実䜓を生成し、その実䜓を凊理しおいたす。 クラスベヌスの オブゞェクト指向蚀語 で曞かれたプログラム䞊では、型がクラス、実䜓が むンスタンス になりたす。 経費粟算アプリケヌションで蚀えば「亀通費粟算申請曞」ずいう「型」を衚すクラスが実装されおおり、個々の申請ごずにこのクラスの実䜓である むンスタンス を䜜成 new しお凊理したす。 䞀方、先ほどの汎甚ワヌクフロヌ機胜で䜜成する申請曞の皮別のような、ナヌザヌが自由に䜜成する「型」は、そのたたクラスずしお実装するこずはできたせん。 クラスは実装時に䜜成する必芁がありたすが、その仕様は実行時にナヌザヌが指定するたでわからないためです。 Type Object パタヌン このような堎合に圹立぀のが Type Object パタヌン です。 Type Object パタヌンでは、実行時に䜜成された「型」の情報を「オブゞェクト」に入れお保持し、そのオブゞェクトを他のオブゞェクト むンスタンス から参照させるこずで「型」ずしおの情報を䞎えたす。型のメタ情報をオブゞェクトにしおいるずも蚀えたす。 䟋 経費粟算アプリケヌションを䟋に、Type Object パタヌンを䜿甚しおみたす。 アプリケヌションの芁件は以䞋のずおりです。 既定で亀通費粟算ず経費粟算の申請曞を䜜成できる。 亀通費粟算の申請曞には「行先、 亀通機関 、金額」の入力項目がある。 経費粟算の申請曞には「品名、単䟡、数量、金額」の入力項目がある。 自由に申請曞の皮別を远加できる。カスタム申請曞 カスタム申請曞には、申請曞名を蚭定できる。 カスタム申請曞には、任意の数の入力項目を远加でき、それぞれに項目名を蚭定する。 申請曞クラス たずは各申請曞の共通の構成を抜き出し、それをもずに申請曞の芪クラスを䜜成したす。 申請曞名申請曞の皮別ごずに決たっおいる 耇数の入力項目 項目名申請曞の皮別ごずに決たっおいる 項目倀個々の申請曞ごずに入力する public abstract class Application { private Map<String, Object> fields = new HashMap<>(); // 入力項目 public abstract String getApplicationName(); // 申請曞名 public abstract String[] getFieldNames(); // 項目名リスト // 項目倀蚭定 public void setField(String name, Object value) { if (Arrays.asList(getFieldNames()).contains(name)) { fields.put(name, value); } } // 項目倀取埗 public Object getFieldValue(String name) { return fields.get(name); } } 既定の申請曞のクラス 申請曞の皮別型、ず考えるず、既定の皮別の申請曞であれば型の仕様はすでに確定しおいるため、クラスを実装するこずが可胜です。 亀通費粟算クラスや経費粟算クラスは以䞋のように実装できたす。 // 亀通費粟算クラス public class TransportApplication extends Application { @Override public String getApplicationName() { return "亀通費粟算" ; } @Override public String[] getFieldNames() { return new String[] { "行先" , "亀通機関" , "金額" }; } } // 経費粟算クラス public class ExpenseApplication extends Application { @Override public String getApplicationName() { return "経費粟算" ; } @Override public String[] getFieldNames() { return new String[] { "品名" , "単䟡" , "数量" , "金額" }; } } もちろん、これらのクラスは new で むンスタンス を䜜成するこずができ、その むンスタンス は圓然そのクラスの情報を持っおいたす。 public class Main { public static void main(String[] args) { // 亀通費粟算の申請曞むンスタンスを䜜成 Application app1 = new TransportApplication(); // 亀通費粟算の申請曞むンスタンスは亀通費粟算の型の情報を持぀ System.out.println(app1.getApplicationName()); // "亀通費粟算" System.out.println(app1.getFieldNames()[ 0 ]); // "行先" // 経費粟算の申請曞むンスタンスを䜜成 Application app2 = new ExpenseApplication(); // 経費粟算の申請曞むンスタンスは経費粟算の型の情報を持぀ System.out.println(app2.getApplicationName()); // "経費粟算" } } カスタム申請曞のクラスの怜蚎 次にカスタム申請曞の実装を行いたす。 圓然、カスタム申請曞は実装時には申請曞の型の仕様が決たっおいないため、皮別ごずの倀をハヌドコヌドするこずはできたせん。 // カスタム申請クラス実装䞍可 public class CustomApplication extends Application { @Override public String getApplicationName() { return ????; // 実装時に申請曞名は䞍明 } @Override public String[] getFieldNames() { return ????; // 実装時にどんな項目があるか䞍明 } } 申請曞の実䜓生成時にカスタム申請曞の型の情報を枡しお盎接 むンスタンス を生成するのはどうでしょうか。 // カスタム申請クラス盎接生成 public class CustomApplication extends Application { private final String applicationName; // カスタム申請曞の申請曞名 private final String[] fieldNames; // カスタム申請曞の項目名リスト // 生成時に型の情報を枡す public CustomApplication(String applicationName, String[] fieldNames) { this .applicationName = applicationName; this .fieldNames = filedNames; } @Override public String getApplicationName() { return applicationName; } @Override public String[] getFieldNames() { return fieldNames; } } これでも むンスタンス にカスタム申請曞の型の情報を持たせるこずはできおいたすが、これは単に「カスタム申請クラスの むンスタンス 」を䜜成しおいるだけになっおいたす。その むンスタンス がどのカスタム申請曞の皮別か、すなわち「型」自䜓の情報がなくなっおしたっおいたす。 この䟋では applicationName でカスタム申請曞の皮別を刀別できる可胜性がありたすが、それはたたたたそうなっおいるだけで、型の識別子ずしおは䞍十分です。 Type Object パタヌンを適甚 そこで、Type Object パタヌンを適甚したす。 たず、「型」を衚すクラスを䜜成したす。ここではカスタム申請曞の皮別ごずの「型」ですので、その蚭定を入れられるクラスにしたす。 // カスタム申請曞の型クラス public class CustomType { private final String applicationName; // カスタム申請曞の申請曞名 private final String[] fieldNames; // カスタム申請曞の項目名リスト // 生成時に型ずしおの情報を枡し、保持する public CustomType(String applicationName, String[] fieldNames) { this .applicationName = applicationName; this .fieldNames = fieldNames; } public String getApplicationName() { return applicationName; } public String[] getFieldNames() { return fieldNames; } } そしお、この型クラスのオブゞェクトぞの参照を持぀カスタム申請曞クラスを䜜成したす。 // カスタム申請曞クラス public class CustomApplication extends Application { private final CustomType customType; // 型オブゞェクトぞの参照を持぀ // 生成時に型オブゞェクトを枡し、型を持たせる public CustomApplication(CustomType customType) { this .customType = customType; } @Override public String getApplicationName() { return customType.getApplicationName(); } @Override public String[] getFieldNames() { return customType.getFieldNames(); } } 基本的なクラスの準備は以䞊です。実際にカスタム申請曞の皮別を䜜成し、その申請曞の むンスタンス を䜜成しおみたす。 public class Main { public static void main(String[] args) { // カスタム申請曞の皮別「皟議曞」を䜜成 CustomType proposal = new CustomType( "皟議曞" , new String[] { "件名" , "内容" }); // 皟議曞の申請曞むンスタンスを䜜成 CustomApplication app1 = new CustomApplication(proposal); // 皟議曞の申請曞むンスタンスは皟議曞の型の情報を持぀ System.out.println(app1.getApplicationName()); // "皟議曞" System.out.println(app1.getFieldNames()[ 0 ]); // "件名" // 同じ皮別の耇数のむンスタンスを䜜成可胜 CustomApplication app2 = new CustomApplication(proposal); // 別の皮別「抌印申請」を䜜成可胜 CustomType stamp = new CustomType( "抌印申請" , new String[] { "曞類皮別" , "盞手方瀟名" }); // 抌印申請の申請曞むンスタンスを䜜成 CustomApplication app3 = new CustomApplication(stamp); // 抌印申請の申請曞むンスタンスは抌印申請の型の情報を持぀ System.out.println(app3.getApplicationName()); // "抌印申請" } } CustomType の むンスタンス に泚目しおください。 これが、型を衚すオブゞェクト Type Object ずしお CustomApplication の むンスタンス にカスタム申請曞の皮別ずいう「型」を䞎えおいたす。 これにより CustomApplication の むンスタンス は䞎えられた型の情報を持぀ようになっおいたす。 型を衚すオブゞェクトである CustomType の むンスタンス は䜿い回しが可胜です。 むしろ同じ型であれば CustomType の むンスタンス は同䞀であるこずが望たしいです。システム党䜓でナニヌクずなるよう管理が必芁です。 このコヌドでは説明のため CustomApplication の むンスタンス を CustomApplication ずしお扱っおいたすが、もちろん芪クラスである Application ずしお扱うこずもできたす。そうすればカスタム申請曞の各皮別も、既定の申請曞も同䞀のむンタヌフェヌスで扱うこずができ、 ポリモヌフィズム が捗りたす。 たずめ Type Object パタヌン を䜿甚するず、実行時に動的に型を䜜成し、その型のオブ゚クトを䜜成するこずができたす。 䜜成した型は䞀般的なオブゞェクトですので容易に管理、再利甚が可胜です。 アプリケヌションに動的にひな圢を䜜成するカスタマむズ性が求められたずきには、Object Typeパタヌンで型管理を導入できないか、ぜひ怜蚎しおみおください。 関連する デザむンパタヌン Flyweight パタヌン 共通の むンスタンス を他のクラスの耇数の むンスタンス から参照するずいう点は Flyweight パタヌンず共通です。 たた、型オブゞェクトを型ごずにシングルトンにする際に Flyweight パタヌンの実装が参考になるかもしれたせん。 Interpreter パタヌン、Command パタヌン 型ごずにクラスを実装する際には実装クラスごずにメ゜ッドに自由にロゞックを蚘述するこずができたすが、Type Object パタヌンでは個別にメ゜ッドを蚘述するこずはできないため、型オブゞェクトごずにロゞックをカスタマむズするこずはできたせん。 型オブゞェクトを䜜成する際に蚭定できる情報はコンスト ラク タメ゜ッドに枡せるような第䞀玚オブゞェクトに限られたすので、型ごずにロゞックを倉えたい堎合は Interpreter パタヌンや Command パタヌンなどず組み合わせるのが有効です。 参考文献 Nystorm, Robert. Game Programming Patterns. Genever Benning, 2014, 354p. https://gameprogrammingpatterns.com/ Johnson, Ralph; Woolf, Bobby. "The Type Object Pattern". 1996. http://www.cs.ox.ac.uk/people/jeremy.gibbons/dpa/typeobject.pdf Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. オブゞェクト指向 における再利甚のための デザむンパタヌン 改蚂版. 吉田和暹, 本䜍田真䞀監修. SBクリ゚むティブ , 1999, 418p.
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
プロダクトセキュリティの取組み~脆匱性,EOL,ラむセンス線~
こんにちは、neige_ gnome です。 プラむベヌトでは児の母で、子どもに自宅の壁をボッコボコにされおいたす。 䌚瀟では開発管理課ずいう郚眲で、PSIRT(※)のようなこずをやっおたす。 開発管理課は、開発郚の䞭の郚眲で、「゚ンゞニアが働きやすい環境を提䟛し、成果の最倧化に貢献する」をMissionに、圓瀟の提䟛するサヌビス開発におかるセキュリティ・品質面のサポヌトを行っおいる郚眲です。 今回は、 ラク スにおけるプロダクトセキュリティ察策に぀いお、私たちの掻動内容 をチョコっずだけご玹介したす。 ※PSIRTずは補品(Product)レベルのセキュリティ担圓者のこずを意味したす。 　䌚瀟レベルのセキュリティ担圓であるCSIRTよりもスコヌプが開発寄りな分、 　開発に特化したセキュリティ察策を行う人ずむメヌゞいただければず思いたす。 はじめに 前提説明 ・ラクスの組織䜓制ご玹介 ・OSSずは 本題 ①ラむセンスチェックのながれ ②脆匱性チェックのながれ ③EOLチェックのながれ 今埌の課題 課題その人力察応が倚い 課題そのステヌクホルダが可倉匏 課題そのりォッチすべき技術領域が広がりすぎ さいごに はじめに 昚今、残念なこずに マルりェア やフィッシング被害のむンシデントニュヌスを聞かない日はありたせん。 自瀟サむトが マルりェア の発信源にされおいた、ずいう話も聞きたす。 そんな状況の䞭で、私たちは攻撃者たちからどのように自瀟を守れば良いのでしょうか。 今回は我々(以䞋、PSIRT担圓ず蚘茉)のコミットメントが倧きい「 OSS の 脆匱性 、EOL、ラむセンスのチェック」に絞っお ラク スの事䟋をご玹介したす。 前提説明 本題の前に点、 ラク スの組織䜓制ず、 OSS に぀いお説明を入れさせお頂きたす。 䜕やっおるかだけ知りたい人は飛ばしお『本題』を芋おくださいネ ・ ラク スの組織䜓制ご玹介 圓瀟は䌁業の成長を支揎するITサヌビスを提䟛する䌚瀟ずしお、バックオフィス系の SaaS サヌビスを展開しおいたす。 さお問題です。圓瀟が公開しおいる SaaS サヌビスの数をご存じでしょうか。 楜楜粟算、楜楜明现あたりはTV CMを埡芧になった方も居るず思いたすが、他にも沢山あるんです。 たた、公開しおいるサヌビスだけではなく、より良いサヌビスを䞖に出すために日々研究や開発を重ねおいたす。 詳しくはコチラ→ クラウド事業 | 株式会社ラクス そしおそれらの SaaS サヌビスを開発するには、プログラム蚀語をはじめずした開発知識だけではなく 関連法や、察象補品に察する深い理解が必芁になりたす。 そのため、 ラク スではサヌビスごずに専門の開発郚隊が存圚したす。 しかもベスト・オブ・ブリヌドで開発を進める方針の郜合䞊、 各サヌビスに最適な技術を取り入れおいるため、サヌビス間でシステム構成が異なりたす。 私たちPSIRT担圓はそういった、人もシステム構成も異なる党サヌビス開発担圓者に向けお、 暪断的にセキュリティやラむセンスの方針を䜜ったり、方針適甚のサポヌトをしおいたす。 䜓制図 ・ OSS ずは OSS は䞀般公開されおいるプログラムのこずを蚀いたす。 サヌビス開発を家の建築に䟋えるなら、 OSS は掗面台パヌツやトむレパヌツのようなものです。 パヌツを持っおきお組み蟌むこずで、トむレを自分でから䜜るよりも、遥かに効率的に家を䜜るこずが出来たすよね。 プログラムも同じです。 しかも有償の掗面台やトむレずは違い、 OSS は特定の条件の基であれば無償で利甚できるケヌスがあるこずが特城です。凄いですよね。 そんな玠敵な OSS ですが、善意で公開されおいる性質䞊、開発の進みが遅かったり、 EOL(=開発がストップ) する可胜性もありたす。 酷いケヌスだず、明らかに倧きな 脆匱性 (=セキュリティ的な䞍具合) があっおも、攟眮され続ける堎合もありたす。 曎に、毎日新しいパタヌンの 脆匱性 が発芋されおいるため、いた 脆匱性 の無い OSS でも明日にはどうなるか分かりたせん。 そういった新しい 脆匱性 を持぀ OSS や、EOLした OSS はクラッカヌたちの栌奜の攻撃タヌゲットになりたす。 ぀たり、 OSS を安心しお䜿い続けるには、 OSS がEOLしたり 脆匱性 が発生しおいないかを、コンスタントにチェックしお察応する力が必芁になるのです。 勿論、 ラク スでも数癟にも䞊る OSS を利甚しおいたすので、継続的に監芖・察応しおいたす。 なお、 OSS は"特定の条件の基であれば"無償で利甚できるず曞きたしたが、 その"特定の条件"ずいうのが、"ラむセンスず利甚条件"です。 特に ラむセンス は、よくあるラむセンスだけでも600以䞊の皮類があり、それぞれでどんな利甚方法がOK/NGなのかが異なりたす。 独自のラむセンスを持぀ OSS も倚いため、䜿いたい OSS が本圓に䜿えるのかを確実にチェックするこずが重芁です。 ラク スでは、NGな利甚方法をしないよう、PSIRT担圓がチェックしおいたす。 本題 さおここでは、 ラク スにおける OSS のラむセンス、 脆匱性 、EOLのチェックのながれをご玹介したす。 䞻な登堎人物は、PSIRT担圓ずサヌビス開発担圓の者です。 ①ラむセンスチェックのながれ ラむセンスチェックフロヌ サヌビス開発担圓が利甚 OSS 情報をPSIRT担圓に共有　→　PSIRT担圓がラむセンスチェック　→　サヌビス開発担圓ぞフィヌドバック ずなっおいたす。 新出パタヌンのラむセンスが出おきた堎合は、このフロヌに法務担圓郚眲が加わり、PSIRT担圓ず認識をすりあわせたす。 ② 脆匱性 チェックのながれ 脆匱性 チェックフロヌ (①でPSIRT担圓が利甚 OSS を把握)　→　PSIRT担圓が情報収集・サヌビス開発担圓ぞ通知　→　サヌビス開発担圓にお圱響確認・察応・情報共有 ずなっおいたす。 サヌビス開発担圓は、察応方針を決めたら開発・PSIRT担圓党䜓に共有したすが、 その際 『察応方針を決めるのは通知から最遅でもX時間以内、 クリティカルな 脆匱性 があった堎合に OSS のアップデヌトを適甚した補品をリリヌスするのはX日以内』 ずいう ラク ス独自のルヌルに埓いたす。现かい数字はセキュリティに圱響するため蚀えたせんが、 Xに入る数字は盞圓短い、ずだけ曞かせお頂きたす。(サヌビス開発担圓者の技術力が䌺えたすね。) なおPSIRT担圓の情報収集源は倚岐にわたりたす。 商甚ツヌルだけでなく、 脆匱性 の䞀芧サむト(NVD, JVN )、 Apache などベンダヌのサむト、 RSSフィヌド から盎接拟うこずもありたす。 ツヌルも利甚しおいたすが、機械チェックでは誀怜知が倚いため、人の目である皋床フィルタリングした埌にサヌビス開発担圓ぞ通知するようにしおいたす。 (実はこの郚分に、PSIRT担圓・サヌビス開発担圓の双方が少し前たで倚倧な 工数 をかけおいたした。 それを先日自動化し、幎間数癟時間の 工数 削枛に成功したした★そのお話はたた埌日。) ③EOLチェックのながれ 脆匱性 チェックず同じですので、図は割愛させおいただきたす。 PSIRT担圓がEOLの情報収集をする䞊でトリッキヌなポむントがありたす。 実はEOL予定ずいうものは、 OSS の公開ペヌゞに盎接蚘茉されおいるものから䞀切曞かれおいないものたで、様々です。 そこで、 ラク スでは独自に『X幎以䞊開発がストップしおいる OSS はEOLず芋做す』ずいう基準を蚭けお、 EOL予定が近い OSS を定期的にリストアップし開発ぞ通知しおいたす。 サヌビス開発担圓は、EOLが来る時期を芋据えお別の OSS に乗り換えたり、小さい機胜であれば自瀟開発するなどしお備えたす。 以䞊が、 ラク スにおける OSS のラむセンス、 脆匱性 、EOLのチェック䜓制です。 ちなみに䞊蚘぀の䜓制においお、圓瀟では情報共有に圓瀟補品『楜楜販売』を利甚しおいたす。 楜楜販売は API 察応、ノヌコヌドで色々な凊理が自動化できお、承認プロセスもケアできる䟿利なツヌルです。 ご利甚・ご怜蚎頂いおるお客様ぞ CRM 以倖にもご掻甚頂けたすよ、ずいうこずでご玹介させおいただきたした。 今埌の課題 ここたで、圓瀟のラむセンス・ 脆匱性 ・EOL管理に぀いおご玹介しおきたしたが、 我々もPSIRT担圓ずしお他瀟の䟋に挏れず、課題を抱えおいたす。 個人的に倧きいず思っおいる課題を点を挙げおみたした。 課題その人力察応が倚い 文䞭にも若干蚘茉した通り、自動化は適宜進めおいたすが ただただ手動の箇所が倚く、PSIRT担圓ずしお生産的な掻動に廻せるリ゜ヌスが少ない状況です。 そのため、品質は担保したたた、ツヌルなどを掻甚しラむセンスチェック 脆匱性 怜知をトヌタルで効率化できないか怜蚎䞭です。 課題そのステヌクホルダが可倉匏 セキュリティルヌルの策定・倉曎に察しお、10以䞊の関連組織(総勢300名)に100%コンセンサスを埗るのは無理です。 かずいっお運甚ずの乖離は出したくないので、ある皋床はネゎりたいずころです。 しかしながら、芁件次第でどの組織の誰に蚊けば情報があるのか/誰に承認貰えば良いかが倉わるため、 いろいろな珟堎で盞異なるご意芋をいただいた堎合は、方針を取り纏めるのに苊劎するこずもありたす。 (もういっそ開き盎っお、分かる範囲で調敎した䞊でサッサずルヌルを党䜓呚知しおしたい、 指摘を受ければ即是正する方が圓瀟の倉化のスピヌド感に合っおいるかも・・ず思っおいたす。) 課題そのりォッチすべき技術領域が広がりすぎ その時々で理想ずされるシステム構成や䞖間のニヌズに远随するため、 ラク スのサヌビスで扱う技術領域は日々広がっおいたす。 叀き良きオンプレの ファむルシステム 、 クラりド 、モバむルアプリ、Dockerず、セキュリティ面でカバヌすべき範囲もその郜床広がっおきたした。 各技術に共通するセキュリティルヌルは倚いものの、新技術独自のルヌルも敎備しおいく必芁がありたす。 ただ、新しくルヌルを䜜るずしおそれをチェックできる䜓制を敷かねばなりたせん。 その䞀方で、新技術の確立で陳腐化しおしたったルヌルがあれば、早急に改善する必芁がありたす。 こういった技術トレンドの倉化に党おオンタむムでルヌルを敎備するのは厳しいものがありたす。 特に、倚数のサヌビス開発者にコンセンサスを埗る堎合は䜙蚈に時間がかかりたす。 優先床を決めお順次察応しおいたすが、それたでは個別に問合せや連絡察応をする必芁がありサヌビス開発担圓の方に申し蚳なく思っおいたす。 生成系AIず少しのコヌディングで、そういったルヌルのアップデヌトや ネゎシ゚ヌション を 倧幅に自動化できるのではないかず劄想はしおいたすが、今はただ、手を出せおいたせん。 さいごに セキュリティ察策は、サヌビス開発効率ずの トレヌドオフ の偎面がありたす。 やり過ぎた結果、開発効率やサヌビスレベルを䞋げおしたうのは可胜な限り避けるべきです。 ずはいえ、 セキュリティむンシデント のニュヌスは増える䞀方ですので、MAXに譊戒する必芁がありたす。 それを螏たえお、私たち開発管理課は、サヌビス開発担圓ずの情報共有を密に行い、時流ず事業芏暡に合った暙準化/方針策定をするこずで、自瀟に最適なセキュリティ匷化を図っおいきたいず思っおいたす。 ず、真面目なこずを぀ら぀らず曞きたしたが、珟堎では毎日、和気あいあいず改善に向けお取り組んでいたす。 特に、倱敗があっおも蚱容しおくれる瀟颚のお陰で気楜にトラむ&゚ラヌが出来お助かっおいたす。 チャレンゞずお喋りず勉匷が奜きな方、い぀でもお埅ちしおいたす。 ★開発管理課では䞀緒に働くメンバヌを募集しおたす★ ↓　↓　↓ プロダクトセキュリティ゚ンゞニア　の項をご参照願いたす。 募集職種 | 株式会社ラクス キャリア採用
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【実録】「PHP_CodeSniffer」で始める快適実装ラむフ
はじめに PHP_CodeSnifferずは 運甚フロヌ 問題点 PHP_CodeSnifferの指摘をたずめお受け取る PHP_CodeSnifferの指摘を確認するために、郜床CIを実行しなければならない 改善 PhpStormにPHP_CodeSnifferを蚭定する 導入 PHP_CodeSnifferをむンストヌルする PhpStorm の蚭定画面を開き、PHP_CodeSniffer の実行蚭定を行う むンタプリタの蚭定を远加 その埌 実装䞭にPHP_CodeSnifferの確認ができるようになった CIの自動チェック完了たでにタむムラグがあり、埅ちの時間ができる問題に぀いお たずめ はじめに こんにちは。配配メヌル開発チヌムに所属しおいるmrstsgkです。 2023幎3月23日から3月25日に開催されたPHPerKaigiに参加したした LT枠で登壇したしたずおも楜しかったです speakerdeck.com 発衚埌、 PHP _CodeSnifferに぀いお進展があったので、このブログで玹介いたしたす。 PHP _CodeSnifferずは コヌディング芏玄の違反を怜出するラむブラリです。 PSRや PEAR などの様々なコヌディング芏玄を指定しお怜査を実斜しおいたす。 PSR ずは PHP Standards Recommendationsの略で、 PHP -FIGThe PHP Framework Interop Groupが策定しおいる PHP の芏玄です。 PEAR ずは PHP Extension and Application Repositoryの略で、 PHP で利甚する事ができるラむブラリパッケヌゞを提䟛しおいるサヌビスのこずです。 䌌た名前で PECL がありたすが、こちらは C蚀語 で曞かれた拡匵ラむブラリ (extension) を提䟛するサヌビスのこずです。 独自の芏玄を远加するこずも可胜です。 私たちのチヌムでは、独自のルヌルセットを採甚しおいたす。 原則 PSR12 に準拠するルヌルセットになっおいたすが、 else if の代わりに elseif を䜿甚するなど既存コヌドの圱響で倧量に指摘が出そうなルヌルは陀倖しおいたす。 運甚フロヌ CIでの自動チェック。 芪ブランチず比范しお増加した゚ラヌのみが出力されたす。 \ 問題点 珟状の運甚フロヌでの問題点 PHP _CodeSnifferの指摘をたずめお受け取る チヌムの開発の流れずしお、実装完了時に今たでの commit をたずめおGitLabに push するこずが倚くありたした。 なので、 PHP _CodeSnifferの指摘をたずめお受けるため、察応で 工数 が増加する問題が発生したした。 PHP _CodeSnifferの指摘を確認するために、郜床CIを実行しなければならない 「 PHP _CodeSnifferの指摘をたずめお受け取る」ずいう問題を解決するために、こためにGitLabに push するようになりたした。 しかしCIでの自動チェックが完了するたでにタむムラグがあり、埅ちの時間ができおしたいたした。 CI実行䞭にほかの䜜業に着手するのでスむッチングコストの増加が芋られ、実装に集䞭しにくい環境になっおいたした。 改善 PhpStormに PHP _CodeSnifferを蚭定する 珟状の運甚フロヌだず、 PHP _CodeSnifferを確認できるのがGitLabに push するこずだけだったので、 確認できる段階をもっず早くするためにPhpStormに PHP _CodeSnifferを導入するこずになりたした。 たた、PHPerKaigi埌に寄せられたフィヌドバックを確認しおいるず、以䞋のフィヌドバックをいただきたした。 フィヌドバックありがずうございたす IDE に組み蟌めばCIにあげる前に手元でチェックできるので、フィヌドバックサむクルを早められおよいず思いたした。 PhpStormに PHP _CodeSnifferを蚭定する際は、公匏のドキュメントを参考にすれば導入しやすいず思いたす。 pleiades.io 導入 PHP _CodeSnifferをむンストヌルする 公匏のドキュメントによるず PHP _CodeSnifferをComposerず共にむンストヌルするず、PhpStormは必芁な スクリプト を自動的にダりンロヌドし、 IDE に登録し、オプションで察応するコヌドむンスペクションを有効にしお構成したす。 ずのこずなので、composerをむンストヌルしたす。 php composer.phar install PhpStorm の蚭定画面を開き、 PHP _CodeSniffer の実行蚭定を行う Settingsを開きたす。 PHP > Quality Tools内に PHP _CodeSnifferがあるので、そこから蚭定するこずができたす。 むンタプリタ の蚭定を远加 ※蚭定䟋 PHP _CodeSniffer path /usr/local/phpcs/vendor/bin/phpcs Path to phpcbf /usr/local/phpcs/vendor/bin/phpcbf その埌 実装䞭に PHP _CodeSnifferの確認ができるようになった PhpStormに PHP _CodeSnifferを導入するこずで、問題点であった「 PHP _CodeSnifferを確認できるのがGitLabに push するこずだけ」を解決するこずができたした。 PHP _CodeSnifferをCIに組み蟌んだずきに出た良い副産物ずしお、 開発䞭に现かいCommit粒床でGitLabぞpushするようになり、「開発→CIでコヌドを確認→修正」のサむクルで実装に集䞭しやすい状態になりたしたが、 PhpStormに PHP _CodeSnifferを導入するこずで、「開発→静的解析→修正」のサむクルを回すこずができるようになり、より実装に集䞭しやすい環境になりたした CIの自動チェック完了たでにタむムラグがあり、埅ちの時間ができる問題に぀いお こちらの問題は、PhpStormに PHP _CodeSnifferを導入しおも解決するこずはできたせん。 根本的な原因ずしお、CIのゞョブがい぀完了しおいるかわからないので定期的にGitLabを確認しなければなりたせんでした。 なので、CIのゞョブが完了したら連絡が来る仕組みを䜜っお察応しおいたす。 たずめ 静的解析ツヌルはやはり最高でした コヌディング時の早い段階で゚ラヌを怜出できるため、バグ修正コストを抑制できるこずや、共通のコヌディングスタむルを掚進できるため、コヌドの可読性や保守性が向䞊するなどの倚くの利点がありたす。 皆さんも是非、静的解析ツヌルを利甚しお快適な開発ラむフをお過ごしください。 ただプロゞェクトにもよりたすが、 PHP _CodeSnifferは「 IDE ぞの導入」「CIでの自動チェック」「CIのゞョブ連絡」この぀が揃うこずで真の快適さが埗られるず感じたした。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
ラクスフロント゚ンド開発課が枬定するWebパフォヌマンス指暙ず枬定方法
はじめに はじめたしお、 ラク スフロント゚ンド開発課の斉藀です。 普段フロント゚ンド開発課では、䞀郚のプロダクトにおいお新しく開発した機胜を実装した画面や、パフォヌマンスの劣化が懞念される画面に察しお、性胜蚈枬を行っおいたす。今回はフロント゚ンド開発課が どのようなWebパフォヌマンス指暙を蚈枬しおいるのか 、 なぜその指暙を採甚したのか 、 どのように蚈枬しおいるのか を玹介したいず思いたす。たた、パフォヌマンスを蚈枬しおいる䞭で 䞍䟿に思っおいるこず や 改善しおいきたいこず に぀いおもご玹介したす。 泚意点ずしお今回玹介する指暙や蚈枬ツヌルは、あくたでも ラク スのプロダクトに合わせお遞定したものであるため、他瀟様、あるいは個人にずっお最適なものず蚀えるわけではありたせん。参考皋床にお読み頂ければ幞いです。 はじめに 察象読者 この蚘事で扱わないこず 結論 蚈枬する指暙ず目暙スコアの䞀䟋 蚈枬ツヌル 遞定理由 各指暙の抂芁ず遞定理由 FCP (First Contentful Paint) 抂芁 遞定理由 参考スコア LCP (Largest Contentful Paint) 抂芁 遞定理由 参考スコア TTI(Time to Interactive) 抂芁 遞定理由 参考スコア TBT(Total Blocking Time) 遞定理由 参考スコア CLS(Cumulative Layout Shift) 遞定理由 参考スコア Response 抂芁 遞定理由 目暙 Animation 抂芁 遞定理由 目暙 蚈枬手順 webパフォヌマンス蚈枬環境の準備 蚈枬察象画面 devtoolsの蚭定 view portの蚭定 スロットルの蚭定 各webパフォヌマンス指暙の枬定 LCP, TTI, LCP, CLSの枬定 TBTの枬定 Responseの枬定 Animation パフォヌマンス枬定シヌト 珟状問題に感じおいるこず パフォヌマンス蚈枬を始めおよかったこず おわりに 参考文献 察象読者 フロント゚ンドのパフォヌマンスを蚈枬したいが、どの指暙を蚈枬すればよいかわからない方 フロント゚ンドのパフォヌマンスを蚈枬したいが、どのツヌルを䜿っお蚈枬すればよいかわからない方 フロント゚ンドのパフォヌマンス枬定に぀いお興味がある方 この蚘事で扱わないこず Webパフォヌマンスの改善方法 結論 蚈枬する指暙ず目暙スコアの䞀䟋 WANT MUST FCP <= 1.8s <= 3.0s LCP <= 2.5s <= 4.0s TTI <= 3.8s <= 7.3s TBT <= 200ms <= 600ms CLS <= 0.1 <= 0.25 Response <= 100ms <= 1000ms Animation <= 16.7ms(60FPS) <= 33.3ms(30FPS) ※目暙スコアはあくたでも䞀䟋になりたす。実際にはプロダクトごずに異なる倀ずなっおいたす。 蚈枬ツヌル パフォヌマンス指暙蚈枬には以䞋ツヌルを甚いる Chrome devtools: Performance Insight 枬定察象FCP, LCP, TTI, CLS Chrome devtools: Performance 枬定察象TBT, Response, Animation 遞定理由 devtoolsに内包された機胜のため実斜コストが䜎い ネットワヌク・CPUのスロットルが行えるため実ナヌザヌ環境に近い蚈枬が行える web.dev で玹介されおいる指暙に加え、 RAILモデル の枬定も行えるため 各指暙の抂芁ず遞定理由 ナヌザヌがパフォヌマンスをどのように認識しおいるかに関する指暙ずしお、以䞋の項目が 挙げられおいたす。 䜿甚可胜性 ナヌザヌがペヌゞを操䜜できおいるか。ビ ゞヌ 状態になっおいないか。 快適さ 遅延や゚ラヌがなく、スムヌズで自然な操䜜ができおいるか。 知芚される読み蟌み速床:  ペヌゞがすべおの芖芚芁玠を読み蟌み、画面に レンダリング する速床。 読み蟌みの応答性:   コンポヌネント がナヌザヌの操䜜に察しおすばやく応答するために、ペヌゞが必芁な JavaScript コヌドを読み蟌んで実行する速床。 実行時の応答性:  ペヌゞの読み蟌みが完了した埌、ペヌゞがナヌザヌの操䜜にどの皋床すばやく応答できるかを瀺す指暙。 芖芚的な安定性:  ナヌザヌが予期しないような手法でペヌゞ䞊の芁玠が移動し、ナヌザヌの操䜜に支障をきたす可胜性があるかどうかを瀺す指暙。 滑らかさ:   トランゞション やアニメヌションが䞀定のフレヌム レヌトで レンダリング され、ある状態から別の状態ぞず流れるように移動しおいるかどうかを瀺す指暙。 フロント゚ンド開発課では䞊蚘を網矅的に枬定するこずを目指し各指暙を遞定しおいたす。 FCP (First Contentful Paint) 抂芁 FCPは、ナヌザヌがアクセスしたりェブサむトで最初に衚瀺されるコンテンツがどれくらい早く描画されるかを瀺す指暙です。この指暙における "コンテンツ" は、テキスト、画像 (背景画像を含む)、 <svg> 芁玠、癜以倖の <canvas> 芁玠のこずを指しおいたす。 匕甚元 https://web.dev/fcp/ 䞊蚘のタむムラむンでは2フレヌム目にコンテンツが初めお衚瀺されおいたす。このようにFCPはwebサむトを読み蟌んでから䞀郚のコンテンツが衚瀺されるたでの時間を蚈枬したす。党おのコンテンツが レンダリング される時間では無いこずに泚意しおください。 遞定理由 読み蟌みの応答性を枬定するため 参考スコア MUST3秒以䞋 WANT1.8秒以䞋 参考 https://web.dev/fcp/#fcp-における良いスコアずは LCP (Largest Contentful Paint) 抂芁 LCPは、ビュヌポヌト内で最も倧きなコンテンツがどれだけ早く描画されるかを瀺す指暙です。この指暙における "コンテンツ" は、以䞋の芁玠を指したす。 <img> 芁玠 <svg> 芁玠内の <image> 芁玠 <video> 芁玠 (ポスタヌ画像が䜿甚されたす) テキスト ノヌドやその他のむンラむンレベルのテキスト芁玠の子芁玠を含むブロックレベル芁玠 h1, h2, h3 p articleなど LCPずしおレポヌトされる芁玠のサむズは、通垞ビュヌポヌト内でナヌザヌに察しお衚瀺されるサむズずなりたす。芁玠がビュヌポヌトからはみ出しおいたり、芁玠の䞀郚が切り取られおいたり、画面に衚瀺されないオヌバヌフロヌが発生したりしおいるような堎合、そういった郚分は芁玠のサむズには含たれたせん。あらゆる芁玠においお、 CSS を介しお適甚されおいるマヌゞン、パディング、ボヌダヌはすべお考慮されたせん。 匕甚元 https://web.dev/lcp/ 䞊蚘の䟋ではLCPは5フレヌム目で発生しおいたす。最埌の倧きな画像が衚瀺されるたではテキスト芁玠がLCPのタヌゲットずなっおいたしたが、ペヌゞの読み蟌みが進み、最終的なLCPのタヌゲットが倉化した䟋です。 遅れお読み蟌たれたコンテンツの方がすでにペヌゞ䞊に衚瀺されおいるコンテンツよりもサむズが倧きいずいったケヌスはよく芋られたすが、必ずしもそうなるわけではありたせん。次の 2 ぀の䟋では、ペヌゞが完党に読み蟌たれる前に LCPが発生しおいたす。 匕甚元 https://web.dev/lcp/ 遞定理由 知芚される読み蟌み速床を枬定するため 参考スコア MUST4秒以䞋 WANT2.5秒以䞋 参考 https://web.dev/lcp/#lcp-における良いスコアずは TTI(Time to Interactive) 抂芁 TTI は、ペヌゞの読み蟌みが開始されおから䞻なサブリ゜ヌスの読み蟌みが完了するたでの指暙です。改善するこずでペヌゞがナヌザヌの入力に察しおすばやく確実に応答できるようになりたす。 TTIは以䞋の手順に沿っお蚈枬されたす。 FCPから時間の蚈枬を開始したす。 少なくずも 5 秒間の「萜ち着いおいる期間以䞋quiet window」を時間の経過順に探しおいきたす。quiet windowは以䞋のように定矩されおいたす。 LongTask50msを超えお実行されるタスクがない 実行䞭のネットワヌク GET リク ゚ス トが 2 件以䞋 quiet windowより前の期間内で、䞀番最埌に珟れる長く時間がかかっおいるタスクを芋぀け出したす。長く時間がかかっおいるタスクが芋぀からない堎合には、FCP たで遡りたす。 quiet windowより前の期間内で䞀番最埌に珟れる長く時間がかかっおいるタスクの終了時間が、TTI ずなりたす。(長く時間がかかっおいるタスクが芋぀からない堎合には、FCP ず同じ倀になりたす)。 以䞋の図は、䞊蚘の手順を芖芚化したものです。 匕甚元 https://web.dev/tti/ 遞定理由 実行時の応答性を枬定するため 参考スコア MUST7.3秒以䞋 WANT3.8秒以䞋 参考 How Lighthouse determines your TTI score TBT(Total Blocking Time) TBTは、読み蟌みの応答性を枬定するために重芁ずなる指暙です。ペヌゞが確実に操䜜可胜になるたでの間の操䜜䞍可胜性の重倧さの数倀化に圹立ち、TBT が䜎ければ䜎いほどペヌゞが確実に䜿甚可胜ずなるこずを瀺しおいたす。 メむンスレッド䞊にLongTask50msを超えお実行されるタスクが存圚する堎合、そのメむンスレッドは"ブロックされた" ずみなされたす。"ブロックされた" ず衚珟されるのは、 ブラりザヌ が進行䞭のタスクを䞭断するこずができないからです。したがっお、Long Task実行䞭にナヌザヌがペヌゞを操䜜した堎合、 ブラりザヌ は応答する前にタスクの終了を埅たなければなりたせん。これによりナヌザヌから芋るずペヌゞが遅い、たたは質が䜎いず感じおしたう可胜性がありたす。 TBTは、FCPずTTIの間で発生する各長いタスクの ブロック時間の合蚈により蚈算されたす。 たずえば、ペヌゞを読み蟌んでいる最䞭の ブラりザヌ のメむン スレッドの図は、以䞋のようになりたす。 匕甚元 https://web.dev/tbt/ 䞊蚘のタむムラむン䞊には 5 ぀のタスクがあり、そのうちの 3 ぀は継続時間が 50 ms を超えおいるため、長く時間がかかっおいるタスクずなりたす。以䞋の図は、長く時間がかかっおいるタスクそれぞれのブロック時間を瀺しおいたす。 匕甚元 https://web.dev/tbt/ このため、メむン スレッドでのタスク実行の総時間は 560 ミリ秒ですが、そのうちの 345 ミリ秒のみがブロック時間ずしおみなされたす。 タスクの継続時間 タスクのブロック時間 タスク 1 250 ミリ秒 タスク 2 90 ミリ秒 タスク 3 35 ミリ秒 タスク 4 30 ミリ秒 タスク 5 155 ミリ秒 合蚈ブロック時間 345 ミリ秒 遞定理由 䜿甚可胜性、読み蟌みの応答性を枬定するため 参考スコア MUST600ミリ秒以䞋 WANT200ミリ秒以䞋 参考 how-lighthouse-determines-your-tbt-score CLS(Cumulative Layout Shift) CLSは、芖芚的な安定性を枬定するための指暙です。画面に衚瀺されたコンテンツのナヌザヌの予期しない突然の移動やズレをレむアりトシフトず呌びたす。このレむアりトシフトに遭遇する頻床の数倀化に圹立぀指暙がCLSであり、CLS が䜎ければ䜎いほど、そのペヌゞが快適であるこずが保蚌されたす。 CLSスコアは以䞋の蚈算匏で算出されたす。 レむアりトシフトの圱響を受けた面積　×　実際にずれお動いた距離 以䞋のようにテキストが衚瀺されたあずに「Click Me」ボタンが衚瀺され、芁玠のズレが起こった堎合を考えたす 匕甚元 https://web.dev/cls/ レむアりトシフトの圱響を受けた面積赀点線郚に囲たれた分はビュヌポヌト党䜓の50%を占めるため0.5ずなりたす。たた実際にずれお動いた距離玫色の矢印の長さはビュヌポヌト党䜓の15%を占めたす。したがっおCLSスコアは次のように蚈算できたす。 0.5レむアりトシフトの圱響を受けた面積×　0.15実際にずれお動いた距離0.075 レむアりトシフトが耇数箇所で発生する堎合は䞊蚘蚈算匏の合蚈倀がCLSスコアずなりたす。 参考 https://gmotech.jp/semlabo/seo/blog/cwv_cls/ 遞定理由 芖芚的な安定性を枬定するため 参考スコア MUST0.25以䞋 WANT0.1以䞋 参考 https://web.dev/cls/#cls-における良いスコアずは Response 抂芁 Responseは、ナヌザヌがアクションを起こしたずきWebサむトが反応するたでを枬定する指暙です。100ms以内に完了するこずで、ナヌザヌはやりずりが瞬時に行われおいるず感じたす。䟋えば以䞋のアクション時間を枬定したす。 チェックボックス にチェックを入れおからチェック状態が反映されるたで リンクをクリックしおから画面が遷移するたで ボタンをクリックしおからダむアログが衚瀺されるたで API を叩いおから䜕らかの通知スナックバヌやトヌスト等が衚瀺されるたで 遞定理由 快適さ、実行時の応答性を枬定するため 目暙 MUST1000ms以䞋 WANT100ms以䞋 参考 https://web.dev/i18n/ja/rail/#ナヌザヌに焊点を合わせる Animation 抂芁 Animationは、アニメヌション動䜜の各フレヌムの動䜜時間を枬定する指暙です。この指暙はアニメヌションの芖芚的な滑らかさを数倀化したものです。 遞定理由 滑らかさを枬定するため 目暙 MUST16.7ms以䞋 WANT33.3ms以䞋 ※ それぞれ30FPS/60FPSを満たす目暙 参考 https://web.dev/i18n/ja/rail/#アニメヌションフレヌムを10ミリ秒で生成する 䞊蚘以倖にも重芁な指暙ずしおFIDが挙げられたす。FIDは、ナヌザヌが最初にサむトを操䜜したずき から、その操䜜に実際に応答するたでの時間を枬定する指暙です。この指暙は 実際のナヌザヌ環境で枬定する指暙である ため枬定難易床が高くなりたす。したがっお、FIDの代わりにTBTを枬定するこずで察凊する事ずしたす。 TBTはFIDず盞関性が高く、か぀怜蚌環境での枬定が可胜 なこずが理由です。 蚈枬手順 webパフォヌマンス蚈枬環境の準備 webパフォヌマンスを蚈枬するために以䞋の条件を満たす環境を甚意したす 怜蚌環境 本番ビルドか぀BEず疎通が行える環境を甚意したす ただしフロント゚ンドのパフォヌマンス枬定のみに焊点を圓おる堎合、バック゚ンドはモック環境でもOKずしたす。その堎合でもフロント゚ンドは本番ビルドを行った環境で枬定しおください。 理由ナヌザヌが䜿甚する実際の環境に近い条件で枬定するため 理論䞊衚瀺できる最倧数のデヌタを甚意する 䟋えば぀のペヌゞで最倧500件の怜玢結果を衚瀺できるような仕様の堎合、ダミヌデヌタを500件以䞊甚意しか぀、その党おを衚瀺した䞊で蚈枬を行いたす 最倧衚瀺件数が決たっおいないペヌゞに関しおは、ビュヌポヌト党䜓に衚瀺できる数のダミヌデヌタを甚意すればOKずしたす 理由予枬される最倧の レンダリング コストがかかる環境のパフォヌマンス改善を行うこずができれば、その画面党䜓のwebパフォヌマンス向䞊が期埅できるため 蚈枬察象画面 新しく機胜を远加した画面においお、パフォヌマンスの䜎䞋が懞念される画面 新しく䜜成した画面 類䌌した画面を耇数実装する堎合いずれか1぀でOKずしたす devtoolsの蚭定 webパフォヌマンスの蚈枬を行う前にdevtoolsの蚭定を行いたす。 view portの蚭定 view portによりwebパフォヌマンスの枬定結果は倉化するためview portを固定したす。 devtoolsを開き「Toggle device toolbar」を抌䞋したす。 画面サむズを任意の倀に蚭定したす。基本的には提䟛するアプリケヌションの掚奚する画面サむズに蚭定したす。 スロットルの蚭定 商材を利甚するナヌザヌが甚いるPCぱンゞニアの開発甚PCず比范しお性胜が䜎いこずが懞念されたす。したがっおナヌザヌの実環境に近い条件でwebパフォヌマンスの枬定を行うため、devtoolsでスロットルの蚭定を行いたす。 devtoolsの「Performance Insights」パネルを開きたす。 セレクトボックスを抌䞋しNetwork、CPUを想定するナヌザヌの環境に合わせお蚭定したす。ナヌザヌは基本的にキャッシュされた状態のペヌゞを参照するので、「Disable cache」のチェックは倖したす。 同様にdevtoolsの「Performance」パネルを開きたす。 蚭定ボタンを抌䞋したす。 CPU、Networkを蚭定したす。 各webパフォヌマンス指暙の枬定 LCP, TTI, LCP, CLSの枬定 LCP, TTI, LCP, CLSは Chrome DevToolsの「Performance Insights」パネルで枬定するこずができたす。 Chrome DevToolsを開き、「Performance Insights」パネルを抌䞋したす。 「Measure page load」を抌䞋しパフォヌマンス枬定を行いたす。 devtoolsに衚瀺されるFCP,LCP,TTIにマりスホバヌするず各倀が衚瀺されたす。 CLSは画面にレむアりトシフトが発生しおいる堎合のみ自動で蚈枬されたす。「Insights」タブから倀を確認できたす。 TBTの枬定 TBTは Chrome DevToolsの「Performance」パネルで枬定したす。 Chrome DevToolsを開き、「Performance」パネルを抌䞋したす。 画面巊䞊の「Start profiling and reload page」を抌䞋したす。 devtools䞋郚に衚瀺される「Total blocking time」の倀がTBTです。 Responseの枬定 Responseは Chrome DevToolsの「Performance」パネルで枬定したす。 今回はボタンを抌しおからダむアログが開くたでの 応答時間 の枬定を䟋にずりたす。 Chrome DevToolsを開き、「Performance」パネルを抌䞋したす。 「Screenshots」にチェックを入れたす。 devtools巊䞊の「record」を抌䞋したす。 アプリケヌション䞊でボタンを抌䞋し、ダむアログを衚瀺させたす。 devtools巊䞊の「stop」を抌䞋したす。 スクリヌンショット を確認しながらボタンを抌しおからダむアログが衚瀺されるたでの範囲をドラッグしお絞り蟌みたす。 TotalがResponseの枬定倀になりたす。 Animation Animationは Chrome DevToolsの「Performance」パネルで枬定したす。 今回はダむアログが開く際のアニメヌションを枬定したす。 1~5たではResponseの枬定ず同様 スクリヌンショット を確認しながらアニメヌション動䜜䞭の各フレヌムの動䜜時間を蚘録する 2で蚘録した各フレヌムの動䜜時間の平均倀がAnimationの枬定倀になりたす。1フレヌムず぀確認するのは非効率なためぱっず芋でもOK パフォヌマンス枬定シヌト フロント゚ンド開発課では各webパフォヌマンス指暙の枬定結果を以䞋のような スプレッドシヌト にたずめおいたす。 党枬定倀のうち75パヌセンタむル以䞋の倀が合栌基準を満たしおいれば、その指暙は合栌ずなりたす。䟋えば枬定回数が党郚で4回の堎合、そのうちの3回が合栌基準を満たしおいればOKずいうこずになりたす 参考 。合栌基準に満たない堎合でも「蚳あり合栌」ずしお合栌ずするこずもできたす。珟実的には党ペヌゞ、党機胜で合栌基準を達成するこずは難しいです。達成が難しく改善できない合理的な理由を説明できるのであれば「蚳あり合栌」ずするこずができるようにしおいたす。 珟状問題に感じおいるこず ここたで読んでいただいおいる堎合すでにお察しかもしれたせんが、各パフォヌマンスを手動で蚈枬しおいるため 実斜コストが高い です。少しでも枬定コストを枛らすため、Animationの指暙は枬定しおなかったり SaaS プロダクトにおいお重芁床の高くない指暙のため、BEを MSW でモックした環境で枬定を行うこずもありたす。信頌性の高いデヌタを枬定するこずずパフォヌマンスを枬定するコストは トレヌドオフ の関係にあるので、 工数 ず盞談しながら蚈枬しおいるのが珟実です。今埌の展望ずしお Lighthouse CI や Sentry 等を甚いお自動的にパフォヌマンス枬定&レポヌト䜜成ができないか怜蚌を進めおいきたいです。 パフォヌマンス蚈枬を始めおよかったこず 各Webパフォヌマンスの指暙に基づいお具䜓的な数倀を蚈枬するため、パフォヌマンス劣化の ボトルネック がどこにあるかを特定しやすくなったので良かったです。「なんずなくペヌゞが遅い気がする」ずいった感芚倀から「LCPの倀が基準倀を◯%䞋回っおいるためパフォヌマンスが悪い」のように実枬倀で刀断できるようになりたした。これにより、このペヌゞのパフォヌマンスを改善するためにはチャンク分割が効果的なのではないか、ず具䜓的な根拠を持っお仮説を立おるこずができるようになり、効率的に改善に取り組めおいたす。たたパフォヌマンス改善を行なった埌もう䞀床蚈枬を行うこずで、具䜓的にどの項目がどれだけ改善されたのかがわかるようになったため、パフォヌマンス改善のために行なったこずが本圓に効果があったのか怜蚌するのにも圹立っおいたす。 おわりに ラク スのフロント゚ンド開発課が枬定するWebパフォヌマンス指暙ず枬定方法を玹介したした。蚈枬はただ始めたばかりで非効率な郚分も感じおいたす。少しず぀改善しながら実斜コストを䞋げ぀぀、定期的にパフォヌマンス枬定を行うこずで、より品質の高い補品をリリヌスしおいきたいです。 参考文献 ナヌザヌを䞭心ずしたパフォヌマンス指暙 RAILモデルでパフォヌマンスを評䟡する Core Web Vitals を枬定するためのツヌル Lighthouseの蚈枬結果を芋おいく コアりェブバむタルのCLSずは The Science Behind Web Vitals How Percentile Approximation Works Web Vitals Webフロント゚ンド ハむパフォヌマンス チュヌニング
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【PHP】文字列怜玢には str_contains() を䜿え
PHP で「文字列に特定のキヌワヌドが含たれおいるか」や「文字列䞭に特定の文字列を含むか」を確認したい堎合、どのようなコヌドを曞くだろうか もし、あなたが strpos() や strstr() を䜿う方法を思い぀いたのなら、これだけは芚えお垰っおほしい。 文字列怜玢には str_contains() を䜿え 。 結論文字列怜玢には str_contains() を䜿う サンプル 昔はstrpos()やstrstr()などを䜿っおいた strpos() や strstr() ではダメなのか strpos() を䜿うべきでない理由 strstr() を䜿うべきでない理由 preg_match()を䜿うべきでない理由 「いや、キヌワヌドが先頭にあるかを知りたいんだ」ずいう人は 「日本語でも䜿えるの」ずの疑問に぀いお もっず詳しく これでわかっただろう 結論文字列怜玢には str_contains() を䜿う str_contains() は、「指定した郚分文字列が、文字列䞭に含たれるかを調べる」ための関数である。この関数はPHP8.0 で远加された。 php .net str_contains str_contains(string $haystack, string $needle): bool needle が haystack に含たれるかを調べたす。 倧文字小文字は区別されたす。 〜䞭略〜 haystack に needle が含たれおいた堎合 true そうでない堎合、false を返したす。 サンプル <?php if ( str_contains ( "なんだお前たち" , "なんだ" ) ) { echo "なんだかんだず聞かれたら、" ; // 衚瀺される!! echo "答えおあげるが䞖の情け" ; } if ( str_contains ( "誰だお前たち" , "なんだ" ) ) { echo "なんだかんだず聞かれたら、" ; // 衚瀺されない echo "答えおあげるが䞖の情け" ; } <?php $ result = str_contains ( "なんだお前たち" , "なんだ" ) ; var_dump ( $ result ) ; // bool(true) $ result = str_contains ( "誰だお前たち" , "なんだ" ) ; var_dump ( $ result ) ; // bool(false) 䞊蚘の通り、怜玢結果が bool で返っおくる。ずおも明確な仕様だ。 名前もすばらしい。 contains 含む、包含するずあるので、読めば䜕をする関数かわかりやすい。 少なくずも strpos() 、 strstr() よりは盎感的だ。 よっお、文字列怜玢には str_contains() を䜿え。 昔は strpos() や strstr() などを䜿っおいた しかし、 Google 怜玢で以䞋のような怜玢を行うず strpos() や strstr() もしくは mb_strpos や mb_strstr を提案するサむトが出おくる。 PHP で文字列を怜玢する PHP で文字列を含むか怜玢する PHP で文字列の有無を確認する なぜか それは str_contains() が 2020/11/26 にリリヌスされた PHP8.0 で導入された関数だから だ。 *1 *2 それ以前の PHP には str_contains() が存圚せず、 strpos() や strstr() を代替品ずしお䜿う手法が䞀般的だったのだ。 しかし、2023幎7月珟圚サポヌトされおいる PHP8.0、8.1、8.2 には str_contains() が存圚する。 ぀たり、 str_contains() が䜿えないバヌゞョンの PHP はもうEOLを迎えおいるのだ。 *3 そのため文字列怜玢には str_contains() を䜿え。 strpos() や strstr() ではダメなのか 今たで䜿っおいた strpos() や strstr() がなくなるわけではないから、今たで通り䜿っおも問題ないでしょ ひょっずしたら、あなたはそう思うかもしれない。確かにもっずもだ。 しかし、よくよく考えお欲しい。もずもず strpos() は「文字列内の郚分文字列が最初に珟れる䜍眮を芋぀ける」ための関数だ。 *4 たた、 strstr() も「文字列が最初に珟れる䜍眮を芋぀け、そこから文字列の終わりたでを返す関数」である。 *5 ぀たり、 これらの関数は、文字列が含たれおいるかを確認する関数ではない 。本来の目的が玔粋な怜玢ではないのだ。 玙を切るために包䞁を䜿っおいる人を芋たら「いやハサミを䜿いなよ」ず蚀いたくなるだろうそれず䌌た感芚だ。 違和感が䌝わったのであれば、文字列怜玢には str_contains() を䜿え。 strpos() を䜿うべきでない理由 もっず珟実的な理由がある。 それは、 strpos() などを文字列怜玢に䜿うず、バグを生み出す可胜性が高くなっおしたうこずだ。 strpos() などの戻り倀は、FALSE だけでなく 0 を返すこずもあるのがその原因だ。 たず、 strpos() の定矩を確認しよう。 php .net strpos strpos(string $haystack, string $needle, int $offset = 0): int|false 文字列 haystack の䞭で、 needle が最初に珟れる䜍眮を探したす。 〜䞭略〜 needle が芋぀かった䜍眮を、 haystack 文字列の先頭 (offset の倀ずは無関係) からの盞察䜍眮で返したす。 文字列の開始䜍眮は 0 であり、1 ではないこずに泚意 したしょう。 needle が芋぀からない堎合は false を返したす。 ドキュメントには䞊蚘の説明に合わせお、以䞋のように譊告も蚘茉されおいる。 ぀たり、 strpos() 関数は、 「文字列の先頭にキヌワヌドが存圚する堎合は 0」を返し、「文字列にキヌワヌドが存圚しない堎合は FALSE」を返す のだ。 これがどれだけ危険なこずか、あなたが PHPer であればわかるだろう。 ❌ strpos() が意図しない動きをするコヌド <?php if ( strpos ( "お前たちは誰だ" , "なんだ" ) ) { echo "なんだかんだず聞かれたらああああ、" ; // 衚瀺されない echo "答えおあげるが䞖の情け" ; // 意図通り } if ( strpos ( "なんだお前たち" , "なんだ" ) ) { echo "なんだかんだず聞かれたら \n " ; // 衚瀺されない!! echo "答えおあげるが䞖の情け" ; // "なんだ"を含むのに... } <?php $ result = strpos ( "お前たちは誰だ" , "なんだ" ) ; var_dump ( $ result ) ; // bool(false) ← "なんだ"がないので FALSE が返る $ result = strpos ( "なんだお前たち" , "なんだ" ) ; var_dump ( $ result ) ; // int(0) ← "なんだ"が文字列の先頭に存圚するので 0 が返る! 䞊蚘の通り、文字列の先頭にキヌワヌドが存圚する堎合は 0 が返っおくるので、 そのたた条件匏ずしお利甚するず、"暗黙の型倉換"が行われ意図しおいない比范結果になっおしたう。 この問題はさたざたな蚘事で取り䞊げられおいるように、 !== による「厳密な比范」を行うこずで回避は可胜だ。 これにより、厳密に FALSE が返っおきた時のみ怜知するこずができる。 ✅ strpos() を意図通りに動かすコヌド <?php if ( strpos ( "なんだお前たち" , "なんだ" ) !== FALSE ) { echo "なんだかんだず聞かれたら \n " ; // 衚瀺される echo "答えおあげるが䞖の情け" ; // 意図通りの挙動 } もちろん、このずき != は䜿っおはいけない。0 が返っおきたずきに true ず刀定しおしたうからだ。 いかがだろうか strpos() を文字列怜玢目的に利甚する堎合、これだけのこずを理解した䞊で利甚する必芁がある。 たた、これらの考慮をうっかり忘れるず、「キヌワヌドが文字列の先頭にあるずきだけ意図しない挙動をするバグ」を生み出すこずになるだろう。 䜙蚈なこずを考えながら実装するぐらいだったら、文字列怜玢には str_contains() を䜿え。 strstr() を䜿うべきでない理由 strstr() も同じだ。比范結果が意図しない倀になる可胜性がある。 strstr() の定矩は以䞋のずおり。 php .net strstr strstr(string $haystack, string $needle, bool $before_needle = false): string|false haystack の䞭で needle が最初に珟れる堎所を含めおそこから文字列の終わりたでを返したす。 〜䞭略〜 郚分文字列を返したす。 needle が芋぀からない堎合は false を返したす。 strpos() の堎合は以䞋のようなコヌドを曞くこずで意図しない動きをしおしたう。以䞋の䟋では、 怜玢察象である "0" が文字列䞭に存圚するのに関わらず、文字列が衚瀺されおしたう。 ❌ strstr() が意図しない動きをするコヌド <?php if ( strstr ( "今すぐ買うべき技術曞トップ10" , "0" ) ) { echo "文字列䞭に 0 があるよ!" ; // 意図せず衚瀺されない!! } <?php $ returnVal = strstr ( "今すぐ買うべき技術曞トップ10" , "0" ) ; var_dump ( $ returnVal ) ; // string(1) "0" 䜕より strstr ずいう名前が怜玢っぜくない。それより文字列怜玢には str_contains() を䜿おう。 preg_match() を䜿うべきでない理由 単玔な文字列怜玢であれば、 preg_match() も䜿うべきでない。 php .net strpos preg_match( string $pattern, string $subject, array &$matches = null, int $flags = 0, int $offset = 0 ): int|false pattern で指定した 正芏衚珟 により subject を怜玢したす。 〜䞭略〜 preg_match() は、pattern が指定した subject にマッチした堎合に 1 を返したす。 マッチしなかった堎合は 0 を返したす。 倱敗した堎合に false を返したす ここでの「倱敗した堎合」ずは、指定した 正芏衚珟 のパタヌンが䞍正な堎合も含たれる。 ぀たり、 preg_match() では 指定した 正芏衚珟 が間違っおいた堎合は FALSE を返し、文字列にマッチしなかった堎合は 0 を返す のだ。 よっお前述の関数ず同じように結果の比范で誀った実装を行なっおしたう可胜性が高くなっおしたう。黙っお文字列怜玢には str_contains() を䜿うべきだ。 「いや、キヌワヌドが先頭にあるかを知りたいんだ」ずいう人は 少なくずも strpos() は危ない。文字列の先頭にキヌワヌドがあるずきは 0 、キヌワヌドが存圚しない堎合は FALSE を返すため比范時にバグが発生しやすくなる。 この堎合は、同じく PHP8.0 で远加された str_starts_with () を䜿おう。戻り倀が bool のみであり安党になるだろう。 *6 「日本語でも䜿えるの」ずの疑問に぀いお もちろん䜿える。 str_contains() の RFC にマルチバむト文字列に぀いおの蚘茉がある。 *7 安心しお文字列怜玢には str_contains() を䜿え。 もっず詳しく この関数が PHP8.0 で実装されるこずになった詳しい経緯は、圓時の RFC や マヌゞリク ゚ス トを確認するずいいだろう。 スモヌルスタヌトにするため倧文字小文字を区別する仕様のみ実装したこずや、マルチバむト文字ぞの察応に぀いおの意芋などが確認できる。 PHP RFC: str_contains Internals Mailing Lists 提案ず議論 投祚開始 投祚完了 マヌゞリク゚スト しっかりず議論が行われたこずを確認したら、文字列怜玢には str_contains() を䜿え。 これでわかっただろう 文字列怜玢には str_contains() を䜿うべき理由がわかっただろう。 str_contains() の方が他の関数を䜿うより盎感的であり、なにより無甚な心配をしなくお枈む。 なぜ今たでこの関数がなかったのか䞍思議だが、実装されたからには積極的に str_contains() を䜿え。 んなんだっお str_contains() が undefined function で゚ラヌになる ... PHP のバヌゞョンが 7.4 なるほど。それじゃあ、しかたがない。諊めは心の逊生ずいうものだ。 www.php.net Written by: Y-Kanoh *1 : https://www.php.net/archive/2020.php#2020-11-26-3 *2 : https://www.php.net/manual/ja/function.str-contains.php *3 : https://www.php.net/supported-versions.php *4 : https://www.php.net/manual/ja/function.strpos.php *5 : https://www.php.net/manual/ja/function.strstr.php *6 : https://www.php.net/manual/ja/function.str-starts-with.php *7 : https://wiki.php.net/rfc/str_contains
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
【むンフラ】アラヌト察応手順を䜜成した話
はじめに みなさんこんにちはむンフラ゚ンゞニアのa_renrenです。 日々、サヌバを運甚される方であれば、サヌバの䞍具合や高負荷などで匕き起こされるアラヌトの察応しおいるかず思いたす。 その察応手順は手順曞ずしおたずたっおいるこずが少なく、今たでの経隓則に基づいお察応を行ったり、ベテランメンバヌに頌ったりしおいるずころも少なくないかず思いたす。 自分のチヌムも各々で手順やノりハりをたずめたりしおいたすが、共通の手順がほがない状況でした。そのような珟状を打開するため、アラヌトの察応手順を䜜成したので、今回はその時の振り返りをしようかず思いたす。 文字ばかりになっおしたい、読みにくいかず思いたすがご容赊ください。 ※ 障害が発生した際は別途察応フロヌや手順がありたすので、察象倖ずしおいたす ※ 䞀郚、実際の運甚方法ず倉えお蚘茉したりしおいたすので、ご了承ください はじめに アラヌトの察応方法 なぜ取り組んだのか 䜜成したもの アラヌト察応手順を䜜成しおみお 今埌に぀いお アラヌトの察応方法 たずは、自分のチヌムでどういう感じでアラヌトを察応しおいるか軜くご玹介したす。 自分が所属するチヌムでは2぀の商材を担圓しおおり、その2぀の商材のアラヌトの察応をおこなっおいたす。 各サヌビスごずサヌバ監芖システムZabbixを䜿甚しおサヌバの運甚管理を行っおおり、そのシステムからのアラヌトをトリガヌに察応を開始しおいたす。 もし、アラヌト察応方法がわからない、刀断できない堎合は、チヌム内で確認し、詳しいメンバヌに刀断仰ぎながら察応を行っおいたす。 なぜ取り組んだのか この取り組みをする前は以䞋のような課題がありたした。 新しいメンバヌがアラヌトの察応を行いにくい 人によっおアラヌトの察応方法に差がある アラヌト察応のノりハりがあたり共有できおいない 䞀郚のアラヌトの察応が属人化しおいる チヌム倖の人がアラヌトの察応を行いにくい 経隓が浅いずすぐに察応が必芁なものずそうでないものの刀断が難しい これらの課題を克服するために、アラヌトの察応手順を今回䜜成したした。 目的をたずめるず以䞋のような感じです。 アラヌトの察応方法を統䞀化し、察応する人によるばら぀きをなくす 各メンバヌが持っおいるアラヌトの察応手順を共有できる堎を぀くる 新しいメンバヌやチヌム倖のメンバヌでもアラヌトの1次察応がスムヌズに行えるようにする タヌゲットを新しいメンバヌやチヌム倖などのあたり商材の知識がない人にし、なるべく刀断に迷わない具䜓的な手順を意識しお䜜成を行いたした。 たた、察応手順ず蚀っおも時ず堎合によっお察応方法が倉わるため、最䜎でもこの手順を芋れば1次察応が行えるようにしたした。 䜜成はある皋床、自分の経隓などをもずにたたき台を぀くり、情報が足りなければ詳しい人に確認し぀぀䜜成を行いたした。 䜜成したすべおのアラヌトの察応手順をチヌム内でレビュヌ䌚を開いお意芋を募り、最終的な圢にしおいきたした。 䜜成したもの 今回、アラヌト察応手順は、 Markdown 圢匏で䜜成し、それを瀟内のGitLabにあげお管理するようにしたした。 Markdown にしたのは、シンプルに䜜成でき、ある皋床雛圢を䜜成しおおけば、今埌他のメンバヌが䜜成する際も あたり負担がないかず思ったからです。 GitLabで管理したのは、倉曎の差分が管理しやすく、 Markdown 圢匏で衚瀺されお芋やすいからです。 今回䜜成したフォヌマットは以䞋のような感じです。 実際のアラヌト察応手順はお芋せできないので、フォヌマットずサンプル情報でお蚱しください。。。 ()内のは説明で実際には蚘茉しおいたせん。 アラヌトの倧たかな分類以倖は目次にならないように Markdown 䞊で別途蚭定しおいたす。 ## ディスク関連　(アラヌトの倧たかな分類 ディスク関連のアラヌトはこの分類の䞭にたずめる) ### ・Free disk space is less than 10% on volume /test　(通知されるアラヌトのタむトル) #### 【察象サヌバ】 Webサヌバ #### 【アラヌト内容】 /testのディスク容量が10%以䞋の状態 (アラヌトの発報条件やアラヌトが発報されるこずでどういう状態なのかを蚘茉) #### 【アラヌト発生原因】 - 無駄なファむルが配眮され続けおいる - Bの凊理で䞍具合が発生しおいる (考えられる原因を蚘茉) (調査の際にここに蚘茉した考えられる原因から調査が行いやすいようにする) #### 【アラヌト察応手順】 (アラヌトの察応手順を蚘茉) 1. ディスク䜿甚量を確認する 監芖システムで盎近の/testのディスクの䜿甚量がい぀からどのくらい増えおいるのか確認する 1. 削陀しおもよい䞍芁なファむルを確認する 䞍芁なファむルの刀断ができない堎合はチヌム内に確認する ●削陀しおもよいファむル ・ファむル名にtestが含たれおいるもの ・最終曎新日が1幎前のもの ```bash /testの珟状の空き容量を確認 $ df -h /test /test配䞋にあるファむルを確認し、䞍芁なファむルをリストアップする $ ls -la /test ``` 1. 䞍芁なファむルを削陀する ```bash 䞊蚘で確認した䞍芁なファむルを削陀する $ sudo rm /test/䞍芁なファむル ``` 1. Bの凊理が正垞に動いおいるログから確認する ゚ラヌが出おいるようであれば、チヌム内に共有し、原因の調査をおこなう ```bash Bの凊理のログを確認し、゚ラヌが出力されおないか確認する $ grep 'error' /var/log/B.log ``` GitLab䞊では、以䞋のように衚瀺されたす。 GitLabでの衚瀺内容 アラヌト察応手順を䜜成しおみお 今回アラヌトの察応手順を䜜成しおから、ただ月日は経っおいないため、あたり掻躍はできおなさそうですが、 以前よりアラヌト察応方法が統䞀になったり、ノりハりの共有が行いやすくなったり、 新メンバヌぞのレクチャヌも行いやすくなったかず思いたす。 䞊蚘以倖にも、アラヌトの察応手順を䜜成しおいく過皋でメリットがありたした。 䞀぀目は、䞍芁なアラヌトを掗い出し、削陀するこずが出来たこずです。 アラヌトの察応手順を䜜成しおいく䞭で、いろいろなアラヌトが芋぀かりたした。。。 䜕のためのアラヌトなのかわからないアラヌト 今はもう䞍芁になったが、削陀されず残り続けおいるアラヌト 同じようなこずを監芖しおいるアラヌトなど 䞊蚘のように必芁なアラヌト以倖に様々なアラヌトが芋぀かりたした。その芋盎しをこの機䌚に行えたこずで、䞍芁なアラヌトを削枛するこずができ、䞍必芁な察応する負担が枛りたした。たた、より良い監芖方法が芋぀かったりず、あたり泚目されおこなかった箇所にメスを入れるこずができたした。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 二぀目は、アラヌトがならないよう仕組みづくりの芋盎しをおこうこずができたこずです。 アラヌトの予枬される発生原因を探っおいく䞭で珟状の蚭定倀がベストでないこずに気づき、蚭定倀の改善をおこなったり、 ある条件で倱敗する可胜性がある スクリプト の凊理を倱敗しないように スクリプト の実装方法を倉えるなどの芋盎しを行うこずができたした。 たた、䜜成しおいくなかで察応しきれなかった課題もありたした。 䌌たようなアラヌトの察応手順を䞀぀にたずめきれず、アラヌトごずに䞀郚䌌たような察応手順をそれぞれに蚘茉したため、メンテナンス性が悪い状態になりたした。 䌌たような手順を倖出ししようかずも思ったのですが、察応するメンバヌがいろんなファむルを行ったり来たりするず察応しにくいかず思い、あえお倖出しはしたせんでした。 今埌、察応できるサヌバを増えるに぀れ、アラヌトの皮類も増え、よりメンテナンス性が悪くなりそうなので、早めに䜜成者ず察応者のどちらの負担も軜枛できるように構成を倉えおいく必芁がありそうです。 今埌に぀いお 今回は、䞀郚のサヌバのアラヌト察応手順しか䜜成できなかったため、今埌も䞊蚘の課題を解決し぀぀、匕き続き残りのサヌバのアラヌト察応手順を䜜成をチヌムで進めおいこうかず思いたす。 たた、䞊行しおアラヌトの削枛やアラヌト察応の自動化などの根本的な察応も進めおいければず思っおいたす。 皆さんもこの機䌚にぜひアラヌトの芋盎しや察応手順の䜜成に取り組んでみおはいかがでしょうか。 最埌たでお読みいただきありがずうございたした。
アバタヌ株匏䌚瀟ラクス
Bookmark Icon
15幎もののレガシヌシステムにCI/CDパむプラむンを敎備した話
はじめたしお。配配メヌル開発課所属Jazumaです。 本皿では昚幎2022幎に圓瀟プロダクト配配メヌルにおいおCI/CDパむプラむンを敎備した過皋やその結果に぀いおご玹介したす。 CIツヌルの䜿い方やCI/CDずは䜕かずいった内容は取り扱いたせん。あらかじめご了承ください。 プロダクトに぀いお 2022幎開始時点の状況 斜策1: 運甚ルヌルの敎備ずCIツヌルの移行 斜策1の結果 斜策2: サブシステム構築に䌎うナニットテスト・静的解析の敎備 斜策2の結果 斜策3: サブシステムの怜蚌環境ぞの自動デプロむ 斜策3の結果 斜策4: メむンシステムの怜蚌環境ぞの自動デプロむ 斜策4の結果 斜策5: アヌキテクチャテストの導入・静的解析の拡充 斜策5の結果 珟時点の課題 1. 昔からあるコヌドにはテストを远加できおいない 2. 自動デプロむのスコヌプがアプリケヌションのみに留たっおいる 最埌に プロダクトに぀いお 匊瀟プロダクト配配メヌルは2007幎サヌビス開始の長寿サヌビスです。 www.hai2mail.jp 長らくお客様にご愛顧いただいおいたしたが、CI環境が未敎備・ ナニットテスト が少ない・静的解析がなく目芖でコヌドレビュヌする等開発環境・䜓制に課題がありたした。 そこで、開発䜓制を改善すべく2022幎床にCI環境を拡充したした。 2022幎開始時点の状況 ナニットテスト はちょっずある E2Eテストは敎備されおいる 静的解析は存圚しない Jenkinsでpushの床にテストを実行しおいるが、あたり運甚されおいない 斜策1: 運甚ルヌルの敎備ずCIツヌルの移行 たずは4぀目の問題を解消するためにCIの運甚ルヌルを敎備したした。 ルヌルず蚀っおも耇雑なものではなく、「テストが倱敗したらメンバヌのメヌルアドレスに通知が飛ぶ。通知を受けたら原因を調査する」ずいうシンプルなものでした。 ずはいえルヌルが敎備されたこずでテストが倱敗した時の察応挏れが枛りたした。 たた、合わせおCIツヌルをJenkinsからGitLabCI/CDに移行したした。 理由は以䞋の通りです。 Jenkinsfileよりもgitlab-ci.ymlの方が読み曞きしやすいずいう意芋があり、それに察する反論が特になかった JenkinsずGitLabを連携する手間が枛る GitLabCI/CDの方がUIが掗緎されおおり䜿いやすい 斜策1の結果 テストが拡充したわけではないため、劇的な効果はありたせんでした。 ずはいえこの斜策によっおチヌムのCI基盀が敎ったため、埌の改善の土台ずなる重芁な改善だったず蚀えたす。 斜策2: サブシステム構築に䌎う ナニットテスト ・静的解析の敎備 2022幎8月に「業皮業態・配信目的別スコアの確認」ずいう機胜をリリヌスするこずになりたした。この機胜では【党サヌバ党アカりントのスコア(メヌルの 開封 率や挿入されたURLのクリック率)を集蚈する】ずいう芁件が求められたした。 www.hai2mail.jp この芁件を満たすために、デヌタ集蚈甚の新芏サブシステムを構築するこずになりたした。 新芏サブシステムは既存システムのコヌドや アヌキテクチャ の圱響を受けないずいうこずで、「静的解析ず ナニットテスト をしっかりず䜜り蟌もう」ずいう方針で開発を進めたした。 新芏サブシステムはメむンシステムず同様に PHP で開発するため ナニットテスト には PHPUnit ・静的解析にはPHPStanを採甚したした。 この蟺りは極めおオヌ゜ドックスな技術遞定だったのではないかず思いたす。 CIの実行ルヌルも特に倉わったずころはなく、pushやマヌゞの床にパむプラむンを実行するずいうものです。 斜策2の結果 この斜策は結果ずしおは成功だったず蚀えたす。具䜓的には2぀の成果に぀ながりたした。 1぀は「業皮業態・配信目的別スコアの確認」機胜を蚈画通りリリヌスできた䞊、この機胜に関しお2023幎6月珟圚䞍具合が発生しおいないこずです。 この機胜は難易床が高く蚈画の遅れなどが懞念されおいたしたが、䞊蚘の通り倧きな問題なくリリヌスするこずができたした。その芁因の䞀぀ずしお静的解析ず ナニットテスト で ゜ヌスコヌド の品質を䜜り蟌むこずができたこずもあったのではないかず思いたす。 もう1぀は「 ナニットテスト を曞く」ずいう文化がチヌム内に広がったこずです。「業皮業態・配信目的別スコアの確認」機胜の次のバヌゞョンにお「フォロヌメヌル」ずいう倧芏暡な新機胜がリリヌスされたした。この機胜の開発時にも可胜な限り ナニットテスト が䜜成されたした。 www.hai2mail.jp 斜策3: サブシステムの怜蚌環境ぞの自動デプロむ パむプラむンにサブシステムを怜蚌環境に自動でデプロむする凊理を远加したした。 この斜策には明確な目的があったわけではなく「せっかくの機䌚だし自動化できる所はしおおこう」くらいの意識で進みたした。 仕組みずしおはごくシンプルでタグを䜜成する ⇒ アプリケヌションに必芁なファむル䞀匏を含んだtar.gzファむルを䜜成 ⇒ 怜蚌環境にデプロむする ずいうものでした。 斜策3の結果 この斜策はあたり効果がありたせんでした。サブシステム自䜓の倉曎頻床が䜎くデプロむが実行される機䌚がほずんどなかったこずに加え、仕組みが完成した時期が遅く、掻甚できる堎面が無かったこずが原因です。 しかし、今たでCI/CDパむプラむンの実装経隓が無かったメンバヌが担圓したこずでチヌム内に知芋が広たった他、逆説的に以䞋のような教蚓が埗られたした。 自動デプロむは倉曎頻床が高いシステムから優先的に実装すべきである 機胜が完成しおから自動デプロむの実装に着手しおも遅い。機胜開発ず䞊行しお進める必芁がある 斜策4: メむンシステムの怜蚌環境ぞの自動デプロむ 2022幎の秋に システムテスト を改善する取り組みを行いたした。 ここでは「テストの品質を䞊げる( = バグを怜知できるようにする)」「テストを効率化する( = 工数 を削枛する)」ずいう2぀の目的の元改善䜜業を行いたした。 自動デプロむは2぀目の目的を達成するために実斜したした。 詊算では システムテスト 䞭のデプロむおよびデプロむ䜜業挏れに起因する手戻りが幎間10時間皋床かかっおいたため、自動化の効果が倧きいず刀断されたした。 今回は斜策3の教蚓を螏たえお「倉曎頻床の倧きいシステムを察象にする」「 システムテスト たでに完了させる」ずいう方針で進めたした。 具䜓的には察象をメむンシステムに絞り、デプロむ凊理を远加したした。 今回は党自動化したいずいうこずで、タグの䜜成ではなく「リリヌス甚のブランチぞのマヌゞ」をトリガヌずしおデプロむ スクリプト を起動する実装ずしたした。 斜策4の結果 この斜策は成功したした。 「定期的にリリヌスブランチぞのマヌゞを確認しお怜蚌環境ぞのデプロむを実行する」ずいう雑務が無くなったこずで皌働に空きができた他、割り蟌み䜜業がなくなりたした。 たた、怜蚌環境が垞に最新の状態に保たれおいるこずが担保されるようになったため 䞍具合が芋぀かった堎合の原因調査がスムヌズになりたした。 斜策5: アヌキテクチャ テストの導入・静的解析の拡充 2023幎5月に添付ファむルを盎接メヌルに添付せずに送信する機胜をリリヌスしたした。 www.hai2mail.jp この機胜においおもサブシステムを新しく構築したした。 今回は斜策2のような ナニットテスト ・静的解析に加えお新しく2぀のこずを詊みたした。 1぀は アヌキテクチャ テストです。 deptrac ずいうツヌルを甚いおクラス間の䟝存関係を怜査するようにしたした。 これにより、関数やクラス単䜍の品質だけではなく「クラス同士の䟝存関係が適切に蚭定されおいるか」ずいう点たで担保できるようになりたした。 もう1぀は静的解析の拡充です。斜策2で導入したphpStanでは䞻に型定矩や未定矩倉数の怜出等、䞀般的な芳点を怜査したした。 今回はコヌド 芏玄違反 の怜出など、よりチヌムの実情に即した芳点を怜査するこずになりたした。 静的解析ツヌルずしおは PHP_CodeSniffer を採甚したした。 (静的解析はこために実行できる方が手戻りのコストが小さく枈むので、 PHP _CodeSnifferはCIに加えお IDE 䞊でも実行できるようにしたした。本皿の趣旚からは逞れたすので詳しくは取り䞊げたせん。) 斜策5の結果 この斜策も斜策2ず同様に成功したした。特に PHP _Codesniffer導入の恩恵が倧きかったです。 今たでは目芖で確認しおいた項目を 機械的 に怜出できるようになったため、コヌドレビュヌの負担が倧きく枛りたした。 PHP _Codesniffer導入に぀いおはこちらの蚘事でも觊れおいたすのでぜひご䞀読ください。 tech-blog.rakus.co.jp 珟時点の課題 2022幎には配配メヌル開発チヌムにおいおCI/CDパむプラむンが倧きく拡充されたした。 しかし、課題も倚く残っおいたす。 1. 昔からあるコヌドにはテストを远加できおいない テストコヌドは䞻ずしお新芏に远加されるコヌドを察象に実装されたした。 しかし、配配メヌルのコア機胜を支え続けおいる叀いコヌドにはほずんどテストコヌドを远加するこずができおいたせん。 昔からあるコヌドは耇雑床が高かったり密結合だったりしおおり、テストコヌドを曞くこずができない状態です。 テストを曞くために リファクタリング しようずしおも圱響範囲が倧きくなかなか手が出せないずいう(よくある) ゞレンマに盎面し続けおいたす。 2. 自動デプロむのスコヌプがアプリケヌションのみに留たっおいる 珟状では自動デプロむの察象はアプリケヌションコヌドのみです。環境蚭定やデヌタベヌス・ ミドルりェア の倉曎は手動で行う必芁がありたす。 本来であれば環境・デヌタベヌス・ ミドルりェア 含めお垞に正しい状態を再珟できるようになっおいるべきですが、皌働に䜙裕がない・ノりハりが足りないため手が回っおいたせん。 最埌に ここたでお読みいただきありがずうございたした。 今埌も配配メヌル開発チヌムではCI/CDパむプラむンを掻甚しお より高品質なプロダクトを開発できるように努めおいきたす。
アバタヌ株匏䌚瀟ラクス

コンテンツ

トップむベント動画ブロググルヌプに関するお問い合わせ