Multiple ActiveRecord connections without Rails

Here is a little trick that allows having connections to multiple databases with pure ActiveRecord.

First, a little recap. Here is the code for making a single connection:

require 'active_record'

ActiveRecord::Base.establish_connection(
  :adapter  => 'mysql',
  :database => $env[:db_name],
  :username => $env[:db_user],
  :password => $env[:db_pass],
  :host     => $env[:db_host])

class MyTable < ActiveRecord::Base
end

The nice thing with this approach is that any additional class will automatically reuse the defined connection.

However, if we need to have multiple connections the approach is a little different:

require 'active_record'

ActiveRecord::Base.configurations["db1"] = {
  :adapter  => 'mysql',
  :database => $env[:db1_name],
  :username => $env[:db1_user],
  :password => $env[:db1_pass],
  :host     => $env[:db1_host]
}


ActiveRecord::Base.configurations["db2"] = {
  :adapter  => 'mysql',
  :database => $env[:db2_name],
  :username => $env[:db2_user],
  :password => $env[:db2_pass],
  :host     => $env[:db2_host]
}

class Table1 < ActiveRecord::Base
  establish_connection "db1"
end

class Table2 < ActiveRecord::Base
  establish_connection "db2"
end

This approach allows defining any number of database connections and any number of tables on those connection. It also allows adding connections and classes dynamically based on some runtime information. The only drawback is that in each class you are required to define which connection needs to be used.

HOWTO: Suppress EJBTHREE-1337 warning

If you are running JBoss 5.X with JBossWS there is an annoying warning that is printed each time a web service is called that looks like this:
EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

First of all, don’t get alarmed – there is no actual problem. The warning is targeted at the framework developers and not at the end users – all it means is that JBossWS is using a recently deprecated API which still works. There is nothing end user can do to fix this and it doesn’t matter anyway since everything just works.

The problem however is that the warning clutters the log file and makes debugging harder than needed. It is easy to suppress it though and I will show you how.

First, locate jboss-log4j.xml file which should be found under ${JBOSS_HOME}/server/default/conf. If you are using a runtime configuration other than default, locate the file under configuration that you actually use. This file is used to configure logging output of the JBoss.

Inside the file search for “Limit categories” – you should find a list of <category> definitions. Edit it to look something like this:

   <!-- ================ -->
   <!-- Limit categories -->
   <!-- ================ -->

   <!-- Suppress EJBTHREE-1337 warning -->
   <category name="org.jboss.ejb3.stateless.StatelessBeanContext">
     <priority value="ERROR"/>
   </category>

You are basically telling JBoss to suppress any WARN or lower messages from the class that generates those warnings. Now just restart JBoss and the warning should disappear.

HOWTO: Simple profiling with Spring AOP

As part of its AOP package, Spring has a very nice little utility class called CustomizableTraceInterceptor which can be used to easily profile and debug your application using automatic logging of method invocations, including name of the method, parameters (using toString()), return values and invocation times. It doesn’t replace proper debugger and/or profiler but it can provide you a lot of interesting data with minimal cost. It can be even used in production as it can be turned on/off easily.

So how does it work? It uses Spring AOP capabilities to wrap around beans you choose to add a little code that will output invocation data before the method is called, and will output return values and execution time after it finishes. The best practise it to apply the interceptor on client facing beans – in other words entry points of your server so you can easily monitor what is called, when it’s called and how long did it take.

So how to add it? First thing you need to define a subclass of CustomizableTraceInterceptor like this:

public class MyTraceInterceptor extends CustomizableTraceInterceptor {

  protected void writeToLog(Log logger, String message, Throwable ex) {
    if (ex != null) {
     logger.info(message, ex);
    } else {
     logger.info(message);
    }
 }

 protected boolean isInterceptorEnabled(MethodInvocation invocation, Log logger) {
   return true;
 }
}

By overriding writeToLog() method you control output severity and destination. Overriding isInterceptorEnabled() allows you to finely control when tracing should happen – you could for example decide not to trace methods that start with “foo*”. Simply returning true means trace always.

Now that you have your interceptor defined it’s time to apply it to your beans. Add this to your spring.xml

    <bean name="traceInterceptor" class="MyTraceInterceptor" dependency-check="none">
        <property name="enterMessage" value="ENTER: $[targetClassShortName].$[methodName]($[arguments])"/>
        <property name="exitMessage"
                  value="EXIT: $[targetClassShortName].$[methodName]() : $[invocationTime]ms : $[returnValue]"/>
    </bean>

    <bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator" dependency-check="none">
        <property name="beanNames" value="*RequestListener,*Notifier"/>
        <property name="proxyTargetClass" value="true"/>
        <property name="interceptorNames">
            <list>
                <value>traceInterceptor</value>
            </list>
        </property>

        <property name="order" value="2"/>
    </bean>

First definition instantiates the interceptor and defines format of the trace messages.

Second bean applies the interceptor to your beans using “beanNames” to select the beans with the wild card. If you use “*” it will mean it will wrap all your beans, so you probably want to input something meaningful here.

And that’s it. Rerun your app, call some methods and open up log files. You will see the traces there.

Hit 1k reputation on StackOverflow

I’ve hit a 1000 reputation at stackoverflow (my profile here) a few days ago and it’s already up to 1129,  which puts me in about top 5%-10% bracket of users there. Yay

It’s really interesting how the reputation thing works there.

For those unfamiliar with the site, it basically allows anyone to post programming related questions and then those questions are answered by community. The cool thing about it is that anyone can answer any question, and everyone can also rate answers and questions of other people by up or down voting. Each up vote gives you some reputation, down vote reduces it (but by smaller amount). It’s a great resource as there are a lot of knowledgeable people there and most questions are answered very quickly.

Gaining reputation there is hard because it seems that there are more experts there than those seeking knowledge. It makes sense I think because if you know about that site it already means that you know some stuff about programming, and those who are really clueless won’t know or try to find out about it. Because of this over-abundance of experts finding questions to answer is hard.

There are basically two types of questions there. One is simple generic ‘what are the benefits of polymorphism’ type of question. Almost everyone thinks they can answer those so usually those questions have 5-6 answers within a minute of being posted. The site displays all answers ordered by their rating, so it’s a game of who can get the most reasonable answer fastest because after about 15 minutes no new answer has much of a chance of getting any up votes because it will buried so deep no one will bother looking at it. These questions also usually get the most up votes because many people are interested in those.

The second type of questions is the extremely specific ones – ‘When I use X with Y on Z OS, and I press A with B, I get exception E”. Sometimes those are not answered at all. But unless it’s very esoteric someone will usually know the answer within couple of days, and the answer will usually be rewarded by point or two, because not many will know about the subject to vote on it.

Starting was not easy. The only type of questions you can reasonably expect to answer when you just start there is the specific ones. I think it took me couple of weeks to just get to 100 rating. But with time you get to learn the system, and as your reputation grows you are also more likely to get upvoted so it’s sort of self reinforcing effect. As evidence, it took me couple of days to get from 1000 to 1100 without really trying to. Additionally as you get more and more answers in, you start to get a steady stream of reputation from old answers that people sometimes find.

My next target? 10k I wonder how long that would take.

How to become a rock star developer?

Is it the hard work? Well yeah that helps.

Is it the constant learning? Sure why not.

Will it help to study some other peoples work? You bet it will.

But the real secret – it’s much simpler. Ask yourself…

How many rock stars don’t like playing rock music?

How many rock stars don’t enjoy listening to rock music?

Yes. Exactly.

EDIT:

There were a number of negative comments on DZone so I guess should have clarify what’s this post is about.

This post is a joke, a parody of sorts on all the “X things you need to do to become Y” which are all too common on various blogs. Unfortunately, since I have to explain, I guess it wasn’t too funny to begin with

Regardless, as Russians say, every joke has some truth in it.

In this case the truth is that you have to be passionate about your work, and that is IMO the most important factor in becoming great developer. When you are passionate about something everything else comes easy and effortlessly because you enjoy extra effort it’s no longer an effort but a fun. When you are passionate about something it rubs on other people too and you gain their respect, people come to you for advice and so on. So indeed one of the key elements to becoming good at anything is to be passionate about it. Perhaps it’s obvious to most of you but from my experience most of people in this business are in it for a paycheck. So by just being passionate you automatically become… well.. “a rock star”.

HOWTO: Run tests with Embedded JBoss

I’ve needed to create an environment for running unit tests on EJB3 JBoss application this week. There were few GOTCHAs so for the benefit of future generations here is a simple recipe for running your unit tests on Embedded JBoss.

First a link to Embedded JBoss wiki page. You can find some information there. Also download the latest version (I used beta3.SP9) from there. We are going to use Maven to get the jars but you still need the configuration files from the download.

Ok, lets setup our maven dependencies.

First define repository if you don’t have it yet:

<repository>
   <id>jboss</id>
   <name>Jboss Repo</name>
   <layout>default</layout>
   <url>http://repository.jboss.com/maven2</url>
  <snapshots>
     <enabled>false</enabled>
   </snapshots>
   <releases> 
     <enabled>true</enabled>
   </releases>
 </repository>

Now add actual dependencies for embedded jboss:

<dependency>
  <groupId>org.jboss.embedded</groupId>
  <artifactId>jboss-embedded-all</artifactId>
  <version>beta3.SP9</version>
  <scope>test</scope>
 </dependency>

<dependency>
   <groupId>org.jboss.embedded</groupId>
   <artifactId>jboss-embedded</artifactId>
   <version>beta3.SP9</version>
   <scope>test</scope>
 </dependency>

<dependency>
   <groupId>org.jboss.embedded</groupId>
   <artifactId>hibernate-all</artifactId>
   <version>beta3.SP9</version>
   <scope>test</scope>
 </dependency>

<dependency>
   <groupId>org.jboss.embedded</groupId> 
  <artifactId>thirdparty-all</artifactId>
  <version>beta3.SP9</version>
   <scope>test</scope>
 </dependency>

Now lets create a test class. It will look just like your normal test class but you need to add the following method to start and deploy JBoss

@BeforeClass
 public static void startJboss() throws Exception {
   Bootstrap bootstrap = Bootstrap.getInstance();
   bootstrap.bootstrap();

   bootstrap.deployResourceBase(MyBeanOne.class);
   bootstrap.deployResourceBase(MyBeanTwo.class);
 }

Two things happen here. First, bootstrap() method launches Embedded JBoss with basic configuration. With standard JBoss it would be enough since it would automatically deploy all ears. In this case though, we need to explicitly tell it what to deploy – that’s what deployResourceBase() command does.

Now that you have Embedded JBoss starting and deploying before your tests, you can write any code that tests those beans. For example:

@Test
 public void testMe() throws NamingException {
   InitialContext context = new InitialContext(); 
   MyBeanLocal bean = (MyBeanLocal)context.lookup("MyBean/local");
   bean.doSomething();
 }

And now the GOTCHAs.

First for JBoss to run it needs some configuration. Remember that zip you downloaded? Open it up, find bootstrap folder inside and then copy entire contents of that folder into test/resources folder of your maven module. That's the basic configuration. If you want something additional, like your own datasource, you can add it into the test/resources/deploy folder as you would normally add it to deploy folder of standard JBoss.

We are not done yet. If you are running on Java 6 and the chances are that you are, it will still not work. You must add the following JVM property to your unit test configuration to force JVM to run in Java 5 compatible mode: -Dsun.lang.ClassLoader.allowArraySyntax=true

And the last thing -  if you are running from IDE you are probably deploying from exploded classes folder and not from packager jar/ear. If so, there is a good chance that Embedded JBoss will fail because it won't have enough file handles to properly deploy your classes. To fix it on Linux use 'ulimit -n <some large number>' to increase the number of file handles. On windows look up your own solution.

And that's it. You now have working Embedded JBoss test environment. Congratulations

@Test
public void testMe() throws NamingException {
InitialContext context = new InitialContext();
MyBeanLocal bean = (MyBeanLocal)context.lookup("MyBean/local");
bean.doSomething();
}

Is eye candy underrated?

Suppose you’ve got a new customer request for a feature, or maybe some great new idea by marketing people that will certainly increase sales of your product. Whether you are working in agile or a more traditional environment you are usually going to get a bunch of functional requirements (program should do a,b and c) and sometimes some non-functional requirements (performance targets, security). Sometimes you will also talk about usability – but in my experience you are never going to get “and it must look really really good” as a requirement. Most of my experience is in management systems development, so it is an assumption, but I am willing to guess that in most “business oriented” software eye candy is not a requirement.

You are not your user

I have recently read a great book called “Why Software Sucks?” and the basic idea of the author is that most of the people involved in making software come from very technology oriented engineering background (he uses the word geeks but lets not go there) and so to us everything is an engineering problem. We value technology and features and prefer more functionality over everything else really. So it is more natural for us to focus on features and performance and elegant solutions and mostly ignore usability and eye candy. But there is a catch – “You are not your user“. The things we value may be not the things our users value. And when developing applications we need to focus on what users want not what we think we would want if we were users. There are a lot of examples in the book of what happens when developers do what they think is usable instead of what their users would consider usable, and it’s not pretty.

But what about visuals and eye candy? Is it possible that the same thing happens here as well? Is it possible that while we as developers often consider eye candy irrelevant and even waste of resources, our users actually value it much more?

Well, some evidence is certainly out there. Take video games for example – good looking games with tons of eye candy just sell much much more. Take Hollywood – the big budget flicks with most effects often are criticized for being too shallow – and yet they are the ones that bring the most money and most people go to watch them. And how about Apple which took eye candy to a whole new levels? I have never used macs in my life, but if you ask me which is better mac or pc in terms usability – I would go with Mac.

So good looks sell but what is even more important here is that often good visuals are even more important than actual features. Macs have less software available for them then PCs. Big budget flicks have usually much less substance than independent movies. Most of recent blockbuster video games are just remakes of existing formula with almost no actual gameplay improvement.

So, yes, I believe that eye candy alone is worth a lot more than we usually think it is, even for applications that are not mass market oriented. (quick test, which bug tracking software is better: bugzilla or jira?). It’s great for first impression and thus sales and it’s great for continuing user satisfaction and thus retaining customers and creating word of the mouth hype. Features and usability alone are not enough anymore – your users demand that it also  must look really really good.

How to: implement singleton EJB in JBoss

As promised in the rant post – here is the simple and elegant way of creating a singleton bean in JBoss.

@Service
@Local(MySingletonLocal.class)
public class MySingletonBean implements MySingletonLocal {
  private Object sharedData = new Object();  

  public void workOnSharedData() {
    // TODO do your things here
  }

}

As you can see, it’s really simple and it looks exactly the same as the @Stateless bean definition except that you replace it with @Service annotation. In order for this to compile you must link with jboss-ejb3-ext-api.jar (found at JBOSS_HOME/common/lib/ directory) during compilation because that annotation is proprietary for JBoss.

Ok, we have the bean – but how we can use it? Well, that’s even easier – just use @EJB annotation the same way you would use it for any regular stateless bean.

@Stateless
public class SingletonUserBean implements SingletonUser {

    @PersistenceContext private EntityManager em;
    @EJB private MySingletonLocal mySingleton;

     // ..... the rest of it

}

And that’s it – everything will be properly injected for you by the container.

I’ve tested this solution in the JBoss 5.0.1GA – it is supposed to work with older versions as well, but you should try it yourself.

One last note – starting from EJB3.1 spec they are adding @Singleton annotation which is going to be the standard solution for these types of problems. One of the nicer things about it is that they are also adding synchronization support with annotations so we wouldn’t have to deal with it manually (the hard part of singleton beans like that is handling the concurrency issues since it’s shared for all application). And even though it is not part of the spec it is assumed that the new @Singleton beans will be shared in the cluster – so if you have few application servers for high availability or load balancing, you will be able to use this technology to share state between them (for example counting requests for the cluster and not just sinlge server). See more details here.

The five minute rule

It seems sometimes people just completely miss the point, even the brightest of them. Yesterday I was doing some prototyping for some new project I am working on which is based on JBoss EJB3 implementation, and since most of my background comes from Spring based project, I was looking for some answers. Nothing too complicated, mind you, I just needed some way to have one of the EJB beans to hold some shared state for all the application, something that is really straightforward in Spring, and something that I assume most of the applications out there today need at one point or another.

So, since I am no JBoss expert (yet ) I did the sensible thing and tried to google it. Well, simple queries didn’t find anything for me (“jboss service”, “jboss singleton”, “jboss ejb singleton” etc), but in the end I stumbled upon something called @Service annotation which is a proprietary annotation of JBoss and can be used for this kind of stuff. Which is documented in this page. Which is while it is couple of pages long and have some code examples lacks one very basic thing – it doesn’t show how to use the thing in the simplest and most common use case, the one I was actually looking for. So instead of just copying and pasting the sample into my code and just running it and continuing to some other stuff I had to spend about an hour trying to figure this stuff out. (BTW the solution turned out extremely simple, elegant and it doesn’t require any of the stuff that is printed on that “help” page – I will put it in a separate post for others to reuse)

Which is why I think some people just don’t get it. I mean they are great developers and the eventual solution is really great and working flawlessly – but they miss the most  important point. Open source frameworks and projects that provide infrastructure are just tools that allow us developers to solve some common problems. The reason these things are actually used (and not reimplemented in house) is that they provide solutions without the need to really go deep and understand all the implementation issues. When I write some application for an end user any time spent on figuring out some stuff that should have been in the manual is time not spent on providing value to my customer.

And this is my main point – you must know who your customer is. It just doesn’t work otherwise. And if you develop open source project that is going to be used by other developers – your customers are  those other developers, usually the ones working on end user oriented software.  This is not about who got the coolest implementation or the tightest algorithm or the most generic platform. This is about providing simple solutions to most common problems. And the reason why you should care is that even though we are not the ones paying your bills  – your success and success of your project is directly proportional to its adoption rate. And guess where that adoption rate comes from.

Here is an example of project that does get it – Terracotta. It will take you less than 5 minutes to understand what it does and what problems it solves. And if you decide to try it out, it will take you less than 5 mintues to download and run an interactive sample of the technology (which is very cool by the way). Compare that site with site for JBoss Microcontainer which is the core of the new JBoss 5 release. I assume it is really good piece of technology but try to spend only 5 minutes on their site and try to understand what it does and whether is solves any of your problems. I couldn’t. And if I was really evaluating it I would just discard it at that point and go look at the next thing. Because there is always another thing (competition is great isn’t it?).

So here is my 5 minute rule – make sure your site and documentation can provide some initial idea of what problems you solve in less than 5 minutes. Make sure that for the most common problems the solution (including examples or better yet cookbook style recipe) is no father than 5 minutes away. Otherwise you are just not competitive with the projects (which by the way may be less technologically advanced) that do provide those answers. Take a look at the success of Spring Framework. Take a look at the success of Ruby on Rails when they took the world by storm using that video of creating a blog application in under 15 minutes. They did it despite the many technological problems that they had (like native threads and performance). This is really fast world. Help yourself by helping me quickly. Otherwise no one will care.

Art of Organizational Refactoring

I am doing some thinking about what it takes to implement Scrum in an organization that is not used to or even familiar with agile concepts, let alone Scrum. When you start a new team or a new company implementing new methodology is rather easy – you select people based on what you believe the required roles and functions are, there is no legacy to overcome and everybody is open to whatever process you are installing. There is no inertia, there is no resistance and there is no conflicting interests you need to account for.

Of course the exact opposite is true when you are attempting to implement Scrum (or whatever else) in an organization with strong waterfall culture. It’s not just about telling people about how in Scrum you do so and so, go to this meetings, here is how product backlog should look like – and then you are done. It is much more challenging because of “that’s not how we are used to do things around here” – so not only you have to be able to teach what Scrum is, but also be able to overcome years of practise of doing something else.

And that is not the hardest part. It is impossible to make all the changes overnight – this stuff takes a long time to get absorbed and interned and used to. So there is going to be some time where organization is not going to be very “organized” for the lack of better word. And yet, there are customers and sales and support and contracts that need to be taken care of, and that cannot be “pushed back” until we can figure out how to do the Scrum stuff properly.

And this brings me to the concept of refactoring. In software engineering, refactoring is the art of taking an existing piece of software that maybe is using some old technology that is a bit obsolete by now, or maybe it is written in somewhat inefficient way and taking that piece of software and rewriting it in such a way that from the outside it keeps looking exactly the same, performs exactly the same function (but better) while inside it gets completely overhauled and made more efficient, with less bugs and easier to maintain. And I call it an art because yes there are some practices and tricks which help you do that refactoring, but in the end, every software is different and what might have worked on a previous project wouldn’t work on the next one, so to be able to do this and succeed requires some flexibility and creativity.

And I think similar art form should be developed for implementing Scrum in organizations that are currently stuck in the old ways. The similar challenges apply – keep the outside interface, support clients, make the sales, while in the same time transforming the entire organization to much more efficient, flexible and adaptive proceses. And yes, even though some techniques are probable shareable, in the end every organization is different and it will take each one a unique path on its road to agile success.