【arm64対応のNode.js】M1 MacBook AirにNode.jsのLTS(v14)をインストールする
ようやくM1のMacBook Airでもプログラミング環境を整えることにしました。
Node.js環境が必要なので、下記のようにインストールを行いました。
なお、Node.jsのLTSを入れておきたかったので、v14をインストールしました。
少し前の記事だとまだv14には対応していないという記述もありましたが、現在は対応も済んでいるようです。
あと、intel版よりもNode.jsのインストールに時間がかかりました。
(v14のソースをローカルに落としてビルドしているからかと思います)
インストールについてはnvmを用いてNode.jsをインストールしています。
ここらへんは個人的な好みで、そうしています。
以下、実行したログとなります。
# nvm install curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash # そういえばm1 macではまだ".zshrc"をつくっていなかったのだった。 touch ~/.zshrc
nvm インストール直後に、コマンドラインのログに出てくる下記の記述を ~/.zshrcにコピペ。
# .zshrc export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
次はNode.jsをインストール
source ~/.zshrc nvm install v14 # ソースをダウンロードしてビルドするところで結構時間がかかる node -v # => v14.16.0 # arm版が入っているかも一応確認 node -p process.arch # => arm64
以上です。
macOSでOBS Studioを使用するときに、Chromeなどの他のアプリが認識されない問題の対応メモ
macOS環境でOBS Studioを利用するときに、毎回のようにハマるのが、インストール後にChromeなどの他のアプリがウィンドウキャプチャの対象として認識されていないということ。
今日、M1 MacBook AirにOBS Studioを導入したときにも同じ要因で少し時間を消費してしまったので、解決した際の対応方法をここに書き残しておこうと思う。
まずウィンドウキャプチャの対象としてChromeなどのアプリが認識されていない問題についてだが、下記のキャプチャの 空の名前でウィンドウを表示 というチェックボックスをクリックすると、私の場合はChromeなどのアプリが認識されるようになった。
(恐ろしくあっけないことではあるが、実際これだけで出てきてしまったのである...。アプリ上のバグのような気がするので、少し経てば解消されているかもしれない)
キャプチャのとおりにチェックをすると、Chromeなどが表示されるので、試しにChromeを選択すると、下記のようなキャプチャが出てくる。
後はいつもどおり、OBSを許可してやれば良い。
(ちなみに上の手順を踏まずに、直接下記のプライバシー画面を開いてみても、最初ここにOBSの項目は出ていなかった。このこともあり、余計に混乱した)
もし同じような内容で困っている方は参考にしてみてください。
Chromeのハードウェア アクセラレーションを無効化することについて
ちなみに、この手の問題で検索するとよく目についていたのが Chromeのハードウェア アクセラレーションを無効化 する方法だが、これは現在は特に行わなくとも問題なくChromeの画面を録画できるようになっている。
当時はできなかったが今は解決しているということかもしれない。
私自身、実際にアクセラレーションは無効化しないで画面録画が行えていることを確認している。
GitHub Actionsのdocsに出てくる $default-branch という記述について
今更ながらGitHub Actionsを使い始めることにした。
まずは小さめのプロジェクトに導入してみようと思い、最近作成した img2amp-img という、imgタグをamp-imgタグに変換するnpmツールのリポジトリにGitHub Actionsを設定してみることにした。
これはNode.jsのツールのため、下記のドキュメントを読みながら .yml ファイルを作成していたが、そのときに $default-branch という記述が出てきて、これはなんだろう？と思ったのが、このポストを書くことになったきっかけである。
Node.js のビルドとテスト - GitHub Docs
最初、GitHub上の Default branch を参照する変数的なものかと思ったが、そのままpushしても、CIは動いていないようだった。
これは間違っていそうだ...と思い、少し調べてみると、下記の記述を見つけた。
どうやら、これはworkflow template用の記述であり、実際にworkflowを記載するときには利用しない記述のようだ。
$default-branch で記述していた箇所を下記のように修正して、再度 push することで、すぐにGitHub ActionsのCIが動き出すのを確認した。
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -2,9 +2,9 @@ name: Test on: push: - branches: [ $default-branch ] + branches: [ main ] pull_request: - branches: [ $default-branch ] + branches: [ main ]
以上、ちょっとした備忘録でした。
Habanero BeeがVersion 0.1.0になりました。
少し前にこちらにも書いたHabanero Bee。
オープンソースにしたからにはある程度早めに、誰でも使えるところまで持っていかねばと思い、最近はこちらの開発を頑張っていました。
機能実装とドキュメントを整理し、とりあえずベータ的な形で誰でも使えそうというところまで持っていけたと思うので、本日version番号を0.1.0にあげました。
GitHub内のREADMEも整理したので、どんなツールなのか興味を持っていただけた方はぜひ覗いてみていただけると幸いです。
ちなみにここでも軽く説明しておくと、 Habanero Beeとは、Google スプレッドシートを使って簡単にコンテンツを作成できるAMP対応のシンプルなCMSシステムです(もしくは静的サイトジェネレーターです)。
- 時間をかけずにAMP対応のサイトが作りたい方
- コンテンツの管理をGoogle スプレッドシートを使ってサクッと管理していきたい方
- 毎月のサーバー代をかけずに自身のサイトを持ちたい方 (Habanero BeeはNetlifyにデプロイすることを前提に設計されています。無料プランで収まる範囲のアクセスであれば、毎月のサイト運営費を無料にすることが可能です)
などなど、これらのことに該当する方はHabanero Beeがマッチするかもしれません。
デモ用のデータを使用して実際にNetlifyへのデプロイを行ってみる、という内容の解説動画も作成していますので、もし興味ある方はご覧になってみてください。
大雨、雷、休日
大雨。娘と一緒にダラダラ部屋で過ごす。久しぶりに休日っぽい感じ。 娘と意味もないようなことを言い合って笑い合ったりゴロゴロしたり、そういう時間はリフレッシュになると改めて実感。 雷が鳴って雷に対する恐怖心を一瞬思い出したが、落ちるわけないとタカを括った。高校生の頃200メートルさきに雷が落ちた時の光景を思い出した。火花が散っていたし、何より音が大きすぎて驚く。大音量は人間にとって恐怖なのだと実感した瞬間だった。 昔、なにかの昔話で雷を恐れる人間が描かれているのを見たことがあるが、現代においても怖いわ。 娘がやがて遊び疲れて眠ると、なんとなく目についた他人の呟き以上ブログ未満的な文章を読み漁る。Googleに勤めているエンジニアの方のブログで、飾らなすぎる言葉の羅列が目に心地よい。今求めているのはこういう文章だと気づいたので、ダラダラと読んでいたら1時間ほど消費した。これが意味のある消費かと問われれば首を横に振るが、意味のある消費ばかりを自分は求めがちなので、これでいいのだ、とバカボンのお父さんみたいに突き進むことにした。
【Gatsby の SEO対策】Gatsby + Netlifyで運用しているサイトで意図しない301リダイレクトがかかっていたので対応した話
先日、Gatsbyで作成してNetlifyで運用しているサイトで不要なリダイレクトが発生していることに気づき、対応をしていた。
(Google Search Consoleでリダイレクトありと出ていた)
ただ、コードを見ていてもリダイレクトがかかっている箇所なんて存在しないし、なぜだろう？と悩んでいたときにこのIssueを見つけた。
私のケースもここで書かれているのと同様で、末尾にスラッシュがない URL を指定すると、末尾にスラッシュがあるページに 301 リダイレクトされるというものだった。
なお、この問題についてはローカルの開発環境上では起こらず、Netlify上でしか発生しない。
そのため、最初はなぜリダイレクトが発生しているのかが分からなかった。
もし同様の問題で悩んでいる方がいれば(かつ、Netfliyを利用している方は)、本番環境で末尾に / なしのURLを打ち込んで確認してみてほしい。
上のissueではなぜNetlify上ではそのような挙動になるのか、色々と議論されているので、興味ある人は目を通しておいたほうが良さそうだ。
また、このケースとは別にURLに大文字が入っていると、全て小文字のURLにリダイレクトされるという事象も同時に発生していたので、併せて対応までの流れを備忘録がてら書いていこうと思う。
また、少し前に下記のような投稿をした。これとも少しは関係しているかもしれない。
末尾に/(スラッシュ)をつけないとページアクセス時に301のリダイレクトがかかる
まずは末尾にスラッシュがない URL を指定すると、末尾にスラッシュがあるページに 301 リダイレクトされるという件についての対応について。
これは単純に末尾にスラッシュを付けるように対応した。
(生成されるリンクURLに対する対応)
また、現在の状態だとスラッシュありとなしで２種類のURLが生成されていることになるため、canonicalを追加し、末尾にスラッシュありのURLの方を指定するようにした。
これで今後どれぐらいSEOに影響があるかは観察してみようと思う。大きな変化があればまたこちらに書くかもしれない。
GatsbyJSにおけるcanonicalの設定方法
なお、Gatsbyではcanonicalを設定するためのpluginがあるため、今回そちらをインストールして設定を行った。
設定方法についてはREADMEを見ればわかるレベルなので、割愛する。
そもそも末尾に/をつけないURLで運用したい
私は結局末尾に / をつける運用に切り替えて対応したが、もし末尾に / つけないで対応していく場合はNetlifyのUI上で設定をイジる必要がある。
上に貼ったissue内のこのコメントが参考になりそうなので、URLを貼っておく。
(私も機会があれば、今度はこの方法で対応を試してみたいところ)
URLに大文字が使用されているとページアクセス時に301のリダイレクトがかかる
これも対応方法としては簡単、かつ地味である。
単純にURLに使用される文字列を小文字に変換して対応するようにした。
というわけで、まあわざわざここに書く必要もないぐらいに地味な内容となったが、原因がわかるまでは気持ちが悪かったし、一応備忘録としてここに残しておく。
追記：その後のSEOへの影響
上記対応を行ってから3日ぐらいで、今までは表示されていなかったページもGoogle 検索結果にポツリポツリ出てくるようになった模様。
(Google Search Console上でのデータから判断した他、自身でも試しに検索をかけてみて、以前よりも表示される頻度が上がっているように感じた)
今回の対応の成果によるものかは完全には言い切れないところだが、すくなくとも悪くはなっていないように感じた。
Google Driveの言語設定を英語に変える方法 (Googleサービス内での言語設定の切り替え方に関する備忘録)
需要があるのかは不明だが、備忘録として残しておく。
Google Driveの言語設定を変えるにはGoogle Driveを開いた上で、画面右上にある歯車マークから設定を開く必要がある。
上のキャプチャのところから設定画面を起動し、言語設定を変更 というボタンを押すことでGoogle Drive内の言語を変更することが可能。
ちなみにここで言語を変更した場合、GmailやCalendarの画面の言語も変わっていたことから、Googleサービス内での言語を変える際はここから変えれば良いらしい。
ここらへんの言語切替のやり方が、ぱっとわかりにくかったので、一応メモとして残しておく。
もしかしたらもっとかんたんなやり方もあるかもしれないが...
