Netuality

As seen today on Google Reader. A strip is a strip is a strip is a strip:

If you came here from the Mediafax article, this address is wrong. The Netuality you’re looking for is hosted by Hotnews.

One of my previous customers has a Jakarta Tapestry [3.0.x] based site. The site is subscription-based, but it also has a public area – if you browse each and every link you should be able to view few thousand of [dynamically generated] pages. No SEO* consulting was involved in building the site. To put it simply : I’ve got some specs and HTML templates: developed, deployed, bugfixed and hasta la vista…

More than 6 months later [!], the site is still alive, which is good, but it doesn’t really spot impressive traffic figures and growth. Basically, all the traffic it gathers seems to come from existing subscribers and paid ads, very low level of organic and almost zero traffic from major engines such as Google (although it was submitted to quite a lot of engines and directories).
Lo and behold, there must be something really nasty going on since a quick query on Google with site:www.javaguysite.com** gives only one freaking result : the home page. What means: Google has indexed ONLY the entry page – same thing happens with all the other major search indexes. And guess what : nobody is going to find the content if it isn’t even indexed by search engines.

Making friends with your public URLs

The problem : Tapestry URLs are too ugly for search engines. Looking at the source of my navigation menu, I found little beasts such as

http://www.javaguysite.com/b2b?service=direct/1/Home/$Border.$Header.$LoggedMenu.$CheckedMenu$1.$DirectLink&sp=SSearchOffers#a

For a Tapestry programmer it is simple direct link from inside a component embedded in other components, but for search engine bots it is an overly complex link to a dynamic page, which will NOT be followed. Thus, if you want these little buggers to crawl all over your site and index all the pages, make’em think it’s a simple static site such as :

http://www.javaguysite.com/b2b/bla/bla/bla/SearchOffers.html

In SEO consultants slang, it’s called “friendly URLs”***.

You don’t have to make all your links friendlier. For instance, no need to touch the pages available only to subscribers as they’ll never be available for public searching. In the public area, make friendly URLs only to access those pages containing relevant content.
The method is called URL rewriting. Rewriting means that the web server is transforming the request URL, behind the scenes, using regular expressions, in a totally transparent manner. Thus, the client browser or the bot “thinks” it reaches a certain URL, however a different address is sent to the servlet container. The rewriting is performed either by:

1. using a servlet filter such as urlrewrite.

or

2. with mod_rewrite in Apache. I do use Apache as a proxy server, in order to perform transparent and efficient gzip-ing on the fly as described in one of my previous blog posts. Now, I only had to add the mod_rewrite filter and I’m ready to go.

Only minor syntax differences exists between the regular expressions in the filter and the Apache module. I was able to seamlessly switch between the two, as I use the servlet filter in development environment and we did Apache proxying in production.

The devil is in the details

Now we’re sure that dynamic pages from the public area will be searchable after the Google bot crawls them. Problem is : all pages of a single category will have the same title. Like for instance “Company details” for all the pages containing … umm, company details. And when you have thousands of companies in the database, that makes helluva lot of pages with the same title ! Besides, keywords contained in the page title play an important role in the search position for the specific keyword. The conclusion: make your page titles as customised as possible: put not only the page type, but also relevant data from the page content – in our case, the company name and whynot the city where the business is located. This is easy with Tapestry:

<html jwcid="@Shell" title="ognl:page.pageTitle">

and then define a customized

public String getPageTitle();

in all the Page classes (with maybe an abstract getPageTitle in the base page class, supposing you have one defined in the project, which one normally should).

The same type of reasoning applies for page keywords and description metatags, as they are taken into account by most of the search engines. Use them, make them dynamic and insert content-relevant data. Don’t just rely on generic keywords as the competition is huge on these: a bit of keyword long tail can do wonders. Don’t overdo it and don’t try to trick Google as you may have some nasty surprises in the process. And if you can afford, have some SEO consulting for the keywords and titles content.

There’s another rather obsolete nevertheless important HTML tag : the H1. Who on Earth needs H1 when you got CSS and can name your headings according to a coherent naming schema ? Well, apparently Google needs H1 tags, reads H1 tags and uses the content of H1 tags to compute search relevancy. So make sure to redefine H1 in your CSS and use it inside page content. People seem to believe it has something to do with a sort of HTML semantics …

That’s it, at least from a basic technical point of view. For a longer discussion about SEO read Roger Johansson’s Basics of search engine optimisation as well as the massive amounts of freely available literature available on the web concerning this subject. Just … search for it.

*SEO = Search Engine Optimization.

**Names changed to protect the innocents.

***Supposedly, Tapestry 3.1, currently in alpha stage, has its URLs way friendlier than 3.0. However, don’t use an alpha API on a production site.

The java.util.concurrent package in JDK 1.5 is worth its weight in Internet porn.

From studdugie on Java

Tomorrow is my last day here as a Senior … whatever. I've done a lot of Java development (Eclipse plugins, SWT/JFace, various components for our proprietary framework) and even some DB work (Sap/Oracle/PostgreSQL migration, benchmarking, testing), spiced with a little bit of API design and a healthy dose of documentation writing. It was a great year with lots of stuff to learn, but it's time to move on towards greater challenges. I'm going back to the web business (this time not under the risky startup umbrella, but with an established company) and back to a managerial position ! Working a full year 100% on a development contract has surely taught me a thing or two about how effective management must be done. I really needed such an experience, because as a young professional (back in 1998) I became very quickly (maybe too quickly) a project manager.

The funny stuff is that I'm going to manage a C# team which is bigger than the Java team. I'm familiar with .Net notions and burning some midnight oil with VisualStudio Express, but there is a serious culture shock of coming from Java/Eclipse development environment. Although C# as a language is very neat and there are some cool MSFT APIs down there, I have the strange sensation of things being terribly awkward. Hope I won't be swallowed by the Dark Side [ugly grin].

If there's any 'actual future former' coworker reading this blog : THANK YOU ! and keep up the good work.

Nice excerpt from an Inc. article :

Future Beef's real albatross, says Darrell Wilkes, was an expensive computer system that ran enormously complex software from J.D. Edwards. “We were pouring all this data in, but we could never get the data out,” says Wilkes, whose job, as the company's cattle and supply expert, was to monitor the progress of about 300,000 head of cattle. And these weren't just any cattle. These were Future Beef cattle, raised by ranchers who met its standards for feeding and monitoring their herds. Wilkes had to keep track of which steers had been given certain region-specific mineral supplements, which had been fed their necessary doses of vitamin E, which had been measured for yields of particular tissues and fats, and what the optimum dates were for shipping each steer off to the slaughterhouse.

When Wilkes asked his staff for the numbers, they didn't have a clue. They had not been able to retrieve the data from the computer system.

“I swore a lot, and jumped up and down a lot, but it didn't do a lot of good,” he says. “We would have been better off going in there with a very simple system. At least the simple systems give you your damn yield report.”

Click here to read the whole article.

Recently, an Indian poster on a Slashdot thread ('India Outsourcers Find Back Door in Canada') mentioned that:

Software Developers in India (including me) are paid 350 times the prevailing minimum wage in India.

I thought it would be interesting to make a comparison with the same data in Europe:

• in a country such as France, this makes 402.640EUR/month.
• in one of the countries wich has recently join EU, such as Hungary, this means almost 67.000EUR/month (Hungary does not have the biggest wages in the recent wave of new EU members).
• finally in a country such as Romania which is scheduled to join EU in 2007, 350 times the minimum wage is however close to 25.000EUR/month and rising with two figures percentage in the last couple of years, due to economic growth. Romania and Bulgaria are considered the poorest countries to join EU in the next years.

Outsourcing in India is more than just a temporary industry trend … and will touch all EU as strong as it does with US. Dear US developers, would you please let us join the club ? (we'd rather not, but you know …)

“Sir, on behalf of this Democratic Government of Nigeria, I apologize for any delay you might have encountered in receiving your money in the past.”

Ummm, well … apologies accepted.

Being extremely busy lately, I arrive a bit late at the Junit destruction feast. While it is probably true that some guys with a certain gift for writing blog articles may “come up with something far more useful in a couple of days”, I think the discussion is missing an important point: there's a whole ecosystem living around Junit. We have Ant integration, we have the choice between code coverage tools (both commercial and open-source), plugins for mainstream IDEs and a certain number of useful or less-useful extensions. We have extensive documentation and a plethora of examples to feed the small fishes. Throwing Junit down the drain means throwing all these down the drain. Or, at least: write your own Ant integration, adapt a code coverage tool and rewrite the IDE integration, rewrite documentation and examples – this is not going to be done in “a couple of days”.

Another Junit advantage is that this little simplistic API is ubicuous. I mean, every developer heard about it and knows how to use it, unless of course he/she was living under a rock for the last few years. And I don't mean every Java developer, but just about every developer for a language under the xunit umbrella. Meaning : all the programming languages (unless you consider “languages” such as Whitespace, Brainfuck and INTERCAL).

Beck and Gamma have not only written some “crappy” classes and put the few “laughable” chunks of code on Sourceforge, they have done it first. Now, there is some well-founded criticism about the lack of evolution in Junit, but one thing is undeniable : it really did fill a niche, back then in 2000. The code may not be beautiful (and this is not good coming from XPers) but it serves its purpose : to provide a simple framework for unit testing.

Competition is the key here and smart newcomers on this “market” are good news for us programmers. But, it's gonna take some time and a lot of work to build a similar ecosystem, a similar mindshare and usurp Junit's kingdom. That would be of course more interesting to see than denial of four years of Junit influence in a few well-rounded, but futile phrases.

… at least that's what Mr. David Gristwood says in this (otherwise excellent) entry ('21 Rules of Thumb – How Microsoft develops its Software') on his MSDN weblog. Davis thinks that :

Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.

What kind of 'portability' are we talking about in the context of software development at Microsoft ? He is probably making allusions to software being developed simultaneously for desktop and pocket Windows, which is in fact quite a challlenge for QA and for the developer team. But if it's a tongue-in-the-cheek reference to Java WORA, I found this entry to be somewhat funny. Let's – for the sake of the argument – suppose that you develop for multiple platforms and your QA team is able to thoroughly test only one of them. Basically, this means that your product is going to work OK on the main platform and have some flaws (most probably in the GUI area) on other platforms. How is this worse than having a product which purposedly works on a single target platform ? Humm, is JVM 'system software' after all ?