2012 was a year of indecision and turmoil for IT folks who use Microsoft technologies.
There were new versions of Windows, Windows Server, SQL Server, Visual Studio, Office, and on and on and on…
Microsoft switched into Apple mode and refused to offer guidance to developers or IT pros in any but the vaguest of terms. Is Silverlight dead? Is it wounded? Have you knowingly led me over a cliff?
In my post Developer Spin Cycle back in September, I talked about my personal cross-roads and trying to figure out which way to go.
I was burned by Windows Phone 7 and unlikely to shell out money to be in an app catalog again. I decided to focus on web technologies since HTML, CSS and JavaScript are not beholden to any one company.
Now it’s time to refine my thinking a bit.
Here is my list of topics I plan to work on for at least the first bits of the new year:
- PowerShell
- Continuous Integration
- Cloud Infrastructure
- EaselJS
- JavaScript
- Game development
PowerShell
For better or worse, I will continue to use Windows and Windows Server as my primary operating systems. I like Linux, but I don’t like any of the alternatives I examined for server-side web work. I am currently most productive with the .Net stack, and as long as my employer is paying for the licenses, I’m not overly bothered by the “Microsoft Tax.”If I am going to stay in the Microsoft world a bit longer, I want to bring some of the efficiencies I’ve enjoyed in Linux and Unix (specifically Solaris) to this world.
In particular I want a rich scripting environment.
PowerShell fits that bill, and has been on my “to-learn” list for years. I’ve always had other items higher on the list, so PowerShell just didn’t bubble to the top.
Over the holidays I decided that the time had come to shift my priorities a bit and bubble PS right to the top.
My next few blog posts will be about learning resources for PowerShell and some of the good bits I’m finding.
Continuous Integration
One of the top factors in moving PowerShell to the top of my list is a desire to improve our workflow. Back in the late ‘90s and early aughts, I was working primarily in Java and rocked the build scripts with Ant. It was a great way to set up a build server and make sure builds and deployments were handled in a repeatable and trustable fashion.I’ve never gotten there with the Microsoft stack. For whatever reason, a large number of us in the MS world wind up building and deploying directly from Visual Studio. Visual Studio is very high on the list of reasons I choose to work with Microsoft tech, but it does become a crutch I can lean on a bit too much.
Psake entered my radar last year, but at a time I didn’t have much time to investigate it.
I’m getting ahead of myself. Ant was a great tool when it came around because it greatly simplified the process of building and deploying compared to the venerable “make” app.
It was a child of the ‘90s when XML was the new hotness.
The Ruby community took a different approach with their build utility Rake. With Rake you could script out your builds and deploys using Ruby, the language you were already working with.
Enter Psake. In simplest terms, Psake uses PowerShell (and therefore .Net) to define a small, domain specific language for building and deploying projects.
My interest was kindled by a video I watched by Harald Fianbakken titled Continuous Integration: Char by char. He also has a related series on his blog starting with Continuous Integration From Scratch Using PowerShell.
I’ll be posting much more on this topic later.