Jan 6
To celebrate the turn of a decade, IEEE Spectrum Magazine has compiled the list of top 11 technologies of the previous decade. Apart from being an interesting read, the newsworthy part is the fact that technology 1 (Smartphones), 2 (Social Networking), 3 (Voice over IP) 4 (LED), 6 (Cloud Computing), 10 (digital photography), and 11 (Class D audio) are all closely related. Read more
Much has been made of the recent performance improvements of web browsers – Mozilla, Microsoft, Opera and Google all lining up to show how their browser is the fastest. Similar performance focused shot outs have taken place for databases (Oracle, IBM, Microsoft) or application servers (BEA, Microsoft, IBM, JBoss etc). Probably any software technology has been subjected to some form of performance comparison.
Performance is important – don’t get me wrong – but it is really very subjective and not as objective as the technology vendors imply.
I ran Mozilla’s ant test site with the new firefox 4 beta 7 and the new Google Chrome 8/9. Chrome won hands down. The test ran much faster in Chrome according to the numbers displayed. And the ants do seem to run smoother in Chrome.
But the problem for firefox isn’t its core code implementation, but its integration with the operating system. When Chrome is running the ant test, the window manager (X.org) consumes about 20% of the CPU leaving Chrome to consume the remaining 80%. But Firefox causes the window manager to consume more than 60% leaving only about 40% for the browser itself. Fix the integration and it should in theory be about 40 to 50% faster than Chrome.
But then again, maybe not. Performance projections are very rarely linear, but far more likely to be indeterminable curves riddled with bottlenecks.
The debate will probably die out soon, once we realise that even 100% improvements of a few milliseconds are still just a few milliseconds – but thanks to Google, all browser users win.
You can try the test for yourself here
Jul 28
Throughout my career, I’ve often been asked what I do for a living – a common question often resorted to when meeting new people in a social setting. Most of my social network outside my immediate work environment don’t utilise software for much other than emails, web browsing and word processing, so the answer “software architect” typically leaves a puzzled look on their faces. Know the face expression? 
Read more
The architecture review process is (or at least should be) a critical part of any IT project – especially considering the seemingly ever increasing level of complexity most IT architects face. It is a key opportunity for stakeholders to ask the ‘why this’ or ‘how about that’ questions with the dual goal of increasing their understanding as well as checking whether the architect is on the ball. It is a game of hunting down all of the critical assumptions – get them wrong and your project will be well on its way to failure.
Any architecture is built on a set of assumptions. We don’t know everything, and we need ways to limit our scope, so we use assumptions to reduce the unknowns and control our commitments. But in the process of making assumptions, we may incur ‘technical debt’. Read more
Apr 18
Wilhelm Röntgen discovered x-rays in 1895 which resulted in a worldwide flurry of excited investigations, speculations and wild claims. The American Institute for Electrical Engineers wrote a couple of years later that “the whole world seems to have been working on it for all this time without having discovered a great deal with respect to it“. At the moment, that sounds a bit like Cloud Computing. We all know about the potential infrastructure flexibility, cost savings, and elastic performance scaling, but the big question remain – how do enterprises with decades of IT infrastructure take advantage of Cloud Computing?
Bernard Golden recently wrote an article about ‘taking an application to the cloud’ versus ‘taking the cloud to the application’ – another way of saying that unless you design your application for the cloud, the application will remain hostage of old style infrastructure constraints. There is little point in elastic infrastructure if the application cannot be ‘stretched’.
I have recently been reading about the caBIG project sponsored by the US National Cancer Institute. The aim of the project is to enable the sharing of medical tools and data among hospitals and other medical health organisations through a sharable and interoperable infrastructure.
The really interesting part about the project is based on voluntary participation, so caBIG does not have any control of the participating systems. So how do they manage to build a single software platform supporting 40+ independent organisations?
The latest . . . Other Software BlogsTheme: Linen by The Theme Foundry
