  |
はてなキーワード:Clientとは
https://www.youtube.com/watch?v=ifc96SDVBkw&ab_channel=BIPRecords
https://www.youtube.com/watch?v=f-041H7YRns&ab_channel=LuluNoo
https://www.youtube.com/watch?v=DbIPhE5W91I&ab_channel=ClevverNews
ここから探すのが一番。
https://www.youtube.com/watch?v=EDwb9jOVRtU&ab_channel=Madonna
https://www.youtube.com/watch?v=IxGvm6btP1A&ab_channel=KanyeWestVEVO
青ビキニでのワークアウト
エアロバイク。お尻。
なんだかんだbadunkadunkやcallon meやSound OfLegend – Maniac
が好き。
それと、PVにつられて最近の音楽を聴いたけれども、やっぱりリズムよりもメロディを重視していた時代の作品の方が性に合っている。
はい、**ブロックチェーンを使ったタイムスタンプ**は、「元データそのものを共有せずに、その存在と時刻を証明する手段」として非常に有効です。特に、ハッシュ値をブロックチェーンに記録することで、元データを後から提示するだけで、それがある時刻に存在したこと・改竄されていないことを**誰でも検証可能にする**、という形になります。
あなたの希望（元の文章が掲示板などで変形されても検証可能、あるいは元文不要）に近づけるには、**ハッシュをブロックチェーンに書き込んで、後からそのハッシュに一致する元データを見せる**という形式になります。
---
### 基本の流れ：
2. そのハッシュをブロックチェーンに記録（トランザクションのメモ欄など）
3. 後から誰でもハッシュとトランザクションを照合して、時刻と整合性を検証可能
---
## ✅ 推奨ツール：OpenTimestamps（OTS）
[OpenTimestamps](https://opentimestamps.org/) は、ビットコインのブロックチェーンを用いた無料のタイムスタンプサービスです。
---
## ✅Windows11 での手順（OpenTimestampsCLI）
Pythonがまだ入っていない場合は、https://www.python.org/downloads/windows/](https://www.python.org/downloads/windows/)からインストーラーを取得し、`Add toPATH` にチェックを入れてインストールしてください。
コマンドプロンプトまたはPowerShellで以下を実行：
```bash
pip install opentimestamps-client
```
たとえば `message.txt` というファイルを用意します（中身は何でもOK）。
```bash
```
これにより、`message.txt.ots` というタイムスタンプファイルが作成されます。
これは「Bitcoinにこのデータのハッシュを記録する要求がされたこと」を表します。
```bash
```
署名がBitcoinブロックチェーンに記録されていれば、次のように表示されます：
```
Success!Bitcoin attests data existedas of 2025-06-0812:34:56UTC
```
---
```bash
echo -n "あなたの文" |openssl dgst -sha256
```
このハッシュに一致するファイルを後から提示すれば、それが当時存在していたことを証明できます。
---
## ✅ まとめ
| 特徴 | 内容 |
| ------------- | -------------------- |
| 元文の提示は不要 | ✅（ハッシュが一致すればOK） |
| 改行や掲示板変形の影響なし | ✅（ハッシュが変わらなければOK） |
| 無料かつ自律的 | ✅（Bitcoinブロックチェーン使用） |
| Windows対応 | ✅（Python +CLI） |
---
もしあなたの目的が「一定時刻に自分がその文を作成したことの証明」であるなら、この方法は非常に相性が良いです。
---
必要であれば、GUIツールやウェブインターフェースを使った方法（例：[OpenTimestamps Calendar](https://calendar.opentimestamps.org/)）も紹介できます。希望があればお知らせください。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA51220250610095304512 -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEgAgAAKCRBwMdsubs4+SII/AP9HFG5+U8BfEXzKxSoyEuxm6X/vJjK7Ee7Kwpi/rwQZJgEAorUjMTh9okHu3WbPvgsSfDyzhpUuwCVsKessR4FSpQE==VNrS-----ENDPGP SIGNATURE-----
それによって読み込まれるらしいファイル:https[:]//wpscriptbox[.]com/vGTVRK?return=js.client&&se_referrer=.......
ttps://www.yosegi-g.com/
＝＝＝＝＝
pluginlibery.com/queryjs
株式会社NSS（改ざん失敗）←日本時間土曜朝追記：いや、トップページが改ざんされて危険なようだ
若干書き直しました
https[:]//pluginlibery.com/min-jquery が
https[:]//wpscriptbox.com/vGTVRK?return=js.client&&se_referrer=https%3A%2F%2Fwww.google.com%2F&default_keyword=%E4%BC%9D%E7%B5%B1%E5%B7%A5%E8%8A%B8%E5%93%81%E3%83%BB%E7%AE%B1%E6%A0%B9%E5%AF%84%E6%9C%A8%E7%B4%B0%E5%B7%A5%20%E9%9C%B2%E6%9C%A8%E6%9C%A8%E5%B7%A5%E6%89%80&landing_url=www.yosegi-g.com%2F&name=_y63Y5hh5t5n1Xkp8&host=https%3A%2F%2Fwpscriptbox.com%2FvGTVRK
を読み込んでいる？
Speed,SEO, scalability, and developer productivity aremore critical than ever. While React.js remains a powerhouse forbuilding interactiveuser interfaces, many businesses and developers arenow leaning towardNext.js for complete, production-ready solutions.So what exactly makesNext.js amore favorable choiceover React.js in 2025?Let’s explorethe reasons in detail.
🧱 React.js vsNext.js:Core Distinction
React.jsis aJavaScript library focused solelyonbuildingUI components.
Next.jsis a full-fledgedframework builtontop of React that includeseverythingyouneed for production — routing,SSR,SEO optimization, static site generation, andmore.
In essence, React givesyou the tools to build aninterface, whileNext.js givesyou thestructure to build, deploy, andscale a completewebapplication.
🚀Key Advantages of ChoosingNext.js in 2025
1. Built-in Server-Side Rendering (SSR)
3. Hybrid Rendering Capabilities
5.Image & Font Optimization
This alignsperfectly withGoogle’sperformance guidelines in 2025. React.js doesn’t offer this natively.
7. Enhanced Developer Experience
Next.jshas evolved intoone ofthe most developer-friendlyframeworks in 2025, backedby the Vercelecosystem.In 2025,Next.js standsoutas the smarter, faster, andmore scalable solution forbuilding modernwebsites andwebapplications.It inheritseverything great about React —and addsstructure, optimization, and production-readiness. Ifyou’re planning to build awebsite that demands speed,SEO,and a seamless development process,Next.jsis the clear choice.
Formore details read this informative article:https://www.nimblechapps.com/blog/choosing-nextjs-over-reactjs-for-website-development
神クラス（GodObject）は、ソフトウェア設計においてアンチパターン（避けるべき設計手法）として知られています。
これは、過剰に多くの責任を持ちすぎるクラスやオブジェクトのことであり、ソフトウェアの保守性や拡張性、可読性に大きな問題を引き起こします。
以下では、「いかに大変か」「なぜ大変か」「どのように大変か」を徹底的に具体的に解説します。
public class ApplicationManager { privateMap<String,User>users; private DatabaseConnectiondb; privateLoggerlogger; privateGUIgui; private NetworkClientclient; publicvoid startApplication() { connectToDatabase(); loadUsers();gui.showLoginScreen(); } publicvoid processUserInput(String input) {logger.log("Input received: " + input); if (input.equals("logout")) {gui.showLoginScreen(); } else {client.send(input); } } // ...more than 5000 lines of code}
「フロントエンド不要論」は、最近の開発現場やサーバーレス、クラウド技術の進化に関わっている人たちの間でリアルに実感されている問題です。
• React,Vue, Angular などのフレームワークがどんどん複雑化
•フロントエンドとバックエンドの分離が、**「本当に効率的か？」**という疑問が生じている
• 「最終的にHTMLを描画するだけなら、サーバーでやればよくない？」
•フロントエンドから直接APIを叩く構成では、「APIを守る」ことが難しい
•XSS,CSRF, CORSといった脆弱性に対処し続けるコストが無駄
🚩 3.サーバーレス・クラウド技術が進化し、APIの負担を減らす方向に
•AWSLambda,APIGateway, Cognitoなどのサーバーレス技術が進化
•フロントエンドがAPIを叩くより、サーバー側で直接処理する方が効率的
• 以前はReactを使用 → ReactをやめてHTMLベースに戻した
• React,Vue, Angularを全廃
•JavaScriptなしで動的なページを実現
3. Laravel（Livewire）
4. Shopify（GraphQLでデータを直接取得）
•フロントエンドを完全分離する構成から、「バックエンドがHTMLを返せばいい」 というシンプルな構成へ移行
✅サーバーレス時代の最適解：「フロントエンド不要アーキテクチャ」
「フロントエンドを捨てて、サーバーがすべての処理を担う」方向に移行するのが最適解になりつつある。
📌 最適なアーキテクチャ
ブラウザ →サーバー（PHP,Node.js,Go） →APIGateway（Cognito認証）
📌 具体的な実装例（PHP + Cognito +APIGateway）
require 'vendor/autoload.php';
useAws\CognitoIdentityProvider\CognitoIdentityProviderClient;
useAws\Exception\AwsException;
$client = new CognitoIdentityProviderClient([
'credentials' => [
'key' => getenv('AWS_ACCESS_KEY_ID'),
'secret' => getenv('AWS_SECRET_ACCESS_KEY'),
],
]);
$email = $_POST['email'];
$password = $_POST['password'];
try {
$result = $client->initiateAuth([
'AuthFlow' => 'USER_PASSWORD_AUTH',
'ClientId' => 'XXXXXXXXXX',
'USERNAME' => $email,
],
]);
setcookie("accessToken", $result['AuthenticationResult']['AccessToken'], [
'samesite' => 'Strict'
]);
header("Location:dashboard.php");
}
?>
🚀 **「フロントエンドはもう不要」**という流れは、最新のクラウド/サーバーレス開発に携わる人たちが実感していること。
☑セキュリティが大幅に向上する
👉結論：「フロントエンドは不要」クラウド×サーバーレスでバックエンドが主役になる！
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらくTCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前にHTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えばanond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見えるclientIP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
別の人からもあったそうです
