はてなキーワード: コンテナとは
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的な仕事もしたりする、相変わらず深夜対応もある、辛い…
年1回、必ず新機能が出てくるので定期的に技術をキャッチアップ出来る必要がある。
国内に限定すると技術スキルは高めの人が多い傾向が見えるが人間としては癖の強い人が多い傾向も見える。
(ちなみに少ない観測範囲だが海外勢は微妙な技術レベルの人間が多かった。)
給与レンジはピンのほうはそんなに高くないがキリのほうはそこまで低くない。
ここ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
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主に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線地下を通っていた、京王マークシティの方にあった、二つの可能性がある。
開業当初は国鉄より頭の固い鉄道省と別会社の帝都電鉄だった訳で気になるのだが…ちゃんと見ておきたかった。
これらには公共地である道路を潜って離れた場所に繋いでいるケースが多い。
普通はこういう占有方法は認められないが、施設の公衆性が強い場合は許されるのである。私鉄が道路地下を走っていたり病院の渡り廊下が道路跨いでたりと同じだ。
デパートの場合の公衆性は、公衆が自由に立ち入り出来て買い物ができる、市場の性格がある事だ。だからデパートは会員制の立ち入り規制的な事が出来ない。
余談だが、中野ブロードウェイのまんだらけが性的な商品を通路側に陳列して対面の商店とトラブル、その商店をネット民が攻撃して炎上するというトラブルがあった。
この時にネット民は中野ブロードウェイは私有施設だから陳列は自由、まんだらけの占有面積は大きいので施設運用でのヘゲモニーがある、というような考えを開陳する人が多く居た。
でもこの法的スキームを知っていたらこの考えは間違いという事が判る。中野ブロードウェイは公衆施設の一種でありそれは立ち入りが自由である事だから、そこの通路は公道が準用される。
そこに性的な陳列をしたら独立店舗の中での陳列よりも厳しい基準で取締りが行われるのは当然なのだ。実際まんだらけはガサ入れされて商品を押収されて件の店舗は後に閉鎖する事になった。
また、デパートは売店床面積を最大化したいのでこういう離れた箇所に搬入口を作るのである。だからビル裏に搬入口を作る場合はその面積を最小化したい。
売り場を持つ業者は相当な数になるので、それらが少量ずつ荷物を持ち込んだら忽ち渋滞だ。
そこでデパートの流通センターか搬入代行業者の倉庫に搬入して、そこからまとめてトラックに混載してデパートに搬入するという形になっている。
当然その業者には委託料を支払わねばならない。だから利幅が小さくなるのでその分価格を上乗せする他無い。故にデパートで買うとどうしても高いのだな。
これはデパ地下の小さな食品売り場、レストラン街の業者もそうなので、地方の業者が東京などのデパートに出店する場合、支社をその代行業者の倉庫内に置いてしまう事もよくある。
「東京支社長就任おめでとう」とか言われて辞令を受け取ったら倉庫勤務とかになっちゃうわけだ。つらい。
陳建一さんが亡くなったと聞いてマジ悲しかったんだが、同時におなかが空いてきて刷り込みってやばいなって思った。俺の脳内で 陳建一=メシ と言う回路ができているようだ。
と言う事で、これからしばらくは陳建一レシピで生きてくことにする。
そこで俺の「みんなの今日の料理」のお気に入りから、3つ紹介したい。
たくさんアドレスを貼るとエラーになるんで、ゆで豚から追ってくれ
https://www.kyounoryouri.jp/recipe/13276_%E3%82%86%E3%81%A7%E8%B1%9A.html
かたまり肉を使ったレシピ。ゆで豚で作っておくと、その後何にでも使えるほか、このゆで豚を使ったスープが激うま。
そしてここまでできてしまえ回鍋肉はできたようなもん。豆板醤も甜麺醤も両方使うレシピでそこがハードル高いような気がするかもしれないが、こいつらが入っていれば味が決まる。
このレシピ無茶苦茶タイパがいい。一見作るのが大変に見えるが、実は待ち時間が殆どなんで他の家事しながら楽勝でできる。
でもできあがりを見るとそうは見えないだろ?
凄く手間をかけたように見えるのがよい。量も作れるのでパーティー料理に最適。
ハレの時と、かたまり肉が安い時しか作れないので登場頻度は多くないが、最もお気に入り。
これをかけると大抵なんでもうまくなるという魔法のたれ。肉そぼろ系の味付けだが、そこに中華スープと水溶き片栗粉でとろみをつけてあるのがポイントだと思う。
季節の野菜を適当に焼いてかけて喰う。うまい。常備食。隔週で作ってる。いつもジップロックコンテナに入ってる。いつの間にかなくなる。
ど定番チンジャオロースーだが、結構レシピで差があるよな。いくつか作ってるが、この陳建一レシピーが失敗が少ないので戻ってきた。
レシピでは牛肉等買うが、高いのでいつも豚肉で作っている。このポイントはたぶん肉の処理で、下味をつけた後、溶き卵をと油を馴染ませる所にあって、これだと安い豚切り落としでもおいしくできる。
もうひとつ「しょうゆ味で」とつく方があるけどこっちの方が失敗しにくい。ピーマンが山ほど採れる季節は2日に1回は作る。
https://www.kyounoryouri.jp/teacher/recipe/140
是非ここからみなさん探してください。
お目にかかるどころか店にも言ったことが無いが、陳建一さんどうもありがとうございました。
(2023/03/15 最低限の誤字脱字を直しました)
ざっくりまとめてみました。
1話で、学園でスレッタと再会したミオリネは、ぼんやりしてMSに踏み潰されそうになったスレッタの手を引いて走ります。
更には、トマトを見たことがないスレッタのためにトマトをプレゼント。なんだかんだ言ってスレッタをよく見て対応するミオリネの優しさが垣間見えるシーンでした。
「よろしくね、花婿さん」の時は、MS持ってる手駒(友達)ゲット!くらいのつもりだったと思うんです。
というか、「よろしくね、花婿さん」は同性愛OKの社会を知らない田舎者をおちょくっての発言じゃなかろうかと。
2話でスレッタの「進めば二つ」を思い返し、審問会に乗り込んで「決闘で勝ったのはスレッタよ!」と発言したのは、スレッタ強制退学&自分も退学して別の男と結婚させられる理不尽に対しての怒りで、ここではまだスレッタに対する気持ちは同じ理不尽を被った仲間意識だったと思います。
3話の「一緒に戦う流れでしょう!」であんた責任取るって言ったでしょ!!+「これは取引よ」でスレッタにプレッシャーをかける作戦。
スレッタの「私たち親友~」からの「はぁ?」は親友じゃなくて婚約者でしょ! とアピールしたかったのではないでしょうか。
そのあとのエラン登場→連絡先交換で、ここでようやくスレッタを意識したんじゃないかなぁと。私の手駒(友達)が取られちゃう!ってな感じ。
いつの間にかミオリネの連絡先がスレッタの端末に登録されている……これ、いつやったんだろう?
さらにグエルのプロポーズによる追い撃ちで、「どいつもこいつも私の花婿に手を出しやがって!」と内心でキレて、恋愛ルート確定、かと。
4話の「自覚持ちなさい。あんたはホルダーで私の花婿なんだから」は、3話の影響から出てる言葉だと思います。この時のミオリネの表情が「意味わかってるわよね? あんたは私の特別なのよ」って念押ししてるように見えます。
エランの「じゃあ、うちの寮来る?」の台詞のあとにコツコツとヒールの音がして「ダメ!」って叫んでますが、ミオリネは走ってもいないし、息も切れていません。ましてやスレッタの座り込んでた場所がどうもペイル寮の前に見えるので、ミオリネはスレッタの居場所が最初からわかってたようです。1話の学園マップインストールか、3話の勝手に連絡先交換の時点でスレッタの携帯端末に何かやばいアプリ仕込んでませんか?
「だったら私を頼んなさいよ」で、スレッタに頼られたいと思っているのが発覚。ミオリネの愛の重さが少しだけ垣間見えて来たかも。
実習がうまくいかなくて泣くスレッタに「立て!」と喝を入れるのは、恋じゃなくて母親の愛に近いかもしれません。
5話。スペーシアンなのにしれっと地球寮にいます。スレッタにくっついて入り込むようになったんでしょう。周りの人間も止めてないので4話のケンカ仲裁で打ち解けたかな?
スレッタとエランのデートの話をどこかから聞き付けて、ちゃんとノーマルスーツ着込んで電動スクーター乗ってMSコンテナエリア?に登場。冷静なのか頭に血が上ってるのかよくわかりません。
「ロミジュリったら許さないから!」で嫉妬の炎を燃やしてるけどスレッタには届いてない、というかこの時点ではスレッタにまだ怖がられてるような。
6話。当たり前のように地球寮にいるミオリネ。しかも女子部屋。ミオリネに相談無しにスレッタが決闘を受けたことについて怒ります。まあ自分の人生かかってるから当たり前だけど、どっちかっていうと「どうして私に一言言ってくれないの?」っていうヤキモチが強いんじゃないかと。
カリカリしててもスレッタと仲良くなれないから「進めば二つなんでしょ?」で方針変更。「あいつが負けたら花嫁の私が困るの」などと照れ隠しもしているあたり、相当スレッタのことが気になってるんでしょうね。まさにツンデレ。
決闘当日の「ほんと、鬱陶しい奴」は”でもそこがいい”んでしょう。スレッタ勝利後はすごいどや顔を披露してました。
スレッタとエランの宇宙でランデブーには「私は理解ある花嫁なの。多少の浮気くらい許してあげるわ」本音というか、スレッタが喜ぶ選択をしてあげたいという健気な姿勢&あくまでも自分が正妻ですよ、と全力アピール。
スレッタとエランとのデートの待ち合わせに5分前まで付き合ってくれるミオリネ。「門限、守んなさいよ」は門限破るような行為……例えばエ○いこととかをするなよ、っていう念押し。ここで背中を見せるんですが、ひょっとして泣いてるんじゃないかと。ミオリネはスレッタに泣き顔を見せないのがポリシー(11話より)らしいので。
7話。「誰かのことで頭がいっぱいになったりしないのか」と問い掛けるスレッタに喰い気味で「ない」と答えるミオリネ。その直後にスレッタの心配をしてるから、説得力0です。
インキュベーションパーティにエランが来るかもしれないと聞いて、出席を希望したであろうスレッタに付き合うミオリネ。自分のドレスを貸してあげる……のはいいけど、きついのは胸だけかよスレッタ!
何度でも言いますけど、この二人は花婿と花嫁であっても、このパーティでスレッタにティアラ(男ならクラウンだけど、スレッタは女性なので)をつけさせる必要はないし、自分もハンドコサージュする必要はないんですよ。だってミオリネはベネリットグループ内で有名なんですから。これ、絶対エランに対する当てこすりが入ってますよね。
吊るし上げられたスレッタを助けるために即興でプレゼンして会社を立ち上げ、「守るわよ、私があんたを」でヒールを脱ぎ捨て嫌いな父に頭を下げました。ここでミオリネの愛情メーターが一気に振り切れたというか、ものすごく愛が重くなったといいますか。
このミオリネを見て、スレッタは「ミオリネさんは優しい人、信頼できる人。ミオリネさん好き(Like)」になったんだと思います。
8話。二人で株式会社ガンダムの看板作り。体操服や顔にペンキが付いているのは、スレッタの手元が狂ってミオリネにペンキが付く→ミオリネがやり返した、かな? スレッタの名言「うちのミオリネさんがごめんなさい」で、スレッタがミオリネに相当懐いたのが伺えます。
ミオリネは勝手に地球寮のメンバーを会社に入れてしまいますが、方針決めで衝突。スレッタの「皆一緒じゃないと」の意見を聞き入れ、会社方針の方向性を考えるようになります。
2週間ぶりに会ったスレッタがミオリネに抱き着こうとして顎を押さえられるのは、7話の後から8話の間にこのやり取りを相当回数繰り返しているんじゃないでしょうか。妙にミオリネが手慣れていますし。
夜の二人乗りデートでは、ミオリネがスレッタに見えないところで「ばーか。遊びじゃないんだから」と柔らかい表情でスレッタの背中に頭をこつんとしています。二人きりの時はイチャイチャしてるのか!
この回は最後のメールを受けとる瞬間まで、ミオリネが不機嫌な顔をしてないんですよね。エランがいないから?
9話。スレッタを茶坊主に、シャディクと対面するミオリネ。この回はシャディクとミオリネを軸に動いてるので、むしろスレッタのミオリネへの想いが垣間見える回でもあります。「花婿ならお嫁さんを信じます」とか、シャディクに対して「ミオリネさんのこと好きじゃないんですか?」とかましたりと、スレッタのミオリネへのボルテージが上がっていきます。
10話。ミオリネの大事な温室を任されて喜ぶスレッタと、仕方ないから頼む(本当はスレッタに負担をかけたくない)ミオリネの対比が素晴らしい。信頼された、任された、頑張らなくちゃ!と張り切るスレッタに対して、ミオリネが余りにも忙しくなりすぎ&言葉足らずのミオリネの悪い面が出てすれ違い発生。
エラン、の単語がスレッタの口から出て、ミオリネがつま先トントン(苛立ちの表現)を見せているので、本音ではスレッタにはエランと関わりを持ってほしくないんだなぁ、とわかるシーン。
11話。牛達の間に隠れたスレッタを見て、ほんの一瞬悲しそうな表情を見せるミオリネ。あんなに鬱陶しいくらい自分に構ってきたのに何故隠れようとするの? って思ってるんでしょうね。
トイレでスレッタの泣き言を聞いて追いかけっこ開始。同性同士じゃないとトイレで立ち聞きイベントはできないので、すごい解決策だな、と。
ミオリネを突き飛ばして離れようとしたスレッタに対して、とうとうミオリネがスレッタに抱き着いて「ずっとそばにいて」発言&ぎゅっと抱きしめイベント。ここでスレッタの瞳にハイライトが入ったので、スレッタのミオリネに対する「好き(LIke)」が「好き(Love)」に変わったんだろうな、と予想します。
花婿からダサいキーホルダーのプレゼント……は、婚約指輪ってことですよね?
12話。ミオリネを助けるべくエアリアルの元へ向かうスレッタと、隔壁の反対側に閉じ込められたスレッタを助けるべくコントロールセンターを目指すミオリネ。お互いを想いながら行動して、いよいよバディに、と思いきやミオリネは父デリングと遭遇。ミオリネをかばって倒れたデリングを何とかすべく……これ、救援信号を出すためにコントロールセンターに向かってます?
一方のスレッタはプロスペラに暗示をかけられ、殺人に対する恐怖がなくなってしまいます。殺人に対する忌避感をなくした&ミオリネと心が通じた高揚感のままミオリネを発見したスレッタは、エアリアルの掌でテロリストを殺害。カッコつけてミオリネの前に現れたけど、当のミオリネからは「人殺し」と拒否されます。
増田を全削除するのであればPower Automation DesktopかSelenium IDEあたりでも使えば可能ですが、中にはブクマを集めた珠玉の増田やブクマは付かなくても割と気に入ってる増田もあるので全削除はしたくありませんでした。
Masuda Deleter
https://github.com/oribeolive/masuda-deleter/
Masuda DeleterはDockerコンテナに環境を作って動くのでDockerが必要です。
M1 Macで動作していますがWindowsは検証できるマシンが手元にないので動作未確認です。
インストールはGitHubのREADMEに書かれたコマンドを実行すればできると思います。
Masuda Deleterははてラボにログインして指定されたページ分の自分の増田の投稿をスクレイピングしてローカルのDBに保存します。
取得された投稿のリストがブラウザで見られるので、そこで削除するものを選んで実行すると、またログインして投稿を削除しにいきます。
ページのアクセスごとに読み込みと遠慮のために1秒から数秒sleepするので少し時間がかかります。
一旦投稿をローカルに保存するという過程があるため副作用として自分の投稿を検索できます。
これにより
が容易になります。
増田にはAPIがないので、IDとパスワードを使ってログインして、表示されている文章をスクレイピングしてくるという原始的なやり方になります。
(2回目からはcookieがある場合はcookieを復元してログイン状態になります。)
ユーザーが知らない外部サイトにクレデンシャルを渡すのは危険であり、サービス運営側としてもパスワードを平文で持ちたくないので、Webサービスとして実装せずセルフサービスとしております。
ユーザーによってローカルの.envファイルに書かれたIDとパスワードを使用する形です。
ソースをオープンしておりますので怪しいことをしていないかも確認ができるかと思います。
一応下にプログレスバーが出ますが、ページ遷移すると見られなくなります。進捗は進捗管理でも確認できます。
取得された投稿はリアルタイムで画面に反映されないのでブラウザをリロードしてください。
増田のID、タイトル、本文の省略、投稿日時、ブクマ数、トラバ数が表示されます。
「あとで消す」投稿をチェックし、「あとで消す」記事をついに消すボタンで削除を実行します。
チェックは別のページに遷移しても有効です。
こちらは実行した時点で表示されているページのみリアルタイムに画面に反映されます。
投稿の全文を見られます。タグ等は取得しないのでテキストのみになります。
投稿を個別に取得してローカルの文章とブクマ数とトラバ数を更新します。
対象の投稿のタイトルを空に、本文をスペース1文字にしにいきます。
処理の進捗(何件中何件処理済みか)を見ることと、処理を停止させることができます。
排他処理(取込と取込、特定IDの削除と同じIDの削除等)にしているので動いていなそうな処理を停止して再度処理を実行するときに使います。
停止する場合は停止ボタンを押すか、それでも停止しそうにない場合は強制停止ボタンを押してください。
「停止」は今行っている最中の処理ではなく次以降の処理を停止するという形になります。
停止ボタンを押したときに4ページ目を取得している場合は、5ページ目の取得を始める前に処理を終了することになります。
そのためプロセスそのものが止まっている場合は停止されません。
「強制停止」はプロセスをkillします。スクリプト名とプロセスIDでプロセスを検索して子プロセスも含めてkillします。
おまけとして、投稿日とブクマ数、投稿日と3ブクマ以上の投稿の件数、投稿時間(hour)ごとの1ブクマ以上の投稿の件数のグラフが見られます。
ブクマが付いた瞬間ではなく投稿日時なので、いつの時期に投稿した、何時に投稿した増田が活きが良いのかを見られる程度です。
集計データを別に持っていないので増田を削除するとグラフに使用されるデータも消えます。
私はこれで多いときには4000件程度あった増田を3000件程度に減らしました。
これを開発する前からも増え続ける増田の削除に日々勤しんでいたので総数はもっと多いはず。
まだまだ削除したいです。
たまに
Message: unknown error: net::ERR_CONNECTION_CLOSED
というSeleniumのエラーが出て処理が実行されないことがあります。再度実行してください。
フロントエンドがレガシーなのでMasuda Deleterの開発に飽きていなければもう少しモダンにリプレースしようと思っています。
使用していないDjango REST frameworkがrequirements.txtに入っているのはその名残です。