「ORIGIN」を含む日記 RSS

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

2022-11-28

[]PS4 お姉チャンバラORIGIN

PS2SIMPLE2000シリーズお姉チャンバラ1,2を1作にリメイクしたもの・・・らしい

原作やってない、というかお姉チャンバラシリーズ自体これが初めてだから比較はできない

グラフィックちょっとしょぼいと思ったけど地球防衛軍といっしょで大量の敵をエフェクトだらけで切りまくるからまあこんくらいでいいのかなと

ただお色気っぽいのにそれを堪能できないゲームシステムなのはどうかと思う

イベントシーンではやたら胸元のアップになったりはするけど、棒立ちモデルの胸元だけアップしたってなんもうれしくないんよ

なんならアクション操作中にポーズしてフリーカメラで動かせる・・・と思いきや、左右回転だけでズーム上下回転もできないという体たらく

妹はダンロン3のマキに似てた

難易度ノーマルハードしか選べなくてノーマルでやった

4時間半でエンディングまで行った

何回もやりこむタイプシューティングげーとかに近い製品なのね、と

トロフィーとかやらないからここで終わりかな

普通にクリアしても設定資料コーナーが99%開示されないのはバグかと思った

普通1周クリアしたら見せるだろ・・・

マフラーグラフィックのせいで口元見えないし

うーん・・・まあ今となってはポリこれで出せないだろうし中古価格高いのもわかるけどゲームとしては物足りないな

ただタムソフトやればできるじゃんと思った

うたわれ斬のくそげーっぷりのイメージしかなかったけど、それなりには遊べた

ただキーアサインはクソだったなー

クリティカル攻撃ジャンプボタンと同時押しに割り当てるとかアホだろ

ジャンプ暴発しまくったわ

イベントシーンがセリフ単位で飛ばせないのはほんとうざいなー

ごとくシリーズでも思ったけど

とりあえず続けてZ2カオスプレイ

2022-11-08

マンガオススメを教えて欲しい

好きな漫画を挙げるので、適当に傾向を読み取っておすすめをしてほしい。



Thisコミュニケーション

SFアクションホラーサスペンス(又はそのパロディ)、ハーレムラブコメ(?)など色んな要素を持ったマンガ

主人公感情移入できる時もあれば、主人公を殺そうとする側に感情移入できる時もあるのがよい。

「第1話で、腹ペコ主人公が、食事をくれたコミュニティを守るため、能力を発揮して化物退治」とか、主人公世界を救うと叫ぶとか、少女たちの問題解決しつつ仲良くなっていくとか、どれもありがちなシーンやセリフなのだけど、それが異常な文脈に置かれているのがよい。


不死の猟犬

「復活」が存在する世界でのガンアクション

こんな大風呂敷畳めるのかと疑問だったけど、一応畳めていてスゴい。

逃がし屋の衣装コスプレ)とか物語上の必然性は全くないんだけど、作者が楽しそうでよい。

ワールドトリガーバタフライストレージもそうなんだけど、刀と銃が共存するSFアクションはよい。


竜女戦記

主婦が天下を取る物語、らしい。

戦国時代日本っぽいけど、鬼や竜がいたりするし、カタカナ語普通に出てくる。

どのキャラ人間的に強いところも弱いところがもあり、善玉・悪玉にはっきり分かれているのでもなく、感情移入できたりできなかったりするのが良い。

日本オマージュが多そうだけど、自分は詳しくないので拾いきれないのが残念。


宙に参る

遠隔焼香とか「つけもの」とか背広の裏地(?)がディスプレイになってるとか小ネタもよいし、魔女Tsueee要素もよい。

夫婦エピソードももっと読みたい。


かげきしょうじょ!!

宝塚音楽学校的な学校もの

脇役のスピンオフが軒並みよい。

特に詩織編。

かげきしょうじょ!!はちゃんシーズンゼロから読もう!(念のための注意書き)


ニセモノの錬金術師

呪術周りの設定がよい。

キャラがそれぞれ独自の信念や行動原理を貫いているのもよい。

続編も面白かった。


有害無罪玩具

哲学的思考実験の並ぶ表題作と「虚数時間の遊び」が好き。


図書館の大魔術師

王道を丁寧に進んでいるイメージ

自分の好みからすると、少し主人公が善人すぎるのだけど、周りに性格に難のあるキャラもたくさんいるので、よい。


峠鬼

古代日本神話SFファンタジー

「墨を飲む者」初登場回がすごく好き。


リュウマのガゴウ

「偽物と本物」とか「嘘と真実」みたいなのは、わりと好きなテーマ

群像劇っぽいのも好き。


第七女子会彷徨

ほのぼのとSFバランスがよい。


ーーー

ここから追記

(最終更新11/11


たくさんオススメありがとうございました。


オススメいただいた中で既読のもの

(ざっくり好きな順で並べようとしたけど、途中から適当です)

HUNTER×HUNTER

スピリットサークル

ヒストリエ

火の鳥

うしおととら

嘘喰い

最果てのソルテ

AI遺伝子

天国大魔境

亜人

刻刻

皇国の守護者

胎界主

水は海に向かって流れる

子供はわかってあげない

金魚王国崩壊

ゴールデンゴールド

イムリ

百万畳ラビリンス

ぼくらのよあけ

二月の勝者

チェンソーマン

虚構推理

ドキュンサーガ

三国志

ドラえもん

彼方のアストラ

双亡邸壊すべし

本田鹿の子本棚

ヴィンランドサガ

それでも町は廻っている

ヨコハマ買い出し紀行

寿司 虚空編

偽史山人

バトルグラウンドワーカーズ

町でうわさの天狗の子

賢い犬リリエンタール

タテの国

ドロヘドロ

PHYREN

EDEN

銀河の死なない子供たちへ

アリスと蔵六

オールドボーイ

そのへんのアクタ

ヨコハマ買い出し紀行

紅殻のパンドラ

GANTZ

ダーウィンゲーム

ONE PIECE

銃夢

メダリスト

ディスコミュニケーション

バーナード嬢いわく

死刑囚042

青野くんに触りたいから死にたい

うちのクラス女子ヤバい

ソフトメタルヴァンパイア

キングダム

四月は君の嘘

へうげもの

メイドインアビス

怪獣8号

辺獄のシュヴェスタ

銃夢

違国日記

久正人作品

志村貴子作品

萩原望都作品

竹内恵子作品

川原泉作品

とんがり帽子アトリエ

あかね

太臓モテサーガ

楳図かずお作品

キャプテン

劇光仮面

堕天作戦

マップス

蟲師

男爵にふさわしい銀河旅行

アルティス

お茶にごす

ストラヴァガンツ

ホーリーランド

フラジャイル

テレプシコーラ

ムーンライトマイル

九龍ジェネリックロマンス

メランコリア

エリア51

予告犯

1000円ヒーロー

パンプキンシザーズ

OL進化論

ヘテロギニアリンギティ

シオリエクスペリエンス

大丈夫倶楽部

宝石の国

懲役339年

ヴォイニッチホテル

蒼天のソウラ

珍遊記

セクシーボイスアンドロボ

茄子

PPPPPP

オススメいただいた中で未読のもの

複数あがっているものには☆)

panpanya作品全般 ☆

瞽女

栞と紙魚子の怪奇事件簿

富沢ひとし

キヌ六

西遊妖猿伝 諸星大二郎作品 ☆

フールナイト

竜と勇者配達

世界の終わりに柴犬

ヴァンパイア十字界

七都市物語

ORIGIN

PEACE MAKER

並愛混の独り言 (?)

数学ゴールデン

税金で買った本

虎鶫

ベアゲルター ☆

任侠転生

バイト

不死身のパイセン

煩悩西遊記

三丁目防衛軍

佐藤史生作品

みちかとまり

ふたつのスピカ

パーム ☆

カルバニア物語

月に吠えらんねぇ

あやつき

殺し屋やめたい!

フールナイト ☆

ニトリ

ブレッドウィザード

第七惑星用心棒

変幻退魔夜行 カルラ舞う!

華と修羅

ピンサロスナイパー

RIDEX

用心棒稼業

セキガハラ

真夏の夜のユキオンナ

ワールドエンブリオ

生と死のキョウカイ

もろびとこぞりて

令和のダラさん

東京カラス

瑠璃宝石

せんせいのお人形

望郷太郎

明日の敵と今日握手

股間無双

スキップ・ビート!

絢爛たるグランドセーヌ

星使いセレナ

バビロンまで何光年

Not Simple

SOUL CATCHER(S)

プリンタニアニッポン

螺旋じかけの海

ハルシオン・ランチ

カムライド

成恵の世界

うめモモさくら

シュトヘル ☆

八百森のエリー

魔女と野獣

いじめヤバイ

アルテ ☆

友達として大好き

マチネソワレ

ソアラ魔物の家

おひさま世界地図

リサの食べられない食卓

八木ナガハル作品 ☆

がらくたストリート

チキタ★GuGu

東京入星管理

ヘルク

潮が舞い子が舞い

一変世界

果ての星通信 ☆

古代戦士ハニワット

八百森のエリー

シマ・シンヤ作品

ブスに花束

エルフ狩猟士のアイテム工房

WOMBS ☆

未来人サイジョー

ビルドワールド ☆

ラグナクリムゾン ☆

ランドリオール

魔導の系譜

ボクラノキセキ

残機×99

惑星クローゼット

三文未来の家庭訪問

白馬のお嫁様

ヤコポコ

ライジング

モーメント

みあげた玉三郎

佐々木淳子作品

絶対安全剃刀

ゾンビ屋れい子

エクソシストを堕とせない

白暮のクロニクル

神さまがまちガえる

迷宮クソたわけ

土星マンション

転生貴族、鑑定スキルで成り上がる~弱小領地を受け継いだので、優秀な人材を増やしていたら、最強領地になってた~

往生際の意味を知れ!

バクちゃん

モリミテ

星をつくる兵器満天の星

鯨庭

魔女

はなしっぱなし

度胸星

きつねとたぬきいいなずけ

つれないほど青くて あざといくらいに赤い

そのあたり読んでる人ってちゃん自分で探せる人なんだよな

自分なりの探し方で見つからないようなのも知りたいのですよ。

未読作品の一覧でも分かるように、そこまで片っ端から読んでるわけでもないですし。

2022-10-16

NovelAIが重すぎるからローカル環境にNAI環境を構築する(2022年10月16日版)(追記あり)

せっかく課金したのにユーザが増えまくっているのか滅茶苦茶重くなっていて最悪。

から流出したモデルを使ってローカルでNAI環境を構築する。

ネットには情報もだいぶ転がってるけど陳腐化した情報があまりに多いため増田にまとめることにした。

しかたらこ記事もすでに陳腐化しているかもしれないが…単純に間違ってたらトラバで教えてほしい。

もちろん自己責任。この記事を見て導入した結果何かあっても増田は何も保証しない。

英語がわかる人はこっちを見た方が早いと思う。今は導入RTAができるくらい導入は楽になっている。

https://rentry.org/nai-speedrun

推奨環境

VRAMが2GB以上あるNVIDIA製のグラフィックボードがあればローカル環境を構築できる。

GPU世代はGTX700シリーズ以降。なので一昔前のミドル級ボードでも動作するらしい。

IntelオンボードGPUでも実行する方法があるらしい(stable_diffusion.openvino)が今回は割愛する。自分で探してね。

その他の推奨環境は以下の通り。

対応OSWindows7以上(と言うがM1Macでも動作する方法があるとかなんとか)

必要な空きストレージ容量:20GB以上

インメモリ:16GB以上(VRAMもたくさん必要だが起動時にメインメモリも大量に食う。WebUI起動時にタスクマネージャを見ているとよくわかる)

スマホしか持ってないような人やこういうのがよくわからない人はNovelAIを使った方が良いと思う。

今は重いけど、きっとそのうちみんな飽きてサーバも軽くなるかもしれないし。

(追記)NovelAIリソースを確保してサーバが軽くなったかリスクを背負ってまで導入しなくても良いか

手順1:PythonGitを導入する

(追記)Pythonは当然3系。最新の奴を入れれば問題無い。

導入方法はいちいち書かないけど、「python --version」や「git -v」で

正常にバージョン情報が出る(パスがきちんと通っている)ことはちゃん確認しよう。

手順2:Stable Diffusion web UI(AUTOMATIC1111)を導入する

Stable Diffusion web UIはStable Diffusionやそれをベースとした画像生成AIを利用するためのフロントエンド

その中でも特に開発が活発でデファクトスタンダードとなっているのがAUTOMATIC1111版だ。

導入したい適当ディレクトリに対してPowerShellなどで

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git

とやってやれば必要ファイルの導入が行われる。

なお、AUTOMATIC1111版は数時間単位コミットが行われるから

定期的に「git pull origin master」で更新しよう。

手順3:BitTorrent流出モデルダウンロードする

クライアントはqBitTorrentが一番楽だと思う。

ここにはさすがにmagnetリンクは書かないか各自ググって欲しい。

結構誤解されがちなことだが流出データ50GBを全部ダウンロードする必要は無い。

必要ファイルはanimefull-final-prunedディレクトリの中身とanimevae.ptから5GBちょっとくらいなんじゃないかな。

もし余裕があるならmoduleディレクトリの中身もダウンロードすればいいけど、ぶっちゃけ必要無いんじゃないか

手順4:ダウンロードした各ファイルリネーム・移動

まずはanimefull-final-prunedの中身のファイルリネーム

model.ckpt」を「animefinal-full-pruned.ckpt」のようなわかりやす名前にして、

「animevae.pt」を例えば「animefinal-full-pruned.vae.pt」のような拡張子以外は同じファイル名にする。

WebUI起動フォルダ配下の\models\Stable-diffusionリネームしたファイルを移動させれば配置はOK

ちなみにmoduleディレクトリの中身は\models\hypernetworksに移動させて使う。

それらのファイルを設定で適用させると画風が結構変わるがNovelAI再現とは関係無いみたいだ。

(追記)moduleディレクトリの中身の.ptファイルはhypernetworksという技術によって画風などを学習したものらしい。

すでに複数イラストレーターの画風を学習したptファイル作成されており議論を呼んでいる。

手順5:webui-user.batの中身に設定を追加する

自分グラボのVRAMが4GB未満の場合は「set COMMANDLINE_ARGS=」の後に

4GB未満の場合は「--medvram」、2GB未満の場合は「--lowvram」とパラメータを追加しておこう。

自分の持ってるグラボのVRAMがわからないときGPU-Zなどで調べよう。

またGTX1600系固有のバグ(単色の画像が出力される)があるらしいので

その場合は「--no-half-vae」もしくは「--no-half」や「--precision full」とパラメータを追加。

ちなみにパラメータに「--xformers」を追加してxformersを導入・使用すると

消費VRAMが減って画像生成処理時間も短縮されるので是非導入しよう。

画像からdanbooruタグAI調査するdeepdanbooruを利用する場合は「--deepdanbooru」を追加。

これらの設定は同時に複数適用させることもできる。例えば

set COMMANDLINE_ARGS=--medvram --xformers --deepdanbooru

のようになる。

手順6:webui-user.bat起動、設定変更

ターミナルPowerShellなどでwebui-user.batを起動しwebUIの初期導入と起動を行う。

過去には手動でCUDA等を導入する必要があったが、現在はこの初期導入でだいたいの導入が行われる。

ずいぶん楽にはなったがその分初期導入の時間結構長い。10分~20分くらいかかるかもしれない。

途中で導入処理がエラーで止まってしまった場合管理者権限で実行するなどして対応して欲しい。

起動ができたらSettingで以下の設定を変更してNovelAIに近づける。

Stop At last layers of CLIP modelを2に、

Eta noise seed deltaを31337にする。

これで設定は完了

おまけ:アスカテスト

設定を合わせて完全にNovelAIと同じ内容になったのかを確認するテストがある。

出力結果から海外じゃHallo Asuka Testなんて呼ばれている。

これは初期SEEDをはじめとする設定内容が完全に一致していれば同じ出力結果を得られる仕組みを利用している。

プロンプトの内容:masterpiece, best quality, masterpiece, asuka langley sitting cross legged on a chair

ネガティブプロンプトの内容:lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts,signature, watermark, username, blurry, artist name

サンプリングステップ数:28

サンプリング形式:Euler

CFG Scale(プロンプトの強度):12

初期Seed2870305590

この内容で見事下の画像と全く同じ画像が出力されれば合格だ。

https://i.imgur.com/Bfl5qJB.jpg

なお、このテストはAUTOMATIC1111のバージョンやxformersの適用状態によっては微妙に違う画像が出力されることがあるらしい。

xformersを適用させている増田環境だと確かに二つ並べると間違い探しレベルの違いがあった。

正直このテストクリアしなくても十分だと個人的には思う。

おまけ2:その他便利になる設定や拡張機能

「Booru tag autocompletion for A1111」を導入すればNovelAIのように自動danbooruタグを保管してくれる。

注意

画像生成AIモデルはStable DiffusionOSSのため派生結構多い。

自前で追加学習もできるため自前で学習した追加AIモデル4chanのような掲示板などで共有する人もいるらしい。

しかしそのようなモデルの中にウィルスのような悪意のある動作を行うものもあるらしい。

FBIペドフィリア一網打尽にするためにIPアドレスなどの個人情報を抜き出す動作を行うロリ特化AIモデル掲示板で配布していて

しかもそれには本物の児童ポルノ教師データとして使われている…などという都市伝説的な話が今界隈を賑わせている。

それが本当の話かどうかはわからないが、とにかく変なところからモデルダウンロードするのは危険なのでやめよう。

自己矛盾溢れる注意喚起かもしれないが…

2022-10-06

anond:20221002214201

ORIGINギャグタイミングというか間が合わない。

なんとなく。

テンポの悪さの半分くらいはアレのせいじゃないかなぁ。

2022-09-22

日本語の原郷」についての論文、取り下げ勧告を受ける

去年、「日本語の原郷」についての論文(Robbeets et al. 2021)が話題になった。増田は専門外の素人ながら疑問を持ったのでツッコミを入れたんだけど(anond:20211121124146)、今年の6月に入って専門家集団から「あの論文は取り下げろ」という反論論文が出ていた(Tian et al. 2022)。といっても、プレプリントサーバのbioRxivに置いてあるだけで、学術誌に掲載されたわけではないんだけど、まあいずれどこかには載るよね多分。

そういうわけで、反論論文の内容を(素人なりに)紹介していくよ!

そもそも誰が書いたの?

ふええ……知らない人ばっかりだよぉ……

22人の共同著者による論文だけど、その多くは中国人研究者。ほかは数人のヨーロッパ人中国人研究者については全然からない。漢字で書かれれば一人か二人は名前を聞いたことがある人がいるかもしれないけど、ラテン文字で書かれているので誰が誰やらさっぱりなんだよな……

ヨーロッパ人研究者のうち、ラッセルグレイ氏は聞いたことがある。20年くらい前に『ネイチャー』に印欧語族起源に関するレター載せてた人だ(Gray and Atkinson 2003)。ホセ・アロンソ・デ・ラ・フエンテ氏は以前ロベーツ氏の著書に辛辣書評書いてた人で、去年の増田でも引用した。

そしてトマ・ペラール氏は、日本では有名な研究者だ。彼は宮古島の北4キロに浮かぶ人口数十人の離島大神島方言について博士論文を書き、それが「母音あるいは声帯を震わせて出される音を含まない単語がある」という世界でも珍しい特徴を持った言語であることを明らかにした(Pellard 2009: 80–85;ペラール 2011: 28–29)。ペラール氏は母語フランス語だけでなく英語日本語でも論文や共著を発表していて(最近だとペラール 2021とか)、琉球諸語の言語復興についても発言しているので(ペラール 2013; 2015)、琉球諸語に関心を持って調べたことがあれば一度は名前を聞いたことがあるはずの人物だろう。

要するにこの反論論文には、そのへんの日本人よりはるか日本語に詳しい研究者が参加しているってこと。

言語的側面について

反論論文は、ロベーツ論文で挙げられている同根語(cognate words)が少なすぎると指摘する。

同根語というのは、「起源を同じくする単語」のことだ。ある言語から分かれた娘言語たちは、いずれも共通した同根語を(二次的に失ったのでなければ)持っているはずだ、というのが比較言語学の基本的な考え方だ(生物学でいう原始形質/祖先形質にあたる……と思う。多分)。もちろん、偶然の一致とか、言語場合借用語とかがあるので、言語学的な検討を行って「これは祖語から受け継がれた同根語である」というのを確定させて、それをもとに言語系統関係判断していく。

たとえば印欧語族だと、次のような対応関係が見いだせる(例はウィキペディアの「印欧語彙」のページから持ってきた)(*がはてな記法の一部と認識されちゃうっぽいので*で代用)。

-印欧祖語英語ラテン語サンスクリット語ハラ
pH₂tér-fatherpaterpitṛ́car
2dwóH₁twoduodvā́wu
ped-footpēspā́d-pe
*ék̂wos英語eohequusáśva-yuk

複数の語派(語族の下位区分)にわたって対応する語彙が存在することがわかると思う。これらの同根語が存在することで、「英語サンスクリット語は親戚なんだなぁ」というのがわかるわけだ(お墓に卒塔婆って置いてあるじゃん。あれに書いてあるのがサンスクリット語)(足で操作する機構を「ペダル」といったり歩行者デッキを「ペデストリアンデッキ」といったりするのは、英語のfootに対応するラテン語pēsから派生語なんだよね)(「父権主義」が「パターナリズム」になるのも、英語fatherに対応するラテン語がpaterだから。これがポルトガル語でpadreになり、そこから日本語に入って「ばてれん」になるわけですよ)。

ついでに日琉語族の表も示しておく(Vovin 2017)。基礎語彙において規則的に音韻対応しているのは、これらの一致が偶然ではなく日本語沖縄語が親戚であることの動かぬ証拠だ。

-標準語沖縄語(首里
これkorekuri
toritui
komekumi
場所tokorotukuru

しかしロベーツ論文は、ひとつ以上の語族でみられる同根語が317、2つ以上の語族でみられる同根語がわずか50、そして5つの語族で共有されている同根語はたったの2つに過ぎないという(Tian et al. 2022: 2)。思い出してほしいんだけど、ロベーツ論文テュルクモンゴルツングース朝鮮・日琉の計5語族が同一の起源を持つと主張しているのね。なのに5語族で共有されてる同根語はたったの2ってどういうこと? って話になるでしょ。全然トランスユーラシア語族」の証拠になってないじゃん。

っていうか、その50個の同根語リストの中には、ロベーツ氏自身が「これは借用語だよ☆」って書いてる単語が入ってるんだってさ。借用語は除くというのが比較言語学の基本なのに(借用語だと気づかずにリストアップしたならまだしも)借用語だとわかった上でリストアップするのヤバくない? そんなこと言ったら日本語英語の親戚になっちゃうよ? 大丈夫

反論論文の著者たちはこれに激おこぷんぷん丸になっていて、ロベーツ論文の「著者たちは彼ら自身歴史的言語比較原則無視し、証拠を彼らの必要にあわせて歪曲している」(Tian et al. 2022: 3)とまで断言している。そりゃ、借用語混じりのたった数十の同根語で「トランスユーラシア語族は、ありまぁす!」って言われたらそう言いたくもなるわな。

遺伝学・考古学的側面について

遺伝学的にも、ロベーツらの論文は「不当な仮定unjustified assumption)と、移民についてのありえそうな他の仮説を排除した選択モデリング」に基づいているとバッサリ。考古学証拠も「弱い」と切り捨てている。このへんは遺伝学や考古学に詳しいはてなー解説をお願いしたいところ。

結論

そして反論論文は、こう締めくくられている。

ロベーツ論文の結果を再現しようという我々の試みは[言語遺伝・考古の]3つすべての面で重要な不一致をみた。さらにいえば、ロベーツ論文はこれら3分野の研究成果を統合するために「三角測量」を用いたと主張するが、その「三角測量」とやらの手法定義記述もしていない。したがって、彼らの手法に従って3つの分野に関する訂正を組み合わせることも不可能だ。つまるところ、我々が行った3つのデータセットすべての再検討は、ロベーツ論文の主張を完全に崩壊させた。トランスユーラシア仮説は未実証である私たちはこの論文を取り下げるよう謹んで勧告する(Tian et al. 2022: 7)。

要するにアルタイ語族2.0は失敗したってことっすね。ロベーツ氏は「民族主義的な議題を持つ人々にとっては、自分の言語と文化の起源が国境の向こうにあるということは不快な真実だが、すべての言語と文化、人間は混じりあっている」って言ってたらしいけど、まずはご自分の仮説がボロボロだという不快真実に向き合ってほしい。

こんなガバガバ論文を載っけちゃった『Nature』については、まあ……仕方ないところもあるのかな? ちょっとでも言語系統かに関心を持っている人なら「これアルタイ語族2.0じゃん」と気づける内容だけど、理系雑誌編集者にその目利きを求めるのも酷かな……査読者選ぼうにも誰がこの分野の権威かすらわからんだろうからな……ただし『トランスユーラシア語族ガイドブック』なんてものをホイホイ出版したオックスフォード大学出版会テメーはダメだ。お前んとこは人文系研究書いっぱい出してるんだからアルタイ語族2.0くらい見抜けるだろうが!

なお、ペラール氏のツイッター(@ThomasPellard)を見たら「そもそも論証の基盤になってる語彙の出典が書いてないやんけ。これスタロスチンが作ったデータベースからコピペじゃね? っていうかいくつかの言語対応表に載ってないから同根語を検討できないんだけど?」という趣旨ツッコミをしていた(https://twitter.com/ThomasPellard/status/1536288665936306176)。あっ……(察し)

そういえば

そろそろ凱旋門賞ですが、タイトルホルダーくん楽しみですね。天皇賞(春)宝塚記念圧勝劇(+お姉ちゃん)ですっかりファンになりました。ロンシャンでも逃げ切ってほしいですね。ただ背負ってる期待が大きすぎるドウデュースくんにも勝ってほしい……武豊凱旋門賞に勝たせるために生まれてきた馬になったら胸熱すぎるでしょ……

あと先日のセントウルステークスは感動で泣きそうになりました。桜花賞のころから推してたので……(ソングラインちゃん安田記念戴冠おめでとう。BCマイル頑張れ!)。スプリンターズステークスで今度こそ待望のG1制覇を成し遂げてほしいですね……

ユキノビジンは! 引けませんでした!(すり抜けで夏服メジロドーベルサクラチヨノオーが来たのでまあ良し)

追記

ペラールさんの解説動画見た方が分かりやすい。

https://www.youtube.com/watch?v=UgXq14ag85Q

anond:20220922081214

これ見落としてましたわ。教えてくれて感謝こちらの方がわかりやすいのでみんなペラール氏の解説動画を見てクレメンス

専門外って日本語起源についてってだけで、比較言語学で博士取られてませんか??

博士号って持ってないからわからないんですけど食べられるんですか? ご飯粒よりおいしいんですか?

ここでもいくつか紹介されているようにトマ・ペラール氏は日本語でもいろいろ書いているしTwitterやAcademia.eduなどでも積極的情報研究を公開していて我々素人にとってはとてもありがたいです

ペラール、ヴォヴィン、ローレンスの3氏は色々academia.eduに上げてくれてて助かりますよね。ところで素人はいったい……うごごご。

有り難い要約だけど、最後の「アルタイ語族2.0」だから胡散臭い、という部分はやや迂闊かと。当該論文はそうでなさそう、というだけで真に画期的論文によりアルタイ語族復権することは可能性としてはあるよね

もちろんそれはそうです。ちゃんとした比較言語学的な手法で「アルタイ語族」の存在実証できるのならそれは歓迎すべきことで、その可能性は残されています。ただ、これまで数百年にわたって研究が続けられてきて熱心な擁護者も大勢いるのにまだ確固たる同系の証拠が出てきてない、というのは相当に重い事実ですよね……。ロベーツ氏は「民族主義的な議題を持つ人々」のことを揶揄してますけど、日琉語族の分類というのはまさにその「自分たちの言語はどこから来たのか」というルーツ探しの情熱に取り憑かれた人たちがいっぱい研究して、それでもなお結論が出ていないテーマなわけで(cf. 日本語の起源 - Wikipedia)。

日本日本語起源について野生の専門家増田意見を聞いてみたい

anond:20220922103201

増田はドシロートなんでなーんも独自見解は持ってないですが、古代ロマン的な観点からanond:20211121124146でも言及した大陸倭語仮説が面白そう(「大陸倭語」の存在はまだ定説にはなってないことに注意)。島嶼倭語(仮に「大陸倭語」の存在実証されない場合は日琉語)のUrheimatは五十嵐氏の指摘に沿えば近畿地方のあたり(多分四国ではない)。日琉語族列島半島にまたがって分布していて、そのうち大陸倭語が南進してきた朝鮮語族同化されたと考えると古代日本朝鮮半島との関わりに色々納得がいく(繰り返すように素人古代ロマンといくつかの論文に基づいて妄想したものです)。では仮に対馬海峡をまたいだ日琉語族存在実証されたとして、そのUrheimatは……どこでしょうね? なんもわからん

あ、トラバでやたらゲノム研究URL貼ってる人は、(もし同一人物なら)去年の議論血統言語系統混同したり(anond:20211121201022)、論文増田の内容を理解できてなかったりする(anond:20211121224311)ような人なので、マトモに相手する価値はないっすよ。一応ご忠告

参考文献

2022-08-15

[]はてなトップページ特定エントリーをuBlock Originで隠す方法を補足

[はてブ]uBlock Origin特定エントリーを隠す方法メモ anond:20180523215832

に対する補足。

このエントリーにこのようなブコメが付いていた。

これはてなトップページには効かないんだな

https://b.hatena.ne.jp/entry/364655312/comment/m7g6s

はてなトップページ(https://www.hatena.ne.jp/)ははてブの各種リストページとHTML構造が異なっていて、これに対応するには別途トップページ用の行を追加する必要がある。

増田エントリーブロックしたい場合はuBlock Originの設定に次のような行を追加する。anond.hatelabo.jpの部分を別ドメインに変えると別ドメインのページをブロックできる。

hatena.ne.jp##.EntryList_entryListItem__1vXtf:has(a[href*="anond.hatelabo.jp"])

タイトルに「転職」を含むエントリーブロックしたい場合は次のような行を追加する。

hatena.ne.jp##.EntryList_entryListItem__1vXtf:has-text(転職)

iOS版のはてブアプリにこの手のブロック機能が付いたみたいだからWebページに対してもそろそろはてな公式対応してくれるかもな。

2022-06-23

anond:20220618201725

安彦良和は「知識はあるけど想像力は低い」という人、富野真逆で「知識は乏しいが想像力が高い」人。そしてどちらかというと作家監督)に向いているのは後者なんだな。

漫画をずっと読んでた人は気付いていたんだろうけど、遅くともORIGIN映画見たときには、みんな理解しておくべきことだったんだと思うよ。

2022-06-05

uBlock Originの設定

自分で設定できることを知って快適なブックマークライフを遅れるようになった

b.hatena.ne.jp##.js-keyboard-selectable-item:has-text(弱者男性)
b.hatena.ne.jp##.js-keyboard-selectable-item:has-text(ジェンダー)
b.hatena.ne.jp##.js-keyboard-selectable-item:has-text(フェミ)
b.hatena.ne.jp##.js-keyboard-selectable-item:has-text(note.com/wakari_te)
b.hatena.ne.jp##.js-keyboard-selectable-item:has-text(twitter.com/63cities) 

2022-06-04

[][] 機動戦士ガンダム ククルス・ドアンの島

はじめに

自分は、ガンダムについてはMSや名台詞とかの知識はそれなりにあるけど(小学生当時にSDガンダムの全盛期だったので)、アニメ作品としてちゃんと観たシリーズは多くない。

TVシリーズだとSEED Destiny(SEEDは未視聴)、00全部(劇場版は未視聴)、AGE2世代目まで。映画だと逆シャアNT、閃ハサくらい。

漫画も(SD関連以外だと)昔ボンボンに載ってたF91やポケ戦のコミカライズくらいかな…(勿論ORIGINも未読)。

今作の感想

アムロがしゃべらない…!

いや、セリフが無いわけではもちろんないけど、主人公の割には寡黙。ガンダムって「会話劇」と言ってもいいくらセリフが多い印象があったので…。

作画が丁寧できれい

ホワイトベースクルージオン兵、島の子供たちなど登場人物が多いけど、どれも記号的に済ませずちゃんと描き分けられてる。

しかも、ひとつカットの中で動かないキャラがいない…!(画面にA・B・Cの3人が映ってたら、Aが喋ってる時にB・Cは棒立ちで動かない……ということがない)

ジブリ作品作画を思い出すとわかりやすいかもしれない(流石にあそこまでヌルヌルとは動かないが…)けど、

こういう作品テレビアニメだと滅多に無いし、劇場アニメでも「これが普通」と言えるほどは多くないと思う。

CGMS戦も違和感なし

3DCGロボットアニメだと、戦闘中に「いま何をやってるのかわからない」というシーンがあったりする(閃ハサやシンエヴァでも一部あった)けど、

今作ではそういうことはなかった(戦闘自体比較スローテンポからというのもあるかもしれない)。

セイラさんがお嬢様口調

「○○ですわよ」とか言ってて「こういう喋り方をする人だったのか…! ガンダム出会ってから、30年以上知らなかった…」と衝撃を受けました…。

最後

演出はやや古めかしいところもあるが、それが逆に「わかりやすさ」「とっつきやすさ」としても機能しているかもしれない。

(「出﨑演出3連発」みたいなシーンでは場内から笑いが漏れてた)

全体の雰囲気世界名作劇場みたいだし、「巨大ロボットに乗って戦う」という点を除けば普通戦争映画と変わらないし、

「今までガンダムというものに触れてこなかった」という人でもすんなり観られる作品ではないだろうか。

「凄い傑作だから絶対見に行くべき」とまでは言わないが、じんわりとした面白さで、見て損はない作品だと思う。

あと、

「ドアンは(直そうと思えばすぐに直せるのに)、なぜ電気を使わなかった(使わせなかった)のか?」というのがわかんなかった…

2022-04-30

パソコンの大先生求む

Windows10デュアルディスプレイ環境で実現したいことがあってあれこれ試行錯誤してるんだけれども、いまいち良いソリューションが出てこない。

セカンダリモニタにメインモニタタスクトレイと同じものを表示させたい

アプリケーション起動時、セカンダリモニタウィンドウ最初から立ち上がるようにしたい。できればアプリケーションごとに個別に設定したい

環境

Windows 10 pro

デュアルモニタ環境(メイン2560*1440 サブ1680*1050)

PC用途

主にFPSゲームボーダーレスウィンドウフルスクリーンでメインモニタプレイしている。

あとは普通の人と同じようにネットサーフィン。たまにOffice

セカンダリモニタにメインモニタタスクトレイと同じものを表示させたい

DiscordOriginSteam・TeamSpeak3・Epic・Tweetenを常時起動していて、サブモニタ側に配置している。あとはChromeをメインとサブに1ウィンドウずつ。

メインモニタフルスクリーンゲームプレイしていると、タスクトレイDiscordアイコンが見えず、誰かに鼻息配信していないかが分かりづらかった。オーバーレイもすべてのゲームで出るわけでもない。

調べると、サブモニタにもタスクバーを表示させてそのままメインモニタタスクバードラッグしてサブモニタタスクバーと交換すると思っていたことに近いことが実現できた。

とはいえ普段自分の目はメインモニタにあるので、やっぱりメインモニタの右下にもタスクトレイが欲しい。そしてこの問題に行き当たった。

アプリケーション起動時、セカンダリモニタウィンドウ最初から立ち上がるようにしたい。できればアプリケーションごとに個別に設定したい

アプリケーションを起動したときに必ずメインモニタで立ち上がるのが地味に面倒くさい。

Steamウィンドウタスクバーピン留めから(起動ではなくタスクトレイ待機状態から)呼び出したとき、メインモニタウィンドウが出現する。それなりの種類のアプリケーションをわざわざ左にドラッグするのは面倒くさい。

ちなみに、以前のDiscordだけはスタートアップ時にきちんとセカンダリモニタで立ち上がってくれた。今はどういう理由スタートアップ自体しなくなって、手動起動時にWindowsへの変更のポップアップが出るようになった。そしてウィンドウはメインモニタに生まれ出る。

まあそんなにPCシャットダウンをしないのであまり大きく困っているわけではないけれど……

2022-04-21

よく使うgitコマンド

git branch --all

git switch

git switch -

git diff

git diff --cached

git cherry-pick

git reflog

git commit --amend

git add . -p

git pull

git show

git fetch && git merge origin/master

git merge

git merge --abort

git rebase -i HEAD^^^^^

git tag --delete

git tag -d

git log

git log --graph

git push

git push --force-with-lease

git push --force

git push --tags

git push --delete

git push --set-upstream

git status

2022-04-17

はてブからTwitterTogetter排除したら何もなくなった

タイトルそのまま。

はてブにあまりにもTwitterTogetterネタが多すぎるから、uBlock Originのマイフィルターに下の2行を追加した。

hatena.ne.jp##.js-keyboard-selectable-item:has(a[href*="twitter.com"])
hatena.ne.jp##.js-keyboard-selectable-item:has(a[href*="togetter.com"])

そうしたら、トップページ話題が3つか4つ、酷いときには1つか2つしか表示されなくなった。

はてブは、感じていたとおりTwitterTogetterを燃焼させるための燃料になってるんだなと実感した。

2022-04-14

apexまだ流行ってるのかな。だいぶ前ハマってて1日12時間はやってた。origin版での総プレイ時間は2600時間だった。Steam版でサブ垢でやってたから3000時間は超えると思う。実力は、ほぼソロマスター帯まで行ったけどプレデターにはなれなかった。昨日久々にやってみたら色々変わってたけど、何となくカラダが覚えてて普通にプレイ出来た。モザンビークめっちゃ強くなってるし新武器も追加されてるし新キャラも大量に追加されてて最初の3時間ぐらいは楽しかった。でもすぐ飽きてつまらなくなった。discordのフレに3年間ずっとapexやり続けてる人がいて、他サーバーの人と組んでここ何シーズンプレデター維持し続けてるらしい。ストリーマーでもないのに一つの事やり続ける人ってスゴいなあって感じた。

2022-04-01

抑圧の反動でぶっこわれた俺

まあ俺はガキのころそれはもう厳しく厳しく、何でも制限されてきた

お菓子駄目、ジャンクフードも駄目、ジュースも駄目、ゲーム駄目、おもちゃ駄目、テレビ駄目、漫画駄目、音楽駄目、お小遣い無し、行事におけるプレゼントも無し

金にも余裕がある家なのにだ、勉強と絵のない本だけしかなかった

から大人になって一人暮らし始めてから俺はやれなかった事を全部やってる

まずお菓子ジャンク、もうそりゃ食う、吐くまで食う、吐いてまた食う、ジュースを飲む飲む飲むたくさん飲む

生食えよ増田が「もうやめろ、悪かったそこまで食うとは思わなかった」って止めるくらいには食べたい物を延々と延々と口に放り込む、そうしないと満たされない

新しいおもちゃも当時買えなかったおもちゃ関係なく沢山買って、全部やりきれないのにSteamOriginセール時にゲームを買いに買ってレトロゲーム衝動的に買って、やる、やりまくる

休みの日は電子書籍で買いまくった漫画を読み漁りCS放送やネトフリでアニメを狂ったように見る、サブスクサービスで片っ端から音楽聴く

歳に似合わないおもちゃに囲まれ休みに一日中ゲームして一人遊ぶ、そうしないと落ち着けない

唯一叶わないのは金、仕事の給金入った側から生活費以外を全部捧げてるからはいつもカツカツだ

そんな俺を親は見て悲しそうな顔してた、なんで悲しむんだよ悲しいのは俺だ、あんたらの望む人間になれなかったのが悲しいだろうが、俺は「子供」を楽しめなかったことが悲しいんだ、みんなと同じことができなかったことが悲しいんだ

みんなの輪に入れずなにもできなかったんだ、今楽しんでも返ってこないんだ

もう一人自立して暮らしてる俺にまで道を強制するのか?たのむ、やめてくれ、俺は欲望に溺れて死にたいんだ

どれだけやっても満たされないから、満たされるまでやりたいんだ、満たされるなら破滅してもいいんだよ

俺はでかい子供だ、泣きわめくでかい子供だ、こんな醜い生き物があんたらの育てた末路だ、人のせいにしかできない狂った生物

子供の頃の様ないい子ちゃんのまま大人になれなかった落伍者

2022-01-27

anond:20220127130213

固有名詞も訳せ」と言っていたのはトールキンだったかと思うけど、俺は好き。

Yoshitsune Minamotoではなく、Origin家のRight Scriptureと名乗って欲しい。

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-13

anond:20220113214953

uBlock Origin大事なところでコケから(わりと大事サイトが無作法だったりするから)怖くて使えん場面が結構あるんだよな

anond:20220113183246

広告ブロックは uBlock Origin 使っててブラウザ自体の同期用アカウントログイン(ChromeならGoogleFirefoxならFirefoxアカウント)してるなら「クラウドストレージサポート有効にする」にチェックを入れるとボタンポチポチクラウドにUP/DLできて便利 (ただし自動で同期してくれるわけでないのでちょっと不便)

安彦さんは、

自分でやるとヒットしないんだよね

絵は天才的に上手いんだけど

アリオンは当たった方なんだろうか

ヴィナスとかスゴいんだけどね…

ゴーグで失敗したと思ってアニメ業界から撤退して漫画家になった気がする

ゴーグも作画的にというか、物語もいいと言えばいいんだけど、

なんかあんまり記憶がないというか、起伏がないというか、大風呂敷広げない

富野大風呂敷広げて、意味深に思わせといてボカシてそのままにする気がする

というか、それはエヴァもそうだし、ツインピークスというかキューブリックっぽいのかも

本当は裏側は空っぽなのに、なんかスゴいものが詰まってるように見せる

オズの魔法使いじゃないけど

安彦さんは根が真面目なんだろう、その裏側にも詰めてしまうので、

大風呂敷とかビッグマウスの人ではないんだよね

からガンダムORIGINもやっぱり蛇足感が否めないというか、

富野ガンダムとの整合性には苦労したんだろうけど、

まり裏側を詰めすぎると、裏側が見えないけど期待だけデカかった頃に比べると、

なんか、その歴史の裏側がこんなに小さくまとまってていいんだろうか、

こじんまりした感じに思えてしま

そうならないように苦労しただろうというのは見えるのだけど、

所詮フィクションだし、漫画ではなくアニメなので、動きや見た目が重視されるわけで、

ORIGIN富野ガンダムに比べると絵は格段に綺麗だけど、凄く地味に思える

あと、ゴーグのデザイン見てると、やっぱりガンダムデザインは安彦さんだよね

大河原氏はファーストガンダムの時点ではガンダムデザインに貢献してない

本人も最近になって言うようになってきたけど、僕が貢献したのはザクです、だよね

玩具会社意向も含めてああまとめ上げたのは本当にすごいと思う

ガンキャノンは明らかに宇宙の戦士だったけど、

多分、モビルスーツという名前通り、本当はテッカマンとかHALOみたいなサイズで、

それをスポンサーに巨大ロボットしろと言われたんだろうけど、

名前そのまんまにした方がかえってその違和感が味になってしまった感がある

偶然も手伝って、汚いテレビ作画を一部修正して編集して劇場版にするとか、

あいうのは安彦さんにはなんとなくできないというか、

全部やり直しそうなタイプに思える

そういえば、いしかわじゅんだったかに安彦漫画酷評?されてたけど、

なんとなく言いたいことは分からなくもないところもあって、

はいわゆるベタ漫画表現というか、流線があったり、ベタウニフラッシュがあったり、

ジョジョのゴゴゴゴゴみたいな露骨な擬音を使ったり、そういうのがない

アニメーターだからでもあるんだろうけど、アニメ作画を描いてる感がある

当然、中割の動画はない

しかし、アニメーターの漫画は酷い、特にコマ割りが酷い、という法則があって、

例えば結城信輝のヴェルバーサーガ?だったか、絵は上手いけどコマ割りが酷い

というか、もっと酷い人が普通で、アニメーターの人はコマの中の絵をちゃんと描こうとしてしま

それよりもコマ割りが重要というか、漫画文法重要というか、

文法ちゃんとしていれば、コマの中の絵は意外といい加減でもいいというか、

から漫画天才的に上手いのに、一枚絵はう〜んという漫画家は逆にまた多い気がする

アニメーターは一枚絵は素晴らしいのに、漫画がう〜んである

そういう感じなので、安彦氏の漫画漫画文法には沿ってるし、コマ割りはおかしくない

しかに独特な乾いた感じがあるが、それは個性というものだろう

宮崎駿ナウシカでさえ、コマ割りというか漫画文法的にう〜んはときどきある

コマの順番が混乱する箇所があった気がする

漫画家コマの順番を重視して、読者が読む順番に困らないようにして、

コマの中の絵はどうせ読み飛ばされるのだから、ある程度手を抜いて描くものである

そのへんを両立させてしまったのが大友AKIRAとかなんだろう

あの時代漫画作画コスト肥大してしまった一因だと思ってる

そして、それが今のパソコン時代になって楽になっているかというと、

未だに液タブにガリガリ描いて腱鞘炎にまでなってたりするというのが、

意外と現状だったりするのではないだろうか

それが、最近はてブでも賑わっていたAIによる作画で、

例えば、手塚治虫自分過去原稿学習させれば、

あとは手塚氏がマルチョンを描いただけでAIが描いてくれる、

みたいになる日が来るのかもしれないが、

なんとなくだが、それはそれで納得できない絵が出てくる気がするのである

悪夢のような絵が出てくるのではなく、AIちゃんとした絵を出力するのだろうけど、

それでもワナビーとして絵を描いてる自分がそれで納得するのか甚だ疑問なのである

やっぱり、自分が頭の中に描いたものが手を通して出力される、

というのが楽しいというか、肝なのであって、

例えば、AI自動作曲してくれて、それが素晴らしい曲だとして、

その自動作曲の指示を自分がしたとしても、

それが自分脳内イメージと直結しているわけではないわけで、

それはアドリブ演奏した曲の方がどこか劣っているとしても、

心情的に?というか、敵わないのではないか、と思うのである

オチはない

2022-01-11

ガンダムORIGIN10話を日本語字幕で見てたら、

「うーん安倍さんの家も焼かれてるん」

とか表示されて笑った

自動生成の日本語字幕面白い

2022-01-10

新成人に対して、我々は旧成人である

まりザクIIに対して旧ザクのようなものである

子供の頃は、あのパイプがないゲッソリした顔、トゲのない肩を格好悪く思えた

しかし、ORIGINを観ていると、なかなかの思い出補正に思える

旧ザクもまんざら悪くはない

2021-12-20

anond:20211220115523

いや、この増田批判もっともだよ。なぜなら吉本興業国連SDGs広報をしているから。

もちろん、この漫才は「表現の自由」の範囲内だけど、吉本興業は「たかお笑い」の企業でいれないほど、国連政府と組んでるから

良いとこ取りだけできるわけないというだけの話でしょ。

SDGs広報担当企業所属芸能人社員?)がSDGs目標と相反する見せ物を公共放送で行ったことは問題があるんじゃないの。

具体的には、「10: 人や国の不平等をなくそう」の中の目標に反する。外務省サイトから抜粋する。

https://www.mofa.go.jp/mofaj/gaiko/oda/sdgs/statistics/goal10.html

10.2

2030年までに、年齢、性別障害人種民族出自宗教、あるいは経済的地位その他の状況に関わりなく、全ての人々の能力強化及び社会的経済的及び政治的包含を促進する。

By 2030, empower and promote the social, economic and political inclusion of all, irrespective of age, sex, disability, race, ethnicity, origin, religion or economic or other status


以下は、今年11月末の「SDGs取り組み事例」インタビュー記事から抜粋

https://www.ecoplaza.gr.jp/sdgs_t_company/15_yoshimoto/

―――吉本興業SDGsに取り組むきっかけは何だったのですか?

宮本さん:2016年国連広報センターさんからSDGs」の啓発に協力して欲しいとお声掛けを頂いた事がきっかけです。

当時は、SDGsのことを知る社員ほとんどいませんでしたが、エンターテインメント提供する企業として、社会的役割を果たす必要があるのではないか

私たちしかできないこともあるのではないかと言う事で、会社をあげてSDGsの推進に取り組むことになりました。


繰り返すけど、こういう今じゃ危うい感じのお笑いをしたかったら、そもそも吉本国連SDGs広報をやらなきゃいいだけの話なので。

もう、吉本興業をただのお笑い企業とみなせないぐらい政府とズブズブになってるでしょ。

吉本所属白河桃子とか民間議員になってて「働き方改革実現会議」に出席してたとか誰も知らないのかな。

検索してたら、2019年記者会見騒動の頃の増田が出てきたわ。

https://anond.hatelabo.jp/20191103140925


追記コメント勘違いしている人がいるけど、吉本興業は単なる事例じゃなくて国連広報センターと長い付き合いです。

口頭契約問題以前以後含めて吉本企業以上にSDGs広報手がけてる企業は無いんじゃないかな。

https://www.unic.or.jp/news_press/info/26262/

少し調べればわかると思うけど、吉本公式サイトSDGs広報をやってること大々的に書いてるからね。

それでこの体たらくは無いでしょという話。

まあ俺はそもそも吉本興業2019年労働問題騒動の時にSDGs広報クビになっておくべきだったと思ってるので。

まあ、問題を受けての吉本の「経営アドバイザリー委員会 中間取りまとめ」の座長日本会議とベッタリらしいし、

テレビ局国連右翼方面でも都合の良い存在批判しないんだなという感じだけど。

大企業こわー

2021-12-12

anond:20211212114319

Windows10Firefoxでμblock originだけど、1回目はほぼ100%弾かれて、再度投稿すると通る。

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