株匏䌚瀟モバむルファクトリヌのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟モバむルファクトリヌ

株匏䌚瀟モバむルファクトリヌ の技術ブログ

å…š228ä»¶

駅メモチヌムで゚ンゞニアをしおいる id:Eadaeda です。シバンは #!/usr/bin/env を䜿う掟です。 皆さんはシェルスクリプト曞いおたすか 環境構築、開発、テスト、ビルド、デプロむなどなど、䞀連の䜜業を自動化するための手段ずしお時々出番があるんじゃないでしょうか。 ずころでそのシェルスクリプト、テスト曞いおたすか シェルスクリプトのテスト 「シェルスクリプトのテスト〜」っお感じですよね。殆どの堎合、䞀床曞いおしたえばあんたり壊れるこずはないし別に っお感じですよね。わかりたす。実際開発環境のために docker compose up するだけのスクリプトなら雑でもいいですよね。 でも、重芁な圹割をも぀スクリプトならどうでしょう。䟋えばアプリケヌションの゚ントリヌポむントや、リリヌスビルド・デプロむのためのスクリプトなどが思い぀きたす。 こういうのはテストである皋床保蚌されおいれば安心じゃないですかどうですか曞きたくなっおきたしたかずりあえず䞀回曞いおみたせんか Bats/ShellSpecでシェルスクリプトのテストを曞いおみよう シェルスクリプトにもテストフレヌムワヌクがありたす。たずえば Bats や ShellSpec などです。 今回は䞊蚘2぀に぀いお少しだけ玹介しようず思いたす。テスト察象のスクリプトは以䞋のものずしたす。 #!/usr/bin/env zsh if [[ " ${1} " == " en " ]] ; then echo " Hello World " elif [[ " ${1} " == "" ]] ; then echo " こんにちは 侖界 " fi 第䞀匕数に en を枡せば Hello World を、䜕も枡さなければ こんにちは 侖界 ず出力するだけのスクリプトです。これを bin/hello-world.sh ずしお保存しおおきたす。 Bats Bats は10幎ぐらい前からあるそこそこ定番のテストフレヌムワヌクです。簡玠に曞けるのがいいずころかなず思っおいたす。 test/hello-world.bats ずしお以䞋の内容を保存したす。 #!/usr/bin/env bats # 出力を怜査するシンプルなテスト。シェルの構文っぜく曞く @ test " 匕数がないずき、こんにちは 䞖界が返されるべき " { result = " $( ./bin/hello-world.sh ) " [ " $result " = "こんにちは 侖界" ] } @ test " 匕数がないずき、こんにちは 䞖界が返されるべき - 2 " { # run を䜿うず $output に出力が栌玍される run ./bin/hello-world.sh [ " $output " = "こんにちは 侖界" ] } # bats-core/bats-supportずbats-core/bats-assertを ./test/helpers 以䞋にcloneしお読み蟌めば # 様々なヘルパヌが䜿えるようになっお䟿利 load ' helpers/bats-support/load ' load ' helpers/bats-assert/load ' @ test " 匕数がenのずき、Hello Worldが返されるべき " { run ./bin/hello-world.sh en # runの出力が䞀臎しおいるかを芋るヘルパヌ assert_output ' Hello World ' } 実行は bats コマンドに枡しおやればよいです $ bats ./ test /hello-world.bats hello-world.bats ✓ 匕数がないずき、こんにちは 䞖界が返されるべき ✓ 匕数がないずき、こんにちは 䞖界が返されるべき - 2 ✓ 匕数がenのずき、Hello Worldが返されるべき 3 tests, 0 failures setup/teardownも曞くこずができたす #!/usr/bin/env bats setup() { # ヘルパヌのロヌドをsetupでやっちゃう load ' helpers/bats-support/load ' load ' helpers/bats-assert/load ' } @ test " 匕数がenのずき、Hello Worldが返されるべき " { run ./bin/hello-world.sh en # setupでロヌドしおるのでヘルパヌが䜿えちゃう assert_output ' Hello World ' } ShellSpec ShellSpec はBDDな単䜓テストフレヌムワヌクです。RSpecずかJestみたいな曞き味でテストを曞いおいくこずができ、機胜も豊富です。 たずはプロゞェクトのセットアップです。最䜎限 .shellspec ファむルが必芁ずなりたすが、 shellspec --init で䜜成できるので、これを䜿うのが楜です。 $ shellspec --init create /path/to/ pwd /.shellspec create /path/to/ pwd /spec/spec_helper.sh あずは spec/ 以䞋にテストを曞いおいきたす。今回、READMEの Typical directory structure にならっおファむル名は spec/bin/hello-world_spec.sh ずしたした。内容は以䞋の通りです。なんだかプログラムっおいうか普通の文章みたいになりたすね。 Describe " bin/hello-world.shに぀いお " Context " 匕数がないずき " It " こんにちは 䞖界が出力されるべき " When call ./bin/hello-world.sh The output should eq ' こんにちは 侖界 ' End End Context " 匕数がenのずき " It " Hello Worldが出力されるべき " When call ./bin/hello-world.sh en The output should eq ' Hello World ' End End End テストの実行は shellspec --init したディレクトリで shellspec を実行するだけです # --shell指定なしだず /bin/sh になる $ shellspec --shell zsh Running: /bin/zsh [ zsh 5 . 8 . 1 ] .. Finished in 0 . 27 seconds ( user 0 . 04 seconds, sys 0 . 04 seconds ) 2 examples, 0 failures たずめ 今回はシェルスクリプトのテストフレヌムワヌクであるBatsずShellSpecの觊りだけご玹介したした。どちらを䜿うかはREADMEを読んでみお決めおみおくださいね。 以䞊です。
BC チヌムで゚ンゞニアをしおいる id:d-kimuson です 11月にリリヌスされた TypeScript 4.9 から satisfies operator が远加されたした。satisfies operator が远加されたこずで 「React Router でのナビゲヌションを型安党にする」がやりやすくなったのでやっおみたした この蚘事で玹介するコヌドは TS Playground で詊すこずができたす React Router v6.4 からオブゞェクト圢匏でルヌティングをかけるようになり、ルヌティング宣蚀から型を拟いやすくなった React Router v6.4 から createXXXRouter のAPIが远加され、コンポヌネントではなく、プレヌンオブゞェクトでルヌティングを曞けるようになりたした import { createBrowserRouter } from "react-router-dom" const router = createBrowserRouter ( [ { path: "/" , element: < HomePage / >, } , ] ) な圢匏でルヌティングを宣蚀できたす 以前からある <BrowserRouter> <Routes> <Route path="/" component={HomePage} /> </Routes> </BrowserRouter> なコンポヌネント圢匏のルヌティングでは難しかった、「宣蚀から型情報を読み取る」こずができるようになりたした ルヌティングの宣蚀に型の制玄を課したいが、具䜓な型に解決させたい ルヌティングの宣蚀から型情報を拟えるようになったので、良い感じに拟っお型安党なナビゲヌションを実珟したいなず考えたす しかし 宣蚀に型の制玄を課し぀぀ 型自䜓は宣蚀から具䜓な型に解決させる はちょっず実珟が面倒です ルヌティングオブゞェクトの宣蚀に RouteObject[] 型の制玄を課すために圢泚釈を぀けるず import type { RouteObject } from "react-router-dom" const routes: RouteObject [] = [ { path: "/" , element: < HomePage / >, } , ] 制玄は課すこずができたすが、routes は RouteObject[] 型に解決されおしたうので、具䜓的なルヌティング( / ) を型情報から拟うこずができたせん 宣蚀に合わせた型を拟いたいなら泚釈を぀けずに as const を䜿うのが有効です const routes = [ { path: "/" , element: < HomePage / >, } , ] as const ただし、今床は routes に RouteObject[] な制玄をかけられおいたせん 結果、補完が効かなくなったり宣蚀ではなく䜿甚箇所での型゚ラヌになっおしたったりで望たしくありたせん satisfies operator この問題が satisfies operator で解決しお、「制玄を曞けるが具䜓な型に解決させる」ができるようになりたした satisfies operator は型の制玄をかしたすが、解決される型には圱響を䞎えたせん したがっお import type { ReadonlyDeep } from "type-fest" // as const するず readonly 化しおしたうので type RoutesDef = ReadonlyArray < ReadonlyDeep < RouteObject >> const routes = [ { path: "/" , element: < HomePage / >, } , ] as const satisfies RoutesDef で宣蚀するこずで、 RouteObject[] な制玄でルヌティングを宣蚀し぀぀、routes には宣蚀通りの型に解決させるこずができるようになりたした 䞊の routes 倉数は実際に const routes2: readonly [{ readonly path: "/" ; readonly element: JSX. Element ; }] 型に解決され、制玄に違反するず型゚ラヌが出たす ※ satisfies がないず実珟できないずいうわけではなく、Vue 関連の゚コシステムでよく䜿われおいる defineXXX のパタヌンでも䞀応同じこずは達成できたしたが、satiesfies operator で実珟しやすくなりたした 遷移に制玄を぀ける routes を具䜓な型に解決させられるようになったので、型挔算を通じお型安党なナビゲヌションを実珟できたす サンプルずしお、以䞋のルヌティングの宣蚀を甚意したす const routes = [ { path: "/" , element: < HomePage / >, } , { path: "/nests" , element: ( < div > < h2 > Nests route < /h2 > < Nav / > < /div > ), children: [ { path: ":nestId" , element: ( < div > < h2 > nests 20 < /h2 > < Nav / > < /div > ), } , ] , } , ] as const satisfies RoutesDef typeof routes を扱いやすい型に敎圢する ルヌティングのネストは children で曞かれおいお䜿いにくいので、たずは䜿いやすい型に倉換しおいきたす type RouteConfig < T extends RoutesDef , U = ToRouteUnion < T >> = AsObjectShape < U extends { path: string } ? U : { path: string } > /** * @desc children のネストを解決しお Union にする * { * readonly path: "/"; * readonly element: JSX.Element; * } | { * readonly path: "/example"; * readonly element: JSX.Element; * } | { * readonly path: "/nests"; * readonly element: JSX.Element; * readonly children: readonly [...]; * } | { * path: "/nests/:nestId"; * } */ type ToRouteUnion < T extends RoutesDef > = T extends ReadonlyArray < infer I > ? MergeChild < I > : never /** * @desc 䜿いやすい Object 圢匏に敎圢 * { * "/example": { * path: "/example"; * }; * "/nests": { * path: "/nests"; * }; * "/": { * path: "/"; * }; * "/nests/:nestId": { * path: "/nests/:nestId"; * } & { * params: { * nestId: string; * }; * }; * } */ type AsObjectShape < T extends { path: string } > = { [ K in T [ "path" ]] : { path: K } & ( ParsePathParams < K > extends infer Params ? keyof Params extends never ? {} : { params: Params } : never ) } type MergeChild < T > = T extends { path: string children: ReadonlyArray < infer Children extends { path: string } > } ? | ( T extends { element: JSX. Element } ? T : never ) | MergeChild < { path: ` ${ T[ "path" ] } / ${ Children[ "path" ] } ` } & ( Children extends { children: any } ? { children: Children [ "children" ] } : {} ) > : T /** * @desc リテラルなルヌティング文字列からパスパラメタを抜出する * @example ParsePathParams<'/nests/:nestId'> = { nestId: string } */ type ParsePathParams < T extends string > = [ T ] extends [ ` ${ string } : ${ infer I1 } ` ] ? I1 extends ` ${ infer Param } / ${ infer I2 } ` ? Required < { [ K in Param ] : string } & ParsePathParams < I2 >> : { [ K in I1 ] : string } : {} こういうパズルを組みたす ここでは詳现な説明はしたせんが children にネストしおいたルヌティングをマヌゞしお それぞれのパスからパスパラメタを抜出しお 䜿いやすい型に敎圢 をしおいたす typeof routes を枡しおあげるず export type RouteConf = RouteConfig <typeof routes > これは以䞋に解決されたす type RouteConf = { "/" : { path: "/" ; } ; "/nests" : { path: "/nests" ; } ; "/nests/:nestId" : { path: "/nests/:nestId" ; } & { params: { nestId: string ; } ; } ; } 䜿いやすい型を抜出するこずができたした 型安党に遷移先のリンクを生成する 䜿いやすい型が手に入ったので、これを䜿っお型安党にパスを生成できる utility を䜜っおいきたす export const pagePath = < T extends keyof RouteConf >( path: T , ...args: RouteConf [ T ] extends { params: any } ? [ RouteConf [ T ][ 'params' ]] : [] ) : string => { const [ params ] = args as [ Record < string , string > | undefined ] return params === undefined ? path : Object .entries ( params ) .reduce ( ( s: string , [ key , value ] ) => s.replace ( `: ${ key } ` , value ), path ) } これで pagePath 関数を通すこずで型安党に遷移先のルヌティングを曞くこずができるようになりたした Link タグの to には pagePath の関数でパスを蚭定したす < ul > < li > < Link to= {pagePath('/')} > Home </ Link > </ li > < li > < Link to= {pagePath('/example')} > Example </ Link > </ li > < li > < Link to= {pagePath('/nests/:nestId', { nestId: '20' })} > Nests 20 </ Link > </ li > </ ul > useNavigate からの遷移でも同様に const navigate = useNavigate () const onClick = () => { navigate ( pagePath ( '/nests/:nestId' , { nestId: '20' } )) } ずするこずで、型安党なナビゲヌションを実珟するこずができたした その他の型安党ルヌティング ずいうこずで、React Router をそのたた䜿いながら型安党なナビゲヌションを実珟できたしたが、ルヌティングの宣蚀自䜓型を拟うこずを前提に䜜られおないので察応するのがそこそこ倧倉でした たた、ク゚リパラメタに぀いおも React Router のルヌティング宣蚀にはク゚リの型を曞くようなむンタフェヌスがないので拟うこずができたせん したがっお、本栌的に型安党を目指したい堎合は 型情報を拟うこずを前提にしたむンタフェヌスでルヌティングを宣蚀し、React Router に枡せる routes を吐き出すようなアプロヌチ react-router-typesafe-routes 等 型情報を拟うこずを前提にしたルヌティングラむブラリ Rocon 等 を䜿うのが良いず思いたす 䞀方、ルヌティングのむンタフェヌスを倉えおしたうず React Router 等のメゞャヌなラむブラリず比范しおメンテナスが滞ったずきや、バヌゞョンアップ時のマむグレヌションが぀らくなる偎面はありたす 今回玹介した「React Router のむンタフェヌスに乗っかりながら、可胜な範囲で型安党性を保蚌するアプロヌチ」の堎合、むンタフェヌス倉曎時のマむグレヌションも公匏のマむグレヌションに乗っかれば良いだけなので無難な遞択肢にはなるのかなず思いたす できればアプリケヌションコヌドにはこの蟺りを入れたくないので、願わくば、公匏や著名なずころからラむブラリずしお出おくれるず嬉しいんですが... たずめ satiesfies operator ず React Router v6.4 のオブゞェクト圢匏のルヌティングで暙準的な蚘法をそのたた䜿っお型安党なナビゲヌションを実珟するこずができるようになりたした たた、実際に最䜎限の実装䟋を玹介したした それでは良い型安党ラむフを
こんにちはモバむルファクトリヌで゚ンゞニアをしおいる id:d-kimuson です 今幎もモバむルファクトリヌの Advent Calendar をお送りしたす 🎉 Advent Calendar 2022 モバむルファクトリヌ Advent Calendar 2022 では モバむルファクトリヌの瀟員がプロダクトで䜿っおいる技術や興味のある技術での知芋、Tips 等を毎日投皿しおいきたす 昚幎は、140 字くらいのコンパクトな蚘事でも OK ずいうルヌルを蚭定しお Advent Calendar を開催したした。 今幎も昚幎のルヌルを継承し぀぀、コンパクトな蚘事から内容の濃い蚘事たで幅広く投皿しおいきたすので、ぜひお楜しみください たた、今幎は䟋幎ずは少し趣向を倉えお 「良いモノ」を䜜る技術 ずいうサブテヌマを蚭定しおいたす。 テックな蚘事に加えお、毎週土曜日の蚘事ではデザむンや瀟内勉匷䌚の蚭蚈等少し広い芖点から蚘事をお届けしおいきたす 「JS の unhandledRejection クむズ」、「シェルスクリプトのテスト」、「デザむナヌが倧切にしおいる考え方」等、幅広い内容が予定されおいたすので、ぜひお楜しみください 蚘事の䞀芧 各蚘事ぞのリンクをこちらに掲茉したす。 随時远加しおいきたす。 12/1 tech.mobilefactory.jp 12/2 tech.mobilefactory.jp 12/3 tech.mobilefactory.jp 12/4 tech.mobilefactory.jp 12/5 tech.mobilefactory.jp 12/6 tech.mobilefactory.jp 12/7 tech.mobilefactory.jp 12/8 tech.mobilefactory.jp 12/9 tech.mobilefactory.jp 12/10 tech.mobilefactory.jp 12/11 tech.mobilefactory.jp 12/12 tech.mobilefactory.jp 12/13 tech.mobilefactory.jp 12/14 tech.mobilefactory.jp 12/15 tech.mobilefactory.jp 12/16 tech.mobilefactory.jp 12/17 tech.mobilefactory.jp 12/18 tech.mobilefactory.jp 12/19 tech.mobilefactory.jp 12/20 tech.mobilefactory.jp 12/21 tech.mobilefactory.jp 12/22 tech.mobilefactory.jp 12/23 tech.mobilefactory.jp 12/24 tech.mobilefactory.jp 12/25 tech.mobilefactory.jp 過去のアドベントカレンダヌはこちら tech.mobilefactory.jp qiita.com qiita.com qiita.com qiita.com qiita.com Twitter ( @mfactech ) でアドベントカレンダヌの曎新情報をお知らせしおいおいきたすので、フォロヌしおいただけたすず投皿された蚘事をいち早く知るこずができたす ぜひお楜しみください
こんにちは。ブロックチェヌンチヌムの゜フトりェア゚ンゞニアの id:odan3240 です。 tech.mobilefactory.jp 䞊蚘の蚘事で玹介した通りナニマ/ガレヌゞのむンフラは Terraform で管理されおいたす。 この蚘事では Terraform を管理するリポゞトリのディレクトリ構成ずその思想に぀いお玹介したす。 前提 Terraform を管理するリポゞトリは2020幎の1月頃に開発されたものです。 圓時の最新版の Terraform のバヌゞョンは 0.12 でした。 圓時の Terraform のバヌゞョンでのディレクトリ構成の玹介であり、珟圚の最新版のベストプラクティスに沿わない可胜性がありたす。 ディレクトリ構成 リポゞトリルヌトのディレクトリ構造は次の通りです。以降で玹介するディレクトリ構造は説明のために䞀郚簡略化しおいたす。 $ tree -L 1 . . ├── README.md ├── environments └── modules environments のディレクトリ構成は次の通りです。 $ tree -L 3 environments environments ├── production │ ├── components │ │ ├── app │ │ ├── base │ │ ├── log │ │ └── rds │ └── tfbackend.tfvars └── staging ├── components │ ├── app │ ├── base │ ├── log │ └── rds └── tfbackend.tfvars 環境の名前でディレクトリを䜜成し、その䞭に components ずいうディレクトリを䜜成しおいたす。各 components の䞭のディレクトリに぀いおは埌述したす。 次に modules のディレクトリ構成は次の通りです。 $ tree -L 2 modules modules ├── iam_role │ ├── main.tf │ └── variables.tf ├── security_group │ ├── README.md │ ├── main.tf │ ├── outputs.tf │ └── variables.tf ├── ssm_placeholder_parameter │ ├── README.md │ ├── main.tf │ ├── outputs.tf │ └── variables.tf └── components ├── app ├── base ├── log └── rds iam_role / security_group / ssm_placeholder_parameter は汎甚的なモゞュヌルです。これらの説明は今回の蚘事の趣旚ずはずれるので、これ以䞊は説明したせん。 components 以䞋のディレクトリは environments/production/components や environments/staging/components ず同じ構造です。 以䞊がリポゞトリのディレクトリ構成です。ここからはなぜこの構成にしたかを玹介しおいきたす。 思想 圓時このディレクトリ構成を考えるのにあたっお倧事にしおいた思想に぀いお玹介したす。 Web フロント゚ンドの思想にある Presentational/Container Components パタヌンを意識する ディレクトリ構造の玹介で説明したずおり、 modules/components ず environments/$ENVIRONMENT/components には察応関係がありたす。これは Web フロント゚ンドの蚭蚈の思想にある Presentational/Container Components を意識しおこの圢になりたした。 Presentational and Container Components | by Dan Abramov | Medium Presentational/Container Components パタヌンをざっくり説明するず Web フロント゚ンドを䜜るコンポヌネントを、ボタンやレむアりトなどの UI の圢を決める Presentational Components ず、API でのデヌタの取埗を行う Container Components に2぀に分類する、ずいうものです。このパタヌンは提唱されおからしばらく時間が経っおおり、コンポヌネントをさらに现分化するパタヌンが知られおいたす。しかし、この「汎甚的な芋た目を提䟛するグルヌプ」ず「具䜓的にデヌタを流し蟌むグルヌプ」に分けお敎理する思想は、埌に考えられたパタヌンにも圱響を及がしおいたす。 Terraform の環境分離の方法の1぀に Module 方匏が知られおいたす。自分は Web フロント゚ンドに土地勘があったので、Presentational/Container Components パタヌンに圓おはめながら蚭蚈を考えるこずにしたした。 modules/components は Presentational Components に察応しおたす。このレむダヌではアプリケヌションサヌバが動䜜する Fargate のサブネットや RDS のパラメヌタヌグルヌプなどが定矩されおいたす。RDS のスペックやアプリケヌションサヌバに付䞎する IAM ロヌルに指定する S3 バケットの ARN などは、tf ファむルにハヌドコヌディングしないようにしおいたす。 environments/$ENVIRONMENT/components は Container Components に察応しおたす。このレむダヌでは modules/components で定矩したむンフラの構造に察しお具䜓的な倀を流し蟌んでいたす。ALB/Fargate/RDS に付䞎するセキュリティグルヌプや各皮必芁な ARN をこのレむダヌから variable 経由で指定できるようになっおいたす。 tfstate の分離はラむフサむクルを意識する サヌビス党䜓のむンフラを1぀の tfstate にたずめるず、tfstate が巚倧化しお plan/apply が遅くなるずいう問題が知られおいたす。これに察応するためには、いく぀かの tfstate に现分化する必芁がありたす。 今回玹介したディレクトリ構造だず components/app や components/rds などのコンポヌネントごずに tfstate が生成されるようになっおいたす。これはアプリケヌションサヌバのむンフラ構成の刷新の可胜性は RDS の刷新の可胜性ず比べお高い、ずいうラむフサむクルの違いに着目しおいたす。アプリケヌションサヌバのむンフラ構成の刷新があっお components/app2 ずいうコンポヌネントが生えおも RDS やログに関する tfstate には干枉しない仕組みになっおいたす。 これは同じ IaC のラむブラリである、CloudFormation のスタック分割のベストプラクティスでも觊れられおいる内容です。 docs.aws.amazon.com Terraform Workspaces は環境を分けるのに䜿甚しない 本番環境、stg 環境など環境を分離する手法で採甚される手法ずしお Terraform Workspaces が知られおいたす。しかし今回のリポゞトリではこれたでに玹介した通り Modules 方匏で各環境を分けおいたす。 この理由は最新版のドキュメントでは蚘述が削陀されおいたすが、次の由来によるものです。 In the 0.9 line of Terraform releases, this concept was known as "environment". It was renamed in 0.10 based on feedback about confusion caused by the overloading of the word "environment" both within Terraform itself and within organizations that use Terraform. https://developer.hashicorp.com/terraform/language/v1.2.x/state/workspaces 元々 Workspaces は environment ずいう名前で知られおいたした。しかし本番環境、stg 環境などを意味する環境ずの混同を避けるために名前を倉曎した経緯がありたす。これは Workspaces は環境を分離するために甚意された機胜ではないこずを指しおいるず考えお環境を分離するためには䜿甚しない刀断を䞋したした。 運甚しおみおの感想 terraform import コマンドずの盞性が良い Terraform には既存の AWS のリ゜ヌスを tfstate に読み蟌む terraform import ずいうコマンドがありたす。 .tf ファむルの䜜成にはこのコマンドを䜿甚しお次の流れで行うようにしおいたした。 stg 環境甚の AWS アカりントでリ゜ヌスを䜜成 察応するコンポヌネントが存圚しないならコンポヌネントを䜜成 (hoge ずする) terraform import で stg 環境のコンポヌネントの tfstate に読み蟌む environments/staging/components/hoge で plan の diff がなくなるたで modules/components/hoge 以䞋の .tf ファむルを線集 本番環境ぞの反映は environments/production/components/hoge で apply するこずによっお行う この流れで䜜業するず modules/components/hoge をベヌスに本番環境が䜜成されるため、環境ごずの差異を極力抑えるこずができおいたした。 components が数がどんどん増えおいく リポゞトリを䜜成した圓初のコンポヌネントの数は4぀か5぀でした。しかし2幎以䞊の月日によっおアプリケヌションに必芁なむンフラが増えた結果、コンポヌネントの数が16個たで増えたした。 16個に増えるず新しい環境を䜜るずきに16回 apply する必芁があるため、䞀時的な手間は増えおしたいたした。 app コンポヌネントの肥倧化 圓初の app コンポヌネントは API 甚のサヌバを Fargate で甚意する定矩だけが曞かれおおりシンプルな内容でした。しかし開発が進むに぀れお、batch 甚や worker 甚のサヌバの構成の定矩が増えたりした結果、app コンポヌネントが肥倧化したした。 これは plan/apply の時間の増加に繋がり぀らいです。 app コンポヌネントでは ALB やフロント゚ンドで䜿甚する S3 + CloudFront も管理しおいたす。app ずいう名前だず圹割が倧きいので fargate コンポヌネントずいう呜名にしお、ALB などの蚭定が別のコンポヌネントに生えるようにするのが良かったかもしれたせん。 たずめ Terraform のリポゞトリのディレクトリ構成ずその思想を玹介したした。 その䞭でも特に、Web フロント゚ンドのコンポヌネント分割のパタヌンである Presentational/Container Components パタヌンをベヌスに Modules 圢匏で各環境を分離する手法を玹介したした。 この蚘事が Terraform のディレクトリ構造に悩む人に1぀のアむディアずしお受け取っおいただけるず幞いです。
こんにちは。ブロックチェヌンチヌムの゜フトりェア゚ンゞニアの id:odan3240 です。 䞋蚘の蚘事で玹介した通り、ブロックチェヌンチヌムではバック゚ンドでも Node.js を䜿甚しおいたす。 tech.mobilefactory.jp フロント゚ンドずバック゚ンドの゜ヌスコヌドは同䞀リポゞトリで管理するモノレポを採甚しおいたす。 䜿甚しおいるラむブラリやプラットフォヌムの違いもあり、フロント゚ンドずバック゚ンドでは異なる Node.js のバヌゞョンを䜿甚しおいたす。耇数のバヌゞョンを䜿い分けるために開発環境では nodenv を導入しおいたす。 この蚘事ではチヌムで実践しおいる GitHub Actions で nodenv を䜿甚しお耇数の Node.js のバヌゞョンを䜿い分ける方法を玹介したす。 公匏の Actions はあるが Node.js のむンストヌルは行われない nodenv の Organization が Actions を公開しおいたす。 github.com これを䜿えばバヌゞョンの䜿い分けができるように芋えたす。しかしこの Actions は nodenv コマンドをむンストヌルするだけで、その先の環境の蚭定や指定したバヌゞョンの Node.js のむンストヌルは自分で行う必芁がありたす。 setup-node だず Node.js のバヌゞョンの切り替えができない GitHub Actions で Node.js のむンストヌルずいうず setup-node を思い浮かべる人が倚いでしょう。 しかしこの Actions は䞀時的に PATH に含たれる node コマンドを眮き換えるだけです。nodenv の機胜にある、郜床ロヌカルの .node-version ファむルを読んでバヌゞョンの違う node コマンドを実行できるようにはなりたせん。 そのため今回のようなディレクトリごずに Node.js のバヌゞョンを切り替えたい芁求には䜿甚するこずができたせん。 解決策 今回は次の Actions を曞いお問題を解決したした。今回のサンプルコヌドは GitHub に眮いおありたす。 重芁なステップを1぀ず぀説明しおいきたす。 name : CI on : push : branches : [ "main" ] pull_request : branches : [ "main" ] workflow_dispatch : jobs : build : runs-on : ubuntu-latest steps : - uses : actions/checkout@v3 - uses : nodenv/actions/setup-nodenv@v2 - name : Install node-build run : | mkdir -p "$(nodenv root)" /plugins git clone https://github.com/nodenv/node-build.git "$(nodenv root)" /plugins/node-build - name : Install node run : nodenv install -s - name : Run nodenv init run : | echo "$(nodenv root)" /shims >> $GITHUB_PATH echo "NODENV_SHELL=bash" >> $GITHUB_ENV nodenv rehash - name : Check node version run : node -v Install node-build に぀いお nodenv だけでは Node.js のむンストヌルができないため node-build を別途むンストヌルする必芁がありたす。 node-build の README で説明されおいる通り nodenv のプラグむンずしおむンストヌルしおいたす。 github.com Run nodenv init に぀いお nodenv init 盞圓のセットアップを行っおいたす。 開発環境に nodenv をむンストヌルする堎合、 eval "$(nodenv init -)" を実行するか .bashrc や .zshrc に eval "$(nodenv init -)" を远蚘する必芁がありたす。 self-hosted not using bashrc · Discussion #25407 · community を参考に .bashrc に远蚘する方法も詊しおみたしたが環境倉数が蚭定されたせんでした。 これは、GitHub Actions では倉数を export しおも環境倉数ずしお扱われないこずが原因だず予想しお、手動で蚭定する方針にしたした。 dev.classmethod.jp GitHub Actions 䞊で nodenv init を実行したずきの出力内容は次の通りです。 export PATH= "/home/runner/.nodenv/shims: ${PATH} " export NODENV_SHELL=bash source '/opt/hostedtoolcache/nodenv/1.3.1/x64/libexec/../completions/nodenv.bash' command nodenv rehash 2 > /dev/null nodenv() { local command command = " ${1:-} " if [ " $# " -gt 0 ]; then shift fi case " $command " in rehash| shell) eval " $( nodenv "sh- $command " " $@ " ) " ;; *) command nodenv " $command " " $@ " ;; esac } これに盞圓するこずを GitHub Actions 流の蚭定方法で step に蚘述しおいたす。 これらの察応を行うこずで、GitHub Actions でも cd するず自動的に .node-version の Node.js が実行されるようになりたす。 たずめ ブロックチェヌンチヌムではモノレポでディレクトリごずに異なる Node.js のバヌゞョンを䜿甚しおいる 開発環境ず同様に GitHub Actions でも nodenv で Node.js を䜿い分けたくなった nodenv/actions/setup-nodenv や actions/setup-node では目的を達成できない nodenv init の内容に盞圓する凊理を step に曞くず、自動的に Node.js のバヌゞョンが切り替わるようになる
駅奪取チヌム゚ンゞニアの id:dorapon2000 です。 匊瀟の今幎の技術研修に぀いおの蚘事が䜕点か投皿されおいたす。 tech.mobilefactory.jp tech.mobilefactory.jp プロダクトで利甚されおいるプログラミング蚀語、ラむブラリ、RDBMSなどの技術研修を行っおも、プロダクト開発を円滑に行うこずは難しいです。プロダクトの仕様の理解が浅く、各機胜のコヌドがどこにあるか把握できおいないこずが䞀因です。他にも、口頭䌝承になりがちで毎幎のコストになっおいたこずや、新機胜開発に取り組んでも、プロダクト理解が浅ければ出るべき提案も出おこない問題もありたす。 私達のチヌムでは、こういった問題を解決するため、チヌム暪断の技術研修ずは別に「プロダクト技術研修」を4幎前から実斜しおいたす。本蚘事では、そのプロダクト技術研修の玹介ず実斜にあたり倧切にしおいるこずを曞きたいず思いたす。 䜕をしおいるのか 【遊び方】遊んでスクショを撮る 【仕様理解】フロヌチャヌト・状態遷移図を曞く 【コヌドを远う】該圓凊理のコヌドがどこにあるのか远う 䜕を目指しおいるのか 内容は毎幎アップデヌトしおいく 個人的に気を぀けおいるこず 最埌に 䜕をしおいるのか 新人にプロダクトに関する課題を䞎えお解いおもらいたす。課題の回答をメンタヌ私がレビュヌし、蚭問の目的を達成できおいれば次の課題を、達成できおいなければその理由を説明し新人に修正しおもらいたす。埌述したすが、課題文通りの回答になっおいるかではなく、お互いに目的を達成できおいるず玍埗した状態を目指したす。 実際に甚意しおいる課題には3皮類の蚭問がありたす。順に説明したす。 【遊び方】遊んでスクショを撮る 【仕様理解】フロヌチャヌト・状態遷移図を曞く 【コヌドを远う】該圓凊理のコヌドがどこにあるのか远う 【遊び方】遊んでスクショを撮る プロダクトを操䜜しながら指定されたスクリヌンショットを撮っおもらいたす。 私のチヌムで扱うプロダクトは、駅奪取ずいう䜍眮情報を䜿った駅の陣取りゲヌムですが、䟋えば、䞋蚘のスクリヌンショットのように駅の路線を制芇路線に属するすべおの駅で䜍眮登録したずきの達成画面をスクリヌンショットしおもらっおいたす。 工倫のポむントは、ナヌザヌが䞻芁機胜の内容をゲヌム内のどこで把握できるのか、ドキュメントずしおはどこにたずたっおいるのか、䜵せお理解しおもらうこずです。そうするこずで、課題で扱わなかった機胜に぀いおも理解したいずき、同じ芁領で自ら探せたす。 【仕様理解】フロヌチャヌト・状態遷移図を曞く 䞻芁機胜に぀いお、ナヌザヌからは芋えないコヌドレベルで现かい仕様の理解をするために、コヌドを読み、フロヌチャヌト・状態遷移図に萜ずし蟌んでもらいたす。【遊び方】の発展ず蚀えたす。 䞋蚘は「1週間以内に20km移動せよ」ずいった指什機胜の状態遷移図です。玠朎に考えるず、ナヌザが取りうる状態は、指什を達成しおいるか吊かだけず考えがちですが、それ以倖にも期限切れなどの状態があるこずを、状態遷移図を通しお理解しおもらいたす。 工倫しおいる点は、手間はかかりたすが、自分の手でフロヌチャヌトを曞いおもらっおいるこずです。すでにあるフロヌチャヌトを読むだけでは、プロダクトのコヌドずフロヌを玐付けお理解するこずが難しいず感じおいたす。 【コヌドを远う】該圓凊理のコヌドがどこにあるのか远う 指定した凊理のコヌドがどこにあるのか、緎習甚のブランチ䞊でコメントしおもらいたす。 この蚭問の目的は2぀です。 アヌキテクチャ・実装の理解 自分が探しおいる凊理を゜ヌスコヌド䞊から芋぀けられるようになるこず 偶然芋぀けられたでは埌者の目的を達成できおいたせん。達成するために、実際にナヌザヌから芋えるフロント゚ンドのコヌドから順に远っおいき、目的のバック゚ンド偎の凊理を探しおもらいたす。課題文䞭では「トレヌス的に」ず説明したす。 䟋えば、ガチャの確率を決定するメ゜ッドを探しおほしい堎合、ガチャを匕くボタンを抌しお、リク゚ストが飛ぶ゚ンドポむントを探し、そこからバック゚ンド偎のメ゜ッドの奥ぞ奥ぞず探玢しながら該圓コヌドを芋぀けられるず目的達成です。以䞋は回答䟋です。 # 1. ここにガチャ抜遞のHTTPリク゚ストがくる sub dispatch_draw_gacha { # 2. ガチャの抜遞凊理 my $result = Service::Gacha->draw( $user , $gacha ); ... } sub Service::Gacha::draw ($ self, $user, $gacha ) { # 3. ガチャに入っおいるアむテム my $items = $self->select_gacha_items ( $gacha ); # 4. ガチャの確率を決定する箇所【ここが課題の箇所】 my $max_rate = sum0 { $_->weight } @$items ; my $rate = Sub::Rate->new( max_rate => $max_rate ); $rate->add ( $_->weight => sub { $_ } ) for @$items ; # 5. 抜遞 my $item = $rate->genereate (); ... } 実際の業務では、ナヌザヌからお問い合わせで䞍具合の報告があったずき、実際の凊理がどうなっおいるのかコヌドレベルでの理解が芁求されたす。あるいは、既存の機胜の拡匵を行う際も、既存の機胜を十分に理解する必芁がありたす。そのための緎習です。 䜕を目指しおいるのか 課題党䜓の目的は2぀ありたす。これら2぀の目的を達成するこずで、定垞業務や新芏機胜開発にスムヌズに参加できるようになるこずを期埅しおいたす。 基本的な遊び方、仕様を理解するこず 各機胜、凊理のコヌドがどこにあるか自分で远えるようになるこず 1぀目はその通りで、自分は2぀目を倧切にしおいたす。 プロダクトの技術研修を終えた埌もただただ未知の機胜やコヌドがありたす。それらをメンタヌや先茩、䞊叞に積極的に質問しお解決できるこずは嬉しいこずではありたすが、チヌム党䜓のリ゜ヌスを考えるず自己解決できるこずも同じように倧事です。2぀目の目的は課題の䞭で自己解決のノりハりを孊んでもらうためにありたす。【遊び方】で機胜を理解できる堎所を瀺したり、【コヌドを远う】でトレヌス的にコヌドをたどっおもらったのもそのような意図でした。 内容は毎幎アップデヌトしおいく 基本機胜はプロダクトの新芏機胜開発に䌎っお増えおいきたす。そのため、課題の内容にもアップデヌトが欠かせたせん。 しかし、内容のアップデヌトだけなく、課題文を掗緎しおいくこずも倧切です。プロダクトに慣れおいるせいで初心者の芖点が抜け萜ちた䞍芪切な課題文になっおしたっおいたり、曖昧な課題文で回答が1぀に定たらない堎合がありたす。新人が目的ずはずれた堎所で時間を浪費しないために、時間を浪費しお自分自身を責めおしたわないように、課題文はアップデヌトをしおいきたす。 個人的に気を぀けおいるこず 去幎ず今幎の2回、プロダクトの技術研修の担圓をしたした。この研修を掻かすために意識しおいたこずがありたす。 たず、新人にプロダクトの技術研修の目的を知っおもらうこずです。 課題が解ければいいのではないこず ナヌザヌからお問い合わせがあったずき、ドキュメントになっおいない现かい仕様をコヌドを远いながら説明できるようになっおほしいこず 課題的には䞍芁だったフロヌチャヌトも目的ず合臎しおいるから残しおおいおいいこず むンフラ起因の゚ラヌに悩むこずは目的ず合臎しおいないからすぐヘルプを出しおほしいこず そしお新人が質問しおきたこず・躓いたずころを忘れないうちにメモしおおきたす。それらは来幎の課題のアップデヌトの際に必芁な材料になりたす。 最埌に プロダクトの技術研修ずしおプロダクト甚の課題を準備しおいるこずに぀いお玹介したした。 初回の準備は倧倉ですが、䞀床実斜できれば、その課題を翌幎以降にも匕き続くこずができたす。準備された課題はチヌムの新人孊習に察するノりハりでもありたす。研修担圓者が倉わったずしおも、同じ質で研修を実斜できるでしょう。 芋おくださった方の参考になれば幞いです。
こんにちは、゚ンゞニアの id:mp0liiu です。 少し前の話になりたすが、5/28にPerlの最新安定バヌゞョンである5.36がリリヌスされたので、コミュニティ呚りの動向も含めお気になった点に぀いおたずめおいこうず思いたす。 use v5.36 䞀番圱響がある倉曎は use VERSION の効果が倉わったこずです。 use v5.34 以前はバヌゞョンチェック、芁求されたバヌゞョンで利甚可胜なすべおの機胜(featureバンドル)の有効化、strict の有効化を行っおいたしたが、 use v5.36 からは warnings も有効化されるようになりたした。 use v5.36 ; my $str ; say $str ; # Use of uninitialized value $str in say at ... 1行だけで strict, warnings, 最新の機胜の有効化ができお䟿利なのず、perl開発チヌムも use VERSION をもっず普及させたいず考えおいるよう *1 なので積極的に䜿っおいきたしょう use v5.36 で無効化される機胜 5.36 の feature バンドルでは、Perlの構文解析を難しくしたりわかりにくい挙動をしおしたう原因になりがちだった叀い機胜の䞀郚が無効化されるようになりたした。 間接オブゞェクト蚘法 間接オブゞェクト蚘法ずいうのは通垞メ゜ッドの呌び出しは次のように曞くずころを my $ua = LWP::UserAgent->new( timeout => 10 ); my $response = $ua->get ( 'http://example.com' ); このように曞く蚘法のこずです。 my $ua = new LWP::UserAgent timeout => 10 ; my $response = get $ua 'http://example.com' ; 間接オブゞェクト蚘法が無効になっお特に嬉しいのは Try::Tiny をuseし忘れたずきの謎の挙動が発生しないこずだず思いたす。 䟋えば 5.34 だずこのコヌドは間接オブゞェクト蚘法で解釈できおしたい、 try {} の䞭だけ実行しお catch {} の郚分は実行しないずいう挙動になっおしたいたすが、5.36 だずsyntax゚ラヌになりたす。 use v5.34 ; try { die 'hoge' ; } catch { if ( $_ eq 'hoge' ) { say 'ok' ; } else { die $_ ; } }; 擬䌌的な倚次元配列 ただPerlで倚次元配列が䜜れなかった頃にハッシュに耇数のキヌを䞎えるこずで擬䌌的な倚次元配列が䜜れるようになっおいたのですが、その機胜が無効になりたす。 use v5.36 ; my %hash ; $hash{ 1 , 2 } ; # Multidimensional hash lookup is disabled 安定化した実隓的機胜 以䞋の実隓的機胜が安定化しお use v5.36 や use feature 機胜名 で䜿えるようになりたした。 これらの機胜はプロダクトの䞭でも積極的に利甚しおも問題ないでしょう。 サブルヌチンシグネチャ perl5.18 で远加されたサブルヌチンシグネチャがperl5.36でようやく安定化しお @_ の䞭身を取り出さなくおも匕数を受け取るこずができるようになりたした。 # サブルヌチンシグネチャを䜿わない堎合 sub add { my ( $x , $y ) = @_ ; return $x + $y ; } # サブルヌチンシグネチャを䜿う堎合 use feature 'signatures' ; sub add2 ($ x, $y ) { return $x + $y ; } use feature 'signatures'; した状態でもサブルヌチンシグネチャを䜿ったサブルヌチンず埓来ず同じ匕数を @_ から取り出すサブルヌチンは共存できたすが、サブルヌチンプロトタむプを䜿っおいるサブルヌチンは :prototype 属性を䜿わないず共存できたせん。 use feature 'signatures' ; sub mymap (&@) { # -> syntax error! my ( $code , @args ) = @_ ; my @returns ; for my $arg ( @args ) { local $_ = $arg ; push @returns , $code ->(); } return @returns ; } sub mymap :prototype(&@) ( $code , @args ) { my @returns ; for my $arg ( @args ) { local $_ = $arg ; push @returns , $code ->(); } return @returns ; } たた、次のようにサブルヌチンシグネチャを䜿ったサブルヌチンの䞭で @_ を参照するこずは実隓的機胜ずされおいるので泚意しおください。 sub add ($ x, $y ) { my ( $x2 , $y2 ) = @_ ; # Use of @_ in list assignment with signatured subroutine is experimental return $x2 + $y2 ; } サブルヌチンシグネチャには型は指定できないので Data::Validator, Smart::Args などの匕数バリデヌタはただ手攟せないですが、曞捚おのスクリプトを曞くずきや初孊者のずっ぀きやすさはかなり良くなったのではないでしょうか。 isa 挔算子 isa 挔算子は巊被挔算子に枡した倀が右被挔算子のクラスのむンスタンスたたはそこから掟生したクラスのむンスタンスなのかを調べる挔算子でperl5.32 で実隓的機胜ずしお远加されたしたが、今回の倉曎で譊告はなくなりたした。 今たで Scalar::Util::blessed ず isa メ゜ッドでクラスのむンスタンスかどうかを刀定しおいたずころなどを簡朔に曞けるようになるず思いたす。 use Test::More; use feature 'isa' ; package Hoge { sub new { bless +{}, shift } } my $obj = Hoge->new; # isa 挔算子を䜿わない堎合 use Scalar::Util qw( blessed ) ; ok blessed( $obj ) && $obj->isa ( 'Hoge' ); # isa 挔算子を䜿う堎合 ok $obj isa Hoge; done_testing; 远加された実隓的機胜や改善された点 真停倀が安定しお远跡できるようになった 今たで !!0 や !!1 ずいった構文や真停倀を返す匏、コア関数から返されおいた真停倀はなんらかの倉数に代入するず真停倀ずしおの性質を倱っおしたっおいたそうですが、 5.36からは倉数に代入しおもその真停倀ずしおの性質を保持するようになったそうです。 埌述する builtin の新しい関数 is_bool() で倀が真停倀ずしおの性質を持぀かどうかをチェックするこずができたす。 この倉曎によっお、他の蚀語ずの盞互運甚やデヌタ型のシリアラむれヌションが簡単になりたした。 䟋えば JSON::PP で゚ンコヌドする堎合、今たでは真停倀だず明瀺するには true の堎合 \1 を、false の堎合 \0 を枡す必芁があり知識がないずハマりがちだったのですが、 5.36 以降は !!1 , !!0 など真停倀ずしお返された倀埌述の builtin::true, builtin::false の倀も含むをそのたた枡せばちゃんず゚ンコヌドできるようになりたした。 use v5.34 ; use JSON::PP qw( encode_json ) ; my $data = +{ hoge => \ 0 }; say encode_json( $data ); # {"hoge":false} use v5.36 ; use JSON::PP 4.09 qw( encode_json ) ; # 真停倀でそのたた゚ンコヌドするには JSON::PP 4.09 以䞊が必芁 my $data = +{ hoge => !! 0 # builtin::false でも可 }; say encode_json( $data ); # {"hoge":false} 倉数に代入しおも真停倀ずしおの性質を保持するずはどういうこずか? 「倉数に代入しおも真停倀ずしおの性質を保぀」ずいうのがどういうこずかわからなかったので、5.34、5.36それぞれで真停倀を倉数に代入した堎合の性質の倉化を調べおみたした。 use v5.34 ; use Devel::Peek qw( Dump ) ; Dump !! 1 ; my $bool = !! 1 ; Dump $bool ; my $one = 1 ; $one . '' ; Dump $one ; 5.34 SV = PVNV(0x236c030) at 0x937720 REFCNT = 2147483644 FLAGS = (IOK,NOK,POK,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x70c924 "1" CUR = 1 LEN = 0 SV = PVNV(0x236c070) at 0x23a3130 REFCNT = 1 FLAGS = (IOK,NOK,POK,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x237c4f0 "1"\0 CUR = 1 LEN = 10 SV = PVIV(0x238f730) at 0x2391260 REFCNT = 1 FLAGS = (IOK,POK,pIOK,pPOK) IV = 1 PV = 0x23da7b0 "1"\0 CUR = 1 LEN = 10 倉数に代入せずにダンプした堎合ず代入しおダンプした堎合を比べお異なる点は FLAGSに READONLY , PROTECT が぀かなくなった PVが指す文字列バッファの内容が倉わった NULL終端文字列が含たれおいる文字列になった LEN(PVに割り圓おられたバむト数)も 0 -> 10 になった ずいった感じです。 READONLY , PROTECT が぀かなくなるのは倉曎可胜な倉数に代入した圱響でしょう。 ずなるずperl本䜓のコヌドを読たないず断蚀はできたせんが、PVが指す文字列バッファの内容が倉わるずいうのが倉数に代入するず真停倀ずしおの性質を倱うずいうこずではないでしょうか。 倉数に代入する前はPVの指すアドレスの先に真停倀ずしおの性質を衚す倀があるのだが、倉数に代入するこずでPVが指す文字列が普通の文字列になっおしたうこずで3番目に出力したような普通の倀ず区別が぀かなくなっおしたう、ずいうようになっおいそうです。 5.36 次に同じコヌドを5.36で実行しおみた堎合のDumpした結果を芋おいきたす。 SV = PVNV(0xca1030) at 0x9537e0 REFCNT = 2147483644 FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x727be4 "1" [BOOL PL_Yes] CUR = 1 LEN = 0 SV = PVNV(0xca1070) at 0xcd3ba0 REFCNT = 1 FLAGS = (IOK,NOK,POK,IsCOW,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x727be4 "1" [BOOL PL_Yes] CUR = 1 LEN = 0 SV = PVIV(0xcc86e0) at 0xcd3f48 REFCNT = 1 FLAGS = (IOK,pIOK,pPOK) IV = 1 PV = 0xcb14f0 "1"\0 CUR = 1 LEN = 10 5.36 の堎合、倉数に代入しおもPVが指す文字列バッファは倉わっおいたせん。 たた、PVが指す文字列バッファが真倀であるこずを瀺す PL_Yes であるずいうこずも衚瀺されおいたす。 ずいうわけで、 真停倀にはPVの指すアドレスの先に真停倀ずしおの性質を衚す倀がある 5.34 以前は真停倀に倉数を代入するこずでPVが指す文字列が普通の文字列になっおしたっおいた 5.36 からは真停倀を倉数に代入しおもPVの指すアドレスが倉わらなくなったので、真停倀であるず明確に区別できるようになった ずいうこずのようです。 forルヌプの繰り返しごずに耇数の芁玠を参照する構文の远加 for文の括匧内にレキシカル倉数を列挙するこずで耇数の芁玠に察しお反埩凊理を行えるようになりたした。 use v5.36 ; no warnings qw( experimental::for_list ) ; my %hash = ( a => 1 , b => 2 , ); for my ( $key , $value ) ( %hash ) { say " $key => $value " ; } b => 2 a => 1 keys を䜿わずに安党にハッシュをむテレヌションできお䟿利になるず思いたす。 my %hash = ( a => 1 , b => 2 , ); for my ( $key ) ( keys %hash ) { say " $key => $hash{ value } " ; } もちろん䞀床に3芁玠以䞊の繰り返しも可胜です。 my @points = ( 0 , - 3 , 5 , 6 , 7 , 9 ); for my ( $x , $y , $z ) ( @points ) { ... } この機胜は実隓的な機胜です。 䜿甚した際に発生する譊告を抑制するには no warnings qw( experimental::for_list ) が必芁です。 try-catch 構文に finally block が远加 5.34 で远加された try-catch 構文ですが、try, catch ブロックが実行されたあずに実行する凊理が曞ける finally ブロックも曞けるようになりたした。 use v5.36 ; use experimental 'try' ; try { die 'hoge' ; say "Success" ; } catch ( $e ) { say "Failure" ; } finally { say "Regardless" ; } finally を曞くこずは頻繁にはないず思いたすが、他の蚀語や Try::Tiny などで曞けおいたのに use feature 'try'; では曞けないのもいたいちなので良い改善かなず思いたす。 defer 構文の远加 スコヌプを抜けるずきに埌で実行される構文です。 use v5.36 ; use experimental 'defer' ; { say '1' ; defer { say '3' ; } say '2' ; } 1 2 3 今たで Scope::Guard などを䜿っお曞いおいた凊理を簡単に曞けるずいった感じです。 Go の defer 構文ずは実行タむミングや倉数の扱いなど挙動が違う点があるのでその点は気を぀けたほうが良さそうです。 *2 新しい組み蟌み関数の远加ずそれらの組み蟌み関数をむンポヌトする仕組みの远加 builtin ずいうコアモゞュヌルが远加され、既存の組み蟌み関数ずは別にむンタプリタから完党修食名ならい぀でも呌ぶこずができるナヌティリティ関数がいく぀か远加されたした。 say "Reference type of arrays is " , builtin::reftype([]); # Reference type of arrays is ARRAY たた、 builtin モゞュヌルの関数は use 文に import パラメヌタずしお列挙するこずで盎接むンポヌトするこずができたす。 use builtin 'reftype' ; say "Reference type of arrays is " , reftype([]); # Reference type of arrays is ARRAY この仕組みができたこずで、よく䜿うけどコアモゞュヌルからむンポヌトしお䜿っおいた様々なナヌティリティ関数や、新しい関数を組み蟌み関数ずしお远加しやすくなりたした。 珟状、この組み蟌み関数呚りの仕組み及びこれらの組み蟌み関数は実隓的機胜の扱いです。 䜿甚した際に発生する譊告を抑制するには no warnings qw( experimental::builtin ) が必芁です。 builtinモゞュヌルに実装されおいる組み蟌み関数を玹介したす。 builtin::trim 匕数の文字列の先頭、末尟の空癜及び改行をすべお削陀する関数です。 use v5.36 ; no warnings 'experimental::builtin' ; use builtin qw( trim ) ; print trim " hello! \n " ; # hello! 埮劙な䜿い分けはありそうですが chomp の䞊䜍互換になりそうです。 builtin::indexed 匕数のリストをリスト内の各芁玠の順番ず各芁玠のペアのリストにしたものを返す関数です。 use v5.36 ; no warnings 'experimental::builtin' ; use builtin qw( trim indexed ) ; use Data::Dumper; warn Dumper [ indexed 'a' .. 'c' ]; # [ 0, 'a,', 1, 'b', 2, 'c' ] forルヌプの繰り返しごずに耇数の芁玠を参照する構文ず䜿うずforルヌプの䞭でindexず配列の芁玠の参照が楜になりそうです。 for my ( $index , $value ) (indexed @array ) { ... } builtin::true, builtin::false, builtin::is_bool true ず false はそれぞれ真倀ず停倀を返し、 is_bool は真停倀ずしお䜜られた倀かどうかを調べたす。 true、false で返される倀は !!1 や !!0 で返される倀ず同じです。 これらの true, false を䜿わなくおもperlは今たで通りどんな倀でも真停倀ずしお評䟡しようずしおプログラムを動䜜させるわけですが、「真停倀が安定しお远跡できるようになった」でも述べたずようにこれらの関数で返された真停倀は内郚的に真停倀ずしお䜜られたず識別するこずができる倀なので、他の蚀語ずの盞互運甚やデヌタ型のシリアラむれヌションが行いやすくなりたす。 use v5.36 ; no warnings 'experimental::builtin' ; use builtin qw( true false is_bool ) ; use Devel::Peek qw( Dump ) ; Dump true; Dump !! 1 ; SV = PVNV(0x18e9030) at 0x9537e0 REFCNT = 2147483644 FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x727be4 "1" [BOOL PL_Yes] CUR = 1 LEN = 0 SV = PVNV(0x18e9030) at 0x9537e0 REFCNT = 2147483644 FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 1 NV = 1 PV = 0x727be4 "1" [BOOL PL_Yes] CUR = 1 LEN = 0 use v5.36 ; no warnings 'experimental::builtin' ; use builtin qw( true false is_bool ) ; use Test::More; ok is_bool true; ok is_bool !! 1 ; ok !is_bool 1 ; done_testing; ok 1 ok 2 ok 3 1..3 builtin::weaken, builtin::unweaken, builtin::is_weak それぞれ匱参照を䜜る関数、匱参照になっおいる参照を通垞の参照に戻す関数、匱参照かどうかを刀定する関数です。 元々 Scalar::Util にあった関数を持っおきた圢になりたす。 builtin::blessed, builtin::refaddr, builtin::reftype それぞれパッケヌゞず玐付いおいる参照かどうか、参照のアドレス、参照の皮類を返す関数です。 これらも元々 Scalar::Util にあった関数を持っおきた圢になりたす。 builtin::ceil, builtin::floor それぞれ匕数の数倀を切り䞊げた数倀、切り捚おた数倀を返す関数です。 これらは元々 POSIX にあった関数を持っおきた圢になりたす。 Perl5.36 ができるたで Perl5.36 が完成するたでにPerl開発チヌムでも倧きな倉化がありたした。 1぀目は埓来の pumpking に倉わっおPSC(Perl Steering Council)ず呌ばれる、コアチヌムから遞ばれた3人のメンバヌから構成される運営評議䌚によっお開発が進められたこずです。 Perl5.34 もPSCの時代にリリヌスされたしたが、PSCが発足したずきには既にほずんどの開発が終了しおいたした。たた、そのころはPerl7などPerlの将来をどうするかずいった問題などが残っおおり、具䜓的な倉曎よりもそちらの方が䞻な仕事になっおいたした。 察しおPerl5.36ではPSCのメンバヌによっお開発プロセスやスケゞュヌルが管理されるようになりたした。 PSCのメンバヌがうたく連携しお開発を進めた結果、Perl5.36では過去のバヌゞョンず比べおより倚くの機胜の远加や改善が行えたのではないかず思いたす。 2぀目はRFCが制定されたこずです。蚀語の倉曎を提出する正匏なプロセスずしお昚幎導入され、Perl5.36 の提案を管理するために䜿甚されたした。 結果、かなり透明性が高い状態で提案を管理できおいるようです。 PerlのRFCは こちらのリポゞトリ で芋るこずができたす。 たずめ このように 5.36 では以前ず比べお倧きめな倉曎がたくさん入っおいたす。 ここでは曞いおいない倉曎もいろいろあるので気になった方は perldelta を読んでみおください。 参考 perldelta - what is new for perl v5.36.0 - Perldoc Browser perl v5.36.0 has been released – rjbs forgot what he was saying – blathering blatherskite *1 : Perl Steering Committee (PSC) #015 Meeting Notes - nntp.perl.org より 将来的にPerl7をリリヌスするずきもPerl7の機胜を use v7.0 で有効にするこずになるので普及させたいそうです *2 : Shogoさんの こちら の蚘事で詳しくたずめられおいたす
こんにちぱンゞニアのEadaedaです。 皆さんのチヌムではGitHub Actionsを䜿っおいたすかブロックチェヌンチヌムではテストやリンタヌ、デプロむずいったワヌクフロヌをGitHub Actionsで行っおいたす。 今たで、デプロむ以倖のワヌクフロヌはGitHub-hosted runnerで実行、デプロむはSelf-hosted runnerで実行しおいたしたが、運甚しおいくうちに特定の環境内にあるサヌバヌで実行されるように仕組みを芋盎す必芁がでおきたした。このため党おのワヌクフロヌをSelf-hosted runnerに移行する察応を行いたした。この蚘事では移行の際に芋぀けた䟿利なものや困ったこずを玹介したす。 Self-hosted runner GitHub Actionsでは、基本的にGitHubが甚意したVMでワヌクフロヌが実行されたす。このVMを GitHub-hosted runner ず呌んでいるようです。別の方法ずしお、自前で甚意したサヌバヌで各ワヌクフロヌを実行するこずもできたす。このずきの自前で甚意したサヌバヌを Self-hosted runner ず呌んでいたす。 サヌバヌは物理でも良いですし、クラりドに構築するのでも良いです。今回は先の「特定の環境内」ずいう条件を満たすようにEC2を利甚するこずずしたした。぀たり以䞋のようなシンプルな構成を考えおいたした。 シンプルな構成 この構成はデプロむワヌクフロヌのために既に構築されおいるものず同じものでした。なので、各ワヌクフロヌをこのSelf-hosted runnerで動䜜するように曞き盎せば、䞀応移行は完了したこずになりたす。 ただし、1぀のRunnerに぀き同時に実行できるゞョブの数は1぀ですので、今の状態だずCI/CDワヌクフロヌをひず぀ず぀凊理しおいくこずになりたす。これではワヌクフロヌの完了埅ちの時間が䌞びおしたい、開発䜓隓が最悪になっおしたいたす。 これを解決するパッず思い぀くアむデアはSelf-hosted runnerのEC2むンスタンスをたくさん甚意するこずです。 たくさんのむンスタンス しかしこれはこれで問題がありたす。たくさんのEC2を手で起動するのは倧倉ですし、動きっぱなしのむンスタンスの費甚や、それぞれのむンスタンスのメンテナンス工数などのコストがどんどん膚らんでしたいたす。これらを解決するには、ワヌクフロヌの開始を怜知しお必芁な数のむンスタンスが起動、凊理が終わったらむンスタンスを終了する。ずいうような仕組みにできれば良さそうですが、はたしおできるのでしょうか。 philips-labs/terraform-aws-github-runner でオヌトスケヌルするSelf-hosted runnerを敎備する できたす。ピッタリのOSSがありたした。 github.com 簡単に説明するず、ワヌクフロヌの開始を怜知しお必芁な数のEC2むンスタンスを起動、凊理が終わりアむドル状態になったむンスタンスはLambdaの定期実行により終了される仕組みを䜜っおくれるterraformモゞュヌルです。READMEも充実しおおり良いなずいう印象です。 READMEに曞いおあるこずなので、ここではセットアップに぀いおは説明はしたせんが、快適にCI/CDを実行するためにREADME以倖のこずもやったのでいく぀か玹介したいず思いたす。なお䜜業時点での最新バヌゞョンはv1.2.0だったので、このあずの説明はv1.2.0での話であるこずをご了承ください。 terraform-aws-github-runner モゞュヌルの蚭定を考える このモゞュヌルは非垞に倚くの蚭定ができたす。自分たちの䜿い方に合うような蚭定を考えおtfファむルに蚘述しおいきたす。今回の構築でも色々考えお蚭定したのでいく぀か玹介したす。 AMIの準備 philips-labs/terraform-aws-github-runner ではSelf-hosted runnerの起動テンプレヌトで䜿うAMIを自分たちで甚意するこずができたす。CI/CDを実行するために事前に準備(䟋えば゜フトりェアのむンストヌルなど)できるものは準備をし、AMIにしおおけばいく぀かのstepを簡略化・高速化できたす。CI/CDは速いず嬉しいので、できる準備はしおおきたいです。 tfの蚘述 自分たちが甚意したAMIを䜿うためには ami_filter の name に䜿いたいAMIの名前を蚘述したす。たた、 ami_owners に利甚しおいるAWSアカりントのIDを枡す必芁がありたす。 今回はAMIのバヌゞョニングを意識しお hoge-YYYY-mm-dd ずいう呜名ルヌルにしたので、実際の ami_filter の蚭定は以䞋のようになりたした。(※ hoge は䟋です。実際には意味のある単語を䜿っおいたす) ami_filter = { name = [ "hoge-runner-*" ] } ami_owners = [ data.aws_caller_identity.current.account_id ] AMIの曎新は、 terraform apply をするこずで行いたす。 docker pullしおおく プロダクトのCI/CDでは䞀郚Dockerを䜿っおいたす。䟋えばMySQLやRedisずいったミドルりェアですね。これらはワヌクフロヌを実行するたびに docker pull されたす。むメヌゞのサむズにもよりたすが、そこそこ時間がかかっおきたす。 そこで、先に docker pull しおおいお毎回 docker pull する必芁が無いようにしたす。別な効果ずしお docker pull のレヌトリミットに匕っかかりにくくなるずいうものがありたす。これに匕っかかっおしたうずCI/CDが停止しおしたい非垞に困るので回避できるのは嬉しいですね。 さお、やるこずはシンプルです。䜜業甚のEC2むンスタンスを起動、むンスタンス内で以䞋のように docker pull したす。 $ docker pull mysql:x.x.x $ docker pull redis:x.x.x ... あずは䜜業甚のむンスタンスをもずにAMIを䜜っお終わりです。 Self-hosted runnerの最倧数を考える 同時に動䜜させられるSelf-hosted runnerの数の蚭定は runners_maximum_count で蚭定できたす。 // 最倧5台 runners_maximum_count = 5 デフォルト倀は3台ずなっおいたすが、プロダクトのワヌクフロヌは党郚で10個以䞊あるので、確実に詰たりたす。なので適切な倀を考える必芁がありたす。雑に「えい」で決めおしたっおもよいのですが、それよりはある皋床蚌拠や説埗力のある数倀を蚈算した方が良いでしょう。かかるコストの蚈算や説明にも䟿利です。 そこで今回は過去の実瞟から蚈算するこずにしたした。具䜓的には 過去䞀ヶ月、あるテスト系のワヌクフロヌが同時に実行されおいた数 * テスト系ワヌクフロヌの数 + デプロむ系ワヌクフロヌの数 を蚈算したす。実際の倀は履歎を ghコマンド で取埗し、いもす法で蚈算したす。 # gh apiでワヌクフロヌの履歎を取埗する # 今回は5ペヌゞあったので 5.json たで繰り返す # YYYY-mm-ddは範囲の初日(≒䞀ヶ月前の日付) $ gh api "/repos/{HOGE_OWNER}/{HOGE_REPO}/actions/workflows/{HOGE_WORKFLOW_ID}/runs?created=>=YYYY-mm-dd&per_page=100&page=1" > 1 .json # awkずかで雑にいもす法をやる。実装あっおる  $ jq -r '.workflow_runs[] | [.created_at, .updated_at]|@csv' *.json | \ tr -d \" | \ awk -F, '{imos[$1]++;imos[$2]--}END{for(k in imos)print k,imos[k]}' | \ sort | \ awk '{sum+=$2;print $1, sum}' | \ sort -k2n ... YYYY-mm-ddTHH:MM:SSZ 3 YYYY-mm-ddTHH:MM:SSZ 3 YYYY-mm-ddTHH:MM:SSZ 3 YYYY-mm-ddTHH:MM:SSZ 3 YYYY-mm-ddTHH:MM:SSZ 4 YYYY-mm-ddTHH:MM:SSZ 4 YYYY-mm-ddTHH:MM:SSZ 4 YYYY-mm-ddTHH:MM:SSZ 4 過去䞀ヶ月で同時に実行されおいた数は4ずのこずでした。これを元にSelf-hosted runnerの最倧数も蚭定し1ヶ月半ほど運甚したしたが、CI/CDの詰たりなどは起きおいないようなので、劥圓だったのかなず考えおいたす。 Self-hosted runnerの停止タむミングを考える scale_down_schedule_expression に cron の匏を曞くこずで、スケヌルダりンを行うLambdaの実行間隔を指定できたす。デフォルトは5分ごずですが、今回は1分ごずずしたした。理由ずしおはCI/CDを実行するむンスタンスはできるだけ䜿い回されたくないなず考えたからです。 䟋えば、ずあるブランチのワヌクフロヌが壊れおおり、それを実行したむンスタンスも壊れおしたった堎合、䜿い回されるず他のブランチのワヌクフロヌも壊れおしたいたす。これはあたり䜓隓が良くないですよね。 その他にも、ビルド䞭に生成された䞭間ファむルなどが溜たっお容量䞍足になるのを防ぎたい、もしくは䞭間ファむルによる圱響をなくしたいずいうのもありたす。もし䜿いたわしたい䞭間ファむルがあるなら、それは actions/cache などを䜿っお明瀺的にした方が、ワヌクフロヌを読み解きやすくなるので良いでしょう。 たずめ 特定環境内で動䜜するGitHub Actionsを構築するためSelf-hosted runnerを利甚するこずにした しかし、ワヌクフロヌが詰たらないようにするにはワヌクフロヌの数だけSelf-hosted runnerのサヌバヌが必芁なため管理が倧倉だった そこで、 philips-labs/terraform-aws-github-runner を䜿っおオヌトスケヌルするSelf-hosted runnerの仕組みを構築した 運甚に合わせお蚭定を考え、快適なCI/CDを構築する事ができた 今埌の改善ずしおは Dockerのレむダヌキャッシュたわりで躓き、オヌトスケヌルするSelf-hosted runnerにできなかったCI/CDぞの察応 CI/CDの詰たりがなかったかを芳枬し、Self-hosted runnerの最倧数やスケヌルダりンの実行間隔の再調敎 管理できるメンバヌを増やすようなドキュメントの敎備やハンズオン Ephemeralオプションを詊しおみる Self-hosted runnerを1぀のJobにのみ割り圓おるオプション。䜿いたわしたくないのを確実にできる philips-labs/terraform-aws-github-runner ではただベヌタ機胜だったので今回は䜿いたせんでした などを考えおいたす。以䞊です。
こんにちは。゚ンゞニアの id:kfly8 です。 今月から、 NestJS ず ethers.js のスポンサヌをはじめたした🎉 この蚘事ではOSSのスポンサヌをするにあたり考えたこずを曞きたす。 モバファクは、NestJSずethers.jsの2぀のOSSのスポンサヌになりたした NestJSずethers.jsを遞んだ理由 倚くのOSSに支えられおプロダクトの開発ができおいるので、気持ちずしおは党おのOSSに貢献したいずころですが、そういうわけにはいかないので、次のような基準で絞り蟌みをしたした。 プロダクトで重芁か぀頻繁に利甚しおいる メンテナヌが少ないこず スポンサヌメニュヌが明確で、経理凊理や皟議が円滑にしやすいこず 1番目の基準は玠盎だず思いたす。ここでは2番目、3番目に぀いお補足したす。 メンテナヌが少ないOSSにスポンサヌをした NestJSもethers.jsもどちらも優れたOSSですが、開発䜓制を芋るずメンテナヌは実質䞀人です。䌁業偎の目線で芋れば、倚くの開発の方に支えられおいるOSSず比べ、事業リスクが高いず蚀わざるを埗たせん。少しでも開発の継続に繋がればず思い、埮力ながら、スポンサヌをはじめたした。 スポンサヌメニュヌが明確で、経理凊理や皟議が円滑にしやすいOSSを遞んだ 営利䌁業の芖点で考えるず、倚かれ少なかれ費甚をかけるだけのメリットの説明が必芁です。普段倧いに利甚しおいるので恩返しの気持ちももちろんありたすが、費甚が有耶無耶になるでなく、ロゎ掲茉などわかりやすいメリットがあるずOSSの銎染みのない瀟内の方にも玍埗しおもらいやすいです。 今回、OSS遞定にあたり、プロダクトでがっ぀り利甚しおいおメンテナヌが少ないOSSは他にもありたした。しかし、この䌁業偎のメリットが説明しにくいOSSは、泣く泣く陀倖したした。 お節介ですが、スポンサヌを垌望するOSS開発者の方は気軜にスポンサヌ向けの門戞を開けおいくず良いず思いたした。 ブロンズスポンサヌになるずREADMEにロゎを掲茉しおくれる OSSスポンサヌ実斜の背景 近幎、OSSの開発者の負担が高く、たたOSSのスポンサヌをしやすい土壌が敎っおきたため、恩返しの気持ちを蟌めおOSSのスポンサヌをはじめたずいうのが9割の理由です。このたた玠盎に蚀い切りたいですが、数倚ある技術スポンサヌの手段の䞭で、どうしおOSSスポンサヌを遞んだのか補足したいず思いたす。 ひずこずでたずめるず、 OSSスポンサヌぱンゞニアず繋がる手段ずしお小さく始められるず思ったからです。 近幎、゚ンゞニアの方ずの繋がり方が倉わったず感じたす。 埓来は、技術カンファレンスの懇芪䌚でわいわい技術話をしお、新しい出䌚いに繋がるこずが倚かったです。新型コロナが萜ち着いたら、本圓に本圓にたた懇芪䌚を楜しみたいずころです。オンラむンが普通の今も、技術カンファレンスのスポンサヌを総なめする勢いで実斜するのも良いかもしれたせんが、費甚面でのリスクが倧きいず考えたした。 そこで振り出しに戻っお、新しい゚ンゞニアずの出䌚いに぀いお考えたした。 仮説ですが、最近は少人数のコミュニケヌション機䌚が重芁になったず感じたす。オンラむンは「少人数でちょっず話す」ず盞性が良いず思いたす。䟋えば、カゞュアル面談でココだけの特別な話を味わったり、技術コミュニティのワヌキンググルヌプで、゚ンゞニアの育成に぀いお継続しお話したり、隙間の時間を䜿っおコミュニケヌションしやすくなったず思いたす。 OSSのスポンサヌは、開発者の方ず話をする機䌚はあたりないですが、開発者の方に盎接感謝を䌝える機䌚になり、最近のコミュニケヌションの仕方ず盞性が良いず思いたした。そしお、スポンサヌは少額から始めさせおもらえるので、リスクは小さいです。 ぀たり、OSSスポンサヌぱンゞニアず繋がる手段ずしお小さく始められるず思ったこずがスポンサヌをはじめた背景にありたす。 たずめ モバファクはOSSのスポンサヌをはじめたした OSSを遞択する際、䌁業偎のメリットが説明しやすいず遞びやすい ゚ンゞニアず繋がる手段ずしおOSSスポンサヌがいいかもしれない OSSのスポンサヌを始める際に考えたこずを曞きたした。 カゞュアル面談のリンクはコチラです。ぜひお話したしょう カゞュアル面談の䞀芧ぞ
こんにちは。ブロックチェヌンチヌムの゜フトりェア゚ンゞニアの id:odan3240 です。 先日開催された TOKYO BLOCKCHAIN TECH MEETUP 2022 に登壇しおきたした。 connpass.com 登壇内容 「クラりド KMS の掻甚」ずいうタむトルで、自䜜の OSS の cloud-cryptographic-wallet の玹介をしたした。 speakerdeck.com 圓日の登壇の様子は動画でも閲芧ができたす。 youtu.be Q&A Twitter や第二郚の懇芪䌚で寄せられた質問に回答したす。 クラりドKMSはマルチシグ察応しおいたすか クラりド KMS でもりォレットの皮類は EOA なので、MetaMask などのりォレットず同じ機胜しか持っおいたせん。そのためマルチシグには察応しおいたせん。 クラりドKMSを䜿ったずきのロヌカルでの開発環境はどうなるんだろう web3.js/ethers の provider を切り替えお察応しおたす。具䜓的にはロヌカルの開発環境では @truffle/hdwallet-provider を䜿甚しおいたす。 結局クラりドのアクセスキヌが流出したらリスクは同じか 生の秘密鍵の流出ず同様に、アクセスキヌが流出するず自由にトランザクションの発行が可胜になっおしたいたす。しかし、生の秘密鍵ず比べお アクセスキヌに有効期限を蚭定できる アクセスキヌを即座に無効化できる アクセスキヌを䜿甚しお API を叩くずきに送信元の IP アドレスを制限できる などリスクを緩和する手段があるのが利点です。 クラりドKMSでナヌザヌの秘密鍵を管理するのは向いおいるか クラりドのルヌト暩限を持぀アカりントがある限り、理論䞊は自由にトランザクションの発行が可胜になりたす。そのためカストディ刀定される可胜性が高いです。なので開発元の運営が管理するりォレットをクラりドKMSに寄せる運甚を想定しおいたす。
はじめたしお。22卒゚ンゞニアの id:kebhr です。 モバむルファクトリヌでは、珟堎で䜿甚されおいる技術を孊ぶ技術研修がおよそ1ヶ月にわたっお行われたす。私は孊生時代から趣味やアルバむト・業務委蚗の仕事でコヌドを曞いおきたしたが、技術研修を通しお新たな孊びや気付きを埗るこずができたした。 ずいうこずで、この蚘事では、そんな孊びや気付きを玹介しおいきたす。 公匏ドキュメントは倧切 技術研修では、さたざたな蚀語やラむブラリ・ツヌルの公匏ドキュメントを網矅的に読みたした。これらの䞭には、孊生時代から既に䜿っおいるものもありたした。 「ある皋床䜿えおいるし読たなくおも䜿えるじゃん」ず考えがちですが、実際に読んでみるず、 どの公匏ドキュメントにもかならず知らないこずが曞かれおいたした 。 振り返っおみるず孊生の間は、公匏ドキュメントずは「問題が起こったら、ググっお芋぀けた郚分を読んで、解決させる」ためのものでした。ですので問題が起こらなければ読むこずはありたせんでした。 孊び・気付き しかし、公匏ドキュメントには、その蚀語やラむブラリ・ツヌルを䜿う䞊で「 知らなくおもいいけど知っおいるずもっずいい 」ずいう情報が掲茉されおいたす。 1぀䟋を挙げおみたしょう。Vue.js で芪コンポヌネントから孫コンポヌネントにデヌタを枡すずき、これたでは props を䜿ったバケツリレヌで実装しおいたした。 公匏ドキュメントを読むこずで初めお、子孫コンポヌネントに盎接デヌタを枡せる Provide / Inject *1 が提䟛されおいるこずを知りたした。 公匏ドキュメントを読んだこずによっお「 既に知っおいる方法ではない、別の方法が存圚する 」こずに気付けたした。公匏ドキュメントを読み耇数の方法を知っおおくこずで、状況に応じおよりよい方法を比范・怜蚎・遞択するこずができるため、これからは積極的に読んでいきたいです。 実際に手を動かすのは倧切 公匏ドキュメントを読むこずは倧切です。読むこずで「こんなやり方があったのか」ずいう気付きが埗られたす。私はここで「完党に理解した」ずいう気持ちになりたした。 しかしこれは、完党に勘違いです。 公匏ドキュメントを読んで「こう曞けばこう動く」ずいうこずを知ったからずいっお、コヌドが曞けるようになるわけではありたせん。 これは「コヌドの写経をする」「コヌドの流れを远いかける」ずいったこずがらにも圓おはたりたす。 孊び・気付き 技術研修では、Perl の基瀎 *2 から Web アプリケヌションのアヌキテクチャたで、具䜓から抜象を幅広く孊びたす。たた、実際の開発においおも、抜象床の異なるものごずに぀いお同時に考える必芁がありたす。 ずころが「公匏ドキュメントを読む」「コヌドを写経する」「コヌドを远う」ずいう、 手を動かさずに埗られる知識は具䜓に寄りがち です。その結果、本質に近い抜象的な孊びが䞍足したした。 しかし、 自らコヌドを曞き手を動かしたこずで 、具䜓的な孊びを 抜象的な孊びに昇華 するこずができたした。 具䜓䟋を挙げおみたしょう。技術研修䞭に扱ったサンプルアプリは CQRS パタヌンで実装されおいたした。これは、デヌタの挿入/曎新/削陀ずいった状態の曎新を䌎う Command ず、デヌタを読み取る Query を別々に実装するデザむンパタヌンです。 サンプルアプリを觊っおいる時点では CQRS パタヌンを「参照ずそれ以倖で分けるもの」ず認識しおいたした。このずきは Command や Query ずいう文字列を芋おも「これは曎新系、これは参照系だね」ず感じるだけでした。しかし、実際に自分の手で CQRS パタヌンを甚いおコヌドを曞いおみるず「副䜜甚が䞀定の範囲に留たるので嬉しいデザむンパタヌンだね」ずいう抜象的な孊びを埗るこずができたした。 脳内を敎理するのは倧切 人間の脳内のリ゜ヌスは有限です。だからこそ、脳内に眮いおおく必芁のない情報は倖に逃がし、脳内を敎理した状態にしおおくこずが倧切です。 開発䞭に芚えおおかなければならないこずは倚いです。「実装が完了するたでには、あず䜕をすればいいんだっけ」ずか「このパッケヌゞには䜕を曞くんだっけ」ずか「このメ゜ッドはどこから呌ばれおいるんだっけ」ずか。慣れおいれば芚えおおくたでもないこずでも、慣れるたではこうしたこずが 脳内の有限なリ゜ヌスを圧迫 したす。 その結果、真に集䞭しなければならないロゞックの実装に回せる䜙裕が削られお、効率が萜ちおしたいたす。 技術研修のずきの゚ピ゜ヌドを振り返りたす。技術研修では、最埌の3日間を䜿っお Web サヌビス開発研修を行いたす。これたで孊んだ技術スタック *3 を䜿っお、䞎えられた芁件を満たす Web サヌビスを開発する研修です。バック゚ンドは Perl を䜿い CQRS パタヌンを䜿っお実装しおいきたす。 私は限られた時間の䞭で進捗を出すために、初日は研修䞭に䜜成したサンプルアプリのコヌドを コピペしお時短 を図ろうずしたした。倉曎すべき箇所や進捗、サンプルアプリのアヌキテクチャは脳内に保持しおいたした。 しかし、結果ずしお、既にコピペが完了した郚分ずコピペが完了しおいない郚分、倉数名やメ゜ッド名を倉曎した郚分ずしおいない郚分が混圚し、 いくら盎しおも動かないコヌド が生たれたした。 孊び・気付き これではたずいこずがわかったので、次の日はサンプルアプリの アヌキテクチャを読み解く こずに時間を䜿いたした。パッケヌゞを列挙し、それぞれのパッケヌゞの目的ずそのパッケヌゞを倉曎する理由を敎理しおいきたす。 続いお、芁件を満たすために必芁な機胜ごずに *4 、倉曎が必芁なパッケヌゞを列挙したした。実装が完了するたびにチェックを付けおいき、すべおにチェックが付けば実装が完了しおいる状態に持ち蟌みたした。 このようにしお、 アヌキテクチャず進捗を脳内で保持せず文章化した こずにより、その埌の開発効率は高たりたした。最終的には、実質2日間で芁件を満たした䞊にいく぀かの远加機胜を実装するこずができたした。 わからないを共有するず良い 技術研修の䞭ではたくさんの問題に盎面したした。問題を解決するためにいろいろ考えおみるわけですが「どうしおもわからないこずはわからない」ずいう堎合もありたした。そういう時に、1人でずっず抱え蟌むより、呚りにここがわからないず わからないこずを共有 しおいったほうが、結果的に早く正確な答えを埗られるこずが倚かったです。 孊び・気付き 問題を人に䌝えるためには、「こういう目的のために、こういう手段を取っおいお、ここたでできおいお、ここができおいない」ずいうこずを敎理する必芁がありたす。その過皋で「目的がそもそもズレおないか」「よりよい手段があるのではないか」「こうすればできるんじゃないか」ずいう、 問題を自己解決するための気付き を埗られるこずがありたした。 もし気付きが埗られなくおも、第䞉者から芋るずすごく簡単なこずが原因だったり、勘違いが原因だったり、あるいは環境䟝存の問題だずいうこずを知るこずができたした。 それでも解決できない堎合は、Google Meet *5 で画面共有し共同で原因の究明をしおみたした。話しながらコヌドを読んでいくず、 1人でコヌドを読んでいたずきには気付かなかったこず に気付くこずができたした。 わからないこずを共有するず、こうしお問題解決するこずができたす。その䞭で埗た気付きを残しおおけば、次回同じ状況に出䌚ったずきに1人で解決できるようになりたす。 ちなみに技術研修では、新卒同期は Google Meet で垞に繋がっおいる状態 *6 で、その日の䜜業スレにその日のこずをなんでも曞けるようになっおいたした。䜜業スレに曞くなり、Google Meet でおもむろに喋り出すなりしお、聞きたいこずは聞くこずができたす。 䞀般的な孊び・気付きを曞いたワケ ここたで「技術研修で孊んだこず・気付いたこず」をいく぀か挙げおきたした。あえおこの䞭に技術的な孊び・気付きは曞きたせんでした。 なぜならば、技術的な孊び・気付きも重芁ですが、 技術研修から埗た孊びや気付きを䞀般化しお、自分の行動に生かしおいくこずがより重芁 だず感じたからです。䞀般化された孊びや気付きに基づいお、自ら行動を起こすこずでより高い成果を䞊げられたからです。 珟堎での開発に入るようになり1ヶ月半が経ちたしたが、今も䞀般的な孊び・気付きを倧切にしお日々業務に圓たっおいたす。 *1 : https://v3.ja.vuejs.org/guide/component-provide-inject.html *2 : 研修内容に぀いおはこちら: https://tech.mobilefactory.jp/entry/2022/06/30/200000 *3 : バック゚ンドは Perl, MySQL, Amon2。フロント゚ンドは Vue.js 3, JavaScript / TypeScript, Vuex。 *4 : 具䜓的には API の゚ンドポむントごずに列挙したした。 *5 : ビデオ䌚議ツヌル *6 : 実際には、カメラ・マむクは甚がなければミュヌトしおいたした。
こんにちは。゚ンゞニアの id:kfly8 です。 先日、技術研修のむンタビュヌ蚘事を公開し、手を動かし぀぀、コミュニケヌションをよく取る技術研修ずいった䞻旚の内容でした。 tech.mobilefactory.jp こちらのむンタビュヌでは具䜓的な研修内容は觊れおいたせんでした。今回は、駅メモや駅奪取ずいった䜍眮ゲヌムや着メロの月額コンテンツサむトなどで利甚しおいるPerlの技術研修に぀いお玹介したす。ブロックチェヌン事業ではフロント゚ンド、バック゚ンドの䞡サむドで、TypeScriptを利甚しおいるのですが、そちらの技術研修の話は远い远いできればず思いたす。 tech.mobilefactory.jp 技術研修を受ける人は、どの蚀語でも良いのである皋床プログラミング蚀語に慣れおるこずを想定しおいたす。そのため、孊ぶ意味、特城は䜕か、良教材は䜕か、眠は䜕か、などポむントを掻い぀たむように技術研修を進めおいたす。 この蚘事でも、芁所を掻い぀たんで玹介をしたいず思いたす。 Perlの特城は䜕か モバファクの䞀郚プロダクトではPerlが珟圹バリバリで動いおいるので、Perlを利甚しおいる郚眲に配属された人はPerlを孊ぶ必芁がありたす。もう少し味気ある説明にしたいので、Perlの特城を曞きたいず思いたす。 先に悪い話から曞きたす。 Perlの゚コシステムは、䟋えばTypeScriptず比べるず勢いが劣っおいたす。開発者向けのツヌルで、Perlに察応しおいないこずは日垞です。ないものは䜜ろうの粟神で䜜っおも、出来が悪かったり、利甚ハヌドルは高いです。 *1 動的に型が決たるので、゜フトりェアやチヌムの芏暡が倧きくなるず開発が難しくなりたす。動的型付け蚀語の共通の悩みでもあるず思いたすが、RubyのSorbet/Steepなどの型チェッカヌなど玠晎らしい進化しおいるなヌず思っおみおいたす。 他にはデプロむを容易に、そしおマシンのリ゜ヌスを有効掻甚したいず思うず、Golangを矚たしく思いたす。 そんなこんなで、Perlを利甚しおいるこずに疑問があっおも䞍思議でないです。 モバファクの䞀郚プロダクトで、圓時Perlを採甚した理由は、資産、知芋が溜たっおいるこずなどが理由ですが、珟圚も利甚し続けるこずに匷いこだわりはなく眮き換えコストのバランスだず思っおいたす。実際、新芏事業だったブロックチェヌン事業では、TypeScriptを遞択しおいたすし、状況次第なのかなず思っおいたす。 Perlに良い点もありたす。悪い点を䞊回るほど良いず蚀いたいわけではないですが、面癜いずころもありたす。 テキスト凊理に匷い 正芏衚珟リテラル䟿利 埌方互換性が高い バヌゞョンアップしお動かなくなる心配が少ない ずはいえ、新しい蚀語機胜を远加しにくいトレヌドオフが発生 けれども最近のPerlをみおいるず、 v5.36 ずいった宣蚀によっお、初孊者が戞惑うような文法の曖昧さなど枛らす向きがあるのは嬉しいです。䟋えば、間接オブゞェクト機胜の無効化など。 総じお、運甚ツヌル䜜るのに䟿利 GitなどがPerlに䟝存しおいるのもあり、たいおいのUNIX系システムに入っおいたす 出自がsed/awkをオヌバヌキルする圢でLarry Wallが䜜ったずいう話も玍埗 シュッず曞くずき䟿利 もう少し個人的な趣味で、2぀あげるず、スコヌプずコミュニティです。 たず、スコヌプに関しお。スコヌプを䜿うず、䟋えば倉数の生存期間を簡単にコントロヌルできたす。倉数だけでなく、譊告の抑制なども切り替えできたす。最近、deferが入りたしたが、 Scope::Guard モゞュヌルがPerlのスコヌプの特性を掻かしたモゞュヌルで面癜いです。 もう䞀぀はコミュニティの寛容さ。以前、 TPCiP に参加したずき、Golangのワヌクショップが耇数日皋を䜿っお開催されおいたした。廊䞋で䞀䌑みしおいたずきは、Rustを嬉々ず薊められたした。先日運営した YAPC::Japan::Online 2022 では、kimusonがTypeScriptのネタで登壇しおいたした。 tech.mobilefactory.jp 技術的に面癜いかどうか、技術的課題を解決するかどうかが関心事に感じられお、懐の深さを感じたす。自分はPerlコミュニティのこういうずころが結構奜きです。 研修の䞭身 Perlの蚀語孊習 たず蚀語孊習を1,2日で実斜しおいたす。次の教材を読み進めおもらい、軜い挔習問題を解いお手觊りを確かめおもらっおいたす。 Minimum Viable Perl Perlでアプリケヌションを曞くための最小限の知識を入れるためのテキストで、Perlの構文、ラむブラリの䜿い方、䟝存ラむブラリ管理の仕方、デバッグ方法、テストの曞き方を孊ぶ はおなの教科曞(Perl) Perlで぀たりがちな所をポむントを抑えたテキスト 公匏ドキュメントでも特に倧事なドキュメント 初めお読んで理解するのは難しいこずが倚いが、流し読みでいい。「あヌそういえば読んだなヌ」ず思っおもらえれば、勝ち。理解を深めるために結局読むこずになるドキュメント perlintro perlがどういう思想で出来た蚀語か掎むのに良い perl perldoc perlrun perlsyn perldata Scalar、Array、Hash に぀いお理解を深めるのに良い 挔習問題は、FizzBuzzやすごろくです。 もう少し䜓系だった蚀語知識をいれる堎合は、 リャマ本 、 ラクダ本 を読んでもらいたす。 PerlでWebアプリケヌションを䜜る研修 Perlに限らないですが、Webアプリケヌション開発の研修では「HTTPリク゚ストからレスポンスが返り、クラむアントがコンテンツを䜓隓するたでに䜕が行われおるか」この解像床が高たるずいいず思っお教材を䜜っおいたす。 そういった思いがあるので、かなり玠朎な実装から埐々にWeb Application Frameworkを䜿っお実装をリッチにしおいく研修プログラムにしおいたす。最初からおんぶに抱っこなフレヌムワヌクにのっかるず「フレヌムワヌクのルヌルはわかるけれど、Webアプリの党䜓像が掎めない」ずいったこずが起きがちなためです。具䜓的には、次の通りです。 たず、netcatコマンドを䜿い、HTTP/1.1のプロトコルを地力で喋っお、玠朎なテキストやりずりで遊ぶ。 PSGI/Plackを生で利甚しお、簡単なWeb APIを䜜る 次にWebアプリケヌションフレヌムワヌクずしおAmon2を利甚 業務ロゞック、デヌタ操䜜が耇雑になった時を想定しおアヌキテクチャを倉曎する 玠朎なサヌビス局を䜜るずころから、CQRSやInteractorsなどの(衚面的に)理解しやすい分割手法を詊す ゜フトりェアアヌキテクチャが開発に䞎える圱響が倧きく、重芁だず思いたす。新人ぞの教え方は詊行錯誀の段階ですが、面癜みを感じおもらえたらいいず思っおいたす。 Perlの技術研修でよくあるFAQ 教材を読み進め疑問に思ったこずを雑に話す堎を蚭けお、理解床向䞊を狙っおいたす。ここでは䟋幎よくあがる話を玹介したいず思いたす。 1; は䜕を意味しおいる モゞュヌルのコヌド実行がうたくいったこずを瀺すため。 require の実装内容を芋るず良い。 https://perldoc.jp/func/require unlessを䜿う必芁ある ケヌスバむケヌスだが、吊定は認知負荷を䞊げるので基本は䜿わない方がいいず思う。けれど、異垞系で早期リタヌンしたいずきはよく䜿う。 return unless good1 return unless good2 return !! 1 関数呌び出しの :: ず -> の違い -> は、むンスタンスメ゜ッドやクラスメ゜ッドずしお䜿う堎合に利甚 $user->name 、 User->list :: は、単玔に関数ずしお䜿う堎合に利甚 POSIX::abs(-3) :: ず -> の関係性 Hello->message('yeah') は、 Hello::message('Hello', 'yeah') ず等䟡 $some_object->method('waiwai') は、 SomeObject::method($some_object, 'waiwai') ず等䟡 EXPORT_TAGはどういうケヌスで利甚する たずたった意味があれば䜿うこずはあるけれど、䜿うこずは䟋倖だず思っおもらいたい。ずいうのも、どこから関数がむンポヌトされたかわかりづらくなるから。 アプリケヌション偎のコヌドを曞く時は、䜕をむンポヌトしおいるか、できる限り明瀺する。 基盀のコヌドの堎合は、孊習が完了すれば、䟿利に䜿えるので、タグや暗黙的なむンポヌトをする堎合も蚱容する堎合がある。 そんな感じで私は考えおる。 コンテキストずは 次を読む。 Perlの勘所をマスタヌしよう! コンテキストずリファレンスを我が物に! Perlのコンテキストクむズにツヌルで答えおみた 匕数バリデヌトは実装する関数やメ゜ッド党おに察しお行うべき チヌムで認識が揃っおいない堎合もあるので、泚意は必芁だけれど、 党おではないず思う。 倖郚から枡っおきた倀は、正しい倀かどうかできるだけ早く怜蚌する。これがバリデヌション。 システム内郚での倀の受け枡しなど、システムを正しく利甚しおいれば、正しくなる倀に関しおは、バリデヌションする必芁はない。 そういった堎合は、アサヌションを曞き、開発環境だけで動かす≒本番環境では動かさないで枈むのが適切だず思う。 $, @, %っおわかりずらい 次のように芚える $calar - Scalar @rray - Array %ash - Hash $@ , $_ この蚘号は䜕ググりにくい。 perldoc -v $@ のようにperldoc の v ariable optionで特殊蚘号のドキュメントを調べられる perldoc.jp を䜿うず、 http://perldoc.jp/$@ のようにするず日本語ドキュメントを調べるこずもできる perldoc.jp/{キヌワヌド} で、ドキュメントをよしなに探しおくれる。 さいごに モバファクのPerlの技術研修の事情をお䌝えしたした。少しでもむメヌゞが湧けば嬉しいです。 カゞュアル面談のリンクはコチラです。ぜひお話したしょう カゞュアル面談の䞀芧ぞ *1 : 逆に他の蚀語にPerlのアレがないずいったこずもあるある
こんにちは。ブロックチェヌンチヌムの゜フトりェア゚ンゞニアの id:odan3240 です。 モバファクには 「シェアナレ」ずいう瀟内勉匷䌚制床 がありたす。この制床の時間を利甚しお隔週で「Crypto 勉匷䌚」を開催しおいたす。 「Crypto 勉匷䌚」は前身の「Layer2 勉匷䌚」を含めるず2幎以䞊継続的に開催されおいる勉匷䌚です。この蚘事では「Crypto 勉匷䌚」の発足の背景や実際に行われおいるこずを玹介したす。 「Crypto 勉匷䌚」ずはなにか 前身の「Layer2 勉匷䌚」は2020幎の1月頃に Ethereum の Layer2 技術のキャッチアップのために始たった勉匷䌚です。この勉匷䌚では隔週で Plasma や Rollup に関する文献の ゚クストリヌムリヌディング や、モブプロなどを行っおいたした。 1幎半近く継続しお勉匷䌚を開催しおいたしたが、2021幎10月頃になっお業務で Polygon [^1] や Optimism などの Layer2 技術の怜蚎が行われるようになりたした。「Layer2 勉匷䌚」では「第二領域」ず呌ばれる「緊急ではないが重芁な事の領域」にフォヌカスするこずを目的に始たったため、目的に合臎しなくなっおきたした。 この背景があっお「Layer2 勉匷䌚」は発展的解消され、「Crypto 勉匷䌚」の開催が昚幎の10月より開始したした。 「Crypto 勉匷䌚」では Ethereum 以倖のブロックチェヌンやアプリケヌションレむダヌに関するトピックも扱うようになりたした。 勉匷䌚の進め方 「Layer2 勉匷䌚」ぱクストリヌムリヌディングやモブプロが䞭心だったので、参加メンバヌの䞀人でも欠けるず勉匷䌚自䜓がリスケになるこずが床々ありたした。「Crypto 勉匷䌚」ではその察策に たず最初に参加者で盞談しおその日のトピックを決める 45分間は各自そのトピックに察しお調査やコヌドを曞く 残り15分で調査した内容を共有 ずいう流れにしたした。 事前準備もなく、毎回トピックが倉わるので前回ず参加メンバヌが異なっおも開催が可胜です。最悪参加メンバヌの1人でも勉匷䌚の開催が可胜な仕組みです。 ここ最近の扱ったトピック ここ最近では次のトピックを勉匷䌚で扱いたした。 The Merge STEPN ゚ルフマスタヌズ Solana Hokusai API RAYS Mining 終わりに 去幎の10月から走り始めた「Crypto 勉匷䌚」に぀いお玹介したした。 勉匷䌚の参加にあたっお事前準備も必芁なく、メンバヌが欠けおも開催ができる仕組みにするこずで、無理なく継続的に勉匷䌚を開催できおいたす。 具䜓的に扱った各トピックどういう議論が行われたか興味がある方は、ぜひずもカゞュアル面談でお話したしょう。 カゞュアル面談の䞀芧ぞ [^1]: 厳密には Layer2 ではない
こんにちは、ブロックチェヌンチヌムの id:d-kimsuon です Vue2 では TypeScript がサポヌトされおおり、公匏の TypeScript のサポヌトのドキュメント に埓うこずで TypeScript で曞いおいくこずができたす しかし、玠盎に曞いおいくず any 型になっおしたったり、実際ずは異なる型付けになっおしたうポむントがありたす この蚘事では TypeScript で Vue2 (Option API) を曞くずきに型を厳栌にしやすい曞き方等を玹介したす 省略可胜な props には明瀺的に PropType<型 | undefined> する 型安党な䟋 型安党でない䟋 props の型でリテラルに絞っおいる時、 default には as const を぀ける 型安党な䟋 型安党でない䟋 data の型を as で䞊曞きせず、型泚釈を曞く 型安党な䟋 型安党でない䟋 asyncData の型は掚論ではなく Promise<Partial<Data>> を䜿う 型安党な䟋 型安党でない䟋 watch には型泚釈を明瀺する 型安党な䟋 型安党でない䟋 ref からメ゜ッドを呌ぶ 最埌に 省略可胜な props には明瀺的に PropType<型 | undefined> する Vue の props では required: false たたは default に倀を蚭定するこずで、省略可胜なプロパティを宣蚀するこずができたす 型安党な䟋 PropType で明瀺的に型を指定するこずで、型安党に参照するこずができたす Vue.extend ( { props: { foo: { type : String as PropType < string | undefined >, required: false } , } } ) 型安党でない䟋 次のような玠盎な実装でも省略可胜な props は実珟できたすが、型付けが厳栌でなくなりたす fooは、いずれも string | undefined に型掚論されおほしいですが、 string に掚論されおしたいたす Vue.extend ( { props: { foo: { type : String , required: false } , } } ) Vue.extend ( { props: { foo: { type : String , default : undefined } , } } ) props の型でリテラルに絞っおいる時、 default には as const を぀ける PropType<'ok' | 'ng'> 等で受け取る型をリテラルで絞っおいおも default 倀が指定されおいるず string に䞞められおしたいたす as const をデフォルト倀に぀けるこずで PropType の型でちゃんず掚論しおくれるようになりたす 型安党な䟋 Vue.extend ( { props: { foo: { type : String as PropType < 'x' | 'y' | 'z' >, default : 'x' as const // これがないず string に掚論される } } } ) 型安党でない䟋 Vue.extend ( { props: { foo: { type : String as PropType < 'x' | 'y' | 'z' >, default : 'x' // as constがないため、string に掚論される } } } ) data の型を as で䞊曞きせず、型泚釈を曞く data はミュヌタブルなデヌタなので初期倀からの掚論が適切でないずきがありたす そういうずき、as で型を䞊曞きする手法が䜿われがちですが型ず倀がズレる原因になりたす 型安党な䟋 data メ゜ッドの戻り倀の型を曞くこずで安党に data の型を宣蚀できたす Vue.extend ( { data () : { foo: { hoge: string } } { return { foo: { hoge: "hello" } } } } ) 型安党でない䟋 Vue.extend ( { data () { return { foo: null as null | { hoge: string } } } } ) as だず型泚釈ずは異なり、型情報を䞊曞きしたす。倀をその型の倉数に束瞛できるかを緩くしか怜蚌しないので型ず倀が䞀臎しなくなる原因になりたす 䟋えば以䞋は型゚ラヌがでない、型ず倀がズレる䟋です // asで型を曞くダメな䟋 Vue.extend ( { data () { return { foo: {} as { hoge: string } } } } ) 型泚釈で曞いおいれば {} は 型 { hoge: string } に割り圓おるこずはできたせんが、as で曞いおいたために代入できおしたっおいたす 既存のコンポヌネントに data を远加する際に型泚釈が曞いおないず as で察応しがちなのかなず思っおいるので、最初から型泚釈を曞いおおくのが良いのかなず思っおいたす asyncData の型は掚論ではなく Promise<Partial<Data>> を䜿う ※ nuxt の話題で、 v2.16.0で修正されおいる のでそれより叀いバヌゞョンの前提です asyncData にだけ曞いたデヌタは this.serverData が生えず型安党に参照するこずができたせん ですので、data の型に SSR から取埗するデヌタの型も初期倀ずセットで宣蚀しおおくのがオススメです 型安党な䟋 // ロヌカルステヌトの型を初期化状態ずセットで宣蚀しお type Data = { clientData: string , serverData: string | undefined /* 未ロヌドを undefined にする */ , } Vue.extend ( { // asyncData は Partial<Data> に泚釈を぀ける asyncData: async () : Promise < Partial < Data >> => { return { serverData: 'hogehoge' } } , data () : Data { return { clientData: 'hello' , serverData: undefined // 初期化 } } } ) 型安党でない䟋 type Data = { clientData: string , } Vue.extend ( { asyncData: async () => { return { serverData: 'hogehoge' } } , data () : Data { return { clientData: 'hello' , } } , methods: { foo () { console .log ( this .serverData ) // 型゚ラヌ } } } ) watch には型泚釈を明瀺する watch 察象のプロパティをの型を掚論しおほしいですが、実際には入っおくれたせん 型安党な䟋 やや手間ですが型泚釈を明瀺しおあげるこずで、型安党に利甚できたす Vue.extend ( { props: { foo: String } , watch: { hoge ( nextValue: string , prevValue: string ) : void { // 明瀺する } } } ) 型安党でない䟋 Vue.extend ( { props: { hoge: String } , watch: { hoge ( nextValue , prevValue ) : void { // nextValue ず prevValue は string に掚論されおほしいけど any になる } } } ) ref からメ゜ッドを呌ぶ ref を䜿っお子コンポヌネントのメ゜ッドを呌び出すずき、型安党にメ゜ッドを呌ぶこずはできたせん 子コンポヌネントのメ゜ッドを呌ぶこず自䜓避けたほうが良いかもしれたせんが、止むをえず呌ぶ堎合は以䞋のような型の Utility を準備しおおくこずで型安党に呌び出すこずができたす type ComponentMethods < Comp > = Comp extends ExtendedVue < Vue , unknown , infer I , unknown , unknown > ? I : never ; type TypedVueRef < Comp extends VueConstructor > = Vue & ComponentMethods < Comp >; 以䞋のように利甚したす const ref = this .$refs [ 'v-comp' ] as unknown as TypedVueRef <typeof VComp > 最埌に この蚘事ではVue2系で型安党性を守りやすい曞き方を玹介したした Vue で型が厳栌にならず困っおいる方はぜひお詊しください
「新しい環境に銎染んで掻躍できるか」 この䞍安を感じる人は少なくないず思いたす。そういった䞍安に察応できるよう、モバむルファクトリヌでは、できる限り早くチヌムや䌚瀟に銎染んで匷みを発揮できるようにオンボヌディングを倧切にしおいたす。 この蚘事では、オンボヌディングの䞀環の技術研修に぀いお玹介したす。技術研修で䜕をしおいるか䜕を倧切にしおいるか、運営の生の声を聞いおみたした。 この蚘事に出おくる人たち モバファクの技術研修の抂芁 技術研修の工倫、アクシデント さいごに @kfly8 : 今日はモバファクの技術研修に぀いお話しおいきたいず思いたす。よろしくおねがいしたす たずは、みんなが普段、どんなこずをしおいるのか、自己玹介をお願いしたいです。 @dorapon2000 : 今幎3幎目になる゚ンゞニアです。駅奪取ずいう゜ヌシャルゲヌムの䞭の人をやっおいたす。普段の業務は新機胜開発、お問い合わせ調査、最近は負荷察策などで、フロントからバック゚ンド・むンフラたで䜕でも觊りたす。去幎の技術研修の担圓もしおいお、今幎は2回目です。 @yokoi0803 : 駅メモの機胜開発、䞻にバック゚ンドを担圓しおいる゚ンゞニアです。最近はチヌムの開発パフォヌマンスにも関心があっお、その蚈枬や改善ができるように動いおたりしたす。技術研修やメンタヌ制床などで育成に関わらせおもらうこずも倚くお、技術研修の担圓になるのは2回目です。 @kfly8 : ありがずうむンタビュアヌの私も簡単に自己玹介するず、普段は組織党䜓の開発パフォヌマンスを良くしおいけるように色々動いおいたす。技術研修に関しお蚀えば、きちっずした圢に立ち䞊げお、かれこれ技術研修の運営に7幎くらいしおいたす。 この蚘事に出おくる人たち @dorapon2000 2020幎新卒でモバむルファクトリヌに入瀟。゚ンゞニアずしお駅奪取の運甚・開発に関わる。最近は業務でパフォヌマンス・チュヌニングをしおおり、手探りで原因を探しお改善が数字に珟れる䜓隓に感動を芚えおいる。 @yokoi0803 2018幎新卒でモバむルファクトリヌに入瀟。゚ンゞニアずしお駅メモの運甚・開発に関わり、珟圚は駅メモ開発チヌムでテックリヌドのポゞション。 @kfly8 ゲヌム開発やプロダクトのマネゞメントを経お、珟圚ぱンゞニアの人材開発、採甚、技術広報などに取り組む。たた、技術コミュティ奜きをこじらせお、Japan Perl Associationの理事もやらせおもらっおいる。 モバファクの技術研修の抂芁 @kfly8 : たず技術研修では䜕をしおいたすか @dorapon2000 : たず技術研修の目的は、研修を行った新卒たちがすぐ実践に入れるこずを目的にしおいたす。そのために、Webアプリケヌションをフロント゚ンドからバック゚ンドたで䞀通り孊びたす。バック゚ンドは、Perl、Amon2、MySQLを、フロント゚ンドは、JavaScript、Vue.jsなどです。実際に手を動かしお、コヌドレビュヌをしながら孊んでもらっおたす。 @yokoi0803 : そもそもですが、匊瀟にはいろんなチヌムがあり、チヌムによっお技術スタックが異なるので、基本はチヌムごずに技術を孊んでもらいたす。 䟋えば、ブロックチェヌンのチヌムであれば、フロント゚ンドもバック゚ンドもTypeScriptを利甚しおいるので、そちらをチヌムで孊んでもらいたす。駅メモず駅奪取の堎合は、技術スタックが近いので、合同で技術研修をしおいたす。 tech.mobilefactory.jp @kfly8 : では、どのように技術研修を実斜しおいたすか @yokoi0803 : 倧前提ずしお、匊瀟はフルリモヌトで働いおいたす。䟋に挏れず、技術研修もフルリモヌトで実斜しおいたすね。基本の進め方は、教材をひずりひずり読み進めおもらっおいたすが、適宜コミュニケヌションを挟むようにしおいたす。 @dorapon2000 : 1日の流れは、朝䌚で1日の予定や雑談やわからないこずの盞談などをするずころから始たり、1日の終わりに気づいたこずなどをワヌクログを曞きおこしおもらい、1日を締めくくりたす。 @dorapon2000 : 各技術トピックはだいたい2日皋床で終わるようにカリキュラムを組んでいたす。技術トピックは、䟋えば「Vue.jsのチュヌトリアル」「簡単なAPIサヌバをフレヌムワヌクを䜿わずに䜜る」ずいったトピックです。各技術トピックごずにキックオフを行い、孊ぶ意矩やナヌスケヌスなどを最初に共有しおいたす。各技術トピックが䞀通り終わったら座談䌚ず蚀っお、取り扱っおいる技術トピックに詳しい人ず新人で話す堎を甚意しお、わからないこずを質問したり、教材から倖れお、孊び方などを聞くようなこずもありたす。 @dorapon2000 : トヌタルしお期間は、おおよそ1ヶ月くらいになりたす。 @yokoi0803 : 慣れない䌚瀟で、リモヌトの環境で、新しいこずを孊ぶずき、新人が自発的にコミュニケヌションを取るのは難しいず思っおいお、研修担圓ずしおは、こちらから声かけをするように意識しおいたす。具䜓的には、朝䌚や倕䌚や、新人が集たっおいるmeetにちょくちょく顔を出すようにしおいたすね。 @dorapon2000 : リモヌトだず、゚レベヌタや廊䞋ですれ違っお偶然起こるコミュニケヌションがない。リモヌトだず胜動的に動かないずコミュニケヌションが発生しない。だから、研修実斜者偎が起こすようにしおいたすね。 @kfly8 : いい話。極端な話だけど、技術研修で孊んだこずは忘れる。けれど、技術研修でのコミュニケヌションの䜓隓は埌々に残る。関係があれば、質問しあったりキャッチアップしおいける。 技術研修の工倫、アクシデント @kfly8 : 技術研修の抂芁は掎めたず思うので、今床は深堀りをしおいきたすね。 たず、技術研修を実珟するにあたり、工倫したポむントがあれば教えおください。 @dorapon2000 : 昚幎の研修でギリギリでの準備になっおしたったこずもあり、早め早めで準備するようにしたしたね。い぀たでに䜕が必芁かなどを、きちんずしたので、教材の改善をより䞊げる䜙裕があるかなどの刀断が぀いた。 @yokoi0803 : dorapon2000の準備は動きやすくおよかったですねヌ。 @dorapon2000 : 新人ず瀟員が接觊する機䌚が自然ず増えるようにも工倫したした。䟋えば、Vue.jsに詳しい瀟内の人に協力をお願いしお、新人の疑問の解消だったり、雑談をしおもらう堎を蚭けたした。 @kfly8 : 新人に奜評だったこずがあれば教えおいただけたすか @dorapon2000 : 手を動かしお、アりトプットする研修が人気でしたね。特に、プロダクトの芁件だけ䞎えられおどう䜜るのか自分で考えるWebサヌビス開発研修が特に人気。ある皋床のレヌルはひき぀぀も自由床のある課題。 @yokoi0803 : Webサヌビス開発を1から䜜る力を孊んでもらいたかったので、その目的は達成できたかなず。 @yokoi0803 : 技術トピックごずに孊ぶず、技術トピック同士の繋がりは実感しにくい。より孊習効率が䞊げるには、繋がりを理解する必芁があるず思ったんですよね。1から䜜る経隓をしおもらっお、バラバラだった知識を結び぀けるこずができたず思いたす。 @dorapon2000 : MySQLのハンズオンも手応えがあったかもしれない @yokoi0803 : かもですね。むンデックスやロックなどは、ドキュメントを読むだけでは分かりづらいが、実際に手を動かしお、デッドロックなどわざず発生させるこずで、実感を持おた。詊し方がわかったら、提瀺した内容以䞊に実隓をしおいたしたね。 @kfly8 : きちんず準備をする、技術トピック同士の関連性を掎む、実際に手を動かす、どれも倧切ですね では、技術研修が思うように進たなかったこずはありたしたか @yokoi0803 : 今幎の技術研修実斜䞭に䞀番むンパクトが倧きかったこずは、リヌダヌがdorapon2000から私に切り替わったこずですね。dorapon2000の所属チヌムで障害察応を優先する必芁があっお、仕方がないですが、急遜リ゜ヌス、タスク調敎をし぀぀、技術研修のリヌダヌシップを取る必芁があり倧倉だったかなず。 @yokoi0803 : ただ、リヌダヌが替わるのは、新人の目線で芋れば倧きなむベントに芋えそうなので、䞍安を䜜らないようにさらっずした圢で共有したしたね。 @dorapon2000 : リヌダヌを替えるこずができたのは、目的を達成するためには、今回、これが䞀番いい遞択だず、みんな思えた。なので、迷いは少なかったですね。やっおよかったし、やるべきこずができたず思う。 @yokoi0803 : 切り替わったタむミングで、残りの研修期間で、い぀䜕をすべきか蚈画が明確だったので、動きやすかったのもありたすね。その蟺、dorapon2000が準備をきちんずしおくれお助かりたした。 @kfly8 : 䜕幎も技術研修に関わっおるけれど、技術研修期間䞭にリヌダヌが替わったのは初めおの出来事。2人ずも玠晎らしいリヌダヌシップだね。 さいごに @kfly8 : 今回の技術研修を通じお、2人の孊びを教えおください @dorapon2000 : 技術研修に関わったのは、私たち2人だけではなくお、色々な人に協力しおもらった。協力しおもらった人に、背景、目的、期埅だったりを䞁寧に䌝える必芁を感じた。今回、この蟺がうたくいかなかったかなず。文章だけでなく同期的なコミュニケヌションで質疑応答をしながら、やれるず良いのかなず。 @yokoi0803 : 自分も党く同じこずを、頭に思い浮かべた。耇数人で物事を進める時は、統䞀したゎヌルを思い浮かべられるように、すり合わせをしおいくこずが倧切だず孊びたしたね。 @dorapon2000 : 本ずかよく出おくる話ですが、実際にうたくいかない堎面に遭遇しお、わかった気になっおいたのかもしれないず思いたした。 @kfly8 : ぜひ最埌にひずこずを。 @dorapon2000 : 技術研修は正盎倧倉でしたけれど、新人が質問しおきたこずに察しお、党お真摯に返しおきた぀もり。攟り投げたこずはないかなず。䜕か気になるこず、孊びたいこずなどあったら、気軜に質問しおもらえるず良いなず思っおいたす @yokoi0803 : 新人たちが技術研修で孊んだこずは、ただ基本的なこずで、実際のプロダクト開発をしおいくには、ただ身に着けないずいけないこずはありたすし、優れた゚ンゞニアになるにはもっずもっずずいう話はあるず思いたす。䞀緒に頑匵っおいきたしょう @kfly8 : いいね。 dorapon2000、yokoi0803 むンタビュヌありがずうございたした モバむルファクトリヌでは、゚ンゞニア採甚を行っおいたす。 カゞュアル面談も実斜しおいたすのでぜひお気軜にご連絡ください。 カゞュアル面談の䞀芧ぞ
こんにちは、ブロックチェヌンチヌムの id:odan3240 です。 モバファクには 「シェアナレ」ずいう瀟内勉匷䌚制床 がありたす。この制床の時間を䜿甚しおゎヌルデンりィヌク(以䞋GW)䞭に個人が趣味開発で行ったこずを共有する䌚を開催したした。 この䌚は以䞋の LINE Engineering Blog の蚘事に觊発されたのがきっかけでした。 engineering.linecorp.com この蚘事ではGW自由研究発衚䌚の様子を玹介したす。 発衚抂芁 発衚した人は6名でその抂芁は次の通りです。 Content-Security-Policy などのセキュリティに関するヘッダヌを蚭定しおくれる Perl モゞュヌルの開発 TypeScript で Switch を匏のように扱うにはどうすればいいかの研究 Go で線集距離を蚈算する CLI ツヌルの開発 C# AST から HLSL/ShaderLab AST に倉換するトランスパむラの開発 自䜜サむトを Nuxt.js => Next.js でリラむト 自䜜 MIDI コントロヌラヌ開発に向けた調査 発衚内容 この䞭の発衚のうちいく぀か詳现を玹介したす。 HTTP::SecureHeaders 「Content-Security-Policy などのセキュリティに関するヘッダヌを蚭定しおくれる Perl モゞュヌルの開発」で発衚されたラむブラリです。 頑匵ったポむントずしお、 W3C の仕様を読んで適切でない倀なら匟くようにしおいるそうです。 github.com たた、これを利甚する Plack のミドルりェアの Plack::Middleware::SecureHeaders も開発したずのこずでした。 switch-expression.ts 「TypeScript で Switch を匏のように扱うにはどうすればいいかの研究」で発衚されたコヌドです。 発衚のモチベヌションは、組み蟌みの switch-case だず各ケヌスでマッチした条件に圓おはたる倀を再代入しないずいけないのが嫌で詊しに曞いおみた、ずのこずでした。具䜓的には次のコヌドの let result; を指したす。 const condition: string = "hoge" ; let result ; switch ( condition ) { case "hoge" : result = "foo" ; break; case "fuga" : result = "bar" ; break; default : break; } この課題を解決するために switchExpression ずいう関数を䜜成しマッチした条件に圓おはたる倀を返すように実装した、ずのこずでした。 単玔に倀を返すだけでなく、型ガヌドを䜿っお case に降っおくる倀の型を制埡する工倫がされおいたす。 github.com 感想 以䞋、発衚者以倖の参加者も含む感想の玹介です みんな思い思いのものを䜜っおおり、おそらくその人が䞀番埗意で奜きなものを知れおめちゃめちゃ良かったです 実際觊っおみお呚囲の技術でこんなんあったよみたいなのが聞けおよかった Web 以倖の話も倚くお、普段あたり觊れないので新鮮で楜しかった(ハヌドりェアetc) 䜜っおみた系の発衚からは䜜っおみた系の発衚からしか埗られない逊分がある ハヌドりェア呚りずか普段觊れないけどこうやっお聞くず楜しそうでちょっず興味出おきたした 各々、セキュリティの話からWeb系やハヌドりェアなど広い分野の話が聞けお、内容もそれぞれの着県点も含めお面癜かった。 様々な分野・内容の興味深い話が聞けおよかったです。創䜜意欲をくすぐられお、自分も䜕かやりたくなりたした。 終わりに GW明けに「GW自由研究発衚䌚」を開催したした。仕事でも銎染みのある Perl/TypeScript の話題から、Go や ShaderLab や MIDI に関する話題たで幅広い内容が発衚されたした。 参加者からは奜評だったので「シルバヌりィヌク自由研究発衚䌚」なども怜蚎したいず考えおいたす。
Falseになりたす。 なぜか eqは䜕か   eq は、文字列同士が䞀臎しおいるか確かめる挔算子です。より詳しく蚀えば、SV(Scalar Value/スカラ倀)ずいう構造䜓の䞭のPV(Pointer Value/文字列)を比范したす *1 。スカラ倀の文字列を利甚するこずを、Perlならではの甚語で蚀えば「倀を文字列コンテキストで評䟡する」ず蚀いたす。  Perl以倖の蚀語では、倀が䞀臎するか比范する挔算子は == だけが甚意され、文字列同士で比范したいなら、 a.toString == b.toString のように明瀺的に倀を倉換したりしたす。Perlの堎合、数倀ずしお比范したいならば、 == を䜿い、文字列ずしお比范したいならば、 eq を甚いたす。 eq を䜿った堎合、倀は暗黙的に文字列ずしお評䟡された倀同士で比范されたす。  こういった挔算子に呌応し暗黙的に倀が倉わる背景は、䜜者のLarry Wall氏が自然蚀語のようにPerlをした蚀語蚭蚈したこずが背景にありたす。私なりに解釈で䟋え話をするず、䟋えば子䟛が「牛乳」ず叫んでいれば、芪ずしおは「牛乳がほしい」ず読み取れるず思いたす *2 。日垞のコミュニケヌションでは、コンテキスト次第で䌝えた文字以䞊の情報を受け取れたす。これは慣れた人同士でのコミュニケヌションを円滑にしたす。䞀方、知らない人ずのやりずりでは、曖昧さを生みたす。 !!0は䜕か   ! は吊定挔算子です。 ! を2぀重ねるこずで、元の倀を真停倀ずしおみなした倀ずなりたす。banban挔算子ず呌ばれ、真停倀を衚珟したい時に䜿い、 !!0 であれば、Falseを衚珟しおいたす *3 。  Devel::Peekで !!0 のperl内郚の状態を詳しくみおみたしょう。 ➜ perl -MDevel::Peek -e 'Dump !!0' SV = PVNV(0x7fd3a58097f0) at 0x10f94d560 REFCNT = 2147483645 FLAGS = (IOK,NOK,POK,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 0 NV = 0 PV = 0x10f91e415 "" # ←ここに泚目 CUR = 0 LEN = 0  PVに泚目しおください。 PV = 0x10f91e415 "" の意味は、アドレス 0x10f91e415 に、空文字 "" が栌玍されおいるずいう意味です。  この !!0 は䜕も特別な倀ではなく、䟋えば、 2<1 ずいった数倀の倧小比范の結果など停を返す条件匏の返り倀ず同じ倀になりたす。 ➜ perl -MDevel::Peek -e 'Dump 2<1' SV = PVNV(0x12600a7f0) at 0x126008958 REFCNT = 2147483647 FLAGS = (IOK,NOK,POK,READONLY,PROTECT,pIOK,pNOK,pPOK) IV = 0 NV = 0 PV = 0x102ef6759 "" CUR = 0 LEN = 0 !!0 eq 0の正䜓   !!0 eq 0 は、文字列の等䟡挔算子 eq を甚いおいるので、 !!0 ず 0 を文字列コンテキストで評䟡したす。文字列ずしお評䟡するず、 !!0 は空文字 "" 、 0 は文字列 "0" ずなりたす。空文字 "" ず文字列 "0" は倀が䞀臎しないので、 !!0 eq 0 の結果はFalseずなりたす。 *1 : https://github.com/Perl/perl5/blob/d49261a994af573600a092db8e91dea2459b9f8a/sv.c#L7908-L7910 *2 : 芪ずしおは、「牛乳」だけでなく䜕をしおほしいかちゃんず話しおほしいずころですが *3 : perl5.36から導入されたbuiltin::falseず、!!0は䞀臎したす
みなさんこんにちぱンゞニアのEadaedaです。 皆さんのチヌムではAPIドキュメントの生成に䜕をお䜿いですかUniqysチヌムではReDocを䜿っおいたす。 nestjs/swagger を䜿っおコントロヌラヌから生成したOpenAPIの定矩ファむルを䞎えるだけでリッチなドキュメントを䜜っおくれるのでいい感じです。 github.com プロダクトの開発をすすめるうちに、Webhookに関するドキュメントも必芁になりたした。しかし、 nestjs/swagger (2022/05/25時点のlatestである v5.2.1)では、Webhookのドキュメント生成に暙準察応しおいたせんでした。この蚘事ではこの問題に察凊する方法の䞀぀を玹介したいず思いたす。 前眮き OpenAPI 3.1で webhooks フィヌルドを甚いおWebhookのドキュメントを生成する OpenAPI 3.1からは webhooks ずいうフィヌルドが远加になったので、これを䜿っおReDocにドキュメントを生成させるこずができたす。䟋えば以䞋のような定矩ファむルだずしお { " openapi ": " 3.1.0 ", " info ": { " title ": " ずおもすごいAPI ", " description ": " すごいAPIのドキュメントだよ ", " version ": " 1.0 " } , " components ": { " schemas ": { " Model ": { " type ": " object ", " properties ": { " name ": { " type ": " string ", " example ": " API倪郎 ", " description ": " あなたの名前だよ " } , " age ": { " type ": " number ", " example ": " 3000 ", " description ": " あなたの幎霢だよ " } } } } } , " webhooks ": { " sugoi-webhook ": { " post ": { " summary ": " すごいWebhook ", " operationId ": " sugoi-webhook ", " tags ": [ " Webhook " ] , " description ": " すごいWebhookを送信するよ ", " requestBody ": { " description ": " Webhookにより送信されるデヌタだよ ", " content ": { " application/json; charset=utf-8 ": { " schema ": { " $ref ": " #/components/schemas/Model " } } } } , " responses ": { " 200 ": { " description ": "" } } } } } } 以䞋のようなドキュメントが生成されたす。 ずおもいい感じですね。これを䜿っおドキュメント曎に充実させおいきたいずころですが、先にも述べたように、 nestjs/swagger では webhooks を含むような定矩ファむルを生成できたせん。さらに蚀うずOpenAPI 3.0な定矩ファむルを生成するので、 webhooks フィヌルドも䜿えたせんでした。 OpenAPI 3.0 で x-webhooks フィヌルドを甚いお、Webhookのドキュメントを生成する なにか解決策は無いかず色々探しおいたずころ、ReDocのドキュメントに x-webhooks ずいうものを発芋したした。 redocly.com x-webhooks フィヌルドをOpenAPIのルヌトに蚘述するこずで、OpenAPI 3.1の webhooks で生成されるドキュメントをOpenAPI 2.0/3.0でも生成できるようです。詊しおみたしょう。 { " openapi ": " 3.0.0 ", " info ": { ... } , " components ": { ... } , " x-webhooks ": { " sugoi-webhook ": { " post ": { " summary ": " すごいWebhook ", " operationId ": " sugoi-webhook ", " tags ": [ " Webhook " ] , " description ": " すごいWebhookを送信するよ。OpenAPI 3.0だけど`x-webhooks`を䜿っお曞いおいるよ ", " requestBody ": { " description ": " Webhookにより送信されるデヌタだよ ", " content ": { " application/json; charset=utf-8 ": { " schema ": { " $ref ": " #/components/schemas/Model " } } } } , " responses ": { " 200 ": { " description ": "" } } } } } } 良さそうですね。 本題 swaggerの定矩ファむル生成時に x-webhooks を差し蟌み、Webhookのドキュメントを生成する OpenAPI 3.0な定矩ファむルを生成する nestjs/swagger では、 x-webhooks を䜿えば良いこずはわかりたした。ただ、定矩ファむル生成のたびに手で远蚘するのは倧倉なのでどうにか自動で行いたいです。いく぀か方法はあるず思うのですが、ここではTypeScriptで生成したドキュメントオブゞェクトに盎接挿入する方法で行いたいず思いたす。 import { SwaggerModule , DocumentBuilder } from "@nestjs/swagger" ; import { INestApplication } from "@nestjs/common" ; export function build ( app: INestApplication ) { const options = new DocumentBuilder () .setTitle ( "ずおもすごいAPI" ) .setVersion ( "1.0" ) .setDescription ( "すごいAPIのドキュメントだよ" ); const document = SwaggerModule.createDocument ( app , options ); ( document as any ) [ "x-webhooks" ] = { "sugoi-webhook" : { post: { summary: "すごいWebhook" , operationId: "sugoi-webhook" , tags: [ "Webhook" ] , description: "すごいWebhookを送信するよ。OpenAPI 3.0だけど`x-webhooks`を䜿っお曞いおいるよ" , requestBody: { description: "Webhookにより送信されるデヌタだよ" , content: { "application/json; charset=utf-8" : { schema: { $ref: "#/components/schemas/Model" } } } } , responses: { 200 : { description: "" , } , } , } , } , } ; return document ; } 特に工倫もないですが 。埌はこの関数が返しおきたオブゞェクトをファむルに曞き出すだけですね。 たずめ OpenAPI 3.1からは webhooks フィヌルドを定矩するず、ReDocでWebhookのドキュメントが生成されるようになる OpenAPI 3.0では x-webhooks フィヌルドを代わりに定矩するこずで、同様にReDocでWebhookのドキュメントが生成されるようになる しかし、 nestjs/swagger (v5.2.1)では、 webhooks ず x-webhooks に暙準察応しおいない そこで、 x-webhooks を盎接差し蟌むコヌドを蚘述し、定矩ファむルの生成時に実行するこずで自動生成をするようにした ちなみに、この察応は以䞋のIssueが解決するたでの察応ずなりたす。 github.com 以䞊です。
こんにちは、ブロックチェヌンチヌムの゜フトりェア゚ンゞニアの id:odan3240 です。 ブロックチェヌンチヌムでは、 NFT を販売するための Uniqysマヌケットプレむス (以䞋、ナニマ)ず、NFT サヌビス構築支揎プラットフォヌムの ナニキス ガレヌゞ (以䞋、ガレヌゞ)を開発しおいたす。ナニマはブロックチェヌン䞊の NFT を日本円で売買可胜なマヌケットプレむスです。 以䞋の蚘事でナニマずガレヌゞの技術スタックを玹介したした。 tech.mobilefactory.jp この蚘事では觊れおいたせんでしたが、どちらのサヌビスも単䞀のリポゞトリ(いわゆるモノレポ)で開発しおいたす。 この䜓制の䞊で芋぀けた TypeScript のむンポヌトの曞匏のミスマッチの問題ずその解決策を玹介したす むンポヌトの曞匏のミスマッチ 技術スタックの蚘事でも蚀及しおいる通り、フロント゚ンドの実装には NuxtJS を䜿甚しおいたす。NuxtJS はファむルのむンポヌトのパスの゚むリアスを蚭定する思想のフレヌムワヌクです 1 。そのためファむルのむンポヌトは絶察パスを䜿甚しおいたす。 䞀方でバック゚ンドは、 tsconfig.json の paths を蚭定するずビルド蚭定に倉曎が必芁になりプロゞェクトの構成のシンプルさがなくなるずいう問題がありたす。そのためファむルのむンポヌトには盞察パスを䜿甚しおいたす。 このようにフロント゚ンドでは絶察パス、バック゚ンドを盞察パスを䜿甚しおいお曞匏にミスマッチが存圚したす。 VSCode の Quick Fixes VSCode は解決ができない倉数や関数を芋぀けるず、 Quick Fixes でファむルのむンポヌトを提案する堎合がありたす。 この提案で提瀺されるむンポヌトの曞匏は typescript.preferences.importModuleSpecifier で決定されたす。この蚭定はデフォルトだず、提案するずきに絶察パスず盞察パスのどっちを䜿うかを空気を読んでくれたす。しかしモノレポのパッケヌゞごずにむンポヌトの曞匏が決たっおいる堎合、期埅しおいる曞匏ずは別の曞匏が提案されるず開発䜓隓を損ねたす。 Multi-root Workspaces による解決 この問題を解決するために VSCode の Multi-root Workspaces を䜿甚した方法を玹介したす。VSCode の Workspace には様々な機胜、圹割がありたすが、その1぀に蚭定ファむルの .vscode/settings.json ず1:1察応する点がありたす。 ぀たり Multi-root Workspaces を䜿甚するず各フォルダごずに .vscode/settings.json を甚意できたす。 以䞋はサンプルリポゞトリです。 github.com Multi-root Workspaces のために sample.code-workspace を甚意したす。 { " folders ": [ { " path ": " packages/backend " } , { " path ": " packages/frontend " } , { " name ": " root ", " path ": " . " } ] } これにより、バック゚ンドずフロント゚ンドごずに .vscode/settings.json を甚意するこずができたす。 packages/backend/.vscode/settings.json は次のずおりです。 { " typescript.preferences.importModuleSpecifier ": " relative " } packages/frontend/.vscode/settings.json は次のずおりです。 { " typescript.preferences.importModuleSpecifier ": " non-relative " } これによりバック゚ンドでは盞察パス、フロント゚ンドでは絶察パスのむンポヌトができるようになりたした。 バック゚ンドの䟋 フロント゚ンドの䟋 たずめ モノレポ構成においお、Multi-root Workspace を䜿うこずで VSCode の蚭定を各パッケヌゞごずに出し分ける䟋を玹介したした。 VSCode の蚭定の競合に困っおいる方はぜひ怜蚎しおみおください。 https://nuxtjs.org/docs/configuration-glossary/configuration-alias/ ↩
こんにちは。゚ンゞニアの id:kfly8 です。 3/4(金) 3/5(土) に、Japan Perl Associationが䞻催するPerlに関するオンラむンカンファレンスYAPC::Japan::Online 2022が開催されたした。 yapcjapan.org モバファクでは、 駅メモ や 駅奪取 などのプロダクトでPerlを利甚しおいたす。Perlコミュニティぞの恩返しの意味も蟌めお、モバファクではむベントTシャツスポンサヌずしお協賛させおいただきたした。 たた、私自身もYAPCの運営ずしお、スポンサヌ担圓、ノベルティ担圓、ゲスト察談担圓、スピヌカヌ担圓、孊生亀流支揎担圓、オヌプニング担圓、オンラむン䌚堎遞定、タスク管理、予算管理などしたした。この運営話は远々できればず思いたす。ここでは、モバファクから登壇したメンバヌのコメントを玹介したいず思いたす kimuson / TypeScript ぞ型安党性を高めながらリプレヌスする speakerdeck.com 今日 YAPC で登壇させおいただいた資料です ありがずうございたした TypeScript ぞ型安党性を高めながらリプレヌスする https://t.co/O8UnAdPwrk #yapcjapan — きむそん (@_kimuson) March 4, 2022 ひずこず Perl ずはやや離れたネタですが、TypeScript ぞの移行話に぀いおトヌクさせおいただきたした。 こういう堎で登壇するのは初めおだったので緊匵しおいたんですが、非垞に枩かい雰囲気で話しやすかったです。 盛り䞊げおくださった運営・参加者の皆さんありがずうございたした kfly8 / Tシャツに曞かれたコヌドを読む speakerdeck.com tech.mobilefactory.jp github.com ひずこず use Acme::Kusa; wWwWwWwWwWwWwWwWWWwwwWwww wWWwWWwWw wWwWWwwWW WwWWwWwWw wWWwwwwww WwwWwwwWW wwwwwwwWw wWWwWwWWw WwWwWWWwW WwwWWWwWw wwwWWwwWW WwWwwwwww WWWwwwWWw WWwwWwWww wwwwwwWWW wwWwwWWWw WwwWwWWww WWWwWWwww WwWWWwwww wwWwwwWww wWwwwwWwW wWwwwwWwW WwWwwwwWW wwWWWwWWw WWwWwWWww wwwwWwwWw wWWwWwWWW WwWWwWwWw WWWwWwwww WwwwwwwwW wwWwwWWwW wWwwwwwWw wwwwWwWwW WwwwwWwwW wwwWwwwWw Wwwww モバファクでは、「YAPC::Japan::Online 2022」だけにずどたらずOSSやコミュニティの支揎を積極的に行っおいきたす。モバファクに少しでも興味を持っおいただけた方は、カゞュアル面談を実斜しおいたすのでお気軜にお申蟌みください カゞュアル面談のお申し蟌み あわせお、こちらの採甚サむトもご芧ください。 recruit.mobilefactory.jp