プログラミングで世界を変える

ゲームプログラミングと技術のこと

Hugo + GitHub Pagesでポートフォリオを作る

出来たもの

Nakaji Kohki https://nkjzm.github.io/

[f:id:splas_boomerang:20180610230627g:plain

urlの先の内容が変わって趣旨が伝わらなくならないようにするためのgif

github.com

はじめに

知り合いがGitHubにResume(職務経歴書)をまとめていて良さそうに見えた。

土曜日を1日使ってポートフォリオを公開してみた。

公開まで

技術選定

  • サーバー: GitHub Pages
  • 静的サイト生成ツール: Hugo (+ Academic)

なるべく手軽に公開できて、かつマークダウンに対応している技術という軸で選びました。

GitHub Pagesで正式サポートされているJekyllも検討しましたが、使いませんでした(後述)。

GitHub Pages

  • 自分でサーバーをホスティングしなくて良い
  • GitHubに対する操作だけで完結できる
  • 独自ドメインにも対応

サーバーの知識がないので、自分でホスティングしなくて良いのはかなりよいです。 また、ホスティングサービスは手軽さ故に放置しちゃう傾向にあると思うのですが、普段から使うGitHubならその心配も少なさそうだと思いました。あと、標準のurlはユーザーidでドメインを発行してくるところも気に入りました。(https://[user_id].github.io/)

Jekyll (不採用)

  • GitHubが開発してる静的サイト生成ツール
  • GitHub Pagesで正式サポート
  • Markdownにも対応

一見良さそうで、ブラウザ上でGithubを操作するだけでもページが作成できてしまうほどしっかりとしたサポートがありました。

Adding a Jekyll theme to your GitHub Pages site - User Documentation

しかし、少しカスタマイズをしようとすると設定が煩雑になり、また反映まで毎回待たされるのがストレスでした。かなり広く使われているツールなので、使いこなせれば便利だと思うのですが、僕の場合後述するhugoの方が使いやすかったです。

Hugo

  • 静的サイト生成ツール
  • Markdownにも対応
  • 静的ファイルの生成速度が早い

そこまで大きな差はないのですが、導入の容易さと生成速度の速さが良かったです。 ただ、Jekyllと違い正式なサポートがないため、一部だけ手間がかかる部分がありました。

Github Pagesの仕様の話

2016年くらいに導入されてからいくつか仕様の変更があったので簡単にまとめようと思います。

gh-pagesブランチの情報がいくつか出てきますが、現状だと使う必要がないので参考にしない方ことをおすすめします。

ページの分類

GitHub Pagesには『ユーザーページ』と『プロジェクトページ』の2種類の仕様が存在します。

      ユーザーページ プロジェクトページ
用途 ポートフォリオやResume プロジェクトのWebページ
リポジトリ名 [user_id].github.io [user_id].github.io/[repository_name]
付与されるurl https://[user_id].github.io/ https://nkjzm.github.io/[repository_name]/
公開対象 masterブランチ直下 masterブランチ直下のフォルダ、もしくは指定ブランチ直下のdocsフォルダ

プロジェクトページは、プロジェクトのソースコード管理と同じリポジトリで管理できるよう、docsフォルダ以下にファイルを置けば良い点が大きく異なると思います。

ユーザーページは直下のファイルしか公開できない制約があるので、今回のような生成元ファイルがある場合の管理が難しかったです(後述します)

利用方法

上記の公開対象にファイルを置いたら、リポジトリのSettingタブから、GitHub Pagesの項目を見つけます。 Sourceで公開対象にするブランチを設定し、Saveします (ユーザーページは自動的にmasterが設定されている模様)

一点注意があって、公開対象に更新があった場合、反映までに少し時間がかかります。

push直後は以下のようなメッセージが表示されます。

Your site is ready to be published at https://nkjzm.github.io/

反映されたら、

Your site is published at https://nkjzm.github.io/

というメッセージに変わります。ミニマム30秒くらい。

失敗すると失敗のメッセージが表示され、メールで通知がきます。その場合公開済みのページが壊れることはなく、失敗前のバージョンが表示され続けます。

参考: qiita.com

Hugoの導入

以下のページを見て導入しました。

qiita.com

簡単にまとめると、

(Macでbrewインストール済みの場合)

brew install hugo
hugo new site hugo-test
cd hugo-test

# サーバー起動
hugo server 

# 静的ファイル生成
hugo

上記の状態だと何も表示されませんが、themeを設定してカスタマイズすることで独自のページを作っていけます。

ローカルサーバーでのプレビュー

http://localhost:1313

からプレビューができます。

これがかなり優秀で、起動しておけばファイルの変更のたびに自動的に更新をしてくれます。

サーバーを落とすときは Controll + C をしないとプロセスが残ることがあるので気をつけましょう。

Github Pagesに向けた設定

hugoコマンドで、public以下に静的ファイルが生成され、これを公開対象に設定することでGitHub Pagesとして表示がされます。 しかし、GitHub Pagesの場合公開対象に選べるのはdocsフォルダなので、その設定をしてあげましょう。

config.tomlpublishDir = "docs"を追記してください。

参考: Host on GitHub | Hugo

雑なカスタマイズのイメージ

使用するテーマによって異なる部分もあるので、詳細は各テーマのREADMEやドキュメントを参照してください。

テーマ毎のサンプルページをコピーしてから必要な部分を書き換えていく方法が分かりやすいように思いました。

  • サイト全体に関するメタ情報などは config.tomlに記述していきます。
  • 画像はstatic/img以下に格納していきます。
  • 各要素やページの内容はcontent以下に記述します。
    • content/homeにトップページの各要素の内容を記述します。
    • content/postなどに記事の内容などを記述します。

Academicテーマ

広く利用されているオープンソースのテーマです。

  • MITライセンス
  • レスポンシブデザイン

themes.gohugo.io

書き方に困ったら僕のリポジトリを参考にしてください。 github.com

Hugoの生成元ファイルと公開対象ファイルを同じリポジトリで管理する

GitHug Pagesのユーザーページはmasterブランチ直下のファイルしか公開できない制約があるため、そのままでは実現できません。

そこで以下の記事が参考になりました。

qiita.com

更新したい場合は、以下の操作を行えばokです。

git push origin source
git subtree push --prefix docs/ origin master

余談ですが、2行目の操作をgitのhooks機能を使い、pre-pushで自動化しようと考えました。

参考: gitのpre-push hookでmasterブランチにpushする際にプロンプトで確認するようにする

参考: git/hooks--pre-push.sample at master · git/git · GitHub

しかし、while read local_ref local_sha1 remote_ref remote_sha1が動作せず、断念しました。

whileより前の行でecho "hello"を記述するとpush時にhelloが出力されるが、while内の処理が呼ばれない

どなたか原因思い当たる方がいましたらぜひご教授くださいmm

最後に (ポエム)

Github PagesとHugoを使い、手軽に自分のポートレートサイトを作成することができました。

最近思ったのですが、こういった自分の情報を俯瞰して参照できるページはかなり意義があるのではないでしょうか。

僕は普段から技術研鑽やアウトプットをしていると自負していて、Twitterなどで出来るだけ周りに発信するように心がけています。しかし、そういった発信を後から参照することは難しいです。実際ある程度交流がある人でも、その人が過去に何をしていたかよく知らないことは多いと思います。そこで、自分の実績やスキル、指向性などがまとまった場所の必要性を改めて感じたのです。

僕はクリエイター気質なので、直接の対話でなくアウトプットを通じて自分を理解した欲しいという想いがあるのですが、そのためにも自分のアウトプットしてきたことを人に伝える努力は怠ってはいけないと思うので、これからも随時更新していきたいと思います。

謝辞

デバッグに協力してくれた@pagu0602に感謝🙏

ARKitのFace Trackingを使った『私、転がります。』を作った

この記事はOculus Rift Advent Calendar 2017の11日目の記事です。

qiita.com

元ネタ

www.youtube.com

ポノスさんの『私、転がります。』という生首を転がして遊ぶゲームからインスピレーションを得ました。

作ったもの

www.youtube.com

※ ぜひ音量を出してご覧ください!

解説

ARKitのFace TrackingはiPhone Xで追加された前面のTrueDepthカメラ(depthセンサー)を使った機能で、顔の各部位を認識や追跡を行うことができます。

今回はその機能を利用し、自分の口の動きを認識して画面上の生首を操作するゲームを作りました。

開発環境

MacBook Pro (Retina, 13-inch, Early 2015) macOS High Sierra Unity 2017.2.0p2 XCode 9.2

作り方

まず、AssetStoreからUnity ARKit Pluginをインポートしておきます。 https://www.assetstore.unity3d.com/jp/#!/content/92515 (ProjectSettingが上書きされるので、はじめにインポートした方が良さそう)

f:id:splas_boomerang:20171212000512p:plain

Assets/UnityARKitPlugin/Resources/UnityARKitPlugin/ARKitSettings.assetsでチェックを入れないと実機で動かないので注意してください。

インゲームを作る部分は省略します。 マウス押下で生首が飛ぶようなシステムを作りました。 小さな力で右回転をかけてあげるところがポイントです。

f:id:splas_boomerang:20171211234532p:plain

口の状態を取得するためには、Blendshapeを利用します。

UnityARSessionNativeInterface.ARFaceAnchorUpdatedEvent にイベントを登録することで、Dictionaryから約50個ほどの状態を取得することができます。

ARFaceAnchor.BlendShapeLocation - ARFaceAnchor | Apple Developer Documentation

今回はjawOpenというキーを利用して口の動きを取得しています。 これは顎の状態を取得するイベントですが、今回の用途には合致していました。

jawOpen - ARFaceAnchor.BlendShapeLocation | Apple Developer Documentation

ちなみに当初はmouthClosemouthFunnelを利用しようと考えていましたが、うまく値を拾えませんでした。

mouthFunnel - ARFaceAnchor.BlendShapeLocation | Apple Developer Documentation mouthClose - ARFaceAnchor.BlendShapeLocation | Apple Developer Documentation

最後に

今回作成したプロジェクトは以下のリポジトリにpushしてあります。 github.com

ちなみに

ARKitRemoteという実機を繋ぐとUnityのEditor上でテストをできる仕組みが用意されていますが、遅延が酷すぎてビルドしちゃった方が効率がいいように思いました。(今回の規模なら1分くらいで実機ビルドできるので)

最後に

できればリアルタイムに今の自分の顔を転がすところまで作りたかったです。 ちなみに実際に声を出す必要もありませんが、出した方が楽しかったです。

以前DK2で頭を振り回すゲームを作ったのですが、今回のようにセンサーが増えると色々なインプットができるようになって幅が一気に広がるように思いました。

www.youtube.com

参考

ARKit+Unity ARKit PluginでFace Tracking - Qiita https://qiita.com/mybdesign/items/65a11d289c8fb5c4ae57

UnityARKitPlugin FaceTracking FaceBlendshapeで取得できるパラメーター - Qiita https://qiita.com/A_kkie/items/94c6cb0c290f04d55755

「学び続ける姿勢」について考えたこと、これから実践すること

内容要約

  • 「学び続ける姿勢」のインプットをした
  • 自分でやってみたことの振り返りをした
  • 今後の実践計画を立てた

はじめに

ドワンゴで行われた@t_wadaさんの講演についてのエントリを読みました yuelab82.hatenablog.com

学び続ける姿勢についてまとめられており、納得感のあるためになる内容が書いてありました。 その中の項目で アウトプットをするのが大事 とあったので、この機会に自分にとっての「学び続ける姿勢」を整理してみました。

『Write Code Every Day』をやってみて

実は3月下旬頃から『Write Code Every Day』を実践していました。

f:id:splas_boomerang:20170518025558p:plain

約1.5ヶ月間ですが、ほぼ毎日contributonsを生み出すことが出来ました。

github.com

始めたきっかけは、Battle Conference U30というイベントで「最良の砂場を目指して-プライベート開発を支える技術-」 というセッションを聴講したことでした。

持続性がという部分の話で紹介されていた『Write Code Every Day』に興味を持ち、実践してみることにしました。

自分なりの『Write Code Every Day』のルール

  • 目的は「毎日コードを書く習慣をつけること」
  • 目標は「毎日草を生やすこと」
    • githubのContribusionsの意味
    • 00:00-から23:59までに最低1contribution
    • 生活環境に依存せず継続する
  • “なるべく"意味のあるコミットを作る
    • 無意味なコミット < 毎日欠かさずコミット
  • オープンソースであることは問わない
    • github上での設定でプライベートリポジトリも表示させる

すぎゃーんさんの記事を参考に、かなり緩めのルールを設定しました。 memo.sugyan.com

書いていて気がついたのです、すぎゃーんさんは@t_wadaさんがきっかけで始められたみたいですね。

良かったこと

ほぼ毎日取り組めた

4月から新卒入社したので現在(2017/05/18)に到るまでずっと研修が続いているのですが、生活環境が変化しても継続出来たことは、習慣づけるためにとても良いことであったと思います。飲み会がある日は前日の寝る前にあらかじめ終わらせるなど、計画的に考えることが必要でした。

毎日開発に向き合う時間がある

ひどい時は空行を削除して「Remove empty line」というようなコミットもしていましたが、それでも意味はあったと思っています。というのも、個人開発は誰かに迷惑がかかるわけでもないので、自分のモチベーション次第では何ヶ月も放置してしまう可能性があります。空行を削除するだけでもプロジェクトに向き合う時間を作ることで、開発から意識が遠のくリスクはかなり軽減されたと思います。

悪かったこと

アウトプット量が少ない

毎日コミットすることだけを目的にしていたため、目的なく頭に浮かんだタスクを消化するという方法を取っていましたが、振り返って見ても大した進捗がほとんど出ませんでした。1回あたりの着手時間が少ない個人開発では、目的と締め切り意識をもち、短期間で集中してコードを書く必要があると感じました。

業務のContributionと混合させた

研修では個人のgithubアカウントが利用可能だったので、業務でコミットした日には個人開発に着手しない日がありました。業務に依存せずに毎日コードを書く習慣を身に付けることが大切だと思うので、後から混合すべきでなかったと感じました。

実践計画

すごい人達のベストプラクティスや『Write Code Every Day』の反省を活かし、個人開発や学習の計画を立てました。これまでの1.5ヶ月で習慣づけることは実践したので、これからは質が伴った習慣づけを行なっていきたいと考えています。

具体的にはスプレットシートにやりたいことのシートと作業計画のシートを作成し、1週間単位でゴールを設定できるようにしました。公開してあります。

docs.google.com

大きく分けて『開発』と『技術書』の2種類があり、それぞれを並行に進めていきたいと考えています。

開発では『Write Code Every Day』を今までのルールのまま継続し、ゴールを設定することで質を高めていきたいです。

技術書の項目では、今まで読みたいと思って積んでいる本がいくつかあるので、それを少しずつ消化していきます。インターネットで気になる記事を読むことも大切ですが、技術書を読んで体系だったまとまりでの知識を獲得する習慣を身に付けていきたいです。

最後に

やはり業務との違いは時間をしっかりと確保することの難しさだと思います。まずは確実にこの計画をこなし、少しずつ「学び続ける姿勢」の精度をあげていきたいです。

LPページを作る際のソーシャル設定のいろいろ

至近距離ガールVRというVRコンテンツのLPサイトを作り直したのですが、その際に行ったソーシャル設定の共有です。Twitter、Facebook、Google+を例に、以下の2点についての概略を説明します。

  • 投稿リンク(シェアリンク)
  • Open Graph Protocol

今回WordPress(WP)を使用していますが、初めての取っ掛かりとしては汎用的に使える内容になっています。

f:id:splas_boomerang:20170327023936p:plain

vr-locker.com

続きを読む