  |
はてなキーワード: ディレクトリとは
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
ノートPCなのに個人ユーザじゃなくて共通ユーザにしている会社はマジで滅びてくれ
「その人がいなくなってもログインできるようにしておきたい」
だったら共通ユーザを追加した上で普段は個人ユーザをちゃんと使え
今時MicrosoftだろうがAppleだろうが小規模から大規模にいたるまでユーザー管理の方法を提供してくれてて
そのユーザー管理に基づいていろんなソフトウェアが準備されてあるんだから
それをちゃんとおとなしく使ってくれ
まぁノートパソコンを事務員が使う場合は「知識がない」という理由で仕方がない部分はある
一番最悪なのはサーバー系でそれをやってるアホはマジで滅びてくれ
EC2やAzureでサーバー建てて、初期に作られるroot権限持ちのユーザーをそのまま使い続けてて
おまけに10人とかでその秘密鍵を共有してるアホは今すぐPCを返却して無人島で暮らしてくれ
もしくはちゃんとしたところでちゃんとしたサーバー運用を学んで来てくれ
ユーザー管理をしっかりしてないサーバーは運用から何からめちゃくちゃで手が付けられん
yumやaptでupgradeしようとするとエラーになって、そのエラーがなんなのか分からないのでずーっとアップグレードされてなかったり
コンフィグファイルがぐっちゃぐちゃで誰も何が起きてるのか把握できてなかったり
共通ユーザのホームディレクトリはもちろんめちゃくちゃで、/etcや/varに至ってもゴミファイルが大量に放置されてたり
最近、IT系の不祥事が多発してるけど多分この手のゴミ屋敷が時限爆弾みたいになって発火してるのが大半だと思う
これやってるやつはすぐにPC返却してくれ
インストールした7-zipをアンインスト&再インストールせずそのまま手動で移動させたことで、dllファイルが読み込みなくなっていた模様。
これは、
https://ameblo.jp/eruna-captor/entry-12384271374.html
これが使う、
が、新しい必要があることがわかりました。
と
axrar.spiをあきらめてax7z_s.spiを使おうとしてax7z_s.txtの解説
ax7z_s.spi 単独では動作しません。他に 7-zip 4.57 以降に含まれる 7z.dll が
※ 7-zip 4.62, 4.65, 9.20, 9.22 の 7z.dll でも動作しているようです。
・レジストリ HKCR\Software\7-zip\Path (文字列)に設定されたフォルダ
・レジストリ HKLM\Software\7-zip\Path (文字列)に設定されたフォルダ
rarを読み込まなくなったソフトのPluginフォルダにはax7z_s.spiのために7z.dllを設置していたのですが、axrar.spiとは一階層ずれていたのでこれも読めず、レジストリ先も見つからない、という状態だったかもしれませｎ。
axrarのreadme.txtには7z.dllに依存するなど動作条件が記載されているわけでもないので憶測ですが、おそらくそういうことでしょう。rarを扱える(7z.dllが使える)環境でaxrarを使うはずなので明記するまでもないということかもしれません。
https://w.atwiki.jp/comicview/
ax7z.spi for 7-zip 4.57+ s (s_y4b5 15/01/08) ※ZIP, RAR, LZH, 7z等。要7z.dll。Hamana非対応
ax7z.spi for 7-zip 4.57+ (y3b6 15/01/08) ※ZIP, RAR, LZH, 7z等。要7z.dll。
購入して10年以上。放置も多いが稼働時間7万越えのHDDがSMARTにおエラーをお出しになられた
不定期バックアップを取ったらファイルがひとつコピー失敗してて手動コピーしようとしたらOSからもBIOSからも認識しなくなってやばたん
何度か再起動したら警告つきで認識してくれてあわててamazonでHDD購入
初めて買ったHDDでseagateなんだよね。それ以降はWD買ってたんだけど、ここまで動いて突然死もしないなら安いseagateでいいかと直系子孫的にseagateにした
バックアップからエクスプローラーでコピーしてディレクトリ構造を同じにしてドライブ番号を入れ替えたら完了かね
今回死んだHDDにはプロファイルも入っててCは生きてるのにログインできなくなったんだよね
セーフモードにすれば新規にユーザー追加できたそうだけど、事前に念のため普段使うユーザーとは別に緊急用のadminユーザーをCにも作ってて助かった
だけど普段使わないそのユーザーの名前とパスは認識しないHDDに入ってるから記憶と勘でハッキングしなきゃいけなくてなんとか突破できてドキドキもんだった
あと一度死んだプロファイルはレジストリ弄らないと再ログインできないし面倒ね
当時はこしゃくにもパーティーションを分けててまああんまり利点を感じなかったから撤廃するつもり
テンポラリと保存先が別々で同一HDDなのにまたいで移動とかしてたしここらへんスッキリするといいね
2Tをちょくちょくやりくりしつつ古い未使用ファイルも沢山ありますね
ファイルはごっそり移行するけど余裕が1Tほどできるので気が楽になりますね
10年前とくらべてHDDの値段は容量低め(2T～)で同額から微増、そっから468Tと盛るための金額のがお安くなった感じでしょうか
SSDもこなれた今、もっと安く手に入るかと思ったので残念でした
増やすより安く欲しい…
その代わり同期の同じく稼動10年越え電源のファンがずっとキュルキュル言ってます
こいつもそのうち買い替えしなきゃなぁ
と言いつつ死ぬまで使うんだろうね
しかしそういえば、今日は「動かなくなっちまった」が 2 連続したんだなあ。
昼は Visual Studio Code の拡張機能「Markdown Preview Enhanced」の PlantUML 機能が動かなくなっていた事に気づいた。
どうやら plantuml.jar のパスを設定してやる必要があるらしい。
以前までは MPE をインストールしたままの状態で動いていたはずなのに。
まあ設定は簡単。MPE とは別に、同じく VSCode の PlantUML 単独の拡張機能も入れていたので
そいつが抱えている plantuml.jar を MPE でも使うように設定。こちらはすんなりと解決だ。
（いや、待てよ。拡張機能は自動でアップデートされていくもの。そして拡張機能のディレクトリ名にはバージョン番号を含んでいる。
つまり PlantUML 拡張機能のディレクトリ名、いつか気づかないうちに変わっちゃうんじゃないか？解決になってないなこれｗ）
nginx、PHP-FPM、Laravelという構成なのですが、failed (13: Permission denied)というエラーが表示されて動きません。どうしたらよいと思いますか。
「failed (13: Permission denied)」というエラーは、通常、Nginxがアクセスしようとしているファイルやディレクトリに対して必要なパーミッションがない場合に表示されます。このエラーを解決するためには、以下の手順を試してみることができます。
Nginxがアクセスしようとしているファイルやディレクトリのパーミッションを確認します。ファイルやディレクトリが適切なパーミッションであることを確認し、Nginxが読み取りや書き込みを行えるようにします。
Nginxがアクセスしようとしているファイルやディレクトリの所有者とグループを確認します。Nginxの実行ユーザー（通常はwww-dataやnginxなど）がファイルやディレクトリの所有者やグループと一致するか確認し、必要に応じて所有者やグループを変更します。
サーバーがSELinuxを実行している場合、SELinuxのセキュリティポリシーがNginxのアクセスを制限している可能性があります。SELinuxを無効化するか、適切なセキュリティポリシーを設定することで問題を解決できる場合があります。
Laravelプロジェクトなどの場合、アプリケーションの一部ファイルが壊れている可能性があります。再度アプリケーションをデプロイしたり、必要なファイルを再生成することで問題を解決できるかもしれません。
上記の手順を順番に試してみてください。また、エラーが特定のファイルやディレクトリに関連している場合、具体的なパーミッションや所有者情報を提供していただければ、より具体的なアドバイスをすることができます。
LOAD DATA INFILEでCSVを分割して読み込むことは可能なのでしょうか。そのときautoincrementのidがあった場合はどうしたらよろしいでしょうか。
はい、LOAD DATA INFILEステートメントを使用してCSVファイルを分割して読み込むことは可能です。CSVファイルを分割するには、LOAD DATA INFILEステートメントのファイル名の部分にワイルドカードを使用することができます。
以下は、例としてMySQLデータベースでのLOAD DATA INFILEステートメントの使用方法です。
LOAD DATA INFILE 'path/to/files/file*.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (col1, col2, col3); -- 列のリスト
上記の例では、path/to/files/ディレクトリ内のfile*.csvというパターンに一致するすべてのCSVファイルが読み込まれます。また、FIELDS TERMINATED BY句とLINES TERMINATED BY句を使用して、フィールドと行の区切り文字を指定しています。さらに、col1, col2, col3のように列のリストを指定することで、CSVファイルの対応する列とテーブルの列をマッピングします。
autoincrementのidがある場合、LOAD DATA INFILEステートメントでは自動的に次の値を生成することはできません。そのため、CSVファイル内に明示的にid列が存在する場合は、id列を指定して読み込む必要があります。id列がCSVファイルに存在しない場合は、テーブルの定義でid列をautoincrementに設定しておく必要があります。その場合、データベースが自動的に新しい値を生成します。
CREATE TABLE your_table ( id INT AUTO_INCREMENT PRIMARY KEY, col1 VARCHAR(50), col2 VARCHAR(50), col3 VARCHAR(50) );
この場合、LOAD DATA INFILEステートメントでid列を省略することで、自動的に新しい値が生成されます。
LOAD DATA INFILE 'path/to/files/file*.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (col1, col2, col3);
このようにして、CSVファイルのデータを分割して読み込むことができます。ただし、autoincrementのid列は明示的に指定するか、データベースによって自動的に生成されるようにテーブルを設定する必要があります。
SETしないと動かない。
分割するとauto incrementの値が飛ぶ。
スタックトレースを読んだらrbsのリポジトリに書かれている定義を読んでいることがわかったんだけど、このディレクトリにopen-uriがないのよね。
https://github.com/ruby/rbs/tree/master/stdlib
---
結論、以下のメソッド定義が公式で提供しているのかと思ったのだけど、用意されていない!!
```
[error] Type `singleton(::URI)` does not have method `open`
│ Diagnostic ID: Ruby::NoMethod
│
└ response = URI.open 'https://api.github.com/XXXX'
```
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
「猿でも分かるプロンプト活用術」というタイトルでの電子書籍について、以下に簡単な目次と章ごとの概要を示します。実際の書籍を作成するには、これらの各セクションを詳細に説明し、例や図を追加する必要があります。
目次:
1. はじめに
2. コマンドプロンプトとは何か
8. まとめ
9. はじめに
・グラフィカルユーザーインターフェイス(GUI)との違い
・コマンドプロンプトの開き方
・基本的なコマンドの使い方（例：help、cls、exit）
...
はじめに
コンピュータの世界は日々進化し続けており、我々が日常的に使用するデバイスやソフトウェアは常に更新され、より使いやすく、効率的になっています。しかしながら、コンピュータの基本的な操作や理解には、依然として古くから存在するコマンドプロンプトという強力なツールがあります。このツールは、多くのユーザーにとって未知の存在であり、その力を十分に発揮できていないかもしれません。
本書「猿でも分かるプロンプト活用術」は、コマンドプロンプトをこれまで使ったことがない方や、基本的な操作しか知らない方を対象に、この強力なツールを効果的に利用する方法をわかりやすく解説します。また、既にコマンドプロンプトを使用している中級者にも、さらなる活用方法を学んでいただける内容となっています。
コマンドプロンプトは、グラフィカルユーザーインターフェイス（GUI）に慣れ親しんだ現代のユーザーにとっては、最初は少し難しく感じるかもしれません。しかし、本書を通じて、コマンドプロンプトの基本操作から高度な活用法までを習得し、日々の業務やパソコン操作に役立てることができるようになります。
各章では、具体的なコマンドの例やスクリーンショットを用いて、わかりやすく説明を行います。また、章ごとに練習問題やチャレンジを設けていますので、学んだ知識をすぐに実践して確認することができます。
この本を通して、コマンドプロンプトの力を最大限に引き出し、あなたのコンピュータスキルを向上させることができることを願っています。それでは、さっそく「猿でも分かるプロンプト活用術」の世界に飛び込んでみましょう！
langってディレクトリに言語ごとのphpが入っててjaディレクトリには日本語の文言書かれたファイルはあるのになぁ。
手動でインストール(https://www.linuxyogi.com/rocky-linux/how-to-install-snipe-it-on-rockylinux-9/)
install.shでインストール(どこに書かれているんだ？git cloneした中にあるinstall.sh叩くと全部入れてくれる)
両方とも変わらず。
docker(https://qiita.com/radiance1104/items/258ef6b693eebf0f4a18)
当時はGoogleよりYahooのディレクトリ検索のほうが主流だった。
確か何かしらの機能が使えなかったので、生年月日をごまかして登録していた。
それから20年ずっとメインのメールアドレスとして使い続けてきた。
確かに過去の自分が悪かったけど、あれから20年立って今更ログイン認証だけじゃなくて生年月日が必要と出てきた。
そして、これは変更不可能。20年前にどう入力していたかなんて覚えているわけがない。
ヤフオクでも色々買っていたり、色んな思い出のメールも見れない。
もちろんこのメールアドレスを登録してるWebサービスも山程ある。
メールアドレスに確認コードを送るタイプのWebサイトだともうログインできなくなってしまったし、今使っているサブスクの解約すらも出来なくなってしまった。
最近、はてな内でインターネット老人会やおい腐女子部の方が過去を振り返っていたので、それに関連して無断リンク禁止からリンクフリーへ至った足跡を記憶を振り返りながら記そうと思う。
ただし、当該エントリのリアクションでも触れられている通り、まだまだ規模が小さかったとは言え個人視点で見れば広大なインターネットの全てを捕捉するのは難しく微妙に個人間で差異があるものと思われる。
違いがあれば私はこうだったと教えてもらえると更におもしろくなるかも知れない。
さて、若者の皆さんはインターネットのオンラインコミュニティではその当初「実名文化」であったことをご存知だろうか？
実名文化となった要因は様々あると考えられるけど、大きく影響を示した要因の1つは「JUNET」であると言われれば、まぁ納得はするのではないだろうか。少なくとも影響ゼロではないだろうなと。
JUNETは学術系ネットワークで、その主要コンテンツは今日における電子掲示板群と非常に似通ったものがあり、つまりは話題カテゴリごとに整理されたページが存在したのだ。
建前上、JUNETはごく真面目な学術系ネットワークだったので書き込みの責任は個々人にあり、書き込みへ責任持ってもらうため実名制が取られていたとされる。
電子掲示板群で「である」調の文体もJUNETで使われていた文体であり、由来は論文に使われていた文体なのだ。
まぁ実名であっても責任？なにそれ？みたいな感じで至るところへ噛み付いたり、唐突にまったく脈絡なく関係のない話をはじめ、それを指摘され叱られたら逆ギレして大暴れする抜き身のナイフみたいな方が居たんだが・・・そのことについては別の機会に。
えっソイツどうなったかって？今でもTwitterで元気に至るところへ噛み付いてレスバしてるけど？
私の年甲斐もなく落ち着かない性分はなかなかだと自覚してるが彼女には負ける。私はそろそろ落ち着かないとと思ってるがキミはそのままで良いと思うよ。
まぁそんなこんなで日本のインターネットはその当初実名文化であり、TCP/IPやWWWがデファクトスタンダードとなりWindows 95が社会現象になるほど売れた時代、ホームページ開設ブームなんてものがあった。
まぁブームと言っても現在に比べればまだまだ小規模のものではあったが、個人が自宅からウェブへアクセスし、何ならウェブサイトを公開するというのは中々に特別感があったのだ。
そのホームページ開設ブーム期のホームページは実名文化の影響下にあり、住所から氏名、電話番号、家族構成、勤め先などなどを載せているホームページが数多く存在した。現代の個人情報保護の感覚からすると実におおらかと言える。
言ってみれば、その当時のホームページは後の時代に登場する「前略プロフィール」みたいなものだったのである。
書いてある内容も個人の日記帳、しかも実像へかなり近い個人の日記帳のようなものであった。実名で交友関係がわかったし、ホームページの管理者が学生であれば甘酸っぱい恋の悩みとかを隠すこともなく実名で書いていた。
この当時のホームページはあまりにもリアルすぎる個人情報の塊であり「ホームページの管理者が広く公開していないURLを無断で他所に転載することはネチケットに反していた」という古の文言を現代で記すこととなる。
現代の感覚からしてみると「広く公開していないURLって何なんだよ」と言いたくなるし、情報技術者から見れば「ローカルにDNSサーバでも立てたのかな？プライベートIPアドレスならば個人利用だと事実上無限みたいなもんだ」と広く公開していないプライベートなURLの可能性を探り始めるが、当時の人の感覚からするとインターネットなんてドマイナーなのでインターネットを使ってる時点で隠しているつもりだったのだ。
実にバカバカしいと現代人は感じるかも知れないが当時の大半のインターネットユーザは至って真面目に本気でそう考えていた。
例えば過去の時代、NTTはハローページという個人の電話番号を膨大に載せていた冊子を発行していた。
この個人情報は公開情報であるが、電話番号所有者に無断で何ら関係しない他所へ公開した場合、倫理的に問題ないか？と言われれば現代人でも問題と感じるはずだ。現代では特殊詐欺とかあるしね。
じゃあ何でNTTはそんなもん発行していたのか？と言えば、当時の電話番号を取得するには加入権というものが必要であり、加入権は金融商品としての側面を持っていたことから、ハローページへ記載されているということはNTTがその個人の信用をある意味で担保しているという判定が得られることがあったのだ。
まぁつまり電話番号すら持ってないヤツは信用ならんから取引しないという考え方がマジで存在したんだ。
現代の、それこそ若者の感覚からするとNVNOで気軽に電話番号を入手できてしまう今では考えられない価値観だ。
ちなみに加入権の反動からか約20年前に契約書すら必要のないプリペイド携帯電話で詐欺が横行するっていう失敗があったので約20年前が最も電話番号の価値は低かった。
まぁそんなこんなで、URLは公開情報であっても勝手に使うのはダメなんだ、URL無断転載禁止なんだ、無断リンク禁止なんだという価値観の時代は存在したが、それが急速に失われて「リンクフリー」が台頭する時代が来る。
リンクフリーが何故一気に広まったのか？と言えば「Yahoo!」が日本国内で営業開始したからであった。
当時のYahoo!はディレクトリ型と呼ばれるウェブ検索エンジン方式で、これはハローページなどと同様に人力でURL情報を収集して掲載するという形のウェブ検索エンジンだった。
掲載されるには審査が必要で、Yahoo!に掲載されるということはウェブサイトへ一定の価値と信用を与えてくれるものだった。まるで本当にハローページみたいだ。
この価値が失われるのは「Google」がロボット型と呼ばれるウェブ検索エンジンを開発したからであったが、リンクフリーはGoogleが登場する前から使われ始めている。
リンクフリーはYahoo!が登場したからだけでは実は説明しきれず、Yahoo!が人気サイトをランキング形式で掲載するようになったからというのが実際の答えである。
人気ランキングが存在するようになると競争が生まれる、当時のウェブサイトにおいてはアクセス数(≠ユニークユーザ数)こそが人気の指標であり、URL無断転載禁止・無断リンク禁止のスローガンはこの人気争いの中で邪魔になっていった。
そして同時にインターネット芸人みたいな人たちも続々と登場するようになり、個人の赤裸々な情報が詰まった日記帳のようなホームページは段々と廃れていき、匿名のインターネット芸人が笑い話やお涙話で人気を集めるようになった。
そうつまり「テキストサイトブーム」の到来である。
テキストサイトの思い出についてはこのエントリを読むインターネットユニークユーザ諸氏の方が詳しいしバラエイティに富んでいると思われるので任せた。
ディレクトリ型ウェブ検索Yahoo!の登場は別にテキストサイトだけへ影響を及ぼしたわけでなく、２ちゃんねるの元になった電子掲示板群「あめぞう」の前身である「あめぞうリンク」は「リンクサイト」と呼ばれる種別のウェブサイトであった。
そのほか後年にはリンクサイトの発展型である「ランキングサイト」も登場しており、ここまで来るともはや牧歌的なインターネットなど想像も付かないような喧騒が起きるようになり、更に現代では当時を喧騒と表現しても良いのか迷う程度に現代インターネットは闘争本能が強すぎる人たちが多く生息している。
アーマードコアの新作発表されたしそっちでやれよ。
URL無断転載禁止・無断リンク禁止派の最後の抵抗はやはりGoogleによるクローリングだろう。
前述したロボット型と呼ばれるウェブ検索エンジンはウェブページからウェブページへのページリンクを自動的に収集するというもので、人力で登録していたYahoo!よりも収集効率が物凄く高かった。
しかし自動で収集するからこそウェブサイト管理者からすると謎のアクセスが急激に増え、何なら当時「Google」という単語など知る由もなかったので特にリンクを多く持っていたウェブサイト管理者からするとDDoSアタックか？と疑念を抱かせる程度には迷惑千万だった。
もちろん静かに仲間内だけで楽しんでいるようなウェブサイト管理者としても急にアクセスが増えることは不快感でしかなく、Googleの人気が増えていくに連れてリンクされない権利を求めるユーザもまた増えていったのだ。
この件であまりにも叩かれすぎたGoogleはウェブ検索エンジンの検索結果に記載されない「noindex」という施策を取ることとなり現代でも運用されている。
ただしこのnoindex、性善説で運用されておりウェブクローリングする側がnoindexを無視すりゃ普通にクローリングできるので完璧な解決手段ではない。
まぁこんな感じでテキストサイトあたりから日本のインターネットは匿名文化へ傾倒するようになりリンクフリーが一般的になっていったのだ。何ならリンクフリーって言葉すら見なくなる程度にはリンクフリーが当たり前の価値観であるインターネットになった。
そう言えば、はてなブックマークでも無断リンク禁止、勝手にウェブブックマークするなという意見が取り沙汰されたこともあったが、その辺の思い出話はブクマカのほうがよく記憶しているだろうし任せた。
結構多くのWEBサーバのアクセス制限で.co.jp .ne.jp .jpがdeny設定されていたって話である。
https://b.hatena.ne.jp/entry/s/twitter.com/kanose/status/1601270223386324992
個人のネット利用で大きな転換点は2005年くらいで、例えばブログのはしりのはてなダイアリーサービス開始は2003年でアルファブロガー選考開始は2004年、youtubeサービスインが2005年だが、これらの特徴は「アカウントをとって企業のWEBサービスを利用する」という、今では当たり前の方法だ。
だがこの以前にはそういう方式のものは少なく、ISPや借りたレンタルサーバに自分でコンテンツをアップロードして構築するというのが主流だった。
これは内部的にはLINUXサーバ制限アカウントを貰ってユーザーディレクトリの/WWWにファイルを置くという事やね。
だから最初のうちは個人サイトのURLは「ｈttp://www.yourisp.co.jp/~aybabtu」って感じだった。~はUNIXのユーザーホームディレクトリを示すのね。やがてバーチャルドメインに対応するサーバ会社が増えてｈttp://www.aybabtu.rentarusabaa.comみたいな今では当たり前のURLになったんだが、最初はバーチャルドメイン設定は有料だった。
MS Officeには「パブリッシュ」ボタンがあってそれを押すと編集してるファイル群の構造のまま指定したサーバにFTPでファイル送るみたいな機能もあった。（だがこれはShift-JISでUpするというクソ仕様で後に読めなくなるのだった）
httpの頭のHTはハイパーテキストで、参照箇所にはリンクが設定できて参照元にジャンプ（これも死語だ）できる電子文書なわけで、まさに公開はパブシュッシュ＝出版なわけだ。今もサブスクリプション＝新聞雑誌の定期購読というのはこの建付けが残ってるからだ。
ISPやWEBレンサバにはユーザー権限の多寡で違いがあって、ユーザに実行権限も付与してperlなどのインタープリタを構築しておくと、テキストであってもファイル先頭にインタープリタへのパスを書いておくとそれが実行され、標準出力をhttpで返す。これがCGIで、ISP供与で多いHTMLファイルの公開だけの権限制限されたサーバに不満な層は「CGI実行可」のレンサバ屋に移っていった。
但しプログラムであるから、いい加減に書いてループ参照とか起こすとサーバのCPUやメモリを喰いつくしてサーバダウンを惹き起こす。だからISP供与のでは実行権限を与えなかったわけだ。逆に言えばISPが必ずホームページ公開スぺースを供与するのに個人向けレンサバが成り立ったのは何故？と言えばCGIの実行が出来たからだ。
故にWindowsしか使わない人には難しい上級者向けだったのだが、これを優しいチュートリアルで簡単設定出来るようにしてユーザーを増やして会社を大きくしたのがpaperboy＆co.の家入一真氏なわけだ。はてな創業者の近藤淳也氏と並ぶ個性的なアントレプレナーと謂われた。その後堀江などと共にインターネッ党を作って都知事選に出て箸にも棒にもな結果になったのは黒歴史なので触れないで上げてください。特に堀江は野菜でいじられるよりも傷つくので偉そうに政治の話してる時に「インターネッ党」とボソっというのは残酷な事なので止めてあげて欲しい。お願いします。
また、CGIでの使用言語はperlが圧倒的で、perlで書いた掲示板スクリプトを配布するサイト、趣味プログラマが星の数ほどいた。
こういう訳で初期のWEBで動的ページ＝perlであってJcode.pmを開発した小飼弾氏は魔術師扱いされて崇拝されており、ブログブームが来ると圧倒的な人気を誇った。
今では多言語が普通に扱えるのが当たり前だが、マルチバイト文字の扱いというのは難しく、文字コードがそれぞれ違うのがそれに輪をかけていた。例えば今でも日本語Windows上でフランス語や中国語のファイル名は作れないだろう。また、最初期からかなりの期間、Twitterでは日本語の検索が出来なかった。youtubeでも日本語で投稿できなかった期間は長い。
子飼氏はperlで日本語を使用できるようにするライブラリをUNICODE対応にしてWEBで普遍的に日本語が使えるようにしたものだ。
ただ、HTLMと実行文を混ぜ書きできるPHPがver.4になるとデータベース連携が強化されていてデフォルトでSQL文発行関数が実装されており、perlCGIは廃れていってしまう。
またISPより高い自由度を求めて自宅にサーバを立ててそれを公開するという者も現れた。
はてなはサーバをデータセンターに置いてはいたものの、筐体は町工場に設計図を持ち込んでステンレスの1U筐体を自前で作っていたし、Pixivはギガバイトのシステムボードを使って自作した多数のサーバをエレクター上に置いてむき出し運用してしていたので、自宅サーバ組の延長にあったのだな、実は。
こういう中で画像を公開する、動画を公開するというのはなかなか大変だった。
仲間内で見るという分にはファイルを置けばいいだけだが、問題になったのが「2ch晒し」であった。これは悪意を持って2chにURLを貼るのだけじゃなくて、単にURLを書くというのも含まれた。
というのも2chにURLが書かれるとアクセスが集中して大抵はサーバダウンしてしまう。すると他の契約者のサイトもページも見れなくなってしまう。
例えばヒーロー戦記主題歌みたいな社歌でbuzzった日本ブレイク工業のサイトは重すぎて何週間も閲覧出来なくなった。社歌の動画ファイルを置いていたためだ。
こういうサーバダウンは契約者の責任ではないがホスティング会社も許してはくれない。契約解除、つまり出ていけか、法人契約への変更かを迫られる。転送量制限なしと言っていても実際に転送過多になると干すティングになるわけだ。
だから2chは悪意の塊の他にサーバーダウンとサーバからの追い出しを惹き起こすので蛇蝎のように嫌われていた。2ch晒し→その時点でサイトを閉じてしまう人も多く居た。
するとこれを逆手に取ってアップローダ（あぷろだ）を自作サーバで運用してアフィリエイトで収入を上げる者が現れてくる。
ただこれは著作権違反のファイルが上げられて訴えられる事もあるからそのリスク低減のためと転送量制限の為にファイル容量に制限が設けられていた。
すると大きなファイルを共有したい連中はこれでは満足できない。
そこで目を付けたのが海外でアップローダを運用しているサーバだ。運用動機は日本のアップローダと変わらない。だがファイルの大きさの制限が緩かった。
そこでそういう海外のアップローダが違法性が高いファイルの共有に使われるようになった。やってたのは2chのダウンロード板と半角板がメインだ。
だがこれは運営には迷惑な話で、日本人は英語の広告なんてクリックしない。しかも商品の販路が無いので日本からのアクセスに報酬は支払われない。つまり金を落とさず転送量だけ上がるのだ。しかも海外では転送量従量課金は多かった。
更に問題なのがロリ画像がアップロードされることだ。2次元ロリでも規制があるのに実写ロリは完全アウトだ。実写ロリが発覚した場合、サーバ管理者は必ず逮捕される。マグショットが新聞に掲載されTVで晒され、釈放後も幼児が被害者の性犯罪者なのでGPSロガ装着が義務付けられ住所は共有される。二度と部屋を借りる事は出来ずに一生トレーラーハウスかキャンピングカーを買って橋の下で生活となる。
こんな実写ロリ画像や動画をアップロードする奴が居たのである。
そこで管理者としては日本からのアクセスが増えたのを確認した時点で遮断するしかない。一生を棒に振る可能性を回避するためだ。
圧倒的によく使われるWEBサーバのapacheでは.htaccessというシステムファイルに記述してアクセス制限を掛ける事が出来る。ここで国別IPアドレス指定するのはちょっと難しいのでdeny from co.jp deny from ne.jpという風に書くとドメインがco.jp、ne.jpからのアクセスを全部弾くことができる。
この時にディレクトリ指定を「/」にするとそのサーバの全てが弾かれて403エラーが出てしまう。しかもバーチャルドメインも同じなので思わぬところで403エラーが出る事もある。
そういう訳であちこちの海外サーバで日本からのアクセスが拒否されていた。全て2chダウンロード板と半角板のやつらのせいである。
自分はアメリカの田舎の新聞社のトップページで403を食らったことがあるから嫌われ方は相当なものだと思う。「やるべき.htaccessの基本設定」みたいなのに書かれて共有されたのかも知れない。
因みにダウンロード板と半角板は2ch名物の厨房板だったのに、今見たら無くなってるのな。諸行無常だ。
2005年にサービスインしたYoutubeだが、翌年にGoogleに買収されたもので最初は元paypal社員らが作ったベンチャーだった。
だが最初は著作権違反コンテンツばかりであって、自作ビデオというのは少なかった。
特に酷かったのがまた日本人で、最初は10分制限がなかったのをいいことにアニメの全話丸上げみたいなのが大量にされており、当事者のアニオタ達も「ここまでやったら閉鎖されるだろ！」と諫めるほどだった。
そんな中で2006年6月にYoutubeが数日間の大メンテナンスに突入し、画面には「All your video are belong to us」というブロークン英語が書かれていて騒ぎになった事があった。
これの元ネタは「All your base are belong to us」で、古いセガのゲームの英語版で出てきたセリフだ。深刻な場面で突然めちゃくちゃな英語をいう。このおかしさでFLASHが作られたりとミーム化していたものだ。
しかも日本産ゲームは結構あちこちでバカ英語を作ってて、engrishとかjanglishとか言われてネタにされていた。日本で言えばアヤシイ中国製品の日本語を愛でるような感じだ。
そこでYoutubeがあんなメッセージを出したので、日本のネット民は身に覚えがありすぎて「アニオタのせいだろ！また排除されるだろ」と責任のなすり合いと相なったのだった。
因みにその後も日本人の利用が制限とかは無かったので誤解だったのだが、海外アップローダ見つけては403の焼き畑とかロリ画像問題とかがあって、その後のアニメフル全話という流れだったので過剰反応をしたのであった。
-
...
正解は下のURLのページに当該のツイートが複製されるでした～～
-
...
正解は下のURLのページに当該のツイートが複製されるでした～～
みんなはわかったかな？
-
そう、今日現在のTwitterの機能上、RTといいねは他人のツイートを複製拡散するという部分でほぼ同じ挙動をするんだ！
ディレクトリがトップページだろうが1個下の階層だろうが法的には区別されないぞ！
保管目的ならブックマーク機能を使えば良いのでお気に入りが云々は的外れもいいとこなのだ
引用も公式に引用RTという機能が追加されたので、これをあえて使わない事情は斟酌されにくいのだ
