jQuery Goodness and Mosso Soso-ness
JQuery
So code cleanup is going really well. In the process I have really polished up my CSS/XHTML/Javascript skills. The core software for RGB Daily, Pligg, is written with Prototype and Script.aculo.us on the front end. A couple of the custom plugins that where written use JQuery though. Working my way thorugh bugs I became really impressed with jQuery and decided to find out more about its author, John Resig. Turns out he lives in Boston and also works for Mozilla now. He is definitely my kinda architect. In the pocess of two days I pretty much taught myself jQuery.
I started out just wanting to get rid of the ugly dialogs that the alert/confirm javascript functions produced. I learned a lot from a plugin called Impromptu, written by Trent Richardson. After figuring out how Prototype was stomping over the “$” shorthand of jQuery I was on my way (I’m a Java guy, not use to that kind of wild west stuff). I hacked the CSS and added some convenience wrapper classes to implement replacements for the native prompt functions. Here is a quick pic of what I was able to achieve:
PR
So I’m showing a little more than just the confirm dialog. In the coming weeks I’ll be giving a little more guidance on what RGB Daily actually does and for what communities it serves. For now you can have a look and speculate 
As for updates on soft launch… Still looks like September is reasonable. At this point to be honest I just want to make the core production ready. That means a bug free UI (address known bugs from internal testing) and a server side that is built for scale on clustered LAMP.
Mosso: How reliable can public clouds be?
Mosso had some hiccups today and that really bothers me. I couldn’t commit my changes to the staging server for over half an hour because of FTP and site outages. I really like what they are doing in terms of ease of use, but at times I just feel like they are no better than Media Temple. For the record I am a customer of both.
When it comes down to it I’ve had less outages hosting on a GoDaddy shared account. Performance was also faster than the “cloud computing” alternatives for my case. Don’t get me wrong, I know that there is a ton of engineering smarts going on at both outfits, but I know customers with public sites are constantly pulling their hair out. I’m trying my best to engineer my way around things that might bring down Mosso at scale; well my piece of Mosso anyway, like the DB. What I can’t take care of though is the fragility of the entire system. These clouds seem to demonstrate some form of systemic fragility on a regular basis. From Amazon, Google, and all the way down the line. The August 11, 2008 Issue of Information Week talks about the concept of “Private Clouds”. Basically talking about running multinode cloud OSes on private infrastructure. Elastra and 3Tera (further along) seem to have figured this out. I’m just waiting for the price to come down.
I think that Mosso has an opportunity here for a new class of products. If I’m correct, at the core of their architecture they use virtualization to deploy and manage their nodes. It would be really cool if they could implement some way to provide higher isolation between nodes. Allowing people to have private interconnected nodes (web/db & shared SAN) that would be cool. GoGrid looks interesting, but they don’t have a NAS/SAN device that can be attached to VMs. Core to my evaluation of all of these solutions is how I can effectively manage growth on disk. RGB Daily is media intensive and those requirements will only go up in the future. Hopefully Mosso releases private VM containers in the near future to compliment the cloud. That would solve a ton of problems without adding a lot more complexity. For now I’ll be sticking with them and trying to figure out options for the DBs.
‘Til next time…
Security and Performance
There are big problems with the code base concerning security and performance. Much of the custom code for RGB Daily is not leveraging caching properly. Most of the inputs into the system are not even properly escaped for querying against the DB. Why am I saying all of this? The take home is not to sit back and relax while you think your dream system is being built. You still need to dive in on your own if you are an engineer and know what your doing. If you’re not the programming type you need to hire a third party auditor before the final release of the code is delivered. It’s actually better if you can have the code reviewed in milestones.
Status of Launch
So launch is really late, but the code is ten times better for it. I also know pretty much every corner of the codebase and that will benefit me as the founder /architect of this puppy. If a potential partner of investor has a question I have the answers and that’s invaluable. August is the last major month of coding and a formal launch will happen towards the end of the month. This is a drop dead date.
Seesmic Integration for Prelaunch
It looks like exciting times over at Seesmic headquarters. I’m really impressed with the teams focus on getting Seesmic in as many places as possible. If YouTube is the default player or the Web than Seesmic is definitely becoming the default webcam recording software of the web. Plus I just think that Loic Le Meur gets it.
To that end, I was pleasantly surprised to find out that the Seesmic API is really easy to integrate. I thought video might come after launch, but now its clear to me that partnering with Seesmic is definitely the right thing to do. The world has change since I started coding again. I couldn’t be happier.
Seesmic Integration for Prelaunch
RGB Daily, LLC
RGB Daily became RGB Daily, LLC on June 10, 2008! We are glad that we are now an official entity recognized by the state of Massachusetts. Half of the battle in Web 2.0 is the partnerships that are forged with other services and that involves lawyers. As a legitimate legal entity deal making gets a lot easier.
As for the code base we are 100% feature complete. Over the next week we will be cleaning up the codebase for the launch. Over 9 months in the making, we are ready to show off all of our hard work. There has been a lot of evolution in the service and we hope it will serve our users well. Once we launch we will start introducing all of the cool features that are available at RGB Daily.com
Workable Pricing at Mosso!
Mosso, our host for RGB Daily proper and this blog, is updating their pricing model. For the most part it looks like they are getting rid of the 3M request cap and $.03 CPM request pricing after the cap. They are moving towards a unit of measure that prices CPU and IO utilization. $100/mo buys you the horse power of a single dedicated box. I’m assuming that their overages at scale should correlate to the fixed pricing per month. So here are my questions:
- What are the specs of this virtual box?
- What average constant percent utilization of this box is the “compute cycle” based on
- Will pricing be linear based on base monthly pricing or will it be more expensive?
- Will pricing be tiered and will discounts kick in at scale?
- What is the relative ratio in terms of compute cycles of CPU vs Disk IO? Disk IO has to come in significantly cheaper for this new model to work. It has to reflect the real cost of CPU vs Disk.
- Will you be able to buy excess capacity ahead of time at base rates or cheaper? Best for Mosso and customers because more capital is generated for resource and capacity planning.
You can check out more at my thoughts at Mashable: Mosso Updates Pricing Structure; A Better Model for Cloud Computing?
For RGB Daily this is huge because it means that we will be able to move forward with our widget strategy unencumbered. With the request caps it just wouldn’t have been possible. Mosso has made our application architecture strategy a simple one.
Choosing a Host
We are feverishly trying to wrap up the first alpha release of RGB Daily. We will be starting a private preview release once we get the latest code settled on our new host. We evaluated several options for hosting including both dedicated/virtual servers and managed solutions. In the end we decided that the best architectural solution for our needs would be a clustered LAMP solution. Building out own multi-tiered clustered solution is not something we are interested in doing, so managed was the only choice for us. Also we wanted a solution that would be able to grow with the demands of a growing user base and their data. We needed a system that had a manageable fixed price, but also was able to grow with us as our storage and bandwidth costs grew.