  |
関係ないかもしれんけど、twitterで好き勝手やってる奴って最終的にファンが離れたり支持者から見放されたりするな。
作業服に着替えたら私服をロッカーの入れ、私服に着替えるときは作業服をロッカーに入れます。これは一見したところ普通の使い方ですが、私の職場は食品工場（納豆を作っています。）なので、問題があるかもしれません。
なぜなら私服が細菌などで汚染されていた場合、それらが作業服に移って現場に持ち込まれる可能性があるからです。
本当に安全にするなら、１人にロッカーを２つ与えて、片方には作業服を、もう片方には私服などを入れさせるべきではないでしょうか。
ただですね、自分で書いたことを否定するなら、かなり前からこの状態で作業をしているようで、特に問題があったわけではないみたいなので、案外このままでいいのかもしれません。しかし浜松でノロウイルスによる中毒とおもわれる事件が起きているのでどうかなと思っています。
整理整頓出来ず机の上が異様に汚い、
40過ぎなのに独り身風俗通いで給料日前は倹約(結婚した事無い)とまあ駄目人間のテンプレ通り。
正直言うと自分は小さい頃ADHDと言われていた＆ネットでのアスペ診断で微妙なラインなので、
これらのことが治らない、自覚が無いのはよくわかるんだ。
でも一緒に働くとなると嫌で嫌で仕方ないなw全く信用出来ない。
この会社はアスペやADHDの人間を重点的に採用する社会貢献企業なのかもしれないと考えると素晴らしい事なのかもしれないが。
はてなブックマーク - 蛭子能収「幸せな姿は他人に見せない方が良い」
http://b.hatena.ne.jp/entry/alfalfalfa.com/archives/7046159.html
こちらの元記事とコメントを読んでいて、こんなトラウマを思い出した。私が小学生の頃だから、もう四半世紀近く前のことだ。国語の授業で自分の家族や家についての作文を書いて、各自が自分で朗読して発表することになった。
そして私の番が無事終わり、その時には何ごとも無かったのだが、それからしばらくした後、クラスの内の何人かが私への陰口や悪口を言っていることを知って驚いた。何でも、私の作文の「私と妹の部屋は二階にあります」「二人で階段で遊んだりします」という下りに対してムカついたそうだ。「自分の部屋があるって自慢してる！」「二階建ての一軒家に住んでるってわざわざ言いたいんだ、ムカつく」とか言ってたらしい。
いや、私はもちろん自慢するつもりは毛頭無くて、ただ家のことを書けというからそのまま書いただけだし、そもそもそういう要素が自慢になるという感覚すら無かった。
だいたい、部屋は6畳間を妹と共用だし、一軒家と言っても庭も無いローンウン十年のウサギ小屋だったし、だいいちたかが小学生程度に大した格差意識があるわけはない。それに、当の陰口を言っていた彼女たちは、私の家にはないゲーム機や流行のグッズを持っていたのだし、加えて私などの家よりも高級なマンションや立派な庭付きの屋敷住まいの子がちゃんといて、「庭でキャッチボールをして遊びました」とか言っていても、その彼らは何も言われていないのだ。
とんだひどい言いがかりだ、どうして私だけが、と内心憤慨したが、結局何も言えなかったし、しばらくしてそのまま忘れてしまった。
つまるところ、「繊細チンピラ」的な存在や事象は最近になって生まれて増殖したものではなく、ネットの普及で目立つようになっただけなのだろう。
男の性欲は食欲とかをイメージすればいいと思う。
基本常に空腹状態ということ。
腹が減って仕方が無いところに食べ物がいっぱい置いてあるわけだ。社会通念上食べてはいけません、とかいう注意書きつきで。
理性で空腹に耐えてやり過ごす男もいれば、ちょっとくらいいいよねってつまみ食いしちゃう男もいるし、がつがつ食べる奴もいる。
それだけの話。
ご意見くださって、ありがとうございます。
例にあげたRPGのモデル設計はhttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1178047006を参考にしました。
ですが自分で書くとしても、十中八九そのような設計にするでしょう。
モンスター.attack(勇者.attackPower)
勇者.attack(モンスター)
主語.動詞(目的語)
モデルに対する命令は、ふつう入力Controllerのイベントハンドラに書かれる。attackに関する命令はどちらの設計をとったとしても"攻撃が選択された"イベントハンドラに書かれるだろう。
モンスター.attack(勇者.attackPower)
だと、たとえばモンスターにダメージを与える要素として、他に「すばやさ」などを加えようとしたら、モンスターのattackメソッドを変更する必要が生じる。
また、FF5には"竜騎士のジャンプ"という攻撃方法があった。ジャンプを選択すると、竜騎士は空高く飛び、一定時間が経ったのちに落ちてきて、空中からモンスターを攻撃する、というもの。これを実装しようとすると、入力Controllerのイベントハンドラの直前の部分で別スレッドに投げるなり、タイマーを起こすなりして処理したくなる。
味方同士の”連携攻撃”を実装しようとするとやはり、入力Controllerのイベントハンドラを修正したくなるだろう。
つまり、悪い方の設計ではModel「勇者」への設計変更の都合で、Model「モンスター」や入力Controllerを修正する必要が出てきてしまう。
勇者.attack(モンスター)
では、どの設計変更の例でも、勇者側を変更するだけで良い。この設計には、クラス間の責任の分担がはっきりするという利点がある。
list.append(elem)でしょ。
リストは実質的にはオブジェクトというより、ただのデータ構造。
リストやディクショナリ(連想配列)は便利な道具だが、これを前面に押し出した設計は複雑さを招く場合がある。
たとえば、"複数のモンスターの集まり"や"ソートされたリスト"を、リストを継承して実装しようとすると、とたんにドツボにハマる。
Onスライムが仲間を呼んだ(){ スライムの集まり.append(スライム) スライムの個数ラベル.更新(スライムの集まり.length) if(スライムの集まり.length == 1 and スライムの集まり.get(0).name == "キングスライム"){ スライムの名前ラベル.更新("キングスライム") } }
スライムは8匹集まるとキングスライムになるので、最初の一行でスライムの集まりを変更して以降、スライムの個数を気にする必要があることに注意して欲しい。
上記のコードを洗練させるために、Model「スライムの集まり」で個数が変わった時にイベント"OnLengthChange"を発行するようにしても良いが、そのようにすると、lengthメソッドを安全に呼べるのはそのイベントハンドラのみ、ということになる。プログラマに注意を促すために、lengthメソッドのコメントにその旨を注意書きしておく必要がある。
"スライムの集まり"リストクラスは、プログラマが期待するだろうリストクラスの振る舞い《append後の個数はappend前+1》を破壊している。
"ソートされたリスト"は、appendメソッドをオーバーライドして、追加時に勝手に順番を並び替えてくれるようなものだが、これも《リストに要素を追加した時には、その要素は末尾に置かれる》というリストクラスの振る舞いを破壊する。スライムの例と同じように、イベントの発行とメソッドの注意書きが必要になる。プログラマはそれらのクラスを使うときに、より注意深くならなくてはいけない。
このように、クラスの振る舞いを壊してしまうようなクラス設計は、プログラマを地雷原におくりこむことになる。
とはいえ、リストのようなデータ構造を便利に使えるシーンもある。
はじめからおわりまで100行程度のスクリプトで、とくにイベントドリブンにするほどの複雑さがない場合。順序を追って読めるので、時間的な流れがわかりやすい。
一方、RPGの例で示したような設計は、オブジェクト指向をフルに使って、コードを責任に応じて役割分担しやすくなる利点がある。
前者は"トランザクションスクリプト"的設計と呼ばれ、後者は"ドメインモデル"設計と呼ばれる。
あるとしても、隅っこだよね。
「びんぼー人の居場所なんてないんすけどｗｗ」オーラを漂わせようと必死。
この手の話は、つくづく、キャラが美少女（又は美少年）じゃなかったら一瞬で話が終わって何の救いも無い絶望エンドまっしぐらっていう現実を浮き彫りにするので、啓蒙と考えても本当に意味があるのか疑問に思う。
嫁姑間では一緒にいる時間は少ないが意思疎通が難しい。だからこそ気遣いは必要になる。
ただずっと一緒なわけだから、自分の可能範囲以上に予測して気遣ってたら、やってられない。
かつ、嫁姑と違って意思疎通できる時間はあるんだから、まずははっきり言えよと。
前半のサンプルでも、まずはっきり嫌だと言って、お互い理解できるならモラハラ認定で離婚とはならない。
嫌だと言ってもやめないって事になると、今の話とはそれてくる。
前提条件として、まずは言ってから。
じゃなきゃ、何も始まらない。
それができなきゃ、誰と結婚しても続かない
