手っ取り早くsitemapを作成する(npmが使える環境にて)
私はNext.js環境で実施したが、npm or yarn が使える環境であれば、特に環境には左右されないかと思う。
使用するのはsitemapというnpmパッケージ。
yarn add -D sitemap
sitemapに記載したいURLのリストを用意する。
vim listofurls.txt
※サイトマップは末尾にスラッシュ (/) を含める必要があるので、注意する
https://example.com/ https://example.com/about/ https://example.com/contact/
URLのリストを作成したら、下記のコマンドを実施することでURLに対応したXMLが吐き出される。
yarn -s run sitemap < listofurls.txt
実際に sitemap.xml というファイルに作成するときは下記のようなコマンドになる。
yarn -s run sitemap < listofurls.txt > sitemap.xml
自分の場合はNext.js環境でこちらを行ったので、下記のようなnpm commandを作成した。 本当はもっとプログラマブルに行えるようにすべきだが、まあ、とりあえずサイトマップ作りたかった、というレベルなので、一旦これで対応。
"scripts": { ・ ・ "sitemap:gen": "sitemap < listofurls.txt > public/sitemap.xml" },
ちなみに、上のやり方で作成されるsitemapは最低限の記述なので、適宜足したほうが良いかも。 詳細は公式のsitempaを見るのが良い。
あとはgoogle search consoleでサイトマップを送信して正常に認識されていることを確認。
BUMP OF CHICKENの藤くん結婚、ecmcorsというnpmパッケージについて
BUMP OF CHICKENの藤くん結婚について
朝起きてコードを書いていたとき、ちょっと集中力が切れてTwitterを開いたら、トレンドに 藤くん結婚 というキーワードが踊っていた。
もしや...！と思って調べたら下記のとおりである。
(なぜか公式サイトの詳細ページが開かなかったので、音楽情報サイトの記事も一緒に載せています。話題になっているからサイトが不安定だったりするのか？)
BUMP OF CHICKEN official website
https://www.musicvoice.jp/news/202008240160947/
私自身、別にBUMP OF CHICKENと直接何かしらのつながりがあるわけではないが、学生時代からずっと聴いていたバンドということもあってか、「そうか、結婚したんだなー」とまるで昔からの友人の結婚報告を聞いたときのような感慨深さがこみ上げてきた。
というわけで、わざわざこうしてブログに書き残すことにした次第である。
今、BUMP OF CHICKENのプレイリストを聴きながらこのブログを書いている。
今流れているのは supernove だ。
自分が生きていることの意味についてこんなにも考えさせられるなんて、、、というのがこの曲を初めて聴いたときの感想だった。
当時、自転車で近所のレンタルCDショップに行って、発売されたばかりのこの曲のシングルを借りたのだ。
家に帰って、CDプレーヤーで早速聴いたら、なんだか不思議な気持ちになった。
曲を聴いてテンションが上がるとか、感動させられるか、とかそういうのとは違う、自分の生きている意味、について急に考え込んでしまった。
当時の自分は大半の思春期を過ごしている人間がそうであったように、少なからずいくつかの問題を抱えていた。
この曲を聴いていると、それらの問題について考え、自分という人間について考え、自分が生きる人生の意味について考え込んでしまった。割と真剣に。
何かしら答えが見つかったのか、もう今の自分には思い出せないが、そういうこともあり、この曲"も"自分の中では、大きな意味を持つ曲となっている。
そんな曲がBUMP OF CHICKENにはたくさんある。
好きなバンドについて書き出すと時間をかけてしまいそうだ。ここらへんで筆を置こう。
なんだか、朝から勝手に嬉しくなってしまうニュースでした。
ecmcorsというnpmパッケージを作った
一昨日にも書いたが、ecmcors というnpmパッケージを公開した。
ただただコーヒーを淹れる動画、それだけなのに、癒やされる。(山でコーヒーを淹れる動画をいくつかピックアップ) - at backyard
個人開発をしている中で、自分用のAPIサーバがいくつか動いている。
Node.js製のAPIサーバはexpressを使って書くことが多いが、CORS の設定をより楽ちんにに行いたい、という思いからこのツールを書いた。
ざっくり説明すると、すでにあるnpmの cors というパッケージのラッパーツールである。
やれることは少ないが、考えることも少ない、そんな発想で作っている。
細かく設定したい人は cors を使うほうが良いと思います。
ちなみに ecmcors で設定する際は、CORS_ALLOW_LIST という環境変数に、許可するドメインを設定して使うようにする。
# 複数指定可能 CORS_ALLOW_LIST=http://example.com,http://example.net
実際に実装する際は下記のようになる
const express = require('express'); const ecmcors = require('ecmcors'); const app = express(); // Only authorized origin will be allowed to pass. app.get('/', ecmcors, (req, res) => { res.status(200); }); const PORT = process.env.PORT || 3000; app.listen(PORT, () => console.log(`listening on ${PORT}`));
ただただコーヒーを淹れる動画、それだけなのに、癒やされる。(山でコーヒーを淹れる動画をいくつかピックアップ)
朝を振り返る日記パート
今日も早めに起きてコードを書いていた。不吉なことに起床時刻が 4:44 だった。
朝起きて気づいたのは、昨晩アイスコーヒーを淹れるのを忘れていた、という痛恨のミス。
とりあえず余っていたアイスコーヒーを注いで、ちびちびと楽しみながらコードを書き出す。
朝のうちに、最近npmに公開したecmcorsのテストケースを追加する。
( ecmcors はcorsの設定を簡単に設定できるようにしたexpressのmiddlewareです。個人開発するときに自分自身がかなり使っており、今回npm package化して公開した形になります。これはまた別のタイミングで紹介させていただけたらと)
テストコードを書き終えて、次に metatag-gen で追加できるテンプレートとしてJSXを追加する。
コード自体は昨日書き終えていたが、PRをマージするところまで出来なかったので、今朝コードを確認してマージ、そのままリリースまで終える。
その後、現在作成中のWebアプリの作成。
Next.jsを用いて開発しているが、昨日も書いたが開発体験がなかなか良い。
機能追加と、パフォーマンス上での問題点の対応などをしたあたりで集中力が切れてきたので、Twitterで以前リツイートしていた、この動画を見返していた。
山頂でコーヒーを淹れる様子が癒されるpic.twitter.com/u5eZhrhQTy
— 最多情報局 (@tyomateee) August 18, 2020
山でコーヒーを淹れている動画まとめ
(ちなみにこんな感じでコーヒーが注がれている光景も、個人的に癒やしポイント高い)
この動画を見返していて、自然の中でコーヒーを淹れるだけの動画って良いなと思ったので、ちょっと探してみた。
見つけたそれっぽい動画をここにひたすら貼っていく。
ただ、探すの意外と大変で疲れたので4つしか貼れていない。
ではでは、文章はこれにて。
最後のは山ではなく、森でした。
react-notificationsをNext.jsから使う場合の備忘録
今日Next.jsでアプリを書いていたときに出会ったことをメモする。
といっても、Next.jsはエラーメッセージが親切なので、メモを残さなくとも、対処方法がわかりやすくエラーログに出てくる。
こういうのは本当に素晴らしいなと思う。
エラーの原因を探ってアタフタしているだけで開発効率は落ちるもの。
そういう時間を極力少なくしてくれるように設計されている印象。
まさにデベロッパーフレンドリーといった感じ。
react-notificationsをNext.jsから使う場合に必要になる下記の記述は、pages/〇〇.js 内には直接かけない。
import 'react-notifications/lib/notifications.css';
その場合は pages/_app.js を作成して、下記のように読み込む必要があるようだった。
import 'react-notifications/lib/notifications.css'; export default function MyApp({ Component, pageProps }) { return <Component {...pageProps} />; }
先にも書いたようにNext.jsはここらへんの解決方法の提示がすごく親切で分かりやすい。 下記のドキュメントを参考にした。
Basic Features: Built-in CSS Support | Next.js
なお、react-notificationsについては、以前こちらのブログにも導入記事を書いているので、興味ある方は一読いただけると嬉しいです。
Reactでnotificationを簡単に実装できるreact-notificationsを試してみた - at backyard
今日から、お家フジロック
話は全然変わりますが、今日からFuji Rockですね。
FUJI ROCK FESTIVAL '20｜フジロックフェスティバル '20 -> リアルタイムではないけども、メンツ豪華すぎの絶対楽しめる内容🤩 https://t.co/8EOddvbIVs
— Yuki Shindo (@shinshin86) August 19, 2020
ランダムな音楽アルバムの情報を取得するGo製のCLIツールを書いた
ちょいとツイッターで脳内を垂れ流してしまった。
Spotifyで生計立てるのは「夢のまた夢」 データから見える収入格差の実態 #SmartNews https://t.co/rbjH9b6ET2
— Yuki Shindo (@shinshin86) August 18, 2020
ここに書いたとおりだが、とにかく音楽で稼いで生きていくというのはなかなかハードルが高い。
しかも世間はそれほど貪欲に未知の音楽を求めているわけでもないので、ゴリゴリに宣伝するとウザいだけで終わってさらに救いもなくなる。
ここらへんの状況を打開していくのに、まだ明確な答えは出ていないが、 上のツイートでもちょっと触れたけど、まったくもって稼げていない大多数の音楽が何らかの形で世間の需要とマッチングできれば、そこには新たな市場が開ける気もする。
引き続き考えていく必要がありそうだ。
こんなことを書きながら、自分自身も興味がない音楽に対しては正直聴く気にならない。
正直聴く気にはならないが、なんの脈絡もなく今まで聴いたことのない音楽を体験してみる、というのはどういう体験だろうかと思い、DiscogsのAPIを用いて、ランダムな音楽アルバム情報を取得するGo製のCLIツールを書いた。
Goでの勉強も兼ねているが、まあ、とりあえずコーディングの合間に使ってみて、新しい音楽と出会ってみようかと考えている。
個人開発者の味方、関連キーワードツール（仮名・β版）が終了して、ラッコキーワードになっていた。
個人開発でWebサービスを作る上で、キーワード選定は勿論重要になる。 そんなキーワード選定・調査を行う際に役に立っていた、 関連キーワードツール（仮名・β版） がいつの間にか終了して、 ラッコキーワード として再スタートを切っていた。
中を見ていただくと、デザインも一新されているのが分かる。
また検索したキーワードの結果をCSVとしてダウンロードすることも可能になっており、キーワードの分析などに対する敷居も下がっているように感じる。
その他にも細かな使用感に改善が図られていたりと、色々と変わっているので、なにかしらのWebサービスを立ち上げたい個人開発者の方で(もちろん法人もしかり)、もしまだ触ったことなかった方がいれば、ぜひぜひ触ってみるとよいかと思います。無料で使えます。
ちなみにメールアドレスを登録しない場合、１日20回までしか使えないようになっていた。
ラッコID（メールアドレスのみ30秒登録）にご登録いただくことで無制限でご利用いただけます。 非ログインユーザーの場合は、 1日あたり20キーワードまでに制限させていただいております。（0時リセット） 高負荷対策となりますため、ご理解いただけましたら幸いでございます。
メールアドレスの登録だけで無料なことに変わりはなさそうだ。
無料にも関わらず、とても役立つツールなので、今後もお世話になる予定。マジ感謝。
ちなみにこちらのサービス、個人の方が運営されているのかと思っていたが、どうやら下記の会社が運営されていたようだ。
余談: マナブ氏のSEO対策の動画講義
ちなみにこのツールを知ったのは、たまたまSEOのことを調べたくて検索で見つけた下記の動画だったと記憶している。
この動画、めちゃめちゃ説明がわかりやすいし、中身も充実していて、この方すごいなー！と思っていたら、いつのまにかインフルエンサー的なポジションになっていた。
(もしかしたら当時からインフルエンサー的なポジションだったのかも)
SEO周りは定期的にアップデートが入るので、いまもここに書いてあることがどれほど有効かは、ウブな自分にはなんともいえないところだが、SEOのことよく分からんけど、多少なりともなんとなく分かっておきたい、という方は一度目を通しても良いかも。個人的にはおすすめです。
Mediumに投稿しても全然アクセスが集まらなかったことについて考えてみる
先日Mediumに一つ記事を英語で投稿した。
少し前にメタタグを生成するためのCLIツールをGoで書いたのだが、それに関する投稿だ。
で、このMediumの記事だが、今日現在Statsを見てみると、４回しか見られていない。
(うち３回は自分でアクセスしている気がするので、たぶん、一人にしか見られていない)
これはちょっと落胆した。というのも、例えばこのはてなブログにしても、Qiitaにしても何かしら書いて投稿すれば当日中に数十アクセスは行くからだ。
勿論、私の知名度の無さ、またMediumでそもそも大して投稿はしていないので、アクセスが集まらないのは当然だ。
だが、それでも新着フィードにのったりして、どこかの馬の骨かわからないやつのポストでも一応開いたりはしてくれるのだろうと思った。5アクセスぐらいはいくのではないかと思っていたのだが、、、
実際、Qiitaの場合、アカウント開設して何かしらの投稿をしても10ぐらいはいきなりアクセスがあった気がする。 Qiitaユーザは別のQiitaユーザの投稿もよく見るし、tagなどから該当する投稿にたどりついたりするなど、ユーザが循環する仕組みが良くできていると思う。 Mediumの場合、たぶん同じくMedium内でユーザが循環していくような仕組みがあまりないのかと思った。
というか、それほどMediumではそのような使い方が想定されていないのかもしれないと思った。
Medium – Where good ideas find you.
上に貼ったのはMediumのトップページだが、そもそもトップページからMediumで書かれた投稿へのリンクがない。
The most insightful stories about Go - Medium
こちらはタグのページ。
Mediumは投稿にタグを付けられるが、こちらから確認できるタグに紐づく投稿の数はそれほど多くない。また、2ページ目にいくためのページネーションもない。
どこかの記事でMediumは書くことに集中できるよう、また読むことに集中できるようなデザインにしている、という文章を読んだことがある。おそらくはサイト内で交流を育むというよりは、書いたものを公開する場所として、ある種独立した場所だけを提供しているような感じなのかもしれない。
Mediumに書いた、というよりは、場所は関係なく、書いた、そして書いた場所としてMediumを使っていた、的な。
(ただ、もしそういうコンセプトなら、ブラウザから開いた時に執拗にアプリから開くことを促さないで欲しいとは思うが。あれはなかなか気が散って体験としてあまり良くない気がする)
と、ここまで書いておきながら、ただ単に自分の知名度の問題でアクセスが集まらなかっただけなら、それはそれで事実を受け止めよう。。。
