PESPA(Today I Learned)
Webの次世代アーキテクチャ - PESPA - Qiita
Webアプリの作り方で、JavaScriptに頼らないシンプルなマルチページアプリは良くも悪くも愚直で、一見スマートなシングルページアプリは複雑怪奇、両方のいいとこどりをしたのがPESPAってとこかな。
こういうのは代表的なフレームワークを使って1個何か作ればよくわかる気がするけど…うーん、何を作ろうか。
Webの次世代アーキテクチャ - PESPA - Qiita
Webアプリの作り方で、JavaScriptに頼らないシンプルなマルチページアプリは良くも悪くも愚直で、一見スマートなシングルページアプリは複雑怪奇、両方のいいとこどりをしたのがPESPAってとこかな。
こういうのは代表的なフレームワークを使って1個何か作ればよくわかる気がするけど…うーん、何を作ろうか。
何もいじっていないMisskeyの仕様確認のため、ローカルでMisskeyインスタンスの構築を試みていました。
Misskey構築の手引き | Misskey Hub
こっちの方は、手順が途中でおかしくなってしまって、断念。
もうちょっとLinuxとサーバーに詳しくなってからリベンジ…するかもしれないし、しないかもしれない。
Docker Composeを使ったMisskey構築 | Misskey Hub
素直に推奨されている方のDocker Composeを使う方法にしたら、おおむねうまくいきそうな感じで、あとは起動するだけになりました。
まあ、起動してからどうなるかはわかりませんが…。
Standard search API | Docs | Twitter Developer Platform
GET /2/tweets/search/recent | Docs | Twitter Developer Platform
Twitterの検索API調べてました。
検索クエリの上限文字数を知りたかったのですが、一般ユーザー向けとしては、以下のように書いてありました。
バージョン1.1:500文字
バージョン2:512文字
で、「文字(characters)」って何なの?ってことで、実測したのが以下のツイート。
どうやらバイト数っぽい。そしてバージョン2はだらしない。 pic.twitter.com/7Q1smLFj0y
— 📛松田美文 (@matsuda323) January 28, 2022
で、クリアしたってわけなのです。 pic.twitter.com/NX4S9F6CnI
— 📛松田美文 (@matsuda323) December 16, 2021
GraphQL実装中。
具体的な使用シーンを想定していないので、死に機能になる可能性もありますが、必要になってから作り始めると、それはそれでしんどいので、やる気のある時に仕組みだけ先に作ってしまおうって算段なのです。
順番的には、実装の簡単そうなタイトルジェネレータから始めようと思っています。
自分のサイトのテスト環境の全ページに全力でアクセスしまくるプログラム作成。
しかし、本来は自分のサイトの外に出ないはずが、スクリプトや画像の埋め込みとして外へのリクエストが発生していたのでした。
アンパンマンDBとかは自動生成されるページも多いので時間がかかり、その対策も必要そうです。
うちのサイトにPA-API 4.0がまだ残っていると連絡が来ています。
もう全部滅ぼしたはずなんですが…。
https://developer.twitter.com/en/docs/tweets/timelines/api-reference/get-statuses-mentions_timeline
メンションのタイムライン?
Google に外部リンクの関係性を伝える - Search Console ヘルプ
aタグに付けるrel=nofollowは知っていたけど、新たにugcとsponsoredが加わっていた模様。
ugc:コメント欄のように、ユーザーが投稿して、ページ管理者には内容を制御できないもの
sponsored:広告
機能的にはどちらもnofollowと同等とのこと。
変更しないと不都合があるわけでもないけど、適切に使い分けた方が望ましいようです。
ゲーム記にページを作りました。
何か解説でもしようかと思ったけど、解説できるような写真が全然撮れなかったので、ほぼ自分の進捗を書くだけのページになりました。
で、その進捗はと言うと、ストーリークリア済みで、後はジェムリンゴ集めてクリア後要素に挑むだけなので、書くことがあまりないという…。
時期を外した感があります。
Chrome 80が密かに呼び寄せる地獄 ~ SameSite属性のデフォルト変更を調べてみた - Qiita
クッキーのデフォルト値が変わって、ドメインをまたいだクッキーの利用が難しくなるということです。
もろに影響を受けるのは、主にWeb広告で、うちだと、Amazonのアフィリエイトが当てはまります。
対応しなければいけないのはクッキーの発行側なので、私の方では何もできることはないのではありますが。
https://developer.atlassian.com/cloud/bitbucket/bbc-gdpr-api-migration-guide/
APIの仕様変更ですとっ!?
サイト運営に直接は関わらないけど影響あるから対応しておこう。
特に目的とかゲームクリアとかはないんですが、でかいギヤバネを場外に落としてみるといいです。しばらくしたらまた降ってきます。 pic.twitter.com/KGsSVqah3p
— 📛松田美文 (@matsuda323) 2019年2月2日
私は無事です。
近年は大地震の直後にさらなる大地震という例が続いていますし、しばらくは気を抜かないで防災しておきたいですね。
浮き沈みランチャを起動しているときにたまにほかのソフトのアップデートが失敗する例があって、こいつのせいだと思って検証していたのですが、検証コードではそれらしき現象は観察されず…。
もしかして浮き沈みランチャは犯人ではなかった?
C#で書いたやつがWebAssemblyになるという「Blazor」を試してみたのですが、サンプルプログラムからして動かないですね…。
まだ実験的なプロジェクトだそうだし、もっと開発が進んだり情報が出そろったりしてからまたさわろうかな。
QiitaにGraphQLの記事投稿。
GitHubのAPIを呼ぶPHPできました。
自分で使うのとは別に、これをネタに何か書こうかと思います。
新規投稿後は新規投稿一覧に飛ぶようにしました。
既にリリース済みですが、見るだけの人には関係ないし、新機能やバグ修正というほどでもないので、更新履歴での告知はしていません。
欲しい情報を取得するGraphQLを構築できました。
しかし、GraphQLを呼び出すプログラムの作り方がまだよくわかっていないので、もう少し調べる必要もありそうです。
GraphQLについて調べもの。
旧来のREST APIを使えばたぶん手っ取り早いんだけど、せっかく新しいのが出たんだから使ってみたい。
何度もリクエスト投げなくてもいいとか、必要なデータだけ取ってこられるとか、REST APIより有利な部分があるようですし。
極限まで手を抜いた形式のapple-touch-icon実験中。
favicon.icoはWindowsアイコン形式、apple-touch-icon.pngはPNG形式が正式ですが、今回、いずれも名前だけ合わせて中身JPEGにしてみました。
意外とまともに表示されるみたいですね。
アンパンマンDB向けに、browserconfig.xmlも簡易対応。
本当は更新通知とかもできるみたいですが、とりあえずはアイコンだけの対応。
favicon新調とかapple-touch-icon作成とか。
faviconは今どきの解像度に全然あっていなかったから高解像度版の追加。
apple-touch-iconは、404エラーが鬱陶しかったので作成。
今のところ、これを反映しているのはアンパンマンDBだけです。
TGWSルートを先に作ってしまうと、アンパンマンDBをブックマークした人がTGWSロゴを見ることになってしまうためです。
browserconfig.xmlも404エラーが出ているので、適当に作っておくつもりです。
TGWSAdmin、今はWindows10の個人PCを使って運用しています。
しかし、アップデートで勝手に再起動したり、そうでなくてもうっかり何かやらかして落ちたりということがたびたびあったわけです。で、遠隔地の安定したデータセンターに安価でサーバー機を仮想的に作れるVPSというものに興味を持っているという話を先月しました。
あのときは、Linuxに不慣れなまま時間が過ぎていって、いったんVPSを解約することになりましたが、そろそろまた具体的な行動を始めようかなと。
いきなりVPSを再契約するわけではありません。
プログラム自体は動く段階まで手元で持っていって、充分動くことが確認できたら、そのとき初めてVPSを契約し、プログラムを稼働させるのです。
VPSはLinuxで運用するつもりなので、まず、WindowsでもLinuxでも動くものを作らなければいけません。
当初、TGWSAdminが.NETでできていたので、Linuxでも動く.NET、.NET Coreを検討していました。実際、.NET Coreを両方の環境で動かす段階まではこぎつけました。
しかし、さらに検討を進めていくと、それは必ずしも得策ではありませんでした。
いくつか理由はあったのですが、大きかったのは2つ。
1つ目、同じ言語を使えるだけで、結局大改修が必要になってしまうということ。元のプログラムがWindowsフォームアプリケーションなので、ライブラリも動き方も、環境自体が大きく変化してしまうんですね。そうなれば、当然、プログラムも大きな変化が必要になるのです。
2つ目、ホットスワップ的なことをしたいこと。つまり、プログラムが動き続けている間に、プログラムの一部を差し替えてしまえるようにするのです。.NETアプリケーションは、基本的に、いったんシステムを全部止めてから、完成したものに全部差し替えるという作業が必要になります。タスクAが動いている間にタスクBを最新版に更新なんてことは、無理ではないにしても大変なのです。
そこで、目を付けたのが、PHPです。
元々サーバー上で動かすことを前提としていて、WindowsでもLinuxでも同じように動かすことができて、私自身、.NETに負けないぐらい使い慣れています。主にWebサーバーで動かすものなので、ユーザーインターフェースもWebアプリとして作れば済みます。
プログラムは大改修どころかフルスクラッチになってしまいますが、これを機に元のプログラムで良くないと思っていた設計も見直すつもりです。動作中のプログラムの一部差し換えは、PHPファイルをただ上書きするだけで済みますね。
と、いうことで、VPS版のTGWSAdminは、PHPで実装されたWebアプリとして提供され、各タスクはPHPファイルを適時呼び出すことで実現される、という形で実現しようと思います。
VMWareには今までUbuntu入れてたけど、今度はCentOSで。
さくらのVPSでもUbuntuは使えるのでこだわる必要はなかったのですが、せっかくCentOS触り始めたので。
まだ具体的なことは何も始められていないけど、とりあえずOSインストールとSSH接続まではやっています。