Software Development

SQL Server – kill all processes connected to a database

Posted by Andy on April 27, 2011
Computers, Software Development / 7 Comments

Below is a little script to kill all the processes which are currently connected to your SQL Server database.  I’m posting this mostly for myself for future reference.  The preferable way to do this is to use the alter database set single_user thing, but that doesn’t always work, so this is the “drastic measure” option.

Window Mobile (6.5 and below) Development Tips

Posted by Andy on September 01, 2010
Computers, Software Development / No Comments

I wanted to link to a few good blogs/articles regarding the wonderful world of Windows Mobile  development.  I’m not talking about Windows Phone 7, this is the old-school Windows Mobile 6.5 and below.

This first article has some must-know tips for writing Windows Mobile apps that can run on either the full or compact frameworks.  Following these conventions gives you the ability to run the same application on either a Windows Mobile device or emulator, or as a full .NET framework desktop application (without re-compiling or re-configuring).

Write Code Once for both Mobile and Desktop Apps

Of course, you can’t have this both ways:  You cannot run full-framework code on Windows Mobile, you can only go in the other direction and run CF code on the full framework.

This next article (written by the lead developer at my company Blue Dot Solutions), shows how to setup Visual Studio to debug .NET CF apps on your PC, rather than the emulator.  This is a super-useful trick that makes Windows Mobile development much faster, and almost tolerable.

Deploy to My Computer

The following articles talk about “provisioning” of Windows Mobile devices.  “Provisioning” is a term you don’t hear too often, unless you work in an “enterprise” environment.  Provisioning has to do with the initial configuration of a device (applications, settings, etc.) by the manufacturer, or continuous setup and configuration by an administrator or user.  There are several industry standard mechanisms for provisioning devices, and Windows Mobile supports several of these, including OMA Client Provisioning and OMA Device Management (among others).  This set of documents is pretty poorly organized, but it contains a ton of really useful information, and provides examples on all the different things that you can provision.

Managing Windows Mobile Devices

Configuration Service Providers

I hope to add more links as I come across more information.


The quest for MacOSX 10.5, Apache, Python, Django, and mod_wsgi

Posted by Andy on October 02, 2009
Computers, Internet, Software Development / 4 Comments

It all started when I decided to learn the Django web framework for Python.  I ran through a bunch of examples on the Django site, and in the book Practical Django Projects, Second Ed. and was overall really impressed with the framework and the provided tools.  It has a lot of really useful features, and makes web development a lot of fun.  During my “evaluation” of Django, I was testing everything using the out-of-the-box dev web server that comes with Django, but I eventually came to the point where I wanted to try to host a Django site “for real” in Apache.  I checked the Django deployment documentation, and decided to try to get the suggested mod_wsgi module setup in my local Apache web server, on my Mac Mini (version 10.5.8 – “Leopard”).

At that time (a few hours ago), I was using the default install of python that came with my Mac Mini: version 2.5.1.  I thought it would be a good idea to download and install the latest version of Python (at least the latest 2.x version, as the 3.x versions are still not fully supported by most Python toolkits), so I could be on the bleeding edge.  Little did I know that the latest version 2.6.3 was being released as I spoke (Oct 2)!  I went to download the 2.6.3 version, and found that the MacOSX .dmg download link was broken on the Python download page.  (This will probably be fixed by the time anyone reads this, but this link was throwing a 404 error when I tried!).  Since the .dmg was not available, I had to give up on the “easy route.”  The only download of 2.6.3 available was the source code .tar.gz.  After download this and screwing around with it for awhile (couldn’t figure out exactly which options to use in configure and make…), I decided to chicken out and look for the most recent version that provided a .dmg install for Mac.  2.6.2 from April 2009 had a .dmg, so I went ahead an installed that.  After removing the default /usr/bin/python related links, I now had a new install of Python 2.6.2 in /usr/local/bin.  So far so good.

The next step would be to get mod_wsgi setup in my current Apache install (version 2.2).  I followed the directions on the mod_wsgi install documentation, and almost got through them.  I read through the MacOSX-specific install instructions, and didn’t really see anything that applied, so I figured I was okay.  I modified the httpd.conf file to load the mod_wsgi module, and this is where the fun started.  When I tried to restart Apache, I got the following error:

httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf:
Cannot load /usr/libexec/apache2/ into server:
dlopen(/usr/libexec/apache2/, 10):
Symbol not found: _PyExc_RuntimeError
  Referenced from: /usr/libexec/apache2/
  Expected in: dynamic lookup

I searched around for some more info, and after reading through a bunch of blog posts and forums, I learned that this was most likely happening because the Python shared library was only build in 32-bit mode, whereas, the default build of Apache on MacOSX 10.5 runs in 64-bit.  At least that’s what I made of it, not sure if that’s completely accurate…  The docs on the mod_wsgi site for MacOSX mention that you need to add extra -arch flags to the Makefile when building mod_wsgi for 64-bit, but that wasn’t the problem.  Those flags were correctly generated by the configure script, and my library was built with full 32 and 64-bit architecture support.  The problem appeared to be that when Apache tried to load the, the was trying to load the default Python library, which was only built for 32-bit.

I searched around some more, and found this excellent blog post: on this very subject.  The post describes the exact problem I was having, and provides the steps necessary to build Python in the full “fat” architecture (all 4 archs), as well as mod_wsgi.  I was about to try out the described steps, when I noticed a link to another blog:  This procedure seemed much simpler, so I decided to try that first.  It would involve over-riding the default launchd configuration for Apache, so that the process would be launched in 32-bit mode, rather than 64-bit when the Mac starts up.  I tried this out and eventually got it to work, but the problem with this is that if you do a “sudo apachectl restart”, it ignores your launchd configuration and starts apache up in the normal 64-bit mode.  I decided to give up on this and keep looking.

I then found this blog post:  This post presents a novel idea:  avoid all the trouble with 64-bit, and just dumb Apache down to the sane level of 32-bits!  I’m not sure why Apple decided to have Apache run in 64-bits when everything else basically runs in i386 (32-bit) mode.  I thought this might be a nice, simple approach, so I’m going to give it a whirl…

This post is already too long, so I’ll post an update if I come up with any new information!

Tags: , ,

RWSD: Service “good-practices”

Posted by Andy on June 30, 2009
RWSD, Software Development / No Comments

I thought I’d jot down a list of what I would consider to be good practices when developing software services.  I’m mainly a C#/.NET developer, so I’ll focus on exposing services via WCF, but most of these concepts are language “agnostic.”  A lot of these are pretty obvious and well-known; however, I’ve seen each of these violated enough times in the span of the last two-to-three months to make me think that maybe they are not so well-known…

  1. Don’t use a raw “object” type for any parameter, property, return value, or really anything else exposed as a service. Using a raw object makes it exceedingly difficult to achieve automatic serialization of messages coming in or out of the service method.  If you expose an “object” in your service, the caller has no idea what to pass in, and you have no way to deserialize whatever XML you end up receiving, unless you import XSDs from the client, which is a pain.  Importing XSDs from another company in your service creates an undesirable dependency between your service and the client.  Sometimes this is necessary, but dealing with WSDLs and XSDs is almost always more painful than it should be.
  2. Use low-level (primitive) datatypes as much as possible for the the properties of your input and output types, and avoid any objects that have properties that go more than two levels deep in object complexity. Web services are supposed to make it easy to achieve interop between any two languages, but I’ve never seen any web-service integration that was easy.  Internal services (where you can control all the datatypes) are usually less painful, but when dealing with external partners, trying to integrate with a foreign WSDL with a complex object model almost always requires some hacking.  The simpler the objects are, the easier it is to integrate.
  3. Don’t expose any object in your service that has anything to do with your backend data-access-layer. This creates a very undesirable dependency between your clients and your data-access layer.  If you expose a data object over the wire, and an external party integrates with your service, it now becomes very difficult to make any breaking changes to your data access layer.  Always create a simple data-transfer object to expose in your service, and hide everything having to do with your domain data.  Another reason to use simple DTOs is it forces any lazily-loaded data objects to be hydrated as you are copying the data to the DTO.
  4. If you need to leave room for extension in a service method, try to define concrete parameters for as many of the fields as possible, and add a string-string dictionary as the last parameter to your service method so the caller can attach additional data.  Another option is to expose an argument that can be subclassed to add functionality. I personally prefer to use the string-string dictionary, because dealing with subtypes adds an extra level of complexity for your integration.  The string-string dictionary is slightly painful, because it’s not really type-safe, requires clunky casting and validation, and is not easily documentable or intuitive to use.  This string-string dictionary is also a very useful technique for receiving and returning client-specific data in a service call.  A lot of times, the client will have their own identifiers for messages, and if you end up needing to perform asynchronous processing on the message, with a callback to the client, it becomes simple to store the data on your side, then return it back to the client with the callback, so they know what the response corresponds to on their side.
  5. With #4 said, avoid “untyped” data as much as possible. By “untyped,” I mean any data that has to be converted/cast at the receiving end before it can be used.  I’ve seen several services where the only argument exposed is a string-string dictionary.  With this, the client can pass whatever arbitrary keys they want, and you have to validate and cast the corresponding values before doing anything.  Try to use concrete, serializable types as much as possible.
  6. Don’t abbreviate anything! One of my coding pet-peeves is when people abbreviate arbitrary words in a method or variable name.  It takes a bit longer to type out the full word, but if you type it all out, you’ll never have to remember what you abbreviated, and the code becomes much more obvious to read and work with.  It is acceptable to abbreviate common acronyms, such as “Http,” or “Sql” however, but try to avoid abbreviating any domain-specific terms.
  7. Don’t define an argument or return type, then share it across multiple methods. There are a few cases where this might be useful, like if your methods all need to return the exact same data, but I’ve seen cases where the shared object ends up needing some custom parameters for certain methods.  When this happens, you end up adding some additional properties, which are coincidentally “given” to all the other methods.  Now you’re stuck with an overblown object that has too many properties for any one method, and requires additional validation code and error handling.
  8. Avoid throwing exceptions out of service methods. If possible, try to catch all exceptions within your service method, and return back some sort of status object indicating what went wrong.  Dealing with SOAP faults is yet another thing that adds an extra level of difficulty to any third-party integration.  I’m not a huge fan of dealing with error codes, but I think it’s actually cleaner and easier to deal with on the client end.
  9. Keep the service interface as compact and intuitive as possible. Avoid any generic methods that can be used to accomplish different types of business use cases.  Avoid “super” interfaces that provide all of the methods you need for an application.  Creating an interface with 20+ utility methods might seem like an easier way to deploy and integrate the service, but it creates a ton of undesirable dependencies between your client and your service.  Follow the “I” principle in the SOLID principles: “Interface Segregation” – segregate the parts of your interface into the smallest possible units that a client needs.  If a client only needs a few methods in your interface, don’t make them integrate with the entire thing.  By doing this you also give yourself the option to move the different services to different locations in your backend, without moving the entire thing, and gives you the ability to scale out parts of your system that might get hit harder.
  10. For heavy service loads, use a “HTTP-Queue” bridge to process messages in an asynchronous fashion. If you have any part of your system that has to process varying loads of messages, you can use an HTTP bridge to receive and enqueue incoming messages.  The HTTP layer exposes a web service to receive the messages in an interop-friendly format (SOAP, etc.), but simply passes the message directly onto a queue for processing by a backend service.  WCF makes this dead simple, you can setup a WCF web service application (hosted in IIS) to listen for messages, then setup a NET MSMQ binding between the web app and your backend Windows Service app.  Using queues makes it slightly more difficult to handle the response, because it requires a web-service callback to the client, but it’s a really solid pattern.
  11. If possible, don’t do anything overly fancy with the serialization of objects in your service. In many cases, your client will be using a different language than you to integrate with your service.  If you make the serialization of types complicated or non-standard, the client will most likely have problems integrating with your service using the default tools of their language.
  12. Keep everything as simple as possible! Try to avoid using any of the more advanced features that might be provided by your language.  I guess WCF is sort of an exception to this rule, since it abstracts away almost the entire service protocol layer, and does a ton of work behind the scenes; however, try to keep your service interface as clean, simple, and standard as possible.  Even the simplest of services can give your clients headaches to integrate with, so just try your best to make it easy on them.

Tags: , ,

RWSD: Don’t abuse the ternary (aka “conditional”) operator

Posted by Andy on June 26, 2009
RWSD, Software Development / No Comments

This will be my first post in a series I think I’ll call:  “Real-World Software Dev” (RWSD for short).  In my short software development career, I come across some things that I feel compelled to write or rant about.  Some of them might be inspired by something I’ve seen in a book, on the intraweb or heard on a podcast, and others might be things that I’ve come across on my own.  Some of these things might be naive, or not even valid, so cut me some slack…

The first topic I’d like to discuss is the ternary conditional operator, which is available in C-based languages (C, C++, Java, C#, etc.).  This operator is basically a condensed form of:

if (conditional)

With the ternary op, it would look like this:

conditional ? doSomething : doSomethingElse

In the real world, it’s my opinion that there are only a few cases when you should use this operator. I think a good rule of thumb is to only use this one-liner if it is completely obvious what the outcome will be whether it falls into the if statement, or else statement. E.g. if you are using this to set a string to one of two possible values, based on a condition:

string myResult = (isSuccess) ? "Great success!" : "You lose!";

It makes me cringe whenever I see the ternary operator used to call one of two methods, or do some other complex action.

string myResult = (isSuccess) ? GetResult(a, b, c) : GetResult(d, e, f);

My big gripe with this thing is that it’s a one-liner, and IMHO, difficult to read. If you put some error-prone call in one of the blocks and it throws, the stack trace will point out the single line containing the ternary operator, rather than pointing out which method was actually called. It must just be Murphy’s Law, but it seems like methods tend to blow up more often when called via the ternary operator, seemingly in some malicious attempt by the computer to make your life more difficult. To me, the ternary just reeks of old-school C code, not unlike its close friend, the “switch” statement. I’m in the camp of writing more explicit, verbose code as opposed to trying to condense code down to the smallest constructs possible.

Overall, the ternary operator is good for simple if/else assignments, but I’d avoid it for just about anything else.

Tags: ,