Returning to this idea, i realized that,increased releasing or increased deployment frequency has a beneficial effect on the overall velocity and quality of the release or deployment, while also improving team morale.

Because of this, I’ve been trying to create and respect strict deployment schedules, matching every development or bug-fixing iteration, namely(and usually)… every week.

It’s hard at the beginning and the first 3-4 iterations are tough (testing and deployment continues through the night because of inefficient planning and scoping) but after the team gets into the rhythm releasing and deployment becomes a trivial and actually fun activity.

Frequent release and deployment cycles also have a tendency of raising customer trust levels and wining some points for the development team, so release fast, release often, release good… and you’ll constantly get better results.

Brief history
GUtil! was born sometime in 2006 and I released the first version (GUtil! 0.4.9.5) on November 3rd 2006, for Firefox 1.5.

At first it was something that I used to speed up access to the Google tools that I was using so I only had a couple of links. Then somebody asked for it and also asked me to add some more things that he used. So I did. And I published it. And more people wanted it. That is all.

Current status
I haven’t touched the code since July 30, 2009.I’m not using it anymore. I have restricted my Google usage to Google apps, Picasa and Reader.I don’t care about anything else, nor do I have the time to care about anything else.

Some statistics:
- GUtil! has been downloaded 240,651 times
- GUtil! is part of 198 collections on AMO
- GUtil! has 8680 active daily users down from more than 12000

Future
Well, here comes the bad news.
I’m not updating it anymore. I don’t have the time, the patience or the interest to update GUtil! anymore.

If you want to work on it, it’s always been open so go get the source and have a whack!
http://code.google.com/p/gutil-firefox-extension/

All the best to whoever wants to continue with GUtil!

List types = new List();
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();

foreach (Assembly asm in assemblies)
{
        IEnumerable asmTypes = from t in asm.GetTypes()
              where t.IsClass
                && (t.Namespace != null && t.Namespace.StartsWith(targetNamespace))
              select t;
        types.AddRange(asmTypes);
}

I actually got to this point because of the way NUnit wraps an assembly in another AppDomain.

The snippet need Linq so it’s for 3.5 or newer.

Sometimes, you’re just having a wonderful day and suddenly the worst just happens:

[ServiceController] Problem starting service jboss:service=Naming
    java.rmi.server.ExportException: Port already in use: 1198; nested exception is:
    java.net.BindException: Address already in use: JVM_Bind
    at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:243)
    ............

The regular solution is to check if the port is actually used. So fire up a command prompt and netstat –aon.

If you find the port, see what process is using it and kill it .

If you don’t see the port you can reserve it by following the information in KB812873 – http://support.microsoft.com/kb/812873.

My ReservedPorts entry contains:

1433-1434

1097-1200

4543-4545

That should fix it. The bad thing is that it requires a restart.

As time flew by, I started to get a taste of what .NET is all about, luring me to the dark side.

Photo by B-tal

At the beginning I felt like “this is what evil must taste like”, but I quickly got accustomed to all the new things and now, I’m playing with .NET stuff again, mostly C#, trying to level my skills and having a lot of fun in the process. I built things like the quick and dirty multi font viewer, buggy and poor, mostly because nobody uses it.

Now, I wanted to start something bigger, and nicer (I won’t say what) and I felt that I needed to do it the right way, you know, MAINTAINABLE.
I started looking for a DI container and I started with Spring and Pico. I’m pretty accustomed to pico and I’ve been using Spring since version 1 so I though I’d give them a try. Wrong, strange, alien, weird, huge, EVIL.

For what I wanted to do it really seemed this way. How’s about something that is 10 megs big because spring and dependencies is 7 megs big. And I’m not even going to use most of it, I just want some plain dependency injection and maybe some tooling , like fast i18n.

Problem solved, evil destroyed
I found the solution! Why not have some fun AND learn the inner workings of C# and .Net? Why not build my own? So I did!

NanoDI is a small dependency injection container and tooling for .NET C# projects that are small or that do not need the complexity of bigger IoC solutions.

NanoDI‘s goal is to be small, fast and clean.

Links:
Nano Dependency Injection home
NanoDI Ohloh.net project page
NanoDI Google Code project

The code is junky by my standards but I’m slowly refactoring as my c# skills get better. Next week I’m going to finish scoping and start working on proxies and interceptors. You can help too!

Have a taste, have fun!

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.

- 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!

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!

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.

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.

• 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