10.25.07
Posted in Development, Mobile, Papers, SDN, Symbian, c++ at 12:10 am by Twm
My new article has been published on SDN.
http://developer.symbian.com/main/oslibrary/cpp_papers/advanced.jsp
This article describes how to write a basic preserving HTML parser which populates a CRichText object. This allows the text to be presented and edited using the stock S60/UIQ rich text controls.
Originally developed for MobileMind, the DLL is not only useful for loading and saving HTML but also great for injecting paragraphs of formatted text into rich text objects programatically.
Permalink
10.23.07
Posted in Uncategorized at 2:53 pm by Twm
In my last flat I had a Sky Plus box with some eleventy billion channels to occupy my evenings. I spent the first weeks glued to the TV as if it was the first time I’d seen the glow box. At one point, I was obsessed with “How it’s made” – a show about how things like chewing gum and violins are made.
When I moved a few months ago, I decided not to get a telly for the flat and instead moved onto DVD rentals from LoveFilm. I had already made the transition because I was sick to death of
adverts interrupting the flow and actually found it more engrossing to watch a series at a rate of one episode a night.
Without a doubt the series which I enjoyed the most was HBO’s ‘The Wire’. In fact, I watched the three seasons within two months and am desperate to get hold of the next season. I’ve not felt so attached to a TV series for a long time.
The structure is of a slowly unfolding novel and so makes it hard to approach mid way, it’s not the sort of thing a viewer will pick up from a few episodes but the reward for persevering is bountiful.
What starts as a seemingly average cop drama slowly reveals itself to be more of a treatise about institutions and individuals.
It’s written by David Simon – who was a crime reporter for Baltimore sun and spent a year shadowing a shift of detectives from homicide. The experience lead to the writing of ‘Homicide – a year on the killing streets’ which was the basis for the ‘Homicide – life on the streets’ series during the 90s.
Read the rest of this entry »
Permalink
10.18.07
Posted in Development, Integration at 4:16 am by Twm
I’ve been trying to keep up with the iPhone unlocking stories that seem to have popped up almost daily on the various tech news sites. I especially liked the story about a teen that was proud of his unlocking achievement but his friends said he had wasted his summer. It’s quite fascinating to see the different methods and breaking and entering said device, but I’m more interested in the whole question of the cost benefit of openness.
Read the rest of this entry »
Permalink
10.12.07
Posted in Development, Graphics, Mobile, Symbian, c++ at 10:34 pm by Twm
I recently had cause to run some of my old benchmarking code on a couple of recent Nokia devices. I wrote one benchmark to quanify the tradeoff beteween RAM and performance when comparing the bit depth (and hence RAM foot print) against the blit time (drawing performance).
The performance graph below shows the median performance figures achieved when copying to the screen, bitmaps of different depths (those supported by Symbian OS9.0).
The rate is measued in Frames Per Second (FPS) which is a value arrived at by taking one over the mean time for a single bitblit. As an example, if it takes 500ms to draw one frame, then 1/0.5 = 2 FPS).
There are two striking results from the data
- The native bitdepth of the sceen EColour16MU is massively faster than any other display mode (on both devices)
- The N95 is more than twice as fast as the E61 at all bit depths
It’s fairly simple rule that on these devices, performance dependent use cases should always use EColour16MU. And from experience this can be generalised as “For performance – match your offscreen bitmap to the depth of the screen”.
Read the rest of this entry »
Permalink
10.08.07
Posted in Development, Integration at 12:03 pm by Twm
Branching of code occurs when an organisation or individual make a change to a code line, causing two or more distinct code line points which can be called the head revision of a piece of software.
The definition above is not perfect distilation of a branch, as there are some ambiguities, but it will serve well for the rest of the discussion.
Branching is an incredibly important mechanism for creating code stable enough to ship products, while allowing future work to continue at a decent rate. It doesn’t always allow future products to steam roll ahead since (depending on project structure) the developers often have to spend more time doing product maintenance than writing new code.
In this treatise; I discuss supplier release strategies, and go on to distinguish the term “Fork” as a seperate type of branch which a customer may create in certain situations. Finally I discuss the costs associated maintaining a Fork, especially in a climate of Frequent releases.
Read the rest of this entry »
Permalink
10.07.07
Posted in Symbian, Writing at 6:40 pm by Twm
My main computer has shifted to a Dell latitude D420. This is an ultra portable and light computer which fits snuggly but easily in my laptop. It can easily do four hours on the battery while writing.
I’ve been doing a lot of freelance technical writing recently including some book chapters. It’s all very time consuming but also fun. I’m sure there is a lot of vanity on my part, but I like being able to show my mum some tangible output related to what I’ve been doing for the last decade or so.
The laptop is great, and aside from being pre-installed with Vista, the only real problem I have is that the screen’s just not big enough for serious copy editing. It’s fine for knocking up thoughts and writing ideas. But when you want to get a few hours of concentrating reviewing and re-arranging for page layout – at only 1280×800, It’s impossible to get a good idea of how things flow: Or so I though.
One evening I must have accidentally hit the short cut key which rotates the screen. I had word open at the time and was impressed to see the A4 page rendered more or less actual size and still readable.
At 800×1280, it’s still no Mac publishing engine. But it really helped get through a lot of work faster. The only problem with this method is that you need a mouse and an external keyboard.
The Symbian OS Comms Book Second Edition is available on Amazon here.
Permalink
10.04.07
Posted in Development, Mobile, Papers, SDN, Symbian, c++ at 11:14 am by Twm
Symbian Developer Network Published my Roids game and paper here.
Roids is a complete game worked through with documentation. I wrote the original several years ago, and it’s nice to see that it ports to the latest Symbian phones without too much trouble.
Permalink
10.03.07
Posted in Uncategorized at 7:03 pm by Twm
Starbucks are everywhere and while I’m not a big fan of their coffee, I quite like their muffins and am particularly interested in how the business was built and scaled (across continents).
To make a succesful chain, it seems that you have to avoid any sense of individuality. It’s all about establishing a reproducable business model and the thick manual which defines every role, every process. To use a cliché: The processes make up the DNA which allows the system to spread.
I was lucky enough to witness a mutation of the DNA(or at least behaviour that I’ve not seen in any other branch). The shop at Waterloo train station is a tiny booth with room for three workers, and is surrounded by a couple of tables.
I had visited the shop on my way to work several times, waited in the large queue for about thirty seconds and promptly left to try one of the other coffee shops on the concourse, in the hope that I’d be served quicker. I wasn’t the only one, I noticed a lot of tail attrition of the queue by those realising the wait was longer than they had chanced for. (Us Brits are drawn to queues but then abandon the purchase when progress isn’t fast enough.)
My Coffee last week however, was different. While waiting in the queue; a lady with a radio mic and Starbucks t-shirt approached and took my drink order. This Madonna impersonator was an extra member of staff on top of the usual baristas and the till girl.
Having given my order, it would feel rude to jump ship and so I was now locked in. As I moved up the queue to the counter, my drink was ready and IÂ was out of there in good time.
This is a great optimisation which works for three reasons:
- There is a person continusoulsy making coffee without context switching to tills or trying to decipher the various requests from indecisive punters and those with thick accents.
- The running of the service at this intensity is only required for a short burst in the morning, not all day
- Morning commuters are creatures of habit and generally know what they want to order without needing to see the menu
- The lock-in is a strong disincentive to leave the queue : Tail attrition is reduced
Under this scheme. I assume that net profit gain offsets the cost of the staff to walk the line.
Permalink
Posted in Development, Integration, Mobile at 9:14 am by Twm
The Quick fix is a well established part of software development, and every engineer has done something in a hurry, under pressure, which bites back in a few weeks when the next level of testing reveals a flaw, regression or worse, they fail to spot it and a customer finds the bug.
Gaffer tape is not good. If we were talking automobiles, a plant manager would never let a car out of the factory with gaffer tape holding the wing mirror or the indicator on, even if the vehicle passes its MOT.
Software is different, it’s not a physical entity – without looking through the code, and you can only see the effects of the code.
On a large piece of integrated software, it’s impossible to test every combination of software variable and so the test has to be constructed well enough to cover every feature to spec, and an important subset of all the possible concurrent use cases.
When a solution is ready, this is the time to write the test case to go with it, get the test and the fix peer reviewed and sleep on it and submit the next morning.
Sometimes it makes more sense to write the test case first, especially if the defect is hard to reproduce, but has obvious cause.
Projects which make a distinction between fix and fix + test code should be weary. Those worried about the extra time taken to write test code should consider the extra time injected later on the whole process of test, triage and resolution has to be applied the next time, or when a follow on fix to the same component causes a regression to a previous fix because the test code isn’t up to date.
The quick fix is like peeing your pants. At first it’s all warm and great and you feel good, but when it goes cold- man your realise that it just wasn’t worth it. (Thanks for that quote Matt).
Permalink
