Being a software developer sometimes involves more than just coding.
This time it was a logo and a splash screen I did a while ago and I had a problem – I couldn’t remember what font I used.

Of course, having a lot of fonts installed made it a nightmare.

I googled a bit and found a lot of shareware that allowed me to view multiple fonts and compare. I didn’t use any of it. Instead I used a nice piece of software called Opcion.

It solved my problem, although it acted a little strange plus, it was Java. I can handle it because I’m a Java developer.. but can anybody else?

After finishing the work I decided I could do something about it. So I did.

It’s called Multi Font Viewer and it’s free.

You can download it from: the Multi Font Viewer page at xandertools.com.

If you want to take a look at the code or contribute visit the Multi Font Viewer Google Code project.

Best of luck and happy fonting!

Strolling through Google Reader, diagonally reading blog posts from the almost 1 hundred blogs that I tend to follow(1000+ unread ) a phrase jump started my brain.

Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges.

This is part of a post from one of the Mozilla blogs that I’m following, namely the blog of Austin King.

Now, this is as straight forward and clear as it is correct, not ever line of code can be reused. Putting it out of its initial context (web development that is) and bringing it into to context of enterprise applications it becomes pure evil, used as an excuse to re-invent a perfectly good wheel.

Photo by tcp909

Some advice:

• Reuse as much as you can, extracting recurring pieces of code as methods
• If common code spawns between projects, always extract it in a common library
• Run a copy-paste detector such as CPD. Extract the code to methods.
• Try to keep your methods under a fixed number of lines, let’s say 20. Doing this will force you to extract consistent pieces of code in separate methods, making them more re-usable
• Try to maintain low cyclomatic complexity. Use a metrics package such as PMD or Panopticode. Refactor complex methods to smaller, less complex chunks of reusable code.
• If you have the feeling that it’s the second time you’ve written a piece of code, search for the first one, because it’s usually true.

Now go and read a good book about this kind of stuff. I recommend The Productive Programmer by Neal Ford. It’s an excellent book for beginners but don’t fear – it’s superb even if you’re an experienced developer, I caught some nice Groovy tips that made the reading worth while, maybe you’ll find something interesting too.

It hasn’t been a long time since I’ve been using Twitter. I’m just getting the hang of it, following the bloggers and the book authors who’s materials I enjoy, news tweetters (local and global) and some random people that make my day happier through their tweets, so I don’t consider myself an expert and you shouldn’t either.

Photo by Louis Abate

What I have noticed though is that Twitter is pretty addictive once you really understand what it is, and what it’s not. Once you understand that it’s not just a website where you tell the world that you are just about to take a shower or eat a peach and you really start to use Twitter you’ll notice this too.

Ever had the feeling that you really want to see what the people you follow have to say right now?

Ever pressed refresh on you browser or clicked “Update tweets now” in you Twitter client twice in a couple of minutes?

That’s called “a distraction”.

It’s what makes you less productive by getting you out of your “flow”.

Humans are not multi-tasking. We just like to think that we are!
Once you are distracted and you loose your focus on the task at hand it may take a couple of minutes or even an hour for you to get back you rhythm.

So here are my four tips on how to avoid a productivity loss:

1. Don’t check Twitter updates very often
Checking what’s up on Twitter every second destroys your concentration. It isn’t really helpful either.
When you feel the urge to press refresh or to click that “Update now” button – just stop.

If you have a Twitter client go to the settings window and set the auto-update frequency to a large value, like 2 or three hours. This way you won’t see the pop-up that often and you won’t feel the need to see what everybody is saying.

In time you will get accustomed to the reality that tweets are not critical.

2. Only follow people that deserve it
If you will follow the first tip, this second one is a must!
By checking Twitter only once or twice every day you will accumulate a lot of tweets, tweets that you will have to either read or ignore.

Making sure that you only receive high quality tweets from high quality tweeters will make your time using Twitter more pleasant.

You can do this the simple way – just unfollow anybody that annoys you or that tweets things that you have no interest in (like getting rich instantly by clicking on a link)

3. Use a client that has good filtering
If you follow the first tip and check Twitter messages rarely you’ll soon have a lot of them to read. Even if you follow the second tip you’ll still have a lot of them so a good client that has good filtering will help you read what you are interested in.

Just filter by what you are interested in or by author and get the most out of the Twitter experience.

4. Only tweet if you have something valuable to share
One would say that if so many people are tweeting, a lot of interesting content is generated. Wrong!
Most of the Twitter content is noise. People announcing their third pizza for the day, people charming you into “winning a million dollars” or even automated bots auto-messaging and auto-following everybody.

You can help stop some of the noise and make yourself more useful (by not spending you whole time tweeting useless stuff) by just tweeting interesting content that adds value to your followers.

That’s it for my 4 tips on how to avoid a Twitter-induced productivity loss. Please leave your thoughts and experiences using the comment box.

Preemptive strike: If your job is monitoring Twitter for product-related complaints, if you are a marketer or publicist using Twitter as a business model or if you are a Twitter spammer you can just ignore everything that I just said.

I’ll share a secret with you: great software has great localization support.

Frankly, this is not really a secret and it’s not just great for your users – having software that can be quickly adapted to any language or culture is a big plus for you and your company.

Writing software that speaks their language is not hard these days, as most frameworks have this support built in, and if your framework or technology doesn’t, it’s time to look for something new.

The infrastructure work of building an internationalizable and localizable product is usually already in place, but using this support is up to you. Most developers tend to treat this subject lightly, but I have found that the investment is well worth it.

Some tips for building applications that can be easily internationalized and localized:

• Make sure the technology that you want to use has support for easy internationalization and localization. If it doesn’t, and you still want to use it, think about the costs of developing localization support for that technology or framework. If the costs are higher than switching to another technology…switch
• Localization doesn’t just mean translation. Consider the cultural aspects
• Always consider bi-directional text, even if exporting to Arab or Asian countries is out of the question now, in the future…who knows. The Internet has made the world a small place
• Never hard-code date or currency formats, it’s just plain wrong
• Remember that different locales have different decimal and thousands separators, don’t hard-code these either
• Keep your strings in an easy-to-translate format. Usually, you’re not the one translating your application strings, which means that your strings must be sent to a translator. If you keep your strings in a complicated format (or hard-coded in your product), you’ll always loose time converting your format to a translator readable (normal human readable) format. Either keep your strings in a simple format, such as a flat text file (think about the.properties file format used in Java applications) or use a special translated text management tool
• If possible, don’t embed your translation file in the binary of your application so that new translations can be easily added without re-compiling and updating. Doing translation update releases just annoys your user base
• Have a native of the language and culture you are targeting use your application. This way, you can be sure that no critical translation or cultural errors have slipped into your product. Try not to use the same person that translated your text, for easily understandable reasons.

The process of localization may also include presenting your application in a different way or highlighting different features so your marketing approach could change(and it should change) also.

In the process of analyzing requirements and development, I usually try to learn the language and cultural habits myself (and I like to have my team do the same). You don’t have to learn the whole language, you just have to learn the terms used in the specific domain you’re targeting, as this can have an important impact on requirements gathering and even on product development, but more on this aspect in another post.

Note to self and others!
When importing large oracle dumps (size in GB’s):

• start early
• always disable ARCHIVELOG….always
• set UNDO retention to a small value, let’s say 5 seconds
• get coffee…
• wait
• remember to enable ARCHIVELOG… when in production