Flash, after starting out its life as one of the bevy of animation plugins for browsers back in the day. has become synonymous with online video. It’s also got a rather terrible reputation for using an inordinate amount of system resources to accomplish this feat, something which hasn’t gone away even in the latest versions. Indeed even my media PC, which has a graphics card with accelerated video decoding, struggles with Flash, it’s unoptimized format monopolizing every skerrick of resources for itself. HTML5 sought to solve this problem by making video a part of the base HTML specification which, everyone had hoped, would see an end to proprietary plug-ins and the woes they brought with them. However the road to getting that standard widely adopted hasn’t been an easy one as YouTube’s 4 year road to making HTML5 the default shows.
Google had always been on the “let’s use an open standard” bandwagon when it came to HTML5 video which was at odds with other members of the HTML5 board who wanted to use something that, whilst being more ubiquitous, was a proprietary codec. This, unfortunately, led to a deadlock within the committee with none of them being able to agree on a default standard. Despite what YouTube’s move to HTML5 would indicate there is still no defined standard for which codec to use for HTML5 video, meaning that there’s no way to guarantee that a video you’ve encoded in one way will be viewable by HTML5 compliant browsers. Essentially it looks like a format war is about to begin where the wider world will decide the champion and the HTML5 committee will just have to play catch up.
YouTube has unsurprisingly decided to go for Google’s VP9 codec for their HTML5 videos, a standard which they fully control. Whilst they’ve had HTML5 video available for some time now as an option it never enjoyed the widespread support required in order for them to make it the default. It seems now they’ve got buy in from most of the major browser vendors in order to be able to make the switch so people running Safari 8, IE 11, Chrome and (beta) Firefox will be given the Flash free experience. This has the potential to set up VP9 as the de facto codec for HTML5 although I highly doubt it’ll be officially crowned anytime soon.
Google has also been hard at work ensuring that VP9 enjoys wide support across platforms as there are already several major chip producers whose System on a Chip (SoC) already supports the codec. Without that the mobile experience of VP9 encoded videos would likely be extremely poor, hindering adoption substantially.
Whilst a codec that’s almost entirely under the control of Google might not have been the ideal solution that the Open Source evangelists were hoping for (although it seems pretty open to me) it’s probably the best solution we were going to get. I have not heard of the other competing standards, apart from H.264, having such widespread support as Google’s VP9 does now. It’s likely that the next few years will see many people adopting a couple standards whilst the consumers duke it out in the next format war with the victor not clear until it’s been over for a couple years. For me though I’m glad it’s happened and hopefully soon we can do away with the system hog that Flash is.
The idea of cloud gaming is a seductive one especially for those of us who lived through the times when upgrading your computer every 12 months was a requirement if you didn’t want to be watching a slide show. Abstracting the hardware requirement away from the user and then letting them play on any device above a certain, extremely low threshold would appear to be the solution to the upgrade and availability issues of dedicated gaming platforms. I’ve long made the case that the end product is something of a niche market, one that I was never quite sure would be viable on a large scale. With the demise of OnLive I could very easily make my point based around that but you can never write off an industry on the failures of the first to markets (see Iridium Communications for proof of this).
Providing even a small cloud gaming service requires some rather massive investments in capital expenditure, especially with the hardware that’s currently available today. For OnLive this meant that only one of their servers could serve one of their users at a time which was terrible from a scalability point as they could never really service that many customers without bleeding money on infrastructure. For cloud gaming services of the future however they might be in luck as both NVIDIA and AMD are working on cloud GPUs that will enable them to get much higher densities than the current 1 to 1 ratio. There’ll still be an upper limit to that’s much lower than most cloud services (which typically serve thousands per server) but at the very least the scalability problem is now an engineering issue rather than a capital one.
The second major challenge that cloud gaming companies face how latency sensitive a good portion of the games market is. Whilst you can get down to very low latency numbers with strategically placed servers you’re still going to be adding a good chunk of input lag on top of any server latency which will be unacceptable for a lot of games. Sure there are titles where this won’t be an issue but cutting off a large section of the market (FPS, RTS, RPGs and any mix of them inbetween) further reduces the viability of any potential cloud gaming service.
In fact for many of the titles that could benefit from a cloud gaming service can already be ported to the web thanks to things like Unity or the use of OpenGL extensions in HTML5. Indeed many of the games that I could see being published on a cloud platform (casual MMORPGs, turn based strategy games, etc.) wouldn’t be much different if they were brought to the traditional web instead. Sure you lose some of the platform agnosticity because of this but you can arguably reach the same number of people using that as you could with a cloud platform.
User expectations are also set rather high for cloud services with many of them being flat fee, unlimited usage scenarios (think Pandora, NetFlix, etc). The current business models for cloud gaming didn’t gel well with this mindset as you were paying for the games you wanted to play (often cheaper than retail, sometimes not) for a limited period of time, akin to a long term rental. Whilst this works for some people most users will expect to be able to pay a flat fee in order to access a catalogue they can then use at their leisure and this has significant ramifications for how publishers and developers will license their games to cloud developers. It’s not an insurmountable problem (the music industry came around eventually so the games industry can’t be far behind) but it does introduce a market dynamic that cloud gaming services have not yet investigated.
With all these things being considered I find it hard to see how cloud gaming services can viable in the near term as whilst all the issues are solvable they all work against delivering something that can turn you a profit. Cloud GPUs, ever increasing quality of Internet connections and the desire by many to migrate completely to cloud based services does mean that there’s a trend towards cloud gaming services becoming viable in the future however the other, fundamental limitations could see those pressures rendered null and void. This is something I’m willing to be proven wrong on though as I’ve invested myself heavily in cloud principles and I know that its capable of great things. Whether cloudifying our gaming experience is one of them is something that I don’t believe is currently feasible however and I don’t see that changing for a while.
Google is one of the biggest proponents of an Internet that’s unencumbered by proprietary standards, patents and non-neutral traffic routes. That’s been a great boon to us Internet users as their advocacy on our behalf means that as long as they stay in business we’re likely to continue to have an Internet that stays true to those ideals. Of course like any company they’re not entirely perfect, at times attempting to forward their own agenda under the guise of openness, but overall their contribution to keeping the Internet free and open has been positive. It seems rather odd then that Google has an obsession with Adobe’s Flash product, to the point where I wonder if there’s something going on that I don’t know about.
Back in March last year Google announced that they were integrating the Flash plugin directly into their Chrome browser. This was at the height of the web standards war that was raging between Apple and Adobe so it was easy to construe Google’s support of Flash as them taking Adobe’s side in the matter. That notion was further reinforced by the fact that Google’s Android platform fully supported Flash as well. This level of support for a proprietary plug-in for a company that prides itself on being a big supporter of open standards seems rather hypocritical, but there are some reasons as to why they’re doing it.
Recently though it appears that Google’s support of Flash was actually leading up to a much more ambitious goal, transitioning the web from Flash to a HTML5 future:
Google is enabling developers who use the Adobe Flash Professional developer tool to convert their animations to HTML5 via an extension based on Google’s Swiffy conversion technology.
“One of our main aims for Swiffy is to let you continue to use Flash as a development environment, even when you’re developing animations for environments that don’t support Flash,” said Esteban de la Canal, Google software engineer, in a blog post. “To speed up the development process, we’ve built the Swiffy Extension for Flash Professional. The extension enables you to convert your animation to HTML5 with one click (or keyboard shortcut).”
Now it’s interesting that Google would go ahead and do something like this when Adobe had already made their play in this field with their Wallaby product. The big difference here is that Wallaby was specifically targeted at Flash Ads only and didn’t support many of the features that made Flash so versatile, like ActionScript. Swiffy on the other hand does support ActionScript and several other features that weren’t present in Wallaby. It would seem then that Google thinks they can do better than Adobe at their own game which they very well could especially when Adobe just recently announced that they weren’t working on mobile Flash any more.
Of course the transition from native Flash to Flash rendered through HTML5 doesn’t necessarily mean we’re looking at a future web that performs better. The main problem with Flash wasn’t so much the platform it was the developers on that platform. The Flash ads were the biggest culprit, often laden with gobs of unnecessary and bloated code that were the source of the performance problems people encountered. Transitioning such ads to HTML5 won’t make that code go away (there is a chance to optimize, but automated tools can only go so far) and the result will more than likely be just as bad as the original Flash it came from. It’s a step in the right direction yes, but it’s not going to be an all roses future like some would have you believe.
It’s quite interesting to see the kind of games that Google plays in order to make the web better for everyone. At times they may seem to be on the wrong side but it’s becoming clear that they’re playing the long game for a better web for everyone. It will be interesting to see how common Swiffy converted Flash files become and whether they’re still the performance hogs that their predecessors are but knowing Google they won’t let it lie until they’ve optimized it to the nth degree. Adobe’s reaction to Swiffy will be telling as well considering they’re now competing directly with Google on their home turf. The end result will be a better, more open Internet for us all something I think we can all agree is a good thing.
Adobe had also been quite stalwart in their support for Flash too, refusing to back down on their stance that they were “the way” to do rich content on the Internet. Word came recently however that they were stopping development on the mobile version of Flash:
Graphics software giant Adobe announced plans for layoffs yesterday ahead of a major restructuring. The company intends to cut approximately 750 members of its workforce and said that it would refocus its digital media business. It wasn’t immediately obvious how this streamlining effort would impact Adobe’s product line, but a report that was published late last night indicates that the company will gut its mobile Flash player strategy.
Adobe is reportedly going to stop developing new mobile ports of its Flash player browser plugin. Instead, the company’s mobile Flash development efforts will focus on AIR and tools for deploying Flash content as native applications. The move marks a significant change in direction for Adobe, which previously sought to deliver uniform support for Flash across desktop and mobile browsers.
Now the mobile version of Flash had always been something of a bastard child, originally featuring a much more cut down feature set than its fully fledged cousin. More recent versions brought them closer together but the experience was never quite as good especially with the lack of PC level grunt on mobile devices. Adobe’s mobile strategy now is focused on making Adobe AIR applications run natively on all major smart phone platforms, giving Flash developers a future when it comes to building mobile applications. It’s an interesting gamble, one that signals a fundamental shift in the way Adobe views the web.
Arguably the writing has been on the wall for this decision for quite some time. Back at the start of this year Adobe released Wallaby, a framework that allows advertisement developers the capability to convert Flash ads into HTML5. Indeed even back then I said that Wallaby was the first signal that Adobe thought HTML5 was the way of the future and were going to start transitioning towards it as their platform of the future. I made the point then that whilst Flash might eventually disappear Adobe wouldn’t as they have a history for developing some of the best tools for non-technical users to create content for the web. Indeed there are already prototypes of such tools already available so it’s clear that Adobe is looking towards a HTML5 future.
The one place that Flash still dominates, without any clear competitors, is in online video. Their share of the market is somewhere around 75% (that’s from back in February so I’d hazard a guess that its lower now) with the decline being driven from mobile devices that lack support for Flash video. HTML5’s alternative is unfortunately still up in the air as the standards body struggles to find an implementation that can be open, unencumbered by patents and yet still be able to support things like Digital Rights Management. It’s this lack of standardization that will see Flash around for a good while yet as until there’s an agreed upon standard that meets all those criteria Flash will remain as the default choice for online video.
So it looks like the war that I initially believed that Adobe would win has instead seen Adobe pursuing a HTML5 future. Its probably for the best as they will then be providing some of the best tools in the market whilst still supporting open standards, something that’s to the benefit of all users of the Internet. Hopefully that will also mean better performing web sites as well as Flash had a nasty reputation for bringing even some of the most powerful PCs to their knees with poorly coded Flash ads. The next few years will be crucial to Adobe’s long term prospects but I’m sure they have the ability to make it through to the other end.
You’d think that since I invested so heavily in Silverlight when I was developing Lobaco that I would’ve been more outraged at the prospect of Microsoft killing off Silverlight as a product. Long time readers will know that I’m anything but worried about Silverlight going away, especially considering that the release of the WinRT framework takes all those skills I learnt during that time and transitions them into the next generation of Windows platforms. In fact I’d say investing in Silverlight was one of the best decisions at the time as not only did I learn XAML (which powers WPF and WinRT applications) but I also did extensive web programming, something I had barely touched before.
Rumours started circulating recently saying that Microsoft had no plans to develop another version of the Silverlight plugin past the soon to be released version 5. This hasn’t been confirmed or denied by Microsoft yet but there are several articles citing sources familiar with the matter saying that the rumour is true and Silverlight will recieve no attention past this final iteration. This has of course spurred further outrage at Microsoft for killing off technologies that developers have heavily invested in and whilst in the past I’ve been sympathetic to them this time around I don’t believe they have a leg to stand on.
All of Microsoft’s platforms are so heavily intertwined with each other that it’s really hard to be just a Silverlight/WPF/ASP.NET/MFC developer without a lot of crossover into other technologies. Hell apart from the rudimentary stuff I learnt whilst in university I was able to self learn all of those technologies in the space of a week or two without many hassles. Compare that with my month long struggle to learn basic Objective-C (which took me a good couple months afterwards to get proficient in) and you can see why I think that any developer whining about Silverlight going away is being incredibly short sighted or just straight up lazy.
In the greater world of IT you’re doomed to fade into irrelevance if you don’t keep pace with the latest technologies and developers are no exception to this. Whilst I can understand the frustration in losing the platform you may have patronized for the past 4 years I can’t sympathize with an unwillingness to adapt to a changing market. The Windows platform is by far one of the most developer friendly and the skills you learn in any Microsoft technology will flow onto other Microsoft products, especially if you’re proficient in any C based language. So whilst Microsoft might not see a future with Silverlight that doesn’t mean the developers are left high and dry, in fact they’re probably in the best position to innovate out of this situation.
It’s only been just over a week since Microsoft demoed their latest iteration of the Windows platform but in that short amount of time it’s already managed to stir up quite a bit of discussion from friends and foes alike. The foes were quick to call out the new OS’s tablet envy, conveniently forgetting Microsoft’s rhetoric that the next version of Windows after 7 was going to have a much more web centric focus, with the possibility of it being entirely cloud based. More interesting however is the discussion arising from long term developers on the Microsoft platform, and it’s not the kind of adulation and praise you’d normally expect.
Rampant speculation soon followed and wasn’t helped by the fact that Microsoft has asked everyone to remain calm until their BUILD developer conference in September. It’s not the first time this sort of thing has happened either, a similar level of hubbub was roused when Microsoft was coy about Silverlight’s future when talking about Internet Explorer 9 and it’s dedication to web standards. They soon came out saying that they still saw a future in Silverlight, especially for the Windows Phone 7 platform, but many of them were left unconvinced. It’s then quite likely that this second round of doubt that Microsoft has cast over their third party developer’s futures was the straw that broke the camel’s back and all the blame is being leveled squarely at Microsoft.
For what it’s worth I feel their concerns are valid if the reaction to them is somewhat overblown. Microsoft has a long history of eating its own dog food and many of their client facing applications are built upon the technologies that so many are worried are going to disappear in the near future. The best example of this is their Windows Azure management console which is built entirely on Silverlight. Couple that with the fact that Microsoft has many partners with a very heavy investment in the platform and I find it hard to jump on the “Silverlight is dead” bandwagon, but that doesn’t necessarily mean Microsoft is committed to bringing Silverlight into the Windows 8 tablet world.
Sure it would be great to be able to create Silverlight applications on the new Windows 8 tile system and Microsoft would be leveraging off a lot of preexisting talent to help drive adoption of the platform. However it would also hinder Microsoft’s adoption of web standards, as many developers would favor using proprietary Microsoft technologies instead of attempting to reskill. They’d then be the slave of two masters: on the one hand the Silverlight crowd demanding ever more features and tools that are constrained to that platform and on the other the web standards crowd that has been Microsoft’s bug bear ever since alternative browsers started to gain real market traction. It’s not like Microsoft doesn’t have the resources to deal with this though, but I can understand their motivations should they want to eschew Silverlight in favour of a more standard environment.
You know I was pretty hyped about getting a WP7 handset after having a short play with one in the store. The slick interface and overall usability of it was so high that I thought it was worth a shot and I had really nothing to lose since my work would be paying for it. The NoDo update was on the horizon however so I decided that I’d hold back until it made its way into production so that I wouldn’t have to deal with the same frustrations that day 0 customers had. Most notably this would be the inclusion of copy and paste, but there were also a few other fixes that I thought would be good to have and worth the wait.
The problem is however that unlike regular Windows patching there’s a gate keeper between me and Microsoft’s patches for their new mobile platform. You see the patches have to pass muster with the carriers first before they can be distributed to the handsets although Microsoft had said in the past that they were working with them to make the process as quick as possible. Unfortunately for us Australian customers looking for a WP7 handset you really only have one carrier to go with: Telstra. Now this wouldn’t be so much of a bad option normally since Telstra had to start playing straight after their retail and wholesale arms were broken apart but it seems that they’re not up to the job of testing WP7 updates:
Universal availability of the copy-and-paste update to Windows Phone 7, codenamed NoDo, is almost here, according to Microsoft’s latest schedule update. The final unpatched phone available in the US market, the HTC Surround sold by AT&T should start to receive its updates within the next ten business days. The network’s other two handsets, the Samsung Focus and LG Quantum, have been receiving updates since last week.
European carrier Deutsche Telekom (which includes T-Mobile UK) has at last finished its testing, as has Australian carrier Optus. Updates from phones on these networks should also appear within the next ten business days or so. This leaves only two carriers still delaying the updates due to “testing”: Telefonica, in Spain, and Telstra, in Australia.
This was the one area where I was expecting Microsoft to shine through since their bread and butter products have depended so heavily on their patch services for well over a decade. Sure the vast majority of the blame should be leveled at the carriers since they’re the ones causing the delays, but Microsoft isn’t innocent of incurring delays either. Of course the original iPhone and Android handsets weren’t immune to problems like this either but I had expected Microsoft’s late coming to the party to be at least coupled with a strong patch and feature release scheme so they could play catch up quickly.
It might seem like an extraordinarily small gripe considering the rest of the platform looks solid but when minor feature releases like this take so long to get through the pipeline it makes me wonder just how long I’ll have to wait for the next update, codenamed Mango, to drop. Amongst other things Mango will bring full HTML5 support to WP7 something which it currently lacks in its browser. Whilst the IE9 implementation of HTML5 does leave some things to be desired (my newest app idea uses HTML5 bits, and IE9 mangles it) it is a lot better than not having it at all, especially when so many mobile versions of sites rely on HTML5 functionality. With speculation now brewing that this update might slip to next year that’s starting to put WP7 at a serious disadvantage, unless some enterprising browser developer ports to WP7 ala Opera et al.
I’m still planning to nab myself one of these handsets if only for the few times I’ll want to try my hand at developing an application for it but with such delays piling up on each other I could very well see myself changing to Android or back to iOS until they’re finished playing the catch up game. I’m sure as time goes on they’ll develop a much better relationship with the carriers and hopefully they’ll be able to leverage that to remove some of the roadblocks to getting patches and updates out to us consumers. Until then however WP7 users are going to be at the whim of the carriers, even more so than they are normally.
Adobe and Apple haven’t been the best of friends for a while now. Whilst many of their products are still considered some of the most top of the line applications available on the OS X platform Apple couldn’t be more hostile to their most popular product: Flash. Now this isn’t without good reason as Flash has a terrible tendency to be abused by sloppy developers (most of the time ad networks) who can even bring a full blown desktop PC to its knees. Keeping Flash out of their handhelds meant fewer headaches for them and forced the hand of many companies to rethink their use of Flash, lest they draw the ire of the iOS browsing crowd.
Whilst there was a good few months of to and fro between these two companies last year it all subsided once Apple capitulated to the developer community that raised concerns over Apple’s wide reaching policy on cross platform libraries. This seemingly opened up the door that Apple had shut in Adobe’s face, enabling them to create a product that could convert Flash files into a more iOS friendly format. A couple days ago they announced the first iteration of the product, called Wallaby:
Welcome to the Wallaby Technology Preview. Wallaby is an application to convert Adobe Flash Professional CS5 files (.FLA) to HTML5. Wallaby has a very simple UI which accepts as input a FLA file and exports HTML and support files to a user-selected folder. There is also an option to launch the default application assigned for the .html extension.
The announcement has, of course, caused quite a stir in the tech community. Most of them focus on the fact that Wallaby was designed with only one purpose in mind: to get Flash banner ads working on iOS devices. As such Wallaby is pretty limited in the functionality it provides, being unable to convert things like ActionScript which enable things like Flash based games. Of course this also raises the issue that Flash is most often abused by advertising agencies with poorly coded banner ads being one of the main culprits. Whether or not badly coded ads in Flash translate into bad (or worse) ads in HTML5 remains to be seen, but I can’t see how they could get any better.
Realistically the issues that many people associated with Flash aren’t really caused by it. More it is those who use the platform that are to blame for the troubles that many people encounter with it. This is why I didn’t understand Apple’s position on Flash in the first place. Sure there are many banner ads out there that can make your web experience a browsing hell but banning one technology simply drives those same people to look for other platforms, it won’t magically make them better developers overnight. Wallaby is a great example of this as those same people that created poor performing Flash ads can now do the same in HTML5. In the end Apple is merely delaying the time in which it takes for the same problems that plagued Flash to come to their iOS platform. Google I feel has is on the right track to solving this problem, tightly integrating Flash into their products so they can tune it properly.
It does show that Adobe doesn’t believe the future is still with their Flash platform and the gears are in motion to transition to the new world of HTML5. There’s a reason why Flash has been such an integral part of the web for so long and it’s simply because Flash gave the best tools for non-technical users to create rich content for the web. Whilst they’ve come rather late to the mobile boat they are one of the few companies that has the momentum and devoted user base to make the switch successfully. I’m sure many people will see this as them “capitulating” to Apple’s demands but in reality its anything but and I’m sure they’ll eventually dominate the HTML5 space just as they’ve done in the past with Flash.
This lack of standard implementation across the browser market is just another form of a format war. Whilst they might all appear to be collaborating on the future of the web realistically they’re all fighting for their version of the web to become the standard. No longer is a company able to release a product like IE6 onto the market that plays fast and loose with the standards in favour of delivering more functionality as that will more than likely end up being ignored by the web development community. Now the war is mostly being raged through standards committees, but that doesn’t mean the same old strong arming tactics aren’t being used.
Last week Google announced that it would no longer be supporting the H.264 codec for the HTML5 <video> tag. The post triggered wide spread discussion about the future of the HTML5 standard and Google felt the need to clarify its position:
Why is Google supporting WebM for the HTML tag?
This week’s announcement was solely related to the HTML tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the tag will be forced to support multiple formats.
On the surface it would appear that Google is attempting to use its share of the browser market to put some pressure on the HTML5 standards committee to make WebM or Theora the default codec for <video> tag. For the most part that’s true and should they get their way Google will have control over yet another aspect of the web (in contrast to now when they’re just the dominating player thanks to YouTube). However whilst such a move might at first appear to only benefit Google, Mozilla and Opera I believe that a push away from H.264 is beneficial for everyone on the web, except for Microsoft and Apple.
You see whilst there’s no official agreement on what the default codec should be for HTML5 there are in fact 2 groups within the standards committee that agree wholeheartedly on which one should be the standard. Google, Mozilla and Opera all believe that WebM or Ogg Theora (or both!) should be the default standard whilst Apple and Microsoft both want H.264. The reason behind that is quite obvious when you look at the patent body responsible for licensing the H.264 technology, the MPEG-LA. Both Apple and Microsoft are have patents in the MPEG-LA patent pool meaning they have a vested interest in making it the default standard. This is the main reason why having H.264 as the default is bad Internet users and web standards as it would force anyone who develops HTML5 products using video to license the H.264 codec, something which could be quite devastating to early stage start ups. Additionally it encumbers what should be a completely open and free standard with licensing requirements, something that hasn’t been present in any web standard to date.
Whilst the decision doesn’ affect me directly, no matter which way it goes, I can’t support something that has the potential to stifle innovation like a licensing requirement does. Google throwing its weight behind its own and other open codecs has highlighted the issue succinctly and hopefully this will lead to more productive discussion around which (if any) codec will become the standard for HTML5. We’re still a long way from having a fully formalised version of HTMl5 that anyone can implement but it’s good to see some movement on this front, even if it’s just one web giant poking the trolls.
I really can be my own worst enemy sometimes. It’s been almost a month since I got back from the USA and despite the best of intentions I haven’t really done that much work on Lobaco apart from a little work on the API and web UI. Whilst I was pretty sure I wasn’t going to hit the code hard immediately after touching back down in Australia I still thought that after maybe a week or two of lazing about the coding bug which had firmly bitten me before I left would take a hold once again, pushing me to build on the momentum I had set up. Sadly it wasn’t to be and instead I just resided myself to feeling guilty about what I should’ve been doing and pulling the meter tall weeds that had grown in our front yard.
Partly to blame is that sense of perspective I get whenever I take time away from a project to work on something else or to just have a break. Usually the first thing that pops into my head is “why the hell should I bother” and I’ll spend a good chunk of time focusing on the negative aspects of whatever I’m doing. After a while though I’ll just try to do a feel small things, a few quick wins to get me back into the mindset of getting things done. After that it’s usually pretty easy going (this usually takes about 2 weeks) until I hit a wall again or I feel like getting my weekends back for a while so I can relax and get my head back together. The last few iterations of this cycle are what lead to the 3 major revisions of what is now Lobaco.
Then along came Sencha.
This client was just an elaborate way of procrastinating.
Now whilst the client looked decent and didn’t take too much to set up it didn’t look anywhere near as good as my native app nor could it hold a candle to its performance. Sure my hack job probably ensured that the performance wasn’t as good as it could be but in comparison to the native client hack job I did it was pretty stunning. After coming to that realisation I booted up my MacBook to start getting acquainted with Xcode again and spent last weekend coding up some performance improvements¹ for it which I had put off before I left for the USA. I’m sure this won’t stop me from looking at going down that path in the future but I can at least rest easier now that I’m feeling the urge to program once again.
It’s been a weird learning experience for me since I’m usually pretty good at knowing when I’m procrastinating. Usually I have a good reason for it (like having 1 bit of work to do and not doing it since it’s not due for months) but this is the first time I caught myself doing something I thought was useful when really I was just making excuses for doing the work I knew needed to be done. With a good week of holidays coming up over the Christmas/New Year period this realisation couldn’t have come at a better time and I’m looking forward to making the most of my time off with the hope that the momentum will carry me on into the new year.
¹I’m going to do a big post about this hopefully tomorrow. I hit some really, really esoteric problems getting everything to work but I have and the results are, to put it bluntly, bloody amazing.