 
|
はてなキーワード: バグとは
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
＜!DOCTYPE html＞ ＜html＞ ＜head＞ ＜meta charset="utf-8"＞ ＜title＞Is it a bug?＜/title＞ ＜/head＞ ＜body onresize="alert('a');"＞ ＜h1＞Is it Ok?＜/h1＞ ＜/body＞ ＜/html＞
コピペ用→ http://pastebin.com/qwm8fqTN
IE9だと問題なく動作するし、
chromeだとご丁寧に「このページからのポップアップをこれ以上出さないか」聞いてくれます。
ぼくの環境だけの事例かもしれないので、みんなも試してくれると嬉しいな。
で、みんなの環境でも同じようなら、これはfirefoxのバグということなのかな？
ブラクラつくれちゃうと困るのでなんとかなるといいなと思います。
「人数増やすと…」について補足。
http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1
スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。
近頃人気ですね。一時期のGREE・モバゲーバッシングはどこへやら。
と言う話はさておいて、今までソーシャルゲームとは縁の無かった方々がプレイしている影響か、
このゲームにやたらと夢を抱いている人が多いようです。
特に、『アニメ化されないか』『アイマス新作に誰か出演しないか』等のメディア展開に関係するものや、
『新イベントの提案』『全体的な動作改善』『ゲームバランスの変更』等のゲームそのものに対する要望が目立ちます。
断言しておくと、動作改善がやや望みある程度で、他は「ありえない」ですね。
理由は下記。
・KONAMIの戦国コレクションがアニメ化と言う前例がありますが、
あれはKONAMIが自社で製作しているゲームだから実現できた話です
よって、新作への出演も無理
知っての通りモゲマスは、既存ゲーム（神撃のバハムート→戦国サーガ→モゲマス）の
モゲマス独自の要素（親愛度）もありますが、バグの温床となっています
（しかもそのバグ修正の方法が非常に稚拙かついい加減だったことは記憶に新しいですね、
（ダブルクォートがあったりなかったり、スラッシュで閉じていたり閉じていなかったり）
パーサに掛けたらエラー連発でしょうね
既存ゲームの挿げ替えであるがゆえに、上記2つのゲームの同じ箇所で誤字脱字が存在しています
気付いていないのか、直す気がないのか…
・モゲマスに限った話ではありませんが、
この手のゲームは『人よりお金を多くかけた人』が俺TUEEEEを実現出来ないと成り立ちません
人よりお金を払わない・そもそも一銭も落としていない人に対する運営の優先度は極端に低いです
だからこそSRカードの性能は壊れていますし、今後もっと壊れていきます
これらを理解した上でプレイしたり数万円つぎ込むのは、別段問題があるとは思いません。
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
2chやTwitterを見てると、あのブログがソニーの回し者であるかのような流れになってるんだけど、何だか違和感を覚えるんだよな。
なので、とりあえず最近のあのブログのPSVITAタグの中からネガティブっぽい記事をピックアップしてみた。
1月だけでこれだけあるわけだが。
PS3の初期もこのブログはこんな感じだったし、ほんとにこいつソニーからカネ貰ってんのか？その辺はどういう解釈でみんな納得してんの？
12月も…と思ったけど多すぎて後半だけで力尽きた。
スマートフォンspモードの不具合で目下お祭り中のNTTドコモ。
どんな言い訳を発表してくるか楽しみにしていたら、
「スマートフォンの普及による通信量の増加でサーバーが能力を超えた」ときた。
相変わらず、自らの誤りは認めませんとも。
内情に詳しい人いわく、真相はバグだらけのソフトウェアを誰も直せないのが原因だって。
ロクな技術者を手配できないのは以前からだったような気もするが、そろそろ臨界のようだ。
spモードに関しては、Xperiaに搭載され大反響を巻き起こしたメールアプリも記憶に新しい。
今回多少ましな技術者に作らせたせいか、見知らぬ他人のメールアドレスにすり変わってしまうという
革新的な出会い系機能が実装され、華々しいサービス停止を披露してくれた。
どうやったらそんなバグ埋め込めるんだｗわざとか？
教えてくれ。
僕が小学生だった頃は、友達とファミコンの話ばかりして、友達の家でファミコンをするのが楽しかった。
ちょっと風変わりなテクニックから、裏技バグ技まで、ほとんどは口伝えだった。
攻略本というのはたいていは高価だったし、旬から一歩遅れて発売されてた。
ソーシャル機能なんかなくたって、友達とつながる快感があった。
そこには確かに、ソーシャルネットワークがあった。
攻略本が、僕のソーシャルネットワークを殺した。
あるいは僕のように、ゲームに没頭すれば、誰かに繋がれるような錯覚を信じて、コントローラを握るパブロフの犬が残った。
条件反射が解けちゃったんだな。
事実上性能悪いでしょ。
たとえばこのご時世で、NLS対応なんかが糞。
根本的な部分に手を出せないんだろ、「過去の安定した実績」とやらを保つ弊害だな。
Expressなんか無償である程度使わせておいて、バグ対処必要とのことで有償でパッチを配る。
パソコンにデザインやキーの感触、I/Oポートの配置などトータルでの洗練は無用、
クロックアップでベンチがすごいとか、PCI-X(出てるのかな...)にも対応、とかで
「さすが!」と嬉々とする厨房みたい。
まあ、Oracle様のアコギ商売、信者どもが守ってくれるからな。
「うまく使えないのは、使うおまえが下手なだけ」...って言ってお終いの、よく見かける世間のパターン。
という俺はゴールド餅だけど、新規DBにOracleは、俺の為にも会社の為にも絶対採用しない。
採用時の１従業員(SIerかもしれぬ)の好き嫌いで、業務が左右されてたまるかよ。(SIerなら、バックもあるのか？)
今後数年の保守やシステム拡張、何より費用面からして会社へ背任行為をするわけにいかない。
困るとすれば、転職ときの経験・スキルでOracle求められること。
DBの意味もわからない人事のひとがとりあえずメジャーということで
求人要件に載せやがるっぽくて参る。
http://www.limy.org/program/db/not_oracle.html
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30408&forum=7&start=8
SIerの下請けが現場でなんか新しいことやろうとすると、だいたいこんな感じの反応になる。
Excelでバグ管理っておかしくね？ お前それSIerが仕切ってる現場でも同じ事言えんの？ SIerの現場の何を知っているなめるな。 お前の意見は正しいSIerの現場以外ではな。 お前ってアレだよな… SIerの現場じゃ真っ先に死ぬタイプだよな。
その開発者の人に、伝えた。
彼からの回答は、こんな感じだった。
→便利にして間口を広くすると、顧客が増えると、文句言う人が増えるので、アンマリ、そういうのは好きじゃないって。
無料で出来るという事で。
何でも、かんでもモンスター顧客のような人が増えるのは、つらいということらしい。
sourceforge.netのオープソースでの開発ですが、
利用者が増えれば、嬉しい、多くの人に喜ばれたいって開発者もいるけれど、そうではないと。
→メールで色々と使った条件を書いてくれて、こんな時にこんなバグが起こりましたよ。
なんて、バグの報告をしてくれるなら、みんなハッピーになれる。
だけど、
「動かないですけど」
というのが困るらしい。
まずは、「ぐぐれカス」ってことだよね。
まぁ、日本語の解説を書いてもいいけどって言われた。
//ダイアログクラスにメンバ変数を定義 std::auto_ptr<CBitmap> m_pbmp; //bitmapを設定するメンバ関数 void C*****Dlg::Set*****Bitmap() { CDC* pDC = GetDC(); CDC memdc; memdc.CreateCompatibleDC(pDC); m_pbmp.reset(new CBitmap()); CBitmap&amp; bmp = *m_pbmp; bmp.CreateCompatibleBitmap(pDC, width, height); CBitmap* old = memdc.SelectObject(&amp;bmp); memdc.FillSolidRect(0,0,width,height, color); memdc.SelectObject(old); ((CStatic*)GetDlgItem(IDC_STAIC_*********))->SetBitmap(bmp); }
スクリーンと同じデバイスコンテキストとビットマップを作成し単色で描画している。描画し終わった後のSelectObjectを忘れてはいけない。
CStatic::SetBitmapに渡した後も実際に描画されるまでCBitmapの寿命を保証しなければならない。
そのためメンバ変数にCBitmapを持たせるがCBitmapが再利用を考慮していないという驚くべき仕様なので仕方なくauto_ptrでラップしている。
いい加減MFC滅びてくれないかな。抽象度が低すぎる。こんな記事自分のブログに書きたくないよ。
さらにVisualStudio 2005のauto_ptrのバグを見つけた operator = にポインタを渡すとおかしくなる。これは本来コンパイルエラーになるべきで代わりにresetメンバ関数を使用するべきだ。
修正するには<memory>ヘッダのauto_ptr_refのコンストラクタのひとつ上の行(642行目)に private: template<class T> friend class auto_ptr; を挿入する。
試験工程が始まり、新規参画メンバーに、ドキュメント与えて試験やらせても得られるアウトプットは、所詮ドキュメント通りにできているかが確認できるレベル。
リリース後にぼろぼろの品質の状態で、なんで試験でちゃんと見つけられないだと言われたとしても、設計通りのものが作成されているにすぎない。
試験メンバーに対して要件／仕様の説明／プロジェクトの前提条件の暗黙知を共有させる準備期間が必要であるはずだが、
そんな意識はまわりにない
組織のプロジェクトの共有意識のなさ、ソフトウェア全体に対してどうあるべきかを考える人が誰もいない状態に対して誰も疑問に感じない。
感じているかもしれないが、各論ばかり論じてお茶を濁している。
開発ツールによってプロジェクトの生産性向上をもくろんでいるはずが、開発ツールの設計が全く生産的でない。
バグ票も、試験の前提条件／試験方法／期待値も記載されず、ただ事象だけ書かれている。
それに対しても開発チームの回答も改修したレベルの記載で、原因／対応／横並びもなく、
開発チームの回答に対してプロジェクト全体として妥当であるかの判断も誰もしない
組織の人員配置／プロジェクトのあり方の不備をただ個人に押し付ける
ただただばからしい
http://anond.hatelabo.jp/20111210100542
俺ポケ○ン赤緑全盛期にミ○ウの出し方のバグ技とかをネットに仕入れてクラスに持ち込んでた世代だけど
15年くらい経ってる計算じゃね…？ あれ？ なんかおかしくね？ 時の流れがおかしくね？
癌は発見が早いほど治る可能性が高く、遅れるほど死亡率が上がる。このような常識を持っていながら、殆どの人は早期発見の十分な対策をしていない。
年１回の適当な検診では不十分だと思われる。吉田所長は去年の検診で異常なしだったが、今年食道癌が発覚して退職（という情報がある）。
がん検診はご存じの通りコストが高い。金も時間もかかる。PET検査でも受けようなら15万とか。庶民にはきつい。
しかし癌になったら高確率で早死にするのである。この間も癌で妻を亡くすまでの詳細な手記が話題になっていたが悲惨だった。今年は川上とも子も死んだ。30や40代でこの世を去ることは多くの人に不本意だろう。俺なら金を払っても避けたい。死んだらおしまいだ。周りも悲しむ。
いいPCを買ったり趣味に金やコストを使うよりも、癌の予防に使うべきだ。「不幸な死を避ける」ことに、社会がもうちょっと本気出してもいいのではないか。
日本がこんな状況になってしまったのだから癌は「なったらしょうがない、多分ならない」じゃなくて、なるものとして死なずに済むことを考えようぜ。
サーバーは落ちる、バグは起きるとの前提で対策をしておくのと同じだ。そういうことには合理的で神経質になるのに、自分の命に無頓着っておかしいだろ。事の重要さを天秤にかけて、正しく判断できるのが頭が良いということだ。
beta登場→betaにしてはバグ取れねーな、alphaより遅くなってるしこのバージョンはハズレか
RC発表→え…こんなバグバグでRC出しちゃうの…大丈夫か…？
final発表→なにこのクソバージョン、Opera終わったな
alpha登場→ちょｗｗｗｗｗ爆速ｗｗｗｗOpera最強伝説始まったなwwww
alpha登場→Opera信者「やべえ超はええOpera最強伝説ｗｗｗｗｗ」
beta登場→Operaマニア「betaにしてはバグ取れねーな、alphaより遅くなってるしこのバージョンはハズレか」
RC発表→Operaファン「え…こんなバグバグでRC出しちゃうの…大丈夫か…？」
・文章が打ちづらくない？
ただし、Androidはソフトウェアキーボードの実装が機種依存だから
打ちにくい 機種も存在している。打ちにくい機種は本当に打ちにくい。
ただ、AndroidはDPIもフォントも機種依存だから見辛い端末はみずらい
・スクロールやらクリックやら、マウス操作にあたる操作が面倒じゃない？
クソな端末は本当にクソ
古いやつはガラケーのほうが早い。
結論から英馬、ガリガリ打ち込む作業についてはノートPCのほうが断然いいけど
スマホユーザーの大半は電車の中でちょっと読むとかだろうから、問題ないだろ。
ただ、最新のどっかのスマホがバグだして販売中止？になってるみたいだけど
そんな感じで端末によってキーボードも液晶の品質も結構色々違う。スマホとおもって買うと有名メーカーでも
痛い目見ることがある。
上っ面じゃなくてちゃんとわかっている人教えてください。
▼モバイル版「Flash Player」の開発中止をどう見る？
http://japan.cnet.com/panel/35010348/300015677/
▼Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
http://jp.techcrunch.com/archives/20111109why-adobe-failed/
今後来るhtml5をもてはやす必要もなく、
で“既に代替されている”
html5厨の中にはこのあたりごっちゃにして歓迎してるやつが多数いる
くどいけど、その他の機能はjsとかcssとかhtml5周辺の独自仕様で
解決してることが多いからな！
普通にhtml5が覇権取るにはオーサリングツールがいるんだぞ。
全部含んでるんだ。
html5が現状見えてるのは、
までだ。
「描画系の機能でflash(flex sdk)同等の仕様を用意することになるだろう」
ってだけじゃ劣化flashすぎんだろ。
あとadobe終わったっていってるやつ、
それを一社じゃなくブラウザつくってる各社が実装するんだからな・・・
お前らがflash嫌ってるのと同じ問題が発生して、
flash殺すのはいいけど、html5を中心とした代替環境できんのに何年かかるんだよ。
あと、リッチインターフェース作るのに、いつまでもなんのサポートも受けれないような
jsライブラリ組み合わせて、必死にカスタマイズとデバッグしなきゃいけないのかよ！
業務系のuxデザインつくっていくのに、flex使おうか、html&css中心で行こうか悩んでんだ。
誰か何かアドバイスくれよ…
flexは良いところが多くて工数も減るし、どこかでadobeの5オーサリングツールに乗り換えられるだろうから
普通のweb屋としては、htmlとjsで苦戦しながらも自己責任でスクリプトチマチマいじってる方が、
他にもこの中途半端な状況に困ってる奴いるだろ！