A day in the life of...

Finally there is proof that God exists. The proof has come in the guise of a product named Balsamiq . Balsamiq allows you to create mock GUI when specifying an application. Rather than having graphics that look like real forms etc it uses a pencil drawing lookalike approach. Here is my reasoning. It does nothing you can't do for free in the IDE you undoubtedly already have. The result looks far worse than a mock up you can create in your IDE. Once you have the mock up you can't do anything useful with it except export it as an image or print it. You can't, for example, actually use that for a real form later in the project's life cycle. The result looks crap. Not poor, crap! It looks like a 7 year old has drawn it with a wax crayon....a blunt one. Balsamiq brought in revenue of over 100,000 US Dollars in its first 5 months. Now the way I see it is this. Lots of people are sending money to a guy to buy software that does something they can already do much better f

I am currently developing part of a website where I pass cart information to PayPal to accept payment. PayPal will call back a "secret URL" on my website to allow me to confirm the cart details haven't been tampered with. I hate installing software I don't need. This is especially the case with software like IIS which just feels so intrusive, which is why I use the ASP.NET Development Server when creating websites. The problem with this server is that it only accepts connections from the local machine. My computer is behind a hardware firewall and my web server wont accept remote connections, so how can I test my PayPal IPN call back? Simple. Obviously I have to open a port on my firewall and direct it to my machine. So I opened port 80. Then I used this tool to list on port 80 and redirect all traffic to port 10101 (the port my ASP.NET development server was listening on). The result is that a remote computer can now make a HTTP request to my computer, and I

I am just creating some classes that allow the user of an app to specify date/time validity. As I am modeling them it reminded me of some recurring event classes I once wrote to schedule payments between bank accounts. One day my customer phoned me up. "Has your invoice been paid this month?" he asked. "Yes" I said. "Ah good, your code works then!"

Jeff seems to have put it very well in his blog. Much better than I did myself back in December 2006 when I blogged about my "Onion" idea. My mistakes were 01: I was missing a domain services layer. 02: I tried to explain it using a specific example (wizard app with a "process stack" aka "task stack"), and later decided I didn't like the example :-) 03: When I drew my diagrams I showed them as a typical stacked diagram, because my graphics skills are crap :-) Here's my badly put idea of onion layered applications: http://mrpmorris.blogspot.com/2006/12/net-onion-part-1.html Here's Jeffrey's http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ Well done Jeff, very nicely put!

[TestMethod] public void Meh() { var mockFileSystem = MockRepository.GenerateMock<IFileSystemService>(); mockFileSystem.Stub(fs => fs.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None)) .IgnoreArguments() .Return(new MemoryStream()); var result1 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); var result2 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); Assert.AreNotSame(result1, result2); } This test case shows a problem I was having. The return value of the stubbed CreateFileStream method isn't calculated each time it is called, it is calculated once at the point you defined the stub method and then returned for every subsequent call. The problem with this is that my real test needed to call CreateFileStream twice and get two different streams, the test was failing because the method being tested disposes of the stream it uses; this was resulti

When I run my unit tests in my project I am seeing a result "Not executed" for every one. I have restarted my computer so I doubt this is some kind of hung process issue. Google has revealed nothing that is not related to load balancing, and I am not load balancing! Solved In order to determine the error you have to do this Open the Visual Studio command prompt Change to the directory where the binary output of your test project is. Type mstest /testcontainer:The.Name.Of.Your.Test.Assembly.dll At the bottom of the output you will see the following text Run has the following issue(s): In my case it was the following: Failed to queue test run 'Peter Morris@PETERMORRIS-PC 2009-02-09 10:00:37': Test Run deployment issue: The location of the file or directory 'C:\SomePath\SomeProject.Tests\bin\Debug\Rhino.Mocks.dll' is not trusted. Now if VS had told me this in the IDE I could have fixed it in minutes! All you have to do is open Windows Explorer and

I'm working on an app which uses a 3rd party library for producing SWF and FLV files. For some reason the trial worked perfectly but when I switched my app to the full version there was no audio output. We'd been looking at this problem for a while, emailing support etc, but just couldn't see what was wrong. It wasn't until I went back to my proof of concept app and ran it that we realised the full version did produce audio, it was just my main app that wouldn't work properly. Then I spotted the error... var compressor = new TVE4(); compressor.LoadSettings(SettingsPath); compressor.SetOutputFile(outputFileName); compressor.EncodeSequenceAudio(Composition.EffectiveProductionAudioFileName); compressor.Key1 = 12345; compressor.Key2 = 54321; (loop to encode frames) Do you see the error? It was only as I switched between the proof of concept code and my app code in the IDE that I noticed the two following lines moving up and down... compressor.Key1 = 12345;