Talk On Tech now Molindo Techblog

Talk On Tech (talk-on-tech.blogspot.com – the tech blog you truly love, don’t you?) was our nice, green home since August 2007. Now, after 1.5 years it was time to move on … Well, okay, we just want to consolidate all our blogs on a single self-hosted platform. In the course of doing that, we also changed the name from Talk on Tech (Let’s create a blog! How do we name it? What about “Talk on Tech”? Yeah, that name is free!) to Molindo Techblog (where Molindo is the name of our very own startup).

If it comes to new posts, We have a lot of ideas but not enough time to elaborate them all. Some ideas are:
Read the rest of this entry »


Virtual WordPress Hosts Made Easy (obsolete)

Currently, we are planing to consolidate all our blogs that we (quite carelessly) created all over the internet. At the moment, we have

  • three blogs hosted on Blogger (1, 2, 3)
  • two blogs running on their own WordPress (1, 2)
  • three private blogs running on Blogger and Serendipity
  • and one or two new ones to come

All in all, there’s quite a bit of blogging going on :)

Yesterday, I was looking into solutions on how to host all those blogs on a single installation of WordPress.
Read the rest of this entry »

Tags: ,


Wicket: A Neat Url Encoding Strategy and some basic SEO

After a year of working extensively with Apache Wicket I want to share some stuff I’ve been using over and over again and might be useful for you as well. In this first post it’s a custom URL Encoding Strategy and some related basic SEO.

Pages often depend on entities – e.g. a Customer or a product and as those pages should be bookmarkable as well, there has to be a unique way to tell the page which entity to use. As entities either don’t have unique names or one wants to avoid having an (database) index over the name column, the index-ID is for most applications the way to go. As it’s usually undesireable to expose the database ID of an entity in the URL, it has to be encoded and decoded somehow to get from myshop.com/customer/12 to myshop.com/customer/ea34cff … or something like that.
Read the rest of this entry »


Java: Map sorted by value

Today, I wanted to solve a – at first sight – rather simple problem in Java. I wanted to iterate over the keys and values of a Map in an order given by its values. E.g.

Map m = new ...
m.put("foo", 47);
m.put("bar", 11);
m.put("baz", 11);
m.put("qux", 100);
// {bar=11, baz=11, foo=47, qux=100}
System.out.println(m);
 
m.put("foo", 101);
// {bar=11, baz=11, qux=100, foo=101}
System.out.println(m);

Read the rest of this entry »


Spotting duplicate classes in Jar files

After more than a month it’s time for another post. Sorry to all of you for keeping you waiting … well, honestly I don’t think somebody even noticed :)

Today, I stumbled upon a classpath related problem – once again. As I doubt that I am the only one to ever face this problem, I want to share a short shell script that came to the rescue.

But first, what was the problem? After adding some additional dependencies to our POM – quite carelessly I have to admit – our application started sending mails without subject, sender address and messed up special characters. Interestingly enough, I didn’t touch the mail part at all. I added Apache CXF dependencies, i.e. web service stuff. So what was wrong?
Read the rest of this entry »


Wicket: Loose Coupling of Componens for Ajax Updates

While developing Wicket applications, one often has to write a simple input form (e.g. a search box) that updates the content of another panel (e.g. a search result panel). And of course, we all use Wicket’s AJAX support to search as it is so damn cool and easy to use.

Normally, you do this by either putting everything on one panel or by passing a reference of the list panel to the form panel.

public SearchBoxPanel(String id, SearchResultPanel results) {
_results = results;
// snip
}
 
public void onSubmit(AjaxRequestTarget target) {
_results.setQuery(getQuery()); // or use the same model ;)
target.add(_results);
}

Read the rest of this entry »


Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests

This entry is part of my “Wicket Interface Speed-Up” series.

Now that I spent some time on configuring client-side caching and resource versioning for aggressive caching, I am going to finalize this series with an article on merging of resources and some code that you can easily use right away to speed-up your own applications in minutes.
Read the rest of this entry »


Wicket Interface Speed-Up: Caching Resources Forever

This entry is part of my “Wicket Interface Speed-Up” series.

In my last post, I explained how to change (i.e. increase) the time a client should cache resources like JavaScript and CSS files served by a Wicket application. In this post, I’ll show you how to cache resources for a year. Caching for a year is close enough to forever and a recommendation by W3C:

“To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.”

Read the rest of this entry »


Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers

This entry is part of my “Wicket Interface Speed-Up” series.

Let’s start with a short introduction before we talk about setting Expires and Cache-Control HTTP-Headers:

By default, all WebResources are cacheable for one hour, which is defined by WebResource.getCacheDuration():
Read the rest of this entry »


Wicket Interface Speed-Up

After reading Matt Raible’s thoughts on [OSCON 2008] Even Faster Web Sites by Steve Souders I decided to look into the topic myself. I knew that one bigger project built with Wicket was reported to be slow. However, I always made the mistake to look into server-side performance as client-side performance never was an obvious problem – well, estimating client-side performance on my Quadcore/4G RAM/Ubuntu workstation with broadband connection admittedly wasn’t very representative ;)

According to Souders, “80-90% of the end-user response time is spent on the frontend”. This obviously makes potential performance improvements of (quite insane) 20% on the server a drop in a bucket. Therefore, I decided to make interface performance tuning a top priority in my work queue and looked thoroughly into it.
Read the rest of this entry »