When is the best time to post to your blog?

I've been wondering for some time, when it's best to post to your technology blog.

There are several factors

  • aggregators like javablogs.com or groovyblogs.org
  • different times zones like US-west, US-east and Europe
  • different times of day where people read
  • weekdays or weekends
  • social news sites like reddit or digg
  • article sites like artima, the serverside, infoq or dzone
  • different audiences

I'm not sure which way to go, when to post. When posting here in Europe at noon, it's in the morning in the US and people get up and to work. So I can catch the morning birds (east, what with west?). Posting in the evening, I get to people in the US at noon, but the people in Europe in the evening at home probably. Timing this with the aggregators and feedburner to reach enough reads to stay on top. But not too soon or the post will be swamped by later entries before the majority of people starts reading blogs. Not too late, or you can't catch the wave. A lot of interdependent variables.

I think I need a simulation tool to optimize weblog posting times. But as always, the best way to get readers is to post interesting stuff 🙂

Thanks for listening.

Open Comment to Dion on SLF4J

Dion wrote about SLF4J and how only the Java community can make such a fuzz about logging. His captcha is broken, I can't comment there so here is my thought on the issue:

From my impression into Rails and Erlang land, others have not reached the problem of proper log configuration, deployment and the need for sophisticated frameworks (But I'd like to learn if I'm wrong, and the issue is not only configurability but pluggin incompatible frameworsk with different loggers into one application).

The problem with commons logging and everything else comes from the fact that Sun implemented logging themselves instead of just going with everyone else by adapting Log4j. They didn't make the error with EJB3 again, instead got Hibernate on board and did it the way everyone else does it. Log4J in the JDK would have killed all other attempts several years ago.

(That said, SLF4J and Logback are better than Log4j and commons)

JUnit recipes: Work around static attributes in classes

Beware of the class loader. I recently had a major testing problem with some code because I didn't take the (sometimes ugly) Java class loading mechanism into account. There was a small class where I wanted to unit test the calculateAge method.

class AgeCalculator {
    public int calculateAge(Person person) {
      ....
    }
}

So I dropped EasyMock into my project and mocked the person class. I was using jMock in the past and could live with methods as strings. With the new JMock 2 syntax this has changed. I still struggle with {{ in JMock expectations and so does my IDE. When IDEA learns to format JMock expectations, I'm back. For now I'm using EasyMock though, sometimes with JMock assertions from the excellent Hamcrest assertion library. Back to the problem at hand . The mock was passed into the AgeCalculator to calculate the age of the person. The problem was the Person class.

class Person {
  private static Configration conf = 
    new DatabaseConfiguration("Person");
    ...
}

Even though I didn't use the Person class, just a mock, the static attributes where initialized and the DatabaseConfiguration tried to load data from the backend. This happens whenever your classloader sees the Person type, even in an interface.

interface Calculator {
    public int calculateAge(Person person);
}

Using Calculator in mocks will initialize the static attributes in Person. Which contradicted the isolation principle of unit tests and also led to long startups of the database backend. This stopped my efforts to test the AgeCalculator. Time passed.

Then I stumbled upon JMockit. Others have too. The friendly and supportive developers of JMockit have helped (thanks Rogerio) and with a simple line I was saved:

Mockit.redefineMethods(
  DatabaseConfiguration.class, 
  MockDatabaseConfiguration.class
);

Constructs like the above with static attributes should never be created in the first place (hello all those people who propagate static inialized attributes for singletons to avoid synchronized). But if you have such code in your legay base, JMockit to the rescue.

Thanks for listening.

Forking Radeox: A new wiki render engine

After some debate of getting the rights to Radeox and a some negotiations I decided to fork Radeox. Radeox is an open source wiki render engine for Java which turns wiki markup into HTML and which is successfully used in several wikis. For years I was the lead developer for Radeox but that changed when I got a new job.

The past

  • Radeox was used in SnipSnap and refactored to it's own project
  • The license was changed to Apache, the API license was changed to BSD
  • Work on Radeox was done during my employment at Fraunhofer FIRST, who own the rights to some of the code
  • The ideas, the API and some implementation predate SnipSnap and Fraunhofer
  • At Fraunhofer Radeox was cleaned up, refactored and extended with features

The name is owned by me so although I fork Radeox I still keep the name. Radeox is available on the Reposita SVN server.

The future

The development of wikis is not over. From my point of view what we see is just the beginning of wikis. We have only seen the tip of the iceberg. Wikis are still growing steadily, just take a look at google trends (not scientific blah blah blah):

Wiki vs. Blog

I've been developing, consulting and thinking about wikis for 8 years, my first self-developed wiki is dated 1999. SnipSnap as a wiki was very successfull for some time. I talked to lots of people about the future of wikis and what they think in which direction wikis will move. I attended several WikiSym events and was helping to organize one. At the last WikiSym I gave a workshop and co-wrote a paper (PDF) about wiki render engines: "The Radeox Wiki Render Engine". The discussion around the paper sparked several revolutionary ideas and I will implement some of them in the next Radeox version. Wiki engines didn't innovate in the last years, so it's time for change and a speedup in innovation. Innovation in rendering engines will spark innovation in wiki implemtations. May we live in interesting times.

Thanks for listening.