Sunday, March 22, 2015

Software Licensing

"I'm not inclined to make grand pronouncements about the future of software, but if anything kills off commercial software, let me tell you, it won't be open source software. They needn't bother. Commercial software will gleefully strangle itself to death on its own licensing terms." Jeff Atwood

Recently we went through an exercise at work in which we tracked down every use of the Oracle database for licensing audit purposes. In particular when I found out that a web app must now be tied directly to an end user I was incredulous. Why? On the back end we had a licensed "service account" accessing Oracle. We were in a sense simply providing a report view to whomever came along to use the application. Seemed reasonable to me, but I was very naive.

So I second guessed IT management as I so very often do and looked into the issue myself. Unfortunately I found out that management has a right to be concerned. Even our company with its in-house lawyers was right to bring in high paid consultants to navigate Oracle's licensing. Suddenly all the Microsoft SQL Server fans were gloating. Gloating that is until they found out that Microsoft was moving in the same direction as Oracle and our existing licensing would expire at the end of the year.

So, I agree with Mr. Atwood: licensing could kill commercial software. It made me glad that my prejudice for personal projects has always been in the direction of free and open software development tools.

Friday, March 20, 2015

iPad: A Bit Less Impressed these Days

When I got my iPad4 a few years ago I was amazed at the battery life and rapid boot -- though most of the time it was just waking up from sleep. I hardly ever shut it off.

These days I've seen what an Ultrabook with lots of RAM, a decent CPU, and a solid state drive can do running Windows 7. Now I understand my iPad better. It's always had a solid state drive and a reasonable about of RAM.

For too many years I compared Apples and Oranges. Now that Ultrabooks have similar hardware to iPads in the form of solid state drives they are very comparable, much more useful, and if you put them to sleep as frequently as my iPad sleeps, their battery life is just as amazing as that of the iPad's.

NuGet for Visual Studio

Lately I've been doing a lot of Visual Studio development at work and at home. I don't like rewriting or copying common code from project to project. I strongly believe in the "DRY" principle of programming: "Don't repeat yourself." On the other hand, package management can be a pain.

Installing third party software using NuGet is now so very easy. But I was not the only developer that thought it would be complicated to create and manage our own Nuget packages. How wrong I was!

Creating and managing NuGet packages could not be easier, and NuGet takes so much of the pain out of managing shared code. It comes installed by default in the latest versions of Visual Studio, and if  you don't have it, you can install it as an ad-on.

Here are the simple steps to creating a NuGet package and making it available to your Visual Studio projects (or other software that accesses NuGet like MonoDevelop). These steps assume a C# project only because that's what I've been working with.
  1. Create, write, and build a library project (this is where you compile to a ".dll" file). Your shared code will be in the .dll
  2. Download nuget.exe from and put it in your "PATH."
  3. From an MS command shell, CD down into your project directory (typically one level lower than your solution). This is the directory where your ".csproj" file exists. (Assuming your doing C# development.) 
  4. Edit your project assembly information (either through project properties or by editing AssemblyInfo.cs directly to fill in program description, company name, etc.
  5. Run "nuget spec" to create a new ".nuspec" file.
  6. Edit the nuspec file as you desire. Once you run the next step, you'll know better how you want to edit it based on the warnings you get form NuGet.
  7. Run "nuget pack" to generate the ".nupkg" file, like: "CommonCode."
  8. Copy this and all other such package files to a directory of your choice. If you're sharing this with others, make sure they can access that directory. (This is the easiest way to create a NuGet repository, and the focus of this example.)
  9. One time only: go into Visual Studio Tools->NuGet package manager->Package Manager Settings and under "NuGet Package Manager->Package Sources" add your package directory as a package source, naming your new "repository." Be descriptive and concise.
Now when you have a solution open in Visual Studio, go to Tools->NuGet package manager->Manage NuGet Packages for Solution, look under "Online" and you will see the repository you added and whatever packages happen to be there.