t-asa2000.net

【個人的振り返り】2024年ありがとうございました・来年の目標など

Fri, 27 Dec 2024 09:17:12 +0900

こんな記事今まで書いてなかったのですが，ブログへのモチベが高まってる時期なので書いていきます．（多分しばらくしたらまた更新が止まるので）

はじめに

2024年もブログしかりSNS投稿しかり，色々な媒体でお世話になりました．

今年1年，「自分に起きたこと，成長できたこと，そして来年の目標」 書いていけたらと思います．

自分に起きたこと

大学院への進学が決まった

一時は卒業すらちょっと怪しかったんですが，おかげさまで無事大学院に進学できることが決まりました．

車に関する悪い出来事が多かった

今年は車に関する悪い出来事が多かったですね．

4月 : もらい事故で修理
9月 : ステアリングの不具合で修理 (人生初の代車)
10月 : 朝起きたら家の駐車場でタイヤがパンクして潰れてた

ただ，こういう経験をしておくことでいざという時どこに連絡して何をすれば良いのか，学ぶことができたので今となってはまあ良かったのかなとも思っています．

その他

後輩ができた
人生初の学会発表をした
「Misskey Advent Calendar 2024」に参加した

成長できたこと

開発技術の大幅な向上

今年の4月頃から，とあるWebシステムの開発に携わらせていただいていて（といいつつ既存のソースコードを頂いて，フォークとして独自に開発を進めてるんですが），そこで開発力を大幅に向上させることができたなと思います．

Node.jsで動くサーバーサイドとフロントエンドが分離してる（それこそMisskeyみたいなタイプの）アプリケーションを開発することで， Expressでのルーティング，Vueによるフロントエンド開発，APIやデータベースの設計 などなど色々なことを自分でやったことは大きな経験になりましたね．

また，実際に業界で働いてらっしゃる方のソースコードを見れたこと，一緒に沢山お話しできたことが自分の人生において大きな財産になりました．

他に

書くことがねぇ・・・（こいつの人生コードしか書いてない？）

来年の目標

体調管理

来年は就活も始まりますし，今のように 「学校行くだけで体力全消耗」 だと死んでしまうので疲れにくい身体を作っていきたいなと思っています．

コミュニケーション能力を鍛えたい

これも就活のためですね．特に瞬発的な考察力が弱い．会話のキャッチボールで，自分が想定していないことを言われると何も返せなくなってしまうので．

ブログの更新頻度が上がったので維持したい

2024年12月のアドベントカレンダー参加を機に，実はブログもプチリニューアルさせました．そしたら急にモチベが出て更新頻度が上がった（笑）

「とりあえずUDフォント使えばええやろ」 とか思ってBIZ UDPゴシックを採用してたら，クッソ見辛かったのでNoto Sans JPに変えてみたり

プロフィールをちゃんと（？）整備したり，どんな環境でも見やすいようにCSSを調整したりしました．

MisskeyやMastodonで好きな時に好きなこと吐き出すよりも，こういう場所で1～2時間かけて自分の頭の中を整理する作業が，面倒だけど自分には必要な時間 なんじゃないかと思うようになりました．

今年は8月に1回，12月にはこれも含めて3回更新したことになるので，月1～2回程度の更新を今後も続けていきたいですね．

挨拶

今年も本当にありがとうございました．来年も私のことをどうか見守っていただければと思っています．

それでは，良いお年を！！！

追記

マジで思ったより書くことなかった

【Google 解体とか言われてるけど】ビッグテック寡占黙認（というより諦め）派なのでその理由を書いていく

Thu, 19 Dec 2024 22:42:24 +0900

今回のブログはかなり 「思想強め」 です．

11月20日、アメリカの司法省は、グーグルの検索サービスの独占を解消するためとして、インターネット閲覧ソフト（ブラウザ）「Chrome（クローム）」事業の売却を含む是正案を裁判所に提出した。立教大学ビジネススクールの田中道昭教授は「アメリカには、公正な自由競争に対する信念が強く根付いており、資本の独占に対して厳しく臨んできた歴史がある。今回の訴訟により、グーグルは戦略の転換を迫られている」という――。

手軽に｢ググる｣はもうできなくなる?…米司法省がグーグルに｢Chrome売却｣を要求した本当の理由 | PRESIDENT Online
https://president.jp/articles/-/89180

要はGoogleが大きくなりすぎたから，分割してそれぞれの分野で競争促しましょうね っていう話ですね．

私の感想ですがハッキリ言って 今更遅すぎるし無駄 だと思ってます．

私はあくまで寡占そのものに賛成というのではなく，「一度寡占させてしまったものは諦めろ」 派です．

もし一社による寡占が問題だと思うなら，ここまで大きくなる前に 早期に芽を摘んでおく 必要があったんです．消費者がすでにそのサービスを使用するのが定着してしまったものを破壊するのは，それが果たして本当に多くの人々にとって良いことなのか疑問に思います．

確かに競争を促して市場が健全化されるのは良いことだと思います．しかし，最終消費者（エンドユーザー）に利益か還元されなければ意味がないですよね．

力の弱い生産者のためだけに，大多数の消費者の利便性を犠牲にするならば，それこそ 「公的機関に泣きつくことで得をする弱者ビジネス」 じゃないですか．

と感情的に批判しても何も始まらないので，米司法省の提案1個1個について自分なりの意見を書いていこうと思います．

Chromeブラウザの売却

1. Chromeブラウザの売却

（目的）
・グーグルが検索市場での支配力を維持するためにChromeを利用しているため、その売却によって競争を促進。

（具体的措置）
・グーグルはChromeを第三者に売却する義務を負う。
・売却後、グーグルは5年間ブラウザ市場に再参入することを禁止される。

「競争を促進」 なんて無理だと思います．分離したところで多くのユーザーは「Google」っていう検索エンジンを知ってしまったのですから，自分らでChromeをインストールして検索エンジンをGoogleに設定することでしょう．

「知名度」 というものは恐ろしい物です．だってそれを知ってしまったら，他の検索エンジンを知る必要がないのですから．(Googleに不満がない限り)

結果が出ないと分かっていても，他のプラットフォーマーが感じる不公平を放置することが，公的機関として問題だから形だけでも対処しておいた方が良いのはわかります．立場上やらなくてはいけないのでしょう．

これによって，例えばGoogle アカウントによる同期ができなくなるなど，消費者の利便性を阻害していることに関してはどうでもいいのでしょうか．まあ実際売却してもどこまで技術協力を許可するかにもよりますし，もしかしたらChrome アカウントなる独自の同期アカウントが誕生するかもしれません．

Androidに関する規制

2. Androidに関する規制

（選択肢1）Androidの分割
・グーグルがAndroidを使用して検索市場の競争を妨害する行為を防止。
・Androidを完全に分離・売却する。

（選択肢2）行動上の是正措置
・グーグルがAndroidを利用して自社の検索エンジンを優遇する行為を制限。
・プラットフォーム上での公平性を確保するための監視と規制の導入。

Androidの場合は，Googleとエンドユーザーの間にベンダーが挟まりますので，ベンダーが自由に検索エンジンを選べるようにするというのは良いことだと思います．

あとAndroidにGoogle Playストアをプリインストールして端末を売るためには，他のGoogle アプリも抱き合わせにしないといけないのも規制したら効果的だと思います．というかむしろこっちの方が寡占としては問題なんじゃないんでしょうか．

デフォルト検索エンジン契約の禁止

3. デフォルト検索エンジン契約の禁止

・グーグルが他社デバイスやブラウザで検索エンジンをデフォルトに設定するために金銭的価値を提供する契約を禁止。

これ自体は良いことだと思うんですけど，それによってFirefoxが死滅しそうになってることについてはなんとも思わないんでしょうか．

Firefoxを開発するMozillaがGoogleの独禁法訴訟でGoogleの各種事業が破壊されると運営資金がピンチになると訴える
https://gigazine.net/news/20241219-mozilla-google-browsers/

（Safariは自社OSでしか使えないからほっておいて）ブラウザの寡占状態になったら，それこそ独立したChromeが暴走して，ブラウザ界のGoogleになる危険性も十分にあります．

拡張機能への締め付けとか，(オープンソースとはいえ) 自社が有利になるようなChromiumへの改変を平気でやるようになると思う．

データ共有と透明性の向上

4. データ共有と透明性の向上

（データの提供）
・グーグルが収集した検索データや広告データをライバル企業に共有。
・共有は無償で、プライバシーを保護したうえで行われる。

（広告データの透明性）
・広告主に対し、検索広告のパフォーマンスやコストに関する詳細情報を提供。
・広告データをライバルプラットフォームで利用可能にする仕組みを導入。

これ例えば何かしらのパラダイムシフトで，Bingがシェア1位になったらMicrosoftにも同じことを要求するんでしょうか．

そうじゃなきゃ不公平ですよね．もしGoogle一社にこれを許して前例ができてしまったら，どのプラットフォーマーもビジネスに少し慎重になってしまう気がします．

むしろそれぞれのプラットフォーマーがデータ収集・活用技術を向上させガンガン稼がせた方が，競争促進にもなるし何よりアメリカの経済的な国益になると思います．

競争を促進する仕組み

5. 競争を促進する仕組み

・グーグルの検索結果データ（インデックスやランキングシグナル）をライバルが利用できる形で提供。
・10年間、グーグルの検索結果や広告の一部をサードパーティが利用可能にする。

これ最初にも書きましたが，米司法省が早期に規制をして肥大化を抑止していればこんなことやる必要なかったんですよ．

「お前ら大きくなりすぎたから，一時的にボランティアになれ」って言ってるようなもんですよね．

競争促進には効果的だと思いますが，米司法省はこのような時間調整をしないといけない状況を作ったことを 「恥ずかしいこと」 だと認識した方が良いと思います．

競争の妨害行為を防止するための管理

6．競争の妨害行為を防止するための管理
（技術委員会の設置）
・グーグルの是正措置の履行を監視するために独立した技術委員会を設置。
・コンプライアンスオフィサーの任命：グーグル内部に、是正措置の遵守を保証する責任者を設置。

（違反の防止）
・グーグルが裁判所の是正措置を回避したり、競争を妨害する行為をしたりした場合の罰則を規定。

ごくごく普通の競争健全化施策なので飛ばします．

ユーザー選択を増やすための取り組み

7. ユーザー選択を増やすための取り組み

・グーグルブラウザやAndroidデバイスでの「検索エンジン選択画面（choice screen）」の導入。
・選択画面を通じて、ユーザーが公平に他の検索エンジンを選択できる仕組みを確立。

そもそもその選択画面ですら，Googleが認知しているサービスだけが一覧に載るんでしょ．一部のプラットフォーマーを優遇してることに変わりないじゃないですか．(EUのInternet Explorerへの規制でも同じこと思ってた)

1. でも言いましたけど，Google の知名度とシェアが広がってしまった以上大半のユーザーが「Google」を選ぶことに変わりありません．やらないよりはマシってことなんでしょうけど．

ユーザーにとって公平に検索エンジンを選択できるようにするならば，デフォルトで検索エンジンを一切搭載せずに， 以下のようにユーザーに一から手動設定させるべきです．

え？ 「デジタル慣れしてない一般ユーザーに負担が大きすぎる」 だって？

甘えたこと言わないでください．「公平」 が大事なんでしょ．これくらいやれよ．

若干，というかほぼ屁理屈みたいなことしか言ってませんが，要は 「大きくなりすぎてからの規制は消費者に負担と混乱を招くだけ」 ということを言いたかっただけです．

MisskeyプラグインでレジストリAPIを使った同期機能の実装と注意点

Sat, 07 Dec 2024 23:28:00 +0900

この記事は 「Misskey Advent Calendar 2024」 8日目 の記事です．

こんにちは．Misskey.ioで活動しているasataと申します．

今回は Misskey のプラグインを自作していく中で気が付いた 「レジストリAPI」 に関する知見をまとめていけたらなと思っています．

自作したプラグイン

私が今回作成したのは 「ノート非表示プラグイン」 というもので，これは個別のノート単位で疑似的なミュートができるというものになります．

タイムライン上に不快に思うような内容が流れてきて，「その人自体は嫌いじゃないけどこのノートだけはもう目に入れたくない」 みたいな場面を想定して作りました．（単純に自分がそういう時にあったらいいな・・・と思ってたので）

https://misskey.io/@asata/pages/notemuteplugin

プラグインのデータをサーバー上で同期させたかった

Misskeyでは，クライアントに関する情報は基本的にクライアントに保存されます．

なので，どういうプラグインを入れたとか，そのプラグインの設定やデータはサーバー上に保存されません．

同じプラグインをスマホとPCで使いたければ，それぞれのデバイスにインストールすることになります．しかし，両方のデバイスで常に同じ状態をキープするということはできないわけです．

ただ私は，できることなら実際のミュート機能の使い勝手に近づけたいと 「ミュート設定したノートIDのリストをデバイス間で同期したい」 と考えていました．そんな中，タイムラインで教えて頂いたのが 「レジストリAPI」 です．

レジストリって何？

Misskeyにおける「レジストリ」とは，「キー」と「値」の組み合わせ で自由な値をサーバー上に保存しておける機能です．値の型は，文字列・数値・配列・オブジェクト，どれでもOKみたいです．

Misskey自体も，各種設定を保存するためにレジストリを使用しています．

レジストリは階層構造となっており，「ドメイン」⇒「スコープ」⇒「キー」という形となっています．「スコープ」は client/aaa のように多重構造（入れ子）にすることも可能です．

レジストリを使えば設定が同期できる・・・はずだった

これを踏まえて，私は 「同じドメイン・スコープ・キーでレジストリを読み書きすれば，ミュート設定したノートを同期できる」 と考え実装に入りました．

Misskey プラグインは，AiScript というJavaScriptベースの言語で記述します．また，Misskey内でAiScriptを使用する場合は 「AiScript Misskey 拡張API」と呼ばれる専用のAPIが使用できます．今回はこちらを使ってプラグインからMisskeyのAPIを叩きます．

↓こんな感じでMisskeyのレジストリAPIを叩きます．

// 非表示ノートの設定(サーバー)
@setMutedNotesServer(notes) {
  Mk:api('i/registry/set', {
    key: 'mutedNotes',
    scope: ['asataPlugin'],
    value: notes,
    domain: 'asata'
  })
}

さて，ここで問題が生じました．上記のコード内ではドメインを 「asata」 としていますが，実際のレジストリでは 全く関係のない文字列をドメインとして 読み書き操作が行われていたのです．

しかも，この文字列，プラグインをインストールし直すごとに変わってしまいます．つまりこれは 「異なるデバイス間で同じレジストリのキーを参照できない」＝「同期ができない」 ということになります．

外部からレジストリAPIを叩くとドメインは無視される

Misskeyのバックエンドのソースコードを見てみると，その原因が分かりました．

packages/backend/src/server/api/endpoints/i/registry/set.ts より引用

@Injectable()
export default class extends Endpoint<typeof meta, typeof paramDef> { // eslint-disable-line import/no-default-export
  constructor(
    private registryApiService: RegistryApiService,
  ) {
    super(meta, paramDef, async (ps, me, accessToken) => {
      await this.registryApiService.set(me.id, accessToken ? accessToken.id : (ps.domain ?? null), ps.scope, ps.key, ps.value);
    });
  }
}

スマホ等では少し見辛いかもしれませんが，レジストリAPI用の関数に投げる第2引数が accessToken ? accessToken.id : (ps.domain ?? null) となっています．

どうやら外部からレジストリAPIを叩く場合は 「指定したドメイン名を無視してアクセストークンのIDをドメインにする」 という仕様のようです．ドメイン名となっていた謎の文字列は，インストール時にプラグイン用に生成されたアクセストークンのIDだったみたいですね．

レジストリを使った同期をするための方法

ただ，プラグインのデータをレジストリ経由で同期できないという訳ではありません．各デバイスにインストールされたプラグインが 同じアクセストークンを使用すれば 同期を行うことができます．

残念ながら，プラグインの実装ではこの問題をどうにかすることは不可能なので， プラグインを使うユーザーに対して 以下の操作を促すことになります．

2つの デバイス「A」と「B」 でMisskeyをしていると仮定して説明します．

デバイスA でプラグインをインストールする．
「設定のバックアップ」機能で，インストール直後のクライアントの状態をバックアップする．
デバイスB 上で「設定のバックアップ」機能から デバイスA で作成したバックアップをクライアントに適用する．

これにより，2つのデバイス上で同じプラグインがインストールされます．しかも，デバイスA のインストール時に生成したアクセストークンが 紐づいた 状態でインストールされます．

これでようやく レジストリを使った同期 ができるようになります．

【実際に同期機能を実装したプラグインのスクリーンショット】

最後に

以上， Misskey プラグインに（無理矢理ですが）同期機能を実装してみたという記事でした．

ドメイン名を強制的に書き換えるという仕様は，セキュリティ的にやむを得ないんじゃないかなと思っています．

悪意のあるプログラムがドメインを偽装してレジストリ書き換える
たまたまサードパーティー同士でドメインが重複してしまう

みたいなケースも十分考えられますからね．

最後までお読みいただき，ありがとうございました．

「SNSは連絡ツールとは別」←この考え方って古い？

Thu, 15 Aug 2024 13:07:09 +0900

インターネットとの出会い

私がインターネットを触り始めたのは小学生の頃(2008年)．当時は当然のことながら，自分から何かを発信するためのアカウントや場所は持っていませんでした．Twitterもアカウントなしで，その都度見たい人のユーザーページに飛んで見てたので，真の意味でのROM専 でした．

当時はTwitterなどのSNSは人口が少なく，必然的に 画面の向こう側にいる知らない人だけに向けて，発信やコミュニケーションを取らざるを得なかったわけです．

アカウントこそ持っていなかったのですが，その当時のイメージが強いので，私は未だにSNSを 「画面の向こう側の人とやり取りするツール」 だと思っています．

SNSと連絡ツールの境界線

まず私の中での定義として以下のように分けてます．

SNS : 世界中の誰に見られても良い前提で短い発信を行うもの(基本的に一方向)
- X(旧Twitter)，Mastodon，Misskey，Threads，Instagramなど
連絡ツール : 現実の友人知人・家族との生活上必要な双方向のやり取りを行うもの
- LINEなど

昨今，自分と同世代の若者達の一部が，InstagramのDMしか使わないとか，俗に言う 「LINE離れ」 みたいな話を聞くんですけども，

私としては 「公開空間のアカウントで非公開なやり取りをする」 ということにすごく気持ち悪さ，セキュリティやプライバシー上の危険性を感じてしまうのです．

奇跡的にも自分はこれまで，インスタのDMでやり取りするような人間関係に遭遇しなかったのですが，万が一そうせざるを得なかった場合はDM専用のアカウントを作って運用していたと思います．

内輪ネタを書かない，リア垢も作らない

上述のようにDMだけの運用なら 「連絡ツール」 という扱いになるので，まだ自分としても許容できます．

問題はタイムラインへの投稿です．

私も高専時代，Twitterを使っていて内輪のフォロイー・フォロワーの割合が8割くらいになってしまい，「SNS」 にも拘わらず内輪寄りのコミュニケーションになりかけてしまったことがあります．

それでも，気を付けていたことは 「内輪ネタをタイムラインに書かない」 ということです．

ここで言う内輪ネタとは，当時の学校の独自の教科名や授業内容についてのこと，現実の友人との間で起きた出来事，つまり 私と物理的に同じ空間にいる人じゃないと分からない情報 です．

「だったらフォロー承認制のリア垢を作れば良いじゃん」

これを見てそう思った人もいるかもしれません．しかし，鍵垢にしてようが間違って知らない人のフォローを承認してしまう可能性もゼロではありません．

例えば私が何かの投稿がバズったor炎上した時に，過去の投稿やフォロイー・フォロワーから辿られて，身元を特定されたり他の現実の友人達がトラブルに巻き込まれるかもしれません．私はリスクを負ったり他人に迷惑をかけてまで，SNSに本腰を入れるつもりはありません．

「インターネットを警戒し過ぎなのでは」って思われるかもしれない．でも，それが正解だと思います．

そもそも インターネットは怖い場所 です．ただ，スマホの普及で

周囲がInstagramをやってる
電車で隣の人がTwitterを開いてる

これが当たり前になった現代，インターネット上の公開空間に 参加すること への抵抗が薄れてきたことで，
世の中の風潮も「リアルとネットの壁を無くす＝SNSも連絡手段の一つだと捉える」という風に変わっていったのだと考えています．

発達障害持ちの僕がこまること「荷物が上手く捌けない」

Sat, 11 Mar 2023 10:07:46 +0900

カバー写真: ぱくたそ

～おことわり～
この記事の筆者は，幼少期から広汎性発達障害（のグレーゾーン）の傾向が見られたものの，その当時は医師による正式な診断は受けていませんでした．ただし，執筆時点では心療内科より正式にADHDの診断をもらっています．また，この手の話題は個人による症状差が大きいため，あくまで私個人のケースとして捉えてもらえると幸いです．

普段の荷物

皆さんがいつも外出する時，絶対に必要なものって何でしょうか．少なくとも以下の3つは，どんな場合でも常に携帯してないといけないと思います．

家の鍵（＋車の鍵）
財布
携帯電話

私は基本，ズボンの左前ポケットに財布，右前ポケットに携帯電話を入れてます．ただ，鍵などを入れる場所がないので，それらを持ち運ぶためだけにショルダーポーチを携帯します．定期券や交通系ICカードも，ショルダーポーチにくっつけてます．

加えて，私は学生ですので教科書などをバックパックで持ち歩きます．

さらに，悪天候時には傘が必要です．

ここまでの荷物の構成は以下のようになります．ついでに，写真も撮っておきました（床が汚くてごめんなさい）．

財布（左ポケット）
携帯電話（右ポケット）
ショルダーポーチ
バックパック

さて，ここから実体験の話をしていきます．

困りごと1: ショルダーポーチとバックパックの紐が絡まる

ショルダーポーチとバックパックを体から降ろすときに，身に着けた順番と逆順で外していかなくてはいけませんが，順番を間違えて紐が絡まってオロオロしてしまうときが多々あります．特に，バスや電車などの公共交通に乗って席に着いた際に，荷物をどかしたいなと思って人前でこれをやらかすのが，本当に恥ずかしい．

困りごと2: 傘を持ち歩いているとき

傘を持ち歩いているときは最悪です．片手が塞がっているので，例えば土足禁止の空間（傘立てがない場所）に入ったとき，靴の履き替えで時間がかかります．というか，手先が不器用なのでただでさえ時間がかかるのに・・・

後ろに人がいると，自分で詰まってしまって，ただただ申し訳なく切ない気持ちになります．

外出時以外でも

夕飯の支度とか，食器の片づけとか，普段のちょっとした動作の中で，今手に持っているものをどこにどかせば良いのか，次に何を手に持てば良いのか，うまく脳内で計算できません．普通の人ならすぐ終わる作業が，2～3倍くらいの時間がかかってしまいます．

まとめ

とにかく日頃の生活において，カバン類や手に持っている荷物を瞬間的に捌くのが，本当に苦手です．全体的な動作が，周囲から見てもちょっと「子供っぽい」「もたもたしている」「変な人っぽい」って感じになって，「この人変だよね」って思われて距離を置かれる（もしくは自分でそう見られてると思い込んで距離を置いてしまう）ことがあります．

もっと要領良く生きていきたいですね・・・

「ホームページを作って欲しい」って言ってきた人に見せる記事

Fri, 10 Mar 2023 01:36:26 +0900

プロローグ

世間一般よりもほんの少しだけPCスキルがある・・・そんな感じの中途半端なデジタルの素質を持ってる筆者なんですが，人生で何回かHPを作ってくれと頼まれたりしてきました．

今の時代

Wixで誰でも作れるから人に頼まなくても良くね？
Twitterやインスタで宣伝できるからHPなんか要らなくね？

と言われてもおかしくない時代なんですが，それでも「ホームページ」という物への需要はまだ完全に無くなってはいないみたいです．

今回の記事は，あまり技術関係に詳しくない方向けに書いたものです．

ホームページを作る意味

一番大きなことは「情報の整理・集約化」だと思います．

例えば，あなたが飲食店の経営者で，毎日，TwitterやInstagramにお店のメニューを写真付きで投稿しているとします．拡散効果は期待できるでしょう．ですが，その情報は

「時系列順に写真や文章が並んでいるだけ」

であり，その情報の中にはお店からのお知らせや店主の独り言など，“他のカテゴリの情報” も含まれていますね．

「シンプルにお店のメニューだけが見たい」

と思ったお客さんが，過去の投稿を遡って色んなメニューの説明を見ていくのは非常に利便性(ユーザビリティ)が悪いです．

そんな時にホームページという，ググれば誰でも見つけられる場所（※）に料理の一覧を置いておくことで，必要な人が必要な時に情報を得ることができます．

※ググれば誰でも見つけられる場所といいましたが，Google 検索で上位に表示されるにはある程度の閲覧数が必要です．

ホームページの正体

「ホームページの正体」と言うと語弊があるので「Webページの正体」の方が適切かもしれません．

↓ざっくり言ってしまうとこれが「Webページの正体」です．

信じられないかもしれませんが，このダラダラと長いコードが「Webページ」です．極端な話，皆さんが普段見てるTwitter(アプリではなくブラウザ版)の正体もこれです．

ここで，恐らく皆さんの頭にこんな疑問が出てくると思います．

Q. でもwixとかホームページ・ビルダーって見た目そのままに作れるよ？

簡潔に言います．コードに起こす作業をwixやホームページ・ビルダーがあなたの代わりにやってます．

勿論，今どきのWeb屋さんもケースバイケースですが，人の手で書くコードは最小限に減らすための色々な工夫をしています．あの長いコード全てを自分で書くことはごく稀でしょう．

ホームページに関わる3つの要素

ホームページを作るうえで抑えておきたいのが，以下の3つの要素です．

ホームページの中身（を生成するためのツール）
サーバー（ホームページの置き場所）
ドメイン（置き場所の住所）

ドメインというのは，www.google.co.jp みたいなやつのことです．

中身・サーバー・ドメインが全てセット

1.と2.と3.が全てセットになったのが「wix」や「Google サイト」みたいなものです．パワポ感覚でHPが作れます．業者に頼めないし簡易的なものでいいから作りたい，という用途には最適です．

ただもちろん無料なので制約は色々あります．一番大きいのが「ドメイン」の制約だと思います．wix使ったことがないので分かりませんが，ドメインは「〇〇.wix.com」みたいな形式になると思います．間違ってたらごめんなさい．

あと，wixの場合は画面内に「wixを使いませんか」みたいな広告が常駐するので，見栄えは悪くなりますね．

中身を作ってサーバー・ドメインは別に用意

恐らく2000年代まで個人で作るホームページの主流がこれ．「ホームページ・ビルダー」などのソフトウェアを使って，見た目通りに作成します．その後，生成されたファイルをサーバーに手動でアップロード(コピー)します．

中身をパソコンの中で作ってから，サーバーに持っていくイメージです．

このサイトも，ホームページ・ビルダーとは全く別物ですが，「静的サイトジェネレーター」と呼ばれるツールを使って，PCの中でファイルを作ってから公開しています．

お金払ってサーバー契約すれば，広告も勝手に載りませんし，ドメインも自分で契約したものを自由に使えるので，これが一番ホームページらしいホームページが作れるかと思います．

wixみたいなシステムをサーバーの中に設置してしまう(奥の手)

実は，先ほどの1+2+3の方法のように，ブラウザ上で更新してそのまま公開するシステムを，wixなどの大手サービスに頼らなくても，自分のサーバー内に設置することができます．

それが「CMS」と呼ばれるツールで，代表的なものがWordPressです．

ただこれは環境構築が専門の知識がいることと，サーバーの中にデータベースを作成したりするため，システムが煩雑になりやすいという欠点があります．また，セキュリティ的なリスクもあり，万全な体制と人的余裕がなければ基本おすすめできません．

サーバー周りの管理をする専門の知識・技術を持った人がいて，それと別に内容を更新する人がいるのであれば，最適な方法だと思います．

HP作りを友人・知人に委託したい人へ

私はちゃんとした仕事としてWeb屋をやっている訳ではないので，世の中のWeb屋さん達がどういう風に仕事をしているのかは分かりません．

ただ，個人的に今まで色々HPを作って来て思うのが，以下の点については，委託側と受託側で認識を共有して置いた方がいいような気がしました．

更新頻度

最初に基本的な情報(飲食店の例:アクセス，メニューなど)を書いたら後は放置する，あるいは最初の更新以降も定期的にお知らせなどを発信する，どれくらいのペースで更新していきたいのかは，予めイメージしておいた方がいいと思います．

どこまでを自分でやるか

本当に何も分からないと言う場合は，載せたい内容をWordファイルにまとめたり簡単なメモにして送ったり，という感じで良いと思いますし，逆に自分でも直接手を加えたい場合は，相手にもその旨伝えておいた方が良いかと思います．

どこまで相手に介入させるか

ホームページの中身だけを作って欲しいか，サーバー内のファイルの操作も許可するか，そこら辺のルールもしっかりと決めておいた方がいいかもしれません．

引き継ぎ

これが一番難しいかなと思いました．先述の通り，我々も全てのコードを手打ちしている訳ではなく「ツール」に頼っているのですが，そのツールもホームページ・ビルダーのような初心者向けではなく，そこそこのスキルが求められる上級者向けのツールだったりします．

例えば，このサイトは「Hugo」というツールを使って作ったのですが，この更新を後任者に引き継ぐのであれば，Hugoが使える人を引っ張ってくるか，最低限使い方をレクチャーするかしないといけない訳です．

もっと面倒くさいのが「WordPress」のようなCMSで，例えばシステムがぶっ壊れた時の応急措置やら，データベース周りのパスワードやら，引き継がないといけない内容が多いこと，

さらに，プラグインを使って機能を拡張していくのでシステムが煩雑になって・・・面倒くさいです．正直言ってあまり手を出したくないのです(使っている最中は楽だけど)

まとめ

という訳で，今回の記事を通して伝えたかったことは

HPを作る目的を今一度確認して欲しい
中身＋サーバー＋ドメインの組み合わせを理解して欲しい
誰かに頼むなら色々なルール決めや認識共有をして欲しい

ということでした．最後までご覧いただきありがとうございました．

ネタ切れ

Thu, 09 Mar 2023 18:46:26 +0900

ネタがない町内
なななななななな

　終
ーーー
ＮＨＫ

Hugoに移行してみた

Sat, 03 Sep 2022 00:00:00 +0000

これまで格安VPSでWordPressサイトをホスティングしてましたが，色々な事情を考慮した結果 GitHub Pages + Hugo に移行しました．

移行と言ってもめんどくさかったので過去記事は全て消滅させました（笑）

~~テーマ等は使わず，僕が以前手打ちHTML+CSSで作った個人サイトをベースに再構成しています．~~

~~（厳密にはHugoで生成してるのはブログ部分のみで，プロフィールページ等はHugoのシステムからは独立させています．）~~

2023.3.6 追記

コードブロックが使いたかったので，テーマを採用しました．個人サイトとブログを統合しました．

https://github.com/CaiJimmy/hugo-theme-stack