  |
はてなキーワード: コンテナとは
昔からオジサンが若い女とエロいことをするエロ系コンテンツが大好物。ちなみに自分は女。そういうエロコンテナツをみる時は複数視点に感情移入してて、まず女性側に感情移入して、性欲の獣みたいな存在とセックスしてる事実に興奮する。オジサン×若い女には一種の異種姦的な趣がある。
ついでオジサン側にも感情移入して、若い女の肉体美を堪能したり（増田はレズじゃないけど女体礼賛だ）そういった存在とセックスできているという満足感、恍惚に興奮する。
好みの展開は、おじさん側が生で挿入することに成功して若い女側が気持ちよく喘いでいる構図である。不倫カップルのようにいつも生でする関係には興奮しない。あくまでも美しい女体に幸運にもありつけた興奮がそこになければならないし、女にとっては一種の異種姦でありながら感じてしまっているというロマンがなければならない。
不満なのが、こういうエロコンテンツにあまり出会えないことである。AVは全体的に男優が若すぎだし、たまにおじさん男優がいても筋肉ムキムキで萎える。こういう物語のおじさんは筋トレなどしないのだ。
二次元の方でも、おじさん主人公はレアである。あと若い女を通り越してロリっぽいが人気で、なかなか若い女と言えるような20代くらいの成熟したボディの女性が出てこない。
そんばわけで不満である
おあそびでPythonで作った自前のCLIアプリをWebで操作したくなり、Celeryと FastAPIで Webから実行できるようにした。
んでつぎは、オシャレな画面をオシャレにつくりたくてReactでフロントを作ろうと思ってるんだけど、そもそも自分はReactの書き方を知らないんだな。
とはいえ仕事柄、このさきReactから逃げ続けるわけにもいかない。
勉強のため、とりあえずなんかのツールが吐き出す、出来合いのReactのボイラープレートを動かしてみようと思ってるわけだけど
そのためには Vite が要って
そのためには Node.js 18+ が要って
そのためには nvm-windows が要る（そういえば nvmって、、、 Javaの mvnと 紛らわしいですね）
そのためには chocolatey が要る（あ、これは自分のPCに入っている、ラッキー！）
たかがフロントエンドと思ってるなら StreamLitで作ればいいじゃんとか言ってくる人もいるだろうけど、そういうわけにもいかねえのな。
あと今から勉強するならSvelteだとか言ってくるひともいるだろうけど、これも無視。
https://togetter.com/li/2207560
普通にこの記事を読んだ感想って、怖いねとか、やばいねってのが先立つのが当たり前だと思うんだけど、なぜかはてな民は「日本は云々」と日本の悪政に絡めたくてしかたないようなアカウントがいっぱい出てくるのよね。
今（2023-08-18 19:00）現在、120ブクマくらいだけど、それでもすでにこんだけ上がってきてる。
さすがにIDはかわいそうだから抜いとくね（といっても大体いつものアカウントだけど）
若い女性がこんな目に遭うなんて酷すぎる。海外渡航の警告出せば済む話ではなくて、日本政府が貧困対策に取り組んで来なかったという事では。
こういう風俗・売春の中でも海外出稼ぎレベルをやろうとするやつは、貧困対策にどんなことをやったところで一定数表れるので、マジでお前は世間知らずか上っ面の正義感。そういうのは立憲民主党か日本共産党の集会の中だけでとどめておかないと恥をかく
「今の」「海外の」「日本人女性が」あってる（らしい）話に対して、80年近く前の慰安婦の話を出すのって、それしか言えないバカなの、ねえ、馬鹿なの。どうしてそんな育ち方しちゃったの？？
まあこれを取り上げるのは若干かわいそうだが、とはいえブローカーが搾取していても、日本に来た技能実習生が雇い主から目をえぐられるなんてことあるわけでもないわけで、議論のすり替えありがとうございますって感じか。
つうか、本当に日本も貧しくなったんだな…
だから、日本が貧しくなったとはこれは全然違う話だってばさ。出稼ぎ売春婦は日本で食えないから行くんじゃないの。もっと社会の吹き溜まりのような歪みで海外に行ってるの。
まっとうに稼ぎに来てたり研修に来てたりする海外の人を、入管という場所で人を家畜のように扱う国があるんですよ。海外からの技能実習生を奴隷のように扱ったりもしてるらしい。酷い国だよね。どこの国かしら？
もうね、こういう定型文出ると思ったら出てきてるんだよな。すげえよな。さすがはてな民としか言いようがない。お前の世界では技能実習生は全員トラックのコンテナに押し込められて、目をえぐられたりしながら仕事してんだろうな、お前の世界ではな
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
完全に独立した技術スタックになりつつある、しかし出来る人間が非常に少なく胡散臭い優秀なフリをしたエンジニアが数多くいるように見える。
さらにとっつきやすさから新人も参入しやすくカオスな雰囲気を感じる、自分の周囲を見た感じでも技術スキルは低めの傾向が見える。
トンカチを持ってそれを振りかざすことを目的にしちゃってるような人間が多いように見えるし、そうでない人間はそもそも技術へのキャッチアップが低い傾向にある。
昔からそんなに変化がない、AWSやGCPの運用や設計もやることがある。
WEBアプリケーションのフレームワークが無いと仕事できない、とにかくDBが大事でプログラミング能力はフレームワークの使い方に寄っている。
DBが大事なのでプログラミングスクールだろうが独学だろうが、勘所を掴むのは困難で実務ありきで成長する必要がある。
大量のトラフィックを扱う人は分散のための設計なども心得ているものの、大抵は場当たり的な対処しかしていない。
IaaS登場以前は空気が乾燥した寒い部屋で黒い画面相手に定形作業をしていることが多かった。
昨今SREと呼ばれるようになり地位が向上しつつあるが、業務内容も広がってきておりIaaSの設計能力が大きく問われるようになってきた。
WEBフロントエンドほどではないが、仮想OS、IaaS、コンテナなどそこそこのテンポで技術が進歩している。
この他にも過去の名残だったりIaaSを触る都合、社内SE的な仕事もしたりする、相変わらず深夜対応もある、辛い…
年１回、必ず新機能が出てくるので定期的に技術をキャッチアップ出来る必要がある。
国内に限定すると技術スキルは高めの人が多い傾向が見えるが人間としては癖の強い人が多い傾向も見える。
（ちなみに少ない観測範囲だが海外勢は微妙な技術レベルの人間が多かった。）
給与レンジはピンのほうはそんなに高くないがキリのほうはそこまで低くない。
ここ20年ぐらいで台頭してきたITエンジニアとは別種の雰囲気を持つ印象、詳しいことは分からない。
技術力はあまり重視されない、コミュニケーション能力や簿記などの会計知識が重要視される。
給料は低め。
---
WEBフロント、バックエンド、SRE、アプリあたりは幾つか交差する領域がある。
交差するキャリアを取っている人はどれも凄い人かどれも微妙な人に二分される傾向が見える。
Next.js を勉強中なんだが、Docker で negix (web) と Next.js のコンテナを起動していて、Next.js から web の API (ttp://127.0.0.1:8080 とする) を fetch するときに、Next.js 側がサーバーコンポーネントの場合 URI に ttp://127.0.0.1:8080 を指定すると fetch failed する。ttp://host.docker.internal:8080 じゃないと駄目だった。
やられた。これで何日持っていかれたのか。
クライアントコンポーネントだと ttp://127.0.0.1:8080 で普通に動作する。サーバーコンポーネントでも httpbin.org などの他の API は正常に動作する。web 側で Access-Controll-Allow-Origin も設定されている。だから、まー謎だった。エラーメッセージも全然詳しくねーし。
Twitter では死んだふりをしてるので取り急ぎここにメモ。SNS に復活することがあったらあとで消す。
参考
ttps://qiita.com/YasuhaF/items/8a72d2898736fb60315f
Ria.Ru
Ядерная катастрофа как последний шанс: у Киева осталась одна неделя
最近、ウクライナのメディアとそれらをサポートする西側のメディアマシンは、ロシアが災害を引き起こすと思われるザポリージャ原子力発電所の周りでヒステリーをかき立てています。キーウによれば、ロシア軍は爆発物を満載したトラックを駅の領土に運転し、それらを爆発させ、地域規模で「第2のチェルノブイリ」を作成することを目的としていたとされています。
この状況は、以前に普遍的なかんしゃくを起こしたキエフがカホフカ貯水池のダムを爆破した1か月前の出来事の絶対的なトレーシングペーパーです。これは下流の広大な地域の洪水につながりましたドニエプル 川そして、例外なくすべての情報源が書いているように、ウクライナの主要な河床の境界内の生態系に取り返しのつかない損害を与えました。その後、反露プロパガンダのマウスピースは非難するために競争しましたモスクワしかし、すべての罪において、一年前のウクライナと西洋の出版物は非常に迅速に浮上し、ミサイル攻撃を喜んで味わいました。マット川の消防士-ドローンの打ち上げに関するロックとトレーニングについて。これらの記録はすべて迅速にクリーンアップされましたが、これは全体像を変えませんでした。
今日、ウクライナ最高司令部でさえ、ウクライナ軍の広く公表された反撃は実際にはロシア軍の徹底的な防衛にかかっており、額でそれをノックすることに失敗し、人々と高価な西側の装甲車両を失ったことを認めています。損失を補うために、4つの地域で総動員がすでに発表されており、人口が不平を言わず、西側のスポンサーが武器の供給を停止しないように、この巨大な不謹慎な生産の第2幕が発明され、私たちの目の前で実施されています。肉眼でも同じ手書きを見ることができます。
爆発当時、カホフカ水力発電所はロシアの管理下にあり、その唯一の稼働中の水力発電所は専門家によって整備されていました。」ラスハイドロ".ZNPPでは、すべての原子炉が冷温停止モードにあり、定期的なメンテナンスは従業員によって提供されます。」ロスアトム".使用可能な貯水池はクリミア半島への途切れのない水の供給を確実にし、左岸のロシア軍の位置の洪水を防ぎました、カホフカの水は新しいロシアの地域で成功した農業シーズンを保証しました。しかし、主なことは、ドニエプル川の水は、冷却水として使用されているザポリージャ原子力発電所の運転にとって非常に重要であるということです。
ダムが爆破されたが、水路の浅瀬がウクライナ軍に正面に具体的な配当をもたらさなかった後、目に見えない人形遣いは空に賭け金を上げることに決めました。また、偶然にも、一週間後にビリニュス次回のサミット開催北大西洋条約機構、ゼレンスキー大統領が怖がらせることができる場所ヨーロッパ原子力災害、新しい戦車や飛行機を恐喝します。
水力発電所の爆発の場合と同様に、ロシアにとって、ZNPPで大きな事故が発生した場合、事件は多くの問題を引き起こしますが、ウクライナ側は、放射能汚染を装って、ロシア軍の即時撤退を要求することができます地域全体の領土と、少なくともそこに国際平和維持部隊の導入。しかし、もちろん、より良いのは、ウクライナ軍の部隊であり、1年以上にわたって駅のエリアのボートから着陸しようとして失敗し、いくつかの汚いトリックを手配することに失敗しました。
脅威の実際的な確率を考えると、危険が実際に存在することに注意する必要があります。
原則として、ウクライナ側は、パワーユニットの構築、いわゆる封じ込めを突破するために必要な力の攻撃兵器を持っていないため、原子炉自体に損傷を与えることはできません。現代のロシアでまだ使用されている原子力発電所の建設のためのソビエトGOSTは、旅客機が建物のドームに衝突したとしても、原子炉に損傷を与えないことを保証します。同様に、使用済み核燃料の入った容器が水中に保管されているプールについても心配する必要はありません。ZNPPでは、それらは封じ込めゾーン内にあるため、外部の物理的影響からも保護されています。
しかし、これらの予防措置はすべて平時用に設計されているため、脆弱性があります。
鍵はドニエプル川の水です。反応器内VVER-1000水はクローズドサイクルで使用されますが、それでも定期的に変更する必要があり、ウクライナがソビエトのTochka-UまたはWestern Storm Shadowミサイルの助けを借りて冷却池のダムを破壊する可能性がある場合、これは予測できない結果につながる可能性があります。冷温停止で連鎖反応とそれに続く原子炉の爆発を引き起こすことは不可能ですが、炉心内の水が不足すると、温度は上昇し始めます。ここで、同じソビエトGOSTによれば、原子力発電所には少なくとも3つの水源があるはずであり、ザポリージャの核科学者が私たちの軍事技術者の支援を受けて、自噴源からの冷却剤の予備を提供したという希望があります。
ステーションの最も脆弱な部分は、間違いなく、単に屋外にある使用済み核燃料の乾式貯蔵のままです。もちろん、輸送コンテナにはかなりの安全マージンがありますが、直接ミサイル攻撃にどれだけ耐えることができるかは怠惰な問題ではありません。
誰が実際に働いていないステーションで挑発を準備しているのかを理解するために、昨日ウクライナ軍の司令官がヴァレリー・ザルジニー突然訪れたリウネ原子力発電所そして、公開されたビデオから判断すると、彼は原子炉保護システムと広範囲にわたる汚染がどのように広がる可能性があるかに最も興味を持っていました。
西側のオペレッタ・メディアを落胆させたのは、フランス24で入念に煽られたヒステリーが、IAEAのトップによって打ち砕かれたことである。ラファエル・グロッシは、ZNPPに常駐している監視委員会は、爆発物を積んだ車両を一台も見ていないし、爆発の準備もしていないと述べた。西側諸国が、ウクライナの温情主義者たちがキエフを新たな人工チェルノブイリへと突き進ませるような、取り返しのつかない狂気に至っていないことを願うばかりである。
https://www.python.jp/train/tuple/index.html
以下、気になったところ。
タプル
Pythonでは、複数のデータの組み合わせから構成されているデータを表現する場合、タプル という種類のオブジェクトを利用します。
タプルの書き方
タプルは、要素となるデータを「 , 」で区切って記述できますが、「, 」だけだとちょっと見にくいので、通常は全体を丸括弧 () で囲んで記述します。
ningyocho = (35.686321, 139.782211)
kotoshi = ('平成', 2)
この括弧は必須ではありませんが、括弧なしでは読みにくく、間違いの元になる場合もあるので、通常は括弧をつけて記述する慣習になっています。
タプルオブジェクトの要素を参照する
タプルオブジェクトに登録したオブジェクトは、リスト と同じように 要素の順番 を指定して参照できます。
タプルオブジェクト[要素の順番]
== 演算子でタプル同士を比較すると、同じ値のタプルならTrue を返します。
!= 演算子でタプル同士を比較すると、異なる値のタプルなら True、等しい値なら False を返します。
タプル同士の値の比較は、先頭の要素から順番に同じインデックス同士の値を比較して、先に小さい値となったタプルが小さい値となります。
比較するタプル同士の長さが異なる場合、短いタプルの要素と長いタプルの要素を比較してすべて等しければ、短い要素のほうが小さい値となります。
タプルオブジェクトの場合、リストオブジェクトのように要素を変更することはできません。
タプルオブジェクトの要素を変更する場合は、リストオブジェクトのように要素を変更するのではなく、あたらしくタプルオブジェクト全体を作り直す必要があります。
タプルとリスト
リストとタプルはどのように使い分ければよいのでしょうか？
タプルは複数のデータの組み合わせから構成されているデータのためのオブジェクトです。
複数の要素から構成される独立したデータ をあらわすときは、タプルを使用します。
固定的な形式をもつ独立したデータではなく、不定個数の独立したデータをたくさん集約してまとめておきたい、という用途には、リストが適しています。
数値オブジェクトは、物質の重さや長さなど、いろいろなデータの値を直接あらわすオブジェクトです。
一方、 リストや辞書は、直接的なデータではなく、いろいろなデータを登録して、集約しておくために使われるオブジェクトです。
リストやタプル、辞書のように、他のオブジェクトを集約することを目的とした種類のオブジェクトのことを、
コレクション (Collection)
と呼びます。
コレクションに登録されている要素の数は、len() 関数で調べられます。
コレクションは、比較演算子 の == 演算子や != 演算子で、値が等しいかどうかを判定できます。
in 演算子を使うと、コレクションに値が登録されているかどうかを調べられます。
in 演算子は < や == のような 比較演算子 の一種で、
値 in コレクション
という式は、指定した値がコレクションに登録されていれば True を、登録されていなければ False を返します。
辞書オブジェクトの場合、in 演算子は指定した キー が 登録されているかどうかを調べます。
文字列オブジェクトの場合も、in 演算子で中に文字が含まれているかどうかを確認できます。
コレクションは、 for 文に指定して、コレクションの要素ごとに、for 文に記述した処理を実行できます。
辞書オブジェクトを for 文に指定すると、辞書のすべての キー を取り出して、for文に指定した処理を行います。
リスト・タプル・文字列はいずれも コレクション に属するオブジェクトですが、コレクションの一種で、整数値のインデックスを指定して要素を参照できるオブジェクトのことを、
シーケンス (Sequence)
と呼びます。
リストやタプルなどのオブジェクトは、コレクションの一種で、他のオブジェクトを登録し、集約できるオブジェクトです。
シーケンスとは、コレクションのうちで、集約する要素が一定の順序で並んでいて、その順序(インデックス)を使ってその要素を指定できる種類のオブジェクトのことを指します。
コレクションに属するオブジェクトでも、リストやタプルとは違って、辞書 は、順序を指定して要素を指定することはできません。
タプルやリスト、文字列などのシーケンスオブジェクトは、 <、 <=、>、>= などの演算子で、値の大小を判定できます。
シーケンスではない、辞書オブジェクトなどのコンテナオブジェクトは、 < などによる大小の比較はできません。比較すると、エラーとなります。
コレクションのアンパック
代入式の右辺がコレクションなどの場合には、左辺に複数の変数名を指定して、コレクションの要素を一括して変数に代入できます。
（例）
list_obj = [1, 2, 3]
var1, var2, var3 = list_obj # var1, var2, var3 に、list_objの要素を順に代入
print(var1, var2, var3)
1 2 3
変数 var1、var2、var3 には、右辺のリストオブジェクトの要素が一つずつ順番に代入されます。
この場合、var1 には list_obj の最初の要素である 1が、var2、var3 には、それぞれ2番目と3番目になる 2 と 3 が代入されます。
アンパックを利用した代入は、Pythonプログラミングで頻繁に利用されます。
アンパックは、複数の値を戻り値とする 関数 でよく使われます。
関数で計算した結果は、return文 を使って、戻り値として返します。
しかし、関数 total_and_average() は合計値と平均値の2つを計算しますが、 return文 に指定できる戻り値は一つだけです。
（例）
def total_and_average(values):
total = 0 # 合計値の初期値 0 を設定
average = total / num
return (total, average)
戻り値としてタプルを使い、複数の値を一度に返す関数はとてもよく使われます。
テクニックとして覚えておきましょう。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
好きな事ってのはYoutuberとかアートとかそういう派手な方面だけじゃ無いんだよ。それは「憧れ」で好きなことじゃないだろ。
道路を作るのが好き、と言う奴と、本当は料理を作るのが好きなんだけど仕事だからと道路を作ってる奴だと、よほど基本スペックに差が無い限り、前者に後者は勝てない。
すでにかなりの割合の人は、好きな事を仕事にしているはず。その職に就いた時は好きでも嫌いでもなかったかもしれないけど、後から好きになったという人もいるはず。
なんか「仕事とは苦しいものだ。苦しいほどお金が得られる。他の人もそうに違いない」という呪いにかかっているように見える。それだとAIとロボットが動く時代には勝てないよ。
何事もそうなんだけど、設備投資で機械化されるのは以下のような順番で行われる。主にコストの問題。
で、人がやりたがる仕事ってのはこの中には当てはまらないのよ。人がやりたがるような仕事が自動化されるのは、この後、とんでもないコスト革命が起きるまで待たなきゃならない。
しかし、それでもやりたいと言う人が情熱を傾けると、そこに需要が発生して職業として成立しているよ。例えば伝統工芸などはその類いだ。
だから、AI時代だからこそ人がやりたがるような人気のある仕事ほど自動化される、と言うのはまるっきり認識が逆。
人がやりたがらない仕事≒人手が慢性的に不足するところの自動化が今進んでいると言う話。そして、人がやりたがらない仕事を選んでいると、ロボットやAIとコスト競争させられることになるのでお先真っ暗。
読者諸兄はデパートに行ったらどこが気になるだろうか？デパ地下？ファッション売り場？
増田は搬入口の場所だ。売り場で何売ってるかなんてどこから搬入するかに比べたらどうでもいいことだ。この文書を読んだら君もきっとそうなる。
売り場で物が売れたらそれを補充しなきゃならない。その搬入口は大抵ビルの裏にある。
しかしデパートがある場所というのは一等地だ。バックスペースである搬入口なんかの為に一等地を使うのは余りに勿体ない…。
という事で離れた場所に搬入口が設けられて秘密の通路で結ばれていることがあるのだ。
それを幾つか紹介するよ。
因みにこういう所は仕事でしか入れないもので、増田が仕事で行ったり同僚に聞いた入りした事がある個所に限られるから偏りはあるよ。
ヤマダ電機が運営する池袋LABIは元は池袋三越だった。開業は昭和29年の地下鉄丸の内線の前年か同年と古い。
LABIの裏に都道があって、道路反対側に3階建てのマクドナルドがある。その裏に付近に似つかわしくない古くて灰色な運送会社的なところがある。
https://goo.gl/maps/9fDTtZiNEB3pQTbJ8
ここが搬入口で地下トンネルで結ばれている。さっきのマクドナルドはそのトンネルに乗ってるのだね。だから周囲が高層化しても3階建てのままなのだ。
かなり離れたところにあるびっくりガードの中に分岐がある。
https://goo.gl/maps/bsTBq4EtxBrgqc23A
元々ここは東上線の線路だった。山手線から東上線への渡り線と電車の留置線が伸びていた。
国鉄が貨物輸送を全廃に近い合理化すると東上線行きの貨物輸送も無くなり、ここは遊休施設になった。
90年代に東武デパートが増床して新館のプラザ館を作る事になるとこの線路跡も一部利用され、新館より先は地上は駐輪場、地下には搬入路として旧館の搬入も集約化。東上線池袋駅が行き止まりホームになったのはこの時だ。
それまで旧館は東上線の北口改札横にある汚らしい搬入口で搬入していたのだが、ここのせいで一帯が大変に荒んでおり、まるで古いアメリカ犯罪映画のダウンタウンのようだった。
https://goo.gl/maps/WQB7qSNwj4AjQPQc8
ミロードの甲州街道のルミネとの間にあって、急勾配でミロードの中を登り、モザイク坂上のミロード広場の上階に出る。
https://goo.gl/maps/oEbSXc96jzT8adFW8
ここは急勾配＆高さ制限がキツイ＆急勾配登ってすぐに急カーブのクランクというデンジャラスなコースだ。クランクの路面は坂登ってる間は見えない。しかも途中で止まると再発進不可な程の急坂なのでアクセルを緩められない。そして暴走してクランクを突っ切ってしまうとミロード通りに落下だ。
危なすぎる。ハードドライビンのスタントコースみたいなところなのだ。
ここを攻める人は注意して欲しい。落下したらインスタントリープレイされるだろう。
https://goo.gl/maps/ZCo693QRHujchVqZ7
ここからJR本社ビルの周りをぐるっと回って甲州街道陸橋の下を潜り、ルミネに到達する。甲州街道陸橋の下が公共地占有だ。
因みにJR本社前にBLAST!っていうお店があって、周囲は高層化されているのにここだけ2階建てだ。
実はここは土地取引を巡って管財人の司法書士とヤクザが殺されたという曰くつきの土地でずっと更地＆駐車場のままだったところだ。
また、バスタの下には昔JRバスの駐車場になっていた大きな地下空間があって高島屋タイムズスクエアとJR本社とトンネルで結ばれているらしい。駅の工事の際には工事基地や職工の詰所になるようだ。ちょっと入ってみたいもんである。
https://goo.gl/maps/UxNpSesPQp88VQY68
西武デパート群は駅に近いA館と井の頭通り向かいのB館、ロフト、パーキング館とあるが、全て地下トンネルで繋がっている。
特に特筆すべきは井の頭通りで、ここは宇田川という川が暗渠化された道で今でも暗渠に宇田川が流れている。
搬入トンネルはこの地下の宇田川の更に下を通ってるってわけだ。
珍奇な搬入路の王者と言ったらここである。もう無くなってしまったが。
駅の東西に建っていたややボロッちかった東急東横店。ここの搬入口がどこにあったかというと、現在ストリームになっている東横線高架下にあった。（古い画像）
https://goo.gl/maps/tA5i7NkHkTGbhhce9
ここからR246の下を通り、東横店東口店までずっと地下トンネルが通っていた。
更にここには空港の手荷物コンベアのようなコンベアがあり、行先（受取り先）が書かれた専用のコンテナに入れて流すと東横店の方に着くというシステムであった。こんな風にシステムになったのは246の掘り下げ工事があり、途中にエレベータを挟んでいたためだと思われる。
このルートというのは全部東横線の高架線と駅の下だ。高架の下に後からトンネルを作るのは危険だし難しい。
つまり、昭和2年の東横線開業時にはすでにこういう通リになっていたという事である。
因みにこの近くには稲荷橋という橋があったので「稲荷橋搬入口」と呼ばれていた。というか、最近行ってみたら川が無くなっているのに橋だけ残ってたわ。
東横店は無くなって今は新しいビルになってるし、稲荷橋搬入口はストリームになってるが、あの地下搬入路はそのままのはずだ。
あれは今どうなっているんだろうか？東横店跡の新しいビルとストリームの地下で荷物の輸送に使われているんだろうか？実に気になる。
肝心の「東横店東口店と西口店の間はどうなっていたか」については西口店の方に用が無かったせいで不明である。無念だ。JR線地下を通っていた、京王マークシティの方にあった、二つの可能性がある。
開業当初は国鉄より頭の固い鉄道省と別会社の帝都電鉄だった訳で気になるのだが…ちゃんと見ておきたかった。
これらには公共地である道路を潜って離れた場所に繋いでいるケースが多い。
普通はこういう占有方法は認められないが、施設の公衆性が強い場合は許されるのである。私鉄が道路地下を走っていたり病院の渡り廊下が道路跨いでたりと同じだ。
デパートの場合の公衆性は、公衆が自由に立ち入り出来て買い物ができる、市場の性格がある事だ。だからデパートは会員制の立ち入り規制的な事が出来ない。
余談だが、中野ブロードウェイのまんだらけが性的な商品を通路側に陳列して対面の商店とトラブル、その商店をネット民が攻撃して炎上するというトラブルがあった。
この時にネット民は中野ブロードウェイは私有施設だから陳列は自由、まんだらけの占有面積は大きいので施設運用でのヘゲモニーがある、というような考えを開陳する人が多く居た。
でもこの法的スキームを知っていたらこの考えは間違いという事が判る。中野ブロードウェイは公衆施設の一種でありそれは立ち入りが自由である事だから、そこの通路は公道が準用される。
そこに性的な陳列をしたら独立店舗の中での陳列よりも厳しい基準で取締りが行われるのは当然なのだ。実際まんだらけはガサ入れされて商品を押収されて件の店舗は後に閉鎖する事になった。
また、デパートは売店床面積を最大化したいのでこういう離れた箇所に搬入口を作るのである。だからビル裏に搬入口を作る場合はその面積を最小化したい。
売り場を持つ業者は相当な数になるので、それらが少量ずつ荷物を持ち込んだら忽ち渋滞だ。
そこでデパートの流通センターか搬入代行業者の倉庫に搬入して、そこからまとめてトラックに混載してデパートに搬入するという形になっている。
当然その業者には委託料を支払わねばならない。だから利幅が小さくなるのでその分価格を上乗せする他無い。故にデパートで買うとどうしても高いのだな。
これはデパ地下の小さな食品売り場、レストラン街の業者もそうなので、地方の業者が東京などのデパートに出店する場合、支社をその代行業者の倉庫内に置いてしまう事もよくある。
「東京支社長就任おめでとう」とか言われて辞令を受け取ったら倉庫勤務とかになっちゃうわけだ。つらい。
