Innovate with Google Maps and Google Docs

Have you seen IT companies websites recently? They doesn't seems like they themselves are aware of the true potential of Web 2.0. Here are few tips and trick to use when (re)designing your company website.

Company's Contact Us web page / Locate Us pages are simple static content with address. Hard to visualize and outdated, doesn't reflect company's diversity, even when the office addresses runs to the bottom of the page. You should, at that point, think back and check whether the website represents company's brand.

Here is an example to spruce up the company's contact information. Company website is the first point of entry for a customer where he would like to visualize about company's capabilities to do certain things. What is far more amazing is that you doesn't need to be a Javascript or web designer guru to do this.




Doing this was so simple in Google docs, that all I needed to do was to enter my fake company's address in one column and contact information in another (Okay, I cheated I used little bit of HTML to make contact information look good). Than I selected the range and told Google spreadsheet to insert a Google Map gadget. Once I am done customizing the gadget I asked for publishing URL and whoof!! I got this beautiful looking Google Map representing my company's location. I could have done far more innovation had I have been used Google Maps API.

The possibilities are unlimited but you have to open your mind towards them.

Grails - A RAD framework

During my quest to learn a new framework I stumbled upon Grails. I have heard about it very often but actually never dared to dive into it thinking that it might be yet another scripting framework like Ruby. But I was wrong and I must admit that I was mesmerized by what I saw (read it as "with What I achieved") in Grails. On the homepage of grails it says "the search is over", its a bold statement to make, but quite frankly it will make you feel like it when you start discovering its power. 


It is actually what Java should have been if it would have been written in 21st Century. The ease with which it helps you handle MVC architecture is great but what is amazing is the ease with which it handles CRUD operations and performs things with "convention over configuration" approach.


Long back I was wondering when a programming language be written which can understand plain simple English and performs the tasks. Grails does it and does it pretty good, no wonder it has developed so many followers. I mean who would not want to get away from reinventing the wheel all the time and just concentrate on building some lean mean applications.


The Grails community is also shaping up pretty well with so many plugins supported each day, I can only assume that this is the next generation framework. Do check back after some time as I will be publishing my first hand experience on Grails very soon.

CSS: Using every declaration just once

While surfing for best practices on Internet, I found this article on Google code site. It was an interesting article which was mostly directed towards web developer, but since j2ee deveoper also do some sort of web deveopment, I thought it will be a good idea to share with you guys.

Author: Jens Meiert, Google Webmaster

Recommended experience: Working knowledge of CSS

Original Site: http://code.google.com/speed/articles/optimizing-css.html

A logical way to make your website faster is to make the client code you send to the browser smaller. When looking to optimize your CSS files, one of the most powerful measures you can employ is to use every declaration just once.

Using every declaration just once means making strict use of selector grouping.

For example, you can combine these rules:

h1 { color: black; }

p { color: black; }

into a single rule:

h1, p { color: black; }

While this simple example appears almost obvious, things get more interesting and harder to quantify when talking about complex style sheets. In our experience, using every declaration just once can reduce the CSS file size by 20-40% on average.

Let's have a look at another example:

h1, h2, h3 { font-weight: normal; }

a strong { font-weight: normal !important; }

strong { font-style: italic; font-weight: normal; }

#nav { font-style: italic; }

.note { font-style: italic; }

Applying the "any declaration just once" rule here results in:

h1, h2, h3, strong { font-weight: normal; }

a strong { font-weight: normal !important; }

strong, #nav, .note { font-style: italic; }

Note that the !important declaration makes a difference here. There are some things to keep in mind when applying this method:

First, overly long selectors can render this method useless. Repeating selectors like html body table tbody tr td p span.example in order to have unique declarations doesn't save much file size. In fact, since "using every declaration just once" might mean a higher number of selectors, this could even result in a bigger style sheet. Using more compact selectors would help, and would enhance the readability of your stylesheet.

Second, be aware of CSS regulations. When a user agent can't parse the selector, it must ignore the declaration block as well. If you run into trouble with this, just bend the "declaration just once" rule - and use it more than once.

Third, and most importantly, keep the cascade in mind. No matter if you're sorting your style sheets in a certain way or are very relaxed about the order in which rules appear in your style sheets, using every declaration once will make you change the order of the rules in one way or another. This order, however, can be decisive for a browser to decide which rule to apply. The easiest solution if you're running into any issues with this is to make an exception as well and use the declaration in question more than once.

Alas, this is not always trivial to implement-this may change the cascading order and require a different workflow.

Workflow

"Using every declaration just once" requires more attention when maintaining stylesheets. You will benefit from finding a way to track changed and added declarations to get them in line again. This is not hard when using a more or less reasonable editor (showing line changes, for example), but needs to be incorporated into the workflow.

One way, for instance, is to mark rules you edited or added by indenting them. Once you're done updating your stylesheet, you can check for the indented rules to see if there are any new duplicate declarations, which you could then move to make sure each one of them is only used once.