読書メモ:いちばんやさしいアジャイル開発の教本

どんな人におすすめ? アジャイル開発について簡単な歴史的背景と具体的にどのような開発手法かまとまった書籍です。 はじめてアジャイル開発について学びたい人、これまで我流でアジャイル開発を進めてきて改めて体系的に概要を学びたい人。 特にChapter7のアジャイル開発の理解を深めるが非常に参考になりました。 ウォーターフォール開発に慣れている人がアジャイル開発にするときに見積もりをしない、ドキュメントを用意しないなど ウォーターフォールから比較して気になっている方が多いと思います。私の周りの気になる人が多かったです。 そのような疑問に対してもアジャイル開発に対するそれぞれの問いに対して各Lessonで説明しているところが非常に良かったです。 組織に応じて適宜修正する必要性 また序盤にこれまでの本はそのまま手法を輸入して、日本に最適化されていないという著者の説明は面白かった。 これまで自分も含めて、周りでアジャイル開発を進めようとするときにウォーターフォール開発に慣れている人からすると受け入れがたいときがあり、 日本の文化にはアジャイル開発が馴染みにくいかなと思うときがありました。 そのような経験もあったので著者の日本に最適化されていないという点は実体験から腹落ちしました。 個人的な意見として、日本とひとくくりにしないで組織や会社によって文化があると思います。 それに応じて臨機応変に最適な手法を選んだり、そのままその手法を適応するのではなく、 適応するチーム・組織にとって最適なやり方に軌道修正する必要があることはあるので、 その際は基本コンセプトは変えずに最適な方法を模索する必要があると思っています。 もちろんこれはアジャイル開発に限らないと思います。 まとめ より実践的にアジャイル開発を導入するには基礎的なことだけでしたらこの本だけで十分ですので、 アジャイル開発の基礎的なところを学びたい方にはおすすめの本です。

December 30, 2021 · 1 min · Implicitnone

GitHub ActionsでHugo extendedを使うやり方

TL;DR GitHub ActionsでHugoを使ってbuildする際にextendが必要となった場合、GitHub Actionsのymlファイルにextend: trueを書くと解消します。 はじめに HugoのレポジトリでPull Requestを作成した際やMergeされた際にGitHub Actionsでレポジトリに登録されたコードをHugoでbuildすることができます。 Hugoでsetup(GitHub ActionsでHugoを使えるようにする)、setupしたHugoでbuildが大きな流れになります。 本ページの参考に記載した各ウェブサイトにてHugoでのsetupを参考にさせていただきましたが、Hugo extendedの対応について書かれているところが管理人は見つからなかったので、このページでまとます(他に書いているところがあったらすみません)。 GitHub ActionsでのHugo deployの仕方 やりたかったことは下記のとおりです。 Pull Request作成 GitHub Actions開始 Pull Requestを作ったレポジトリのブランチをチェックアウト(https://github.com/actions/checkout) Hugoをset up(https://github.com/peaceiris/actions-hugo) Hugoでbuild Firebaseでpreviewページをデプロイ(https://github.com/FirebaseExtended/action-hosting-deploy) 上記中で忘れがちなところは、3の最新のブランチのチェックアウトでsubmoduleもcheckoutすることとです。 これは他のサイトでも説明されています。 GitHub Actionsとしては下記のように記載します。 ~略~ - uses: actions/checkout@v2 with: submodules: true ~略~ 今回は、5.のHugo buildのところでエラーになりました。 GitHub Actionsで表示されたエラーは下記になります。 WARN XXXX/XX/XX XX:XX:XX Module "theme-name" is not compatible with this Hugo version; run "hugo mod graph" for more information. Start building sites … hugo v0.91.2-1798BD3F linux/amd64 BuildDate=2021-12-23T15:33:34Z VendorInfo=gohugoio Error: Error building site: TOCSS: failed to transform "scss/style....

December 29, 2021 · 1 min · Implicitnone

Google DomainsでGCPのサーバーに転送する方法

*GoogleおよびGoogle、Google Domainsのロゴは、許可を得て使用されているGoogle LLCの登録商標です。 TL;DR Google DomainsからGCPなどで構築したサーバーに転送する方法を紹介します。このページで紹介する内容は、GCP上でWordPressなど構築して、ドメインをGoogle Domainで取得した際などに利用できます。 ドメインとサーバー サーバーを構築してパブリックなIPアドレスを取得したらドメインと連携すると思います。 ドメインを取得するとそのサイトの信用が得られたり、メールアドレスを取得できたりと色々メリットがあります。 そもそもIPアドレス直打ちで公開しているサイトはほとんどないですもんね… 管理人はWordPressを構築して公開する必要があったので下記ページを参考に GCP上でWordPressを構築しました。 外部サイト:簡単!便利!GCPでWordPress環境を立ち上げてみよう!@株式会社トップゲートさん 上記のページだとGCPのサービスのCloud DNSを利用してドメインからWordPressのサーバーへの紐付けを行っていますが、 Google Domainsから直接該当のサービスに転送できないかと思いこのページに記載する方法で解決しました。 Google Domainsでの転送方法 Google Domainsの管理画面から左のタブでDNSを選ぶと、中央にリソースレコードと表示されている枠の中にカスタムレコードの項目があります。 この中のカスタムレコードを登録していないと下記図のようにカスタムレコードを登録できます。 ここで登録しているドメインにサブドメインを追加しない形での登録方法を書きます(サブドメイン:hoge.comのドメインを取得している場合、abc.hoge.comがサブドメインになります)。 ホスト名:空欄 タイプ:A TTL:3600(デフォルト) データ:サーバーのIPアドレス(例:192.168.1.0) 上記はIPv4のサンプルです。IPv6の場合は、タイプをAAAAにするなど変更が必要です。 半角スペースなど不要な文字が入らないように注意しましょう。 あとは保存すると早くて数分、遅くても大体1日以内には登録したドメインに通信すると指定されたサーバーにアクセスすることが確認できるかと思います。 もちろん設定がただしくないと時間が立ってもサーバーにたどりつけないのでその場合は設定が間違っていないか?IPアドレスが間違っていないか?サーバーが起動しているか?などが思いつきますので確認されるのがよいかと思います。 参考 https://domains.google/ https://www.topgate.co.jp/gcp-wordpress https://support.google.com/domains/answer/10751068#zippy=%2Ca%2Caaaa

December 28, 2021 · 1 min · Implicitnone

Google Domainsでドメインを登録する

*GoogleおよびGoogle、Google Domainsのロゴは、許可を得て使用されているGoogle LLCの登録商標です。 TL;DR Google Domainsでドメインを登録する方法を説明します。Google Workspaceなどにすぐ連携できるので便利です。 Google Domainsとは? https://domains.google/ Googleで提供しているドメイン登録サービスです。日本だとお名前.comさんなどが有名かもしれませんが、 Google DomainsだとGoogle Workspaceとの連携がしやすいなどメリットがあります。 Google Workspaceを検討されている方、新しく購入される方で新規にドメインが必要な場合はGoogle Domainsの利用を検討されてはいかがでしょうか? Google Domainsの登録の仕方 登録したいドメインをTOPの画面で入力して検索します。 その後検索結果に応じたドメインが表示され、購入したいドメインの横にあるカートアイコンをクリックします。 もちろん、このときすでに他ですでに購入されているドメインは登録できませんので他のものを登録するか、 もしくは似たようなドメインをGoogle Domainsのサイトからレコメンドされるのでそれを選択することになります。 もし今すぐ買えないが、気に入るドメインがある場合はハートマークのアイコンをクリックしてお気に入りに入れていくことも可能です(gmailなどのgoogleアカウントでログインされているときに表示されます)。 購入するドメインがすべて決まったら右上にあるカートのアイコンをクリックして登録するドメインの内容を確認します。 .comのドメインはプライバシーの保護として、登録したユーザーの住所など公開されない機能が利用できます。 .jpなど他は保護機能はないので注意です。参考:プライバシー保護を有効または無効にする。 また、自動更新の機能はあります。基本的には自動更新はONにしておけばよいかなと思います。 このままGoogle Workspace(gmailやgoogle driveをこのドメインで使う有料版)を使う場合は、申し込むタイプを選びます。 残りは支払い画面になり、gmailなどですでにログインされていればそのまま支払い情報から支払えます。 また、Google Payでの購入も可能になっています。参考:Google PayでのDomainの購入 *日本が請求先住所の国に設定されていれば問題ありませんが、請求先住所の国の制限がありますので詳細は公式サイトをご確認ください。 まとめ 意外と簡単にGoogle Domainsでドメインが登録できることがわかったかと思います。 特に今後Google Workspaceを利用予定ならGoogle Domainsでドメインも管理すると簡易に連携できるのでおすすめです。 参考 https://domains.google/

December 18, 2021 · 1 min · Implicitnone

Firebase Hostingを遣う際の.gitignore

TL;DR .firebaseディレクトリは.gitignoreに記載する。.firebasercとfirebase.jsonは基本的にgitignoreに記載しなくてよい。ただし、状況に応じて使い分けるべきで、投稿するFirebaseプロジェクトがオープンソースや他の人が別のFirebaseを遣うなら、.firebasercはgitignoreに入れたほうがよいと思われる。 Firebase Hostingとは 静的ファイルをホスティングしたくGCP GCSやAWS S3でいいかと思っていたのですがFirebase Hostingだと通信量やファイルサイズが小さい無料枠に収まることがわかり、実際に試してみることにしました。 実際に使ったところ、htmlなどデプロイしたいものが既に用意されていればすぐにserveできるのでFirebase Hostingは非常にクイックにデプロイできるサービスかと思います。最初のデプロイの解説は他の記事にゆずるとして、この記事ではFirebase Hostingを遣うさいに記載すべき .gitignoreを検討します。 .gitignore記載すべき項目 さきに.gitignoreに記載するために私が検討した項目を記載します。なお、.DS_Storeなどの各開発環境に依存するファイルやホスティングするファイルに関してはここで検討しません。 .firebaserc firebase.json .firebaseディレクトリ 上記3つがFirebase Hostingにデプロイするときに主に検討するファイル/フォルダかと思います。 私が調べた範囲ではfirebase.jsonは基本的に.gitignoreに記載せず、そのままgitに記載している意見しかなかったです。 firebase.jsonはFirebase Hostingの構成情報を記載します(参考:Firebase ホスティング動作を構成する )。publicが必須属性でどのディレクトリをFirebase Hostingにデプロイするのか指定する属性になります。他にも省略可ですがigonore属性でホスティングしないファイルなどを指定したり、404のファイルを指定したりとFirebase Hostingを遣う上で必須のセッティングファイルになりますので、このファイルを登録しないと同じレポジトリを遣う他のユーザー/他の環境でデプロイに関する情報を共有できなくなるので基本的にgitに登録すべき情報になります。もちろん他では別のファイルを遣うなどあれば.gitignoreに記載すれば良いですがそのケースは記載するケースに比べて少ないかと思います。 .firebasercはネットで検索すると、Firebaseの有志のfirebase-continueの.gitignoreファイル内で記載されています。また、stackoverflowをみると用途に応じてこのファイルはgitignoreに記載するか記載しないか判断することと回答がありました。例えば、オープンソースや組織内で公開して、別の人が別のFirebase Hostingのプロジェクトを使う場合はこのファイル名が.gitignoreに書いていないと別のFirebaseプロジェクトにデプロイするときに記載しなおさないといけなくなるので.gitignoreに記載したほうが効率的でしょう。他の開発者も同じFirebaseプロジェクトを遣う場合は共通化しておいたほうが良いので、.gitignoreに記載しないほうがよいということになります。 .firebaseディレクトリはFirebase CLI versionが4.2.0から導入された機能で前回のデプロイした内容からの差分がたまるようになっているそうです(参考:stackoverflow What’s the purpose of .firebase/hosting. ALPHANUM.cache)。 こちらの記事をおってgithubの変更からなにが具体的に変更になったのか調べようかと思ったのですが、ご存知な方は教えていただけると助かります。 キャッシュについては登録する環境で異なるでしょうし、githubに登録する必要がないので.gitignoreに登録したほうがよいということになるかと思います。 まとめ 初めて遣う言語やフレームワークのときはgithubのgitignoreレポジトリを参考にして自分のレポジトリのときはどうするか考えていくのですが、今回Firebase Hostingを初めて使うにあたりgithubに登録するファイルの検討をして、フォルダの構成やファイルがどんな役割を持つのか理解が深まったのでまとめてよかったです。もちろんそれぞれのファイルの役割やフォルダについてすべて理解したわけではないのでこれから使いながらより理解を深めたいと思います。 参考 https://firebase.google.com/docs/cli?hl=ja https://github.com/FirebaseExtended/firebase-continue/blob/master/.gitignore https://stackoverflow.com/questions/43527359/what-is-the-practice-on-committing-firebase-files-in-a-nodejs-app https://github.com/firebase/firebase-tools/releases/tag/v4.2.0 https://github.com/github/gitignore

November 28, 2021 · 1 min · Implicitnone