  |
はてなキーワード: デグレードとは
○ご飯
○調子
マリオもいいけど他のものね、ということでサクッと始めてサクッとクリア。通して遊ぶのは2回目なのもあるし、カービィは強いからサクサク遊べて楽しい。
あと最終面にいるカービィのコピー体みたいなやついるけど、あれは何者なんだろう。
半年前ぐらいにデデデの前まで遊んでたのだけど、急に辞めちゃってたのを再開して、クリア。
面白かったー。ストーリーとかわかってなかったけど、デデデは悪者じゃないんだね、可愛い、しゅきい。
それにしても、今ではもう当たり前だけどやっぱコピー能力は楽しい。
どの能力も強いから雑魚敵をサクサク倒しながら進めるし、ちょっとした謎解きにも使えてそれも楽しい。
マリオは割と道中苦戦してボス戦はイベントって感じだけど、カービィは道中は無双できてボス戦で苦戦する感じで、同じ2Dアクションでも全然違うなあ。
一応これも好き好きランキング作るか。
とは言っても、まだ2作品なので、こんな感じ。
というわけで、早速購入してプレイ開始。
コピー能力もあるし、リック、カイン、クーの三匹の仲間と組み合わせることでそれがパワーアップする仕組みなのかな、素の数は夢の泉より少ないけど仲間との掛け算でそうとは感じなくて楽しい。
特に気に入ったのが、スパーク×カインの組み合わせ。電球を使った可愛らしい見た目だけじゃなく、全身のビリビリに加えて電球も発射できて遠距離にも対応できて楽しい。
あと調べればすぐわかるんだろうけど、仲間がいるときに仲間が閉じ込められてる袋を開けた時に出てくる中華っぽい女の子は何者？ カービィの世界にアドレーヌ以外の人間のキャラいるんだ。
Newシリーズ特有なのかな、妙に滑る感があってまだマリオとアジャストできてない。
加えて、ギャラクシーのときと全く違うスピンの感覚にも戸惑ってる。
あとWiiUをテレビに繋ぐのがタルくてゲームパッドで遊んでたんだけど、2回ぐらい処理落ちして転落することがあったので、テレビに繋ごう。
そうえば昨日書いた好き好きランキング、NewDS追加する前のやつをコピペしてデグレードしてたので、戻した。
サンシャイン＞ワールド＞ランド2＞3＞1＞ランド＞ギャラクシー＞64＞2＞NewDS＞USA
ただこれ、NewDSが下の方の理由はコンプリートをしたときの面倒臭さが大半だった気がしてて、ギャラクシーはその辺を放置したら楽しかったから、フェアなというか、一貫性のある好き好きにしたいな。
「赦し」がないから以外に何が考えられるのか。
むしろコンピュータとは、人類の「赦し」を試すために生まれてきたのかもしれない。
バグが出ても「赦す」、デグレードしても「赦す」、納期が遅れても「赦す」だけでよい。
そんなことは絶対に無理だろうと皆思うだろう。
SIの客、ITゼネコンの客、ユーザー企業の客…というように辿ってゆくと、最終的には個人消費者に至る。
個人消費者はどうか。
ミスを犯した企業は全て「悪徳企業」で、叩こうが虐めようが全てが正義だ。
つまり、IT業界をブラックにしている責任は、IT業界の末端のエンジニアを含む日本人全員にある。
次々とやってくるさまざまな環境で色々がんばる人のためのノウハウを集めてみよう。
必ずしも綺麗な環境で開発できる人ばかりじゃない。スパゲッティを手渡されラーメンを作れといわれる。
所詮下請けなので、そもそもこうした方がいいよとか軌道修正すらできない環境で足掻くために何ができるのか。
朝はCakePHP、昼はsymfony、右向きゃ独自FW、左向きゃ素php。
こんなこと、よくありますよね！
いろんなFWを使ってるとFW固有の機能とかもう何がなんだかわけがわからなくなります。
FWの機能を使ってデバッグなんてやってられません。一番信頼できるデバッグ方法とはなんでしょう。
・・・そうprintデバッグです！！！printデバッグこそ神！PHPならprint_rを使おう。
ただし出力バッファを捕獲したりするFWもあったりするのでprintだけだとどこの処理通ってるかわけわからんときがあります。
そんなときはこれ！
exit！
exitだけは何者にも犯せない最強の関数（言語構造）なので確実に処理がとまってくれます。なのでわけわからんことになったら真っ先にexitしましょう。
世の中には開発者のPCに環境（ローカル環境）を作るのが困難な場合があります。例えば設置できたはいいが、ローカルでこの関数が動かないor動いたらまずいだとか
こんなこと、よくありますよね！
そんなとき僕達がよくやる対策としてはソースコードを直接書き換えることですね！呼ばれたくない関数は中身をコメントアウトしたり、定数はローカル用の値に書き換えたりするわけです。
しかしこのやり方は少し問題があるのです。
例えばSVN等を使っている場合、常にこれらのファイルが変更状態のままになってしまいます。間違えてコミットしちゃった！なんてこともあります。
そして更にそのファイルに何か変更があった場合とても面倒です。関数のコメントアウトを外し、定数は本番環境用に戻してからコミットする、なんてことになります。まぁ確実にいつか人的ミスが入るでしょう。
そこで僕が推奨するのはファイルを直接書き換えずに書き換えろ。ということです。
つまりrunkitを利用するのです。
通常PHPは関数や定数などを動的に上書きすることはできませんが、runkitを使えばそれができてしまうのです。このようなローカル環境を無理やり構築したい場合にはとても使える機能です。
もちろん本番環境においてrunkitを使うのはご法度だと思います。伝家の宝刀、馬鹿と鋏は使いよう、です。
こんな経験はありませんか？
「ここを改修して欲しい」
「わかりました、じゃあSVNをUPDATEしてから改修しますね。」
「いや、今はステージング環境にあるファイルが最新なのでそこからダウンロードしてから作業してほしい」
「あ、そうなんですか、じゃあステージングから持ってきて対応します」
「改修完了しました。コミットしてステージングにアップします」
「あれ、なんか本番の動作がおかしい！デグレードしてます！デグレードしてます！」
「コミットもされてねぇ！」
「競合！競合！」
「うわああああああ、今何が最新なの？ねぇねぇ？もう僕わかんない。」
こんなこと、よくありますよね！
この後の担当者の作業はこうです。
ローカル環境のファイルとSVNでdiff。ステージング環境とdiff。本番環境とdiff。
改修対象のファイルが複数ある場合のdiff作業の大変さと言ったらもう筆舌に尽くし難いものとなります。
僕は思いました。ローカル環境のファイルと、SVNとステージング環境と、本番環境のdiffをワンコマンドでさっとできたらどれだけ楽か・・・。
もちろん探せばそういったツールを見つけることは可能だとはおもいますが、探すのが面倒だったので自作しました。
そのツールをここに晒す事もできなくはないですが、この余白はそれを書くには狭すぎるので今回はそういうアプローチがあるということだけを書いて終了します。
とりあえず僕が自作したのはローカル(windows)とhttp(SVN)とftpとsshに対応した相互diffツールです。全ての環境の組み合わせでdiffをして差分を表示したり、特定の環境だけをdiffしたりできるので開発効率アップです。
タイトルで言ってしまった感がありますが、下請けで改修作業をしていると既知バグを発見してしまうことがあります。
これは非常に難しい問題です。もう完全にクライアント次第としかいいようがないんですが、クライアントに報告すべきかしないべきかは慎重に考える必要があります。
バグを報告するとちょちょっと直してよ、とかいうクライアントもいますし、何よりクリティカルなバグの場合、見積もりしてくれと言われたとしてもとてもじゃないけど責任を請け負いたくない場合もあります。
なので見なかったことにする。
む、ちょっと眩暈が。最近寝てなかったし。とか言いながら缶コーヒーでも飲んで一服しましょう。
するとどうでしょう、さっきまでバグを見過ごさないのはプログラマの矜持だとかなんとか言ってたのにあら不思議、とりあえず今改修対象のところだけ直そう。となります。
20個くらい書くつもりで見切り発車してみたものの、もうない。泥臭い作業にノウハウなんてないのだ。
所詮泥は泥。ドロドロ。細かいコードの書き方まで言い出せばいくらでもあるけど「些末なコードレビュー」の話したところで泥で足掻いてる人にとってはなんら救済にならないし別に必要ないよね。
さてここからは他にも泥臭い作業をしている人たちでノウハウを構築しようではないか。６番目以降を書く同志達を僕は待ち望んでいるッ！
多分http://anond.hatelabo.jp/20091010232609
システムテストに関してはhttp://anond.hatelabo.jp/20091010210506
で書いている通り
その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。
で、修正が必要な１機能しかデグレード試験しなくてよいと思っています。
私が言いたいのは
どのような共通化を行うか（共通関数をつくるか）内部設計書に宣言させて(して)、
責任者（そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間）とレビューして、
そのプロジェクトではどのような共通化が適切であるか合意をとるべきだということです。
合意とった内部設計書とおりに実装していなければ（勝手に新たな共通化関数つくっていれば）、
そもそも内部設計書に誤りがあれば、
その修正が呼び出してる20機能に必要な修正なら、20機能全部でデグレード試験し直しは必要。
1機能にしか影響しなくて他の19機能のロジックを変えたくない(デグレード試験したくない)なら、
逆 ２０機能で同一関数を使っているとその同一関数を１行修正すると２０機能全部デグレード試験し直し。
逆に２０機能を２０関数で使っていると、１つの関数を直しても１９機能のデグレード試験は不要。
よって、機能の共通化は必ずしも、トータルでの工数を減らしたりはしない。どころか、増やしたりもする。
結局、共通化する関数に求められる品質依存。その関数に求められるクオリティーが高い・技術的難易度が高い場合上位者が作って、下位作業者に呼ばせるだけのブラックボックス化したほうが良い。でないと、作れないし、まともな速度が出ないとか、全体が動かない。
とくに、普通の関数の場合は、担当者にオリジナルで作らせても問題ない。むしろ、オリジナルで作らせておいた方が勉強になるし、上記のように仕様変更による試験工数の影響が少ない。
その辺のバランス取りが設計力。設計力に、こうなるみたいな王道はなくて、チームメンバー他 状況次第の水物。それがわかっていないと、デスマするような無茶な設計したりする。そいうことだと最近思う。
