  |
はてなキーワード: コンテナとは
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 最低限の誤字脱字を直しました）
ざっくりまとめてみました。
１話で、学園でスレッタと再会したミオリネは、ぼんやりしてMSに踏み潰されそうになったスレッタの手を引いて走ります。
更には、トマトを見たことがないスレッタのためにトマトをプレゼント。なんだかんだ言ってスレッタをよく見て対応するミオリネの優しさが垣間見えるシーンでした。
「よろしくね、花婿さん」の時は、MS持ってる手駒（友達）ゲット！くらいのつもりだったと思うんです。
というか、「よろしくね、花婿さん」は同性愛OKの社会を知らない田舎者をおちょくっての発言じゃなかろうかと。
２話でスレッタの「進めば二つ」を思い返し、審問会に乗り込んで「決闘で勝ったのはスレッタよ！」と発言したのは、スレッタ強制退学＆自分も退学して別の男と結婚させられる理不尽に対しての怒りで、ここではまだスレッタに対する気持ちは同じ理不尽を被った仲間意識だったと思います。
３話の「一緒に戦う流れでしょう！」であんた責任取るって言ったでしょ！！＋「これは取引よ」でスレッタにプレッシャーをかける作戦。
スレッタの「私たち親友～」からの「はぁ？」は親友じゃなくて婚約者でしょ！ とアピールしたかったのではないでしょうか。
そのあとのエラン登場→連絡先交換で、ここでようやくスレッタを意識したんじゃないかなぁと。私の手駒（友達）が取られちゃう！ってな感じ。
いつの間にかミオリネの連絡先がスレッタの端末に登録されている……これ、いつやったんだろう？
さらにグエルのプロポーズによる追い撃ちで、「どいつもこいつも私の花婿に手を出しやがって！」と内心でキレて、恋愛ルート確定、かと。
４話の「自覚持ちなさい。あんたはホルダーで私の花婿なんだから」は、３話の影響から出てる言葉だと思います。この時のミオリネの表情が「意味わかってるわよね？ あんたは私の特別なのよ」って念押ししてるように見えます。
エランの「じゃあ、うちの寮来る？」の台詞のあとにコツコツとヒールの音がして「ダメ！」って叫んでますが、ミオリネは走ってもいないし、息も切れていません。ましてやスレッタの座り込んでた場所がどうもペイル寮の前に見えるので、ミオリネはスレッタの居場所が最初からわかってたようです。１話の学園マップインストールか、３話の勝手に連絡先交換の時点でスレッタの携帯端末に何かやばいアプリ仕込んでませんか？
「だったら私を頼んなさいよ」で、スレッタに頼られたいと思っているのが発覚。ミオリネの愛の重さが少しだけ垣間見えて来たかも。
実習がうまくいかなくて泣くスレッタに「立て！」と喝を入れるのは、恋じゃなくて母親の愛に近いかもしれません。
５話。スペーシアンなのにしれっと地球寮にいます。スレッタにくっついて入り込むようになったんでしょう。周りの人間も止めてないので４話のケンカ仲裁で打ち解けたかな？
スレッタとエランのデートの話をどこかから聞き付けて、ちゃんとノーマルスーツ着込んで電動スクーター乗ってMSコンテナエリア？に登場。冷静なのか頭に血が上ってるのかよくわかりません。
「ロミジュリったら許さないから！」で嫉妬の炎を燃やしてるけどスレッタには届いてない、というかこの時点ではスレッタにまだ怖がられてるような。
６話。当たり前のように地球寮にいるミオリネ。しかも女子部屋。ミオリネに相談無しにスレッタが決闘を受けたことについて怒ります。まあ自分の人生かかってるから当たり前だけど、どっちかっていうと「どうして私に一言言ってくれないの？」っていうヤキモチが強いんじゃないかと。
カリカリしててもスレッタと仲良くなれないから「進めば二つなんでしょ？」で方針変更。「あいつが負けたら花嫁の私が困るの」などと照れ隠しもしているあたり、相当スレッタのことが気になってるんでしょうね。まさにツンデレ。
決闘当日の「ほんと、鬱陶しい奴」は”でもそこがいい”んでしょう。スレッタ勝利後はすごいどや顔を披露してました。
スレッタとエランの宇宙でランデブーには「私は理解ある花嫁なの。多少の浮気くらい許してあげるわ」本音というか、スレッタが喜ぶ選択をしてあげたいという健気な姿勢＆あくまでも自分が正妻ですよ、と全力アピール。
スレッタとエランとのデートの待ち合わせに５分前まで付き合ってくれるミオリネ。「門限、守んなさいよ」は門限破るような行為……例えばエ○いこととかをするなよ、っていう念押し。ここで背中を見せるんですが、ひょっとして泣いてるんじゃないかと。ミオリネはスレッタに泣き顔を見せないのがポリシー（11話より）らしいので。
７話。「誰かのことで頭がいっぱいになったりしないのか」と問い掛けるスレッタに喰い気味で「ない」と答えるミオリネ。その直後にスレッタの心配をしてるから、説得力０です。
インキュベーションパーティにエランが来るかもしれないと聞いて、出席を希望したであろうスレッタに付き合うミオリネ。自分のドレスを貸してあげる……のはいいけど、きついのは胸だけかよスレッタ！
何度でも言いますけど、この二人は花婿と花嫁であっても、このパーティでスレッタにティアラ（男ならクラウンだけど、スレッタは女性なので）をつけさせる必要はないし、自分もハンドコサージュする必要はないんですよ。だってミオリネはベネリットグループ内で有名なんですから。これ、絶対エランに対する当てこすりが入ってますよね。
吊るし上げられたスレッタを助けるために即興でプレゼンして会社を立ち上げ、「守るわよ、私があんたを」でヒールを脱ぎ捨て嫌いな父に頭を下げました。ここでミオリネの愛情メーターが一気に振り切れたというか、ものすごく愛が重くなったといいますか。
このミオリネを見て、スレッタは「ミオリネさんは優しい人、信頼できる人。ミオリネさん好き(Like)」になったんだと思います。
８話。二人で株式会社ガンダムの看板作り。体操服や顔にペンキが付いているのは、スレッタの手元が狂ってミオリネにペンキが付く→ミオリネがやり返した、かな？ スレッタの名言「うちのミオリネさんがごめんなさい」で、スレッタがミオリネに相当懐いたのが伺えます。
ミオリネは勝手に地球寮のメンバーを会社に入れてしまいますが、方針決めで衝突。スレッタの「皆一緒じゃないと」の意見を聞き入れ、会社方針の方向性を考えるようになります。
２週間ぶりに会ったスレッタがミオリネに抱き着こうとして顎を押さえられるのは、７話の後から８話の間にこのやり取りを相当回数繰り返しているんじゃないでしょうか。妙にミオリネが手慣れていますし。
夜の二人乗りデートでは、ミオリネがスレッタに見えないところで「ばーか。遊びじゃないんだから」と柔らかい表情でスレッタの背中に頭をこつんとしています。二人きりの時はイチャイチャしてるのか！
この回は最後のメールを受けとる瞬間まで、ミオリネが不機嫌な顔をしてないんですよね。エランがいないから？
９話。スレッタを茶坊主に、シャディクと対面するミオリネ。この回はシャディクとミオリネを軸に動いてるので、むしろスレッタのミオリネへの想いが垣間見える回でもあります。「花婿ならお嫁さんを信じます」とか、シャディクに対して「ミオリネさんのこと好きじゃないんですか？」とかましたりと、スレッタのミオリネへのボルテージが上がっていきます。
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に入っているのはその名残です。
コンピュータサイエンス、アルゴリズムにしろOSにしろ「作って証明」的な側面があるから発展しやすいんだろうな
OSSで代表されるように、技術はある程度オープンなのでそれも発展を後押ししてる
どっかの老害が「IT系は声がデカイ！」とか言ってるの見たけど、むしろ老害こそOSS文化を学んでも良いのではと思う
老害がどっかのマネージャーなのかしらんけど「コンテナ！」「Python！」とか表面的な言葉だけピックアップして腹立ててるんじゃどうしようもねぇよな
老害はITを価値のない仕事だと思い込んでるらしいが、技術発展がマクロ的に見て生産性を上げるってことは統計出てる (コブ・ダグラス型生産関数ってモデルがあることぐらいは老害も知ってるだろうけど、技術発展などに依存する項目が関数にはある)
http://www2.toyo.ac.jp/~mihira/keizaitoukei2014/08_production/08_production_slides.pdf
技術者は意味もなくコンテナを使ってるのではない可能性が高い。
老害の部下は、おそらくAWSとかの兼ね合いでマイクロサービスを運用するのが良いと判断した可能性があるし、嫌いな「声のデカさ」でマイクロサービスってこんな利点があるんですよと世界中で共有してるので利点は把握してる。
https://stackoverflow.com/questions/34903605/microservices-what-are-pros-and-cons
老害は基本的に政治屋だから技術者の会話を見てデタラメに言葉をチョイスしているだけに見えるのかもしれないね。
技術者は老害が思っているよりもちゃんと意味のある言葉の使い方をしてるよ。
あるいは生産性向上そのものも無意味だと認めて、世の中の大部分の仕事が無意味だと悟って老害の会社を畳んでも良いんじゃないかな。
https://twitter.com/ojimakohei/status/1603955048752746502
「colaboの件。所管の福祉保健局としては、直ちに契約要件に抵触するものではないが、一部、不適切な処理が認められ、指導を行ったとのこと。住民監査請求も出ているので、この後は独立機関「監査委員会」にて本格的な調査が行われます。また、国の「会計検査院」の検査も入ります。また経過報告します。」
「監査委員会」って書いてあるけど、「監査委員」ですね。都議であるなら、同じ都議が監査委員になっているわけだから、ここを間違うのはツイートの全体的な信頼性を疑います。監査委員のお一人は議員と同じ党ですね。
https://www.kansa.metro.tokyo.lg.jp/kansazimukyoku/index.html
「監査委員は独任制の機関です。これは、それぞれの監査委員が独立して職権を行使する、ということを意味します。教育委員会や選挙管理委員会や人事委員会といったほかの行政委員会と違って、委員会制をとっていないため、監査委員を対外的に代表する委員長もいません。」
会計検査院は国の機関で、国のお金の使い方を検査する（必要的検査対象）機関ではありますが、国は地方（もちろん東京都を含む）にお金を出すことが多いので、その使い方がどうだったかという視点で、地方自治体も検査をしています（選択的検査対象）。議員が後に「会計検査」について「定期的」と触れたのは、多分地方公務員の会計検査についての認識そのままで、選択的検査対象が地方自治体に対して定期的に行われていることを指していると思われます。感覚的には２年に１回とかかな。どの自治体に入るとかどの事業を検査するとかは事前に公表されていなくて、大まかな流れだけが通知されて、直前にこの自治体のこの事業を検査します、となる。
地方公務員として生きる上で、避けたくても避けられないのが会計検査です。国庫補助金を受ける時は必ず「会計検査、当たりませんように！」と思いながら、当たったときのために保存する書類を整備する。会計監査があるおかげで、地方自治体の仕事はキッチリしていると言っても過言ではない。
では、地方自治体が会計監査を受けるときの実際はどんなものか。まず、諜報がすごい地方自治体全てが一体となって、「どこの都道府県でどんな検査があったか」を必要な地方自治体で共有します。会計検査員が今どこにいて、どこに向かっているかを共有します。今日の検査で何を聞かれたかを共有します。何を聞かれたかを知った時、次の地方自治体では同一事業や類似事業で同じことを聞かれてもいいように想定回答を考えます。会計検査では「会計」という名前のイメージとは違って、「この事業はどんな目的で行われ、どんな効果を出しているか」という費用対効果を重視して検査されます。これは検査結果を発表する時に、枝葉末節を見ているのではなく、ある程度やってるアピールができるように、ということもあるのではないかと想像します。そういった意味では、直近ではコロナ交付金が記憶に新しい。
https://www.jbaudit.go.jp/pr/kensa/result/4/r041017.html
「地方公共団体が実施した個々の交付対象事業の効果検証と検証結果の公表がどのように行われているかなどに着眼して検査しました。」
このように、どんな効果があったか、またその効果をどう検証しているか、が重視されている。
地方公務員の一大イベント、会計検査について、全く意識せずに仕事をしている職員は、採用歴が浅い職員を除いてほぼいない。会計検査が入れば全庁に対して「会計検査中はこのフロアで私語厳禁」というお触れが出たり、紙資料をコンテナ何杯も会場に持ち込んだりする。何かの形でこれを目にする地方公務員にとっては、いくつかあるお祭りの一つといっていい。
それに対して、「情報提供を受けての会計検査」というのがどのように行われるか、多くの地方公務員は知らないと思われる。あくまで選択的検査対象として、一連の流れで検査されるということであるなら、情報提供された１件のみについて特出しで行われるということはないのかもしれない。通常、検査の対象は社会的に話題となる事業（コロナ交付金のように）が多いと思われるが、もちろんどのように選ばれているかは地方公務員は知り得ない。
マツコ有吉かりそめ天国にて「ガントリークレーンの操縦士」の話をしていた
自分は海の近くに住んでいるが、そういうクレーンを意識して見たことが無い
日本海側だとあまりコンテナ無いとか…ってことは無いよなあ。大きな船は接岸しているし積み荷の上げ下ろしもあると思う
それにしても、ガントリークレーン操縦士。通称ガンマン。奥が深い仕事だなあ
https://www.nhk.or.jp/professional/2015/0223/index.html
まさにプロフェッショナル
ちょっとアレに似てる
空港で積荷の重さ出してどれくらい積めるかとか指示する人の仕事に
どっちも胃が荒れそうな仕事だな
世の中には物凄い仕事してる人たちが沢山居る
それに引き換え自分は…
おじいさんやおばあさんのうんこをふくしごとだ
生産性皆無なところが凄いよな
わらう
やめたい
