For the impatient: check out the code here.

The code

The actual code is very simple:

1. it executes an HTTP GET with a given URL
2. follows HTTP redirects
3. finally downloads the contents
4. checks whether there’s a meta refresh tag
   • starts over at 1. if it found such a tag
5. returns the content.

Have a look at the class TitleTest here: the private method doGet will be most interesting.

Conclusion

I was wondering why there aren’t that many tools out there which support following meta refresh tags. Since a lot of websites use this feature I thought that this would be something a lot of people might want to use when testing their websites.
Hacking a small tool that does the job is very easy though, as demonstrated in this post.

Since there wasn’t a German translation for it I created one and the author, Matteo Lucarelli, integrated it into a new release. If you’re from Germany and don’t speak English you may want to give this software a shot.

The Visual Basic script

For everybody who knows how to program in Visual Basic it’s be pretty easy to write some lines that get the files from a certain directory and deletes them if they haven’t been changed for some time. For everybody else: just copy the following lines into a file e.g. cleaner.vbs.

1
2
3
4
5
6
7

Dim fso, f, f1, fc
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFolder("C:\foo\bar")
Set fc = f.Files
For Each f1 in fc
If DateDiff("d", f1.DateLastModified, Now) > 7 Then f1.Delete
Next

All that’s left to do is to change the folder in line 3 to whatever you want. Have a look at line 6 and adapt the number of days, currently 7, to your needs.

Running the script

The at command helps you to run programs at a certain time. Let’s say we want to run our script every day at 22:30 o’clock (that’s 10:30PM) we would type this on the command prompt:

at 22:30 /every:M,T,W,Th,F,S,Su C:\Scripts\cleaner.vbs

If we just type at we’ll see all the tasks that are planned for execution.

Conclusion

With a simple Visual Basic script and the at command it’s pretty easy to run recurring tasks under Windows. If your Windows server is running longer than a week without rebooting this is a really nice solution.

While the link tags were introduced in an earlier release of WordPress the meta tag came with 2.5. I’m pretty sure that the latter will cause incompatibilities with a lot of existing themes that have a line like this in their header.php:

<meta name="generator" content="WordPress 2.3.2" />
<!-- leave this for stats please -->

In this post I’d like to share my ideas about removing some clutter from your WordPress installation. Namely:

• RSD and WLW links
• generator tag
• some JavaScript

Removing RSD and WLW links

Getting rid of this stuff is as easy as using the WLW Disabler plugin. After installing and activating the plugin the links are gone. That’s great.

Getting rid of the generator tag

Maybe it’s possible to write a nice plugin that removes this tag too but a quick and dirty hack is to edit the file general-template.php; you can find it in wp-includes. On line 1187 set the variable $gen to an empty string:

// ...
$gen = '';
return apply_filters("get_the_generator_{$type}", // ...

If you come up with a clean solution to this please leave a comment.

Living without JavaScript

Although this isn’t really related to the previous two I’d like to share this one too. I’ve disabled most of the JavaScript that comes with WordPress quite some time ago. And it works great for me: especially the admin pages load a lot faster.

Furthermore I got rid of Prototype that doesn’t play well with SmoothGallery. So, if you’re using the WordPress SmoothGallery plugin this might be something for you.

Just open the file wp-includes/script-loader.php and comment out the line saying:

$this->default_scripts();

That’s it.

Conclusion

If you don’t use Windows Live Writer and the like, using WLW Disabler should be of no harm for you. Disabling some of the JavaScript will give you a performance boost but you’ll lose some of the nifty features at the same time.

Results

I ran a case insensitive analysis on 2833 RFC’s and related text documents from here; all in all 169 MB. This took quite some time but once it was done I had these results, sorted by:

• letters
• occurrence count

I didn’t thought that I might come up with nice results so easily.

The most frequently used characters make up the word etiansor here.

Conclusion

If I seriously wanted to analyze the letter frequencies of a text corpus I would implement some sort of filtering. But without that I got reasonable results too.

• using an Iterable
• toCharArray()
• charAt()
• calling charAt() on a CharSequence

You can download the Eclipse project as a tar or zip or browse the code online here; have a look at the StringIteratorTest class first.

Results

Without further ado here are the results:

Conclusion

If speed is what you want you shouldn’t use Iterators but one of the other solutions instead. On the other hand if you just like to play with Iterators and classes that implement Iterable you may want to choose the slower solution.

You can download the Eclipse project as a tar or zip file or view the code online here.

Implementation

If you don’t know how dynamic proxy classes work here’s a short overview. Let’s say you want to do some extra work if the methods foo and bar from the class Tee are called. You would extract the methods into an interface and let Tee implement this interface.

Next, you’d implement a factory that produces a proxy instance for Tee with a custom InvocationHandler. This handler would have a look at the method’s name and check whether it’s foo or bar: you can now implement any extra actions in this handler.

You can also examine the annotations of the invoked method and that’s what I did: if the method has got the @Cachable annotation we’ll utilize a cache. But how do we know whether we can safely return an object from the cache?

Constructing a unique method identifier

This is crucial since we don’t want to return the same result from the cache if the method was called with different parameters. So we’ll have to add the values of the parameters to a identifier like so:

"package-name" + "class-name" + "method-name" + "param1-param2-[...]"

This way we’ll create a unique entry in the cache for different method calls.

How to

All we have to do is to add @Cachable to some methods:

public interface Foo {
  @Cachable
  public SomeObject foo(int param);
  @Cachable
  public AnotherObject bar(int param1, long param2);
}

Once we’ve done that we can use the factory to produce a new proxy instance with our custom InvocationHandler. The handler will use the cache, i.e. the method calls will return faster.

Conclusion

In this post I presented a simple solution for a cache that may speed up method calls. Although I recommend using AspectJ for this kind of job you can use dynamic proxy instances if your environment (in most cases read: your project leader) doesn’t permit you to use AspectJ.

You can download the Eclipse project as a tar or zip file or browse the code online here.

Implementing the aspect

I decided to use an annotation and an aspect with a pointcut that matches this annotation. All I had to do was to annotate the methods that should be cached.

Here’s the very generic version of a pointcut that matches the execution of all methods annotated with @Cachable:

@Pointcut("execution(@Cachable * *.*(..))")
private void cache() {}

The logic is this simple:

@Around("cache()")
public Object aroundProfileMethods(ProceedingJoinPoint thisJoinPoint) {
  // construct genericIdentifier
  Object obj = cache.get(genericIdentifier);
  if (obj == null) {
    obj = thisJoinPoint.proceed();
    cache.put(genericIdentifier, obj);
  }
  return obj;
}

Everytime a cachable method is executed we’ll first have a look at the cache. If there’s a cache hit we’ll immediately return the object. If there’s no such object in the cache, we’ll call the cachable method, put the returned object in the cache and finally return the object.

The genericIdentifier is a string consisting of the package-, class- and method-name and the supplied arguments. For a method named foo from a class bar inside a package called baz this might result in:

"baz.bar.foo-Integer-42"

The method foo takes one argument and at the time of this execution it was 42. This way we’ll only return objects from the cache if this generic identifier matches.

Using the aspect

All we have to do is to use the @Cachable annotation. Hava a look at it:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Cachable {}

It can be used with any method that returns something:

@Cachable
public BigObject getObject(final int param) {
  return new BigObject(param);
}

The first time this method is called we’ll store the object in the cache. If it’s called again with the same parameter we’ll return the object from the cache.

Conclusion

Implementing a cache is simple and so is using it with AspectJ. I presented a straightforward way to speed up any application that deals with big objects which take a long time to load. All you have to do is to use the @Cachable annotation along with the aspect. Implementing another cache in the aspect should be simple, too.

You can download the Eclipse project as tar or zip or browse the code online here.

Basic operations

The cache supports these basic operations: you can put and get objects. If you put an object you can specify a time in seconds - after this time period the object will be remove from the cache.

Getting an object from the cache is simple too and you’ve also got the possibility to specify the type of the object you’re retrieving from the cache - this adds some type safety.

Have a look at this sample code:

SimpleCache<Integer> intCache = new SimpleCache<Integer>();
intCache.put("one", 1);
assertEquals(new Integer(1), intCache.get("one"));

This creates a SimpleCache that holds objects derived from Integer. Since you parameterized this cache with Integer you’ll only be able to put and get integers.

If you want to save all different kinds of objects in the cache that’s no problem at all. If you do this you can use the convenience method get which performs a cast for you. Have a look at this example:

SimpleCache cache = new SimpleCache();
cache.put("one", 1);
cache.put("str", "Some string");
assertEquals(new Integer(1), cache.get("one", Integer.class));
assertEquals("Some string", cache.get("str", String.class));

I think it’s better to create several instances of SimpleCache that store objects of a specific type.

Removing expired objects

Once an object is expired we want to remove it from the cache. The SimpleCache class supports two ways of removing old objects:

1. if the get method is called we’ll check whether the object that’s about to be returned is expired. If that’s the case we’ll remove it from the cache.
2. a thread that runs periodically removes expired objects from the cache.

Both features reside in implementations of Runnable so they can be executed in separate threads. This way the basic operations will not be slowed down by this kind of housekeeping.

With Java 5 it’s easy to schedule recurring tasks with the Executors class. To remove expired objects from the cache we can use this code:

Runnable cleaner = new Runnable() {
  public void run() { /* remove expired objects here */ }
};
Executors.newScheduledThreadPool(1)
         .scheduleWithFixedDelay(cleaner, 0, 30, TimeUnit.SECONDS);

Conclusion

I presented a very simple cache written in Java that stores objects of any kind. It’s configurable, type safe and easy to use; it should be pretty easy to integrate this cache into an existing project.

I’ve tried to keep the cache fast: certain tasks will be executed in threads to speed things up. But don’t worry because the threads are easy to maintain and to understand.

Then I was told that the plugin as I built it wasn’t working with Internet Explorer. I booted up Windows and came up with a solution to this problem that I want to share here: don’t embed SmoothGallery and Prototype on the same page.

SmoothGallery and Prototype

Jonathan warns us on the download page that he doesn’t recommend the namespaced version of SmoothGallery because of incompatible frameworks like Prototype or jQuery.

I did some tests and found out that SmoothGallery doesn’t work with Prototype at all - if you’re using Internet Explorer. You can download the tests here: Just open the HTML files and check whether the gallery is present.

Have a look at my results:

If you try to use SmoothGallery with Prototype enabled in Internet Explorer the gallery won’t be rendered; I have tested this with version 6 and 7 of IE. No problems with Firefox or Safari though.

There’s another thing I noticed: if you change the order of the script entries in the HTML header IE will display the images of the gallery in two different ways. Either you’ll be able to see all pictures in the gallery or you’ll just see the first one.

Another observation is that SmoothGallery breaks apart if you insert an a tag with the name set to options. Once you’ve inserted such an anchor IE won’t render the gallery; again no problems with Firefox or Safari.

Conclusion

I’ve just explained what I observed testing JonDesign’s SmoothGallery and Prototype with Internet Explorer, Firefox and Safari. I didn’t take a look at the JavaScript and didn’t search for a solution there.

If you want IE users to watch a smooth gallery on your website it seems that there’s no other way than to get rid of Prototype - remove it at least from the specific page you’re using a SmoothGallery on.