The Öredev Developer Conference 2010

Each year since its inception, I have attended the Öredev developer conference. What makes it special is that it is a combined conference, with not only Java. This year it is especially important for me, since I can learn about both Android and iPhone development.

I will attend this year. Will you?

Do not forget to register at the Öredev site.

Microlog4Android V1.0 Released

Finally! After many months of struggling with Microlog4Android, the first official release is here. The core is the original Microlog code, but it is re-written to take full use Java SE features. For example, no Vectors are used. This means that the logging is faster than it was in Java ME. One important addition is the support for SLF4J. This should make it easy to migrate if necessary. This might also be an addition to future versions of Microlog. This way it should be easy to share code between Java ME and Android. The most important appenders are there as well.

Please download it from here. As always, any feedback and comments are welcome.

Microlog, Microlog4Android, SLF4J and Other Stuff

Right now a lot of interesting stuff are happening with both Microlog and Microlog4Android. I have been working with Microlog, while Jarle has been working on Microlog4Android (M4A). Let me start with Microlog.

I have started the work on Microlog V3.0. To start with I have been able to make the structure a little bit easier. For example I have removed some abstract classes, like the AbstractFileAppender. This was created for one purpose only, to be able to re-use parts of the file logging functionality between Microlog and M4A. A nice side effect of this construction is that we save some memory, both in terms of the memory footprint and run-time memory. Some bugs are fixed and there are some minor improvements.

Even though Microlog is my long time sweetheart, the most exciting things are happening within the M4A project. When moving the code from the Microlog to M4A, we skipped a lot of code. It was the core and only a few appenders that was moved. Working with the Android platform is quite different and the needs are a little bit different. For example, there is not really a need to log to the console. Instead we have replaced the ConsoleAppender with the LogCatAppender. This works as the built in log classes.  The reason for moving Microlog to the Android platform was to give Android developers more opportunities than the built in logging facilities. It is possible to use the logcat tool to log to file, but in that case you do not get the normal logcat logging in Eclipse. I have never heard of any way of logging to a file on the SD card or on the device, using the Android logging classes. With M4A it is possible to log to a file on the SD card. Just use the modified FileAppender to use M4A to log to file.

Another unique feature in Microlog is the ability to log to a remote server. This far we have the HTTPAppender which logs to a HTTP server. This is definitely something that is not possible with the standard Android logging facility. The HTTP logging is ideal for field test or similar, where the developers need to collect logs in a central place. No need to transfer log file manually. Note that during the development it might be more natural for individual developers to log to a file.

But that is not all! The most prominent addition is the SLF4J implementation. This gives you as a developer freedom to change the logging implementation whenever you feel like it. For example you want to use M4A during development for file logging, but want to remove the logging at deployment time. Just replace the M4A jar with the NOP implementation. If you want to revert back to good old Android LogCat logging (only), use the SLF4J implementation.

Last but not least, we have changed the PropertyConfigurator to read configuration files from an Android resource directory. The microlog.properties file could either be stored in the /res/raw or the /assets directory.

For those of you that want to try it out, it is available for download at: http://code.google.com/p/microlog4android/downloads/list
 
Please note that the latest release (V0.5) is rather experimental, but please try it out and give us feedback.

Ego Surfing - Microlog4Eclipse

Sometime I do some ego-surfing. I check if there is anything written about Microlog or any other open source projects that I am involved in. One funny thing is that I found the podcast that I and Darius Katz was part of as a ringtone. Maybe it is a bestseller? :) But I just found a more serious project, namely the microlog4eclipse project. It is an Eclipse plugin to simplify the usage of Microlog. Or as it say on the project page "Plugin for j2me microlog logger based on android adt plugin". I wonder if they are using the Android part of the Microlog library. There is no download available at the moment. I will investigate this further. Curious to check it out. It is interesting that someone is actually writing a dedicates Eclipse plugin for Microlog.

Some Words about Microlog and Some Maven Stuff

As you faithful readers know, I am a believer in “Release early, release often”. Therefore I have tried to streamline the release procedure as much as possible. It must not feel like a burden to do a release. In fact it should be as fun as watching a comedy film, almost at least. But this time it was not very fun.

About two weeks ago, one of my fellow Microlog developers committed some changes. It was time to make a new release! I always start out with the deployment of Maven artifacts to the Sonatype repository. Ever since I changed from using the website at SourceForge as a repository, to the Sonatype repository this is a process that works like a charm. It usually takes a little more than two minutes to do this. After that point the artifacts are available on a Nexus staging repository. If something is wrong, you can drop the release. If  the release seems to be ok, you have to close and promote the artifacts. When you close the staging release, a validation takes place. It checks if everything is ok.

The validation process has always worked for me since I first got it right. But not this time! It was complaining about missing information in all the module, information that is available in the parent module. As a coincidence, or not, a discussion about this was started on the Sonatype forums. As it turned out, this was a bug in a new validation scheme. There was a workaround, but I did not feel that it was worth it. From my experiences I could conclude that the folks at Sonatype usually fix this in a day or two. This time it took some days more.

When the validation bug was fixed it was time to give it a try again. This time the validation was complaining about a file not being signed (site.xml). A file that should not be signed, at least not according to me. This was part of the parent module. To get rid of this problem I decided to make a new sub-module for the site generation and try if I could sign the file this way. After a while I was able to sign the file. However now the site was not generated correctly. Not good! I moved the site.xml file back to the parent module, but kept the module since I thought the site generation was good anyway. The site generation worked again, but the file was not signed. Time to google. Now I found a solution that should work; disable the deployment of artifacts from the parent module. It worked, almost anyway. Now none of the artifacts was deployed. More googling. Aha, it is possible to disable the inheritance of some build plugins. Now it worked the way I wanted. Nice! The process of finding out how this should be done took me “only” about 4 hours. But there was one bonus; I could now disable artifacts modules that was not very useful to deploy. For those who wonders how to disable artifacts deployment, take a look at this helpful article.

Finally I managed to make the release and deploy the artifacts to the Sonatype repository. The artifacts are there in Maven central as well. For those of you who are interested, the version is now 2.3.5. Enjoy!

R.I.P. Kenai - Microlog4Android has been Moved

I admit it. I was wrong. It is not business as usual for microlog4android. Yesterday I got an e-mail explaining that Kenai will be shutdown. But fortunately there are other hosting options. I wanted to move the project as fast as possible and have a simple solution. I was recommended by my esteemed colleague Hugo about using Google Code together with GitHub. Google Code allows a project to use other service, such as GitHub, when Google Code  is not sufficient enough. Moving the source code was rather simple. The part that took time was to generate a new SSH key for my new computer. The nice thing with git is that all the history is preserved.

To move the source code from the Kenai git repository I did the following:

git pull git://kenai.com/microlog4android~source-code-repository

git remote add git@github.com:johanlkarlsson/microlog4android.git

git push origin master


It was as simple as that. The first line was needed to pull the source code out from Kenai, since I had no backup copy on my new computer. So for a user with the code on his computer, it would be even simpler.

Right now it is time for me to relax a little. I know I have a lot of things to do tomorrow at work. Please stay tuned for more updates about microlog4android.

The project:
http://code.google.com/p/microlog4android/

The source code:
http://github.com/johanlkarlsson/microlog4android

Newsflash! Microlog for Android - microlog4android

As you might know, Microlog has support for logging on the Android platform. However it has been living a rather discrete life in the shadow of the rest of Microlog. The other day I chatted with one of the other Microlog developers (Jarle) and we decided that it was suitable to create a new project for Microlog support on Android. We aim to re-use the Microlog core, but to optimize and such for the Android platform.

But why should I care? Android already has built in logging support that works rather well. I think that there are a couple of reasons for using Microlog on Android:

• Log4j API
• Resource effective
  
• Remote logging
  

Many people are used to the Log4j API when it comes to logging and prefer it over the Java logging API (which is used on Android). I have spoken to several users of Microlog and they have praised that it uses the Log4j API.

The Microlog has been built from scratch. It has been designed to be used on devices with a small amount of memory and with reduced processor capacity. Log4j on the other hand contains a lot of legacy code and has been used on computer with many times the capacity of an embedded device. For example Log4j contains a lot of classes that are there for being backward compatible with older releases.

The Microlog library has support for logging to remote servers and devices. This is not something that is built into the logging API found on Android. Remote logging is something that is very appreciated in Microlog. My guess is that it would be nice for Android developers as well.

As mentioned before, the project was registered a couple of days ago. Notice that we are in the startup phase and no release is available yet. We decided to use Kenai.com, since SourceForge does not meet our expectations. The project is called microlog4android. As always; any contributions are very welcome. Please contact me if you are interested in the project.

It would be interesting to know what you think of this idea. Is this something that is missing on the Android platform? Or is the built in logging enough for you?

Microlog Mentioned Again

Maybe a little bit of old news, but I thought I would share it anyway. Microlog was mentioned in this article:

http://weblogs.java.net/blog/editor/archive/2009/11/10/microlog-220-provides-reliable-small-footprint-j2me-and-android-loggi

Öredev Reflections

I have just finished 3 intense day at the Öredev conference here in Malmö. As always I have a lot of thoughts, ideas and inspiration after attending a conference. These are my reflections from the conference:

• I was missing a sessions about Android. Everybody is talking about the Android platform, but I wonder how many developers are actually developing for Android. It would be interesting to hear about some real Android projects. But maybe next year we will have some Android sessions?
  
• I was surprised by the session "Design to Development- Collaborating and Communicating Interaction Design". I have never heard of Theresa Neil before. She has some really good ideas. It was about communication between developers and interaction designers. This is something that I could relate to.
  
• My friend and colleague Davor had an interesting presentation called "Snow white and the seven dwarfs". It is a true about Davor (Snow White) and his team of developers (the dwarfs). He introduces the concept of Developers Exploratory Testing (DET), which is a way to do continuous testing in an agile project. The James Bach really liked the way how Davor has taken some ideas by James Bach and evolved them even further. Note: I am one of the dwarfs.
  
• Maven 3.x has some genuinely interesting news. The thing that I would like to try out the most is the new Maven console. I hope that it will help me to do faster builds.
  
• The keynote by Scott Hanselman was interesting. He gave some nice hands on tip for improving your efficiency as a developer.
  
• I have been registered as a Twitter user for some time now. Never used it much for anything other than Microlog news. During the conference I twittered a lot. I used the "I Tweet" Android client. Now it feels like I am hooked on Twitter. The Tweets was displayed on large screens all over the place, so it became very popular for many attendees. In fact tweets about #oredev was on the top list for Scandinavia.
• I attended a session by Neil Ford that was interesting. He is the author of "The Productive Programmer", a book that I recently read. As the name implies it is all about productivity for programmers.
  
• Some interesting stuff going around with the Java app store. I have always wondered why Java desktop applications are so underrated. I hope that Java desktop apps will get more popular.
  
• Ze Frank is very funny. He has a lot of very interesting social experiments going on and some unusual games.
  
• I liked the sauna and dinner on Monday. Did meet some interesting people there like Marc Lesser and Chris Hughes. The Swedish pickled herring on a toast was superb. The main course was Swedish fish, not candy kind, but a codfish.
• In general a very good conference. Of course I am a little bit biased since my company is one of the founders of Öredev.
  

That is all that I could remember right now. I guess that I have missed something out. Here are some pictures from the conference:


Marc Lesser about "Doing Less"

Terrence Barr about Java and Open Source


Theresa Neil about Interaction Designers and their interaction with software developers and vice versa.


Davor speaking about "Snow white and the seven dwarfs".


The Öredev Twitter feed. Notice the comments about Davor's presentation.

The No SQL presentation. To the left Emil Eifrem, Adam Skogman to the right. Notice their new definition of NO SQL.

The multi talented Ze Frank was very funny.

An air safety instruction. Notice the wizard to the right.

Chris Hughes about the secrets of the iPhone. Chris is a very cool geek, just the way a geek should be according to me.
Looking for some bugs?


Scott Hanselman and his keynote.

Powerful Logging in Java ME

The last couple of weeks has involved very much work. First of all I have been preparing the Microlog V2 release. Second I have been writing an introductory article to Microlog. It is now published over at Sun Developer Network. Please read the article and rate it.

http://java.sun.com/developer/technicalArticles/javame/javame-logging/

As always, feedback is very welcome. What do you think about the latest Microlog (V2) release? What do you think about the article?

Microlog Maven Repository

Right now I am deploying a signed version of Microlog V1.1.1. The reason for this is that the Microlog Maven artifacts are going to be moved to the Sonatype Maven repository. The next step is to upload the latest Microlog V2 to the same repository. By the way; I am going to use Sonatype OSS Repository Hosting. The reasons for putting the Maven artifacts there are many. First of all, using the SourceForge web hosting as a Maven repository is real bad. The primary problem is that I get all sorts of timeouts or other problems when deploying artifacts. For example, I have tried 5 times now to deploy but has not succeeded yet :( The other reason being that I want Maven to be a natural part of the Maven universe. The Sonatype repository is synched with the Maven central repository. When this is done, it is you as a user (developer) that benefits from that. You only need to specify the Maven dependency, without adding any new repositories. When the artifacts have been moved, I will write an article to explain exactly how this is done.

Now I will go back and try to deploy the artifacts once more. It seems that it failed for me.

Microlog V2.0.0 Finallly Available for Download

Today I have finally made the V2.0.0 release of Microlog. Please download and try it out. Feedback is very welcome!

Download it from here: https://sourceforge.net/projects/microlog/files/

The official release news:

"We have finally released the long awaited Microlog V2.0.0. The core has been reworked and very much improved. It is meaner and leaner than ever.

Noteworthy new features:

• New improved configuration
• Hierarchical logging
• HttpAppender with a sample servlet that you could do your logging to.
• More Maven friendly with small modules. This let you use only the part that you are interested in.

Microlog is a small, yet powerful logging library for mobile devices based on the Log4j API. Supports Java ME (J2ME) and Android. Logs to device, to PC or to servers online. Used in all phases from development on emulator/device to outdoor field-testing.

Microlog is licensed under The Apache Software License, Version 2.0 so it is possible to link and distribute commercial software with this library."

Microlog is Still Alive!

It was a while since I wrote about what is happening to Microlog. I myself have not been working very much on Microlog the last couple of weeks. But fortunately there are more developers working on Microlog. At the end of last week, the Microlog project was joined by Jarle Hansen. He has been improving the Bluetooth logging in Microlog, to work better on Ubuntu Linux. He has also written an excellent article on the subject "Using MicroLog over Bluetooth with Ubuntu and Eclipse".

Therefore I have released a new snapshot of Microlog. The snapshot version includes the changes made by Jarle Hansen, as well as some minor changes made by me. The snapshot version is also available in the Microlog Maven repository as well.

Report from Presentation at JavaForum in Malmö and Gothenburg

Last week I did present Microlog at JavaForum both in Malmö and Gothenburg. JavaForum is the Swedish JUG. It was a great honor to be invited to both these places. These are my reflections and thoughts about my presentation.

At the first presentation in Malmö there was around 50-60 people. I knew many of the people beforehand, which made me less nervous. The presentation went smoothly and I got some questions, that hinted me what to improve in the presentation. Unfortunately I did not had time to stay afterwards to get some more feedback.

Driving to the destination in Gothenburg at rush hours was not an easy task. My GPS device was out of battery, so I used Google Maps to find my directions. When no GPS device is attached, it uses GSM cells to figure out where you are. The accuracy is about 600 m in a city like Gothenburg. That is maybe enough when walking in a city to find out where to go, but by car that is not enough. What a shame I was not in a Hollywood movie, where the accuracy seems to much better than that. Anyway I found the place to be and was there on time.

Afterwards I had the opportunity to speak to some people in the audience. First of all I got a question about what Maven help I wanted. It is mainly about getting Maven to generate better packages for the releases. For more details see this discussion.

One other question I got, was "What is the reason for not being able to do printStackTrace() and re-direct it to a log? Or do you have any idea how to solve it?". The thing is that I have not found a way to re-direct to another destination within Java ME. The reasons are:

1. The System.err is final in the System class found in Java ME (CLDC). I do not know why this is, but it hinders you as a developer from setting these to something like a FileOutputStream or similar.
2. The method printStackTrace() comes in different flavors in Java SE. For example, the public void printStackTrace(PrintStream s) is useful to direct the stack trace to another destination than the default one. This is not available in Java

One workaround that works under some condition is to re-direct the output from your Java MIDlet outside the JVM found in your phone. On the Symbian platform there are such applications available. If the problem is reproducible in the WTK, you could run it look you normally do. By using the ConsoleAppender you get both the normal exception message along with the stack trace. BTW do you know any other workaround? If yes, please enlighten me.
That is all for now. Thanks to Björn Granvik and Rickard Thulin for inviting me to JavaForum.

Microlog Recent Updates

It feels like I have spent ages on re-factoring the Microlog code. When I look in the rear mirror I see two things that has caused the slow progress. First of all there has been a lot of hard decisions that has been made. For example, how should the setup of the logging hierarchy work like? Should I use the same approach that is used in Log4j or should I invent a new and clever way? The answer is that I used the Log4j way, but adopted it to Microlog. The second problem has been the lack development time. Not much to say about that, Microlog is a project that I do on my spare time. Last but not least, everythings seems to take more time than originally planned.

But what has happened? The biggest change must be the new configuration. The configuration has been centralized and I use dependency injection to inject my properties into Microlog. The properties are fetched using Microproperties. This is in fact the first project where I have used Microproperties. This is good since I managed to improve the Microproperties source code along the way. I have spent many hours writing tests for the logging hierarchy and improving the code along the way. As always, I have commited the source code very often. As such the code in the source repository is very much in flux. Do not expect the API to be stable for yet a couple of weeks.

The coming days I plan to adopt all the Appender classes to comply to the new configuration. A nice side effect is that the code will be smaller. Also I will test out the HttpAppender. It is implemented as it is now, but not tested against a server. This is a much awaited feature. I am really looking forward to make this code available for all Microlog lovers.

Please be patient! I am certain that the new version of Microlog will be worth waiting for.

Premature Generalization is the Root of All Evil

Finally! I have now finished the first reincarnation of the new logger hierarchy for Microlog. It is a very simple tree structure that keeps track of all the created Logger objects. I choose to do a specialized tree implementation for the purpose, not a general tree implementation. Since there is no tree implementation in Java ME, it could be tempting to do a tree implementation for Java ME. When finished this could be re-used in a lot of other Java ME projects. This got me thinking about those good old days when I was a junior programmer, just fresh out of school.

I was involved in a research project with the purpose of showing the opportunities with an embedded device with an ethernet connection. The embedded device contained a simple web server that was equipped with simple CGI support. My assignment was to create a web pageswith a Java applet for administration of the embedded device. This was actually a proof of concept study. If we managed to convince our product managers about our genius invention, we would of course re-use the code for the real product. So far, so good.

I made a very ambitious design before even starting to do some coding. I can tell you, my manager was really nervous when I did not start code immediately. "No worries, good design is important for fast and good implementation. You need to be prepared really good before starting your implementation!". This was how I was taught. Anyway I managed to do a real fancy design, with many really nice-to-have-classes. I ruled the world of design and my way to fame and glory was laid out for me! As part of the design I did a very general API for the communication. General design is good, I reasoned. This was a BIG mistake!

When we were closing in on delivery date for the demonstration, I had made the general network communication. However I was not finished with real implementation, the parts that was vital for the demonstration. Anyway I was finished about 30 minutes before my project manager was going to leave for the airport, to meet the people who was sponsoring our research. I was tired since I have worked all night and my project manager was not happy. For me it was embarrassing that I was not able to deliver something that I was proud of and I was to close to the deadline. My project manager did manage to do a successful demonstration. Finally the management decided to make our prototype into a real product.

After a couple of weeks it was decided that we was going to use another low level protocol for the communication. It turned out that my general design was useless, since I did not anticipate all the aspect of the problem. But what did I learn from this rather embarrassing moment of my life as developer?

First of all I realized that I do not have the powers, like Nostradamus, to see into the future. I also came to the conclusion that you have to know the domain, before making any generalization. You have to do your first implementation in that domain, before you should make any general design. When you continue to evolve your product, you can figure out what parts of the code that is reasonable to generalize.

So I invented a rule that is "Premature generalization is the root of all evil design". It is of course inspired by "Premature optimization is the root of all evil". Nonetheless I think it is a good rule. This is why I choose to do a specialized tree structure for Microlog, instead of making a more general tree implementation. I have seen the phenomena of "premature generalization" in many projects since. For some reason it tends to be junior developers who fancies these general designs. Today many more people learns design patterns, than when I finished school. There is a big risk that you use to many design patterns, without really understanding the consequences. I prefer to get the code working and to deliver it in time for the demonstration. When adopting my golden rule stated above, this is not a problem. Thanks to agile methods, like Scrum, you are forced to make your application ready for demonstration early on. But that is another story.

Microlog Group @ LinkedIn

One networking forum that I really like is LinkedIn. It is a proffesional networking forum, not focusing on the social aspect like Facebook. I have learnt to know a lot of people through LinkedIn. Many of my present and former collegues and friends are there as well. There are many interesting groups at LinkedIn, like the FOSS Proffesionals Group.

I have had the idea of creating a Microlog group lingering around in my head for some time. During the weekend I finally decided to create a Microlog grup. When the decision was made, the registration was simple. I used the new project description and added a group description. Unfortunately the existing Microlog icon did not comply to the required criteria, but I settled with the LinkedIn default icon.

Please join the Microlog group at LinkedIn.

Microlog & Microproperties Updates

This weekend I decided to start the replacement of the old Microlog configuration with the new one; Microproperties. Ironically this work was to copy the file reading part from Microlog to Microproperties. When this was done and tested, I decided to do a new Microproperties release. This is the new V0.2.0 release. When this was done I added Microproperties V0.2.0 to Microlog.

However this weekend is approaching its end and I decided to do the first snapshot release of V2.0.0, before continuing my work. The Android extension is included in this release. My hope is that developers who prefer the Log4j API will find Microlog for Android an interesting alternative. Please download and try it out!

Microlog4Android

I have continued with the re-factoring of Microlog. Tonight my plan was to re-arrange the package structure to separate the Microlog core from the rest of the code. One reason for this was to make it easier to make different flavors of Microlog. The Microlog core should be possible to execute on CLDC. The plan was to move the MIDP specific classes to its own package structure. One new flavor that I had in mind was the Android flavor of Microlog. Many people have asked me about Microlog on Android. My answer has always been something like "It should work on Android, at least the core.".

After the re-factoring it was time to prove my point, that it is possible to execute Microlog on Android. And it did! The setup was simple, it was Microlog with a ConsoleAppender and a SimpleFormatter. Not so very much at the moment, but I think it is a good starting point.

During the process I learnt that it was in fact possible to see the System.out.println() statements. Many people claim that it is not possible to see the System.out.println() in the Console. That is true, but it is possible to get hold of the prints. The trick is to show the "LogCat" view. This is activated this way:

1. Select "Window->Show View->Other..."
2. Open up the Android category and select "LogCat"

You can now see the output from System.out.println() and System.err.println(). A nice side effect is that you now can see your Microlog statements as well!

One might ask why should I use Microlog on Android, since there already is a logging API available. This is a perfectly legitimate question. The reason would be that Microlog brings a Log4j like API to the Android platform, but the supplied API is the java.util.logging package. I have always preferred the Log4j API, which was the reason why I choose it for Microlog in the first place. But I guess that you could use Log4j on Android, but Microlog is designed for constrained devices, which Log4j was not.

Microlog Work During the Weekend

During this weekend I finally started my work on the new Microlog V2.0.0. The first thing I did was to implement support for client identification. I did it by adding a property to the Logger that is called clientID. The clientID must be set manually. Since I plan to change the configuration classes, I did not put any effort in adding support for this in existing configuration classes. This will be implemented when I change to to Microproperties.

I have added support for showing the clientID. The SimpleFormatter and ConfigurableFormatter always prints the client ID, if not null. It is possible to use the PatternFormatter as well. You use the %i to print the clientID. It is as simple as that.

The developer have the option of setting the clientID manually or letting Microlog create a unique clientID. I still need to figure out an automatic way of creating a unique clientID. I will have to get back on that.