Vlad Mazek – Vladville Blog

All the Shockey Monkey activations that were requested until today have been put into the provisioning process. So if you’ve ever applied for Shockey Monkey and never heard from me, it likely got eaten by your SPAM filter. Please reapply and whitelist ownwebnow.com domain in your app.

There are only two reasons why someone would not get their application accepted:

• Submitted an email from a freemail system
• Web site or organization does not exist

So if you sent me an email from aol.com, msn.com, gmail.com, yahoo.com, sbc.com or any other freemail system the message has been destroyed. System usually does this automatically, I wish I could reply to them all but there are so many form spam bots with those addresses that its impossible whats legit and whats fake. So use a business email address. Second reason for being denied would be the lack of a corporate web page. If I can’t tell that you have an online presence, I can’t extend the service to you due to some long standing legal concern. When/if that changes you’re welcome to reapply, I frankly don’t see these as big roadblocks to any established IT firm.

So there is currently 0 backlog, everyone that wanted it (and met criteria above) is being taken care of – if you aren’t, hit the app again after you whitelist me.

Thank you for your phenomenal, awesome and amazing support. 

The pace of signups for Shockey Monkey is picking up for some reason. I don’t know why but I am guessing that the people using the monkey are really enjoying it and are recommending it to their peers – for that I thank you and I am very happy.

I’ve taken a moment to write the following document that explains Shockey Monkey activation process. As you can tell, it’s quite simple.

The big secret..

I know what you’re thinking: “Big Bad Vlad the service automation programmer sure can’t automate things worth crap.” – So I’ll let you in on a little secret. Yes, this can be automated quite easilly. However, by making people jump through the hoops of updating their contact information, updating their corporate information, ordering a service, creating a new contact, updating and reviewing the support ticket and more I am effectively training the future administrators of Shockey Monkey on how to use the product. Yes, you can watch the video all you want and read the documentation but after you’ve been put through the paces you get the feeling for how the platform works, events and triggers, and by the time you’re in your portal you already know how it works, most importantly, you know how your clients are going to view this new thing you’re offering them.

So you see, sometimes a lot of thinking goes into seemingly stupid decisions.

Now that a lot of the logic behind Shockey Monkey has been solidified I decided it was time to optimize the interface performance a little bit. Truth is, there is a lot of minor updating that goes on behind the scenes that should not be calling for the entire page to be reloaded. Enter AJAX.

I was talking with Pablo the other night about XHR and told him I was trying to use Script.aculo.us libraries but couldn’t really wrap my head around some of the stuff. So he showed me his blog which is tricked out with the Yahoo UI library (which I find ugly but to each his own) and explained to me how the whole thing works. Funny how its thing fall into place when someone explains it to you.

So for the past day I have been Ajax crazy trying to nail down some of the effects and events. One of my cornerstone values for Shockey Monkey is that it be lightning fast. If I have to wait to get or input data I’ll open up Notepad (used to be Outlook before 2007 started getting non-response-happy all the time). And even though its a web app I have to say that I’ve really done a good job at keeping it very lightweight and fast.

Speeding it up by slowing it down…

So the AJAX premise is that you can speed up the interface by doing partial page rendering. The smoke and mirrors of it is that in order to enable all the cool effects, events and transitions you have to load up a very hefty Javascript file (mine comes out to about 268Kb).

So yes, the partial screen rendering will be very fast because I am only loading some text into a <div> but what happens when they go from page to page? You’ve guessed it, JS reloads. Because the documents themselves change often I have a no-cache directive for the entire page meaning every time someone clicks on something that triggers the page reload the entire mountain of javascript gets pushed down. Click through four pages and you’ve pulled down over 1 Mb which would effectively make the entire web app crawl and put quite a sticker shock on the bandwidth bill at the end of the month.

Guessing the right Google search string…

There is no way that Google, Yahoo and all the other big league Web 2.0 players are constantly pushing down megs and megs of data during each session. Let’s face it, the events and effects code is in libraries which will rarely be changed so why make it take the pipe trip every time? After a  little bit of searching I found a way to do selective javascript caching from Ajaxian. The answer is actually in the comments but the question is outright scary:

Our users have to download a 2MB ajax application every time they visit our website. It would be much faster if we could cache 90% of our application in the browser cache using this LRU Cache so that the next time the user visits our website, they only need to download a small 10K file!

The answer comes further down from Vasili Sviridov:

    ### activate mod_expires
    ExpiresActive On
    ### Expire images and javascript 1 month from when they’re accessed
    ExpiresByType text/javascript “access plus 4 weeks”

Dumping that into the .htaccess file to override default server config (hi Schrag) takes care of the problem completely. Just have to make sure you’re sending your Javascript as text/javascript and not part of your inline text/html page code and voila.