「GitHub」の記事 - Crieit

海外進出を目指して、ProductHuntへ個人開発サービスを投稿するまでにやったこと&やった結果を全面的にシェアする

2021-09-30T07:19:35+09:00

初めて作った個人開発サービスで海外進出しようという無謀な挑戦

以下の記事の通り、9月頭に2goというサービスを作って公開しました。サービスの詳細は以下のURLから見てもらえればと思いますが、いくつかの理由から世界での公開を元から視野に入れていました。
https://crieit.net/posts/Github-Issues-2go

英語圏のユーザーも含めたほうがサービスの規模感が大きくなる
サービス内容が日本だけに留まらない共通の需要があると思った
どこかで挑戦しなくてはならないのなら、ここで挑戦しようと思った（無謀）

こういった背景があり、全てのインターフェースは英語で作ってきました。そして、MVPが9月に完成したので、日本でのアナウンスをしました。海外を意識していたので、日本での進め方はあくまでフィードバックを貰えればくらいに思っていましたが、今思えばここからが既に問題なんだなと考えられます。

私の経験をまとめましたので、自分への戒めと今後トライされる方の参考になれば。

日本でやったことと、その結果

日本でリリースしたときにやったことを書いていきます。

Twitterでの開発進捗の共有による露出

私のTwitterアカウントはコチラですが、元々は現在働いている会社のAwarenessを上げるために、自分自身の考えやnoteなどの記事を共有するために使っていたものでした。そのため、インフラやクラウドなどのトピックが中心のため、100強のフォロワーもそういった傾向がありました。ただし、インフラやクラウドもこれからはアプリケーションレイヤーがわかっていないと語れないなと思い、個人開発をすることで開発者の気持ちを理解していこうとしている途中でした。
https://twitter.com/jnakajima1982

Twitterでの取り組み内容

そのため、絶対数としてこういったアプリレイヤーに興味がある人が少ないということもあり、開発進捗を共有したとしても反応がほぼもらえないという状況が続きました。そこで、私は以下を取り組みました。
1. 「#個人開発」や「#今日の積み上げ」といったハッシュタグを使った投稿を増やした
2. 上記ハッシュタグにまつわる個人開発者を中心にフォローを増やした
3. 自分自身で話題を作るより、フォローしている人のTweetに引用RTするようにした
　

結果と考察

「#個人開発」に関しては普段よりはインプレッションが増えましたが、反応が劇的に増えた感じはしませんでした。これには2つの原因があると考えています。「どんなサービスかわかりにくかった（プロフィールもわかりにくかった）」のと、「作っているサービスが英語」だったため、ハードルが高かったのだと思っています。それでも少しずつフォロワーは増え、最終的には今回の取り組みで50フォロワーくらい増えたので、コツコツやっていくことが重要で、指数関数的に上がることになるのではないかなと思っていますので、継続が必要です。

ただし、私のアカウントが公共分野（デジタル庁など）のインフラ・クラウドと、個人開発が混ざっているので、アカウントを分けるべきか非常に迷っています。フォロワー0から作り直すリスクと、複数アカウントを運用することの大変さに応えられるのかに解がないため、一旦は1つのアカウントとしています。

また、「#今日の積み上げ」は、インプレッションが非常に増え、リアクションも同時に増えるのですが、フォロワーが増えません。これは個人開発に留まらないユーザーが大量に流入しているせいだと思いますが、どちらかと言うとお互いに励まし合おうというハッシュタグの位置づけになっていると思われるので、このような結果になっているのだと思います。自分自身の精神安定の観点で、たまに投稿して安心するくらいが丁度いいと思っています。

3については、私自身が有益なことをTweetすることができればいいのですが、いざTwitterの画面を開いてなにか書こうと思ったときに、思いつくことには限界があったんですよね。特に、何がウケるのかみたいなことを考えだしたのもいけなかったんだと思います。なので、フォローしている人は私が興味があってフォローしているわけで、その人が話題にしていることに対して引用RTすることにして、自分の意見を言っていこうと考えました。

これは意外と効果があります。Twitter上での表示のされ方も、元Tweetが強ければ同時に表示されることもあります。また、何より引用RTした相手からのコメントを頂ける確率も高く、それがインプレッションの増加に繋がる結果が多かったと思います。

反省と今後

いずれにしても、Twitterでの認知度向上は一朝一夕ではいきませんので継続した活動が必要ということが身に沁みました。後ほど触れますが、ProductHuntなどは、このようなフォロワーの数が少ない開発者を掘り出して世に出すためのサービスという大前提があるのですが、現実問題として規模の戦いは存在すると実感しましたので、Twitter等のSNSでコミュニティを形成する必要を感じさせられました。

特に英語圏での情報発信を考えると、英語用Twitterアカウントを作ったのですが、日本語用Twitterアカウントだけでも苦労しているのに、英語で書いて運用していくというのはとても大変なことです。そのため、英語用Twitterアカウントはほとんど活動ができていません。

運営者ギルドへの参加

Twitterを徘徊していると、運営者ギルドという存在を知りました。まさに私が陥っているような状況が冒頭に書かれていました。
https://qiita.com/organizations/admin-guild

作ったWebサービス、全然使われない……
どうやってマネタイズしよう
どこまで作り込んでからリリースすればいいんだろう
デザイン難しすぎ
利用規約はどうすれば？
この先どうやってサービスを伸ばしていけばいいのか……
Slackでの運営形態になっており、中の活動が全く見えなかったので、入れていただくかを非常に悩んだのですが、何事もチャレンジだと思ったので、連絡させて頂き、無事入らせて頂きました。

結果と考察

結果から言うと、個人開発をしている人は入ったほうが良いです。下手な質問をしたら、ぶっ飛ばされるのではないかとビクビクしていましたが、そんな事は全くありませんでした。唯一あるとするならば、自分自身で発信したことには多くの意見がもらえてモチベーションに繋がりますが、自分自身で発信しない方はここで何をしていいかわからなくなってしまうと思います。

私は、実運用ではどのようにしているかなどは、こういった限定されたユーザーだけが参加するコミュニティだからこそ聞ける生の声が本当に貴重だと思いました。また、今回のProductHuntのチャレンジなどを好意的に捉えてくださるだけでなく、普段の自分自身の開発の進捗にコメントいただける方もいらっしゃり、個人開発の課題となりがちなモチベーション維持にもなりました。

だからこそ、私自身がコミュニティの一部として、他の方が同様な状況にいる場合には、積極的に自分の経験を還元する必要があると思い、いろいろな方のチャンネルに入るようにしました。

技術コミュニティメディアへのサービス開発記事の投稿

Twitterや運営者ギルド以外では、とにかくサービスを知ってもらえるチャネルを増やそうとしていました。そこで以下の技術コミュニティメディアに記事を投稿してみました。
- Zenn：https://zenn.dev/nice2have/articles/aa15eccd13a23c
- Qiita：https://qiita.com/nice2have/items/28449ae4ef45fef2c671
- Crieit： https://crieit.net/posts/Github-Issues-2go
- ツクログ：https://creators.eightbit.jp/service/item4309.html

以下にそれぞれのメディアの現時点での結果をまとめます（Google Analytics調べ）。Zennは正直きちんと取れているのかわかりません。ツクログは投稿して間もないのと、どこからデータが取れるのかわからずなので、外しています。

メディア	記事閲覧数	サービス流入数	LGTM
Zenn	34	10	4
Qiita	1468	261	7
Crieit	1198	66	1

結果と考察

いずれにせよ、どのメディアにも投稿することは確実に認知度とサービス流入に繋がっていると言えますので、サービスローンチのタイミングだけでなく、書く内容がある限り、投稿し続けると良いと思います、、、が、やっぱり書くのって大変なんですよね。さらに、メディアによってトレンドがあるから、書く内容を変えたほうがよいというのを見たのですが、全く同じ記事を上げているのが現状です。まずは続けることが大事なので、しばらくはそれを継続しようと思っています。

ダイレクトアプローチ

追加でした作業についても記録しておきます。2goというサービスの特性上、Github Issueを利用している/利用見込みのユーザーがターゲットになります。そのため、メディア上にGithub Issueについて記事を書いている人へ直接連絡して実際に利用していただくことで、フィードバックを受けて改善に生かしていこうと思いました。

Google検索からたどり着いた5件にコメントをしてコミュニケーションを図ってみたのですが、どこからも未だ返事がない状況です。Twitter上でキーワード検索してアプローチしたこともありましたが、ちょっと利用用途が異なったようで、試してもらうまでに至りませんでした。

以上のアプローチで、面白いですとか、良いサービスですねなど言われるものの、今思えば、やはり利用されるだけの魅力やユースケースが見出してもらえなかったのだと思いました。

まとめ：日本での取り組み

海外進出を前提に置いていたため、以下の2点の理由で、Githubアカウントでログインしてまで試してくれた人は、2桁にすら行きませんでした。
- 日本での取り組みを正直本気で取り組んだとは言えない
- 英語のインターフェースのため、伝わりづらかった

そこで、Githubアカウントでログインすることのハードルが高いと思い、ログイン不要で誰にでも触れるサンプルを追加開発して提供してみたのですが、こちらも時たま試す人が現れるくらいで、試すことすらしてもらえないのかと打ちひしがれましたorz

ほとんどのユーザーアクティビティ（サービス登録/ログイン/公開設定）が発生すると、Slackに通知が飛んでくるようにしていたのですが、たまにしか飛んでこず、こちらも現時点では自分のログイン動作だけが通知される閑古鳥が鳴いている状態です。

海外編：Product Hunt

つらつらと書いてきましたが、これからが本編です。当時、海外進出しか見えていなかった私は、海外での認知度を上げるための方策を調査していました。調べていくと以下の2つのサービスがマッチすると思いました。

Product Hunt : https://www.producthunt.com/
Indie Hackers : https://www.indiehackers.com/

これらのサービスでは、個人開発者やスタートアップが自分の作ったプロダクトを投稿して、認知度を上げることが毎日のように行われています。ただ、Indie Hackersの方は招待制でしか入れず、Redditなどを徘徊してもInvitation Codeを求める人はいるものの、なかなか何もない状態でそれがもらえる人は見られなかったので、一旦Product Huntにフォーカスすることに決めました。

Product Huntへの投稿を決心

まずは経験者のまとめを読み漁りました。具体的には以下の記事を読みました。この中でも、本当に有効だったこと、今では有効ではないこと、役に立たないことがあるので、それを自分なりに整理していきました。とにかくやれることはやりきらないと、次につながらないと思い計画していきました。

https://crieit.net/posts/7
https://jp.taishikato.com/posts/i-want-to-prove-that-japanese-can-compete-in-english-speaking-countries
https://blog.notsobad.jp/entry/2019/12/23/232807
https://blog.notsobad.jp/entry/bungo-search-product-hunt

Product Hunt攻略計画

先述の記事を読んで私が立てた当日の計画は以下のとおりです。
1. 太平洋時間 0:01（日本時間 16:01）からその日のランキングレース開始。
2. 1時間くらい様子をみて、Google や Facebook からのプロダクトなどのビッグサービスが投稿されていないのを確認してから投稿。
3. Twitter で Product Hunt への投稿を英語でアナウンス。 @ProductHuntをメンションする。
4. Product Hunt 上の紹介ページ URL が取得できるので、それを基に Product Hunt Card 作成（Medium の場合は URL を貼り付けるだけで OK）し、Medium 投稿。
5. ProductHunt の URL を使って Landing Page に反映し、導線を作る。
6. Medium の記事を、Product Hunt 上のプロダクト紹介ページに関連記事として貼り付け。
7. Medium の記事を、Hacker News に投稿（Show HN:をタイトルにつけて投稿）
8. Reddit に投稿
9. コメントが入ったらそれに返信していく。

また、投稿当日までの計画は以下のとおりです。
1. 投稿用のランディングページを作る
2. 投稿用の動画（英語）を作る
3. Medium/HackersNews/Redditの記事を準備する
4. Product Huntのupcoming Productに登録する
5. Product Hunt投稿内容の準備をする
6. 最低限必要な機能の整備（退会機能・規約）
7. 著名なProduct HuntersにReview Requestをして、認知してもらう

簡単に言ってしまうと、以下の2点に集約されます。すごくシンプルです。
- ProductHuntの投稿を魅力的なものにする
- ProductHuntのupvoteを得るための導線をできるだけ多く作る

投稿当日までの準備と結果

順番は前後しますが、投稿当日までの計画について共有します。

ランディングページ

ランディングページはたいして手間もかからなかったのですが、当日投稿しなければ、貼るURLがわからないため、ボタンだけ作ってVueの機能で表示しない状態で準備しておきました。実際のトップページの見えるところにボタンを置いた程度でした。はっきり言ってダサいですね。

改めて投稿後にいろいろ研究してみましたが、以下のような形で誘導するのはとても有効だと感じました。後にわかりますが、こんなレベルの問題ではないことがわかります。

投稿用の動画

ProductHuntの投稿にYoutube動画を付けると、Product紹介の一番最初に表示され、自動的に再生される仕組みになっています。そのため、インパクトがあると思ったのと、これをやらねばやらなかったときの効果が今後わからなくなると思い、動画制作に手を付け始めました。しかしながら、以下の問題にぶつかります。

動画編集に知見がない
動画ナレーションは英語の必要性がある

動画編集に知見がないので、いろいろ調べたところ、ダビンチリゾルブという動画編集ソフトが良さそうで試してみたところ、操作が全くわからず、説明記事をウロウロしていたのですが、わからなすぎて挫折しそうになっていました。ところが、原点に戻って動画のことは動画で、と思ってYoutubeの解説動画を探しました。

そして以下の動画を10分で見たら、一気に進み、こんな私でも動画編集ができるようになりました。基本操作と、動画編集に最低限必要そうな動画を紹介しておきます。

https://youtu.be/duxtN8ixpLo
https://www.youtube.com/watch?v=0J7lqAnP_64&t=194s

ただ、計画もなしに動画編集するとうまく行かなったので、Figmaで整理してみました。ただし、これで一旦動画を作ったのですが、文字だらけでなかなか理解しにくいものになってしまいました。

ここあら紆余曲折があって、ようやく完成した最終版はコチラです。
https://youtu.be/YvcyiAccCBo

先にナレーションの英文を考えて、Google Text to Speechに喋らせて、それに合わせて映像を作成するという手順を踏みました。しかしながら、結果的に動画以前の問題であることも発覚します。

Medium/HackersNews/Redditの記事を準備する

ここから導線となる記事の準備についてお話しいたします。

Medium
https://medium.com/@nice2have/2go-road-to-my-first-webservice-5b38666a7dd8

- 特に制限もないので、自由に書きましたが、タグについては迷いましたね。サービスの特性上、割り当てるべき適切なタグかどれか未だにわかっていません。
- しかしながら現時点でもView数は2です。そのため、こちらもMediumのフォロワーを増やしておくか、単なるプロダクト説明の置き場と割り切るかのどちらかが今後の戦略となりそうです。

HackersNews

- Show HNを付けるというルールを守って投稿
- 付けるURLはMediumのページか、サービス自体のURLかは迷いましたが、サービスにProductHuntへの誘導を用意していたので、後者を選択しました。
- しかし残念ながら、GoogleAnalytics上は、HackersNewsからの流入は０でしたので、もう少し工夫が必要か、流れるのが早すぎて流入が期待できないかもしれません。

Reddit
https://www.reddit.com/r/ProductHunters/comments/px15lq/i_created_my_first_web_site_2go_2go_can_generate/

- Karmaというポイントがないと記事が投稿できないという話を見たので、事前に記事投稿やコメントで参加してみました。特にGithub Issueの必要性などを投稿したりして、反応を窺うなどもトライしましたが、慣れていないせいもあって反応も薄かったです。
- どのSubredditに投稿するかは検討しました。ProductHunt / Github / webdev / SaaS / startups / indieHackers / indieDevelopers等、色々調査しました。ProductHuntのSubredditが最も適切かと思いましたが、あまり活況がないのが心配でした。ただ、それ以外のところでは厳しい反応も予想されたので、シンプルにProductHuntのSubredditを投稿先と決定しました。
- その他細かいことですが、RedditのProfileなどもきちんと整備しました。
- しかしながら、RedditのSpamFilterに引っかかって削除されてしまったみたいです…

Product Huntのupcoming Product

あまり認知されていませんが、以下のようにサービスローンチ前にユーザーとコミュニケーションができるPre-Postサイトを作ることが出来ます。ただここからSubsriberは1人も登録されませんでした。おそらくProductHuntの著名なユーザーが、次期サービスを立ち上げる前にユーザーとコミュニケーションするためのプラットフォームだと感じましたので、私には当分必要ないと思いました。
https://www.producthunt.com/upcoming/2go

Product Hunt投稿内容の準備をする

Product Huntの投稿ページは入力したものが記録されるようになっているので、Submitボタンの直前までを入力しておいて事前に準備しておくことが可能です。今回の画像は、動画作成時に作っていたFigmaデータを画像データに変換して利用することとしました。特に動画は視覚的に、画像は落ち着いて読むように文字を入れるようにしました。

ここで用意しにくいのは、投稿ロゴとして利用できるGIFファイルだと思います。動画や画像イメージは比較的簡単に用意できますが、GIFファイルはどんなものにするところから微妙に悩ましい位置づけです。私は今回動画ファイルを作って出力した後、MovファイルからGIFに変換して利用しました。

目立たせるために、アニメーションというよりは、全体の色が大きく変わることで目につくように意識して作りました。

著名なProduct HuntersにReview Request

先程の記事の中には著名なProductHunterにお願いして、彼らに周知してProductHuntで彼らをフォローしているユーザーに通知されるようにしたほうが良いという記述がありました。一方で、その機能はなくなったのでやる必要ないよというのも見受けられました。ということは、やってみるしかありません。まずは以下のサイトからTop Huntersを探しました。

https://yvoschaap.com/producthunt/

それぞれがどういった方なのかまで抑えられなかったので、上から順番にTwitterを見て、直接DMを送れる人にていねいな英文を書いて送りました。…が、結果的に1人からも返信は返ってきませんでした。おそらく、こういった依頼が定常的に来るので、そもそもDMを開いていない可能性が高いです。既読にすらなりませんでしたので。

では、このアプローチは不要なんでしょうか。その答えは、私のProductHuntの通知ページにありました。以下のようにフォローしているHunterがUpvoteすると、その通知がフォロワーには届きます。つまり、TopHuntersにUpvoteされると知られる確率が高くなるという理解をしています。ただ、彼らからUpvoteされるためにどうしたらよいかは未だにわかりません。Twitterでフォローされるわけもないので、ProductHuntでDiscussionに参加するなどして自分自身の露出が必要なのかもしれません。

その他に可能性があるとすると、以下は検討してみてもよいかと思いました。開発者のクローズドなコミュニティがあり、そこで繋がりが作れるかもしれません。なぜなら、$2,000/yearの有料会員制だからです。だからこそ、人数が爆発的に多いわけでもないですし、コミュニケーションが活発なのかもしれません。ただし、個人開発者がここに投資するのは、英語とお金が必要なので、ハードルが高いとは思います。

https://megamaker.co/club/

投稿当日の結果

改めて、投稿当日の計画を振り返る前に、投稿曜日を検討していました。最初は準備ができた翌日に投稿しようかと思っていましたが、ちょうど週末でした。週末がどう影響するかがわからず、Active User数が減少するのではないかと推測して候補から外しました。また、週明けの月曜日も同様の理由で除外し、現地時間火曜日0時に投稿することとしました。

太平洋時間 0:01（日本時間 16:01）からその日のランキングレース開始。
1時間くらい様子をみて、Google や Facebook からのプロダクトなどのビッグサービスが投稿されていないのを確認してから投稿。
Twitter で Product Hunt への投稿を英語でアナウンス。 @ProductHuntをメンションする。
Product Hunt 上の紹介ページ URL が取得できるので、それを基に Product Hunt Card 作成（Medium の場合は URL を貼り付けるだけで OK）し、Medium 投稿。
ProductHunt の URL を使って Landing Page に反映し、導線を作る。
Medium の記事を、Product Hunt 上のプロダクト紹介ページに関連記事として貼り付け。
Medium の記事を、Hacker News に投稿（Show HN:をタイトルにつけて投稿）
Reddit に投稿
コメントが入ったらそれに返信していく

まず、予約投稿機能があるので、試してみましたが、正常に動作しませんでした。もしかすると私の現地時間の入力時間が間違っているかもしれませんが、念の為日本時間16時にはPCの前にいたほうがいいかもしれません。

投稿後の動きの感想

現地時間0時のタイミングでは、少しでもUpvoteを稼いだProductが上位に行きやすいです。そのため、初速を確保する知り合いやコミュニティへの事前声掛けは重要だと思いました（ただし、Upvoteを直接的に促してはいけません）
必要初速Upvoteは10くらいだと思います。トップページに表示できるProductにも限りがあり、そこに載れなければ閲覧数も獲得できないです。
必ずUpvote順にソートされるわけではありませんでした。コメントなどの他の要素も見ていると思われます。コメントはUpvote同様に初速に影響する可能性があるので、できれば事前に確保しておきたいところです。ただし、日本人のコミュニティにおいて、Upvoteはしてくれても、コメントまでしてくれる人を確保するのは至難の業だと思います。
コメントがないと盛り上がりに欠けるのか、追加のコメントが得られにくいと思います。私はただの1つもコメントを最後まで得られませんでした。他のProductは、共同開発者などがコメントし合うことで盛り上がりを演出している印象を受けました。
コメントが来たら返信しながら、投稿スレッドを盛り上げる準備をして待っていましたが、杞憂に終わってしまいました。

結果と感想

最終的な結果はUpvote x15となりました。結果をまとめていきます。
- Upvote x15(しかし、運営者ギルドから半数くらいはUpvoteしてくれた方がいたと思います)
- 流入トラフィック x5(ほとんど流入が見込めませんでした)
- 新規登録ユーザー数 x0(残念ながら一人も使ってくれませんでした)
- サンプルを試したユーザー数 x2(流入トラフィックの割に確率が高かった)

重要なのは…

とにかく初速Upvoteを増やして、トップページに載らないと何も始まらない
流入さえしてくれれば試してもらえる率はそこそこある
投稿内容（文章・動画・画像）の良し悪しが影響するのかはわからなかった
導線はほとんど影響しなかった（影響するように仕立て上げるには継続的な活動が必要）
TopHuntersに認知される方法があれば、Upvoteを得るための近道になるかも。

ProductHuntへの挑戦は惨敗

多くの方にご協力を頂きましたが、残念ながら私の個人開発サービスのProductHunt挑戦は惨敗に終わったと言って良いでしょう。ただし、考えうる限りのことはやり切ったので、次に繋がる敗戦だと考えています。

海外進出のサービスの難しさを以下の点で痛感しています。
- 海外でウケるサービスとかユースケースが、真の意味で理解できない可能性
- 海外で求められるデザインやマーケティング・言い回しが適切かどうかわからない
- 海外でのコミュニティ参加は更に負荷がかかるため、労力に見合うかが不安
- 番外編）ユーザーに提供する規約の英文精査が難しい

英語で開発すれば、非常に多くのユーザーに対する市場へのアプローチが可能ですが、このような深刻な悩みがついてまわることになります。いくつかの記事にもありましたが、英語圏の感覚を持つ人にヘルプしてもらわないと難しいかもしれません。

最後に…

想像してよりもずっとずっと個人開発は難しいです。プログラミングの世界だけでなく、デザイン・マーケティングまで1人で取り組まなければならず、かつアイデアの捻出とその中からの選定も全部自分の責任です。だからこそ楽しみがあるわけですが、大変さも同時に存在しています。

企業よりも個人開発が気楽な分、企業よりもマーケティングや作業分担にお金がかけられません。特に個人開発はサービスが知られることがなければ、提供するユースケースが知られていないから失敗しているのか、知られていても失敗しているのか判断が難しくなります。

そこでやはり重要となってくるのが、コミュニティだと思います。自分の作るプロダクトに意見を言ってくれる、試してみてくれる、拡散して届けてくれる人たちとともに歩まねば成功はあり得ません。そしてそれは継続的な努力によってのみ得られるものだと感じました。

私にとって今回の開発は本当に作りたいものに対する準備の意味合いも兼ねていますが、コミュニティとともにモチベーションを維持し、成功の模索をしていきたいと思います。

ということで、ぜひ気になる方はTwitterのフォローと、2goの利用をしてみて、フィードバックをいただければと思いますので、最後にリンクを貼って終わりにさせていただきます。

https://twitter.com/jnakajima1982
https://2go.plus/

ありがとうございました！

Github Issuesをキレイに外部公開するサービス「2go」作ってみた

2021-09-10T06:00:03+09:00

はじめに

今回初めて個人開発で作ったサービスを公開します。今までも何回かトライしていたのですが、なかなか公開までに至らないうちに、なにか問題にぶちあたったり、時間がかかりすぎて情熱が冷めてしまったりしていたので、今回はまずはスモールスタートで公開して改善していくことを心がけました。大体今回の公開まで、開発を始めてから1ヶ月程度になります。毎日朝4時半に起きて、子どもたちが起きる7時過ぎまでを開発時間として取り組んできました。

どんな人向け？

自分で作っているサービスの開発ロードマップをユーザーに公開するために、都度ブログを書いたりするのも大変ですよね。もし、自分のサービスのソースコードをGithubで管理していたとして、Github Issuesを見せるとしてもGithubに馴染みのない人にとっては読みにくいですし、外に出すサービスであればあるほど、Githubのレポジトリは非公開になっていると思います。これをなんとかできないかなと思いました。

どんなサービス？

まずはこちらを見てください。
https://2go.plus/nice2h/2go/roadmap
このようにGithubのレポジトリ内のIssueをMilestone区切りにして、Githubに馴染みのない人にも見やすいロードマップサイトを公開するサービスです。もちろん、非公開のレポジトリを公開設定にすることなく、ロードマップだけを外部公開することができます。

Githubアカウントでログインすると、以下の設定画面になります。レポジトリを選択して、どのMilestoneを共有するかをチェックして保存します。すると、自動的にロードマップサイトのURLが生成されるので、こちらにアクセスすれば常に最新のロードマップを見ることができます。このURLをシェアすれば、多くの人にあなたのサービスのロードマップを簡単にキレイに公開できるわけです。

Milestoneを今まで使っていな方は、Milestoneを作成して、Issueを割り当てればロードマップを整理することができます。また、Labelを活用している方もいらっしゃると思いますので、Milestoneの中のLabelでIssueをフィルタすることもできます。これらを駆使することで、Bugは見せずにenhancementだけ表示するなどのことも可能です。
今後の予定としては、今はMilestone基点で表示しているところを、Labelベースで表示できるようにもしたいと思っています。その他は、まさに上記のURLを参考にしていただければ、いつも最新です。

どんな技術を使ってる?

企業での開発経験はないので、全て自己流です。書籍やWebサイトを中心に勉強して開発しながら学んできました。念の為、利用している技術は以下のとおりです。
- Laravel : APIとBlade（SSRはやってみたことあり）
- Vue3 : フロントエンド（今回初挑戦）
- Tailwindcss : デザイン（Bootstrapからの脱却）
- Docker : これらの開発環境と、本番でもDocker利用（いずれ分割予定）
- Cloud : Conoha VPS(インフラに時間を掛けたくなかった)

気になっていること（随時追加予定）

開発環境はLaravel sailを使いましたが、本番は自前でdocker-compose.ymlを使いました。このあたりのコンテナの構成をどのようにしているか気になりました（本番でもsail使う？）
本番環境にコードをpullしてからnpm run prodしてbuildが終わるまでにラグがあり、この間は使えない機能が出てしまったりするが、このあたりをみなさんはどのように工夫しているか？
DBについては、どこまでレコードを暗号化するか。検索機能などとのトレードオフになると思われるが。。

今後は？

現在alphaフェーズですが、alphaとしてもう1段階リリースの予定があります。多くの人に使っていただき、Feedbackをいただきながら改善して、開発経験を増していきたいと思います。また、今回の個人開発は最初から海外も同様の問題を抱えていると思ったので、最初から英語圏も視野に入っており、今の所すべてのUIは英語にしています。以下の英語Twitterアカウントも作成して、情報発信していこうと思っています。

https://twitter.com/2go_plus

もちろん、日本語のTwitterは私の今まで通りのアカウントを利用していく予定です。
https://twitter.com/jnakajima1982
ぜひご感想・ご指摘をいただければと思います。

GitHub ActionsでJestを叩くときのタイムゾーンと言語を設定する

2021-08-30T17:14:25+09:00

GitHub リポジトリにプッシュした時、GitHub Actions のワークフローで自動的に Jest を走らせるようにしています。GitHub 上で自動的に走る Jest と、手動で直接叩く Jest との違いはタイムゾーンとロケールです。ここでは、GitHub 上で Jest を動かすときに環境変数としてタイムゾーンとロケールを指定する方法について説明します。

1. package.json にグローバル設定ファイルを指定する

以下のように設定を追記します。jest-global-setup.jsに設定を記載すれば、環境変数から読み込まれた値を上書きできます。

  "jest": {
    "globalSetup": "./jest-global-setup.js"
  },

2. jest-global-setup.js の中身を記載する

タイムゾーンと言語を指定します。

module.exports = async () => {
  process.env.TZ = "Asia/Tokyo";
  process.env.LANG = "en_US.UTF-8";
};

3. 動作結果を確認する

Jest のテストで出力される日時の文字列を確認したところ、言語が日本語から英語になっていることが確認できました。

    -     "date": "Wed Apr 01 2020 09:00:00 GMT+0900 (日本標準時)",
    +     "date": "Wed Apr 01 2020 09:00:00 GMT+0900 (Japan Standard Time)",

GitHubのパスワード認証が通らなかった話

2021-07-28T18:50:16+09:00

約1週間前まではGitHubのパスワード認証が使えていたのに、
今日突然使えなくなっていたのでメモ。

発生した問題

GitHubにソースをpushしようとしたが、エラー(403)が出て失敗した。
以下のようなメッセージが出ていた。

remote: Password authentication is temporarily disabled as part of a brownout. Please use a personal access token instead.
remote: Please see https://github.blog/2020-07-30-token-authentication-requirements-for-api-and-git-operations/ for more information.

解決方法

Creating a personal access token に書かれている手順でPersonal Access Tokenを作成する
Terminalにて、以下のコマンドを実行する：
git config --global --add user.password 取得したトークン
Keychain AccessにてGitHubの情報を探し、パスワード欄を取得したトークンで置き換える

この記事の通りだった↓
GitHubの認証方法の新しいビッグウェーブに乗り遅れるな！

備考

トークンの有効期限が切れたら、また上記手順を行う必要がある
約1週間前に、GitHubからこんなメールが届いていた。気付かなかった・・・

Hi (ユーザ名),

You recently used a password to access the repository at (リポジトリ名) with git using git/2.0 (libgit2 0.26.0).

Basic authentication using a password to Git is deprecated and will soon no longer work. Visit https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information around suggested workarounds and removal dates.

Thanks,
The GitHub Team

Github で特定ユーザの publicリポジトリの名前の一覧を生成する Docker Compose

2021-07-11T01:08:30+09:00

経緯

自分のあるリポジトリを clone しようとして、名前を失念。探すのに手間取ったのでリポジトリの名前の一覧を生成するスクリプトが欲しくなりました。

調査

調べたら Linuxコマンドでどうにかなりそうだったので、 Docker で Linux環境を用意してごにょごにょしよう、と思い立ちました。

成果物

GitHub - arm-band/docker_list_of_hirokawa: Github の特定ユーザの public リポジトリの一覧を生成する Docker Compose 設定集。

構成

ディレクトリ構造

PROJECT_ROOT/
    ├ docker/
    │   └ Dockerfile
    │
    ├ entrypoint/
    │   └ entrypoint.sh
    │
    ├ template/
    │   └ script.sh       // コンテナ内で実行したいスクリプトのテンプレート。一部変数をエントリポイントで置換
    │
    ├ workspace/          // リポジトリ名一覧のテキストファイルのダンプ先
    │
    ├ .env                // docker-compose.yml 用の環境変数
    └ docker-compose.yml

今回はこんなディレクトリ構造に。

docker-compose.yml

version: '3.8'
services:
    hirokawa:
        build:
            context: ./docker
            dockerfile: Dockerfile
            args:
                USER_NAME: $USER_NAME
                FILE_NAME: $FILE_NAME
        volumes:
            # entrypoint
            - ./entrypoint:/entrypoint
            # workspace
            - ./workspace:/workspace
            # docker settings template
            - ./template:/template
        tty: true
        entrypoint: /bin/sh -c "/bin/sh /entrypoint/entrypoint.sh $USER_NAME $FILE_NAME && /bin/sh"

リポジトリ名の一覧を取得したい対象ユーザ名とダンプ先ファイル名を .env で指定しています。

.env

USER_NAME=saigyo
FILE_NAME=repository_list.txt

上述の通り。

docker/Dockerfile

FROM alpine:latest
RUN apk update && \
    apk upgrade && \
    apk add --no-cache \
    jq \
    bash \
    sed \
    curl
RUN mkdir /var/script
RUN chmod 777 /var/script

必要なパッケージのインストールとスクリプトの生成先のディレクトリの作成。

今回はやることが最小限なので alpine を使用。

entrypoint/entrypoint.sh

sed -e "s/USER_NAME/${1}/gi" -e "s/FILE_NAME/${2}/gi" /template/script.sh > /var/script/script.sh

一部変数名を .env の値で置換。一行しかないので command でも良かったかも。

template/script.sh

for page in $(seq 1 10);
    do result=$(curl -s "https://api.github.com/users/USER_NAME/repos?page=$page&per_page=100"|jq -c '[.[] .name]'|jq -c '.[]');
    if [ -z "$result" ];
        then break;
    fi;
    formatted_result=$(echo "$result"|sed -e "s/\"//gi");
    echo "$formatted_result" > "/workspace/FILE_NAME";
done

実行するスクリプトのテンプレート。個人ユーザ対象で curl で Github API を叩いて100個(指定可能な最大数)ずつ出力、 jq でフィルタリングして、 workspace にファイルとしてダンプ。

これでやりたいことは実現できました。

参考

サンプル

jq

jq play

alpine で bash

【docker alpine linux】でbashの使用方法 - Qiita

starting container process caused: exec: "bash": executable file not found in $PATH: unknown

プログラマーの雑記: docker コンテナにログイン時に、「executable file not found in $PATH」エラーの対応

alpineイメージへの entrypoint 指定

【Docker】ENTRYPOINT と CMD の仕組みと小技 – 株式会社シーポイントラボ｜浜松のシステム・RTK-GNSS開発

Github Actions のバッジを付ける (＋バッジに Github Actions ページへのリンクを付与するChrome拡張機能を作成)

2021-01-06T23:45:20+09:00

前回記事の続き。 Github Actions で PHPUnit が走ることが確認できたところで、今度は「そういえば Github Actions のバッジはあるのだろうか？」と気になって調べてみました。

バッジの所在

バッジについては Github Actions のページにありました。

リポジトリの対象アクション ( https://github.com///actions? ) に遷移
上のハンバーガー( … ) からメニューを開く
Create status badge をクリック

以上の手順で発行できます。

メニュー展開時。

ダイアログ表示。

バッジを readme.md に貼り付けてみました。

バッジのリンクを変更する Chrome拡張機能

ところで、

GitHub Actionsのバッジをリンク付きでREADMEに追加する - Qiita

こちらの記事で「デフォルトのバッジ画像の Markdownコードは画像のみとなっていて対象の Github Actions へのリンクにはなっていないのが不便」とありました。確かに……。

上記の記事では UserScript で該当の Markdownコードを書き換える方法を紹介していましたが、個人的には Chrome拡張機能で充分な気がしたのでざっくり自前で作ってみました。

リポジトリ

arm-band/chrome_extensions_cambadge

manifest.json

{
    "manifest_version": 2,
    "name": "cambadge",
    "description": "Github Actions のバッジのURLを変更する拡張機能です。",
    "version": "0.0.1",
    "browser_action": {
        "default_icon": {
            "19": "icon_19.png",
            "38": "icon_38.png"
        },
        "default_title": "cambadge"
    },
    "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",
    "content_scripts": [
        {
            "matches": [
                "https://github.com/*"
            ],
            "js": [
                "main.js"
            ]
        }
    ]
}

main.js

/**
 * cambadgeCampaign: rewrite markdown code in textarea
 *
 * @param {object} DOMBadgeMd
 */
const cambadgeCampaign = (DOMBadgeMd) => {
    if (/^\!\[(.*)\]\((.*)\)$/gi.test(DOMBadgeMd.textContent)) {
        DOMBadgeMd.textContent = `[${DOMBadgeMd.textContent}](${location.href})`;
    }
};

window.addEventListener('load', (e) => {
    // triggered load
    if (/https:\/\/github\.com\/(.*)actions(.*)/gi.test(location.href)) {
        // only github actions page
        const clickItem = document.querySelector('summary[data-test-selector="badge-builder-button"]');
        clickItem.addEventListener('click', (ev) => {
            // triggered click of element:summary[data-test-selector="badge-builder-button"]
            let setIntervalId;
            let DOMBadgeMd;
            function findTargetElement () {
                // watch until find element:#badge-markdown
                DOMBadgeMd = document.querySelector('#badge-markdown');
                if (DOMBadgeMd !== null && DOMBadgeMd !== undefined) {
                    // found
                    clearInterval(setIntervalId);

                    // call function
                    cambadgeCampaign(DOMBadgeMd);
                }
            };
            setIntervalId = setInterval(findTargetElement, 100);
        });
    }
});

ダイアログ中の #badge-markdown を含むバッジ生成の要素は Create status badge をクリックした際に生成されるようなので、 Create status badge をクリックした後、 #badge-markdown が見付かるまで書き換えの処理を待つようにしました。

Chrome拡張機能で書き換えられたダイアログ。これで該当の Github Actions ページへのリンクに繋がるようになりました。

参考

バッジ

バッジのリンクを変更する

GitHub Actionsのバッジをリンク付きでREADMEに追加する - Qiita

UserScript

UserScriptで業務改善

Github Actions で PHPUnit を走らせる

2021-01-05T22:38:21+09:00

Github Actions で ESLint や Stylelint 、あるいはデプロイのワークフローは走らせたことがありますが、 Jest も行けるはず……と思い至ったところで、ふとそういえば PHPUnit はどうでしょうか、と思い実験。

検証

検索すると、

これらの記事がヒットしました。そこで、この記事を参考に .github/workflows/test.yml として作成。

.github/workflows/test.yml

name: PHPUnit test

on: [push]

jobs:
  test:
    name: Test

    runs-on: ubuntu-latest

    strategy:
      matrix:
        php-version: ['7.4']

    steps:
    - name: Setup PHP ${{ matrix.php-version }}
      uses: shivammathur/setup-php@v2
      with:
        php-version: ${{ matrix.php-version }}
        extension-csv: mbstring, xdebug, dom

    - name: Add Plugin
      run: sudo apt install -y php7.4-xml

    - name: Checkout
      uses: actions/checkout@v2

    - name: Check PHP Version
      run: php -v

    - name: Check Composer Version
      run: composer -V

    - name: Check PHP Extensions
      run: php -m

    - name: Validate composer.json and composer.lock
      run: composer validate

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress --no-suggest

    - name: Run test suite
      run: composer run-script test

試しに Github に push してみます。

走りました。

先人の知恵があればこそですが、 workflows の yml ファイルがあれば PHPUnit のテストも可能ということが分かりました。

参考

Github Actions で PHPUnit

composer

Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

2020-12-10T00:55:08+09:00

はじめに

Zenn や Qiita, note など様々なウェブサービスで記事を書くにつれて、ふと雑多な内容で自分の好き勝手に記事を書いて公開できる自分のブログが欲しくなりました。そこで、自分のブログを作ろうと思い調査したところ、SSG で作るのが手っ取り早そうだったのと、その中でも一番ラクにウェブサイトが構築できそうな Hugo を採用しました。

また、デプロイは簡単に行いたかったので、デプロイ先として GitHub Pages を採用しました。
独自ドメインの割り当てから HTTPS 対応まで無料でできるかつ、使い慣れている GitHub をデプロイ先に使えることが決め手でした。

Hugo で自分のブログを構築して GitHub Pages で公開できるようになったのですが、ブログ内容を更新したり記事を書くたびにビルドしてデプロイをするのが、意外と面倒なことに気づきました。そこで、GitHub Pages action を用いて、ビルドしてデプロイするという作業は自動化しました。

上記までの作業をすることで、自分のブログを書いたり更新することだけに集中できる環境を整えることができました。ウェブサイトを作りこむ以外は、簡単ないくつかの作業をするだけで Hugo で満足のいく自分のブログを書く環境が整えられたので、その手順についてまとめてみました。

ちなみに本記事の手順で実際に作成した私のブログは下記です。
https://nikaera.com/

Hugo を PC にインストールする

私は Windows には Chocolatey、Mac では Homebrew で Hugo をインストールしました。Chocolatey や Homebrew を利用したインストール方法については公式サイトの手順で公開されています。

# Mac で Homebrew を使って Hugo をインストールする
brew install hugo

# Windows で Chocolatey を使って Hugo をインストールする
choco install hugo -confirm

# Sass/SCSS を用いてウェブサイトのデザイン改修を行いたい場合は
# 下記で Chocolatey を使って Hugo をインストールする
choco install hugo-extended -confirm

Hugo で自分のウェブサイトを構築する

Hugo プロジェクトを作成する

下記コマンドで Hugo のプロジェクトフォルダを生成できます。

hugo new site <プロジェクトフォルダのパス>

Hugo のコンフィグファイルのデフォルトフォーマットは TOML 形式なのですが、hugo new site <プロジェクトフォルダへのパス> -f json のように -f オプションを付与することで JSON フォーマットでもコンフィグファイルを生成可能です。

後述しますが、一部の Hugo のテーマはコンフィグファイルのサンプルが JSON ファイルで書かれています。その場合は、新規で設定するコンフィグファイルのフォーマットも JSON で統一しておくと各種設定項目の調整が楽になりそうです。

もしくはこちらのようなコンバーターを使用したり、こちらのようなウェブのコンバーターを使用して、設定ファイルを JSON から TOML フォーマットに変更しても良さそうです。

ウェブサイトのテーマを探す

テーマとは、ウェブサイトのデザインテンプレートのことです。テーマは Hugo Themes で公開されているので、この中から自分の好みを選びます。Hugo ではテーマの内容をカスタマイズしたり差し替えることもできるので、あとから一部デザインを自分好みに修正できます。

Hugo Themes にアクセスした時のページ

お気に入りのテーマが見つかったら、Download ボタンをクリックしてテーマの GitHub URL を控えておきます。

Kiera というテーマのページ

Hugo プロジェクトにテーマを適用する

テーマの適用方法については公式サイトの手順で紹介されていますが、Hugo のプロジェクトフォルダのルートで下記コマンドを実行して、コンフィグファイルに theme を追記するだけです。

git clone <テーマの GitHub URL> themes/<テーマ名> --depth=1
echo 'theme = "<テーマ名>"' >> config.toml

どのテーマも基本的に適用方法は同じで、例えば私が採用したテーマである PaperMod を適用する場合は下記コマンドを実行することになります。

git clone https://github.com/adityatelange/hugo-PaperMod themes/hugo-PaperMod --depth=1
echo 'theme = "hugo-PaperMod"' >> config.toml

これで自分のウェブサイトを作り込んでいくための準備が整いました。

ウェブサイトを作り込む

各テーマには exampleSite というウェブサイト作成の参考になる Hugo のプロジェクトフォルダが存在します。 最初は exampleSite フォルダ内に存在する各種ファイルを自分のプロジェクトにコピー&ペーストして、改変しながらウェブサイトを作り込んでいくとスムーズに作業が進められます。

exampleSite フォルダは大抵 GitHub プロジェクトのルートに存在しているのですが、GitHub のブランチで管理しているものもあります。 私の採用した PaperMod は GitHub の exampleSite ブランチで管理していました。

上記のような詳細は Hugo のテーマページに記載があるはずなので、事前に exampleSite フォルダが配置されている場所や設定可能な項目等をチェックしておくことをオススメします。実際のウェブサイトの見た目を確認するには、Hugo のプロジェクトフォルダのルートで下記コマンドを実行します。

hugo server

hugo server 実行中に、ウェブサイトの設定を変更したり記事を追加すると、自動的にビルドが実行されるので常に最新のウェブサイトの見た目を確認できます。また、その際にエラーもコンソールに出力されるので、適宜修正しながらウェブサイトの作成を進めていくことが可能です。

GitHub にデプロイ環境を整える

ウェブサイトの構築が出来ればあとはデプロイするだけです。今回は GitHub Actions でデプロイするため、残りの作業は GitHub 上で進めていきます。一応 GitHub Actions を使わずに手動でデプロイする手順については、Hugo の公式サイトの手順にて紹介されています。

GitHub Actions を用いてデプロイできるようにした際の利点としては下記があります。

デプロイ時に毎回手動で複数コマンド実行する手間が省ける
自動化することでデプロイ時のコマンドミスを防ぐことが可能
常に統一した Hugo のビルド環境が利用可能

最初のうちは私も公式サイトの手順通りに Mac で手動デプロイしていました。しかし、Windows 環境でデプロイ作業した際、本番環境デプロイ時に SRI 関連のエラーが発生してしまい、ウェブサイトに stylesheet が適用されないバグが発生してしまいました。

結局原因はよく分からなかったのですが、GitHub Actions 経由でデプロイするようにしたところ直りました。CI 経由でデプロイできるようになると、こういった実行環境の違いによる挙動も気にする必要が無くなります。

一応 Windows 環境で発生した SRI 関連のバグは Hugo で該当するテンプレートファイルを layouts フォルダを利用して差し替えて、integrity の設定内容を空にすることで、本番環境でも stylesheet が適用できるようになったことは確認しました。詳細はこちら。

自分のウェブサイトをデプロイするためのリポジトリを作成する

GitHub の公式サイトの手順に従って、自身のウェブサイトをデプロイするためのリポジトリを作成します。また本記事では、Hugo プロジェクトのリポジトリはデプロイ用リポジトリとは別で扱うため、Hugo プロジェクトのリポジトリも新たに作成します。

本記事では Hugo プロジェクトのリポジトリ名は hugo-blog という名前に設定した前提で進めていきます。また作成したリモートリポジトリの情報は、下記コマンドで Hugo プロジェクトに登録しておきます。

# Hugo プロジェクトフォルダのルートで Git リポジトリを作成する
git init

# Hugo プロジェクトのリポジトリ情報を登録しておく (hugo-blog の GitHub URL)
git remote add origin

GitHub Actions で Hugo のビルドからデプロイまでを自動化するための環境を整える

今回は hugo-blog という Hugo プロジェクトのリポジトリから、デプロイ用リポジトリへデプロイしたいため、まずはデプロイ用リポジトリでデプロイキーを登録します。公式サイトの手順に従いデプロイキーを登録したら、秘密鍵を hugo-blog リポジトリのシークレットに登録します。

シークレットは公式サイトの手順に従って登録します。今回は秘密鍵をシークレットに登録する際の名前に ACTIONS_DEPLOY_KEY を設定した前提で進めていきます。

次に GitHub Pages action を導入して Hugo のビルドから公開までを自動化する環境をセットアップします。

hugo-blog リポジトリに GitHub Pages action の Getting started を参考にワークフローファイルを追加します。- name: Deploy の項目のみデプロイ用リポジトリへデプロイするために設定内容を変更します。

# .github/workflows/gh-pages.yml
name: github pages

on:
  push:
    branches:
      - main  # Set a branch name to trigger deployment

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: '0.78.2'

      - name: Build
        run: hugo --minify

    #   - name: Deploy
    #     uses: peaceiris/actions-gh-pages@v3
    #     with:
    #       github_token: ${{ secrets.GITHUB_TOKEN }}
    #       publish_dir: ./public
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          external_repository: nikaera/nikaera.github.io
          publish_branch: main
          cname: nikaera.com

- name: Deploy の項目で設定した各種パラメータは下記になります。

キー	説明
deploy_key	デプロイ時に使用する秘密鍵
external_repository	デプロイ先のリモートリポジトリ
publish_branch	デプロイ先のリモートリポジトリのブランチ
cname	設定するカスタムドメイン名

deploy_key にはシークレットに登録した秘密鍵を設定します。external_repository には Hugo をビルドした際のデプロイ先リポジトリを <ユーザ名>/<リポジトリ名> のフォーマットで指定します。publish_branch はデプロイ先として使用するブランチ名になります。cname には自分が設定したいドメイン名を指定します。cname の詳細はこちらからご確認いただけます。

カスタムドメインで設定した内容で DNS 設定を書き換える

GitHub Pages にカスタムドメインを利用する際は、該当するドメインの DNS レコードの設定で CNAME レコードもしくは A レコードを設定する必要があります。公式サイトの手順に従って設定します。

また、カスタムドメインの設定後は特別な理由がない限りは、デプロイ用リポジトリで HTTPS 強制の設定をしておくことオススメします。

ちなみに GitHub Pages で利用している証明書は Let's Encrypt のものになります。

設定作業はこれで完了です。あとは実際に Hugo プロジェクトを更新後、hugo-blog リポジトリに push することでビルドからデプロイまで GitHub Actions で行われるようになったかを確認していきます。

Hugo プロジェクトの更新時に自動でデプロイが行われるか確認する

Hugo プロジェクトには既に hugo-blog リポジトリの GitHub URL が origin として設定されているはずなので、下記で実際に hugo-blog リポジトリへ push してみます。

# Hugo プロジェクトを hugo-blog リポジトリに push する
git add -A
git commit -m "initial commit"
git push origin main

次は実際に GitHub リポジトリの Actions タブから、GitHub Pages action のワークフローが実行されているか確認します。

GitHub Pages actions の実行に成功した様子

無事ワークフローの実行に成功したことを確認したら、デプロイ用リポジトリの様子を確認します。

デプロイ用リポジトリに Hugo の最新ビルドが push されていることを確認する

最新コミットのメッセージに deploy: <ユーザ名>/hugo-blog@<コミットハッシュ> のコメントが表示されているはずです。コメントのリンクをクリックすると、hugo-blog リポジトリの最新コミットの確認画面に遷移するはずです。

ここまで確認できれば、あとはローカルで hugo server して確認していたウェブサイトと同じように、GitHub Pages 上でもウェブサイトが見えるか実際に確認してみます。

デプロイ用リポジトリ名が <ユーザ名>/<ユーザ名>.github.io であった場合、https://<ユーザ名>.github.io でウェブサイトにアクセスできます。私の場合は https://nikaera.github.io になります。その際、カスタムドメインにリダイレクトすることも確認できれば、カスタムドメインの設定も正常に反映されています。

ページが正常に表示されていてカスタムドメインでアクセスできた様子

アクセス時に意図したページが表示されていることが確認できれば大丈夫です。これで自分のウェブサイトを更新したら hugo-blog リポジトリに Hugo プロジェクトを push するだけで自分のウェブサイトを自動更新できるようになりました。

おわりに

今回は Hugo を例にしましたが、本記事内で紹介した GitHub Pages action は様々な SSG に対応しています。そのため Hugo ではウェブサイトのカスタマイズに限界が来たなと感じたら Next.js や Gatsby に乗り換えるといったことも可能です。

また Hugo では何も考えずとも、マークダウンで記事が書けてビルドも高速なので、手っ取り早く自分のウェブサイトを構築してみたいという用途にはピッタリだと感じました。

関係ないですが、Hugo でウェブサイト構築する際の知見も記事に含めてしまったせいで、文章量が意図した倍近い量になってしまいました。。簡潔で分かりやすい文章が書けるようにならなきゃ。。

参考リンク

GitHubのデフォルトラベルを和訳 + 絵文字付加

2020-10-04T23:26:27+09:00

本記事は、 Qrunch からの移転記事です。

移転元: GitHubのデフォルトラベルを和訳 + 絵文字付加 - 雑木林

TL; DR

絵文字	原文	和訳
🐛	bug	不具合
📝	document	ドキュメント
🔙	duplicate	別チケット有
✨	enhancement	新機能など
🤝	good first issue	初心者歓迎
🆘	help wanted	助けて！
⛔	invalid	不適当な内容
❔	question	質問
❌	wontfix	意図的な中止

はじめに

GitHubのリポジトリを最初に作成すると、Issue／プルリクのラベルとして、下記が出現します。

これらの意味を知りたくなったので、調べてみます。
ついでに、該当しそうな絵文字を探して付けてみます。

各ラベルの説明と和訳と絵文字

以降、各ラベルについての説明と和訳、そして絵文字を付けてみます。

下記に参考ページを載せます。

About labels - GitHub Help

bug

特に言う必要は無いと思いますが、バグですね。
ただ、日本ではバグという言葉は強すぎるという意見もあるので、「不具合」の方がいいかもしれません。
絵文字は 🐛 でいいんじゃないですかね。

documentation

これは、比較的最近作られたラベルですかね？
上記画像のリポジトリは2年前くらいに作ったので、存在しないです。

純粋に、「ドキュメント」で良いと思います。
絵文字は 📝 にしましょう。

duplicate

これは、既存のIssueが既に立っていることを示します。
「別チケット有」なんてどうでしょうか？
絵文字は、ドンピシャなものが無かったのですが、 🔙 とします。

enhancement

新機能や要望のIssueでよく見かける気がします。
「新機能など」とすることで、機能追加以外についてもこのラベルで対応できるのではないでしょうか。
絵文字は、みんな大好き ✨ です。

good first issue

直訳では「最初のIssueに良い」ですかね。
実は「最初のコントリビューター向けのIssue」、という意味があるそうです。
意訳ですが、「初心者歓迎」なんてどうでしょうか？
絵文字は 🤝 なんていいですね。

OSS 貢献における GitHub の Issue 探しについて手始めに調べてみた - Qiita

help wanted

GitHubのヘルプページには「メンテナが課題やプルリクについて助けを求めていること」とあります。
ということで、意訳ですが「助けて！」としてみます。
最後のびっくりマークにより、声を大にして求めている感じを出しています。
絵文字は 🆘 がぴったりです。

invalid

文法エラーなどでもよく登場しますが、直訳では「無効な」という意味です。
Issueにラベル付けすることを考えると、「不適当な内容」としてみると良いかもしれません。
不適切とまでは言わないが、Issueに価値が無くなってしまったことを伝えたいです。
絵文字は悩みましたが、このラベルが付いたらクローズされそうなので、 ⛔ としてみました。

question

質問する際に使えますね。
和訳も「質問」で良いと思います。
絵文字は ❔ としてみます。
❓ もありますが、デフォルトラベルの背景色が赤紫っぽかったので、白色の方にしました。

wontfix

不具合はあるが未修正のままにするなどのように、あえて変更しないことを意味します。
「意図的な中止」とすることで、意図が伝わる気がします。
絵文字は ❌ がいいですかね。

おわりに

英語だととっつきづらいものも、日本語にすることで理解が進みますね。
絵文字文化ももっと広まることを願います。

Gitのコミットメッセージに絵文字付きプレフィックスを適用する

2020-10-04T23:25:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Gitのコミットメッセージに絵文字付きプレフィックスを適用する - 雑木林

TL; DR

コミットメッセージのプレフィックスは、Angularスタイルを基準としています。
また、各プレフィックスに絵文字を付ける際は、下記のようにしています。

プレフィックス	絵文字	絵文字の綴り
feat	✨	sparkles
fix	🐛	bug
docs	📝	memo
style	📁	file_folder
refactor	♻️	recycle
perf	⚡️	zap
test	✅	white_check_mark
chore	🍰	cake
init	🎉	tada
merge	🔀	twisted_rightwards_arrows
review	👌	ok_hand
wip	🚧	construction

はじめに

コミットメッセージにプレフィックスを付ける文化が、少しずつ広がっています。

一方、コミットメッセージに絵文字を付ける文化も、広まりつつあります。

両者を組合せれば、最強のプレフィックスが出来上がるのではないかと考えました。
ということで、絵文字付きプレフィックスという考え方を提案し、ここに記すこととします。

コミットメッセージにおける絵文字の付け方

コミットメッセージに、絵文字名を : で挟むことにより、GitHub上で表示できます。
また、コンソール上では、 emoji-cli などを利用することで、表示が可能です。

コマンドラインで emoji を扱う - Qiita

例えば、 ✨ (sparkles) という記号をコミットメッセージに書きたい場合、コミットメッセージを次のように記述します。

:sparkles: feat(ruby): やさしい日本語ページのルビタグ対応

すると、GitHub上のコミットメッセージとして登録されます。

covid19-miyazaki/covid19: 宮崎県(非公式) 新型コロナウイルス感染症対策サイト / Miyazaki COVID-19 Task Force website

コミットメッセージの1行目は、表示できる文字数に制限があるため、長すぎる絵文字名の絵文字は気をつけたほうがいいかもしれません。

git commit 時に書くコミットメッセージ1行目の表示文字数上限を調べてみた - Qiita

各プレフィックスと絵文字の紐付け

大前提として、プレフィックスを使う場合は、リポジトリ内で統一する必要があります。
これは、プレフィックスを使ったとしても、意味がわからなければ伝わらないからです。
同様に、多くの種類の絵文字を使うことも否定的です。
これからの時代は、プロジェクト毎に、コーディングスタイルと共にコミットメッセージスタイルも定義する必要があると思います。

今回は、Angularスタイルのプレフィックスを参考にします。
~~理由は、それ以外のスタイルを知らないからです。~~

angular.js/DEVELOPERS.md at master · angular/angular.js

また、絵文字については、Gitmojiを参考にします。
~~理由は、サイトが綺麗だからです。~~

gitmoji | An emoji guide for your commit messages

オリジナル絵文字を利用する場合は、GitHubで使える絵文字チートシートを参考にします。

🎁 Emoji cheat sheet for GitHub, Basecamp, Slack & more

以降、各プレフィックスの内容を説明し、それに見合った絵文字を紹介します。

feat

feat: A new feature

新機能を追加する際に利用します。

Gitmojiでは、同等の絵文字として ✨ (sparkles) を定義しています。
新機能を導入する際に使う絵文字です。

:sparkles: Introducing new features.

ということで、 feat には ✨ (sparkles) を利用します。

余談ですが、新機能というと、無かった機能を追加した際のみにも聞こえます。
僕の場合は、既存機能を変更する際や、既存機能を削除する際にも使っています。
変更／削除についても、変更することによって統一性が図れるとか、削除することによってUIが向上するとか、変更／削除そのものが機能追加という場合が多いなーと思っていたからです（いわゆる enhansement と同じ意味として捉えています。
これについては、プロジェクト毎に決めておくといいかもしれません。

fix

fix: A bug fix

不具合を修正する際に利用します。

Gitmojiでは、同等の絵文字として 🐛 (bug) を定義しています。
意味は全く同じです。

:bug: Fixing a bug.

ということで、 fix には 🐛 (bug) を利用します。

また余談ですが、個人的には、修正コミットに 🐛 を付けることは、若干抵抗があります。
GitHubでIssueファーストの開発をしていると、Issueでは不具合発見として 🐛 を付けて、修正プルリクとして 🐛 の絵文字を付けてしまいませんか？
🐛 という絵文字自体には2つの意味があるからです。

不具合発見時
不具合修正時

前者は 🐛 で問題ないのですが、後者については考える余地があるはずです。
もし虫網や虫籠の絵文字があれば、それを使っていたのですが......

コミット時に不具合を意図的に入れることは考えられない点と、不具合発見時をコミットメッセージで表すことが無い点、さらに不具合 == バグ == 🐛 を知らないエンジニアがほぼいない点を考慮して、 fix には 🐛 がいいかなと考えました。

docs

docs: Documentation only changes

ドキュメント類を修正する際に利用します。
修正と言っていますが、追加や削除時にも使ってよいと思います。

Gitmojiでは、同等の絵文字として 📝 (pencil) を定義しています。
ドキュメント類を記述する際に利用します。

:pencil: Writing docs.

また、 pencil と memo は、GitHubでは同じ絵文字として認識されます。

ちなみに、鉛筆だけの絵文字は pencil2 です。
~~これは酷い......~~

ということで、 pencil では文字ベースとして判断しづらい点から、 📝 (memo) を利用します。

style

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

ソースコードの可読性を変更する際に利用します。
Lintを適用した際や、空行を追加した際など、振舞いに変化を与えない変更が該当します。

Gitmojiでは、 🎨 (art) が当てはまるかもしれません。
🎨 は、ファイル構造を変更する際、または、ソースコードのフォーマットを変更する際に利用します。

:art: Improving structure / format of the code.

style という観点で言えば、2番目の意味に該当することは間違いありません。
また、1番目の意味も、ファイル構造の style という側面で見れば、該当すると見ることもできます。

しかし、 art という単語からは、UIに関連しそうなイメージが付きます。
実際、下記のようなIssueも上がっています。

🎨 for design and 📐 for structure · Issue #320 · carloscuesta/gitmoji

style という内容に合わせるため、ここでは 📁 (file_folder) を利用します。

📁 File Folder Emoji

refactor

refactor: A code change that neither fixes a bug nor adds a feature

ソースコードの可読性を向上する際に利用します。

Gitmojiには、同等の絵文字として ♻️ (recycle) を定義しています。
意味はほとんど同じです。

:recycle: Refactoring code.

ということで、 refactor には ♻️ (recycle) を利用します。

perf

perf: A code change that improves performance

パフォーマンスを向上する際に利用します。

Gitmojiには、同等の絵文字として ⚡️ (zap) を定義しています。
意味は全く同じです。

:zap: Improving performance.

ということで、 perf には ⚡️ (zap) を利用します。

test

test: Adding missing or correcting existing tests

テストコードを追加する際や、既存テストコードを修正する際に利用します。

Gitmojiには、同等の絵文字として ✅ (white_check_mark) を定義しています。
意味は全く同じです。

:white_check_mark: Updating tests.

また、チェックマークの絵文字は、他にも ✔️ (heavy_check_mark) が存在します。

正直、どちらでもいいとは思います。
個人的には、Windowsでの開発が多かったため、 ✔️ を利用していました。
✔️ のチェックの色が緑色で、わかりやすかったためです。

しかし、他OSではチェックの色が黒色で、わかりづらくなっています。
一方、 ✅ は、殆どのメーカーが緑色矩形の白抜きチェックであり、わかりやすくなっています。

ということで、 test には ✅ (white_check_mark) を利用します。

chore

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

自動生成ツールによりファイルを変更する際に利用します。
chore とは、雑務という意味があります。

choreの意味・使い方・読み方 | Weblio英和辞書

Gitmojiには、該当する絵文字はありません。
一部分で該当しそうな絵文字は、いくつか定義しています。

少し頭を悩ませましたが、英語圏のスラングである 'It's a piece of cake' から取って、 🍰 (cake) を利用します。

it's a piece of cakeの意味・使い方・読み方 | Weblio英和辞書

Angularスタイル以外

以下は、Angularスタイル以外のコミットメッセージで利用する絵文字です。
プレフィックスは付けても付けなくても構いません。

First commit

最初のコミットとしてよく使われる first commit ですが、Gitmojiでは 🎉 (tada) として定義しています。

:tada: Initial commit.

ということで、 first commit には 🎉 (tada) を利用します。
プレフィックスは init とします。

余談ですが、個人的には first commit を空メッセージにするのは懐疑的です。
必要無いから消したのか、書き忘れたのか、空メッセージでは判断できないためです。

Gitの最初のコミットは空コミットにしよう - Qiita

Merge commit

マージ実行時のコミットですが、Gitmojiでは 🔀 (twisted_rightwards_arrows) として定義しています。

:twisted_rightwards_arrows: Merging branches.

ということで、マージコミットには 🔀 (twisted_rightwards_arrows) を利用します。
長いですが、マージコミットの1行目はあまり重要であることは少ないため、問題なしとします。
プレフィックスは merge とします。

Review commit

レビュー指摘反映時のコミットですが、Gitmojiでは 👌 (ok_hand) として定義しています。

:ok_hand: Updating code due to code review changes.

ということで、レビュー指摘反映コミットには 👌 (ok_hand) を利用します。
~~あまり個人的には多用しないようにすべきとは思いますが......~~

WIP commit

作業中コミット (WIP: Work in Progress) ですが、Gitmojiでは 🚧 (construction) として定義しています。

:construction: Work in progress.

ということで、作業中コミットには 🚧 (construction) を利用します。
プレフィックスは wip とします。

おわりに

現在ではプライベートリポジトリでしか利用してませんが、個人的には可読性が上がっている気がします。
これを開発チームに展開して共有できれば、また違った世界が見えるかもしれません。

絵文字は、用法用量を守り、適切にご利用ください。

ちなみに

Gitmojiでは、本記事と似たようなIssueが立っていました。
もしかしたら、Gitmoji側で方針が決まるかもしれません。

Add a "semver" field for each emoji · Issue #429 · carloscuesta/gitmoji

こんなリポジトリもあります。
これを使えば、本記事の内容をPJで統一しやすくなりますね。

negokaz/git-fancy-message-prefix: A Git prepare-commit-msg hook for fancy commit message

vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか

2020-10-04T23:17:10+09:00

本記事は、 Qrunch からの移転記事です。

移転元: vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか - 雑木林

はじめに

皆さんは、出先にvimrcファイルがあれば良かったのに、という経験はありませんか？

偶然にも、私はそんなことが何度かありました。

例1：インターンシップ

それは、とあるインターンシップでのことです。

回想はじめ

偉い人「AWSサーバ1つあげるから、これで何か作ってください」
私「よっしゃいじり倒したろ、さてapacheの設定ファイルは......」
私「Vimの設定がデフォルトで全然使えん！！！」

回想おわり

さて、私はこの時、偶然にもGitHubにvimrcファイルを置いていたため、クローンしました。
するとどうでしょう、行番号も碌に表示していなかったVimに、命が吹き込まれたのです。

私は、このインターンシップを大成功で収めることができました。

例2：新しい業務用パソコン

それは、新しい業務用パソコンがたくさん届いた時のことです。

回想はじめ

私「さて、環境構築するか」
新パソコンA「Vim無いよ」
新パソコンB「Vim無いよ」
新パソコンC「Vim無いよ」
私「......これ全部同じことしないとならんの？」

回想おわり

さて、私はこの時、偶然にも（以下略）

私は、たくさんの新しい業務用パソコンにいち早くVim環境を整えることができました。

例3：vimrc編集後

それは、突発的にvimrcファイルを書換えた時のことです。

回想はじめ

私「ふへへ、ついに最強のvimrcを書いてやったぜ」
私「さて、これを私が利用している別のパソコンにも入れなきゃ」
私「えーっと、家のデスクトップ、家のノート、新パソコンA、新パソコンB、新パソコンC......」
私「......今日はそろそろ帰ろう」

回想おわり

さて、私はこの時、偶然にもGitHubでvimrcファイルを管理していたため、新しいvimrcをpushしました。
別のパソコンを使う際にpullすればいいだけですから、その日は何も考えずに帰りました。

数日後、別のパソコンを利用時にvimrcをpullするとどうでしょう、Vimが生まれ変わったのです。

私は、常に最新のvimrcをどこでも利用できるのです。

おわりに

vimrcは便利ですが、慣れてしまうとデフォルトのVimが苦痛になってしまいます。
いち早く自分の環境に（PCを）適応させるため、GitHubで環境ファイルを管理するのは1つの手だと思います。

上記を活用して、快適環境の生活を過ごしませんか。

追記

GitHubで管理する前は、USBにvimrcを入れて生活していました。
書換えた時に面倒なことになるのは、お察しの通りです。

そのまま使えるGitHub事始め

2020-10-04T23:16:13+09:00

本記事は、 Qrunch からの移転記事です。

移転元: そのまま使えるGitHub事始め - 雑木林

何も考えたくないけどGitHubを使いたい方へ

昔、誰でもGitHubを使えるように私が書いたREADMEもどきを発掘したので、それっぽく編集して上げておきます。

この文章は、私の周りの新しいことが得意じゃない人たちにGitHubを使わせるべく書いたものです。
本質とか理由とかは抜きにして、この文章さえ読めたら使えるよう、本質から少しでも外れるものは除外しました。
また、GitHubを使わせることが目的のため、Gitを使う際に最も恩恵を受けるはずのbranchの切替えやresetについては全く書いていません。

これを読めば誰でもGitHubが使えるようになりますが、使えるだけで使いこなせるわけじゃないので気を付けましょう。
特に、最近はGUIベースのGitツールがたくさんあるので、わざわざCUIベースで使う利点があるのかどうかわかりません。
でも僕がCUIベースのGitツールしか使ったことがないため、とっかかりにはいいんじゃないですかね？ (適当)

なお、既存のディレクトリをGitHubで管理したい人向けです。

使い方

事前条件は、以下の通りです。

コマンドを利用できる (黒い窓に抵抗が無い)
GitHubアカウントを作成済みである (作り方は調べてください)
ローカルPCにgitコマンドを導入済みである (導入方法は調べてください)

GitHubの自分のアカウントで新しいリポジトリの作成

右上の自分のアイコンの隣の"＋"ボタンを選択して、New repositoryを選べばいいと思います。
ここで記述したリポジトリ名が後々に響きますので、ここは真面目に考えましょう。
ここではhogehogeという素晴らしいリポジトリ名を付けたとします。

導入したいディレクトリに移動

ここではホームディレクトリ直下のhogehogeディレクトリを導入したいことにします。

cd ~hogehoge

gitの確認

git --version

と打ってgitのバージョン情報が出てこなければ、gitを導入してください。
また、ユーザ名やEメールアドレスも登録しておいてください。

git config --global user.name "User Name"
git config --global user.email "[email protected]"

この時、今回導入したいディレクトリは別のアカウントで登録したい場合は、--globalを外しましょう。

git config user.name "The Other Name"
git config user.email "[email protected]"

リポジトリ化

git init

リポジトリ情報として、GitHub上で作成したリポジトリのURLを追加してください。
当然ですが、アカウントの名前は自分のアカウントを書いてください。

git remote add origin https://github.com/ユーザ名/リポジトリ名.git

hogehogeリポジトリをGitHub上で作ったMorichanさん（私です）であれば、次の通りです。

git remote add origin https://github.com/Morichan/hogehoge.git

古い方法

僕は上記でうまくいきましたが、幾つかのウェブサイトでは下記のように設定しているみたいです。

git remote add origin [email protected]:ユーザ名/リポジトリ名.git

これでうまく行った方は教えてくださいね。
ちなみに、設定は

cat .git/config

で見ることができます。
うまく行かなかったときは

git remote rm origin

などで消して最初から書き直しましょう。
もちろんconfigファイルを直に書き換えてもできるかもしれません。
やったことがないのでわかりませんが自己判断でどうぞ。

ネット上のGitHubの情報をローカルに入手

git fetch

この時エラーとして、fatal: Could not read from remote repository.と出てきたら、リポジトリ化で設定したGitHub上のリポジトリのURLの設定が間違っている可能性が高いです。
書き直してあげてください。

masterブランチの導入

git pull origin master

でmasterブランチが手に入ります。
ちなみにpullする前に

git branch

と打っても何も出力されません。

gitの歴史にファイルの追加

git add -A

もし上記のコマンド、あるいは次のコマンドで何も書き換わってませんよということを言われたら、適当なファイル（README.mdなど）を書き換え（改行一つ追加でもいいよ）て、保存して同じコマンドしてください。

最後にカラcommitをしてネット上に送り出せば終了です。

git commit --allow-empty -m "Pushしてやるぜ。"
git push -u origin master

お疲れ様でした。

まとめ

こんな文章で理解した気になるのはやめましょう。

GitHubのプロフィールにREADMEでアクセスカウンタを表示する

2020-07-21T08:27:14+09:00

ちょっと前からGitHubのプロフィールにREADMEを表示できるようになったようです（2020/7/20現在）。僕も試してみてアクセスカウンタを表示してみました。

https://github.com/dala00

キリ番報告用の掲示板（issue）もあります。キリ番ゲットしたら絶対にスルーしてはいけません。

READMEの表示方法

プロフィールに表示するREADMEは、自分のユーザーIDと同じ名前のリポジトリを作ることで、そこに作ったREADMEを表示することが出来ます。作成しようとすると下記のような表示が現れます。

赤くなっているのは僕が既に作成済みだからなので無関係です。あとはもしかしたらリリースされたばかりの機能のため、人によってはまだでないのかもしれません。

これでリポジトリを作成したら、README.mdを作成すればプロフィールにそれが表示されます。

アクセスカウンタを表示する

dev.toとかを見ると、色んな人が色々なREADMEを作って遊んでいます。僕も作成時の参考にしたのですが、 @ryanlanciaux さんのプロフィールは昔懐かしきWebを表現しています。

この方のアクセスカウンターは、実はパラメータを変えれば誰でも使うことができるというシロモノです。とにかくすぐ試してみたい場合はこれを利用してみると良いでしょう。

Add a visitor count on your GitHub profile with one line of Markdown - DEV Community

ただし下記の技術記事を見る限りはオンメモリで値を持っているようですので、何か再起動のタイミングとかがあれば0に戻ってしまう可能性はあるのかもしれません。もしくはデータ保存型に修正済みかもしれませんが。

Quick GitHub profile visit counter - DEV Community

アクセスカウンタを作る

自分で作る場合です。具体的には下記の方法です。

値は適当に保存したり取得したりさせる
動的に画像もしくはSVGを作る
キャッシュを無効にする

基本的には難しいことはしていません。キャッシュを無効にしないと、GitHub側で画像をキャッシュしてしまうため、キャッシュ無効のレスポンスヘッダを返して無効にします。そうすれば大丈夫みたいです。よくよく考えたらCIのバッジもキャッシュされず動的に変わってますね。元々不可能ではなさそうです。

僕のプロフィールのリポジトリに一応サンプルのプログラムも置いてあります。適当です。

https://github.com/dala00/dala00/blob/master/counter_sample.php

キャッシュでハマったのでなんやかんややっているうちにSVGになってしまいましたが、多分普通に画像でも行けるのではないかと思います……が試していないため分かりません。

あとは先程の方がやっていたように、別にサーバーを持たなくてもGlitchで行けるのではないかと思いますがこちらも面倒で試していません（作り終わってからそっちでやればよかったと気づきました）

ということで皆さんも色々試してみて下さい。

できないこと

多分iframe表示したりはざっと調べた限り、出来ないんじゃないかと思いますが試していません。画像で試行錯誤するしかないのかな……と今のところ思っています。何か面白いことができたらぜひ教えて下さい。

hugoをgithub-actions上でbuildした際、lastmodの更新がすべての記事に適用される問題を解決した

2020-04-04T10:47:33+09:00

はじめに

hugoのジェネレートをGitHub-actionsを使って、pushするだけでデプロイできるようにしたのですが、全記事の最終更新日が更新されていたため原因調査をおこないました。

TL;DR

gitのcloneを行う際に最新コミットしか取得していなかった
actions/checkoutを利用する場合は以下の方法でfetchを行わせ、全履歴を取得しておく

- uses: actions/checkout@v2
  with:
    fetch-depth: 0    # Fetch all history for .GitInfo and .

試したこと

GitHub-actions上とlocalの比較

icon	結果
✅	更新対象記事のみlastmodが更新されていた
❎	すべての記事に対して更新が入っていた

ローカル
- ✅MacOSでのビルド
- ✅Vagrant内のUbuntu:18.04.4でのビルド
CI環境
- ❎Ubuntu:ubuntu-18.04でのビルド
- ❎MacOS:latestでのビルド
- ✅hugoのビルドを省いてデプロイ
- ❎オプションを外してビルド
- ❎既存のworkflowを使わずにコマンドでインストール（下記コマンドを実行）
```
wget https://github.com/gohugoio/hugo/releases/download/v0.68.3/hugo_0.68.3_Linux-64bit.deb
sudo apt-get install -y ./hugo_0.68.3_Linux-64bit.deb
```

git周りの確認

参照先のcommitIDが対象コミットのcommitIDになっているか
- 対象のコミットIDでした
git logの結果が正常に表示されているか
- CI上のログでは、1件しか表示されていなかった

結果

actions/checkout@v2という公式のworkflowを利用してgitのcloneを行っていたのですが、デフォルトでは最新のコミットしか取ってこないようです。
更新日時の参照先が見つけられなくなるため、すべての記事が最新のコミット更新日時を取得しに行ってしまったのだと思います。

# Number of commits to fetch. 0 indicates all history.
# Default: 1
fetch-depth: ''
https://github.com/actions/checkout#usage

すべての履歴をcloneしてくることで、解決しました。
GitHub Actionsのymlファイルでは、以下のように記載するようです。

- uses: actions/checkout@v2
 with:
   fetch-depth: 0    # Fetch all history for .GitInfo and .
https://github.com/peaceiris/actions-hugo#️-create-your-workflow

さいごに

最初はhugoのセットアップに使っているworkflowが悪いのかを疑ってたせいで、結構解決までに時間がかかりました…

今回のような問題を早期発見するために、確認用のStepも入れたほうが良いのかなと思いました。

参考

GitHub ActionsでMySQLを使ったLaravelのテストを実行する

2020-02-20T18:48:36+09:00

GitHub ActionsでMySQLを使ったLaravelのテストを実行してみたら出来たのでメモ。

アクションを作成する時にLaravelの雛形が選べるようなので、とりあえずそちらを使って作成する。雛形を下記のように置き換えた。

name: Laravel

on: [push]

jobs:
  laravel-tests:
    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:5.7
        ports:
          - 3306
        options: --health-cmd "mysqladmin ping -h localhost" --health-interval 20s --health-timeout 10s --health-retries 10
        env:
          MYSQL_ALLOW_EMPTY_PASSWORD: yes
          MYSQL_DATABASE: laravel

    steps:
      - uses: actions/checkout@v2
      - name: Copy .env
        run: php -r "file_exists('.env') || file_put_contents('.env', str_replace('DB_PORT=3306', 'DB_PORT=${{ job.services.mysql.ports['3306'] }}', file_get_contents('.env.example')));"
      - name: Cache vendor
        id: cache-vendor
        uses: actions/cache@v1
        with:
          path: vendor
          key: ${{ runner.os }}-vendor-${{ hashFiles('**/composer.lock') }}
      - name: Install Dependencies
        if: steps.cache-vendor.outputs.cache-hit != 'true'
        run: composer install -q --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist
      - name: Generate key
        run: php artisan key:generate
      - name: Directory Permissions
        run: chmod -R 777 storage bootstrap/cache
      - name: Execute tests (Unit and Feature tests) via PHPUnit
        run: vendor/bin/phpunit

やったこと

下記が追加で編集したもの。

MySQLの設定

もともとはSQLiteでテストが行われる設定になっていたが、ちゃんとMySQLで実行したいのでその設定。まずはservicesにMySQLのサービスを追加。optionsはよくわからないがコンテナが落ちてしまうらしいので追加している。そのうち不要になるのでは。

接続の設定は .env.example をコピーして使う。そのため、その設定に合わせてこのサービスのenvを設定する。具体的な設定はDockerHubのmysqlイメージのところに書いてある。

ポートは ${{ job.services.mysql.ports['3306'] }} という感じでサービスのポートを参照できる。ホストはローカル。ただしlocalhostでなく127.0.0.1としないとつながらないっぽい。

phpunit.xmlの編集

phpunit.xmlにSQLiteを使う設定が書かれているので、そちらを削除する。

キャッシュの設定

vendorフォルダをキャッシュする。Cache vendorとInstall Dependenciesのところ。これでキャッシュされて次回から0秒になっているので多分大丈夫っぽい。

ちなみに下記がキャッシュ前。

まとめ

雛形もあるし非常に簡単だった。

テキストエディタとGitHubでコード管理できるGAS開発環境を作る

2020-02-04T12:25:53+09:00

はじめに

GASでの開発に取り組む中で、コードをテキストエディタで書き、Githubで進捗を管理したいなと思いました。

普通にGASで開発する場合は、ブラウザからGoogleDriveのスクリプトエディタを起動してその中でコードを記述します。
このブラウザ上で簡単に書けてすぐに実行できるという開発環境いらずなのがGASの良いところなのですが、
このコードをローカルのテキストファイルとして作り、Githubを使って管理できたら良いなあと思ったわけです。

僕の場合は
- 以前に書いたコードと見比べたい時に、テキストファイルだと参照しやすい
- Githubにコードを残してポートフォリオやメンターの方と共有したい
- 以前Githubのプルリクを使って開発する流れを教わったので活用したい（行き当たりばったりの開発にならないように）

そんなところから自分のやりやすいように開発環境を作ってしまえと考えてやってみた結果、
1. VSCodeでコードを作成・修正してGithubにpush
2. GASのscriptエディタでそれをpullして実行
3. 1に戻ってデバッグ

という流れで作業をすることができるようになり、
例えば学習教材から学んだサンプルコードと見比べて吟味したりコピペしたり学びながらコードを書くのがとても便利になりました。

正直この開発環境がベストプラクティスかどうかは怪しいですが、ノンプログラマの僕が最低限の使い方ができれば良し！という感じでやっています。
同じく最低限で使えれば良いよーという方は参考にしてみたらいただけたら嬉しいです。
また、もっと良いやり方があるよーというのがあれば教えていただけると嬉しいです。

この記事の対象者

GASを既に使っている方
gitやGithubの基本的な使い方もある程度理解している方

使用ツール等

Google Chrome（ブラウザ）
VSCode（テキストエディタ）
Github
　
GASでのgithubとの連携にはChrome拡張機能を使用します。
前提として、以下のアカウント登録やインストールなどは先に済ませておきます。それぞれのやり方はここでは割愛。
Githubのアカウントは登録済み
GitをPCにインストール済み（$ git --versionでバージョンが出ればOK）

開発環境づくり

１．プロジェクトフォルダとファイルの作成

これから制作するプロジェクトのフォルダと、コードを記述するファイルを作っておきます。

プロジェクトフォルダはどこに作っても大丈夫です（試しに作るならデスクトップで良いでしょう）。
そしてその中にmain.jsという空のテキストファイルをjs拡張子で作成しておきます。
（実際には拡張子は.gsなんですが、ここは.jsに。理由は後ほど）

※（余談）プロジェクトフォルダの名前や保存先は自由に決めて問題ないですが、あまり階層を深くしないのと、プロジェクトは一箇所（僕の場合はDocuments/Projects）にまとめておき、その中にプロジェクトごとにフォルダを作るのが便利かなって思います。

２．ターミナルでgitの初期設定とGithubとの連携

ここから、参照リンク１を大いに参考にさせて頂いてます。
ターミナル（Mac）を起動してコマンドを打ち込んでいっても良いのですが、せっかくなのでVSCodeのターミナル機能を使ってみます。

VSCodeを開いたら、「表示」タブから「外観＞パネルを表示＞ターミナル」もしくは「ターミナル」タブから「新しいターミナル」で開けます。これでターミナルも別窓にならないのでとても便利。

さて、このターミナルにコマンドを打ち込んでいって、先ほど作成したプロジェクトフォルダに入ります。
フォルダを作った場所によって違いますが、僕の場合はDocuments/Projects/（プロジェクト名）がプロジェクトフォルダなので、

$ cd Documents
$ cd Projects
$ cd （プロジェクト名）

次にgitの初期化を行い

$ git init

GitHubとの連携のための初期設定を行っていきます。

$ git config --global user.name "ユーザー名を入力"
$ git config --global user.email "メールアドレスを入力"

ダブルクォーテーション（""）の中には、自分のGithubにアカウント登録しているユーザー名とメールアドレスを入力するようにします。エラーが出ないようなら成功。

３．Githubでリポジトリ作成

GitHubにログインしてNewボタンからリポジトリを作っておきます（ここでReadMeを作っておくと良いようですが僕はすっ飛ばしてしまいました）。

リポジトリが完成したら、とりあえずHTTPSを選択（下の画像の赤丸）
…or push an existing repository from the command line
の下の２行のコマンドをコピーしておきます。一番右のマークをクリックしたら一発でコピーできます。
（下の画像の赤四角の部分）

※（余談）ほんとはSSHを選択して鍵の作成や設定をしておくと安全だったりするっぽいのですが今回はHTTPSで。もうちょっと勉強しておきます。

４．リモートリポジトリの登録・コミットとプッシュ

ターミナルに戻り、一旦今の状態でコミット。
コミットメッセージは最初はとりあえず"First Commit"とでもしておきます。

$ git add .
$ git commit -m "First Commit"

次に、ローカルディレクトリにリポートリポジトリを登録します。
先ほど作成したGithubリモートリポジトリからコピーした２行のコマンドを入れます。

$ git remote add origin https://github.com/アカウント名/リポジトリ名.git
$ git push -u origin master

するとユーザーネームとパスワードを聞かれるので、Githubのアカウントに使用しているものを入力します。

（上のコマンドを入力後の応答）
Username for 'https://github.com': （Githubのユーザーネームを入力）
Password for 'https://ユーザーネーム@github.com':　（Githubのパスワードを入力）

もしパスワード入力に失敗したりしても、慌てずに$ git push -u origin masterと入れれば再度入力できます。

ユーザーネームとパスワード入力に成功すれば、見事リモートリポジトリの登録完了！

５．Chrome拡張機能の導入・GASでGithubと連携

次にGASのスクリプトエディタ側でGithubと連携し、push/pullをできるようにします。
これにはChromeの拡張機能である「Google Apps Script GitHub アシスタント」を利用します。
この導入には参照２を参考にさせていただきました。

導入は簡単で、まずChrome ウェブストアから「Google Apps Script GitHub アシスタント」を検索してインストール（Chromeに追加）します。
次にGASのスクリプトエディタを開いて、Login SCMをクリックして、usernameとpasswordを入力すればGithubと連携が完了です（Repositoryが選択可能な状態になっていればOKです）。

６．GASでいったんpullしてみる

Repositoryタブから今回作成したGithubリポジトリを選択して、
その右のほうにある⬇︎ボタンをクリックしてpullしておきます。
（⬇︎がpull、⬆︎がpush）

ただ、そのままpullしようとしても上手くいきません。上部に「There is nothing to pull」とアラートが出てしまいます。

Repositoryの右の方にある歯車マークをクリックして、File type to syncの項目を.jsに変更します。
これはテキストファイルを作った時にjs拡張子で作っていたためです。こうすることでgsファイルとして読み込むことができます。

これにより⬇︎をクリックするとちゃんとpullできるようになっています。

以上で設定は完了です！わーい！

開発の流れ

以降、

VSCodeでコードを作成・修正してGithubにpush
GASのscriptエディタでそれをpullして実行
1に戻ってデバッグ

を繰り返して開発を進めていきます。

VSCodeでテキストファイルを読み込んで、実際にコーディングしていきましょう。
ある程度コードを書いていき、ここらでGASで実行してみたいなーと思ったら、ターミナルでプロジェクトフォルダに入ってることを確認してから、

$ git add .
$ git commit -m "（コミットメッセージを入力）"
$ git push

続いてGASのスクリプトエディタ側で、⬇︎クリックでpullして、関数の実行なりアプリ公開なりしてみてください。
しっかり「テキストエディタ＆Github＆GASのスクリプトエディタ」が連携しているはずです！！

※（余談）コミットの管理とかプッシュはVSCodeの「ソース管理画面」なるものからクリックで直感的にできるようです。僕はターミナルを叩きたくて使ってませんが、そのやり方も参照リンク１を参考にできそうです。

解説・補足

ただこのやり方、開発の際に注意しなければいけないのが、コンフリクトが起きないように気をつけることです。

例えばデバッグする際にGASのスクリプトエディタ側のコードを修正してしまうと、テキストエディタで記述しているものと差異が生まれてしまいます。
その都度push＆pullするなら良いのですが、うっかり忘れがちなので結構面倒です。

僕はひとまず
「コードの修正は必ずテキストエディタの方で行う」
と決めて、GASスクリプトエディタでは基本的にコードを直接いじらないようにして回避しています（いじるとしたらあくまで関数の動作チェックのため）。

そこがちょっと煩わしいのですが、一応今の所は不自由なく目的を果たしています。
この辺上手く使いこなしている方がいれば、ぜひやり方を教えてください。

また、テキストエディタはVSCodeに限る必要はなさそうなので、自身の慣れたテキストエディタでアレンジしてみても面白そうです。

あとがきMEMO

今回のやり方はさほど手間もかからずに１時間程度でできるし、自分の使い慣れているツール・やり方に落とし込む作業というのは、ハマればとても楽しいものですね。

gitでのバージョン管理やGithubはこれまでも使っていたものの、調べて書いてある通りにやっていただけで実際によくわかっていなかったので、これを機に理解が深まった気がします。

参考にしたサイト

参照リンク１
【初心者向け】Visual Studio Codeで書いたコードをGitHubに公開する方法 - 鍋綿ブログ
参照リンク２
GASをGitHubで簡単管理可能なChrome拡張機能　～導入時に躓いたこと～ - Qiita

GitHubにブランチの自動削除設定が追加されたようです

2019-08-01T10:22:32+09:00

GitHubにブランチの自動削除設定が追加されたようです。公式のブログはこちら。

Automatically delete head branches of pull requests

なぜ自動で削除するのか

例として以前下記のような記事を書きました。

一人プルリクエストのすゝめ

Gitでブランチを利用した開発をした場合、基本的にプルリクエストをマージした後はブランチを即削除するのがベストだと思います。残しておいてもたくさん並んでじゃまになるだけですし、どうしてももとに戻したい場合はもとに戻せばよいだけです。

GitHubであればこんな感じですぐもとに戻せます。

ブランチは単なるコミットに対するタグ付けと同じですので、チームの運用ルールに従っていれば別に削除しようが戻そうが自由です。

ということで、プルリクエスト後にボタンを押して毎回ブランチを削除していたのを単に自動にする、というだけですので、特に個人で開発しているリポジトリやOSSの場合だと何も支障はありません。

業務の場合は一応チームで確認したり、テスト用リポジトリを作って試してみたほうが良いかもしれません。開発サーバー用ブランチのようなものを作って運用している場合もありそうですのでそういったものが削除されると厄介だと思います。

設定方法

リポジトリの設定画面を開きます。

下の方に行くとMerge buttonの設定があり、その一番下に追加されているようです。

BitBucketからGitHubの無料プライベートリポジトリに引っ越した

2019-01-08T09:25:51+09:00

GitHubのプライベートリポジトリが無料でも作れるようになりました！　無料で共有できるのは３人までですが、僕がやっているような個人開発は一人で使うことが多いため非常に嬉しいです。

ずっとプライベートリポジトリとしてBitBucketを使っていましたが、重かったり使いづらかったりで不満はあり、GitHubを使いたかった気持ちはあったので、とりあえず一番頻繁に使っているCrieitのリポジトリをBitBucketからGitHubに引っ越ししてみました。

GitHubでプライベートリポジトリを作成

まずはGitHubにて空のプライベートリポジトリを作成しておきます。

各環境のremote参照を変更

開発環境、本番環境など、Gitで参照しているremoteのURLを変更します。とりあえず現状のURLを見てみます。

$ git remote -v
origin  [email protected]:alphabrend/dev.git (fetch)
origin  [email protected]:alphabrend/dev.git (push)

URLを変更します。

git remote set-url origin [email protected]:dala00/crieit.git

再度確認してみると変更されていることがわかります。

$ git remote -v
origin  [email protected]:dala00/crieit.git (fetch)
origin  [email protected]:dala00/crieit.git (push)

実際にpushしたりする際にはGitHubの方にも鍵を登録しておく必要があります。ローカルはBitBucketにもGitHubにも登録しているかもしれませんが、本番環境は個別に登録していく必要がある場合が多そうです。

諸々準備できたらpushすれば完成です。それぞれの環境でfetchしたりpushしたりを試してみてください。

草も移動するっぽい

多分ちゃんと草も移動してくれてるっぽい（？）です。

WikiやPagesは使えない

無料プライベートだとWikiは使えないみたいですね。メニューにありません。BitBucket側で色々な周辺機能をガンガン使ってる場合は移行しづらそうですね。あとGitHubでのダウングレードも注意が必要そうです。

その他料金表で細かくは確認してください。

Pricing · Plans for every developer

まとめ

~~あとはCIとかも引っ越す必要がありますのでまた対応したら記事を書いていきます。~~ CIは単に新しいリポジトリのビルド設定を追加するだけで問題なさそうでした。

Crieitはdev.toとQiitaを参考に作った、というところからdevという変なリポジトリ名になっていたのですが、この機会にちゃんとしたリポジトリ名にできたのも良かったです。

vimとかtmuxとかを使いこなそうとしない

2018-11-15T10:25:03+09:00

Google Cloud Shellの中でやれることをやる。高価なPCやサーバーを用意しなくてもブラウザだけで従来の「プログラミング」をすることができる。評価の定まった本に書かれたコードを書いて実行できる。いま始める人のためにピッタリ。

Google Cloud ShellにはWebエディターも用意されているけど複雑だから使わない。
vimがインストール済みだからvimを使う。

$ vim index.html

ややこしいことは考えずに、
ESCとiと:q!と:qwだけで十分使える。
ESCキーの代わりに使えるctrl + [ が便利。

設定しなくても色が付いてるし、自動で閉じタグ書いてくれる。
ただ、タブ幅が大きすぎるからvimrcファイルで設定する。

~/.vim/vimrcファイルを置く、中身は3行。

source $VIMRUNTIME/defaults.vim

まずこれを書くこと。これがないとすっぴんで起動して、htmlのハイライトもされない。

set tabstop=4
set shiftwidth=0

これでタブ1文字の表示がスペース4つ分になる。

index.htmlを書いたら、プレビューする。

Google Cloud Shellの「ウェブでプレビュー」は、インターネットからアクセスできるURLを用意してくれる。googleアカウントでログイン済みのアクセスだけをcloud shellの8080ポートへ通してくれる。
ということで、8080ポートで待ち受けするWebサーバーを起動する。何を使ってもいいんだけど、インストールされててすぐ使えるからpython3。

$ python3 -m http.server 8080

実行すると、画面から入力待ちのプロンプトが消えてWebサーバーのログが表示されるようになる。こうなるとvimが使えない。Webサーバーを起動したままで他のこともしたい。cloud shellの別のタブを使ってもいいけど、Google Cloud Shellはtmuxが導入済みで、こういう場面で役に立つ。

ctrl + b, cを押すと、「Wellcome to Cloud Shell」が表示される。さっきまでの画面はctrl + b, nで戻れる。迷子になったときはctrl + b, wで画面の一覧が出せる。

これで、Webサーバーを起動させたままvimでhtmlファイルを編集できる。

vimを終了させずにファイルを保存するには、:w

エンジニアライブを支える技術 ~ もしくは、React + Netlify + GitHub + GraphQL + TypeScript でイベント用のウェブサイトを作った話 ~

2018-10-25T12:36:02+09:00

エンジニアが出演する (音楽の) ライブイベントを企画したので、そのためのウェブサイトを作りました。

EngineerLiveTokyo

これで利用したシステム構成が、短時間でそこそこ使いやすいサイトを作るのに使い回しの効きそうなものだと思うので紹介します。

エンジニアライブを支える技術

タイトルのまんまですが、技術スタック的な視点では以下の組み合わせで構築しています。

React
Netlify
GitHub
GraphQL
TypeScript

React + Netlify

まずサイトを手早く作るために create-react-app のテンプレートを元に SPA で画面を作っていきました。

トップページ
出演者一覧ページ
出演者詳細ページ
ニュース一覧ページ
ニュース詳細ページ

というシンプルな画面構成なので React を使えば (デザインは置いといて) 速攻で作れました。最終的にはペライチみたいなサイトでいいかなと思って出演者/ニュース一覧ページは無くしてしまいましたが。

しかしここで特に「支える技術」として伝えたいのは Netlify のお手軽さで、Netlify を使うことで

GitHub のブランチに更新を push したら CI でデプロイ
SPA リロード時の404対策
SPA の OGP 対策のための pre-rendering

などを他の外部ツールに頼ることなく Netlify のみで一瞬で実現することができました。特に最後のものは、今回のエンジニアライブサイトのように各ページを LP としてシェアしてもらいたいようなサイトを SPA で構築するときに頭が痛い点の1つだと思うので、これがお手軽なのはかなりありがたかったです。

そして小規模なウェブサイトであればフリープランで使えますし、うーん、とにかく良い…

GitHub issues as CMS

サイトを更新していく方法は色々ありますが、参加者の大半がソフトウェアエンジニアということで、GitHub の issues に記事などをポストするとそれがサイトのコンテンツに反映されるようにしました。

エンジニアライブのサイトでは、定期的に更新されるコンテンツとして

ニュース (お知らせや出演者の活動レポートなど)
出演者情報

の2つのカテゴリのページがあります。

それぞれ、普通に GitHub の issue として内容を書いたらそれに post や lineup のラベルをつけると、対応するカテゴリのページとして実際にサイトに表示される仕組みにしました。フロントエンド側はリアルタイムに情報を GitHub から取得するので、GitHub 側でラベルを付けた issue を作成または更新すると即座にサイトにも反映されます。

例えばニュースカテゴリのページを作りたかったら以下のように post ラベルをつけます。

GitHub を CMS として使うことで、普段使っているものと全く同じ感覚で markdown でコンテンツを入稿できて、ユーザー管理なども GitHub のものをそのまま使うことができるのが楽なところです。

例えば「出演者情報ページでは写真が欲しい」といった理由から内容に一部レギュレーションを規定する必要はありましたが (必ず画像を入れてねみたいな) 、基本的には issue から取得した HTML をそのまま埋め込むだけなので markdown で表現可能などんな内容でも書くことができます。

ただし、YouTube 動画を埋め込みたい要件があり、それがどうしても実現できなかったためにショートコード機能を追加しています。ショートコードというのは Hugo や WordPress にある機能で、特定の文法規則にしたがって記載しておくとそれが決まった形の HTML に展開されます。

具体的には、issue 本文に

youtube xxxxxxx

と書いておくと (xxxxxxx は YouTube の動画 ID) 、それがサイト上では iframe の埋め込み動画として表示されるというものです。多少強引ですが、これはフロントエンド側で直接取得した HTML 文字列を変換することで対処しました。

GraphQL

GitHub issues からのコンテンツデータの取得には GraphQL を使いました。

REST API でも同じことはできますが、GraphQL を使うことで、シンプルな GET だけならほとんど API リファレンスなどを見なくても「必要な情報を必要なだけ得る」ためのクエリがすぐに書けるのはサッサと作りたい場面ではかなりありがたいです。今回のような「post ラベルがついた issue だけ取得したい」といった仕様を満たすのも簡単です。

また、特筆すべき点として、GitHub は GraphQL Explorer という GraphQL フロントエンド (GraphiQL) を用意してくれています。GraphiQL を使ったことがある方はわかると思うのですが、これが IDE 的な補完やドキュメント参照もその場でできる大変素晴らしく便利なやつです。

前述した「ほとんど API リファレンスを見なくても…」というのにはこの GraphQL Explorer の存在が大きいです。

GraphQL のクライアントには Apollo を使いました。今回、実は最初に JavaScript で開発していたのを後から一気に TypeScript に書き換えたのですが、そのときも react-apollo を使っていると型定義の追加が簡単にできて型付けのための書き変えを難なく完了することができました。

TypeScript

前節でも書いた通り、最初は JavaScript で開発をスタートしました。理由は単純で「JS をそのまま使う方が開発速度はきっと速いだろう」というものでした。

が、最終的にはすべてを TypeScript で書き直しました。確かに JS の方がコード量は少なくなるのですが、開発中に結局 props を意識しないといけなくてそれがすぐにわからなくて悩むことや、静的型付けの方が結果的に細かいバグが減って開発効率も良かったためです。

特に VSCode などの IDE 的なサポートが強いエディタで開発する場合には、TS の導入に大きな障害がないのであれば、ごく小規模なサイトを高速開発したいような場面でも最初から TS を使った方が良いかもしれません。

まとめ

実は、一番最初はこのサイトの作るのに自分の趣味を優先して Swift の Web Application Framework である Vapor を使ってフルスタックで作っていたのですが、やっぱり色々時間がかかってしまったので、実益を取って React SPA + バックエンド CMS に切り替えた背景があります。React を用いて静的サイトになったことで Netlify を利用することもできたため、結果的には CI などの開発フローも含めて全体的な開発効率を大きく高めることができて正解でした。

ただ、今回のようなシンプルな構成の場合に柔軟で高速な開発を行うには、どちらかというとバックエンドにこだわるよりはフロントエンドをデータ層と分離できていることが大事で、その上で適切に抽象化されたバックエンドとのインターフェースがあって楽に取り替えがきくことが重要であると感じています。

そういう点で、コンテンツを更新していく仕組みは別になんでもいいと考えていて、GitHub じゃなくても NetlifyCMS や Contentful などのマネージドな Headless CMS を使ってもよいし、別にプレーンテキストのファイルでもクラウドストレージでも、手軽に更新できるものならなんでもよいでしょう。この辺りを突き詰めていくとプラガブルにデータソースを選択できる GatsbyJS を使うのが思想的にはマッチする気がしてきますが、記事更新のたびに静的サイトをビルドするのがちょっと面倒で今回は使いませんでした。

まあ、今回高速開発が求められた理由というのが、単純にイベントそのものの準備もあってあんまり周りのシステムに時間をかけたくなかったことがありますので、もし次回があればせっかくの機会なのでもっと趣味を全開にして作ってみたいなと思います。とはいえ、躊躇なく CSS Grid Layout を使ったりできたのでストレス解消にはなりましたが…

Lighthouse のスコアも、Web フォント使ってるところでパフォーマンスだけ満点取れなかったけどまあ十分かな。

最後に宣伝になりますが、エンジニアライブは 2018/11/25 (日) に「真昼の月・夜の太陽」 で開催します。僕は band.rb というグループで出演します。他にもエンジニアとして活躍中の方が多数出演するので、興味のある方は以下のページより参加をご登録ください！

エンジニアライブ東京 #1 - connpass

「GitHub」の記事 - Crieit

海外進出を目指して、ProductHuntへ個人開発サービスを投稿するまでにやったこと&やった結果を全面的にシェアする

Github Issuesをキレイに外部公開するサービス「2go」作ってみた

GitHub ActionsでJestを叩くときのタイムゾーンと言語を設定する

GitHubのパスワード認証が通らなかった話

Github で特定ユーザの publicリポジトリ の名前の一覧を生成する Docker Compose

Github Actions のバッジを付ける (＋バッジに Github Actions ページへのリンクを付与するChrome拡張機能を作成)

Github Actions で PHPUnit を走らせる

Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

GitHubのデフォルトラベルを和訳 + 絵文字付加

Gitのコミットメッセージに絵文字付きプレフィックスを適用する

vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか

そのまま使えるGitHub事始め

GitHubのプロフィールにREADMEでアクセスカウンタを表示する

hugoをgithub-actions上でbuildした際、lastmodの更新がすべての記事に適用される問題を解決した

Github で特定ユーザの publicリポジトリの名前の一覧を生成する Docker Compose