  |
はてなキーワード: Ciとは
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
https://anond.hatelabo.jp/20230102104156
私も売上…じゃなくて見てくれる人が相当減ったのでコミケは100を最後の出展とした。
（売上というと、同人は売上じゃねーガーがやってくるので、見てもらえる人が減ったという言い方にしておこう。）
で、そんな中、頒布数を落としつつも健闘している知人のサークルをみていて
いくつか生き残るためのヒントがあると思ったのでメモがてら記しておく。
当該サークルは神絵師でもエロでもないが、男性向けジャンルとしては健闘している方だと思う。
会いに行ける絵師じゃないけど、購入者が接しやすそうな女子がサークル主or売り子でいるとよい。
これは、(3)の欲求を駆り立てさせるための駆動条件として必要。
ルッキズムガーとかなんとかいっても、現実はそんなもんである。
ただし、かわいすぎると高嶺の花と思われてしまうのか距離がうまれてしまうので、そこそこ感が大切。
(2)ファンサをしっかりと行う。
FANBOXやCi-enなどで囲い込みをしておくとGood.
作家を推すためのコミュニティを作り込み、新刊などを手にいれることで地位があがっているかのように見せかける。
インプレッション数が表示されるようになったTwitterはイキリマシーンとして非常に優れているので
承認欲求を駆り立てる行為がしかけやすい。どれだけ推しているか、ファン同士の競争が生まれると強い。
気をつけなければいけないのが、(1)(2)(3)とも、ファンであるときはよいのだが、なにかのきっかけで
YouTuberを始めるにあたって昨日今日と環境構築をしている。
動画のジャンルは内緒として、ひたすら効率良く動画を作ることを志向してる。理想は新規のMarkdownファイルがGitHubのmainブランチにマージされたら自動でYouTubeの自分のチャンネルに動画が投稿される、みたいな状態。
まあそこまでやるのは調べるの大変だし事故とかbanが怖いしまずYouTuberとして大成しないことにはって話なので、どっかで妥協すると思う。てかCI/CD周りちゃんと仕事でやっとけばよかったな。
テキスト読み上げで商用利用するなら今はVOICEVOXが良いのかなと感じた。
ただ、作成した音声に合わせた字幕ファイルを作るのがひたすら面倒くさい。絶対自動出力できそうなのに。
VOICEVOXから直で出してくれたら楽だったんだけど、リップシンク用のファイル出力しか対応してなかった（どっかでやってる人がいるかもしれない）。
VOICEVOX公式のGitHubでissue上げることも考えたけど、俺自身がまだ動画一つも上げてないし、字幕ファイルの需要がどれほどのものかも分からないので、とりあえず変換用のスクリプトを自分で書いてみた。
VOICEVOXのプロジェクトファイルであるvvprojファイルの中身はバイナリではなくただのJSONなので、エディタやエンジンのソースコードを弄らなくても、比較的簡単に字幕ファイルに変換できる。なお今回俺はDenoを使った。
こういうシェルスクリプトみたいな小さい仕事やるのにDenoはまじで楽。
あとは動画作るときに需要ありそうだなと感じたら、SubViewer以外のマークアップに対応させてissue上げるなり俺のrepoに置いとくなりしようかな。
エンジンの実態はhttpサーバーらしいので、上手くやれば意外と労力かけずに理想に近い自動化が実現できるかもしれない。
○ご飯
朝：バナナ。昼：かいわれ大根、ピーマン、焼きそば。ベーコンエッグ。トマトとチーズ。夜：キャベツとウインナーのスープ。パン。
○調子
クリア。
20年以上前のゲームなのに、オシャレで格好いいイケてる雰囲気が凄かった。
私立探偵の小次郎パートと、エージェントのまりなパートで全く異なる二つの事件を捜査する。
捜査の過程で街を探索するのだが、情報屋とのやりとりや、聞き込みなどのシーンが洒落ててたり、ゲラゲラ笑えたりと個性豊かで楽しい。
絵で表現しきれない箇所はバッサリ黒塗り背景に文章だけで表現するのも潔いし、何よりそのテキストが面白いのだから一切問題なし。
ホテルのバーや海沿いの倉庫など、登場する場すら格好よく感じてくる。
軽妙なやり取りもあれば衒学的な部分もありで、兎に角事件捜査を楽しめる。
二人主人公制は最初のうちは時折登場人物が重なる程度なんだけど、徐々にそれらが一本に繋がっていくところが快感。
特に二人の主人公が互いを知らずにコンピュータ回線越しに事件捜査のために協力するシーンはただCIのコンソールに文字が出るだけも演出なのに、熱く燃える今作屈指の名シーンだろう。
この互いが互いをあまり知らずに事件捜査のために協力するという関係性も、格好いい。
普段はだらしないけどやる時はやるタイプの主人公が拳銃片手に非合法組織と戦いながら夜の街を駆ける、そんな創作物テンプレート自体が根本的に格好いい…… と言ってしまえばそれだけなのかもだけど、もうこれは冴羽獠をDNAに植え付けられた僕たちの宿命なのかもしれないなあ。
そんな感じで、事件を捜査する過程については百点満点文句なしの出来。
だけど、物語の終盤はかなり駆け足気味かつ、しっくりこない終わり方だった。
突然現れる現実を超越した科学技術に、二人の主人公は蚊帳の外で自体が進行し、犯人が突然恋愛をはじめる展開、そして自白で幕をおろす。
最終章までの丁寧な展開、格好いい展開はどこへやらで、正直肩透かし。
犯人の自白と、とあるキーパーソンの独白だけで最終盤は進むため、二人の主人公がそれらにどう感じたのかどんな行動を取ったのかが一ミリもわからないのは流石にガッカリ。
何より「犯人の自白」とは書いたが、とあるSFガジェットにより厳密には正しい言い回しではなく、真の意味での犯人はおそらく作中でセリフが全く無いという構造も、流石にちょっと終わった感じがしなかった。
とはいえ、謎解きのロジックや、あっと驚くサプライズなトリックを楽しむ作品ではなく、事件捜査の過程の格好良さを楽しみ作品だと割り切れば文句なし。
なお、柴田茜というルポライターの女性が「僕っ子」なのは、流石に当時でもコテコテでやりすぎなのでは？ と思っていたが、かないみか氏の演技力のおかげですぐ違和感がなくなった、声優ってすごい。
原作がアダルトゲームなこともあり、明らかに情事を意図するシーンや、明らかに元はエッチなことされたけど違うことに置き換えたシーンなどが多くあり、元もプレイしたくなった。
また、銃を突きつけた状態で自由を奪うために服を脱がすというシーンが3回ほどあって性癖を感じたが、たしかにその惨めさはエッチだなあと思った。
自己啓発本の類は読まないタイプなんだが、それでも自分のQoLを高めるにはどうするかってことぐらいは考える。
俺は今後何かで「大金持ち」になったり「大成功」することもないだろうから、今の収入のままでQoLを上げたいわけだ。
それで、そもそも「俺の精神がダメージを受けるのはなんでなのか」ってのを突き詰めたら「孤独感」ってやつにたどり着いた。「孤独」ではなく「孤独感」だ。
「周囲の人間に無視されることはサバイバル上の死を意味したから、認められるために孤独を痛みとして感じるようになった」という進化的経緯があることを知る。
だから「承認欲求」とやらは本質的に人間の社会本能であり、個人主義という最新の文化に脳が適応しきれていないことを意味する。
数学という趣味を全く他者と共有せず、一人部屋にこもってやり続けても満足できるなら、そもそも普段の社会生活で十分満足できている可能性が高い。
ところが「孤独感」を抱えてしまうような何らかの問題を持った人間は、趣味を他者と共有したいと考えたがる。
要するに「趣味がないこと」が問題なのではなく、日常生活で「社会から見放されている」と感じる何らかの要因の存在が問題だ。
お前がツイートしても誰もイイネしない。あいつはイイネをたくさんもらっているのに。
こういう本能は理性的には全く理解できない。俺がいくら理性レベルで「こういう感情ってバカっぽいな」と考えても、本能部分が勝手に「孤独感」を生み出すから制御ができないのだ。
アドラーだかなんだかは胡散臭いので、「低次機能で説明可能な場合は高次機能を仮定するな」という心理学におけるオッカムの剃刀はもっと考慮するべきだろう。
理性レベルで対処可能なのは、Twitter、Facebook、Instagramなどの主要ソーシャルメディアを使わないようにすることだ。
そのためにはDNS、ルーター、ファイアウォール、アプリケーション層などあらゆるレベルでコンテンツフィルタリングしてしまったほうが良い。
またロールモデルを作ることも僅かながらの効果はあるかもしれない。賞金を辞退したペレルマンのように振る舞いたい。
以下は参考
"Social isolation results in higher likelihood of mortality, whether measured objectively or subjectively. Cumulative data from 70 independent prospective studies, with 3,407,134 participants followed for an average of 7 years, revealed a significant effect of social isolation, loneliness, and living alone on odds of mortality. After accounting for multiple covariates, the increased likelihood of death was 26% for reported loneliness, 29% for social isolation, and 32% for living alone. These data indicated essentially no difference between objective and subjective measures of social isolation when predicting mortality."
Holt-Lunstad, J. et al. (2015): Loneliness and Social Isolation as Risk Factors for Mortality: A Meta-Analytic Review. Perspectives on Psychological Science 2015, Vol. 10(2), pp. 227–237 https://pubmed.ncbi.nlm.nih.gov/25910392/
"Results Of the 35 925 records retrieved, 23 papers met inclusion criteria for the narrative review. They reported data from 16 longitudinal datasets, for a total of 4628 CHD and 3002 stroke events recorded over follow-up periods ranging from 3 to 21 years. Reports of 11 CHD studies and 8 stroke studies provided data suitable for meta-analysis. Poor social relationships were associated with a 29% increase in risk of incident CHD (pooled relative risk: 1.29, 95% CI 1.04 to 1.59) and a 32% increase in risk of stroke (pooled relative risk: 1.32, 95% CI 1.04 to 1.68). Subgroup analyses did not identify any differences by gender. Conclusions Our findings suggest that deficiencies in social relationships are associated with an increased risk of developing CHD and stroke. Future studies are needed to investigate whether interventions targeting loneliness and social isolation can help to prevent two of the leading causes of death and disability in high-income countries."
Valtorta, N. K. et al. (2016): Loneliness and social isolation as risk factors for coronary heart disease and stroke: systematic review and meta-analysis of longitudinal observational studies. Heart Vol. 102, pp. 1009–1016 https://heart.bmj.com/content/102/13/1009
https://www.mhlw.go.jp/content/10601000/000854571.pdf
26歳以上の女性におけるCIN1+に対する2価HPVワクチンの有効性(RCT)
○ 26歳以上の女性におけるHPVワクチンの有効性、安全性、免疫原性を評価するために、アジア 太平洋、欧州、北米、ラテンアメリカの12カ国の健康な女性を対象としたランダム化比較試験 (ワクチン群 vs コントロール群)の7年間のフォローアップが実施された。一次評価項目とし て、HPV16/18型への持続感染又はCIN1+の病変に対するワクチン有効性が設定された。
○対象者は2006年2月から2014年1月まで登録され、有効性の評価には 4,407名の女性が対象 (ワクチン群 2,209名、コントロール群 2,198名)となった。年齢層では、26歳から35歳が全体の 43.9%、36歳から45歳が45.1%、46歳以上が11.0%を占めていた。全体の15%でHPVの既感染又は関 連疾患への罹患を認めた。
接種から84ヶ月の時点で、ワクチン接種者における、HPV 16/18型の持続感染(6ヶ月間)又は CIN1+病変に対するワクチン有効性は90.5%(96.2%CI: 78.6-96.5)であった。
学歴がよくなくて、就職が困難だったので中小 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 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
いわゆる引退。
札によって試行錯誤を封じられた。基本的にぜかまし様やTwitterなどの編成をコピるのが、当初からの攻略方法だった。札実装前は編成を少し変える余裕があり、ボスにたどり着かなかったり寄り道したりなども楽しめた。今では全海域の情報が出揃うまで何も出来ない。海域攻略のための特効艦と友軍弾きのため、迂闊に札を付けられない。札対策のために同じ艦を複数用意するのも、ずっと納得していない。
一回の出撃で勝たなければならない運の要素が増えすぎた。道中、交戦形態、基地航空隊、開幕航空戦、決戦支援、開幕雷撃、砲撃戦、特殊攻撃、友軍ガチャ、夜戦CIなどがあり、これからもゆるやかに増え続けるだろうこれらの中でも基地航空隊と開幕航空戦が特に辛く、F5保熟練も使うようになってしまった。キラ付けと違って熟練度は3回の出撃でマックスにはできない。なんでこんな不正行為をしないといけないんだ？
戦果以外の任務をやるなら、それ相応の時間を使うのは仕方ない。ゲームとして驚くほど駄目なイベント海域をやるのは、時間が非常にもったいない。でもイベント海域をやらないなら、なぜ艦これをやるんだ？
二次創作を楽しむには、イベントの新艦を迎えておいたほうが良いか？艦娘のキャラクターとしての情報なんて、調べたら全部出てくる。つまらないイベント海域で心臓をキリキリさせながら時間に追われて天井なし堀りをやらされるのか？道中で撤退もあるし、SAが取れるとも限らない。何ならシャッターもある。
不公平な改造、不公平な新規イラスト、イベント海域終了後の新艦限定グラ。お抱え絵師なら頼みやすいのかな？でも幅広く平等にして欲しいよ。
ランカーにしか配られず何年経っても降りてこない「ささやかな」装備、イベント頻度が少なくなったのに大勢居るイベント限定艦。名前に「これくしょん」なんて入ってなければ良かったのに。
信用できないメンテ終了予定時刻。外部の力を借りてでも改善してくれ。
そういう点ばかり認識できるようになった自分も嫌。そんな自分に艦娘を従わせるのも嫌。
今まで多くのことでありがとう。任務の消化のために幾度となく出撃してくれてありがとう。ずっと遠征に行って資源を集めてくれてありがとう。イベント海域の攻略を成し遂げてくれてありがとう。出会ってくれてありがとう。
そして、多くの点で申し訳ない。提督に成り立ての頃システムを理解せず、君たちの仲間を轟沈させてすまない。システムを理解した後も、ながらプレイによる大破進撃で、君たちの仲間を轟沈させてすまない。俺のくだらないミスで傷つけてすまない。
終戦や平和という意味でサービス終了まで続けたかった。俺のプレイや課金によって平和が遠のくなら、辞めるべきだと考えた。イベント攻略を通じて、負の感情を強めるのが怖かった。イベント攻略をしないのに、君たちを負傷させる出撃や使わない資源のための遠征をさせる理由がなくなった。
前職と比較すると平均技術レベルはマジで変わったように感じる。
前職だとクリーンアーキテクチャやらCI/CDやらは言葉の意味すら知らない人も多かったけど、
今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。
FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、
凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値もめっちゃ上がるんだろうなって感じもある
コードの品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル。
命名として若干ニュアンスに違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し！」みたいなのは容赦なく潰される。
ペアプロ・モブプロはしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。
会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらいはいる。
開発手法もアジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんとセオリーに則ってる形で管理されている。
ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね？」っていうのもまた感じた。
そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算で10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値を提供できてんのかなこのサービス？っていう感じというか……
前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。
動いてるものが同じなら採用技術がオンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、
NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん？
難易度の高いイケてる技術スタックを使う＝必然的にエンジニアのお賃金が高くなるってことだから、経営者視点から見てもこういう選択って果たして正しいのかなぁって。
なんならエンジニアの賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。
どう思うよ。
https://anond.hatelabo.jp/20220120221328
お前これか
28歳男プログラマー。地方零細IT企業に勤めてるけどコロナをきっかけに求人の選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。
Webプログラマー＋自社サービス＋フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。
1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。
2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものをRTA感覚で実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。
3社目は「あなたのテックリード経験などは経歴的に弊社の求める人材とマッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと～」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った
正直学歴とかは偏差値の概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。
でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒のガチガチ勢に叩きのめされてたらどうしようもないもんな。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
28歳男プログラマー。地方零細IT企業に勤めてるけどコロナをきっかけに求人の選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。
Webプログラマー＋自社サービス＋フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。
1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。
2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものをRTA感覚で実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。
3社目は「あなたのテックリード経験などは経歴的に弊社の求める人材とマッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと～」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った
正直学歴とかは偏差値の概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。
でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒のガチガチ勢に叩きのめされてたらどうしようもないもんな。
冴えない男に生まれた以上はスキルを上げて経験積んで資本主義社会で殴り合って金なり地位なり手に入れなきゃ俺なんて誰一人にも見向きもしてくれない。
食うにゃ困らんが、食うのに困らんだけの男など誰の視界にも入らない。負けたら死ぬまで孤独が続くだけ。
今を抜け出したかったら、弱者男性には戦う以外の選択肢はないんだ。
「クリスマスにはシャケを食え！」の棘。
【追記あり】「ここまで来るとサモーンを倒し損ねてる可能性すら…」クリスマスにシャケを食べる謎の新習慣定着にパトレンジャー自ら懸念を示す #ルパパト - Togetter
についたブコメ。
ポーランドでは鮭を食べてるらしいとの情報もある。 https://twitter.com/Eeri～ - kamanobe さんのブコメ
https://b.hatena.ne.jp/entry/4712966491844065954/comment/kamanobe
ツイ辿るとサーモン食べるのは軟弱になった今時の習慣で、昔は鯉を食べてたそうな。
Eri MizutaniさんのTwitter 「もう、絶滅文化である風呂桶に鯉。私が見たのは11年前、ポーランドに来たばかりの時に、クリスマスに招待してもらった子のおばあちゃんの家ででした。 11年でほぼ絶滅。最近はみんなサーモン食べるしね～…」
twitter.com/Eerimizu/status/1473719841332903946
Eri MizutaniさんのTwitter 「ポーランドのクリスマスの風物詩。風呂桶に生きた鯉。 ポーランドはクリスマスに鯉を食べるのだけど普段新鮮な魚とは無縁なのにこの時期だけスーパーに生簀が出現し、ご家庭で調理するまで風呂桶で保存されます。」
でも、鯉って骨が面倒臭かったよな。Y字の骨。
コイは挽肉にしちゃえば骨がとんで食べやすい！捌き方から説明するよ | 東京でとって食べる生活
totte-taberu.com/kiroku/kawa/koi
鯉はうまい魚なのですが欠点があり、どんな料理をやっても小骨が気になってしょうがない。
太い大きくて刺さると痛いY型の骨が、身の中にたくさん埋まっています。
本当に鯉のY骨は手強い相手なのです。手練れの職人はうまく避けて鯉の洗いなんかを作るそうですが、とてもじゃないないですが素人にはできません。
箸で食べるにしても骨つまんで出すの面倒いのに、ポーランド人はどうやって食べてんだろ？
japoland.pl/blog/%E3%83%9D%E3%83%BC%E3%83%A9%E3%83%B3%E3%83%89%E3%81%AE%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%9E%E3%82%B9%E6%96%99%E7%90%86/
この日最も大事なのが魚料理、特に鯉です。鯉はシンプルに油で焼いたもの(Karp smażony‐カルプ・スマジョーヌィ)や
Karp smażonyで画像検索するとブツ切りで調理してるっぽい。
切り身も。
https://akademiasmaku.pl/upload/recipes/4664/karp-smazony-w-masle-na-patelni-4664.jpg
Y骨入りのまま食べて口からペッペッと吐き出すのかな？
そのまま焼いてるものもあるが、隠し包丁入れてる動画もあった。
Karp smażony na patelni. Chrupiący i delikatny. Przepis na filety z karpia bez ości. MENU Dorotki
youtu.be/-olIz9Al0Jc?t=260
これなら骨吐き出さずに食べられそう。食感は良くないが。
static.e-mieszkanie.pl/art/9932_huge.jpg
丸ごと1匹入ってる。フォークとナイフで骨避けながら食べるの？
こっちは丸ごと1匹を捌いてブツ切りに。
Karp w galarecie
youtu.be/wxUNl4OoHx0
小骨取り除くどころか背骨ごとブツ切りにして茹でてる。骨のゼラチン質使う為？
茹でた後、ブツ切りから骨を手で取り除いてるがY骨は取りきれてなさそう。
結論としては自分なら、手練れが調理した鯉の洗いを酢味噌でいただきたい。
追記)
Results:
A total of 3030 participants were randomly assigned to the recommendation to wear masks, and 2994 were assigned to control; 4862 completed the study. Infection with SARS-CoV-2 occurred in 42 participants recommended masks (1.8%) and 53 control participants (2.1%). The between-group difference was −0.3 percentage point (95% CI, −1.2 to 0.4 percentage point; P = 0.38) (odds ratio, 0.82 [CI, 0.54 to 1.23]; P = 0.33). Multiple imputation accounting for loss to follow-up yielded similar results. Although the difference observed was not statistically significant, the 95% CIs are compatible with a 46% reduction to a 23% increase in infection.
Multiple imputation accounting for loss to follow-up yielded similar results. Although the difference observed was not statistically significant, the 95% CIs are compatible with a 46% reduction to a 23% increase in infection.
特にここ
Depuis fin Mars – début avril 2021 jusqu’à maintenant, un groupe discord d’une vingtaine de personne avec qui j’étais autrefois en bon terme cherche à me nuire et à me faire « cancel » par tous les moyens qu’ils ont.
Leur discord comporte une trentaine de personnes, et j’en faisais parti depuis pratiquement le début du jeu. Le discord était privé et en sachant cela tout le monde se faisaient le plaisir de parler sur tout le monde, moi y compris. J’ai donc pu dire des choses déplacés dans ce serveur sur des membres de la communauté c’était privé donc je me disais juste que c’était de la vanne sans forcément le penser dans le fond, je me complaisais juste dans le serveur et je prenais aucun recul sur la situation.
En fin mars, j’ai pris du recul et je me suis enfin éloigné de ce groupe discord. À la suite de ça, il y à eu une altercation bateau sur un serveur de la communauté. Ils en ont donc profité pour contacter une vingtaine de personne importantes de la communauté DBFZ dans le but de me faire cancel, inventant certaines choses, envoyant tous types de screen à mon égard, parfois de manière détournée parfois non. J’ai donc eu une discussion avec les concernés, au début en essayant de me dédouaner en renvoyant la faute ailleurs, mais j’ai vite réalisé que cela n’avait aucun but car ça ne menait à rien de ne pas assumer, je me suis donc « expliqué » sur ce qui était explicable et qui n’était pas juste méchant et gratuit pour rien, je me suis excusé sur tout ce qui a pu être dit, même si cela ne pardonne rien c’est la moindre des choses. J’ai ensuite proposé une solution à tout cela : quitter la communauté et on me reverrait plus, au moins on aurait plus à faire avec moi, choses a laquelle ils ont refusés. La seule chose condition aura été qu’on ne se parle plus.
Voyant que leur plan n’a pas fonctionné le groupe a donc cherché à ce moment là plus de personne, tout en ressortant encore une fois pleins de screen avec à chaque uniquement des paroles dites par moi sans contexte de conversation ou sans des choses qu’ils ont pu dire, pour prétendre auprès de ceux qu’ils aillaient voir que c’était juste pour les mettre en garde contre moi et qu’eux à contrario étaient clean.
L’histoire s’est laissé couler jusqu’en septembre ou là ils ont continué à chercher des histoires à des potes, en cherchant encore une fois des histoires et encore une fois en partant loin. J’ai donc pris la décision de prendre le compte d’un pote qui était dans leur serveur pour avoir accès a tout ce qu’ils disent depuis le début de l’année et même avant, J’ai parlé de l’idée à quelques personnes qui ont du coup pu voir eux aussi tout le contenu de leur serveur dans leur intégralité. J’ai donc eu accès a absolument tous leurs messages et j’ai pu tout screen ainsi qu’enregistrer l’entièreté du contenu dans leur serveur. Je constate donc qu’il y a environ 600 pages de messages concernant juste mon pseudo, tout y passe ça spam des photos de moi, proférant des menaces physiques, me souhaitant le sida, la mort, en menaçant qu’apparemment ils ont mes codes de CB et peuvent s’en servir à tout moment, mon adresse mais surtout se ventant avoir crée un fake compte de moi et qu’ils se le passent (J’ai évidemment tout screen / enregistré),
https://i.imgur.com/uy6N7kD.png
https://i.imgur.com/t0CF0MH.png
https://i.imgur.com/78pZBds.png
Rajoute à cela du trash talk sur absolument toutes les personnes de la et mêmes des personnes partiellement extérieures qui sont là depuis peu (cf : https://i.imgur.com/P6TagB6.png ) rajoutant qu’il ne pourra rien leur arriver car de toutes façons ils ont « le pilier » de la communauté de leur côté, maintenant ces mêmes personne m’accuse de racisme entre autres alors qu’ils sont suffisamment à l’aise pour dire ce genre de chose sous couvert apparemment de second degré :
https://i.imgur.com/laxZeye.png
https://i.imgur.com/DqJ9nRp.png
https://i.imgur.com/MIxTUcY.png
Aujourd’hui encore une fois ils essaient donc de me cancel en envoyant cette fois-ci des screens a toutes les personnes qu’ils peuvent étant donné que les fois précédentes n’ont pas fonctionné, c’est pourquoi je tenais donc à m’excuser publiquement envers toutes les personnes que j’ai pu offenser.
Oui j’ai eu un comportement de merde je le reconnais, à l’heure actuelle je regrette tous les dires que j’ai pu proférer et je continuerai de m’excuser à propos de ça (je suis bien conscient que cela n’efface en rien la chose) et m’expliquerais plus amplement envers ceux qui le souhaitent en DM.
N’ayant absolument rien à cacher tous ceux qui souhaitent lire le contenu de leur serveur ont juste à me DM et j’enverrai le lien donnant accès à tout ce qui a pu se dire sur leur serveur depuis là création et pas de simple screen avec juste mon pseudo.
A l’époque j’avais laissé une chance et je n’étais pas allé jusqu’à déposer plainte malgré tout l’harcèlement depuis le début d’année. Cette affaire est actuellement entre les mains d’autorité publique. Je ne souhaite plus développer dessus et laisse les décisions au soin de la justice française.
