「ci」を含む日記 RSS

はてなキーワード: ciとは

2022-09-24

[]9月24日

ご飯

朝:バナナ。昼:かいわれ大根ピーマン焼きそばベーコンエッグトマトチーズ。夜:キャベツウインナースープパン

調子

むきゅーはややー。お仕事おやすみ

EVE burst error

クリア

20年以上前ゲームなのに、オシャレで格好いいイケてる雰囲気が凄かった。

私立探偵小次郎パートと、エージェントまりパートで全く異なる二つの事件捜査する。

捜査過程で街を探索するのだが、情報屋とのやりとりや、聞き込みなどのシーンが洒落ててたり、ゲラゲラ笑えたりと個性豊かで楽しい

絵で表現しきれない箇所はバッサリ黒塗り背景に文章だけで表現するのも潔いし、何よりそのテキスト面白いのだから一切問題なし。

ホテルバーや海沿いの倉庫など、登場する場すら格好よく感じてくる。

軽妙なやり取りもあれば衒学的な部分もありで、兎に角事件捜査を楽しめる。

二人主人公制は最初のうちは時折登場人物が重なる程度なんだけど、徐々にそれらが一本に繋がっていくところが快感

特に二人の主人公が互いを知らずにコンピュータ回線越しに事件捜査のために協力するシーンはただCIコンソール文字が出るだけも演出なのに、熱く燃える今作屈指の名シーンだろう。

この互いが互いをあまり知らずに事件捜査のために協力するという関係性も、格好いい。

普段はだらしないけどやる時はやるタイプ主人公拳銃片手に非合法組織と戦いながら夜の街を駆ける、そんな創作物テンプレート自体根本的に格好いい…… と言ってしまえばそれだけなのかもだけど、もうこれは冴羽獠DNAに植え付けられた僕たちの宿命なのかもしれないなあ。

(ルパン三世でもいいし、ダグラスカイエンでもいいし)

ジャズっぽいBGMも決まっている。

そんな感じで、事件捜査する過程については百点満点文句なしの出来。

だけど、物語の終盤はかなり駆け足気味かつ、しっくりこない終わり方だった。

突然現れる現実を超越した科学技術に、二人の主人公蚊帳の外自体が進行し、犯人が突然恋愛をはじめる展開、そして自白で幕をおろす。

最終章までの丁寧な展開、格好いい展開はどこへやらで、正直肩透かし

犯人自白と、とあるキーパーソン独白だけで最終盤は進むため、二人の主人公がそれらにどう感じたのかどんな行動を取ったのかが一ミリもわからないのは流石にガッカリ

何より「犯人自白」とは書いたが、とあるSFガジェットにより厳密には正しい言い回しではなく、真の意味での犯人はおそらく作中でセリフが全く無いという構造も、流石にちょっと終わった感じがしなかった。

とはいえ、謎解きのロジックや、あっと驚くサプライズトリックを楽しむ作品ではなく、事件捜査過程の格好良さを楽しみ作品だと割り切れば文句なし

なお、柴田茜というルポライター女性が「僕っ子」なのは、流石に当時でもコテコテでやりすぎなのでは? と思っていたが、かないみか氏の演技力のおかげですぐ違和感がなくなった、声優ってすごい。

原作アダルトゲームなこともあり、明らかに情事意図するシーンや、明らかに元はエッチなことされたけど違うことに置き換えたシーンなどが多くあり、元もプレイしたくなった。

また、銃を突きつけた状態自由を奪うために服を脱がすというシーンが3回ほどあって性癖を感じたが、たしかにその惨めさはエッチだなあと思った。

続編が色々と出ているが、近年の作品以外はどれも評判が良くないので、飛ばしてその近年の作品を遊ぼうと思う。

2022-09-21

承認欲求孤独

自己啓発本の類は読まないタイプなんだが、それでも自分QoLを高めるにはどうするかってことぐらいは考える。

俺は今後何かで「大金持ち」になったり「大成功」することもないだろうから、今の収入のままでQoLを上げたいわけだ。

それで、そもそも「俺の精神ダメージを受けるのはなんでなのか」ってのを突き詰めたら「孤独感」ってやつにたどり着いた。「孤独」ではなく「孤独感」だ。

調べてみると、孤独感というのは人間本能である

「周囲の人間無視されることはサバイバル上の死を意味たから、認められるために孤独を痛みとして感じるようになった」という進化的経緯があることを知る。

から承認欲求」とやらは本質的人間社会本能であり、個人主義という最新の文化に脳が適応しきれていないことを意味する。

例えばお前が「数学趣味にしよう」と考えたとする。

数学という趣味を全く他者と共有せず、一人部屋にこもってやり続けても満足できるなら、そもそも普段社会生活で十分満足できている可能性が高い。

ところが「孤独感」を抱えてしまうような何らかの問題を持った人間は、趣味他者と共有したいと考えたがる。

要するに「趣味がないこと」が問題なのではなく、日常生活で「社会から見放されている」と感じる何らかの要因の存在問題だ。

ソーシャルメディアはそれを加速する現代暴走装置だ。

お前がツイートしても誰もイイネしない。あいつはイイネをたくさんもらっているのに。

こうして孤独感という本能的痛みを加速させる。

こういう本能理性的には全く理解できない。俺がいくら理性レベルで「こういう感情ってバカっぽいな」と考えても、本能部分が勝手に「孤独感」を生み出すから制御ができないのだ。

アドラーだかなんだかは胡散臭いので、「低次機能説明可能場合は高次機能仮定するな」という心理学におけるオッカムの剃刀もっと考慮するべきだろう。

理性レベル対処可能なのはTwitterFacebookInstagramなどの主要ソーシャルメディアを使わないようにすることだ。

そのためには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

2022-09-11

anond:20220911123537

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)であった。

すまん君の提示したソース有効性があるって書かれてるんやがワイの読み間違いか

2022-08-27

センスの無い未経験年収300万強のプログラマとして就職して必要だったこ

学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)

レキサルティレクサプロデパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。

参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキル必要かを、まとめておく。

ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミング努力しても AtCoder黄色になれず青色のままってくらい。

AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。

要するに

経験プログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。

入社時に覚悟しておかなければならない事

誓約書

基本的に、損害を与えた場合には、それを作業者補填するという誓約書を結ぶ。

要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。

このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。

要するに、低賃金で未経験プログラマ案件にノーリスクで送りこんで、稼ぐための手段です。

必要だったスキル

ディレクション

基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマ自分ディレクションして意思決定する必要がある。

例えば、下請け場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM瑕疵担保責任がどうとか言われる。

社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。

そういう不幸を防ぐためにも自分ディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキル要求される。

基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。

これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。

デザイン

こう見せたい、こう表現したい、という事を伝えるには、必然的デザイン知識必要になる。

創造思考デザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である

ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングデザインと言えるかもしれない。

言語技術 (言語能力)

顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。

まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。

なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますお茶を濁して、エマージェンシーになる。

後述する設計能力においても、課題を把握するための言語技術(言語能力)は重要ファクターだと思う。

ソフトウェア設計

C/C++システムプログラムフレームワーク基本的に無いので、自分概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。

この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。

読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。

ネットワークプログラム (C)

UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単作業があって、振られた。

リークしてはいけないという事で malloc禁止で、グローバル変数を利用するという変なルールがあった。

Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。

あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。

システムプログラム (C++)

なんか、特殊PCI Expressカードからベンダーが用意している SDKデータ引っこ抜いて Web API へつなぎ込む部分をやった。

データの中の特殊信号を取りたかったらしい。

一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人やらせるんなとは思った。

Webバックエンド (Express/Fastify + PostgreSQL)

当たり前だが、DB 作って RestAPI を生やすのは現代プログラマにとって自然にできなければならない。

なので、新規開発のサブモジュールバックエンドを任せられた。

だが、ORM の癖を把握したり、発行されるクエリ確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。

結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。

それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。

最近だと、TypeScriptPrisma 使うのが、型安全でよさそうだなと思っている。

Nest.js個人的には好み。

Linux操作 (EC2 とか)

デプロイEC2 直でやったり ECS にしたりとしていたので、ベアメタル知識必要になった。

要するに systemd のいじり方とか、死活監視の仕方とか。

個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。

Bind権威DNS管理して、postfix絶対止めてはいけないメールサーバ管理するとかもあったけど、出来て当然ではある事だし。

Webフロントエンド (React/Vue)

会社Webアプリ案件を取ってきたので突っ込まれた。

経験プログラマでも、月単価 100 万以上で顧客請求してるんだから会社はそりゃ儲けるだろうと思った。

会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客責任はないのだから

当たり前だが、WebディレクションWebデザインWebプログラミング, Webマークアップ は、全て作業者であるプログラマ仕事になる。

個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。

デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS手書きしていた。

tailwind が出た現在では使っていればよかったなと思う。

結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10リリースするという行為をした。

顧客大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。

一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。

そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。

これはなんとか保守対応ねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。

CI/CD 構築 (Azure Pipelines)

当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。

今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由Azure Pipelines で CI/CD フローを構築した。

もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。

IaC (Terraform)

当然だが、デプロイするためには IaC を整える必要がある。

これを知らずに、コンソールポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。

今は CDK とか便利なものが出来てるんだなぁ。

自動テスト

本来テスト自動テストを整えて、質保証をしてバグを減らさなければならない。

だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。

一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど

自動化できれば費用必要じゃなかったから、怠慢だと、責められてしまった。

同じような未経験の人へ

経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。

甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。

2022-08-13

anond:20220813125811

Japan za ta ci gaba da rarraba har shekaru masu zuwa. Kasancewar Shinzo Abe ya kasance babba ga duka sansanonin masu ra'ayin mazan jiya da masu sassaucin ra'ayi.

2022-06-24

anond:20220624093955

業界経験って職歴自体はなんとかなりそうな気がするけどな。

自分でしらべてAWSサーバたててサイト作りましたソースgithubにあってciちゃんとしてます

とか成果物あるかが重要で、それなりにあったらWeb系?でもコーディングテスト突破 or センス見せたら採用してくれるとこ普通にありそう。

2022-06-15

https://zenn.dev/sosukesuzuki/articles/1d1bfb73118a9b

CIが途方もない計算量を消費してるのは間違いないので

CIの短縮に貢献したところには金が還元されて欲しい

2022-06-06

さようなら艦これ

いわゆる引退

提督プロフィール


引退理由

期間限定海域がつまらなくなった

札によって試行錯誤を封じられた。基本的ぜかまし様やTwitterなどの編成をコピるのが、当初から攻略方法だった。札実装前は編成を少し変える余裕があり、ボスにたどり着かなかったり寄り道したりなども楽しめた。今では全海域情報が出揃うまで何も出来ない。海域攻略のための特効艦と友軍弾きのため、迂闊に札を付けられない。札対策のために同じ艦を複数用意するのも、ずっと納得していない。

一回の出撃で勝たなければならない運の要素が増えすぎた。道中、交戦形態基地航空隊、開幕航空戦、決戦支援、開幕雷撃、砲撃戦、特殊攻撃、友軍ガチャ、夜戦CIなどがあり、これからもゆるやかに増え続けるだろうこれらの中でも基地航空隊と開幕航空戦が特に辛く、F5保熟練も使うようになってしまった。キラ付けと違って熟練度は3回の出撃でマックスにはできない。なんでこんな不正行為をしないといけないんだ?

もちろん複数ゲージと大量のギミック面白さは感じない。

時間もったいない

戦果以外の任務をやるなら、それ相応の時間を使うのは仕方ない。ゲームとして驚くほど駄目なイベント海域をやるのは、時間が非常にもったいない。でもイベント海域をやらないなら、なぜ艦これをやるんだ?

二次創作を楽しむには、イベントの新艦を迎えておいたほうが良いか艦娘キャラクターとしての情報なんて、調べたら全部出てくる。つまらないイベント海域心臓をキリキリさせながら時間に追われて天井なし堀りをやらされるのか?道中で撤退もあるし、SAが取れるとも限らない。何ならシャッターもある。

運営を好きになれない

不公平な改造、不公平新規イラストイベント海域終了後の新艦限定グラ。お抱え絵師なら頼みやすいのかな?でも幅広く平等にして欲しいよ。

ランカーにしか配られず何年経っても降りてこない「ささやかな」装備、イベント頻度が少なくなったのに大勢居るイベント限定艦。名前に「これくしょん」なんて入ってなければ良かったのに。

信用できないメンテ終了予定時刻。外部の力を借りてでも改善してくれ。

不満点がいくらでも出る

そういう点ばかり認識できるようになった自分も嫌。そんな自分艦娘を従わせるのも嫌。

鎮守府の皆へ

今まで多くのことでありがとう任務の消化のために幾度となく出撃してくれてありがとう。ずっと遠征に行って資源を集めてくれてありがとうイベント海域攻略を成し遂げてくれてありがとう出会ってくれてありがとう

そして、多くの点で申し訳ない。提督に成り立ての頃システム理解せず、君たちの仲間を轟沈させてすまない。システム理解した後も、ながらプレイによる大破進撃で、君たちの仲間を轟沈させてすまない。俺のくだらないミスで傷つけてすまない。

終戦平和という意味サービス終了まで続けたかった。俺のプレイ課金によって平和が遠のくなら、辞めるべきだと考えた。イベント攻略を通じて、負の感情を強めるのが怖かった。イベント攻略をしないのに、君たちを負傷させる出撃や使わない資源のための遠征をさせる理由がなくなった。

皆を解体せず、このまま去る。どうか楽しく生きて欲しい。さようなら。またいつか、どこかで。

2022-05-21

零細Saasベンチャーから競合のSaasメガベンチャー転職した

表題の通り。当方エンジニア

前職と比較すると平均技術レベルマジで変わったように感じる。

前職だとクリーンアーキテクチャやらCI/CDやらは言葉意味すら知らない人も多かったけど、

今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。

FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、

凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値めっちゃ上がるんだろうなって感じもある

コード品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル

命名として若干ニュアンス違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し!」みたいなのは容赦なく潰される。

ペアプロモブプロしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。

会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらはいる。

開発手法アジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんセオリーに則ってる形で管理されている。



ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね?」っていうのもまた感じた。

そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値提供できてんのかなこのサービス?っていう感じというか……

前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。

動いてるものが同じなら採用技術オンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、

NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん?

難易度の高いイケてる技術スタックを使う=必然的エンジニアのお賃金が高くなるってことだから経営者視点から見てもこういう選択って果たして正しいのかなぁって。

なんならエンジニア賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。

どう思うよ。

2022-02-24

anond:20220224195309

https://anond.hatelabo.jp/20220120221328

お前これか

28歳男プログラマー地方零細IT企業に勤めてるけどコロナきっかけに求人選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。

Webプログラマー+自社サービス+フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。

1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。

2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものRTA感覚実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。

3社目は「あなたテックリード経験などは経歴的に弊社の求める人材マッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと~」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った

正直学歴とかは偏差値概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。

でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒ガチガチ勢に叩きのめされてたらどうしようもないもんな。

2022-02-13

anond:20220212154229

それはできる限りやろうとしていて、それゆえ今のデジタル社会が出来上がっているのではないか

IDEの高機能っぷり。コーディング自動デプロイ自動テストリリース

といったCI/CD、DevOpsもそんなイメージで作られている。

それを使いこなすための知識だけでいっぱいいっぱいになってる気もする。

ラプラスの悪魔パラドックスみたいだ。

アプリ開発したこといから、そんなにわかんないんだけどね。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-20

弱者男性だけど弱者男性を抜け出すための転職活動が辛い

28歳男プログラマー地方零細IT企業に勤めてるけどコロナきっかけに求人選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。

Webプログラマー+自社サービス+フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。

1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。

2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものRTA感覚実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。

3社目は「あなたテックリード経験などは経歴的に弊社の求める人材マッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと~」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った


正直学歴とかは偏差値概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。

でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒ガチガチ勢に叩きのめされてたらどうしようもないもんな。

冴えない男に生まれた以上はスキルを上げて経験積んで資本主義社会で殴り合って金なり地位なり手に入れなきゃ俺なんて誰一人にも見向きもしてくれない。

食うにゃ困らんが、食うのに困らんだけの男など誰の視界にも入らない。負けたら死ぬまで孤独が続くだけ。

今を抜け出したかったら、弱者男性には戦う以外の選択肢はないんだ。

こんな焦燥感とは無縁で戦わないで済む人達が俺には心底羨ましいよ。。。。

2021-12-26

[] クリスマスには鯉を食べる

クリスマスにはシャケを食え!」の棘。

追記あり】「ここまで来るとサモーンを倒し損ねてる可能性すら…」クリスマスにシャケを食べる謎の新習慣定着にパトレンジャー自ら懸念を示す #ルパパト - Togetter

https://togetter.com/li/1820268

についたブコメ

ポーランドでは鮭を食べてるらしいとの情報もある。 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ポーランドクリスマス風物詩風呂桶に生きた鯉。 ポーランドクリスマスに鯉を食べるのだけど普段新鮮な魚とは無縁なのにこの時期だけスーパーに生簀が出現し、ご家庭で調理するまで風呂桶で保存されます。」

twitter.com/eerimizu/status/803341299705380865

でも、鯉って骨が面倒臭かったよな。Y字の骨。

コイは挽肉にしちゃえば骨がとんで食べやすい!捌き方から説明するよ | 東京でとって食べる生活

totte-taberu.com/kiroku/kawa/koi

鯉はうまい魚なのですが欠点があり、どんな料理をやっても小骨が気になってしょうがない。

太い大きくて刺さると痛いY型の骨が、身の中にたくさん埋まっています

本当に鯉のY骨は手強い相手なのです。手練れの職人はうまく避けて鯉の洗いなんかを作るそうですが、とてもじゃないないですが素人にはできません。

箸で食べるにしても骨つまんで出すの面倒いのに、ポーランド人はどうやって食べてんだろ?

ポーランドクリスマス料理 | Japoland

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 w galarecie‐カルプ・フ・ガラレチェ)が出されることが多いです。

Karp smażonyで画像検索するとブツ切りで調理してるっぽい。

http://4.bp.blogspot.com/-WOJ5do7jpPs/VJaNhR7zsmI/AAAAAAAALiI/e8lhN4QAr0o/s1600/Karp%2BSma%C5%BCony%2B11.jpg

切り身も。

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

これなら骨吐き出さずに食べられそう。食感は良くないが。

もう一方のゼリー寄せ、Karp w galarecie。

static.e-mieszkanie.pl/art/9932_huge.jpg

丸ごと1匹入ってる。フォークナイフで骨避けながら食べるの?

調理動画

こっちは丸ごと1匹を捌いてブツ切りに。

Karp w galarecie

youtu.be/wxUNl4OoHx0

小骨取り除くどころか背骨ごとブツ切りにして茹でてる。骨のゼラチン質使う為?

茹でた後、ブツ切りから骨を手で取り除いてるがY骨は取りきれてなさそう。


結論としては自分なら、手練れが調理した鯉の洗いを酢味噌いただきたい。




追記)

しまった、タイトルを「クリスマスは鯉の季節」にしとけば上手いこと言ったった感出せたのに…

2021-12-10

anond:20211210102502

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.

特にここ

2021-11-30

Kasugaの告発twitlonger

Ma version des faits.

Bonjour,

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 communauet 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 fonctionle 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 lacision 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.

2021-10-14

anond:20211013171730

CFじゃなくてCi-enとかPixivFanboxで集金すりゃいいのにな

2021-09-11

jQueryWebアプリケーションに使っている会社は滅びゆく(前編)

いまもjQueryWebアプリケーション大事ライブラリとして使っている会社は少なくないと思う。

jQuery会社で使っていると何が問題なのかを語っていこう。独断偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。

フロントエンドエンジニアjQueryを嫌うので入社しない

退職理由: jQuery

採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。

また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人可哀想なだけで、現役なわけではない。ラガード(遅滞者)の仲間入りをさせているだけだ。新人でもキャリアデザインできる新人は「jQueryオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。

そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。(jQueryアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQuery依存しておらず、jQuery依存していないのであれば簡単jQueryから脱却できるはずで、簡単jQueryから脱却できるならもう脱却しているはずだからだ)

メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます!」とにこやかに言うようなものだ。

(ただし、さすがにjQueryだけでフロントをやっているという会社求人ほとんど見かけることはない。無意識スクリーニングで落としているのかもしれない)

jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているかたまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。

jQueryを使っていました」というエンジニアは、他社からフロントエンドスキルが0とみなされる。つまりフロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ(逆はできる)

jQueryが書ける人材は縮小傾向にある

jQueryを書ける人口自体は増えているだろうが、労働市場から撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。

私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。

jQuery入社するのは、昔からjQueryを使っている高齢エンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。

そのため、需要供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。

jQueryを使っている会社にはフロントエンド知識が高い人がいないのでjQueryから抜け出せない

リプレイスはハッキリ言って難しい。モダンフロントエンド学習するだけでは足りなくて、それを使いこなせた上でしかjQuery使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。

時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。

jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。

何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。

jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合既存従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。(もちろん、「jQueryしかなかったサービスモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある)

ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ?」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態リプレイスしようとするのは、生活困窮世帯リボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。

ちなみにこのヤバい状態を『jQueryの崖』と言う。

jQueryを使っている会社フロントエンド周りのCI/CD等、エコシステムが構築できていない可能性がある

jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。

jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代通用しにくいものになっていく。

bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンインフラエンジニア(もしくはモダンインフラ知識のあるエンジニア)がいないかもしれない。SREという概念がないかもしれない。

世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。

すべては憶測なので、実際は違うかもしれない。

jQuery自体が悪いわけではない

さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体メンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。

問題は、jQueryというライブラリを使ってきた時代からアーキテクチャ前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryバージョン反比例する。

jQueryを使っているアプリケーションには、jQuery担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベントSPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数無視される変数スコープサポートが終わったライブラリドキュメントを見つけるのすら困難なよくわからないライブラリ高齢しか知らない伝説機能伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。

そのため、一定基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。

そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。

そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。

(そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ)

前編のおわりに

jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか?」という部分が気になるところだと思う。

そこで、後編では「どうやってjQueryを全廃すればいいのか?」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。

お楽しみに!

2021-09-02

小さい方がいいもの

ライブラリ

ライブラリは小さい方がいいです

当たり前ですね

ネット無駄な帯域を動画の次に食ってるのはCIライブラリインストールという話もあります

キャッシュを使いなさいキャッシュ

2021-08-29

コロナデカドロン処方のあれ

倉持仁医師コロナウイルス自宅療養者にイベルクチン抗生剤(フロモックス)+軽症者を悪化させる恐れのあるステロイドを処方?

https://togetter.com/li/1766223

のあれこれ、前提として私は医療従事者ではない。

どちらの判断が正しいかからないので、私に理解できる範囲で調べたのが以下。

抗生剤の方でなくステロイドの方。

  

前提

「倉持医師が自宅療養のCOVID-19感染者にデカドロンという薬剤を処方した」を事実とする。

ツイッター上の消去された自称患者ツイートであるため、信頼度がそこまで高いわけではないが、おそらく事実であろうという判断可能と思われる。

まずツイート上では「デカドロン(ステロイド)」とあるため、処方の書き間違いは考えにくいし「自宅療養の人に積極的に処方してあげて欲しい」といっていることから自宅療養の患者であろうと推測できる。

また、倉持医師ツイッター

自宅待機で呼吸苦あり、酸素も測定器もない。検査も診察も受けられないのに自宅待機者に医者なら〇〇出しちゃいけないとか、私ならこの薬は使いませんとか、意味不明。実際の患者さん見ての話前提。投薬とは医師患者さんで同意して行うもので、ガイドラインしか知らない人は自分だけそうしてれば良い。

https://twitter.com/kuramochijin/status/1431846060935168000

という反応をしているため、自身の処方である解釈されても仕方ないであろう。

    

説明書

まず、デカドロンとはデキサメタゾンというステロイドホルモン一種を錠剤にした製品である

デカドロンの説明書には以下のように書いてある。

https://pins.japic.or.jp/pdf/newPINS/00062800.pdf

9.特定の背景を有する患者に関する注意

9.1 合併症・既往歴等のある患者

9.1.1 以下の患者には治療上やむを得ないと判断される場合を除き投与しないこと。

(1) 有効抗菌剤の存在しない感染症、全身の真菌症の患者

免疫抑制作用により、感染症が増悪するおそれがある。

というわけで有効抗菌剤の存在しない感染であるCOVID-19に対して、やむを得ないと判断される場合でなければ処方してはいけないのがデカドロンとなる。なぜなら、感染症をかえって悪化させるおそれがあるためというはっきりした理由があるわけで。

一般論としてのデカドロンの説明としては以上になるが、コロナ治療の場という場では話が変わるかもしれないというわけで、次。

  

診察の手引き

なぜデカドロンが処方されていたかと言えば、コロナ治療薬としての認証を受けているからと思われる。

https://www.nikkei.com/article/DGXMZO61798210R20C20A7MM8000/

ということで、この異常事態では特殊な処方のされ方もされているかもしれないということで厚労省が出している「新型コロナウイルス感染診療の手引き[第2.2 版]」を見ることにする。

https://www.mhlw.go.jp/content/000650160.pdf

デキサメタゾンステロイド薬)

 英国での RECOVERY 試験の結果,デキサメタゾンが COVID-19 の重症例の死亡を減少させたとの報告がなされた.……主要評価項目である治療開始 28 日後の死亡率はデキサメタゾン治療群 vs.標準治療群において全体で 21.6% vs. 24.6%(年齢調整リスク比:0.83 [95% CI 0.74-0.92], p<0.001)とデキサメタゾンによる致死率低下を認めた.さらに呼吸サポート別では人工呼吸器装着患者の致死率は 29.0% vs. 40.7%(リスク比:0.65, [95% CI 0.51-0.82], p<0.001),酸素投与のみの患者の致死率は 21.5% vs. 25.0%(リスク比:0.80,[95% CI 0.70-0.92], p=0.002)とデキサメタゾンによる死亡率低下を認めたが,酸素投与の必要のない患者の致死率は 17.0% vs. 13.2%(リスク比: 1.22, [95% CI:0.931.61],p=0.14)とデキサメタゾン効果を認めなかった.

(RECOVERY Collaborative Group, Effect of Dexamethasone in Hospitalized Patients withCOVID-19: Preliminary Report, 2020. doi: https://doi.org/10.1101/2020.06.22.20137273)この試験を受けて,米国 NIH治療ガイドラインを 2020 年 6 月 25 日に改訂し,人工呼吸,または酸素投与を要する COVID-19 患者デキサメタゾン使用を推奨している.

NIH COVID-19 Treatment Guidelines https://www.covid19treatmentguidelines.nih.gov)

なお, MERS-Co-V やインフルエンザにおいては,ステロイド投与によりウイルス排除が遅延し,致死率も高かったとの報告がある.デキサメタゾン以外のステロイド薬の評価確立していない.

デキサメタゾンの投与で効果が認められたのは、人工呼吸又は酸素投与を要する場合であり、そうでない対象には効果が認められていない(それどころか投与した方が死亡率が高い)。

他のウィルス感染症の場合にはステロイド投与で致死率が高まるという報告も書かれており、原則使用不可の説明書裏付けているものだろう。

 

なぜ効果があるのか

デキサメタゾンが効く理由として、日本感染症学会の「COVID-19 に対する薬物治療の考え方 第 7 版(2021年2月1日)」では

https://www.kansensho.or.jp/uploads/files/topics/2019ncov/covid19_drug_210201.pdf

機序重症COVID-19患者は、肺障害および多臓器不全をもたらす全身性炎症反応を発現する。コルチコステロイドの抗炎症作用によって、これらの有害な炎症反応を予防または抑制する可能性が示唆されている。

としている。免疫作用として炎症が起こるが、免疫作用しすぎて炎症が有害になっているため炎症を抑えるためにデキサメタゾンが処方される。

そうすると免疫暴走していない状態デキサメタゾンを処方するのは問題ということだろう(免疫普通に頑張ってくれないとウィルス排除してくれない)。

  

やむを得ないと判断される場合

他のデキサメタゾン必要な疾患のためにCOVID-19と並行して治療を行う可能性とかも考えられるのかもしれない(それにしたって、COVID-19が治った後でもいい話でそんなに急いで取り掛からなくてはならないかと思わなくもないけども)。

後は、有害な炎症反応が起こっているが病床が足りないために入院できないで自宅療養をせざるを得ない状態もあるかもしれない(それならそうと説明すればよい気もするが)。

もっと専門的見地から見てやむを得ない事情があるかもしれないので、デカドロンの処方が全くおかしいとは私の調べた範囲では言い切れないが、危険を伴う処方であることも事実ではあろう。

基礎中の基礎の資料しか舐めていない私の理解は全く足りていないだろうが(倉持氏が苦言を呈したようにガイドラインしか読んでいない)、何も知らない一般人が調べただけでは倉持医師批判する側の言い分を肯定する資料が見つかったといえるだろう。

これ以上は私の手に余るので終わらせるが、それが本当に効くのならば一医師経験と勘で終わらせてほしくはないので、ほかの医師でも診断可能なような客観的基準を示して世界の役に立ってほしいなぁと愚考する次第である

2021-08-05

anond:20210709230408

基本的に Linter をコミットする前に通す癖がないと、良くないよね。あと、ユニットテストコミット前には必須よね。もうちょっとCI/CD勉強必要だな、自分は。運用の感じがわかんねー。

2021-08-04

キスブリアのリスクベネフィット比を推定するのは容易ではない

日経のこの記事、1/10万人程度の血栓にびびってバキスブリアを棚上げしてた国がおかしいみたいな論調だけど。

https://www.nikkei.com/article/DGXZQODK281E70Y1A720C2000000/

そのバキスブリアによる血小板減少を伴う血栓症候群(TTS)は脳静脈血栓を起こすと致死的になりうる( https://www.jsts.gr.jp/news/pdf/20210601_tts2_3.pdf p6) 。確率が低くても結果が重大なら当然その分「得失」の失の部分は大きくなり無視できなくなる。リスク不寛容とかそういうレベルの話じゃないんだよ。

一方で国内コロナ感染症が猛威を振るっている現状ではコロナにかかる確率デルタ株が優勢という点から、従来より高いと思われる。この点に関してはライフスタイル・体質の影響は大きい。また臨床経過も人様々であろう。両側広範囲肺炎から呼吸不全で亡くなったり、血栓症を合併してこちらが致死的になるかもしれない。これらのことから、「得失」の得の部分も一様ではない。有症状感染予防に関してデルタ株に対して、バキスブリアは65-75%程度といわれる。(67%, 95%CI 61.3%-71.8%, https://www.nejm.org/doi/full/10.1056/NEJMoa2108891)。得は思ったより大きくないかもしれない。

これらのことからリスクベネフィット比を各個人でどう判断するかは容易ではない。ここで、コミナティモデルナなどの比較安全ワクチンを接種できる選択肢があるのならばよいが、バキスブリしか選択できない若年世代はどうしたらよいのだろうか。それが1/10万人でも自分に起こってしまえばそれは100%の災難だ。そうなったとき、現状東京では治療を受けられるかどうかもわからない。

「腑に落ちない」のはかまわないが、それを非合理な国・国民所為だと高みから放言できるのは自分が恵まれ地位いるからだ、と自覚してから物言おうな。

2021-08-02

anond:20210801064035

GOODな自由研究です。いくつか補足させていただきます

あなた10%はどこから?私は通説から

元増田さんは「民間調査機関ドイツ全体の新生児10%が血縁関係がないと推計したよ」とおっしゃっています

元増田さん的にはドイツの托卵率10%という数字元ネタをこれだと推測しているのかもしれません。

しかし恐らく10%という数字は別のところからきています。その理由は、"托卵"率が10%と言うのが一昔前の通説だからです。

例えばLancetの1991年論文MacIntyre & Sooman (Lancet:1991)では

"Medical students are usually taught that the rate is 10-15%; 10% is a figure widely used in DNA studies and quoted in standard genetics textbooks;"

医学部生は通常その比率(non-paternity rate: 非父系率=托卵率)を10~15%と教わります10%という通説は広く範囲DNA研究に用いられ遺伝学の教科書でも引用されています

と述べられています1991年の時点でそう言われるほど人口膾炙した説だったわけですね。

この論文はその通説に批判的で、

"We would guess that the higher estimates are probably exaggerated for the general population in the UK, but have no way to assess the accuracy of the frequently quoted figure of 10%. We would be interested to hear of any reliable data."

我々はそのような高い推定値が、UK一般的母集団に対して過大評価であろうと考えていますしかし我々はこの10%という頻繁に引用される通説の正確性を評価する術を持っていません。我々は信頼できるデータを求めています

結論しています

事実比較的近年の研究では托卵率の推定値は1~4%程度(e.g., Anderson (Curr Anthropol:2006)、Voracek et al. (Psychol Rep:2008))、ごく最近研究では1%前後(e.g., Greeff & Erasmus (Nature:2015)、Larmuseau et al. (Trends Ecol Evol:2016))と従来の10%と比べてかなり低く推定されています

私としてはドイツに限った話じゃない"10%"という数値が、何の拍子かドイツ特異的な話になり、いくつかの逸話と一緒にネットロアと化したのではないかと推測しています

ドイツの実際はどうなのよ

ドイツの托卵率についての論文は3つあります。Krawczak et al. (Forensic Sci Int:1993)、Henke et al. (Forensic Sci Int:1999)およびWolf et al. (Hum Nat:2012)です。

Krawczak et al. (1993)では托卵率が16.8%、Henke et al. (1999)では50.2%とくそ高いですが、これは係争中の父子鑑定の結果です。「お前は俺の子じゃない!」と父子鑑定をしてそれが的中したパーセンテージですね。ドイツ一般母集団を反映しているとはとても言えません。

その点Wolf et al. (2012)は質が良く、ドイツ一般集団を反映していると考えられる研究です。

概要を軽く説明しますと、この研究は小児白血病患者とその骨髄ドナーのHLA型を用いて托卵率を調べたものです。

骨髄移植にはドナーレシピエントのHLA型が一致する必要があるためデータ化されているのですが、このHLA型は親子の推定にも使用可能です。

時に皆さんは自分の子供が白血病になって骨髄移植必要という時にまずどうしますか?そうですドナー登録ですね。

まり、小児白血病患者とその骨髄ドナーデータを使えば子と親の鑑定用DNAデータがセットで山と手に入るわけです。

さら病気人間よりかは平等ですので、バイアスも少なくなりますプライベート情報を削除してしまえばコンプラ的にも安心

賢い方法ですね。

この研究の結果、推定されたドイツの托卵率は0.94% (95%CI: 0.33-1.55)でした。

Wolf et al. (2012)も完ぺきではありませんが、ドイツについて現状手に入る中で最も質の良い研究ですので、「ドイツの托卵率は?」という質問に対しては「約1%です」と答えるのが科学的な態度と言えるでしょう。

法律の話

父親のみによる勝手DNA鑑定はダメだよ→母子同意を取ってやってね(2005年から)

これは2008年です。2005年にあったのは別のもっとマイナー改正です。

元増田さんの引用にもある"否認手続から独立した父子関係明確化のための法律/Gesetz zur Klärung der Vaterschaft unabhängig vom Anfechtungsverfahren"が発効したのが2008年なのです。

さらにややこしいのですが、これとは別に"遺伝的診断法/Gendiagnostikgesetz"、正式には"ヒトの遺伝検査に関する法律/Gesetz über genetische Untersuchungen bei Menschen"というものもありまして、こちらは2010年に発効してます

さらさらにややこしいことに、勝手DNA鑑定を禁止したのは"遺伝的診断法"で、"否認手続から独立した父子関係明確化のための法律"の方は"秘密の父子鑑定(当事者同意を得ない遺伝子鑑定)"は証拠採用されないとされた一方で、裁判所から命令があれば当事者拒否してもDNA鑑定を命令できるという、双方向配慮された法律なのです。

ややこしすぎるので個別説明します。

遺伝的診断法

正式名称からわかる通り、遺伝子診断全般に関わる法律です。親子関係推定については法律の"セクション3:親子関係を明確にするための遺伝学的検査/Genetische Untersuchungen zur Klärung der Abstammung"で規定されています

要約すると

親子関係を明確にするための遺伝学的検査は、当事者(父、母、子)の同意を得た上で一定資格を持つ専門家によって行われなければならない。無断でやったら罰金

です。

ちなみに

なんで妻の同意必要なの?→……わからん……

これはシンプルでして、同意必要相手未成年場合親権者が決定の代行者になります父親が鑑定の請求である場合自動的に残った母親が代行者として同意/非同意することになります。つまり仮に母親請求者だった場合父親同意必要になるわけです。

この法律が求めているのは、遺伝情報という究極の個人情報を親とは言え勝手に使うな、あと品質保証のない民間企業に頼るのはやめなさい特に家族崩壊しかねない親子鑑定では、というもの

近年の分子生物学の発展的にみて、いずれ必要となる法律であろうな、というのが私の評価

否認手続から独立した父子関係明確化のための法律

これについて説明するには前提知識がいるので少し長くなります

ドイツには法的父親/母親というものがあり、出生に合わせて自動的に決定されます

  1. 法的母親は"その子供を出産した女"です。代理母だろうが出産後に性転換して男になろうが、産めば法的母親です。後述の法的父親とは異なり、異議申し立てによる回避はできません。代理母出産をした場合養子縁組手続きしなきゃ親子になれません。
  2. 法的父親は(a)嫡出児の出生時に法的母親結婚していた男、(b)非嫡出児を自分の子である認知した男、(c)裁判所が異議申し立てに従って指定した男、です。こちらは法的父親とされたことについて異議申し立て可能です。
異議申し立てプロセス

まず異議申し立て資格者は(1)法的父親ab、(2)受胎時に法的母親と親密(意味深)だった男、(3)子供、(4)母親、です。

「お前は俺の子じゃねえ!」という異議申し立ての他に「お前なんて俺の/この子父親じゃねえ!」という異議申し立てもあるわけですね。

ここでは(1)の場合だけ解説します。

まず(1)による異議申し立て裁判所に申し出る場合、親子関係に対する合理的な疑いの根拠提示しなければなりません。

判例にもとづけば、

  1. 実は子供結婚前に生まれていた(嫡出児の法的父親要件を満たさない)
  2. 母親浮気示唆される
  3. 推定される受胎期間中母親と親密ではなかった(セックスレス、別居等)
  4. 男性不妊

などが合理的な疑いとして認められています

一方で「自分と(子供の)容姿が似てない」程度の疑いでは異議申し立ては認められません。

"否認手続から独立した父子関係明確化のための法律"が出てくるのはまずこのタイミングです。

この法律合理的な疑いの証拠として遺伝子診断の結果を用いることを合法化しました。以前は証拠として使えるか曖昧(たいていは却下)だったのですが、この法律基準明確化とともに採用可能になったのですね。

ただしこのタイミングで提出する遺伝子診断の証拠には、母親(と子供)の同意必要となります同意のない診断結果を出しても証拠として採用されず、 2010年以降は遺伝的診断法に基づいて罰せられます

そしてこのプロセスがつつがなく進んだ結果、最終的に裁判所遺伝子診断による父子鑑定を命令します(既に遺伝子診断の結果が証拠として提出されていない場合)。

これは母親(と子供)の同意が無くてもできるため、これによってほぼ決着がつくわけです。

そして、この裁判所による鑑定命令もまた"否認手続から独立した父子関係明確化のための法律"によって制定されたものなのです。

初手秘密鑑定結果ぶっぱが封じられた一方で、丁寧に手続きを進めれば裁判所権限DNA診断による親子鑑定をしてもらえるという点で、バランスの取れた法律であると思います

以前は初手ぶっぱしても証拠採用されるのは厳しかったわけだから、異議申し立て側にとっては正味プラスでは?とも。

2016年のアレ

これもちょっと前提知識必要

前述の父親認定に対する異議申し立て成功裏完了し、法的父親から他人に変わるとどうなるでしょうか?

元法的父親過去遡及して養育等の父親の責務として支払ったもの等々への請求権を得ます

請求先は母親でも子供でもなく真の父親です。真の父親の払うべきものを立て替えてた扱いになるのですね。

そして真の父親は異議申し立て完了後、法律に従って裁判所が法的父親として指定します。法的父親説明で挙げた(c)のことです。

しかし……真の父親はいずこに?それがわからなければ請求も何もできません。

知っているのはきっと母親でしょう。聞きださなければなりません。真の父親候補……"推定上の父親"を。

しかしかし、2015年に「母親に"推定上の父親"について話すことを強制するのはプライバシー侵害である」という判例が出てしまいました。

はい詰んだー。

流石にそれはちょっと……ということで、父性の異議申し立てが成立した場合母親は"推定上の父親"について"重大な理由"が無い限り黙秘できないという法案が出てきたわけです。

まだ成立はしてなかったはずなので、この先どうなるかは分かりませんがね。コロナもいるし。

ログイン ユーザー登録
ようこそ ゲスト さん