Cacheismo learnings

I already knew lua, memory management, writing servers and other technical bits. I did learned the automake stuff to make sure people can compile it.

But the best part was something else. Marketing. I guess I failed miserably at that one. I don't know if anyone has downloaded cacheismo code and tried to compile it or is anyone using it. I think it is one of my best works and it is free and I don't know what more do I need to do to convince people that it is better that memcached.

I tried the following:

• I wrote a mail on memcached group explaining cacheismo.
• I wrote to author of highscalability.com blog. He was kind enough to include a link. 
• I created cacheismo google group. Only my friends joined. (Thanks!). No questions so far.
• I tried to answer some of the questions on stackoverflow about memcached. I looked at problems which people face but can't solve with memcached. Tried answering the questions to best of my knowledge and also provided information about how it can solved using cacheismo. Someone removed all my posts :( from stackoverflow. 

So I guess even if their exist people who might find cacheismo useful, it is kind of impossible for them to find it, unless of-course they magically search for cacheismo on google.  So the question is what is the plan? And the answer is nothing much. I am not actively working on cacheismo. I will be more than happy to help anyone who wants to use it.  I need to solve the discovery problem and the plan there is to keep posting to stackoverflow...until the person who deletes my posts gets tired of it. Quora is another option. And may be some videos on youtube.  

May be caching is not such a big problem for people and memcached is good enough. Well in that case I will write some more servers. Http Proxy something like haproxy but configurable in lua might be fun. Or may be websocket server for HTML 5 applications.  

Loan or Subscription

Some things are expensive. If sold only at their price points, they would have a very small addressable market. Even if they are useful, even if they would provide move value over time than what they cost, making a choice to buy them is fairly hard.

The first solution to this problem was delayed payments. Companies will allow customer to settle bills later, helping them in maintaining cash flows. The second solution was loan from banks and the latest one is credit cards.  All these mechanisms allow customers to have something of value now and pay for it later (hopefully realizing the value of the thing they purchased). But the risk of not being able to realize the value stays as the purchase is not reversible.

In my opinion the best solution to this problem is service model, pay as you use. Many of the severs used in companies have vanished. The email server, the content management system, the svn repository, etc. We have gmail for email, google docs for content, github for svn and all of these are on services model. 

I guess subscription helps in figuring out the "price" of something. Figuring out lifetime value delivered by a product is hard. By forcing ourselves to think about value of something in a month, we have better chances of falling in range that is acceptable to the customers. The second benefit is frequency of choice. We give our customers every month a chance to stop using us and selecting someone else. This has two benefits. One it makes decision making simple for the customer and second it brings focus to the company because we need to keep "selling" ourselves, keep delighting the customer, to be in business.

Software is not the only thing that can be sold as a service. Almost everything can fit in this scheme of things. If you are selling something expensive that provides its value over time, subscription is your best answer to "barrier to buy".  Product/Service is a superficial packaging over the value you provide. Package your value the way it makes sense for your customers.

Life is not a game

In a game either you win or your opponent. In life, you may both win and you may both loose or the usual gaming rule apply.

Relational DB and Objects

Strange observation.

DB's mature over time and adapt to new requirements much easier than code. Code breaks from release to release and after some time needs major changes to keep in shape.

Relational DBs are more Zen compatible - A is A and A is not A. Code is usually not so flexible. More strangely, relational db's are less flexible (schema, everything is table) and ends up being more flexible whereas code is flexible (extend, copy-paste, interfaces, override) and ends up being inflexible.

Wonder, if we could associate code (C, Java, PHP) with tables/columns or joins and write our web applications in SQL.  Immediately all the hashmaps and arrays become moot. No for/while loops just select/where.  It becomes so much easier to create as many views as you like which are consistent by writing new SQL queries.  If queries can be named, they can be used as first level objects for creating higher level queries.  Empty tables that only have code associated with them but no data, can be used for providing all the decoration or access control or mappings.

I haven't seen something like this, but I do think that it is very much possible to build. With all the ORM tools and frameworks we are almost at the point where talking to DB is almost automated. I guess all I want to say is that SQL is probably a good framework for not just managing data, but also code. Lets give it a shot.

The Ambulance Lane

Hardly a day passes by when I don't see an ambulance screaming on the road while coming back from office.  In spite of all the good intentions of the frustrated drivers, most of the time ambulance is stuck with rest of the traffic.

I think one way to make things a little better would be fix say the left most or the right most lane as the virtual Ambulance Lane. The idea is to align the good intentions of people so that instead of randomly deciding how to give way to ambulance, it is pre-decided for them. How does it help? Lets say we decide right most lane to be Ambulance Lane. If you hear Ambulance and you are in the rightmost lane, move to left and make the right lane free.  If you are not on the right lane, make space for vehicles on the right. If you are in the rightmost lane and you can't move to left, honk, put on your parking lights and jump the red light. That is it.

As long as people follow this one rule, I am sure we could help more Ambulances reach hospitals on time.