まとめ 発注額の桁が違う?PC-9801用アプリケーションの解析業務が話題に 20年以上前の見積もりシステム(?)の解析と仕様を起こすお仕事です。 どうも単純に逆アセンブルしただけでは全体は見えてこなさそうな雰囲気です。 発注側は何とか「単純」な仕事にしたいようですが、個人的にはこういった仕事にありがちな、蓋を開けてみると全く簡単じゃなかった案件じゃないかとみております。 23305 pv 66 4 users 156
![【更新あり】PC-9801のプログラム(ソースコード無し)をリバースエンジニアリングしてくれ!→変態技術の塊なことが判明しました](https://cdn-ak-scissors.b.st-hatena.com/image/square/d55ec004164189834b3f247325fdd8266ae8db74/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F3ac254c9bb3bfd839396f1c1fb43b151-1200x630.png)
高専の友達と呑んでいた。 なんでそういった話になったか覚えていないが、情報工学畑の僕が 「大学の実験ページを見たらコンパイラ演習が無くなっていて驚いた。情報工学でコンパイラも作ったことないってどうなのよ?アカンでしょ」 と言ったところ、電気電子畑の友が 「そんなもの『電気科で8石スーパーヘテロダインラジオも作らないで卒業するのは許せん!』と言っている老害と同じ。やるべきことは時代で変わる。会社でも特定の技術に長けて成功した人ほど、視野が狭くなって老害化してほんと困る云々」 というようなことを言った。 ちょっと話は逸れるけど、家電メーカーでもあるよね。一度テレビで成功しちゃったが故に、赤字になってもテレビをいつまでも家電の王様と信じて作り続けちゃう、みたいな。バカは死ななきゃ治らない、って言うけど赤字事業でもそれに従事するエンジニアは超一級で、そもそもかつてテレビは最先端の花形事業であって、
他社様のプロジェクトの事で。 開発チームに、企画チームが(このチームが分かれているのが俺的にはあり得ないんだけど)発注した内容が、「開発工数的に無理」(実験しないと実装方法の確定が出来ない)みたいな事があってモメたという話を聞いた。 間接情報なので事実とは異なるだろうが。勝手に。 「無理なものは無理だろ。せめて時間をよこせ」 というのが俺が開発なら言うセリフだと思うが。 モメたというのは「だがやってくれ」みたいな事があったと言う事。なにが「だが」だか解らない。 開発者は魔法の杖ではないので「他社のゲームがやってる事は全部実現できて当然で、実現できないのは技術力が無いか、やる気が無いかだ」という考え方はいい加減捨てた方がいいと思う。 ここで、開発チームは4つの選択肢がある訳だ。 1.頑なにやらない→評価が下がる 2.やるが時間はオーバーする→評価が下がる 3.徹夜してでもやる→なんだ出来るじ
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
お探しのページは一時的にアクセスできない状況にあるか、移動もしくは削除された可能性があります。 リンクが切れている場合は、こちらのお問い合わせフォームよりご連絡ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く