Aug 31, 2011
NOTE: This is not a supported change and if something breaks on your machine, well… you’ve been warned :-)
Step 1: Open explorer in Administrator mode and go to C:\ProgramData\Microsoft\Phone Tools\CoreCon\10.0\addons
Step 2: Copy “ImageConfig.en-US.xsl” and name it “ImageConfig.en-US 2.xsl”
Step 3: Open this new file in your text editor of choice and locate the DEVICE element and change the device name to something of your choice and the device GUID to a new GUID as shown. Use the Online GUID Generator to make generating new GUIDs easy.
Step 4: Given the WP7 is a virtual machine, we also need to supply a new Virtual Machine ID, so locate the VMID section and provide a new GUID in there as well. Again the Online GUID Generator can be used for this purpose.
Ensure that the GUID you insert is in the same format (i.e. with the braces)
Step 5: Save the file and start the Application Deployment Tool. You should now see your new emulator available to deploy your applications to:
If you close and restart Visual Studio 2010 you should also seen the second phone emulator available as a deployment target:
Note that of you run a phone application in debug mode there seems to be no way to launch a second instance on the other emulator whilst the phone is running. It’s not a major problem though since you can simply take the debug .xap file and deploy it to the second emulator using the deployment tool.
I hope this helps you out. Enjoy!
Aug 19, 2011
Unfortunately I don’t have the code or load test details embedded in the presentation but even so this should still have a number of useful things for you to look at, especially the resources section at the end
Oh, as an experiment, I’ve put both a Slideshare player and a Powerpoint Web App player in this post. I’d like to know which one you think is better (send me a tweet to @rbanks54 or leave a comment)
Aug 12, 2011
Let’s say you work in an internal IT department, largely doing maintenance work on software solutions. Solutions that are by and large built by external vendors through an outsourcing arrangement and then brought in house once they’ve gone live and the initial warranty period has elapsed.
Let’s say every time you look at one of these solutions that you now have to maintain you find the grand sum of zero unit tests. Without exception. Every single application has nary a unit test to be seen. Not even a hint that one might have existed and been removed at a later date.
“Why?!” you cry to yourself. In frustration you cry “Why!!?” to management as well. Their answer: The vendors tell us “it will cost more and take longer to do unit testing” and of course, they reason with you, if that’s the case then why would we pay for it? You know this is a bad argument and the logic is built on sand, so what’s your comeback? How do you get it across to management that a vendor that ignores unit testing is a bad vendor and is actually more expensive overall?
So my initial response to their claims would be along the lines of “So do I assume they’re not actually testing the software they write for us then.” and then explain how manual testing takes (much) longer than developing automated tests, assuming of course that the code being written is in any way testable. If they develop poorly and have a lot of tight coupling between concrete classes or make a lot of static calls to HttpContext or develop in SharePoint for instance then the application might not be easily testable, but hey! That’s their problem not ours. The good news is that anyone with a business brain can understand the benefits of automation for tedious repetitive time consuming processes – heck, we worked that out during the industrial revolution.
Let’s try a different angle in case the first, most obvious one doesn’t work. If you consider a lack of automated testing to be merely another form of technical debt then it’s just like poor design and architecture, horribly complex methods, N+1 ORM queries, poor UI’s, high bug counts, etc. It’s something that will cost you. So, if a vendor delivers you software with a high level of technical debt and you’ll be maintaining it, then you’re going to have a lower long term ROI and higher TCO from those vendors versus what you might have from a vendor who keeps their debt levels low. So while the cheap guys may argue that it will cost more and takes longer to write code with unit tests then what they’re really saying is this
“It costs US more and takes US longer to do unit testing because the developers we hire are the cheapest and suckiest we could find. They don’t understand good development practices and we’re not about to teach them because they’ll leave in the next 3 to 6 months. Also manual testers here are cheap-as-chips and lose staff too quickly, so it’s easier for US if we just get the software to ‘it kind of works’ and then give it to you so we can get our money and hope you won’t notice”.
Also, don’t forget that post delivery, all those bugs and problems that snuck through from the vendor will end up becoming your bugs and problems to fix as part of your maintenance work. So the company is either paying for it with internal staff costs (often seen as a hidden/sunk cost) or, if the vendor is also charging for maintenance, paying for it once a development project is concluded. Development takes longer, it’s harder to find and fix bugs, it takes longer and longer to test the application manually, etc. These all add up to time, and in software development time is money!
With that, good luck convincing management to change their vendors, and if you’ve got a better reason to present yours case I’d love to hear it.
Note: I’m not implying manual testing is bad. In fact I think you should be doing manual testing; but only manual exploratory testing where testers are trying to break your code. It’s rote, repetitive manual testing that is neither cost efficient or effective.
Aug 8, 2011
Why? Because that’s the session you want to go to of course!
Here’s the link with all the details: http://australia.msteched.com/topic/details/DEV305
Aaron Powell, Luke Drumm, Steve Nagy and myself are going to show you how to build applications for the cloud using multiple clients (i.e. PC and Windows Phone 7 in this case) and some of the things to watch out for. Don’t worry it won’t be one of those sessions where people try and prove how awesome they are by writing the whole thing on stage. Instead we’ll be showing you the highlights and what you should think about if you want to try something similar.
I’ll also have my recording equipment with me and will be recording a number of podcasts for Talking Shop Down Under with people while I’m up there, so if you want to hear from someone in particular, let me know so I can line up a time with them!