Tim Hardy

To give myself a break from my studies, I’ve been exploring writing code for my mobile phone. I bought a Series 60 phone at Christmas from a high-street store planning to learn how to program it. Instead I ended up wasting most of the holidays dealing with Carphone Warehouse’s appalling customer service.

(It’s a long story. In brief, the salesman lied to me and sold me the phone on a tariff that was unusable with the handset meaning I couldn’t get network access on it. His manager, an unhelpful thug, refused to accept the return of the phone. It took close to 40 hours of phone calls, letters, emails and visits to stores to cancel the contract and get my money back. The experience left a very bitter taste in my mouth. I will never use Carphone Warehouse again.)

I’ve only scratched the surface of developing C++ apps for Symbian so far but while searching for a way to read GSM cell info (according to the forum posts it looks as if the API is restricted to registered developers who pay) I found that it was simplicity itself to get this data using Python for Series 60.

Learning Python is (yet another) thing on my todo list and after installing it on the phone and trying out a few sample scripts from the web I’m eager to do so.

Although it’s easy to code on your pc and send the finished script to your phone via bluetooth, there is also a way to code directly on the phone from your machine by using the bluetooth console that is included with Nokia’s python installer.

Assuming you have bluetooth up and running already on your Debian box:

$ sdptool add --channel=2 SP
Serial Port service registered
$ rfcomm listen /dev/rfcomm0 2
Waiting for connection on channel 2


Now start python on the phone and select bluetooth console from the options.

Connection from 00:16:4E:CD:09:06 to /dev/rfcomm0
Press CTRL-C for hangup

In a new terminal on the machine start minicom with the following flags

$minicom -s -m

then choose “Serial Port Setup” and set the Serial Device to “/dev/rfcomm0″ and you’re ready to run.

Test with:

import appuifw
appuifw.note(u'Hello world!', 'info')


You should get a “Hello world!” info box popping up on your phone screen.

Now for something more interesting, print the gsm location details of your nearest cell (see how simple this is):

import location
print(location.gsm_location())


Finally to send a text message (replacing 0000000000 below with the real destination number) :

import messaging
messaging.sms_send("0000000000", u"Hello there")


I can see Python coming in very handy for creating rapid prototypes of applications and/or simple applications for private use only. Although I find the low level details you need to know for C++ development fascinating, there’s something undeniably satisfying about being able to write an application that does something powerful in only two or three lines of code.

Inform 7 has been released, a new version of the langugage used to write Infocom-style text-based adventure games (am I showing my age?). Whereas Inform 6 resembled an OO language, version 7 resembles structured English.

In place of traditional computer programming, the design is built by writing natural English-language sentences:

1. Martha is a woman in the Vineyard.
2. The cask is either customs sealed, liable to tax or stolen goods.
3. The prevailing wind is a direction that varies.
4. The Old Ice House overlooks the Garden.
5. A container is bursting if the total weight of things in it is greater than its breaking strain.

Although the exams are over, I still have my project to complete so I probably won’t touch this for a few months but I’m looking forward to exploring it.

I’ve heard Haskell mentioned a couple of times now and (having far better things to do with my time) decided to look into it briefly just now.

It’s a purely functional language as opposed to an imperative one which leads to very succinct code for certain domains. For example, a quick sort in Haskell could be written as follows:

qsort [] = []
qsort (x:xs) = qsort less ++ [x] ++ qsort more
where less = filter (<x ) xs
more = filter (>=x) xs


Definitely something I’d like to look at in more depth when I have some time. Now back to what I should have been doing in the first place.

In bash, the return value of a called program is stored in a variable called $?

grep returns zero on a succesful match, one on no match and minus one on an error. Being able to read this return value enables easy conditional branching based on pattern matching, eg:


#/!bin/bash
# Branch based on pattern matching
PATTERN=$1
FILE=$2
grep $PATTERN $FILE > /dev/null
if [ $? -eq 0 ]; then
echo $PATTERN found
echo Now do something to $FILE
else echo Skipped $FILE
fi


Sure, you could use Perl or another more sophisticated scripting language to do this but the bash shell is powerful enough for most tasks.

I’ve just spent a couple of hours trying to track down an error in some Java code I’m writing that uses generics (an area I do not know as well as I would like).

I’ve been tearing my hair out, assuming that the problem must lie in something I’ve misunderstood about the new area. The code implementing generics looked correct, but then what do I know? It’s not an area where I’m confident so I must have made some kind of idiotic, beginner’s mistake with it that I’m just not noticing. Or so I assume.

I refactored the code substantially. The bar stayed red. The same test kept breaking.

And then I found the error. A typo in the unit test itself. My code had been generating the right results all along but I had been checking the wrong thing.

When I’m confident of something and there’s an problem, I check the simplest things first. But when I’m not confident, I assume that the problem must lie in the area I don’t fully understand and dive straight into that without pause to check anything else.

I’ve fallen into this trap often enough that perhaps I should consider it a personal anti-pattern. Hopefully articulating it is the first step towards breaking it.

If you get annoyed when Eclipse alerts you about your unit tests that “This method has a constructor name”, you can set it to ignore these warnings in Window / Preferences / Java / Compiler / Error/Warnings - set “Methods with a Constructor Name” to “Ignore”.

It’s generally a bad idea to switch off warnings but in this case I think the JUnit syntax is confusing Eclipse so it’s easier to just switch them off.

Eclipse won’t print under linux. The bug report makes for an interesting read.

However, Kim Lux has posted a rather satisfying workaround for KDE users which allows you to open your currently selected text file in kwrite and print from there.

To set this up: Run/External Tools/External Tools. Create New, name it kwrite-print, location: /usr/bin/kwrite, Working directory: ${container_loc}, Arguments ${resource_name} then, if you wish, switch to the Common tab and select External Tools in the Display in Favourites menu window.

Now you can use Run/External Tools/kwrite-print to open your code in the external editor and print it from there.

Following a discussion on a mailing list tonight about object-oriented v procedural programming, I’ve been doing a little digging.

The discussion was on whether objects should have their own print method or should be passed to an external Printer object that handles that function.

One solution in Java would be for them to implement an Interface Printable that provided a toString() method. That way, the object remains decoupled from the output process but encapsulation is preserved and the Printer object (which takes a Printable object) does not need to know anything about the internals of the objects it is passed.

Which led to the question, can you do this in C++?

It looks as if Interfaces do not yet exist in C++ in spite of some interest. There is a library under development however for submission to Boost.

In an interview from 2003, Bjarne Stroustrup advised programmers not to treat C++ as C and to take advantage of the STL. He was wary, however, of copying the Java model and making everything too OO.

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn’t have been a class in the first place. It’s just a data structure. And if it really is a data structure, make it a data structure.

The C++ Style Sweet Spot | A Conversation with Bjarne Stroustrup, Part I by Bill Venners (October 13, 2003)

It’s a brief and interesting read.

I recommend writing small but useful programs every day. Never mind that someone has written the same or better once. They are not you. You must feel the utility of your own programs to gain a sense of balance between that and complexity.

WardCunningham

Sage advice found here while getting distracted from my main purpose.