02.03.12

Batch Source Formatting in Eclipse Indigo

Posted in Blogroll, News, Tech at 5:41 am by Liv

This has been bugging me lately — how to do a batch formatting using Eclipse!

If you plug things like Checkstyle (and PMD to a certain extent) in your project build, you get bugged every now and then when someone else makes a change with stuff about tabs/spaces, brackets being on the same line or not, line being too long etc etc etc. Typically what you do in this instances, you just open the file in Eclipse, and a simple Mac+Shift+F (or Alt+Shift+F on Windows) automatically formats the source and you’re good to go!

However, what do you do, when you see a Checkstyle report reporting 100′s of issues across say 10-20 different files? You could of course set off to process every file manually — if you have the time! — or look for a way to do this using Eclipse in a batch manner. I personally opted for the latter — and this is how to do this using Eclipse.

Read the rest of this entry »

Permalink Comments

Disclaimer

28.10.11

Customizing Squirrel Mail Login Page

Posted in Blogroll, Tech at 1:44 pm by Liv

For those of you who are using SquirrelMail, you might have noticed that it looks a bit well, let’s just say amateurish That doesn’t go to say it isn’t a good package! (I personally love it and I think it does a pretty good job — hence my additions to this software.) However, as every open-source package in its early stages, there is still a lot more to be done to get it to a stage where it works beautifully and looks just as good! If you have been using it for a while chances are you have already installed some of the plugins and configured them to your needs. Some of these plugins as you know allows certain visual customizations to SquirrelMail to make it look more pleasant to the eye.

It is one of these plugins that captured my attention, as I figured out straight away it will allow me to customize the login page! And here’s how:
Read the rest of this entry »

Permalink Comments

Disclaimer

28.05.11

Java vs JavaScript?

Posted in Blogroll, Random Thoughts, Tech at 10:31 pm by Liv

The title of this post was intentionally chosen to raise some eyebrows – after all we all know that in most cases (I’m taking the likes of Rhino out of the equation, same for applets) the former resides on the server side while the latter is used as a client-side language. So why would someone have a go at comparing them?
I guess the post really is more about questioning whether we should move most of the processing on the server side or whether it is a good idea to leave some of this to the client side.
Let’s start with some basic example: showing the user the local time and date. (By local I mean local to the user!) If we intend to do this server side we’ll do something like this:

Date d= new Date();
DateFormat df= ... //prepare the format we need the user to be in
//we might also take into account the user is in a different timexone and add or substract hours etc
out.print( df.format(d) );

At this point we have created 2 objects in the server JVM which will be discarded once the response has been sent back to the client – and as such the objects will be subject to garbage collection. In an application when we get tons of such requests we are putting a lot of stress on the system’s memory recycling as we’ll end up with lots of memory that needs to be reclaimed very often. Let’s look at the solution that involves JS:

<script type="text/javascript">
document.write( new Date() );
</script>

That’s it! No extra memory consumption on the server, no extra cycles needed for computing timezone differences, or formatting the results! Even more since the above contents is static, you can offload that to a simple Apache instance to serve the contents and take the burden off your application server. And if you need to compute the user local time for instance – you could as I said have a function which based on user profile settings adjusts the local time and stores it as an attribute in the user session – or you could use some JavaScript to create an instance of Date then pass that to the server side via a simple Ajax call (and from there one once you get that date you just store in the user session and use it as before). It’s interesting to see that simple things like these are still done in a lot of cases on the server side – and there’s hardly ever a clear reason for it, but even though computing user local time might only take a couple of variables and only a few CPU cycles, multiply this by 1,000′s of users and all these small numbers add up.
Another example – which is common in the web world is writing back to the user a message comprising of a concatenation of a few session variables – for instance if you say open an email in your web mail system the header might show you something like this: “received from John Doe (john@Doe.com) on 1/January/2011″. Looks simple enough and any server side developer will probably use a string templating mechanism (String.format, Velocity engine etc) and pass in the sender name, email address and sent date to produce this script-nothing unusual about this. But under the cover in this example you will employ 4 strings (the template, sender name, sender address and sent date) and based on these you produce a 5th one which gets displayed to the user. But what if you take a different approach and you just dump just 3 of these variables (sender name, email and sent date) to the page in a format your JavaScript can “understand” (eg JSON) and let your scripts concatenate these and present exactly the same message to the user?you’d argue that really this only saves you one string – and in this example it is true- but think now how many other things in your app can be changed like that so you don’t create an object to serve just for the purpose of that request? If we look at the above example what if your application shows customized buttons like “reply to john Doe”, “archive john Doe’s message”, “report john Doe’s email as spam” – all of these messages are created server side for each message you view, and while the memory consumption is small the fact that there are loads of them means your GC will work pretty hard to recycle these. Looking at the above example for the message and buttons you’ll end up creating (and then dumping) 4 strings for each email viewed; taking the approach I’ve described means you don’t create any!
I do accept the argument that a web based mail system needs to be used by a variety of clients – some which might not have JavaScript support – in which case you can’t avoid building everything server side. But there are a lot out there which only target and require “modern” browsers – and as such this approach would work just fine.
Historically a lot of the processing has happened server side to separate the business logic from the presentation layer. Also at the same time initially JavaScript support in browsers was rather poor and not standardized. But I’m not advocating changing the business logic to the client side – in fact everything I talked about earlier on us only to do with the presentation layer! Also let’s remind ourselves that browsers made a huge progress when it comes to JavaScript – after all we have nowadays frameworks like JQuery and prototype and Scriptaculous working cross browser and taking care of everything else for you, we have browsers that even though need a few hacks here and there do support largely the JavaScript standards. So if you know your clients, and even more if you can enforce it (and most corporate products can enforce this – by rolling out ie9+ across the enterprise for instance) then it’s worth wondering yourself if you might not be better off changing some of the way you do things in your app and allow some more processing on the client side? After all browsers and PC’s have come a long way and asking the browser to do a bit of string concatenation is nothing nowadays and the speed difference from doing that server side or client side are negligeable. And if you can offload some of your processing server side to another component (be it the client browser) then you should. I appreciate that saving 4 megs of RAM is not much nowadays – if anything it’s too much hassle to chase for that memory! – and if at first glance all you can get from your web app is save some memory then moving things client side is not benefit you that much. But if you reduce your churn rate of new object creation then that is a major achievement – because your GC will kick in less often for once and you’ll have less time spent for “kitchenware” and more time spent on what your app was designed to.

Permalink Comments

Disclaimer

11.03.11

Bandwidth – reloaded

Posted in Random Thoughts, Tech at 1:59 pm by Liv

I’ve posted before about bandwidth in my posts and I knew from the beginning that it’s one of those issues that you can never exhaust. As it happens recently I came across another interesting thing which is probably worth sharing: cross browser delivery. In brief, it means delivering to each browser the content it can “understand” and more to the point display.

Sure it is easy to deliver the same content to each and every browser – it means you don’t have to do any browser “targeting”, and as such your code is easier to maintain and write. It does mean however you are pumping out quite often a lot of content that browsers will have to ignore as they cannot display it. For instance, some of you might not know this but there are a few text-only browsers in the unix world (mainly lynx or elinks) that have been designed to work for instance in a text console — they have no capabilities of displaying images, flash movies, quicktime etc as typically the container they get launched in doesn’t offer anything but text (think old-style green terminals!). You’d think that there is no point for someone to use these browsers and in most cases you’re correct, but imagine this: you’ve ssh’d into a server and figured out you need to download a patch to some component. You got 2 options:

1. browse the net on your desktop using a “proper” browser, download the patch locally and then upload it onto the server to apply it
2. use the likes of lynx on the server directly, google and find the patch, download it right onto your server and apply it

The latter surely is not the most user-friendly experience but it has the advantage of typically being fast: if your server is in a data centre it will quite likely have a fast connection and since it is a server by definition it is more powerful than your desktop machine so more than likely the download will complete in an instant. On the other hand, in the case of the former, the initial download onto your desktop is guaranteed to be slower as it will go through your office internet connection (I don’t know of that many companies that have a gigabit connection from their office!) and on top of that you have to then take the hit again to upload this onto the server through the same (slow) office connection. And if you have to jump through another machine to reach your server you have doubled the hassle for the sole purpose of avoiding using a text-based browser!

Don’t get me wrong, I don’t think anyone in their right mind would actually use one of these browsers all the time – but they do exist and are occasionally used, and as such you’ll probably find you get occasional hits from them. And chances are each time you reply with the same JavaScript block (that gets downloaded but not executed), or flash content, image etc only so the browser can ignore it. On average you’ll probably get about 0.5 to 1 % of your hits I would say based on previous observations, though there are of course variations. That’s not a big percentage but it can add up to big numbers depending on the size of the site your solution is running on: on a site with a daily average of 10,000 page views a day (and this isn’t by any means a big site – 300k page views a month isn’t a big number at all!) about 100 requests will come from these sort of browsers, and with an average response of say 5k (though I’m guessing the reality is higher than that if you have graphics etc as it will probably some up to about 30k or so) you are wasting daily on this site alone 0.5 MB. Doesn’t sound like much, but if you’re dealing with say 20 sites (though again, in reality, if you’re an average advertising solution you’re more likely to deal with at least 100 of them) that means 10MB a day wasted for these browsers alone.

I might have mentioned the next issue before but it’s worth re-itresting it: web spiders! (These only apply if you’re a company providing online services for sites, not if you’re a website yourself, in which case web spider traffic is useful for seo reasons.) Ask yourself: do you really need to return any content to web spiders? Does that bring you any benefits? Would simply return HTTP 200 (OK) with zero length content not suffice? If you are not providing any response to the spiders that will benefit the site (in terms of search ranking etc) than it won’t benefit you in anyway either returning that content! and bearing in mind that an average spidering happens once a week but across the whole website you might be saving yourself some bandwidth! If we consider the same average of 5k per response and a site with about 500 pages (again I’m being very conservative here!) each spider visit would see you waste around 3 MB per web spider a week. If we consider only the major 4 spiders (Google, Bing/Microsoft, Yahoo and Ask) we’re looking at about 12 MB every week per site. Times that 20 (sites) and you got approx 1/4 GB in w week wasted! Add the other 300 MB and rougly 1/2 GB a month are just wasted. And if you’re paying for your outgoing traffic from your datacentre you will probably find you’re wasting some money as well – not to mention the hidden cost of your servers actually processing the requests, entries probably stored in the database and so on.

Another thing to take into consideration is Flash support. With the increasing demands for user interactivity in the advertising space nowadays it’s pretty rare to find non Flash ads on websites. If your solution is involved in this chain of advertising delivery then you will have to start looking at whether the content you are pushing is compatible with the user browser — in this case for instance does it support Flash or does it support the right version of Flash? Obviously in most cases you would employ some JavaScript and with the help of the swfobject library you would find out and have a second hit requesting the right creative for what the browser supports – it is a standard mechanism of delivery of Flash. That is because normally you can’t determine Flash support based on browser headers — but how about the mobile phones traffic? You can have a pretty good idea of what type of mobile it is based on the user agent, right? And most of the handsets don’t support Flash and even though they do support JavaScript it doesn’t make sense to use the same mechanism, knowing upfront that Flash is not supported. Why not instead just deliver upfront the non Flash creative? (I.e. static graphic and link) with your average Flash creative size for a sky scraper around 30+ KB and an image of the same size going around 15 KB (half size) you’d be halving your bandwidth consumption for mobile traffic! With some sites getting up to 20% of their traffic from mobiles if you consider the above example again you’re looking at 2,000 requests a day being mobile traffic. And based on the above figures it means for these requests you’ll be wasting 2000 x 15KB=30,000 KB (30 MB) a day – so more than another half a gig a month.

Come to think of it you might want to check as well whether your solution does need indeed to deliver to mobile handsets? If it doesn’t, just blocking those requests and not returning anything saves you another 600 MB or so! Oh and by the way, that would be per site – multiply this by the 20 sites you’re working with and the figures will start being more substantial!

I’m not going to end here as more than likely there’s more to the bandwidth saga than this – I will however take a break for now. Till next time I write about it, watch your bytes!

Permalink Comments

Disclaimer

15.11.10

Server side developers

Posted in Blogroll, Random Thoughts, Tech at 1:13 pm by Liv

OK I had this post in my mind for a while now — the only reason I’m publishing it so late is because it started initially with just small nags in my head about server side developers and I thought at the time one small nag from me hardly constitutes enough reason for a post. Since then though I guess you could say I’ve got a few more “nags” to add, hence finally this post

The reason behind it is the continuous specialization of developers in today’s world — mostly understandable, as the explosion of technology nowadays makes it very difficult for any developer to be a generalist. And as you know, we have nowadays (amongst many others) the 2 types of “breed” of developers: the front end and back end developers. And you probably know that in most cases the backend ones tend to think they are the better breed — as they do the “complicated” business logic stuff. However, what I hate about this “breed” of developers it the fact that even though they claim to be better than the front end developers they run shit-scared of simple things like JavaScript, CSS and HTML!

It even amuses me when they come up with comments like “JavaScript is so difficult!” or “CSS is too complicated for what it’s worth” and the likes. First of all, the syntax of JavaScript is right there with Java — we are talking the basic syntax! We’re not talking interfaces, inheritance, polymorphism and so on — because in most cases, as a server-side developer, you are unlikely to be asked to dive in the deep end of JavaScript client-side processing — more likely than not, you will be required to “deal” with some basic JS code in order to identify/fix a bug somewhere in the chain frontend – backend – database. As such, no one would expect server side “gurus” to know JQuery, or Scriptaculous etc — though from my point of view, if you truely are a really good backend developer, you surely figured by now that your backend cannot work alone and as such there’s always a frontend as well; and if you want to make yourself really useful and raise to a challenge then I’d say you should make yourself not familiar with these front-end libraries but even half-decent in using them. (Let’s face it, you will never be asked to write/debug JQuery plugins for instance, but instead you will be asked to deal with some code that maybe uses some of these plugins — and surely reading a page on the JQuery website with the help information and being able to understand the calls that use that plugin is not too much!)

So bearing in mind that like I said a lot of the “fancy” stuff is taken out of the language and you’re stuck with Java-like syntax, what is difficult to understand? The DOM/DHTML processing bits? Let’s see…

document.getElementById("...")

right? You mean you haven’t done any XML processing in the backend and never heard of the DOM and the W3C traversal functions? Because it’s exactly the same API!

And if you’ve done some Java for instance and touched onto Groovy then even some of the more obscure things in JavaScript should be easily readable (yep, JS does have closures too — just done via functions that’s all).

As for CSS — coming from a language like C# or Java where everything is OOP and inheritance you cannot understand it? The whole idea of “cascade” really means “inheritance” as for the CSS properties, you can get them listed on tons of websites nowadays so shouldn’t be a problem understanding that.

So all in all, I don’t get it: if you are a backend developer why can’t you work front end or at least assist with debugging some frontend code? Is it not the case that those who take this approach are not actually developing anymore and instead are so stuck in a routine where they just apply “patterns” (be it for Spring, Struts, or any other framework) that taking them outside that set of patterns (hardly called development!) makes them totally useless? And if that’s the case should you not be worried, if you do have such “developers” in your team, that in fact you might be spending money on something that’s not there really?

Don’t get me wrong, I totally understand that “context switching” in between applications does imply a hit on productivity — as the developer will have to take a bit of time to re-acquiant himself or herself with the product they just switched on to. If this switch happens only rarely, I expect it to be quite significant (ironically, if you get your developers to do this more often the context switching becomes much smoother and there’s less and less time spent on this!) — however, few hours max into it I expect a backend developer to be able to pick on the JavaScript (and if needed CSS, HTML etc) and be able from there on to run with it. If that’s not the case, like I said, time to look at competencies. Either you’ve hired the wrong people, or you hired the right people but you’ve burden them for too long with boring, repetetive “development” tasks that they’ve been brain-washed…in other words you ended up with the wrong people having hired the right ones. Either way, you’re paying too much for your backend development and you probably need a re-shuffle in that department!

And having just written the above, I’m curious to find out at some point in the future, how many companies are going to start asking their backend developers during the recruitment process about their JavaScript skills

Permalink 1 Comment

Disclaimer