Leadership musings and hackery from the Perl generation...
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.
MS Deploy is such a powerful tool when used to keep your applications and services up to date. What is even more awesome is that the API for MS Deploy is available for you to write applications that utilise this power from within your own applications. As most people who’ve played with MS Deploy can report though, whether you’re using MSBUILD, PowerShell or the .Net API; The MS Deploy API sucks when it comes to simplicity. So after trial and error and much head banging I’ve created a wrapper for MS Deploy’s API to help you complete simple tasks with less friction.
Migrating to a Code-First or Model-First approach to database development can be very liberating. At the end of the day your database is just a way of storing state, so getting away from the implementation details can really help speed up development and allow you to focus your efforts. Code First’s awesomeness aside, when you try and implement this kind of paradigm shift within a team you unlock a different set of problems. Here are two potential ways to alleviate some of the headaches.
For the last 15 odd years we have continually expanded the amount of information available at our finger tips year on year exponentially. Thank you Internet for all your glorious contributions to our lives. Only recently has staying connected to the internet on a Mobile really started to take this to a level where I can truly say that I really am "connected on the go" and as far as technological achievements go that is a pretty amazing achievement to witness in our lifetimes.
Geeky salesman have spent decades selling us a pipedream of the end of “Tree based communication”. To date not much has changed and I’m not holding my breath. In the mean time, what do we do with all this paper? If like me you are dabbling with ways to get your code to convert the physical to the digital, I’ve got news for you: Smarter people have already solved the problem for you and it’s simply a matter of plug and play.
We’ve all been guilty of it in our development careers at one time or another. When starting out using a language or framework that you’ve never used before you often have no choice but to. What I’m talking about is the act of “copy paste coding”, and it’s as common in the programming world as chewing gum under seats. When you copy and paste other developer’s code into your application it’s important to fully understand what the code does before you continue; or risk joining the many fools that have gone before you.
When writing testable code your first port of call is often to abstract any dependencies and make them easy to mock. This is the same for any of your codebase that talks to FTP servers. Testing the way your code behaves under real world conditions makes integration tests important regardless of abstraction though. Here’s a simple trick to test FTP code in the wild.
When you include .Net 2.0 mixed mode assemblies in .Net 4.0 or .Net 4.5 projects you often have to add some start up options to your project’s config file to get it all to play nice when your app starts up. This backwards compatibility feature is great as it allow you to use older/non supported projects in your recent work.When when using Visual Studio 2012’s new unit testing tools this magical piece of app.config code doesn’t seem to help though, and the solution is pretty simple.