「アンチパターン」を含む日記 RSS

はてなキーワード: アンチパターンとは

2021-03-13

anond:20210313153723

存在する機能そのまま使ったらアンチパターンって叩かれる暗黙知が多すぎる

じゃあそんな機能最初から入れとくなやって思ったけど手っ取り早くだの動けばOKだのってなるとそれでいいのか

2021-03-02

COCOAアプリのissueとか見るとXamarinって

AndroidのActivityのonCreateでアプリ初期化をしたり(アンチパターンでは?)

iOSバックグラウンドファイル保存ができたり(裏行ったら10秒くらいでアプリ自体動かなくなるはず)する前提っぽいんだが

カメラGPSとかハードウェア絡まなきゃ大丈夫と思ってたけど

ReactNativeやらFlutterまさかアプリ初期化バックグラウンド動作をろくに考慮してなかったりするんだろうか

2020-10-23

anond:20201022005749

この辺の継承アンチパターンとかデザパタの話、JavaRubyくらいしかそういう本がないのが問題なんじゃないのかね。デザパタ学ぶのにJavaRuby使いたくねーよ。Pythonでそういうのある?

2020-10-22

継承禁止するべき

キチガイ刃物ゴミプログラマ継承危険ものは取り上げるべきだ。

オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合継承を使うことで却ってプログラム保守を困難にしてしまう。継承アンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。

そもそも熟達したプログラマ感覚では、業務で書くアプリケーション実装継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承効果的となる場合もあるが、複雑なアプリケーションロジック継承を使うのはほとんどの場合、時期尚早な抽象化となる。

また、凡庸プログラマ継承で実現したいと思うことは、ほとんどの言語でより適切な手段存在する。

継承を使う資格があるか、一発で判定できる質問

継承を誤って用いるプログラマが多いにも関わらず、実は継承の使い時ははっきりしている。以下は、一定水準のプログラマならば、誰でも答えられる質問である。これに答えられないプログラマ不勉強を恥じるべきである

問題
継承を使うべき/使ってもよいのは、どのようなときですか。
正解
リスコフの置換原則を満たすときリスコフの置換原則 - Wikipedia

答えられない人、自分の答えが正解の内容と一致しているか即座に判断できない人は、継承を使うべきではない。医学知識ゼロ素人外科手術をするようなものであり、非常識まりない。

リスコフの置換原則は、オブジェクト指向文脈で言えば、以下のようになる。

Baseを基底クラス、DerivedをBase任意派生クラスとするときBase型として生成されたオブジェクトをDerived型のオブジェクトに置き換えても問題なく振る舞うようにしなければならない」

問題なく振る舞う」というのは、以下のことを意味する。


継承を用いないやり方

ゴミプログラマ継承を使いたがる理由の99%は、以下である

こんなもん、何も難しいこと考えずとも、以下のどちらかの方法解決する。

AからBの機能を用いる場合は前者を、Aを変更できないがBと同じインタフェースを持たせたい場合後者を使えばいい。

2020-09-26

セクハラしない」ってかなり高度な技術じゃね?

自分を棚に上げて言うんだが、経験上、他人気持ち人格尊重できて、自分衝動を抑えて、行動を顧みることができる、そんな奴世の中にほぼいないと思うんだが???

ほぼ居ないはまあ言い過ぎだけど、個人性格とか育ち(謎)云々が悪いって話じゃなくて、能力的に無理な人がかなり居ると思うんだよな。

書いてあること読み取るだけのセンター現代文ですらロクに解けない奴がゴロゴロしてるのに、不文律とか勘とかい理不尽まりない概念跋扈してる現代のナマの人間コミュニケーションなんて、多くの人にとって手に負えるわけがない。

その手に負えない舞台の上で、性衝動を抑えながら、自分にはない経験をよく知って、語彙を磨いて厳選して、アンチパターンもある程度学習しておいて、ミスしそうになったら後からフォローもして……ってめっちゃ高度な技術だと思うんだよな。

DSMIDC定義された疾患とそのグレーゾーンには「治療必要」みたいな多少の同情が得られるのに、ことそこから外れた(広義の)コミュ障に関しては「雨と埃だけ食って生きてろ」みたいな言葉が飛んで反発するなってのも無理があると思う。

とはいえセクハラ被害者人生を壊しまくってる社会悪から根絶しないといけないし、どうすりゃいいんだろうな。

特に考えがあるわけじゃないから、いつものはてな仕草で「人間には解決できないかテクノロジーの力で~」とか「社会構造のものを変えて~」とか「性欲が悪いから早く総去勢と人工子宮を~」とか言って適当に考えてるフリして終わっとくわ。

2020-09-22

重度障害児が産まれてくる可能性が恐い

正確に言うと、重度の障害を持った子供が産まれてきたときに、特別養子縁組が認められず、そのまま育てることになるリスクが怖い。

まず第一に、愛情を持って接せられる自信が無い。

平均より大きく劣った能力を持って産まれ子供に対し、愛情を向け続けられる気がしない。

もちろん親として他の子供と比較してしまうことはアンチパターンだが、

「なんでうちの子は…」という気持ちを消化して、親としての義務規範を果たせる気がしない。

次に、莫大な育児時間的・体力的コストを払うのが怖い。

ただでさえ大変と言われている育児だが、障害児の場合は更にコストが高くなると言われている。

例えば自閉スペクトラム症児童が高頻度で引き起こすパニック発作対応をするのは保護者

自分場合育児サポートしてくれる親族もいないので、自分可処分時間は皆無になるだろう。

相談相手がいれば多少は楽になるのかもしれないが、レア事象である以上、身の回りに同じ境遇家族はまずいない。

観測可能範囲オンライン上にある障害児の保護者コミュニティは、育児を前向きに捉えるために、

ほとんど共感不可能価値観がまかり通っていると感じる。あのノリに自分が馴染むのは難しい。

最後に、その子本人が楽しく暮らせるようになるための支援をして送り出す自信がない。

「うちの子は、別に立派な人になんかならなくても、元気に暮らしてくれたらそれでいい」というのは多くの保護者が達する境地だが、

仮に自分障害を持って産まれ立場だと仮定した場合

劣った能力しか授けられなかった己の生と、劣った能力自分を産んだ親を恨まずに生きていける気がしない。

まりその元気に暮らすという最低限度のラインすら満たしてあげられる気がしない。

まとめると、自分子供もつらい状態必死で維持し続ける、そういう人生になってしま可能性が怖い。

思いつくままに色々書いたが、結局の所、自分の中にこびりついた差別意識がこの悩みの原因だと思う。

から、仮に障害を持たない子供が産まれたとしても、似たような機序自分自分の子供は苦しむことになるだろう。

まれてもいない子供とその育児に対してこんなネガティブ感情をいだいてしま自分は、そもそも子供を設けるべきでは無いのだろう。

2020-09-09

コード共通化」というアンチパターンプログラミング初心者に教えないでくれ

嘆かわしいことに、多くの人が「同じコード関数クラスなどを用いて共通化しなければいけない」と信じているが、これはプログラミングにおけるアンチパターンである

たとえば、

という2つの処理は、どちらも元の数値を1.1倍する処理であり、完全に同一のコードであるが、これは共通化すべきではない。意味が異なるからだ。

これらを共通化すると、たとえばシステム全体で金利を5%に変更しなければいけなくなったとき消費税を加える処理すべてに影響を及ぼしてしまう。つまり保守性が下がっている。

元々、DRY原則は「情報の重複」を無くすためのものだし、SRP(Single Responsibility Principle)も「モジュールの責務(言い換えればそのモジュールを変更する理由)を1つにすべし」というものだ。つまり、どちらも実装に関するものではなく、より抽象的な「意味」や「役割」に関するものだ。

どうして、こういうことが起こってしまうのか。理由は単純で、ほとんどの(自称プログラマ馬鹿からだ。

ほとんどのプログラマは基礎学力が著しく低く、プログラミング言語の書き方を覚えるのに精一杯で、実装意味を分離するとかそんなことは考えられない。というか、彼らは自分が書いているソフトウェア機能日本語説明することすらできない。

これは教える側もそうで、知能と知恵が足りていないか

DRY原則コード共通

みたいな安易にわかった気になれる情報に飛びついて、間違いを悟ることができない。

2020-07-31

頼むからおっぱいのない女子パイズリしようとしないでくれ

本当に迷惑なんだ。

おっぱいがない女子パイズリの何が問題かというと、技術がないとか、気持ちよくないということではなく、根本的に「無理」なことなんだ。

おっぱいのない女子は、巨乳人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「パイズリをした経験のない人は典型的にこういうことをしがち」という例であるが、おっぱいのない女子はそういう典型的アンチパターンにすら当てはまらないほど意味不明なことをする。だから、「おっぱいのない女子典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメから直せ」という指摘もできない。

https://anond.hatelabo.jp/20200731155404

頼むからパンティのないやつはプログラマにならないでくれ

本当に迷惑なんだ。

パンティがない奴の何が問題かというと、技術がないとか、恥を知らないということではなく、根本的に「頭がおかしい」ことなんだ。

パンティのない奴は、普通人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「パンティを履いた経験のない人は典型的にこういうことをしがち」という例であるが、パンティのない奴はそういう典型的アンチパターンにすら当てはまらないほど意味不明なことをする。だから、「パンティのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメから直せ」という指摘もできない。

https://anond.hatelabo.jp/20200731155404

頼むからセンスのないやつはプログラマにならないでくれ

本当に迷惑なんだ。

センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。

センスのない奴は、普通人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的アンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメから直せ」という指摘もできない。

最近見た例を書いてみる。2次元テーブルを扱うJSONだ。

普通の人なら、何も考えず以下のような実装をするだろう。フィールド定義データが分かれているのは、ユースケースによってフィールドが可変だからだ。

[
{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"}
]

一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。

センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界常人と異なるから矯正は無理だし、チームにいると非常に迷惑なんだ。だからプログラマにはならないでくれ。

2020-06-30

anond:20200629114431

「中盤の段階で最善手と判断して指すには23分は短すぎる」

これがすべてで、他の話(でルール説明以外の部分)は将棋知らない人向けだとしてもあんまりしっくりこないかな。


書かれている通り、棋士セオリーとか大局観とか手の流れとかによって、「読み」の量を減らしたりとか

読みきれないときに、直感的に選択することを実現しているわけだけど、

31銀は、いわゆる流れとか大局観としてはややアンチパターン

ただ、攻めの手順とか、ここまでの流れ的にこう指すかなぁっていう手順の先をかなりの量読んだ結果、

「あまり良くなる順が見えない」「激しくなって制御しにくくなる」ということから

残った手を指した。

膨大な変化手順があり、プロでも大局観や直感、流れ、などを駆使して指す中盤に対し

「読む」という、その量とスピード、それをやろうとする精神力が唯一無二なんだと思う。

もともと能力天才的なことに加えて明らかに中盤に時間を使っているというのもそれを裏付けるというか、興味深いところ。


まりコンピューターがやるように(もちろん実際のコンピューターよりは遥かに「ありえる手」を限定しているが)、

フラットに読んで、フラット判断した。

これを実現してるのは、読みの量とスピード

それが(他の棋士との比較として)相対的意味尋常じゃない。

2020-06-28

anond:20200622101632

ラティブのサイトに行ったところ、下にスクロールすると延々と more... が展開されて、永遠に会社情報」にたどりつけないという、5年ぐらい前のアンチパターン実践していてなるほどな、と思った。

https://www.mirrativ.com/

2020-06-03

アンチパターン説明説明になってなくて意味不明

ソフトウェア開発におけるアンチパターン とは、必ず否定的な結果に導く、しか一般的に良く見られる開発方式記述する文献形式を言う。

その内容は、基本的には、否定的な開発方式一般的な形、主原因、症状、重症化した時の結果、そしてその対策記述からなる。

2020-04-10

執筆経験なしアラサー半年間で二作完成させて電撃小説大賞投稿するまで

思った以上に非日常体験だったので、共有したい。

スペック

30代前半・独身・男・非正規年収

小説執筆経験を含め、創作経験は無かった。仕事文章を書くことはあるが、クリエイティブものではない。

読書家と言えるほど読む量は多くないし、映画アニメマニアなどに比べれば全く観ていないが、フィクションは好きな方だと思う。

結果は?

投稿締切が今日だったので、まだわからない。1次選考の結果は7月で、最終選考結果発表10月らしい。

結果が出た後だと、良くても悪くてもまとめる気にならないし、変に情報を取捨選択してしまうと思うので、このタイミングで書き残しておく。

どうして小説を書きたいと思い、電撃大賞に応募しようと思ったか

小説映画漫画アニメなどの作品をみてストーリーについて「こうすればもっと面白くなるのに」と思う時が多かった。

あわよくばいろんな人に読んでほしいし、収入源にもなればと思った。ただ、今は普通に小説を出しても売れない時代アニメドラマ映画化などのメディアミックス選択肢が多いライトノベルは、まだマーケティング的に強いと思った。電撃を選んだのは、単純に最大手から

仕事マンネリ感があり、毎日に変化が欲しかった。

絵が描けない(ありがち)。

スケジュール

11月-12月: プロット

物語の作り方を勉強しようと思い、脚本についての本をいくつか読む。ここ最近受賞作品や売れている小説を読む。ネット情報も調べる。

その後、まず100字以内でどんな物語かをあらわす文章をたくさん作る(ログラインと言うらしい)。この時点で早速、創作の難しさに気づく。思いつくのはありきたりなストーリーばかり。

ゼロからアイデアを出していると、似たようなものばかりになることに気づく。自分がどんなストーリーを考えるのが得意かわからないし、この段階ではある程度多様性があった方がいいと思い、SF現代青春もの戦記物、みたいにカテゴリでわけて、その中で考えることにする。それぞれのカテゴリの中でまだマシと思えるログラインを、800字程度のあらすじに膨らませる。

なんとかかんとか、4本分ひねり出し、この段階で一度友人に見せてみる。わりと恥ずかしかった。

1月: ドラフト

友人に見せた4本のあらすじがそれなりに評判が良かったので、キャラ世界観の設定を深めていく。ここで、あらすじごとに考えやすものと考えにくいものがあることに気づく。わりとスムーズキャラや設定を考えることができた2本を使って、書き始める。

いざ書き始めて、これは長期戦になるであろうことを瞬時に悟る。自分夏休みの宿題を直前まで放置するタイプだが、それでは到底太刀打ちできない。そこで、毎日起きてから3時間執筆にあてることにする。3時間にしたのは、仕事との兼ね合いと、これ以上は創作力が続かないから。土日だけは3時間x2スロットの6時間にした。また、毎日同じ小説を書いていると自分自身がその物語に飽きることに気づく。自分が心から楽しめないのはまずいだろう。なので、二作品を一日交代で書き進める。

電撃大賞には、全体で80ページ以上130ページ以内という規定がある。自分執筆ペースは、エピソードの流れが頭にできていればだいたい3時間で8ページぐらい。文字数にすると約6000〜8000字。だがこの「流れが頭にある」というのがくせ者で、最初に作った800字程度のあらすじだけでは、一つ一つのエピソードが書き進められない。つまりエピソードごとに、もっと細かなプロット必要だった。なので、3時間執筆時間以外でも、通勤時間を使って次に書くエピソードの流れを頭で考えて、スマホメモを取っていった。

また、書いている途中は一度も推敲せずに一気に最後まで走るのが良いというアドバイスネットにあったのでそれに従う。結果的にこれはよかったと思う。とりあえず終わらせるのがモチベーション的に非常に大事だと思った。特に序盤〜中盤あたりを書いているときは、本当に最後までたどり着けるか結構不安になった。その辺で行ったり来たりするのはあまり良くないのではないかと思う。

月末に二作分のドラフトが完成する。この段階ではまだ人に見せられるようなものではなく、第ゼロ稿というところか。

2月: 第一稿

ドラフトが完成してから、1週間寝かせて、再度最初のページから直していく。

上に書いたとおり、一切途中に推敲は入れていないので、矛盾が生じていたり、伏線をまったく張っていない設定がたくさんある。他にも、安直でつまらない会話や、適当人物風景描写冗長な文だらけ。まずは全体を見てそれらを洗い出し、一つ一つ潰していく。

細部の推敲と並行して、改めてプロットを見直す。物語全体の流れがほぼ確定したので、章立てを決める。各章内に、盛り上がる部分・落ち着く部分があって、最後に引きがあるかを確認する。うまくまとまっていない章については、エピソードを追加・削除・移動。また、全体をとおしてテーマ一貫性があるか、最後まで引っ張る謎や問題があるか、改めて確認する。

これも平日3時間休日6時間スケジュールで進める。「自分はこの小説を完成させられる」という自信のようなものがようやく出てくる。

第一稿が完成する。プロットを見てもらった友人に完成版を見せる。かなり恥ずかしかった。

3月: 第二稿

1週間ほどで友人から感想をもらう。自分では気づかなかった有益視点が多くもらえる。特に物語最初テーマ放置されて途中からのものに変わってしまっていたり、せっかく魅力的なキャラがいるのにそのキャラエピソードほとんどなかったり、そういうのこそ案外自分では気づかない。

感想を踏まえて、ぶれている部分を直したり、キャラエピソードを追加したり、不要キャラを削除したりする。

月末に再度友人に見せる。これぐらいになると、あまり恥ずかしくもなくなる。

この月もやはり平日3時間休日6時間は守る。

4月: 推敲

最初から最後まで、何回かにわたって見直す。

漢字の使い方を見直したり、改行の入れ方を変えたりと、読みやすさやテンポに気をつけて変更していく。

脚本術の本に、「審査員ランダムにページを開いてそこが面白いかどうか見る」と書いてあった。なので、自分でもそれを試した。これは良かったと思う。通しで読んでいると良くも悪くも物語に入り込んでいくので、細かい欠点に気が向かなくなる。あと、無意識自分が気になる部分ばかり直してしまうのも防げる。

10日が締め切りだったが、さすがに直前は結構時間を使った。コロナの影響で使える時間が多くなったこともあった。

やってよかったこ

過去受賞作品を読む

受賞作の傾向をつかもうと思って読んだが、ストーリーという点では傾向はあってないようなものだと思った。文体も多様で、地の文多め漢字多めのものから、ほぼ会話文で構成されてるものまで。そんな感じではあったが、ある意味傾向がないのが傾向と言えるので、それがわかったのは良かった。

脚本術の本を読む

どう作れば失敗しないかアンチパターンを学べた。当たり前のことを網羅的に並べてあるような印象は少し受けた。結局、面白ストーリー方法なんてないのだろう。

ドラマアニメの一話を観る

序盤で一気に引き込むのが大事、というのはどんな指南書にも書いてあった。つまりそれぐらい難しいということなんだと思う。実際、キャラ紹介や世界観説明必要な序盤は、面白くするのが難しいと感じた。

よくできているドラマアニメの一話は、テンポ良くこれらをこなしている。映像があるドラマアニメと違い、小説文章だけしか使えないのでそのまま真似はできないが、構成などは参考になる。

書くにあたってした工夫

常に全体の流れを考える

どこで盛り上げてどこで落ち着かせて、どこで困難にあわせて、、、とかの流れは常に意識した。二作品とも六章構成だったため、全体を六話構成アニメだと考えて、各話の中できちんと盛り上がりポイントがあるか、全体の中でどういう位置付けか、などを意識した。そのために、定期的に全体の流れをノートに書き出した。

音楽意識して、横軸に時間、縦軸に盛り上がり度、みたいなグラフを何回も描いた。可視化すると、ずっと盛り上がってばかりの章や(つまり盛り上がってない)、ずっと平坦な章があることに気づく。

とにかく文章シンプル

過去受賞作品、あるいは売れているプロ作品を読むと、文体に正解はないことがわかった。読みにくく目が滑るな、と思うような作品もあるが、それはそれで作品雰囲気を作るのだと思う。ただ、自分にとってはやはり読みやすい文がよいと思った。なので、とにかくシンプルに読みやすく、を推敲時には心がけた。

意外だったこ

小説を書くことは難しい

普段読んでいる時は意識しなかったが、一つ一つの仕草や会話文の後に続ける文書ひとつとっても、無数に可能性がある。正解なんてないから、すべて自分で考えないといけない。ストーリーにしても、少し気をぬくとありきたりな展開になるし、会話文も安直切り返しばかりになってしまう。少しも気が抜けない。

書き始めるまではいろいろなキャラや展開があったのに、書いていくとそれらをどんどん切り捨てる必要が出てくる。ページ数の要請ももちろんあるが、実際、切り捨てた後に読むと、そっちの方が大抵の場合面白いし読みやすい。熱くなれるはずと思ったシーンや、魅力的なキャラを、どんどん消していく。そうした決断をいつ、どうやってするかには常に悩んだ。

小説を書くことは楽しい

仕事息抜きになるだけでなく、毎日の生きがいになる。普段生活では辛いことも多いが、小説を書いている時間はそれらを忘れて空想世界に浸れる。熱いシーンや悲しいシーンなどは泣きながら書くことも多く、そのあとには不思議な充実感が得られる。

自分はあまり人と喋るのが得意ではない。人と会話しないといけない時は、単なる雑談でさえ、そのシミュレーションをしてから参加してしまう。それでも失敗ばかりである。会話の後に反省会をすることは、もはやライフワークだ。ただ、人と会話するのが決して嫌いではないし、むしろ人が何を考えているのかにとても興味がある。小説ならば、いくらでも時間をかけて会話をすることができる。これはとても心地よいものだった。

こんなところだろうか。良い結果が出ればいいな。

2020-04-09

最終出社日まであと数日

最終出社日まであと数日となった。

次の会社は決まっているんだけど、まさか半年転職するとは思っておらず、自分で言うのもなんだけど、この転職は半分失敗だった。

この半年で学んだことって何かあったんだっけ、という気持ちもあるのだけど、何も学んでいないのは悲しいので、無理矢理絞り出して考えてみたい。


ここがダメだなーってのはたくさんあるんだけど、ITベンチャーであるならメールベースのやり取りではなくて、Slack等をメインで使って欲しい。

Slackでどこを見ればいいのか分からないとか言わないで欲しい、せめて自分が見るべきチャンネルぐらいは自分の中で整理して欲しい。

ある程度忙しいのは分かるけど、従業員から飛んできたメンションに対して無視するのは非常に良くないです。

それらに対して、改善しようと大なり小なり自分コストをかけて臨んでみたのだけど、結局ほとんど変わらなかったのが厳しかった。

この半年で一番学んだこととしては、当たり前のことではあるけど、どんな環境においても「何も学びが無いと思ったら、学びがなくなる」ということだった。

半年で辞めるほどの会社であっても学ぶべきところはあるし、それは良い点とかでなくて、反面教師にしようという点でも良いんだと思う。

それぐらい酷い感じだったのだけど、いよいよ最終出社日まであと数日なので、明日我慢して何もしないでおこうと思う。

2020-02-16

パラサイトオブジェクト指向で考える

偶然できた時間を利用してパラサイトを観た。

噂に違わず、そして期待に応える素晴らしい映画だった。その素晴らしさの仕組みを読み解きたい。

システム屋なので、オブジェクト指向で読み解いていく。

ドメインは2つ。ソン・ガンホ演じる父の無職一家とイ・ソンギョン演じる事業家の裕福な家庭の2つ。

クラス図は、裕福な一家の方はシンプルで父・母・娘・息子である無職一家の方は少し複雑になる。

同じ父・母・娘・息子と構成は同じだが、それぞれが偽のロールを実装し元の素性を隠蔽している。

作品というアプリケーションの中で、この2つのドメイン間でのメッセージのやりとりでストーリー駆動していく。

メッセージの発生は基本的イベントリブンになっている。

最初イベントはチェ・ウシク演じる無職の息子が友人の代理として、裕福な家庭へ家庭教師面接を受けにいくところから始まる。すでにこの時点で偽のロールとして継承している。そして、以降芋づる式に無職一家は裕福な家庭に偽のロールを継承しながら組み込まれいてる。いわゆる密結合である。密結合はいろいろと良くないことが起こる。そして映画でも良くないイベントが起こる。

あとは、映画を観てもらうとして、基本的には密結合した2つのドメイン間でのイベントが発火するごとにインシデントが発生しシステムダウンに向かうストーリー見立てる。

という感じでシンプル構造を解析すると、映画の中での重要ガジェットに気づく。

それは「臭(にお)い」である

無職一家のそれぞれの元クラスさらに親クラス貧困層実装されている臭いは偽のロールにも引き継がれ、ところどころでメッセージとして出現する。ただし、出現するだけでイベントは発生しないようにみえる。

そこがこの作品の1つの重要設計要素になっていて面白い

言葉や行動など偽のロールで実装した可視化されたメッセージと、根源クラスにある非可視臭いメッセージのやりとり。臭い隠蔽できなかった時点でシステムとして破綻は目に見えてた。

ここで、構造をもう一段掘り下げる。

無職一家の父・母・娘・息子というクラス自体映画でのロールという偽物である

まり俳優のものオブジェクトがあって役になり、作品の中で偽物を演じるという3段階の構造になっている。

そして、俳優生活のもの貧困一家のような生活ではない。

多重継承である

偽の家庭教師を演じている無職息子と、それを演じている俳優

多重継承は常に複雑度を増し、予測もしなかったような振る舞いをする時がある。

それがこの作品本質と思ってる。

まり作品だけを見ると貧困層富裕層悲喜劇に見えるが、それ自体富裕層の遊びになっているのでは?という視点で、実際少なくないレビューがそれを指摘している。いわく、本当の韓国貧困を描いてない等の指摘である

言いたいことはとても分かる。

監督ポン・ジュノの経歴を見ても、普通に大学に行って映画アカデミーに再入学小説家祖父もつという貧困とはあまり近くない。

社会問題を描くとき当事者でないと本質を描けないのかという問題は本当に根深い。

極論すれば、殺人テーマにするならば人を殺さないといけなくなってしまう。

そして、されに言ってしまえば、当事者自分たち問題作品化する能力があるかどうかという問題と、そういった作品果たして当事者たちが触れる機会があるかどうかという話になる。

そこまで行くとすべてがゲームになる。

ある社会問題に対して、インテリ作品をつくり富裕層ではないけれど貧困層でもない聴衆が消費し、何とかしないといけないねと言いながら何もしないといういつものパターンである

パラサイトもそういったアンチパターンの一つかどうかは今の時点では分からない。

パラサイトノンフィクションではない。とても上手く設計されたフィクションになっていて、アカデミー作品賞が贈られたことにも疑問の余地がない。

ポン・ジュノ監督スピーチで言った

もっと個人的なことが、もっとクリエイティブだ」

という言葉。この個人的なこととは何か?

作品から観客へ送信されたメッセージ、それが何か。

ゲームで終わらせてはいけない。

2020-02-04

dポイントキャンペーン攻略法

現在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円なんて買物になりそうな時。

そんな時はうまい棒1本買う事!!!

390円だと1p×40で40p、400円だと 2p×40で80p。40円相当の差が出るのでうまい棒分の元取ってさらに30pつきますキャッシュレス還元前の支払額に対してポイント計算されるので、合計税込400円をなんらかのキャッシュレス決済すると392円になりますが、400円に対してポイントつくから大丈夫です。

そしてファミマのみ有効方法として、うまい棒欲しくない時など、取っておきの方法としてイートイン申告して消費税8パーで396円とかのとき10パー適用なら400円超えるのでイートイン使わなくても申告する技。40pの差がつくので、イートイン税分よりも大きいのです。

「うち、イートインないんすけど」とか言われても「店内で食べます!!!」と押し通すこと!!!!!!店の構造にかかわらず、レジ10%適用対応してるはず。

なおローソンでは「税抜き100円あたり…」の条件なのでイートイン申告しても税抜価格は変わりません。初心者は間違いやすいですがここ重要です。

2019-11-06

フェミニストアンチパターンというのかな

女性差別よろしくない」ってのは分かるし賛同できる。

そのために行動するのもいいんちゃう

でも意見だけ言って「誰かやってくれないか」になるとなんか違う。

完全にフェミニストのやったことが「行動はしないけど配慮してもらえる女性」の立場に落ち着いてる。

託された側は「女性配慮した」とか「めんどいので誤魔化した」になるのは目に見えてる。

2019-08-17

anond:20190817191914

そういや、SQLアンチパターンBLOBにつっこむのを薦めてたな。

管理情報だけSQLに載せてファイルを別途保存するのはアンチパターンなんだって

2019-03-25

[]2019年3月24日日曜日増田

時間記事文字数文字数平均文字数中央値
005817400300.048.5
01689209135.440
023814743388.0121
033812146319.6291
044823638492.588.5
052512705508.2147
06122204183.794
07418058196.551
08455997133.370
098015756197.041.5
1068595587.630
1153318360.130
1265612794.353
131231181896.154
1477708292.063
15106762671.943
1698811282.846
17859294109.360
184711012234.387
195610482187.254
209716300168.045
2112321494174.749
2211918106152.258
239618118188.745.5
1日1666276565166.052

本日の急増単語 ()内の数字単語が含まれ記事

犯行予告(4), 詰め寄っ(3), 足立(3), 着付け(4), アンチパターン(3), 生き恥(3), ずん(3), 若返り(3), 初月(3), 傍観(12), 遡及(3), 仄めかす(3), 自発的(21), 迫害(12), 順位(7), テロ(19), 誇張(7), 明言(7), ワンチャン(8), デスク(6), 昼休み(6), 若さ(7), 頻度(11), post(6), KKO(52), 弁当(11), まとめサイト(7), 解消(19), 無理矢理(6), 配偶者(6), カルト(5), AM(12), PM(12), 差別主義(12), 殴っ(8), ヤクザ(8), NG(9), 動い(12), 考慮(8)

頻出トラックバック先(簡易)

男性オタクに苛められてたこ絶対に忘れないから 追記 /20190324040152(30), ■日本弁当食べる場所がない問題 /20190324001129(28), ■足立です。 /20190323215053(19), ■海外に自信増田は教えて /20190324092109(13), ■母の作品を破った /20181013021617(11), ■この国の人間はなんでもっと怒らないんだ /20190324180834(7), ■とある増田特定した。 /20190324094734(6), ■増田は何か引退したことある? /20190324051429(6), ■男性必要な「清潔感」 /20190324233535(5), ■極論でしか話せない人 /20190324020518(5), ■単語しか反応できない増田っているよね /20190324103559(5), ■anond20190324102925 /20190324103915(5), ■公園ちんこ /20190324150050(5), ■お前らがブラウザに固定してるサイト教えてくれ /20190324155643(5), ■2人でご飯に行くということ /20190324125204(4), ■anond20190324224134 /20190324230106(4), ■anond20190324151557 /20190324152320(4), ■ /20190323184042(4), ■はてサ政権批判したら反日扱いされた」 /20190324102925(4), ■大企業人材は使い物になるだろ /20190324212034(4), ■今の新卒はどの会社に入ればいいの? /20190324104223(4), ■自分想像勝手に怒る人 /20190324111157(4)

増田合計ブックマーク数 ()内の数字は1日の増減

6117615(1498)

2019-03-24

anond:20190324094739

SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。

1回のトランザクションでupdateを2回発行する場合と1回のSQL複数行のアップデートをする時はデッドロックリスク考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。

1回のトランザクション複数回update文を投げるケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value where id = 2;

tA =# update t1 set column = value where id = 2;
tB =# update t1 set column = value where id = 1;
tB =# ERROR:  デッドロックを検出しました

1回のSQL複数行のアップデート文を発行するケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value -- update all record

tA =# update t1 set column = value where id = 2;
tA =# ERROR:  デッドロックを検出しました

あと、先勝ち後負けを実現するのはSELECT FOR UPDATEではなく楽観的ロックな。

tA =# begin;
tA =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tB =# begin;
tB =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tA =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 1
tB =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 0

MySQL存在しないレコード更新しようとするとギャップロックになるから注意な。

SQLアンチパターンコピペするアンチパターン

キーレスエントリー(外部キー嫌い)

外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか

外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。

すぐに思いついたケースは

とかを思いついたがこんなケースで合ってるのか?こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。

特に下2つは害悪で、SQLアンチパターンコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか

そんな経験していると、DB初心者は「せや!ユーザテーブルに退会フラグ論理削除フラグ持ったろwww うはw天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。

http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e

初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね

俺?俺はAndroidエンジニアSQLiteは使わないか関係いね

RDB初心者の俺が恐れ多くも案を出すと、FK作成する前に、そのテーブル性質予測することが大事なんじゃないかね?大量に発生するログデータなのか、大事トランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事トランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。

ちなみに外部キーいかER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。

から先ずは外部キー使用していなくて「こんな被害を出した」ってのを聞いてみたい。

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