In The Brain Session

I presented an "In the Brain" session at Skill Matter last evening. It was initially intended to be focused on Python and why it is a real "must learn" language - hence the title You Need to Know Python. However it became more a Python in context sort of session.

I had initially assumed most people would have a little familiarity with Python, but it became clear fairly early on that there was a very wide ranging experience of Python, from the very knowledgeable to the "haven't tried it yet". I therefore changed the content of various parts of the session on the fly. This is why there might have appeared to be a few discontinuities, well more than usual anyway.

As ever Skills Matter videoed the session and have already uploaded it, you can find it at:

I enjoyed the session, and various people came up afterwards and said how much they enjoyed it. So overall a success. Thanks to everyone who came, especially those who chipped in and made the session interactive. Thanks to Skills Matter for hosting the event.

You are almost certainly violating a patent . . .

Given the tone of the writing in this article about Apple winning a patent judgement against HTC, the author gives all the evidence of being a shill for an interested anti-Android party (probably either Apple or Microsoft). Putting aside all the emotive stuff (which is almost certainly just FUD), there is the point that two patents have been cited explicitly. Both of these are on Google Patents:

  1. US Patent 5,946,647
  2. US Patent 6,343,263

Read them and fear.

Admittedly on a relatively cursory glance, and remember I am not a lawyer, just a person who does expert witness work, it would seem that Apple have US patents covering all software that manipulates data structures (5,946,647) and all devices that do real-time signal processing (6,343,263). Ok that seems to mean all software and all signal processing hardware are covered by these patents and so royalties are due to Apple for every sale of such a thing in the USA.

One has to hope that HTC files for re-evaluation of these clearly over-broad and obvious patents. I would suggest little need to find prior art to invalidate the patents (though I bet there is a real mass of that - every bit of software written and every digital electronic device created before 1990 really), they fail on these other grounds. Why were the US Patent Office (USPTO) issuing such obviously over-broad and obvious patents? I assume because that is part of the way of business in the USA. The USPTO issues a patent if the paperwork is in order, and allows the courts to decide everything else - thereby making the lawyers rich and everyone else not.

If USPTO had sent these patent filings to any sort of expert in the domain, the patent would not have been granted. So whatever you believe about the rights and wrongs of software patents - personally I am anti - it must be agreed that the USA software patent system is out of control, indeed broken. Will it get fixed? Clearly not if Apple, Microsoft and IBM have anything to do with it. These are the tools of protectionism for USA big organizations. They won't now give them up without a huge fight, one the USA government are unlikely to have an appetite for. Sadly.

Don't forget though the USA, via the USTR (USA Trade Representative) are trying to impose the USA system of patents on the rest of the world via ACTA (Anti-Counterfeiting Trade Agreement) . We really must fight this patent imperialism.

Skills Matter, Python, and Me

As some people will already have seen from the announcements on Twitter, I have teamed up with Skills Matter to provide a Python training activity. The initial public courses are workshops for people who have some programming experience, but little or no Python experience - see this page for details. I am sure, over time, there will be a demand for my intermediate, and possibly even advanced workshops.

Although this activity is new, the courses themselves are not. I have been presenting Python training since 2006 - and a Python user for many years before that. The courses are not of 5 year old material though. After each presentation, the courses are reviewed and updated in the light of the feedback from the presentation, and the state of the Python world at the time. So the material undergoes continuous evolution to stay in tune with the Python language, its philosophy and its practical use.

If you fancy coming on one of these courses contact the Skills Matter sales folk by phone on +44 20 7183 9040. Or even drop me an email.

_ If you spot anything you think is wrong or missing in the advertised course, please send me an email. _

Jeepers GPars, It's All So Easily Parallel

I'll be doing a session with the above title for the BCS Edinburgh branch on 2011-09-14 at 18:30, unsurprisingly in Edinburgh. Details are to be found on their website here. I repeat the marketing blurb here:


In the beginning, a computer had but one processor and one memory and programmers knew what to do. Unless of course their program involved concurrency, in which case they had to learn about locks and sempahores and monitors and all manner of things arcane, and indeed, obscure. But there were great minds at work and as well as many "toy problems" to help programmers learn how to use locks and semaphores and monitors, many new higher level applications structuring models were invented: Actor Model, Dataflow Model, Communicating Sequential Processes (CSP) - to name but three. Sadly these models were eschewed by the mainstream, who convinced themselves, and nigh on everyone else, that operating systems techniques of shared-memory multithreading were a necessary evil of applications programming. And concurrent programming was deemed hard. And parallel programming harder, even when using frameworks such as MPI.

Then we had the Multicore Revolution, which started about 2004 and will continue for many years yet. This brought parallelism from the upper stratosphere of high performance computing (HPC) to the very heart of the mainstream. Worse, processor clock speeds stopped their even increasing rise, terminating the free ride of ever increasing performance of single threaded programs. So mainstream programming had to learn how to do concurrent and parallel programming, and they said it was hard, which it is. Fortunately some remembered the old models, and they were revived, and given new life. And the models prospered, as it is increasingly clear to all programmers that shared- memory multithreading is indeed very hard, and should not be used for applications programming, except where direly necessary

GPars is a Groovy/Java framework that brings Actor Model, Dataflow Model, CSP, Agents and other interesting high-level program structuring tools to the world of Java and Groovy programming. In this session we will look at some of these tools and techniques, and indeed idioms, and show that concurrent and parallel programming can be easy. Indeed it can be fun, which is a necessity for good programs.


You Need to Know Python

In this world of a plethora of programming languages, where new ones seem to appear on a weekly basis, C, C++ and Python have been, and remain, the main non-Java Platform languages. Even on the Java Platform there is Python, in the form of Jython. Gnome emphasizes C, C++ and Python, as does Canonical and many other organizations. The Python Software Foundation is definitely pro Python. Why is Python so "front and centre" and high profile? What makes Python so strong, used and loved as a programming language?

Even though Python is over 20 years old, it has evolved to stay modern and relevant. This is especially poignant given the Multicore Revolution that has caused so much change in C++ and so much distress for C. How does Python, a fundamentally sequential system in is CPython form, deal with the parallelism of modern hardware?

These questions, and I have no doubt many others, will be investigated in a free event I am running at Skills Matter at 2011-08-02T18:30+01:00. To sign up go to this URL.

If you don't sign up, we'll send Monty the Python round to put the squeeze on you.

Software Patents getting Back in the News?

This paper by James Bessen has stirred up the world somewhat regarding software patents - and a good thing too. As well as this Groklaw article (it's also worth looking at this one about the proposed changes in the US patent system), it even got to be a Slashdot article

The headline from the Bessen article is that small companies do not generally obtain patents, whereas large companies get them by the truckload, and that this is bad for innovation.

In the UK, software is not patentable per se, neither are algorithms. Bessen states that the case In re Alappat was the one that changed the nature of things in the US system, and allowed software and algorithms to be patented. Let us hope that the UK and EU do not allow the US to bully them into allowing software patents, and especially not via the tool of ACTA. What would be even worse of course is the US bullying the UK and EU to accept US patents as valid in UK and EU. This would likely kill small business software development stone dead. And UK software innovation would go out with it. Remember the US strategy is to support US development not to foster UK development.

What is the problem? Well a patent is enforceable even if the person violating the patent didn't know about it. Say you write some proprietary software and guard it as a commercial secret so there is no publication. Say a patent troll wants to target you. They find one of their seriously general patents which is bound to have been violated, cf. the patent on linked lists as an obvious example, they get an injunction to have your source code analysed to see if it is in violation. Along the way they will of course find others of their patents that might apply, and now they have access to your software,they can do lots of research on it. They then threaten to take you to court unless you pay licencing fees. At this point the issue is one of extortion (normally considered a criminal offence, and yet completely legal in the world of patents), you either suffer the indignity of paying licencing fees or you fight the case in court. Either way you lose financially. And most small companies cannot afford to go to court, it is simply too costly. So they either pay the fees or go into liquidation. Or sometimes, get bought by the patent holder for a trivial fraction of the value of the company.

So the situation where potential innovators do not play the patent trolling game but big companies do, means either potential innovators avoid any area that might be seen as competition to the big companies or they develop simply to sell to the big companies (not to create their own business). The big companies thus drive the agenda, usually for their own ends, and genuine innovation is sacrificed at the altar of big company profits and stock price.

The conclusion is inescapable: software patents destroy innovation in software development. Anyone professing to support innovation, must therefore be against software patents. Yet the UK government is towing the US party line and supporting ACTA and hence software patents. Clearly the UK government wishes to terminate all software innovation in the UK.

Sadly though software patents are now an integral part of the US business model. Witness the way Microsoft is using its unnamed patents as ammunition to force companies making Android phones pay licence fees for what it claims is its intellectual property. What intellectual property can Microsoft possibly have embedded in the Android system? Microsoft has made no contribution to Android and Android is not based on any Microsoft technology. Microsoft of course will not say and the contracts of licencing require silence from the licencee. This is definitely a "shakedown" operation by Microsoft. Although in any other area than licencing patents this sort of extortion would be illegal, with patents it is a valid business operation. So you can't blame Microsoft for employing valid business tools even if it is evil and objectionable.

Clearly the "conspiracy theory" goes along the lines of: Microsoft are trying to validate claims they will eventually take up against Google and Oracle, by having a lot of small companies already signed up as licencees. The eventual goal is clear, Microsoft are failing to keep their position in the market by creating new and possibly innovative products, so they are turning to software patent trolling as a way of generating an income stream from other people creating new and possibly innovative products - well at least products that people want to buy, in increasingly large numbers.

It would be good for the US government to put a stop to this software patent trolling business so that everyone can get on with innovating and letting the market decide who makes money and who doesn't. Software patents are a tool of protectionism, indeed a protection racket. It is a mechanism for squashing innovation. Let us hope the UK and EU governments recognise this and do the right thing for innovators. Make it clear that software and algorithms are not patentable, and let the innovation start.

Linux, Netgear, 802.11, Pain

A few days ago, Debian Testing changed its Linux kernel from 2.6.38 to 2.6.39. My Wifi connection between Lenovo X201 and Lenovo T500 laptops and the Netgear DGN3500 suddenly stopped working. Oh it would start fine and the laptops would connect, then a short while later, or sooner if there was a steady heavy load, the Netgear would crash requiring a power cycle - even the HTTP server console froze. This never happened with 2.6.38.

I reported this problem to the Debian bugtracker only for the bug to be immediately closed as "So there's a bug in the router". I beg to differ that it is so certain. Anyway the triager has agreed that should the evidence become more than a single data point, then the bug would be reopened and a message sent upstream that there is a problem. Personally I think the iwlagn folk in the Linux development community really ought to be very interested in the problem that has suddenly started occurring.

I also reported the issue to the Netgear forum - I had forgotten how much I hate fora, email for me any day. Someone has also spotted someone having a similar problem with a different Netgear router, and a different distribution, but the same Linux 2.6.39.

I tried some experimentation varying the WiFi connection speed on the Netgear and varying the kernel version. I also tried Ubuntu Natty as well as Debian Testing, both the 2.6.38 kernel and 2.6.39 kernel - Natty only has a 2.6.38 kernel as far as I can tell.

  • The 2.6.38 kernel works fine with the router at "upto 270", "upto 130" , and "g only".
  • The 2.6.39 kernel fails to work after a period or with higher loads at "upto 270" and "upto 130", but works fine at "g only". The deduction from this is that something has changed in the 802.11n aspects of the 2.6.39 kernel that either:

  • has diverged from the standard as implemented in the router; or

  • has corrected a divergence from the standard, that is incompatible with the router. I am sure there are other possibilities, but these seem the most obvious.

I would have thought the Netgear folk would be investigating this now that two separate people have reported it independently on different Netgear devices. Also the Linux/iwlagn people really ought to be interested as to what change they made that is causing this problem to exhibit. We shall see.

Grails Activity - Chapter 1: PostScript

A small postscript to the previous post: I get the following stats:

+----------------------+-------+-------+ | Name | Files | LOC | +----------------------+-------+-------+ | Controllers | 1 | 7 | | Domain Classes | 1 | 10 | | Services | 1 | 11 | | Unit Tests | 3 | 27 | | Integration Tests | 1 | 15 | +----------------------+-------+-------+ | Totals | 7 | 70 | +----------------------+-------+-------+

The Unit Tests are not listed in the book. So removing them I have 43 lines of code, which I think compares well with the 55 in the Smith and Ledbrook book :-)

Grails - taking a small draught

ACCU is running a mentored developer project on Grails using the Grails in Action book by Glen Smith and Peter Ledbrook. The place to start is Chapter 1 which is a rush through the main concepts of a Grails application. I did it once using Emacs and command line. Thought to try the whole thing in Eclipse using STS, but never got to that before moving on to Chapter 2. This is a set of notes based on me redoing the Emacs and command line sequence, to provide notes for someone.

Installed Grails 1.4.0.M1 to a place and ensured an alias to the right place so that grails works from the command line.

"grails create-app qotd" works fine. If this is the first time of running grails it seems very slow as it is downloading stuff -- I wonder what happens if you are not connected to the Internet? - and it seems extraordinarily slow in this case if the filestore in NFS mounted rather than local disc. Fortunately this delay all seems to go away if grails has been used before.

"cd qotd", "grails run-app" work as expected. Very seriously slow starting up on NFS mounted filestore compared to local disc. Finally decides to load resources, hibernate, tomcat, and jquery.

Am seeing lots of Gant output :-) (wander around and the source code to get the point).

Finally Grails is ready and . . . after a long delay . . . the expected Grails page shows on http://localhost:8080. Doesn't look anything like the image in the book of course as this is Grails 1.4 not 1.1, which is what was used for the book.

Grails and Groovy community seem to favour Git over any other version control system, so rather than fight the community by using Mercurial or Bazaar, decided to use Git. Followed the instructions at g+Projects+into+SVN#Adding%20a%20new%20project%20to%20Git Methinks this should be a separate page, and there should be stuff for Mercurial and Bazaar as well - Git is not mandated by Grails. Then found out about so used that instead. It seems that Grails deals with IntelliJ IDEA as well as Eclipse.

OK, ready to move on, so create a controller: "grails create-controller quote" seems to do the right thing but slow on NFS mounted filestore. This comment about NFS mounted filestores comes up at all stages, so I shall now assume you appreciate this.

Added the home closure (Groovy calls them closures, but technically they are not, they are lambda functions -- the Groovy community knows that they are abusing the jargon term but it's all too late now :-( Grails notices the file change and compiles the file but there is an error of some sort. "Failed to reload file". This is reasonable as the file didn't exist when Grails was started, so a restart needed.

Did I mention how slow Grails is to start on NFS mounted filestore?

Anyway success. Added the index redirect. Updated file compiled and seemingly reloaded. Redirect works. Excellent. Commit.

Added Emacs backup files to the Git ignore list.

Added a view and it worked!

Added the style template. Begin to wonder if SiteMesh is really worth it. Now discover that snazzy.css and logo.png are not found. Reasonable really, the default Grails project shouldn't contain them! The book really ought to say something about putting these things in the web-apps directory. I didn't think I'd have to do a Grails restart but I did. Then discovered snazzy.css refers to three other image files background.png, logo_background.png, and menu_background.png. Found versions, put them in . . . failure. Restart Grails again. I get the feeling that adding any new file requires a restart.

Onto domain models. "grails create-domain-class quote" works fine. Listing 1.10 is slightly wrong, don't use what is printed there ("jdbc:hsqldb:file:devDB;shutdown=true") instead use "jdbc:h2:file:devDB".

Short-circuited the loading of the database by writing a Groovy script and then executing it in the Grails Console. Noted that qotd.Quote has to be explicitly imported, which the book doesn't mention.

Did I mention things are extraordinarily slow over NFS mounted filestore?

Apparently Grails not finding jquery at this point is not a problem.

Amended the controller to present a random message. Worked fine. Can't say I like the coding style of Listing 1.12, far to imperative and not nearly declarative enough.

def random = {
def allQuotes = Quote.list ( )
[ quote :
( ( allQuotes.size ( ) > 0 )
? allQuotes[ new Random ( ).nextInt ( allQuotes.size ( ) ) ]
new Quote ( author : 'Anonymous' , content : 'Real Programmers don\'t eat much quiche.' ) ) ] }

Scaffolding gives a CRUD interface by adding a single line to the controller. Magnificent.

Noted that all entries created via the scaffolding are created at 00:00 -- how to add a time to the date of creation?

Grails gets confused by the .#Quote.groovy file created by Emacs.

Added constraints, but the screen doesn't quite look like the one in the book, no time, just a date.

Created the service, spotted error in book, path shown is grails- app/services/QuoteService.groovy but should be grails- app/services/qotd/QuoteService.groovy

The field transactional is not in the default service as in the book, presumably a 1.1. -> 1.4 change. Listing 1.15 still hideously imperative and insufficiently declarative.

class QuoteService {
boolean transactional = false
def getStaticQuote ( )
def getRandomQuote ( ) {
def allQuotes = Quote.list ( )
( ( allQuotes.size ( ) > 0 )
? allQuotes[ new Random ( ).nextInt ( allQuotes.size ( ) ) ]
getStaticQuote ( ) ) } }

Started adding the tests. Spotted that the code listings had the wrong class names QuoteService Tests should have been QuoteServiceIntegrationTests. I hate * includes, not sure why but I do. the Grails template integration tests is full of them. Also of course the book is using Grails 1.1 and hence JUnit3 whilst Grails 1.4 uses JUnit4 so the test files are very different looking. But this is good. Using TestNG would of course be better than using JUnit4. But then using Spock would be even better. Must find out how to use Spock for these Grails tests.

Test reports go in a different place that stated in the book, I found them at target/test-reports/html/index.html. We are green :-)

Funny I always though AJAX was a scouring powder like VIM, apparently though it works well with Grails. I use the word apparently as it seems means you have to hack a lot to get it working. Something to do with JavaScript -- or should that be ECMAScript, is there actually a difference?

I think at this point I am going to quit, I'll leave AJAX hacks until I need them. Maybe actually try to do this with Eclipse/STS.

Final note: Grails is going to be great fun, and very efficatious at creating the Web applications I am seeking to build.

Copyright © 2005–2020 Russel Winder - Creative Commons License BY-NC-ND 4.0