いずれは何処かにまとめたい。

2022.02
元々、spitz用にとっておいたが、１つのseesaawiki-IDでは新たに作成できなくなったので、とりあえず
ここをPC/AT機用に使う。元のお題は、
Slackware-15.0 spitz GPE メモ
メモとまとめ。Sharp SL-C3x00へのOpenSource(SlackwareARM Linux)の自家製移植の試行。
\
spitzは、Zaurus(SL-C3000)のこと。でもSL-C3100、SL-C3200にも入れてる。
GPEは、X(diet-x/kdrive)ベース。
動作中にバッテリが外せるように(分解して)電池ぶたロック部品を外してある。(予定。まだやれてない)
Life with SlackZaurus たまに Cacko の構築。
\
しばらくはspitzのシステム構築はしない。休止中。

2022.02
Flutterとは何か？ 使うメリットや特徴を理解する
https://codezine.jp/article/detail/12718
もともと「Dart」は、JavaScriptの代替言語として2011年にリリースされました。そのため、TypeScriptと似ており、目的も同じのためおおよそ同等レベルの言語と捉えても良いです。
オープンソースのアプリケーションUIフレームワーク「Flutter」、Windowsサポートが正式版に
https://codezine.jp/article/detail/15557

2022.06
Flutter 実行環境、でググった：
実際にFlutterを触ってみよう～初めてのアプリ開発 https://codezine.jp/article/detail/13143
android-studio-ide linux、でググった：
Android Studio のインストール | Android デベロッパー https://developer.android.com/studio/install?hl=ja
［Ubuntu］Android Studio をインストールしショートカットを作成する https://qiita.com/kaleidot725/items/dc1eccc9064ab6b8cd4a
Flutterは個人開発に向いている、と聞いてググった：
https://qiita.com/tags/%e5%80%8b%e4%ba%ba%e9%96%8b%e7%99%ba
Software Design 2022年4月号 はじめてのFlutter
https://gihyo.jp/magazine/SD/archive/2022/202204

2022.06
FlutterやりたくなったらJavaを入れなきゃならないなあ。アプリ作成で使うだけで普段使うわけじゃ
ないからいいってか。

2022.03
商用 レンタル Linux サーバー シェア、でググった：
(CentOS >> Ubuntu >> Slack 現状はほぼこれだろう)
サーバー OSシェア 2021、でググった：
https://ja.hostadvice.com/marketshare/os/jp/
まあしかし、よく知るシステムでさっと動かしてからDockerで本番環境を持ってきて試す、のも
ありだろう。サーバー環境作ってDockerでコンテナ化するかな。
その後、格安NotePCでDockerはムリだと分かった。(2022.11)

2022.03
WordPressでジタバタした件：
phpちゃんと動いてるか?で、phpをちょっとお勉強した。
$ php -a
Interactive shell
php > echo \_\_DIR__;
/myproj
php > quit
$ pwd
/myproj
\
ググるとたまに出てくる、認証は基本認証だけですが、というやつ
https://riceplanting.hatenablog.jp/entry/2013/05/19/183339

2022.04
nginxは「エンジンエックス」と言うらしい。

2022.04
昔のLinux本だと、インストールして使う本とネットワークサーバ本に分かれていて、メーラー(MUA)
がMTAと一緒にネットワークサーバ本に入ってしまってる事が多かった。やっぱりメーラーはインストー
ルして使う本だと思う。それでもSlackの場合はこの20年以上使い方がほぼ変わってないのは救いだ。
自分の使い方が変わらないだけか。自分の変わらない使い方をさせてくれるSlackは偉大だ。もうとっく
に元は取ってるな。いやよく見るとちょっとづつ変わってるか。でもついて行けてる。メンドクサイ事
はやってないだけか。
大昔からもっと変わらないものは他にある -> FreeBSD。ここ十数年どうしてるかは知らない。

2022.05
当面、基本的には、サイトの構成は、
動的なサイト、専用サーバー：JSフレームワーク/Go
静的なサイト、レガシーサイト、共用サーバー：JS旧lib/PHPやRuby
に収束していくのではないかと自分的には思っているが、ユーザーのデバイスのパフォーマンスに合わせ
て、サーバ側で頑張るかクライアント側で頑張るか、の両方を作る必要性はあるかもしれない。ないか。
Firefox-3/ZaurusでもWeb見ようとするのは自分くらい。

2022.06
はじめてのGitLab（鍵認証によるSSH接続 ～ git cloneまで）
https://laraweb.net/environment/8473/
gitlab github 違い、でググった：

GitとGitHub、GitLab｜概要・それぞれの違いについて解説！

例えばGitLabでは「グループ・プライベートリポジトリを作れる」などの特徴があります。むしろここが魅力的であると考えられています。
GitHubはMicrosoft社の製品ですので商用のライセンスが適用されています。それに対してGitLabはオープンソースソフトウェアとして開発されています
ライセンスの違いはありますが、基本的にどちらも無料で利用できます。Microsoft社は無料で利用できるフリープランの機能拡充に力を入れましたので、実質的には無料で十分な機能を得られます。

ちょっとした用事でIPパケットを見たくなった件： 2022.09
pingするのにinstallした。iputils-20211215-x86_64-1
netcatするのにinstallした。nc-1.10-x86_64-4
(データが途切れずストリームだったのでsedでCRを入れようとしたが、そもそもCRされていない
\とsedは結果を出力できず、foldを使った)

redmineでたまたま： 2022.10
スケジュール管理で使えるが、たまたまググって rest api を実装しているので(当たり前か)、
PHPかRubyでポートフォリオにでも使ってみるかな。

ググってたまたま見つけた： 2022.10
qiita zenn、でググった：
結局ZennかQiitaかnoteか個人ブログをどうやって使い分けると良いのか
https://zenn.dev/nomuraya/articles/howtouse-zenn
(ググった先をどう判断するかについての記事(私見))

ちょっとした用事でSerial通信をしたくなった件： 2022.11
unix cuコマンド、でググった：
https://qiita.com/g0117736/items/270942c37483183d98ef
https://hassiweb-programming.blogspot.com/2020/02/serial-comm-on-linux.html
$ ls /mnt2/slackware64/*/*uucp*.txt
/mnt2/slackware64/n/uucp-1.07-x86_64-5.txt
ls -l /dev/ttyUSB0
crw-rw—- 1 root root 188, 0 Nov 12 yy:zz /dev/ttyUSB0
ls -l /usr/bin/cu
\-r-sr-xr-x 1 uucp uucp 167144 2月 13 2021 /usr/bin/cu
ttyUSB0をchmodしないと実行できないが、cuをchwon_rootしてもsuidが付いているので実行
できる。ttyUSB0の方をchwon_uucpでもいいか。USB抜き差しでttyUSB0いたりいなかったり
するのでcuをchwon_rootの方がいいか。

ふと思った事： 2022.12
CygWinはあるがCygMacは無いのか?
MacはBSD系?(March)だろうから普通にSlack感覚(startxでtwm起動)でできてしまうのか?。が、
Winと同じでWMを変える事ができないだろうから、Xやtwmをコンパイルする事になるのかな?

2023.02
Dropbox使おうとしたら、DLしろと。wgetが2になっていた。がパラメタ非互換らしい。
$ sudo installpkg /mnt2/slackware64/n/wget2-2.0.0-x86_64-2.txz
$ grep -E ‘bin|lib’ /var/log/packages/wget2-2.0.0-x86_64-2 | sed s@^@/@ | xargs ldd | grep found
$ sudo installpkg /mnt2/slackware64/a/lzlib-1.13-x86_64-1.txz
(依存があったのでinstallした。lzlibは依存がなかった)
$ sudo installpkg /mnt2/slackware64/n/wget-1.21.2-x86_64-1.txz
\
# wget2 (a non-interactive network retriever v2)
# GNU Wget2 is the successor of GNU Wget, a file and recursive website
# downloader. Designed and written from scratch it wraps around libwget,
# that provides the basic functions needed by a web client. In many
# cases Wget2 downloads much faster than Wget1.x due to HTTP2, HTTP
# compression, parallel connections and use of If-Modified-Since HTTP
# header.
# Design and implementation by Tim Rühsen, with lead maintainers
# Tim Rühsen, Darshit Shah, and Giuseppe Scrivano.
\
# lzlib (lzip compression library)
# Lzlib is a data compression library providing in-memory LZMA
# compression and decompression functions, including integrity checking
# of the decompressed data. The compressed data format used by the
# library is the lzip format. Lzlib is written in C.
# Homepage: http://www.nongnu.org/lzip/lzlib.html
\
# wget (a non-interactive network retriever)
# GNU Wget is a free network utility to retrieve files from the
# World Wide Web using HTTP and FTP, the two most widely used Internet
# protocols. It works non-interactively, thus enabling work in the
# background after having logged off.
# The author of Wget is Hrvoje Niksic .

Dropboxは老舗だけあってlinuxコマンドでもできるらしい。速いのだろうが今風のやり方では
ないのだろうな。今時はブラウザだけで完結するんじゃないの?
https://help.dropbox.com/ja-jp/installs/linux-commands
https://www.dropbox.com/ja/install?os=lnx

PC/SPコーディング
https://fastcoding.jp/services/htmlcoding/

ChatGPTでの始めての質問： 2023.03
今日の日本の○○県の天気は？
申し訳ありませんが、私は現在の情報を持っていません。情報を得るには、天気予報サイトやアプリを確認するか、○○県の地元のニュースや天気情報を調べることをお勧めします。
(なるほど過去の検索だからか。しかし天気予報は見てないのか?)

MySQL/MariaDB 練習ネタ 2023.04
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/WordPress%a4%c7HP%a4%f2%ba%ee%a4%c3%a4%c6%a4%df%a4%eb

Spring Framework はJavaのFWなので練習しない。Javaを練習すると、C++の練習みたいになって
本業っぽくなってくる気がするので、当面はやらない。2023.05
git_labサーバ立て練習とgitコマンドまとめもやるか。そのうち。
\
java tomcatとは、でググった：
https://contextpath.zealseeds.com/basicKnowledge/Tomcat/index.html
ApacheとTomcatの違い
Apache（Apache HTTP Server）とTomcatの違いについてです。 ApacheもTomcatもHTTPサーバの機能を提供するソフトウェアですが、TomcatはJavaでできており、WebコンテナというJava Servletを実行する機能があるところが大きな違いがあります。 ミドルウェアの区分でいうとApacheがWebサーバ、TomcatがWebアプリケーションサーバになります。
TomcatはServer＞Service＞Connector、Engineという階層で管理
Tomcatのプロセスでは、Server＞Service＞Connector、Engineという階層で管理されています。 さらに掘り下げるとEngine＞Host＞Contextという階層になっていて、ContextがWebアプリケーションに該当します。
TomcatへのリクエストはConnector部分が受け付けてEngineの中のWebアプリケーションへ伝えます。 Tomcatはブラウザから直接HTTPのリクエストが送信できますが、間にApache HTTP ServerやNginxといったWebサーバーを経由する構成で利用されるのが一般的です。

Zoom、再開：2023.08
$ tar xpf zoom_x86_64.tar.xz
$ LD_LIBRARY_PATH=. ldd zoom
\ linux-vdso.so.1 (0x00007ffebed5b000)
\ libcef.so => not found
\ libffmpeg.so => not found
\ libxcb-image.so.0 => not found
\ libxcb-keysyms.so.1 => not found
\
なんと、Qt使ってるぞ～、Zoomは。
\ libQt???.so.? => not found
\
$ ar x zoom_amd64.deb
$ mkdir package-zoom; cd package-zoom
$ tar xf ../data.tar.xz
tar: ./usr/bin/zoom: “/opt/zoom/ZoomLauncher” へのシンボリックリンクが作れません: 許可されていない操作です
tar: 前のエラーにより失敗ステータスで終了します
$ sudo mkdir /opt/zoom; sudo chown ore /opt/zoom
$ tar xf ../data.tar.xz
Slack/Win共用環境で作業したかったのでexFat上で展開してたが、exFatではパーミッションが使えない
ので、ext3/ext4上で展開することにした。

日本人は｢超過死亡増加｣の深刻さをわかってない (たまたま、2023.09)
https://toyokeizai.net/articles/-/628413
特記すべきは、3月10日の『ランセット』や『ネイチャー』の論文、記事での日本に関する情報を、国内のマスコミは、一紙も報じなかったことだ。今回のように、厚労省や国立感染症研究所が発表すれば、大々的に取り上げるが、世界的学術誌の記事は「無視」する。これでは国民は堪らない。コロナ対策での過剰な自粛が国民の命を奪っているのだから、新しい事実が判明すれば、早急に対応を変えねばならないが、マスコミが報じないのだから、国民は自粛を続けるしかない。

Node.jsの2022年を振り返り、Node.jsの未来を見つめてみた (2023.09)
https://gihyo.jp/article/2023/01/tfen006-nodejs

impress： (2023.10)
Web系でバイトするには、プレゼン用のアプリを入れておいた方が良いかもしれない。
\
linux プレゼンアプリ、でググった：
Linux 向けの最高の PowerPoint 代替ツール
https://ja.linux-console.net/?p=2646
(昔はOpenOfficeというのがあったと思うが、今はLibreOfficeなのか?)
\
zoomが先か。Qtいれなきゃいかんか～。Qt内臓のようだからそれでいいか～?
https://www.linuxquestions.org/questions/slackware-14/new-dependency-for-zoom-5-4-a-4175684582/

webassembly とは、でググった： (たまたま、2023.10)
https://qiita.com/ShuntaShirai/items/3ac92412720789576f22
https://zenn.dev/hodagi/articles/4925afbeb3c4dc

ChatGPTに聞いた。(2024.01)
これを npm run dev にて動かし、http://localhost:3000/ でアクセスすると動作するのですが、npm run buildしてデプロイしたものにアクセスすると 404 not found となります。なぜでしょう？
\
Next.js で開発サーバーを起動しているときは、APIルートは自動的に有効になり、ファイルの構造に基づいてルーティングが行われます。しかし、ビルドしてデプロイした場合、これは手動で設定する必要があります。
次の手順を確認してください：
1. next.config.js ファイルの存在確認:
\ プロジェクトのルートに next.config.js ファイルがあることを確認してください。もし存在しない場合は、作成してください。
2. next.config.js へのルーティングの設定:
\ next.config.js ファイルに、APIルートへのルーティングを手動で追加する必要があります。以下は、APIルートへの設定例です。
\module.exports = {
\ async rewrites() {
\ return [
\ {
\ source: ‘/api/:path*’,
\ destination: ‘/api/hello/:path*’,
\ },
\ ];
\ },
\};
\ この例では、/api/* へのリクエストを /api/hello/* にリライトしています。この設定を追加することで、ビルドしたアプリケーションでも API ルートにアクセスできるようになります。
3. ビルドとデプロイ:
\ 設定ができたら、npm run build でアプリケーションをビルドし、その後 npm start などでデプロイしてください。
\
これで、ビルドしたアプリケーションがデプロイされ、API ルートにアクセスする際に 404 エラーが解消されるはずです。手順に何か問題があれば、再確認してみてください。

$ npm run start
\
\> practice387@0.1.0 start
\> next start
\
\ ▲ Next.js 14.0.3
\ – Local: http://localhost:3000
\
\Error: “next start” does not work with “output: export” configuration. Use “npx serve@latest out” instead.
\ at /myproj/oldcygwin/practice300/practice388/node_modules/next/dist/server/next.js:208:31
\ at async NextServer.prepare (/myproj/oldcygwin/practice300/practice388/node_modules/next/dist/server/next.js:152:24)
\ at async initializeImpl (/myproj/oldcygwin/practice300/practice388/node_modules/next/dist/server/lib/render-server.js:91:5)
\ at async initialize (/myproj/oldcygwin/practice300/practice388/node_modules/next/dist/server/lib/router-server.js:103:22)
\ at async Server. (/myproj/oldcygwin/practice300/practice388/node_modules/next/dist/server/lib/start-server.js:236:36

ChatGPTに聞いた。(2024.01)
日本人には癌患者が多いらしいです。添加物の多い食事は癌の原因と言われていますが、添加物の多いカレーを主食としているインド人は癌患者が多いですか？
\
癌の発生には様々な要因が関与しており、食事だけが原因ではありません。癌の発生には遺伝的な要因、環境要因、ライフスタイルの違いなどが影響を与えます。日本人の中で癌患者が多いとされる一因は、喫煙率の高さや食生活の変化、遺伝的な要因などが挙げられます。
\
インド人が主食としている添加物の多いカレーが癌患者数の増加と関連しているかどうかについては、はっきりとした結論は難しいです。インドの食事習慣は地域によって異なり、様々な食材が使用されています。ただし、一般的に言って、食事だけが癌の原因となるわけではなく、他の要因も考慮する必要があります。
\
癌のリスクを減少させるためには、バランスの取れた食事、健康的なライフスタイル、定期的な運動、喫煙や飲酒の制限などが重要です。ただし、これらの要因は個人や地域によって異なります。発生率が異なる理由は様々であり、それを単純に食事だけに帰すことは難しいです。

Slackware-15.0 メモ Slackware Linux 15.0 でやったこと。に題材を付けるなら、(2024.01)
格安ノートPCに生LinuxをインストールしてWebアプリ学習、だ。そこで、ググってみた。
格安ノートPCにLinuxをインストールしてWebアプリ学習：
【第38回】ノートPCでもUbuntuを使ってみよう！
https://pc.watch.impress.co.jp/docs/column/ubuntu/1544354.html
webアプリの開発用にLinuxノートPCを1台欲しいとしたら、どうしたらいいでしょうか？Windows機を買ってOS入れ替えがベストでしょうか。
https://jp.quora.com/web%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AE%E9%96%8B%E7%99%BA%E7%94%A8%E3%81%ABLinux%E3%83%8E%E3%83%BC%E3%83%88PC%E3%82%921%E5%8F%B0%E6%AC%B2%E3%81%97%E3%81%84%E3%81%A8%E3%81%97%E3%81%9F%E3%82%89-%E3%81%A9%E3%81%86
(スペック低すぎるとWeb開発できてもWeb制作できないかも。AdobePS動かん(Gimpは無問題)。あとRAM
少ない(2GBRam)とDocker重い。生Linux環境で開発してDocker環境は最終確認だけにする)

apache nginx 使い分け、ググった： 2024.01
https://qiita.com/kamihork/items/49e2a363da7d840a4149
一方、NginxはCPUリソースがたくさん必要な処理には向いていない
https://cn.teldevice.co.jp/column/38275/
処理能力の高さや並行処理能力、メモリ消費量の少なさなどがNGINXのポイント
(Nginxは小さくて多い処理、Apacheは大きくて少ない処理)

忘れないようにやりたい事を書いておく： (2024.01)
生コンテナ
パーティションを切った領域に、Docker compose? でコンテナを持ってきて、efibootmgr -n xxx
でPC再起動、Linuxで起動して格安PCで生で使う。

漢字を使う日本人に中国人は好意的か？
ChatGPT：
漢字を使う文化を共有することは、日本人と中国人の間にある文化的なつながりの一つです。漢字が日本の言語や文化に深く根ざしていることは、中国人にとって興味深い側面であり、敬意を表する理由にもなり得ます。しかし、好意的かどうかは個人によって異なります。
一般に、中国人は日本人が漢字を使い続けていることに対して、特に肯定的な感情を持っているわけではないかもしれませんが、文化的な共通点として認識していることは確かです。文化や言語の交流は相互理解を深める機会を提供しますが、歴史的な出来事や現代の政治的な緊張が人々の感情に影響を与えることもあります。
漢字を通じた文化的な繋がりは、中国人と日本人の間で相互の興味や尊敬の基盤を形成することがありますが、個々の人々の好意的な態度は、多くの要因によって左右されるため、一概には言えません。両国間の人々が互いの文化を尊重し、理解を深めようとする姿勢が、ポジティブな関係を築く鍵となります。
\
英語を学習すると、英米人は日本人に好意的になるか？
ChatGPT：
英語を学ぶことは、文化的な架け橋を築く手段の一つであり、英語圏の人々、特に英国人やアメリカ人との間で相互理解とコミュニケーションを促進する効果があります。英語を話せる日本人は、言語の壁を越えて英米人と直接交流することができ、その結果、お互いの文化や価値観について学び、理解を深めることが可能になります。これは、好意的な関係を築くための良い出発点となり得ます。
しかしながら、英語を学ぶことが直接的に英米人が日本人に好意的になるという結果を保証するものではありません。人々の態度や感情は、単に言語能力だけでなく、個人的な経験、文化的背景、相互の行動や価値観の理解に基づいて形成されます。英語を話す能力は、コミュニケーションを通じて相互理解を深めることに役立ち、好意的な関係を築くための一つの要素に過ぎません。
また、英語を学ぶことは、日本人自身にとっても利点があります。世界共通語としての英語を理解し、話すことができれば、国際社会でのコミュニケーション、情報の取得、教育やビジネスの機会へのアクセスが容易になります。これは、個人の視野を広げ、異文化間の架け橋となる能力を高めることに繋がります。
結論として、英語学習は英米人と日本人の間の好意的な関係を築く助けになり得ますが、真の相互理解や好感度は、言語能力を超えた多くの要素に依存します。
\
(やっぱり外国語はAI翻訳で十分と思われる)
\
IT時代の現代で、ビジネスに感情は必要か？
ChatGPT：
IT時代の現代においても、ビジネスにおける感情の役割は非常に重要です。技術の進化とデジタル化が進む中で、人間の感情や対人関係のスキルは、企業の成功においてますます価値を増しています。以下に、ビジネスにおける感情の重要性についていくつかの点を挙げます。
1.顧客関係の構築: 感情知能（EQ）は、顧客との強い関係を築く上で不可欠です。顧客の感情やニーズを理解し、共感する能力は、顧客満足度を高め、ロイヤリティを確保する上で重要です。デジタル時代であっても、人々は自分たちのニーズを理解し、価値を提供してくれる企業との接点を求めています。
2.チームワークとコラボレーション: 効果的なチームワークとコラボレーションは、企業が革新的なアイデアを生み出し、競争力を維持するために不可欠です。これには、感情の理解、共感、そして適切なコミュニケーションが必要です。チーム内での信頼と相互理解は、生産性と創造性を促進します。
3.リーダーシップ: 強いリーダーは、自己認識、自己管理、社会的認識、関係管理といった感情知能のコンポーネントを活用して、チームを導き、モチベートします。感情を理解し、適切に対応することで、リーダーは信頼と尊敬を得ることができ、チームの士気とパフォーマンスを向上させることができます。
4.変化への適応: ビジネス環境は常に変化しており、企業と個人は新しい挑戦に迅速に対応する必要があります。感情の理解と管理は、ストレスや不確実性に対処し、変化への適応をスムーズにするのに役立ちます。
5.倫理的判断と信頼の構築: 感情を考慮することは、倫理的な意思決定にも重要です。企業が社会的責任を果たし、顧客や従業員からの信頼を得るためには、感情に基づく倫理的な判断が必要です。
技術が仕事の多くを自動化し、人間と機械の相互作用が増える中で、人間特有の要素である感情の理解と共感は、ビジネスの差別化要因となり得ます。したがって、IT時代の現代でも、ビジネスにおける感情の重要性はむしろ増していると言えるでしょう。
\
(つまり、ビジネスに感情は必要だが、外国語はAI翻訳で十分。言語能力を超えた多くの要素に依存しているため)

JavaScriptフレームワークが発達した今でも、スタイリングが干渉することがないよう、CSS設計は必要か？
ChatGPT：
はい、JavaScriptフレームワークが発達した現在でも、CSS設計は非常に重要です。フレームワークが提供するコンポーネントベースのアプローチやスコープ付きスタイルなどの機能は、スタイルの干渉を防ぐのに役立ちますが、効果的なCSS設計はそれらの機能を補完し、より強固でメンテナンスしやすいスタイリングを実現します。
CSS設計の重要性
・再利用性と拡張性: 効果的なCSS設計は、スタイルの再利用性と拡張性を高めます。これにより、開発時間の短縮とプロジェクトの拡張が容易になります。
・メンテナンス: 大規模なプロジェクトや長期間にわたるプロジェクトでは、CSSのメンテナンスが大きな課題となることがあります。良いCSS設計は、将来の変更や追加が容易なコード構造を促します。
・パフォーマンス: CSS設計を最適化することで、ウェブページの読み込み時間を短縮し、パフォーマンスを向上させることができます。不要なスタイルのオーバーライドや複雑なセレクタはパフォーマンスに悪影響を与える可能性があります。
・チームワークとコミュニケーション: 効果的なCSS設計は、チームメンバー間での一貫性を保ち、コードの解釈や編集が他の開発者にとっても理解しやすくなります。
JavaScriptフレームワークとCSS設計
多くの現代的なJavaScriptフレームワーク（React、Vue.js、Angularなど）は、スタイルのスコープ付けやコンポーネントレベルでのスタイリングを容易にしますが、全体のアーキテクチャ内でのCSSの構造化や管理については、依然として開発者の責任です。例えば、フレームワークを使用していても、BEMのような命名規則を採用することで、クラス名の衝突を避け、スタイルの意図が明確に伝わりやすくなります。
加えて、CSSプリプロセッサ（Sass、Lessなど）の使用やCSS-in-JSライブラリ（Styled Components、Emotionなど）を採用することで、スタイリングの問題をさらに洗練された方法で解決することができます。これらのツールやライブラリは、フレームワークと組み合わせて使用することで、開発の生産性を高め、より複雑なスタイリング課題に対応することが可能になります。
結論として、JavaScriptフレームワークが発達した今でも、CSS設計の原則とベストプラクティスを適用することは、ウェブ開発プロジェクトの成功に不可欠な要素です。

WebGL (2024.06)
https://www.kohgakusha.co.jp/books/detail/978-4-7775-1958-3
「WebGL」は、Web上で3Dグラフィックスを動かすためのAPIで、そのベースとなっている技術は、「組み込み機器」用の「OpenGL」として策定された、「OpenGL ES 2.0」となっているが、これは今でも変わらないか？
ChatGPT
WebGLは、Web上で3Dグラフィックスを動かすためのAPIで、そのベースとなっている技術は「OpenGL ES 2.0」です。この点については現在も変わりません。WebGLの標準化が進む中で、基本的な仕様やAPIの互換性は維持されています。
WebGLの主要バージョンには、以下のものがあります：
・WebGL 1.0：これはOpenGL ES 2.0に基づいており、2011年に正式リリースされました。
・WebGL 2.0：これはOpenGL ES 3.0に基づいており、2017年に正式リリースされました。WebGL 2.0はWebGL 1.0の後継であり、より高度な機能とパフォーマンスを提供します。
つまり、WebGL 1.0はOpenGL ES 2.0に基づいており、WebGL 2.0はOpenGL ES 3.0に基づいています。最新のWebGL 2.0の仕様でもOpenGL ESを基盤としていますが、バージョンが異なります。

Shopify はどこのサーバを使っている？ (2024.07)
ChatGPT
Shopifyは主にGoogle Cloud Platform (GCP) を使用しています。GCPのインフラストラクチャを活用することで、Shopifyはスケーラブルで信頼性の高いサーバを運用し、世界中のユーザーにサービスを提供しています。
具体的には、Shopifyは以下のようなGCPサービスを使用しています：
Google Compute Engine：仮想マシンを利用してアプリケーションのホスティングを行う。
Google Kubernetes Engine (GKE)：コンテナオーケストレーション。
Google Cloud Storage：データのストレージ。
BigQuery：データ分析。
Cloud SQL：リレーショナルデータベースの管理。
Cloud Pub/Sub：メッセージングサービス。
Cloud CDN：コンテンツデリバリーネットワーク。
Shopifyはまた、マイクロサービスアーキテクチャを採用しており、様々なサービスが連携して動作することで高いパフォーマンスと可用性を実現しています。
\
ShopifyはRubyで書かれているのではないのか？
ChatGPT
はい、Shopifyのアプリケーションは主にRuby on Railsを使用して開発されています。Ruby on Railsは、Rubyプログラミング言語で書かれたウェブアプリケーションフレームワークで、Shopifyの迅速な開発とスケーラビリティに寄与しています。
Shopifyのインフラストラクチャについては、以下のポイントが重要です：
・アプリケーションレイヤー：Shopifyのウェブアプリケーションは、Ruby on Railsで構築されています。これは、迅速なプロトタイピングと堅牢なアプリケーションの構築に適しています。
・クラウドインフラストラクチャ：Shopifyは、アプリケーションをホスティングするためにGoogle Cloud Platform (GCP)を使用しています。これは、スケーラビリティと信頼性を確保するためです。
・データベースとストレージ：Shopifyは、Google Cloud StorageやCloud SQLなどのGCPサービスを使用してデータを保存および管理しています。
・コンテナ化とオーケストレーション：Shopifyは、Google Kubernetes Engine (GKE)を使用してコンテナ化されたアプリケーションを管理しています。これにより、スケーラブルなマイクロサービスアーキテクチャが実現されています。
これらの要素を組み合わせることで、Shopifyは高性能で信頼性の高いeコマースプラットフォームを提供しています。
\
Shopifyのマイクロサービスとはどの部分か？Railsはマイクロサービスとは言わないはずだが。
ChatGPT
おっしゃる通り、Ruby on Railsは通常、モノリシックアーキテクチャで使用されることが多いです。しかし、Shopifyはそのインフラストラクチャのスケーラビリティと柔軟性を向上させるために、特定の機能やサービスをマイクロサービスとして分離している部分もあります。
Shopifyのマイクロサービスアーキテクチャについての具体的な詳細は公にされているわけではありませんが、以下のようなアプローチが考えられます：
1.特定の機能の分離：Shopifyの特定の機能、例えば支払い処理や注文管理などを、マイクロサービスとして分離している可能性があります。これにより、各機能が独立してスケールし、開発チームがそれぞれのサービスを独立してデプロイおよび管理できるようになります。
2.コンテナ化とオーケストレーション：ShopifyはGoogle Kubernetes Engine (GKE)を使用して、コンテナ化されたマイクロサービスを管理しています。これにより、アプリケーションの異なる部分が独立して動作し、スケーラビリティと信頼性を向上させることができます。
3.サービス間通信：マイクロサービス間の通信は、HTTP APIやgRPCなどのプロトコルを使用して行われることが一般的です。これにより、各サービスが独立して動作しながらも、連携して全体の機能を提供できます。
4.データ管理：各マイクロサービスは独自のデータストアを持つことができ、データの整合性と独立性を保ちながらサービスを提供します。
Shopifyの主なアプリケーションが依然としてRuby on Railsで動作している一方で、特定の高負荷または独立性が求められる機能をマイクロサービスとして分離することで、全体のアーキテクチャの柔軟性とスケーラビリティを向上させています。

 

Meld関係：
meld received signal SIGTRAP, Trace/breakpoint trap in g_log_structured_array () from /usr/lib64/libglib-2.0.so.0、でググった：
https://bbs.archlinux.org/viewtopic.php?id=276467
https://qiita.com/swakamoto/items/0d5edf7ab3b7e6b7a75f

/etc/glib-2.0/settings/defaults というファイルは何をするとできるのか？
ChatGPT
/etc/glib-2.0/settings/defaults というファイルが存在する場合、それはシステム全体のデフォルト設定を定義するために使用される可能性があります。このファイルは、GLibやGTKアプリケーションの設定値を指定するために使用されることが考えられます。
具体的なファイルの役割

/etc/glib-2.0/settings/defaults は、システム管理者がデフォルトの設定値を提供するために使用できるファイルで、GLibやGTK+の設定をカスタマイズするために存在する可能性があります。
生成方法とカスタマイズ方法

通常、このようなファイルは以下のようなシナリオで生成または編集されます。

1.インストールスクリプトやパッケージマネージャ:
パッケージのインストール時に、特定の設定ファイルが生成される場合があります。例えば、debやrpmパッケージがインストールされたときに、設定ファイルが配置されることがあります。

2.システム管理者による手動設定:
システム管理者が特定の設定をシステム全体に適用するために、このファイルを手動で作成または編集することがあります。

3.構成ツールやスクリプト:
構成管理ツール（Ansible, Puppet, Chefなど）やカスタムスクリプトを使用して、このファイルを自動生成または管理することがあります。

ファイルの作成と編集
もし /etc/glib-2.0/settings/defaults ファイルが存在しない場合、自分で作成して設定を定義することができます。
1.ファイルの作成:
ファイルを作成し、適切な設定値を記述します。以下は、ファイルの基本的な構造の例です。
bash
$ sudo nano /etc/glib-2.0/settings/defaults

2.設定値の記述:
設定値を記述します。具体的な設定内容は、カスタマイズするアプリケーションやシステムの要件に依存します。例えば：
ini
[org.gnome.desktop.interface]
gtk-theme=’Adwaita-dark’
icon-theme=’Adwaita’
[org.gnome.desktop.wm.preferences]
button-layout=’close,minimize,maximize:’

3.設定の反映:
ファイルを保存し、設定が正しく反映されることを確認します。

設定スキーマの再コンパイル
設定スキーマが変更された場合は、GLibスキーマを再コンパイルする必要があります。これは、glib-compile-schemas コマンドを使用して行います。

bash
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas

確認
設定が正しく適用されているか確認するためには、GSettingsコマンドラインツールを使用して設定値を確認します。
bash
$ gsettings get org.gnome.desktop.interface gtk-theme
$ gsettings get org.gnome.desktop.wm.preferences button-layout

これらの手順に従って、/etc/glib-2.0/settings/defaults ファイルを作成および編集し、システム全体のデフォルト設定を管理できます。具体的な設定内容は、利用するアプリケーションやデスクトップ環境に依存します。

WindowManagerはgnomeではなくtwmなのだが。
ChatGPT
TWM（Tab Window Manager）を使用している場合、GNOMEやGTKの設定は直接関係しないことが多いです。TWM自体は非常にシンプルなウィンドウマネージャであり、デスクトップ環境の設定スキーマなどの高度な設定システムを持ちません。

しかし、GTKアプリケーションを使用している場合、その設定はGLibやGSettingsによって管理されることがあります。以下に、TWM環境でGLibやGSettingsのデフォルト設定を管理する方法を示します。
GSettingsとGTKアプリケーションの設定

TWMを使用している場合でも、GTKアプリケーションの設定を管理するためにGLibやGSettingsの設定を行うことができます。
1.設定ファイルの作成
/etc/glib-2.0/settings/defaults ファイルを手動で作成して、GTKアプリケーションのデフォルト設定を定義します。
bash
$ sudo nano /etc/glib-2.0/settings/defaults

ここに、GLibやGSettingsで使用する設定を追加します。例えば、GTKテーマやアイコンテーマを設定する場合：
ini
[org.gnome.desktop.interface]
gtk-theme=’Adwaita-dark’
icon-theme=’Adwaita’
[org.gnome.desktop.wm.preferences]
button-layout=’close,minimize,maximize:’

2.設定スキーマの再コンパイル
設定ファイルを作成した後、GLibのスキーマを再コンパイルします。
bash
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas

3.設定の確認
設定が適用されているか確認するために、GSettingsコマンドを使用します。
bash
$ gsettings get org.gnome.desktop.interface gtk-theme
$ gsettings get org.gnome.desktop.wm.preferences button-layout

TWMの設定
TWM自体の設定は、主に.twmrcファイルを使用して行います。このファイルにウィンドウマネージャの設定を記述します。
.twmrcファイルの例

以下は、TWMの設定ファイル（.twmrc）の基本的な例です：
twmrc
# .twmrc file
# Define colors
Color
{
\ BorderColor “black”
\ DefaultBackground “grey20”
\ DefaultForeground “white”
}

# Define menu
Menu “Main”
{
\ “xterm” f.exec “xterm &”
\ “gvim” f.exec “gvim &”
\ “firefox” f.exec “firefox &”
\ “exit” f.exit
}

# Define key bindings
#
# Ctrl + Alt + Delete to exit
#
“Meta+Ctrl” = f.quit

# Define mouse bindings
#
# Left mouse click on root window brings up menu
#
“Button1” = : root : f.menu “Main”
このファイルをホームディレクトリに配置することで、TWMの起動時に読み込まれます。
bash
mv .twmrc ~/.twmrc
以上の手順で、TWM環境でGTKアプリケーションの設定を管理しつつ、TWM自体の設定も行うことができます。TWMは非常にシンプルなウィンドウマネージャであり、設定が他のデスクトップ環境と比べて簡素であることが特徴です。

たまたま見つけた、nohupコマンド：
https://note.com/ym202110/n/ndaf6ea2b0ce7

まず、プロジェクトのディレクトリを作成し、必要なパッケージをインストールします。
$ mkdir my-static-server
$ cd my-static-server
$ npm init -y (対話なしでdefで設定ファイル作成)
$ npm install express

 

2024.08
ECサイトで使う Node.jsフレームワーク、でググった：
https://qiita.com/kohsukeve/items/d4ce68b8b63e51123756
https://noveltyinc.jp/media/node-js
https://offers.jp/media/programming/a_3610#outline-2

 

2024.10
php artisan serve を実行すると、管理パネルを使えるが、Apacheにて http://127.0.0.1:8000 をlistenすれば、php artisan serve の代わりはできるか？
Apacheを使用してLaravelアプリケーションを提供するには、`php artisan serve`の代わりに、Apacheの仮想ホスト設定を行う必要があります。以下にその手順を日本語で説明します。
### 1. 仮想ホスト設定ファイルの作成
Apacheの設定ファイルにLaravelアプリケーションの仮想ホストを設定します。
$ sudo nano /etc/apache2/sites-available/laravel-app.conf
このファイルに、以下のように設定を記述します（Laravelの`public`ディレクトリをドキュメントルートとして指定）：
\“`apache
\
\ ServerName 127.0.0.1
\ DocumentRoot “/path/to/your/laravel/public”
\
\
\ AllowOverride All
\ Require all granted
\
\
\ ErrorLog ${APACHE_LOG_DIR}/error.log
\ CustomLog ${APACHE_LOG_DIR}/access.log combined
\
`”/path/to/your/laravel/public”`の部分は、実際のLaravelプロジェクトの`public`ディレクトリのパスに置き換えます。
### 2. サイトの有効化とRewriteモジュールの有効化
ApacheでRewriteモジュールを有効にし、仮想ホスト設定を有効化します。以下のコマンドを実行してください。
$ sudo a2ensite laravel-app.conf
$ sudo a2enmod rewrite
### 3. Apacheの再起動
設定が完了したら、Apacheを再起動します。
$ sudo systemctl restart apache2
### 4. ファイルの権限を確認
ApacheがLaravelのファイルにアクセスできるように、`storage`と`bootstrap/cache`ディレクトリのパーミッションを調整する必要があります。
$ sudo chown -R www-data:www-data /path/to/your/laravel
$ sudo chmod -R 775 /path/to/your/laravel/storage /path/to/your/laravel/bootstrap/cache
### 5. `.env`ファイルの`APP_URL`を確認
`.env`ファイル内の`APP_URL`が正しいURL（`http://127.0.0.1`など）に設定されていることを確認します。
APP_URL=http://127.0.0.1
この手順でApacheを使用してLaravelアプリケーションを提供することができ、`php artisan serve`を使わなくても、Apache経由でアクセスが可能になります。

 

ライブUSB efi、でググった：
https://qiita.com/tchofu/items/6e6e0b243f45526b3a20

 

2025.05

セッション管理について、phpでは以下の様にするが、
<?php
session_start();
session_regenerate_id(true);
if(isset($_SESSION[‘login’]) == false){
print ‘ログインされていません。<br />’;
print ‘<a href=”../staff_login/staff_login.html”>ログイン画面へ</a>’;
exit();
}else{
print $_SESSION[‘staff_name’].’さんログイン中<br />’;
print ‘<br />’;
}
?>
Reactや生JSではどうするのか？ (->DeepSeek)

# セッション管理の比較: PHP vs React/生JavaScript

PHPのセッション管理と比較して、Reactや生JavaScriptでのセッション管理の方法を説明します。

## PHPのセッション管理の特徴
– サーバーサイドでセッションを管理
– `session_start()`でセッション開始
– `$_SESSION`スーパーグローバル変数を使用
– セッションIDはクッキーで自動管理

## React/生JavaScriptでのセッション管理方法

### 1. localStorage/sessionStorageを使用する方法
“`javascript
// ログイン時にデータを保存
localStorage.setItem(‘isLoggedIn’, ‘true’);
localStorage.setItem(‘staffName’, ‘山田太郎’);

// セッションチェック
if (!localStorage.getItem(‘isLoggedIn’)) {
// ログインしていない場合の処理
console.log(‘ログインされていません。’);
// ログインページへのリダイレクトなど
} else {
console.log(`${localStorage.getItem(‘staffName’)}さんログイン中`);
}

// ログアウト時
localStorage.removeItem(‘isLoggedIn’);
localStorage.removeItem(‘staffName’);
“`

### 2. Cookieを使用する方法
“`javascript
// Cookieの設定
document.cookie = “staffName=山田太郎; path=/; max-age=3600”; // 1時間有効
document.cookie = “isLoggedIn=true; path=/; max-age=3600″;

// Cookieの読み取り関数
function getCookie(name) {
const value = `; ${document.cookie}`;
const parts = value.split(`; ${name}=`);
if (parts.length === 2) return parts.pop().split(‘;’).shift();
}

// セッションチェック
if (!getCookie(‘isLoggedIn’)) {
console.log(‘ログインされていません。’);
} else {
console.log(`${getCookie(‘staffName’)}さんログイン中`);
}
“`

### 3. Reactでのコンテキスト/状態管理を使用
“`jsx
import React, { createContext, useState, useContext } from ‘react’;

const AuthContext = createContext();

export function AuthProvider({ children }) {
const [authData, setAuthData] = useState(() => {
// 初期状態をlocalStorageから読み込む
const isLoggedIn = localStorage.getItem(‘isLoggedIn’) === ‘true’;
const staffName = localStorage.getItem(‘staffName’) || ”;
return { isLoggedIn, staffName };
});

const login = (staffName) => {
localStorage.setItem(‘isLoggedIn’, ‘true’);
localStorage.setItem(‘staffName’, staffName);
setAuthData({ isLoggedIn: true, staffName });
};

const logout = () => {
localStorage.removeItem(‘isLoggedIn’);
localStorage.removeItem(‘staffName’);
setAuthData({ isLoggedIn: false, staffName: ” });
};

return (
<AuthContext.Provider value={{ …authData, login, logout }}>
{children}
</AuthContext.Provider>
);
}

export function useAuth() {
return useContext(AuthContext);
}

// 使用例 (コンポーネント内)
function StaffArea() {
const { isLoggedIn, staffName, logout } = useAuth();

if (!isLoggedIn) {
return (
<div>
ログインされていません。<br />
<a href=”/staff_login”>ログイン画面へ</a>
</div>
);
}

return (
<div>
{staffName}さんログイン中<br />
<button onClick={logout}>ログアウト</button>
{/* 他のコンテンツ */}
</div>
);
}
“`

### 4. JWT (JSON Web Tokens) を使用した認証
フロントエンドとバックエンドAPI間でよく使用される方法です。

“`javascript
// ログイン後にトークンを受け取った場合
localStorage.setItem(‘token’, ‘受信したJWTトークン’);

// APIリクエスト時にヘッダーに付加
fetch(‘/api/protected-route’, {
headers: {
‘Authorization’: `Bearer ${localStorage.getItem(‘token’)}`
}
})
.then(response => {
if (response.status === 401) {
// 認証エラー – ログインページへリダイレクト
window.location.href = ‘/login’;
}
return response.json();
});
“`

## セキュリティ上の注意点
1. 機密情報はクライアント側に保存しない
2. `HttpOnly`と`Secure`フラグ付きのクッキーを使用するのがベストプラクティス
3. CSRF対策を実施する
4. トークンには適切な有効期限を設定する
5. localStorageはXSS攻撃に対して脆弱なので注意

Reactアプリケーションでは、通常はコンテキストAPIやReduxなどの状態管理ライブラリと組み合わせて、上記のストレージメカニズムを使用します。また、ルーティングライブラリ（React Routerなど）と統合して、認証が必要なルートを保護します。

\

node.jsでセッション管理はできるか？

# Node.jsでのセッション管理

Node.jsでもPHPと同様にセッション管理を行うことが可能です。Node.jsでは主に以下の方法でセッションを管理します。

## 1. Expressセッションミドルウェアを使用する方法

`express-session`という公式ミドルウェアを使用するのが一般的です。

### 基本的な設定例

“`javascript
const express = require(‘express’);
const session = require(‘express-session’);

const app = express();

// セッション設定
app.use(session({
secret: ‘your-secret-key’, // セッションIDを暗号化するための秘密鍵
resave: false, // セッションが変更されていなくても再保存しない
saveUninitialized: false, // 未初期化のセッションを保存しない
cookie: {
secure: false, // HTTPSを使用する場合はtrueに
maxAge: 3600000 // 1時間の有効期限(ミリ秒)
}
}));

// ログイン処理の例
app.post(‘/login’, (req, res) => {
// 認証処理…
req.session.isLoggedIn = true;
req.session.staffName = ‘山田太郎’;
res.send(‘ログイン成功’);
});

// 認証チェックの例
app.get(‘/staff-area’, (req, res) => {
if (!req.session.isLoggedIn) {
return res.send(‘ログインされていません。<br /><a href=”/login”>ログイン画面へ</a>’);
}

res.send(`${req.session.staffName}さんログイン中<br />`);
});

// ログアウト処理
app.get(‘/logout’, (req, res) => {
req.session.destroy(err => {
if (err) {
return res.status(500).send(‘ログアウトエラー’);
}
res.redirect(‘/login’);
});
});

app.listen(3000, () => {
console.log(‘Server running on port 3000’);
});
“`

## 2. セッションストアの選択

デフォルトではメモリ上にセッションを保存しますが、本番環境では以下のようなストアを使用します。

### 2-1. Redisを使用する場合 (`connect-redis`)

“`javascript
const Redis = require(‘ioredis’);
const RedisStore = require(‘connect-redis’).default;
const redisClient = new Redis();

app.use(session({
store: new RedisStore({ client: redisClient }),
secret: ‘your-secret-key’,
resave: false,
saveUninitialized: false,
cookie: {
secure: false,
maxAge: 3600000
}
}));
“`

### 2-2. MongoDBを使用する場合 (`connect-mongo`)

“`javascript
const MongoStore = require(‘connect-mongo’);

app.use(session({
store: MongoStore.create({
mongoUrl: ‘mongodb://localhost:27017/session_db’
}),
secret: ‘your-secret-key’,
resave: false,
saveUninitialized: false,
cookie: {
secure: false,
maxAge: 3600000
}
}));
“`

## 3. JWT (JSON Web Tokens) を使用する方法

APIベースのアプリケーションではJWTを使用するのも一般的です。

“`javascript
const jwt = require(‘jsonwebtoken’);

// ログイン処理
app.post(‘/login’, (req, res) => {
// 認証処理…
const token = jwt.sign(
{ staffName: ‘山田太郎’, staffId: 123 },
‘your-secret-key’,
{ expiresIn: ‘1h’ }
);
res.json({ token });
});

// 認証ミドルウェア
function authenticateToken(req, res, next) {
const authHeader = req.headers[‘authorization’];
const token = authHeader && authHeader.split(‘ ‘)[1];

if (!token) return res.sendStatus(401);

jwt.verify(token, ‘your-secret-key’, (err, user) => {
if (err) return res.sendStatus(403);
req.user = user;
next();
});
}

// 保護されたルート
app.get(‘/protected’, authenticateToken, (req, res) => {
res.send(`${req.user.staffName}さんログイン中`);
});
“`

## PHPとの比較

1. **類似点**:
– サーバーサイドでセッションを管理
– セッションIDをクッキーで保持
– セッションデータをサーバー側で保存

2. **相違点**:
– PHPは組み込み機能、Node.jsはミドルウェアが必要
– Node.jsではセッションストアを柔軟に選択可能
– Node.jsではJWTを使用する選択肢も一般的

## セキュリティ上の注意点

1. `secret`キーは強力なものを使い、環境変数で管理
2. 本番環境では`cookie.secure`をtrueに（HTTPS必須）
3. 適切な`SameSite`属性を設定
4. セッションタイムアウトを適切に設定
5. CSRF対策を実施（`csurf`ミドルウェアなど）

Node.jsでもPHPと同様のセッション管理が可能ですが、より柔軟な設定が可能で、さまざまなデータストアと連携できるのが特徴です。

最近は、CUIの事をCLIと言うのか？ (2025.09)
CUI (Character User Interface)
DOS も UNIX も含めて「文字ベースで操作する UI 全般」を指す。
厳密には、CUI にはメニュー型のテキスト UI（たとえば ncurses を使ったアプリ）も含まれる。
CLI (Command Line Interface)
その中でも「コマンドを打つ」方式を特に指す。

GooglebotはIPアドレスを公開している。(2025.10)
このため、GoogleのクローラーをDNS逆引きやIPフィルタリングで回避できる。

 
雑多な記録リンク：
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/%bb%a8%c2%bf%a4%ca%b5%ad%cf%bf
https://seesaawiki.jp/lifewithslackarmzaurus_15_0/d/%bb%a8%c2%bf%a4%ca%b5%ad%cf%bf
https://seesaawiki.jp/lifewithslackarmzaurus_14_2/d/%bb%a8%c2%bf%a4%ca%b5%ad%cf%bf
https://seesaawiki.jp/lifewithslackarmzaurus14_1/d/%bb%a8%c2%bf%a4%ca%b5%ad%cf%bf
https://seesaawiki.jp/questzaurus/d/%bb%a8%b5%ad%cf%bf
https://seesaawiki.jp/lifewithslackarmzaurus/d/%bb%a8%b5%ad%cf%bf
https://seesaawiki.jp/lifewithslackzaurus/d/%bb%a8%b5%ad%cf%bf
https://seesaawiki.jp/lifewithopenzaurus/d/%bb%a8%b5%ad%cf%bf
https://seesaawiki.jp/cacko/d/%bb%a8%b5%ad%cf%bf