A day in the life of...

I'm writing an app which basically performs the following steps in a wizard-like interface: Select an audio file of someone speaking + loads a text script in. Process the audio file and the script, can take about 5 seconds for a minute of audio. Select a character to use in the animation. Select some additional graphics and scene settings. Use the data generated in step #2. Sitting there for 5 seconds wasn't really a problem, not to process a 1 minute audio file. A longer audio file would take a little longer, but 10-15 seconds is okay, isn't it? Well, what if I could make it take no time at all? Obviously I can't, but I can make it look like it takes no time at all. The fact is that I don't need the processed data until Step 5. The user will probably spend at least 30 seconds twiddling settings in each Step 3 and 4. How much processing power does a bit of GUI interaction take? Hardly any at all! So I made Step 2 run in a separate thread. As soon as the user

My observations on data transfer objects They should not be a one to one representation of your domain classes. Sometimes you want a subset of the information of a single instance, sometimes your DTO will collect data from various instances (starting with an aggregate root ). You might create different types of DTO from the same domain classes based on what the user needs to do. Sometimes the user only wants OrderNumber + DateRaised + TotalValue (to show as a list of orders), sometimes they want the entire order details (including lines) for editing. The domain classes should have no knowledge of your DTO classes. So you shouldn't have any methods such as pubic PersonDto CreateDto(); public UpdateFromDto(personDto); DTO's are not part of the business domain, so you should never do this! The DTO you send out might not be the same type as you get back. For example you don't want the user to edit the order number or the date raised. If there are only a couple of properties

I am lazy.  I don't mean that I don't work, I mean that I like to get my work done with as little effort as possible.  Writing tests before my code used to look like too much extra work, but I've realised just how much time they actually save me. When you make a small change to something it's very easy to think to yourself "That's such a small change, I can't see how it can possibly fail", what I have also realised is this really means "Despite this being a small change, it will fail and I can't possibly see how". I recently observed a change to some code that introduced a simple if statement, and all existing tests passed.  The problem is that the existing tests only checked the expected behaviour worked (which it still did), but by introducing the "if" statement (and an additional parameter on the method) the developer had changed the expected behaviour under certain circumstances .  Thinking it was so simple it couldn't p

To me this book has been a huge disappointment. Someone told me "Pete, there's a name for what you do!" and pointed me to this book. Now personally I prefer technical books, as I read the Ubiquitous Language part at the start I thought to myself "Not technical, but fair enough some people will get value from being taught how to ask questions" and I stuck with it. The first thing I must say that I cannot stand and which happens a lot in this book is over emphasis. When you want to emphasise something it needs to stand out. This book not only emphasises whole paragraphs but does it far too often too. Being an Internet user for some time now when I read upper case letters the imagined vocalisation actually SHOUTS at me, when I read bold my brain vocalises it as a loud and punctuated word, so when I read a whole paragraph in bold I, READ, EACH, WORD, LIKE, THIS ; it makes it difficult to read. Another thing I don't like when reading something is reading i