Available for part-time contracts

After having finished a 6-month assignment, I am returning to a very much work-in-progress ERP-project - I hope to provide more information about that later in 2015.

However, that does not have to be a full-time project, so I would be interested in part-time contracts from now on.

Part time could be 1-3 days a week, but it is pretty flexible. It may be one week full time and then one week off, but other arrangements might be possible.

I am available for development work in most common languages (C#, Java, C++, Visual Basic, Javascript), system administration (Windows / Linux), Build/test (Jenkins/TFS, Subversion/Git), scripting in PowerShell/Bash and database-related tasks like optimization or migrations in primarily SQL Server, but also Oracle or PostgreSQL.

I do mostly back-end work, but can do UI as well (both HTML/CSS/Javascript, WPF or WinForms). Technical documentation is also a possibility.

So if you have any use for a highly flexible senior developer or system administrator on a flexible basis, then please contact me by e-mail: oht@tolsit.com.

Invented Here Syndrome

The NIH (Not-Invented-Here syndrome) is probably well-known, but this blog post puts focus on the less-known other side of the coin: the Invented Here Syndrome:
http://mortoray.com/2015/02/25/invented-here-syndrome/

It agrees quite well with my experience from development in several companies. In a well-meaning effort to meet increasingly tight deadlines and demands to the software to be delivered managers and even quite a few programmers fall prey to the idea, that time spent writing code is wasted, if some third-party software exists that does roughly the same thing.

This however ignores time spent researching suitable third-party software, learning how to use them, working around bugs, head-scratching due to lack of documentation, writing wrappers around not-quite fitting designs and increased complexity of the solution in general.

This does not mean that every piece of software should start from scratch, but keeping in mind that using third-party software may carry quite a few hidden costs may help us make better choices when considering "Download" or  "Build"?

Happy development!

At a customer's site for the next months

This week I will be starting a project with a new customer. It is expected to last the rest of 2013.

So my MCSA certification and other projects will have to be paused until next year. There might be time for blogging from time to time, but the client shall have my full attention, so we will have to see.

Have been looking into TFS 2012 a bit

Having seen that experience with Microsoft Team Foundation Server (TFS) is appreciated in several potential freelance projects, I decided to take a look at TFS 2012.

I did that by installing TFS 2012 on a virtual server and connecting VS Ultimate 2012 to it. The basics about work items, source control and builds looked straigt forward enough, and in no time flat I had TFS automatically building on every check in.

To get a better overview of what TFS 2012 has to offer, I read this book:

It stays quite high level and describes what is possible, without getting into details about how to actually set up the procedures. Lots of screenshots though.

It is clear that the TFS ecosystem is indeed a very strong player in the Application Lifecycle Management (ALM) area. No question about Microsoft taking agile development practices seriously.

TFS and Visual Studio handles everything one would need with respect to issue handling, sprint monitoring and (manual and unit) testing, but also offers some quite advanced code visualization tools. I especially found it interesting the way one could describe (by drawing diagrams) the intended code organization and layering, and then have TFS/Visual Studio validate the code on check in against these intentions. How well this works is in practice, I am not too sure of. Anybody got any real experience with this?

It should be possible to create a very automatic and reliable build/test setup, by automatically deploying to virtual machines (in a "lab") as part of the build process. However, to enable this and get the most from TFS one also must install Sharepoint, SQL Server Reporting Services, Microsoft Test Manager, System Center Operations Manager and System Center Virtual Machine Manager - IMHO a pretty big setup for a small development organization.

PowerShell detour

The "MCSA: SQL Server 2012" certification has been temporarily paused, while I investigate some tools that could prove useful. 

 

I am looking into Team Foundation Server - especially the parts of Continuous Integration and Deployment. First step in that direction was learning Powershell scripting, which looks as a great way of doing automated deployments on Windows and now I just finished reading the book "Windows Powershell 3.0 First Steps":

 

Having experience with both .NET and scripting in general (mostly Bash/Unix-style scripting) learning the basics of Powershell was not hard. Of course, there are hundreds of commands (called cmdlets) that it will take time to get really comfortable with, but the fundamentals of Powershell seems easy enough.

One very nice thing about Powershell is the discoverability of commands and parameters. Tab-completion is very Visual Studio-like and is way more advanced than the traditional path-expansions in other shells. The help system also appears quite polished, but perhaps the part I like best, is the focus on (typed) objects.

The pipeline plays just as important a role as it does in Unix-scripting, but instead of piping text lines, it pipes typed objects. This allows very easy access to rich information about files, processes etc. without all the "awk"-text parsing. Easier, more robust and probably faster too.

Powershell also includes quite powerful remoting capabilities, perhaps finally bringing practical SSH'ish functionality to Windows. It appears pretty easy to use, but it requires one to have Active Directory configured right. It can also run on HTTPS.

So, a question begs to be asked: is a mono-based powershell for Linux a desireable thing? Does it exists?

Connecting to SQL Server from another domain

Have you ever had to connect to an SQL Server using SSMS or perhaps from an ASP.NET application, where the SQL Server is set up to only use Windows Authentication (not Mixed Authentication) from your client PC, web server or whatever, and that machine was not part of the same domain as the SQL Server?

Eg. if I want to connect from my laptop (OHTXPS13, not a member of any domain) to the server "SQL-B-462" (part of the Contoso domain) then it appears I am out of luck.

Notice that the "User name" and "Password" fields are disabled. Even though I have the username "Contoso\Kim_Akers" and password "Pa$$w0rd" there seems to be no way to provide it.

Trying SQLCMD.exe does not improve the situation. There are -U and -P switches to allow you to provide username and password, but those requires the SQL Server to allow mixed mode authentications.

Solution:

The recommended solution I think is to establish a domain trust relationship between the SQL Server domain and the "client" domain. However, since this must involve a Domain Administrator it might not be a practical solution in all circumstances.

A very simple quick 'n' dirty solution is this:

That is, simple use the command (from powershell or plain cmd.exe):
runas /netonly /user:<domain>\<username> ssms.exe

Enter the password of the domain user and SQL Server Management Studio will start up running under the specified user account. Now simply connect to the desired SQL Server with Windows Authentication.

Querying SQL Server 2012 is PASS

Just finished the 70-461 Exam "Querying Microsoft SQL Server 2012" and fortunately it was a (comfortable) PASS.

Much of the topics is something I have used extensively before, but these items are more or less new for me and I am happy to know a bit more now:

• OFFSET-FETCH
• APPLY
• Pivoting and unpivoting data
• Common table expressions (covered in this previous post)
• Windows functions (eg. PARTITION, OVER, ROW_NUMBER())
• Full-text data
• XML queries
• The MERGE statement
• OUTPUT-clauses for INSERT, UPDATE and DELETE.
• TRY-CATCH error handling
• Extended events

So now I have begun on this book:

 The exercises in this book requires no less than six Windows 2008 R2 servers (one DC, 4 ordinary servers and 1 server core), so the first step will be to punish my ESXi by creating this setup.