reading
You Should Read
archives
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
blogs I read
- Caspian Arts
- Coding Horror
- ComputerZen
- Joel On Software
- Knowing.net
- MSBuild Team Blog
- Rob Howard
- ScottGu
- Scott On Writting
- Signal vs. Noise
- SimpleBits Articles
Thursday, November 04, 2004
Discovering .NET Reflector
Reflector is a class browser for .NET components. It supports assembly and namespace views, type and member search, XML documentation, call and callee graphs, IL, Visual Basic, Delphi and C# decompiler, dependency trees, base type and derived type hierarchies and resource viewers.The disassembler included with the tool can decompile any of our .dll files we have created with Visual Studio and allow you to view the source code. It will also convert that source code into VB, IL, Delphi, or C#.
Another way to use the tool is to look-over the assemblies included in the .Net Framework. You can then see how MS created their classes and how you can extend those classes to better serve your needs.
Tuesday, November 02, 2004
New Google Groups Beta
You can now subscribe to groups. The left nav displays a list of your subscribed to groups as well as groups you have recently visited. You can track threads you want to follow.
So far, I am impressed. Good job Google.
Monday, November 01, 2004
Testing ASP.NET 2.0 and Visual Web Developer
A tester can use Maddog within their office to build a query of tests to run (selecting either a sub-node of feature areas – or doing a search for tests based on some other criteria), then pick what hardware and OS version the tests should run on, pick what language they should be run under (Arabic, German, Japanese, etc), what ASP.NET and Visual Studio build should be installed on the machine, and then how many machines it should be distributed over.
Maddog will then identify free machines in the lab, automatically format and re-image them with the appropriate operating system, install the right build on them, build and deploy the tests selected onto them, and then run the tests. When the run is over the tester can examine the results within Maddog, investigate all failures, publish the results (all through the Maddog system), and then release the machines for other Maddog runs. Published test results stay in the system forever (or until we delete them) – allowing test leads and my test manager to review them and make sure everything is getting covered. All this gets done without the tester ever having to leave their office.