February 16, 2011
February 08, 2011
Use cases for logging
There are use cases for logging events in your application, including performance logging of audit logs. These can be seen as the implementation of functional requirements, and are typically implemented using AOP. The application signals some sort of an event, and one implementation could be to simply write out the event in a logfile. But these kinds of logging are hardly ever implemented in libraries, as they are the result of functional requirements.
Another typical case of logging is error handling. But a well-designed library should signal the application using the library something is wrong, and let the application decide what to do when an error occurs. Often this involves at least logging it, once and only once by the way!
So why include logging in a library? It might be useful if it's a closed source library you can't easily debug. But for open source libraries using a debugger is the way to go if you want to know what's going on.
Logging in a library
If a library has logging in it anyway, how should it be implemented ideally? There are some useful tips listed in the dark art of logging about what and how to log in general, but there's more...
In a library, please think about the logging library dependency. When writing code, an important part of controlling dependencies is by depending on interfaces instead of implementations. So when depending on a logging library, please just depend on an interface or facade (such as slf4j) instead of an implementation (such as log4j). A single dependency on e.g. slf4j-api would be sufficient, let the application using the library decide which implementation it wishes to use.
Unfortunately there are still a lot of libraries out there depending on commons-logging, log4j or other implementations. Using these libraries in an application involves a process of excluding the logging dependencies and including the slf4j bridging implementations, e.g. using the Maven dependency management. This way the applications and its libraries all log via the slf4j-api, and a single logging implementation can be chosen by the application or the environment it is deployed on (OSGi container anyone?).
Finally a special note to the log4j adepts out there. If you insist on using log4j in your library, try to avoid depending on the log4j appenders and filters, or use the PropertyConfigurator. Doing so makes it impossible to use the slf4j bridging.
It's also not a good idea to include a log4j.properties file in your library jar. Since log4j looks for a config file on the classpath, this config file might get to be used for the entire application although the application adds a config file itself to the classpath. In that case it's a matter of who comes first on the classpath, which might lead to unexpected logging behavior that is really hard to figure out.
It is in fact a tip if you're using log4j and your application logging don't seem to use your own log4j.properties: search the classpath, including third-party jars, for other config files.
February 07, 2011
Things get a bit more complicated when developing OSGi bundles using Scala, and to be more specific, when using Scala actors. The Scala libraries are available as OSGi bundles, so that's a no-brainer. But what happens when you want to use actors in Scala, and you decide to use the Scala actors from the Akka project?
Akka itself consists of multiple modules, and each of them is an OSGi bundle. Some of the Akka 3rd party dependencies are on the other hand not available as OSGi bundles, so that's why Akka provides one big dependency OSGi bundle. Not really the nicest solution, but the Akka guys can't help it that their dependencies aren't available as OSGi bundles. When creating actors in Akka, each actor is registered in the ActorRegistry so the actor can later on easily be looked up, sent messages to be started and stopped etc. This ActorRegistry is a singleton, so there's one registry for all actors in an application.
Using Akka actors and the ActorRegistry in an OSGi environment triggers some interesting architecture questions however. An OSGi application bundle acts as some sort of mini-application, and allows to export services and keep all the other functionality of a bundle private. If this bundle creates actors however, they're registered in the application-wide ActorRegistry, and are available to other bundles without being exported explicitly as OSGi services. This makes the use of OSGi services superfluous, that's one way to look at it. But at the same time the bundle can no longer control which actors (acting as services) are made available publicly: every actor is accessible via the ActorRegistry.
In an OSGi environment the application bundles are mini-applications themselves. They can be started and stopped, they can execute logic when started and stopped (using a bundle activator), they come and go. When a bundle starts it typically creates it actors, when stopped the actors should be stopped. Be careful however when using the ActorRegistry to stop the actors of a bundle, as using shutdownAll would stop all the actors of all the bundles.
There are things you can try to achieve some more control in what your bundle makes available to other bundles. Using TypedActor's or by using Scala case classes as messages you achieve more strong-typed behavior, which is a good thing anyway. But it also allows you not to make these classes available to other bundles by not including them in the OSGi bundle's export-package. Using the functionality of your actor without the message classes becomes impossible this way, but the actor is still available in the ActorRegistry, and can be controlled this way by other bundles (stopped, started, ...).
Ideally in an OSGi environment each bundle should have it's own ActorRegistry, and make actors available to other bundles by exporting them as OSGi services. Or at least it should be possible to use Akka actors this way. Or maybe there are other solutions to achieve this more application-bundle-like behavior?
There's a thread on the Akka-users mailinglist on this topic. There's a suggestion to use classloader isolation for the different bundles and use remote actors to communicate between bundles. Feel free to provide any other insights or suggestions in the comments.
February 04, 2011
So you decided to hire people to work for your company or project, as did we. In a previous post we talked about identifying the target audience for your job opening, we'll now deal with the profile your ideal candidate should match.
Think about what you find really important
Instead of writing down a long list of required knowledge, to us how you work is more important. We like the getting-things-done mentality, but the quality of work delivered is equally important to us. It's mandatory you think about the design and architecture of software, and not just to start coding. Modularity, scalability, reliability and other -ilities will come back to haunt you if you don't pay attention to them. This is also the experience we were talking about earlier.
And of course we can't afford to ignore all of this, since this is the core of our business. We are a team of highly specialized experts providing real quality solutions to our customers. This is the way we work, but it's also who we are and how we are known in the market. So this is also our way to check if you'll fit in in the team, and match the philosophy of our company.
So when composing the ideal profile of our candidates, we don't list required knowledge of this or that framework. We do however provide some pointers that should give you as a candidate an idea of what knowledge we think is required to do the job we have in mind for you. Don't worry if you don't already know all of it, that's ok. But some topics at least should ring a bell, and ideally these are exactly the things you already knew a little bit, but always wanted to know more about. As a consequence, your ability and willingness to continuously learn is very important to us.
So think about what you find really important aspects for the profile of a candidate. It's easy to write and entire page of must-have knowledge and experience, it's much more difficult to bring a consistent message of what your requirements really are and at the same time effectively deliver your message as a future employer. It should breathe the culture and atmosphere of your company, and even this profile part of a job opening should offer a clear view what a candidate can expect when actually working in the company.
We'll talk about this perspective and what to think about when formulating your offer as an employer should in the next follow-up post.
February 02, 2011
As Xume consultants we are often involved in the process of hiring people for our customers, both in composing job profiles as well as in screening potential candidates. And we've also a lot of experience in analyzing what a customer is really looking for when we receive a request consultancy work formulated as a vacancy. But writing a job profile is not an easy task. Now we've written one down ourselves, we'll share some thoughts and tips on how to do it, and motivate the choices we've made.
So what do you have to think about when you want to write a vacancy to hire people? In this post we'll focus on identifying your target audience. Follow-ups will deal with key requirements, offering perspective to a candidate and finally some words about the selection procedure.
Identify your target audience
When writing a text in general, you always have to think about your target audience. This is especially important when writing a job vacancy. In our case, we deliberately chose to write a single job profile for both senior and more junior candidates. The motivation behind this is very simple: how will you distinguish between both?
We don't believe the age of a candidate or the years of work experience matters very much in our sector (IT). It's all about relevant experience, and you can have more relevant experience after one year of professional work than some other people have after ten years.
Another option is to list required knowledge of this or that framework. If you do so, be aware that you are defining criteria in terms of knowledge and not necessarily in terms of experience. This might be relevant if you actually need your candidate to bring specific knowledge aboard, or you don't want to invest too much in the education of your candidate, e.g. when hiring a consultant. But in our case we're hiring employees and we do want to invest in training and education, so the required knowledge boils down to knowing Java and JEE. We believe you as a candidate will acquire further knowledge quickly if you have relevant experience in general, when you are part of a team of experts and if you haven proven you're eager to learn.
In a follow-up post we'll talk about defining the key requirements for our ideal candidate. In the meantime do check our job opening, and if you know anyone that might be interested in joining us, please spread the word!