Posts Tagged ‘Software Engineering

Recently I got a Chromebook, which has forced me to step up my search for a good web-based IDE. I only looked at the free-level capabilities, looking for something that would handle multiple projects and maximum flexibility. Here are my top three recommendations:

Koding provides a clean interface with a lot of flexibility. In particular, I like that they provide a full AWS virtual machine. This is particularly nice for those who want to do more than just code, but to design or experiment with an entire software stack. However, their interface is a little bit less like an IDE and more of just a terminal and editor connected to that virtual machine.

Cloud9 works more like a good IDE where you can set up a build and run tasks. But the build and run environments seem to work outside of your particular terminal environment, which makes their workflow different than it might be on other platforms.

Codeanywhere maybe be a good mix. For code editing it provides a little more than a text editor, and doesn’t want to control or own your project. You can actually keep your code external, and access it through (S)FTP, Google Drive, or Dropbox, and simply access it through code anywhere. But the still also give you a “DevBox” which is something like a VM.  Additionally, Codeanywhere provides mobile apps (which I haven’t tried).

I looked at other solutions (Codio, Codebox, Codenvy, PythonAnywhere, Nitrous) but excluded most of them because they didn’t allow me full control over my software stack.

The problem with all of these is that they can’t access code that you don’t have on the Internet, for example, code in your private Intranet only. For that I found that I could quickly install the open source Codebox IDE on my private Intranet server.

Coding in the cloud

Posted in Technicalon Dec 30, 2013

I’ve been looking for ways to write code inside a web browser.  There are a number of offerings, and I plan on giving a serious look to the free ones.

So far, I’ve come across runnable.com, It seems like a good site to share code snippets that can be executed right on the site. Kind of like a YouTube-like site for sharing code.  It isn’t the sort of site that you would want to code a large project, but good for sharing just a chunk of code that might be useful by others or useful for programming instruction.

Some of the things I am looking for when writing code in the cloud is the ability to import, export, run, and write code easily.  I am especially looking for the ability to work along side my existing development practices on my home computer.

Make your version numbers count

Posted in Technicalon Jun 3, 2013

I’ve seen many software products have a version numbers in the form of:

X.Y.Z

Where X, Y, and Z are integers. For example, I’m using Linux 3.8.0.

Communicating a software version number is important because it communicates the fact that the same software title can be different between versions.

Unfortunately, when using X.Y.Z numbering, too many software publishers leaves the meaning out of the components of the version number. Often changes in X mean “big change”, changes in Y mean “medium change” and changes in Z mean “small change”. So software of version 3.2.1 is much better than version 1.2.3, but version 1.0.2 is only minimally better than version 1.0.1.

The problem with this is that it it is subjective. What a publisher considers a big change might not be important to a particular customer. What a publisher considers a small change might fix a show-stopping bug for another customer. When it takes someone’s judgement to decide the version number of the next release, your version numbering scheme is messed up.

When choosing a version numbering scheme it is important to remember how the version number will be used. Sometimes, a customer wants to know how old a software release is, in which case a date-based scheme might be appropariate. In many situations, a customer only wants to know if one version is newer than another version. In this case, I might suggest a simple numbering scheme where version 20 is newer than version 19 is newer than 18.

Firefox uses an X.Y scheme where X is the release number and Y indicates how many bugfix re-releases have been made. For example, Firefox 21.2 would indicate the second bugfix release for the 21st new feature release of Firefox.

When developing a software library, I like to use an X.Y.Z numbering scheme. If the API to the library is backwards incompatible, then X increments (and Y and Z reset to zero). If I add a new feature, then I increment Y (and Z is reset to zero), and I increment Z if I fix a bug. Consumers of my library can look at the version numbering to help them quickly decide whether or not they should update. If they see only Z change, then they should be able to get the only the bug fixes and improve stability. If they need to use a new feature, they should use a version with an incremented Y component. If the X component of the version changes, the library should not be updated until the developer has an opportunity to review the changes and adapt the consumer of the library.

Software quality != testing

Posted in Technicalon Jul 27, 2012

I was working in an organization when there was a lot of panic about lack of software quality.  Immediately a team was spun up and tasked to implement some form of automated testing.

While well intentioned, I think the associated between software quality and testing is a little misguided.  Testing can be used to discover a lack of software quality, but by itself it doesn’t cause software to be of higher quality.  Sure a software developer can take the results of testing and fix any defects, but that process isn’t testing, it is developing.

Software quality comes through quality software development.  When software developers follow good development practices, they will create higher quality software.

So while testing isn’t bad, a company looking to improve software quality should look at the development practices first.

The ‘From’ email header

Posted in Technicalon Dec 5, 2011

Every email that is ever sent has a set of header fields. These fields keep track of things like the sender, recipient, subject, date, and content type. Normally, these header fields aren’t directly presented, but instead are used by email programs like Gmail or Outlook to properly display information about the email.

Side comment: If you are using Gmail, you can select “Show original” (from the same menu that allows you to reply or forward the email) to see the full email content, including all of the email header fields.

There is a header field called ‘From’ that is particularly important. Like you might expect, it encodes information about who the email is from. The ‘From’ field can contain just an email address like this:
From: spam@squaregalaxy.com
or perhaps like this:
From: <spam@squaregalaxy.com>
The ‘From’ field can be more useful by containing both a name and the email address like this:
From: Sir Spamalot <spam@squaregalaxy.com>

When an email program, like Gmail or Outlook, present the name of the email sender, they often parse the ‘From’ field to display the name of the sender. If the name is not included, then the program displays all or part of the actual email address.

Let me proceed with two examples, one good and one bad.

Bad example: Staples.com sends me an email to confirm my recent order. The ‘From’ field of their email looks like this:
From: <support@orders.staples.com>
When I look at the sender’s name in Gmail, it simply says, “support.” Of course I need support on all sorts of levels, but I don’t know anyone names support.

Good example: LivingSocial.com sends me frequent emails to tell me about discounted deals in Fort Collins. The ‘From’ field of their email looks like this:
From: LivingSocial Deals <deals@livingsocial.com>
When I look at the sender’s name in Gmail, it shows up as “LivingSocial Deals” so I can quickly determine who is telling me about “6 Laser Hair-Removal Treatments.”

When writing a program (or website) which sends emails, it is important that the program include a name along with the required email address. This allows the recipient’s email program to more meaningfully present the name of the email sender. This is especially important in business applications, which need to establish a clear identity for their customers.

Adobe AIR is a platform in which developers can create desktop applications which work on Linux, Windows, Mac, and other platforms. Developers can create an app using the same technologies that they might use to create a web site, but have it installed and deployed as a desktop application. From the Adobe AIR website:

The new Adobe® AIR® runtime enables Ajax developers to build rich Internet applications (RIAs) that deploy on the desktop. AIR applications run across operating systems on the WebKit HTML engine and are easily delivered using a single installer file. With Adobe AIR, Ajax developers can use their existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web.
(source; emphasis added)

So it seems that a big selling feature behind Adobe AIR is that developers can re-use web development code in building Adobe AIR applications, because Adobe AIR uses the Webkit engine.

But the problem is that Adobe AIR continues to deviate from web standards in favor of their own proprietary APIs.  A post on the Adobe Developer Connection website lists the various Webkit features turned off.  These features include: HTML5 audio and video, SVG, Web sockets, Web workers, Client database, Offline caching, and Window messaging.  With many of these features, Adobe states that they didn’t add the functionality because it was instead provided by an existing AIR API.  Their typical response reads:

Currently this is not enabled in AIR, but AIR does provide mechanisms…

So while Adobe states that developers can use “existing skills and code,” they are, at the same time, limiting which skills and code developers can use.  Adobe is betraying one of AIR’s greatest selling points by turning off some of Webkit’s hottest features in favor of their own APIs.

I’ve seen this problem many times. Someone develops a neat little gadget that can be computer controlled. It might be a toy microscope, a building automation system, or a mass spectrometer. Then the write a software application to control the gadget through a computer. Ten years later, there is nothing wrong with the gadget, but the software doesn’t.

The problem is that software applications is that they are written for today’s operating system, and there is no way to say that it will work on the common operating systems of ten or twenty years from now. Consider an app written 15 years ago. It would have been written for Windows 95, which you will find difficult to run on today’s advanced hardware. Maintaining a 15 year old computer which runs Windows 95 is equally difficult.

To avoid this problem, gadget developers need to decouple their gadget with a platform dependent software application. One way to do this is to build web servers into gadgets so that the gadget can always be controlled through a web browser without any special apps required. That is assuming that we will still use web browsers 20 years from now.


Categories