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 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 >>
■20140  Re[1]: 検索プログラムについて
□投稿者/ 凪瀬 -(2008/06/06(Fri) 15:44:50)
>
    No20138 (名無し さん) に返信
    > (LinkedListと入力すると、Linked.classしか検索して表示されない)
    「LinkedList.class」かな?

    > 入力されたクラス名の全文一致検索しかできないので
    > 部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。

    パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
    ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。

    クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
    たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
記事No.20138 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20182  Re[2]: 検索プログラムについて
□投稿者/ 名無し -(2008/06/07(Sat) 09:51:19)
    No20140 (凪瀬 さん) に返信
    > ■No20138 (名無し さん) に返信
    >>(LinkedListと入力すると、Linked.classしか検索して表示されない)
    > 「LinkedList.class」かな?
    >
    >>入力されたクラス名の全文一致検索しかできないので
    >>部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。
    >
    > パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
    > ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。
    >
    > クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
    > たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
    >
記事No.20138 のレス / END /過去ログ39より / 関連記事表示
削除チェック/

■20259  Re[3]: 検索プログラムについて
□投稿者/ 倉田 有大 -(2008/06/08(Sun) 21:26:32)
    No20182 (名無し さん) に返信
    > ■No20140 (凪瀬 さん) に返信
    >>■No20138 (名無し さん) に返信
    > >>(LinkedListと入力すると、Linked.classしか検索して表示されない)
    >>「LinkedList.class」かな?
    >>
    > >>入力されたクラス名の全文一致検索しかできないので
    > >>部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。
    >>
    >>パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
    >>ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。
    >>
    >>クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
    >>たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
    >>

    この引用だけ返信は失礼とおもうのですが、わたしだけかいな。
記事No.20138 のレス / END /過去ログ39より / 関連記事表示
削除チェック/

■20141  Re[8]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ じゅで -(2008/06/06(Fri) 15:47:45)
    ・要員の再配置
    ・残業すれば出来る事は出来ない事にする。
    ・PMやPLが注視しなければならないワークパッケージを明確にする。
    (他は多少おくれても問題ないのは悪い言い方をするとほっとく)
    ・コアな部分は、内部の出来る人に任せる。外だししない。
    ・新人などを、人数に数えて、工数と照らし合わせて作業分担をしない。
    ・お客さんの要望を吸い出す人間とクラスなどの詳細設計を行う人間は、
    必要なスキルが違うので、明確に分ける。
    ・上司は、実装部分に口を出さない。必要であれば、技術力のある人間をつれて
    客先につれていく。
    (お客さんにできない事は出来ないといえるような仕事をとるのが一番ですorz)

    まだまだ色々あるでしょうが、長くかいてたら送信できなかったので、
    短くしてみましたorz
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

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

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

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

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

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

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

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

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

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

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

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

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

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

■20143  Re[13]: ディレクトリの排他アクセス
□投稿者/ す -(2008/06/06(Fri) 16:07:49)
    No20142 (れい さん) に返信
    > エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

    ん? そういうモデルじゃロックの意味がないでしょ?

    ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
    の間書き込み禁止するからロックの意味があるのでは?

    こういうモデルだと、相当長い期間ロックされるので、相当困ったことになると
    思いますが。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20145  Re[14]: ディレクトリの排他アクセス
□投稿者/ れい -(2008/06/06(Fri) 16:36:36)
    No20143 (す さん) に返信
    > ■No20142 (れい さん) に返信
    >>エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
    >
    > ん? そういうモデルじゃロックの意味がないでしょ?

    なぜでしょう?
    少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。

    > ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
    > の間書き込み禁止するからロックの意味があるのでは?

    おやや?
    それが「ふつう」だと考えるのですか。

    では す さんは「ディレクトリのロック」と聞いたときに、
    ディレクトリ内の整合性をとるための機能だと思うわけですね?
    NyaRuRuさんが示したTxFで実現されてるような機能を想像しているということですね。

    なるほど。

    「ロック」とばかり言っていたので誤解を招いたようですが、

    No19998 (れい さん) に返信
    > Windowsでファイルを開くとき、共有モードやアクセス権を設定して開きます。
    > 共有しないと設定してファイルを開けば、
    > 他のプロセスからファイルが削除されたり変更されたりすることがないという前提でプログラムを作れます。
    >
    > ですが、ディレクトリを扱う場合はこれができません。

    上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
    「共用アクセス制御」の方のロックを話題にしていました。
    .Net的に言うなら、「FileShare」の話です。

    一応誤解ないように書いておきますが、
    「FileStream.Lock」のようなロックはディレクトリにはありません。
    APIにもありませんし、Windows内部にもありません。

    ディレクトリのアクセス制御といったときにどんなアクセス制御の話をしてるのかよくわからない、
    というのもアクセス制御がない理由の一つかもしれないですねぇ。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20146  Re[15]: ディレクトリの排他アクセス
□投稿者/ す -(2008/06/06(Fri) 17:12:36)
    No20145 (れい さん) に返信
    > なぜでしょう?
    > 少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。

    そんなのに何か価値があります?
    エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
    するのと、大して違いませんが。。。

    >>ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
    >>の間書き込み禁止するからロックの意味があるのでは?
    >
    > おやや?
    > それが「ふつう」だと考えるのですか。

    おや、違うんですか?

    例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
    それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
    想定したのですが。。。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20148  Re[16]: ディレクトリの排他アクセス
□投稿者/ れい -(2008/06/06(Fri) 17:41:20)
    No20146 (す さん) に返信
    > ■No20145 (れい さん) に返信
    >>なぜでしょう?
    >>少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。
    >
    > そんなのに何か価値があります?
    > エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
    > するのと、大して違いませんが。。。

    No20027あたりで書いてますが、
    ファイルシステムを利用する側からみると大していいことはありません。

    ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
    エントリの属性を適用する際に整合性を維持することもできるとか。

    >>それが「ふつう」だと考えるのですか。
    > おや、違うんですか?

    私には「ふつう」どう考えるのかはわかりませんので、違うかどうかはわかりませんが、
    それを す さんが「ふつう」と捉えているというのはちょっと興味深いです。

    > 例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
    > それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
    > 想定したのですが。。。

    ふむふむ。
    やはりディレクトリ内での整合性の維持、ということですね。
    読み直してみるに、シャノンさんもそう捉えていたということかしら。

    「ディレクトリのロック」とだけ言うと、
    そう捉える人は少なからず居るようですね。
    「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20151  Re[17]: ディレクトリの排他アクセス
□投稿者/ す -(2008/06/06(Fri) 18:17:11)
    No20148 (れい さん) に返信
    > ファイルシステムを利用する側からみると大していいことはありません。

    それが、れいさんが欲してた「理由」なのでは?

    > ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、

    抜けはチェックの仕様がないような。
    重複のチェックは可能だけど、必要なのは場合によりけりだし。

    > エントリの属性を適用する際に整合性を維持することもできるとか。

    どういうことでしょう?

    > やはりディレクトリ内での整合性の維持、ということですね。
    > 読み直してみるに、シャノンさんもそう捉えていたということかしら。
    >
    > 「ディレクトリのロック」とだけ言うと、
    > そう捉える人は少なからず居るようですね。

    ロックで、整合性以外に思い浮かぶものがないんですけど。。。

    > 「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。

    と言われても、共用アクセス制御って知らないですけど。。。
    MSDNライブラリで引いても出て来ないし。。。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20150  Re[17]: ディレクトリの排他アクセス
□投稿者/ シャノン -(2008/06/06(Fri) 18:06:41)
    2008/06/06(Fri) 18:08:41 編集(投稿者)

    No20148 (れい さん) に返信

    出来ても何が嬉しい訳でもないけれど、そうなっている方が自然だと思う、ってことですかね?

    <追記>

    > 上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
    > 「共用アクセス制御」の方のロックを話題にしていました。
    > .Net的に言うなら、「FileShare」の話です。

    これはよくわかんなかったです。
    FileShare.None を指定すれば、同一プロセスからしか書き込めなくなると思いますが。
    (同一プロセスからさえ、別ハンドル経由では書き込めませんけど)。

    </追記>
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■20144  Re[12]: ディレクトリの排他アクセス
□投稿者/ ネタ好き -(2008/06/06(Fri) 16:10:28)
    >エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

    これは正しいと思います。DBでも読み込み可、書き込み禁止のロックは一般的です。
記事No.19998 のレス /過去ログ40より / 関連記事表示
削除チェック/

■22014  Re[18]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ さかもと -(2008/07/15(Tue) 09:01:43)
    宣伝エントリを上げようかと思いますが、(仮)ということでスピーカー各位のお名前を出しても良いものでしょうか?
記事No.21522 のレス /過去ログ44より / 関連記事表示
削除チェック/

■22019  Re[19]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ うつせみ(虚蝉) -(2008/07/15(Tue) 09:38:21)
    No22014 (さかもと さん) に返信
    5名のスピーカーの方々はかまわないと思います。
    (確定ですよね?ね?)

    そろそろ一ヶ月前ということで締めですよね。
記事No.21522 のレス /過去ログ44より / 関連記事表示
削除チェック/

■22055  Re[20]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ とっちゃん -(2008/07/15(Tue) 13:24:39)
>
    No22019 (うつせみ(虚蝉) さん) に返信
    > ■No22014 (さかもと さん) に返信
    > 5名のスピーカーの方々はかまわないと思います。
    > (確定ですよね?ね?)
    >
    > そろそろ一ヶ月前ということで締めですよね。

    そうですね。ぼちぼちと順番とかも決めないとですw
    というか...今週末までにもろもろ提出です>スピーカー各位&ディレクター

    そうしないと募集サイトが開けられなくてあちこちに宣伝が出せません。

    スピーカーの顔出しがNGっぽいのは、画伯くらいなので
    #他はみんな一度以上顔出ししてるw
    なので、画伯が問題なしなら誰も問題にはなりませんw

    ちなみに予定では福岡に行く前に E-Mobile が使えるようになってるはず<おいらw
    なので、中継は問題なくやれますよ。
    あるとしたら、おいらのセッション中にそのマシンでの中継が耐えられるか?
    というくらいw

    ま、今回はデモはない予定なので、多分大丈夫でしょうw
    というか、セッションだけならおいらは自分のマシンじゃなくてもやれるしw
    #MISAOはあったほうが面白そうなので、セッティングは必要ですが
記事No.21522 のレス /過去ログ44より / 関連記事表示
削除チェック/

■24265  Re[4]: 見積書作成ソフトを作りたいけどデータベースがわからない
□投稿者/ 堂島ロール -(2008/08/31(Sun) 09:03:45)
    みなさまが経験豊富な上司ならおっしゃるでしょう
    「データベースはそれほど難しいものじゃないんだから
     データベース勉強してからやっとけ」
    ということですよね

    ありがとうございました
    上記URLも参考にやってみます
記事No.24246 のレス / END /過去ログ45より / 関連記事表示
削除チェック/

■24267  Re[2]: プログラミングの学習法について
□投稿者/ 北圭次 -(2008/08/31(Sun) 10:30:55)
    >「目標を高く持つことです。無謀と思っても絶対にできると信じれば、
    >必ず実現します。思い込みこそが力です」

    >学習じゃなくて楽習って考えればいいピヨ。

    >まー失敗学ですね、いっぱい失敗して欲しい。

    >進み続ければ抜けられないトンネルはないので頑張って下さい。

    たくさんの力になるお言葉、ありがとうございます。
    また、学習法についても詳しくおしえていただき感謝しております。

    >Jitta on the wayさんが記載されているような、アプリケーションを作ってみたらいかがでしょう
    >か?
    はい。チャレンジしてみようと思っています。
    今後ともご指導のほどよろしくお願いします。
記事No.24251 のレス / END /過去ログ45より / 関連記事表示
削除チェック/

■24266  Re[1]: プログラマーと栄養ドリンク
□投稿者/ ちわわ -(2008/08/31(Sun) 09:53:56)
    No24264 (倉田 有大 さん) に返信
    > 会社で働いているとき!
    > デスマーチのおとも栄養ドリンク!
    > 近くのコンビニで、みんなで買いに行った記憶があります。
    > みなさま、何か常用の栄養ドリンクってあります?
    >
    > ちなみに私は錠剤にかえました。安いので^^;
    > キューピーコーワiにしようかなと思ったのですが、有名メーカー品でたかいので、ジャパンで売っている180錠、1800円ぐらいのにしました。
    > 一日(2錠まで)
    > カフェインははいってないので眠気ははらせませんが〜
    >
    > ブルーベリーを一年ほど飲み続けましたが。効果わからん〜
    > なにげに、ブルーベリーは月に1400円ぐらいするので、ビタミン剤の方がやすいんですよね。

    栄養ドリンクは、ほとんど効き目がないそうですよ。
    ドリンクを飲んで効いたとしたら、それは薬のプラシーボ効果と同じようなものかもしれません。
    ドリンクに入っている成分は、ほとんどが糖分で、それが疲れを一時的にもとってくれる、特に
    脳の疲れには糖分が効くそうですね。
    私は、そういった健康食品には拒絶反応があるのでほとんど飲んだことがありませんが、
    効くと思って飲むのなら、それはそれでよろしのではないかと考えています。

    ちなみにプラシーボ効果も薬の薬効だけでなく、効くと思いこむ気持ちが、体を賦活させる未知の
    成分を大量に分泌させることもある、という説が、いつか医学的にも証明される日がくるかもしれませんね。

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

■25902  Re[2]: CG関連の数学の情報源について
□投稿者/ ごう -(2008/09/27(Sat) 11:20:14)
    No25901 (なちゃ さん) に返信
    > 幾何の教科書
    > 入門系の3DCGプログラミング本
    >

    こんにちは。
    まず行列について勉強されることをお勧めします。
    行列演算について理解が出来ればいいので、入門書1冊マスターするぐらいの知識が必要です。
    画像処理にまつわるライブラリというのもいくつかありますが(OpenCVなど)
    行列をマスターしないと扱えないものが多いんですよね。空間図形になればなおさらです。

    行列(幾何)の教科書は、石村園子氏の入門書「すぐわかる線形代数」などのシリーズがおすすめです。
    (「行列とは何ぞや?」という文系の方でも、読みやすくとっつきやすい内容かと思います。)


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

■32014  Re[6]: C++→C#
□投稿者/ επιστημη -(2009/01/30(Fri) 18:27:31)
>
    > まず答えを求めてそれをじっくり吟味して学習していく方法は間違っているのでしょうか?

    それがやれるのは土台がしっかり組みあがってから。
    # C++できるんならそんなに難しくないっすよ > C#
記事No.31995 のレス /過去ログ56より / 関連記事表示
削除チェック/

<前の20件 | 次の20件>

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 >>

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

パスワード/

- Child Tree -