First of all I'm sorry for adding another acronym to the development world...
... but unfortunately I cant get away with it this time, over the last 3 months I've been working as a HTML5 Architect for Foxtel here in Australia and have been tasked with the responsibility of setting some governance and architecture groundwork for our company as they move from a native app environment optimised STB (Ocode apps) to an open standard web based STB platform. This massive change has resulted in a completely new STB being built from the ground up which is geared to being a web friendly platform. This also means that all previous applications need to be ported to HTML5 and will have to run with the same performance on the new STB as previous native apps had.
The challenge I've facing is that the app development work which is largely being done by 3rd party vendors is taking place as our new STB platform is still being built. This is like a web developer trying to build a cutting edge HTML5 website, but all they have to test their work is an incomplete webkit based browser running on an incomplete computer. In this example, the web developer will probably be shocked when they test their work on the STB platform as they don't get the performance they think a cutting edge web platform should give them. They will then need to try and understand what the current platform capabilities are and what the future capabilities will be and architect their apps to evolve with the platform. And this is an incredibly hard way to work and requires some very smart app engineers.
As this is the situation in our company right now, I work with our app vendors to try and document the STBs platform evolution and how app developers need to plan and architect their apps. This involves me writing performance tests that test and validate the state of various HTML5 features, CSS3 Hardware Acceleration, Browser platform support (how HTTP requests are managed, SSL latency etc). I then make these benchmarks available to our app developers with some recommendations on how to architect an app that will work with current platform limitations and then as the platform evolves the app continues to function and "speed up".
So my job involves me researching low level elements on how browsers work (Specifically Webkit based platforms) and how HTML markup gets rendered on a browser gets interpreted and result in high performance UI. I look at things like how can we code HTML that will have a very lean DOM tree and what CSS3 applied to this DOM tree will benefit from forced hardware acceleration etc.
So, to document my findings I needed to create a category of coding rules and recommendations. Internally in my company I tag my findings in a architecture wiki under the label Low Performance Environment Coding (L-PEC).
And this is how the term Low Performance Environment Coding (L-PEC) was born.
Now, this kind of performance based coding is nothing new and companies like Google and Yahoo have been investigating and documenting their finding in this department for years now, as these rules also help speed up websites and web apps. But I could not find a term that captured this kind of performance based thinking for coding and wanted to do that with L-PEC.
Also L-PEC does not mean that you are coding for an environment that will always be "Low Performance" but can be thought of coding strategies that you put in place for environments where the performance is not as high as mainstream environments that are similar. So "Low" can mean "Lower" than mainstream performance of a similar mainstream platform.
So coding on a mainstream platform can be thought of as O-PEC which is Optimised Performance Environment Coding.
A good example would be a STB platform that uses a custom built webkit browser running on a OS like Linux which sits on top of some limited STB hardware configuration. This is a "web ready platform" that supports HTML5 too but it cant be compared to a mainstream web platform like Google Chrome running on a Macbook Pro for example. (The underlaying OS and Hardware is also important as they determine the performance of the UI - as everything you do on a HTML5 and CSS3 level flow down to hardware optimisation to be smooth and responsive). In this example coding for the STB environment will use L-PEC strategies and on the Chrome + MacBook environment you can get away with the more common coding principles that developers use for websites (we can call this O-PEC for comparison)
Over the next few months, I will add some blog posts that describe my work with L-PEC along with some guidelines and best practices.
To start off with, you can read my post on the Importance of Benchmarking Custom HTML5 Browser Platforms
No comments:
Post a Comment