Its a huge huge step in my life – something I’ve always dreamt of ever since my college life – working for myself!
What I’ve always seen practically happening is once you burn the bridges, there’s only one way to go – and that is move forward!
That said, I still have butterflies in my stomach – but this time, I’m more determined than being scared of what’s in store for me.
Bring it on… head on!
The past few years have been a complete roller-coaster ride! With each passing year – I was getting closer to my ultimate objective.
2009 & 2010 were the magic years when things started going really well. My single minded objectives for 2009 included getting aboard full time, getting INR 1M in profit for the year, moving into a full time office, etc. As it happend, our (then) experimental idea AdoMado.com also sprung to life in 2009 – and was selected as top 10 finalists for IIMA BPlan contest. We met some really good folks & finally partnered with them to bring into existence – AdoMado.com, the AppStore, Custom Toolbars, etc.
Today, as I look back at the objectives I had set for myself in 2009 – I feel glad that each one of those objectives were achieved in 2009 & 2010. It took us (& me personally) 2 years to achieve all of them – but we did it.
2010 was also a wonderful year for me personally. I found the love of my life in Kanika. We committed in Feb 2010, got engaged in June 2010 & got married on 13th November 2010. I love you Kannu!
As I start the new year 2011, I want to thank my family for being there when I needed them the most. Now with Kannu by my side, there’s nothing out of my reach. The destination may be a bit far… but hey, isn’t the journey worth more than the final destination?
More about my objectives in 2011 to follow…
I recently had to add a CSS header to a lot of AdoMado Apps. This is how I managed it…
$ for file in `find ./ | grep html` > do > sed -i 's/original word/new word/' $file > done
Ever wondered how can you have something like this
<% some_helper do %> Some text here <% end %>
Well, here how it is…
def some_helper(&block)
content = capture(&block)
concat("this comes before the block", block.binding)
concat(content, block.binding) # adds "Some text here" to the view
concat("this comes after the block", block.binding)
end
Neat! Isn’t it 
The offers that we run at AdoMado.com are of three basic types – Exclusive offers, Deal A Day aggregation and several more interesting offers sponsored by our partners.
AdoMado.com Offers
A few days back, I woke up to a terrific morning, only to notice that my inbox had several “downtime” alerts. I quickly checked and realized that a key/value pair in our memcached had suddenly grown beyond 1MB. Since memcached supports maximum 1 MB of data per key – hence the problem.
I quickly tried to see if I could increase this size limitation – but soon realized that if keys are growing beyond 1 MB, we are not doing something right. And I think I was correct.
What happens is – the 3rd party offers which we aggregate are stored straight into memcached – ie., there is no DB interaction until an offer is actually used. This allows us to treat these aggregated offers as transient data. Also, since the offers change daily (some weekly/monthly) – it made perfect sense to treat them as transient data. So when memcached b0rked, this data was 1.5 MB in size.
Solution was simple – break the big key into several multiple keys and then use the master key-name to fetch all the keys. Hence without changing much in the codebase, I applied this solution – and voila! – we had fixed the problem. Each of the keys are now about 100 KB in size.
Now we don’t have to do this complete 1MB I/O whenever we want to render our offer pages. We fetch and render just what we need
Lessons learnt
- Memcached keys are limited to 1 MB in size.
- Store and use only what you need.
I think this I/O will be almost negligible when I merge the caching branch into master. I’m trying something very unique – page caching, while still maintaining the dynamic nature of the page – using jQuery and HAML – project Puncture (as it punctures holes into your page cache). Stay tuned for more on it
sudo dpkg –configure -a
I’m still running this… lets see how my new Ubuntu 10.10 Beta install fairs out…
Seems like the problem is with how ATI graphic drivers are updated. Please consult http://www.redshirtlinux.com/?p=239 before installing Ubuntu 10.10 Beta
Now this is going to be fun!
Just because you can say something, should not mean you should say it.
When you are in a relationship, don’t intentionally say something which can hurt the other person.
But does that means you should not express yourself freely? – Well, no! There can be 10 different ways of conveying your point across. Though, fastest ways aren’t always the best ways.
That said – love you always.
Faster HTML and CSS: Layout Engine Internals for Web Developers (@GoogleTechTalks)
I think I never cared about these – but the way David Baron from Mozilla describes these, I think I will now.
The points he was making started seeming so crucial that I jotted them down as if taking notes – something I never did with previous videos.
The things which I picked up from this video are…
From fetching the DOM over the wire to displaying it, following steps take place in order…
(1) Compute => (2) Compute Style => (3) Construct the DOM frame => (4) Layout => (5) Paint
The further Left (towards (1)) you push the browser’s rendering engine via your DOM/JS/CSS, the slower the browser would get.
Hence…
Use as specific CSS tags as possible. The more generic tag, the higher performance hit while searching the DOM. For example, a “#some-id {}” is way way faster than “body > div p {}” – as in the second tag, a larger portion of DOM is parsed to check which elements are affected by the selector. You push the browser to start from stage (2).
“:hover” style hits the browser pretty badly – as it pushes the browser back to stage (2). Coupled with the above mentioned CSS selectors problem, it can lead to real slow computation. Use it with CSS selectors which are very very specific in nature.
Programmatic scrolling of tags (some of which might have overflow property) via javascript – as that does not causes re-computation of style (stage 2). While if you do it with CSS magic, you push your browser back to stage (2).
Mozilla’s rendering tree, while building itself – does not takes any element with with CSS property “display:none” into account – it just skips it. So when this property is flipped, it triggers a full re-computation of the tree – which is expensive. However if we use the style “visibility:hidden” – the rendering tree picks up the related element while building itself. Hence when visibility is flipped, its much faster as there is no re-calculation of the rendering tree.
An old one – when javascripts are being downloaded, the browser stops itself from any other processing and waits for the script to download and execute (as script can modify the DOM anyhow it likes). During this time, the precious time is lost – which could have been used in downloading other content – like images, DOM, CSS, etc. Hence – keep the javascripts as further in the DOM as possible. Use caching is possible.
Learn more about speeding up your website at – Yahoo’s best practices (YSlow stuff) – some of which we regularly follow at AdoMado.com
Found a great video on youtube today…
Link: www.youtube.com