Get To Business.

There’s a process philosophy called DRY (Don’t Repeat Yourself) that revolves around the notion that duplicate information is inherently bad. The thinking behind it is that duplicate information is harder to change, reduces clarity and is more likely to be inconsistent (since changes introduces inconsistencies between duplicates).
Such philosophy is the base for modern software engineering concepts, but apparently can be also applied to social networks.

An interesting experiment in social interactions has been attempted in an IRC channel (Internet relay chat) in which chat participants are not allowed to repeat any before said sentences. An automated monitoring system (called a bot) automatically mutes offenders for gradually increasing periods of time, forcing them to be original in what they say - or at least in how they say it.

I wonder if such philosophy could be applied in real life…

Needs to come up with better excuses

While taking a break from Octabox work, I came across John Resig’s blog. For those unfamiliar with that name, John Resig is the creator and head developer for the jQuery javascript framework (check the links if you’re unfamiliar with any of those terms either). I have read his book “Pro Javascript Techniques” a while back, and it was nice read though I skimmed through much of it since I was already familiar with most of the material. I wish it had more “Pro” and less common sense materials - which are still good but aimed more at beginners or non-programmers. I’ve read the table of contents for his next books which sounds very promising.
I did ‘read’ his more serious work, namely the source files for the jQuery library, which are a testament to his and his developer group vast mastery of the javascript programming language.

As I was navigating the posts, I came across this small flame war between a mootools dev and John regarding some comments made at a mootools introduction presentation. This matter was consequentially resolved, with both sides and other parties releasing apologies (of sorts).

Before I’ll iterate my thoughts on the matter, I’ll go ahead and say that at Octabox we use jQuery exclusively as a tool for javascript development. This is not a knock on mootools, from the little I tried it and from feedbacks I heard it’s a very good javascript library (and their site is absolutely gorgeous by the way). Choosing a software library is a matter of personal and design preferences, and is influenced to a large degree from what you hope to get out of that particular library.

A short recap of the story: Omlo Maldonado, a mootools developer at the time, was giving a presentation on mootools as a javascript framework. During the presentation, he made several references to other javascript frameworks, jQuery included, in a non flattering manner to say the least. John Resig, being the creator of jQuery, took offense and responded on his blog, adding further fuel to this rivalry. A small comment flame war ensued and the matter was later resolved with all parties (and mootools lead developer) issuing apologies.

Being a software developer myself, I sympathized with John’s feelings in response to the allegations that were made. He and the jQuery team were accused of ’stealing’ code, and their entire approach and design were being looked down upon. While I can’t condone his inflammatory response, I can certainly understand it (I probably would’ve written something much worse if I was accused in this manner. I’m a pretty cynical and sarcastic person). The allegations were serious indeed and detrimental to the whole approach of open source development and coexistence of multiple design approaches.
And while all sides eventually apologized, I got the feeling that the air hasn’t been completely cleared between the two teams. It’s too bad, since it’s exactly the diversity of such frameworks and the inter learning between them that continues to drive javascript development forward.

I’ll end with some insights I hold on jQuery, having used it professionally for over 9 months:

• jQuery lean packaging (15kb minified and gzipped) is a major plus. Previously we have been using Prototype at Octabox, and the switch to jQuery reduced our average page weight by over 50% (Here’s the original post I wrote back then. Seems like eons ago). The improvement to user experience with shorter page load times, the savings on bandwidth - those are all major benefits.
• jQuery has one the best user communities I have seen. Their approach to user contributions via plug-ins is a great idea, and it has proven an invaluable resource for adding functionality not provided in the core (for those knocking on jQuery feature reduction for size benefits - have you seen their plugin library?). The plug-ins being separate from the core also allows developers to hand pick their features, and not having those force fed in the official release.
• The use off CSS selectors as the driving scheme for selecting DOM elements is brilliant. Combining that with the chainable interface is the main reason I chose jQuery - It’s super convenient to use. All scripts I converted to using that interface have had size reductions of ~40% on average As a matter of fact, using the chainable interface has made me fall in love with fluent interfaces and has definitely influenced my design methodology.
• Their documentation is very good overall. I have used many open source projects that didn’t have the documentation to match the level of their code.
• Their UI component still needs work, and some libraries have more mature solutions (script.aculo.us, mootools and DOJO spring to mind). However they seem to be aware of that and have recently launched their UI specific project. By looking at their track record I don’t think this will remain an issue for much longer.

This guy and this organization share my sentiments. Also here and here

Can you tell I’m somewhat biased? I consider myself pretty hard to impress, but jQuery has earned my vote and I’m sticking by it (at least, until something better comes along )

Amazon storage solutions have been a hotly debated issue recently at the Octabox water-coolers. My partner Adam believes that S3 is the best thing since sliced bread and I think its a lot hype but of no real value. The truth is probably somewhere in between.

Lets give Amazon’s service a head-to-head comparison with our hosting providers, ServInt:

Amazon:

• Provides storage
• Provides bandwidth
• Charges per request (Is this a new model? never heard of that)
• Sells books

ServInt:

• Provides storage
• Provides bandwidth
• Provides application and database servers
• Is a managed solution

I’ll focus on the storage and bandwidth, and consider the rest added value, starting by building several possible real-world scenarios

1. Small art gallery:
We’ll start with a small but not obscure art gallery. It stores about 12Gb of images and videos and transfer is about 200Gb.

At ServInt, the only choice is the essentials package (a bit of an overkill, but the cheapest solution ServInt has to offer). Monthly charge is fixed at 50$, barring any unforeseen sudden increase in bandwidth or storage. ServInt actually allows accounts to go over the limits, and charges for the difference (0.25$ per 1Gb bandwidth, 3$ per 1Gb storage).

At Amazon, the calculation is relatively simple:
(12 Gb storage x 0.15$) + (200 Gb traffic download x 0.18$)
+ (25 Gb traffic upload x 0.10$) + (800,000 GET requests x 0.01$ per 1000)
+ (100,000 PUT requests x 0.01$ per 1000) = 49$ and change.

The amazon charge is composed of ~80% bandwidth and ~19% requests.

* Get requests were derived from dividing the download traffic by the average high-resolution image size of 250Kb. PUT requests are based on upload traffic divided by the same image size.

Round One: Draw

2. The upstart video sharing community:
Those have been popping like flies recently. Supposing its marginally successful, storage is about 30Gb and transfer is about 800Gb. This time we’ll be taking the VSPro Deuce account at ServInt, which is fixed at 150$ per. The calculation for Amazon is the same as before, and it comes to 160$ and change.

The amazon charge is composed of ~95% bandwidth and ~2% requests.

* This time Get requests were based on the traffic divided by the average web-encoded movie size - about 3Mb.

Round Two: Advantage, ServInt

3. The up and coming social network:
XYZ Social network has been doing recently well, and has some plenty of users uploading and sharing photos and so forth, marking its current needs at 220Gb storage and 3,000Gb bandwidth. It requires a dedicated server, such as the simplest enterprise solution by ServInt, which cloaks at 500$ per. Again, calculating for Amazon we come to 1,021$ and change.

The amazon charge is composed of ~57% bandwidth and ~40% requests.

* This time Amazon exploded since I’ve put average user uploaded image size at 80kb (including thumbnails), increasing requests by a large factor over previous cases.

Round Three: ServInt by TKO

Excel style -

So what does this all mean?

First of all, it’s interesting to note that most of Amazon’s costs are bandwidth related. The other significant cost factor is the amount of requests - which becomes most pronounced for low size files, high transfer sites. In fact, storage costs on average comprised only 3.2% of the total costs!

Those figures support my view that Amazon is an expensive alternative to standard web hosting. Lets not forget, that the hosting packages mentioned actually include a hosting server, providing the backend to run the site. The only path in which Amazon seems like a viable alternative, considering their reputation for speed and reliability might be the heavier media types, such as video and audio streams.

There are some who would obviously dispute my conclusions, such as SmugBlog (marketing ploy?) and actual small blogs (not to mention my partner in crime, Adam)

Well basically not. However, we did get invited to hear about their Startup Essentials program, a promotion plan aimed at startups. The meeting took place at their local (Re: Israel) branch, which is located in a giant building complex in the commercial sector of Herzelia (Pituach). Calling it a building complex is actually quite literal - as we actually needed a map to find the right building, another mini-guide to get to the right floor, security doors bypass, visitors permit, auto-guiding laser turrets shutdown code… complex.

We sat down with a marketing executive in a ’small’ meeting room. I’ll comment now that despite the difficulty of finding their office, it’s pretty well stocked with fresh fruit in the lounge, big showoff SUN servers near the reception and so forth. The ’small’ meeting room was no different. I guess this is what being enterprise is all about

We exchanged business cards and introduced ourselves and what we do at a record time of 20 seconds (we are getting better at this). We then got to hear a 10 minute tirade of what SUN is in ‘general’, only it wasn’t very general at all with the marketing guy apparently going on in great detail about the architecture of their latest SPARC chipset and other technical jargon that was pretty difficult for me to swallow. I mean, I’m as technical as the next guy (by the way, I’m CTO here at Octabox ;)) but when someone tells you “Where were you 8 years ago? We at SUN were just coming with this great chipset / server/ OS thingamabob… “, you have to wonder. Oh, and 8 years ago I just finished high-school… Talk about a generation gap.

Ok, so what does SUN have to do with startups? A quick recap: In the .com bubble period, SUN grew tremendously by selling servers and services to startups who had a lot of VC money to spend around. The bubble proceeded to blow up, startups stopped buying SUN servers, SUN decided that startups aren’t good money and went on to provide servers and services to enterprise corporations. All is well, until youtube sells for 1.65$ billion to google, and shockingly enough, SUN has no foothold in this deal.
Are you shocked? Well I certainly wasn’t but apparently SUN executives process such worldly events differently. This great disaster prompted SUN to once again try to appeal to small startups, in the hopes that the next youtube will be using SUN servers and Solaris OS.

I have to say when I heard this story all I thought was how contradictory SUN’s attitude is to ours. Our motto is “Helping small businesses” - We think the power is with the people, so to speak, not with the money. Also, by cultivating small businesses and giving them great service you create loyalty - which will pay itself back when those small businesses grow to become big businesses. I could look at my partner’s face and see he was thinking the same thing.

So SUN now wants startups such as ourselves to see the light and bask in their obviously superior products and services. Awesome. So what can SUN offer us? Two things - Servers and Server OS. This all sounds great if we were in the server startup business. And while I’ve heard good things about both their OS and their servers, at the end of the day I rather leave such decisions to professionals - our hosting company. As long as I have the performance I need and the scalability options I want, it really doesn’t matter to me whether my LAMP based service is running on Xeon based redhat server or SPARC based Solaris server.
By the way, we love our hosting providers servint. Over the years we had several unusual requests and they never failed to provide. Their service and support are top notch, and other hosing providers should take heed - You are in the service business, not the serving business. Also, we just got a small bandwidth and storage bonus to our account for free, which appears to be an annual giveaway from servint. Again, service!

I have been doing some research recently on scaling and server performance, reading some interesting stuff about wikipedia’s setup and about comparisons between SUN and Intel based servers, which is all very informative - And this just reinforces my belief that when we have the funds, we will hire an expert to handle our scalability issues instead of trying to do everything ourselves.

It’s been almost half a year since our last post… We have been working hard and learned much.
We are getting close to the beginning of our seed funding round, our product is in closed beta with a public beta coming in about 3-4 months and things certainly look exciting.

We are restarting our blogging activities, and we have much to share with you about entrepreneurship, web development, startups, graphical design and more.

Stay tuned