MSDN Magazine and me

I used to read from the MSDN magazine from cover to cover, but now I noticed I read one or two articles only skipping the rest of them. This is the sad truth about my skills and experience: I am no longer on the bleeding edge... Let's take a look:

• C++ - The last time I was writing C++ was 15 years ago. Plus I always disliked Microsoft C++
• Windows metro-style apps: Just not interested. The dev model will be tweaked a lot in the next couple of years. Plus that's not what I am doing right now.
• Entity Framework: good implementation of ORM. However for several years now I am not enthusiastic about ORM and DDD, because in my opinion they represent another cache with all issues of managing and trying to keep it in sync with database. This would make sense for desktop apps, but Microsoft decided to disallow using EF from Metro apps. So my interest in EF decreased even more
• ASP.net MVC: I was always excited about this, but did not actually use it for any production code because we are stuck with SharePoint 2010, which means Web Forms. I think it is also going through transition to make it fully asynchronous. At that point I would seriously consider it.
• Did I mention WinJS? Poorly designed. Waiting for its replacement, perhaps based in Node and Angular, something along of the lines with Ionic. 
• SharePoint 2013. Not using it now, will probably upgrade in several months. Not thrilled about the app model. I always knew that SharePoint hates developers, but I always hoped that the future version of SharePoint will hate developers less. Not so. It will probably die hating developers even more...
• Cloud. I am not in the cloud yet. Azure is confusing with a sheer volume of products available on it. It changing every week, so it I take a Pluralsight course on Azure it will probably be already outdated. For this reason I usually skip all articles about Azure: it will all change a month from now, so why bother?
• TypeScript: waiting when async/await will be implemented. Before that I would recommend Traceur that does have that capabilities. There is one feature of TypeScript that I like: ability to specify weak contracts. If my function is getting an object, I don't care that it is of the type Person. All I care that it has a method with an expected signature (firstName(): string for example). 
• Big Data. "Hey we got these terabytes and terabytes of data? What do we do now?" "Press Delete button"

What I am excited about right now:

• JavaScript
• node
• OWIN and Katana - these have potential of becoming as good as node
• NoSQL databases
• Kanban and Lean

Probably missing something...

Visual Studio 2013 bug with SharePoint 2010

We are using Über-packages with SharePoint that stopped working after we upgraded from Visual Studio 2010 to 2013.
The bug and workaround are described here

Description:
In VS2010 I can package the SharePoint 2010 projects without a problem. 
When I open the same code in VS2013 I can compile without any compilation errors
However when I am trying to "publish" I am getting compilation errors.
This is related to the "additional assemblies" that are project outputs. If I change to hard-coded path this fixes the problem. Unfortunately that is not acceptable because we have multiple configurations.

Workaround:
1. Open C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets
2. Find the following line and remove the @(ProjectOutputReference)
    <UnfilteredSharePointProjectDependency Include="@(ProjectItemReference);@(FeatureReference);@(ProjectOutputReference)" Condition="%(FullPath) != '$(MSBuildProjectFullPath)'" />
3. Reload the project and it should publish fine now.

Apparently it did not help me with the production code, so I ended up editing csproj file and manually forcing version 10 of the build tools:

                                                                                                                            

PowerShell One-Liners

Must share this one

Yet another reason to use PowerShell

From this article:

Notice that all XML nodes in the document are converted to standard PowerShell properties, whether a node has children (e.g. catalog) or is a leaf node (e.g. price), or whether a leaf node is an element (e.g. author) or an attribute (e.g. id). In particular (as the last two examples above illustrate), element values and attribute values are treated exactly the same with standard “dot” notation.

This sill also help us suck work with DataSets, converting them to XML and then accessing the data as properties.

Microsoft encourages bad developer practices

Look at this: http://sdt.bz/content/article.aspx?ArticleID=65362&page=1

“To give you a concrete scenario or example, let’s assume that you’re working on building an Azure website during the day, and you go home in the evening and suddenly the one thing that was bugging you about your website you want to go fix, and you suddenly know in your head, ‘Hey, these are three lines of code that I need to go add to make it work the way I want it to make it work.’ You can fire up a browser, use Visual Studio Online, get access to the source code, which is stored in Visual Studio Online, and then be able to edit your project with those three lines of change that you want to make, and boom, you are there. And you can deploy using Visual Studio Online right from there.”

What could go wrong? The developer fixes the issue and introduces three more, without integrating with other developers, testing, etc. deploys the stuff from his Visual Studio Online to production, breaking the site.
Why is Microsoft investing into the tools for deployment from the Visual Studio? They only encourage bad coding practices... This ability should be removed from the Visual Studio, instead we should be only deploy from the drop folder, after the code is integrated and built, all tests passed and the code is certified to be ready for prod. Instead of building tools to deploy from the Visual Studio Microsoft should make it easy to build deployment pipeline.