Friday, June 26, 2009

    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

    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.

    Sunday, June 21, 2009

    Unit Test Helper

    Working on JUnit is fun and great but always remember a golden rule "Never change a good design just to make it accessable/runnable by JUnit". Let me elaborate on this statement to tell you what exactly I meant. In our code we write data access layer, which creates connections and execute sql.

    Specially in Web Application, connections are often managed inside container and are accessed by our code using JNDI. This is one of the industry best practices. Problem is how to test that code outside the Container. How to make that code JUnit accessible.

    Normally we might make some changes in our code in order to make JUnit run outside container, DON'T. With the above statement I meant these kind of changes specially. But the question is what is the solution for this situation. Should you leave that code untested? No, you can still test that code. And I am not going to talk about any new testing methodology either. You can test the same code with simple JUnit.

    This is made possible a small helper jar called JRUnitTestHelper from Java Ranch. This junit utility helps create JNDI based datasources and connections at the run time to assist junit test the code efficiently.

    Using this jar is very very simple, put this jar in your classpath while running your junit test and call these two lines

    if(JNDIUnitTestHelper.notInitialized()){
    JNDIUnitTestHelper.init("jndi_unit_test_helper.properties");
    }

    And of course please mention your connection details like IP, port, username etc in this "jndi_unit_test_helper.properties" properties file. Please feel free to shoot me emails if you have any questions.

    Wednesday, June 17, 2009

    Google Maps

    Google Maps is an interesting feature which most of us have used in some way or other. Either to find the way to a friend's new house or to locate a Pizza joint near our house. It helps and it sure do but what is interesting is to learn how to use this in our Applications to make them more user centric with all other Web 2.0 concepts.

    Let me start with giving you some examples, you go to a Bank's website and click on Locate an ATM link. It takes you to a page where you select a state from a drop down (Eeeaaakkhhhh!!!). The selection than loads another drop down below it with the city information (Double Eeeaaakkkkhh!!). You than select your city and the page is refreshed with 50 entries and their address. Now its your job to figure out which one is the nearest one and in most cases you doesn't even know your neighborhood else you would not had to use this service. Now as a Web developer how can you make this easy and interesting for the user. How about using Google Maps for this? Nope I am not kidding you can integrate Google Maps with your application (For FREE!!). Check out Google Maps API it have very interesting example and usage.

    To see a live usage you can goto my other blog Varun Smriti Udhyaan. It is a very flexible api completely usable using javascript technology and allows you to be very creative in finding the usage. Check out the examples and demo provided on Google Maps API page.

    Be Creative...

     

    Site Info

    Text

    Java 2 Enterprise Edition Copyright © 2009 Community is Designed by Bie