Going Dark to Fight SOPA.

Copyrights vs. human rights by opensourceway

On January 18, this blog, alongside many other websites, is going dark for a day to protest against the proposed introduction of the Stop Online Piracy Act (SOPA) and its Senate counterpart, the PROTECT IP Act (PIPA) in the USA. SOPA will not just affect those in the USA; its knock-on effects would touch every website in the world. Under the proposed legislation, it would be illegal for us (or you) to link to any website – any website at all, including community-driven behemoths like YouTube, Flickr, Blogspot or WordPress (where we’re hosted) – without checking first that nothing on that site infringes copyright. And we’d have to review those sites continually after a link was made.

Under these Acts, every person making a link to such a site would have to check the millions of other pages on that site to ensure that nobody, anywhere, is breaching copyright. Even search results would be covered under the proposed law. And if a website like ours were to be prosecuted for linking to another site where copyrighted material was hosted, our domain could be confiscated and our IP address added to a USA-wide blacklist, even though we are not US-based.

So far, so ridiculous. It’s censorship and shifting of responsibility on a grand scale. But despite a loud chorus of opposition to the Acts from legal experts, internet experts, journalists, website owners like us, human rights activists (want to publicise the next Arab Spring using Twitter, Facebook, YouTube or another site that potentially infringes? You’ve just provided the powers that be with an instant excuse and mechanism to shut you down) and ordinary people who just surf the web, the Acts stand a genuine chance of being pushed through. Lobbyists like the Motion Picture Association of America (MPAA), the Recording Industry Association of America (RIAA) and the movie and music studios have much louder voices and deeper pockets than we individuals on the internet do; but by joining together on January 18 we hope that we can make enough of an impact to be noticed by those voting on the legislation, and by the news outlets that they read and watch.

So on January 18, this blog intends to join the planned shutdown organised by Reddit. This site will be unavailable from 8am EST to 8pm. We encourage those of you who can to join us – and if you’re a US citizen, please call or email your representative.

Dependency Injection – Why Bother?

dependencies by jonathanvlarocca

In this post we discuss the various mechanisms of Inversion of Control (IoC) including Dependency Lookup and Dependency Injection.  We look at the differences between the various IoC approaches and present the advantages and disadvantages of each.

Handling Shell Script Interrupts

A Real Screen Shot

If you do much shell scripting, then handling shell interrupts is something you should consider.  As a user is interacting with your script, they may decide to interrupt it by typing Ctrl-C, for example.  Typically this will interrupt your shell script execution, forcing it to exit.

Depending on what your shell script is doing, this could leave behind temporary files, or leave other files in a broken state.  It would be useful if you could trap the interrupt, and handle it safely, before exiting the script.
This can be achieved on most shells using the ‘trap’ command.  The trap command takes the following syntax:

trap [OPTIONS] [[ARG] SIGSPEC ... ]

The ARG is the command to be executed on signal delivery, while SIGSPEC is the name of the signal(s) to trap.  Options include -h for help, -l to list signal names, or -p to print all defined signal handlers.

For example, to always return a ‘user aborted’ error code, the following line in your script could be used.  Whatever value given to $exit_user_abort would be returned.

trap 'echo "`basename $0`: Ouch! User Aborted." 1>&2; exit $exit_user_abort' 1 2 15

The numbers 1, 2 and 15 at the end of this example define which interrupts we’re interested in trapping.  These numbers correspond to different kinds of interrupts.  A short list is given here, but you can use ‘trap -l’ for a complete list.

Signal Number	Signal Name	Explanation
0	EXIT	exit command. Script has executed successfully.
1	HUP	Hang Up. The user session has disconnected.
2	INT	Interrupt.  Ctrl-C (or other shell interrupt signal) has been given.
3	QUIT	Quit.  Ctrl-\ (or other shell quit signal) has been given.
6	ABRT	Abort signal.
15	TERM	Terminate.  Kill command has been issued against your script.

If your trap runs several commands, it’s possibly neater to call a shell function than list the commands in-line, as above.  For example:

trap funcname 1 2 15

funcname
# Function to handle interrupts
{
echo "`basename $0`: Ouch! User Aborted." 1>&2
exit $exit_user_abort
}

Technical Marketing

Tag Cloud

It saddens me sometimes to see videos like this.  While the rest of us chuckle, we fail to learn the lesson, that users don’t share our world view of software.

As a Software Engineer, I am too well aware of our industries penchant for technical terms.  Yet the fact remains that you can use the internet without knowing what a “browser” is, just as well as you can drive a car without knowing what a “limited slip differential” is.

Follow me on Twitter

I’ve decided to bite the bullet, and see what all the fuss is about this Twitter thing.  I’ve signed up, and now I need a few buddies to follow (and be followed by).  You can find me at http://www.twitter.com/gosub3000.  Drop by and introduce yourself.

Getting Subversion Revision in Ant – Part II

We have previously discussed getting the subversion revision number from an ant script.  While the previous method relied on antcontrib and regexes, I’ve recently come across the SvnAnt project.

SvnAnt is a contribution for ant, which allows for access to svn functionality from within your ant scripts.  Several of the svn operations are available, and are documented here.  Personally, I think that your build system shouldn’t be mucking around with your source control system, though it is useful to use the subversion revision number as part of your build numbering system.

<target name="find_revision" description="Sets property 'svn.info.lastRev' to head svn revision">
<path id="svnant.libs.path>
		<fileset dir="libs">
			<include name="svnant.jar"/>
			<include name="svnClientAdapter.jar"/>
		</fileset>
	</path>

	<!-- Load SvnAnt -->
	<typedef resource="org/tigris/subversion/svnant/svnantlib.xml" classpathref="svnant.libs.path" />    

	<!-- find head revision number, amongst other things. -->
	<!-- Replace svn_username and svn_password with values appropriate to your system -->
	<svn username="svn_username" password="svn_password" javahl="false">
		<info target="." />
	</svn>

	<!-- Display svn revision number -->
	<echo>Revision found: ${svn.info.lastRev}</echo>
</target>