Posts

Hugoでこのブログを立ち上げたので、HugoのインストールからGithub Pageで公開するまで。 環境 windws11 Hugo そもそもHugoのことをよく知らずに技術選定をしてしまったので、ここでしっかり調べておくことにする。 HugoはGoで記述された静的サイトジェネレータで 「ウェブサイトを構築するための世界最速のフレームワーク」 らしい。 The world’s fastest framework for building websites | Hugo 静的サイトジェネレータ 静的サイトジェネレーターとは、生（未加工）データとテンプレート群を基に、完全に静的なHTML Webサイトを生成するツールのことです。静的サイトジェネレーターは、基本的に個々のHTMLページをコーディングする作業を自動化し、それらのページをユーザーがすぐに使えるようにします。これらのHTMLページは事前作成されたものであるため、ユーザーはブラウザで即座に読み込むことができます。 静的サイトジェネレーターとは？ 上記の通り、事前にHTMLを生成するのでパフォーマンスがいいのがメリットのひとつ。 Hugoのインストール 公式サイトに詳しい。 WindowsなのでWindowsのインストール方法通りに行った。 パッケージ管理システムのChocolatey、ScoopとWingetを使うインストール方法が提供されていた。他にも2つインストール方法が記載されている。比較表があるのでわかりやすい。 パッケージ管理システム ちなみにパッケージ管理システムとは、 コンピュータのプログラムを一貫した方法でインストールやアンインストール、ライブラリなどの依存関係を解決する流れをツールによって管理を自動化するシステム のこと。 npmとかComposerとかも言語のパッケージ管理ツールにあたる。 Chocolateyが有名っぽいけど、インストール方法がぱっと見わからなかったので、Scoopを使用することにした。 調べるとMacではHomebrew一択っぽい。Windowsではwingetが公式っぽく、インストールも必要なく使えて便利そうだった。 インストール情報をエクスポートすることもできるので、パソコンの買い替え時とかにも重宝できそうだった。 Windowsのパッケージマネージャー「winget」を使ってみた 今思えばwingetにすれば良かったと思うけど、Scoopを選択したので、それで進めていく。 Scoopでインストールする scoop install hugo-extended 上記コマンドを使用すれば、hugoの拡張版をインストールすることができる。 'hugo-extended' (0.122.0) was installed successfully! Hugoでサイトを構築する Hugoでサイトを構築するのは簡単で、下記コマンドを叩くだけでいい。 hugo new site site-name 上記を実行した後に、 hugo -D serve で、サイトを確認することができる。 テーマを選んで適応する Hugoは沢山のテーマが提供されている。Wordpressに通ずるものがある。 Hugo Themes 今回は一番上にあったPaperModを採用することにした。 hugo-PaperMod テーマを導入する git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod サブモジュールって？ 外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組み...

環境 windws11 node => v20.11.0 npm => 10.4.0 nuxt => 3.10.1 install 公式の手順に従っていく。 Installation · Get Started with Nuxt npx nuxi@latest init <project-name> ❯ Which package manager would you like to use? ● npm ○ pnpm ○ yarn ○ bun 上記を実行すると、エラーが発生した。 npm ERR! gyp ERR! cwd C:~\node_modules@parcel\watcher npm WARN cleanup Failed to remove some directories [ npm WARN cleanup [ npm WARN cleanup 'C:\\project\\project-name\\node_modules', npm WARN cleanup [Error: EPERM: operation not permitted, scandir 'C:\project\project-name\node_modules\resolve\test\resolver\multirepo\packages\package-a'] { npm WARN cleanup errno: -4048, npm WARN cleanup code: 'EPERM', npm WARN cleanup syscall: 'scandir', npm WARN cleanup path: 'C:\\project\\project-name\\node_modules\\resolve\\test\\resolver\\multirepo\\packages\\package-a' npm WARN cleanup } npm WARN cleanup ], npm WARN cleanup [ npm WARN cleanup 'C:\\project\\project-name\\node_modules\\@vercel', npm WARN cleanup [Error: EPERM: operation not permitted, rmdir 'C:\project\project-name\node_modules\@vercel\nft\node_modules\@rollup\pluginutils\dist'] { npm WARN cleanup errno: -4048, npm WARN cleanup code: 'EPERM', npm WARN cleanup syscall: 'rmdir', npm WARN cleanup path: 'C:\\project\\project-name\\node_modules\\@vercel\\nft\\node_modules\\@rollup\\pluginutils\\dist' npm WARN cleanup } npm WARN cleanup ] npm WARN cleanup ] npm ERR!...

最近鳴りを潜めていたブログをリニューアルしたいという欲望が、新年早々むくむく頭をあげてきたので、欲望のままにリニューアルすることにした。 今までのブログ歴 初めてブログを立ち上げた時は、WordPressの無料テーマを使った。確かあれは新卒で入社したWebサイト制作会社を退職した時で、コードを書くことに飢えていた。そこでブログを立ち上げ、「実験だ」と、無料テーマをカスタマイズしては楽しんでいた。 それから1年後くらいにWordPressの自作テーマを作りたくなり、リニューアルした。リニューアルした後も色々新規ページを作って楽しんだりしていた。記事のメインは技術についてで、それなりに見てくれる人も多く、有難いことに副業の依頼もいただけたりした。 徐々にWordPressに慣れてくると、次にWordPress以外のプラットフォームでブログを作りたいという欲求がむくむくと頭を上げ始めた。 そこで当時話題になっていたmicroCMSとNetlifyとNuxt2で静的ブログを作成した。これもまたいい経験であった。転職活動の時にいいポートフォリオになってくれたし、それなりの知見を得ることができた。 そのあと、またWordPressに戻り2度ほどテーマを作成し、拡張機能(Create Eye Catch For Classic)も作成した。 そして今に至るのである。 書いた記事は資産になるはずだがどこかに消えた ということで今まで、5回ブログをリニューアルしている。テーマだけを変えればいいのだが、そのたびサーバーを変えているので、記事の記録はすべて引き継がれていない。これは自分が悪いのだが、エクスポートするのもそれなりに面倒くさいことはわかってほしい。 そんな面倒なことはしたくないが、きっと今後もブログはリニューアルし続けるに違いない。そのたびに今までのように記事が失われるのは避けたいということで、Githubで記事を管理することにした。Githubで記事を管理し、それをWordPressにポストする。これが最適解に思えたのだが、運用してみるとこれが何とも面倒くさい。 特に編集するときが面倒くさい。 まずGithubで変更し、そのあと修正をWordPressの投稿画面でチェックする。問題がなければ公開する。なんとも面倒で仕方ない。 Githubでcommitするたびに記事が公開されればいいのに、という思いになり、静的サイトジェネレータを使うことにした。 ヘッドレスCMSでもいいのだが、すべてのソースコードがGithubに集約されているので、管理画面をこれ以上増やしたくない。 そういうことでこのブログを立ち上げることにした。 ブログリニューアルした っていうのも6回目となる。 どうせまたリニューアルするけど、記事はそのまま資産にできる。

タイトルにあるようにSwaggerで作成したいのであれば、yamlを作成すればいい。 だけど、そんなことをするのは面倒くさい。 というのもNestJsではデコレーターを追加するだけで自動でSwagger UIを作成してくれた。 そこでGoでも同様な手順で実現できるライブラリを探してみた。 swaggo/swag swaggo/swagを使えばできそうだったので試してみた。 インストール go install github.com/swaggo/swag/cmd/swag@latest アノテーションを作成する main.goにアノテーションを追加する。 // @title sample api // @version 1.0 // @description this is sample apigw // @host localhost:18080 // @BasePath /api/v1 // @tag.name accounts // @tag.description about accounts request func main() { handlers.HandleRequests() } 記入後にswag initを実行する。 . ├── docs.go ├── swagger.json └── swagger.yaml すると上記ファイルたちが生成される。 UIで確認する これがいまいちわかなかったので、https://editor.swagger.io/に生成されたyamlファイルをコピペして見る方法にしているけど、localhost:18080/api/v1で見られるんだと思われる。 …見れないので、要調査。 ⚠️ 違った。 localhost:18080/api/v1 上のURLはBaseURLだった。 まあ、問題ないので、いったん上記方法で行く。 追記：2023.12.30 Swagger ViewerVSCodeの拡張機能があった。 個別APIのアノテーションを作成する // GetAccount // @summary アカウントの情報を返します // @description user_idを元にアカウント情報を返します // @tags accounts // @produce json // @success 200 // @failure 401 // @router /accounts [get] func FetchUserById(w http....

アクセストークンの有効期限は短く ログイン認証を作るうえで、アクセストークンの有効期限は短い方がいい、という情報を得た。 アクセストークンが盗まれた時に、備えてのことらしい。 例えば15分とか、って例で書かれていた。 そうすると15分ごとにログインをし直させなければならない。 それはユーザビリティ的にどうなのだろうか。という疑問が生まれた。 それを解決するのがリフレッシュトークンらしい。 アクセストークンとリフレッシュトークン リフレッシュトークンはアクセストークンを再発行するために必要になる。 例えば、ログインをしアクセストークンを取得する。 15分後、アクセストークンが切れた場合はリフレッシュトークンを使用し、アクセストークンを再発行する。 その際、リフレッシュトークンも最新化する。 これで15分ごとにユーザーがログインし直すという苦痛から解放することができる。 アクセストークンは危険で、リフレッシュトークンは安全なの？ アクセストークンもリフレッシュトークンも一緒に得ることができ、同じように保存をしておく必要がある。 それなのにどうしてアクセストークンは危険で、リフレッシュトークンは安全なのだろうか。 ってずっと疑問だったけど、社内の博士に聞き解決した。 確率の問題 アクセストークン、リフレッシュトークンが盗まれるのは通信中である。 通信にアクセストークンを持たせて、15分間、何回通信をするだろうか。 それに比べてリフレッシュトークンはアクセストークンが失われた時にしか使用されないので、リフレッシュトークンに比べて安全だと言える。 ということ。