GridPulse

as stimulating as black coffee and just as hard to sleep after.

Archive for the ‘Development’ Category

Transactional unit tests that support scopes using JUnit and Spring

2 comments

Most of the unit tests that you write don’t need support for transactions and scopes, but if you ever want to test your web frontend code properly you’ll hit into this one.

Writing transactional unit test with JUnit, Spring and Hibernate is easy, what you want to do is:

- Add a transaction management bean in your test context:

<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>

- Make your test extend AbstractTransactionalJUnit4SpringContextTests
- Annotate you test class with @TransactionConfiguration and @Transactional

If your transaction demarcation is correct( surrounding your dao or service ) you should be done. This is the cleanest way that I found.

Everything until now is fine and dandy. The problem arises when one of the injected beans is bound to a scope. It can be any scope but for this example I’ll take the simplest scope – the ‘session’ scope.

In a non-transactional situation this should be pretty straight forward, just implement Scope and using a ConfigurableBeanFactory register it. The fact that we are extending and that our context is automatically created really kills the simple path.

You’ll get a org.springframework.beans.factory.BeanCreationException with a nested “java.lang.IllegalStateException: No Scope registered for scope ‘session’”.

But do not despair, there is simple solution available and it’s called CustomScopeConfigurer.

The fastest and cleanest way to use it is:
- Create a simple class that will be used as our scope manager. Let’s call it MockSessionScope.

code

- In your test context, create a CustomScopeConfigurer that will automatically register your scope on context creation:

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
<property name="scopes">
<map>
<entry key="session">
<bean class="com.gridpulse.xandria.translator.MockSessionScope"/>
</entry>
</map>
</property>
</bean>

Run your tests and you’re done!

Written by Bogdan

August 21st, 2009 at 4:45 pm

Multi Font Viewer on xandertools.com

one comment

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.


twittshot

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!

Written by Bogdan

August 13th, 2009 at 7:04 pm

On refactoring and code reuse

leave a comment

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.

Puzzle
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.

Written by Bogdan

June 22nd, 2009 at 6:30 pm

Posted in Development,Java

Building software that speaks their language

leave a comment

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.

Localization

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.

Written by Bogdan

April 10th, 2009 at 6:02 pm

Posted in Development

When importing large Oracle dumps…

leave a comment

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

Written by Bogdan

February 6th, 2009 at 7:55 pm

Posted in Development,RDBMS