A problem shared is a virus?
I spoke at the Symbian smartphone show last year and the slides have been posted by Symbian.
I quite enjoyed putting the talk together, but realised quite late in the day that it was only a 20 mins slot rather than an hour. So apologies for anyone who attended, I went through it incredibly fast.
In case you were wondering, the watermark in the template is my parent’s back yard in Wales.
I used to read the dailywtf.com often, a website which originally just posted anonymised coding horrors sent in by the readers.
The site has expanded its scope to include disastrous project management techniques and stories from the front line of sysadmin. But unfortunately the horror stories seem have come to represent the norm rather than the exception in the software development and so I lost interest somewhat. I do however, occasionally visit to be cheered up by a moronic dialog box or some hoplessly desperate code fragment which takes a twenty lines to concatinate a string rather than use the built in function.
After spending so many years establishing the fundamentals as a C++ engineer, trying to master thread safety, secuirity, atomic transactions and small footprint code. It can feel a little off putting to have the mobile platform open to any developer who can throw together some javascript and XML.
It’s not that I think these technologies are bad or inappropriate even, it’s that I worry about anything that grossly underestimates the development effort.
Read the rest of this entry »
note: Just to ensure that this posting dates quickly. I’ve adopted the word “Yo” as a gender neutral pronoun (as used by kids in Baltimore).
I had an interesting case this week. A guy working on maintenance of telephony code asked for some advice. Now maintenance is one of the trickiest things to do if you are not the person who wrote the original code. You have to get into the head of the developer, try to figure out yo’s skill level, how much time was given to the design and what level of testing the module has received.
When a developer changes a bit of code, and alters its fundamental behaviour, then the safety net of test code which protects the module should trip up, politely announcing that the clean re-factored design is full of holes.
Back in the real world, a developer at some point in yo’s career can expect to inherit some spaghetti code with minimal to zero test code.
This is where the same clean re-factored design emerges as above, but now a whole lot of code paths will be missing from testing since the main focus will be on the feature which is being added or the defect being rectified.
Read the rest of this entry »
Camera optics are complex things. Anyone who has ever read a photography magazine or tried to follow a discussion on-line will have been baffled by jargon such as F stops, focal length, film speed, wide, telescopic, tilt and shift, and so on.
The basics can be learned relatively quickly, but sensing the best combination of light, lenses and stop which will capture a scene the way you want is a big investment in time and experiment. It’s the art of photography.
So given the many factors to choose from to get a ‘good’ image. It’s not surprising that camera marketing folk have capitalised on the mega pixel. It’s a simple scalar analogous to the GHz of the PC world. In other words, more is better, and that’s all you need to know.
It doesn’t take much investigation to work out the lack of correlation between image quality an mega pixel is often coincidental. Nokia have started to put much better Carl Zeiss lenses on their N series phones (and in some cases protect them from pocket dust which has a much more drastic effect on image quality). But still, a lot of people I encounter seemed to have been been inflicted with a pathological pixel inadequacy.
Of course, with a simple quality metric comes a irrational arms race. Marketing express their requirements to engineering in terms of ‘more pixels than competitors’ rather than image quality, simply because that’s what the free-market demands.
So I was quite pleased when a friend who studied fashion photography passed this link on to me:
http://6mpixel.org/en/
It describes the image depredation due to noise which occurs when using really dense sensors. I.e more mega pixels are not just a waste of disk space but also there is a point where the quality degrades. It’s very interesting to see actual sensors lifted from various cameras.
Please do your bit, go see a psychiatrist about your pixel envy.
This week I attended a Goggle Android developer day at the London office. It was less productive than I thought it would be since a lot of developers are having commitment difficulties with Android and wish to get as much re-assurance as possible before going ahead and learning yet another language, framework, tools and security model.
The SDK is rather good for a first platform release, especially since it supports Linux mac and PC from day one. The fact that Java was chosen as the source doesn’t bother me because I know the eclipse tools are most mature for Java development and if the core data structures and utilities are the same as JavaSE then it means that developers can spend time getting to know the frameworks rather than learning a new linked list class.
The frameworks seem sensible, encapsulate data well and work within an provider/activity framework which has a design goal of allowing either the provider or the activity to be replaced by 3rd party developers.
It’s the last point which is seen as a key strength of the Android platform but also the aspect that developers regard with most suspicion. A big perception in the industry is that netops and certain key partners get “under the counter” API headers and documentation which are not available in the SDK.
Read the rest of this entry »
