C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 >>
■20264  Re[13]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ やじゅ -(2008/06/09(Mon) 02:12:06)
>
    デスマーチがなくなる? IT業界に義務付け「工事進行基準」ってなんだ
    http://www.atmarkit.co.jp/news/analysis/200803/31/sier.html

    ■今現在  :開発終了時に売り上げと原価を一括計上(どんぶり勘定の原因)
    ■2009年4月:開発期間中にその売り上げと原価を開発の進捗度に応じて、分散して計上

    会計基準が変わるから、デスマーチがなくなるとは言い難いけど
    多少なりとも影響はありそうですね。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20265  Re[14]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/09(Mon) 07:41:36)
    また一つ思いついたので書きます。
    デスマーチは体調だけではなくて人間関係を壊します。
    デスマーチになってしまったら、憎まれてもいいぐらいの勢いでズバッとする必要があるので、
    しがらみが無い外部の人間を呼ぶのは効果的かもしれません。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20266  Re[15]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ ネタ好き -(2008/06/09(Mon) 08:02:57)
    2008/06/09(Mon) 08:10:22 編集(投稿者)

    デスマーチを根源的に防ぐには、この業界共通仕様が必要だと思います。

    1、価格・・・いい加減人月単価は止めましょう。
    2、期間・・・〇〇ならば1月とか、統計を取って標準期間を設けるべきです。
    そうしないと優秀な人ほど損をします。

    他にもあると思いますが、情報処理技術を知らない社長の下、一会社の閉じた空間内で適当にやっているからデスマーチが発生するという気がしてなりません。
    私はデスマーチ以外のプロジェクトに参加した事が無いのですが、やっぱり大きな原因は「上司の無知さ」でした。どんぶり勘定、どんぶり仕様、どんぶり納期ではデスマーチになるのは当然だと思います。
    それに、この業界技術が上がれば上がる程色々損をしませんか?

    【実例を追記】
    1、デスマーチのプロジェクトは、作業範囲が曖昧で自分の仕事が終わったら他の人の尻拭いまでさせられます。しかも、尻拭いをした人よりも給与が低かったりします。
    断れば「デスマーチ中に何をしている?」といわれて人事の評価ダウンですしどうしようもありません。

    2、変にいいアイデアを出してしまうと奪われて文句を言うとクビをきられます(知的財産の窃盗が多発)

    3、余りに酷い状態なので辞めたくなったらその会社の製品について詳しいと勝手に危険を感じて就職妨害をしてきます。

    4、デスマーチ中活躍してしまうと、違うプロジェクトでも余分に作業を押し付けられる。もちろん給与は上がらないまま・・・
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20269  Re[16]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ こあら -(2008/06/09(Mon) 10:06:11)
    No20266 (ネタ好き さん) に返信
    > 2008/06/09(Mon) 08:10:22 編集(投稿者)
    > 【実例を追記】

    起業して上場。これですべて解決しそうですね。

    自分の仕事を卑下するようで、あまり言いたくはないのですが、
    私自身、今すぐ誰かと交代可能だと思っています。

    自分がやってこなかったことを棚に上げさせて頂きますが、
    素直にうらやましく感じます。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20270  Re[17]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ じゅで -(2008/06/09(Mon) 10:26:36)
    最近技術力の低下が目立つような気がしないでもないです。

    昔々仕事をしていた時は、2進・8進・10進・16進の暗算や、
    メモリのダンプを見て、ここがおかしいとか言う変人が
    多々居た気がしますが、どうもここ最近そんな人々を見た事が無いです。

    なにやらダンプを見るのもコツさえつかめば簡単だよとか言ってた
    おかしな人もいましたし・・・orz

    そんな中で、自分は今Windowsのプログラムを組んでますが、
    先人たちには、恐ろしい化け物が居た為、今の自分の実力など
    下の下の下くらいに位置しているのがわかっているので、
    日々勉強しているのですが、最近そういった事が無いですよね。

    今の自分から見ても、5年目とか6年目とかのPGやSEであほか?
    というような人々が平気でプログラム設計などをやっているのが
    おかしいような気もします。

    そういう意味では、PMやPLだけの問題ではなく、
    実装を行う人間の質の低下も問題のような気がします。

    この業界、人が増えたのはいいですが、良質な人間が
    増えたかといわれると、首を傾げざるえない気がします。

    # 当然私も首を傾げられる側の人間だと自覚しておりますorz
    # 本当にすいません。
    # たぶんここにおられる方々と一緒に仕事をしようものなら、
    # 怒鳴り散らされるような気がしてなりませんorz
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20276  Re[18]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ ネタ好き -(2008/06/09(Mon) 11:49:53)
    No20270 (じゅで さん) に返信
    同感です。私もその化け物に弟子入りしたくてワクワクしながら社会に出たらとんでもない状態でした。
    自分の技術力が低くて師匠に怒られるつらさなら耐えられます。
    しかし、新人の自分よりの先輩の能力の低くて、さらにその尻拭いをされるとなれば、もう耐えられませんでした。おまけに、その初めての会社がブラック企業で、入社してみたらまともな開発者が居なくて、私が一人で自分のアイデアをフル実装をしてその作品を盗られたうえ給与未払い状態でしたorz。
    おまけに辞める際に「ここ辞めたらこの業界生きていけると思うな」と脅されつつしたら、就職妨害が酷くて履歴に書けなくなりました。仕方が無いので欲を言わずに探すとまたブラクック企業の連続、果てには「君のアイデアをくれ」といわれて対価を要求したらクビにされた事があります。
    【私の技術力は決して高くはありません】。しかし、「俺より強い奴に会いに行く」と思って社会に出たら、何故か自分の周りには技術者は居ず、卑怯者しか居ませんでした。
    私が特別運が悪いのか、それともこの業界それが普通なのか分かりませんが、下を見ても仕方が無いのでひたすら技術力を高める事をだけを考えて生き恥を晒しています。
    デスマーチとは直接関係ないのかもしれませんが、技術者のレベルの低下も間接的原因になると思います。
    長々と失礼しました。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20278  Re[19]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ 鶏唐揚 -(2008/06/09(Mon) 12:13:06)
    No20276 (ネタ好き さん) に返信
    > ■No20270 (じゅで さん) に返信
    > 同感です。私もその化け物に弟子入りしたくてワクワクしながら社会に出たらとんでもない状態でした。
    > 自分の技術力が低くて師匠に怒られるつらさなら耐えられます。
    > しかし、新人の自分よりの先輩の能力の低くて、さらにその尻拭いをされるとなれば、もう耐えられませんでした。おまけに、その初めての会社がブラック企業で、入社してみたらまともな開発者が居なくて、私が一人で自分のアイデアをフル実装をしてその作品を盗られたうえ給与未払い状態でしたorz。
    > おまけに辞める際に「ここ辞めたらこの業界生きていけると思うな」と脅されつつしたら、就職妨害が酷くて履歴に書けなくなりました。仕方が無いので欲を言わずに探すとまたブラクック企業の連続、果てには「君のアイデアをくれ」といわれて対価を要求したらクビにされた事があります。
    > 【私の技術力は決して高くはありません】。しかし、「俺より強い奴に会いに行く」と思って社会に出たら、何故か自分の周りには技術者は居ず、卑怯者しか居ませんでした。
    > 私が特別運が悪いのか、それともこの業界それが普通なのか分かりませんが、下を見ても仕方が無いのでひたすら技術力を高める事をだけを考えて生き恥を晒しています。
    > デスマーチとは直接関係ないのかもしれませんが、技術者のレベルの低下も間接的原因になると思います。
    > 長々と失礼しました。
    >
    一時期、ITとは畑違いの事業主が単純に儲かる・ブームだからという理由でそういう会社を設立しまくってた時期がありましたね。
    ネタ好きさんがどの時期に入社されたのかはわかりませんが、もしその時期と被っていたとしたら、
    不運とも言えますしミスチョイスとも言えます。今もまだそういう会社が存在しているでしょうけど
    割合としてはある程度マシになってきたと思います。私のとこも、優良とはいえませんが劣悪というわけでもありません。
    サラリーマンやってくには標準的だと思います(プログラマの思考回路に合わせない発言ばかりする役員ばっかりなのでやりにくいですが)

    まぁ、お金さえ工面できれば私も会社など辞めて自分の技術を磨き、ばしばしソフトウェア作って
    晒して生きたいと思ってますけど、独り身ではない(夫婦じゃなくて家族的な意味)ので
    安定収入必須なのが悩みどころです(稼ぎ手が私しかいない。4人養うのは大変)
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20279  Re[20]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ ネタ好き -(2008/06/09(Mon) 12:23:23)
    2008/06/09(Mon) 12:24:25 編集(投稿者)

    No20278 (鶏唐揚 さん) に返信
    私(29歳)が新卒の頃は地域的な問題かもしれませんが、とにかく就職難でした。
    それこそブラック企業でもなんでも就職しなければ生きていけませんでした。
    それでブラック企業を渡り歩いていたわけです(何社か忘れました)
    でも、今はそんなこともないようでほっとしました。
    私自身は今もなお生き地獄(目下サバイバル生活中)ですが、それだけに他人にその苦しみを味わいさせたくはありません。
    トリカラさんところがそんなところでなくて本当に良かったです。
    この業界もよくなってきたんですね。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20281  Re[21]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ じゅで -(2008/06/09(Mon) 12:31:56)
    小さな会社には、いまだ知られていないブラック企業が多々あったりします。
    ここら辺の会社は、かってに沸いて出てきますから・・・

    昔いた会社は、業績悪化とともに、神棚が出来て、お祈りをしていました。

    もっと別にやる事があるだろうとorz

    そういえば、自分も新入社員の頃は、ブラックでしたね・・・
    ブラックというか・・・派遣だったorz

    下駄をはかされ、現場に潜り込まされ、何度苦労した事か・・・orz

    今は今で、色々問題があります。
    出向先が真っ黒なので・・・

    # 今は正社員ですよ・・・けどそろそろまた会社を移ろうか考え中ですが・・・
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20466  Re[18]: デスマーチプロジェクトの立て直し・防止につい
□投稿者/ RUN -(2008/06/10(Tue) 22:26:03)
    > なにやらダンプを見るのもコツさえつかめば簡単だよとか言ってた
    > おかしな人もいましたし・・・orz

    ん〜、昔はダンプ読めたな〜、今はすっかり読めなくなってしまったが。
    読めてた当時は確かに、読むコツってのは有ったんだが思い出せん。

    ダンプに限らず、下級言語とか触ってないと確実に忘れてくね〜
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20510  Re[1]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ Z -(2008/06/11(Wed) 13:10:19)
    No20108 (やじゅ さん) に返信

    > ・期間を短縮するために、画面チームと業務ロジックチームに分けた。

    自分は全く逆の発想をしました。

    「画面+ロジック+DB」を1処理ととらえ、ある機能の開始画面から完了画面までの遷移を1業務とし、

    この処理と業務間の繋がりの中で共通的にやれることを土台となるクラスで徹底的にやり、ソースを
    書く手間をなるべく減らす。(例えば、入力情報やDB取得情報の画面間の持ち越しとか)

    さらに1人が1業務というスタイルにしたので、例えば「画面とロジック」や「画面と画面」間の連携
    についての意識合わせやドキュメントは基本的に必要なし。(少なくとも開発時では)

    癖のあるやり方(MVCもあまり意識してないし)だとは思いますし、
    他の人に慣れてもらう時間も必要ですが、
    ソース量の減少ということについては、達成できました。

    デザイナがこだわりにこだわった画面にする場合は、さすがに難しいですが、
    シンプルな画面、シンプルなSQLなら、分ける必要もないって思っています。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20105  Re[10]: ディレクトリの排他アクセス
□投稿者/ れい -(2008/06/05(Thu) 18:57:25)
    No20064 (y4yama さん) に返信
    > ■No20042 (れい さん) に返信
    >>ファイルハンドルと同様にも導入していれば、
    >>ファイルもディレクトリも同等に扱うAPIになっていたかもしれない。
    > 手元に1997年のwin32 APIオフィシャルリファレンスがあって、CreateFileを何気なく見たら
    > ディレクトリハンドルを返すことが記載されています。(1997では、NTに限るとあるような、?)

    はい。
    ディレクトリハンドルを取得することは可能です。排他で開くことも可能です。
    ですが、そこからエントリのリストを得るのはめんどくさい方法しかありません。

    > どうも、95,98では欠如してて、NT,2000以降では同等に扱うAPIに(現在)なっている・・という
    > 解釈はできないでしょうか? (私が、変な勘違いをしておりましたら、お許しください)

    はい。
    NT系では内部でほぼ同等に扱っています。
    95系はよくわかりません。

    私はユーザーモードアプリケーションが通常使うであろうAPIで同等になっていない、
    ということを問題にしています。

    ディレクトリ内のファイルリストを得るのに、今はFindXXXFike系のAPIを使います。
    しかし私は、
    CreateFileでディレクトリハンドルを開きそのハンドルを指定してFindFirstFileを呼ぶ、
    というような実装の方が綺麗で分かりやすいと思うのです。

    No20068 (す さん) に返信
    >普通に考えてディレクトリロックなんて傍迷惑な機能はないほうがよいのでは?

    その考えは全然「普通」ではないと私は思っています。

    まず、ディレクトリを排他で開く機能は「すでにあります」。
    OSは利用しています。
    必要ないから実装してないということにはなりません。

    また、ファイルIOはいつ失敗するか分かりませんので、
    ディレクトリのエントリ列挙をするときには例外がおきたときの処理を入れる必要があります。
    この処理が適切に入っていれば、ディレクトリの排他ロックがあっても問題なく動作します。
    「他のひとはエラー対処で大変なことに」というのは間違いです。

    同様に、再試行もデッドロックの検出も、今でも行わなければいけない事項です。

    つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
    ディレクトリの排他ロックが可能であってもコード量は変化しません。
    大変なことにはなりません。

    ですので、私は、「普通に考えて」ディレクトリを排他で開けるOSの方がよいと思ったわけです。

    問題になるとするなら、774RRさんやPATIOさんの言うように、
    共有違反やアクセス違反が頻発してしまってファイルIOに不具合が生じたり、パフォーマンスが悪くなる、
    という点です。

    どの程度悪くなるのかは実際にやってみないとわかりません。
    OS作成者がどう判断してもおかしくありませんが、
    私はあまり問題にならないと予想しています。

    y4yamaさんのリンク先、NyaRuRuさんの記事でも述べられていますが、
    ディレクトリが開かれているためにフォルダが削除できなくなることは現在でもありますが、
    あまり問題になっていません。
    ファイルを排他で開いても、それほど問題になりません。
    ですので、孫子まで自動でロックするような実装にならない限り、
    それほど大きな問題にはならないと思います。

    ちなみに、NTFSでディレクトリハンドルを排他で開いても、サブディレクトリはロックされません。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20137  Re[11]: ディレクトリの排他アクセス
□投稿者/ す -(2008/06/06(Fri) 14:25:25)
    No20105 (れい さん) に返信
    > つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
    > ディレクトリの排他ロックが可能であってもコード量は変化しません。
    > 大変なことにはなりません。

    そんなことはありません。エラーの発生状況や頻度が変われば、
    対処も変えなければなりません。

    > どの程度悪くなるのかは実際にやってみないとわかりません。
    > OS作成者がどう判断してもおかしくありませんが、
    > 私はあまり問題にならないと予想しています。

    そんなことはないと思います。同時実行性が相当損なわれると思います。

    > まず、ディレクトリを排他で開く機能は「すでにあります」。
    > OSは利用しています。

    なら、予想より実際に試してみたほうが早いのでは?
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20142  Re[12]: ディレクトリの排他アクセス
□投稿者/ れい -(2008/06/06(Fri) 15:50:45)
    お。
    お返事が。

    No20137 (す さん) に返信
    > ■No20105 (れい さん) に返信
    >>つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
    >>ディレクトリの排他ロックが可能であってもコード量は変化しません。
    >>大変なことにはなりません。
    >
    > そんなことはありません。エラーの発生状況や頻度が変われば、
    > 対処も変えなければなりません。

    んー。そうですね。
    共有違反の頻度が激しく上がるなら、
    根本的に変えなきゃいけない場合もありえると思いますが…

    > なら、予想より実際に試してみたほうが早いのでは?

    それがですね。
    一応やってみてはいるんですが…確かなことが言えないのです。

    確かにユーザーフォルダとかをロックすると多少困りはしますが、
    エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

    乱用しまくると確かに邪魔ですが、ファイルロックの乱用も同様に邪魔です。
    それと比べてどのくらい邪魔なのか、どう比較するのかわかりません。

    どこまで行儀の悪いプログラムを考慮するべきかというのもよくわからない要素の一つで。
    最悪プロセスを殺せばいいわけですが、
    それをどの程度重く考えるべきなのかも人や状況によって違います。

    条件が複雑で曖昧なので、
    普通に考えて全然問題ない、とも言えず、
    普通に考えてロックがうざくて使えない、とも言えないなぁと。
    微妙な感じです。

    OSは結構な頻度でディレクトリを「共有書き込み禁止」で開いてますが、
    邪魔になることは普通ありませんよね?
    それはアクセスが細切れになってるから邪魔じゃないのか、
    邪魔にならないようにシステムが調節してるのか、
    そもそもディレクトリロックはそれほど邪魔じゃないのか。

    いろいろ試したのですが、自信を持って言えるほど十分に試せませんでした。
    #予想としては困らないと思うんですが…。
    私が気づいていない致命的欠陥があったり、何か大切なところで勘違いしてたり、
    そういうことがありそうなのでここで皆さんの知恵をお借りしたいと。

    > そんなことはないと思います。同時実行性が相当損なわれると思います。

    排他でアクセスできるようなシステムだと「同時実行性が相当損なわれる」ような状況というのは
    どのような状況でしょうか?
    まさにそれが、知りたい所です。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■22010  Re[3]: InputManを組み込んだFlexGridのセル内での改行
□投稿者/ オガシン -(2008/07/15(Tue) 02:27:45)
    参考になるかどうか微妙なところですが思ったところを書きます

    @InputmanのみでMultilineプロパティをTrueにして入力したら
     複数行の入力が可能ですか?

    AFlexGridのKeyPressイベントみたいなキーボードが押された時に発生する
     イベントがありますか?

    もし@、Aともに○という結果であれば
    'a'を押した時はFlexGridのイベントでは'a'に割り当てられた処理がなにもなくて
    そのごInputmanのイベントに処理が移ってテキストボックス(エディットボックスでしたっけ)に'a'
    が表示される。
    しかしEnterの場合はFlexGridのイベントでEnterキーが押されたら次の要素に移動という処理が実装されていて
    Inputmanのイベントに到達するまえにFlexGridoの次の要素に行ってしまうとかでしょうか

    一回それらしきイベントを両方実装してみてブレークポイントを設定して
    どっちが先にイベントとして発生してみたら多少は解決になるかもしれません。

記事No.21890 のレス /過去ログ42より / 関連記事表示
削除チェック/

■22115  Re[11]: 管理人様へ
□投稿者/ じゅで -(2008/07/15(Tue) 20:08:20)
    > やじゅさんじゅでさんのなまえの由来は、何でしょう?
    > よろしかったらおしえてください。

    元々は、judeccaというHNだったのですが、なんと読むのと聞かれまして、
    ジュデッカと答えていたら、そのうち何時の間にやら略称が「じゅで」となりまして、
    以来そのHNとなっております。

    ただ、この掲示板ではないです。
    というよりも・・・掲示板でもないです・・・
    元々オンラインゲーム側で使っていたHNなのです。
    ずいぶんと昔になりますが・・・
記事No.21945 のレス /過去ログ42より / 関連記事表示
削除チェック/

■23919  for文について
□投稿者/ sac -(2008/08/25(Mon) 00:17:57)

    分類:[.NET 全般] 


    VS2003のC#でコーディングしているのですが、
    年と月の処理の部分で困っています。

    どのような処理かと言うと、
    開始年(コンボボックス)開始月(コンボボックス)〜終了年(コンボボックス)終了月(コンボボックス)
    を選択した結果を「表示」ボタン押下時に「データグリッド」に出力したいのですが、
    選択した期間をXヶ月でfor文を使いループさせ(例:2008年8月〜2010年2月)、
    Xが12ヶ月を超えたら、月を1に戻し、かつ年を1プラスするというループ文を作成したいと思っています。

    for (int m = 0; m < (((y.endyear - y.Syear)*12)+(m.endmonth - m.Smonth + 1)); m++)
    これにプラスとして、選択期間が28ヶ月だとしたら、ループが12を超えたら月を1に戻し、かつ年を1プラスしてデータグリッドに表示させるという処理を行いたいです。

    どうかご教授お願いいたします。
親記事 /過去ログ45より / 関連記事表示
削除チェック/

■23922  Re[3]: for文について
□投稿者/ επιστημη -(2008/08/25(Mon) 08:36:54)
>
    > うーん、DateTimeに変換して素直に書いたほうがいい気がしないでもない。
    ↓ですよねー
    
    using System;
    using System.Collections.Generic;
    
    class Program {
    
      // fromYear から toYear を越えない範囲で列挙する
      public static IEnumerable<DateTime> DateRange(int fromYear, int toYear) {
        DateTime dt = new DateTime(fromYear,1,1);
        do { yield return dt; dt = dt.AddMonths(1); } while ( dt.Year <= toYear );
      }
    
      // おためし
      public static void Main() {
        foreach ( DateTime dt in DateRange(2008, 2010) ) {
          Console.WriteLine("{0}/{1}  ",dt.Year,dt.Month);
        }
      }
    }
    
記事No.23919 のレス /過去ログ45より / 関連記事表示
削除チェック/

■24258  Re[2]: 見積書作成ソフトを作りたいけどデータベースがわからない
□投稿者/ 堂島ロール -(2008/08/30(Sat) 22:42:27)
    多くのレスをありがとうございます

    今日たくさんの参考書をかってきました
    データベースを少しずつ勉強していきたいと思います
    今教えていただいたことと、私が本で得たデータベース知識とを考慮した結果ですが

    @テーブルというかデータをソートする際に、機械的なソートをすることはなく
     入力した順番を再現するだけで必要十分である
    Aデータベースよりも、enumとコレクションの組み合わせのほうが自由度が高く
     ちょっとした機能が追加しやすい
    B計算そのものは結局vb.netでやることになりそう
    CSQLよりもvb.netのほうがデバッグしやすそう

    物理的な障害がない限りはデータベースは使わずに済ませたく感じてしまいますが
    これはデータベースを知らないからこう思うだけなのでしょうか
記事No.24246 のレス /過去ログ45より / 関連記事表示
削除チェック/

■25748  Re[12]: 再帰によるスタックオーバフローエラー
□投稿者/ たくボン -(2008/09/25(Thu) 14:21:45)
    No25741 (渋木宏明(ひどり) さん) に返信
    > PE のヘッダ情報をいじるだけですよね>editbin
    そうみたいですね。

    > マネージコードってホストプロセスのスタックそのまま使うんでしたっけ?
    スレッド単位だからメインスレッドのスタックを消費するんじゃないかな?この辺りは調査してないから断言できないけど、MSDNに

    http://msdn.microsoft.com/ja-jp/magazine/cc163491.aspx

    と書いてありますね。この資料はLilyさんにとっても参考になると思うので、読んでみてください。

    > とか、他にもいろいろ疑問があるけど、不毛な方向にしか発展しない気がするので深く掘り下げていません>じぶん

    スタック関係とかメモリ絡みは不毛な方向にしか発展しないかもしれないですが、プログラマとしては押さえておきたい部分ですね。
    GCとか絡むようになって楽になった部分は大きいけど、意識しないプログラマが増えたのも事実。
    去年は携帯を開発していて、ずっとCでしたがメモリの管理が自由にできるのはある意味気持ちいいですよ:-)
記事No.25671 のレス /過去ログ47より / 関連記事表示
削除チェック/

<前の20件 | 次の20件>

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 >>

ヒット件数が多いので過去ログ1〜76 までの検索結果 / 過去ログ77からさらに検索→

パスワード/

- Child Tree -