Operator overloading is an enemy of functional programming

Trying to use curry function against lodash´s groupBy, was getting TypeScript compilation errors at the build server. Figured out, that the reason is that curry will pick the incorrect overload of the function out of 6 available. Not the first time I am having problem with overloads... I think a good functional language should not have function overload as its feature.

What people are really saying when they say "DevOps".

If you think that when people mean "continuous delivery" when they say "DevOps", you are probably wrong. In my conversation with other people I discovered that most of them think that DevOps are developers who have admin access to the production servers, can log in any time, check logs, update DLL or JAR files, change configuration etc. DevOps for them is a way to save money on hiring real sysadmins.

Needless to say, this is the very opposite of the Continuos Delivery promise with immutable infrastructure. With immutable infrastructure not even sysadmins can change code or configuration of the servers, but that is done through the delivery pipeline.

This terminology shift is similar to what happened to Agile, which understood by most of the people to mean "no design". When we hear or say "DevOps" we should be very careful to indicate that we don't mean hackers with admin access, but a disciplined process driven by the delivery pipeline.

ASP.Net 5

Looks like the latest Microsoft "innovations" are aimed at preventing the Microsoft developers from moving to node.js and other popular web technologies. ASP.Net 5 even sacrificed Web Forms to create a framework that is very similar to node.js or other modern web framework. But they forget that developers are loyal to Microsoft mostly because of the excellent development experience. Within the latest years we ovserve deteriorating design surface experience in Microsoft web technologies, the void the component vendors are not able to fill. They are risking losing more developers than gaining...
End of rant.

SharePoints bails out if more than 10,000 search results.

Toy (but expensive!!!) search engine called FAST Search for SharePoint 2010 bails out if using wildcards and it decided that the query may return more than 10,000 results...
Good article about how to increase the limit.

Change recovery model to Simple for all databases

Import-Module SQLServer
Get-SqlDatabase -sqlserver . | ? {$_.RecoveryModel -eq [Microsoft.SqlServer.Management.Smo.RecoveryModel]::Full } | % { $_.RecoveryModel = [Microsoft.SqlServer.Management.Smo.RecoveryModel]::Simple ; $_.Alter() }

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: