After several hours of fooling around with my Nokia 6680 and some tools I’ve finally succeeded! I’m able to use my home Internet connection on my phone via Bluetooth! Now I’m able to load my phone with tons of software, data and experiment with other nice applications like Google Maps without paying 1.5 Euro per Megabyte!

Here a short step-by-step guide:

1. Setup a Serial Port on your Mac:
   1. Open Bluetooth in your System Preferences
   2. Make sure your mobile is paired with your Mac (it should appear in the Devices pane)
   3. Go to the Sharing pane. Here you should have a Bluetooth-PDA-Sync click on it and enable Require pairing for security and make shure that your Port Type is set to RS-232. If you don’t have this port simply click on Add Serial Port Service and configure it as described above.
   4. It should look like this:
   5. Now run the share script (at the end of this article) to associate a pppd and share your connection
2. Download xans Version of GnuBox
3. Install it on your mobile.
   1. Create a new Access Point named Bt on your mobile.
   2. Set it up according to xans howto
   3. Set your mobiles IP to 192.168.1.131 (or the IP you chose for it in the above script).
   4. Setup the DNS IPs of your provider.
4. Start the gnubox application
   1. Ignore any error messages at the start
   2. Choose Options->Install->create records
   3. Choose Options->Install->copy settings from GPRS
   4. Choose Options->2box Bluetooth->Serial port
   5. Choose Options->Debug->Bring up IF
   6. That’s it! If you have any troubles, please refer to xans troubleshooting guide
   7. I’ve used Opera to test the installation. You have to configure it exactly like here .

It’s likely that some of this steps aren’t necessary, but it’s working for me.

Share

Here the script to share your serial port with your AirPort. You may want to adapt the script according to your setup

• IP Address (be sure to change it on both ends, mobile and Mac),
• Serial Port name,
• interface to share (for example the en1 interface is your AirPort and the en0 your Ethernet)

   
 sudo /usr/sbin/pppd /dev/tty.Bluetooth-PDA-Sync 115200 \
   noauth local passive proxyarp \ 
   asyncmap 0 silent persist :192.168.1.131
 sudo /usr/sbin/sysctl -w net.inet.ip.forwarding=1
 sudo /usr/sbin/natd -same_ports -use_sockets -log -deny_incoming -interface en1
 sudo /sbin/ipfw add divert natd ip from any to any via en1
   

Unshare

To unshare your port use this script:

   
 sudo /sbin/ipfw -f flush
 sudo killall natd
 sudo /usr/sbin/sysctl -w net.inet.ip.forwarding=0
 sudo killall pppd
   

or simply restart your computer.

Further info

If you still have troubles try these ressources in order: xans howto xans troubleshooting guide support forum

There’s also guide for Macs and Nokia 6600 mobiles available.

A very handy tool for debugging is the Bluetooth PacketLogger, available if you’ve XCode installed (take a look at /Developer/Applications/Utilities/Bluetooth).

Bluetooth Hack Series60 Nokia

We all know that programming languages affect productivity. For example writing a word processor in Assembler is much harder than writing it in C++. If seems natural to have a table with all available programming languages with their corresponding productivity value.

The main problem is to compare these languages. A common method is counting the “lines of code” a programmer needs for a given program. But who is going to implement the same specification in hundreds of languages? So to make the test applicable we need a common concept for the comparison.

This concept is called “Function Point Analysis”. This approach was introduced by IBM for exactly this task. Here you define function points (there are a lot of rules for doing that) and measure how many function points a programmer implements per month. More information about function points: Function Point FAQ and Fundamentals of FPA.

For the productivity measurement of programming languages we count the lines of code per function point.

The languages are categorized into levels – Assembler for example has level 1 with 320 lines of code per function point. A Macro Assembler has level 1.5 with 213 lines of code per function point etc…

Here an excerpt of this list:

Language	Level	LoC
Assembly (Basic)	1.00	320
Assembly (Macro)	1.50	213
C	2.50	128
C++	6.00	53
Haskell	8.50	38
JAVA	6.00	53
LISP	5.00	64
Objective-C	12.00	27
SMALLTALK 80	15.00	21

A lot of languages are special languages – like Excel with level 57. My guess is that a general purpose language is not able to go far beyond level 20.

Another table from here shows this:

Language	LoC
Assembler	320
Macro Assembler	213
C	150
Lisp	64
Basic	64
Objective – C	26
Smalltalk	21
Query Languages	16
Spreadsheet Languages	6

The values are the same or at least nearly the same for the languages (maybe they came from the same source?)

I would like to see a JavaScript, Ruby and Python included in these tables, but unfortunately I couldn’t find anything for these languages. I think JavaScript is no better than 10, Python and Ruby are together with Perl around 15, maybe Ruby has the highest level of these languages (Comments?).

The higher the language level the easier it is to read and change such a program. There is – of course – a trade off: the more code you write (for example in assembler) the more optimizations are possible. With increasing processor speed, and advanced algorithms this argument is getting more and more obsolete.

—
Programs must be written for people to read, and only incidentally for machines to execute. —Abelson & Sussman, SICP, preface to the first edition

If people talk of "Web-Services", they often mean SOAP as maintained by the W3C. But SOAP isn't everything. In fact SOAP was a basically a RPC (Remote Procedure Call) protocoll over HTTP (therefore the name Simple Object Access Protocoll). Since W3C took over SOAP (from Microsoft and later IBM) it has been extended into more general directions.

With REST (Representational State Transfer) similar applications can be written. REST itself is only an architectural style (defining how you should design your application). REST was initiated by the IETF as the basic model for the modern Web. HTTP 1.1 was designed using REST as tool for discovering unproper features etc... .

What is the essence of REST?

REST sees the Web as a collection of resources connected to a common network. Each resource has a set of associated methods (PUT, GET, POST, DELETE) to operate on them. SOAP on the other hand has services with definable methods (like getCustomerRecord, setCPUHeat etc...).

Since REST heavily depends (or defines) on existing standards existing software can easily be used with it. For example firewall administrators can block writing methods (DELETE, PUT, POST) on some resources, or internet caches are able to store resources requested by GET. SOAP uses POST (non-cacheable) to transfer the data between the client and the server. Using SOAP a firewall administrator has no chance to control access to his resources - he can allow or disallow SOAP (meaning HTTP). SOAP applications have to manager their own security.

The REST/SOAP debate is often compared to pre-SQL eras. Think of a database providing "getCustomerRecord" and "setCPUHeat" commands instead of general SELECT and UPDATE statements on resources like "Customer" and "CPU". The same applies to REST - here we have general methods, with SOAP we have specialized interfaces.

Why SOAP if REST is so good?

SOAP is a product (at least you can make products from the SOAP specification) - REST is "only" an architectural style. Guess with which one companies can make money? REST of course has it's drawbacks too, for example you cannot buy libraries to ease some task... . REST isn't widely known/accepted and few companies provide explicit support. Amazon calls it's XML over HTTP a REST interface, del.icio.us and flickr have REST interfaces too (usually XML over HTTP). The biggest drawback of REST is the lack of a description language - SOAP has a very powerful one with WSDL.

More? REST

--
The Church says that the Earth is flat, but I know that it is round. For I have seen the shadow on the moon and I have more faith in the Shadow than in the Church. -- Ferdinand Magellan (or not)

If you’re searching UML, Design Patterns or suchlike, you’re wrong here – this time I’ll try to cover some principles of puzzle design to general software from the point of the user:

Scott Kim, a well known Puzzle creator has written a great paper on Puzzle design called “The Puzzlemaker’s Survival Kit” (sorry, no link available).

He goes through principles, case studies and the design process of puzzle and game design. Some of these guides can (IMHO) applied to software design in general.

How? I think, puzzles in games and features in general software aren’t that different. Here the first principle of puzzle design written by Scott Kim:

He also writes: A puzzle is a problem that is fun to solve!

What makes puzzles different from problems is that they are fun to solve. A good puzzle is guaranteed to have a solution that is neither too easy nor too hard to find.

If we map puzzle to real world problem I want/have to solve we should design our software to allow this as easy as possible and powerful as needed. So, our software should enable the user to solve a problem with joy!

I wouldn’t limit “fun” to games – I think we could build software that every problem is fun to solve because the software helps us and doesn’t step in the way. It depends only on our imagination and our willing to invest a lot of time to build software that is fun to use. (Although game puzzles may be more fun to solve, but not as rewarding).

...neither too easy nor too hard… is another interesting phrase. Doesn’t that map directly to the power of any feature included into a piece of software? Conclusion: don’t treat your users as complete dumbs, design your features right – not too complex, but with enough power to perform a specific kind of task.

Scott Kim explains how to construct puzzles in games, let’s see if we can map these to software in general.

Think small.

Interesting, huh? Think small as advice! Isn’t that the same as Apples Think different – just take the iPod Shuffle or the Mac Mini? A lot of people try to get more and more features into a piece of software (Think big), but these systems tend to be overly complex and unusable (at least for me).

See how far you can get with the smallest number of features.

This is one of the most thrilling and adorable advices I’ve ever read! Don’t build battalions of special cases. Extract, refine and rewrite until you’ve got a truly elegant solution for the problems you want to solve. The web, meaning HTTP, follows exactly this advice. They striped out every special case and build a solid foundation for thousands of web applications by not disturbing or limiting the possibilities. See Axioms of Web architecture for more.

Many, if not all, of the brightest minds of history gave this advice – starting from Da Vinci Simplicity is the ultimate sophistication., Hoare The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay., Dijkstra Simplicity and elegance are unpopular because thy require hard work and discipline to achieve and education to be appreciated. or Simplicity is prerequisite for reliability.... .

Start with a tutorial.

Definitively a game design advice, or not? Eclipse, GMail and many more start with a tutorial – maybe we should think of including a quick and simple introduction into any given piece of software?

Make puzzles easy to author. ... Construction puzzles need to be as easy and fun to author as they are to solve. ...

This is a very underestimated advice in general software. Why do we think that we are the great masterminds and know every single case our users want to do with the software? There is no possible way for doing that with any given real world problem!

Open up your software and let users create features the need through an API, scripting capabilities or whatever. Design these interfaces so, that no existing code has to be read to use the API, Interface or Scripting capabilities. Make it easy to build new functionality and don’t even try to lock in the user!

Even Microsoft allows users to build their own little programs within their office suite.

Another big advantage: You might use that feature yourself to build new features and customizations… .

Simplification!

Do it! Any feature you find “hard to use” is for the user simply unusable – your user doesn’t invest month or years learning (like you building) the software!

User interfaces which you – as the creator – find “super easy” are usually “just right” for your users.

[I’ve written this in a rush, so please excuse some weird phrases and formulations.]

—
The imagination of nature is far, far greater than the imagination of man. —Richard Feynman

Rechargeable lithium-ion batteries are very common in gadgets like laptops, PDAs and cell phones, unfortunately these are very expensive. I had to replace my Sony battery for 250 Euro(!) – well I bought a cheaper clone for 100 Euro, but it has its drawbacks (at the beginning it worked for 3 hours, now for about one…).

So it pays if you keep your current battery up and running as long as possible. Here are a few facts I’ve collected over the last few months:

• Lithium-ion batteries can be recharged whenever convenient, there is no memory effect
• A new battery should be charged and discharged fully for the first three cycles (initial conditioning)
• Keep the electrons moving (discharge/recharge the battery at least once every month)
• Don’t keep your device plugged in all the time (this is very bad for the battery)
• Keep the working temperature in mind (22°C is best for most devices)

I put my notebook battery out if I’m working plugged in for a longer time.

Notebook Li-Ion batteries have a typical lifetime of about three years, but this depends on how you use it. A friend of mine uses his notebook on a daily basis (on battery) and his battery works for about four years now – I’ve used my notebook occasionally (mostly plugged in) and the battery had to be replaced after 2.5 years… .

I’ve read some posts on bulletin boards telling me to put my battery into the refrigerator – these procedure should repair some structure and the battery should work like a new one. Well I’ve tried it with my old battery, but it didn’t work :-).

Broken batteries usually provide their full power but only on very low power consumption, for example my broken laptop battery could power my cell phone for days (weeks?) because it consumes much less power than the laptop.

More resources: Apple Cellpower

Well – I’m after all a software guy, so the electronic stuff written here should be used with caution :-).

—
No man’s knowledge here can go beyond his experience. —John Locke

Yes, repetition is the root of all evil. Knuth (or was it Hoare?) said “Premature optimization is the root of all evil”, but I think it’s repetition. In fact repetition is often used to provide better performance (eg loop unrolling to suit your CPUs pipeline or the good old Duff’s device).

I’m talking about repetition in software – the typical copy and paste fault. Every programming book I’ve read so far deals in one or the other way with reducing repetition.

Think of patterns – each pattern tries to reduce the amount of code written by providing professional reuse mechanisms. - Factory tries to concentrate the code for creating objects on one place, - Strategy tries to supply a mechanism to traverse through interconnected objects, - Facade lets an existing piece of code hide behind another interface. - Singleton seems to be an exception because it reduces not the code replication rather the data replication.

In Test Driven Development the rules are simple: - write a test (red bar) - fake to get the bar green (unit tests are ok, when the “bar” is green) - clean up and remove replications

Every programming language which doesn’t provide good facilities to reduce replication should be considered harmful! All functional languages have facilities to pass around functions, Python and Ruby introduced similar techniques, Java… well no, but you can simulate such a behavior with enormous amount of code (I don’t know C#, but I guess Anders Hejlsberg introduced something similar).

Whenever you look at a program or you’re writing one and you discover some kind of repetition: Remove it! Kill it! Destroy it… whatever but get rid of it!

Each time I introduced some sort of repetition and had to fix a bug in there, I forgot to fix the replica…

Now, what should we do to reduce replication? Sometimes it’s a bit hard to remove the replication. In the eighties the keyword was subclassing. Today subclassing is considered a performance killer and is sometimes referred to as hardwired code. Now we have patterns – those magic constructs made by object gurus. I doubt that too many people do some kind of “pattern driven” design – those systems would get utterly complex and even harder to maintain than systems with a few repetitions. So, whenever you encounter a repetition just remove it as best as you can, don’t hack! Think of a clean lean design and write some tests before changing something (just to be sure you didn’t break something).

That’s one of Extreme Programming’s weaknesses: there is no master plan the whole team adheres. Each pair of programmers implements their user stories and doesn’t know what the others do (unless the pairs are changed very (very) frequently). [Extreme Programming isn’t written in stone, every team can adopt it to it’s own needs – so maybe there are some who indeed have such a master-plan]

On the other hand repetition helps me to remember things, therefore: Remove repetition in your software (and your friends software) as soon as you discover it!