「Vagrant」の記事 - Crieit

Vagrant で Temporary failure resolving となる問題の解決 - イントラネット DNS 編

2021-05-19T09:57:20+09:00

Vagrant で Ubuntu の VM を立ち上げたとき、 apt 等を行おうとすると、以下のようなエラーに遭遇した。

client: Err:1 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libjpeg-turbo8 amd64 2.0.3-0ubuntu1.20.04.1
client:   Temporary failure resolving 'proxy.local.example'

上記のエラーの内容はプロキシに接続できないというものだが、問題のポイントはプロキシかどうかはあまり関係が無く、名前解決に失敗しているという部分だ。
こういうのはだいたい systemd-resolved のスタブリゾルバ周りの問題だと相場が決まっている。

…ということで、順番に確認しながら問題を解決していこう。

なお、使った box は generic/ubuntu2004 で、 VirtualBox で VM をホストしている。

スタブリゾルバの確認

まず、 resolv.conf を確認してみる。

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
nameserver 127.0.0.53

テキストファイルのコメントに書いてあるとおり、コイツを書き換えるのは悪手。

ネームサーバーが 127.0.0.53 を指しているが、これが systemd-resolved のスタブリゾルバだ。

ここで言うリゾルバとは、ドメイン名を元にIPアドレスを解決する仕組みのことを指していて、 DNS なども同様の機能を持っている。
その中でも、スタブリゾルバは、（「スタブ」と言うだけあって、）それ自身はドメイン名とIPの対応リストを持たずに、 DNS 等の他のリゾルバを呼び出して解決する仕組みをもっている、ローカルのサービスだ。
ローカルアプリケーションが直接 DNS を参照せず、一旦スタブリゾルバを参照することで、 systemd で管理された適切な DNS を自動的に参照されるようになったり、 DNS では解決できない hostname.local といったホスト名ベースの名前解決 (mDNS) を行えるようになっている。

さて、そのスタブリゾルバがどう動いているか resolvectl status で確認してみよう。

$ resolvectl status
[...]
Global
  Current DNS Server: 4.2.2.1
         DNS Servers: 4.2.2.1
                      4.2.2.2
[...]
Link 2 (eth0)
      Current Scopes: DNS
    DNSSEC supported: yes
  Current DNS Server: 4.2.2.1
         DNS Servers: 4.2.2.1
                      4.2.2.2
                      208.67.220.220
                      10.0.2.3

4.2.2.1 や 208.67.220.220 などが DNS に設定されているのがわかる。
これらは、いわゆるパブリックDNSだ。

実は、先ほど名前解決できなかったプロキシは、 LAN 内のサーバーだった。このため、パブリックDNSに問い合わせられてしまっては、名前解決ができないのも当然だ。

パブリックDNS はどこで設定されているのか

名前解決に失敗する理由はわかった。しかし、この DNS はどこで設定されているのか？

ざっと確認してみたところ、 resolved.conf の設定と、仮想マシン内の NAT を繋いだ NIC の netplan 設定に、それっぽい設定が書かれていた。

$ cat /etc/systemd/resolved.conf 
[Resolve]
DNS=4.2.2.1 4.2.2.2 208.67.220.220

$ cat /etc/netplan/01-netcfg.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      dhcp6: false
      optional: true
      nameservers:
        addresses: [4.2.2.1, 4.2.2.2, 208.67.220.220]

これらは通常の Ubuntu のインストールプロセスでは設定されないので、 generic/ubuntu2004 の box の作成者の味付けなのだろう。

これらの DNS のアドレスの設定を、プライベートネットワーク内の DNS のアドレスに書き換えてしまえば、きっと意図した動作に近づくはずだ。

スタブリゾルバを使わずに LAN内の DNS を指定する

スタブリゾルバは、細かい優先度合いの制御などを外から行えない。これはネットワークの状況に応じて最適調整してくれる設計だからなのだが、 Vagrant で立ちあげる VM のように、 NAT の DNS やローカルの DNS が混在していると、うまく調整できずに、こういった問題の解決がやりにくい。

スタブリゾルバを動かしているままでも問題なく動いているのならそれでもかまわないのだが、上記の DNS の書き換えを行ってもどうも意図通りに名前解決されない場合は、 systemd-resolved のスタブリゾルバを使わずに、 /etc/resolv.conf の nameserver を切り替えるようにしたい。

具体的には、 /etc/resolv.conf が ../run/resolvconf/resolv.conf へのシンボリックリンクになっているところ、 ../run/systemd/resolve/resolv.conf へのシンボリックリンクに書き換える。
こうすることで、 resolved.conf や netplan で設定した DNS が直接 /etc/resolv.conf の nameserver に書かれるようになる。
詳しくは、 systemd-resolved.service のマニュアルあたりを見て欲しい。

…と、このような書き換えを、 Vagrantfile の定義に書き落とすと、以下のようになる。
なお、以下は 192.168.11.1 がローカルネットワークの DNS のアドレスである場合の例なので、適宜書き換えていただければと。

config.vm.provision :shell, inline: <<-'SHELL'
    ln -sf ../run/systemd/resolve/resolv.conf /etc/resolv.conf
    sed -i -E '/nameservers:/{n; s/(addresses:).*/\1 [192.168.11.1]/}' /etc/netplan/01-netcfg.yaml
    netplan apply
    sed -i -E 's/(^\s*DNS\s*=\s*).*$/\1192.168.11.1/' /etc/systemd/resolved.conf
    systemctl restart systemd-resolved.service
SHELL

そうすると、 resolv.conf の中身が以下のように netplan の設定などから求められた DNS に置き換えられ、スタブリゾルバを経由せずに名前解決されるようになる。

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
nameserver 192.168.11.1
nameserver 10.0.2.3

このようになれば、ローカルの DNS でキチンと名前解決されるようになるだろう。

個人開発でサイトリリースした理由とやったこと

2019-10-27T15:10:52+09:00

こんにちは。ケイジです。
ボルジムというボルダリングジム検索ウェブサービスを制作し運営しています。

今回、このサービスをリリースするまでにやったことを綴ることによって、誰かの役に立つのではと思い記事を書きました。

なぜ創ったか

この数年、ボルダリング沼にとっぷりと浸かってしまい、週イチの社内ボルダリング部活動と週末の自主活動の週２回ボル活をするのが習慣になっています。たまにボルダリングができない週末があると気持ちも体も落ち着かずムズムズし週明けの仕事に差し支えるまでに。

また個人開発もしばらくご無沙汰していて何か創りたい欲がフツフツと湧いてきたタイミングでもあったので、エイヤ！とボルダリングジム検索ウェブサービスを創りました。
首都圏近郊のボルダリングジムの口コミなどの情報が閲覧、投稿できるウェブサービスになります。

ボルジム・首都圏近郊ボルダリングジム検索サイト

好きなこと ✕ 好きなことの掛け合わせだから、それはそれは楽しいだろうと。

やったことリスト

ボルジムを立ち上げるために、したことは以下のようになります。

プログラミング言語、フレームワークを選ぶ

以前はCakePHPでの開発経験はあったものの、ここ数年はWordPressのカスタマイズをメインに仕事をしているため、どの言語とフレームワークで開発するのかをまず選定しました。

候補に挙がったのは以下のフレームワークになります。
※カッコ内はプログラミング言語

Laravel（PHP）
WordPress（PHP）
Ruby on Rails（Ruby）
Django（Python）

選定にあたってはGoogleトレンドでまずざっくりと最近の検索結果の多いものをリストアップしました。

また、求人が多いフレームワークは今勢いのあるものだろうと推測し、国内と海外のリクルートサイトで求人数の多いもので絞り込みもしました。

結果、学習期間にあまり時間を使いたくないということで個人的なPHP慣れもある、LaravelとWordPressの二択になったのですが、開発の自由度の高いLaravelに決定しました。

環境づくり

環境づくりはできるだけ仕事で使い慣れているものを選択。

ローカル開発環境

Vagrant一択でした。

ソースコード管理

BitbucketでGitコードを管理。
現在はGitHubでプライベートリポジトリを作成できるとのことなので今選ぶならそっちになるかもしれません。

ウェブサーバ

さくらのレンタルサーバを使ってます。

サイトデザイン

いつも使い慣れているものを使いました。
パーツ、ロゴやイラスト制作は、Adobe IllustratorとPhotoshop。
サイト全体とUIデザインにはSketchを使用。

学習方法

Laravel学習法

Laravelについてはまったく触ったことがなかったので、ドットインストールのプレミアム会員になり、動画学習しました。

まず、Laravelをローカル環境で使うにあたって必要なSQLite入門をざっと一周します。

次に、Laravel 5.5入門レッスンをざっと１周して概要をつかみ、次に実際にローカル環境で手を動かしてチュートリアルウェブアプリをつくりながらもう１周しました。

ドットインストールは構成が初学者にとって非常に分かりやすく、動画一つが３分前後ととっつきやすくておすすめです。
Vagrantについても最初はこのサイトで学習しました。

プレミアム会員になると女性ボイスが選択できるのと、再生スピードが変更できるのが個人的に良い機能だと思います。

という感じでざっくりとLaravelについて理解が深まったところで、ララ帳「はじめてのLaravel」を参考にしつつ、実際にウェブサイト開発をしていきました。

分からないところは随時ググりながら進めました。
頻繁に使ったのはreadouble（日本語版Laravelドキュメンテーション）になります。翻訳してくれている有志の方々ありがとう。

英語に抵抗がなければlaravel documentationの方が情報も早く、デザインも見やすいためおすすめです。

まとめ

という感じのことを、休日や出勤前や後に細々と続けていき大体6ヶ月ほどかけてリリースまでこぎつけました。

この記事が少しでも読まれた誰かの一助になれば幸いです。

では、よいものづくりライフを！

LAN内ですぐに使えるPleromaのVagrant Box（構築済みゲストOSのひな形）を作った

2019-02-28T04:11:43+09:00

表題の通り。本記事の半分はインストール方法でできています。

Pleroma is 何

PleromaとはElixirで書かれた分散型SNSのひとつ．

GNU SocialやMastodonとも連携することが可能．Pleromaによればラズパイでも動く軽さが特徴．

※分散型SNSのPleromaをDocker+Macでローカルに構築する from てくてくぷれいす by しまさん様より引用

Pleroma用Vagrant Boxからサーバの立ち上げまでの手順

以下の手順はWindows、macOS、Linuxで共通です。ただし、Windows 10 Homeでのみ確認を行っています。

Oracle VirtualBoxをインストールします。ダウンロードページ
Vagrantをインストールします。ダウンロードページ
コマンドプロンプトなどのターミナルにて自分の好きなフォルダへ移動します。
下記コマンドを実行します。Vagrant Box（構築済みゲストOSのひな形ファイル）のダウンロードと登録、Vagrantfileという設定ファイルの生成が行われます。
vagrant init hidao/Pleroma099
テキストエディタで先ほどのコマンドによって生成された Vagrantfile の最後の end の前の行に以下の行をコピペします。
config.vm.network "public_network", ip: "192.168.0.221"
以下のコマンドを実行します。構築済みゲストOSのインストールが行われます。しばらくかかるのでコーヒーを淹れて待ちましょう。
vagrant up
ターミナルにプロンプトが表示されていればゲストOSが実行中になっています。ブラウザから http://192.168.0.221 にアクセスしましょう。

以上の手順でLAN内からアクセスできるゲストOS上のPleromaの準備が完了です。

ユーザの追加はブラウザからできますが、「つながっているすべてのネットワーク」に別のサーバを登録したいときには、ゲストOS内でコマンドを実行する必要があります。

その方法は他の記事に譲ります。

【重要】ゲストOSの停止方法

Vagrantでは、ゲストOSを停止させずにホストOSを終了しようとしたとき、ゲストOSが邪魔をしてホストOSのシャットダウンを中断させてしまいます。

そのため、ホストOSをシャットダウンさせる前に、起動したすべてのゲストOSをシャットダウンさせる必要があります。

ゲストOSのシャットダウン方法

ターミナルより、起動したゲストOSの Vagrantfile があるフォルダに移動して、次のコマンドを入力します。

vagrant halt

ゲストOSをシャットダウンさせた旨のメッセージが出たら、ゲストOSが正常終了されています。

ホストOSをシャットダウンさせる前に、すべてのゲストOSをシャットダウン（vagrant halt）するようにしましょう。

おわりに

Pleromaの環境構築用にdocker-compose等もありますが、あれはあれで癖があるのと、「構築済み環境が一発で立ち上がる」のを目標にVagrant Boxを作成してみました。

Vagrant Cloudデビューも兼ねていたので至らぬ点があるかもしれませんが、お気づきの点があるときはコメントまたはQiitadonのアカウント（@hidao）までご連絡ください。

それでは素敵なPleromaライフを！

初めてのウェブサービスを WordPress + Vue.js で個人開発した話

2018-12-06T00:00:50+09:00

はじめに

11月25日(日) に「にじさんじ配信スケジュール」と呼ばれるウェブサービスをリリースしました。

正確には初めてリリースしたサービスでは無いのですが、会員登録機能が用意された本格的なサービスを出した事がこれまでなく、実質的には初めてのサービスと呼んでも良いだろうと考えています。

という訳で、Crieit「個人開発サービスに用いられている技術 Advent Calendar 2018」6日目は「初めてのウェブサービスを WordPress + Vue.js で個人開発した話」と題して、開発に WordPress や Vue.js を用いたこと、ウェブサービスを作るまでの話や、リリース直後の話をしたいと思います。

n番煎じなテーマですし、蛇足に感じられる内容も多々あるかと思いますが、適宜必要な箇所をお読み頂ければ幸いです。

この記事の想定読者

これからウェブサービスを個人で作りたい方や開発中の方
ウェブサービスで実際に用いられている技術やツールを知りたい方
開発ノウハウを知りたい方
技術面以外の話にも興味がある方

開発経緯

「にじさんじ」と呼ばれるバーチャルライバー (VTuber) グループが存在しています。

僕はこちらのグループのファンなのですが、公式がスケジュール情報の発信を行っておらず、スケジュールを把握しにくい問題がありました。
スケジュール情報を発信する非公式サイトやアプリも存在していますが、閲覧がしにくく使い勝手が悪い状態でもありました。
そこで、スマートフォンでも十分に閲覧でき、にじさんじライバーの配信スケジュールに特化したウェブサービスを作れば需要があるのでは考え、開発に着手しました。

主な機能

元々はシンプルにスケジュールを確認出来るだけのシンプルなサイト開発を考えていましたが、
自分自身が必要十分に感じるレベル（このサービスユーザーのペルソナの1つは自分自身です！）に加え、サービスとして多くの方々に利用頂く事を前提に機能検討した結果、リリース時は以下の機能を実装しようという結論に至りました。

ユーザー向け機能

バーチャルライバー (VTuber) グループ「にじさんじ」メンバーの生配信スケジュールの閲覧
実際の生配信（ライブ）、アーカイブ情報の閲覧
ライバー情報の閲覧
ライバーのフォローを元にしたスケジュール等の情報閲覧（要会員登録）
配信時間前のメール通知（要会員登録）
Twitter へスケジュール情報まとめツイート
端末を問わず利用可能（レスポンシブ）
ネイティブアプリっぽいリッチなデザイン

運営者向け機能

スケジュール、ライブ、アーカイブ情報の自動取得（API、スクレイピング）
情報登録時のメール通知
管理画面

機能についての詳細

ユーザー向け

にじさんじは59名（現在は58名）と多くのライバーを擁します。
ライバー全体の情報を網羅しようとした場合の情報量は馬鹿に出来ません。
ユーザーごとに追っているライバーは異なるため、にじさんじ全体の情報をすべてのユーザーに一律に見せる事はユーザーの負担に繋がります。
また、にじさんじには「1期生・2期生（無印）」「ゲーマーズ」「SEEDs」という3つのグループが存在していますが、それぞれを追っているファン層は異なります。
さらに、グループ問わず人気ライバーを追っている方や、特定のライバーに搾って追っている方など、ユーザーの興味は多種多様です。

そこで、以下のフィルタリング機能を備えることにしました。

にじさんじ内のグループごと
ユーザーによるライバーのフォロー

フォロー機能を用意する場合、会員機能の実装は欠かせません。

また、当サービスを多くの方に継続的に使っていただくことを考えた場合、アプリっぽいデザインで使いやすい UI を提供する事は欠かせないだろうと考え、フロンロエンドを Ajax で提供することに決めました。

運営者向け

過去に情報の手動更新で苦労した経験があった為、情報の自動取得は欠かせませんでした。
また、テストデータを作成したり、自動化を行った場合であっても、情報の編集は適宜必要となる事から、GUI の管理画面の存在も必要でした。

使用技術・開発ツール

今回用いた技術・開発ツール

WordPress

開発フレームワークとして WordPress を用いた理由ですが、

見知った技術であること
データの CRUD 、ページ作成、ユーザー認証など、会員機能付きウェブサービス作成に必要十分な機能が揃っていること
管理画面が標準で用意されていること
「プラグイン」を用いて楽が出来ること
枯れた技術であること

上のようなものが挙げられます。

特に「管理画面が標準で用意されていること」は重要で、管理画面が必要な状況において、これがあるのと無いのとでは開発工数に雲泥の差が生じます。

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点ではありますが、検索を主体としたサービスでは無いため、あまり問題にならないと判断しました。

Advanced Custom Fields Pro

WordPress にてカスタムフィールドを扱う際 Advanced Custom Fields が欠かせません。
繰り返しフィールド（配列）を簡単に用いることが可能な有料の Pro 版を使用しています。

GUI でデータ構造や管理画面を作成する事ができ、大変重宝しています。
コードを書かずに済む作業は、書かずに越したことがないです。

WP-REST API

Ajax でのレンダリングを行う場合、情報元となる API が欠かせません。
以前は admin-ajax.php を利用して API を1から作る必要がありましたが、
今では WordPress コアに標準で API の機能が備わっています。WP-REST API を使わない手はありません。

jQuery

こちらも WordPress コアに標準で含まれています。
ユーザー画面においてもツールバーの描画に必要で、WordPress を用いる場合欠かせません。
また、後述する Semantic-UI のスクリプトも jQuery で出来ており、jQuery に依存せざる得ない状態です。

とはいえ、単一 DOM の表示切り替えといったシンプルな仕事は jQuery 向きであると言えると思います。
また、Ajax 用の仕組みも備わっており、上のような前提が存在する状況においては、別途 axios といったライブラリを用意しなくとも済む点は引き続き評価出来ます。

Vue.js

Ajax にて取得したデータを用いて画面を構成する場合、開発効率やコードの視認性、いずれを考慮してもビューとコントローラーの仕組みは欠かせないだろうと思います。

Angular, React, Vue.js あたりが採用候補にあたると思いますが、jQuery との併用可能な（最新バージョンを持つ）フレームワークは後者2つのみです。
元々 Riot.js を使っていた身として、またテンプレートエンジンライクな PHP 使いとして、 Vue.js の記法はとても親近感があり書きやすいものでした。
また、Vue CLI, Nuxt.js といった関連技術も充実しており、廃れる心配が少ない技術だろうという点も技術選定の後押しポイントになりました。

Semantic-UI

UI コンポーネントは Bootstrap が有名で、僕も用いたことがありますが、
あまりにも多くのサイトで用いられている事から見慣れてしまい、飽きを感じ始めていました。
そういった状況で Semantic-UI を見つけた時は感動したのを覚えています。

選定理由としてデザインの好みの影響は多分にありますが、UI パターンが Bootstrap 並に備わっており、技術者として実用に耐えうる UI コンポーネントであると感じています。

Twitter API

会員登録・認証に用いました。

利用に審査が必要となり導入敷居が上がりましたが、
Google 翻訳の手助けを得つつ簡単な英文で申請を行ったところ、サクッと審査がおりました。

また、Gianism と呼ばれる WordPress プラグインがあった為、認証に係る新規コードはほとんど書かずに利用することが出来ました。

YouTube API

YouTube のライブ、動画データを取得する為には欠かせませんでした。

動画 API は REST 形式でも提供されており、利用の敷居はとても低くなっています。

PHPMailer

メール通知の際にメール配信の仕組みが必要でした。

今回、サーバーはさくらインターネットさんのものを用いましたが、多くのスパム業者の利用実績の影響からか各プロパイダからの締め付けが強く、標準ポートでのメール配信は厳しいものがありました。

PHPMailer を用いると、Gmail といった各プロパイダからの受信規制の少ないサーバーを利用できるため、メール配信にあたり安心感があります。

さくらインターネットVPS + KUSANAGI

サーバーはさくらインターネットVPS（標準2GB） + KUSANAGI という形を取りました。

さくらインターネットVPS は国内サービスのため、契約周りでの安心感がありますし、国内サービスの中での信頼性は随一です。
また、ビジネス目的でのサービスでないため運用コストは抑える必要がありますが、従量課金で無く、不意な請求が絶対に起こりえない点もポイントでした。

KUSANAGI については WordPress サイトを運営する為に必要な nginx, PHP の設定がデフォルトで最適化されており、SSL 化に欠かせない Let's Encrypt も自動で走るなど、WordPress サイトを運営するために至り尽くせりな機能が OS レベルで備わっています。

heroku や Cloud9 といった PaaS に頼る手も検討しましたが、環境セットアップの安易さはそれらのサービスに劣らないことや、さくらインターネットの場合は VPS であってもスケールアップ可能といった特徴を持つことから、最初のウェブサービスはこの構成から始めることにしました。

VCCW

開発環境は VCCW を用いました。
VCCW とは Vagrant がベースの WordPress 開発に最適化されたツールです。
macOS での導入は一瞬でした。

PaaS ではなく VPS を用いた理由としては VCCW の存在も大きく、同梱された Wordmove で DB 含めたデプロイ（同期）が一瞬で完了するなど、VCCW を用いた際の総合的な体験がとてもスマートで感動しました。

実は、これまで Filezilla (FTP) を主なデプロイ手段としていましたが、どうして早く試さなかったのかと反省しています。

Visual Studio Code

コードはもっぱら Visual Studio Code で書いています。
これまで Sublime Text を用いていましたが、稀に落ちたり OS ごとの挙動差分が気になっていました。
Visual Studio Code は開発環境をベースとしており拡張性も高く安心感がありますし、動作が軽快なためストレスフリーにコードが書ける点がとても評価出来ます。

Google Chrome

開発関係のプラグインが豊富である事、検証ツールにてスマートフォンやタブレットの画面エミュレートが安易である点が良いです。

もちろん、最終的な動作確認の際は各種ブラウザ（Safari, Firefox, Edge, Opera, それぞれ最新）・OS（macOS, Windows, iOS, Android, それぞれ最新）でのテストも行っています。

Git

純粋にファイルのバージョン管理目的で用いました。

ちなみにホスト先は Bitbucket、クライアントには SourceTree を用いています。

Macbook Pro (13inch)

ハードウェアの好みで用いています。

スペックですがメモリ16GB、CPU Corei7 2.5GHz デュアルコア、SSD 512GBになります。

VCCW にて仮想環境を走らせる都合上、ある程度のメモリが必要となります。
8GB では処理が重く感じられる為、7月に new MacBook から移行しました。

メモ (Apple)

ToDo リスト機能が便利でした。

今回用いなかった技術・開発ツール

Gutenberg

WordPress のエディタにブロックの概念が導入され、レイアウトレベルで見たまま編集が行えるようになりました。その機能名の事を Gutenberg と呼びます。
WordPress 界隈においては有名な新技術ですが、Gutenberg を無効化する Classic Editor を入れ導入を見送りました。
以下のような理由からです。

今のところ新しい技術であり今後仕様が頻繁に変わるリスクがある
画面の表示要素を再利用したり、レイアウトを頻繁に変更したり、デザインを他人に任せたり、ユーザーに編集させたりといった、Gutenberg のメリットを享受可能な状況に置かれていない

Firebase

フロントエンド中心の開発の勉強も兼ねて用いることを考えましたが、自動化にあたってスクレイピングが必要で、サーバーサイド中心の開発にせざる得ませんでした。

Laravel, CakePHP 等の開発フレームワーク

複雑なデータモデルが必要であったり、検索が重要となるサービスを開発する場合は WordPress では限界があったと思いますが、そうではありませんでした。

Drupal, concrete5, baserCMS, Movable Type 等の CMS

前者2つについては、掲示板など会員管理周りの機能が充実している事やエディタのリッチさが売りかと思われますが、その点において今回メリットには感じませんでした。

baserCMS については、CakePHP がベースに採用されており、かつ管理画面も備わっている事から、開発者目線ではとても魅力的です。
今回は採用していないですが、データモデルが複雑で、管理画面もサクッと用意したいという状況においては、選ばざる得ない選択肢だと思われます。

Movable Type は WordPress 以上に一般サイト制作に特化しており、会員管理等の標準機能が弱い印象があります。

CDN

入れれば速くて良いのですが、コストが気になります。趣味のサービスには向かないでしょう。
今回は KUSANAGI (nginx + サーバーキャッシュ) に頑張ってもらっています。

gulp, babel, webpack 等のフロントツール

実はまともに用いたことがありません。（勉強せねば…）
ただ、これらのツールが活用できずともウェブサービスを開発し運用を開始出来る状態になる事が分かります。

初心者はWebpackの事は一度忘れた方が良い - Crieit

AMP

文章や写真ベースの記事がほとんど無く、JavaScript に頼るページも多く導入は見送りました。

ただ、Vue.js でのレンダリング結果を Googlebot が拾ってくれない都合で、Vue.js のレンダリングが完了するまでは SSR の結果を表示する仕組みを入れた事で、JavaScript に頼るページがほとんど無くなりました。

AMP を導入した場合 SEO 効果も期待できるため、後々導入する可能性があります。

PWA

アプリっぽい見た目にした事や Ajax での情報取得は PWA 化を見越しての方法でもありました。
一旦 apple-touch-icon の設定でお茶を濁しましたが、AMP 同様後々導入する可能性があります。

Docker

VCCW のお陰で、動作環境としては Linux ベースで開発が出来ており、本番サーバーに環境も近いはずで、環境を揃える意味ではほとんど不要だろうと考えていたのですが、本番リリース直前に本番でのみ発生する不具合に見合わされました。
始めから Docker ベースでの開発であればそのような悩みも発生しなかっただろうと思います。
今後の新規開発の際に導入を検討する可能性がありそうですが、費用を中心に何かとコストが増えやすい為、趣味のサービス開発での導入は難しそうです。

開発やリリースで苦労したこと

上で記載した以外の点について触れたいと思います。

類似サービスの登場

開発開始からわずか数日ほど経ったタイミングで、VTuber のスケジュールを扱うサービスが登場しました。

一見デザインも綺麗で、にじさんじ以外も含め、様々な VTuber のスケジュールが登録されています。

ただ、スケジュールが不十分な部分があったり、にじさんじ好きにとってはノイズとなる情報も多いなど、欠点や方向性の違いによる差がある事も分かってきました。

当初の目的を常に意識しながら、なんとかリリースする事が出来ました。

Twitter アカウント凍結

現在 @nijisanji_net というアカウントを用いていますが、元々はドメイン取得時に別のアカウント名で作成し放置していたところ、何故か凍結の事態に…

このような事は初めてでしたが、凍結直後に気づくことが出来ず、凍結解除申請も虚しく現在も凍結されたままになっています。

惜しかったですが、思い切って別アカウントを作成し事なきを得ました。

スクレイピング

スクレイピング対象に想定外のパターンの文字列が混ざった場合、データに不具合が発生します。
中にはスクレイピング先情報の typo など、どうしようもないものもありますが、
大きなデータ崩れが発生しないように抑えるべく、多くの分岐処理が必要となりました。
スクレイピングは本サービスのコア機能になりますが、最も実装に時間のかかった部分でもありました。

Google Search Console

リリース直前に noindex,follow 指定で本番環境でのテストを行っていた影響で、この記事を書いている現在もエラーを吐く状態となっています。
当初は別に問題があるのではといろいろ試したのですが、不慣れのため、単純な時間の問題だろうと気づくまでにとても時間がかかりました。

Googlebot 上で Vue.js が機能しない

Search Console 上の問題もあり、時間が経つまでの検索インデックスは DOM に頼るしかない状態となっていましたが、
その問題に追い打ちをかけるように Googlebot 上で Vue.js が機能しない問題にぶち当たりました。

Googlebot で JavaScript を解釈できる事は知っていましたが、Vue.js など一部のスクリプトが正しく認識されない問題についての知識が無く、これには参りました。

結局 Vue.js で出力される内容をサーバーサイドレンダリング (SSR) させ、 Vue.js が読み込まれるまでの間の表示をサーバー側に任せる事でなんとか事なきを得ました。

開発期間・工数

9月9日に開発を開始し、11月25日に公開しました。
開発期間は約3ヶ月、累計作業工数は142時間でした。

工数について

当初はせいぜい数十時間で終わるだろうと見込んで開発を開始しましたが、実際はサービス開発を行いながら仕様を詰めており、当初の想定よりも機能が増えたことから、予定よりも工数が嵩んでしまいました。

また、作成していたプログラムの不具合の影響で、手動で作成していたライバーデータを全て別データで上書きしてしまったのですが、そのライバーデータの作成に10時間近くかかっており、再度同様の工数が発生しました。

さらに、リリース直前に発生した本番環境限定の不具合もあり対処に10時間ほど時間が取られてしまいました。

実際にかかった時間と比較し20時間〜30時間ほどは短く出来たのではと思います。次に活かしたいです。

余談ですが、改めて2つ歳下のせせりさんのすごさを実感しました。

「1人で6時間で作った」　Twitterで匿名質問「Peing」人気、月間2億PV超えへ - ITmedia NEWS

開発以外で取り組んだこと

他の趣味活動の制限

ポッドキャストやブログでのアウトプット、仲間との Discord など、日常的に様々な趣味活動を行っていましたが、業務、他のプライベートでの活動も含め忙しく、削れる活動は制限する事に。

もちろん、万人が意識する事でも無いと思いますが、忙しい社会人が開発を継続していく為には、多少他の活動を制限する覚悟が必要だと感じています。

息抜きは欠かさない

とは言いつつも、仕事も開発、プライベートも開発で休み無しという状況では、つらい日々が続きます。

趣味のアニメ視聴時間は一切削らず、本サービスで扱っている VTuber 動画の視聴時間もある程度確保した事は、
モチベーションの維持に大きく貢献しただろうと思います。

開発者コミュニティへの加入

運営者ギルドのメンバーとなりましたが、他のみなさんの発言は「自分も頑張らないと」という刺激になりました。

リリースしてからの気付きや変化

アクセス数が気になって落ち着かない

公開から数日たった現在は多少慣れましたが、公開1日目は気づいたら Analytics の画面を見ている状態で本当に落ち着きませんでした。

運用に時間が取られる

理論上は自動化出来ているため、運用に時間が取られることも少ないだろうと考えていましたが、実際は更新ツールの不具合を修正したり、データを一部手直ししたり、アクセス数を増やすための SEO や PR を行ったりと、100%の自動化は中々難しく今後の課題であると感じています。

WordPress + Vue.js を用いてどうだったか

WordPress

サービス開発においても使用感は悪くなかったです。

そもそもとして、開発フレームワークではない WordPress を開発に用いる事に対する心配をお持ちの方は多いと思われますが、上に記載した通り

データモデルの構造上、複数のデータ項目への検索実装が難しい点が弱点

問題はこの程度だと考えています。

大規模な開発になった際に、規約が少なくコードの品質が担当者間で不揃いになりやすかったり、
データモデルの都合上パフォーマンスの問題も出てきますが、
個人開発レベルにおいてはほとんど心配する事ではないだろうと思いますし、
現実的な対策は十分可能ですので今後業務の開発でも用いると思います。

Vue.js

リリース後に SEO 面の問題が発生した為、フロントエンド技術に頼った開発は難しそうだと実感させられました。
ただ、今回のようなサーバーサイド技術との併用であれば小回りも効くため、十分実用的ではと思います。

WordPress と Vue.js の併用

下記2点があり、併用には全く支障がありませんでした。

WordPress 標準で API が提供されている
WordPress コアに含まれている jQuery と Vue.js が併用可能

その他

Semantic-UI と Vue.js のかみ合わせがあまりよろしくなく、
Semantic-UI 内の JS ライブラリで作成したフォームの value が Vue.js 側で上手く取得できませんでした。
Semantic-UI に value を直接返す関数が提供されておりどうにかなりましたが、
サードパーティ製ではあるものの Semantic UI Vue と呼ばれる UI コンポーネントも存在している事から、今後はそちらを使っていく可能性があります。

これから取り組みたいこと

サービスの継続運用、機能拡張

一部不具合も残っているため、それの改善も含めた継続的なサービス運用を目指したいです。
また、ある程度機能を絞ってリリースしており、残りの機能もしっかり開発できればと考えています。

数字、結果

現状、Twitter のフォロワーは 50 に満たず、まだ SEO の効果も出ていないことからアクセス数はご察しのとおりです。
趣味のサービスのため、数字や結果が最優先ではありませんが、折角ですのでにじさんじファンの半数程度（数万人）に利用して頂けるサービスを目指せればと考えています。

別サービスの新規開発

上で記載の通り、継続運用の為の対策を打ったり、機能拡張も計画しており、新規着手までは中々骨が折れそうですが、平行開発も踏まえ新しいサービス開発にも取り組めればと考えています。

ありそうな質問

仕様書や設計書はきちんと書いたの？

ぶっちゃけるとほとんど書いていません。要件を前述のメモ (Apple) に数行書いた程度です。

上記の機能一覧
コード上の役割分担
- 投稿タイプ、API、情報フィルタリング、テンプレートなどデータ定義・表示制御は「nijisanji」と呼ばれるテーマが担う
- YouTube API へのアクセス、スクレイピングなどデータ更新は「nijisanji-cron」と呼ばれるプラグインが担う

代わりにコードへのコメントはしっかり入れています。
また、可能な限り WordPress コア標準の仕組みを用いています。
さらに作業中に発生した不要なコードやデータは逐次削除するなど、
仕様書が無くとも現状の確認で全体像が見えやすい工夫を行いました。

趣味の個人開発だから出来ることだと思います。

念の為補足ですが、余裕があれば情報は残すに越したことは無いと思います。

広告は入れないの？

数年前に月間数十万PVのサイトを運営していた事もありますが、 Adsense も大した額にはなっていませんでした。
本サービスでも同等のアクセス数が稼げれば広告の導入を検討しますが、利便性も下げますので、導入は慎重に判断したいと思います。

事業化はしないの？

そもそも趣味のサービスですし、権利問題も絡みますので考えてないですが、公式関係者の方々にも使って頂けるサービスにはしたいと考えています。

おわりに

自分のような素人の書いた記事が参考になるのだろうか、と思う節もあり、中々重い腰が上がらなかったのですが、

すごいですね～。個人開発はじめたい人とかだとどうやってるか知りたい人多いかもしれないので、もし気が向いて且つ12月もたまたま無茶苦茶暇だったらカレンダーも是非ｗhttps://t.co/iGA3PpFL6U
— だら@技術系投稿サービス運営中 (@dala00) November 26, 2018

Crieit のだらさんに直接お誘い頂き執筆するまでに至りました。
改めてお誘い頂きありがとうございました。

何かしらの Advent Calendar への参加は初となりますが、夢でもあったので参加出来たことはとても光栄でした。

また、これからウェブサービス開発を考えている方や、ウェブサービス開発中の方の一助になれば幸いです。

ご質問、ご指摘、アドバイス大歓迎です。コメントや @sola_io までリプライ、お気軽にお寄せ下さい。

ここまで読んで頂いたすべてのみなさま、本当にありがとうございました。

個人開発サービスに用いられている技術 Advent Calendar 2018、明日は Hiroz さんの「Koretteのオモテとウラ」になります。
そもそも「Korette」って何？というところも含め、とても気になりますね。