  |
はてなキーワード: アンチパターンとは
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
342あとで/2882users Amazonプライムビデオで観てほしいおすすめの人気映画42選 ～編集部厳選～ : 映画ニュース - 映画.com
256あとで/1375users 真面目なプログラマのためのディープラーニング入門 | 新山 祐介 | github
233あとで/1341users 実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 | ほげさん | Zenn
185あとで/949users ソフトウェア開発の見積もり入門 | hakotensan | Zenn
183あとで/1374users ロシアのウクライナ侵攻の背景を読み解く | 東京大学 | 鶴見太郎
180あとで/968users Google が公開している、より良いデータ分析のためのガイドブック「Good Data Analysis」で、データ分析の要所が簡潔にまとめられていて感動した | hurutoriya
178あとで/1408users フォントが大好物な人に朗報🎉 MORISAWA BIZ UDゴシックとUD明朝がオープンソースになったぞ！！ | coliss
169あとで/887users 高木浩光さんに訊く、個人データ保護の真髄 ——いま解き明かされる半世紀の経緯と混乱 | 一般財団法人情報法制研究所出版部
168あとで/958users はじめに – アルゴリズムとデータ構造大全 | take44444 | github
166あとで/1232users ガラケーしか使えないデジタル音痴だった私が「GISでデータ分析」できるようになるまでの話｜NHK取材ノート｜note
156あとで/728users セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
153あとで/1187users iPhone・Macの標準アプリ「メモ」のディープな使い方 | デジタルシニア
153あとで/987users なんとなくプレイしてもそこそこ囲碁のルールがわかるようになる「ぷよ碁」 | Gigazine
150あとで/926users 30代後半になって初めて発信活動を始めたら人生が変わった話 - Qiita
144あとで/1584users ロシアの攻勢と新世界の到来 (2022/02/26): 侵略成功時のロシアの予定稿 全訳 - 山形浩生の「経済のトリセツ」
143あとで/1309users 鶏むね肉を驚くほどしっとりさせた台湾料理「ジーローファン」の作り方【ネクスト魯肉飯】 - メシ通 | ホットペッパーグルメ
141あとで/786users RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料 | Rebi | Zenn
140あとで/1336users 「依頼された仕事をやらない人」は、なぜあれほど言われても、仕事をしないのか | 安達 裕哉 | Books＆Apps
139あとで/891users 「ウクライナ」(2) 小泉悠・東京大学先端科学技術研究センター専任講師 2022.3.9 | YouTube
139あとで/698users テーブル設計の考え方とやり方 [入門編] | 増田 亨 | SpeakerDeck
137あとで/733users オードリー・タン氏が日本人のために「デジタルとITはまったく別物」と語る理由 | ビジネス+IT
137あとで/765users AWS、オンラインロールプレイングゲームでAWSのソリューション構築を学べる「AWS Cloud Quest」公開。実際にプレイしてみた | Publickey
137あとで/909users 手軽に負荷テストができるツール「Taurus」がスゴい | tonchan1216 | Zenn
131あとで/1149users クレカを100万円使って解脱に至るための曼荼羅 - 本しゃぶり
123あとで/587users システム運用アンチパターン | O'Reilly Japan
121あとで/896users 【引越しやることリスト】事前に役立つ知識を50個まとめた | SPOT
119あとで/831users 背景合成アプリ「Shoost」レビュー 映画のワンシーンのような「いい感じ」の絵を手軽に作れる | PANORA
118あとで/724users 電子メール送信に関する技術 | Yuuki Takahashi | Zenn
116あとで/555users 1on1の「話したいことは特にないです」を解決する ~ 共感から始まる関係性改善のススメ ~ / How to solve rejection on 1on1 | 面川泰明 | SpeakerDeck
116あとで/1088users 「強いエンジニアは結局休日に勉強してるじゃん」って思うけど - spice picks
自分は完全にリスナー側なので「こうすれば伸びる」とかは全く言えないが
個人勢を多く視聴していいて伸び悩んでいる人達は割と似ているところがあるなあと思ってまとめてみる
興味を持って見に行っていきなり病みツイを見てあっやばい人だサヨナラとなってしまう
喋り続けるのは特殊スキルなので無理して虚無を作ると見てる方も辛い
元々4000時間を達成するためのテクニック？として1時間って枠が定着した感じですが
アーカイブ追うのも大変だしネタが切れたら終わっても良いと思う
興味を持って見に行って長時間アーカイブがズラっと並んでるとその時点でサヨナラになってしまう
布教でリツイートしてもYouTubeまで飛んでもらうのはハードルが高い
英語などができると海外リスナーが獲得できて一気に伸びるのでやりがちですが
コメント英語ばかりになり日本人新規リスナーが入りにくくなってしまった推しが何人もいます
無事YouTube収益化条件を達して嬉しくなって開設する方多いですが
まだその段階だと同時接続のほとんどが緑になり新規がコメントしづらい状態になることが多いです
金銭面を充実させたい場合FANBOXの高額プランを用意する方が可能性あります
↓参考
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。
オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。
そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。
また、凡庸なプログラマが継承で実現したいと思うことは、ほとんどの言語でより適切な手段が存在する。
継承を誤って用いるプログラマが多いにも関わらず、実は継承の使い時ははっきりしている。以下は、一定水準のプログラマならば、誰でも答えられる質問である。これに答えられないプログラマは不勉強を恥じるべきである。
答えられない人、自分の答えが正解の内容と一致しているか即座に判断できない人は、継承を使うべきではない。医学知識ゼロの素人が外科手術をするようなものであり、非常識極まりない。
リスコフの置換原則は、オブジェクト指向の文脈で言えば、以下のようになる。
「Baseを基底クラス、DerivedをBaseの任意の派生クラスとするとき、Base型として生成されたオブジェクトをDerived型のオブジェクトに置き換えても問題なく振る舞うようにしなければならない」
ゴミプログラマが継承を使いたがる理由の99%は、以下である。
こんなもん、何も難しいこと考えずとも、以下のどちらかの方法で解決する。
自分を棚に上げて言うんだが、経験上、他人の気持ちや人格を尊重できて、自分の衝動を抑えて、行動を顧みることができる、そんな奴世の中にほぼいないと思うんだが？？？
ほぼ居ないはまあ言い過ぎだけど、個人の性格とか育ち(謎)云々が悪いって話じゃなくて、能力的に無理な人がかなり居ると思うんだよな。
書いてあること読み取るだけのセンター現代文ですらロクに解けない奴がゴロゴロしてるのに、不文律とか勘とかいう理不尽極まりない概念が跋扈してる現代のナマの人間のコミュニケーションなんて、多くの人にとって手に負えるわけがない。
その手に負えない舞台の上で、性衝動を抑えながら、自分にはない経験をよく知って、語彙を磨いて厳選して、アンチパターンもある程度学習しておいて、ミスしそうになったら後からフォローもして……ってめっちゃ高度な技術だと思うんだよな。
DSMやIDCに定義された疾患とそのグレーゾーンには「治療が必要」みたいな多少の同情が得られるのに、ことそこから外れた(広義の)コミュ障に関しては「雨と埃だけ食って生きてろ」みたいな言葉が飛んで反発するなってのも無理があると思う。
とはいえセクハラは被害者の人生を壊しまくってる社会悪だから根絶しないといけないし、どうすりゃいいんだろうな。
特に考えがあるわけじゃないから、いつものはてな仕草で「人間には解決できないからテクノロジーの力で～」とか「社会の構造そのものを変えて～」とか「性欲が悪いから早く総去勢と人工子宮を～」とか言って適当に考えてるフリして終わっとくわ。
正確に言うと、重度の障害を持った子供が産まれてきたときに、特別養子縁組が認められず、そのまま育てることになるリスクが怖い。
平均より大きく劣った能力を持って産まれた子供に対し、愛情を向け続けられる気がしない。
もちろん親として他の子供と比較してしまうことはアンチパターンだが、
「なんでうちの子は…」という気持ちを消化して、親としての義務や規範を果たせる気がしない。
ただでさえ大変と言われている育児だが、障害児の場合は更にコストが高くなると言われている。
例えば自閉スペクトラム症の児童が高頻度で引き起こすパニック発作の対応をするのは保護者。
自分の場合は育児をサポートしてくれる親族もいないので、自分の可処分時間は皆無になるだろう。
相談相手がいれば多少は楽になるのかもしれないが、レアな事象である以上、身の回りに同じ境遇の家族はまずいない。
観測可能な範囲のオンライン上にある障害児の保護者コミュニティは、育児を前向きに捉えるために、
ほとんど共感不可能な価値観がまかり通っていると感じる。あのノリに自分が馴染むのは難しい。
最後に、その子本人が楽しく暮らせるようになるための支援をして送り出す自信がない。
「うちの子は、別に立派な人になんかならなくても、元気に暮らしてくれたらそれでいい」というのは多くの保護者が達する境地だが、
劣った能力しか授けられなかった己の生と、劣った能力の自分を産んだ親を恨まずに生きていける気がしない。
つまりその元気に暮らすという最低限度のラインすら満たしてあげられる気がしない。
まとめると、自分も子供もつらい状態を必死で維持し続ける、そういう人生になってしまう可能性が怖い。
思いつくままに色々書いたが、結局の所、自分の中にこびりついた差別意識がこの悩みの原因だと思う。
だから、仮に障害を持たない子供が産まれたとしても、似たような機序で自分と自分の子供は苦しむことになるだろう。
産まれてもいない子供とその育児に対してこんなネガティブな感情をいだいてしまう自分は、そもそも子供を設けるべきでは無いのだろう。
嘆かわしいことに、多くの人が「同じコードは関数やクラスなどを用いて共通化しなければいけない」と信じているが、これはプログラミングにおけるアンチパターンである。
たとえば、
という2つの処理は、どちらも元の数値を1.1倍する処理であり、完全に同一のコードであるが、これは共通化すべきではない。意味が異なるからだ。
これらを共通化すると、たとえばシステム全体で金利を5%に変更しなければいけなくなったとき、消費税を加える処理すべてに影響を及ぼしてしまう。つまり、保守性が下がっている。
元々、DRYの原則は「情報の重複」を無くすためのものだし、SRP（Single Responsibility Principle）も「モジュールの責務（言い換えればそのモジュールを変更する理由）を1つにすべし」というものだ。つまり、どちらも実装に関するものではなく、より抽象的な「意味」や「役割」に関するものだ。
どうして、こういうことが起こってしまうのか。理由は単純で、ほとんどの（自称）プログラマは馬鹿だからだ。
ほとんどのプログラマは基礎学力が著しく低く、プログラミング言語の書き方を覚えるのに精一杯で、実装と意味を分離するとかそんなことは考えられない。というか、彼らは自分が書いているソフトウェアの機能を日本語で説明することすらできない。
これは教える側もそうで、知能と知恵が足りていないから
本当に迷惑なんだ。
おっぱいがない女子のパイズリの何が問題かというと、技術がないとか、気持ちよくないということではなく、根本的に「無理」なことなんだ。
おっぱいのない女子は、巨乳の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「パイズリをした経験のない人は典型的にこういうことをしがち」という例であるが、おっぱいのない女子はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「おっぱいのない女子は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
本当に迷惑なんだ。
パンティがない奴の何が問題かというと、技術がないとか、恥を知らないということではなく、根本的に「頭がおかしい」ことなんだ。
パンティのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「パンティを履いた経験のない人は典型的にこういうことをしがち」という例であるが、パンティのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「パンティのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
本当に迷惑なんだ。
センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。
センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
普通の人なら、何も考えず以下のような実装をするだろう。フィールドの定義とデータが分かれているのは、ユースケースによってフィールドが可変だからだ。
[
{fieldName: "id", title: "id", type: "number"},
{fieldName: "name", title: "商品名", type: "text"},
{fieldName: "price", title: "値段", type: "number"}
]
[
{id: 1, name: "商品A", price: 100},
{id: 2, name: "商品B", price: 200},
{id: 3, name: "商品C", price: 300}
]
ところが、センスのない奴はたとえば以下みたいな意味不明な実装をナチュラルに行う。
[
{id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"},
{id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"},
{id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"},
{id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"}
]
一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。
センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界が常人と異なるから、矯正は無理だし、チームにいると非常に迷惑なんだ。だから、プログラマにはならないでくれ。
これがすべてで、他の話(でルール説明以外の部分)は将棋知らない人向けだとしてもあんまりしっくりこないかな。
書かれている通り、棋士はセオリーとか大局観とか手の流れとかによって、「読み」の量を減らしたりとか
読みきれないときに、直感的に選択することを実現しているわけだけど、
31銀は、いわゆる流れとか大局観としてはややアンチパターン。
ただ、攻めの手順とか、ここまでの流れ的にこう指すかなぁっていう手順の先をかなりの量読んだ結果、
「あまり良くなる順が見えない」「激しくなって制御しにくくなる」ということから
残った手を指した。
膨大な変化手順があり、プロでも大局観や直感、流れ、などを駆使して指す中盤に対し
「読む」という、その量とスピード、それをやろうとする精神力が唯一無二なんだと思う。
もともと能力が天才的なことに加えて明らかに中盤に時間を使っているというのもそれを裏付けるというか、興味深いところ。
つまりコンピューターがやるように(もちろん実際のコンピューターよりは遥かに「ありえる手」を限定しているが)、
これを実現してるのは、読みの量とスピード。
小説執筆経験を含め、創作経験は無かった。仕事で文章を書くことはあるが、クリエイティブなものではない。
読書家と言えるほど読む量は多くないし、映画・アニメマニアなどに比べれば全く観ていないが、フィクションは好きな方だと思う。
投稿締切が今日だったので、まだわからない。1次選考の結果は7月で、最終選考の結果発表は10月らしい。
結果が出た後だと、良くても悪くてもまとめる気にならないし、変に情報を取捨選択してしまうと思うので、このタイミングで書き残しておく。
小説・映画・漫画・アニメなどの作品をみてストーリーについて「こうすればもっと面白くなるのに」と思う時が多かった。
あわよくばいろんな人に読んでほしいし、収入源にもなればと思った。ただ、今は普通に小説を出しても売れない時代。アニメ・ドラマ・映画化などのメディアミックスの選択肢が多いライトノベルは、まだマーケティング的に強いと思った。電撃を選んだのは、単純に最大手だから。
絵が描けない（ありがち）。
物語の作り方を勉強しようと思い、脚本についての本をいくつか読む。ここ最近の受賞作品や売れている小説を読む。ネットの情報も調べる。
その後、まず100字以内でどんな物語かをあらわす文章をたくさん作る（ログラインと言うらしい）。この時点で早速、創作の難しさに気づく。思いつくのはありきたりなストーリーばかり。
ゼロからアイデアを出していると、似たようなものばかりになることに気づく。自分がどんなストーリーを考えるのが得意かわからないし、この段階ではある程度多様性があった方がいいと思い、SF、現代青春もの、戦記物、みたいにカテゴリでわけて、その中で考えることにする。それぞれのカテゴリの中でまだマシと思えるログラインを、800字程度のあらすじに膨らませる。
なんとかかんとか、4本分ひねり出し、この段階で一度友人に見せてみる。わりと恥ずかしかった。
友人に見せた4本のあらすじがそれなりに評判が良かったので、キャラや世界観の設定を深めていく。ここで、あらすじごとに考えやすいものと考えにくいものがあることに気づく。わりとスムーズにキャラや設定を考えることができた2本を使って、書き始める。
いざ書き始めて、これは長期戦になるであろうことを瞬時に悟る。自分は夏休みの宿題を直前まで放置するタイプだが、それでは到底太刀打ちできない。そこで、毎日起きてから3時間を執筆にあてることにする。3時間にしたのは、仕事との兼ね合いと、これ以上は創作力が続かないから。土日だけは3時間x2スロットの6時間にした。また、毎日同じ小説を書いていると自分自身がその物語に飽きることに気づく。自分が心から楽しめないのはまずいだろう。なので、二作品を一日交代で書き進める。
電撃大賞には、全体で80ページ以上130ページ以内という規定がある。自分の執筆ペースは、エピソードの流れが頭にできていればだいたい3時間で8ページぐらい。文字数にすると約6000〜8000字。だがこの「流れが頭にある」というのがくせ者で、最初に作った800字程度のあらすじだけでは、一つ一つのエピソードが書き進められない。つまり、エピソードごとに、もっと細かなプロットが必要だった。なので、3時間の執筆時間以外でも、通勤時間を使って次に書くエピソードの流れを頭で考えて、スマホにメモを取っていった。
また、書いている途中は一度も推敲せずに一気に最後まで走るのが良いというアドバイスがネットにあったのでそれに従う。結果的にこれはよかったと思う。とりあえず終わらせるのがモチベーション的に非常に大事だと思った。特に序盤〜中盤あたりを書いているときは、本当に最後までたどり着けるか結構不安になった。その辺で行ったり来たりするのはあまり良くないのではないかと思う。
月末に二作分のドラフトが完成する。この段階ではまだ人に見せられるようなものではなく、第ゼロ稿というところか。
ドラフトが完成してから、1週間寝かせて、再度最初のページから直していく。
上に書いたとおり、一切途中に推敲は入れていないので、矛盾が生じていたり、伏線をまったく張っていない設定がたくさんある。他にも、安直でつまらない会話や、適当な人物や風景描写、冗長な文だらけ。まずは全体を見てそれらを洗い出し、一つ一つ潰していく。
細部の推敲と並行して、改めてプロットを見直す。物語全体の流れがほぼ確定したので、章立てを決める。各章内に、盛り上がる部分・落ち着く部分があって、最後に引きがあるかを確認する。うまくまとまっていない章については、エピソードを追加・削除・移動。また、全体をとおしてテーマに一貫性があるか、最後まで引っ張る謎や問題があるか、改めて確認する。
これも平日3時間、休日6時間のスケジュールで進める。「自分はこの小説を完成させられる」という自信のようなものがようやく出てくる。
第一稿が完成する。プロットを見てもらった友人に完成版を見せる。かなり恥ずかしかった。
1週間ほどで友人から感想をもらう。自分では気づかなかった有益な視点が多くもらえる。特に、物語の最初のテーマが放置されて途中から別のものに変わってしまっていたり、せっかく魅力的なキャラがいるのにそのキャラのエピソードがほとんどなかったり、そういうのこそ案外自分では気づかない。
感想を踏まえて、ぶれている部分を直したり、キャラのエピソードを追加したり、不要なキャラを削除したりする。
月末に再度友人に見せる。これぐらいになると、あまり恥ずかしくもなくなる。
漢字の使い方を見直したり、改行の入れ方を変えたりと、読みやすさやテンポに気をつけて変更していく。
脚本術の本に、「審査員はランダムにページを開いてそこが面白いかどうか見る」と書いてあった。なので、自分でもそれを試した。これは良かったと思う。通しで読んでいると良くも悪くも物語に入り込んでいくので、細かい欠点に気が向かなくなる。あと、無意識に自分が気になる部分ばかり直してしまうのも防げる。
10日が締め切りだったが、さすがに直前は結構時間を使った。コロナの影響で使える時間が多くなったこともあった。
受賞作の傾向をつかもうと思って読んだが、ストーリーという点では傾向はあってないようなものだと思った。文体も多様で、地の文多め漢字多めのものから、ほぼ会話文で構成されてるものまで。そんな感じではあったが、ある意味傾向がないのが傾向と言えるので、それがわかったのは良かった。
どう作れば失敗しないか、アンチパターンを学べた。当たり前のことを網羅的に並べてあるような印象は少し受けた。結局、面白いストーリーに方法なんてないのだろう。
序盤で一気に引き込むのが大事、というのはどんな指南書にも書いてあった。つまりそれぐらい難しいということなんだと思う。実際、キャラ紹介や世界観の説明が必要な序盤は、面白くするのが難しいと感じた。
よくできているドラマやアニメの一話は、テンポ良くこれらをこなしている。映像があるドラマやアニメと違い、小説は文章だけしか使えないのでそのまま真似はできないが、構成などは参考になる。
どこで盛り上げてどこで落ち着かせて、どこで困難にあわせて、、、とかの流れは常に意識した。二作品とも六章構成だったため、全体を六話構成のアニメだと考えて、各話の中できちんと盛り上がりポイントがあるか、全体の中でどういう位置付けか、などを意識した。そのために、定期的に全体の流れをノートに書き出した。
音楽を意識して、横軸に時間、縦軸に盛り上がり度、みたいなグラフを何回も描いた。可視化すると、ずっと盛り上がってばかりの章や（つまり盛り上がってない）、ずっと平坦な章があることに気づく。
過去の受賞作品、あるいは売れているプロの作品を読むと、文体に正解はないことがわかった。読みにくく目が滑るな、と思うような作品もあるが、それはそれで作品の雰囲気を作るのだと思う。ただ、自分にとってはやはり読みやすい文がよいと思った。なので、とにかくシンプルに読みやすく、を推敲時には心がけた。
普段読んでいる時は意識しなかったが、一つ一つの仕草や会話文の後に続ける文書ひとつとっても、無数に可能性がある。正解なんてないから、すべて自分で考えないといけない。ストーリーにしても、少し気をぬくとありきたりな展開になるし、会話文も安直な切り返しばかりになってしまう。少しも気が抜けない。
書き始めるまではいろいろなキャラや展開があったのに、書いていくとそれらをどんどん切り捨てる必要が出てくる。ページ数の要請ももちろんあるが、実際、切り捨てた後に読むと、そっちの方が大抵の場合面白いし読みやすい。熱くなれるはずと思ったシーンや、魅力的なキャラを、どんどん消していく。そうした決断をいつ、どうやってするかには常に悩んだ。
仕事の息抜きになるだけでなく、毎日の生きがいになる。普段の生活では辛いことも多いが、小説を書いている時間はそれらを忘れて空想の世界に浸れる。熱いシーンや悲しいシーンなどは泣きながら書くことも多く、そのあとには不思議な充実感が得られる。
自分はあまり人と喋るのが得意ではない。人と会話しないといけない時は、単なる雑談でさえ、そのシミュレーションをしてから参加してしまう。それでも失敗ばかりである。会話の後に反省会をすることは、もはやライフワークだ。ただ、人と会話するのが決して嫌いではないし、むしろ人が何を考えているのかにとても興味がある。小説ならば、いくらでも時間をかけて会話をすることができる。これはとても心地よいものだった。
こんなところだろうか。良い結果が出ればいいな。
最終出社日まであと数日となった。
次の会社は決まっているんだけど、まさか半年で転職するとは思っておらず、自分で言うのもなんだけど、この転職は半分失敗だった。
この半年で学んだことって何かあったんだっけ、という気持ちもあるのだけど、何も学んでいないのは悲しいので、無理矢理絞り出して考えてみたい。
ここがダメだなーってのはたくさんあるんだけど、ITベンチャーであるならメールベースのやり取りではなくて、Slack等をメインで使って欲しい。
Slackでどこを見ればいいのか分からないとか言わないで欲しい、せめて自分が見るべきチャンネルぐらいは自分の中で整理して欲しい。
ある程度忙しいのは分かるけど、従業員から飛んできたメンションに対して無視するのは非常に良くないです。
それらに対して、改善しようと大なり小なり自分のコストをかけて臨んでみたのだけど、結局ほとんど変わらなかったのが厳しかった。
この半年で一番学んだこととしては、当たり前のことではあるけど、どんな環境においても「何も学びが無いと思ったら、学びがなくなる」ということだった。
半年で辞めるほどの会社であっても学ぶべきところはあるし、それは良い点とかでなくて、反面教師にしようという点でも良いんだと思う。
噂に違わず、そして期待に応える素晴らしい映画だった。その素晴らしさの仕組みを読み解きたい。
ドメインは２つ。ソン・ガンホ演じる父の無職一家とイ・ソンギョン演じる事業家の裕福な家庭の２つ。
クラス図は、裕福な一家の方はシンプルで父・母・娘・息子である。無職一家の方は少し複雑になる。
同じ父・母・娘・息子と構成は同じだが、それぞれが偽のロールを実装し元の素性を隠蔽している。
作品というアプリケーションの中で、この２つのドメイン間でのメッセージのやりとりでストーリーは駆動していく。
最初のイベントはチェ・ウシク演じる無職の息子が友人の代理として、裕福な家庭へ家庭教師の面接を受けにいくところから始まる。すでにこの時点で偽のロールとして継承している。そして、以降芋づる式に無職一家は裕福な家庭に偽のロールを継承しながら組み込まれいてる。いわゆる密結合である。密結合はいろいろと良くないことが起こる。そして映画でも良くないイベントが起こる。
あとは、映画を観てもらうとして、基本的には密結合した２つのドメイン間でのイベントが発火するごとにインシデントが発生しシステムダウンに向かうストーリーと見立てる。
という感じでシンプルに構造を解析すると、映画の中での重要なガジェットに気づく。
それは「臭（にお）い」である。
無職一家のそれぞれの元クラスのさらに親クラス、貧困層に実装されている臭いは偽のロールにも引き継がれ、ところどころでメッセージとして出現する。ただし、出現するだけでイベントは発生しないようにみえる。
言葉や行動など偽のロールで実装した可視化されたメッセージと、根源クラスにある非可視な臭いのメッセージのやりとり。臭いを隠蔽できなかった時点でシステムとして破綻は目に見えてた。
ここで、構造をもう一段掘り下げる。
無職一家の父・母・娘・息子というクラス自体が映画でのロールという偽物である。
つまり、俳優そのもののオブジェクトがあって役になり、作品の中で偽物を演じるという3段階の構造になっている。
多重継承は常に複雑度を増し、予測もしなかったような振る舞いをする時がある。
つまり、作品だけを見ると貧困層と富裕層の悲喜劇に見えるが、それ自体が富裕層の遊びになっているのでは？という視点で、実際少なくないレビューがそれを指摘している。いわく、本当の韓国の貧困を描いてない等の指摘である。
言いたいことはとても分かる。
監督のポン・ジュノの経歴を見ても、普通に大学に行って映画アカデミーに再入学、小説家の祖父をもつという貧困とはあまり近くない。
社会問題を描くときに当事者でないと本質を描けないのかという問題は本当に根深い。
極論すれば、殺人をテーマにするならば人を殺さないといけなくなってしまう。
そして、されに言ってしまえば、当事者が自分たちの問題を作品化する能力があるかどうかという問題と、そういった作品が果たして当事者たちが触れる機会があるかどうかという話になる。
そこまで行くとすべてがゲームになる。
ある社会問題に対して、インテリが作品をつくり富裕層ではないけれど貧困層でもない聴衆が消費し、何とかしないといけないねと言いながら何もしないといういつものパターンである。
パラサイトもそういったアンチパターンの一つかどうかは今の時点では分からない。
パラサイトはノンフィクションではない。とても上手く設計されたフィクションになっていて、アカデミー作品賞が贈られたことにも疑問の余地がない。
現在dポイントでは、ファミマとローソンで最大20%還元キャンペーン中です。
https://dpoint.jp/ctrw/web2/src/dpc_lp_familymart_200128.html
https://dpoint.jp/ctrw/web2/src/dpc_lp_lawson_200204.html
となるのが要注意。ローソンで軽減税率適用品を買う場合、108、216、324と覚えておき、しきい値をギリギリ超える会計を目指すことが重要。これは簡単ですね。でもちょっと厄介なのが200円ごとに倍率が変わるファミマ攻略法。
たとえばアンチパターンとして、ファミマで390円なんて買物になりそうな時。
390円だと1p×40で40p、400円だと 2p×40で80p。40円相当の差が出るのでうまい棒分の元取ってさらに30pつきます。キャッシュレス還元前の支払額に対してポイント計算されるので、合計税込400円をなんらかのキャッシュレス決済すると392円になりますが、400円に対してポイントつくから大丈夫です。
そしてファミマのみ有効な方法として、うまい棒欲しくない時など、取っておきの方法としてイートイン申告して消費税8パーで396円とかのときに10パー適用なら400円超えるのでイートイン使わなくても申告する技。40pの差がつくので、イートイン税分よりも大きいのです。
「うち、イートインないんすけど」とか言われても「店内で食べます！！！」と押し通すこと！！！！！！店の構造にかかわらず、レジは10%適用に対応してるはず。
なおローソンでは「税抜き100円あたり…」の条件なのでイートイン申告しても税抜価格は変わりません。初心者は間違いやすいですがここ重要です。