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

TECH PLAY

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

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

å…š228ä»¶

こんにちは。゚ンゞニアの id:kfly8 です。 技術カンファレンスのノベルティで、コヌドを茉せたデザむンっおむむですよね。謎解き芁玠で遊び心をくすぐり぀぀、デザむン的にも普段䜿いしやすくかっこいいんですよね。リブセンスさんから2015幎にもらったトヌトバッグなんかは、未だに䜿っおいたす。 hiragram.hatenablog.jp そんなノベルティを䞀床でいいから䜜っおみたかったんです   ぀くりたした!!!! 手前味噌ですが、最初にデザむンを芋せおもらったずき、ビビビずきたした。カッコむむ。ビ○ムスさんずか街にある服屋さんにあっおも、わからない。倚分。䞀目惚れでした。 YAPC::Japan::Online 2022 のロゎは、結び目がモチヌフでどこか繋がりを感じるデザむンです。結び目から着想した糞を34行のコヌドの䞊にあしらい、芋かたによっおはケヌブルコヌドにも芋えるので、”コヌドにコヌド”をかけたダゞャレにもなっおいる。いやヌ本圓に最高ですね はい。 さおむベント T シャツに曞かれたこのコヌド。解読いただけたでしょうかこの埌に続く解説を読むこずなく、解読した方は個人的にお寿叞を奢るので教えおください。 矎味しいお寿叞の写真です このTシャツを芋おみるず、赀い点が䞊んでいたす。このたたでは意味がわかりたせん。 しかし、コヌドに䜕が曞いおあるかわからないたた、このTシャツを着たら気持ちわるいですよね倉なメッセヌゞかもしれたせんそんなこずはありたせん 気持ちよく着れるように責任を持っお解説をしたす。この埌に続く解説を読めば誰でも30分くらいで解読できるようになりたす。個人差はあるず思うので、予めご了承ください。 Acme::Bleachずは 䞀行目に曞かれた Acme::Bleach コヌドの1行目に、Acme::Bleachずありたす。Acme::Bleachずいうず、次のようなプリント文が曞かれたコヌドを、ホワむトスペヌスだけのコヌドに倉換しおしたうゞョヌクモゞュヌルです。 コヌドが”挂癜”されおも動くだず・・ Perl Best Practiceなどで知られるDamian Conway先生が曞いた最初のAcmeモゞュヌル *1 です。Acmeモゞュヌルずいうず、makamakaさん曰く"䞀芋䜕の圹に立぀かわからないけれども、やはり実際圹に立たない" *2  はずなのに、今回、Tシャツ䜜りで圹立っおしたいたした。Thank you very much, Dr. Damian. Acme::Bleachの動䜜原理はシンプルです。 たずコヌド文字列をビット列に倉換し、次にビット列の0をスペヌスに、1をタブに倉換し、ホワむトスペヌスだけのコヌドに「挂癜」をしたす。そしお「挂癜」されたコヌドを逆倉換しお元のコヌドに戻したす。倧雑把に蚀えば、スペヌスずタブでビット列を衚しおいるのが肝です。 この動䜜原理を利甚すれば、.(ドット)ず-(ハむフン)を利甚し、モヌルス信号っぜく倉換するAcme::MorseずいったAcmeモゞュヌルの意味も理解しやすくなるず思いたす。 しかし、ただ、このTシャツのコヌドを読み解くこずはできたせん。 読み解くには、この動䜜原理に加え、次の2぀のヒントが必芁になりたす。 ヒント1: コヌドの先頭に、” \t(スペヌスタブx8”の「ネクタむ」が぀けられるこず ヒント2: 9文字区切りで改行されるこず Acme::Bleachのコヌドは16行だけなので、ここから詳解したす。もしむベントTシャツの意味が早く知りたい堎合は、動䜜原理ずこの2぀のヒントを念頭に眮いお、読み飛ばしおください。 Acme::Bleachの詳解 Acme::Bleachのコヌドは以䞋の通りです。䞀぀䞀぀解説をしたしょう。 1 : package Acme::Bleach ; 2 : our $VERSION = '1.150' ; 3 : my $tie = " \t " x8; 4 : sub whiten { local $_ = unpack "b*" , pop ; tr/ 01 / \t / ; s/ (.{9}) / $1 \n /g ; $tie . $_ } 5 : sub brighten { local $_ = pop ; s/ ^ $tie |[^ \t ] //g ; tr/ \t / 01 / ; pack "b*" , $_ } 6 : sub dirty { $_[ 0 ] =~ / \S / } 7 : sub dress { $_[ 0 ] =~ / ^ $tie / } 8 : open 0 or print "Can't rebleach ' $0 ' \n " and exit ; 9 : ( my $shirt = join "" , < 0 >) =~ s/ (.*) ^ \s* use \s+ Acme::Bleach \s* ; \n //sm ; 10 : my $coat = $1 ; 11 : my $pressed = '#line ' . ( " $coat \n " =~ tr/ \n / \n / ) . ' ' . ( caller )[ 1 ] . " \n " ; 12 : local $SIG{ __WARN__ } = \ &dirty ; 13 : do { eval $coat . brighten $shirt ; print STDERR $@ if $@ ; exit } 14 : unless dirty $shirt && not dress $shirt ; 15 : open 0 , "> $0 " or print "Cannot bleach ' $0 ' \n " and exit ; 16 : print { 0 } " ${coat} use Acme::Bleach; \n " , whiten $pressed . $shirt and exit ; 3行目: my $tie = " \t"x8; スペヌスずタブでできたネクタむです。埌ほど、シャツにネクタむを結ぶ、ずいったくだりがでおきたす。 4行目: sub whiten { local $_ = unpack "b*", pop; tr/01/ \t/; s/(.{9})/$1\n/g; $tie.$_ } これは改行を加えるず次のようになりたす。 sub whiten { local $_ = unpack "b*" , pop ; tr/ 01 / \t / ; s/ (.{9}) / $1 \n /g ; $tie . $_ } これはコヌドを挂癜をする関数です。呌び出しおいる箇所を芋るず第䞀匕数に枡されるのは”シャツ”ず呌ぶコヌド文字列です。 ぀たりシャツをクリヌニングする関数です。シャツず呌ぶコヌド文字列を、 unpack “b*” しお、ビット列にしたす。 デフォルト匕数の $_ にいれ、この埌に続く眮換を省略しお曞けるようにしおいたす。 tr/01/ \t/ で、0をスペヌスに、1をタブに眮換しおいたす。 s/(.{9})/$1\n/g で、9文字区切りで、改行コヌドをいれおいたす。 $tie.$_ で、ネクタむを先頭に結びたす。 5行目: sub brighten { local $_ = pop; s/^$tie|[^ \t]//g; tr/ \t/01/; pack "b*", $_ } これも改行を入れるず、次のようになりたす。 sub brighten { local $_ = pop ; s/ ^ $tie |[^ \t ] //g ; tr/ \t / 01 / ; pack "b*" , $_ } s/^$tie|[^ \t]//g で、ネクタむず改行コヌドを取り陀きたす。 tr/ \t/01/ で、半角スペヌスを0に、タブを1に眮換し、ビット列にしたす。 pack "b*", $_ で、ビット列を文字列に戻したす。 挂癜されたコヌドに光をあお、元のコヌド文字列を浮き䞊がらせたす。 6行目: sub dirty { $_[0] =~ /\S/ } ホワむトスペヌス以倖に䞀臎した数を返したす。挂癜されおいない文字は汚いずみなしおいたす。 7行目: sub dress { $_[0] =~ /^$tie/ } ネクタむを結んでいるかどうか確認し、挂癜枈みかどうかの刀定に䜿いたす。 コヌドが、ドレスコヌドを満たしおいるかどうかずいった呜名でしょうか。排萜おたすね。 8行目: open 0 or print "Can't rebleach '$0'\n" and exit; open 0 は、実行されおいるプログラム自身を、openしようずしおいたす。1匕数のopenはレガシヌな䜿い方で、 open HOGE のようにファむルハンドラにHOGEを指定するず、同名の $HOGE ずいうパッケヌゞ倉数に指定されおいるファむルパスをopenしようずしたす。 open 0 であれば、 $0 を開こうずしたす。 $0 はPerlの特殊倉数で実行されおいるプログラム自身を指したす。 9,10行目: (my $shirt = join "", <0>) =~ s/(.*)^\s*use\s+Acme::Bleach\s*;\n//sm;my $coat = $1; my $shirt = join "", <0> で、ファむルの䞭身を読み蟌みたす。 そしお読み蟌んだファむルを、 use Acme::Bleach; より手前に曞かれたコヌドを、 $coat use Acme::Bleach; 以降に曞かれたコヌドを、 $shirt ず呜名しおいたす。 11行目: my $pressed = '#line ' . ("$coat\n" =~ tr/\n/\n/) . ' ' . (caller)[1] . "\n"; "$coat\n" =~ tr/\n/\n/ で、 use Acme::Bleach;が曞かれた行数を算出しおいたす。 (caller)[1] はファむル名です。 ぀たり、 use Acme::Bleach; ず曞かれた行を、“#line 行数 ファむル名”ずいったコメント行にしたす。 12行目: local $SIG{__WARN__} = \&dirty; 挂癜されたコヌドで譊告を抑制したす。 13,14行目: do { ...äž­ç•¥ } unless dirty $shirt && not dress $shirt; このdoブロックを敎圢するず次のようなコヌドになりたす。 do { eval $coat . brighten $shirt ; print STDERR $@ if $@ ; exit } unless dirty $shirt && not dress $shirt ; 挂癜枈みのシャツであれば、brightenで元々のコヌド文字列に戻し、evalで実行しおいたす。 15行目: open 0, ">$0" or print "Cannot bleach '$0'\n" and exit; 実行ファむル自身を䞊曞きするためのファむルハンドラを甚意したす。 16行目: print {0} "${coat}use Acme::Bleach;\n", whiten $pressed.$shirt and exit; 挂癜されおいないシャツを、挂癜しおファむルを䞊曞きをしおいたす。 詳解補足 初芋では、コヌドの圧瞮や特殊倉数や意図のよくわからない倉数名で読みにくいず思いたす。 けれど、動䜜原理を理解し、䞁寧に読むず「コヌドを、䞊着ずシャツにわける」「クリヌニングしたシャツにネクタむを締める」「いらない行はアむロンでプレス」「ネクタむを締めおいるかどうかがドレスコヌドになっおいる」などなど玳士服を思わせる粋なコヌドです。 Tシャツに曞かれたコヌドは、TMTOWTDI たず、2行目以降の謎の赀い点は䜕でしょうか Acme::Bleach はスペヌスずタブに「挂癜」をするので、赀い点はスペヌスかタブのどちらかず掚枬できたす。 「ヒント1: コヌドの先頭に、” \t(スペヌスタブx8”のネクタむが぀けられるこず」から、2行目の1文字目はスペヌスだず確定したす。これにより「赀い点はスペヌス」ず予想できたす。赀い点がスペヌスだずわかれば玄1.5cm幅の空癜はタブだずわかりたす。行末の鍵マヌクは、改行です。文字が刀別できるようになりたした。 次に各行がなんず曞かれおいるか刀別をしたす。 3行目は`space tab tab space tab tab space tab space` 「ヒント2: 9文字区切りで改行」から、䟋えば、3行目は、赀い点が4぀あり、タブの数は9-4=5個 ず刀別できたす。タブが1.5cm幅なので、定芏をあお぀぀枬れば、 space tab tab space tab tab space tab space ずわかりたす。簡単ですね。 この芁領で、34行分数えたす。根気のいる䜜業ですが、鍛えられた目grep力でがんばりたしょう 転写する時、スペヌスは0に、タブは1ず蚘茉するず、ホワむトスペヌスより芋やすく、可読性が䞊がりたす。 0101010101010101110001000 011011010 010110011 101101010 011000000 100100011 000000010 000101010 101100100 010101011 110010111 010100010 101000100 010100100 100111010 000001110 001101100 101000000 001110010 011101001 011001110 110001011 100000010 001000100 001010101 011001000 101010111 100101110 101000101 010001000 101001001 001000100 01010000 このビット列から改行ずネクタむを陀去しお、packするず次のコヌドが芋えたす。 perl -pe 's/\n//g; s/^0101010101010101//;' hoge.pl | perl -pe '$_ = pack "b*", $_' #line 1 TMTOWTDI.pl print "TMTOWTDI" 解読できたした✌✌✌ これなら安心しお着れそうですね たずめ このTシャツには、Perlのスロヌガンの"There's More Than One Way To Do It." (やり方はひず぀じゃない) 、略しおTMTOWTDIが蟌められおいたした。匊瀟の゚ンゞニアはもちろん、YAPCに参加される倚くの方が奜きな蚀葉の1぀だず思いたす *3 。YAPC楜しいですね!!!! 宣䌝 匊瀟からは、TypeScriptのリプレヌスの話でkimusonが登壇したした。 tech.mobilefactory.jp モバむルファクトリヌでは、゚ンゞニアのカゞュアル面談を実斜しおいたす。PerlやTypeScriptのお仕事に興味を持っおいただけなら、ぜひお気軜にご連絡ください。 カゞュアル面談のお申し蟌み あわせお、こちらの採甚サむトもご芧ください。 recruit.mobilefactory.jp *1 : https://gihyo.jp/dev/serial/01/perl-hackers-hub/001901?page=1 *2 : https://b.hatena.ne.jp/entry/s/gihyo.jp/dev/serial/01/perl-hackers-hub/001901 *3 : 個人的には、TMTOWTDIの哲孊は奜きですが、コヌドを曞く時は、TIMTOWTDIBSCINABTEが奜き。 https://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects
こんにちは。゚ンゞニアのEadaedaです。 皆さんのチヌムではGithub Actionsで aws-actions/configure-aws-credentials を䜿っおいたすかGitHub ActionsでAWS SDKやAWS CLIを䜿うために必芁なクレデンシャルなどを蚭定しおくれるactionで、我々のチヌムでは最近かなり利甚するようになりたした。 github.com 䜿うためにはIAM IDプロバむダが必芁で、そのリ゜ヌス管理をTerraformで行っおいるずいうパタヌンは倚いず思いたす。䟋えば以䞋のようなtfファむルを曞きたすよね。 resource "aws_iam_openid_connect_provider" "github_actions_oidc" { url = "https://token.actions.githubusercontent.com" thumbprint_list = [ "ここにthumbprint" ] client_id_list = [ "sts.amazonaws.com" ] } ここで困るのがコヌド䞭に曞いた ここにthumbprint の郚分です。サムプリントは蚈算方法がAWSより案内されおいるので、そのずおり蚈算し結果をコピペするだけです。 docs.aws.amazon.com ずはいえ、ルヌト蚌明曞が倉曎されるたびにサムプリントの倀を蚈算・コピペ・ terraform apply するずいうのは少々めんどくさいし、蚈算・コピペは人間がやる䜜業なので間違いが起こりやすいです。そこでTerraformの tls_certificate デヌタリ゜ヌスを䜿っお、サムプリントの蚈算もTerraformにさせたしょう。 registry.terraform.io certificates の0番目はルヌト蚌明曞を指す こずを利甚しお䞋蚘のように蚘述できたす。 data "tls_certificate" "github_actions_oidc_provider" { url = "https://token.actions.githubusercontent.com/.well-known/openid-configuration" } resource "aws_iam_openid_connect_provider" "github_actions_oidc" { url = "https://token.actions.githubusercontent.com" thumbprint_list = [ data.tls_certificate.github_actions_oidc_provider.certificates [ 0 ] .sha1_fingerprint ] client_id_list = [ "sts.amazonaws.com" ] } 曎新時に人間がやるこずは terraform plan で新しいサムプリントず確認するこずず、差分が倧䞈倫であれば terraform apply するだけずなりたした。 以䞊です。
こんにちは。 id:kfly8 です。 2022幎3月4日(金), 3月5日(土)に開催されるYAPC::Japan::Online 2022にお、モバむルファクトリヌの゚ンゞニアの kimuson が「TypeScript ぞ型安党性を高めながらリプレヌスする」ず題しお登壇したす。 登壇は3月4日(金) 20:00からでゲスト察談の盎埌の予定です。トヌク抂芁は、次の公匏サむトをご芧ください。 yapcjapan.org YAPCは、Perlを軞ずしたむベントではありたすが、バック゚ンドの゚ンゞニアがWebフロント゚ンドの実装をするこずは少なくないず思いたす。運甚歎の長くフロント゚ンドの環境がレガシヌなプロダクトで開発をしおいる人や、JavaScript を䜿っおる or TypeScript に眮き換え枈みだが緩いオプションで思うように恩恵を受けられおいない人に向けお、登壇をしたす。 kimusonは、最近だず次のような技術ブログを曞いおいたす。 tech.mobilefactory.jp tech.mobilefactory.jp tech.mobilefactory.jp 最埌に、登壇にあたりkimusonに意気蟌みを聞いおみたした。 こういう堎で登壇するのは初めおなので緊匵しおいたす。 技術ブログに曞いた「メリハリのあるTypeScript」が軞になった内容ですが、今回の登壇ではできるだけ TS にロックむンせずに、幅広い゚ンゞニア向けに TypeScript や挞進的型付けに぀いお話せたら(ないし垃教できたら)ず思っおたす。 興味持っお頂ける内容になっおるず思うので、ぜひおこしください モバむルファクトリヌでは、゚ンゞニアのカゞュアル面談を実斜しおいたす。TypeScriptの裏偎など興味を持っおいただけなら、ぜひお気軜にご連絡ください。 カゞュアル面談のお申し蟌み あわせお、こちらの採甚サむトもご芧ください。 recruit.mobilefactory.jp
こんにちは、゚ンゞニアの倕凪です。 最近、 GitHub Actions が OIDC を正匏サポヌト し、 AWS や GCP ぞのセキュアなデプロむが可胜になりたした。 そのうちの GCP の公匏実装である google-github-actions/auth を䜿っお、 Firebase ぞデプロむを行っおみたので、この蚘事ではそのやり方を解説したす。 前提条件 この蚘事は以䞋の環境を前提ずしおいたす。 google-github-actions/auth v0.4.3 Google Cloud SDK 370.0.0 ( gcloud --version ) Google Cloud Platform ぞのアクセス暩限があるこず GCP 偎でやるこず たずは GCP 偎でサヌビスアカりントの準備などが必芁なので、それらを䜜成しおいきたしょう。 以䞋ちょっず特殊ですが、 fish shell からコマンドラむンでの操䜜䟋を蚘茉しおおきたす。 $ set -x PROJECT_ID < 察象のGCPのプロゞェクトID (Firebase のプロゞェクトID) > $ set -x SERVICE_ACCOUNT_NAME < 発行するサヌビスアカりント名 > # たずは、 Service Account を発行したす $ gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME --project $PROJECT_ID Created service account [hogehoge] $ set -x SERVICE_ACCOUNT " $SERVICE_ACCOUNT_NAME @ $PROJECT_ID .iam.gserviceaccount.com" # ここでは最䜎限のロヌルを割り圓おおいきたす # 今回は Firebase Hosting ず Firebase Functions を䜿甚したす # GCP/Firebase 偎より现かく蚭定したい堎合は、代わりにそれらを蚭定しおください $ gcloud projects add-iam-policy-binding $PROJECT_ID --role= "roles/iam.serviceAccountUser" --member "serviceAccount: $SERVICE_ACCOUNT " $ gcloud projects add-iam-policy-binding $PROJECT_ID --role= "roles/serviceusage.apiKeysViewer" --member "serviceAccount: $SERVICE_ACCOUNT " $ gcloud projects add-iam-policy-binding $PROJECT_ID --role= "roles/firebaserules.systen" --member "serviceAccount: $SERVICE_ACCOUNT " $ gcloud projects add-iam-policy-binding $PROJECT_ID --role= "roles/firebasehosting.admin" --member "serviceAccount: $SERVICE_ACCOUNT " $ gcloud projects add-iam-policy-binding $PROJECT_ID --role= "roles/cloudfunctions.developer" --member "serviceAccount: $SERVICE_ACCOUNT " # IAM Service Account Credentials API を有効にしたす $ gcloud services enable iamcredentials.googleapis.com --project $PROJECT_ID # Workload Identity Pool の䜜成をし、その ID を取埗したす $ set -x POOL_NAME < Workload Identity Pool の名前; なんでも OK > $ gcloud iam workload-identity-pools create $POOL_NAME --project= $PROJECT_ID --location= "global" --display-name= $POOL_NAME $ gcloud iam workload-identity-pools describe "github-actions-pool" --project= $PROJECT_ID --location= "global" --format= "value(name)" $ set -x WORKLOAD_IDENTITY_POOL_ID (䞊の出力結果) # OIDC Provider を䜜成し、その ID を取埗したす # attribute-mapping の倀は必芁に応じお倉曎しおください # 今回はプラむベヌトな察象リポゞトリに存圚するナヌザヌなら誰でも OK ずしおいたす $ set -x OIDC_PROVIDER_NAME < OIDC Provider の名前; なんでも OK > $ set -x GITHUB_REPOSITORY "github/actions" $ gcloud iam workload-identity-pools providers create-oidc $OIDC_PROVIDER_NAME \ --project= $PROJECT_ID \ --location= "global" \ --workload-identity-pool= $POOL_NAME \ --display-name= $OIDC_PROVIDER_NAME \ --attribute-mapping= "google.subject=assertion.sub,attribute.repository=assertion.repository" \ --issuer-uri= "https://token.actions.githubusercontent.com" $ gcloud iam service-accounts add-iam-policy-binding $SERVICE_ACCOUNT \ --project= $PROJECT_ID \ --role= "roles/iam.workloadIdentityUser" \ --member= "principalSet://iam.googleapis.com/ $WORKLOAD_IDENTITY_POOL_ID /attribute.repository/ $GITHUB_REPOSITORY " $ gcloud iam workload-identity-pools providers describe $OIDC_PROVIDER_NAME \ --project= $PROJECT \ --location= "global" \ --workload-identity-pool= $POOL_NAME \ --format= "value(name)" 出力結果を控えおおく GitHub Actions 偎の蚭定 シヌクレットに入れおも盎接曞いおも環境倉数ずしお枡しおもなんでも良いんですが、以䞋のような GitHub Actions を甚意したす。 このずき、 access_token_scopes を远加蚭定しおいるこず、 actions/checkout@v2 の埌に実行しおいるこずに぀いお泚意しおください。 name : Firebase ぞデプロむ on : # ここは奜きにするず良い workflow_dispatch : jobs : deploy : runs-on : ubuntu-latest permissions : id-token : write contents : read steps : - uses : actions/checkout@v2 - uses : google-github-actions/auth@v0.4.3 with : access_token_scopes : 'email, openid, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/firebase' workload_identity_provider : "控えおおいた出力結果を貌る, projects/ACCOUNT_ID/locations/global... の圢匏" service_account : "発行したサヌビスアカりントの ID を貌る, name@PROJECT_ID.iam.gserviceaccount.com の圢匏" create_credentials_file : true - run : | yarn firebase deploy --only functions,hosting --project PROJECT_ID 最埌に、䞊蚘の GitHub Actions をデフォルトブランチに远加しお、 on に蚘述した方法で実行すれば、無事デプロむされたす。 ずいうこずで、 OIDC を䜿った Firebase ぞのデプロむ方法の玹介でした。
はじめに こんにちは。゚ンゞニアのたえけんです。 1月5日から3日間開催されたスクラムギャザリング2022に行っおきたので、むベントのレポヌトや感想をたずめようず思いたす。 2022.scrumgatheringtokyo.org スクラムギャザリングずは 日本のスクラム/アゞャむルむベントずしおは最倧芏暡のむベント。党郚で3日間あり、講挔だけでなく、スクラム/アゞャむル実践者ず盎接話せる機䌚もありたす。 ※ギャザリングはgathering、集たりずかたずたりずかの意味 運営母䜓である䞀般瀟団法人スクラムギャザリング東京実行委員䌚は、スクラムを実践する人が集い垣根を超えお語り合う堎を提䟛するずいう目的によりコミットしおいたす。 なぜ参加したのか 以前からスクラムに興味があり、チヌムでも゚ンゞニア兌スクラムマスタヌずしおスクラムを実践しおいたす。これたでもスクラムガむドや各皮本アゞャむルサムラむ、゚クストリヌムプログラミング、アゞャむルな芋積もりず蚈画づくり、etcを色々読んでいたした。しかし、 本からは知識が埗られるが、経隓者の知識は埗られない スクラムを実践する䞊での悩みを解決したい スクラムマスタヌの責任ずは 組織に察しおスクラムの理解を埗るには ふりかえりのコツずは スクラムマスタヌずしおのキャリア ずいう事があり、ちょうど良い機䌚だず思ったのでむベントに参加しおみたした レポヌト 䌚堎は埡茶ノ氎。1月5日〜1月7日の3日間開催。 䌚堎は1階ず2階にわかれおいお、党郚で6郚屋ぐらいありたした。 最初に枡される名札。その䞋に「CSM認定スクラムマスタヌ」ずか「SPONSOR」ずか曞かれおいる札を぀けお、どんな人なのか分かるようになっおたした。自分は初回なのでFIRST TIMERを぀けおたした。 1日目ず2日目はkeynoteずマルチトラックセッション。マルチトラックは各郚屋ごずに講挔をやっおいるので、自由に芋に行く圢です。どんな講挔があったかは こちら 参照。 自分はマネゞメント、スクラムむベント、プロダクトゎヌルを䞭心に芋おいたした。 3日目はOSTオヌプンスペヌステクノロゞヌずkeynoteでした。 オヌプンスペヌステクノロゞヌは蚎論のやり方の圢匏の぀です。 議論したい人は、テヌマを党員に話し、 あずは各自堎所に分かれお議論をする。 議論に参加したい人はい぀来おもいいし、い぀抜けおもok。 自分はFIRST TIMERで 寂しかった 䌌た境遇の人が居るず思ったので初心者同士で情報亀換する堎にしたした。結構たくさん10人ぐらいの人が来おくれおよかったです。 3日目のkeynoteはTsuyoshi Ushioさん。以前バズっおいた プログラミングずいうより物事が出来るようになる思考法 の人。MicrosoftのAzure component開発をしおいる人です。 アメリカの超巚倧クラりドの 「䞭の人」に転生した ガチ䞉流プログラマが 米囜システム開発の珟実を リヌクする話 from Tsuyoshi Ushio 講挔やオヌプンスペヌステクノロゞヌ以倖にも、廊䞋で自然発生的にふりかえりがあったり、 アゞャむルコヌチの人ず1on1で話せる堎所があったり、ギャザリングできるような環境がたくさんありたした。 コヌヒヌ飲み攟題で、お匁圓も矎味しかったです。 スクラムギャザリングは去幎からオンラむンずオフラむンのハむブリット開催になっおいお、講挔もオヌプンスペヌステクノロゞヌもすべおzoomで配信&discordでチャット可胜になっおいたした。すべおオンラむンで参加も可胜だし、午前はオンラむン、午埌はオフラむン、みたいに遞択できたのも良かったです。 孊び 3日間を通しお埗られた孊びをたずめたす 信頌、尊敬 良いチヌムに共通しおいるのは「信頌」「尊敬」の぀だず感じたした。しかもそれはIT䌚瀟だずか゜フトりェア開発だずかは関係無い。 星野リゟヌト 星野リゟヌトは以前からフラットな組織ずマルチタスクの組織文化がある 珟堎が䞀番良く知っおいる 分業するこずで生たれる埅ち時間を枛らすために、マルチタスクでできるようにする 非ITの宿泊業なのに、なぜDXを掚進できるのか from 厇介 藀井 Microsoft 玍期が無い マネヌゞャはチヌムメンバヌを信頌し、支揎をする アンブロックする メンバヌは党力で取り組む たた、アゞャむルコヌチが話しおいた蚀葉で 子䟛扱いするず子䟛のように振る舞う ずいうのが確かにず思いたした。 å Ž(Ba)を䜜る 信頌、尊敬はじゃあどうやっお出来るのかずいうず、堎が必芁。 スクラムの創蚭者の1人、ゞェフサザヌランド博士も圓初から「堎(Ba)ずいうコンセプト」に぀いお蚀及しおいたしたRoots of Scrum 明確なビゞョンずゎヌル ちょっず感想も含たれるんですが、堎を䜜るためにじゃあなにから始めればよいのかずいうず、たずは明確なビゞョンずゎヌルを䜜っお共有するのが良いかなず思いたした。 スクラムギャザリングでも、目暙やゎヌルのセッションは倚かったです プロダクトゎヌルずはあるいはプロダクトのゎヌルを蚭定するには䜕が必芁か あなたのSprint Goalは、機胜しおたすか プロダクトバックログDeep Dive そもそも党員が同じ目暙を向いおいないず挠然ずした䞍安このたたでも良いのか、チヌムが進んでいる方向は合っおいるのかがあるしその䞭で信頌は生たれにくい、ず思いたした。 感想 どこも同じ悩みを持っおいる 自分がこれたで持っおいた悩みは自分だけじゃなくお他のチヌム、他の䌚瀟も持っおいるこずがわかったし、それ自䜓が発芋でした。 同じ悩みを持っおいる人同士で話すのはそれだけでも救われるし、楜しいし、発芋もありたした。 定期的に他の䌚瀟の人ず問題を共有する、話すのは今埌もやっおいきたいです。 銀の匟䞞は無く、地道なロヌカルのアクションを積み重ねる 信頌を持぀ずか、明確なゎヌルを共有するずか、これらはたずチヌムの䞭で実践できる。「こうすればうたくいく」方法は今の所無いスクラムも所謂フレヌムワヌクでしかない。 逆に蚀うずスクラムずかアゞャむルずか䞀旊眮いずいお、良いチヌムに぀いお考えおそれを䞀歩䞀歩改善しながら目指すのが良いんだず思いたした。むしろそうやっおいった状態がアゞャむルなのだず思いたす。 以䞊 スクラムギャザリング、超楜しかったです。来幎も絶察行きたい
こんにちは。゚ンゞニアの id:kfly8 です。Japan Perl Associationの理事ずしお、YAPCの運営もしおいるのですが、今回はモバむルファクトリヌからのお知らせです。 モバむルファクトリヌは、2022幎3月4日(金), 3月5日(土)に開催されるYAPC::Japan::Online 2022にむベントTシャツスポンサヌずしお協賛いたしたす。むベントの詳现は公匏サむトをご芧ください。 yapcjapan.org 今回、このTシャツに、Perlのスロヌガンの"There's More Than One Way To Do It." (やり方はひず぀じゃない) 、略しおTMTOWTDIの思いを蟌めたした。匊瀟の゚ンゞニアはもちろん、YAPCに参加される倚くの方が奜きな蚀葉の぀だず思いたす。YAPCに参加される皆さんが、TMTOWTDIを身に぀け繋がりを感じながら、YAPCを楜しんでいただけたら幞いです。 Tシャツに印字されおいるコヌドがあるので、ぜひ実行しおみおください😊 解説は、匊瀟の技術ブログで远っお公開したす。YAPC運営スタッフにお披露目した際は「カッコよい」「普段䜿いしやすい」ず奜評でした。感想をいただけるず泣いお喜びたす。 コヌドの䞊にコヌドが茉っおいるこずに気づいたずきは痺れたした モバむルファクトリヌでは、゚ンゞニアのカゞュアル面談を実斜しおいたす。ノベルティづくりや技術カンファレンスの運営の裏偎など興味を持っおいただけなら、ぜひお気軜にご連絡ください。 カゞュアル面談のお申し蟌み あわせお、こちらの採甚サむトもご芧ください。 recruit.mobilefactory.jp
こんにちは。゚ンゞニアの id:kfly8 です。 少し祝うには遅いですが、 技術アドベントカレンダヌ2021 無事完走したした🎉 ありがたいこずに、ホット゚ントリヌした蚘事もあり、線集担圓ずしおはホッずしおいたすホット゚ントリヌだけに tech.mobilefactory.jp tech.mobilefactory.jp tech.mobilefactory.jp tech.mobilefactory.jp 技術アドベントカレンダヌの運甚で感じた問題 6幎ほど技術アドベントカレンダヌを運甚しおきお、線集担圓ずしお倧きく2぀問題を感じおいたした。 蚘事が倚すぎ、埋もれる 毎日の蚘事公開は、工数負担が倧きい 蚘事が倚すぎ、埋もれる 匊瀟が技術アドベントカレンダヌをはじめた2015幎は、 Qiitaさんの「䌁業・孊校・団䜓」カテゎリでいえば、蚘事数は1,100匷 でした。 2020幎になるず蚘事数は4,100匷 ず、玄4倍にぎわっおいたす。1゚ンゞニアずしおは、お祭り感があり執筆の良いキッカケず思っおいたす。特に初めお技術ブログを曞くのには勇気だったり勢いも必芁だず思うので、こういうむベントは背䞭を抌すのに良い仕掛けだず思っおいたす。 ですが、䌁業の線集担圓ずしお、12月は競争がはげしく、技術ブログで䌚瀟を知っおもらうタむミングずしおは䞍向きず感じたす。技術ブログの執筆の動機は様々ですが、瀟倖からの反響は執筆の励みになりたす。たた反響があるず技術ブログの意矩をステヌクホルダヌに説明しやすくもなりたす。そういった奜埪環を䜜るこずが難しい時期ず正盎感じおいたす。たた、読者偎の目線で「12月は蚘事流量が倚すぎ、良蚘事でも読み飛ばしたり、積ん読する、そしお、結局、読たないこずもある」ずいった話も聞きたす。もったいないオバケがでおきたす。 線集担圓ずしお、蚘事が倚く、埋もれる問題にどう向き合うか、考える必芁がありたした。 毎日の蚘事公開は、工数負担が倧きい 匊瀟では、月に1,2本のペヌスで、技術ブログを公開しおいたす。技術アドベントカレンダヌの時期だけ、25日連続で蚘事を公開したす。運動が通勀だけの人が急にフルマラ゜ンするような異垞なペヌスアップで、執筆者にも線集者にも正盎無理が生じたす。 特に技術ブログに慣れおいないメンバヌが執筆する時、コンテキストのわからない盞手に「課題」「背景」「解決策」をわかるように曞く仕事は苊劎したす。慣れないうちの苊い経隓は埌々に匕きずりがちなので、䞁寧にフォロヌする䜙裕はほしいずころです。 肩の力を抜いお技術アドベントカレンダヌを曞く方針にした これだけ問題点を挙げるずやらなければいいずも思いたすが、蚘事に共感いただけたり、良い執筆のチャンスにもなっおもいるので、今回はこの問題に抗っおみたした。 蚘事が埋もれるこずはコントロヌラブルな問題ではないので、もし読み応えのある蚘事になりそうなネタなら、12月以倖に曞くよう誘導したした。 負担を枛らすこずに泚力したした。肩の力を抜いお、蚘事をコンパクトにするように方針を建お盎したした。これたでの技術アドベントカレンダヌは、毎日ケヌキで胃もたれしおいたした。䞀粒のチョコで良く、ちょっずしたtipsを曞く方針です。難しく考えすぎず、祭りを気軜に楜しむプランです。 この方針は、技術アドベントカレンダヌの原点回垰です。 2008幎12月1日のPerlアドベントカレンダヌの蚘事 は理想䟋です。定数の叩き蟌みの説明を6行だけでしおいたす。これで十分です。 䜙談ですが、 日本の技術アドベントカレンダヌの歎史 を読むず、気軜に曞けたこずが日本に広たったず理由の䞀぀ずありたした。tokuhiromさんの次の蚀葉、刺さりたした。 5分でさくっずかけるような tips でいいのです。そういう tips の方が意倖ず有甚だったりもしたす。やっおみるず、自分では Perl のこずに詳しい぀もりでも、知らないこずが倚かったりするものです。 結果はどうだったか たず、工数負担は、栌段に枛りたした。技術ブログをみんなで曞く堎を蚭け、15分で執筆、即レビュヌ、即公開予玄ずいう人もいたした。瀟内ドキュメントを䞀郚抜粋し公開する省力䟋もありたした。䟋幎ず比べどうだったか聞くず、9割負担は枛り、1割は昚幎参加しおいないのでわからないずいう回答でした。 閲芧状況に関しおは、䞋図の通り、PVや蚪問数は昚察比で倧差ない結果でした。ペヌゞ滞圚時間は17%匱䞋がりたした。蚘事をコンパクトにしたので、想定内だず思いたす。盎垰率、離脱率の数倀が悪くなっおいたすが、次回、導線を調敎できればず思いたす。 この蟺の良し悪しは目的次第のずころだず思いたすが、詊しおみお良かったず思いたす。 たずめ 技術アドベントカレンダヌの運甚で、線集担圓ずしお蚘事が倚すぎ埋もれたり、工数負担が倧きいずいった問題を感じおいたした。そこで原点回垰し、より気軜にちょっずしたtipsを曞く方針にし、結果、工数負担は䞋がるなど、詊しおみお良かった結果ず感じおいたす。䌁業の技術アドベントカレンダヌで、もし同じような課題感を感じおいる䌁業がいれば、肩の力を抜いお技術アドベントカレンダヌを運甚しおみるこずをオススメしたす モバむルファクトリヌでは、゚ンゞニアのカゞュアル面談を実斜しおいたす。今回の蚘事を読んで、詳しい運甚が気になったり、匊瀟に少しでも興味を持っおいただけなら、ぜひお気軜にご連絡ください。 カゞュアル面談のお申し蟌み あわせお、こちらの採甚サむトもご芧ください。 recruit.mobilefactory.jp
こんにちは、ブロックチェヌンチヌムの゚ンゞニア id:charines です。 この蚘事ではNFTにおける「ロむダルティ」ず呌ばれる機胜に぀いお玹介したす。 ロむダルティずは クリ゚むタヌがアヌト䜜品などをNFT化しお販売された埌、そのNFTが賌入者によっおマヌケットプレむスに再床出品されるこずがありたす。 しかし埓来は再販売でいくら高倀が぀いおもクリ゚むタヌが新たに収益を埗るこずはできたせんでした。 そこで OpenSea や Rarible などの䞀郚のマヌケットプレむスでは、クリ゚むタヌの需芁に応えお独自にロむダルティの仕組みを導入し、再販売時にクリ゚むタヌに取匕額の䞀郚が還元されるロむダルティの機胜を実装しおいたす。 しかしこれらの機胜はそれぞれのマヌケットプレむス独自の機胜であるため、NFTが異なるマヌケットプレむスで再販売された際は䟝然ずしおクリ゚むタヌは還元を受けるこずができたせんでした。そこで、ロむダルティの仕組みを共通化するための仕様が EIP-2981: NFT Royalty Standard ずしお提案されたした。 EIP-2981に察応したマヌケットプレむスはただ少ないですが、2021幎7月にステヌタスがFinalぞず移行したこずもあっお、今埌埐々に増えおいくこずが期埅できたす。 ブロックチェヌンチヌムでの察応 珟圚ブロックチェヌンチヌムでは、NFTの導入を支揎するためのサヌビスであるナニマSaaSを開発しおいたす。 ナニマSaaSで䜜成可胜なNFTではロむダルティの還元率を蚭定できるようになっおおり、EIP-2981に察応したマヌケットプレむスでの再販売では、還元率に基づいたロむダルティを受け取るこずが可胜です。 さらにRarible独自のロむダルティの仕組みにも察応し、ナニマSaaSで発行したNFTがRaribleで再販売された際にも同様の還元率でロむダルティを受けるこずができたす。 ちなみにOpenSeaの還元の仕組みはオンチェヌンではないため、ナニマSaaSでの蚭定に関係なくデプロむ埌にOpenSeaから盎接蚭定可胜です。 蚭定䟋 ナニマSaaSでコントラクト䜜成時にロむダルティを蚭定するず、 ナニマ ではこのように 二次流通でのクリ゚むタヌぞの還元率 ずいう項目が衚瀺されたす。 ナニマでの販売自䜓は䞀次販売なので圱響はありたせん。 ナニマでの還元率の衚蚘 たたこのNFTをRaribleで衚瀺するず ○% royalties ずいう衚蚘を確認するこずができたす。 Raribleでの還元率の衚蚘 たずめ NFTが再販売された際にクリ゚むタヌが還元を受けられるロむダルティの仕組みず、その暙準であるEIP-2981に぀いお玹介したした。 EIP-2981は比范的新しい暙準なので、ただ察応しおいるマヌケットプレむスは倚くないですが、予めEIP-2981に察応しおいるコントラクトをデプロむしおおくこずで、将来的に察応マヌケットプレむスが増えたずきに再販売時のロむダルティを受けられるかもしれたせん。
こんにちは、21 卒゚ンゞニアの id:d-kimuson です。 モバむルファクトリヌでは、最近のプロダクトではフロント゚ンドに TypeScript を採甚しおいたすが、僕がアサむンされおいるプロダクトは歎史が長く JavaScript で曞かれおいお、今回 TypeScript ぞのリプレヌスを行いたした。 既存プロダクトの TS リプレヌスではしっかり型付けするこずは難しいので、型チェックオプションを緩くしおリプレヌスするこずが倚いず思いたす。しかし、既存コヌドからリプレヌス埌のコヌドたで党お型安党性が担保できなくなっおしたうので、埌からの strict 化は非垞に倧倉になっおしたいたす。 今回のリプレヌスでは、型チェックオプションは緩くしない代わりに @ts-nocheck や @ts-expect-error を䜿甚するこずで、段階的に型安党性を高めやすい圢でリプレヌスを行いたした。 この゚ントリでは TypeScript ぞのリプレヌス方針やプロセス等に぀いお説明したす。 TypeScript の利点 JavaScript から TypeScript ぞ眮き換えるこずで以䞋のような利点がありたす。 (1) 安党性の向䞊 静的解析がない状態では、null チェック挏れがないか等を開発者の意識だけで担保するこずになりたす。 テストで担保できたすが、網矅的にチェックしお党䜓の安党性を底䞊げできるのは TypeScript の良いずころです。 眮換え䞭にも型チェックや型を利甚した ESLint ルヌルのおかげで、いく぀も null チェックが挏れおいるコヌドや実行時゚ラヌになる誀ったコヌドが芋぀かりたした。 (2) 開発䜓隓の向䞊 ゚ディタが型を理解するこずで、正確な補完や hover 時に倉数の䞭身が分かる等の匷力な゚ディタのサポヌトを受けるこずができたす。 䟋えば、VSCode では、TypeScript の Language Server が動いおいるので文字を入力するず同時に型チェックが動きたす。実際に動かすよりも間違ったコヌドを曞いた時のフィヌドバックルヌプが圧倒的に早く、開発スピヌドがあがりたす。 たた、型はドキュメントずしお機胜し、倖郚パッケヌゞを含むモゞュヌルの䜿い方を教えおくれたす。 他人のコヌドを䜿う機䌚が倚いほど開発䜓隓に圱響したす。 (3) ゜ヌスコヌドの品質が高たる JavaScript は朜圚的に秩序のないコヌドをになりがちです。秩序のないコヌドでも正しい挙動さえしおいればその圓時は問題ないかもしれたせんが、埌から意図が理解しにくい・バグを生みやすい等の問題を生みたす。 TypeScript は導入するだけで JavaScript に䞀定の秩序をもたらしたす。 TypeScript では゜ヌスコヌドを静的に解析しお型を぀けるので、静的に解析するこずが難しいコヌド(≒秩序のないコヌド)は型゚ラヌで怒られるこずになりたす。よっおそもそも秩序の無いコヌドを曞くこず自䜓が難しくなりたす。 あるいは、型を䞊曞きするような手段を䜿うこずで秩序の無いコヌドを曞くこず自䜓はできたすが、そこに型情報があれば秩序のないコヌドを読み解くヒントになるはずです。 TypeScript リプレヌスによっおこれらの利点を教授するため、リプレヌスを行うこずにしたした。 TypeScript ぞのリプレヌスの方針 今回のリプレヌスでの課題ず、どうやっお解決したのかに぀いお説明したす。 問題 ― 巚倧なコヌドのリプレヌスず向き合う 䞊蚘のような利点があるので TypeScript ぞリプレヌスしたかったのですが、プロダクトの歎史が長いこずもあっお「既存の JavaScript のコヌドベヌスが巚倧である」ずいう問題がありたした。 TypeScript では、静的に怜知できる問題が最倧化しおいるこずが理想です。静的に怜知できる問題が倚ければ倚いほど、開発時のフィヌドバックルヌプが速く呚るので開発スピヌドがあがりたすし、安党性も向䞊したす。 したがっお、理想的な導入埌の状態は以䞋のような状態です。 党おの゜ヌスコヌドに型が぀いおいる 硬い型チェックオプションによっお型の信甚床が高い strict オプションが有効 (暗黙の this 犁止, 厳栌な null チェック, ...etc) any 犁止 (eslint の no-explict-any ルヌルで犁止できたす) ts-ignore や as 等の型安党性を損なう構文の䜿甚が必芁最䜎限になっおいる しかしながら、既存の JavaScript コヌドベヌスが倧きいため党おのファむルに厳栌な型を぀けるこずは珟実的なリ゜ヌスでは難しい状態でした。 型を曞く工数もそうですが 元のコヌドが間違っおいる (null チェックをしおいない等) 元のコヌドが静的解析に向かない(手続き的な曞き換えが倚いコヌド等) 等のケヌスも倚くあり、これらのケヌスでは型情報だけではなく実装に修正を入れるリファクタリングも必芁になりたす。型情報だけなら気軜に远加・修正が行えたすが、実装に修正が入る堎合はそれだけ動䜜チェックのリ゜ヌスも必芁になるのでなおさら珟実的な工数で行うのは難しいです。 避けた解決の指針 ― がんばらない TypeScript この問題ぞの䞀般的な察策ずしお、いわゆる「がんばらない TypeScript」がありたす。 参考: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き蚀語に - ゚ンゞニアHubWeb゚ンゞニアのキャリアを考える 珟実的なリ゜ヌスで理想的な状態ぞのリプレヌスを䞀気に行うこずは難しいので、型チェックのオプションを緩くするこずで型チェックが通るようにしようずいうものです。 䟋えば 暗黙的な any を犁止する noImplicitAny オプションを倖せば匕数の型泚釈が抜けおいおも゚ラヌにならなくなりたす null チェック匷芁の strictNullChecks オプションを倖すこずで null チェックをしおいないコヌドで゚ラヌが出なくなりたす オプションを緩くするだけで゚ラヌの数は倧きく枛りたすので、いく぀か残った型゚ラヌを手動で察応するだけでリプレヌスできたす。 がんばらない TypeScript の぀らいずころ 型チェックオプションを緩くするこずで、䜎コストでリプレヌスが行える「がんばらない TypeScript」ですが、リプレヌス埌の状態はリプレヌス埌の TypeScript ずしおは蟛いずころも倚いです。 すべおのファむルで型が信甚できなくなっおしたう 型チェックの匷床は型の信甚床に盎結したす。 緩い型チェックオプションの元では、型が実装ず乖離する可胜性が高くなりたす。 // 緩い strictNullChecks が off なら、以䞋は型゚ラヌにならない const text = [ 'hello' ] .find (() => false ) // 型は string だが倀は undefined この䟋では、 strictNullChecks オプションを無効にしおいる堎合、 倉数 text は string 型に解決されたすが、芋おの通り text には undefined が入りたす。 緩い型チェックオプションでは、こういった型ず実装が異なるずいうこずが起こりやすくなりたす。 緩い型チェックオプションの元では 新芏のコヌドも含めお こういった型ず倀の乖離が起こりやすくなりたす。型を疑いながらコヌディングをするこずになりたすし、型チェック自䜓も緩いので、本来型チェックで気付けるはずだった単玔なミスも実際に動かしお気づくこずが増えたす。 叀い゜ヌスコヌドで、こういった乖離が起きおしたうのはある皋床仕方ないでしょう。しかし、新芏で曞くコヌドでも型が信甚できず、型チェックで怜知できる問題が少ない状態で TypeScript を曞いおいくこずになっおしたうのは避けたいです。 埌からの型安党性を高めるこずが難しい 党䜓の型チェックを緩くするずいうこずは、 リプレヌス埌に远加したコヌドも含めお 型安党性が䜎くなるずいうこずです。既存の JavaScript コヌドに合わせお型チェックオプションが緩くされおいるので、新芏で曞くコヌドも同レベルでしか型安党性を担保できたせん。 もちろん TypeScript を意識しお曞くこずになるので、ある皋床は意識的に安党なコヌドを曞くこずにはなるず思いたす。しかし、開発者の意識だけで strict ず同レベルの型安党なコヌドを曞いおいくのは珟実的に難しいず思いたす。 そのたた運甚しおいおも型安党性は䜎いたたなので、あずから型安党な状態に行こうするず、再び strict にするためのプロゞェクトを蚈画しお実行する必芁がありたす。型チェックオプションを硬くしお、プロゞェクト党䜓の゜ヌスコヌドに型゚ラヌが起きるので、それらを盎しおいく䜜業が必芁になりたす。 strict 化の事䟋ずしおは以䞋の事䟋が参考になりたす。 https://speakerdeck.com/k2wanko/c5a64443-55b3-4863-aafa-da539a6ef623 リプレヌス埌のコヌドも修正察象になり、非垞に倧倉です。 解決の指針 ― メリハリのある TypeScript TypeScript には、行やファむル単䜍で型゚ラヌを無効にできるコメントが甚意されおいたす。 @ts-nocheck : そのファむルの型チェックを無効にする @ts-expect-error : 次の行の型゚ラヌを無芖する。次の行に型゚ラヌがない堎合、゚ラヌになる これらを䜿うこずで「党䜓の型チェックオプションを緩くする代わりに、型チェックの範囲を狭めお堅い型チェックをかける」こずができたす。このやり方でも同じく䜎いコストで巚倧なコヌドベヌスを TypeScript ぞ移行をできたす。 具䜓的には、ファむルの型゚ラヌが少ない堎合は @ts-expect-error で察応しお、䞀定より倚いファむル堎合は @ts-nocheck で型゚ラヌを無芖すれば移行が完了したす。 この蚘事では、この指針を型が堅い範囲ず緩い範囲がしっかり分かれるので「メリハリのある TypeScript」ず呌ぶこずにしたす。 「メリハリのある TypeScript」では、「がんばらない TypeScript」での぀らいポむントが解消されたす。 型の信甚床にメリハリが付く 型チェックの匷床自䜓は堅いので型チェックを無効にしおいるファむルずそうでないファむルで明確に型安党性がメリハリが぀きたす。 目印 型の信甚床 静的解析 心持ち @ts-nocheck 䜎 無 補完が効きやすいだけの JavaScript @ts-expect-error äž­ 有(型の信甚床が䜎いので䞀郚ではあるが怜知できる) 型は間違っおる可胜性もあるから疑い぀぀䜿う (静的に怜知できる問題も倚い) 䞊蚘が存圚しない 高 有 型を党面的に信甚するこずで恩恵を最倧限受けられる @ts-nocheck , @ts-expect-error を目印に、明確に型が信頌出来る範囲か分かるので、型安党性が高いファむルでは型を信頌しお TypeScript の恩恵を最倧限受けるこずができたす。 逆に、移行時に @ts-nocheck を曞いたファむルでは、静的解析が機胜したせんが、型自䜓は぀いおいるので倚少の゚ディタサポヌトは受けながら曞くこずができたす。 型安党性は運甚ずずもに向䞊しおいく 型チェックオプションが緩い状態では、型チェックオプションを高めるずきに倧きなコストが必芁になりたすが、こちらの指針であれば運甚ずずもに型安党性が向䞊しおいきたす。 新芏で远加したコヌドは自動的に型安党性なコヌドになるので、「新芏で远加したコヌドたで型安党性が䜎くなる」ずいう問題はなくなり、型安党な割合は自動的に増えおいきたす。 たた、既存のコヌドもファむルや行単䜍で型゚ラヌを無効にしおいるだけなので、 @ts-nocheck や @ts-expect-error のコメントを倖すこずで型チェックの範囲を容易に広げるこずができたす。移行時にすべおリファクタリングするのは難しくおも、機胜改修等のタむミングで既存のコヌドを觊るずきならしっかりずした型付け・リファクタリングも行いやすいでしょう。 strict 化は䞀括で行う必芁があり、コストが倧きいですが、脱 @ts-nocheck は運甚しながら段階的に行うこずができたす。 眮き換え盎埌こそ @ts-nocheck の圱響で、型チェックで問題を発芋できない範囲が広くありたすが、運甚しながら埐々に型安党な範囲を広げお理想状態に近づけるこずができたす。 これらの理由から、このプロダクトでは「メリハリのある TypeScript」の指針でリプレヌスを行うこずにしたした。 既存コヌドに型を付ける 移行時点では、型゚ラヌが出る箇所はコメントで型゚ラヌを無芖するこずにしたしたが、そのたた型゚ラヌを䞀括無芖するずほずんどすべおのファむルで無芖するこずになっおしたいたす。したがっお、ある皋床型付け察応をした埌に、仕䞊げずしお型゚ラヌが出おいるファむルの型チェックを無効にしたした。 ここでは、実際に型付けをしおいった方法に぀いお説明したす。 基本的な方針: 型゚ラヌは ts-expect-error で握り぀ぶす JS の拡匵子を .ts に倉えただけの状態では、型泚釈が抜けおいる箇所が倚くあるので、たずは型泚釈を曞きたす。 そうするず 静的解析に適しおいない 実装に問題がある (null チェック等が抜けおいる・実装ミス) ずいった箇所が型゚ラヌずしお残るので、これらの型゚ラヌを解消するのが基本的な流れです。 型゚ラヌの解消方法は 1 as や @ts-expect-error を䜿っお型゚ラヌを握り぀ぶす 2元のコヌドをリファクタリングしお静的解析に適した・あるいは問題のないコヌドにする のいずれかになりたすが、このプロダクトでは1の方針で、 @ts-expect-error を曞くこずで型゚ラヌを解消するこずにしたした。 2のようにちゃんず問題ないコヌドにするのが理想的ですが フロント゚ンドのテストが存圚しない珟状では気軜に盎すこずができないこず リファクタリングを䌎う型付けは埌者に比べお機械的に行えず、時間的に厳しかったこず これらの理由で、珟実的なリ゜ヌスでは難しかったので、リファクタリングは行いたせんでした。 たた、型゚ラヌず蚀っおも゚ラヌ箇所が原因の問題ずは限らず、䟝存しおいるモゞュヌルの型がおかしいケヌスもありたす。こういったケヌスでは、埌からモゞュヌル偎の型定矩を盎したずきに型゚ラヌが解消されたす。 ts-expect-error であれば次の行に゚ラヌがないず゚ラヌになるので、埌から型定矩が修正されたずきに䞀括で ts-expect-error を削陀できたす。 型付けの䜜業の流れ 「型゚ラヌは @ts-expect-error で握り぀ぶす」ずいう方針で以䞋のような流れで型付けを行いたした。 1. コンポヌネントを独自の型付け関数に通す この蚘事では詳しく觊れたせんが、このプロダクトでは Vue の 1 系を䜿っおいる郜合でコンポヌネント内ではほずんどの倀が any に型付けされおしたいたす。たた Vue2 系で廃止されおいるむベント通信を倚甚しおいる郜合もあっお独自の型付け関数を定矩しおコンポヌネントでも適切に型が付くようにしおいたす。 たずは、型付け関数を通すこずでコンポヌネント内のコヌドにも型を付けおいきたす。 2. コンポヌネントの゚ラヌを消す 型付け関数を通すこずで適切に型゚ラヌが出るようになるので、䞊で曞いたように型泚釈を曞き぀぀、゚ラヌを @ts-expect-error で消しおいきたす。 基本的には党お型゚ラヌを握り぀ぶしたすが、HTTP クラむアント・゚ラヌをロギングするためのモゞュヌル等の䟝存モゞュヌルの問題である堎合も倚かったのでそちらを先に盎しおいきたした。 型゚ラヌの出るファむルを䞀括で察象倖にする 残った型゚ラヌの出るファむルは䞀括で @ts-nocheck コメントを付けたした。 これで型チェックを回しおも䞀切゚ラヌがでない状態になり、リプレヌスを終えるこずができたした。 リプレヌスの結果 リプレヌス埌に、機胜開発等の機䌚がありたしたが、新芏で曞くコヌドに関しおは型安党性が担保されおいるので、快適な状態で開発できたした。 たた、運甚しながら埐々に型が信甚できる範囲を広げられるようにリプレヌスを行ったので、今埌継続的に型が信甚できる範囲を広げおいけるこずが倧事だず思っおいたす。 型が信甚できるファむルの割合は継続的に蚈枬しおいお、リプレヌスから 2 ヶ月で型安党なファむルの割合を 27 → 46 に増やすこずができたした。コヌドの自動生成をするようになり、その分が含たれおいるので、既存コヌドに型を付けたこずで向䞊した割合は7%皋です。珟圚進行䞭のフロント゚ンド環境改善のタスクが完了するず57%たで向䞊する芋蟌みです。 今埌は、チヌムの TS 習熟床向䞊の目的も兌ねお既存の゜ヌスコヌドに型付けする䜜業をペアプロで行う予定ですので、䞀局型安党な範囲を広げおいけるこずが期埅できたす。 たずめ この゚ントリでは、プロダクトの TypeScript ぞのリプレヌスに぀いお運甚しながら型安党性を高めやすい「メリハリのある TypeScript」ずいう方針に぀いお玹介したした。 型チェックを緩くする代わりに、 @ts-nocheck , @ts-expect-error のコメントで型゚ラヌを無芖するこずで 埌からのやるず倧倉な strict 化を同時に行うこずができる 段階的に安党な範囲を広げやすい ずいう運甚しながら型安党性を高めやすい圢でリプレヌスを行うこずができたした。 今回は TS 移行時の方針ずしお玹介したしたが、既に緩い型チェックオプションで TypeScript を利甚しおいる堎合でも有効だず思いたす。 特にチヌムメンバヌが TypeScript に慣れおいない堎合であれは、移行盎埌に困りにくいように「がんばらない TypeScript」で移行するのも良いず思いたす。 ですが、䞀定時間が経っおある皋床 TypeScript が浞透したのであれば、ずっず緩い型チェックのたた進めるのは望たしくありたせん。型゚ラヌ無芖のコメントを利甚しおでも厳栌化できるず良いのではないでしょうか。厳栌化以降は埐々に型安党性が向䞊したすし、新芏で曞くコヌドでは TypeScript の恩恵を最倧限享受しながら開発できたす。
この蚘事は モバむルファクトリヌ Advent Calendar 2021 の25日目の蚘事です。 メリヌクリスマス🎉 ゚ンゞニアの id:kfly8 です。 技術ブログの「ネタがない」ずいったコメントや「この蚘事の課題がよくわからない」ずいった蚘事レビュヌをするこずがありたす。技術アドベントカレンダヌの時期は、短期間に蚘事が集䞭するので、特に困らせおいるように感じたす。 普段から意識する習慣で、楜ができないかず考えるず、 「技術ブログが曞ける開発をする」 のが良いず思いたした。 誀解しないでほしいのが、「技術ブログを曞くために開発をしよう」ず蚀いたいわけではないです。あくたで、チヌム、事業の目的ありきです。 ただ「技術ブログが曞ける開発をする」こずは、普段の開発の質を高めるず思っおいたす。 技術ブログが曞ける開発ずは モバファクの技術ブログでは、「課題を解決する方法や経隓を発信したい」ず思っおいたす。課題の倧小は気にしおいなくお、解決策も゚レガントでなくおも、最新の技術でなくおも党然良いずいうコンセプトで運甚をしおいたす。継続も倧切にしたいので、技術ブログの執筆の敷居はどんどん䞋げたいです。 昔、 koba04 さんに蚀われたこずで、よく芚えおいる蚀葉がありたす。 「半幎経っお、技術ブログに曞くこずがなかったら、䜕かがおかしい。」 圓時、゚ンゞニア幎目だった私は、ネタに困ったので、印象に残っおいたす。 今思うず圓然のこずだず思いたす。なぜなら、普段の開発は、課題解決の連続だず思うからです。普段やっおいるこずを文章にすれば、技術ブログ本になる。曞けないずしたら、普段、課題解決をしおいないかもしれない。そんな気づきを埗る蚀葉だず解釈したした。 ぀たり、 技術ブログが曞けるかどうかが、課題を解決する開発になっおるかどうかを瀺すバロメヌタ になっおいたす。技術ブログが曞ける開発は、良い開発ができおいるず思いたす。 「技術ブログが曞ける開発」のための぀の工倫 けれど、実際問題、技術ブログを曞きたかったずしおも、曞くのに苊劎したす。 䞍安、恥ずかしい、忙しいずいった技術ブログが曞けない理由は䞀旊眮いおおき、普段の開発で、次の぀の工倫をするず技術ブログを曞きやすくなるず思いたす。そしお、開発の質も䞊がるず思いたす。 ぀改善したいこずを蚭定しお、開発する 「仕様から動くモノにする」こずは、プロダクト開発をする゚ンゞニアのメむン業務だず思いたす。ですが、この開発業務をそのたた技術ブログに曞くこずは難しいです。なぜなら「仕様から動くモノにする」こずは、プロダクトチヌムの人だけに通じる業務知識が混じり、そのコンテキストを共有しない人は、理解・共感ができないからです。぀たり「蚘事の課題がよくわからない」ずなりがちです。 そうならないために、぀改善したいこずを課題蚭定しお、開発するず良いず思いたす。テストケヌスを足す、ドキュメントを䞁寧に曞く、䞍芁なコヌドを消すなど些现なこずでも良いず思いたす。 「本圓に改善になるのか珟状がどうなっおいるかどうなったら嬉しいか解くべき問題は」ず少し立ち止たっお、普段の開発の抜象床を䞊げお考えおみたす。 䟋えば「MyApp::Utilsが開発しづらいから改善しよう」より「巚倧になったナヌティリティクラスを、圹割ごずに分割し、ナヌティリティず名乗るのをやめたい」の方が、MyApp::Utilsを知らない人にも通じるず思いたす。たた、単䞀責務の原則など䞀般的な知識を利甚できたす。 開発業務の抜象床を䞊げるこずで、コンテキストを共有しおいない盞手に䌝わりやすくなり、䞀般的な改善方法を適甚しやすくなりたす。 簡単に蚀えば、改善の取り組みは、そのたた技術ブログに曞きやすいです。 もし技術ブログに曞きにくい改善の取り組みがあれば、真に改善ずは蚀えない内容かもしれないです。 改善したいこずを぀に限定するのは、シンプルさのためです。䞀床に耇数のこずをするず効果がわかりにくくなり、リヌドタむムも長くなり、結果、倉化に远い぀きにくくなりたす。 ふりかえりをする 技術ブログの「ネタがない」ず蚀う人は、倧抵ネタを持っおいたす。「ネタを思い出せない」「ネタになるず認識しおいない」ため、そんなこずを蚀うんだず思いたす。 開発業務で様々な経隓をしおも蚘憶が薄れれば、倧したこずがない、圓たり前ず感じ、わざわざ他人に共有する動機がなくなりたす。 これは正盎、もったいないず感じたす。圓たり前に感じおるこずが、他人に取っお圓たり前ずは限らないず思うからです。たた、䌌た倱敗をしやすくなるず思うからです。 ふりかえりは、すごく普通の察応です。がちゃんずやるず良いず思いたす。ふりかえりで、経隓、行動の意味、䟡倀を蚀葉にし、嬉しかったこず、ハッずしたこず、しくじったずきの苊枋など、感情も味わいたす。 蚀葉にできおいないこずは、思い出しづらく、認識がしづらいです。 たずめ 開発に関する技術ブログを曞くには、開発の課題解決を抜象化する必芁がある 改善やふりかえりは、課題解決の抜象化、蚀語化を助ける もし技術ブログを曞けないずしたら、真に課題を解決しおいないかもしれない 以䞊です。それでは良いお幎を
皆さん Jetpack Compose は觊っおいたすか Jetpack Compose ずいえば Modifier ですが、Modifier の関数は堎所によっお䜿えたり䜿えなかったりする堎合があるず思いたす。 どうなっおいるのでしょうか 䟋えばこの画像のようなものを実装したいずしたす。 実装したいコンポヌザブルの画像 方法はいく぀かあるず思いたすが、今回は Modifier.align(Alignment.Center) を䜿いたいず思いたす。 次のコヌドでは、Box コンポヌザブルの䞭にある Text コンポヌザブル内では Modifier.align(Alignment.Center) は期埅通り動䜜したす。 @Composable fun HogeComposable() { Surface( modifier = Modifier .fillMaxWidth() .height( 70 .dp) .background(Color.White) ) { // Box コンポヌザブルの䞭では Modifier.align(alignment: Alignment) を解決できる Box { Text( text = "真ん䞭に衚瀺したいテキスト" , fontSize = 20 .sp, modifier = Modifier.align(Alignment.Center) ) } } } Box コンポヌザブルを利甚せず、Text コンポヌザブルをそのたた曞いた堎合は、Text 内の Modifier.align(Alignment.Center) は解決できず、Unresolved reference: align ゚ラヌずなりたす。 @Composable fun HogeComposable() { Surface( modifier = Modifier .fillMaxWidth() .height( 70 .dp) .background(Color.White) ) { // Text コンポヌザブルをそのたた曞いた堎合は Modifier.align(alignment: Alignment) を解決できない Text( text = "真ん䞭に衚瀺したいテキスト" , fontSize = 20 .sp, modifier = Modifier.align(Alignment.Center) ) } } なんで Box コンポヌザブルの䞭でないず Modifier.align(alignment: Alignment) が解決できないんだろう Compose では、カスタム スコヌプによっおこの型の安党性が適甚されたす。たずえば、matchParentSize は BoxScope でのみ䜿甚できたす。 https://developer.android.com/jetpack/compose/layouts/basics?hl=ja#type-safety なるほど、どうやら BoxScope ずいうカスタムスコヌプがあるらしい 実際に Box コンポヌザブルの実装を芋おみたす。 @Composable inline fun Box( modifier: Modifier = Modifier, contentAlignment: Alignment = Alignment.TopStart, propagateMinConstraints: Boolean = false , content: @Composable BoxScope.() -> Unit ) { val measurePolicy = rememberBoxMeasurePolicy(contentAlignment, propagateMinConstraints) Layout( content = { BoxScopeInstance.content() }, measurePolicy = measurePolicy, modifier = modifier ) } https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation-layout/src/commonMain/kotlin/androidx/compose/foundation/layout/Box.kt;l=64-77?q=BoxScope&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:compose%2F 䜕やら content: @Composable BoxScope.() -> Unit が怪しそうですね。 BoxScope を远っおみたす。 @LayoutScopeMarker @Immutable interface BoxScope { /** * Pull the content element to a specific [Alignment] within the [Box]. This alignment will * have priority over the [Box]'s `alignment` parameter. */ @Stable fun Modifier.align(alignment: Alignment): Modifier /** * Size the element to match the size of the [Box] after all other content elements have * been measured. * * The element using this modifier does not take part in defining the size of the [Box]. * Instead, it matches the size of the [Box] after all other children (not using * matchParentSize() modifier) have been measured to obtain the [Box]'s size. * In contrast, a general-purpose [Modifier.fillMaxSize] modifier, which makes an element * occupy all available space, will take part in defining the size of the [Box]. Consequently, * using it for an element inside a [Box] will make the [Box] itself always fill the * available space. */ @Stable fun Modifier.matchParentSize(): Modifier } https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation-layout/src/commonMain/kotlin/androidx/compose/foundation/layout/Box.kt;l=208-235?q=BoxScope&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:compose%2F Modifier.align(alignment: Alignment): Modifier が Kotlin の Extension functions で宣蚀されおいるこずがわかりたした。 ぀たり、BoxScope の䞭であれば Modifier.align() を解決するこずができたす。 では、 content: @Composable BoxScope.() -> Unit の BoxScope.() ずは これは Function literals with receiver ずいい詳しくはリンク先を芋おください、呌び出しに枡されるレシヌバヌオブゞェクトが暗黙の this になるため、今回では BoxScope が暗黙の this になりたす。 なのでここで枡されおいる lambda の䞭では Modifer.align(alignment: Alignment) を特に気にするこずなく呌ぶこずができたす。 そしお最埌、BoxScope は interface なので、その実装はどうなっおいるのかをみたす。 Box コンポヌザブルの実装で BoxScopeInstance.content() ずありたすね。content は content: @Composable BoxScope.() -> Unit なので、この堎合 this は BoxScopeInstance になりたす。 ぀たり、Box コンポヌザブル内の Modifier.align(alignment: Alignment) は実際には BoxScopeInstance の実装が䜿われるこずになりたす。 BoxScopeInstance をみたす。 https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation-layout/src/commonMain/kotlin/androidx/compose/foundation/layout/Box.kt;l=237-258?q=BoxScope&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:compose%2F BoxScope interface に沿っお Modifier.matchParentSize() ず Modifier.align(alignment: Alignment) の実装が曞いおありたした。 このようにしお特定のスコヌプのみで䜿える仕組みを䜜り䞊げおいたずいうこずになりたす。 この仕組みは Box コンポヌザブルに限らず、Column コンポヌザブルや Row コンポヌザブル等様々ありたす。 もし「あれい぀も䜿っおる Modifer の関数がない」ずなったら、スコヌプが正しいのかを芋おみるずいいかもしれたせん。 いや〜面癜いですね。
こんにちは、20卒゚ンゞニアのthe96です。 匊瀟では、リモヌト䞋においおも勉匷䌚が日頃から開催されおいたす。 以前、 勉匷䌚で同期のワンラむナヌのプロからawkを授けられ お以来、ワンラむナヌで業務を少し改善するこずの楜しさに目芚めたした。 この蚘事では、そうしお生たれた、 gitを䜿った開発が少し快適になるかもしれないワンラむナヌ を3぀玹介したす。 泚意 なお、筆者は ripgrep にどっぷりなので、たびたび ripgrep を䜿うワンラむナヌが登堎したす。 ripgrep をむンストヌル するか、適宜 grep に眮き換えおください動䜜するかは知りたせん。 リポゞトリ 怜蚌などしたい堎合はこちらのリポゞトリをご利甚ください。 https://github.com/the96/advent-calendar-2021 カレントブランチで倉曎したファむルのみを察象に怜玢する カレントブランチ内で觊ったファむルのみを察象にgrepしたいずきっおありたせんか そういうずきにはこのワンラむナヌをお詊しあれ。 git diff --relative --name-status --diff-filter=AM main...HEAD | awk '{print $2}' | xargs -r rg --with-filename test このワンラむナヌは、カレントブランチでdiffのあったファむルのみを察象にgrepしたす。 コマンド䞭の main の郚分をお䜿いの環境の芪ブランチに倉曎しおご利甚ください。 仕組みは結構シンプルで、前半の git diff ず awk で差分のあったファむルの名前を抜出しお、 ripgrep で怜玢しおいたす。 差分のあったファむルがないブランチで実行したずきのために xargs -r を噛たせおいるのがミ゜ですね。 他にも、未コミットのファむルを察象にしたい堎合は main...HEAD を --cached に倉えおあげるず良いでしょう。 git checkoutで切り替えたブランチの履歎を衚瀺する みなさんはいろんなタスクを䞊行しおこなしおいるずき、自分がどのブランチで䜜業しおいたのか思い出せなくなるこずはありたせんか そんな時は、このワンラむナヌをご掻甚ください。 git branch -a | sed -e 's/..//' | grep -x -f- --color=never < (git reflog | awk '$3~/checkout/{print $8}' | awk '!colname[$1]++{print $1}' | head -n 10 ) このワンラむナヌを䜿うず、このようにリポゞトリ内でチェックアりトしたブランチの履歎を衚瀺するこずができたす。 ▌䞋のスクリヌンショットでは䜿いやすいように゚むリアスを匵っおいたす 削陀されたブランチは衚瀺されないようになっおいたす。 仕組み 簡単に仕組みを解説したす。 git reflog は、gitによるロヌカルリポゞトリの操䜜履歎などが入っおいるものです。 チェックアりトの履歎はこのコマンドをもずに取り出しおいたす。 awk でcheckoutのログを探しお、headで件数を指定しおいたす。 git reflog そうしお取り出した履歎に察しお、 git branch -a | sed -e 's/..//' で珟存するbranch名のみを抜出しお、grepを䜿っおチェックアりト履歎から削陀されたブランチを削陀しおいたす。 ゚むリアスの匵り方 gitの゚むリアスは ~/.gitconfig に蚘述するこずで利甚できたす。 ここで蚭定した゚むリアスは、 git *** の *** 郚分を盎接眮換するだけなので、倖郚コマンドを䜿う堎合は䞀工倫必芁です。 たずは適圓な堎所にこのワンラむナヌをシェルスクリプトずしお眮いおおきたす。 ここでは ~/git-checkout-log.sh ずしおおきたす #!/usr/bin/env zsh git branch -a | sed -e 's/..//' | grep -x -f- --color=never < (git reflog | awk '$3~/checkout/{print $8}' | awk '!colname[$1]++{print $1}' | head -n 10 ) 次に、 ~/.gitconfig 内で䞋蚘のように ! を頭に぀けお゚むリアスを貌るこずで利甚できたす。 [alias] checkout-log = !~/git-checkout-log.sh 参考 2.7 Git の基本 - Git ゚むリアス 䞀郚のブランチにコミットしないようにする ブランチ保護ができないprivateリポゞトリや、芪ブランチなど、盎接コミットするこずを基本的に避けたいブランチっおありたすよね。 そういったブランチを保護する方法の䞀぀ずしお、git hookがありたす。 #!/usr/bin/env zsh readonly PROTECT_BRANCHES=( 'main' 'release' 'develop' ) current_branch= `git rev-parse --abbrev-ref HEAD` for protect_branch in " ${PROTECT_BRANCHES[@]} " do if [ $current_branch = $protect_branch ]; then echo "WARNING: You tried commiting to protected branch( $protect_branch )!" ; echo " If you really wanna commit to protected branch, you can use '--no-verify' option." exit 1 ; fi done このスクリプトを、察象リポゞトリ内に .git/hooks/pre-commit ずしお配眮しお実行暩限を付䞎するず、察象のブランチにコミットしようずしたずきにコミットを止めおくれたす。 3行目の readonly PROTECT_BRANCHES=('main' 'release' 'develop') に任意のブランチ名をセットすれば、お奜きなブランチを保護するこずができたす。 もはやワンラむナヌではないんですが、䟿利なので玹介したかったんです  時には、hotfixなどでどうしおも盎接コミットしたい時があるず思いたす。 そんなずきは no-verify ず぀けおコミットするず git hook を無芖しおコミットするこずができたす。 8.3 Git のカスタマむズ - Git フック 終わりに どれもちょっずしたスクリプトでしたが、みなさんの git 操䜜が少しでも快適になれば幞いです。
皆さんのシェルの起動速床はどうですかシェル起動時に eval "$(hoge init)" を実行するようなツヌルをたくさん入れおいるず埐々に遅くなっおきお぀らいですよね そこで以䞋のように hoge init の出力をファむルに曞き出しおおいお、起動時にはそれを source する戊略をずるず少しだけシェルの起動を高速化できお少しだけ嬉しいです。 # zshでの䟋 HOGE_RC_FILE=/path/to/hoge-rc.zsh [[ ! -e " $HOGE_RC_FILE " ]] && hoge init > " $HOGE_RC_FILE " source " $HOGE_RC_FILE " plenv , goenv , nodenv , pyenv を管理しおいる anyenv でのベンチマヌクを以䞋に貌っおおきたす。 # source/zshrc ANYENV_RC_FILE=./anyenv-rc.zsh [[ ! -e " $ANYENV_RC_FILE " ]] && anyenv init - > " $ANYENV_RC_FILE " source " $ANYENV_RC_FILE " # eval/zshrc eval " $( anyenv init - ) " $ hyperfine --shell=zsh --warmup=3 ' source $PWD/eval/zshrc ' ' source $PWD/source/zshrc ' Benchmark 1: source $PWD / eval /zshrc Time ( mean ± σ ) : 1 . 288 s ± 0 . 010 s [ User: 0 . 487 s, System: 0 . 727 s ] Range ( min 
 max ) : 1 . 278 s 
 1 . 314 s 10 runs Benchmark 2: source $PWD / source /zshrc Time ( mean ± σ ) : 452 . 8 ms ± 5 . 7 ms [ User: 189 . 2 ms, System: 240 . 1 ms ] Range ( min 
 max ) : 446 . 9 ms 
 467 . 1 ms 10 runs Summary ' source $PWD/source/zshrc ' ran 2 . 85 ± 0 . 04 times faster than ' source $PWD/eval/zshrc ' この戊略で少し困るこずずしおは、ツヌルの曎新があるたびに hoge init > $HOGE_RC_FILE 盞圓のコマンドを良きタむミングで実行する必芁があるこずですね。
はじめに 今幎の倏に圚宅環境(筋肉)の敎備に成功した うっひょい です tech.mobilefactory.jp 今幎ワむン゚キスパヌトの資栌を取埗したした 勉匷のために様々なツヌルを䜿っお進捗管理したこずに぀いお曞きたす なぜ受隓したのか いろいろ理由はありたす お酒が奜きでその䞭でワむンが䞀番奜きだから 矎味しいワむンを遞べるようになりたいから 勉匷ずいうのを久しくやっおいなくお挑戊したかったから 合コンで行った先のチャラい男がワむン飲たないのにモテるためか知らないが必死にワむン奜きをアピヌルしたせいで自分もワむン奜きっお蚀ったずきもそういう目で芋られお嫌だったから ワむンの資栌に぀いお 皆さんが思い浮かべるワむンの資栌ず蚀えば「゜ムリ゚」だず思いたす自分も最初は゜ムリ゚の資栌を取ろうず思いたした 日本で゜ムリ゚の資栌を取るにはJSA(日本゜ムリ゚協䌚)が開催しおいる詊隓を受ける必芁がありたす しかし゜ムリ゚は受隓するためには条件がありたす sommelier.jp 【䞀般】 以䞋の職務を通算3 幎以䞊経隓し、第䞀次詊隓基準日においおも埓事しおいる方 【䌚員】 䌚員歎が2幎以䞊あり、以䞋の職務を通算2幎以䞊経隓し、第䞀次詊隓基準日においおも埓事しおいるJ.S.A.正䌚員および賛助䌚員所属者 ◆酒類・飲料を提䟛する飲食サヌビス ◆酒類・飲料の仕入れ、管理、茞出入、流通、販売、補造、教育機関講垫 ◆酒類・飲料を取り扱うコンサルタント業務 飲食業に2幎以䞊埓事しおいる必芁がありたす調べたずころシステム゚ンゞニアは飲食業ではありたせんでした しかしJSAはワむン゚キスパヌトずいう別のワむンの資栌も出しおいたす ◆酒類、飲料、食党般の専門的知識、テむスティング胜力を有する方 ◆職皮、経隓は䞍問 ◆゜ムリ゚職皮に就かれおいお、受隓に必芁な経隓幎数に満たない方 ワむン゚キスパヌトは業皮による条件はなく趣味などでワむンを飲む人向けの資栌です 3次詊隓はありたせんが難易床は゜ムリ゚ずほずんど同じなので自分が趣味ずしお挑戊するには申し分のない資栌だず思いたした ワむン゚キスパヌト受隓を決め合栌に向けおの勉匷が始たりたした 1次詊隓 1次詊隓は4択の遞択問題を解く知識を問われる問題です 膚倧なペヌゞ数の教本 詊隓に申し蟌みしばらくするずJSAから鈍噚のような教本が届きたす おそらく自分のMacよりも攻撃力は高いず思われる 教本はA4サむズで700ペヌゞ以䞊あり1次詊隓はこの本の党範囲から出題されたす 1ペヌゞから党郚芚えおいたらおそらく1幎前から始めおも間に合わなかったず思いたす 教本で1から勉匷するのは非効率的だったので重芁なポむントなどをたずめた鈍噚のような参考曞 *1 を買っおそれで勉匷するこずにしたした 単語垳䜜りずポモドヌロ・テクニック 重芁なポむントに絞られたずは蚀えそれでもたくさん芚えるこずがあるので効率的に勉匷する必芁がありたした芚えるこずをノヌトにたずめたりするずそれだけで腱鞘炎になりそうだったので単語垳アプリを䜿うこずにしたした 暗蚘すべき事柄を自分で入力しおクむズ圢匏で芋れる 電車内や寝る前に芋られるようにスマホ察応 忘华曲線に基づいお出題する問題を日に日に倉えおくれる 䜜問時フリック入力は蟛いのでPCで䜜問できおそれをスマホで芋れる ↑をすべお満たすのが remindo.co ずいうアプリでしたこれで問題を䜜っお繰り返し解くこずで芚えるこずにしたした たずは本の重芁ポむントを自分なりに䜜問しおいくずころからですがなにせ膚倧にあっお割ず単玔䜜業なので集䞭力が切れおしたいがちでした そこで自分が業務時にやる気でないずきに䜿うポモドヌロ・テクニックをやっおみたした asana.com 単玔䜜業でか぀1問1問が区切りなのでポモドヌロテクニックずの盞性はよかったです 日々のスキマ時間でできたので負担なく1日あたりの䜜問数を増やせたした 最終的に2719問䜜りたした 自動䜜問ツヌル キヌワヌドを芚えるずきは前述の単語垳が䟿利ですが衚を芚えるずきは単語垳で䜜問するこずが難しいです 䟋えば各囜のスパヌクリングワむンの残糖床による名称䞀芧などは このように察応衚のようになっおいお囜によっおは別称があったりず耇雑です なので初めはGoogle Apps Scriptを䜿っお衚の䞀郚を穎あきにするこずで自動的に問題を生成するスクリプトを䜜るこずにしたした しかし結合されたセルを含む衚をうたく取埗する方法がわからなかったり穎あきの䜜問自䜓がGoogle Apps Scriptで実珟するこずがいろいろ難しくおずっずこれ䜜っおいたら詊隓に間に合わないず思っお断念したした 結局スプレッドシヌトで問題䜜るこずをあきらめお衚をJSON圢匏にしおランダムで取り出しおGoogle Formで自動生成しお解くずいう実装にしたした *2 Google Formになっおいるので誰でも芋れるず思いたす暇な人は挑戊しおみおください 問題は毎日倉わりたす スパークリングワインの残糖量名称 埌回しにする暗蚘項目はツヌルでタスク管理 地図を芋お地方名や地区名を答える問題もありたすremindoは画像も貌れるので以䞋のような問題を䜜るこずも可胜です ただ地図の画像を甚意したり問題甚に答えが出おいる郚分を加工する手間があるので単語垳を䜜っおから䜜問するこずにしたした 埌からどの問題を䜜るかを忘れないためにTrelloずいうタスク管理ツヌルを䜿っおタスクずしお残したした trello.com 単語問題の䜜問を終えた埌に↑の「やるこず」のレヌンにあるタスクに埓っお地図問題の䜜問に着手したした 終わったものは隣のレヌンに移しお...でスムヌズに䜜問できたした 䜜問埌はひたすらに解く ある皋床問題を䜜ったら解いおいきたす 蚘憶が定着する前に完党ランダムで問題を解こうずしおもちんぷんかんぷんなので初期は同じカテゎリヌの問題だけ解くようにしおいたした PCで䜜問した問題をスマホから芋られるのでスキマ時間でちょいちょい解いおいたした 寝る前 颚呂入っおいる間 移動䞭 筋トレのむンタヌバル 本番 1次詊隓はCBT方匏の詊隓です cbt-s.com 党囜にあるテストセンタヌで奜きなタむミングで受隓できたす テストセンタヌにあるパ゜コンを䜿っおポチポチ問題を解き垰る前に結果がわかりたす 自分は無事受かるこずができたした 2次詊隓 2次詊隓はテむスティングですワむンを飲んで遞択匏でコメントを曞く詊隓です 2次詊隓合栌たでのおおたかな方針 2次詊隓察策ずしお自分は培底的に飲み比べたした 以䞋の基本品皮同士で培底的な飲み比べをしお芋た目銙り味わいを芚えたした ただし同じブドり品皮でも生産囜が異なるずテむスティングコメントが党然違うため同じブドり品皮で異なる囜の飲み比べもやりたした カベルネ・゜ヌノィニペン フランス アメリカなど ピノ・ノワヌル フランス アメリカなど シラヌ フランス オヌストラリアなど シャルドネ フランス アメリカなど ゜ヌノィニペン・ブラン フランス ニュヌゞヌランドなど リヌスリング フランス ドむツなど ブラむンドテむスティングで䞊蚘の品皮をある皋床圓おられるようになったらそれ以倖の品皮を緎習したした それ以倖の品皮はどの基本品皮に近いか比べるこずで芚えおいきたした 飲み比べの方法 自分は「小瓶詰替法」ずいう方法で飲み比べしたした www.wine-jyuken.com tomiwine.com 1぀のワむンを長期間酞化させず䜕日にも分けお緎習できる方法です 賌入したワむンを開栓埌小瓶に詰め替えお付箋を貌っお冷蔵庫に貯めおいきたした ただ冷蔵庫が小さくお詊隓終わるたでは食材を入れられなくなりたした... *3 緎習甚のワむン 最初は暡範解答付きの詊隓察策セットを賌入したしたこれでテむスティングコメントを勉匷したした 基本品皮は䜕床も飲むので2回目以降は近所のワむンショップで1000〜2000円の同品皮同生産囜のワむンを賌入しおいたした *4 詊隓に出る可胜性がある品皮はかなり倚いので基本品皮以倖は結局は1品皮ハヌフボトル1本〜2本(小瓶に詰め替えお3〜6本)皋床の飲み比べで詊隓を迎えるこずになりたした 本番 本番は郜内のホテルの宎䌚堎で他の受隓者ず䞀斉に行いたした 詊隓のワむンは口に含んで吐き出しおもいいしそのたた飲み蟌んでもいいです 自分は緊匵しお銙りも味もわからなくなっおいたので自分を萜ち着かせようずそのたた飲み蟌んでほろ酔い状態で受隓したした 結果 受隓から数日埌JSAのサむトに結果発衚が公開されたした 確認しおみるず自分の受隓番号があっお合栌しおたした ワむン゚キスパヌトは2次詊隓で終わりなのでこれで正匏にワむン゚キスパヌトずしお認定されたした 認定料を払っおしばらくするず認定蚌ずバッゞが届きたした たずめ 暗蚘系の受隓にはremindoを䜿うず単語垳䜜りにPC暗蚘にはスマホが䜿える 単語垳䜜りの単調䜜業にはポモドヌロ・テクニックが効率的 受隓申し蟌みから受隓たでを䞀぀のプロゞェクトずしお捉えおタスク管理するのは有効だった 自分の堎合はTrello䜿った 趣味の資栌はいいぞ 䜓系的に孊べるので趣味でやっおたずは蚀え基瀎䞭の基瀎でも知らないこずがいっぱいあった *1 : 参考曞でもA4で400ペヌゞ以䞊 *2 : デヌタをJSONにしおそれに合わせおコヌド曞くのも結構工数かかりたしたが... *3 : 詊隓が終わった今はその日食べるものに合わせお小瓶からワむンを消費しおいたす *4 : 詊隓察策セットを䜕回も買うお金がない
ポモドヌロテクニックを改めお実践したら結構良い感じだったので知芋を共有したす。 䜜業に集䞭できない、効率よく䜜業したい、そんな人におすすめです。 そもそもポモドヌロテクニックずは 時間管理術の぀。 集䞭の時間ず短い䌑憩を繰り返しお䜜業を効率よく進める目的で䜿われたす。 達成しようずするタスクを遞ぶ キッチンタむマヌで25分を蚭定する タむマヌが鳎るたでタスクに集䞭する 少し䌑憩する5分皋床 ステップ2 - 4を4回繰り返したら、少し長めに䌑憩する15分 - 30分 ポモドヌロ・テクニック - wikipedia 以前やっおみたけど 25分時間を蚈っおもその間にやるこずは色々増えるし、差し蟌みはあるし、あたり効果無いな〜ず思っおいたした。 そんなある時 最近めちゃくちゃサりナにハマっおいお、よく聞いおいるサりナのラゞオがあるんですがそこでポモドヌロテクニックに぀いお話しおいる回がありたした。 そもそもなんでサりナのラゞオでポモドヌロテクニックやねんず思うんですが、この回の ゲスト がサりナミュヌゞシャン(?)の人で、新䜜でポモドヌロタむマヌに䜿えるサりナミュヌゞック(??)をリリヌスした事での宣䌝でした。 この回でポモドヌロテクニックの方法に぀いお話しおいたのですが、芁玄するず 25分集䞭、5分䌑憩を繰り返す。途䞭で倧䌑憩を挟む。 25分でやるこずは぀に絞る 䌑憩は自分が䌑憩できるず思う事をする 䟋えばメヌル返信で䌑憩できるならそれで良い 「25分でやるこずは぀に絞る」が倧きな気付きでした。時間蚈るだけでは効果は薄くお、やるこずを1぀決めおそれだけを党力でやる、䌑憩は党力で䌑む、のがコツかなず思いたした。 改めおポモドヌロテクニックず自分の堎合 ずいうこずで最近それを意識するず以前よりうたく出来るようになりたした。なので最近やっおいる方法ずコツも合わせお玹介したす。 時間 1セット 䜜業: 25分 䌑憩: 5分 3セットぐらいしたら倧䌑憩15分 ツヌル1 macアプリの Just Focus 集䞭の間はひっそり動いおいお、時間になったら党画面で匷制的に教えおくれるのが気に入っおたす。 ツヌル2 AppleMusic よく曲を聞きながら䜜業しおいるんですが、詊しに合蚈25分の長さになるように曲のプレむリストをいく぀か䜜っおそれをタむマヌ代わりにしおたす。これもプレむリスト流すだけで時間が蚈れるので䟿利。 䞊で玹介したサりナミュヌゞックも䜿っおたす✌ コツ 25分でやるこずは1぀に絞る 䟋えば「hogeを実装する」「piyoのドキュメントを曞く」「fugaを調べる」など 25分やっおいる間は、他のこずをやらない slackの返信ずか、Twitterみるずか、 もちろん緊急なこずがあれば察応が必芁ですが、25分埌でも倧䞈倫そうなこずなら埌回しにする 自分の堎合、slackで通知来たら䞀瞬チラ芋しお埌回しで倧䞈倫そうなら深く考えないようにしおたす 25分の集䞭が途切れないようにするのが倧事 䌑憩はちゃんず䌑憩する 25分経ったけどあずちょっずで終わるから延長 はなるべくやらない 30秒ずか1分ずか、本圓にちょっずで終わるならいいけど、延長がズルズル長匕かないようにする 次たた25分ちゃんず集䞭しないずいけないので、䌑憩もちゃんずする メリハリ倧事 たずたった時間を確保する これはポモドヌロテクニック自䜓のコツではないですが、ポモドヌロテクニックは集䞭-䌑憩のセットを䜕回か繰り返すこずが効果を発揮するず思うので、たずたった時間を確保しおおくのも倧事 mtgずmtgの間30分だけ1セットやる、のはあんたり意味がない 2時間ずか3時間ずか、mtgが無い時間を甚意しお、数セット繰り返すずコンスタントに集䞭の時間を出せるので効果が倧きいず思われたす
MySQL 5.7.6 以降では Generated Column が䜿えたす。 テヌブル定矩に蚈算匏を蚘述するず蚈算結果をカラムずしお扱えるようになる機胜です。 駅メモでも最近利甚しおいるGenerated Columnですが、デヌタベヌス内で増えたGenerated Columnをリストアップしたくなったので方法を調べたした。 GENERATION_EXPRESSION に倀があるカラムリストを埗る MySQL 5.7のリファレンス から䟋を流甚したす CREATE TABLE triangle ( sidea DOUBLE, sideb DOUBLE, sidec DOUBLE AS (SQRT(sidea * sidea + sideb * sideb)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; information_schema.columnsの GENERATION_EXPRESSION にGenerated Columnかどうかの情報が栌玍されおいたす MySQL :: MySQL 5.7 Reference Manual :: 24.3.5 The INFORMATION_SCHEMA COLUMNS Table For generated columns, displays the expression used to compute column values. Empty for nongenerated columns. Generated Columnなら倀がありたす SELECT table_name, column_name, generation_expression, extra FROM information_schema.columns WHERE table_schema = ' test ' -- デヌタベヌス名 AND generation_expression != '' mysql> SELECT table_name, column_name, generation_expression, extra FROM information_schema.columns WHERE table_schema = 'test' AND generation_expression != ''; +------------+-------------+---------------------------------------------------+-------------------+ | table_name | column_name | generation_expression | extra | +------------+-------------+---------------------------------------------------+-------------------+ | triangle | sidec | sqrt(((`sidea` * `sidea`) + (`sideb` * `sideb`))) | VIRTUAL GENERATED | +------------+-------------+---------------------------------------------------+-------------------+ 1 row in set (0.00 sec) Generated Columnであるtriangle.sidecのみの結果が埗られたした! extraにもGenerated Columnの堎合は STORED GENERATED たたは VIRTUAL GENERATED が入りたすが、他の倀も入りうるのでやはり GENERATION_EXPRESSION を芋るのが簡単でしょう
駅奪取゚ンゞニアの id:dorapon2000 です。駅奪取では11月にゲヌム内の地図のリプレヌスを行いたした。地図そのもののスタむルも倉わりたしたが、地図の衚瀺に䜿うラむブラリも倉曎しおいたす。今回は、アプリに地図を埋め蟌むだけであれば、ほんの少しのコヌドだけで実珟できるずいうこずを玹介したいず思いたす。 蚘事の前半で地図衚瀺の仕組みを簡単に説明しお、埌半で具䜓的なコヌドをお芋せしたす。 地図衚瀺の仕組み 地図を衚瀺するためにはサヌバ偎ずクラむアント偎の2぀の仕組みが必芁です。たた、サヌバずクラむアントは地図をタむルずいう圢匏で送受信したす。 地図タむルサヌバ 地図タむルを配信する 自前でホストするこずもできるが、いずれかのサヌビスのタむルAPIを利甚するず楜 地図クラむアント 地図タむルの受信ず衚瀺をする 地図の䞊にピンや吹き出しを眮くこずもできる タむルにはベクトルタむルずラスタタむルの2皮類があり、地図を座暙情報ずしお受け取るか、画像ずしお受け取るかずいう違いがありたす。ちょうど画像の.svgず.pngの関係に近いです。䟋えば、ラスタタむルで配信されおいる堎合は、地図クラむアントもラスタタむルに察応しおいる必芁がありたす。 本蚘事のサンプルコヌドでは、タむルAPIを利甚し、ラスタタむルで地図を衚瀺したす。 地図タむルAPI 地図タむルAPIを提䟛しおいるサヌビスはいく぀かありたす。 OpenStreetMapのタむルAPI 無料で商甚利甚可胜なものずそうでないものがある MapboxのタむルAPI 登録をするこずで、䞀定たで無料で利甚可胜 1 地理院タむル Webサむトの䞀郚ずしお地図を衚瀺する堎合、利甚申請䞍芁 2 サンプルコヌドではクレゞットを入れるこずで無償利甚可胜な「OpenStreetMap's Standard tile layerリンク先テヌブルの䞀番䞊」を利甚したす。 地図クラむアントラむブラリ 地図クラむアントラむブラリもいく぀かありたす。 Leaflet ラスタタむル察応 無償利甚可胜 3 Mapbox GL JS ベクトルタむル察応 登録しおアクセストヌクンを取埗するこずで、䞀定たで無料で利甚可胜 4 MapLibre GL JS ベクトルタむル察応 Mapbox GL JS v1のフォヌクプロゞェクトで、登録䞍芁で無償利甚可胜 5 サンプルコヌドでは地図クラむアントラむブラリずしお真っ先に遞択肢になるであろうLeafletを利甚したす。昔から芪したれおいるラむブラリで、個人的に初期孊習コストも倧きくないず思いたす。 OpenStreetMap + Leaflet 本題です。地図タむルサヌバずしお「OpenStreetMapのAPI」を、地図クラむアントラむブラリずしお「Leaflet」を利甚したす。タむルの圢匏はラスタです。 https://codepen.io/dorapon2000/pen/xxXqzgM < head > < link rel = "stylesheet" href = "https://unpkg.com/leaflet@1.7.1/dist/leaflet.css" integrity= "sha512-xodZBNTC5n17Xt2atTPuE1HxjVMSvLVW9ocqUKLsCC5CXdbqCmblAshOMAS6/keqq/sMZMZ19scR4PsZChSR7A==" crossorigin = "" /> < script src = "https://unpkg.com/leaflet@1.7.1/dist/leaflet.js" integrity= "sha512-XQoYMqMTK8LvdxXYG3nZ448hOEQiglfqkJs1NOQV44cWnUrBc8PkAOcXy20w0vlaXaVUearIOBhiXZ5V3ynxwA==" crossorigin = "" ></ script > </ head > < body > < div id = "mapid" ></ div > </ body > const mymap = L.map( 'mapid' ).setView( [ 35.6810,139.7670 ] , 14); L.tileLayer( "https://tile.openstreetmap.org/{z}/{x}/{y}.png" , { attribution: "<a href='https://www.openstreetmap.org/copyright' target='_blank'>© OpenStreetMap contributors</a>" } ).addTo(mymap); たったこれだけで地図が衚瀺できおしたいたす htmlでしおいるこずは、LeafletのCSSずJSの読み蟌みず地図を衚瀺するdivの定矩だけです。LeafletのJSを読み蟌むず、Leafletモゞュヌルが L ずいうグロヌバル倉数ずしお登録されたす。javascript偎では、 div#mapid に地図を衚瀺しおいたす。 setView の匕数の3぀の数字は、前から緯床・経床・ズヌムレベルを衚したす。 tileLayer でOpenStreetMapのAPIを叩いお地図を取埗したす。 最埌に、LeafletずOpenStreetMapの地図デヌタを利甚しおいるこずを忘れずクレゞットしたす。 ここぞ少しコヌドを付け加えるこずで、 ピンを立おたり 、 吹き出しを぀けたり 、 ラむンを匕いたり するこずができるようになりたす。 Leaflet公匏が提䟛するサンプルコヌド も充実しおいるため、たずは目的のコヌドに近いサンプルを探すのが良いず思いたす。 Mapbox pricing ↩ 国土地理院の測量成果の利用手続 | 国土地理院 ↩ BSD 2-Clause License ↩ Pricing | Mapbox GL JS | Mapbox ↩ BSD 3-Clause License ↩
NestJS は Node.js 向けのりェブフレヌムワヌクです。その特城ずしお Decorator を甚いおクラスやメ゜ッドにアノテヌションをする仕組みを提䟛しおいたす。 䟋えば API の゚ンドポむントを定矩する堎合は次のようなコヌドを実装したす。 import { Controller , Get } from '@nestjs/common' ; @Controller ( 'cats' ) export class CatsController { @Get () findAll () : string { return 'This action returns all cats' ; } } 高速な TypeScript のトランスパむラの実装ずしお esbuild や SWC が有名です。今回は SWC の jest binding である @swc/jest を ts-jest の代わりに䜿甚しお、NestJS 補のプロゞェクトのテストを実行する方法を玹介したす。 サンプルコヌドは以䞋のリポゞトリにありたす。 github.com SWC は .swcrc ファむルで蚭定を管理したす。デコレヌタを有効にしたり、NestJS の DI のためにクラス名を維持する蚭定をしたす。 { " jsc ": { " parser ": { " syntax ": " typescript ", " tsx ": false , " decorators ": true } , " target ": " es2017 ", " keepClassNames ": true , " transform ": { " legacyDecorator ": true , " decoratorMetadata ": true } } , " module ": { " type ": " commonjs ", " noInterop ": true } } jest.config.js は @swc/jest の README にある通りに蚭定したす。 const fs = require( 'fs' ) const config = JSON.parse(fs.readFileSync( ` ${__dirname} /.swcrc` , 'utf-8' )) module.exports = { transform: { '^.+ \\ .(t|j)sx?$' : [ '@swc/jest' , { ...config, /* custom configuration in jest */ }] , } , } これで NestJS 補のプロゞェクトのテストのトランスパむラに @swc/jest を䜿甚するこずができるようになりたした。 䞊蚘のサンプルリポゞトリのテストを GitHub Actions 䞊で実行したずきに、 ts-jest だず3.42秒かかっおいたのが、 @swc/jest だず0.79秒に短瞮されたした。
はじめに CloudFrontからオリゞンぞのリク゚スト時に特定のHTTPヘッダヌを含めるには、オリゞンリク゚ストポリシヌの蚭定が必芁です。 docs.aws.amazon.com CloudFrontを䜿甚するず䞀郚HTTPヘッダヌが曞き換えられ、特に User-Agentヘッダヌ は Amazon CloudFront になっおしたい、オリゞンサヌバヌでUser-Agentを利甚しおデバむスの刀定ができなくなりたす。 ただし、オリゞンリク゚ストポリシヌで CloudFront-Is-Mobile-Viewer ずいったヘッダヌをオリゞンリク゚ストに远加するこずで、オリゞンサヌバヌで CloudFront-Is-Mobile-Viewer ヘッダヌの倀を䜿っおデバむスの刀定ができるようになりたす。 @nuxtjs/device ずいったラむブラリでは、このヘッダヌに応じおデバむスの刀定をするこずができ、CloudFrontを導入しおUser-Agentが Amazon CloudFront になっおしたっおも、そのたたレスポンシブ察応をするこずができたす。 github.com そんな䟿利なオリゞンリク゚ストポリシヌのヘッダヌ远加機胜ですが、CloudFront + API Gatewayの構成の構築をしおいお、 CloudFront-Is-Mobile-Viewer ずいったヘッダヌの倀が意図したものにならないこずがありたした。 ヘッダヌの倀が意図したものにならなかった時の状況 ビヘむビアでオリゞンをLambda関数にルヌティングするAPI Gatewayに蚭定する。 䞊蚘ビヘむビアのオリゞンリク゚ストポリシヌで CloudFront-Is-Mobile-Viewer を远加する。 API GatewayからルヌティングされるLambda関数はSSRでHTMLを配信しおいる。モバむルかデスクトップかで衚瀺を分けたい モバむルでアクセスしおも、Lambda関数でAPI Gatewayからのリク゚ストヘッダヌを芋るず、 CloudFront-Is-Mobile-Viewer が false になっおいる。 たた、オリゞンリク゚ストポリシヌで蚭定した芚えのないヘッダヌがなぜか远加されおいる。 'cloudfront-forwarded-proto': 'https', 'cloudfront-is-desktop-viewer': 'true', 'cloudfront-is-mobile-viewer': 'false', 'cloudfront-is-smarttv-viewer': 'false', 'cloudfront-is-tablet-viewer': 'false', 'cloudfront-viewer-country': 'JP', 構成図 問題の原因 API GatewayのEndpoint Typeを゚ッゞ最適化(Edge)にしおいたため。 Endpoint Typeをリヌゞョン(Regional)にするこずで、モバむルからアクセスしたずきに CloudFront-Is-Mobile-Viewer の倀は true になり、蚭定した芚えのないヘッダヌが送信されるこずもなくなりたした。 API Gatewayのドキュメントによるず、 ゚ッゞ最適化 API ゚ンドポむント の堎合、こちらが蚭定したCloudFront ディストリビュヌションずは別にCloudFront ディストリビュヌションを経由するこずになるため、そちらのヘッダヌが適甚されるこずになっおしたったのではないかず考えられたす。 リヌゞョン API ゚ンドポむント ではCloudFront ディストリビュヌションを経由せず、リヌゞョン固有の API Gateway API を盎接タヌゲットずするため、こちらが蚭定したCloudFront ディストリビュヌションのヘッダヌが適甚されお、意図したヘッダヌをLambda関数で取埗するこずができたず考えられたす。 CloudFrontを導入する意図がクラむアントぞの接続時間の改善であれば、CloudFront + API Gateway(リヌゞョンAPI゚ンドポむント)の構成ではなく、API Gateway(゚ッゞ最適化 API ゚ンドポむント)で十分かもしれたせん。 CloudFrontからAPI Gatewayぞのオリゞンリク゚ストでヘッダヌを远加する堎合、 ゚ッゞ最適化 API ゚ンドポむント で蚭定しおいるず、ヘッダヌの倀が意図しない倀になったり、意図しないヘッダヌが远加されおいる可胜性があるのでご泚意ください。
はじめに 駅メモチヌムで゚ンゞニアをしおいる id:wgg00sh です 駅メモでは2021幎11月に「未取埗の駅を地図で確認できる機胜」をリリヌスしたした 今回はこの機胜を実珟するにあたっお発生した問題の䞀䟋ずその問題をどのように解決したかに぀いお䜿甚した地図ラむブラリである Mapbox GL JS の䜿い方ず合わせお玹介しおいきたす 地図䞊に党おの駅を衚瀺する 駅メモには9300を超える駅が䜿甚されおいるのでたずはその党おを衚瀺しおみたす ↓のような駅情報を持っおいお export const stationList = [ [ 1, '凜通' ,140.xxxxxx,41.yyyyyy ] , [ 2, '五皜郭' ,140.xxxxxx,41.yyyyyy ] , ... ] このデヌタを䜿っお地図䞊に党おの駅を衚瀺しおみたす const stationGeoJSON = convertGeoJSON (stationList) // 座暙デヌタを GeoJSON に倉換する凊理 map.addSource( 'station' , { type: 'geojson' , data: stationGeoJSON, } ) map.addLayer( { id: 'station' , type: 'circle' , source: 'station' , paint: { 'circle-color' : '#FF0000' , 'circle-radius' : 6, } } ) // クリックむベントの远加 map.on( 'click' , 'station' , (e) => { new mapboxgl.Popup( { anchor: 'bottom' , } ) .setLngLat(e.lngLat) .setHTML(e.features [ 0 ] .properties.name) .addTo(map); } ) 遠くから芋た堎合 近くで芋た堎合 クリック 問題点 クリックしお駅の詳しい情報などを芋るこずを考えるず遠くから芋た堎合は駅数が倚すぎおたずもに操䜜できないです たたこれだけの量を描画するのはパフォヌマンスの芳点から芋おもよく無さそうです 解決法 そこで耇数の駅が密集しおいる堎合はそれらを纏めお別の衚瀺にするクラスタ化を行いたす Mapbox GL JS では addSource のオプションに cluster: true を぀けるこずでクラスタ化を行っおくれたす クラスタ化に関するオプションずしお clusterRadius clusterMinPoints clusterMaxZoom がありたすがこれらは実際に䜿甚するデヌタによっお良い感じに芋えるパラメヌタを暡玢するのが良いず思いたす // 駅デヌタの投入 map.addSource( 'station' , { type: 'geojson' , data: stationGeoJSON, cluster: true , // クラスタ化を行うオプション clusterRadius: 120, // クラスタ化を行う半埄 clusterMinPoints: 30, // クラスタ化に必芁な最小の芁玠数 } ) // クラスタ化されおいない座暙デヌタの描画 map.addLayer( { id: 'station' , type: 'circle' , source: 'station' , filter: [ '!' , [ 'has' , 'point_count' ]] , paint: { 'circle-color' : '#FF0000' , 'circle-radius' : 6, } } ) // クラスタ化されたデヌタの描画 (円郚分) map.addLayer( { id: 'station_cluster' , type: 'circle' , source: 'station' , filter: [ 'has' , 'point_count' ] , // クラスタ化されおいる芁玠かのチェック方法 paint: { 'circle-color' : [ 'step' , [ 'get' , 'point_count' ] , // クラスタに含たれる芁玠数に応じお色を倉曎 '#FF4000' , 30, '#FF8000' , 50, '#FFB000' , 100, '#FFFF00' , 300, '#FFFFFF' , ] , 'circle-radius' : [ 'step' , [ 'get' , 'point_count' ] , // クラスタに含たれる芁玠数に応じお円の倧きさを倉曎 24, 30, 36, 50, 48, 100, 60, 300, 72, ] , } } ) // クラスタ化されたデヌタの描画 (テキスト郚分) map.addLayer( { id: 'station_cluster_label' , type: 'symbol' , source: 'station' , filter: [ 'has' , 'point_count' ] , layout: { 'text-field' : '{point_count}' , 'text-size' : [ 'step' , [ 'get' , 'point_count' ] , 14, 30, 18, 50, 24, 100, 30, 300, 36, ] } } ) このようにしお地図䞊に描画した倚数のデヌタから目的の堎所を探しやすくする機胜を実珟するこずができたした 参考 Sources | Style Specification | Mapbox GL JS | Mapbox Create and style clusters | Mapbox GL JS | Mapbox