João Magalhães

Every once in a while there comes a moment in a startup's life that you just know you'll look back on as defining. This is one such moment. Today we announce Frontdoor (http://frontdoorhq.com), our online Point-of-Sale service.

As incredible as it might sound, setting up a Point-of-Sale system today still means a huge investment. First it's the expensive point-of-sale equipment out there, and the overpriced software from before the Internet. Then, you have to add the maintenance costs for that quirky hardware, as well as the (well) paid updates for the software to fix bugs and keep up with legal changes.

Frontdoor lets you sell anywhere from any device, be it PC, Mac, iPhone, iPad or Android. You can start using Frontdoor with just your pocket change, and only pay for what you use. Period. No surprise updates to pay for. No hefty maintenance costs for weird hardware you don't need.

Frontdoor is about user experience, that's why we went to so much trouble to craft each user interface you'll see in Frontdoor. Anyone can build software that does the job, but to make it work in ways that delight you and make your life simpler... that's just beautiful. That's what we did with Frontdoor.

Frontdoor is also about your data. We're going to set the data free from the application silos. You'll be able to use OAuth to securely authorize access to your data, which can then be combined with other information sources. Open up to new, unexpected uses and insights from your data. Frontdoor is about bringing the power of advanced analytics to small and medium business. Business intelligence is not just for the big boys anymore.

Beta starts today. Expect public availability this Spring. So if you know anyone running a store these days, you owe it to them to at least mention the new kid in town.

We're proud to announce that Colony Framework now supports Modular Configuration.

What this means is that you can now load and unload configurations, in runtime, in the same you way could already load and unload Colony plugins. Colony configurations do to data, what Colony plugins already did to logic: they remove the need for restarts, promote modularity and make distribution transparent.

For instance, you could fire up a Colony instance, throw in a CPX file containing the HTTP server plugin and then throw in a CCX file (Colony Configuration file) which would set your HTTP server to act as a proxy. You could then pop in a new CCX file which would completely reconfigure you server to act as a simple file system navigator. All of this without ever having to stop your instance or even reload your HTTP server plugin. Pretty cool, huh?

For a long time now, the configuration facilities in Colony were seriously underdeveloped compared to the other parts of the technology. We had been wanting to fix this almost straight after the configuration infrastructure was set in place.

Until now, like with every other system in the world, changing the core configuration options of any component would require restarting the instance. This can be fine for a lot of people, but when you support loading and unloading components in runtime, having to reload because of a settings change always seemed a bit awkward.

Modular configuration also comes with a high content of distributed AWESOME. Think about Colony Distributed, and how easy it now will be to deploy work units to remote plugins. We could already ship plugins to distributed instances, now we can ship them with precise indications on how the host instance should use the plugins: the configuration file. Try that on a regular distribution framework!

So the alpha is out.

Everybody we were showing Colony to lately was saying we had to release it because people needed to know about that kind of awesomeness. But we are people of work, not of show... So we kept on working, ironing out the wrinkles and such.

We even started working on documentation and, again, people who looked at it were asking why we didn't have it online. So things added up, we polished a bit more, and felt it was as good a time as any to put something out there.

We didn't pimp it much, just some places where like-minded individuals hang out. We got some mixed feedback between people amazed at the amount of work we had put into this thing, while staying under the radar, and others having a hard time understanding what it was good for. But, most interestingly, we found some people that actually felt the kind of pains Colony was intended to ease. And they wanted to know more.

We got several requests for a forum for users to exchange experiences using the technology, and we got a tip about creating the #colonyframework IRC channel to help connect even better with the audience.

And so here we are. We have something that you can already start calling documentation to. You can also check out our daily builds. To get an insider perspective on the project consider joining the Colony Users mailing list.

Let me know what you think in the comments.

Ok, the prank has gone for too long... the fact is that... Colony doesn't exist, it was all a big hoax. Ahah got ya! It does exist, but with years passed and no release in sight, people have started to wonder, and rightly so, what the frack happened to Colony. Questions typically involve one or more of the following frustrations:

• What the hell is Colony?
• Why do I keep hearing about Colony and still can't really understand what it is or where to get it?
• Why is www.getcolony.com down?

Are we there yet?

Well, I can tell you that during this long timespan, few were the days where there wasn't a commit to our repository, directly or indirectly related with Colony. So, in fact, Colony is better than ever, and 99% of the work we do today, is either on: directly improving Colony (through the development of new plugins, bug fixes, and miscellaneous code improvements), creating products with Colony, or doing consulting work using Colony. In fact, we can't stop Colony from getting better with each passing day, even if we tried.

So why isn't it out yet you may ask? Well... you can say it's out, in fact, from day one, http://svn.hive.pt has been open to the public and filled with GPL goodness. The bottleneck has always been in making Colony so f-ing simple, that using it for the first time is an enjoyable straightforward experience. That means quality documentation, useful examples, easy installation and transparent updates, etc.. and we ain't there yet... but we're moving in the right direction.

Where are we going?

Documentation has improved quite a lot, both by extending their subject coverage, and by making them more actionable and straight to the point. Serious work as also been done in creating tasty multimedia content to make the experience of diving into Colony more enjoyable. This content is still in the works, but just last month, we leaked one of a series of Colony comics we have created:

However, the biggest milestone has been getting our Colony Build Automation infrastructure (which is a set of Colony plugins, as everything else) up and running. Nowadays, we have a server running a Colony instance that is constantly fetching code from our repository, making sure it passes our validations, and packaging it into various formats. As an added bonus, everytime someone screws up the build, that person is greeted with a nice unforgiving e-mail:

With this automated lifecycle in place, I can now access the Colony instance where the build automation plugins are running and building Colony (embrace the paradox :P), and through the Colony Web Server (which is also just a bunch of Colony plugins), and the HTTP File Handler Plugin, which extends the Colony Web Server and allows me to browse the build server's filesystem with my web browser, I can always access the latest build, in various formats, including fancy "deb" files. Meaning that currently, in Ubuntu for example, I can just add this web server as a source and am able to use its package manager to easily install Colony.

This infrastructure, will in the future, keep delivering you fresh Colony builds, regardless of what operating system you want to deploy Colony on.

When will we finish?

I just finished reading one of ultramarathoner Dean Karnazes' books (I just got a Kindle, and its kickass paper-like display has gotten me addicted to reading again!), where he details the gruesome pain he endured in his insane runs, like running 320km non-stop without sleeping. Heat strokes, muscle damage and severe dehydration aside, 12833 commits and 354.488 lines of code (639.286 with comments) later, getting Colony ready already seems like an ultramarathon, which fortunately seems to be getting nearer and nearer to the finish line. As Dean says, no point in thinking of how long to run, just put one foot in front of the other. This to say, I can't give you a release date, it's ready when it's ready, but it will be worth it!

This blog has been gathering dust for quite a long time, but fear not, for these are good news... they may not be good news for you blog readers that haven't had a mind-blowing article to read in a long time (oh, the unhealthy ego :P), but they are great news for us, because we have been very busy, which made the blog drop to a lower priority for a while. Busy with what you may ask... I can't tell you... not yet... but I can let you in on some miscellaneous stuff that's been happening at Hive.

Luigi, Mario, Berlusconi, Panzerini!

In no particular order of importance, let's start with Panzerini. No, it's not a sandwich, it's a multiplayer artificial intelligence robot battle game. Where's the money in that, you may ask. It ain't in our pockets that's for sure, but that doesn't mean it wasn't worth it.

Long story short, we went on a roadtrip to Lisbon to participate in Sapo Codebits 2010 in the 48 hour programming competition. We needed a nifty Colony demo to use when we officially launch Colony, but we never really had the time to do it, so this seemed like the best opportunity to make a sprint and create one.

The idea was simple. Create an online arena where people can drop robots developed by themselves and watch them fight against other users' robots. The whole project was to be developed in Colony from the ground up, robots would be Colony plugins that could be dragged and dropped into the arena, which would be a simple HTML5 page (no Flash, no Canvas).

With Colony in hand we went on a road trip to Lisbon to participate in the competition, and arrived at the spot, only to find that there were no places to sit down or electrical outlets to power our laptops. This was a great opportunity to honour what sometimes appears to be a Portuguese tradition, and just blame the organization and quit the competition... but we were on a mission! We managed to get access to a small office, inside a garage, got an unprotected wireless network from some neighbour, and started coding.

Fourty-eight hours later, with very little sleep, and after eating a lot of chicken (it was near, it was cheap, and it was the only available food in that restaurant at that time), we had a functional version of Panzerini.

It ended up quite good for the time we invested in it, so we went quite confident for the presentation, only to land on our faces in the end. Turns out the competition was more of a stand-up comedy show, which was a great lesson for us, to remember to always understand the audience first. At the end of the day, every successful interaction is an exchange of value, be it in whatever shape of form. Even if you have something great to offer, it's worthless if it's not valuable to the receiver, and value may take the shape of something as simple as making that person laugh, as was the case of some awarded projects. Regardless, the first three places or so, went to great projects that truly deserved it, and in the end we walked out with a Colony demo in the bag ;).

The Hive Crisis Center

We had a big LCD television stuck in storage for over two years now. We used it in an exposition a long time ago, and never touched it again. After trying to drill holes in the wall, having to change drill bits, making a mess of the whole office, having to run to the electronics store a couple of times, and having to struggle with the TV provider's front-line support to make them come and replace a Set Top Box that was stalled for two years and couldn't update itself because the firmware was too old, we managed to hang the television in one of our walls and turn it into a Corporate TV, with our very own home-brewed company dashboard.

It is now being used to show statistics about the company, like number of commits, upcoming calendar events, ticket status changes, alert messages for when something bad happens, like one of our servers to stop responding, or simply broadcasting a video for everyone to see.

Just imagine how cool it is to have a live dashboard with your company's heartbeat, giving you an applause sound as it tells you are currently the top commiter of the day, or that a bug as just been closed, or to hear the sound of a siren as it alerts you that a server is down. At the very least, it makes you feel like you are working at the Pentagon.

For now I can't tell you much more about what's going on, mainly because I also have get some work done today... I'm sorry... but in case you are disappointed with the few revelations I have done in this post, here's some cuteness overload as compensation:

P.S: This is a photo of Luis Martinho's dog ;).

Pack your bags folks! The world is about to end, the Mayans were off by a year or so, and I don't think even them could foresee our end as "death by IP address shortage" at the time. Why the media hasn't picked up on this one as the soon to be apocalypse yet, is beyond me, but by the end of next year we will be running out of IP addresses to assign to stuff, which is kind of an inconvenience, since following the current trend, even my boxer shorts will be pingable any time soon.

If we do live to tell the tale, and IPv6 has indeed saved us all, we will have a gazillion of IP addresses to use, apparently more than enough for all the sensing and computing devices we are decorating our planet with. If you think we are in the era of information overload, you ain't seen nothin' yet. We are about to be sh*tstormed with a tidal wave of information the likes of the world as never seen. Twitter has done a marvelous job of flooding our beloved Internets with arguably valuable data, by dumping what's on everyone's mind, however irrelevant, onto the Web. It won't be long before everything is "tweeting" every single piece of relevant and/or irrelevant information to the Internet, from GPS devices, to cell phones, to toasters.

Web 3.0: Now with 532452% more Data (and peanuts, hopefully...)

We will have a lot of information on our hands and very little to do with it, or what we will able to do with it, will be with great effort. A paradigm shift is in order, and such is the promise of the Semantic Web, that of switching the Internet from a worldwide file server to a global database.

The problem with the Web nowadays, is that it's fine and dandy for retrieving information, but kind of sucks for retrieving knowledge. For example, I like to travel, but the planning and booking I have to do beforehand is always a huge pain (am I not an ungrateful bastard?). What I want is simple: I want to go to one or more locations, in a certain time range, with the cheapest transportation available with the shortest trip time, be accomodated in easily accessible spots, preferably near the center, with best rating for the lowest price. I know what I want, but here's what happens when I type that in Google:

What the hell am I supposed to do with these results? Read them, extract the information, cross reference it, apply my constraints mentally and hope to find a match? No friggin' way, I'm too lazy... especially when I know that this is a feasible query, that it's possible to compute my query and get a decent answer, if only data was described in a standard way. I was a Semantic Web atheist, as I always saw the concept as something invented by pot-smoking hippies from academia to keep their paper flow steady... but in May 2009, Wolfram|Alpha opened my eyes.

Couldn't See the Forest for the Trees...

Wolfram|Alpha is scaringly awesome, you can give it the most insane questions, and it will give you a decent answer most of the time. Like, hey, I wonder where the International Space Station is right now:

And the list of cool questions you can ask it just goes on and on:

• Big Mac + Coke
• What is the average speed of an unladen swallow?
• What is the weather for next sunday?
• How much would would a woodchuck chuck if a woodchuck could chuck wood?
• What was the population of Portugal in 1984?

Wolfram|Alpha accomplishes this by working on structured data sources, instead of flat pages of unstructured data. This way, it knows what the data is, what it means and what it's associated with, and can therefore cross different data sources to extract new knowledge. Imagine if a similar knowledge engine had access to every single piece of data on the Internet in a structured way. A lot of incredible things would be possible, and one of them, would be to get an answer to my god damn query. What if travel booking was as easy as asking a question like that and clicking the pay button? I stress, that this is more than possible, so there is no reason not to dream that high (or that low...).

Heigh-ho, Heigh-ho, Semantify the Web we Go, Tralalalala...

The question is, how to go about making the Web semantic. That's where the going gets tough... In order to annotate data with semantics, W3C proposes its Resource Description Framework (RDF) family of specifications. Basically you're supposed to use these to annotate your data so that it can be understood by computers. For example, if you had a travel agency website, annotating it in such a way, would bring my holy grail backpacking online service one step closer to reality, since its travel plans could be used as a data source. The huge problem is that producing this data is humongously painful, and there's little to gain from it from the point of view of who's annotating the data. Therefore, from my point of view, this bottom-up approach to the Semantic Web is just a fairy tale acid trip.

The solution is cleary top-down, this data has to be at least initially produced by machines, and later fine-tuned by humans. This is the approach used by Freebase, an open database of structured information, which was recently acquired by Google. Freebase initially harvested its data from unstructured data sources such as Wikipedia, and now relies on crowdsourcing for collaborative fine-tuning.

So what's my point? I honestly don't know... just want to shout out to my homies that the Semantic Web is "for reals", it's not a pipe dream, and it will come about faster than you expect, just still not sure in what shape or form, but definitely the one that offers the path of least resistance. Which I may speculate to be in the form of a killer Semantic Web Application that leaves huge amounts of open structured data in its trail, like a semantic "googlish" search engine that is incredible enough to break the muscle memory imprinted habit of using Google after every question mark that pops into one's head.

Today is Saint John's day here in Porto, where Hive Solutions is headquartered.

Which means that tonight, thousands of people will hit the streets, in what is probably Europe's liveliest street festival, to bang each other's heads with plastic hammers, eat sardines, and watch fireworks. And I will too, just after I finish this post :). So, on a completely unrelated note, I am going to quickly rant on Ruby on Rails.

To Rail or not to Rail

Rails rocks, or so they say. Until now, I knew very little about Ruby on Rails. I knew what it was capable of, what the framework was meant for, who designed it, its as well as their history, their success, and all the associated hype that roams the web (and also knew a little bit of Ruby). Basically, my paradigm was: "For the scenarios it was built for, Rails rocks.".

But now that I have actually implemented some new features for another company's product, which was built on Rails, and had to learn it for real, some of the hype has dissipated, and I was left with reality.

1 - Ruby is just too awesome

Ruby is a very liberal language, in the sense that it has some nice features, like everything being an object, which allow people to create delicious syntax sugar at first glance, and cryptic mumbo-jumbo for whoever has to understand the code afterwards. For example, here's a creative way of creating a loop in Ruby:

5.times { print "This is one of the many ways you can loop five times." }

Cool as it may seem (and it is), if possible, I personally don't like having more than one way to do a thing, since I feel that it makes it just too easy for a team to create a messy codebase, in case they haven't agreed on strict code standards beforehand.

2 - Rails is just too damn helpful

Rails shortcuts a lot. In its quest for DRYness (Don't Repeat Yourself 'ness), it provides a lot of default behaviour (example: default template routing) which in the beginning provides a developer like myself with a pleasantly paranoid frustration of having things work, but not understanding why, which may be interesting when starting from scratch, but completely sucks when you're building stuff on top of a codebase that isn't yours and you're still not done grasping it completely, as you have Rails' smoke and mirrors making that job harder (this is obviously a very personal rant :P).

3 - Rails is stateless

This is one of the reasons I wouldn't trust Rails if I was going to build something big. The need for state, would pop in at one time or another. Just on the top of my head, if I wanted to have a scheduling task, I am not seeing my way out of having to run a cronjob, and getting out of the development stack truly sucks for many reasons, one of them having to do with portability.

4 - Rails is not modular

This is the ultimate reason why I won't do anything big in Rails, I am addicted to modularity, so I would use Colony instead. Taking all the advantages that runtime modularity brings out of the equation, just the paradigm that Colony would impose on my development, by forcing me to separate my application's concerns gracefully, would pay off so damn much in the long run, that I wouldn't consider any other option.

So what?

My opinion may change, but currently, if I was going to build a small project with very specific requirements, very fast, I would probably use Rails, and if I was doing something big, I would use Colony. Anyway, I don't see a reason why Colony won't be able to beat Rails in this regard as well in the nearby future :).

Notice the catchy title? It's called copywriting, and I am not very good at it, but I'm trying. In the last posts I was pretty thorough with my writing, but this time I will try to keep it short and sweet, so you still have time to watch Star Wars Kid and Chocolate Rain on YouTube like the rest of us. So here's a pre-washed, pre-cooked, pre-heated, pre-screened, pre-approved, pre-packaged, post-dated, freeze-dried, double-wrapped, vacuum-packed list of the ten things you must know about Microformats:

1 - You Can Talk to Machines With Microformats

Microformats are used to annotate semantics, so that humans, and especially machines, can parse a page's content and know what it's all about. With regular markup, it's possible to interpret content with natural language processing and other artificial intelligence techniques, or simple hardcoded data scraping, but these techniques obviously fall short, as there is no better way to extract semantics than to have them already specified along with the content in the first place, and this is where Microformats come in.

2 - Microformats are Damn Easy

Microformats are not based on some weird esoteric language, they use pre-existing syntax to specify semantic information, with most formats being represented in HTML by using "class", "id", "title", "rel" and "rev" attributes. So in a way, if you know HTML, you already know everything you need to start using Microformats.

3 - HTML5 is a Microformat Killer (slight exageration)

HTML5 takes semantics into account, as it has added a lot of tags that are meant to be used instead of their generic "div" predecessors (example: "header", "section", "article", "footer"). For example, in the past while creating a blog post entry, one would probably use the "div" tag to wrap the post's contents, whilst with HTML5, the kosher thing to do would be to use the "article" tag instead, giving parsers a greater insight as to the enclosed contents.

As the HTML5 specification matures, it may integrate further markup that may turn some Microformats obsolete. However, Microformats should be here to stay, as no organization can be as fast as a single individual at writing a specification, and no one can stop you from making your own Microformat addressing a new semantic description need you have identified.

4 - Microformats are in the Wild

There are already loads of Microformats available out there. I'm going to show you examples of two stable and widely used Microformats, but first, switch to Firefox, and install the Operator extension. This extension will parse pages for a multitude of Microformats, extract their enclosed contents and provide you with operations you can perform on them. It will give you a superficial example on the benefits of annotating data with semantics.

Now that you're running Firefox with Operator, here are some Microformat examples:

hCard

This one is used to represent contact information. Below you can see my business card, annotated with the hCard Microformat:

If you check out the Operator bar, you will notice that it has detected the above contact information. This was a pretty straightforward feat, as it may look like regular text, but if you look under the hood:

<div class="vcard">
<span class="fn">Tiago Silva</span>
<span class="org">Hive Solutions</span>
<a class="url fn n" href="http://www.tiagosilva.me">Personal Web Site</a>
<a class="url" href="http://www.hive.pt">Hive Solutions Web Site</a>
</div>

This markup allows the parser to know the enclosed content is a contact information, since the "div" has the "vcard" class which indicates that hCard is being used in its contents, guiding the parser on how to interpret the data.

You can use this creator to encapsulate your contact information with the hCard Microformat.

hCalendar

This Microformat is used to represent information about an event. Below you can see the event of me writing this post, annotated using the hCalendar Microformat:

Once again, if you check out the Operator bar, you will notice that it has detected the above event, and if you look at the code, you can see more than meets the eye:

<div class="vevent">
<a href="http://blog.hive.pt" class="url">
<abbr title="2010-06-09T18:0000" class="dtstart">June 9, 2010 6</abbr> -
<abbr title="2010-06-09T18:00" class="dtend">6</abbr>pm at
<span class="location">Hive</span> -
<span class="summary">Hive Solutions Post</span>
</a>
<div class="description">Make a post for the Hive Solutions Blog.</div>
</div>

This markup allows the parser to know the enclosed content is an event, because the "div" has the "vevent" class which indicates that hCalendar is being used in its contents, providing the parser with insight on how to interpret the data.

You can use this creator to encapsulate your events with the hCalendar Microformat.

5 - You're Already Using Microformats

Google is starting to pay attention to Microformats in its crawling endeavours. Nowadays, if you search for thai green mango salad recipe you will get the following result:

Google didn't used any cutting-edge algorithm to figure out that the underlying page was talking about a recipe that could be cooked in 20 minutes, and was reviewed 5 times. If you follow the link and analyze the page's source code, you will notice that it uses the hRecipe and hReview Microformats to annotate these details explicitly.

6 - Lorem ipsum ipsum lorem

'Sup dawg, I heard you like 7 bullet points, so I put a 6th bullet point in your bullet points so you can have 7 bullet points.

7 - The Semantic Web is Here

Straight out of Wikipedia, here's the definition of the Semantic Web for you:

The Semantic Web is an evolving development of the World Wide Web in which the meaning (semantics) of information on the web is defined, making it possible for machines to process it. It derives from World Wide Web Consortium director Sir Tim Berners-Lee's vision of the Web as a universal medium for data, information, and knowledge exchange.

When you talk to an academic about the Semantic Web he/she will probably geek out on elaborated specifications like Resource Description Framework (RDF) being what the Semantic Web is all about, and it probably will be, but for now, keeping it real, HTML5 and Microformats are the tools we have to realistically make the web semantic today.

If you wonder where all of this is moving to, and what's the ultimate vision for the Semantic Web, have a look at WolframAlpha, a computational knowledge search engine where you can today make queries as magical as big mac + coke and know everything there is to know about this combination, thanks to the semantic data sources it uses to cross data and extract meaning out of of. Now imagine if WolframAlpha could use the whole web as its data source... now imagine if something much more intelligent and sophisticated could have access to the whole web as its data source...

I lied... Google DIDN'T steal our idea, just wanted to attract your attention. You see, Google I/O, a huge event bringing together thousands of developers, is having its 2010 edition right now, where it once again revealed itself to be following the same path as we are, by announcing the Chrome Web Store.

Buy Right Now and Get a Free Vacuum Cleaner

The Chrome Web Store will only be open at the end of the year, and it will be a marketplace where one can publish and sell web applications. The concept may seem a little bit strange for some people, but it is really not unlike Apple's App Store for iPods, iPhones, and alikes; or the Android Marketplace for Android powered mobile devices. Like in these previous installments, it will bring centralization, with all its benefits, to a world of web applications that often remain unnoticed due to the turbulence of the chaotic sea of information overload.

Even though it's getting easier and easier to sign up to different services nowadays, with open authentication methods becoming mainstream (Facebook Connect seems to be everywhere these days), they still don't beat the simplicity of hitting "buy" on the App Store, and being done with the process, with the application you selected now being easily accessible from your dashboard. This is the experience that I am expecting this marketplace to bring, hoping that it will bring forth an obliteration of nowadays' bias towards still developing native applications for cloud-connected devices.

Common sense would say that there is no reason to make native applications for smartphones for example, or that at least they should be a dying trend. Even though mobile devices are getting increasingly powerful, previous limitations that stopped the browser from being a container for any kind of application are disappearing, and internet access is becoming ubiquitous, the transactionable merchandise in the current popular application marketplaces, be it the App Store, Android Marketplace, or Steam, still consists of a native application. If you want to commercialize a web application in any of these stores, you still have to create a native application that will act as a client for it, and obviously deploying your application in all these markets amounts to lot of nonsensical extra work that shouldn't have to be done in the first place.

We're Losing Cabin Pressure

Google's version of a web application marketplace is not technologically revolutionary, but it is still nevertheless, a potential game changer, and another step in Google's apparent commitment to leave desktop applications dead and buried, an attitude we are on board with, and that I have addressed extensively in previous posts.

It's no coincidence that this service will be made available at the same time Google Chrome OS will be launched. To those not up to speed, Google Chrome OS is a very stripped down version of Ubuntu, that basically comes with the Google Chrome browser and little else, and which is meant to be run on netbooks with a custom firmware used to bypass traditional hardware detection routines for lightning-fast boot times.

If you join Google Chrome OS, with their evangelization of HTML5, their WebM codec, Chrome Web Store, Chrome's Native SDK and services like Google Cloud Print, you can see that Google is really pulling out all the stops to turn the browser into the container for all applications in the future.

We're in the Pipe, Five by Five

These moves are always a reassurance as to our mental sanity, as we were happy to see that at least one big industry player is seeing the future as we do, since this was yet another instance of Google revealing itself as to being on the same trail as us, but fortunately, still seeming to be miles away from the paradigm and service we want to establish for the next generation of the web.

Every post, I usually deliver a punchline or two about either Colony or Omni, one being our open-source modular application framework which is the fruit of two years of hardcore research and development, and Omni our holy-grail flagship platform-as-a-service that runs on Colony. There is currently no official portal for these technologies, since even though they are currently being used in-field successfully, they are for many reasons, still not consumer-ready. Today, and for the first time, I leave you with a coherent speech on what Omni is/will be, and how its ideology still distances itself as cutting-edge:

Traditional software development models fail miserably in promoting steady and measurable development of large-scale software that is highly pressured by environmental changes. We believe that a truly modular approach to software development (think legos) is the solution.

We have built the technology that supports a platform where beautiful modular rich internet applications, that rival desktop applications in every way, can be easily developed, deployed and consumed. We call this service Omni, and it will be "the iTunes of the web application world".

As a consumer you will be able to access all your applications from anywhere in the world, with any device and operating system, without ever having to think about storage or processing capabilities, paying only for what you use, just like electricity.

As a developer you will be able to develop and deploy new plugins using no more software other than a web browser. A plugin may be a new application by itself, which can re-use any of the hundreds of already available plugins (not counting third-party), or just an extension to an already existing application in the platform. You may sell and promote your work in our marketplace, benefiting from the ability to create attractive business models where you can offer and charge the consumer solely for the features he wants to use, thanks to our modular approach. You will be able to maintain your application without any kind of overhead, as you will be able to push any improvements to your consumers without them having to restart their service in any way, shape or form.

Desktop applications are dying, along with their isolated, rigid, and high-maintenance nature. A brave new world of flexible and ubiquitous services is coming to replace them, and it lacks only the earth where it can grow and flourish: Omni.

We're back from a weekend in Coimbra, where we attended Switch, a conference that aimed to gather scientists, entrepreneurs and thinkers, in the context of a Web 2.0, Social Media and Entrepreneurship theme, with some refreshing outliers to the main theme along the way.

The conference attracted our attention mainly because of its Startup Competition, where one could go and pitch for an idea in a couple of minutes in front of investors and a tech-savvy audience. As we have been living under a rock for a long time, under heavy research and development for our Colony framework and Omni platform, we figured out this would be a great opportunity to go out and breathe fresh air, something we started doing much more as of recently, now that we have reached a phase where Colony is becoming rock solid and very powerful, and we can quickly develop awesome applications on it.

We took the opportunity to take an idea out of the drawer (one that would scratch a personal itch), quickly prototype it, present it, and get some feedback on it. We wanted to always go out and eat in different places, to avoid falling into a routine, so we built a tool that would help us solve that problem. A place where you can just go and ask whatever is on your head in a search box and have useful results show up, like "penne all arrabiata in Coimbra between 5 and 10 euros near me", or just "penne alla arrabiata 5 euros", or whatever you feel like querying for. We implemented the prototype lighting-fast thanks to our Colony framework, and be it not for the current lack of data, it would already scratch our personal itch. With prototype implemented, and presentation in hand, and a name for what could be a new service built around this idea and prototype, we headed out to Switch to pitch for alacarte.fm.

The Long Hard Road to Switch

The organization was nailed on the head with every single frickin' Murphy Law. With Eyjafjallajokull spitting out volcanic ash and cancelling Portuguese flights and international speakers dropping out, a sh*t storm rained on the organization's parade, which could very well kill the conference, so when we arrived at the place (which was not that easy to find), and after hearing such a silence around which you could hear the grass growing, we thought for a minute that we had been scammed. Fortunately, after finding the conference hall, there actually were quite a lot of people there, and in the end, it was great to see that the organization still managed to make an awesome conference against all odds.

Switch had a little bit of a TED-like feeling to it, as different people, from different ages, professions and backgrounds, shared their thoughts on the same stage. The conference was almost entirely performed in English, which unfortunately limited some of the speakers' ability to showcase their ideas and knowledge to their full extent, as well as to deliver that emotional punch that presentations need to touch/brainwash/inspire audiences. I do, however, give my deepest congratulations to them, in fact, the lousier the speaker's english, the prouder he should be, because public speaking alone is already such a huge fear for most people, that in a popular study it ended up being ranked as the biggest fear of all, with death itself coming in second place. That's right folks, in a funeral, people would rather be in the casket than giving the eulogy. So a clap of hands for their courage, which allowed the results of this conference to be shareable with the whole world.

Speakers talked about everything from cell biology, to freelancing, to lifestyle, to entrepeneurship, to journalism, and so on. We even had a speaker talk about how to make didgeridoos out of toilet paper, and give a pretty cool performance on stage, which myself, having unsuccessfully tried to play the instrument in the past (not only could I not do circular breathing, but the sound itself came out as an elephant in pain), really enjoyed:

Do You See The Face?

I have to give some special attention to a great presentation in the out-of-the-box part of the conference about the science of human emotional facial expressions. Talking badly about someone behind his back is very nasty, but I will take the negative hit on my karma this time, because this one was just too f-ing hilarious.

To me, personally, this talk looked promising, as I am a closet behavioral psychology geek, which made me get preemptively excited. As the speaker stepped on stage, an epic music permeated the room, and he started talking in an hypnotic voice... a black slide appeared, as he provocatively asked if we could see the face... I couldn't see the face... and neither could anybody...

The lights were turned off, and once again we were asked if we could see the face... I couldn't see the face. As his steady voice blended with the harmonious tones of an Enigma-like music I was drawn spellbound by the eery atmosphere joining the darkness which previously enveloped the room, as I still wondered quite naively: where is the face? I wanted to see the face! I was sure he was going to surprise me with a pearl of wisdom that would shatter my model of reality and change the way I saw life and human relations forever, I just didn't have the psychological frame under which I could see the face, but when I did, I was sure my life would change... such an epic stage event just had to be the undertone for something big.

After a couple of minutes the spell broke, and I was probably the last one in the room to figure out that we were actually stuck in what could be a mixture between a sketch from Monty Python's Flying Circus and a David Lynch movie, a ride that would take me into the most bizarre public speaking experience I ever saw in my life. Turns out there was actually a face on the slide, but it wasn't being seen because of a technical problem, but the lack of facial expressions on the speaker's behalf (ohhhh the irony) and the epic tone of the presentation blinded me to the fact that the performance was not a mind-blowing metaphor, but was in fact completely foobar.

In the end, I still have no idea what the hell the presentation was about, and what the speaker has done in his supposed decades of research, due to the absolute lack of content in the presentation. I wanted to post the video of his talk here, and help create a new internet meme, but unfortunately, I could only find the presentation itself, which with some imagination and my previous description, I hope will give you a nice laugh:

P.S.: When I die (knock on wood), I am going straight to hell...

The Startup Panel

In the end, we managed to present our project at the startup panel of the conference, which was unfortunately, too small, as it consisted only of us, showcasing alacarte.fm, our restaurant and food discovery service, and another startup, showing Bondiu, an event discovery and management service.

Bondiu was pretty interesting, and it's true that I have felt a need for such a service, and even though competitors exist, for some reason I never found them to be good enough, and never ended up using them, so good luck to them on this one, as I hope I will be able to Bondiu in the future.

Our presentation went quite well in my opinion, as João managed to keep it going rather smoothly even with all the unexpected technical problems. I mean, give us a break, we improved the idea and implemented a prototype in little more than a week, within blank timeslots around our regular work, and had to pull close to an all nighter the day before the startup panel, to have things ready. The presentation was fine, the prototype was also working great, but we forgot to turn off the screensaver on the laptop, which kept nagging through the entire presentation, a rookie mistake on our part that won't happen next time.

Anyway, the feedback was great and mostly positive, and to all of those that jumped on the web address expecting something... no, it's not there, this was only a prototype. However, we will probably put a minimal set of stable features online soon. To all of those that weren't there, I leave you with our current "long elevator ride pitch" for alacarte.fm:

Do your days always seem exactly the same? That's because you're doing exactly the same! Why don't you try going out to eat in a different place everyday for the next month? You may think that's too much of a pain, you don't know where the restaurants are, the ones you know are far away, you don't know what you can eat there, if you have enough money, or they don't have what you want to eat... not anymore! Just go to alacarte.fm, tell it what your stomach and wallet are thinking about, in a freestyle google-like fashion, and you're done! You'll get the best restaurant that fits your stomach, wallet and current location!

You're a restaurant owner, and lots of people passing by your restaurant just ignore it? You know you're better than your neighbouring competitor, but they still go next door, and you can't figure out why? That's because humans are creatures of habit, and in this particular case, their habits are being fueled by deep primal survival strategies... they want food! They'll go for where they can fulfill their need in the best way, they won't settle for any unknowns, they won't give you a fair chance. You just need to be able to showcase yourself and prove them how great you are, and we give you just that! We take the choice out of choosing. The people for which your restaurant is the best choice will be the ones we suggest to go there, and since they don't even have to think about it, and it's the best choice for them, they'll have no reason not to go... the rest is up to you, if you're good, they'll be hooked for life! :)

And here are the slides for the presentation too:

The Aftermath

I have no idea as to the real impact this event had, but I am sure it had at the very least some, and that it was one step forward in waking us up to our great potential, one step towards making us stop whining and step up to the plate, to get our ideas out there and act on them.

Yeah, we live in Portugal and we're in the middle of a financial crisis, but then again, we live in Portugal and we're in a middle of a financial crisis, same phrase, different interpretation, our circumstances can either be a handicap, or a huge advantage. Let's choose wether we want to be whiners or winners, and then stick with that decision. Until then, we hope to see you at the next Switch or similar conference, and see the idea YOU have been keeping in the drawer for all this time :).

Since Steve Jobs has bashed Adobe and Flash recently, calling Adobe "lazy", saying no one will use Flash anymore, and that everyone will move to HTML5, and since I agree with his arrogance (at least in the "everyone will move to HTML5" department), this is a great time to talk about HTML5.

I've just been tinkering around with some of the features that are already available in today's browsers and their nightly builds, and I was very pleased to confirm that all these nice features are incredibly easy to use. Just to get you up to speed, HTML5 brings with it not only new markups, but also some kickass extensions to the DOM API. Here are some of the features that come with HTML5 or are piggybacking on them:

• Dropped obsolete elements: frame... you will be missed :(.
• Added new elements meant to replace the generic and semantically shallow div tags by giving more semantic information about their contents (example: header, section, article, footer).
• New form controls as well as the ability to make any marked up content editable.
• Offline Storage: Goodbye 4kb cookies.
• Application Cache API: One of the many nails in Google Gears' coffin.
• Drag and Drop: No more frustrating upload forms.
• Web Workers: Finally I can use the Javascript Virtual Machine for real, without freezing the browser.
• Websockets: Goodbye polling, hello push notifications.
• Notifications: Desktop apps get to be able to notify me even when they're hidden, and the browser doesn't? Not anymore.
• Geolocation: You are here!
• Canvas: Hello special FX.
• WebGL: Will anything run outside the browser now?
• Video and audio: Hasta la vista 90% of Flash applications (I just made the 90% figure up).

The Desktop Killah

One of the nicest things about HTML5 is that it reduces the need for browser plugins like Flash and Silverlight, both technologies that deserve their spotlight for having redefined the browser's role, to that of a much more multi-purposed and capable tool, but that also deserve to have the spotlight removed from them for making it much harder to make web applications seamless and platform independent. This move represents a strong detachment from the language's original purpose, which was to layout content, as there is now a strong focus on satisfying the needs of web applications.

HTML5 is demolishing the last obstacles that prevented us from forsaking desktop applications and all the evil that comes with them:

• I am lazy and I don't like to install stuff.
• I don't like to upgrade applications either.
• Nor uninstall them.
• I don't like to clean viruses out of the computer of someone that used an USB pendrive.
• I don't like to have to choose an operating system.
• I don't want to have to install all operating systems.
• I reaaaally don't like to reinstall an operating system (I left that lifestyle along with win9x).
• I don't like to give tech support, as I'm much happier if things just work all the time... and I like giving tech support for free even less.
• I don't like to have to tell people that they shouldn't have to buy a new computer, that it's not slow for being obsolete, but from all the crap that they downloaded, that infected their computer, that is spamming everyone, and hogging their computers resources.

For these reasons and more, everything should be on the cloud, everything you need should be a browser, and all browsers should remove their download features. When this happens, the world will be a much more peaceful place where the skies are blue, unicorns will roam the streets, and the sun will shine. HTML5 is a huge milestone in this paradigm shift and it therefore has our full support.

Webless Web Applications

If 1990's Tim Berners-Lee were to slip and fall into a wormhole that sucked him into our time, he would probably be speechless at what we've done with his beloved World Wide Web. It was supposed to be a bunch of pages with links, and not a platform that aims to steal the desktop realm's throne.

Everytime one of us web application pseudo-prophets chants the good ol' word of a world without desktop applications, heretic voices shout: "What if I lose my internet connection?". Until now, the answer was one or more of: use Google Gears, get a better ISP, and/or get a backup internet connection like 3G.

The answer is becoming much simpler, with the Application Cache API, DOM Storage and Web SQL Databases, which are the most recent omens validating "the prophecy" (these along with Web Workers and Geolocation features, easily justify why Gears was dropped by Google in favour of HTML5).

Application Cache API

With the Application Cache API, one can now control what parts of the web application should be cached on the client side. To do so, is as easy as placing a manifest attribute in the document's html tag, with an URI to the location of a manifest file, which indicates which contents should be cached (this file must be sent with the "text/cache-manifest" mime type).

The cache manifest file is a simple text file with a list of the resources that should be cached and those that shouldn't. Its structure is beyond the scope of this post, but it's pretty much straightforward. To learn more about it you can have a look at the Offline Web Applications chapter of the HTML5 spec.

DOM Storage

You can now also partially, or fully replace the usage of cookies with the easier and more flexible DOM Storage. Now you can access two new structures in your browser called localStorage, and sessionStorage.

With local storage you can store data that is accessible by all scripts within the domain that originated it, and that is persistent even after the browser closes. With session storage, you can store data that is accessible only by the specific window/tab, and therefore disappears after it's closed.

You are not limited to storing only strings like in cookies, it's really easy to use, as you can use them as regular associative array structures, and browsers offer somewhere around 5-10mb per domain for this kind of storage.

You can have a look at this online demo to give this feature a test run.

Web SQL Databases

This feature is just totally sweet, the idea that I can now write a full blown web application without even needing a web server is pretty liberating. The concept may be kind of stupid, but bear with me for a while. Imagine that I just wanted to write a quick personal app, to keep track of workout logs or whatever, and I lived in a parallel universe where spreadsheet software was never invented. Previously I would have to pick up some programming language, or combination thereof, which offered me a way to quickly prototype an application with an user interface, and I would probably end up in .NET and Windows Forms land.

Now I can just hammer up a HTML page with some Javascript and I'm done. It's easy, it's free, it's cross platform, and I just need a rudimentary text editor to do it. If you find this to be a weird scenario for this feature's usage, then think about making web applications that are available offline in whatever platform you're using them in: control the cached resources with the Offline Cache API, sync the user's data with a local Web SQL Database, and you can now use your web applications even in Antarctica.

Give this online demo a try to get a feel for how this works.

Pimp my Website

HTML5 brings with it some nice features that will make web applications increasingly indistinguishable from their desktop counterparts.

Video and Audio

I remember the old days when playing video and audio content on the web was a huge pain in a part of my body. Buffering 10%.... buffering 20%... buffering failed... or I didn't have the appropriate player, or the appropriate player was loaded with spyware, it just wasn't fun to say the least... until YouTube and similar services appeared.

Due to Flash's ubiquity, the experience of watching media in these services is nowadays pretty decent, as they work out of the box. However, the way Flash deals with video is pretty resource intensive, and to top that, it uses proprietary formats for compression. HTML5 kind of deems Flash obsolete in this department, as it lets the browser deal with media playback by itself, by now adding a way to reference them via video and audio tags.

Here's another cool demo showing off video in HTML5.

Canvas

Another one of Flash's nemesis, Canvas consists of a drawable region defined in the HTML code that can be manipulated via a set of drawing functions similar to other 2D APIs. Amongst its many utilities (charts for example, just from the top of my head), Canvas may very well be the container where a new wave of video games an other interactive media applications will run in. Their quality may even be boundless, as the WebGL specification is in the works, which will provide the Canvas container with OpenGL ES bindings, and make hardware accelerated in-browser cross-platform graphics a reality.

You can check out CanvasDemos for a motherload of Canvas demos to play with.

Drag and Drop

Have you closely checked out Gmail recently? Try dragging and dropping multiple files into the attachment upload area when using Firefox or Chrome, and just watch the magic happen. The files will be uploaded and attached with no extra interaction.

Gmail is using an interesting hack to do this, it's just using a normal form input tag, of type "file", with the new "multiple" attribute offered by HTML5, which already supports dragging and dropping multiple files into it, and it's hiding the input control and masking it with CSS trickery.

Most browsers already handle custom drag and drop events, but when these events are caused by dragging and dropping files, accessing and manipulating their contents seems to be a whole other story. Hopefully this will become a standardized reality in the not too distant future, and it will bring a whole new level of user experience to web applications, but for now you can already fool around with it today, by using Firefox's FileReader object.

Notifications

Yes, you can install plugins in your browser to provide you with notifications when you receive something in your Gmail inbox for example. But change browser or computer, and you've lost the feature.

The fact that web applications can't issue decent notifications nowadays, kind of forces them into having to be visible all the time, which makes them a lesser breed than desktop applications. This is probably a thing of the past, as you can now issue desktop notifications with Chrome, through WebKit's Notification API.

Actually, for the sake of accuracy, I looked for this feature in the current HTML5 spec, and I didn't find it there, so I can't promise this will actually be somewhere in the standard, but I won't be very surprised when this API finds its way there.

Check out this slide from this awesome HTML5 slideshow with Chrome to see this feature in action.

And Even More Miscellaneous Sweetness

Breathe deep... and there we go... more HTML5 goodies.

Websockets

Browsers and web servers just didn't get along until now. Everytime the browser requested something from the web server, it would just close its door afterwards without asking it if it wanted anything else. Ok, it could ask it to keep the door open for more or less time, but still, it ended up being pretty rude in the end.

Try to design an application that needs to be notified of server-side events and you'll notice how messy and inefficient your solution will be, as you'll have to keep polling the server time and time again, asking it the same old question and having the door shut in your face afterwards. Websockets make things so much easier, since now you can just open a connection with the server and have it notify you instead, leaving you with the simple job of waiting for the notifications, instead of having to be asking questions all the time.

Here's a demo of an IRC client using Websockets.

Geolocation

Want to track down someone who is owing you money? Make a website that will draw him in, and use the Geolocation API to get his coordinates. I'm sure there are better uses for this feature than that one, I mean, even in the desktop computer where I'm writing this post, which naturally has no GPS, I was able to get some pretty accurate coordinates as to the whereabouts of my current location, so I guess coming up with cool uses for this feature just requires a tiny bit of creativity.

Try out this demo, and don't blame me if you get a little paranoid after trying it.

Web Workers

Javascript Virtual Machines are getting pretty efficient, just look at Google's V8 for example. Probably it's time to start taking them seriously and getting them to do heavy duty work.

Until now, everytime you wanted to perform heavy computations, either you used some nasty setTimeout hacks, or you would get a frozen user interface. With Web Workers, you can now run your code in different threads (or something thread-like, I guess this depends on the browser and the operating system it's running on), and fully use the browser's power without handicapping your user experience.

Watch your CPU fly without crashing your browser, with this demo.

We Want You for the HTML5 Army!

Still not convinced that you can kiss Flash bye bye? Then you can go back to sleep. In case you are, then use HTML5, it's right here, right now. Yes, the specification is still a draft and it's obviously not implemented in all browsers as a consequence, but at least whenever there's not much of a risk in going for HTML5 instead of a sluggish browser plugin, then go for it. When Flash becomes an archeological artifact found in archaic websites, along with GIF animations of mailboxes, then you can proudly say you were one of the standard's pioneers :).

It has been a "gung-ho" week here at a Hive, as we have pushed Colony into the ranks of Ruby on Rails, Django and similar rapid web application development frameworks.

Colony is a modularity framework, and as such, it promotes well-designed modular applications. Modular applications are normally of a large scale nature, or at least they intend to be as such, or else they needn't be modular in the first place. Due to this focus, even though we aim for simplicity, promoting rapid development wasn't exactly a top priority.

Roughly two weeks ago, after performing a demonstration of the Colony framework and the Omni platform service we're building on it, we were asked if Colony was useful as a productivity tool, in order to develop better applications in less time, and how fast we could make an application with the functionality of a specific pre-existing invoicing application. After saying we had to think it through, we went back to the drawing board.

We checked the application out and it didn't seem that complex, it could be easily done with any of the many already existing web application frameworks. But why not Colony? Just because it was built to create quality modular applications in a fair amount of time, not being able to use it for quick prototyping didn't seem to make sense. In order to push the framework further, instead of doing some math on how long we would take to make the application and probably end up being overly optimistic in our estimations, we build the whole damn thing just to be sure.

That's right, we built a Software-as-a-Service invoicing application in Colony in little more than one week (without burning the midnight oil!). It's a beta of a pre-alpha version for sure, but from here onward, its basically bug fixing (we're probably aware of most bugs by now, just have to put in the time to fix them), and usability and design improvements. The whole thing, which we branded Take the Bill just for kicks, included:

• Both application and visual design.
• All the CRUD (create, remove, update, delete) normally associated with most information systems, with this one not being an exception.
• Both regular and single sign-on authentication with OpenID, Twitter or Facebook.
• PDF report generation for invoices and others.
• Application interface and logic glued together with Ajax, for a smoother and faster user experience.
• Facebook-style full-text searching, giving the user a single search box where to look for any entity in the application, like a customer or an invoice, using any keyword related to it and without losing context.

To do this, we had to depart from the traditional way we built web applications in Colony until now. Our primary way of doing web applications was to have a Python implementation of Colony running on the server-side with all the plugins necessary to support the application's logic and deployment, which roughly meant having Object-relational-mapping, HTTP server and application logic plugins.

When the user accessed the Colony instance's HTTP server by typing the web application's URL in the browser, Colony would serve its Javascript implementation, opening up a way to provide modularity on the client-side. From here onward, the server would send all the required plugins to the browser and it would execute them in its Javascript Virtual Machine, which in the end had the effect of rendering the whole web application.

To achieve the level of modularity we usually targeted for, we didn't provide the client-side visual and logic code in the web plugin itself, but added yet another useful level of indirection by partitioning this code into a Model, a View, a Controller, and a Presentation Model, in a fashion similar to the traditional MVC design pattern, and wrap these parts in a concept we call an MVC Module.

MVC Modules are managed on the client-side by a MVC Manager, which provides lifecycle management in a manner as similar as possible to the Colony specification, but with all the particular twists required to provide modularity in visual components. Finally, in the Module's View, we would then implement the user interface using Colony Web UI, our own Javascript widget library.

This way of doing things is architecturally sound, and it's the best solution in the long run, but it's still painfully slow to develop in, as we end up only breaking it even in terms of development time by being able to avoid a lot of bugs that would come from a more ad-hoc messy approach. We have ideas on how to cut this time shorter, but they're still pending implementation.

Long story short, we could have never implemented this application in this time frame with this previous approach without overdosing on caffeine, so we took a different route this time.

No need for modularity on the client-side, so no Colony implementation on the browser. Modularity on the server-side was enough, so we threw the whole Javascript stack to the side this time... leaving only some jQuery wizardry in the plate.

Separation of concerns was made possible on the server-side due our lightweight MVC server-side framework plugins. This was enough to separate logic, static content, dynamic content and visual components, and therefore more than enough to make the whole party.

In the end, Colony is now more all-purpose than ever, which means more power to the people :). Also, we now have a prototype of a new Software-as-a-Service which can easily be shaped into a consumer-level reliable service if we decide to go in that direction, which we can use as another trophy in our showcase regardless.

Different week same menu, today I am yet again going to pitch in favor of Cloud Computing. If you've been following this blog you've probably found the words SaaS and Cloud popping out of your mouth in your chats around the watercooler and leaving your colleagues to think you're a loon. Fear not! I am going to approach the subject in a totally different light this time, and I promise to change either in area or depth in the next posts, probably by diving into more technical stuff.

Loving the Planet is the New Blue

Today, ecology is trendy, so trendy in fact that even huge companies previously massacred by activism or simply negative overall public opinion due to their ecological policies or lack thereof, today promote themselves as green, clean, sustainable, low-footprint, yada yada yada... This practice is sometimes refered to as "greenwashing", like the devil was putting an halo on to hide its horns. I personally call it "who the hell cares?". Does it really matter that much, the motivations that made someone perform a good action? Or does it matter more that the action was performed? No matter what your stance torwards the environment is, if you want to save the planet, or just spend less money, Cloud Computing will make you environment-friendly regardless.

Captain Cloud, He's Our Hero, Gonna Take Pollution Down to Zero

If tomorrow, all services were to be moved to the Cloud, the savings we would have energy-wise would be absolutely incredible. My math skills may be rusty, but "less energy being spent = less energy needing to be produced = smiley planet" seems to be at least correct in theory. Going straight to the point, how can Cloud Computing lower our energy spenditure? Just to get people up to speed, let me just redefine Cloud Computing straight out of Wikipedia again:

Cloud Computing is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand, like electricity. It is a paradigm shift following the mainframe and client-server shifts that preceded it. Details are abstracted from the users who no longer have need of, expertise in, or control over the technology infrastructure “in the cloud” that supports them.

Or show you this nifty Salesforce video instead:

By embracing the Cloud Computing paradigm, you will be using storage and processing capabilities just as you use electricity in your house. To use electricity, you don't really need to understand where it comes from or how it works. You will fairly pay for what you use, and not for the resources that provide what you use. You will pay for the storage and not for the hard disk, for the processing and not for the processor. This business model paves the way for the centralization and brutal optimization of the resources that provide these utilities, especially regarding how they're being used.

Save the Planet by Being Cheap!

Let's think about it in a very simple way. Let's say you want to create a web site and decide to host it on your own. You buy a server just for that purpose, set it up, get your domain, bind it to the server's address, and you're proudly hosting your website by yourself. In the end, it turns out your website is not as important as you thought it was, its not attracting that much traffic, and as a consequence your server is largely underused. Most likely you also have a huge hard disk that is completely empty, unless you are hosting some kind of media streaming service.

So there you have it, you have an incredibly powerful machine sitting in your house or office, which is basically not being used at all. You have spent your money on something you didn't need, it's turned on and wasting unnecessary energy (power saving methods will probably reduce the impact, but still...), its hard disk is not being fully used, its processor is mostly idle, and the energy and resources necessary for manufacturing and transporting this computer were already wasted and are not coming back.

If you were to use a shared hosting solution, which would probably serve your needs in case the website had low traffic and uptime demands, then you would have opened the way for the service host to cut on their maintenance costs by placing your website in the same server as many others, consequently using it to its full capacity, and lowering the amount of resources and energy used to provide the same services to the world.

It would be cheaper for you, cheaper for them, and cheaper for the planet, it's a win-win deal all the way. And I'm talking about shared hosting, something that already existed in the stone-age, along with spears and clubs. When I talk about services like Amazon's S3 and EC2, where you can pay for the exact storage and processing you end up using, you are in most cases getting the fairest cost for what you are consuming, while being confident that a company that can sell services at this level of granularity, has to have very efficient and scalable infrastructures, and if they can use less resources to provide the same service, and increase their profit margins, they will, and once again, the planet says thanks.

Today I was reading a small blog post about a new desktop client for Twitter, Facebook, and LinkedIn being done by Seesmic. The interface looked very interesting, but as to the concept itself... ad nauseaum... until I got to the part where they claimed it was going to be easily extensible through plugins. As to the particular details of how they're going to implement the modularity and how easy it will be for developers to extend, and consumers to use, I can only speculate from the articles I have read, since it wasn't launched yet, but it does hold the promise of scratching a itch of mine, since I still have to use different tools to post on different social networks, and redundancy bugs me immensely.

The modularity train is gaining momentum, as we have seen developments all over the industry in this direction these pasts years, all apparently and hopefully heading torwards the station where we are already waiting at. Not so long ago, talking about building fully modular and extensible applications was crazy talk, utopic mumbo-jumbo, it made sense, but it was, or was perceived as, an unworthwhile investment... but history is about to change.

The Ghost of Modularity Past

In the software development world, Eclipse was probably the first extensible application whose modularity really seemed to pay off, or at least its utility was easily perceived by the developers using it. Personally, I've been using Eclipse for years, and it always seems to catch up to my new demands, since there always seems to be a bunch of plugins I can use to extend it in order to get the functionality I want.

Modularity even seems to have already played a significant role in the consumer market. There is probably more than one reason why Firefox has risen from being the underdog, to having a reasonable chunk of the browser market, and I personally think one of the reasons had to due with its extensible nature. When one needed a new feature in Firefox, like a downloader manager for example, one didn't need to spam the Mozilla Foundation requesting for that new feature, it was very probable that someone had already developed that feature as an extension, and getting it was as simple as search, point and click.. and if it wasn't available yet, developing the extension by ourselves was always an option.

When Google Chrome came out, even though it was blazing fast and I loved it for that, I have to admit it took me a while to drop Firefox and start using Chrome by default, due solely to it not being extensible, and to the fact that I had already placed some weight on my Firefox extensions' shoulders. Certainly, for a lot of early adopters the lack of extensibility in Chrome was probably irrelevant, but I'm pretty sure I wasn't the only one in the same position, that didn't think twice about dropping Firefox for Chrome once it started supporting extensions.

Above all people want speed, that's it, they want to be able to do the same or more, in less time. Chrome already delivered in terms of raw speed by having an incredibly short boot time, as well as lighting speed rendering and Javascript processing provided by WebKit and the V8 Javascript Engine, respectively. However, the last speed improvement was not so directly measurable; it was by providing extensions that it finally opened the possibility for a whole range of valuable time-saving shortcuts.

Modularity has been around for quite some years in the desktop application world, and even though monolithic applications are still the norm, one cannot deny the world of difference modularity brings to the few applications that apply the paradigm successfully.

The Ghost of Modularity Present

There is, as of recently, a new trend arising, that of bringing modularity to the web. Google seems to be increasingly interested in modularity and integration, Google Labs features seem to be popping up in all Google applications, and slowly but surely, the whole Google ecosystem seems to be integrating more and more, each time making more sense as a coherent whole. The recent launch of Google Apps Marketplace was particularly interesting, because it was a noteworthy move in bringing together different web applications into a single unified platform.

It's very satisfying to know that our own crazy talk/utopic mumbo-jumbo, or should I call it vision, is being confirmed with each passing day. The web has brought us all together, and thanks to this, excuses for re-inventing the wheel are becoming obsolete. If someone has already solved a problem, you shouldn't have to solve it again, period. The web mixed with the open source movement has done a huge deal in this regard, and we can surely credit them with the exponential growth in innovation brought forth nowadays by even by small groups of people with limited resources.

The Ghost of Modularity Future

The next step, is to have an unified platform where to develop and deploy applications, where one doesn't have to worry about scalability problems, or compatibility with target platforms. Where we can easily re-use the work performed by other developers, and share our own, a host where the user can find all his web applications, and the developer freely distribute or sell his own, ultimately a service that kills redundancy and complexity in favor of value and simplicity... we are working for Omni to be that service, to be your open web platform, your singularity on the web.

All boundaries are nearly gone, as we are being propelled towards a future where all computing resources will be easily transferable and tradable, just like electricity and other household services. This change will surely bring about a major paradigm shift in all stages of software development, as well as in its distribution and consumption.

Whilst globalization brought about an increasing complexity and unpredictability to the marketplace, it surely opened the floodgates to a world of new and exciting possibilities. Opening trading possibilities between all corners of the world, businesses were streamlined to their core competencies, and other tasks delegated to other businesses to which these peripheral tasks were to them, their core competency. Businesses became lighter and more efficient, bold ideas kept in the drawer for years finally saw the light of day due to new outsourcing possibilities, new distribution channels and more flexible logistics.

Globalization hits the Software Industry (again!)

The exact same shift is happening in the software world, with the advent of Cloud Computing, the Software-as-a-Service paradigm, and the increasingly accelerated evolution of the technologies that support them. Everything is moving to the Cloud, and we are moving back to the old computer terminal days, but now not out of necessity, but due to the incredible advantages of Cloud Computing.

Cloud Computing is, philosophical ramblings apart, the outsourcing of computing and storage resources, as well as full fledged services to the Internet. As so eloquently stated in Wikipedia at the time of this post’s writing, a clearer definition would be the following:

Cloud Computing is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand, like electricity. It is a paradigm shift following the mainframe and client-server shifts that preceded it. Details are abstracted from the users who no longer have need of, expertise in, or control over the technology infrastructure “in the cloud” that supports them.

Due to this shift, end-users are being stripped down to their core competencies as they’re becoming increasingly able to delegate all the setup and maintenance of their computer software by using software accessible via the Internet as if it were a service (hence the term Software-as-a-Service), with all the accessibility advantages that it brings.

Down with the Desktop, Yay to the Modular Web!

This shift, along with the growing infrastructures supporting it, is paving the way for a modular web, where applications will be able to cooperate with each other on a whole new level beyond anything ever done before, and bring about at a breakneck pace immeasurably valuable applications built on leveraging various applications and services in a synergistic fashion and by making the all too common process of reinventing the wheel a thing of the past.

When we talk of these consequences, we are talking also about traditional desktop software eventually disappearing as a whole, leaving the computer with only a lightweight operating system providing solely the functionality necessary to act as a gateway to the Cloud, where all data storage, retrieval and processing operations would take place. This vision, as that of a modular web, is also highly controversial, but bear in mind that in the past one could argue that there were technological barriers both in software and hardware that prevented such a change, but this is not the case nowadays.

With browsers becoming lightning fast, and new technologies trying to bridge the gap between their sandboxed environment and the computer’s hardware, it is today possible to use the browser to deploy and run on the fly, something as demanding as a full-blown computer game. With upcoming standardizations and further backup from major industry players, this pre-meditated possibility will become completely ubiquitous (think about Google’s support of HTML5 and its investment in Chrome OS as perhaps a validation of this vision).

What Does the Horoscope Tell Us?

As to the time frame within which these changes will occur, that’s unfortunately another story, and a more unpredictable one at that, since the behavior of a single human being is unpredictable enough, let alone the whole world’s collective behavior. But since this entire post is written with an arrogant mindset, let’s just say that this will happen much faster than people thought so a couple of years ago.

Meanwhile, the Colony framework, the Omni service, and the ecosystem we are building around them, are being done with the presupposition that these transformations will inevitably take place, short of other unexpected technological or conceptual breakthroughs that could eventually render this vision obsolete.