はてなキーワード: バグるとは
C FAQに書いてあるからだろうけど、あれ20年以上前の文章で、いまどき下位ビットだから極端に周期が短い処理系とかないと思うんだけどね。
初心者が使う用途ならたいがい rand() % N で十分なはず。
「(int)((double)rand() / RAND_MAX * N)」 とか 「rand() >> 16」 とかバグってたりすることがあって、素直に rand() % N 使えよって感じになる。
むかしカルドセプトってゲームが乱数ルーチンバグって、偶数と奇数が交互にでるって現象があってネット上でやっぱり「こう書け」みたいに乱数ルーチン書いてる人がいたけど、そういう人たちもバグってるの多かったね。
例えばスーファミのFFみたいな、古典的なRPGの戦闘シーンを作っていて、「勇者がモンスターを攻撃する」。
勇者.attack(モンスター);
という設計だったとする。
これに「モンスターが毒を受けて、自死する」という挙動を追加するケースを考える。
毒.attack(モンスター);
やや複雑な変更になりそうだが、勇者の攻撃とのタイミングの差で、
のようになるとしよう。
まず、インターフェイス"攻撃者"をつくって、「勇者」、「毒」をその実装とする。加えて...
斬撃後に死んでいた場合(*) 、納刀する
攻撃前に既に死んでいた場合、攻撃できないようにする
この設計変更によって、
が、
の4パターンに増えた(※ただし最後のパターンに関しては今回特に修正の必要はなかった)
攻撃者がひとつ増えるごとに、これらの分岐は倍、倍に増えていく怖れがある。
あらたに攻撃者を追加すると、既存の攻撃者を変更しなければならない。
この変更によって、全体の時間的な流れがよくわからなくなった。
等々の分岐が並ぶことになる。この分かりにくさは単にStateパターンを導入しただけでは本質的には改善しないだろう。
MVCにおけるモデル、は振る舞いを持ったデータだ。モデルが状態変化したとき、イベントが発生する。
しかしその状態変化が別のモデルの状態変化のタイミングに影響をうけるとき、モデルの設計はとても複雑になり、読みにくくなってしまう。
モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。
このような複雑さをプログラマが支配するのは、とても大変だ。
みなさんも体験したことがないだろうか、GUIで「ホニャララしているときにホゲホゲするとバグる」みたいな挙動を。
すると、上部に表示される「更新時刻」の表示位置がおかしくなる。
RPGの設計は、たとえば下記のように記述できるDSLを導入すると、劇的に改善する。
タイミング:毒 ⇒ 死ぬ ⇒ 斬撃 の順なら、納刀する タイミング:毒 ⇒ 斬撃 ⇒ 死ぬ の順なら、変色した血が飛び散る
オブジェクト指向ではこれはStateパターンとStrategyパターンを組み合わせることで実現できる。
でも、このような設計にすると、勇者やモンスターのモデルオブジェクトの責任は極端に少なくなってしまう。
加えてオブジェクト間のやりとりの複雑さがDSLに押し込められるので、オブジェクトの主体性も殆ど無くなってしまい、
うん、ただのデータでいいや。
---------------------------
(*) 攻撃時に相手の状態を問い合わせるのが醜い。これを避けるには、モンスターが毒で死んだ時に勇者にイベントを通知して、勇者を”戦意喪失”状態に変化させる手がある。
Sレアメタルの増殖
1)『どうぐ』を40まで拡張 40の一つ目にいらないアイテム置いておく
4)修理キットを『どうぐ』40の4つ目に移動する
5)『かいふく』に修理キット0個とまんたんドリンク0個とが出きているのを確認する
6)『かいふく』のまんたんドリンク0を一つ目に修理キット0を3つ目に移動し2つ目は空白にしておく
7)『どうぐ』のスーパーレアメタルを『どうぐ』の40の4つ目に移動する
8)『どうぐ』にまんたんドリンク0、『かいふく』の一つ目にスーパーレアメアタル0、二つ目にまんたんドリンク0が生成
9)『かいふく』の一つ目にスーパーレアメアタル0、二つ目に修理キット0をおく
10)修理キット4個買ってきてそれを『どうぐ』40の4つ目に移動する
11)『どうぐ』にスーパーレアメタル243個 『かいふく』の一つ目の修理キット0個が生成
12)『どうぐ』のまんたんドリンク0を『どうぐ』40の4つ目に移動する
13)『どうぐ』に修理キット4個 『かいふく』にまんたんドリンク0が生成される
大規模化していくと、(複雑すぎて)設計図通りに出来ない奴が増える。
バグをバグで直しておいて(つまりたまたま通っているだけで、条件を変えるとまたバグる)治りました。という人が異常に多い。
とくにメモリ破壊エラーとかは、通常のやつに作れても、治せない。
ようするに、作ってるんじゃなくて、破壊してる奴が多い。
メンテナンスならともかく、フルスクラッチに近い仕事は少数精鋭で作るしか無い。
それを経験すると、そもそも、(難しい部品の)設計図を回さないって事が始まる。
昔は、それでも、子会社を喰わせるために、簡単な部品の設計図だけを下請けに回してたけど、
今後はそういうのは無くなっていくだろ。
使う側からすると、徹夜しなければ作れないレベルの会社に出すことがデスマーチの原因だ。 検品するコストや結合テストをするコストは0じゃない。
なんかソーシャルゲーム業界に転職したい増田がホッテントリしていた。 http://anond.hatelabo.jp/20130122131752
自己回顧録みたいなものをつけたいと思っていたところだったので、なんとなくこの2年間について書いてみようと思う。
もともと、2年前に当時SIerに勤めてて、そこでSEとかコンサルとかしてたんだけど、会社の経営が傾き始めたのがきっかけだった。
当時勢いのある(今もかな)ソーシャルゲーム業界にしたのは、単に元々Web系やってたし、勉強会だとかやってるっぽいし、花形っぽいし…みたいな。まぁこのへんの気持ちはIT系の人ならなんとなく分かってもらえると思う。
その頃は「今までやっていた官公庁や大企業向けのコンサル事案と比べたら格下だな」と思っていたところはある。正直、今も社会的地位みたいなものだと格下だと思ってる。
2年経過して、色々な人と交流して思うことは、やっぱすげー人がいっぱい居る。反面、どーでもいい人もいっぱい居る。
なんか元増田の人の言ってるgloopsの人にも何度もあったことがある(仕事でも勉強会でも)。
実のところ全然つかえねーーーーって人も居るよ。
オチャラケてるっぽいけどすごい人ってのはいるけど、しっかりしててすごい人ってのはあんま見たことがない。しっかりしててすごい人はむしろ大企業系のほうが見たわ。あくまで俺の観測範囲。
ドワンゴの人はなんか楽しそうだし非リアっぽくて親近感だった。
グリーの人は割とさわやか系が多い。というかあんまり変な人が少なかった。
アメーバの人はなんか公共系SEのできる人っぽい雰囲気に近かったよ。もっとリア充ギャル男っぽい人だと思ったら全然だった。
でぃーえぬえーの人は数人しかあったことがないんだけどなんか雰囲気ちょっとこわいんだよなーみんな。
UEIの人はなんかとんがってた。ってか最初性別勘違いしてた。
基本みなさんすごい人だった。
あと学歴なーーー!やっぱり学歴高い人とか見るわけですよ。東大京大筑波大。あとなんかMITとか海外大学とか。あと高専生か。
学歴高いとやっぱりすごい人多いと思う。
下品なのでちょっと親しくなると学歴聞いちゃうんですよ。あとfacebookとかもあるしね。facebookで学歴見れるし。やっぱり頭いい…というか、頭よくてアクティブで社交性高めな人は学歴高い傾向あるよね。低学歴で根暗で一芸のみ、ってヤツもいるけど(俺だわ)。
でもたまに学歴高いのにヤバいくらいダメな人も居たりする。逆も居る。まぁこれはどこでもいっしょか。
デキる人と勉強会とかで話すと楽しいし、名刺交換したときに「あー…(コンサル会社か)」な反応から「あー!(あのベンチャーで○○で有名な!)」みたいな反応になってくれるのは嬉しい感じです。
スライドとかも自社テンプレとかあるので楽しい。下手糞が頑張ってパワポでつくるよりずっといい。
あとデザインなー。前の会社でも自社プロダクトなるものがあってデザイナーに発注してたけど、正直ショボかった。ちゃんとしたデザイン事務所に発注した案件(他社案件でコンサルしてた)は綺麗なんだけど。自社プロダクトは糞レイアウト…というか特徴なさすぎだったわ。良いデザイナによるデザイン主導が良いわ。
あ、あとこれはウチの会社だけかもしれないけど、イベント好きなエンジニアがいるので非技術系のイベントもしてたりして楽しい。サバゲだったりスキーだったり釣り部だったりあるっぽい。オフィスでケーキ作ったりとか。話し合う奴らとつるむ、って大学生のノリなんだけど。前の会社の同僚とかとはこんな感じじゃなくて、話を合わせるために合わせてるって感じでつらかったし、キュウべぇのキグルミで出社なんか出来なかったし。
とまぁ良い点を適当に並べた。
悪い点:
・勤怠管理がひどすぎる。残業代の有無は会社にもよると思うが。多少出社しなくてもOKなんだけど、明確なラインがないから困るっちゃ困る。あと風邪ひいてんのに家のPCから会社につないで仕事するヤツとかもいるし。
・時間ねぇー! 彼女作るひまもねぇよ! あっこれは時間あってもかもしれん。とりあえず前職の倍ぐらい働いてる気がする。明確に有給とったのもコミケの時とか母親が手術したときくらいか。土日祝も出たりしてるしちゃんと計算してないけど、めちゃんこ労働してる。
・技術ついてけねぇー!なにそのRailsとか知ってて当たり前みたいな!知ってるっつーのはRailsのActive Recordやらなんやらの実装とか、Railsライクな種々の実装とか、pythonで書かれたRailsっぽいフレームワークの実装状況とか、rakeとかえーと。まぁ色々。ちなみにうちの会社はいっさいRailsを使ってない。つまり自分が関わってない技術でも普通に語れ的な。JSフレームワークも20個くらい平気で使い込んで…というかソースまで読んでるくらいな感じの人がゴロゴロいる。20じゃ足りないかも。
・ゲーム屋じゃねー! ソシャゲ業界はわりとWeb屋です。ゲーマーが1割いればいい方。俺はエンジニアなんでいわゆるそういう企画屋さんじゃないんだけど、ほんと非ゲーマーの企画屋がズレたことを言ったりカネのことを言ったり平気でパクったりしてるのも見てる。ゲーマー系の企画屋はそれはそれで面白いけど、要するにソシャゲってゲーマーやんないしね?って感じだわ。 エンジニアもゲーマー少ない。俺もゲーマーじゃないしね。元RO廃人だけど。 なので企画段階で蹴られるフレーズのひとつに「それゲーマーしかやんねぇよ」ってのがよくある。 まぁでも流れはブラゲからアプリゲーになってきてるんで変わるかも。変わるといいね。
・使えない人の立場がなくなってく感じこええええええええ!!! これは一番でかいかも。使えない人がホントに…なんというか。恐ろしい勢いで立場が悪くなっていくのを見えてく。口には出さないけど「あいついらねー」感がひどいし、俺もそう言うのを(昔は出さなかったし、使えないなりに使える余裕があったのに)だしちゃってる。
つまりさ、高尾山にハイキングに行くなら、ハイヒールのギャルがいても別に許すじゃん?おぶってあげたらおっぱい当たって嬉しいくらいの。
でも富士山とか、登ったこと無いけどエベレストなんかに登るなら、そんなヤツがいても「今すぐ帰れ」以上には言えないわけじゃん。
そんぐらいリリース速度厳しいし、そういう意味での余裕はない。
まぁでも「○○ってフレームワークの実装が微妙に気に入らないので、新しく書きなおしてpull requestを送ったよ!」なんて仕事中にする余裕はあるので、これはなんつーのかな…。
・太った(重要)
まぁでも2年経って、面白いしエキサイティングなのは間違いないと思う。
なにより、Creativeであろうと思うなら、Creativeな人たちと多く話さないといけない、と強く思ってた。Blogを読むのもTwitterで話しかけるのもGitHubでIssueやPull Requestを投げるのもいいけど、実際に会わないといけないと思ってた。勉強会に参加して、それはさらに強く思うようになってた。
現状、そういう人たちに囲まれてるし、何人か『○○さん(自分)に影響を受けました!』とか言ってもらったり、勉強会で発表した俺のセッションがきっかけで話しはじめた人が弊社に入ってくれたりしてると嬉しい。
自分の作ったコードで遊んでくれたお客さんが居るのはうれしいもので、Muninのアクセス数見てニヤニヤしたり、自分の作ったところの課金処理が回ってる時は超テンションあがるし、何度テストコード走らせテスターさんに見てもらってても「うおおバグるなよおおおお」って神に祈ってしまう。
課金関連はお客様にお金払ってもらうわけだから、何かあるとヤバいわけですよ…。
すげーーーー長文になったけど、まとめると、『自分と近い価値観の人と居ると楽しい』『俺より強い奴に会いに行く→(転職)→会った→コテンパン…だが負けてたまるかー!→そいつらに認められる→承認欲求がすごく満たされる!』『まだまだ強いヤツに会いたい』『(SIerでもだけど)自分の関わったプロジェクトでお客様に喜ばれると嬉しい。怒られるとマジ恐縮』『当たるとうれしい。当たらないと悲しい。やめたくなる』あたりです。
「ソシャゲすごい好きだわーーー!だからこの業界超楽しいわーーー!」って言ってるエンジニアは会った中では…5%くらいかな。1割くらい行くかな。廃課金じゃなくてもカジュアルに好き、って程度の人は3−4割は居る気がする。コンテンツ寄りの人は、やっぱ自分の作ってるものが好きじゃない人はうまくいってない感じ(逆にインフラとかフレームワーク周辺の人はあんまり関係ない感じ。インフラ系の人でも廃課金はいたけど)。
2年経って自分を見直すと、もしもソシャゲ業界っていうものがシュリンクするなら、別の業界に移るとは思う。
技術的に楽しいとかそういうだけならソーシャルゲームにこだわる理由はないのです。むしろゲームなんて暮らしの役にはたたぬのです。クックパッドとか食べログとかのほうが役に立つし、ニコ生とかは政見放送までしちゃうのです。