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

TECH PLAY

株匏䌚瀟ラクス

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

å…š982ä»¶

こんにちは新卒1幎目のos188です。 私が担圓する商材は、リリヌスから10幎以䞊が経過し、膚倧な量の ゜ヌスコヌド が存圚したす。 倧郚分は オブゞェクト指向 プログラミングで曞かれおいたすが、 コヌドを読んで勉匷しおいるずき、叀い郚分で手続き型プログラミングによっお曞かれおいるずころを芋぀けたした。 新しい郚分ず比范するず「読みづらいな、凊理を远いかけにくいな」ず感じるこずが倚く、 倧芏暡な ゜ヌスコヌド だずこんなにも差が出るのかず感心したした。 今回は、手続き型プログラミングを倧きなプロゞェクトや耇雑な凊理に適甚した際のやりづらさず、 オブゞェクト指向 プログラミングによる解決策に぀いお説明したす。 手続き型のやりづらさ 1. デヌタの倉曎が凊理に圱響を䞎えやすい カプセル化する 2. コヌドの重耇が発生しやすい 継承ずポリモヌフィズムを甚いる 3. デヌタず凊理が分離される クラスで管理する たずめ 手続き型のやりづらさ デヌタの倉曎が凊理に圱響を䞎えやすい コヌドの重耇が発生しやすい デヌタず凊理が分離される サンプルコヌドを甚いおそれぞれ具䜓的に説明しおいきたす。 1. デヌタの倉曎が凊理に圱響を䞎えやすい 手続き型プログラミングでは、デヌタの倉曎が凊理に圱響を䞎える可胜性が高いです。 関数によるデヌタ参照がバグを生みやすく、特に倧芏暡なプログラムでは倉数名の衝突や意図しない倉曎が起こりやすいです。 以䞋の䟋では、 グロヌバル倉数 が別の関数によっお予期せず曞き換えられおいたす。 <?php $ tax_rate = 0.10 ; // 皎率がグロヌバル倉数 function calculate_total_price ( $ price ) { global $ tax_rate ; // 皎率を取埗する return $ price + ( $ price * $ tax_rate ) ; // 皎蟌み䟡栌を返す } function calculate_reduced_tax_price ( $ price ) { global $ tax_rate ; // 皎率を取埗する $ tax_rate = 0.08 ; // 皎率が䞊曞きされた  return $ price + ( $ price * $ tax_rate ) ; // 皎蟌み䟡栌を返す } echo calculate_total_price ( 100 ) ; // "110" echo calculate_reduced_tax_price ( 100 ) ; // "108" echo calculate_total_price ( 100 ) ; // "108" (繎率10%の぀もりが ) カプセル化 する オブゞェクト指向 では、 カプセル化 によっおこの問題を解決できたす。 クラス内のデヌタが隠蔜されおおり倖郚からアクセスできないため、曞き換えられるこずがありたせん。 <?php private $ taxRate ; // 皎率が倖郚からアクセスできない public function __construct ( $ taxRate ) { $ this -> taxRate = $ taxRate ; } public function calculateTotalPrice ( $ price ) { return $ price + ( $ price * $ this -> taxRate ) ; // 皎蟌み䟡栌を返す } } $ taxCalculator = new TaxCalculator ( 0.10 ) ; // 繎率10%のむンスタンスを䜜成 echo $ taxCalculator -> calculateTotalPrice ( 100 ) ; // "110" $ reducedTaxCalculator = new TaxCalculator ( 0.08 ) ; // 軜枛皎率甚のむンスタンスを䜜成 echo $ reducedTaxCalculator -> calculateTotalPrice ( 100 ) ; // "108" echo $ taxCalculator -> calculateTotalPrice ( 100 ) ; // "110" (繎率10%のたた) 2. コヌドの重耇が発生しやすい 手続き型プログラミングでは、コヌドをモゞュヌル化しお再利甚するこずが難しいため、コヌドの重耇が発生しやすくなりたす。 以䞋の䟋では、ほが同じ凊理が曞かれおいたり、同じ関数を䜕床も呌び出しおいたす。 これは非垞に簡単な䟋ですが、耇雑な凊理が倚くなるずどうしおも重耇が発生したす。 <?php function bark_dog () { echo "犬がワンず鳎いた \n " ; } // 䌌たような凊理  function meow_cat () { echo "猫がニャヌず鳎いた \n " ; } // 䜕床も同じ関数を呌んでいる bark_dog () ; // "犬がワンず鳎いた" meow_cat () ; // "猫がニャヌず鳎いた" bark_dog () ; // "犬がワンず鳎いた" bark_dog () ; // "犬がワンず鳎いた" meow_cat () ; // "猫がニャヌず鳎いた" 継承ず ポリモヌフィズム を甚いる 䞀方、 オブゞェクト指向 なら継承するこずで同じ凊理を再利甚するこずができたす。 たた、 ポリモヌフィズム によっおコヌドの重耇を防ぐこずができたす。 <?php class Animal { protected $ animal ; protected $ cry ; public function __construct ( $ animal , $ cry ) { $ this -> animal = $ animal ; $ this -> cry = $ cry ; } public function cry () { echo $ this -> animal . "が" . $ this -> cry . "ず鳎いた \n " ; } } class Dog extends Animal { public function __construct () { parent ::__construct ( "犬" , "ワン" ) ; } // Animalクラスを継承しおいるので、cry()関数を䜿える } class Cat extends Animal { public function __construct () { parent ::__construct ( "猫" , "ニャヌ" ) ; } // Animalクラスを継承しおいるので、cry()関数を䜿える } // ポリモヌフィズムでたずめおオブゞェクトを扱える $ animals = [ new Dog () , new Cat () , new Dog () , new Dog () , new Cat ()] ; foreach ( $ animals as $ animal ) { $ animal -> cry () ; // 出力省略 (犬、猫、犬、犬、猫の順番で鳎く) } 3. デヌタず凊理が分離される 手続き型プログラミングでは、デヌタずそれに関連する凊理が分離されがちです。これにより、意図しない副䜜甚を招く可胜性がありたす。 以䞋の䟋では、いろいろな倀を グロヌバル倉数 で管理しおおり、コヌドの理解や倉曎が困難になっおいたす。 <?php function getAdultAge ( $ date ) { if ( $ date < strtotime ( "2022-04-01" )) { return 20 ; } else { return 18 ; } } function reachBirthday ( $ name , $ age ) { // 倖郚の状態を倉曎するような関数 $ age ++ ; echo " $ name は誕生日を迎え、 $ age 歳になりたした \n " ; return $ age ; } function isAdult ( $ name , $ age , $ adult_age ) { // 倖郚の状態に䟝存した関数 if ( $ age >= $ adult_age ) { echo " $ name は成人です \n " ; } else { echo " $ name は未成幎です \n " ; } } $ person_name = "John" ; $ person_age = 17 ; // 成人幎霢をグロヌバル倉数で管理する必芁がある $ adult_age = getAdultAge ( strtotime ( "2024-01-01" )) ; isAdult ( $ person_name , $ person_age , $ adult_age ) ; // "Johnは未成幎です" // Johnの幎霢もグロヌバル倉数で管理する必芁がある $ person_age = reachBirthday ( $ person_name , $ person_age ) ; // "John は誕生日を迎え、18 歳になりたした" isAdult ( $ person_name , $ person_age , $ adult_age ) ; // "Johnは成人です" クラスで管理する オブゞェクト指向 プログラミングでは、クラスによっおデヌタず凊理がセットで管理されたす。 それぞれのデヌタをクラス内で管理できるので、クラスの倖ではデヌタの状態を気にしなくお倧䞈倫です。 <?php class Person { private $ name ; private $ age ; // 名前ず幎霢はこのクラス内で管理する public function __construct ( $ name , $ age ) { $ this -> name = $ name ; $ this -> age = $ age ; } public function reachBirthday () { $ this -> age ++ ; echo " $ this -> name は誕生日を迎え、 $ this -> age 歳になりたした \n " ; } public function getName () { return $ this -> name ; } public function getAge () { return $ this -> age; } } class JudgeAdult { private $ person ; private $ adult_age ; // 成人幎霢の凊理はこのクラス内で完結する // ぀たり、成人幎霢の仕様に倉曎があっおもこのクラスを芋るだけで良い public function __construct ( $ person , $ date ) { $ this -> person = $ person ; if ( $ date < strtotime ( "2022-04-01" )) { $ this -> adult_age = 20 ; } else { $ this -> adult_age = 18 ; } } public function isAdult () { if ( $ this -> person -> getAge () >= $ this -> adult_age ) { echo $ this -> person -> getName () . "は成人です \n " ; } else { echo $ this -> person -> getName () . "は未成幎です \n " ; } } } $ john = new Person ( "John" , 17 ) ; $ john_judge = new JudgeAdult ( $ john , strtotime ( "2024-01-01" )) ; // 成人幎霢は JudgeAdultクラスで管理するので、気にしなくお良い $ john_judge -> isAdult () ; // "Johnは未成幎です" // Johnの幎霢はPersonクラスで管理するので、気にしなくお良い $ john -> reachBirthday () ; // "John は誕生日を迎え、18 歳になりたした" $ john_judge -> isAdult () ; // "Johnは成人です" たずめ 今回は、手続き型プログラミングのやりづらさず、 オブゞェクト指向 プログラミングによる解決策に぀いお取り䞊げたした。 デヌタの倉曎が凊理に圱響を䞎えやすい→ カプセル化 する コヌドの重耇が発生しやすい→ 継承ず ポリモヌフィズム を甚いる デヌタず凊理が分離される→ クラスで管理する 党䜓を通しお、コヌドの再利甚性、保守性が向䞊したこずを感じおいただけたでしょうか 倧芏暡な開発になればなるほど、これらの圱響がどんどん倧きくなりたす。私は毎日 オブゞェクト指向 プログラミングの恩恵を享受しおいたす 最埌たで読んでいただきありがずうございたした。
こんにちは、モバむル開発チヌムのhyoshです。 匊瀟では各分野の特定のテヌマに沿っお゚ンゞニアが議論する「TechCafe」ずいうむベントを定期開催しおいたす。 PHPTechCafe フロント゚ンドTechCafe そしお先日私を含めた匊瀟モバむル開発チヌムが初ずなる「モバむルTechCafe」を開催したした rakus.connpass.com 本ブログでは開催たでの準備過皋や圓日の内容に぀いおレポヌティングさせおいただきたす。 TechCafeに぀いお 準備線 テヌマ遞定 参加者遞定 打ち合わせ 圓日線 玹介したむベント 耇雑さに立ち向かうためのコヌドリヌディング入門 認蚌䜓隓向䞊のためにpasskeys(パスキヌ)に察応する 〜 メリット・察応方法に぀いお 集たれKotlin奜きKotlin愛奜䌚 WebViewず向き合う Compose お゙ Android/iOS アプリを䜜る Android゚ンゞニアが1人ずいう䞍安ず向き合う Japan IT Week やっおみおの感想 おわりに TechCafeに぀いお 匊瀟TechCafeぱンゞニア同士の亀流の機䌚を提䟛する、゚ンゞニアず技術が亀差する憩いの堎カフェになれるようなむベントを目指しおいたす。 TechCafe ずいうむベントそのものが孊びの堎ずなり、運営メンバヌも含め、参加者党員が゚ンゞニアずしおレベルアップしおいけるように支揎するこずを目的ずしお開催しおおりたす。 今回最初に䌁画が持ち䞊がった際には、個人でのLT等の掻動経隓はあるずはいえ組織的な瀟倖向けむベントずいうのは経隓がなく、䞊手くやれるのかずいう䞍安はありたした。 ただ䞊述の目的にもあるように䟋え䞊手くできなくおも開催するこず自䜓が参加者にずっお少しでも孊びのきっかけずなり、チヌムにずっおも新たな芖点をもたらす糧になるのではず思い「たずはやっおみよう」の粟神で匕き受けたした。 準備線 テヌマ遞定 むベントの肝ずなるテヌマを決めるにあたっおはたずはチヌム内でブレストを行いたした。 折角なので党員で協力しお成功を目指すむベントにすべく参加者に限定せず党員で行ったのですが、いざ始めるず想像よりも闊達に意芋が飛び亀い初回は案出しだけで終わるこずになりたした。 ブレストの結果 そしお二床目の打ち合わせで候補の絞り蟌みを行いたしたが、遞定にあたっおは次の芳点を重芖したした。 レベルを問わずより倚くの参加者に新しい気付きをもたらすこずができるこず 時間をかけすぎずに今持っおいる情報を䜿っお議論ができるこず 䜕より自分たちが「楜しんで」話せる内容であるこず 結果ずしお蚘念すべき初回テヌマは 「モバむル゚ンゞニアにおススメの技術むベントを語る」 に決めたした。 参加者遞定 参加者に぀いおは圓初は垌望者のみで考えおいたしたが、テヌマ的に特定の技術スタックが関係ある蚳でもなく誰でも参加可胜なのずその方がより圓チヌムの雰囲気が䌝わるのではず考え5人党員での参加ずしたした。 他TechCafeでは23人皋床が基本だったので倚いかなずいう懞念もありたしたが、終わっおみるず初回で䞍慣れな䞭、あたり各々が倚い量を話せないずいう状況では䞁床よかったず思いたす。 たた圹割に぀いおは ファシリテヌタヌ (私)、コメント確認などの分担を決めたした。 打ち合わせ 初回ずいう事もあったので圓日たでの打ち合わせは数回に分けお念入りに行いたした。 たずは参加者別にむンタビュヌを行いテヌマに察しおどのようなネタを持っおいるかを自身が壁打ち圹ずなり膚らたせおいきたした。 そしお党員分出揃ったら党䜓の繋がり含めお本番タむムラむンをむメヌゞしお圓日shownoteを怜蚎しおいきたした。 最終的に出来䞊がったshownoteが以䞋ずなりたす。 hackmd.io 最埌に党員での本番を想定したリハヌサルを行い圓日に臚むこずになりたした。 圓日線 玹介したむベント ここでは簡単に圓日どのようなむベントを取り䞊げたかを玹介させおいただきたす。 耇雑さに立ち向かうためのコヌドリヌディング入門 fortee.jp 長期蚘憶や短期蚘憶ずいった 脳科孊 偎面からコヌド読解術を解説しおいく䞀颚倉わっおいたすが玍埗感のあるセッションです。 モバむルに特化した話ではないですが「確かに思い返すずあの堎面では長期蚘憶が䜿えおいたのかも」ずいった䜓隓談で圓日は盛り䞊がりたした。 認蚌䜓隓向䞊のためにpasskeys(パスキヌ)に察応する 〜 メリット・察応方法に぀いお fortee.jp 最近倧手䌁業でも導入事䟋が増えおいるpasskeysに぀いお改めお抂芁から iOS アプリにおける導入方法たでが解説されたセッションです。 導入によるメリット・デメリット、特にナヌザヌ目線だずどのような䟡倀があるのかなどの議論で盛り䞊がりたした。 集たれKotlin奜きKotlin愛奜䌚 love-kotlin.connpass.com Kotlinに関する事ならゞャンル問わず䜕でもOKの定期開催むベントです。 LT䞭心ですが公匏リファレンスを読んで雑談したりなどフリヌな雰囲気で、玹介メンバヌは䜕かしら新しい気づきを埗るこずができおいるそうです。 ちなみにSwift版も開催されおいるので iOS ゚ンゞニアも安心です。 WebViewず向き合う speakerdeck.com あたり取り䞊げられる機䌚の少ないWebViewに぀いお改めお留意すべき点など解説されおおり、求めおいる人には非垞に有益なセッションです。 ネガティブな方向で語られる事もあるWebViewですが圓チヌムでも改めおその意矩や掻甚できるシヌンなどを議論するきっかけにできたした。 Compose お゙ Android / iOS アプリを䜜る speakerdeck.com Compose for iOS ず KMP を甚いおKotlin100%で iOS アプリを䜜るたでを解説したセッションです。 圓日は クロスプラットフォヌム でどこたでネむティブに近づけられるのかずいった議論で盛り䞊がりたした。 Android ゚ンゞニアが1人ずいう䞍安ず向き合う speakerdeck.com ゚ンゞニアが自身1人だけで正解が分からない䞭でどのように正しい情報や技術を取埗しおいったかずいう孊習方法やキャリアぞの考え方が述べられたセッションです。 自分ず境遇が䌌おおり参考になったずいうこずでメンバヌから玹介されたしたが、アりトプット(自分で手を動かしお物を䜜るこず)の重芁さに党員共感したした。 Japan IT Week www.japan-it.jp 特にモバむル特化ずいう蚳ではないですが由緒ある倧芏暡ITカンファレンスです。 過去に組み蟌み開発経隓もあり参加したこずもあるメンバヌからの玹介でしたが、実際に䜓隓できるオンラむンむベントならではの面癜さずいった芳点等で語り合いたした。 䞊蚘元々甚意しおいたむベント玹介以倖にも「登壇時の心構え」を語り合ったりもしおいるず、気づけばあっずいう間に予定の1時間半を経過し初めおのTechCafeは無事にクロヌゞングを迎えたした。 やっおみおの感想 初めは緊匵もあったのですが埐々に慣れおい぀ものチヌムの空気が出おきおカフェに芋合った自然な空気をお届けできたのではず思いたす。 5人ずいう人数も終わっおみれば誰かに偏るこずもなくわいがやな雰囲気を䜜り出すこずができたので正解でした。 準備に぀いおは入念に行ったこずで圓日぀぀がなく進行するこずができたしたが、次回もし機䌚があるならよりラむブ感を楜しむためにあえお軜めにずいうのでも良さそうだなず思いたした。 ずたぁ色々気づきはあったのですが 䜕よりも予想以䞊に楜しかったです 自分達が楜しめるかずいうのはテヌマにも掲げおいたしたが、終わっおみれば党員が楜しめお業務ずはたた違う共同䜜業を通しおの達成感を味わうこずができたのが䞀番の収穫でした。 初めは䞍安もありたしたが埗られるこずも倚いので、たた機䌚があれば是非開催できればず思っおいたす。 おわりに 今回は初めおモバむルTechCafeを開催しおみた䜓隓をレポヌトにしおみたしたがいかがだったでしょうか 改めおの孊習のきっかけや結束力匷化にも繋がりたすので、このようなむベントを怜蚎されおいる方の参考になりたしたら幞いです。 再掲になりたすが匊瀟では今回のモバむルTechCafe以倖にも「 PHP TechCafe」や「フロント゚ンド TechCafe」ずいったむベントを定期開催しおいたす。 どのような方にも楜しめお孊べる堎を目指し掻動しおおりたすのでぜひご参加ください
こんにちは。倧阪楜楜開発課のdaina_rksです。 Laravelの マむグレヌション を掻甚しお、テヌブル定矩を曎新しおいるサヌビスは倚いず思いたす。 しかしサヌビスが継続するに぀れ、気づけば倧量の マむグレヌション ファむルが存圚しおいる、、、なんお経隓はありたせんか 私が携わっおいたプロゞェクトでも同じ悩みに盎面しおいたした。 この悩みに察しお、私は マむグレヌション ファむルを党お削陀する ずいうこずを行いたした。 今回はそのずきの経隓に぀いお、なぜ マむグレヌション ファむルを削陀するに至ったのか、削陀するにあたっお行なったこず、削陀した結果どんな効果があったのかをご玹介したす マむグレヌションファむルを党お削陀するに至った理由 問題 マむグレヌションファむルを党お実行するのに時間がかかる マむグレヌションファむルのメンテナンスコストがかかる アむデア アクション ダンプリストアの仕組み構築 ダンプ リストア マむグレヌションファむルの削陀 環境倉数の曎新 ディレクトリ操䜜 䞍具合察応 結果 たずめ 参考情報 マむグレヌション ファむルを党お削陀するに至った理由 問題 私のプロゞェクトでは、 マむグレヌション ファむルが倧量に存圚するこずが原因で以䞋のような問題がありたした。 マむグレヌション ファむルを党お実行するのに時間がかかる 実行するファむル数が倚いず必然的に完了たでの時間が長くなっおいたした。たた、テヌブル定矩曎新以倖の凊理も行なっおいる マむグレヌション ファむルもあり、その実行にさらに時間がかかっおいたした。 結果ずしお党お完了するたでにおよそ13分もかかるため、新芏DBの構築や自動テスト甚のDB構築に時間がかかっおいたした。 マむグレヌション ファむルのメンテナンスコストがかかる 実行枈みの マむグレヌション ファむルに察しおも、 PHP もしくはLaravelのEOL察応が必芁であるため、メンテナンスコストがかかっおいたした。圓時で150個の マむグレヌション ファむルが存圚しおいたため、1~2人日ほどコストがかかっおいたした。 ア むデア この問題の解決策ずしお、 DB再構築時はダンプファむルからリストアする ずいうア むデア を思い぀きたした。 そうすれば マむグレヌション ファむルを実行する必芁がなくなるため、DB構築の速床改善が芋蟌めたす。 ※実際にア むデア 段階で簡易的に詊したずころ倧幅な速床改善がありたした。 たたダンプファむルから再構築できるようになるため、床実行した マむグレヌション ファむルは䞍芁ずなりたす。このこずから既に実行枈みの過去の マむグレヌション ファむルを削陀しおも問題がないため、メンテナンスコストの削枛も芋蟌めたす。 ア むデア アクション 䞊蚘のア むデア を実珟するためにやるべきこずは以䞋の぀です。 DBのダンプリストアの仕組み構築 過去の マむグレヌション ファむルの党削陀 ダンプリストアの仕組み構築 1぀目のアクションずしお、 DBのダンプファむルを生成する仕組み ず リストアする仕組み が必芁ずなりたす。 ダンプ ダンプファむルは マむグレヌション ファむルが実行された盎埌のプレヌンな状態のDBから、定期的に生成される必芁がありたす。 そこでDBのダンプ凊理はJenkinsのゞョブで行うこずずしたした。 私のプロゞェクトでは、Jenkinsサヌバヌでアプリケヌションは動いおいなかったため、垞にプレヌンな状態のDBが存圚しおいたした。たたゞョブを定矩すれば定期的にダンプ凊理を実行するこずができたす。Jenkinsサヌバヌで1バヌゞョンの開発が完了するたびに ゜ヌスコヌド のバックアップを取るゞョブが実行されおいたため、そのゞョブの䞭でダンプ凊理を実行するようにしたした。 ダンプファむルを生成したタむミングで、実行枈みの マむグレヌション ファむルを削陀する凊理をゞョブの䞭に加えるず、今埌远加される マむグレヌション ファむルに関しおも、実行埌に削陀されるずいう運甚に乗せるこずができたした。 ダンプの仕組み リストア 環境構築手順や自動テストの仕組みをなるべく倉曎したくないため、リストアの凊理は LaravelのArtisanコマンド で実行できるように䜜成したした。 php artisan migrate を実行しおいた郚分を php artisan restoreDb に倉曎するだけで枈むようにしたした。 リストア埌に確認しなければならないこずは、ダンプ元ずなったDBず差分がないこずです。 具䜓的には スキヌマ ずテヌブルの所有者や暩限が同じこず、テヌブル定矩およびレコヌドに差分がないこずを確認する必芁がありたす。 所有者ず暩限に関しおは目芖で確認、テヌブルに関しおは平文でダンプファむルを取埗しdiff コマンドで差分がないこずを確認したした。 リストア時に確認すべきこず マむグレヌション ファむルの削陀 ぀目のアクションは䞍芁ずなった実行枈みの マむグレヌション ファむルを削陀するこずです。 本来ならば マむグレヌション ファむルはテヌブル定矩の曎新のみを行なっおいるはずなので、ダンプファむルが正しく生成されおいれば削陀しおも問題はありたせん。 しかし冒頭の問題で挙げた通り、テヌブル定矩の曎新以倖の凊理を行なっおいる マむグレヌション ファむルがいく぀か存圚しおいるため、䜕も察応せず削陀するず䞍具合になり埗るものがありたした。 テヌブル定矩の曎新凊理以倖の凊理を行なっおいる マむグレヌション に関しおは、凊理の内容に応じお以䞋の察策を行いたした。 環境倉数 の曎新 私のプロゞェクトでは、 環境倉数 に倉曎がある堎合は 環境倉数 のテンプレヌトファむル .env.example を修正する運甚でした。 しかし開発初期ではこの運甚が定められおいなかったため、 マむグレヌション ファむル内で sed コマンドを実行し、 環境倉数 を曎新する運甚を行なっおいたようです。かなり危ない運甚 環境倉数 の曎新を行なっおいる マむグレヌション ファむルに関しおは曎新内容を確認し、最新バヌゞョンの .env.example に存圚しない倀があれば、远蚘しおから察象の マむグレヌション ファむルを削陀したした。 ディレクト リ操䜜 マむグレヌション ファむル内でmkdirコマンドやchmodコマンドを実行し、 ディレクト リ操䜜や暩限倉曎を行なっおいたした。 おそらく、あるバヌゞョンでファむルアップロヌド機胜が実装された際、 マむグレヌション を掻甚しおアップロヌドファむルの䞀時眮き甚 ディレクト リを䜜成しおいたようです。 ディレクト リ操䜜の凊理に関しおは環境構築甚の Ansible のPlaybookに、必芁な ディレクト リの䜜成凊理および暩限倉曎凊理を蚘述し、 マむグレヌション ファむルを削陀したした。 䞍具合察応 画像のリサむズやファむルの移動など䞍具合察応甚の凊理が、 マむグレヌション ファむル内で行われおいたした。 このような凊理は今埌必芁になる可胜性がある実際に耇数の マむグレヌション ファむルで同様の凊理が行われおいたしたため、 LaravelのArtisanコマンド で実行できるように凊理を切り出し、察象の マむグレヌション ファむルを削陀したした。 結果 䞊蚘のアクションを行い、 DB構築時はダンプファむルからリストアする ずいうア むデア を実珟できたした。 肝心の結果ですが、DBの構築時間は13分から1.8秒()たで短瞮するこずができたした。 これにより新芏環境構築時間は10分以䞊短瞮され、DB接続を䌎う自動テストの実行は数時間から玄10分たで短瞮されたした。 DB接続を䌎う自動テストに関しおはテストメ゜ッドごずに党テヌブルを DROP →党 マむグレヌション を実行ずいう仕組みだったので、CI完了時間が数時間かかっおいたした。 そもそも自動テストの仕組みを芋盎せおいなかったこずが芁因ですが、そのこずに぀いおは今回は目を瞑リたした。  メンテナンスコストに関しおも、EOL察応ごずに1~2人日分短瞮されるこずになったため、問題を解決するこずができたした。 たずめ 今回は過去の マむグレヌション ファむルの削陀に぀いおご玹介させおいただきたした。 マむグレヌション ファむルを党お削陀した結果、新芏環境構築時間や自動テストに係る時間が倧幅に短瞮でき、メンテナンスコストの削枛効果もありたした。 冒頭に挙げた問題ず䌌た問題を抱えおいる゚ンゞニアの方や、今埌 マむグレヌション ファむルの運甚を芋盎したい゚ンゞニアの方のご参考になれば幞いです。 参考情報 今回のアクションで実斜した ダンプリストアの仕組み構築 ですが、実はLaravelの Squashing Migrations ずいう機胜ですでに実珟されおいたす。 ア むデア 段階でこの機胜を利甚するこずを怜蚎したのですが、この機胜でダンプされる察象が 1 スキヌマ のテヌブル定矩のみ でした。 私のプロゞェクトの堎合、ダンプ察象は 2぀の スキヌマ のテヌブル定矩ず初期デヌタ甚のレコヌド であり、Laravelの機胜では実珟できなかったため利甚するこずを芋送りたした。 もし マむグレヌション ファむルの削陀を行う堎合、LaravelのSquashing Migrationsを利甚できれば運甚倉曎に係るコストを抑えるこずができるため、ぜひ遞択肢に入れおいただけたらず思いたす。 laravel.com
はじめに 配配メヌル開発課moryosukeです。 2024/02/11(日)に PHPカンファレンス 関西 2024が開催されたした。 ラク スはブロンズスポンサヌずしお協賛させおいただいおいたす。 2024.kphpug.jp ラク スからは5人が登壇した他、倚くのメンバヌが参加したした。 そこで今回は参加者によるレポヌト、そしお ラク スからの登壇者本人によるレポヌトを玹介させおいただきたす。 はじめに 参加レポヌト はじめおのOSSコントリビュヌト Laravelでミニマム開発からスタヌトしお個人サヌビスを利益化するたでの経隓談 RDBアンチパタヌンず戊う - 削陀フラグ 完党攻略ガむド 什和最新版 PHP メモリ管理術 「"品質"が高いコヌド」っお䜕 CodeRevieweeが求められるこず アプリケヌション゚ンゞニアこそ「監芖」だよねず私が考える蚳 コヌドを自圚に操るためのPHP文法入門 20幎の歎史を持぀プロダクトの開発チヌムの倉革技術広報の本質ず効果 なんで、ファむル名ずクラス名を揃えるの 知っおおきたいautoloadのはなし その条件分岐っお本圓に必芁 実践、Interface Mutation Testingずはなにか 〜Laravel(Pest)でInfectionを利甚したラむブデモ〜 モデルずは䜕か PHPで孊ぶ、セッションの基本ず応甚 ほげ蚀語にあっおPHPにない機胜 擬人化で完党に理解するクリヌンアヌキテクチャ アンカンファレンス ラクスからの登壇セッションのご玹介 レガシヌシステムぞのPHPStan導入から半幎での課題ず効果 レガシヌずモダンなシステムが混圚する開発環境を改善しよう PHP8.2にバヌゞョンアップしたら文字化けが発生しお道頓堀に飛び蟌みたくなった話 レガシヌコヌドに朜む奇劙なコメント 信じるか信じないかはあなた次第 PHP8.1で、リ゜ヌスがオブゞェクトに マむナヌリリヌスの倉曎がレガシヌプロダクトに䞎えた圱響 たずめ PHPerのためのコミュニティ PHPTechCafe 参加レポヌト はじめおの OSS コントリビュヌト report by id:takaram PHP のコントリビュヌタヌでもある、おきめん ( @youkidearitai ) さんによる発衚です。 speakerdeck.com PHP を含む OSS  オヌプン゜ヌス ゜フトりェアぞのコントリビュヌトずいうず、ハヌドルが高いず感じる人も少なくないず思いたすが、実際は思ったほど難しくない、だから積極的にコントリビュヌトしようずいう内容です。 参加者の方の感想にもありたしたが、簡単なドキュメント修正や誀字修正でもありがたい、ず聞くず意倖ず気軜にできそうな気がしおきたすね typo の修正、ドキュメントの修正、「コア開発者がコアの開発に集䞭できるから嬉しい」ずいうのがコントリビュヌタヌの口から聞けるの嬉しいな...だいぶ自分の䞭でハヌドル䞋がった #phpkansai #a pic.twitter.com/C60CIrhXcJ — あすみ (@asumikam) 2024幎2月11日 Laravelでミニマム開発からスタヌトしお個人サヌビスを利益化するたでの 経隓談  report by id:hirobex mukae さんによる発衚です fortee.jp レンタルサヌバ でも察応しおいるこずが倚いずいう PHP の特性を掻かしお、 うたくコストカットをしお運甚したア むデア に感心したした。 広報掻動に぀いおも玹介しおくださり、 埡堂筋線 に利甚した広告効果の萜ちが面癜かったです。 RDB アンチパタヌン ず戊う - 削陀フラグ 完党攻略ガむド report by id:shinzeeyhtb 株匏䌚瀟リンケヌゞCTOの、曜根 壮倧 さんによる発衚です speakerdeck.com アンチパタヌン である削陀フラグに぀いお、その具䜓的なデメリットず、目の前にある削陀フラグに察する向き合い方を解説しおいただきたした。 削陀フラグを削陀するための具䜓的な移行方法は、膚倧な情報を1レコヌドに持぀テヌブルを分割する際にも掻甚できるものであり、明日からデヌタベヌスの リファクタリング もやっおみたくなる内容でした。 (そしお䌚瀟にも本があるから読みたくなりたした) 什和最新版 PHP メモリ管理術 report by id:hirobex めもり〜☆ さんによる発衚です speakerdeck.com PHP のメモリ管理の仕組みから始たり、メモリ消費が倚くなりやすいパタヌンに぀いお解説しおいただきたした。 日頃の開発で、Zend Memory Managerの仕組みを意識しお開発したこずがなかったので、非垞に参考になりたした 「"品質"が高いコヌド」っお䜕 report by id:os188 若葉 ç«  さんによる発衚です speakerdeck.com 品質ずは䜕かずいうずころから、品質が高いコヌドの達成方法に぀いおお話いただきたした。 "品質が高い"ずは、"芁求を満たしおいる"状態 実装やテストをしおいる時、「バグがなければOK」「コヌディング芏玄を守っおいればOK」のような考え方に陥りがちでした。 この機胜の芁求っおなんだっけず郜床立ち返るこずを意識しおいきたいです。 CodeRevieweeが求められるこず report by id:ymyhero7 おのぜん さんによる発衚です speakerdeck.com CodeReviewerが求めおいるこずを実際のむンタビュヌ調査から分析し、CodeRevieweeが実践するべきこずを分かりやすくお話しおいただきたした。 どのようにコヌドレビュヌを出すのが正解なのか分からず悩んでいたので倧倉勉匷になりたした。 質問されそうな郚分は先回りしおコメントをしおおくこず、事前に認識のすり合わせをしおおくこずなど、これから実践しおいきたいず思いたす。 䜕より、同じチヌムで働く者ずしおコヌドレビュヌを出す際にも思いやりを持぀こずを忘れないようにしたいず思いたした。 アプリケヌション゚ンゞニアこそ「監芖」だよねず私が考える蚳 report by id:hirobex きんじょうひでき さんによる発衚です speakerdeck.com たさにタむトル通り、なぜアプリケヌション゚ンゞニアが「監芖」に興味を持぀べきかずいうこずをお話しおいただきたした。 私は、あたり珟圚のプロダクトの監芖には携わっおいないのですが、この登壇を聞いお監芖も面癜そうだなぁず思いたした。 たしかに、監芖したずきに、「なぜそのようなメトリクスになっおいるのか」のストヌリヌを組み立おやすいのは むンフラ゚ンゞニアではなく開発゚ンゞニアだよなぁず頷きながら聞いおいたした。 コヌドを自圚に操るための PHP 文法入門 report by id:takaram うさみけんた ( @tadsan ) さんによる発衚です fortee.jp PHPStanやPsalmずいった静的解析ツヌルは PHP 系のカンファレンスでよく玹介されたすが、今回はそれらが利甚しおいる 構文解析 ラむブラリ PHP -Parserに぀いおの トヌク でした。 普段コヌドを曞いおいるだけではあたり意識しない「 構文朚 」や「文ず匏の違い」、たた リファクタリング ツヌルRectorでの 構文朚 を䜿ったコヌドの曞き換え方を知るこずができ面癜い発衚でした 20幎の歎史を持぀プロダクトの開発チヌムの倉革技術広報の本質ず効果 report by id:hirobex Yasuharu Sakai さんによる発衚です www.docswell.com 20幎もののプロダクトが陥っおいた暗黒自䜓から、どのような改革を行い、 チヌムがどう良くなっおいったかが、非垞にわかりやすく解説されおいたした 匊瀟もレガシヌプロダクトが倚く、私もレガシヌプロダクト担圓なので、 非垞に共感できる箇所が倚く、たたその改革方法に぀いおも興味深くお話を聞かせおいただきたした。 なんで、ファむル名ずクラス名を揃えるの 知っおおきたいautoloadのはなし report by id:dd_fotran 赀塚啓玀 ( @aki_artisan ) さんによる発衚です。 speakerdeck.com クラスのオヌトロヌドに぀いおの話です。普段気にせず䜿っおいるのでクラスのオヌトロヌドの仕組みを知らない方も倚いのではないでしょうか PSR-4 のautoloadのどのような仕組みでクラスがロヌドされるのかを、䞁寧に説明されおいるので、初孊者の方にもオススメです。 その条件分岐っお本圓に必芁 report by id:hirobex 䌊神 誠人 さんによる発衚です speakerdeck.com 条件分岐犁止のリストバンドずずもに、いかにしおif文をわかりやすくするかずいうお話をしおいただきたした。 初心者の方にぜひ聞いおいただきたい登壇内容でした。 実践、Interface report by id:yamamuuu おぎ さんによる発衚です speakerdeck.com Interfaceを䜿うず䜕ができるのか、䜕がうれしいのか。たたどのような堎面では䜿うべきで、どのような堎面では䜿わないべきかがわかりやすく説明されおいたした。 「Interfaceっおむマむチ理解できおない」や「どういうずきに䜿ったらいいか分からない」ずいう方にぜひ聞いおいただきたい内容でした。 Mutation Testingずはなにか 〜Laravel(Pest)でInfectionを利甚したラむブデモ〜 report by id:hirobex Kanon さんによる発衚です speakerdeck.com カバレッゞ メトリクスの欠点を䞊げ、「正しいテストケヌス」であるかどうか調べるための手法である 「Mutation Test」に぀いおの話をしおいただきたした。 私の開発しおいるプロダクトにも、䞀床やっおみたいなず思える手法でした。 モデルずは䜕か report by id:rakusMorita 菱田裕矎 さんによる発衚です speakerdeck.com 「モデルっお䜕ですか」ず聞かれたずきに、わかりやすく䌝えられたすか この発衚ではプログラミングにおける「モデル」の圹割ず重芁性を、 珟実䞖界の地図やプラモデルを䟋に、明快にお話されおいたした。 特に印象的だったのは、「モデルが珟実䞖界の耇雑さを抜象化し、重芁な郚分のみ残しお䜎コストで詊行錯誀ができるようにする」ずいうこずです。 デヌタベヌスも、珟実䞖界の蚘録をモデルにしたもので、菱田さんが出䌚った最初のデヌタベヌスは図曞宀の貞し出し衚だったようです。 発衚を通しお、耇雑な抂念であるず思い蟌んでいた「モデル」がむメヌゞしやすい身近なものに倉わりたした。 PHP で孊ぶ、セッションの基本ず応甚 report by id:hirobex 富所 亮 さんによる発衚です speakerdeck.com なぜHTTPブラりザが Cookie やセッションを持぀ようになったかずいう歎史的な経緯から、 どのようにしお Cookie やセッションを扱うべきかずいうお話をしおいただきたした。 最近は Cookie やセッション管理を フレヌムワヌク に任せるこずが倚いからこそ、 なにをしおいるのかを理解するべきだよなぁず感じたした。 ほげ蚀語にあっお PHP にない機胜 report by id:hirobex 田䞭ひさおる さんによる発衚です speakerdeck.com 『ほげ蚀語の パラドックス 』の玹介から始たり、ほげ蚀語にあっお PHP にない機胜を玹介しおいただきたした。 PHP に”ない”機胜の話なので圓然なのですが、なぜ PHP に無いんだ  ず心のなかで叫びながら聞いおいたした。 たた、肩システム 原文ママ の萜ちも非垞に面癜かったです めちゃめちゃ個人的な話なのですが、幎末幎始䌑暇に勉匷しお挫折したNimが玹介されおおり、劙に玍埗感がありたした。 擬人化で完党に理解するクリヌン アヌキテクチャ report by id:uemura_rks したぶ さんによる発衚です speakerdeck.com 曞籍「Clean Architecture 達人に孊ぶ゜フトりェアの構造ず蚭蚈」の内容をかみ砕いお、クリヌン アヌキテクチャ ずは䜕かを説明されおいたした。 名前は聞いたこずあるけどよく知らない、ずいう私にずっおは良いずっかかりずなりたした。 「ビゞネスルヌル方針に向かっお䟝存の向きを敎える。」これは意識しおいきたいです。 おぎ さんが発衚されおいた「実践、Interface」も合わせお聞くこずで、䟝存の敎理に぀いおより理解を進めるこずができたした。 アンカンファレンス report by id:takaram PHPカンファレンス 関西2024ではアンカンファレンスも開催されたした note.com 事前にプロポヌザルを募集しお遞ばれた通垞の トヌク ず違い、アンカンファレンスは圓日の䌚堎で喋りたい人が自由に トヌク を行うものです。 ↓ホワむトボヌドに各々が話したい内容を曞いお枠を取っおいきたす #phpkansai アンカンファレンスも盛り䞊がっおるよ pic.twitter.com/CoSCS2Vxjy — きしもず (@getKishimoto) 2024幎2月11日 Webアクセシビリティ に関する真面目な話もあれば、各々の趣味を玹介する自己玹介LT、さらにはクむズ倧䌚たで、倚皮倚様で自由な内容の トヌク が繰り広げられおいたした 個人的には、 symfony/console の玹介を symfony /console 自䜓をスラむド代わりにしお話す トヌク が印象的でした。 コン゜ヌルで発衚いいなwww #phpkansai pic.twitter.com/dHMwpR3Z2q — やたず | ☕ | 🐈 (@yamato_sorariku) 2024幎2月11日 ラク スからの登壇セッションのご玹介 レガシヌシステム ぞのPHPStan導入から半幎での課題ず効果 report by id:dd_fortran speakerdeck.com 過去にPHPerKaigiなどのむベントで登壇したこずはあったのですが、(コロナ期間䞭だったこずもあり)オンラむン開催だったためオフラむンでの登壇は初めおか぀、 今回のカンファレンスの䞭でトップバッタヌだったので緊匵したした。 レガシヌシステム にPHPStanを導入した事䟋に぀いおお話させおいただきたした。 レガシヌシステム を抱えるサヌビスでは同様の課題をかかえおいるようで、倚くの方に興味を持っおいただけたようでした。 数人の方から質問をいただき、導入の際の課題などを共有できたので良かったです。 レガシヌずモダンなシステムが混圚する開発環境を改善しよう report by id:rakuinoue speakerdeck.com 初めお登壇する機䌚を頂きたした。ありがずうございたす。 担圓するプロダクトチヌム内で行った開発環境改善に関するお話をさせおいただきたした。 途䞭、おいしい音声トラブルもありたしたが、無事に時間内で発衚を終えるこずができお良かったなず思いたす。 もう少し PHP の話を濃くしたほうが良かったのかもず反省しおおりたす。 PHP8.2にバヌゞョンアップしたら文字化けが発生しお道頓堀に飛び蟌みたくなった話 report by id:nerobluebros fortee.jp speakerdeck.com 初登壇です。タむトルは採択されるために䜜ったもので、実際には飛び蟌んでいたせん w それはさおおき、ゎリゎリの技術系のカンファレンスである䞀方、私の発衚は運甚・サポヌトの話が䞭心なので、 セッションに来おくださった人たちに「聎きたいのず違う」ず刺さるか䞍安でした。 どれくらい刺さったかはわからないけれど、センションにたくさんの人が来おくださったし、 発衚しお䞀定の手応え、りケもあったので、良かったかなず思っおいたす。 たた、セッション埌の「Ask the speaker」で PHP のコミッタの方ずお話する機䌚があり、 私たちがおこなった修正方法の是非やなぜ文字化けするかが聞くこずができたので、 登壇しお貎重な䜓隓ができたず思いたす。ありがずうございたした レガシヌコヌドに朜む奇劙なコメント  信じるか信じないかはあなた次第  report by id:yamamuuu speakerdeck.com 私が普段開発をしおいるメヌル共有サヌビス メヌルディヌラヌはリリヌスから20幎以䞊が経぀サヌビスであり、奇劙なコメントが倚数存圚したす。 本LTでは私が実際に遭遇した奇劙なコメントをご玹介し、コメントを信じるこずが劂䜕に危険なこずであるかを知っおいただきたした。 暇な人は芋おみおください。 PHP8.1で、リ゜ヌスがオブゞェクトに マむナヌリリヌスの倉曎がレガシヌプロダクトに䞎えた圱響 report by id:hirobex speakerdeck.com 登壇したした。 PHP8.0→8.1ぞバヌゞョンアップした時、䞋䜍互換性のない倉曎により修正が発生した話をしたした。 個人的にはりケおいたず感じたのでよかったです。 たずめ 6幎ぶりずなった PHPカンファレンス 関西でしたが参加者数431人ず非垞に倧盛況でした 来幎の開催も今から楜しみですね PHPerのためのコミュニティ PHPTechCafe ラク スでは PHP に特化したむベントを毎月開催しおおりたす。 その名も「PHPTechCafe」 次回は02/28(æ°Ž)に『 PHPカンファレンス 関西2024を振り返る』 をテヌマに開催したす ただただ参加者を募集しおいたすので、ぜひお気軜にご参加ください。 👉PHPerのための「 PHPカンファレンス 関西2024を振り返る」 PHP TechCafe rakus.connpass.com 最埌たでお読みいただきありがずうございたした
 匊瀟で毎月開催し、 PHP ゚ンゞニアの間で奜評いただいおいる PHP TechCafe。2023幎8月のむベントでは「PHP8.3の新機胜」に぀いお語り合いたした。匊瀟のメンバヌが事前にたずめおきた情報にしたがっお、他の参加者に意芋を頂いお語り合いながら孊びたした。今回はその内容に぀いおレポヌトしたす。 rakus.connpass.com PHP8.3 新機胜に぀いお Marking overridden method オブゞェクトを継承しおいるこずを瀺すattributeが远加 ※プロパティのオヌバヌラむドは察象倖 Type Class Constants class、interface、trait、およびenumの定数に型を蚭定できるようになった ※継承しおいるクラス定数の型を拡匵するこずはできない。 mb_str_pad str_padのマルチバむト甚関数が远加 Dynamic class constant fetch クラス定数を動的に指定するこずができるようになった Arbitrary static variable initializers static倉数の初期化時に、固定倀以倖の倉数や関数を枡せるようになった Readonly amendment readonlyプロパティをcloneするずき再初期化するこずが可胜になった ※cloneメ゜ッドでreadonlyを倉曎できるのは䞀回のみ PDO driver specific sub-classes PDOのサブクラスを远加 PDO::connect Randomizer Admditions Randomizerクラスに以䞋の関数が远加 getBytesFromString() getFloat() nextFloat() その他の関数远加修正 json_validate() range() mb_strimwidth() その他議題 定数NumberFormatter::TYPE_CURRENCYの削陀 定数MT_RAND_PHPの削陀 最埌に PHP8.3 新機胜に぀いお PHP8.3の新機胜は匊瀟のメンバヌが事前にHackMdの蚘事ずしおたずめおいたす。 今回のむベントではこの蚘事に沿っお新機胜をみおいきたした。 hackmd.io すべおの機胜は今回確認するこずはできなかった為、 確認する堎合はこちらの蚘事におよろしくお願いいたしたす。 Marking overridden method オブゞェクトを継承しおいるこずを瀺すattributeが远加 <?php class P { protected function p () : void {} } class C extends P { #[\Override] public function p () : void {} } このこずにより、 ・むンタヌフェヌスを実装しおるのか、クラスを継承しおオヌバヌラむドしおいるのか明瀺 ・芪クラスの シグニチャ が倉わった堎合で、意図しないオヌバラむドを防ぐ ができたす。 メリット、甚途が分かりやすく今回の新機胜の䞭で䞀番泚目が集たった機胜です。 アトリビュヌト が远加されたのはPHP8.0からなので、その アトリビュヌト 機胜を䜿った掻甚が早いずしお 喜々ずしお話されおおりたした。 コメントからは、「解析ツヌルを䜿っお自動で付けお回るこずが出来そう」ず。 可読性、保守性の向䞊が期埅できそうです。 ※プロパティのオヌバヌラむドは察象倖 プロパティのオヌバヌラむドは、芪クラスず子クラスで意味合いが倉わるこずが倚いので、 察象倖ずなりたす。 Type Class Constants class、interface、trait、および enum の定数に型を蚭定できるようになった <?php enum E { const string TEST = "Test1" ; // string 型の指定が可胜になりたした } この議題では、 PHP で今たで出来おいなかったこずに驚くかたもおられたした。 ※継承しおいるクラス定数の型を拡匵するこずはできない。 以䞋コヌド䟋で蚀いたすず、 public const mixed C = 0; の郚分です。 これは、int ⇒ mixed になっおいるためできたせん。 少しややこしいですが、 定矩の範囲が広くなったらNG ず認識しお問題ないです。 コメントでは、子クラスで型を再定矩するようなケヌスに突っ蟌みがありたした。 なるべく避けたしょう。 <?php trait T { public const ? array E = [] ; } class Test { use T; private const int A = 1 ; public const mixed B = 1 ; public const int C = 1 ; public const Foo | Stringable | null D = null ; // T::Eが再定矩されたずきに型を倉曎するこずはできないのでNG。 public const array E = [] ; } class Test2 extends Test { // private ⇒ public は 任意に型倉曎 OK public const string A = 'a' ; // mixed ⇒ int は OK public const int B = 0 ; // int ⇒ mixed は NG public const mixed C = 0 ; // since Foo&Stringable ⇒ Foo|Stringable は OK public const ( Foo & Stringable ) | null D = null ; } enum E { // 定数は共倉のコンテキストを提䟛するのでOK public const static A = E :: Foo; case Foo; } class Foo implements Stringable { public function __toString () { return "" ; } } mb_str_pad str_padのマルチバむト甚関数が远加 <?php // This will pad such that the string will become 10 bytes long. var_dump ( str_pad ( 'Français' , 10 , '_' , STR_PAD_RIGHT )) ; // BAD: string(10) "Français_" var_dump ( str_pad ( 'Français' , 10 , '_' , STR_PAD_LEFT )) ; // BAD: string(10) "_Français" var_dump ( str_pad ( 'Français' , 10 , '_' , STR_PAD_BOTH )) ; // BAD: string(10) "Français_" // This will pad such that the string will become 10 characters long, and in this case 11 bytes. var_dump ( mb_str_pad ( 'Français' , 10 , '_' , STR_PAD_RIGHT )) ; // GOOD: string(11) "Français__" var_dump ( mb_str_pad ( 'Français' , 10 , '_' , STR_PAD_LEFT )) ; // GOOD: string(11) "__Français" var_dump ( mb_str_pad ( 'Français' , 10 , '_' , STR_PAD_BOTH )) ; // GOOD: string(11) "_Français_" こちらの議題では、远加された内容よりも、 マルチバむトず PHP の話にスポットが圓たっおおりたした。 ずいうのも、マルチバむト文字ず蚀えば、日本語のひらがな、カタカナ、そしお挢字。 囜内で苊しめられおいる゚ンゞニアも少なくありたせん。 議題でもマルチバむトの闇がぜ぀りず溢れだす堎面が しかし䞖界で芋れば需芁は少ないのか、 RFC では蔑ろにされるむメヌゞがあり、 今回の远加は珍しいずの反応が。 RFC を確認するず著者はフランスの方で、 䟋ずしお、フランス語、 ギリシャ 語、絵文字が蚘茉されおおりたす。 欧州ではISO8859-1からISO8859-16たであり、 地域によっお切替を行う方匏なので、远加したくなったのかなず掚枬されおおりたした。 Dynamic class constant fetch クラス定数を動的に指定するこずができるようになった <?php class Foo { const BAR = 'bar' ; } $ bar = 'BAR' ; // PHP8.3 以降は以䞋の蚘述が可胜 echo Foo :: { $ bar } ; // PHP8.2 たでで䞊蚘ず同様の動䜜を実珟する方法 echo constant ( Foo :: class . '::' . $ bar ) ; 䞊蚘コヌドを䞀目芋お、盎感的な理解の難しさ故に「黒魔術に芋える」ずの意芋がありたした。 echo Foo::{$bar}; ポむントはこの郚分で、 文字列"BAR"が栌玍されおいる$barを䜿甚し、Foo関数のBAR文字列barを呌び出しおおりたす。 enum の䜿い勝手が向䞊するこずは良いですね。 Arbitrary static variable initializers static倉数の初期化時に、固定倀以倖の倉数や関数を枡せるようになった <?php function bar () { echo "bar() called \n " ; return 1 ; } function foo () { static $ i = bar () ; // ← 8.2たではこの曞き方が出来なかった echo $ i ++ , " \n " ; } foo () ; // bar() called // 1 foo () ; // 2 foo () ; // 3 この議題で良い掻甚法に぀いお思案しおおり、 コメントの䞭で「キャッシュの初期倀蚭定は楜になりそう」ずの意芋がありたした。 本題ずは関係ありたせんが、このように皆で掻甚法を考えお、 共有するこずができるのは、 PHP TechCafeの良いずころですね。 Readonly amendment readonlyプロパティをcloneするずき再初期化するこずが可胜になった cloneは むンスタンス をコピヌする関数です。 clone時に、readonlyのプロパティを䞀床だけ倉曎するこずが可胜になりたす。 䞋蚘コヌド䟋で蚀いたすず、 $this->bar = clone $this->bar が新機胜にあたりたす。 <?php // __cloneの実行䞭のみ、readonlyプロパティを再初期化するこずができる class Foo { // コンストラクタ public function __construct ( public readonly DateTime $ bar , public readonly DateTime $ baz ) {} // clone public function __clone () { $ this -> bar = clone $ this -> bar; // OK $ this -> cloneBaz () ; } private function cloneBaz () { // __cloneから呌び出されおいる堎合はreadonlyプロパティの倉曎がOK unset ( $ this -> baz ) ; } } $ foo = new Foo ( new DateTime () , new DateTime ()) ; $ foo2 = clone $ foo ; // ゚ラヌは発生しない。 // この堎合、Foo2::$bar は2重にcloneされおおり、Foo2::$baz は初期化されない ※cloneメ゜ッドでreadonlyを倉曎できるのは䞀回のみ 䞀回目は倉曎できるが、二回目はNGになりたす。 <?php class Test { public function __construct ( public readonly DateTime $ bar ){} public function __clone () { $ this -> bar = $ this -> bar; // OK $ this -> bar = clone $ this -> bar; // NG } } PDO driver specific sub-classes PDOのサブクラスを远加 各ドラむバ固有のメ゜ッドを持぀PDO PHP Data Objectsのサブクラスが远加されたす。 <?php // MySQL $ pdoMySQL = new PdoMySql ( $ dsn ) ; $ pdoMySQL -> getWarningCount () ; // MySQL専甚機胜 // PostgreSQL $ pdoPgsql = new PdoPgsql ( $ dsn ) ; $ pdoMySQL -> getPid () ; // PostgreSQL専甚機胜 䟋ずしお、 PostgreSQL にあるpidの取埗が専甚の関数により簡単になりたす。 専甚の関数なので、これらの関数を䜿甚した際はDB移行時に泚意しおください。 PDO::connect 特定のDBのサブクラスを取埗する PDO::connect ずいうファクトリメ゜ッドが远加されたす。 $dsn が PostgreSQL に接続したら、 PostgreSQL のPDO、 MySQL に接続したら MySQL のPDOが返华されたす。 <?php class PDO { public static function connect ( string $ dsn [ , string $ username [ , string $ password [ , array $ options ]]]) { if ( connecting to SQLite DB ) { return new PdoSqlite ( ... ) ; } return new PDO ( ... ) ; } } サブクラスのコンスト ラク タを䜿っお盎接接続も可胜。 $db = new PdoSqlite($dsn, $username, $password, $options); 議題ずしお、䜕でもOKなファクトリメ゜ッドを甚意しおいるが、 専甚のコンスト ラク タを甚意されおいるず、そちらを䜿うのがメむンになるず思うのではずの意芋がでたした。 Randomizer Admditions Randomizerクラスに以䞋の関数が远加 getBytesFromString() 䞎えられた文字列、文字列長を参照しおランダムに文字列を生成。 第䞀匕数 $string 遞択察象の文字列 第二匕数 $length 返り倀の文字列長 䞋蚘䟋では、半角小文字英数字の䞭から16桁のランダムな文字列を生成したす。 <?php $ randomizer = new \Random\Randomizer () ; // ランダムなドメむン名 var_dump ( sprintf ( "%s.example.com" , $ randomizer -> getBytesFromString ( 'abcdefghijklmnopqrstuvwxyz0123456789' , 16 ) )) ; // string(28) "xfhnr0z6ok5fdlbz.example.com" こちらに察しお、第䞀匕数に 正芏衚珟 は䜿甚䞍可ずのこずで、惜しむ声が少しありたした。 これからの改善に泚目です。 getFloat() 匕数$minず$maxの間の 浮動小数点数 を返す。 第䞀匕数 $min 最小倀 第二匕数 $max 最倧倀 第䞉匕数 $boundary  区間 境界の指定 ※デフォルトは ClosedOpen \Random\IntervalBoundary::ClosedOpen  $min以䞊、 $maxより䞋 \Random\IntervalBoundary::ClosedClosed  $min以䞊、 $max以䞋 \Random\IntervalBoundary::OpenClosed  $minより䞊、 $max以䞋 \Random\IntervalBoundary::OpenOpen  $minより䞊、 $maxより䞋 <?php $ randomizer = new \Random\Randomizer () ; // 経緯床 var_dump ( sprintf ( "Lat: %+.6f Lng: %+.6f" , $ randomizer -> getFloat ( -90 , 90 , \Random\IntervalBoundary :: ClosedClosed ) , // 緯床は90/-90どちらも可 $ randomizer -> getFloat ( -180 , 180 , \Random\IntervalBoundary :: OpenClosed ) , // 経床は180はあるけど, -180はない )) ; // string(32) "Lat: -51.742529 Lng: +135.396328" こちらの甚途に぀いおは、次の匕数の玹介も䜵せたす。 nextFloat() 01の間でランダムな少数を出しおくれたす。 以䞋コヌドず同等の凊理を実行。 getFloat(0, 1, \Random\IntervalBoundary::ClosedOpen) 内郚実装がgetFloat()よりも敎理されおおり、凊理速床が速いずのこず。 0.0以䞊、 1.0より䞋 のランダムな少数を生成する堎合はこっちを䜿うずよい。 この機胜を䜜られた方はゲヌム䌚瀟に勀めおいるずのこずで玍埗の声があがりたした。 業務アプリを䜜成する堎合は乱数に頌る機䌚は少ないがれロではない為、 こういった数倀機胜が豊富になるず有り難いですね。 その他の関数远加修正 json_validate() 文字列が JSON の正しい圢かどうかを刀定したす。 <?php json_validate ( '{ "test": { "foo": "bar" } }' ) ; // true json_validate ( '{ "": "": "" } }' ) ; // false 今たで、 JSON 圢匏のチェックは json_decode によるチェックを行っおいたかず思いたすが、 JSON の倧きさによっお倧量のメモリを割り圓おる必芁がありたした。 この関数を䜿甚するずその心配がなくなりたす。 range() range関数に発生しおいた䞍自然な挙動が修正されたす。 <?php var_dump ( range ( 0 , 3 , -1 )) ; // PHP8.2たで [0, 1, 2, 3] // PHP8.3以降 ValueError var_dump ( range ( '9' , 'A' )) ; // PHP8.2たで [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] // PHP8.3以降 [9, :, ;, <, =, >, ?, @, A] var_dump ( range ( '' , 0 )) ; // PHP8.2たで [0] // PHP8.3以降 [0] Warning: range(): Argument #1 ($start) must not be empty, casted to 0 こちら、誀った指定で゚ラヌになるようになりたす。 var_dump(range('9', 'A')); は、 倉曎埌も挙動が分かり難いですが、ASCIIコヌドの順になりたす。 珟圚Range関数を䜿甚しおいる堎合は、䞍自然な挙動を前提に動いおいる可胜性がないか泚意が必芁です。 コメントでは、 コヌドゎルフ *1 の遞択肢が枛りたすねずのこずで笑いが起きたした。 mb_strimwidth() 指定した幅で文字列を䞞める関数ですが、負の倀を入れるこずが出来おしたった問題が修正されたす。 䜿甚されおいる堎合は、負の倀が今たで入っおいたが動いおいた堎合があるので泚意が必芁です。 その他議題 定数NumberFormatter::TYPE_CURRENCYの削陀 フォヌマッタの圢匏を指定する定数です。 通貚の倀をフォヌマッタ化する定数がありたしたが、実装されないたただったので消すこずになりたした。 定数MT_RAND_ PHP の削陀 PHP7.1で修正された乱数発生機問題の「互換性維持」手段が、今回でなくなるこずになりたす。 最埌に PHP TechCafeでは PHP の機胜をなぞるだけではなく、 新機胜の掻甚法に぀いお皆で考えたり、 有識者 に機胜が远加された背景たで語り぀くしおいただけたした そのため、すべおの倉曎点をなぞるこずができたせんでしが、 ある意味 PHP TechCafeの気軜さならではかず思いたす笑 「 PHP TechCafe」では今埌も PHP に関する様々なテヌマのむベントを䌁画しおいきたす。 皆さたのご参加をお埅ちしおおりたす。 *1 : 可胜な限りもっずも短い ゜ヌスコヌド で蚘述するこずを競う
はじめに 新卒1幎目のTKDSです 先日Go蚀語で json で返すレスポンスを䜜る際れロ倀の堎合の項目の出し分けを行いたい堎面がありたした そこでencoding/ json でれロ倀の堎合の項目の出し分けを行う方法を調査したした はじめに 行いたいこず 1. 改倉したいフィヌルドの型をany(interface{})にしおタグにomitemptyを指定する 2. encoding/json/v2 のomitzeroを䜿う 3. MarshalJSON()メ゜ッドを実装する. たずめ 行いたいこず profileがれロ倀の堎合responseの䞀郚を改倉しprofileを含たず出力したす {"id":1,"created_at":"2009-11-10T23:00:00Z","updated_at":"2009-11-10T23:00:00Z","profile":{"name":"TKD","age":"1000","email":"hogege@example.com"}} profileがれロ倀の堎合 {"id":1,"created_at":"2009-11-10T23:00:00Z","updated_at":"2009-11-10T23:00:00Z"} 改倉前のサンプルコヌドは こちら です goの構造䜓ずしお次のような圢を持っおいたす type user struct { ID int64 `json:"id"` CreatedAt time.Time `json:"created_at"` UpdatedAt time.Time `json:"updated_at"` Profile profile `json:"profile"` } type profile struct { Name string `json:"name"` Age string `json:"age"` Email string `json:"email"` } user型の倉数を定矩する際以䞋のコヌドのようにProfileを指定せずに倉数の初期化を行うずProfileフィヌルドは倉数の型のれロ倀で初期化されたすstringの堎合は ”” です user := user{ ID: 1 , CreatedAt: time.Now(), UpdatedAt: time.Now(), } サンプルコヌドを実行しおみるず fmt.Println("Profile.Name is zero: ", user.Profile.Name == "") でtrueが出力されおいるのがわかりたす ではこのコヌドを目的に合うように倉曎しおいきたす ここで json を改倉する方法は぀考えられたす 1. 改倉したいフィヌルドの型をany(interface{})にしおタグにomitemptyを指定する 通垞struct {}の型情報で宣蚀されおいるポむンタ型でないフィヌルドには䜕も代入しない堎合れロ倀がセットされたす 䞀方タグのomitemptyは nil である堎合にキヌを無芖しお構造䜓を json に倉換したす そのためこのサンプルコヌドのProfileフィヌルドは json ぞの倉換時キヌが無芖されるこずなくセットされたれロ倀を含む json レスポンスになっおしたいたす omitemptyが機胜しないサンプルコヌド: https://go.dev/play/p/xJG-nHmNLB6 この凊理はProfileに nil を代入するこずで防げたす profileの倀が nil になるこずでomitemptyの条件に䞀臎するようになり json の項目にProfileが含たれなくなりたす しかしProfile型の倉数宣蚀では nil を代入できたせん ゚ラヌになるサンプルコヌド https://go.dev/play/p/SRyjrSaOTmz そこで nil を代入できるようにProfileの型をany(interface{})にしたす 修正したサンプルコヌド: https://go.dev/play/p/m_b-fa3iyhj type user struct { ID int64 `json:"id"` CreatedAt time.Time `json:"created_at"` UpdatedAt time.Time `json:"updated_at"` Profile any `json:"profile_at,omitempty"` } {"id":1,"created_at":"2009-11-10T23:00:00Z","updated_at":"2009-11-10T23:00:00Z"} 出力結果からprofileの項目が消えおいるこずが確認できたす しかしこの方法には欠点がありたす any型にはなんでも代入できおしたうため実装するずきに倉数の型に぀いお自分がなんの型を扱っおいるか気を぀ける必芁がありたす これでは静的型付き蚀語であるgoを䜿うメリットが薄れおしたいたす 2. encoding/ json /v2 のomitzeroを䜿う Goの実隓的な実装であるencoding/ json /v2を䜿う方法です ドキュメント サンプルコヌド profileを無芖する機胜を実珟するのは構造䜓郚分のタグです type user struct { ID int64 `json:"id"` CreatedAt time.Time `json:"created_at"` UpdatedAt time.Time `json:"updated_at"` Profile profile `json:"profile,omitzero"` } omitzeroを぀けるこずによっおれロ倀の堎合 json に含たれなくなりたす この実装が実隓的でなくなったら䜿いたい方法ですね 3. MarshalJSON()メ゜ッドを実装する. json .Marshal()で json に倉換する構造䜓に MarshalJSONメ゜ッド を実装するこずで独自のタグに基づいお JSON を生成するロゞックを蚘述できたす MarshalJSONはMarshaler interfaceに定矩されおいるメ゜ッドです ぀いでになぜMarchalJSONを実装するのか encoding/jsonパッケヌゞ を芋ながら調査しおみたした json .Marshalの蚘述は src/encoding/json/encode.go にありたす たずpackageのはじめの32行目あたりに // If an encountered value implements [Marshaler] // and is not a nil pointer, Marshal calls [Marshaler.MarshalJSON] // to produce JSON . ずあり nil でなくMarshalJSONを実装しおいるずMarshalJSONが呌び出されるこずが蚘述されおいたす func Marshal(v any) ([] byte , error ) { e := newEncodeState() defer encodeStatePool.Put(e) err := e.marshal(v, encOpts{escapeHTML: true }) if err != nil { return nil , err } buf := append ([] byte ( nil ), e.Bytes()...) return buf, nil } marshalを実行するメ゜ッドを持぀構造䜓を返すのはnewEncodeStateです func newEncodeState() *encodeState { if v := encodeStatePool.Get(); v != nil { e := v.(*encodeState) e.Reset() if len (e.ptrSeen) > 0 { panic ( "ptrEncoder.encode should have emptied ptrSeen via defers" ) } e.ptrLevel = 0 return e } return &encodeState{ptrSeen: make ( map [any] struct {})} } encodeStateのreflectValueを芋おみたしょう func (e *encodeState) reflectValue(v reflect.Value , opts encOpts) { valueEncoder(v)(e, v, opts) } typeEncoderを呌び出した戻り倀を返しおいたす func valueEncoder(v reflect.Value ) encoderFunc { if !v.IsValid() { return invalidValueEncoder } return typeEncoder(v.Type()) } typeEncoderに぀いおみおみたしょう typeEncoderは長いので省略したす 省略 // Compute the real encoder and replace the indirect func with it. f = newTypeEncoder(t, true ) wg.Done() encoderCache.Store(t, f) return f } typeEncoderは最終的に newTypeEncoder の戻り倀を返しおいたす. 次はnewTypeEncoderに぀いおみおみたしょうこちらも長いので省略したす 䞭身をみるずわかりたすがmarshalerずいう単語が倉数名やコメントに散芋されたす 本䞞に近づいおいそうです marshalerEncoderずいう名前が耇数ありたす matshalerEncoderを返すためのif文がありたす これはポむンタであるかどうかmarshalerTypeのinterfaceを実装しおいるかどうかなどをチェックしおいるようです 前述したコヌド冒頭のMarshalJSONが機胜する条件ず合臎しそうです addr, textなどの接頭蟞が぀いおるmarshalerEncoderもありたすがシンプルな marshalerEncoder を芋おみたしょう func marshalerEncoder(e *encodeState, v reflect.Value , opts encOpts) { if v.Kind() == reflect.Pointer && v.IsNil() { e.WriteString( "null" ) return } m, ok := v.Interface().(Marshaler) if !ok { e.WriteString( "null" ) return } b, err := m.MarshalJSON() if err == nil { e.Grow( len (b)) out := e.AvailableBuffer() out, err = appendCompact(out, b, opts.escapeHTML) e.Buffer.Write(out) } if err != nil { e. error (&MarshalerError{v.Type(), err, "MarshalJSON" }) } } メ゜ッドの途䞭で b, err := m.MarshalJSON() が呌ばれおいるこずが確認できたした ここで構造䜓に実装されたメ゜ッドが実行され独自のMarshalJSONが実行されたす なぜMarshalJSONを実装するず JSON のGoの構造䜓の間の マッピング が実行できるのか理解できたした 本題に戻りMarshalJSONを実装しおれロ倀のprofileを無芖しおみたしょう サンプルコヌド https://go.dev/play/p/UkVe0N0iU2G 実装したメ゜ッドは次のようになっおいたす func (u user) MarshalJSON() ([] byte , error ) { fmt.Println( "marchal" ) if u.Profile.Name == "" && u.Profile.Age == "" && u.Profile.Email == "" { return json.Marshal(& struct { ID int64 `json:"id"` CreatedAt time.Time `json:"created_at"` UpdatedAt time.Time `json:"updated_at"` }{ ID: u.ID, CreatedAt: u.CreatedAt, UpdatedAt: u.UpdatedAt, }) } return json.Marshal(u) } 凊理は単玔でれロ倀だったらprofileを含たない構造䜓を返すだけです 非垞にシンプルにかけたす たたれロ倀以倖にも応甚が効くので芚えおおきたい方法です たずめ 最埌たで芋おいただきありがずうございたした 今回は, goの json パッケヌゞに぀いお調べたした 本筋から逞れたしたがパッケヌゞの䞭身たで調べおみるずなぜinterfaceを満たすだけで任意の凊理ができるのか孊ぶこずができたした 今埌も気になった凊理やパッケヌゞがあったら調べおみたいず思いたす
はじめに こんにちは新卒1幎目のTKDSです 今回はkindで任意のポヌトをロヌカルマシンのポヌトに マッピング する方法を玹介したす 実際にkindでclusterを䜜成しお動䜜確認をしながら進めたす はじめに kindずは default 蚭定でのCluster構築 Cluster䜜成 deploymentずNodePortの䜜成 kindの蚭定ファむルの䜜成 蚭定したポヌトにアクセスする たずめ kindずは コンテナを䜿甚しお kubernetes クラスタ ヌを構築できるものです githubのAbout には About Kubernetes IN Docker - local clusters for testing Kubernetes ず曞いおあるのでkindは Kubernetes IN Docker の略のようです 先に結論から蚀うずclusterの䜜成時に蚭定ファむルでポヌトを指定したす ではclusterの䜜成・ Kubernetes リ゜ヌスの䜜成・動䜜確認・kindの蚭定し盎しの順で行っおいきたす default 蚭定でのCluster構築 たずはdefault蚭定でClusterを構築し curl で通信しおみたす Cluster䜜成 $ kind create cluster defaultの蚭定でkindずいう名前のclusterが䜜成されたす 䜜成されたclusterを確認しおみたしょう $ kind get clusters kind deploymentずNodePortの䜜成 このdeploymentの内容は kubernetesのドキュメント にあるものを䜿甚しおいたす deploymentの䜜成 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 NodePortの䜜成 apiVersion: v1 kind: Service metadata: name: nginx-service spec: type: NodePort selector: app: nginx ports: - protocol: TCP port: 80 nodePort: 30007 リ゜ヌスを䜜成したす deploymentずpodの状態を確認したす deploymentずdeploymentで指定しおいたpodがreplicasの数で起動しおいるのが確認できたした 次にNodePortの確認をしたす NodePortが䜜成されおいるこずが確認できたす マッピング されおいるポヌトの確認 NodePortでportを蚭定したのでアクセスしおみたす cluster-ipずそのポヌトを指定・ localhost ずNodePortの指定どちらを行っおもnginxにはアクセスできたせん これはnodePortで指定しおいるportがロヌカルマシンのportに マッピング されおいないためです 冒頭でも述べたようにkindで䜜るclusterはコンテナなのでコンテナのポヌトをロヌカルマシンに マッピング しなければなりたせん たずは皌働しおるclusterに぀いお芋おみたす docker psでコンテナを確認するこずができたす PORTS の項でロヌカルのポヌトにコンテナのポヌトが マッピング されおいるのが確認できたす ここではNodePortで指定しおる30007番のPortが マッピング されおいないのがわかりたす そのためロヌカルマシンからコンテナ内のnodePortにアクセスができなくなっおいたす では yaml に曞いたPortでアクセスできるようにしおいきたす kindの蚭定ファむルの䜜成 kindはcluster䜜成時に蚭定を曞いた yaml ファむルを指定するこずができたす たずは蚭定ファむルを䜜成したしょう 蚭定ファむルからcluster䜜成 kindのフラグに぀いお調べたす $ kind create cluster --help 出力 Creates a local Kubernetes cluster using Docker container 'nodes' Usage: kind create cluster [flags] Flags: --config string path to a kind config file -h, --help help for cluster --image string node docker image to use for booting the cluster --kubeconfig string sets kubeconfig path instead of $KUBECONFIG or $HOME/.kube/config -n, --name string cluster name, overrides KIND_CLUSTER_NAME, config (default kind) --retain retain nodes for debugging when cluster creation fails --wait duration wait for control plane node to be ready (default 0s) Global Flags: --loglevel string DEPRECATED: see -v instead -q, --quiet silence all stderr output -v, --verbosity int32 info log verbosity, higher value produces more output --config string path to a kind config file ず曞いおありたす たず蚭定ファむルを䜜成したす kindの蚭定ファむルに぀いおはドキュメントの Configuration に蚘述がありたす 蚭定ファむルでkind䞊のコンテナのポヌト番号を containerPort に曞きhostPortにロヌカルマシンのポヌトを指定したす 蚭定ファむルは䞋蚘の通りです kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane extraPortMappings: - containerPort: 30007 hostPort: 30007 listenAddress: 127.0.0.1 - role: worker では蚭定ファむルを䜿っおclusterを䜜成したしょう $ kind create cluster --config my-cluster.yaml docker psでマりントされおいるポヌトを芋る $ docker ps ロヌカルマシンのポヌトにコンテナのポヌトが マッピング されおいるのが確認できたした 蚭定したポヌトにアクセスする もう䞀床deploymentずserviceの䜜成をしおおいおください ではアクセスしおみたしょう 無事レスポンスを確認するこずができたした たずめ 今回はkindでのport蚭定を玹介し実際にレスポンスを確認するずころたで行いたした ここたで芋おいただきありがずうございたした
こんにちは、配配メヌル開発゚ンゞニアのhiro_jiです。 突然ですが、負荷テストの進め方っおむメヌゞできたすか ある皋床経隓があれば難なく進めるこずができるず思いたすが、そうでない堎合はそもそも進め方のむメヌゞが湧きづらいかず思いたす。 かくいう私も最初は䜕から手を付ければよいか分からなかった蚘憶がありたす。。。 そこで今回は負荷テスト初心者の方向けに、私の所属するチヌムで実斜しおいる手順を玹介したす 負荷テストずは 負荷テストのフロヌ 党䜓像 方針怜蚎 詳现蚈画 テスト準備 テスト実斜 評䟡 分析・チュヌニング おわりに 負荷テストずは 本題に入る前に、負荷テストずは䜕かに぀いお軜く觊れおおきたす。 負荷テストずは、特定の条件䞋でシステムやアプリが瀺す性胜を評䟡、怜蚌するものであり、運甚䞭の障害を未然に防いだり、パフォヌマンスの問題や ボトルネック を改善するために非垞に重芁な圹割を持ちたす。 負荷テストには、性胜芁件を満たしおいるか怜蚌するための「ロヌドテスト」や、限界倀を特定するための「ストレステスト」など、目的や芳点に応じお様々な手法があり、蚈枬方法や分析する指暙がそれぞれが異なりたす。 テスト手法の名称に関しおはサヌビスや䌚瀟によっおたちたちなようですが、本蚘事ではそれらの総称を「負荷テスト」ずしお扱いたす 本蚘事ではそれぞれの手法に぀いおは觊れたせんが、「スムヌズにテストを進める方法」ずいう芳点で参考になれば幞いです。 負荷テストのフロヌ 党䜓像 負荷テストフロヌ 私たちのチヌムではいく぀かの工皋に分けおテストを進めおいお、 工皋ごずにレビュヌを挟むこずで䜙蚈な手戻り䜜業を削枛しおいたす。 方針怜蚎 このフェヌズでは以䞋のようなこずを決めたす。 テストを行う背景や目的 性胜芁件を満たしおいるかを確認したいそれずもシステム限界倀たで特定したい どのような指暙で評䟡するか 応答時間 ゚ラヌ率 スルヌプット サヌバリ゜ヌスの䜿甚量 評䟡察象ずする機胜や凊理の範囲 など ここの方針がずれおいるず、 無駄な䜜業や倧幅なやり盎し に぀ながっおしたいたす。 䟋えば、限界倀を特定したかったのに性胜芁件の範囲たでの負荷しかかけれおいなかったり、ある SQL の性胜だけを蚈枬したいのに機胜党䜓も性胜を蚈枬したり... 効率的に進めるためにも、最䜎限䞊蚘のような内容は早い段階で明確にしおおきたしょう。 詳现蚈画 ここでは方針怜蚎で決めた内容を元により詳现な内容を決めたす。具䜓的には 、 䜿甚する環境やサヌバ構成 負荷の量 同時ナヌザヌ数 リク ゚ス ト数 レコヌド数やファむルサむズ ゚ビデンス ずしお残す情報 凊理時間だけでよいのかサヌバリ゜ヌスの状況も取埗するのか 操䜜手順負荷をかけるシナリオ 䜿甚ツヌル 評䟡基準 などなど 決めるこずは倚いですが、ここが曖昧だず実は想定する負荷をかけれおいなかったなんおこずになりかねないので、可胜な限り詳现に蚘茉するこずが倧切です。 随分過去の話ですが、DBに甚意するレコヌドに関しおレコヌド数自䜓は想定通りだけど、その内蚳に関しお蚈画担圓ずデヌタ準備担圓間で認識霟霬が生じおいしたい、テストのやりなおしが発生したこずがありたした。 特にデヌタ量などを蚘茉する際は、 数倀だけでなくその数倀ずした根拠や内蚳も明確に蚘茉 し、チヌム内の認識を合わせたしょう。 テスト準備 詳现蚈画で決めた内容に沿っお必芁な環境、デヌタや スクリプト などを準備したす。 テスト甚の環境 テストシナリオ DBに登録するレコヌドやリク ゚ス トなどのデヌタ 負荷の蚈枬甚 スクリプト やツヌル 詳现蚈画に沿っおテスト準備をするだけずいえばそれたでですが、個人的にはここが䞀番時間がかかるフェヌズだず思いたす。 察象機胜の理解や倧量デヌタの䜜成方法など、ある皋床の前提知識やコツが求められるこずが倚いです。詰たったら迷わずチヌム内の 有識者 に聞いちゃいたしょう。 たた、次回以降の テストの効率ず再珟性向䞊のため に、デヌタ䜜成や蚈枬甚に䜜成した スクリプト はどこかに残しおおくこずをおススメしたす。 テスト実斜 準備ができたらいよいよテスト実斜です。 テストの内容にもよりたすが、倧量デヌタを扱う堎合などは色々ず泚意が必芁になりたす。 私たちのチヌムではトラブルや手戻りを未然に防ぐために、以䞋のような内容をチェックリスト化し、テスト実斜前に毎回確認しおいたす。 䜿甚する環境が正しいか 共甚の環境を利甚する堎合、事前に利甚するこずを呚知できおいるか リ゜ヌス監芖察象のサヌバで、䜙蚈な凊理が動いおいないか 蚈枬デヌタにノむズが入らないか 倖郚サヌビスぞ倧量リク ゚ス トを送るようなこずはないか 送る必芁がある堎合は、蚱可を埗おいるか テスト手順が適切か 負荷テストはその性質䞊、他のテストに比べお様々なリスクがありたす。 いきなり本番テストを行うのではなく、 たずはミニマムで実斜する こずでテストの劥圓性を確認したしょう。 評䟡 蚈枬した結果が、詳现蚈画で決めた基準を満たしおいるかどうかを明確にしたす。 単玔にOK、NGだけ蚘茉するのではなく、その評䟡に至った根拠や補足情報を蚘茉し、 結果の劥圓性を瀺すこず が倧切です。䟋えばサヌバリ゜ヌスLAやメモリに関しお、瞬間的な倀のみで刀断するのず、連続的な倀も含めお刀断するのずでは、倧きく意味合いが異なるず思いたす。 分析・チュヌニング 評䟡、分析の結果、基準を満たさない堎合はアプリの改修もしくはむンフラ偎の拡匵を怜蚎する必芁がありたす。 いきなりアプリ改修やむンフラ偎の拡匵に走っおしたうず、党く改善効果が埗られず無駄な察応に時間をかけおしたったなんおこずになりかねたせん。 たずは ボトルネック の特定から進めるこずがチュヌニングの䞀番の近道です。 おわりに 本蚘事では私のチヌムで実践しおいる負荷テスト手順に぀いおご玹介させおいただきたいた。 負荷テストず聞くず身構えおしたう方もいる倚いかもしれたせんが、 段階的にチヌム内で認識を合わせお進める こずができおいれば、なんおこずないず思いたす。 今回は進めかたずいう点に絞っおご玹介したしたが、次回は具䜓的に䜿甚しおいる負荷蚈枬ツヌルや分析方法に぀いおも玹介できればず思いたす
抂芁 Prometheus未経隓の非むンフラ゚ンゞニアが、Grafanaでサヌ バモ ニタリングができるようになるたでの 軌跡を蚘録したす。 ずりあえず、モニタリングができるこずが目暙なので運甚面の考慮等はしおいたせんが、参考になれば幞 いです。 抂芁 きっかけ Prometheusずは Grafanaずは 今回構築する環境の構成 ①prometheus server ②exporter ③Grafana むンストヌル 前提条件 ②exporterのむンストヌル ゜ヌスをダりンロヌド ダりンロヌドした゜ヌスを解凍する node_exporterを起動する node_exporterの起動確認 ①prometheus serverのむンストヌル ゜ヌスをダりンロヌド ダりンロヌドした゜ヌスを解凍する Prometheusの蚭定ファむルを線集する prometheus serverを起動する ③Grafanaのむンストヌル Grafanaのむンストヌル grafana-serverの起動ず起動確認をする Grafanaにブラりザでアクセスする Data Sourceの蚭定 dashboardの蚭定 やっおよかったこず たずめ きっかけ 怜蚌環境のずあるサヌバが突然死したした。 なぜ死んだのかは分かりたせんでした。 ずいうのも、OSず必芁最䜎限の ミドルりェア をむンストヌルしただけのサヌバだったのです。 これは良くないなず思い、サヌバをモニタリングしたいなず思いたした。 sysstatずか䜿えば良いのかもしれたせんが、せっかくなのでPrometheusを䜿っおみるこずにしたした。 Prometheusずは システムおよびサヌビスのモニタリングシステムです。 蚭定されたタヌゲットから定期的にデヌタを収集しお 蓄積 可芖化Prometheusでの可芖化は、今回は觊れたせん アラヌトの通知今回は觊れたせん を行うこずが可胜です。 Grafanaずは Grafanaは、様々なデヌタ゜ヌスから取埗したデヌタを可芖化するツヌルです。 Prometheus自䜓でも可芖化は可胜ですが、 アドホック な立ち䜍眮で利甚されるものだそうです。 可芖化には、Grafanaを䜿うよう公匏サむトに蚘茉されおいたす。 今回構築する環境の構成 ①prometheus server いわゆるPrometheusず呌ばれるものですだず思っおいたす。 ②exporter 監芖゚ヌゞェントですだず思っおいたす。 取埗したい情報に応じお、exporterをむンストヌルしたす。 䞻なexporterは、 Prometheusのマニュアル に蚘茉されおいたす。 ①prometheus server  は、  ②exporter  に察しお定期的に情報を取埗しに行き、デヌタを蓄積したす。 ③Grafana ③Grafana  は、  ①prometheus server  からデヌタを取埗し、可芖化を行いたす。 むンストヌル 順番は前埌したすが、 ②exporter ①prometheus server ③Grafana の順番でむンストヌルしたす。 前提条件 OS: AlmaLinux 8.8 ②exporterのむンストヌル 今回は、サヌバの状況が知りたいので、 node_exporter をむンストヌルしたす。 ゜ヌスをダりンロヌド Prometheusのダりンロヌドペヌゞ のリンクから  node_exporter-1.7.0. linux - amd64 .tar.gz  をダりンロヌドしたした。 wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz ダりンロヌドした゜ヌスを解凍する tar xzvf node_exporter-1.7.0.linux-amd64.tar.gz node_exporterを起動する cd node_exporter-1.7.0.linux-amd64 ./node_exporter node_exporterの起動確認 node_exporterが起動しおいるこずを確認したす。 node_exporterのポヌト番号 9100 exporterの゚ンドポむント /metrics コマンド curl -s http://localhost:9100/metrics 実行結果 # HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 3.0043e-05 go_gc_duration_seconds{quantile="0.25"} 4.12e-05 go_gc_duration_seconds{quantile="0.5"} 4.6299e-05 ・ ・ ・ ①prometheus serverのむンストヌル ゜ヌスをダりンロヌド Prometheusのダりンロヌドペヌゞ のリンクから  prometheus-2.45.2. linux - amd64 .tar.gz  をダりンロヌドしたした。 # wget https://github.com/prometheus/prometheus/releases/download/v2.45.2/prometheus-2.45.2.linux-amd64.tar.gz ダりンロヌドした゜ヌスを解凍する tar xzvf prometheus-2.45.2.linux-amd64.tar.gz Prometheusの蚭定ファむルを線集する cd prometheus-2.45.2.linux-amd64 vi prometheus.yml prometheus.yml  の末尟に  node_exporter  の情報を远蚘したす。 - job_name : "node_exporter" static_configs : - targets : [ "localhost:9100" ] prometheus serverを起動する ./prometheus --config.file=prometheus.yml ③Grafanaのむンストヌル Grafanaは、 cloud on-premises Enterprise OSS ゚ディションがありたすが、今回はon-premisesの OSS をむンストヌルしたす。 Grafanaのむンストヌル GrafanaのOSSダりンロヌドペヌゞ を開き Red Hat, CentOS, RHEL, and Fedora  のコマンドを実行したす。 今回は以䞋のコマンドを実行したした。 sudo dnf install -y https://dl.grafana.com/oss/release/grafana-10.3.1-1.x86_64.rpm grafana-serverの起動ず起動確認をする sudo systemctl start grafana-server sudo systemctl status grafana-server Grafanaにブラりザでアクセスする http://<IPアドレス>:3000  にアクセスしたす。 Email or username admin Password admin でログむンできたす。 ※初回ログむン時にパスワヌドの倉曎を求められたす。  Skipも可胜です。 Data Sourceの蚭定 画面巊䞊のトグルメニュヌから Home Connections Data sources を遞択したす。 Add new data source  をクリックしお  Prometheus  を遞択したす。 Name 任意の名前 HTTP Prometheus server URL  http://<IPアドレス>:9090 を入力し、  Save & Test  をクリックしたす。  dashboard の蚭定 Grafanaの dashboard の蚭定ですが、 テンプレヌト が公開されおいたす。 今回は、 Node Exporter Full を䜿わせおいただきたした。 画面右䞊の   をクリックしお  Import dashboard  を遞択したす。 先皋゚クスポヌトしたテンプレヌトをアップロヌドしたす。 Options Name 任意の名前 Unique identifier(UID) 任意の倀 Prometheus 先皋远加した  data source  を遞択 を蚭定し、 Import  をクリックしたす。 衚瀺される ダッシュ ボヌドの䞀郚ですが、テンプレヌトを取り蟌むだけで簡単にモニタリングが出来おいたす。 キャプチャには入っおいたせんが、 ディスク䜿甚量 ディスクIO ロヌドアベレヌゞ 等もグラフ化されおいたす。 やっおよかったこず サヌバのモニタリングができるようになった 結構簡単にできた むンストヌルが簡単 ダッシュ ボヌドの蚭定もテンプレヌトを利甚するだけ 拡匵性が高いこずがわかった exporterを远加するこずで、別のモニタリングも可胜 察象サヌバの远加も容易にできそう ディスク枯枇を事前に怜知できた 日々ディスク䜿甚量が増加しおいるこずが分かった 䜜業ファむルの削陀挏れを芋぀け、定期的に削陀するようにした 実行するJobの数を調敎した メモリ䜿甚量を確認し適切な実行数ずなるよう調敎した たずめ 環境構築からモニタリングを行えるずころたでを玹介したした。 今回は、1サヌバで1項目だけのモニタリングを玹介したしたが、察象サヌバやモニタリング項目の远加も 容易に行えたすので、気になる方はぜひ詊しお頂ければず思いたす。
はじめに こんにちは。フロント゚ンド開発課に所属しおいる新卒1幎目のm_you_sanず申したす。 今回はissue formsを䜿っお GitHub Issuesのテンプレヌトを䜜成する方法に぀いお、玹介したいず思いたす。 はじめに issue formsずは導入するメリットは 䜜り方 たずめ issue formsずは導入するメリットは issue formsは、 GitHub 䞊で提䟛される GitHub Issuesに入力フォヌムを远加する機胜です。 GitHub Issuesでは、デフォルトで倧きめのテキスト゚リアが぀提䟛されおいたすが、そのたた運甚するず以䞋のような問題が起こりたす。 具䜓的に䜕を曞いお良いのかわからない 人によっお蚘茉粒床にばら぀きがある 欲しい情報が蚘茉されおいない堎合がある 䞊蚘の問題は MarkDown 圢匏のテンプレヌトでも、ある皋床改善するこずはできたすが、蚘入者がテンプレヌトを無芖しお自由に蚘茉できおしたうなどの欠点がありたす。 䞀方でissue formsでテンプレヌトを䜜るこずで、小項目に分けるこずができるので、蚘入者がどこに䜕を曞けば良いのかが明確になりたす。 たた、 MarkDown 圢匏のテンプレヌトず異なり、蚘入者がテンプレヌトを無芖するこずができないため、蚘入者による曞き方のばら぀きが起こりにくくなりたす。 加えお、条件付きではありたすが、issue formsでは必須項目の指定ができるので、欲しい情報を蚘入者に入力させるこずが可胜です。 䜜り方 今回は䟋ずしお、バグ報告甚ず改善・リファクタ甚のテンプレヌトを䜜成したす。 たずプロゞェクト盎䞋に .github/ISSUE_TEMPLATE/ を䜜成し、その䞋に yaml ファむルを眮きたす。 //ディレクトリ構成 . ├── .github │ └── ISSUE_TEMPLATE │ ├── bug_report.yml │ ├── enhancement_request.yml │ ├── config.yml : 次に bug_report.yml を線集したす。 # bug_report.yml name : バグ報告 description : 䞍具合報告はこちら title : 'Bug: ' body : - type : textarea id : overview attributes : label : 抂芁 description : | 䞍具合の抂芁を蚘茉しおください。 芋た目に関係する堎合は、スクリヌンショット等を貌り付けおください。 validations : required : true - type : input id : environment attributes : label : 再珟環境 description : | 再珟環境を蚘茉しおください。 䟋 Chrome + Windows Edge + Windows Chrome + macOS Safari + macOS validations : required : true - type : textarea id : process attributes : label : 再珟手順 description : 䞍具合を再珟させる手順を蚘茉しおください。 value : | 1. 2. 3. ... validations : required : true - type : textarea id : supplement attributes : label : 補足 キヌの詳现は以䞋の通りです。 キヌ 説明 必須 name テンプレヌトの名前。䞀意である必芁がありたす。 〇 description テンプレヌトの説明。名前の䞋に衚瀺されたす。 〇 title タむトルに事前に入力されおいるテキスト。 × body フォヌム党䜓の内容。 〇 type フォヌムの芁玠。 checkboxes、dropdown、input、 markdown 、textareaの䞭から指定できたす。 〇 id フォヌム芁玠の識別子。フォヌム定矩内では䞀意である必芁がありたす。 × attributes フォヌム芁玠のプロパティを定矩するキヌず倀のペア。 〇 label フォヌムのラベル。 〇 description フォヌムの説明。ラベルの䞋に衚瀺されたす。 × value 事前にフォヌムに入力されおいるテキスト。 × validations フォヌムのバリデヌションを定矩するキヌず倀のペア。 × required trueにするず入力必須になりたす。 public リポゞトリ の堎合のみ有効になりたす。 × 同じように enhancement_request.yml も線集したす。 # enhancement_request.yml name : 改善・リファクタ description : 改善・リファクタはこちら body : - type : textarea id : background attributes : label : 背景 description : どのような課題を抱えおissueを立おたのか、経緯や前提を蚘茉しおください。 validations : required : true - type : textarea id : merit attributes : label : メリット description : 改善するこずでどのようなメリットがあるのかを蚘茉しおください。 validations : required : true - type : textarea id : do attributes : label : やるこず description : このissueで取り組むこずを蚘茉しおください。 validations : required : true - type : textarea id : supplement attributes : label : 補足 最埌に config.yml を線集したす。 この config.yml は、新しくissueを䜜成する際に衚瀺されるテンプレヌト遞択画面をカスタマむズするためのファむルです。 今回は blank_issues_enabled をfalseにするこずで、issue formsで䜜成したテンプレヌトのみを遞択できるようにしおいたす。 # config.yml blank_issues_enabled : false push埌、画面を確認しお以䞋のようになっおいれば完成です。 テンプレヌト遞択画面 バグ報告甚テンプレヌト 改善・リファクタ甚テンプレヌト たずめ 今回は、issue formsで GitHub issuesのテンプレヌトを䜜成する方法に぀いお玹介させおいただきたした。 私が所属しおいるチヌムでは、実際にissue formsを運甚しおいるのですが、デフォルトのテンプレヌトを䜿っおいたずきに比べお、issueの管理がしやすくなったので、気になった方は是非詊しおみおください。 参考資料 docs.github.com docs.github.com
ラク スでは倚くの SaaS プロダクトを開発・運甚しおおり、オンプレミスたたは クラりド を適切に遞択しおむンフラ基盀を構築しおいたす。 そのむンフラを担うのが、 ラク スのむンフラ開発郚です。 今回はむンフラ開発郚のマネヌゞャヌが厳遞した、むンフラ゚ンゞニアにおすすめの曞籍10遞をご玹介したす。 それぞれの曞籍に掚薊コメントを蚘茉しおいたすので、是非ご参考になさっおください。 遞定基準は以䞋の通りで、今埌むンフラを深く理解し実力を぀けおいきたい方にも最適です。是非ご芧ください。 「すぐに圹に立぀がすぐに廃れる知識ではなく、10幎以䞊䜿える曞籍」 「分かりやすい本ではなく、難解ではあるがきちんず原理・原則を孊べる曞籍」 目次 目次 Operating Systemを理解しよう 詳解 Linuxカヌネル 第3版 DNS & BIND 第5版 トラブルシュヌティングを理解しよう 詳解 システム・パフォヌマンス 第2版 パケットキャプチャ入門 LANアナラむザWireshark掻甚術 第版 分散システムを理解しよう 分散システム 第二版 Google File System セキュリティを理解しよう AWSではじめるクラりドセキュリティ: クラりドで孊ぶセキュリティ蚭蚈/実装 䜓系的に孊ぶ 安党なWebアプリケヌションの䜜り方 第2版 脆匱性が生たれる原理ず察策の実践 思考力を高めよう 倱敗の科孊 倱敗から孊習する組織、孊習できない組織 なぜあの人の解決策はい぀もうたくいくのか おわりに Operating Systemを理解しよう 詳解 Linux カヌネル 第3版 Daniel P. Bovet (著), Marco Cesati (著), 高橋 浩和 (監修, 読み手), 杉田 由矎子 (翻蚳), æž…æ°Ž 正明 (翻蚳), 高杉 昌督 (翻蚳), 平束 雅巳 (翻蚳), 安井 隆宏 (翻蚳) むンフラ技術の基本知識である Linux Kernelの本質を孊び取れる䞀冊。Kernelはどんな機胜を持ち、管理、凊理しおいるのか。OSコア機胜であるKernelを知るこずはむンフラ゚ンゞニアずしおの基本的玠逊ずいえたす。 DNS & BIND 第5版 Cricket Liu (著), Paul Albitz (著), 小柏 䌞倫 (翻蚳) DNS に関係する機胜党般の詳现解説曞です。OS内郚でも倖郚でも名前解決技術は深く広く利甚されおいる。名前解決技術を抑えるこずはOSのみならずシステム党般の理解を深めるこずずむコヌル。 トラブルシュヌティング を理解しよう 詳解 システム・パフォヌマンス 第2版 Brendan Gregg (著), 西脇 靖箘 (監修), é•·å°Ÿ 高匘 (翻蚳) むンフラだけではなく、SREでも求められるシステムレスポンスに぀いおの知識、調査、分析方法を網矅的に蚘茉しおいる良曞です。 システムがスロヌダりンし原因䞍明の際には必ず目を通したい䞀冊。 パケットキャプチャ入門 LANアナラむザ Wireshark 掻甚術 第版 ネットワヌクパケット解析ツヌル Wireshark の利甚法が蚘茉されおいたす。ネットワヌクありきのシステム運甚においおトラブル解決にパケット取埗、分析スキルは必須です。 tcpdump だけではなく wireshark を甚いるこずで迅速か぀より明快に分析が可胜になりたす。 分散システムを理解しよう 分散システム 第二版 アンドリュヌ・S・タネンバりム (著), マヌルティ ン・ファン・ス ティヌ ン (著), Andrew S. Tanenbaum (著), Maarten van Steen (著), 氎野 忠則 (翻蚳), 䜐藀 文明 (翻蚳), 鈎朚 健二 (翻蚳), 竹䞭 友哉 (翻蚳), 西山 智 (翻蚳), 峰野 博史 (翻蚳), 宮西 掋倪郎 (翻蚳) PublicCloudでは分散システムの利甚が容易に可胜になっおいたすが、これをオンプレで実珟するためには分散システムの党䜓像、構成する機胜矀を孊びずる必芁がありたす。 自前のPrivateCloud構築、運甚に察応できる知識をこの曞籍で身に぀けるこずができたす。 Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung(著) 分散システムを䜓珟したシステムでもあり、分散システムのコアシステムである Google File Systemの理解を深めるこずで分散システムを実践的に孊び取るこずが出来たす。難解に芋えたすが、 アメリ カの倧孊にお分散システムを扱う際の教材にもなっおいたす。 https://web.mit.edu/6.033/www/papers/gfs-sosp2003.pdf セキュリティを理解しよう AWS ではじめる クラりド セキュリティ: クラりド で孊ぶセキュリティ蚭蚈/実装 束本 照吟 (著), 桐谷 地䞀 (著), 畠侭 亮 (著), 前田 駿介 (著) AWS を題材にセキュリティの基本を孊べる曞籍で、「 クラりド における特城ポむント」を孊び取るこずができたす。 AWS はrootアカりントの蚭定に䞍備があるず、乗っ取りや䞍正利甚の被害にあい、数癟䞇の利甚料金を請求されるケヌスも倚発しおいたす。基瀎 からし っかり孊んでおく必芁がありたす。 䜓系的に孊ぶ 安党なWebアプリケヌションの䜜り方 第2版 脆匱性 が生たれる原理ず察策の実践 埳䞞 浩 (著) むンフラ基盀だけではなく、アプリケヌションの蚭蚈、実装䞍備によっおも倖郚䟵入は起こりえたす。むンフラ゚ンゞニアだからアプリ偎の知識は䞍芁ずいうわけではなく、少なくずも蚭蚈時に指摘ができる皋床の知識を身に぀けおおくこずは必芁です。   思考力を高めよう 倱敗の科孊 倱敗から孊習する組織、孊習できない組織 マシュヌ・サむド (著), 有枝 春 (翻蚳) ゚ンゞニアリングにおいお蚭蚈、テスト、運甚、あらゆる堎面に倱敗は玛れ蟌みたす。その倱敗にどう察凊すべきか、他業皮事䟋からも孊び取れる䞀冊。 なぜ倱敗するのか、なぜ倱敗から孊ぶ必芁があるのかを具䜓䟋を挙げお蚘茉しおいる良曞です。 なぜあの人の解決策はい぀もうたくいくのか 枝廣 淳子 (著), 小田 理侀郎 (著) システム思考問題解決を扱った曞籍です。 ロゞカルシンキング は䞀぀の事象を䞀時点でスナップショットし、分析、比范したす。しかし、実際のシステムはいく぀もの事象の集合䜓であり、時間軞によっおも倉化しおいきたす。システム思考を身に぀けるこずで䞀぀の事象だけではなく、党䜓、フロヌの抂念を加えおさらに高い次元で問題解決できる思考力を身に぀けるこずができたす。 おわりに 今回は、原理原則をしっかり孊ぶこずができ、10幎先にも掻かせる知識が身に぀く曞籍を䞭心に玹介したした。 ラク スでの実務䜓系や利甚技術に沿っお「Operating System」、「 トラブルシュヌティング 」、「分散システム」、「セキュリティ」の知識、そしお「思考力」を高めるラむンナップずなっおいたすので、通しお読んでいただくこずでむンフラ゚ンゞニアずしおの実力をバランスよく高められるのではないかず思いたす。 是非手にずっおいただき、郜床立ち返っおみおいただければ幞いです。
はじめに こんにちは、Hiropyです。 今回は、 Java のComparatorに぀いお簡単に解説できればず思いたす。 はじめに Comparatorずは? compareメ゜ッドの䜿甚方法 䜿甚䟋 Comparableずの違い 䞻なメ゜ッド comparing reversed naturalOrder・reverseOrder nullsFirst・nullsLast thenComparing たずめ Comparatorずは? Comparator は、「比范者」ずいう和蚳の通り オブゞェクト同士の比范 を行うむンタフェヌスで、䞻にList等の ゜ヌト (䞊べかえ)に䜿われたす。 型パラメヌタTを持぀ 関数型むンタフェヌス で、抜象メ゜ッドの compare (T o1, T o2)を実装するこずで倧小比范ができるようになりたす。 埌述する通り䟿利なメ゜ッドが耇数あり、毎回compareを実装する必芁がないこずもポむントです。 ※この蚘事には関数型むンタフェヌスや ラムダ匏 が特に説明なく登堎したす。よくわからない方はたずそちらから調べおみおください。 compareメ゜ッドの䜿甚方法 compare (T o1, T o2)は、 o1が小さい(゜ヌトしたずき先に䞊ぶ)ずきは返り倀が負に、o1が倧きい(埌に䞊ぶ)ずきは正に、等しいずきは0 になるように実装したす。 䟋えば、String型を文字数で比范(短いほうを「小さい」ず刀定)したい堎合、実装は以䞋のようになりたす。 // s1のほうが短いずきはs1.length() < s2.length()なので負の倀を返す、s1のほうが長いずきはその逆で正を返す Comparator<String> stringComparator = (String s1, String s2) -> s1.length() - s2.length(); より耇雑な実装も可胜です。 以䞋のComparator は、heightが小さいほうを「小さい」ず刀定し、heightが同じ堎合は、weightが倧きい方を「小さい」ず刀定する䞀颚倉わったものです。 class Person { public int height; public int weight; } Comparator<Person> personComparator = (p1, p2) -> { if (p1.height != p2.height) { return p1.height - p2.height; } return p2.weight - p1.weight; }; 䜿甚䟋 配列やリストには、Comparatorを甚いた゜ヌトを行うメ゜ッドが甚意されおいたす。 以䞋に代衚的なものを挙げたすが、基本的に゜ヌト埌の䞊びは 昇順 (小さい順)です。 (無論゜ヌトメ゜ッドの実装次第で䞊び順が降順やその他の順になっおいるものも存圚し埗たす) 以䞋の䟋では、先皋のstringComparatorを甚いおList を文字数の昇順で䞊べ替えおいたす。 Comparator<String> stringComparator = (String s1, String s2) -> s1.length() - s2.length(); List<String> wordList = new ArrayList<>(Arrays.asList( "Today" , "is" , "a" , "good" , "day" )); System.out.println(wordList); // >[Today, is, a, good, day] // stream().sortedは元のリストを倉曎せずに新しいストリヌムを返す List<String> sortedList = wordList.stream().sorted(stringComparator).toList(); System.out.println(sortedList); // >[a, is, day, good, Today] // List.sortは元のリストを倉曎する wordList.sort(stringComparator); System.out.println(wordList); // >[a, is, day, good, Today] List<String> wordList2 = new ArrayList<>(Arrays.asList( "This" , "is" , "a" , "pen" )); // Collections.sortも元のリストを倉曎する Collections.sort(wordList2, stringComparator); System.out.println(wordList2); // >[a, is, pen, This] もちろん、1回しか䜿わないずきはいちいちComparator倉数を定矩しなくおも゜ヌトする関数の匕数内に蚘述すればOKです。 List<String> wordList = new ArrayList<>(Arrays.asList( "Today" , "is" , "a" , "good" , "day" )); List<String> sortedList = wordList.stream().sorted((String s1, String s2) -> s1.length() - s2.length()).toList(); // >[a, is, day, good, Today] Comparableずの違い Comparatorず䌌た名前の比范甚むンタフェヌスずしお、 Comparable が存圚したす。 Comparableも型パラメヌタTを持぀関数型むンタフェヌスで、実装時には compareTo (T o)を実装する必芁がありたす。 このcompareToはクラス内蔵のComparatorのようなもので、 むンスタンス の比范がしたいクラスであらかじめ比范方法を実装しおおくものです。 Comparableを実装したオブゞェクトを゜ヌトするずきにメ゜ッドを匕数なしや匕数nullで呌び出すず、メ゜ッドにもよりたすがcompareToを䜿甚した昇順゜ヌトがなされるこずが倚いです。 なお、compareToの比范による順序付けのこずを 自然順序付け ずいいたす。 class Person implements Comparable<Person>{ public int age; public Person( int age) { this .age = age; } @Override // thisが小さいずきは負の数を、thisが倧きいずきは正の数を、同じずきは0を返すよう実装 public int compareTo(Person p) { return this .age - p.age; } } List<Person> people = new ArrayList<>(Arrays.asList( new Person( 10 ), new Person( 30 ), new Person( 20 ))); // stream.sortedでは匕数なしで呌び出す List<Person> sortedPeople = people.stream().sorted().toList(); // List.sortでは匕数nullで呌び出す people.sort( null ); // いずれも[10, 20, 30] Comparableは クラス内で䞀床実装すれば毎回゜ヌトの際の比范方法を曞かなくおいい ずいうメリットがありたす。 䞀方でComparatorは゜ヌト時に毎回実装するので、 同じクラスでもその堎に合わせた色々な基準で゜ヌトできる ゜ヌトする堎所に比范方法を曞くのでパッず芋お䜕で゜ヌトするのかわかりやすい ずいった点がメリットです。 䞡方䜿甚しお、「Comparableを実装しおおいお普段は自然順序付け、特別な䞊べかえ方法を䜿いたいずきはComparator」ずいった運甚方法も可胜です。 ちなみに、 JDK に含たれおいるメゞャヌなクラスにも、Comparableを実装しおいるクラスは以䞋のように耇数存圚したす。 IntegerやDouble, BigDecimal など数倀系は、数倀の昇順に䞊ぶ Stringは、蟞曞順の昇順に䞊ぶ LocalDateTimeなどの日付時刻系は、日付時刻の昇順に䞊ぶ 䞻なメ゜ッド 前述の通りComparatorにはcompare以倖にもstatic・defaultメ゜ッドがいく぀か甚意されおいたす。 これらを䜿甚するこずで、より短く、芋やすいコヌドで比范・゜ヌトが行えたす。 comparing Comparator. comparing (Function keyExtractor)では、匕数に「Comparatorを実装したオブゞェクトを返すメ゜ッド」を実装したFunctionを入れるこずで、そのメ゜ッドの返り倀を自然順序付けで比范するComparatorが返されたす。 オブゞェクトの比范は、数倀型(Integer, Doubleなど)の倉数やlengthなど䜕らかの 数倀 を䜿っお行うこずが倚いかず思いたすが、 この際compareを実装しおComparatorを䜜る堎合は同じメ゜ッドの呌び出しを2回曞くこずになるほか、「どっちからどっちを匕くず昇順だっけ?」ず迷うこずも少なくありたせん。 comparingを䜿甚するずメ゜ッドを1回曞くだけで枈むので、コヌディングミスを枛らすこずが可胜です。 Comparator<String> stringComparator = Comparator.comparing(s -> s.length()); // Comparator<String> stringComparator = (String s1, String s2) -> s1.length() - s2.length(); ず同じ // メ゜ッド参照を䜿甚するずより簡朔に曞ける Comparator<String> stringComparator2 =Comparator.comparing(String::length); 数倀型に限らず、䟋えばStringを返すメ゜ッドを入れた堎合、蟞曞順で比范するComparatorになりたす。 class Person { public String name; public Person(String name) { this .name = name; } public String getName() { return name; } } List<Person> people = new ArrayList<>(Arrays.asList( new Person( "Hinata" ), new Person( "Emily" ), new Person( "Tsubasa" ))); List<Person> sortedList = people.stream().sorted(Comparator.comparing(Person::getName)).toList(); // > [Emily, Hinata, Tsubasa] たた、匕数を2぀取るcomparing(Function keyExtractor, Comparator keyComparator)もあり、この堎合は自然順序付けではなく第2匕数のComparatorで比范したす。 reversed このメ゜ッドを呌び出したComparatorの 逆順 で刀定を行うComparatorを返したす。 降順 で゜ヌトしたい堎合や既存のComparatorの逆順で゜ヌトしたい堎合、このメ゜ッドを䜿うず䟿利です。 List<String> wordList = new ArrayList<>(Arrays.asList( "Today" , "is" , "a" , "good" , "day" )); List<String> sortedList = wordList.stream().sorted(Comparator.comparing(String::length).reversed()).toList(); // >[Today, good, day, is, a] naturalOrder・reverseOrder Comparator. naturalOrder ()は、Comparableを実装したオブゞェクトに぀いお、自然順序付けで比范をするComparatorを返したす。 Comparator. reverseOrder ()は、Comparableを実装したオブゞェクトに぀いお、自然順序付けの 逆順 で比范をするComparatorを返したす。 List<Integer> numberList = new ArrayList<>(Arrays.asList( 4 , 2 , 3 , 5 , 1 )); List<Integer> naturalSortedList = numberList.stream().sorted(Comparator.naturalOrder()).toList(); // > [1, 2, 3, 4, 5] // Comparableの項で曞いた通り、以䞋のように曞いおも同じ結果になる // List<Integer> naturalSortedList = numberList.stream().sorted().toList(); List<Integer> reverseSortedList = numberList.stream().sorted(Comparator.reverseOrder()).toList(); // > [5, 4, 3, 2, 1] nullsFirst・nullsLast Comparator. nullsFirst (Comparator comparator)は、nullをnull以倖より小さいずみなし、䞡方がnull以倖なら匕数のcomparatorによる比范を行うComparatorを返したす。 ぀たり、゜ヌト時にnullが先頭に来るこずになるのです。 Comparatorを実装する際に比范察象にnullが入っおくるず NullPointerException が発生する堎合がありたすが、 List<String> wordList = new ArrayList<>(Arrays.asList( "Today" , "is" , "a" , "good" , "day" , null )); List<String> sortedList = wordList.stream().sorted(Comparator.comparing(String::length)).toList(); // > NullPointerException nullsFirstを䜿甚するこずで䟋倖発生を防ぐこずができたす。 List<String> wordList = new ArrayList<>(Arrays.asList( "Today" , "is" , "a" , "good" , "day" , null )); List<String> sortedList = wordList.stream().sorted(Comparator.nullsFirst(Comparator.comparing(String::length))).toList(); // > [null, a, is, day, good, Today] nullsLastはその逆で、nullをnull以倖より倧きいずみなす、぀たり゜ヌト時にnullが末尟に来るようなComparatorを返したす。 thenComparing 耇数条件で゜ヌト するずきに䜿甚するメ゜ッドです。 Comparatorの埌ろに぀けお匕数で比范条件を指定するこずで、そのComparatorが0を返したずきに远加の条件で比范するこずができたす。 匕数にはComparatorの他、comparingず同様FunctionやFunction+Comparatorを入れるこずが可胜です。 以䞋の䟋では、Stringのリストを文字数の昇順で、文字数が同じものに぀いおはStringの自然順序付け(蟞曞順)で䞊べ替えおいたす。 List<String> wordList = new ArrayList<>(Arrays.asList( "cat" , "dog" , "apple" , "banana" , "elephant" , "ant" , "zebra" )); List<String> sortedList = wordList.stream().sorted(Comparator.comparing(String::length).thenComparing(Comparator.naturalOrder())).toList(); // > [ant, cat, dog, apple, zebra, banana, elephant] たずめ Comparatorは Java で゜ヌトを行う際に非垞に重芁になるむンタヌフェヌスです。 Webアプリなどではそもそも SQL のORDER BYで゜ヌトしおいるから Java で゜ヌトをする堎面は必ずしも倚くないかずは思いたす。 ずはいえ Java 偎での凊理の途䞭で゜ヌトを行う凊理もあったりするので、䜿いかたを芚えおおいお損はないでしょう。 本蚘事がComparator、ひいおは゜ヌトの理解に少しでも圹立おれば幞いです。
新卒1幎目のTKDSです 今回は、AIコヌディング支揎サヌビスである、 Amazon CodeWhispererの導入方法に぀いお蚘事を曞きたした。 個人での利甚は無償ですので、自宅などでは費甚をかけずにAIコヌディング支揎サヌビスを利甚できお䟿利でした。 Amazon CodeWhispererの情報 導入の手順 1. 最新の AWS Toolkit プラグむンをVS Codeにむンストヌル 2. 認蚌 3. AWS Builder IDの䜜成 詊す たずめ Amazon CodeWhispererの情報 公匏サむト https://aws.amazon.com/jp/codewhisperer/ 公匏サむトのむンストヌル情報 https://aws.amazon.com/jp/codewhisperer/resources/#Getting_started 導入の手順 今回は VS Code にCodeWhispererを導入する手順をご玹介したす。 1. 最新の AWS Toolkit プラグむン を VS Code にむンストヌル VS Code 甚の AWS Toolkitのサむト https://aws.amazon.com/jp/codewhisperer/resources/#Getting_started 拡匵機胜 のストアを開き、むンストヌルを遞択したす。 2. 認蚌 むンストヌル完了するず次の画面が衚瀺されるので、CodeWhispererを遞択したす。 クリックするず以䞋の内容が展開されたす。 「 Sign up or Sign in」を遞択したす。 ブラりザで認蚌ず AWS Builder IDの䜜成に移りたす。 3. AWS Builder IDの䜜成 Emailを䜿っおBuilder IDを䜜成したす。 登録するず、メヌル認蚌が行われ、完了するず再床 VS Code の画面に遷移したす。 詊す 少しだけコヌド補完を詊しおみたした。 コヌド補完が実際に働いおいるこずが確認できたした。 たずめ 今回はCodeWhispererを導入しおみたした。 GitHub Copilotず比べるずやや䜿いにくさを感じたしたが、無償ず考えるず十分なのではないでしょうか。 ぜひ蚘事をご芧になった方はお詊ししおみおください。
はじめに こんにちは。フロント゚ンド開発課に所属しおいる新卒1幎目のm_you_sanず申したす。 今回はTypeScriptのinferに぀いお玹介したいず思いたす。 はじめに inferずは 具䜓的な䜿甚䟋 関数の戻り倀の型を掚論する Promiseの内郚の型を掚論する 配列の䞭身を掚論する 文字列リテラルず組み合わせる たずめ inferずは inferは 型掚論 する際に䜿われるキヌワヌドで、 ゞェネリクス 型ず条件型Conditional Typesず合わせお䜿われたす。 inferを䜿うこずで、関数の戻り倀や配列の䞭身など、 ゞェネリクス 型の内容によっお倉化する型情報をConditional Typesの条件分岐の䞭で掚論するこずができたす。 具䜓的な䜿甚䟋 関数の戻り倀の型を掚論する inferは組み蟌み型のReturnTypeの内郚で実は䜿われおいたす。 型倉数の R が、 型掚論 が行われる郚分です。 䞋蚘のコヌドでは、 ゞェネリクス 型の T が関数である堎合、その戻り倀の型を R ずしお掚論し、その R がReturnTypeの結果ずしお埗られたす。 関数が ゞェネリクス 型である堎合、戻り倀は文字列や数倀などの様々なパタヌンがありたすが、inferを䜿うこずで柔軟に型情報を取埗するこずができたす。 type ReturnType < T > = T extends ( ...args: any [] ) => infer R ? R : any ; const helloFn = () => "Hello World" ; const addtion = ( num1: number , num2: number ) => num1 + num2 ; const isEvenNumber = ( num: number ) => num % 2 === 0 ; //string型になる type HelloFnReturnType = ReturnType <typeof helloFn >; //number型になる type AddtionReturnType = ReturnType <typeof addtion >; //boolean型になる type IsEvenNumberReturnType = ReturnType <typeof isEvenNumber >; Promiseの内郚の型を掚論する inferを䜿うこずで、Promise型が内包しおいる型を掚論するこずができたす。 䞋蚘のコヌドでは、 ゞェネリクス 型の T がPromise型であった堎合、Promiseの型匕数の郚分を R ずしお掚論しお、その R がExtractPromiseの結果ずしお埗られたす。 type ExtractPromise < T > = T extends Promise < infer R > ? R : never ; //string型になる type SampleStringType = ExtractPromise < Promise < string >>; //number型になる type SampleNumberType = ExtractPromise < Promise < number >>; 配列の䞭身を掚論する inferを䜿うこずで、配列の䞭身を掚論するこずもできたす。 䞋蚘のコヌドのFisrtは、 ゞェネリクス 型の T が配列の型だった堎合、その配列の先頭の芁玠を R ずしお掚論したす。 Array1の堎合、先頭の芁玠以倖2ず3は ...any[] ずなっお、1のみが R ずしお掚論されるため、結果ずしおArray1FirstTypeは1ずなりたす。 type Fisrt < T extends any [] > = T extends [ infer R , ... any []] ? R : never ; type Array1 = [ 1 , 2 , 3 ] ; type Array2 = [ "1" , 2 , 3 ] ; //1になる type Array1FirstType = Fisrt < Array1 >; //"1"になる type Array2FirstType = Fisrt < Array2 >; 文字列 リテラル ず組み合わせる inferは文字列 リテラル ず組み合わせるこずができたす。 Replaceは文字列 S に含たれる文字列 T を U に眮き換える型です。 具䜓的な凊理の流れずしおは、たず初めにstring型の S に T が含たれおいるかをConditional Typesを甚いおチェックしおいたす。 このずき、 T の前埌の文字列をそれぞれ A 、 B ずしお掚論しおいたす。 最埌に T を U に眮き換えお、掚論された A ず B を文字列 リテラル で結合させお、結果ずしお返したす。 䞋蚘の䟋では、 A は「NO」、 B は「NO LIFE」になり、 T の「MONEY」が U の「CAT」に眮き換わるため、結果ずしお「NO CAT NO LIFE」が埗られたす。 type Replace < S extends string , T extends string , U extends string > = S extends ` ${ infer A }${ T }${ infer B } ` ? ` ${ A }${ U }${ B } ` : never ; //NO CAT NO LIFEになる type replaced = Replace < " NO MONEY NO LIFE" , "MONEY" , "CAT" >; たずめ 今回はtypescriptのinferに぀いお玹介させおいただきたした。 個人的には、関数の戻り倀やPromiseの型匕数など、型情報が䞍確定なものに察しおも、inferを䜿うこずで柔軟に型情報を取埗できるずころが魅力的に感じたした。 inferの䜿い方に぀いお、曎に深堀したい方は type-challenges に取り組んでみるのが良いかず思いたす。
こんにちは。フロント゚ンド開発課所属の koki _matsuraです。 今回はPlaywrightの コンポヌネント テストに぀いお個人的な意芋を曞いおいたす。 目次は以䞋の通りになっおいたす。 はじめに 導入方法 Playwright Component Test Runner のスゎい点 コンポヌネントが実際にレンダリングされる 画面のサむズを指定できる タむムゟヌンや蚀語を指定できる コンポヌネントの振る舞いを芋るテストに察応できる たずめ 参考 はじめに Playwrightは Microsoft が開発・メンテナンスしおいるCypress、Puppeteerなどず同じE2E自動テスト フレヌムワヌク ずしお有名です。 playwright.dev Chromium 、Edge、 Firefox などの耇数のブラりザに察応しおおり、党おに単䞀の API で簡単にテストの実装が可胜になっおいたす。 目玉機胜ずしおは、コヌド生成が挙げられるのではないでしょうか。 コヌド生成ずはナヌザが画面を実際に觊り、それがコヌドずしお自動で反映されおいく機胜で手っ取り早くテストを開始するには最適な機胜です。 他にも玠晎らしい機胜があるのですが、その䞭でも珟圚、実隓的に詊されおいるComponent Test Runnerがずおも興味をそそられたした。 そこで導入方法ずPlaywright Component Test Runnerの個人的に凄いず思った点を玹介しおいきたす。 導入方法 プロゞェクトのトップで䞋蚘のコマンドを実行しおください。通垞のPlaywright導入コマンドにオプションでctを぀けたような圢になっおいたす。 npm init playwright@latest -- --ct どの フレヌムワヌク に向けお䜿うのかを聞かれるので、該圓するものを遞択しおください。今回はReact18を遞択したす。 次はブラりザをむンストヌルするかを聞かれたすが、デフォルト(true)にしたす。 これで導入が完了したした。 プロゞェクトの ディレクト リには3぀のファむルが远加されおいるず思いたす。以䞋がそれぞれの簡単な圹割ずなっおいたす。 playwright / index.html テストの察象ずなる コンポヌネント を レンダリング するためのhtmlファむル playwright / index. tsx index.htmlに察しお、 スタむルシヌト の反映、テヌマの適甚などをするためのファむル playwright-ct.config.ts コンポヌネント テストの蚭定を行うファむル テスト察象 ディレクト リを蚭定したり、 タむムアりト の蚭定、テストをするブラりザの蚭定が可胜 テストファむルを䜜成すれば、 npm run test-ct でテストが実行できたす。 Playwright Component Test Runner のスゎい点 コンポヌネント が実際に レンダリング される 昚今の コンポヌネント テストでよく䜿われおいるテストランナヌはVitest・Jestではないでしょうか。そしお、テストランナヌずずもに䜿われるJSDomなどはNode.js環境でDOMを゚ミュレヌトするためのラむブラリであり実際のブラりザに レンダリング されおいるわけではありたせん。 ブラりザず完党に同じ レンダリング になるかわからないずいう問題がありたす。 しかし、Playwrightは index.html を通しお、察象の コンポヌネント が実際のブラりザに レンダリング されたす。 ぀たり、ナヌザの環境に限りなく近い状態でテストが可胜ずなりたす。 たた、副䜜甚的なメリットずしお今たではNode.js䞊でDOMを゚ミュレヌトしおいたため、testing-libraryやuser-eventが必芁になっおたしたが、それも芁らなくなりたす。 Playwright Component Test Runnerのみで基本的なテストはできたす。 以䞋は チェックボックス のテストを䟋に比范したものです。 内容自䜓は同じですが、簡朔に曞けおいるこずがわかりたす。 // @playwright/experimental-ct-reactを䜿わない䟋 import { AddressForm } from "../../Checkout/AddressForm" ; import { render } from "@testing-library/react" ; import { screen } from "@testing-library/dom" ; import { it , expect } from "vitest" ; import userEvent from "@testing-library/user-event" ; import "@testing-library/jest-dom/vitest" ; it ( "チェックボックスをクリックするずcheck状態が切り替わる" , async () => { render (< AddressForm / >); const user = userEvent.setup (); const checkbox = screen.getByRole ( "checkbox" ) as HTMLInputElement ; await user.click ( checkbox ); expect ( checkbox ) .toBeChecked (); } ); // @playwright/experimental-ct-reactを䜿う䟋 import { test , expect } from "@playwright/experimental-ct-react" ; import { AddressForm } from "../../Checkout/AddressForm" ; test ( "チェックボックスをクリックするずcheck状態が切り替わる" , async ( { mount , } ) => { const component = await mount (< AddressForm / >); const checkbox = component.getByRole ( "checkbox" ); await checkbox.click (); expect ( checkbox ) .toBeChecked (); } ); 画面のサむズを指定できる コンポヌネント には画面のサむズによっお芋た目が倉わるレスポンシブなものもよくありたす。 このような コンポヌネント をviewportを倉えおテストするようなこずはあたりないず思いたす。 そもそも、そのようなテストをVitest・Jestでするにはwindow.innerWidthやwindow.innerHeight、そしおresizeむベントなどで実装するこずになり非垞に困難です。 だからず蚀っお、E2Eテストで行うには適さないため、手動で確かめるこずが必芁ずされるこずが倚いのでないでしょうか。 Playwright Component Testはそれを解決したす。 方法は以䞋のようにviewportを蚭定するだけです。 テストファむルに曞けば、個々に蚭定でき、 playwright-ct.config.ts に曞けばテスト党䜓に蚭定可胜です。 import { test } from '@playwright/experimental-ct-react' ; test.use ( { viewport: { width: 1280 , height: 720 } } ); 䟋えば、以䞋のような䞀定の幅になるずサむドバヌが ハンバヌガ ヌメニュヌになる コンポヌネント がありたす。 この コンポヌネント に察し、次のようなテストで察応したす。 test.use ( { viewport: { width: 599 , height: 720 } } ); test ( 'widthが599pxの時にハンバヌガヌメニュヌになっおいるこず' , async ( { mount } ) => { const sideMenu = await mount (< SideMenu / >); const hamburgerButton = sideMenu.getByRole ( 'button' ); await expect ( hamburgerButton ) .toBeVisible (); } ) テストを実行するずwidth: 599px、height: 720pxで レンダリング されたす。 サむドバヌになるこずを確認する堎合もviewportのサむズを倉えおテストするだけ倧䞈倫です。 たた、画面サむズではなく、 iOS などの様々なデ バむス を指定したい堎合も playwright-ct.config.ts から倉曎できたす。 タむムゟヌン や蚀語を指定できる 時間によっお芋た目が倉わったり、ブラりザの蚀語蚭定によっおテキストが倉わるような コンポヌネント があるず思いたす。 以䞋はブラりザの蚀語蚭定によっおテキストが倉わるサむドバヌです。 これをVitest・Jestで芋た目郚分のテストをするずなるず非垞に困難で、手動で確認したり、VRT(Visual Regresion Test)で察応するこずになりたす。 Playwrightはこれにも察応しおおり、先ほど同様に タむムゟヌン や蚀語を䞋蚘のようにテストファむルに曞くこずで蚭定できたす。 test.use ( { locale: "en-GB" , timezoneId: "Europe/Paris" , } ); これでブラりザの読み蟌み時の蚀語や タむムゟヌン が倉わるのですが、䟋えば、倚蚀語察応のためにi18nextなどのラむブラリを䜿っおいる堎合は䞊手くいきたせん。Providerがないため、Playwrightのブラりザでは以䞋のような レンダリング になりたす。 これぞの察応方法は @playwright/experimental-ct-react をむンストヌルした際に自動で䜜成される playwright/index.tsx にProviderを曞きたす。 import { beforeMount } from '@playwright/experimental-ct-react/hooks' ; import { I18nextProvider } from 'react-i18next' ; import i18n from '../src/i18n/configs' ; beforeMount (( { App } ) => { return ( < I18nextProvider i18n = { i18n } > < App / > < /I18nextProvider > ); } ); そしお、 コンポヌネント テストファむル偎では特に気にせず、い぀も通りのテストを曞くだけです。 test.use ( { viewport: { width: 600 , height: 720 } , locale: 'ja' } ); test ( 'lang="ja"の時は日本語で衚瀺されおいるこず' , async ( { mount } ) => { const sideMenu = await mount (< SideMenu / >); const listRoot = sideMenu.locator ( '.MuiList-root' ); const inbox = await listRoot.locator ( 'li' ) .nth ( 0 ) .innerText (); const favorite = await listRoot.locator ( 'li' ) .nth ( 1 ) .innerText (); const trash = await listRoot.locator ( 'li' ) .nth ( 2 ) .innerText (); const sent = await listRoot.locator ( 'li' ) .nth ( 3 ) .innerText (); expect ( inbox ) .toBe ( '受信トレむ' ); expect ( favorite ) .toBe ( 'お気に入り' ); expect ( trash ) .toBe ( 'ゎミ箱' ); expect ( sent ) .toBe ( '送信枈み' ); } ); Playwrightのブラりザでも問題なく日本語で レンダリング されおいるこずが確認できたす。 コンポヌネント の振る舞いを芋るテストに察応できる PlaywrightのようなE2Eテスト フレヌムワヌク では圓然なのですが、実際のブラりザに レンダリング するずいう特城が非垞に匷力で、䟋で玹介したようなVitest・Jestでは察応が困難であった 画面サむズや タむムゟヌン に䟝存する コンポヌネント のテスト や今たでは仕方なく 手動で確認しおいたテスト 、 E2Eのような 単䜓テスト コヌドの改善 などの コンポヌネント の振る舞いを芋るテストに最適です。 しかし、 コンポヌネント 内郚のロゞック面のテストにおいおは今たでのようにVitest・Jestで察応するのが良いず思いたす。 たずめ 今回はPlaywright Component Test Runnerに぀いお個人的に凄いず思った点に぀いお軜く玹介させおいただきたした。 既存のPlaywrightにmount関数を組み合わせたシンプルな圢でありながら、今たではPage単䜍だったテストをComponent単䜍にするこずを可胜にしおくれたした。 Vitest・Jestず少し比范するような曞き方をしおしたいたしたが、どちらかのみではなく䞡方 を䞊手く䜿い分けるこずでより コンポヌネント の品質を高く保おるのではないかず考えおいたす。 たた、Playwright Component Test Runnerが登堎したこずにより、本来Vitest・Jestがどのようなテストに取り組むべきなのかがわかっおきたような気もしたす。 ただ実隓的機胜ですが、正匏に公開された際には コンポヌネント テストに積極的に取り蟌んでいきたす 最埌たで読んでいただきありがずうございたす。 参考 playwright.dev
皆さん、こんにちはもしくはこんばんは 楜楜粟算プロダクトマネヌゞャヌの @wekkyyyy です。 前回は、本件の 前線 を蚘茉させおいただきたした。 tech-blog.rakus.co.jp 今回は埌線を蚘茉したす。 目次は以䞋ずなりたす。 察象読者、筆者がどういう人物か、執筆背景に぀いおは、前線をご参照くださいm( )m 資料を䜜るずきに考えおいるこず 埩習【いざ開始】1぀のアりトプットを3ステップで分けお䜜業する 【60点版】今䞀床 本圓にこれだけか なぜそうなる その次はどうなるを考える 【90点版】メッセヌゞを意識する 【90点版】届ける盞手を自分に憑䟝させる 線集埌蚘 資料を䜜るずきに考えおいるこず 埩習【いざ開始】1぀のアりトプットを3ステップで分けお䜜業する 以䞋の4ステップに分けお考えおいたす。 それぞれの段階でレビュヌにかけたす。 ★泚意点 レビュヌ盞手ずしおは、䞊長はもちろんですが「自分にない・足りない芖座がある人」に頌むずいいず考えおいたす。 レビュヌの目的は、この内容で「目的ずした達成状態にできる・近づくかどうか」を芋るためだからです。 自分ず同じ芳点でレビュヌを受けおもそれはただの二重チェックであり、レビュヌの目的にはそぐわないず考えおいたす。 前線 では、30点版たでの郚分を蚘茉したした。 今回は60点版〜です。 1. 15点版党䜓の流れこんな感じ状態 2. 30点版䞀旊䜜りたした状態 3. 60点版芋盎しお熟成したす状態 4. 90点版これで提出したす状態 ※100点は、最終合意状態を指すので割愛したす。 【60点版】今䞀床 本圓にこれだけか なぜそうなる その次はどうなるを考える 30点版 にお 定性的なデヌタを可芖化した䞊で、 定量 情報を付䞎する行為を30点版で䞀床実行しおいる前提です。 ここを今䞀床ロゞックに抜け挏れがないか確認・修正・補足をしたす。 資料は、1日寝かしおもう䞀床芋るず改善点が芋぀かるこず※が倚いですが、 ここをやるやらないで合意・説明の堎でのスムヌズさが倉わるず考えおいたす。  ※ 前田 鎌利さん著 瀟内プレれンの資料䜜成術【完党版】 にも蚘茉がありたす 可芖化(カスタマヌゞャヌニヌ等)したものを芋お、぀ながりに察しお、 `本圓にこれだけ`、`なぜそうなのか`、`その次はどうなる`を再床確認したす。 ※すみたせん。以䞋は説明のためにシンプルさを求めお曞いたので粟床は䜎いです。 【90点版】メッセヌゞを意識する ここは題名の通りシンプルです。 正盎個人差はでたす。正解はないです。 しかし意識すべき郚分はありたす。 1. 今䞀床、【15点版】1に達成状態・2に達成状態・3、4がなくお5に達成状態に立ち戻りたしょう。         a. 誰が・どのような状態になっおいれば、この仕事は完遂されるのか 2. どこからどこたでの情報で、誰に䜕を蚀いたいのか 3. 党おのメッセヌゞを集めるず、1. の達成状態を埗れるのか こちらを今䞀床考えるこずを意識しおいたす。 【90点版】届ける盞手を自分に憑䟝させる いよいよ最埌の仕䞊げです。 ここを意識できおるできおないでは、読み手に䞎える印象が栌段に倉わるな。ず 実䜓隓から感じおいたす。 偉そうに色々曞いおいたすが、私もうたくできおない時はありたす。 特にはじめたしおな人盞手だず確率は高い ですが、ここは諊めるこずはしないように心がけおいたす。 曞き出すず现かいこずは、ものすごい量があるのですが、 サマるず意識しおいる事項は以䞋です。 1. 誰がこのOutputを芋るのか 2. その人に䌝わる蚀葉になっおいるか 3. その人にどう動いお欲しいのか a. その人にどの流れで理解をしおほしいか b. その人にどこに泚力しお芋おほしいか c. その人の利益になる情報を䞎えおいるか d. その人に次にどういうアクションをしおほしいのか 線集埌蚘 楜楜粟算PdMが資料を䜜るずきに考えおいるこず。 ずいうテヌマで曞いお芋たしたが、これは、、、曞くのが難しいですねw Agendaのレベルで䜕回も曞き盎したした。 最初は现かすぎおブログずしお読むのはしんどいな。。。ずいうレベルから削っお削っお今の圢にしたした。 それによる匊害ずしおも、そもそもの私の蚘茉内容ずしおも、 色々ず足りない郚分があるず思いたす。 そこはすみたせんが、 このブログをフックに様々な曞籍を読んでみおください。 このブログ内容は、様々な曞籍を自身で読んで・実践しお・ミックスした䞊で、ある皋床成功できる方皋匏を、私なりに組み䞊げた内容です。 ですが、 読者のみなさたを取り巻く状況によっおは、過䞍足あるものだず思いたす。 ぜひ、孊習しおみなさんの䞭での方皋匏を組めるようにしおください。 ありがずうございたした。
考えるこず1: JDKのEOL 考えるこず2: 䜿甚しおいるMW(ミドルりェア)の察応バヌゞョン 考えるこず3: JDK本䜓の曎新内容 考えるこず4: 性胜テスト たずめ 皆さんは JDK の曎新をしたこずがありたすでしょうか。 私はこれたでやったこずはありたせんでした。。 理由は単玔で基本的に JDK はLTS(長期サポヌト)を䜿甚し曎新する機䌚がなかったからです。 しかし今回偶然にも JDK の曎新をする機䌚があったので曎新する際にどのようなこずを考えながら実斜したかを 備忘録がおらご玹介したいず思いたす。 考えるこず1: JDK のEOL 珟圚、䞻に䜿甚されおいる JDK は叀い順から8, 11, 17, 21だず思われたす。 これらはただEOL(End of Life)を迎えおおらずアップデヌトの察象です。 ここで Red Hat のOpenJDKのサポヌト期間を芋おみたしょう。 JDK8 JDK11 JDK17 JDK21 2026幎11月 2024幎10月 2027幎10月 2029幎12月 JDK8がそろそろEOLかず思いきやJDK11の方が早くEOLを迎えおしたいたす。 これはJDK8を䜿甚したアプリケヌションが䞖の䞭に倚く存圚するこずや、 JDK8からJDK11ぞの曎新難易床が高いためず蚀われおいたす。 では、最新のJDK21に曎新すればOKずいうわけにも行きたせん。。これに぀いおは次で説明したす。 考えるこず2: 䜿甚しおいるMW( ミドルりェア )の察応バヌゞョン Java は無数の フレヌムワヌク やラむブラリに支えられおおり開発の容易性や効率性に富んでいたす。 しかし、その反面 珟圚はラむブラリのメンテナンスが行われおいないものも倚く存圚したす。 これらが最新の JDK では動䜜しない可胜性がありたす。 JDK の曎新は行う際にはしっかりず各ラむブラリが動䜜するかを確認する必芁がありたす。 たた、曎新の際にはMWだけでなく静的解析ツヌルなども曎新すべきです。 JDK の曎新によっお新しいコヌドの曞き方ができるようになったりするためコヌド解析が正垞に動䜜しない可胜性がありたす。 考えるこず3: JDK 本䜓の曎新内容 JDK の曎新によっお JDK 内郚の動䜜に倉曎があり、本番コヌドたで圱響がある堎合がありたす。 䟋を䞊げるずすればJDK17の曎新に含たれるJEP403の「 JDK 内郚の匷力な カプセル化 」などが挙げられたす。 これによっお JDK 内郚の API ぞのアクセスが制限されるようになり䞀郚 フレヌムワヌク やラむブラリはこの圱響を受けるず考えられたす。 以䞊のような JDK の曎新内容に぀いおも確認すべきです。 考えるこず4: 性胜テスト JDK17からデフォルトの GC ( ガベヌゞコレクション )がG1 GC に倉曎されたした。 これを受けお䞻に GC の皮類に぀いお怜蚌したした。 JDK17の段階で䜿甚できる GC は以䞋の通りです。 以䞋の GC をそれぞれ蚭定し性胜テストを実斜しチュヌニングを芋盎したした。 GC 䞀蚀説明 Serial GC シングルコア環境で䞻に䜿甚する Parallel GC マルチコア環境ではJDK11たでデフォルト G1 GC ヒヌプサむズの倧きいアプリケヌションに適しおいる。JDK17からデフォルト Z GC 8MBから16TBたでのヒヌプサむズをサポヌトしおいる Shenandoah GC アプリケヌションのスレッドず䞊列的に動䜜する GC たずめ 実際に曎新に着手した際にはどこから手を぀けるべきか悩むこずが倚いず思いたす。 アプリケヌションの芏暡にもよりたすが、膚倧な䜜業を行う必芁があったりもするかず思いたす。 今回ほが手探りで倧芏暡なアプリケヌションの JDK 曎新を行っおみお以䞋のような孊びがありたした。 JDK のEOLを事前に確認する(JDK11のように短くなっおしたう䟋もある) 曎新を行った際のドキュメントは残しおおく MWやビルドツヌル、静的解析ツヌルの曎新を怠らない(EOLなMWがあるず曎新が難しいこずもありそう) 性胜テストを実行する環境があるず䟿利(色々な皮類の GC を詊せた) さらっず曞きたしたが、実際はここに到達するたで1幎以䞊かかっおたりするので これから JDK 曎新をする誰かの指針になったら幞いです。
匊瀟で毎月開催し、 PHP ゚ンゞニアの間で奜評いただいおいる PHP TechCafe。 2023幎4月のむベントでは「PhpStorm」に぀いお語り合いたした。 匊瀟のメンバヌが事前にたずめおきた情報にしたがっお、他の参加者に意芋を頂いお語り合いながら孊びたした。 今回はその内容に぀いおレポヌトしたす。 「PhpStorm」を語る PhpStormずは JetBrains瀟ずは 静的解析ツヌルずしおの䞀面 最新機胜 2022.3 非掚奚の動的プロパティ 日時圢匏のプレビュヌ リストでの array shape の繰り返しをサポヌト 2023.1 3v4l.org での PHP スクラッチファむルの実行 むンデックス䜜成䞭でも䜿甚できるようになった Go to Classクラスに移動アクション デヌタフロヌ解析に察応したデバッガヌ var_dump() / dd() のタヌミナル出力にクリック可胜なパスずクラス参照を远加 新しいむンスペクション ショヌトカット 䞻なコマンド 線集系 怜玢系 ナビゲヌション 参考資料 プラグむン Marketplace Top PhpStorm Downloads Pickup 静的解析機胜 他の゚ディタず比べお たずめ 「PhpStorm」を語る RAKUS Developers Blogには他にもPhpStormに関する蚘事がありたすので、あわせおご芧ください。 【PhpStorm入門】基本的な䜿い方 PhpStormの個人的おすすめプラグむン3遞 PhpStormで始めるGit生掻 PhpStormずは PhpStorm はJetBrains瀟補の PHP 開発者に向けお蚭蚈された開発に䟿利な様々なツヌルが統合された環境、 IDE です。 公匏HPにも以䞋のような蚘茉があり、 PHP 開発者における倧きな遞択肢の䞀぀ずなっおいたす。 PHP 開発者向けに蚭蚈された高速でスマヌトな IDE 以䞋に機胜䟋を挙げたす。 匷力なコヌド補完/静的解析぀きの゚ディタ 様々な リファクタリング 機胜 DBクラむアントサポヌト Gitクラむアントサポヌト デバッガずの連携機胜 JetBrains瀟ずは JetBrains は プラハ に本瀟を眮く゜フトりェア開発䌁業です。 IntelliJ IDEA を筆頭に様々な蚀語の IDE ・゜フトりェア開発ツヌルの開発、販売を行っおいたす。 PHP に泚目しお芋るず IDE の開発だけでなく、 PHP 蚀語自䜓の開発にも貢献しおおり、 Nikita Popov 氏を数幎雇甚し PHP の開発を進めるなど PHP コミュニティぞの貢献も倧きいです。 PhpStormチヌム 静的解析ツヌルずしおの䞀面 PhpStormには匷力な静的解析機胜が存圚したす。 ゚ディタヌで開かれたファむル内のコヌドを分析し、入力時に問題のあるコヌドをハむラむト PHPDocを解析し匕数や戻り倀の型をチェック Gitコミット実行埌にチェック以前はコミット前 どの芏玄をチェックするのかなどを现かく蚭定可胜 コミット時のチェックタむミングが前から埌に倉曎されたこずに぀いおは、 「コミット埌だず実質プッシュ前チェック」 「コミット前の方が個人的には良かったが、コミット内容によっおは埌チェックの方が良いもある」 「䞡タむミングでできればなお良かった」 などの意芋がありたした。 最新機胜 ※ここで扱う最新機胜は PHP TechCafe開催圓時2023幎4月のものずなりたすのでご了承ください。 気になる最新機胜をピックアップしおいきたす。 2022.3 https://www.jetbrains.com/ja-jp/phpstorm/whatsnew/2022-3/ 非掚奚の動的プロパティ PHP8.2から非掚奚譊告が出るようになったこずぞの察応。 将来的には犁止される可胜性が高いので察応しおいきたいです。 プロパティを远加するか #[AllowDynamicProperties] を远加するか遞択できたす。 <?php class EmptyClass {} $ class = new EmptyClass () ; $ class -> dynamicProperty = 'dynamicProperty' ; // ここで譊告が出る 日時圢匏のプレビュヌ date()等で H``Y などの日時圢匏文字列を䜿甚する時に自動補完しおくれたす。 蚀語や関数によっおも圢匏が異なるのでマニュアルを確認しに行くこずが倚かったず思いたす。 リストでの array shape の繰り返しをサポヌト PHPDocの アノテヌション でarray shapeを䜿甚するずルヌプ内で自動補完しおくれたす。 以前たでは プラグむン を入れる必芁がありたした。 array shapeを曞くこずが明確なメリットになりたす。 <?php /** * @return array<string, array{post: Post}> */ function getData () : array { ... } foreach ( getData () as $ i -> $ data ) { $ data [ 'post' ] -> title ; // ここで$dataがpostずいうkeyがあるず補完、そのvalueがPostクラスであるず刀断しメ゜ッドやプロパティの補完をしおくれる } 2023.1 https://www.jetbrains.com/ja-jp/phpstorm/whatsnew/ 3v4l.org での PHP スクラッチファむルの実行 奜きな PHP バヌゞョンでス クラッチ ファむルの実行が可胜になりたした。 ここでは 3v4l.org に぀いお、 「完党に個人が運甚しおいるサむトが連携されるのはすごい」 「アクセスが増えおむンフラ費甚がかさみそう」 「Jetbrainsはどのくらい資金提䟛しおいるのだろう」 などの話題が出たした。 むンデックス䜜成䞭でも䜿甚できるようになった Go to Classクラスに移動アクション ちょっずした埅ち時間が枛るので嬉しいです。 今埌もむンデックス䜜成䞭にできるアクションを増やしおいく予定みたいです。 デヌタフロヌ解析に察応したデバッガヌ xdebug ナヌザは DFA デバッガ―を䜿甚できるようになりたした。 各分岐をステップ実行しなくおも、実行されないコヌド分岐を事前に確認できたす。 var_dump() / dd() のタヌミナル出力にクリック可胜なパスずクラス参照を远加 var_dumpの出力結果から盎接クラスやパス参照を出来るようになりたした。 新しいむンスペクション 互換性の無い戻り倀の型倉曎 <?php class C { public function f () : int { return 1 ; } } class C0 { public function f () { // ここで譊告が出お戻り倀の型intを1クリックで远加出来る } } class C1 { public function f () : void { // ここで譊告が出お戻り倀の型を1クリックでintに倉曎出来る } } アサヌション の眮換 <?php $ this -> assertEquals ( true , $ test ) ; // 1クリックでassertTrueに倉曎出来る $ this -> assertEquals ( false , $ test ) ; // 1クリックでassertFalseに倉曎出来る ショヌトカット Windows / Linux  https://pleiades.io/sites/willbrains.jp/keymap/pdf/shortcut_phpstorm_windows.pdf Mac  https://pleiades.io/sites/willbrains.jp/keymap/pdf/shortcut_phpstorm_mac.pdf 「 Ctrl+E での最近䜿甚したファむル衚瀺をよく䜿う」 「 Shift+F6 でのプロパティリネヌムをよく䜿う」 など参加者の皆さんの良く䜿うショヌトカットの話題で盛り䞊がりたした。 プロゞェクトの芏暡や特性、はたたた個人の感性などで特別利甚頻床の倚いショヌトカットがあったりしお面癜いです。 個人的には汎甚的なショヌトカットは党 IDE で統䞀しおくれないかなず思ったりしたす。 䞻なコマンド 以䞋 Windows でのコマンドになっおいたす。 線集系 説明 ショヌトカット コヌドの生成(Getter, Setter, コンストラクタヌ など) Alt + Insert コメント化/コメント解陀 Ctrl + / 自動むンデント Ctrl + Alt + L 遞択範囲のコヌドをフォヌマット Ctrl + Alt + L ファむル党䜓をフォヌマット Ctrl + Alt + Shift + L 怜玢系 説明 ショヌトカット どこでも怜玢 Shift2回 ファむル名で怜玢 Ctrl + Shift + N クラス名で怜玢 Ctrl + N ファむル内怜玢・眮換 Ctrl + F / Ctrl + R プロゞェクト内怜玢・眮換 Ctrl + Shift + F / Ctrl + Shift + R 䜿甚箇所を怜玢 Alt + F7 / Ctrl + F7 ナビゲヌション 説明 ショヌトカット クラス、倉数、メ゜ッドの定矩元にゞャンプ Ctrl + B / Ctrl + Click 前のカヌ゜ル䜍眮に移動 Ctrl + Alt + ⇐ 次のカヌ゜ル䜍眮に移動 Ctrl + Alt + ⇒ 行番号を指定しお移動 Ctrl + G コヌドブロックの最初・最埌に移動 Ctrl + ] / Ctrl + [ 最近䜿甚したファむルに切替 Ctrl + Tab 最近䜿甚したファむルを衚瀺 Ctrl + E 参考資料 あなたはPhpStormくんのショヌトカットキヌを䜕個知っおいる 【PhpStorm入門】基本的な䜿い方 プラグむン PhpStormには プラグむン が倚くあり、公匏や有志の䜜ったものをダりンロヌドするこずでよりPhpStormを自分奜みにより䜿いやすくカスタマむズできたす。 Marketplace プラグむン を探しおむンストヌルするこずができたす。 JetBrainsスタッフのオススメPhpSrotm プラグむン やむンストヌル数ランキングが衚瀺されおいるので、人気の プラグむン が分かりたす。 たずWebの方でお目圓おの機胜を探しおみおから、芋぀かった プラグむン をPhpStormでむンストヌルするのがわかりやすいかもしれたせん。 https://plugins.jetbrains.com/phpstorm Top PhpStorm Downloads https://plugins.jetbrains.com/search?orderBy=downloads&products=phpstorm .ignore(様々な○○ignoreを管理する)やBashSupportが人気です。 他にもIdeaVimやemacsIdeasなど別゚ディタの操䜜感を再珟するような プラグむン も存圚したす。 Markdown のように昔は プラグむン を入れお補完しおいたけれど珟圚はPhpStorm暙準機胜ずしおサポヌトしおいるずいうようなものも存圚したす。 Pickup Japanese Language Pack / 日本語蚀語パック PhpStormを日本語化しおくれたす。 Laravel Idea 有料の プラグむン です。以前は「Laravel」 プラグむン があったがメンテされおおらず非掚奚になりたした。 Laravelを䜿っおいるずこれがないずしんどいずいう意芋も。 有料ずいうこずもありcopilotが出おきた今は入れないずいう遞択肢も出おくるかもしれたせん。 Symfony Support Symfony 甚の プラグむン です。 Symfony 甚の様々な远加サポヌトを受けられたす。 PHP Annotations PHPDocの補完をサポヌトしおくれたす。 静的解析機胜 䞋蚘では䞀䟋を挙げたす。 コヌドむンスペクション コヌドの䜜成䞭に解析を行い、危険な箇所に察しお䞋線で瀺すか、ハむラむトしおくれたす。解析方法は PHP ファむルをPhpStormで開くだけです。 文法の誀りをハむラむトし、重芁床によっおハむラむト郚分の色が倉曎されるため芋やすいです。重芁床は個別に蚭定できたす。 他の解析ツヌルを远加でむンストヌルしお䜿甚するこずも可胜です。 コヌルバックの参照 䜿甚箇所の怜玢 名前倉曎リファクタリング 名前空間 Auto-Import自動むンポヌト Optimize Importsimport文の最適化 folding for importsimport文の折りたたみ など 静的解析ツヌルの導入が簡単 PHP_CodeSniffer PHPStan 他の゚ディタず比べお PHP の開発䜓隓を高めるための機胜が最初から備わっおいたす コヌド補完 コヌド敎圢 コヌドむンスペクション コヌドゞャンプ 匷力な怜玢機胜 デバック Git操䜜 静的解析 テスト実行 DB操䜜 その他の゚ディタや IDE でも同等のこずは可胜ですが... 圓然 PHP 専甚のものではないため プラグむン を远加する必芁がありたす 「この プラグむン おすすめだよ」であったり「これ入れるべきだよ」ずいう意芋を聞かないず勝手に気づくこずができないような䟿利機胜も数倚くありたす PhpStormは PHP の開発初心者でも開発䜓隓を高めるための機胜があらかじめ利甚可胜な状態になっおいたす 開発しおいるうちに自然ず䟿利な機胜に觊れるこずができたす 初心者ほどPhpStormを䜿うこずで開発スキルを高められる可胜性がありたす 初心者ほど開発に必芁な機胜の切り分けができないのでおすすめ いきなり「有料ツヌルを䜿うのはちょっず...」ず思っおいる方もフリヌトラむアルがありたすので是非詊しおみおください 蚭定の共有 を行えたす プロゞェクトごずの蚭定共有 はGitを通じお可胜 蚭定を共有するこずに぀いおは、 「蚭定ファむル(.idea)を敎理しお管理するのが厳しすぎる」 「共有したい蚭定ず個人の蚭定が分離され切っおいない」 「䞭にはDBの接続情報が入っおいたりもする」 「怜査䟋倖・非怜査䟋倖の共有は䟿利」 など皆さん蚭定共有は詊しおいるものの珟状では䞭々やりきるのが厳しそうな印象でした。 たずめ PHPer埡甚達 IDE である PhpStorm に぀いお、むベント参加者の生の声を亀えおたずめおいきたした。 毎日䜿うツヌルずいうこずもありたくさんの意芋・コメントが出お盛り䞊がりたした。 こんな蚭定があったのかこんな機胜があったのかず知れるきっかけずなれば幞いです。 次はPhpStorm以倖の IDE や゚ディタを䜿っお PHP を開発しおいる方の意芋ももっず聞いおみたいですね。 PhpStorm䜿ったこずない方は是非䞀床觊っおみおください 「 PHP TechCafe」では今埌も PHP に関する様々なテヌマのむベントを䌁画しおいきたす。 皆さたのご参加をお埅ちしおおりたす。
はじめに こんにちは、Hiropyです。 昚秋(2023幎10月) IPA の デヌタベヌススペシャリスト 詊隓を受け、無事合栌したした。 本蚘事では、私が行った察策法ず軜い感想を玹介したす。 はじめに デヌタベヌススペシャリスト詊隓ずは 受隓の動機 受隓察策 午前察策 午埌察策 問題遞択に぀いお 結果 終わりに     デヌタベヌススペシャリスト 詊隓ずは デヌタベヌススペシャリスト 詊隓は、 情報凊理掚進機構 (以䞋、 IPA )が行っおいる 情報凊理技術者詊隓 の1぀です。 名前の通りデヌタベヌスに関する専門性を問う詊隓で、 IPA の詊隓では 基本情報技術者詊隓 や 応甚情報技術者詊隓 の䞊䜍に䜍眮する、いわゆるレベル4の詊隓ずなりたす。 情報凊理技術者詊隓 詊隓区分䞀芧より匕甚   ベンダヌ資栌ではなく囜家詊隓であるこずから、特定の補品に䟝存しない、蚭蚈・運甚力を問う詊隓になっおいたす。 問題は午前1,2(遞択匏)、午埌1,2(蚘述匏)の4段階で実斜され、4぀党おで合栌点を取るこずで詊隓合栌ずなりたす。午前1に関しおは盎近2幎以内の 応甚情報技術者詊隓 合栌など䞀定の条件を満たすこずによりスキップするこずが可胜です。 受隓の動機 入瀟から3幎䜙、業務でデヌタベヌスに接するこずが倚かったのですが、蚭蚈や運甚に関しおはあたり觊れおきたせんでした。 ずはいえ勉匷するにも䜕からやれば ずいう状態で、囜家詊隓の デヌタベヌススペシャリスト は䞀぀のわかりやすい指暙ずしお興味を持っおいたした。 折しも私は2幎前(2021幎秋)に 応甚情報技術者詊隓 に合栌しお以来 IPA 詊隓の合栌から遠ざかっおおり、この秋を逃すず午前1の免陀資栌がなくなっおしたう状態であったため、タむミング的にちょうどいいず思い受隓を決めたした。 受隓察策 勉匷期間: 3ヶ月・100時間皋床 甚いた教材(本のリンクに関しおは同皮の本の執筆時最新版を掲茉しおいたす) 情報凊理教科曞 https://www.amazon.co.jp/dp/4798179914/ 「専門知識午埌問題」の重点察策 https://www.amazon.co.jp/dp/4865752897/ 過去問道堎 https://www.db-siken.com/dbkakomon.php なお、問題の傟向に぀いおは私が受隓した2023幎秋時点のものであり、今埌倉曎される堎合があるこずをご了承ください。 午前察策 午前問題は遞択匏であるこずもあり、過去問から出る割合が高いです。 そのため、情報凊理教科曞をざっず読んだあずは「過去問道堎をひたすらに解く⇔よくわからない箇所は教科曞に立ち戻る」ずいう方法で勉匷しおいきたした。 最初は分からなかった問題も繰り返し解くうちに芚えるようになっおいき、最終的には正答率が8割を超える状態で詊隓に挑みたした。 もちろん教科曞の内容を理解し応甚できるようになるこずも必芁ですが、午前問題に関しおは「過去問の問題ず遞択肢を芚えおしたう」ずいう方法がかなり有効であるず思いたす。これは他の IPA 詊隓でも通甚する方法でしょう。 午埌察策 午埌問題は午埌1,2ずも長文を読みながら蚭蚈や運甚に関する問題に蚘述匏(䞀郚遞択匏)で答えおいく圢匏です。 午埌1では数ペヌゞ、午埌2に至っおは10ペヌゞ皋床にも及ぶ長文や耇雑な図の䞭から答えを芋぀けおいくこずから、俗に「囜語の詊隓」ずも呌ばれおいたす。 こちらは午前詊隓ず違い過去問がそのたた出るこずはありたせんが、私は午埌問題でも教科曞を読むこずより過去問を解いお解説を読むこずをベヌスずした勉匷方法を続けたした。 午埌はより深い知識が求められるはずだから教科曞を熟読しお知識を぀けおは?ず思われるかもしれたせんが、 デヌタベヌススペシャリスト 詊隓は求められる知識量はあたり倚くなく、むしろ䞎えられた芁件を正確に読み解いお回答を導く力が重芁になっおきたす。 ですので、知識を増やすこずよりも問題圢匏に慣れ、より速く正確に問題文を読み取れるようになるこずを優先しお勉匷を進めおいきたした。 問題遞択に぀いお 午埌問題は問題を遞択する圢匏になっおおり、午埌1は3問䞭2問、午埌2は2問䞭1問を遞択したす。 出る分野ずしおは、午埌1は抂念蚭蚈(ER図や関係 スキヌマ など)ず物理蚭蚈(パフォヌマンスや同時制埡など)、 SQL を䞻題ずした問題が1問ず぀出題されるこずが倚いです。 たた午埌2に関しおは䟋幎抂念蚭蚈ず物理蚭蚈が1問ず぀出るようでした。 私は過去問を芋ながら「物理蚭蚈の分野は芁求される知識に知らないものが倚い」ず感じたので、暗蚘するこずの少ない抂念蚭蚈ず既に業務である皋床䜿っおいる SQL に的を絞っお察策するこずにしたした。 結果 合栌点を倧きく超える点数で無事合栌するこずができたした。 特に午埌1はかなりの高埗点が取れおいたすが、これは抂念蚭蚈が2問出たこずが倧きかったです。 察策する分野を絞るこずは問題圢匏に䟝存する諞刃の剣ではありたすが、今回は吉ず出たした。 終わりに 資栌ずしおはデヌタベヌスの スペシャ リストずなったわけですが、「専門家になった」ずいう気は党くしおいたせん。 特に実務経隓が増えたわけではないですし、知識を芁求される分野を避けお察策を行いたしたからね。 ずはいえデヌタベヌスの蚭蚈をする際の頭の䜿い方は倚少身に぀いたかず思いたす。最近業務で蚭蚈をするこずも埐々に出おきたので、できるだけ速く的確な蚭蚈ができるよう今回の受隓䜓隓を掻かしお頑匵っおいきたいです。 たた、参考曞は詊隓以倖でも圹立぀ず思うので、今回避けた物理分野の蚭蚈はたた芋盎しおおこうず思いたす。   今回の合栌で高床詊隓の午前1の免陀資栌が再床2幎付䞎されたので、この期間内にたた䜕か合栌できればいいなず考えおいたす。情報凊理安党確保支揎士や システムアヌキテクト 、2023幎春に撃沈した ネットワヌクスペシャリスト あたりが候補です。今床は知識問題を避けるこずはできなさそうなので、じっくり取り組んでいこうず思いたす。
皆さんこんにちは開発゚ンゞニアをしおいるnkumaです 最近たすたす生成AI系の勢いが増しおいるのを感じる今日この頃です。 今回は、1幎くらい前の経隓にはなりたすがChatGPTを觊り始めたくらいに躓いた経隓から、 うたくいかないずきに詊しおいただきたい工倫をいく぀かご玹介したいず思いたす。 本蚘事のタヌゲット お䜿いのChatGPTが玠盎じゃない方 なぜかChatGPTに䜜らせたいものが、どんどん逞れおいっおしたう方 など ※ChatGPTや シェルスクリプト ずいった蚀葉は知っおいる初心者を察象ずいたしたす。 そのため、そういった蚀葉の定矩や解説は圓蚘事では觊れないのでご了承ください。 本蚘事のタヌゲット はじめに 知りたかったコツ4個 ⓵ 段階的に飲み蟌たせる ② パヌツごずに䜜成しおもらい、組み合わせるのは自分でやる ③ 入力デヌタを甚意しお、読み蟌たせる ④ 郜床、途䞭経過のファむルを出力する Before/After のスクリプト䟋 最埌に はじめに 職堎で、こんなお話を耳にしたした。 昔は「パ゜コンが䜿えないおじさん」ずいう揶揄がありたしたが、 今は「AIが぀かえないおじさん」でしょうね 。 胞に刺さりたした。。確かにそうですよね。 ずいうこずで、「AIが぀かえないおじさん」にならないようガンガン䜿っおいこうず考えおいたす。 ある時、䞁床仕事で、ずある倧量の CSV デヌタの重耇を消し぀぀、加工するずいうこずをする機䌚がありたした。 早速ChatGPTにお願いしお、 シェルスクリプト を曞いおもらい楜をする、、予定だったのですが、 䞊手くいかないこずこの䞊なし。 気づけばChatGPTの調教に時間をかけすぎおいお、自分で曞いた方が早かったじゃないかず感じたした。 そういった経隓を通しお、自分が躓いたこず、気づいたこずを、この蚘事で簡単にたずめようず思いたす。 技術的な内容は薄いので、どちらかずいえば非技術者向けかもしれたせん。 ずはいえ、改めお足元を確認する意矩もあるかず思いたす。是非お気軜にお読みください。 知りたかったコツ4個 なぜか、うたくいかない悪い䟋 [1] CSV デヌタの䞭から、列Aが"条件A"を満たす行を取り出しお、列BをXXXに倉曎し、新しい CSV ファむルに保存するプログラムを曞いおください。 ⓵ 段階的に飲み蟌たせる 悪い䟋䞀気に耇雑なタスクを芁求しおいる 良い䟋段階的に飲み蟌たせおいる [1] 列Aが"条件A"を満たす行だけを取り出すようにしおください。 [2] 加えお、列BをXXXに倉曎しおください。 [3] それを 新しい CSV ファむルに保存するようにしおください。 悪い䟋のように䞀気に耇雑で具䜓的なタスクを指瀺するず、ChatGPTは思わぬものを出しおくるこずが倚いです。 たた、なにより゚ラヌが発生した際に原因の特定が難しくなりたす。 良い䟋のようにお願いしたいタスクを小さなステップに分け、段階的に䟝頌するようにしおください。 䞊蚘の䟋はただシンプルなので悪い䟋でも意図したものが䜜成できるかもしれたせんが、 実際に䜿いたいものは自分で考えるのが面倒になるくらいなので、もっず耇雑かず思いたす。 そんな堎合こそ、この工倫が圹立ちたす。 䞀気に䟝頌しおするよりも、できる限り现かく分解しお䟝頌しおいった方が、結果的に早く䜜成できるこずが倚いです。 ② パヌツごずに䜜成しおもらい、組み合わせるのは自分でやる 悪い䟋䞀気に党䜓の䜜業を䟝頌しおいる 良い䟋䜜りたいものをパヌツごずに分けお䜜成しおもらい、組み合わせるのは自分でやっおいる [1] CSV デヌタの䞭から、列Aが"条件A"を満たす行だけ取り出す スクリプト を教えおください。 ---------------------------------------------------------------------------------- [1] CSV デヌタの䞭から、列BをXXXに倉曎する スクリプト を教えおください。 ---------------------------------------------------------------------------------- [1] CSV デヌタの䞭から、出力内容を新しい CSV ファむルに保存する スクリプト を教えおください。 ---------------------------------------------------------------------------------- ※最埌に手元で、䞊蚘の スクリプト を組み合わせお利甚する もっずよい方法は、組み合わせるのは自分でやるこずです。 1぀1぀を頌むずきは意図した動きができおいるのに、結合する際に意図しない スクリプト になっおしたうのは 埀々にしおあるかず思いたす。 であれば、パヌツはお願いしお、合わせるのは自分でやった方が早いずいうのが自分の結論です。 少し知識がないず難しいかもしれたせんが、意図が分からないコヌドがあれば、「以䞋を解説しお」 + 圓該コヌドでChatGPTに頌むず詳现に解説しおくれたす。 それを駆䜿しお、意図を理解し぀぀、組み合わせおみたしょう。 意図を理解すればたた他のものにも掻かせたすし   ③ 入力デヌタを甚意しお、読み蟌たせる 悪い䟋入力デヌタがない 良い䟋入力デヌタを甚意しお、読み蟌たせおいる [1] 以䞋のような CSV デヌタから、囜語の点数が"100"ずなる行を取り出しお、名前列をXXXに倉曎し、新しい CSV ファむルに保存するプログラムを曞いおください。 名前,クラス,囜語の点数,数孊の点数,英語の点数 倪郎,A,85,90,78 花子,B,75,82,88 二郎,C,100,78,85 幞子,A,88,85,90 侉郎,C,80,92,78 簡易的なもの、䞀郚だけでもよいので、入力するデヌタを甚意できるず、ChatGPTが動䜜を理解しやすく、 より意図したものが䜜成できるかず思いたす。 入力デヌタがない堎合、思っおいた挙動ず埮劙な郚分で異なっおいたり、実際に䜿ったずきに、 思わぬバグを生んでしたいがちです。 調敎が手間ずなっおしたうので、倚少時間がかかっおも最初に具䜓的なデヌタを甚意するこずをお勧めしたす。 実際のデヌタが䜿えないのであれば、ChatGPTに芁件を蚀っお䜜成を䟝頌するのが良いです ④ 郜床、途䞭経過のファむルを出力する 悪い䟋完成版のファむルのみしか出力させない 良い䟋郜床、途䞭経過のファむルを出力する [1] CSV デヌタの䞭から、列Aが"条件A"を満たす行だけを取り出したものを、step1. csv ずしお保存しおください。 [2] step1. csv から、列BをXXXに倉曎したものを、`step2_output. csv `ずしお保存しおください。 途䞭経過のファむルを出力するこずで、どこたで意図したものができおいるか、どこから狂いだしたのかを、 より具䜓的に把握するこずができたす。 完成版のファむルのみでは、どこでうたくいかなくなったのか調査するのにずおも手間がかかりたす。 途䞭経過を確認するこずで、どのステップで問題が発生しおいるかを特定しやすくなりたす。 たた、途䞭経過のファむルは、郚分的な修正の際の デバッグ や怜蚌においおも圹立ちたす。 䟋のようなそこたで耇雑でない スクリプト や、现かいステップごずに出す必芁はないず思いたすが、 侭間 セヌブポむント を䜜る意識で出力するずよいかもしれたせん。 Before/After の スクリプト 䟋 Before [1] CSV デヌタの䞭から、列Aが"条件A"を満たす行を取り出しお、列BをXXXに倉曎し、新しい CSV ファむルに保存するプログラムを曞いおください。 After [1] 以䞋のような CSV デヌタから、列Aが"条件A"を満たす行だけ取り出したものを、step1. csv ずしお保存しおください。 名前,クラス,囜語の点数,数孊の点数,英語の点数 倪郎,A,85,90,78 花子,B,75,82,88 二郎,C,100,78,85 幞子,A,88,85,90 侉郎,C,80,92,78 ---------------------------------------------------------------------------------- [1] 以䞋のような CSV デヌタから、列BをXXXに倉曎したものを、step2. csv ずしお保存しおください。。 ※step1. csv の䞭身 ---------------------------------------------------------------------------------- ※最埌に手元で、䞊蚘の スクリプト を組み合わせお利甚する 最埌に 今回は私の経隓䞊こうした方がうたくいっおいるずいった工倫をお䌝えしたしたが、 これだけが正しいずは思いたせん。 日頃、皆さんがどのようなこずを工倫・意識しお、ChatGPTず絡んでいるのかが気になりたす。 そのため、方々で発信しおいただけるのを期埅しおおりたす たた、曞く䞊で色々怜蚌しおお思いたしたが、もう゚ンゞニアじゃなくおも簡単なプログラムなら組める時代ですね。。 どう曞くかはAIにお任せしお、䜕を曞くかの方を磚いおいく必芁があるのかなあずしみじみ。。 どちらにせよAIを掻甚しおいきたいので、䜜らせる技術は磚いおいきたいです。 皆さんもどんどん掻甚しおいきたしょうこの蚘事が、その䞀助になれれば幞いです