はてなキーワード: ORIGINとは
PS2のSIMPLE2000シリーズのお姉チャンバラ1,2を1作にリメイクしたもの・・・らしい
原作やってない、というかお姉チャンバラシリーズ自体これが初めてだから比較はできない
グラフィックはちょっとしょぼいと思ったけど地球防衛軍といっしょで大量の敵をエフェクトだらけで切りまくるからまあこんくらいでいいのかなと
ただお色気っぽいのにそれを堪能できないゲームシステムなのはどうかと思う
イベントシーンではやたら胸元のアップになったりはするけど、棒立ちモデルの胸元だけアップしたってなんもうれしくないんよ
なんならアクション操作中にポーズしてフリーカメラで動かせる・・・と思いきや、左右回転だけでズームも上下回転もできないという体たらく
妹はダンロン3のマキに似てた
何回もやりこむタイプのシューティングげーとかに近い製品なのね、と
普通にクリアしても設定資料コーナーが99%開示されないのはバグかと思った
うーん・・・まあ今となってはポリこれで出せないだろうし中古価格高いのもわかるけどゲームとしては物足りないな
ただタムソフトやればできるじゃんと思った
うたわれ斬のくそげーっぷりのイメージしかなかったけど、それなりには遊べた
クリティカル攻撃をジャンプボタンと同時押しに割り当てるとかアホだろ
ごとくシリーズでも思ったけど
好きな漫画を挙げるので、適当に傾向を読み取っておすすめをしてほしい。
SFアクション、ホラー・サスペンス(又はそのパロディ)、ハーレム系ラブコメ(?)など色んな要素を持ったマンガ。
主人公に感情移入できる時もあれば、主人公を殺そうとする側に感情移入できる時もあるのがよい。
「第1話で、腹ペコ主人公が、食事をくれたコミュニティを守るため、能力を発揮して化物退治」とか、主人公が世界を救うと叫ぶとか、少女たちの問題を解決しつつ仲良くなっていくとか、どれもありがちなシーンやセリフなのだけど、それが異常な文脈に置かれているのがよい。
こんな大風呂敷畳めるのかと疑問だったけど、一応畳めていてスゴい。
逃がし屋の衣装(コスプレ)とか物語上の必然性は全くないんだけど、作者が楽しそうでよい。
ワールドトリガーやバタフライストレージもそうなんだけど、刀と銃が共存するSFアクションはよい。
戦国時代日本っぽいけど、鬼や竜がいたりするし、カタカナ語も普通に出てくる。
どのキャラも人間的に強いところも弱いところがもあり、善玉・悪玉にはっきり分かれているのでもなく、感情移入できたりできなかったりするのが良い。
日本史オマージュが多そうだけど、自分は詳しくないので拾いきれないのが残念。
遠隔焼香とか「つけもの」とか背広の裏地(?)がディスプレイになってるとか小ネタもよいし、魔女Tsueee要素もよい。
脇役のスピンオフが軒並みよい。
呪術周りの設定がよい。
続編も面白かった。
自分の好みからすると、少し主人公が善人すぎるのだけど、周りに性格に難のあるキャラもたくさんいるので、よい。
「墨を飲む者」初登場回がすごく好き。
「偽物と本物」とか「嘘と真実」みたいなのは、わりと好きなテーマ。
群像劇っぽいのも好き。
ーーー
最果てのソルテ
天国大魔境
胎界主
水は海に向かって流れる
ぼくらのよあけ
二月の勝者
彼方のアストラ
双亡邸壊すべし
ヴィンランドサガ
寿司 虚空編
タテの国
PHYREN
そのへんのアクタ
バーナード嬢いわく
死刑囚042
怪獣8号
違国日記
あかね噺
劇光仮面
堕天作戦
お茶にごす
ストラヴァガンツァ
1000円ヒーロー
シオリエクスペリエンス
懲役339年
PPPPPP
猫瞽女
キヌ六
フールナイト
ヴァンパイア十字界
並愛混の独り言 (?)
税金で買った本
虎鶫
任侠転生
裏バイト
不死身のパイセン
三丁目防衛軍
みちかとまり
パーム ☆
月に吠えらんねぇ
あやつき
殺し屋やめたい!
フールナイト ☆
クニトリ
変幻退魔夜行 カルラ舞う!
華と修羅
ピンサロスナイパー
RIDEX
セキガハラ
真夏の夜のユキオンナ
生と死のキョウカイ
令和のダラさん
せんせいのお人形
絢爛たるグランドセーヌ
星使いセレナ
Not Simple
螺旋じかけの海
シュトヘル ☆
八百森のエリー
魔女と野獣
アルテ ☆
友達として大好き
ヘルク
潮が舞い子が舞い
一変世界
果ての星通信 ☆
八百森のエリー
ブスに花束を
WOMBS ☆
ランドリオール
魔導の系譜
残機×99
白馬のお嫁様
モーメント
みあげた玉三郎
エクソシストを堕とせない
神さまがまちガえる
迷宮クソたわけ
転生貴族、鑑定スキルで成り上がる~弱小領地を受け継いだので、優秀な人材を増やしていたら、最強領地になってた~
往生際の意味を知れ!
モリミテ
鯨庭
はなしっぱなし
つれないほど青くて あざといくらいに赤い
せっかく課金したのにユーザが増えまくっているのか滅茶苦茶重くなっていて最悪。
だから流出したモデルを使ってローカルでNAIの環境を構築する。
ネットには情報もだいぶ転がってるけど陳腐化した情報があまりに多いため増田にまとめることにした。
もしかしたらこの記事もすでに陳腐化しているかもしれないが…単純に間違ってたらトラバで教えてほしい。
もちろん自己責任。この記事を見て導入した結果何かあっても増田は何も保証しない。
英語がわかる人はこっちを見た方が早いと思う。今は導入RTAができるくらい導入は楽になっている。
https://rentry.org/nai-speedrun
VRAMが2GB以上あるNVIDIA製のグラフィックボードがあればローカル環境を構築できる。
GPUの世代はGTX700シリーズ以降。なので一昔前のミドル級ボードでも動作するらしい。
IntelのオンボードGPUでも実行する方法があるらしい(stable_diffusion.openvino)が今回は割愛する。自分で探してね。
その他の推奨環境は以下の通り。
対応OS:Windows7以上(と言うがM1Macでも動作する方法があるとかなんとか)
メインメモリ:16GB以上(VRAMもたくさん必要だが起動時にメインメモリも大量に食う。WebUI起動時にタスクマネージャを見ているとよくわかる)
スマホしか持ってないような人やこういうのがよくわからない人はNovelAIを使った方が良いと思う。
今は重いけど、きっとそのうちみんな飽きてサーバも軽くなるかもしれないし。
(追記)NovelAIがリソースを確保してサーバが軽くなったからリスクを背負ってまで導入しなくても良いかも
(追記)Pythonは当然3系。最新の奴を入れれば問題無い。
導入方法はいちいち書かないけど、「python --version」や「git -v」で
正常にバージョン情報が出る(パスがきちんと通っている)ことはちゃんと確認しよう。
Stable Diffusion web UIはStable Diffusionやそれをベースとした画像生成AIを利用するためのフロントエンド。
その中でも特に開発が活発でデファクトスタンダードとなっているのがAUTOMATIC1111版だ。
導入したい適当なディレクトリに対してPowerShellなどで
「git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git」
なお、AUTOMATIC1111版は数時間単位でコミットが行われるから
定期的に「git pull origin master」で更新しよう。
クライアントはqBitTorrentが一番楽だと思う。
ここにはさすがにmagnetリンクは書かないから各自ググって欲しい。
結構誤解されがちなことだが流出データ50GBを全部ダウンロードする必要は無い。
必要なファイルはanimefull-final-prunedディレクトリの中身とanimevae.ptだから5GBちょっとくらいなんじゃないかな。
もし余裕があるならmoduleディレクトリの中身もダウンロードすればいいけど、ぶっちゃけ必要無いんじゃないか?
まずは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ファイルが作成されており議論を呼んでいる。
自分のグラボの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」を追加。
のようになる。
ターミナルや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
https://i.imgur.com/Bfl5qJB.jpg
なお、このテストはAUTOMATIC1111のバージョンやxformersの適用状態によっては微妙に違う画像が出力されることがあるらしい。
xformersを適用させている増田の環境だと確かに二つ並べると間違い探しレベルの違いがあった。
「Booru tag autocompletion for A1111」を導入すればNovelAIのように自動でdanbooruのタグを保管してくれる。
画像生成AIモデルはStable DiffusionがOSSのため派生が結構多い。
自前で追加学習もできるため自前で学習した追加AIモデルを4chanのような掲示板などで共有する人もいるらしい。
しかしそのようなモデルの中にウィルスのような悪意のある動作を行うものもあるらしい。
FBIがペドフィリアを一網打尽にするためにIPアドレスなどの個人情報を抜き出す動作を行うロリ特化AIモデルを掲示板で配布していて
しかもそれには本物の児童ポルノが教師データとして使われている…などという都市伝説的な話が今界隈を賑わせている。
去年、「日本語の原郷」についての論文(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- | father | pater | pitṛ́ | pācar |
2 | *dwóH₁ | two | duo | dvā́ | wu |
足 | *ped- | foot | pēs | pā́d- | pe |
馬 | *ék̂wos | 古英語eoh | equus | áśva- | yuk |
複数の語派(語族の下位区分)にわたって対応する語彙が存在することがわかると思う。これらの同根語が存在することで、「英語とサンスクリット語は親戚なんだなぁ」というのがわかるわけだ(お墓に卒塔婆って置いてあるじゃん。あれに書いてあるのがサンスクリット語)(足で操作する機構を「ペダル」といったり歩行者デッキを「ペデストリアンデッキ」といったりするのは、英語のfootに対応するラテン語pēsからの派生語なんだよね)(「父権主義」が「パターナリズム」になるのも、英語fatherに対応するラテン語がpaterだから。これがポルトガル語でpadreになり、そこから日本語に入って「ばてれん」になるわけですよ)。
ついでに日琉語族の表も示しておく(Vovin 2017)。基礎語彙において規則的に音韻が対応しているのは、これらの一致が偶然ではなく日本語と沖縄語が親戚であることの動かぬ証拠だ。
- | 標準語 | 沖縄語(首里) |
これ | kore | kuri |
鳥 | tori | tui |
米 | kome | kumi |
場所 | tokoro | tukuru |
しかしロベーツ論文は、ひとつ以上の語族でみられる同根語が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制覇を成し遂げてほしいですね……
ユキノビジンは! 引けませんでした!(すり抜けで夏服メジロドーベルとサクラチヨノオーが来たのでまあ良し)
これ見落としてましたわ。教えてくれて感謝。こちらの方がわかりやすいのでみんなペラール氏の解説動画を見てクレメンス。
博士号って持ってないからわからないんですけど食べられるんですか? ご飯粒よりおいしいんですか?
ここでもいくつか紹介されているようにトマ・ペラール氏は日本語でもいろいろ書いているしTwitterやAcademia.eduなどでも積極的に情報や研究を公開していて我々素人にとってはとてもありがたいです
ペラール、ヴォヴィン、ローレンスの3氏は色々academia.eduに上げてくれてて助かりますよね。ところで素人とはいったい……うごごご。
有り難い要約だけど、最後の「アルタイ語族2.0」だから胡散臭い、という部分はやや迂闊かと。当該論文はそうでなさそう、というだけで真に画期的な論文によりアルタイ語族が復権することは可能性としてはあるよね
もちろんそれはそうです。ちゃんとした比較言語学的な手法で「アルタイ語族」の存在が実証できるのならそれは歓迎すべきことで、その可能性は残されています。ただ、これまで数百年にわたって研究が続けられてきて熱心な擁護者も大勢いるのにまだ確固たる同系の証拠が出てきてない、というのは相当に重い事実ですよね……。ロベーツ氏は「民族主義的な議題を持つ人々」のことを揶揄してますけど、日琉語族の分類というのはまさにその「自分たちの言語はどこから来たのか」というルーツ探しの情熱に取り憑かれた人たちがいっぱい研究して、それでもなお結論が出ていないテーマなわけで(cf. 日本語の起源 - Wikipedia)。
増田はドシロートなんでなーんも独自の見解は持ってないですが、古代ロマン的な観点からはanond:20211121124146でも言及した大陸倭語仮説が面白そう(「大陸倭語」の存在はまだ定説にはなってないことに注意)。島嶼倭語(仮に「大陸倭語」の存在が実証されない場合は日琉語)のUrheimatは五十嵐氏の指摘に沿えば近畿地方のあたり(多分四国ではない)。日琉語族が列島と半島にまたがって分布していて、そのうち大陸倭語が南進してきた朝鮮語族に同化されたと考えると古代の日本と朝鮮半島との関わりに色々納得がいく(繰り返すように素人が古代ロマンといくつかの論文に基づいて妄想したものです)。では仮に対馬海峡をまたいだ日琉語族の存在が実証されたとして、そのUrheimatは……どこでしょうね? なんもわからん。
あ、トラバでやたらゲノム研究のURL貼ってる人は、(もし同一人物なら)去年の議論で血統と言語系統を混同したり(anond:20211121201022)、論文や増田の内容を理解できてなかったりする(anond:20211121224311)ような人なので、マトモに相手する価値はないっすよ。一応ご忠告。
[はてブ]uBlock Originで特定のエントリーを隠す方法のメモ anond:20180523215832
に対する補足。
はてなのトップページ(https://www.hatena.ne.jp/)ははてブの各種リストページとHTMLの構造が異なっていて、これに対応するには別途トップページ用の行を追加する必要がある。
増田のエントリーをブロックしたい場合はuBlock Originの設定に次のような行を追加する。anond.hatelabo.jpの部分を別ドメインに変えると別ドメインのページをブロックできる。
hatena.ne.jp##.EntryList_entryListItem__1vXtf:has(a[href*="anond.hatelabo.jp"])
タイトルに「転職」を含むエントリーをブロックしたい場合は次のような行を追加する。
iOS版のはてブアプリにこの手のブロック機能が付いたみたいだからWebページに対してもそろそろはてなが公式に対応してくれるかもな。
自分で設定できることを知って快適なブックマークライフを遅れるようになった
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)
自分は、ガンダムについてはMSや名台詞とかの知識はそれなりにあるけど(小学生当時にSDガンダムの全盛期だったので)、アニメ作品としてちゃんと観たシリーズは多くない。
TVシリーズだとSEED Destiny(SEEDは未視聴)、00全部(劇場版は未視聴)、AGEの2世代目まで。映画だと逆シャア、NT、閃ハサくらい。
漫画も(SD関連以外だと)昔ボンボンに載ってたF91やポケ戦のコミカライズくらいかな…(勿論ORIGINも未読)。
いや、セリフが無いわけではもちろんないけど、主人公の割には寡黙。ガンダムって「会話劇」と言ってもいいくらいセリフが多い印象があったので…。
ホワイトベースクルーやジオン兵、島の子供たちなど登場人物が多いけど、どれも記号的に済ませずちゃんと描き分けられてる。
しかも、ひとつのカットの中で動かないキャラがいない…!(画面にA・B・Cの3人が映ってたら、Aが喋ってる時にB・Cは棒立ちで動かない……ということがない)
ジブリ作品の作画を思い出すとわかりやすいかもしれない(流石にあそこまでヌルヌルとは動かないが…)けど、
こういう作品はテレビアニメだと滅多に無いし、劇場用アニメでも「これが普通」と言えるほどは多くないと思う。
3DCGのロボットアニメだと、戦闘中に「いま何をやってるのかわからない」というシーンがあったりする(閃ハサやシンエヴァでも一部あった)けど、
今作ではそういうことはなかった(戦闘自体が比較的スローテンポだからというのもあるかもしれない)。
「○○ですわよ」とか言ってて「こういう喋り方をする人だったのか…! ガンダムと出会ってから、30年以上知らなかった…」と衝撃を受けました…。
演出はやや古めかしいところもあるが、それが逆に「わかりやすさ」「とっつきやすさ」としても機能しているかもしれない。
(「出﨑演出3連発」みたいなシーンでは場内から笑いが漏れてた)
全体の雰囲気は世界名作劇場みたいだし、「巨大ロボットに乗って戦う」という点を除けば普通の戦争映画と変わらないし、
「今までガンダムというものに触れてこなかった」という人でもすんなり観られる作品ではないだろうか。
「凄い傑作だから絶対見に行くべき」とまでは言わないが、じんわりとした面白さで、見て損はない作品だと思う。
「ドアンは(直そうと思えばすぐに直せるのに)、なぜ電気を使わなかった(使わせなかった)のか?」というのがわかんなかった…
Windows10、デュアルディスプレイ環境で実現したいことがあってあれこれ試行錯誤してるんだけれども、いまいち良いソリューションが出てこない。
・セカンダリモニタにメインモニタのタスクトレイと同じものを表示させたい
・アプリケーション起動時、セカンダリモニタにウィンドウが最初から立ち上がるようにしたい。できればアプリケーションごとに個別に設定したい
Windows 10 pro
デュアルモニタ環境(メイン2560*1440 サブ1680*1050)
主にFPSゲームをボーダーレスウィンドウかフルスクリーンでメインモニタでプレイしている。
あとは普通の人と同じようにネットサーフィン。たまにOffice。
Discord・Origin・Steam・TeamSpeak3・Epic・Tweetenを常時起動していて、サブモニタ側に配置している。あとはChromeをメインとサブに1ウィンドウずつ。
メインモニタでフルスクリーンでゲームをプレイしていると、タスクトレイのDiscordのアイコンが見えず、誰かに鼻息を配信していないかが分かりづらかった。オーバーレイもすべてのゲームで出るわけでもない。
調べると、サブモニタにもタスクバーを表示させてそのままメインモニタのタスクバーをドラッグしてサブモニタのタスクバーと交換すると思っていたことに近いことが実現できた。
とはいえ普段自分の目はメインモニタにあるので、やっぱりメインモニタの右下にもタスクトレイが欲しい。そしてこの問題に行き当たった。
アプリケーションを起動したときに必ずメインモニタで立ち上がるのが地味に面倒くさい。
Steamのウィンドウをタスクバーピン留めから(起動ではなくタスクトレイ待機状態から)呼び出したとき、メインモニタにウィンドウが出現する。それなりの種類のアプリケーションをわざわざ左にドラッグするのは面倒くさい。
ちなみに、以前のDiscordだけはスタートアップ時にきちんとセカンダリモニタで立ち上がってくれた。今はどういう理由かスタートアップ自体しなくなって、手動起動時にWindowsへの変更のポップアップが出るようになった。そしてウィンドウはメインモニタに生まれ出る。
タイトルそのまま。
はてブにあまりにもTwitterとTogetterのネタが多すぎるから、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"])
apexまだ流行ってるのかな。だいぶ前ハマってて1日12時間はやってた。origin版での総プレイ時間は2600時間だった。Steam版でサブ垢でやってたから3000時間は超えると思う。実力は、ほぼソロでマスター帯まで行ったけどプレデターにはなれなかった。昨日久々にやってみたら色々変わってたけど、何となくカラダが覚えてて普通にプレイ出来た。モザンビークめっちゃ強くなってるし新武器も追加されてるし新キャラも大量に追加されてて最初の3時間ぐらいは楽しかった。でもすぐ飽きてつまらなくなった。discordのフレに3年間ずっとapexやり続けてる人がいて、他サーバーの人と組んでここ何シーズンもプレデター維持し続けてるらしい。ストリーマーでもないのに一つの事やり続ける人ってスゴいなあって感じた。
まあ俺はガキのころそれはもう厳しく厳しく、何でも制限されてきた
お菓子駄目、ジャンクフードも駄目、ジュースも駄目、ゲーム駄目、おもちゃ駄目、テレビ駄目、漫画駄目、音楽駄目、お小遣い無し、行事におけるプレゼントも無し
金にも余裕がある家なのにだ、勉強と絵のない本だけしかなかった
だから大人になって一人暮らし始めてから俺はやれなかった事を全部やってる
まずお菓子やジャンク、もうそりゃ食う、吐くまで食う、吐いてまた食う、ジュースを飲む飲む飲むたくさん飲む
一生食えよ増田が「もうやめろ、悪かったそこまで食うとは思わなかった」って止めるくらいには食べたい物を延々と延々と口に放り込む、そうしないと満たされない
新しいおもちゃも当時買えなかったおもちゃも関係なく沢山買って、全部やりきれないのにSteamやOriginのセール時にゲームを買いに買ってレトロゲームも衝動的に買って、やる、やりまくる
休みの日は電子書籍で買いまくった漫画を読み漁りCS放送やネトフリでアニメを狂ったように見る、サブスクサービスで片っ端から音楽を聴く
歳に似合わないおもちゃに囲まれ、休みに一日中ゲームして一人遊ぶ、そうしないと落ち着けない
唯一叶わないのは金、仕事の給金入った側から生活費以外を全部捧げてるから金はいつもカツカツだ
そんな俺を親は見て悲しそうな顔してた、なんで悲しむんだよ悲しいのは俺だ、あんたらの望む人間になれなかったのが悲しいだろうが、俺は「子供」を楽しめなかったことが悲しいんだ、みんなと同じことができなかったことが悲しいんだ
みんなの輪に入れずなにもできなかったんだ、今楽しんでも返ってこないんだ
もう一人自立して暮らしてる俺にまで道を強制するのか?たのむ、やめてくれ、俺は欲望に溺れて死にたいんだ
どれだけやっても満たされないから、満たされるまでやりたいんだ、満たされるなら破滅してもいいんだよ
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
広告ブロックは uBlock Origin 使っててブラウザ自体の同期用アカウントにログイン(ChromeならGoogle、FirefoxならFirefoxアカウント)してるなら「クラウドストレージのサポートを有効にする」にチェックを入れるとボタンポチポチでクラウドにUP/DLできて便利 (ただし自動で同期してくれるわけでないのでちょっと不便)
自分でやるとヒットしないんだよね
絵は天才的に上手いんだけど
アリオンは当たった方なんだろうか
ヴィナスとかスゴいんだけどね…
ゴーグで失敗したと思ってアニメ業界から撤退して漫画家になった気がする
なんかあんまり記憶がないというか、起伏がないというか、大風呂敷広げない
富野は大風呂敷広げて、意味深に思わせといてボカシてそのままにする気がする
というか、それはエヴァもそうだし、ツインピークスというかキューブリックっぽいのかも
本当は裏側は空っぽなのに、なんかスゴいものが詰まってるように見せる
オズの魔法使いじゃないけど
安彦さんは根が真面目なんだろう、その裏側にも詰めてしまうので、
だから、ガンダムORIGINもやっぱり蛇足感が否めないというか、
あまり裏側を詰めすぎると、裏側が見えないけど期待だけデカかった頃に比べると、
なんか、その歴史の裏側がこんなに小さくまとまってていいんだろうか、
そうならないように苦労しただろうというのは見えるのだけど、
所詮フィクションだし、漫画ではなくアニメなので、動きや見た目が重視されるわけで、
ORIGINは富野ガンダムに比べると絵は格段に綺麗だけど、凄く地味に思える
あと、ゴーグのデザイン見てると、やっぱりガンダムのデザインは安彦さんだよね
大河原氏はファーストガンダムの時点ではガンダムのデザインに貢献してない
本人も最近になって言うようになってきたけど、僕が貢献したのはザクです、だよね
玩具会社の意向も含めてああまとめ上げたのは本当にすごいと思う
多分、モビルスーツという名前通り、本当はテッカマンとかHALOみたいなサイズで、
それをスポンサーに巨大ロボットにしろと言われたんだろうけど、
名前そのまんまにした方がかえってその違和感が味になってしまった感がある
偶然も手伝って、汚いテレビの作画を一部修正して編集して劇場版にするとか、
ああいうのは安彦さんにはなんとなくできないというか、
全部やり直しそうなタイプに思える
そういえば、いしかわじゅんだったかに安彦漫画が酷評?されてたけど、
なんとなく言いたいことは分からなくもないところもあって、
要はいわゆるベタな漫画的表現というか、流線があったり、ベタウニフラッシュがあったり、
ジョジョのゴゴゴゴゴみたいな露骨な擬音を使ったり、そういうのがない
アニメーターだからでもあるんだろうけど、アニメの作画を描いてる感がある
当然、中割の動画はない
しかし、アニメーターの漫画は酷い、特にコマ割りが酷い、という法則があって、
例えば結城信輝のヴェルバーサーガ?だったか、絵は上手いけどコマ割りが酷い
というか、もっと酷い人が普通で、アニメーターの人はコマの中の絵をちゃんと描こうとしてしまう
それよりもコマ割りが重要というか、漫画の文法が重要というか、
文法がちゃんとしていれば、コマの中の絵は意外といい加減でもいいというか、
だから、漫画が天才的に上手いのに、一枚絵はう〜んという漫画家は逆にまた多い気がする
そういう感じなので、安彦氏の漫画は漫画の文法には沿ってるし、コマ割りはおかしくない
たしかに独特な乾いた感じがあるが、それは個性というものだろう
宮崎駿のナウシカでさえ、コマ割りというか漫画の文法的にう〜んはときどきある
コマの順番が混乱する箇所があった気がする
漫画家はコマの順番を重視して、読者が読む順番に困らないようにして、
コマの中の絵はどうせ読み飛ばされるのだから、ある程度手を抜いて描くものである
そのへんを両立させてしまったのが大友AKIRAとかなんだろう
あの時代は漫画の作画コストが肥大してしまった一因だと思ってる
そして、それが今のパソコン時代になって楽になっているかというと、
未だに液タブにガリガリ描いて腱鞘炎にまでなってたりするというのが、
意外と現状だったりするのではないだろうか
みたいになる日が来るのかもしれないが、
なんとなくだが、それはそれで納得できない絵が出てくる気がするのである
悪夢のような絵が出てくるのではなく、AIがちゃんとした絵を出力するのだろうけど、
それでもワナビーとして絵を描いてる自分がそれで納得するのか甚だ疑問なのである
というのが楽しいというか、肝なのであって、
例えば、AIが自動作曲してくれて、それが素晴らしい曲だとして、
それが自分の脳内のイメージと直結しているわけではないわけで、
オチはない