Continuous Deployment is an time-saving, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup. Once you’ve started out automating deployment though iteration is the key. Deploying your website early and often is great but with OnCheckin this goes further – Add-ons. And where better to start than helping developers out than with an often overlooked part of web development: Application Security.

Recently I’ve had the pleasure of setting up a new build environment at work to replace our TFS Team Build setup and its build-information-opaqueness. In the process I uncovered a lot of not-so-fun-to-be-a-developer things that our large corporate IT Infrastructure team have in place to keep the masses at bay – one of those things is an NTLM proxy server. And so the head banging began – hopefully I can save you some brain cells and get you home on time.

Constantly over the past few years I’ve thanked my lucky stars that I’ve had continuous integration and deployment setup for the web sites I’ve been working on. It is one of the few development opinions where I break the “religion and politics” laws of social etiquette. I feel incredibly strongly about the benefits that having a good Continuous Integration and Deployment story can bring to a project and it’s team. Sadly, not everyone has been able to experience the awesome sauce of CI/CD. I’ve been working hard to change that.

When maintaining applications built in ways that make unit testing them high friction, difficult or down right impossible, we often turn to integration tests or no tests at all. Poking around the outside of your logic to see that the outcomes our code produces is often fiddly, brittle and in most cases so time consuming it just doesn’t happen. Lucky for us all, if there has been a case in the past where we’ve been unable to test part of our business logic, Visual Studio 2012 Update 2 is here to offer an answer to your prayers which you just might not be aware of.

Finishing your Windows Phone 8 application isn’t the end of your Windows Phone journey. You’ve now got to get it into everyone’s hot little hands – by submitting it to the Store. Having developed for the Windows Phone platform now for a number of years, I can attest that just uploading  your XAP file isn’t the only thing required to make this happen. Similar to my post on “Must have tools for Windows Phone” I'll try and fill you in on a few things I wish I'd known before I submitted.

Windows 8 comes with some pretty awesome new toys, one of these for me is the Music app. As a Windows phone user for many years now I’ve fallen in love with the all-you-can-eat music subscription service that Microsoft has on offer. Sadly for me when I installed Windows 8 the app simply crashed every time I tried to play music. I searched for months and months, and now have the answer – in the hope that I save someone else the heart ache I’m happy to share what I discovered.

This weekend a bunch of like minded people are getting together to hack on Windows 8 and Windows Phone to create some awesome applications and win sweet sweet prizes. You can be one of them – so why don’t you come rock out with Microsoft, eat and drink on the house and create some app awesomeness.

You’re close to shipping and you receive a shopping list of bugs and changes. Some are tiny and un-eventful, some are show stoppers, some let the bad guys in, and some are simply scope creep trying to sneak through the door. It’s hard to know where to start without reclassifying them because the majority of them are all labelled Critical. It’s time to sit down with whoever documented your bugs and do some talking…

Nuget has become such a valuable part of the .Net ecosystem it's any wonder how we got the job done with 3rd party packages without it. When working on projects in a team many developers turn on Nuget Package Restore to save them having to check their packages into Source Control. This allows them to have their packages download whenever a new developer goes to build. It’s also quite popular with project teams that have Continuous Integration setup. I recommend against Nuget Package Restore, as I’m simply not a fan.

When you go to create a mobile app for each major platform you quickly realise that it’s a mind boggling task with many languages and tools out there to learn along the way. A number of products have arrived over the last few years that enable you the freedom of only having to care about one language and toolset, with the dream being that they take care of the rest. Does this type of approach work? DXTREME does a pretty good job of making the answer to this question Yes.