IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
C#がメインで他もまぁ諸々なブログです おかしなこと書いてたら指摘してくれると嬉しいです(´・∀・`) つーかコメント欲しい(´・ω・`) ビルド自動化のために。 PowerShell で Visual Studio のソリューションをリビルドするための関数。 ソリューションにセットアッププロジェクトが含まれている場合は注意が必要(後述)。 この関数は内部で Invoke-Process 関数を使用する。 [ パラメータ ] solutionPath ソリューションファイルのパス。 vsVersion Visual Studio のバージョン。 timeoutMilliseconds プロセスの実行時間に対するタイムアウト値 (単位:ミリ秒)。 無制限に待機する場合、-1 または Int32.MaxValue を指定。 省略した場合は -1。 [ 戻り値 ] 戻り値については Invoke
C#がメインで他もまぁ諸々なブログです おかしなこと書いてたら指摘してくれると嬉しいです(´・∀・`) つーかコメント欲しい(´・ω・`) コマンドレットのコンストラクタ辺りで、Debugger クラス (System.Diagnostics) の Launch メソッド を呼び出せばいいだけです。 PowerShell でコマンドレットを呼び出すとデバッガ選択ウィンドウが出てきますので、コマンドレットのプロジェクトを開いている Visual Studio を選択してあげてください。 他にも、Visual Studio の [ デバッグ ] - [ プロセスにアタッチ] にて、PowerShell に直接アタッチすることでも、デバッグ可能になります。 どちらにしろ、PowerShell にインストールしたスナップイン DLL が配置されているディレクトリに .pdb ファイルを配置するこ
Management, Building Manageable Applications, Design for Operations, WMI, DSI, MMC, VSMMD and of course Windows Powershell bye MSDN BLOG, Hello davidaiken.com Only the blog has moved. I still work for Microsoft. See www.davidaiken.com for more. Author: daiken Date: 05/30/2008 Visual Studio Team System Management Model Designer Power Tool (TSMMD) Ships Visual Studio Team System Management Model Des
第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?:連載 C++開発者のための単体テスト入門(1/4 ページ) 連載目次 「ビッグバン・テスト」をご存じですか? アプリケーション全体を構築する数千行、数万行に及ぶコードをコンパイルし、いきなり全体を走らせてその動作を確認するテスト手法です。われわれプログラマーが絶対に過ちを犯さないならともかくも、そうではない現実を考えると、このようなビッグバン・テストは極めてつたないテスト法です(そもそも過ちを犯さないなら、テストの必要はないのですけど)。 テストとは、ひと言でいってしまえば「思ったとおりに動くかを検証すること」でしょうね。プログラムは思ったとおりには動きません。作ったとおりに動きます。従って、「思ったとおりに動くか」の検証とは「思ったとおりに作られているか」の検証にほかなりません。 ビッグバン・テストでも「思ったとおりに動くか」
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
先日言及した大文字と小文字を区別しないディレクトリ名がリポジトリにあるとTortoiseSVNのチェックアウトに異常に時間がかかる件だが、Subversion側で対策用のフックスクリプトが公開されていることをdiscypusさんに教えて頂いた。 /case-insensitive.py (contrib/hook-scripts) - 大文字と小文字を区別しないために生じるファイル名の衝突を検出する pre-commit フックスクリプト 時間が空いたら管理者に聞いてみよう。 ところでこの問題の原因に気が付いたのは、Visual Studio 2005で使用するSubversionクライアントであるAnkhSVNアドオンで同様のリポジトリからチェックアウトした時にTortoiseSVNのように長時間無応答になるのではなく即座にエラーリターンしたからである。 同アドオンはTortoiseSV
Visual Studio 2005 C#のソリューションをチェックアウトするとO/Sごと砂時計でハングアップ。 今のところ原因全く判らず。 追記:原因が判明 以下のように頭一文字のキャメライズの有無だけが違う同一のディレクトリがリポジトリに存在しており、そこがチェックアウトの範囲に入っていると同様の症状が発生するようだ。 /trunk/Hogehoge/ /trunk/hogehoge/ ちなみにO/Sごとハングアップではなく、処理に異常な時間が掛かっているだけの模様。不要な方(今回は後者)を削除したところTortoiseSVNからのチェックアウトは成功した。 CVSではこのような名前でディレクトリ名が重複しても一見問題無く運用できていたので、そのままSubversionに移行するような場合は注意が必要だろう。
id:NyaRuRu:20070722#p2 のお題がおもしろいので、unfold 書いてみました。Orcas 立ち上げるのが面倒だったので C#2.0 で。 コードは最後にして、その前にいろいろと。 unfold ??? まずは unfold が何なのかわからなかったので Haskell の定義から。Hugs の List.hs から引用。 名前からして fold の反対だろうとは思うけど、畳み込みの反対って余計想像できなかったりw unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = case f b of Just (a,new_b) -> a : unfoldr f new_b Nothing -> []Haskell には unfoldr がありました。foldr、foldl はありますが、unfoldl はなさそう。
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
http://0xcc.net/blog/archives/000178.html このコードには長時間動作させる上で明らかにマズい点が二つあります。 (22:58追記: 問題のコードは既に修正されています。高林さん、すばやい対応ありがとうございます。) 「UNIXネットワークプログラミング」の別の節に解説はありますが、コードだけコピペした人が困らないよう指摘しておきます。 一つ目はSIGPIPEシグナルの発生に備えていない点です。 サーバーがレスポンスを返す前にクライアントがソケットを閉じてしまうと、write()がSIGPIPEシグナルを生成することがあります。 SIGPIPEの既定の動作はプロセスの終了なので、この状況が発生しただけでサーバーは勝手に(coreを残さず)終了してしまいます。 通常は次のような関数でSIGPIPEを無視します。 #include <cstring> #i
何ですかこれは? 二つのシーケンスのLongest Common Subsequence, Longest Common Subsequence Distance及びShortest Edit Scriptを求めるクラス。 Subversionのコードを、C++に移植したものです。 アルゴリズムは、"An O(NP) Sequence Comparison Algorithm" (Sun Wu et al.)に述べられているものと同一で、計算量は最悪でO(NP)、平均的にはO(N+PD)です。ただし、N=二つのシーケンスの長さの和、P=D/2-Δ/2、D=LCS距離、Δ=二つのシーケンスの長さの差です。 ここでいうLCS距離(longest common subsequence distance)は、あるシーケンスを別のシーケンスに変化させるために必要な、シンボルの挿入及び削除操作の最小
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
ユニットテストやテスト駆動開発(TDD; Test Driven Development)については、メリットや作り方の説明ばかりが先行している気がします。 現場にとって本当に必要なのは、どうやったら開発の現場に定着させることができるのかということではないでしょうか。 カバレッジだとか、より効果的なテストコードだとかは、ユニットテストが継続的に実施されるようになってからのハナシだと思います。 私が実際に、開発現場にユニットテストとテスト駆動開発を導入した経験から、この問題を考えてみたいと思います。コンテンツ障壁ユニットテストしたくなる環境オススメ障壁 まず、最初に意識しておいていただきたいのは、テスト駆動開発を導入する際に、障壁となるのは誰かということです。 テスト駆動開発の導入をもっともシブるのは、経営者でもマネージャでもありません。 技術者です。 普通、技術者(に限らないとは思いますが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く