aporem.net

Imagine you’re on a development project which relies heavily on a third party software.
Then, out of nowhere a new version is released which changes the function(call)s in a way that your software breaks.
Or the end of life of this code is announced surprisingly.

Actually, there is very little you can do to avoid such situations. But the shock can be mitigated somewhat by being well informed and up to date with the press releases of the software provider.

Usually, there is either a mailing list or a syndication feed with important release informations. There are probably also some rumor sites or private blogs of developers which could give away some hints beforehand. Or even advises how to handle the situation.

Now being well informed doesn’t solve your problem: the project is at risk in both scenarios.
So the development process has to stop and some emergency plan has to take effect.
First, the impact has to be quantified. Which parts of the project are affected? (All others can go back to work)
Second, decide what has to be done. Is it feasible to adjust to this new situation in the current state of the project? Do some parts of the project need a code review? Has this to be communicated to the public?
Third, test against the above points and reiterate if necessary. Or close the incident and get back to normal work.

So note that third party software provider, especially the commercial ones, have their own schedule.

This post will start a little series about the caveats of using third party software in your software developement projects.

Starting from simple system calls and ending in the mere utilization of a complex framework with little or no own code, software development always includes the use of third party code.
There are tons of posts about which software to use for which programming task or what effect the use of commercial third party software is going to have on your business/soul/clients, but what do you have to take in account after you have chosen your underlying code base?

The upcomming articles try to give you an answer to four major problems the developer faces:

• Updates of the third party software
• Licensing changes
• Unfixed bugs and changes in course
• Requirements for YOUR clients

The next rant will start with the schedule issues.

The permalinks structure is now changed to a category based link structure. This means that individual articles are now accessible via “/category/name-of-the-post/” instead of the meaningless post number.

This makes an individual post URI more readable, easier to recall and ‘hackable’, i.e. deleting the postname from the URI shows all articles in this category.
Additionally, the pages have nice names, too.

As everything this comes at a cost, namely longer link names and a complete new structure to pick up by the search engines. (Their indexing algorithms don’t like changes in the structure of a web site.)

Most modern programming languages allow you to define macros, new symbols or other extensions. Generally, you don’t want to use this features. Here’s why:

First, keeping with the standards of the programming language you choose makes the code generally more readable. Not necessarily for you, but surely for anybody else. This saves time and effort if someone else has to go through the code. It could be your peer for the code review on the large scale enterprise project or some voluntary who helps out with the open source app you put on the web. And because the others have spent less time and pain going through the code, they can help you faster and will eventually do this again, compared to a hard to read code.

Additionally, you can keep up to date more efficiently. If you have spent lots of code shipping around some insufficiency of the programming language to get things done and in the new version there is a feature that makes these problems go away, how you are going to find the problematic spots if you buried them? Sometimes there are migration guides with examples of the new features. If you can start out right away going through the code semi-automatically, why spend time to adopt them to your customized language additions?

Moreover, why bother? Is there a real need to add some new features, macros or somethings to the programming language? Or would it be easier to address the problem with another, more suited language? You have to make clear what you want. Solving the problem or extending your favorite programming language? If it’s the second answer, why are you doing this within the code of an application?

This is not a post about how to set up key-bindings in your applications but why.
Users, especially power users, like to navigate across your application efficiently. This implies a sound user interface, where the things are in their “natural” places and a bunch of key bindings. Nothing is more annoying than having to click several times to accomplish a simple task and doing it all over again in every repetition.

Any good application framework should support the basic key bindings for the most important functions used by all applications, like command+N for “new”. But what makes the difference are the key bindings you define for everyday tasks within your program. These must not interfere with standard key bindings of the OS and in order to being used frequently, they should be easy to remember.

Try to use your application without the mouse and you will soon find out which key bindings to add!

I’ve read a very interesting point of view in [1]. It states that one should type in the programming examples printed in the book in order to better understand the inner workings of the code. First I was somewhat stomped by this blatant suggestion, but in the days of auto-completion and all those nifty editor tricks, typing in some dozen lines of code isn’t really a big deal.
With this little cost there comes a huge benefit of learning the IDE (if you are not already familiar with it), the debugger, for almost no-one can type error free and spend more time with quality code (as everyone knows that reading good code makes you a better programmer).
Additionally, I would like to stress that complete code examples are a must for any good book about programming. It’s somehow useless if only code snippets are presented and the text refers to “the complete sources can be found on the website accompanying this book”. The reader won’t read the rest of the code thoroughly and perhaps won’t even compile the sources. Therefore the source code will be of no educational use.

The fact is that can learn only through labor and learning to write programs means typing them — no matter if it’s your own code or not.
—-
[1] Simson Garfinkel & Michael Mahoney, “Building Cocoa Applications”. O’Reilly 2002.

Today the start of the FreeBSD 6.2 release cycle was announced by Ken Smith:

FYI – we have begun the release cycle for FreeBSD-6.2. Code freeze on
the RELENG_6 branch started last week. For people in the habit of
tracking RELENG_6 you will start to notice various pieces of it that
start saying “6.2″ for version numbers (despite 6.2 not being officially
released) as we progress through the release cycle. Sorry if that
causes a bit of confusion or problems but we need to do this as part of
the BETA/RC testing that gets done. Bumping things like the
FreeBSD_version to reflect 6.2 now gives the ports folks a chance to get
ready for it as part of their preparations for the release, etc.

The current targets for the BETAs/RCs/Release are:

BETA1 Sep. 17
BETA2 Oct. 1
RC1 Oct. 15
RC2 Oct. 29
RELEASE Nov. 13

We’ll give a bit more information along with the BETA1 announcement.

Notable about this message is how Ken Smith has stressed that this is just the start of the release process despite the fact that most version numbers already sport a 6.2 tag. Apparently there are more FreeBSD users out there who have not passed through a release cycle or are not familiar with such a formal procedure.

Welcome, new users!

I like comparisons. They usually help in making a judgement or decision. For example which product to buy or use. Almost every review of several items usually sports a table of “short summaries” with some sort of numerical representation of the measured qualities. This gives the comparison a touch of credibility and scientific methodology.

But comparisons and reviews only work, if one takes the qualities of the items as products of some/the same sort. It’s pretty pointless to measure how good something is created by the reviewed products. For example, it’s clear nonesense to measure the quality of texts produced by a text editor typed by two different persons! Therefore one must pay extreme attention what to consider in such a comparison.

So I was shocked to find a reference to The Computer Language Shootout Benchmarks. Clearly, programming languages are no products (not even their implementations) which can possibly be compared. A programming langugage is mereley a tool to create instructions for the processor. So every shootout (I use the word shootout here as shortcut for a comparison in speed) boils down to how many instructions it takes to accomplish the task. But this can only be compared for the same language since only this means that the source code doesn’t have to be changed. Any other shootout is completely pointless for exactly this reason: the underlying source isn’t the same (I’ve read another shootout where they implemented a simple for-loop to compare the speed between Fortran, Java, C/C++, and C# — they came out pretty equal).

Nevertheless I recommend the shootout page, first for the FAQ and the “Flawed Benchmarks” page which give a clear summary about the intentions behind this and second because it also has some pretty interesting results which are counterintuitive at first but where the answer to how this result can be correct lead to deep insights about how such shootouts work.

Yesterday the /usr/src/sys/conf/newvers.sh appeared in the CVS tree, so everybody who builds a new 6-STABLE with the new sources gets the 6.2-PRERELEASE tag.
This marks the beginning of the release process of FreeBSD 6.2. Now every commit to the source tree has to be approved by the release engineering team before being commited. This plays down to the fact that only bug fixes and documentation updates are allowed.

In a week or so the 6.2-BETA1 will be released, the first possibility to get binaries and ISO images from FreeBSD.org for testing.

Just shot myself into my foot running portaudit — it prevented me from upgrading a port because it contained vulnerabilities. Ok, it’s usually a good idea to get informations about vulnerabilites in the installed ports and preventing the careless admin from installing bugy software, but sometimes it just hurts. This time it was about a port containing more than one security flaw where the upgrade would fix some but not all vulnerabilities. So it’s clear what one should do: install the new version and wait for the next bug free release. But the portupgrade command keeps failing.
Here’s how to let it ignore the concerns it raises: portupgrade -m -DDISABLE_VULNERABILITIES

Happy upgrading!