  |
はてなキーワード: コンソールとは
エヴァQシンにて登場するヴンダー及びNHGシリーズ二番艦～四番艦は「誰と」シンクロしているのか？ というふとした疑問。
一見LCLも存在しないようにも見えますが、どうやら戦闘時にはガス化したLCLガスが艦橋に注入されているようです。
冬月博士もシンで乗っていた二番艦エアレーゼ(エアレーズュング)で最終的にLCL化していましたが、同じ仕様なのかしら。
しかし重要なのはむしろ二番艦以降が「無人でも動く設計」というところかもしれません。
まぁ破時点からダミープラグはずっと存在しているわけで、エヴァにしろNHGにしろ無人仕様はわりと当たり前ではあります。
二番艦～四番艦は誰ともシンクロしていない。冬月博士は好きで乗って指揮してただけ。ここまではOK。
ヴンダーでは主機(メインエンジン)としてエヴァ初号機を、補機としてS2機関を採用しています。
明らかにシンジを含め誰もパイロットは搭乗していないので、初号機用のダミープラグも持っていたのでしょうか。
とはいえ、アンチLシステムや操演に比べれば破の時代からある古い技術なのであって当然かもしれません。
そうなってくると逆にLCLガスなんて艦橋に注入する必要はあるんだろうか？ とも思えます。
そもそも艦橋のメンバーは明らかに直接操船しています。しかし完全手動であり、あれだけ壊されたヴンダーのダメージのフィードバックもないのでシンクロはしていない。
ふーむ？
ダミープラグシステムを応用して、外部から非シンクロ者が操縦するシステムを確立させたのはほぼ間違いないように感じます。これは冬月もヴンダー乗員も同様。
あと残る謎はＬＣＬガスだけです。シンクロ技術を使って、脳波だけで操ったりしてたのかな？ 冬月博士はなんもコンソールとか出してなかったのでそれっぽい。
DMM版ウマ娘プリティーダービーを遊ぼうとしても、エラーダイアログを出さずに起動しなくなる現象に遭遇した。
Windowsのイベントビューアーを除くと、こんなログが吐かれていた（各IDは削除）。
=====
日付:
ユーザー:
説明:
障害が発生しているアプリケーション名: umamusume.exe、バージョン: 2020.3.24.51085、タイム スタンプ: 0x
障害が発生しているモジュール名: apphelp.dll、バージョン: 10.0.22621.963、タイム スタンプ: 0x
障害が発生しているアプリケーション パス: D:\DMMGames\Umamusume\umamusume.exe
障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\apphelp.dll
結論から言うと、Windows本体のapphelp.dllが原因でウマ娘が起動できなくなっているという。
アプリケーションに罪は無いため、DMM Game Playerやウマ娘を何度再インストールしても直らない厄介な現象だ。
Windowsは数十万のファイルが存在するため、今回のようにWindows Updateやアプリケーションのインストール・アンインストールを繰り返すだけでシステムファイルが壊れる事がある。
Windowsでは、これを直すためのコマンドがコンソールUIのみに用意されている。
Windowsのスタートメニューを右クリックして、コマンドプロンプトまたはターミナルを管理者権限で起動する。
を実行する。これは、オンライン上にある正しいWindowsのシステムイメージを元に、壊れたファイルを修復する操作となる。
実行するとこう表示される。
[==========================100.0%==========================] 復元操作は正常に完了しました。
DISM.exeを実行すると、正しいWindowsのシステムイメージがPC内に保存された状態になる。
この状態で、
sfc /scannow
を実行すると、次のように表示される。
システム スキャンを開始しています。これにはしばらく時間がかかります。
Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました。
オンライン修復の場合、詳細は次の場所にある CBS ログ ファイルに含まれています
windir\ Logs\CBS\CBS.log (たとえば C:\Windows\Logs\CBS\CBS.log)。オフライン修復の場合、
これで、とりあえずWindows自体の修復コマンドによってシステムファイルが正しい状態に復元された状態となる。
実行してもまだメモリ上には古いシステムファイルが読み込まれて実行されている状態なので、終わったらPCを再起動する。
さて、準備は完了だ。ここまでの操作でWindowsを回復しDMM Game Playerで「ダウンロード版をプレイ」を押す事でウマ娘が起動し…ない！
イベントビューアーには今もウマ娘を起動しようとする度にアプリケーションクラッシュイベントが追加されている。救いは無いのですか？
結局、今回のケースではPCで常駐していたリモートデスクトップ用のSplashtop StreamerとVirtual Desktop Streamerをタスクキルする事でウマ娘が起動できるようになり、DMMブラックフライデーで得た有償石でおはガチャを回すことに23時成功した。
仏人；ワールドカップでフランスが決勝戦で負けたときのマクロンのシネマ、
https://www.youtube.com/watch?v=6Vof5tbYhcE
チームの乗ったバスがやってきて4時間やってお祭り騒ぎ、みんな喜んでみんな浮かれたんだ。
で、
そんときもパレードやったんだけどどれくらいの時間やったかわかるか？
20分だよ。
エリゼの中でワイワイてめえだけで盛り上がりたかったんだ、
voom！
弾丸のように去ってってそれっきりさ。
もちろん外せないのはあるけど、パテだな、ソーモンやカナールとか、
あとは牡蠣か、それ以外はまあチーズとかなんとか、家族めいめいってとこじゃね？
とにかくフランスではノエルから年末にかけて食って食って食って騒いで、
なので1月ってのはガストロよ、気持ち悪いし寒いしでみんな体調悪くなるよ。
益田；そうだね、日本は正月におせちを初めとして祝いじゃ祝いじゃ、
食って食って食って、ってなって、
仏人；その制度は非常にいいな。
ただまあフランスではだんだんノエルがmoins sacré(神聖ではない)になってきたがな。
それもこれもみんなヴォク（woke）のクソッタレのせいだ。
ジョワイユノエル（メリクリ）が言えないノエルに何の価値がある。
ヴォクの糞どもはクリスティアンはけちょんけちょんに貶すくせに、
全く世の中狂ってるよ。
益田；いやでも昭和の早い頃にはすでに子供にはクリスマスプレゼントをあげる風習があったよ。
仏人；羨ましいな。
まあそういやフランスでも似たようなのでétrenneってのがあるな。
家政婦とか守衛とか、
お前のためにいつも日々の面倒を見てくれる人に感謝の意味を込めてあげるものだけど、
まあ廃れた古い風習だな。
でも今どきのガキのクリスマスプレゼントってのもmoins sacréだな。
アイツラが欲しがるのは最新のiPhoneだよ。可愛げのないことといったらない。
俺らがガキの頃のプレゼントはせいぜい50ユーロくらいのもんだわ。
仏人；50ユーロじゃ買えねえよ！
マリオやストリートファイターがどんだけ面白いかという情報だけが流れてきて、
その間俺たちは涙を流してよだれを垂らすしかなかったんだ。
そこでフランスのオタクの猛者共は輸入をしてなんとか遊ぼうとしたんだが、
コンソールだけで2,000バル、アダプタもテレビも何もかも規格が違う中で頑張ったやつがいたんだよ。
益田；ファミコンの頃はアングレしか使えなかったから、昔の方がまだ良かったんだね（笑）
仏人；シューペルニンテンドーになると文字が全部日本語なんだ、
haï・ïïéの意味すらわからん、どっちがウイでどっちがノンだ！？
って万事がそんな調子よ。
そうやっていろんな壁を乗り越えたんだ、
プレイステーションだって規格が違うからディスクが回らないんだが、
蓋がしまっているかを感知するセンサー部分にチューインガムをつけて、
蓋を開けっ放しにしてヨーロッパ規格のディスクを入れてくるくる回して、
回った！となったら超高速回転しているディスクだから危ないんだが
それで「動いたー！！！！」とか感涙にむせんでいたんだ。
ああ、何もかもが懐かしいな。
ああ、そんなニュース聞いたな。
でも「あっそ、ふーん」くらいだわ。
まあ何の権力もないわな。
益田；でもドイツでは旧貴族の連中が国家転覆を企んでたってのがあったよね。
仏人；coup d'État!!
あったなそんなこと、実に残念だ。
我がフランスでもぜひ起きてほしいことだが。
革命の本場の我が国でも、マクロンはむしろ中世の暴君のようにやりたい放題に振る舞ってるわ。
益田；でも現代のボナパルト家やブルボン家って金持ちなんじゃねえの？
仏人；どーだろ。
でも超金持ちってことはないだろ。
子孫が増えれば増えるほどパトリモワンヌが減ってくんだし。
それに城は維持補修にえれえカネがかかるんだぞ。
もしお前んちの窓が割れたら業者に頼めばせいぜい100ユーロくらいだろうけど、
でもそれでもお城ってのは憧れであり夢だからな。
維持補修が大変だってのに買いたがるやつはいるし、海外の連中にも大勢いる。
フランスでもギニョールの声を担当してた奴らは、リサンシエされるまでは大金持ちだったから、
ほうぼうの城を買ってレフォルムしてたんだよ。
そんなの作っても意味ねーだろ。
そういった積み重ねがあって初めて城ができるんだ。
まあそういうことやるんだとしたらシノワの連中じゃねーか、
pex LegendsとCounter-Strike: Global Offensiveは、どちらもゲームですが、ゲームプレイやユーザー層が大きく異なります。Apex Legendsはバトルロイヤルゲームであり、PCやコンソールでプレイすることができます。一方、Counter-Strike: Global OffensiveはFPSゲームであり、PCでプレイすることができます。また、Apex Legendsでは、ソロプレイやフルパーティーのプレイが選択できますが、Counter-Strike: Global Offensiveでは、フルパーティーでのプレイが標準となっています。そのため、Apex LegendsとCounter-Strike: Global Offensiveでは、ゲームプレイや話題が大きく異なるため、同じスレッドで話題を共有することは困難です。
これまだ1/2だとか言っている人がいるので、本当に2/3かどうかプログラミングで確かめれば良い。
// 「ある夫婦に2人子供がいる」 // 1. 男or女 である確率は 1/2 (トランスジェンダーなどは考えない) function child() { return ["男", "女"][Math.round(Math.random())]; } // 2. 100000組の二人の子がいる夫婦を作る const families = Array(100000).fill(null).map(function () { return [child(), child()] }); // 「片方の子が男であるとき」 // 3. その中で少なくとも一人が男である夫婦を選ぶ const families_have_son = families.filter(function (children) { return ~children.indexOf("男"); }); // 「もう片方が女である確率は？」 // 4. 3の総数が母数である const total = families_have_son.length; // 5. 3の中で、女のいる夫婦を選ぶ const families_have_son_and_dauter = families_have_son.filter(function (children) { return ~children.indexOf("女") }); // 6. 5を母数で割る console.log(families_have_son_and_dauter.length / total);
私の環境では 0.6674999002778923 になった。
2/3が正しそうだ。
実際には、このコードを書いている時点で答えは明確になってしまう。
コードに落とし込むことによって隠された前提をつまびらかにする必要が出るため、実行ボタンを押す以前にはっきりする事がある。
ちなみに 1/2 にしたければ、
// 「片方の子が男であるとき」 // 3. その中で「はじめの子」が男である夫婦を選ぶ（間違い） const families_first_is_son = families.filter(function (children) { return children[0] === "男" }); const total = families_first_is_son.length; // 5. 3の中で、「次の子が」女である夫婦を選ぶ const families_first_is_son_and_second_is_dauter = families_have_son.filter(function (children) { return children[1] === "女"; }); // 6. 5を母数で割る console.log(families_first_is_son_and_second_is_dauter.length / total);
のようにすれば予想通り 0.49868384317792047...(1/2に近似する) のようになる。
息子の寝顔を見ててふと思った
２歳から使っているので器用なものだ、ゲームやYouTubeをサクサク操作している。
優しさではない
タブレットに「アレクサ」と呼びかけるとゲーム画面が消えアレクサコンソールに遷移する
割り込み中断され俺が怒るのが楽しいようだ、そのたびに腹を抱え足をバタバタ笑い転げている。
「ピッカピカピカチュー」
部屋を走り回り発狂して笑い転げる
これを何度も繰り返す、何が面白いのだか
「こらー」と叱ってやるのが最高潮で息ができないほど笑ってる
そんな息子との日々、寝顔を眺めていると俺はフワフワ幸せなんだけど、
はて、俺はこの子を幸せにしなきゃならんのだろうか。無理っぽくね？
飯は食わせ、常識や社会性を授け、習い事やら学問やら、適宜適切な機会は与えるつもりだが
知ったこっちゃない、俺の手で制御できるものではない、運もある、頑張ってくれとしかいいようがない。
○ご飯
朝：バナナ。昼：かいわれ大根、ピーマン、焼きそば。ベーコンエッグ。トマトとチーズ。夜：キャベツとウインナーのスープ。パン。
○調子
クリア。
20年以上前のゲームなのに、オシャレで格好いいイケてる雰囲気が凄かった。
私立探偵の小次郎パートと、エージェントのまりなパートで全く異なる二つの事件を捜査する。
捜査の過程で街を探索するのだが、情報屋とのやりとりや、聞き込みなどのシーンが洒落ててたり、ゲラゲラ笑えたりと個性豊かで楽しい。
絵で表現しきれない箇所はバッサリ黒塗り背景に文章だけで表現するのも潔いし、何よりそのテキストが面白いのだから一切問題なし。
ホテルのバーや海沿いの倉庫など、登場する場すら格好よく感じてくる。
軽妙なやり取りもあれば衒学的な部分もありで、兎に角事件捜査を楽しめる。
二人主人公制は最初のうちは時折登場人物が重なる程度なんだけど、徐々にそれらが一本に繋がっていくところが快感。
特に二人の主人公が互いを知らずにコンピュータ回線越しに事件捜査のために協力するシーンはただCIのコンソールに文字が出るだけも演出なのに、熱く燃える今作屈指の名シーンだろう。
この互いが互いをあまり知らずに事件捜査のために協力するという関係性も、格好いい。
普段はだらしないけどやる時はやるタイプの主人公が拳銃片手に非合法組織と戦いながら夜の街を駆ける、そんな創作物テンプレート自体が根本的に格好いい…… と言ってしまえばそれだけなのかもだけど、もうこれは冴羽獠をDNAに植え付けられた僕たちの宿命なのかもしれないなあ。
そんな感じで、事件を捜査する過程については百点満点文句なしの出来。
だけど、物語の終盤はかなり駆け足気味かつ、しっくりこない終わり方だった。
突然現れる現実を超越した科学技術に、二人の主人公は蚊帳の外で自体が進行し、犯人が突然恋愛をはじめる展開、そして自白で幕をおろす。
最終章までの丁寧な展開、格好いい展開はどこへやらで、正直肩透かし。
犯人の自白と、とあるキーパーソンの独白だけで最終盤は進むため、二人の主人公がそれらにどう感じたのかどんな行動を取ったのかが一ミリもわからないのは流石にガッカリ。
何より「犯人の自白」とは書いたが、とあるSFガジェットにより厳密には正しい言い回しではなく、真の意味での犯人はおそらく作中でセリフが全く無いという構造も、流石にちょっと終わった感じがしなかった。
とはいえ、謎解きのロジックや、あっと驚くサプライズなトリックを楽しむ作品ではなく、事件捜査の過程の格好良さを楽しみ作品だと割り切れば文句なし。
なお、柴田茜というルポライターの女性が「僕っ子」なのは、流石に当時でもコテコテでやりすぎなのでは？ と思っていたが、かないみか氏の演技力のおかげですぐ違和感がなくなった、声優ってすごい。
原作がアダルトゲームなこともあり、明らかに情事を意図するシーンや、明らかに元はエッチなことされたけど違うことに置き換えたシーンなどが多くあり、元もプレイしたくなった。
また、銃を突きつけた状態で自由を奪うために服を脱がすというシーンが3回ほどあって性癖を感じたが、たしかにその惨めさはエッチだなあと思った。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
勝手に tampermonkey とかに突っ込んで使ってヨロ
スクリプト保守とかするつもりないから、保守とかするつもりのあるパワーの溢れた人が
これ参考とかにしてもっとかっちょよくしたのを greasy fork あたりに公開してくれ
そしたら俺もそれ使う
localStorage.hatebu_ng_word_list に非表示のトリガーになる文字列を|区切りで登録する。
localStorage.hatebu_ng_word_list = "池田信夫|フェミ|弱者男性|やまもといちろう"
大なり小なり(>)が実体参照で表示されるのはよくわからん。使う人で適宜コードを直してくれ。
// ==UserScript== // @name はてブの一覧NG記事非表示 // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author masuda // @match https://b.hatena.ne.jp/* // @icon https://www.google.com/s2/favicons?sz=64&domain=hatena.ne.jp // @grant none // ==/UserScript== (function() { 'use strict'; if (!localStorage.hatebu_ng_word_list) { return; } console.log("はてブの一覧NG記事非表示", localStorage.hatebu_ng_word_list); /* * 例： * localStorage.hatebu_ng_word_list = * "池田信夫|フェミ|弱者男性|やまもといちろう|togetter.com"; */ let words = localStorage.hatebu_ng_word_list.split('|').map(w => new RegExp(w)); function entryDelete(els) { els.forEach(el => { let hit = false; words.forEach(w => { hit = hit|| w.test(el.textContent); }); if (hit) { el.remove(); } }); } // entrylist-header-main li １つ目のアイテム entryDelete(document.querySelectorAll('.entrylist-header-main > li')); // ２つ目以降の li アイテム entryDelete(document.querySelectorAll('.entrylist-item > li')); })();
文字は正規表現として評価されて、ヒットした記事項目をページから削除する(DOMから要素を削除する)。
自動で安価をつけて返信するプログラムでもこんなに長く複雑になる(一部抜粋)
/**************************************
以下のCSV_DIR, FILE_PATHS, SETTINGSを書き換えてね。 <h3>o- *************************************/</h3>
//CSVファイルが置かれてるディレクトリのパス。投稿前にエラー出たら大体ここの設定ミス。 例："C:\\Users\\sakuraimasahiro\\Documents\\iMacros\\Macros\\rentou\\";
'C:\\Users\\USER\\Desktop\\iMacros\\Macros\\rentou\\';
//ファイルのパス。CSVは絶対パスで、拡張子も必要。iimは相対パスでよく、拡張子不要。
const FILE_PATHS = {
textCsv: CSV_DIR + 'textNoAnker.csv',
//レス用投稿文が書かれたCSV。通常とレス用で分けないなら同じファイルを使えばいい。
replyTextCsv: CSV_DIR + 'textReply.csv',
};
baseWaitTime: 5,
//baseWaitTime+0～waitTimeRange（ランダム）だけ待つ
waitTimeRange: 5,
//連投しすぎだと忠告された場合に処理を一時停止させる時間(秒)
waitTimeForAvoidingPunishment: 60 * 30,
//メール
mail: 'sage',
//名前設定
name: '',
//以下、偽装ワッチョイ設定。浪人でワッチョイを非表示にしてるときだけtrueにしてね。
//妙なニックネーム（ﾜｯﾁｮｲ、ｱｳｱｳｳｰなど）をランダムで決めて付加するかどうか。true=付加する。false=付加しない。
//妙なニックネームの後に付く8桁の文字列をランダムで決めて付加するかどうか。
},
//アンカー無し投稿をするならtrue。しないならfalse。noAnkerPostかreplyPostのどちらかはtrueにすること（両方trueでもOK）。
//アンカー付き投稿（返信）をするならtrue。しないならfalse。もしnoAnkerPostとreplyPostの両方がtrueの場合、投稿は返信が優先され、返信対象が見つからなくなったらアンカー無し投稿をする。
//最初に取得するアンカー無し投稿文CSVファイルの行番号。もし返信用と同じCSVファイルを使うなら-1と入力。
noAnkerPostTextCsvStartRow: 1,
//最初に取得する返信用投稿文CSVファイルの行番号。もしアンカー無しと同じCSVファイルを使うなら-1と入力。
//テキストCSV/返信用テキストCSVの取得行が最終行に達したら最初の行まで戻るかどうか。true=戻る。false=マクロ終了。
//返信する場合、これより小さなレス番には返信しない。返信を投稿すると、この数値は前回の返信先のレス番に更新される。
minAnker: 895,
//返信する場合、名前に以下の文字列を含む投稿にアンカーをつけて返信する(ﾜｯﾁｮｲやIPなど名前フィールドにあるものならなんでも可)。配列で複数指定可能。指定無しなら空配列（[]）。filterNamesとfilterNamesNotIncluded共に無指定ならレス番1から順に返信していく（minAnkerが設定されてればそこから順に）。以下のfilter系は全て併用可能。
//↑とは逆に、名前に以下の文字列を含まない投稿にアンカーをつけて返信する。↑と併用も可能。
//返信する場合、本文に以下の文字列を含む投稿にアンカーをつけて返信する。
filterText: ['自演かな', '自演わらわら', 'スクリプト使うの', '安価ガバ', '>>660', '自演で擁護', '最後' ,'あいうえお', 'かきくけこ', 'さしすせそ', 'なにぬねの', 'はひふへほ', 'まみむめも', 'やいゆえよ', 'やゆよ', 'らりるれろ', 'わいうえを', 'わをん', 'わいうえをん'],
},
//自分のIPアドレスの確認。VPNとかでIPを変更してマクロを動かしてるとき、突然VPNが作動しなくなってIPが元に戻ったときにマクロを止めるためのもの。
//以下の文字列が自分の現在のIPアドレスに含まれている場合、マクロを一時停止する。基本的に自分の本当のIPアドレスを入力。
},
//浪人設定。最後に動作を確認したのは5年くらい前で、今も同じように動作するかは、浪人を持ってないから確認できずわからない。
//浪人にログインしてるかどうかをチェックするかどうか。trueならする。falseならしない。trueにしていてもし浪人にログインしていないことを確認したらログインしにいく。
password: '1234',
},
};
/**************************************
設定箇所終わり。
https://info.5ch.net/index.php/%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%82%81%E3%81%AA%E3%81%84%E6%99%82%E3%81%AE%E6%97%A9%E8%A6%8B%E8%A1%A8 <h3>o- *************************************/</h3>
/**************************************
・NULL演算子(??)は使えない。論理積(&&)は使える。
・オブジェクトの分割代入はできない。
・importはできない。 <h3>o- *************************************/</h3>
/**************************************
関数 <h3>o- *************************************/</h3>
/**
* ここから始まる。
*/
checkSettings();
var _TextCsvCursors = new TextCsvCursors(
SETTINGS.postSettings.noAnkerPostTextCsvStartRow > 0
? SETTINGS.postSettings.noAnkerPostTextCsvStartRow - 1
: SETTINGS.postSettings.noAnkerPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
SETTINGS.postSettings.replyPostTextCsvStartRow > 0
? SETTINGS.postSettings.replyPostTextCsvStartRow - 1
: SETTINGS.postSettings.replyPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
);
var _LoopStatuses = new LoopStatuses(0, SETTINGS.postSettings.minAnker);
const _MyPosterName = new MyPosterName({
name: SETTINGS.nameSettings.name,
});
const _ThreadUrl = openPromptThreadUrl();
//ループ
while (true) {
SETTINGS.ipSettings.checkIp && checkCurrentIpNotTheIp();
//スレを開く
openUrl(_ThreadUrl.fullUrlHttps());
//浪人にログインする設定なら、浪人にログインしているかどうかを確認し、していなければログインしにいく。
if (SETTINGS.roninSettings.checkLogin) {
}
}
if (SETTINGS.postSettings.replyPost) {
const targetAnkerNumber = createPostDOMList()
.filterPostnumberHigher(_LoopStatuses.currentMinAnker())
.filterByPostername(SETTINGS.postSettings.filterNames)
.filterByPosternameNotIncluded(
SETTINGS.postSettings.filterNamesNotIncluded,
)
.filterByText(SETTINGS.postSettings.filterText)
if (targetAnkerNumber !== null) {
const r = _TextCsvCursors.takeNextRowTextAsReply(targetAnkerNumber);
messageDisplay(`返信対象有り。アンカー先: ${targetAnkerNumber}`);
return {
...r,
updatedLoopStatuses:
_LoopStatuses.updateMinAnker(targetAnkerNumber),
};
}
}
if (SETTINGS.postSettings.noAnkerPost) {
//返信対象無し、或いは返信しない設定の場合。アンカー無し投稿文を作る。
const r = _TextCsvCursors.takeNextRowTextAsNoAnker();
messageDisplay('返信対象無し。アンカー無し投稿。');
return {
...r,
updatedLoopStatuses: _LoopStatuses,
};
}
return null;
})();
if (p) {
//投稿。
nickname: SETTINGS.nameSettings.nickname,
korokoro: SETTINGS.nameSettings.korokoro,
area: SETTINGS.nameSettings.area,
}),
SETTINGS.mail,
p.text,
);
//_TextCsvCursorsと_LoopStatusesを更新。
_TextCsvCursors = p.updatedTextCsvCursors;
_LoopStatuses = p.updatedLoopStatuses.incrementPostCount();
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
} else {
`返信対象が現われるのを待機中...。`,
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
}
wait(SETTINGS.baseWaitTime + randomRange(0, SETTINGS.waitTimeRange));
}
}
/**
* 投稿処理と投稿結果を見てリトライしたりマクロ終了したり。
* @param {string} serverName サーバー名
* @param {MyPosterName} _MyPosterName
* @param {string} postMail メール
*/
serverName,
postMail,
_MyText,
retryTimes = 0,
) {
const r =
retryTimes === 0
? new ValuesOfPost(serverName, _MyPosterName, postMail, _MyText).post(
postTo5chTread,
)
serverName,
postMail,
_MyText,
).postSubstring(retryTimes, postTo5chTread, postConfirm);
if (r) {
back();
return;
}
wait(7);
const error = createPostErrorMessage().analyze();
messageDisplay(error.message);
if (error.order === 'KILL') {
kill();
} else if (error.order === 'SKIP') {
return;
} else if (error.order === 'TRUNCATE') {
back();
serverName,
postMail,
_MyText,
retryTimes + 1,
);
} else if (error.order === 'WAIT') {
wait(SETTINGS.waitTimeForAvoidingPunishment);
serverName,
postMail,
_MyText,
retryTimes,
);
} else if (error.order === 'LOGIN') {
serverName,
postMail,
_MyText,
retryTimes,
);
}
return;
}
/**
* 現在のIPアドレスに、SETTINGS.ipSettings.avoidTheIpの値が含まれていないことを確認する。含まれていたらマクロを一時停止。
* @returns
*/
function checkCurrentIpNotTheIp() {
openUrl('https://www.cman.jp/network/support/go_access.cgi');
const _IpAdress = createIpAdressFromCMan();
if (_IpAdress.includes(SETTINGS.ipSettings.avoidTheIp)) {
pause('現在のIPに指定した値が含まれていることを確認。');
}
return;
}
/**
* @returns
*/
if (
SETTINGS.postSettings.noAnkerPost === false &&
SETTINGS.postSettings.replyPost === false
) {
return kill('設定エラー。noAnkerPostとreplyPost両方ともfalseになってる。');
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow < 0 &&
SETTINGS.postSettings.replyPostTextCsvStartRow < 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRowとreplyPostTextCsvStartRow両方とも-1になってる。',
);
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow === 0 ||
SETTINGS.postSettings.replyPostTextCsvStartRow === 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRow/replyPostTextCsvStartRowの初期値は-1或いは1以上で。',
);
}
}
/**
* 入力フォームを表示して入力されたスレのURLを受け取る。
*/
function openPromptThreadUrl() {
const url = prompt('スレURLを入力');
}
/**
* 開いてるスレのレス全て読み取ってPostListインスタンスを作って返す。
* 重すぎるので使うのやめ。どうやらインスタンスの大量生成が原因な模様。
*/
const posts = window.document.getElementsByClassName('post');
return new PostList(Array.from(posts).map((e) => new Post(e)));
}
/**
* 開いてるスレのレス全て取得してPostDOMListに格納して返す。
* @returns
*/
function createPostDOMList() {
const posts = window.document.getElementsByClassName('post');
for (let index = 0; index < posts.length; index++) {
//HTMLCollectionからElementを1つずつ抽出して配列に。
arrPostDOMList.push(posts.item(index));
}
return new PostDOMList(arrPostDOMList);
}
/**
* 開いてる投稿結果画面に表示されてるエラーを読み取ってPostErrorMessageインスタンスを作って返す。
*/
function createPostErrorMessage() {
window.document
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。
初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。
Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)
和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。
また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。
元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。
https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date
ほぼ毎号のように出現していたのが判るだろう。
もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。
この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。
UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。
オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。
「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。
そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。
UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。
さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。
端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。
結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。
当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。
こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。
CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。
ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。
そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。
ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。
もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。
こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。
当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。
Small is beautiful.
マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？
ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
