Improving Blogger Templates

"Content without the ability to communicate will simply stay isolated. So presentation is essential and it must be refined."

Define how you want to present it:

1. Can aesthetics truly be fluid? For the template of my blog, I want to design for certain ranges that appeal to me on an average mini notebook, an average laptop and an average desktop screen. I say that but I'm really aiming for the area that a browser's content window has available to it at any given time, While keeping in mind that there is the resolution to factor in because it can show more for less, so one has to take into account what an average user's eyes are comfortable with. Therefore, simply counting on the browser's dom/javascript variables that let me know the height & width in em (pixel measurements) should do very nicely.
2. I also want to experiment by empowering the user to have controls/buttons that can instantly change the browser size to one that offers the ideal sizes for more or less content to digest for the given website. I don't want to aim for the browser's resize event off the bat and even if I did, I would only make a change if the resize event crossed boundaries between two very wide ranges that I've set based on my "presenter" aesthetics.
3. Just as much as the reader for any content has preferences or tastes (consciously or subconsciously) for what presentation layout works best for them. The writer too plans on how to draw in the readers from the first glimpse, to the first pass, all the way to repeated use.
4. What's most important in this blog right here? 1st the content that brings users here and finding exactly what they were looking for, 2nd the widgets that let them have better access to the content. So what I want to do is define the ranges (first & foremost) based on the segregation of the content and the widgets.
5. What is the minimum width that my content must have to please me? I would say that I'm highly biased towards picking the width that the bloggers's edit window imposes upon me! Even with the preview option available to me, I tend to write within that constraint of 675 pixels and I'm always leaning towards cutting my content short to match that width in as beautiful and succinct a manner as I can.

Perhaps a poll is in order to get some real data on preferences.

Flex Compiler Constants

There is plenty of information on the web talking about how to specify constants for the Flex compiler so I've compiled a cheat sheet of the essentials:

• Constant values can be defined in main-config.xml for the flex/mxml compiler so that they don't have to be edited in eclipse preferences.
• Values for String constants should have quotation marks around them
  
  • Whether you are defining strings in your maven's pom.xml file to manage maven builds:
    <property>
         <name>MY_CONSTANTS::someStringConstant</name>
         <value>"Hello World"</value>
    </property>
  • Or you are using *-config.xml file to manage Eclipse builds:
    <define>
         <name>MY_CONSTANTS::someStringConstant</name>
         <value>"Hello World"</value>
    </define>
• Values for Boolean constants DO NOT need any quotations.
  
  • pom.xml
    <property>
         <name>MY_CONSTANTS::someBooleanConstant</name>
         <value>true</value>
    </property>
  • *-config.xml
    <define>
         <name>MY_CONSTANTS::someBooleanConstant</name>
         <value>true</value>
    </define>
• More to come...

Log4j: Log concrete and abstract classes

In the past I've often pondered how to get better logging when I'm dealing with abstract classes.

Let's take the following class struture as an example:

• SomeInterface
  
  • AbstractImpl
    private static final Logger logger = Logger.getLogger(AbstractImpl.class)
    
    • ConcreteImpl_A
      private static final Logger logger = Logger.getLogger(ConcreteImpl_A.class)
    • ConcreteImpl_B
      private static final Logger logger = Logger.getLogger(ConcreteImpl_B.class)

This usually results in logs like:

21 Apr 2011 DEBUG [main] (AbstractImpl.java:10) - the actual log message
21 Apr 2011 DEBUG [main] (AbstractImpl.java:10) - the actual log message

... which makes it difficult to distinguish between the concrete implementation classes that are actually being used when the message was logged.

This entry helped me realize that the (AbstractImpl.java:10) portion of the logged line was being placed there by the regex (%F:%L) from the PatternLayout that was specified in the log4j.properties file like so:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{dd MMM yyyy} %5p [%t] (%F:%L) - %m%n

Therefore, the solution would be to add the regex [%c{1}]:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{dd MMM yyyy} %5p [%t] [%c{1}] (%F:%L) - %m%n

Hoping to get logs that look like:

21 Apr 2011 DEBUG [main] [ConcreteImpl_A] (AbstractImpl.java:10) - the actual log message
21 Apr 2011 DEBUG [main] [ConcreteImpl_B] (AbstractImpl.java:10) - the actual log message

... but that will not happen yet because there is still one major flaw in the way the logger code in the java classes above has been written!

The code needs to be like this:

• SomeInterface
  
  • AbstractImpl
    protected Logger logger = null;
    
    • ConcreteImpl_A
      private static final Logger myLogger = Logger.getLogger(ConcreteImpl_A.class)
      public ConcreteImpl_A() {
      super();
      super.logger = myLogger;
      }
    • ConcreteImpl_B
      private static final Logger myLogger = Logger.getLogger(ConcreteImpl_B.class)
      public ConcreteImpl_B() {
      super();
      super.logger = myLogger;
      }

Finding current PermGen size via JConsole

It is not exactly rocket science but sometimes it is the simplest tasks that lack instructions around them.

Any Java developer would have faced the out of memory error with the cause being the limit for JVM's PermGen (Permanent Generation) size. If you are walking in on an environment or project, it is not immediately clear as to how you can get the JVM to simply spit out the current PermGen size without looking around in batch/shell files or system environment for any earlier tweaks.

This is where JConsole is great for quickly figuring out the current PermGen size because it present on any system with a Java JDK installed on it.

1. Connect to the JVM with JConsole.
2. Click on the Memory tab.
3. From the Chart drop-down select the Memory Pool "PS Perm Gen" option.
4. After a few seconds the Details panel at the bottom right will refresh and the current Max for the permgen will be shown.

Jetspeed - Finally an unpack plugin with the flat option

Lets look at the case where one uses the maven-dependency-plugin to unpack certain files from an artifact:
artifact.zip
> some
> > nested
> > > file.txt
> other_nested_folders

If you specify your output directory to be:
/dev/bundle
And try to unpack file.txt from artifact.zip, then the resulting structure will look like:
/dev/bundle/some/nested/file.txt
There is absolutely no way (known to me as of this blog post writing) to get this maven plugin to spit out a flat structure like:
/dev/bundle/file.txt

So a good alternative is to use the jetspeed-unpack-maven-plugin which allows the users to specify <flat>true</flat> as part of the configuration in order to obtain the desired file without the burden of having the relative path from the root of the artifact included as well.