Rentio で Nreal Ari をレンタルし、試してみました。

1日コワーキングスペースで利用してみたので、その感想を書きます。

自分が期待すること

自分がディスプレイの代替として AR グラスに求めることは次のとおりです。

1. 複数画面を出力できること
2. ディスプレイの解像度が大きいこと
3. ディスプレイを縦回転できること

1はマルチモニタ環境の構築です。私はシングルモニタよりもマルチモニタ環境を好みます。自宅ではトリプルモニタで仕事をしているため、できれば3画面あるとベストです。Nreal Air は2022年9月のアップデートでMacで3画面まで対応してので今回試してみました。

2はディスプレイの大きさですね。より詳細には1画面あたりの情報量を多くしたいです。Macbook Air の画面は小さいと感じてしまうため、できれば24インチ相当の画面の大きさ、情報量がほしいです。

3はIDEの利用のためです。私は普段はモニタ2枚を縦に配置してエディタを開いているのでそれを実現させたいです。

使ってみた感想

結論としては、現時点では自分の期待することが実現できない + 長時間利用は合わない と感じ、実用は難しい印象です。しかしARでしっかり画面が映し出される点は非常に将来性を感じました。あと5年ほどの進化で十分に実用に耐える形になるのではないでしょうか。

メリットとデメリットをそれぞれまとめました。

良い点

• 画面は普通に見える
• AR なので周囲の状況が見える
• 目線を上がることができ首が楽

悪い点

• 大解像度にはならない
• 画面の回転はできない
• ライトシールドを着用すると画面のちらつきを感じる
• 長時間つけると鼻が痛くなる

画面は普通に見える

AR グラスを初めて体験しましたが、画面は普通に見えます。正直感動しました。ディスプレイの視認自体に問題はありません。モニタの代替として使用できます。

以前マイクロソフトの Hololens をつけたとことがありますが視認性の次元が違いました。Hololens は視界の上半分に心もとなく画面が表示される程度です。しかし Nreal は完全にディスプレイが表示されます (伝えるのが難しくすみません)。そもそも Hololens はMRデバイスであり、画面をスマホのように指で摘んで操作することができます。そのためディスプレイの点のみの比較は妥当ではないかもしれません。

AR なので周囲が見える

これはシンプルに便利です。少しスマホをいじったり、飲み物をとって飲むことができます。VRゴーグルにできない芸当であり、ここはARグラスにアドバンテージがあります。

目線を上げることができ首が楽

素晴らしい利点だと思います。Nreal Air では空中の好きな位置に画面を固定することができます。自然と正面を向いた状態で固定でき、首への負担はかなり軽減されます。

大解像度にはならない

ここは期待していたために少し残念でした。

解像度の選択肢は2つあります。

• 1440 × 900
• 2880 × 1800

1440 × 900 はMacbook Air の標準ディスプレイと同じ大きさです。こちらの解像度では1画面あたりの情報量は増えません。

2880 × 1800 の設定は使い物にならなりません。画面サイズに対する解像度が大きすぎます。文字等がとても小さくなり視認できないません。結果、実用に耐えません。

ただ、画面サイズ自体は大きく表示されるのでそれは良いと感じました。1画面あたりの情報量は変わりませんが、単純に大きいディスプレイで作業することが可能です。

この解像度に関してはソフトウェアのアップデートで対応できる部分と感じるため今後に期待です。

画面の回転はできない

ディスプレイの回転はできません。Mac のディスプレイ設定内に「画面を回転する」が表示されません。

こちらはソフトウェア側で対応可能なのかはわかりませんが、今後のアップデートに期待しようと思います。

ライトシールドを着用すると画面のちらつきを感じる

Nreal Air には野外など外部の光が強い環境向けにライトシールドというシェードが用意されています。

こちらをグラスのレンズ部分に装着することにより、外部の直射日光の影響を受けずにディスプレイを視認することが可能です。

しかし私の場合はライトシールドを着用すると画面のちらつきを感じました。うまく説明できないのですが、ピントが合っていないと・解像度が合っていないような感じになります。

長時間つけると鼻が痛くなる

実用する上で一番デメリットに感じた点になります。長時間使用すると鼻のあたりが痛くなります。

重さによる影響で痛くなっているとは感じません。Nreal Air は 79g と軽量です。一般的な眼鏡は 30g 程度です。50g ほど差がありますが、つけていて重さが気になったタイミングはありません。

鼻当ての形状や材質に起因しているように思います。こちらも将来的に楽になれば大変嬉しいです。

終わりに

AR グラス自体が初体験でしたが、空中にディスプレイが表示されていることには感動しました。しかもしっかりと視認できるので技術の進歩に感服です。

記事内にも書きましたが5年ほどでモニタを代替できるレベルになるのではないでしょうか。今後の進化が非常に楽しみです。

つまり、10分前の私のことです。

はじめに

私のデスク環境には、横モニター1枚 + 縦モニター2枚 の計3枚のモニターがあります。しかし M1 Macbook を使用するときは、横モニター1枚と縦モニター1枚の計2枚の使用に制限されていました。1枚の縦モニターには光が宿されていません。

これは M1 Macbook + DisplayLink では、DisplayLink を通したディスプレイは縦回転できないと思っていたからです。ここで、あえて「思っていた」と書いてある点に注意してください。そう、これは思い込みだったのです。今思えばそんなばかなと言いたくなるほどの、しかし何者かに仕込まれたと考えざるをえないほどのまやかしを、私はまんまと信じてしまっていたのです。

一体いつから縦回転できないと錯覚していた？

あなたが幾度となく打ち込んだであろう「DisplayLink 縦」で Google 検索 or Twitter 検索をかけると、2つの情報が出てきます。それは縦回転はできないという情報と、縦回転はできるという情報です。特に後者は Twitter でしばしば目にすることができます。M1 発売当初は縦回転ができなかったことは事実のようなので、どちらの情報も間違っていないでしょう。当初はできず、あるときから修正され、M1 + DispLaylik でも縦回転ができるようになった。

ところが、誰もその方法を書いていないのです。これにはビビリちらかしました。まるでだれかが裏で糸を引いているように、どこまでどこまで調べても、いくらネットの深淵を覗こうとも、一向にディスプレイを縦回転させる方法が書いていないのです。これはガチです。某当局の規制を思わせる、いやそれ以上に鮮やかに、暗闇の奥へと隠されているのです。やっとみつけることができた「縦回転できます！わからなければ連絡してください！」「縦回転できました！〇〇で調べると出てきます〜」の書き込み、いや書いてくれんか！！！その方法を！！お願いだから！！！、、、もしかして幻なのか？そんな方法は最初から存在せず、自分は一生その方法にたどり着くことなどできないのではないか？であるとしたならば、この一連の活動は Stand Alone Complex 以外の何物でもなく、それが指し示す意味とは一体、、、？？

ここまで妄想が膨らみました。というか半分信じていました。それほどまでに本当にどこにも書かれていなかったのです。

それでもたまたま DisplayLink まわりを試行錯誤していた所、ついに見つけることができたのです！ディスプレイを縦回転させる方法を！

M1 Macbook  + DisplayLink でディスプレイを縦回転させる方法

ついにこの方法を公開します！何者かによって隠された、いやもしかしたら最初から隠されてなどいなかったかもしれない、事実上門外不出となっていた方法を白日の元に晒します！このインターネットという広大な海に解き放ち、情報を個から public にし、もう二度と「DisplayLink 縦回転 できない」という検索が起こることないよう、検索バーの門をくぐることがないようにするときが来たのです！

しかし、ここでもい一度よく考えてみましょう。果たして本当に、いままでディスプレイを縦回転させる方法をインターネット上に書き込んだ人は誰もいなかったのでしょうか？常識的に考えてみると、この現象はにわかには信じられません。なぜなら、ニーズはあるからです。M1 Macbook を使用していてモニタを縦置きで使用しているユーザーは一定数います。ネットで検索しても「M1 Macbook + DisplayLink」の記事は容易に見つかりますし、その中には縦回転に挑戦している記事もあります。そのような中で、誰か1人でも、縦回転に成功し、ブログに書き込めばよいのです。手順を示したスクリーンショットを Twitter に投稿するでもかまいません。しかし、これらは起きなかった。少なくとも、自分の観測範囲内では観測できなかった。これはいささか不自然ではないでしょうか？

とすれば答えは1つ、そう、消されているのです。ついに縦回転に成功し、悲願が成就された達成感を味わい、感動冷めやまぬままにそれを公表した人は、過去にはいた。しかし、何者かに消されてしまうのです。我々の希望となる投稿（つまり何者かによっては絶望となる投稿）は削除され、二度と同じことが起きないよう、リスクは排除されるのです（一体何が行われるのか、具体的な内容はみなさんの想像におまかせします）。その結果、DisplayLink 縦回転界隈ではその方法を公表することができず、可能であるという事実のみを示唆するにとどまっているのです。なぜ消されるのか、その本当の目的はわかりません。しかし事実として、DisplayLink を使用したディスプレイの縦回転の方法が公表されない構造はこうなのです。

つまり、自分で気づくしかないのです。そうです、方法はあります。ここまでは明言できます。しかしその先は掴み取るしかない、自らの手で。誰だって命には代えがたい。自らの行いにより救われる何かがあったとしても、所詮は自分の命がかわいいもの。しかも今回は、その救われる何かとは、しかたなく横置きで使用していたモニタを縦置きできる程度なのです。90度の転換。一体誰が責められると言うのでしょうか。それらほんの少しの価値を提供するために、一体誰が命を投げ打つというのでしょうか。ことなかれ主義にのまれ、Macbook Pro を買えばよいではないか、将来的な Apple の対応を待てばよいではないか、そう言いたくなるのが人情というものです。

DisplayLink を使用してディスプレイを縦回転する方法は、あなたの中にあるのです...

...

...

すみませんでした

とんだ茶番にお付き合いいただきありがとうございました。普通に縦回転させる方法を書きます。もし私が音信不通になることがあれば、今度はあなたがキーボードを手に立ち上がってくれることを祈っています。

方法は、以下です。

1. DisplayLink Manager の設定を開く
2. Display rotation and toggle の値を変更する

1は Mac の Menu Bar にあるアイコンをクリックすれば開くはずです。

こんなところにあったんですね〜。

Display rotation and toggle が表示されないとき

以下を試しましょう!!

1. macOS を Monterey 以降に Update する
2. 最新の DisplayLink ドライバを DL する

縦回転に対応したのは Motenrey 以降のようなので、Update していない人はしましょう。

最後に

でも自分はいまだに Stand Alone Complex 説を信じています。

どうかこれで、二度と私のような人が現れませんように。

Slack に絵文字を追加するWebサービスを開発しようと思い、調べた内容をまとめます。

開発しようとしているサービスは Slack の絵文字を管理し、ワークスペースに一括 import できるサービスです。個人的には絵文字の重要度を高く捉えており、コミュニケーションにおいてテキスト以上に情報量があります。例えば、「良いと思います」よりも「良いと思います👍」の方が相手が受け止めやすいと感じます。前者だと冷徹さ高圧的な印象を自分は感じてしまうのですが、後者では一転して肯定メッセージと素直に受け取ることができます。

このようなサービスを開発しようとしているのですが、調べてみるとSlackの絵文字追加まわりが複雑な状態になっていたので一旦まとめます。

1.絵文字を1個ずつ追加する

最初に絵文字を1個ずつ追加する方法を紹介します。

1個ずつ追加する方法は2つあります。1つ目は公式のSlack APIを利用する方法です。2つ目はSlackの非一般公開APIを利用する方法です。

上手く言語化できないが、後者は筆者にとって少し抵抗があります。非公開にしているということはもちろん外部から使用されることを想定しておらず、何かの理由で訴えられても文句は言えないです。しかし後者の非公開APIを公開にしてほしいとの GitHub issue で立てられていたりと、非公開ながら認知度はある程度あるように感じます。

1-1 Slack API の admin.emoji.add の利用

1つ目の方法は、王道に Slack API を利用する方法です。

admin.emoji.add API method

Add an emoji.

Slack APISlack

この方法は1つ欠点があり、それは Admin 権限の API トークンが必要なことです。具体的には admin.teams:write 権限が必要であり、この権限はワークスペースを変更することができます。

たかだか絵文字を追加するために Admin 権限を渡すのは非常にリスキーです。また、そもそもAPIキーの登録が必要な事自体、ユーザーからしたらハードルが高いです。

王道な方法ではあるのですが、このAPIを元にサービスを組み垂れるのは現実性が低いように思います。

1-2 非一般公開APIである /api/emoji.add の利用

2つ目の方法は Slack の非一般公開の API を利用する方法です。

この方法は以下のようなプロダクトでも使用されています。

• Natural Face Emoji Tools
• decomoji
• slack-emojinator

方法としては、 /api/emoji.add というエンドポイントを使用します。実際に叩くパラメータや実装例は Natural Face Emoji Tools のコード がわかりやすいので参考にしてみて下さい。

このエンドポイントでは xoxs と呼ばれている専用トークンを渡す必要があります。こちらも方法が2つあるので紹介します。

CSS セレクタから API トークンを取得

この方法は Natural Face Emoji Tools で使用されています。コードはこの部分です。

document.querySelectorAll でコードを取得し、正規表現で値を取得しています。

window.boot_data.api_token から API トークンを取得

この方法はオブジェクトから直接 API トークンの値を取得します。decomoji で使用されており、コードはこの部分です。

2.絵文字を複数追加する (できない)

なんとSlackには絵文字を複数追加する方法がありません。まとめて追加したい場合、1個ずつ追加するAPIを複数回叩くこととなります。

こればっかりは方法が用意されていないので諦めるしかありません。

終わりに

非一般的APIを利用するかは個人の判断に任せますが、今回はここまでとしたいと思います。

Slack さんには以下の2点をお願いしたいです。

1. Slack API に 絵文字の bulk insert API の追加
2. せめて Admin ではなく最低レベルの権限で叩けるように

参考文献

• Slack Custom Emoji を追加する非公開 API /api/emoji.add
• APIトークンなしでslackの絵文字(emoji)を一括エクスポート＆インポートする
• Slackに日本語絵文字を大量に一括登録する方法
• Slackに大量の絵文字をコマンドラインで登録する方法
• Neutral Face Emoji Tools
• decomoji

私、気になります。🍨

というわけで、東京税理士会の税理士の方に相談していきました。その結果を書きたいと思います。

注意事項

この記事は、これから記述する内容を保証するものではありません。あくまで参考として利用し、実際には自己責任でお願いします。

まず、自分が理解が間違っている可能性があります。説明を受けた内容をメモしたものであり、税理士の方の回答書面や参考書の内容を記述しているわけではありません。

また、今回の相談では深い内容までは検討していません。今回は東京税理士会の無料相談という枠を使用しました。その名のとおり相談であり、税理士の方にも一般としてはこう、という形式で伺っています。

人によってユースケースは異なるため、実際に行動に移される場合は専門の方に相談することをおすすめします。

背景

まず、なんでそんなこと聞いてきたの？という私情の部分を書きたいと思います。完全に自分語りのパートであり、結果だけが気になる方は飛ばして頂いてかまいません。

自分自身、海外に住んでみたいという想いがあります。理由は3つくらいあります。

1つ目は価値観を広げたいからです。人生は長く、いつか死んでしまいます。自分は死には恐怖からあまり向き合えていないですが、人生には真剣に向き合いたいと考えています。人生は、色んな価値観を持っていたほうが楽しめそうですし、より良い人生が送れそうです。あまり言語化できていませんが、人生には真剣に向き合いたい、少なくとも現状のまま終わっていく気は自分の中にはない、という想いが強いです。

2つ目は単純に海外に行ったことがないので行ってみたいです。興味です。厳密には幼少のころに家族旅行でハワイに行ったことがありますが、遥か遠くの出来事すぎてSPでテリーのワンダーランドをしていたことしか覚えていません。仮に覚えていたとしても、大人になってからの海外ではまた感じることも異なるでしょう。

3つ目は英語です。英語の読み書きができれば、人生の幅は一気に広がります。対人コミュニケーションの面でも、情報収集の面でも有利でしょう。機械翻訳の発達が著しいという側面もありますが、最初にテキストの壁が解消されるのはいつになるかわかりません。コミュニケーションの壁の解消はもっと先になるでしょう。正直、英語を学ぶことによって一気に人生が良くなるイメージは抱けていませんが、より良くなることは確実だと考えています。

というわけで海外に行きます。

するとどうやって行くんだとう疑問が出てきます。調べてみると有るじゃありませんか、ワーキングホリデーという神制度が。制約といえば年齢制限くらいで、問答無用で1~2年ほど滞在できます。ワーキングホリデービザ以外ではそうもいかないとのこと、利用するしかありませんね。1ヶ国あたりの滞在年数は短いですが、ワーキングホリデー加盟国をはしごするという技術を使用することにより、トータルで英語圏に長期で滞在することが可能です。合法的に海外へ滞在することが可能、素晴らしい制度です。

ワーキングホリデー第一弾の国はオーストラリアに決めました。理由は英語圏であることと、日本との時差が少ないためです。

次の問題として、じゃあ仕事はどうするねんという最もクリティカルな問題が出てきます。これに関して、自分はエンジニアのフリーランスを継続するという形を取るつもりです。現在は日本で業務委託で働いているのですが、海外に行ってもその仕事を継続するつもりです。端的には住んでいる場所が変わるだけのイメージです。実際にはクライアントさんとエージェントさんへの相談は必須ですが、どちらも不都合はないはずと考えています。ここで重要になるのが時差です。時差がかなり離れているとMTGにほぼ出席できないなど、日本チームとの乖離が発生し、特別対応の必要が出てきます。しかしオーストラリアの時差は+1時間（サマータイム時は+2時間）のため、自分の稼働時間をズラせば日本の勤務時間に合わせることは十分に可能です。もしダメなら現地でアルバイトをします。それも良い経験になると想います。究極的には貯金を切り崩し、人生の休暇期間としても良いでしょう。

さて、そろそろいつになったら税金の話が出てくるんだという疑問をお持ちでしょう。今お出しします。そうです、ここで思い当たるのが税金です。日本で仕事を受けながら、海外に住む、これはいわゆるノマドという働き方に近いです。ノマドをしたくて海外に行くわけではないのですが、結果的にやっていることは同じです。その場合、税金が問題となります。働いて得たお金の税金は日本に納めるのか？オーストラリアに納めるのか？収入元の仕事は日本ですが、実際に働いている場所はオーストラリアです。一体どっちに納めるべきなんでしょう？調べた限りではどちらにすべきかわからりませんでした。

というわけで今回税理士さんに聞いてきました。なんか人生とか言っているし、背景が長い。少し語りたかったんです。大目に見てください。

前提

今回の前提をまとめると以下です。

1. 仕事は日本の業務委託を継続する
2. オーストラリアで仕事を受ける予定はない
3. オーストラリアでの滞在期間は1年以内

先に言ってしまうと、1と2は所得税に、3は住民性に関わってきます。

結論

結論としては、「今回のケースでは日本でのみ収めればOK」とのことでした。

今回の論点となる税金は所得税と住民税の2つです。（見逃しがあったらすみません🙏）

所得税に関しては、納税方法が2つあるとのことです。

1. 自分で納税
2. 納税管理者により代理納税

1はそのまま、自分で納税する方法です。この場合、納税のために帰国する必要があります。法律的には「居住者」に対して課税であり（間違っていたらすみません🙏）、日本から納税しないと辻褄が合わないためです。ただ、納税のためだけに帰国することは相当コストがかかります。そのため、実務的には e-Tax でも問題はないだろうとの私見をいただきました。※あくまで私見であり、保証するものでは有りません。ここに関しては自分も、やっていることは同じなので問題はないと考えています。国からすれば、日本に住んでいないのだから納税しないという解釈も有り得る中、納税をすると言っているので問題はないでしょう、という考え方です。現地納税とe-Taxでそこまで違いが有るとも思えません。そのため、自分は海外からe-Taxで納税するつもりです。

2に関しては、納税管理者を登録し、その人に納税してもらう方法です。納税管理者には家族や友人、税理士を登録することができます。無難に家族を登録するか、難しければ税理士の方に依頼することが確実でしょう。この場合、申告は自分で行う必要があります。あくまでも税金を納める作業を代理してもらうのみであり、税金の申告作業は自分で行います。納税するお金は相手の口座に振り込みましょう。もしかしたら税理士の方を登録する場合は、申告も依頼できるかも知れません。その場合は別途料金が発生すると想いますが、相談してみてください。

住民税に関しては、今回のケースでは1年分を払う必要があります。詳しい内容はこのあとのQ & Aに譲ります。

Q & A

以上が記事タイトルの問いに対する回答ですが、その他聞いた内容を Q & A方式でまとめます。何を基準に判断したら良いの？など、回答の背景を書いているので、気になる方は見てみてください。

日本で納めるか海外で納めるかの基準は？

基本的にはどちらで仕事を受けたかで判断して問題ないと思われる。日本の仕事であれば日本に納め、海外の仕事であればその国で納める。

日本と海外の両方で仕事を受けた場合は？

より複雑なため、税理士の中でも海外に強い専門家に聞くことをおすすめする。

具体的には、各国と日本が結んでいる租税条約というものが絡んでくる。租税条約は法律の原則を飛び越えるため、ユースケース毎に精査する必要がある。

さらに日本の場合は海外の仕事の所得税も払わなければならない (全世界所得)。海外で税金を納めたことを証明できれば、控除することができる (2重納税の回避)。

住民税は1年分払わなくちゃいけないの？（1月 ~ 4月 だけいたら、その期間だけ払うとかはできないの？）

1年分を払う必要があります。

住民税って海外にいても払わなくちゃいけないの？

以下の3点が論点となる。

1. 1月1日に日本に住んでいるか
2. 住所は日本か
3. 1年以上不在になるか

ここはこれ以上詳しく聞かなかったので、上記を手がかりに調べてみてください🙏

個人事業主ではなく、法人の場合もここに書かれたような判断で良いの？

専門家へ聞くことをおすすめする。法人となるといろんな手段がありややこしく、ユースケースに応じて専門家へ相談したほうが良い。

最後に

結局、今回の場合ではe-Taxを使用して日本に納税するという、通常と変わらない形となりました。住民税が1年分取られることは不服ですが、まあ致し方なしでしょう。甘んじて納税します（何様）。

英語で調べたりもしましたが、まだまだ法整備が追いつていなく、各国でも有益な情報は少なかったです。この記事が同じ海外に行きたいと考えている方のお役に立てば、これ以上の喜びはありません。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API を読んだのでその書評を書きます。

Kindle 版は出ていなかったので紙の本で読みました。内容は比較的コンパクトで概要 ~ 実装まで書いてあります。スキーマ定義周りが少し重めですが、全体的にライトに読める本となっています。

グラフ理論は飛ばしても良い

2章ではGraphQLの元となるグラフ理論が紹介されます。この章は飛ばしても問題有りません。

グラフ理論はGraphQLの思想について軽微に参考になる程度で、書き方には全く影響しません。数学チックな内容の章になるため、どのような理論か興味有る方のみが読めばよいでしょう。

ただ1点、この章を飛ばすのであれば「エッジ」について抑えておく必要があります。この単語だけはこの章で紹介され、後の章でも登場するためです。後の章で出てくるエッジは、「オブジェクトの関係」と考えて問題有りません。グラフ理論のエッジとは異なる理解ですが、GraphQLのエッジではこの理解で十分成り立ちます。スキーマ定義における1対多や多対多の関係の表現につてい記述されている内容が出てくるため、そのときに「エッジ」とは「オブジェクトの関係」なんだと覚えていればOKです。

この章は飛ばしても良いと書きましたが、私は元々数学が好きだったため、このような分野もあるんだと少し興味を持って本章を読むことができました。余談ですが、エンジニアの勉強が落ち着いたら数学の研究や勉強をするのも悪くないと考えています。

スキーマ定義とクエリのコードを分けて認識する

ここの認識が混ざってしまい、自分は少しわかりずらいと感じてしまいました。

GraphQL には 3部の構成があります。スキーマ定義とクエリ、バックエンドの実装です。

スキーマ定義では、GraphQLサーバーで扱うスキーマを定義します。GraphQLのスキーマとはAPIの構造です。どのようなエンドポイントがあり、どのようなリクエストを受け付け、どのようなレスポンスを返すのかを定義します。このスキーマに合うようにクライアントはクエリを投げ、スキーマに合うようにバックエンドは実装します。

クエリはGraphQLサーバーへのリクエストです。クエリには書き方があり、スキーマで定義された内容しかリクエストすることはできません。

バックエンドでは、スキーマに合うように実装する必要があります。すなわち、定義されたエンドポイントに対応するハンドラーを定義し、レスポンスを返す必要があります。GraphQL はスキーマは管理しますが、バックエンドの実装は管理しません。バックエンドの処理をどのように実装しようが、スキーマに合致していれば自由です。

本書の前半ではスキーマ定義とクエリについて記述され、後半の実装例ではクライアントとバックエンドについて記述されます。

この前半のスキーマ定義とクエリではどちらも似たような書き方になるため、混乱しがちです。本書も紹介しているコードがスキーマ定義なのかクエリなのかを明示していないように感じます。そのため、両者を区別し、今説明している内容はどちらかを意識することが大事と思います。

スキーマ定義とクエリの区別には 公式ドキュメント の参照をおすすめします。Queries and Mutaions ではクエリに関して記述され、Schemas and Types ではスキーマ定義について記述されています。少々大変ですが、混乱した場合は公式ドキュメントを確認することが確実でしょう。

最後に

2022年現在でGraphQLに関する本は少なく、公式ドキュメントに書いてある内容は少々あっさりしています。そのような中で、本書はGraphQLを学ぶ有効な手段となるでしょう。本記事が「初めてのGraphQL」を読む上で少しでも参考になれば幸いです。

DDD の勉強をすべく、「ドメイン駆動設計 モデリング/実装ガイド」を読んだのでその書評を書く。

本書は DDD の概念部分がトップダウンで記述されています。DDDの概念を網羅しつつ、各概念の説明は必要十分な内容にとどめているため、比較的軽量な印象です。しかし、DDD自体の概念が非常に巨大なため、本書のボリュームは大きくなっています。

私のようなDDD初学者の最初の1冊として非常におすすめです。

DDD ってなんぞや？

DDD とは、「モデリングを中心とした設計手法」です。モデリングを重要な設計手法と位置づけ、コードレベルではモデルをどう活かすかを考えます。

モデルを活かす手法には私も同意です。個人開発でモデルオブジェクトを導入したことがあるのですが、その利便性の高さには驚きました。コードの可読性、ロジックの再利用、テストの書きやす際におていモデルは優れています。

コードの可読性は、いわゆるクラスの責務と関係しています。責務が明確であれば、処理を修正するときに対象のロジックがどのクラスに書かれているかがわかりやすくなります。逆にクラスの責務が曖昧だと、数あるクラスの中から目的のクラスを探しづらくなったり、想定外のクラスに影響が及んだりなど、開発の難易度が一気に上がります。

ロジックの再利用も利点です。複数のサービス層（ユースケース層）でロジックを使い回すことができるため、アプリケーション全体でコード量が減少します。

最後にテストの書きやすさ、これはピカイチですね。モデルのテストを書く場合、前提条件のセットが簡単です。インスタンスや構造体を生成して、必要なフィールドに値をセットするのみです。逆にサービス層（ユースケース層）のテストは大変です。複数のモデルやリポジトリに依存している場合が多いため、前提条件を整えることに苦労します。ロジックをモデルに寄せることによりテストの拡充が容易になり、より高品質なソフトウェアを作り上げることが可能です。

コードレベルの話を書いてしまいましが、DDDの本質は「モデリング」にあります。ソフトウェアで開発したい対象領域をどのようにモデル図で表現するかが重要です。このモデル図は開発者以外にも共有され、チーム全員がモデル図で認識をあわせて行動します。コードのモデルは、あくまでのモデリングの成果物を実装しているに過ぎません。

いかにモデリングを行うか、またモデリングを通してモデル図を更新するか。またモデル図の更新に応じてコードのモデルを変更し、他の依存するコードも素早く変更していくかが重要となります。

オニオンアーキテクチャ

「ドメイン駆動設計 モデリング/実装ガイド」では、数あるアーキテクチャの中からオニオンアーキテクチャをおすすめしていました。

今の現場でもまさしくオニオンアーキテクチャを採用しているのですが、本を通じてかなり納得することができました。本では既存のアーキテクチャ（三層アーキテクチャやレイヤードアーキテクチャ）の問題点を挙げ、その問題点がどのような形でオニオンアーキテクチャで改善されているのかという形式で説明されるため、三層アーキテクチャに馴染みある人であれば理解しやすい構成になっています。

オニオンアーキテクチャでは、以下の4層が存在します。

• プレゼンテーション層
• ユースケース層
• ドメイン層
• インフラ層

プレゼンテーション層

プレゼンテーション層は、アプリケーションの外部との通信を担当します。いわゆるコントローラーやハンドラーが存在する層です。

この層では、外部とのInput/Outputnoの変換を行います。

ユースケース層

ドメインオブジェクトを駆使して、ユースケースを実現する層です。いわゆるサービスやユースケースと呼ばれるものが存在する層です。

ここにはドメイン知識（業務ルール・業務ロジック）は配置されません。あくまでもドメイン知識はドメインオブジェクトに記述され、ユースケース層からはそれらのメソッドを呼び出すのみです。

このドメイン知識というのは、モデリングで発見されます。そのため、DDDはまずはモデリングなのです。

とわいえ私はモデリングの経験がないため、これ以上は語れず、、、。せっかく個人開発をやっていいるので今度トライしてみます。

ドメイン層

みんな大好き(?)ドメイン知識を配置する層です。ドメインオブジェクトやそのドメインオブジェクトを使用するクラスが存在します。

また、ここにはリポジトリのインターフェースも配置します。え？リポジトリのインターフェースはインフラ層じゃないの？と思われるかも知れませんが、オニオンアーキテクチャではリポジトリのインターフェースをドメイン層に配置するのです。

理由は各層の依存関係を保つためです。ドメイン層は他の層に依存しません。すなわち、ドメイン層からインフラ層へアクセスすることはなく、ドメイン層のオブジェクトは同じドメイン層の他のオブジェクトにのみ依存します。

しかし、ドメイン層からリポジトリを呼び出したい、、、我々は一体どうしたら良いのか、、、。この問題を解決するのがリポジトリのインターフェースのドメイン層への配置です。ここでは依存関係逆転の原則が適用されています。ドメインオブジェクトは、同じドメイン層にあるリポジトリのインターフェースにのみ依存します。その実装はインフラ層のリポジトリクラスで行われますが、依存はインターフェースのみに対して向かっているのです。

と書いていて思ったのですが、リポジトリを呼ぶケースとして、ドメイン層からリポジトリ呼ぶケースなくない？と思っていまいました。ユースケース層から直接リポジトリを呼ぶケースしか思い当たらないのですが、何か理解を見落としていそう、、、。うーむ、ドメイン層からリポジトリを呼ぶより詳細なコードがほしい。今後の課題とします。

インフラ層

インフラ層では、主にデータの永続化を担当します。DBとかストレージへのアクセスですね。いわゆるリポジトリが配置されます。

以上が、各層のざっくりとした理解と説明です。

最後に

私はこの本を読んでよかったと感じました。冒頭にも書きましたが、最初の1冊として適切だと思います。

DDDに尻込みしているみなさん、ぜひ買いましょう！「ドメイン駆動設計 モデリング/実装ガイド」

この次のステップとして、以下の書籍を上げていました。

1. ドメイン駆動設計入門
2. 実践ドメイン駆動設計

1がボトムアップ・アプローチとのことで、本書との補完に丁度よさそうと感じました。2はケースごとの詳細が記述されているようなため、実際に運用した後に読むと良さそうです。

ではこれにて！良いエンジニアライフを！

以下を試してみる。

1. PC の再起動
2. DisplayLink ケーブルを他のモニタに付け替える

自分の場合はこれで直りました。ご参考まで。

今回、自己診断ツールである VIA-IS 診断を受けました。各診断結果とその解釈を書いていきます。

注意点として、あまり有益度が高い情報ではないかもしれません。特に各診断結果へのコメントには自分語りの内容が多くなっています。暇なときの読み物として呼んでいただければ幸いです。

VIA-IS 診断とは

公式サイトは こちら です。

VIA-IS 診断とは、自分の強みを知るための性格特性診断テストです。性格的な強みを24個に分類し、15分程の質問に答えるだけで自分の強みの順位がわかるとしています。自分の場合は回答に20分ほどかかりました。

背景にある理論としては、自分の性格をよく知っているほど色々と人生上手くいきやすい、というレポートを根拠に挙げています。確度が高い研究結果に裏付けされているのか、心理学業界などで一般的とされている内容なだけなのかまでは調べていませんが、たしかに自分の性格を知ればより良い意思決定ができるだろうなと感じます。

無料で診断を受けることができます。追加でお金を払うことにより「レポート」というものを購入・閲覧することができます。調べても「レポート」というものの内容がよくわからなかったのですが、無料でも24個の特性のランキングと各特性の説明を見ることができます。診断後に自分にはそれで十分と感じたため、レポートの追加購入はしていません。

受けた背景

自分の今後のキャリアを考える材料にしたいと思い、診断しました。

最近職場の人間関係について考える機会があり、どうすれば自分はより良く働けるのか？今後の人生をどのように生きれば自分にとって幸せなのだろう？という疑問を感じました。「人生のより良い生き方」というのは自分の中で大きなテーマとなっています。

また、キャリアについていろいろな方に相談したところ、ある方から自己分析がおすすめとアドバイスを受けました。その人は自己分析を重ねるうちに、人生が上昇気流に乗ったという体験があるとのことです。自分は新卒の就活でやったきりだったので、良い機会だと考えやってみることにしました。

診断結果

正直、この診断1つでその人のすべてがわかる、人生が劇的に変わる、とは考えていないです。自分を知るための材料の1つにしていただければと思います。先入観による影響がでかそうなことが危惧されますが、とりあえず公開してみます。

内容は上位5個、最下位の特性の計6個を載せています。IVA-ISではあくまでも「強み」に着目するための診断テストであり、公式では上位5個に着目することをおすすめしています。しかし、どうせなら弱みもみておこうと最下位の特性にも着目します。

構成はそれぞれの特徴の解釈と、自分の経験・体験の振り返りを書いています。後者は自分語りの内容であるため、あまり読んでくれている方の役には立たないかも知れません。自分としては良い振り返りの機会になり、新たな気づきも得られました。

また、自分は英語で診断結果をダウンロードしました。そのため、各特性の解説はDeeplを通してがっつり機械翻訳しています。もしかしたら原文とはニュアンスが異なる部分があるかもしれませんが、あしからず。

上位5個の特性

1. Social Intelligence (社会的知性)

他者や自分自身の動機/感情に気づくこと。
さまざまな社会的状況に適合するために何をすべきかを知ること。
他者が何を求めているのかを知ること。

1位が「社会的知性」となりました。何だか壮大な特性ですね。内容を読むと次の2つを表していそうです。

1. 自分や他者への感情に敏感である
2. 上記を活かし、他者と協働することができる

1に関しては完全に同意です。ネガティブな面では、特に相手に威圧されると萎縮します。自分自身でも「今、めちゃくちゃメンタルやられてるな、、、」と感じます。みなそのような形なのでしょうか。

そういった経験があるからこそ、他者への感情にも敏感なつもりです。例えば、MTG の中で誰かが相手を攻めるような発言をする（発言者は責めているつもりはない・受け手はそう感じている）場面とかはよくわかります。その人の表情の硬直や一瞬詰まる感じ、その後の受け答えから「あ、この人いま辛いだろうな、、、」ということを感じます。そういったときはなるべくファシリテートし、話題を変える・その人を肯定する発言をする、といった行動を取ることが多いです。そういったことができるのは、自分がそのMTGにおいて心理的に安全な立場にいる＆客観的な立場で見れているからです。自信が辛い経験をしたことがあるからこそ、なるべくその人の負担を軽減したいと感じます。ここのあたりに関する自分の考えについては、どこかで1つの記事に書きたいです。

1は当てはまると思いますが、2に関しては微妙です笑。そこまで協調性がある人物だとは感じていません。ですが、感情を爆発させたり、なにか「悪いこと」をするのは自分の中でハードルがあります。ここは根が真面目な性格が影響していると思います。しかし、「打算的に人間関係が上手くいくように動く」ことは苦手であると感じます。平たく言ってしまうと、人間関係の仕方に苦手意識があります。人間関係のベストプラクティスや対処法を知らないです。

まとめると、「感情には敏感だけど、自身のメンタルがやられているときの対処法は知らない」という感じでしょうか。他者の場合は「こうしたら助かるだろうな」というのがわかるつもりなのですが、自分が絶賛メンタルやられ中のときの対処法はわかっていないです。あまり深く考えたことがないだけかもしれません。

自身がメンタルをやられているとき、どうすればよいのでしょうか？せっかくなので自身の体験を振り返りつつ考えてみようと思います。

1. ストレスを発散する
2. 気分転換する
3. 何かに熱中する
4. 忘れる・時が解決する

自分の場合、メンタルがやられると数日は引きずります。時間経過で継続的に5ダメージ受けるポインズン状態です。そのため、1と2で解決できるイメージがいまいち湧きません。スキマ時間でふと「辛いな、、、」と考えてしまいます。

3はありな気がします。自分の場合は熱中している間は他のことを考えなくて済むためです。効果的な対処法としては、「マインドフルネスを発揮する」→「自分の考え事に気づく」→「他の作業をする」が良さそうですね。それができたら苦労はしないのですが。😅

3を実施したとしても、最終的な解決は4になると思います。

2. Creativity (創造性)

新しい概念や生産的な方法を考え、物事を行うこと。
芸術的成果を含むが、それに限定されない。

2位が「創造性」ですね。これはあるかもしれません。しかし、そこまでアイデアマンというわけでもないと感じます。

学生のころは「他人と違くありたい」思っていて、何かにつけそう考えていました。他人と同じはつまらないと感じていたためです。そのため、日常会話やワークショップのネタ出しなどでは、結構アイデアを出していたと思います。

社会人になってからはあまり発揮できているとは感じません。仕事では成果を出すことを求められ、常に期限がつきまといます。そのため学生のときほど発揮できている感覚はないです。

3. Appreciation of Beauty & Excellence (美と卓越性の鑑賞)

自然、芸術、数学、科学、日常経験など、生活の様々な領域における美、卓越性、熟練したパフォーマンスに気付き、評価すること。

3位が「Appreciation of Beauty & Excellence」となりました。日本語訳が「美と卓越性の追求」で合っているのかわかりません。ざっくり「美やエレガントな方法の追求」と解釈します。

エレガントな方法・解法というのは好きです。うまく問題を解決できたという喜びと、自身の有能さを示す優越感に浸れます。こう書くとイヤなヤツに聞こえますが、少なからず自分の中に存在します。

特に幼少期は数学で発揮していました。小学生・中学生の頃は数学の問題を解くことが好きだったので、いかに少ないステップで解くか・斬新なアプローチで解くかを自然と行っていました。特に応用問題で、自分なりの解き方を試して解いていくのはかなり楽しかったです。

ある応用問題にて、後から自分で見返してみて「これどうやって解いたんだ？」と感じた体験があることを覚えています。それほど解いている最中は集中していました。そのときはアイデアが突飛すぎて、なぜそのアプローチで解こうと思いついたのか、あとから見てみても自分自身でもわからない、という状態でした。あの頃は楽しかったですね、戻れるなら戻りたいとも思います。

社会人になってからは、プログラミングをするようになって発揮されていると感じます。自分は「良いコード」というものに非常に強い関心があります。なぜかそう感じるのかは自分自身でもわからないのですが、初学者の頃から意識していました。その中に、自分が感じるプログラミング的な「美しさ」というもの入っています。上手く言語化できないのですが、この設計は良くない気がする、もっと上手いやり方があるはず、あまり良い書き方・美しい書き方ではない、と感じることがあります。最近は個人開発を通して0→1を経験したり、Clean Architecture などの設計本を読んで知識を入れたりをしており、多少は自分の中で言語化ができつつある気がします。

4. Houmor (ユーモア)

笑うこと、からかうことが好き。
人を笑顔にすること、明るい面を見ること、冗談を言うこと（必ずしも言う必要はない）。

4位が「ユーモア」です。これはドンピシャで当てはまります。一般的な「ユーモアがある人間・面白いヤツ」というイメージではなく、説明にある「笑うこと・からかうこと・冗談を言うこと」といった内容が当てはまります。

子供のころはからかうことが好きでした。高校 ~ 社会人のあたりは他人を笑わせることが好きで、正確には「自分の言葉で他人が笑っている状況」が好きでした。なんでなんでしょうね、自分でもよくわからないです。それは今でも続いていると感じます。

学生の頃は特に顕著だったように思います。頭の回転が働くときは、相手にツッコミがある状態で発言したりしていました。「頭の中で、自分の発言とそれへのツッコミを同時に思いつく」→「発言に対してツッコミがあることを自覚する」→「発言する」という流れでした。これはヒラメキの類です。

また、会話の順序を数ステップとばして発言とかもやっていました。「Aを誰かが発言」→「頭の中で高速でB, C まで考えつく」→「Cを発言」→「ワンテンポ遅れ(周囲がAとCの間の関係を考える)、周囲が理解する」というのをやっていました。これは有能感を示せるからでしょうか。自分で書いていて、何だか付き合わされていた友人には申し訳なさを感じます。

どちらも楽しいからやっていたように思います。「からかい」の側面が強いです。

5. Love of Leaning (学習意欲)

新しい技術、話題、知識体系を独学または形式的に習得すること。
好奇心の強さと関連するが、それを超えて、自分の知っていることを体系的に追加していく傾向を表す。

5位が「学習意欲」です。これも当てはまります。子供のころは勉強が好きでしたし、得意なのは今でも変わりません。

社会人になってからも勉強はしています。新卒で入った会社でも読書はしていましたし、プログラマーになってからは職業上、余計顕著になりました。たまに「土日も勉強で幸せな人生といえるのだろうか、、、」と考えてたりしていました。今は土日には熱中することをやると決めているので、そこまで焦燥することは少ないです。

最下位の特性

24. Leadership (リーダーシップ)

自分が所属するグループが物事を成し遂げられるよう促すと同時に、良好な関係を維持する。
グループ内の活動を計画し、それを実現すること。

最下位が「リーダーシップ」となりました。これは自信のイメージとも当てはまります。 過去の経験を見ても、あまりリーダーシップを発揮した体験はないと感じます。自身もマネージャーと言うよりかは技術者よりであると感じます。

ファシリテートは好きです。まとめてる感があって良いです。ただし、マネージャー・リーダーとなると少し億劫に感じます。「責任」を感じるからです。自分の中で「責任」に対してどこか後ろめたさを感じます。これは過去の失敗体験が原因であるように感じます。

自分は好きなことには局所的にハマります。自分の好きなこと・興味があることだったら、いくらでもリーダーをやります。情熱によりどんどん進んでいけます。そういうモードに入ることが過去でも何回かありました。

自分のやりたくもないこと・あまり興味がないことでリーダーをやるのはとても面倒と感じます。それでもリーダーをやっている人・純粋にリーダーとしてパフォーマンスを発揮している人には尊敬しかありません。大変だろうなと思います。

まとめると、「自分の興味・関心がある物事に対しては情熱を持って進められるが、自分が興味がない物事に関しては推進力が落ちる」と感じます。誰しもそうかも知れませんが、自分の場合は特に前者が顕著と感じます。ハマるときはハマります。

リーダーシップに関しては構造的問題があるようにも思います。自分の場合では「そもそもリーダーを務める機会がない」ことも原因のように感じます。リーダーを努めた回数が0であれば、最下位になるのは必然でしょう。他のVIA-IS受診者の結果でもリーダーシップが最下位となっている方がいました。構造的には絶対数は常に「リーダー < 作業者」ですから、リーダーシップは下位になりやすい特性と言えるのではないでしょうか。

それでも、学生の頃などに率先してリーダーに立候補するような立ち振る舞いが少なかったことは事実です。両者の要因を考慮し、なるべくしてなった最下位という気がします。

診断結果の総括

自分の特性のランキングは以下となりました。

1. Social Intelligence (社会的知性)
2. Creativity (創造性)
3. Appreciation of Beauty & Excellence (美と卓越の鑑賞)
4. Houmor (ユーモア)
5. Love of Leaning (学習意欲)

...

24. Leadership (リーダーシップ)

ここから何がわかり、どのように自分の人生に活かしていくことができるのでしょうか？

正直、わかりません。後述しますが、性格診断テストでは結果よりも振り返りによる気づきの方が大きいように感じます。結果だけを見せられても、何をすればよいのか、何を意味しているのか、それは教えてくれません。それよりも強みについて自分なりに振り返り、自己理解を深める方が重要と感じます。

受けてみて感じたこと

回答していく中で感じたことが2つあります。

1つ目はクリエイティビティの発揮です。今後はなるべくクリエイティビティを発揮する活動を増やしていきたいと感じました。最近、自分は何かに熱中しているときに楽しいと感じることがわかりました。そしてその熱中している作業はどれもクリエイティビティな活動です。現在では個人開発やブログに熱中できます。今後は執筆や絵など、いろいろな活動を通し、新たな発見をしていきたいと感じます。

2つめは感情への配慮です。特に相手への感情に配慮したいです。これまでを振り返ると、自分の感情には敏感でしたが、相手への感情に配慮した行動が本当に取れていたかと言われると微妙です。1つ1つ、もし自分が相手の立場だったらと振り返ってみると、自分が受けてきた対応と大差ないようにも思います。それに気づいたからこそ、相手の感情は重要視したいと感じますし、その行動を取っていきます。

感情への配慮として、婉曲表現（えんきょくひょうげん）はかなり有効であると感じます。まだまだ模索中ですが、Slack などのテキストメッセージでは感情が伝わりにくい分、とくに意識して取り組みたいです。

一言でいうと、モダンだったからです。

自分の場合、とりあえずブログをはじめたものの中々続かないという典型的なパターンを経験していました。自分が書きたいと思えるブログサービスがなく、モチベーションが続いていない状態です。

自分がブログサービスに求めるものは以下でした。

1. かっこいいデザイン!!
2. Markdown で書ける!!

まず1を満たすものが中々なく、この時点ではてなブログやAmebaブログなどの日本製ブログのほとんどが脱落します。note は逆にシンプルすぎて味気がないという理不尽な理由で脱落しています。

1を突破したのがBloggerやMediumなど、比較的シンプルなデザインの海外製サービスです。なのですが、なんと大手にも関わらずMarkdownが使えないではないですか、、、。シンプルに絶望しました。

王道のWordPressも試してみたのですが、1記事書いて更新が止まりました。無料テーマで良さげなものがなかったことと、エディがが重く使いづらいと感じてしまいました。

エンジニアならQiitaがあるではないかという声が聞こえてきますが、Qiitaは技術系の記事に特化しているイメージがあり、個人的なブログとは棲み分けをしようと思いました。この記事を書いていながらも、こんなポエムはQiitqには投稿しづらいなと感じています。Qiitaでは何か有益なものを発信しなければという圧を勝手に感じています。

そんなこんなで理想の無料ブログサービスという砂漠を歩いていたところ、知人から教えてもらったのがこのGhostです。どうやらモダンらしいとの触れ込みのもと触ってみると、デザインがきれい!! Markdwonで書ける!! とまさに求めていたものがすべてそろっていました。この先の人生をこのブログサービスとともに生きていくと決めました。

それほど自分にとっては「いかに楽しく書けるか？書いていて楽しいか？」が重要なんだなと気づきました。

Ghost の始め方

公式ドキュメトにすべて載っています。

Ghost Developer Docs - Introduction

Ghost is an open source, professional publishing platform built on a modern Node.js technology stack — designed for teams who need power, flexibility and performance.

Ghost - The Professional Publishing Platform

すごい、リンクを貼り付けただけで執筆中でもサイトをプレビュー表示してくれる（圧倒的ブログ初心者）。これがGhostの力、、、シンプルに書いていて楽しいですね。他のブログサービスでもできるところはあるのでしょうが、素直に感動しました。

公式ドキュメトを読めといえばそれまでなのですが、いくつか選択肢があるので自分がどれを選んだのかを書いていきます。

自分が選んだホスティングサービス

Ghost実際に利用するには、サーバーを建てる必要があります。

公式ドキュメントには、クラウドホスティングとして3つが記載されています。

1. Ghost(Pro)
2. Digital Ocean
3. Linode

How to install Ghost, the official guide

Everything you need to know about working with the Ghost professional publishing platform.

Ghost - The Professional Publishing Platform

1は公式のホスティングサービスです。しかし、最低でも9$/月からと少々高いのがネックです。

2と3ははじめて知ったのですが、AWSやGCPのようなクラウドホスティングサービスのようですね。どちらも5$/月からで利用開始できます。ざっくりいうと、2のDigital Oceanの方がコンソールの設定が簡単なかわりに自由度が狭く、3のLinodeの方がコンソールの設定が複雑なかわりに自由度が高いとのことです。

自分は3を選択しました。設定が複雑といってもAWSやGCPと大差ないだろうという予想と、Digital Oceanは日本リージョンを選択できないので遅延性を気にしての選択です。

GCP でセルフホスティングという第4の選択肢

しかし、当初はGCPでセルフホスティングをしようと考えていました。GCEでコンテナサーバーを建て、Cloud SQL（MySQL）にデータを保存し、Cloud Storage に画像を保存するという構成です。データを可用性の高いストレージに保存し、万が一サーバーがダウンしてもデータを保護する戦略です。

MySQLにデータを保存まではローカルで確認できたのですが、後半のCloud Storageへの保存が実現できず、、、。時間がかかりすぎたので断念となりました。

Cloud Storage に保存する方法はGhostのデフォルト機能にはなく、プラグインを作成して組み込む必要があります。幸い先人でGithubに公開している人がいるのですが、メンテナンスされておらず動かないという状況でした。

Configuration - Adapt your publication to suit your needs

Find out how to configure your Ghost publication or override Ghost’s default behaviour with robust config options, including mail, storage, scheduling and more!

Ghost - The Professional Publishing Platform

自分で再実装しようとコードを書いてみました。しかしnpmパッケージ開発が初心者過ぎてIntelliJのハイライトが効かず、投げ捨てました😇

他にもAWS S3などのプラグインが公開されていますが、ほとんど更新が数年前で止まっています。これからGhostを始めようと考えているつよつよエンジニアの方、全世界のクラウドデプロイ待望者があなたのコミットをお待ちしています。

ブログのドメインとサーバーのIPアドレスを紐付ける

上記で公式ドキュメントにすべて載っていると書きましたが、1点だけ載っていない箇所があります。取得したドメインとIPアドレスの紐付けです。

ドメインの取得方法は割愛します。自分の利用経験があるところでいうと、お名前.comあたりが無難でしょうか。今回は既にAWS Route 53で取得していたので、自分はそちらを流用しました。

ドメインを取得する｜ドメイン取るならお名前.com

ドメイン取得の手順をご紹介。お名前.comはドメイン登録実績2700万件を超える国内最大級の公式ドメイン登録サービスです。人気の「.com」「.net」「.jp」や企業向け「.co.jp」「.inc」など580種類以上の中からドメインを取得することができます。

お名前.com

ドメインが取れたら、やることが2つあります。

1. DNSのAレコードの設定
2. GhostプログラムでブログのURLを設定

1はドメインを取得したサービスによって設定方法が変わります。お名前.comの場合でいうと、「ホスト名」は取得したドメイン名（example.com など）をそのままサイトのドメイン名にしたければ、空白でよさそうですね。

DNS関連機能の設定：DNSレコード設定｜お名前.com Navi ガイド｜ドメイン取るならお名前.com

お名前.com Naviへのログイン方法やログインに必要なID・パスワードの再発行方法、ドメイン移管、DNSレコードの設定、レンタルサーバーの申し込みなど、各種手続き方法をご確認いただけます。

「VALUE」には、ホスティングサービスで建てたサーバーのIPアドレスを設定します。これも利用したホスティングサービスによって確認方法が異なるので、詳しくは調べてみてください。

2のGhostでのブログURLの設定は、公式ドキュメトに書かれている以下の部分のことです。

Blog URL
Enter the exact URL your publication will be available at and include the protocol for HTTP or HTTPS. For example, https://example.com. If you use HTTPS, Ghost-CLI will offer to set up SSL for you. Using IP addresses will cause errors.

How to install & setup Ghost on Ubuntu 16.04, 18.04 and 20.04

A full production install guide for how to install the Ghost professional publishing platform on a production server running Ubuntu 16.04, 18.04 or 20.04.

Ghost - The Professional Publishing Platform

ここで https を含むURLを指定すればOKです。

あとは手順通りに進めればブログが公開できるはずです。自分の場合はAレコードの再設定から数分待つ必要がありましたが、問題はそれくらいでした。手順は多いものの、ドキュメントがしっかりしているので脳死で歩けることが便利ですね。

最後に

初めて本格的なブログ記事を書きましたが、意外とすらすらと書けました。ここまでで文字数が1000文字、時間は大体50分かかりました。文章を書くのは大変ですね。

最後に自己紹介を少し。自分は普段はフリーランスエンジニアとして働いています。休日はがっつり個人開発をしており、マインドマップ型のTodoアプリを開発しています。Twitterで開発過程を発信しているので、よかったら見てください。いいねされると泣いて喜ぶと同時に、モチベが上がるのでリリース日が1日早くなります。

https://twitter.com/HitoroOhira