As a X-mas present for you, I have released a new snapshot version of Microlog. The most important update is the updated RecordStoreLogviewer. The default settings was not the same as the RecordStoreAppender. This made it hard to read the log from the record store, although it was possible. The was also some problems with NullPointerExceptions, which is now removed.
Please download the latest snapshot release and try it out.
Dec 25, 2008
Dec 21, 2008
Yet Another Review: The Book "Producing Open Source Software"
Running an open source project is not at all what I expected. I started out with one small open source project, Microlog. I have now founded several other projects and the Microlog project has grown. As the time has passed a lot of decisions has to be made, ranging from pure development issues to questions about how to handle project members. Finally I started to think along these lines; "There must be someone who has been running an open source project and written a book about it". Most book that I found was related to license issues. However I found one book that seemed to fit my purposes which is "Producing Open Source Software" by Karl Fogel. I have finished reading the book and I would like to tell you my opinions and thoughts about this book.
The book starts with guidelines how to start an open source project when you have some code that you want to share. Although I have started several projects, the book gave me insight into several issues that I have not been aware of or neglected. The author goes through all the documentation that is needed to get started. The list is comprehensive and contains some documentation that I have missed out, for example developer guidelines. Fortunately most of the documentation seems to be in place for my own projects, even though there are some subjects missing. Consequently I think that I will spend some time on improving the documentation. I will keep the book nearby to get everything in place. The next part is " Technical Infrastructure". As the name implies, this goes through how to setup things like mailing lists, forums etc. The books briefly mention canned hosting, such as SourceForge, but I would like to get more information on the subject. This is one the weak spots of the book. There are millions people out there running a project on SourceForge, or a similar site. The "Social and Political Infrastructure" is by far the most interesting part of the book. The expression "Benevolent Dictator" is explained, which is the final decision-making authority within the project. Since I am more or less the benevolent dictator in the Microlog project, I really enjoyed reading this part. I found myself laughing and people on the bus looking like a was from Mars or something. The next subject in line was "Money". This was totally new for me since none of the projects that I am involved are sponsored by a company, but they are only spare time projects. The author on the other hand is one of the founders of the Subversion project, which is sponsored by a company. This part is well written and it seems that the author does know what he is speaking about. What I am missing is a part on how to fund a project that started out as a spare time project. This is one of the questions that I was looking for an answer to. So I guess that I will have to find the answer elsewhere. The "Communications" part describe how you should handle the communication within the project, including how to handle rude people or people that are creating to much noise in the forums. Not one of the most interesting subjects in the book, but still worth reading. The part about "Packaging, Releasing and Daily Development" was rather familiar to me. In the era of Agile development, this is of great significance. If the "daily development"-part is not working correctly, the project runs a big risk loosing developers. The users may abandon the project if the release process is not working the way it should. Imagine if your project has an unclear release strategy, or the version numbering is dodgy. Managing volunteers is not always as easy at it would seem. To learn this, you should read the chapter with the same name. The last part of the book covers a subject that in itself could fill a whole book; "Licenses, Copyrights and Patents". This is the motivation for keeping the chapter short, the author only included a short introduction to the subject. If you wish to deep diver into this subject, choose a book on the subject.
For those of you who have not started an open project, I think that this book is a very good "getting started guide". For people like me that is already running a project, the book gives invaluable tips. Even people that are participating in open source project could get something out of this book, even though this is not the primary audience. One last thing to mention, the book is under open copyright. In other words you could download it and distribute is as you like. Nice!
The book starts with guidelines how to start an open source project when you have some code that you want to share. Although I have started several projects, the book gave me insight into several issues that I have not been aware of or neglected. The author goes through all the documentation that is needed to get started. The list is comprehensive and contains some documentation that I have missed out, for example developer guidelines. Fortunately most of the documentation seems to be in place for my own projects, even though there are some subjects missing. Consequently I think that I will spend some time on improving the documentation. I will keep the book nearby to get everything in place. The next part is " Technical Infrastructure". As the name implies, this goes through how to setup things like mailing lists, forums etc. The books briefly mention canned hosting, such as SourceForge, but I would like to get more information on the subject. This is one the weak spots of the book. There are millions people out there running a project on SourceForge, or a similar site. The "Social and Political Infrastructure" is by far the most interesting part of the book. The expression "Benevolent Dictator" is explained, which is the final decision-making authority within the project. Since I am more or less the benevolent dictator in the Microlog project, I really enjoyed reading this part. I found myself laughing and people on the bus looking like a was from Mars or something. The next subject in line was "Money". This was totally new for me since none of the projects that I am involved are sponsored by a company, but they are only spare time projects. The author on the other hand is one of the founders of the Subversion project, which is sponsored by a company. This part is well written and it seems that the author does know what he is speaking about. What I am missing is a part on how to fund a project that started out as a spare time project. This is one of the questions that I was looking for an answer to. So I guess that I will have to find the answer elsewhere. The "Communications" part describe how you should handle the communication within the project, including how to handle rude people or people that are creating to much noise in the forums. Not one of the most interesting subjects in the book, but still worth reading. The part about "Packaging, Releasing and Daily Development" was rather familiar to me. In the era of Agile development, this is of great significance. If the "daily development"-part is not working correctly, the project runs a big risk loosing developers. The users may abandon the project if the release process is not working the way it should. Imagine if your project has an unclear release strategy, or the version numbering is dodgy. Managing volunteers is not always as easy at it would seem. To learn this, you should read the chapter with the same name. The last part of the book covers a subject that in itself could fill a whole book; "Licenses, Copyrights and Patents". This is the motivation for keeping the chapter short, the author only included a short introduction to the subject. If you wish to deep diver into this subject, choose a book on the subject.
For those of you who have not started an open project, I think that this book is a very good "getting started guide". For people like me that is already running a project, the book gives invaluable tips. Even people that are participating in open source project could get something out of this book, even though this is not the primary audience. One last thing to mention, the book is under open copyright. In other words you could download it and distribute is as you like. Nice!
Dec 18, 2008
The Microlog Project is Growing
The Microlog projects is growing! My colleague Henrik Larne told me the other day that he has started to use Microlog. He especially liked the BluetoothSerialAppender, which is used for logging to a Bluetooth server on your PC or on another phone. Before I had time to say welcome, he contributed with a better version of the BluetoothSerialAppender. The developer has the opportunity set the server URL, in those cases where the automatic find function does not work. Very handy I would say. I suggested that he would join the project, which he did. All in all we are now four developers. Since we soon will start working on Microlog V2.0, this is very good timing. But that is not all; Henrik wrote an excellent article about how to get started with Bluetooth logging. If you are going to start logging using Bluetooth this article is a good starting point.
Labels:
Microlog,
News,
Tips and Tricks
Dec 7, 2008
Useful Microlog Feedback
During this week I received some really useful and tangible feedback for Microlog. First I received feedback regarding file logging, i.e. logging with the
The feedback for the
What started out as a discussion about an
I try to handle the requests with the same tactics I use for my wife; I try to be as responsive as possible. The initial code changes are in place, as well as a snapshot release. These changes will probably lead to a continued discussion. This shows the real power of open source development. With about 3-4 iterations I had a solution that satisfied the developers need, and it took 3-4 days to solve. What a joy it is to be part of an Open Source project (like Microlog)!
FileAppender
. Later this week I got feedback regarding the reading of logs from the RecordStore
.The feedback for the
FileAppender
was from the beginning rather straightforward. The developer had found that the JavaDoc and the code were not in sync. The documentation stated that there should be a setDirectory()
method available. As it turned out there was no such method. The setFilename()
& getFilename()
had the same documentation. In other words a ordinary copy-and-paste mistake. The missing setDirecotory()
method was not so serious, but yet annoying. I implemented the setDirectory()
method within a couple of minutes. I did not really consider the implications of this solution.
What the developer really wanted was a method to set the filename, with or without the full path. He did not want to make a separation between the filename and the directory. The final solution was rather elegant. If the user sets a filename with a full path, this is used. Otherwise the user defined filename is used, but the first root directory is used. A feature request for some kind of rotating file logging was also included. The feature request for a rotating log created two featuture requests at the end, a RollingFileAppender
and a RotatingFileAppender
.What started out as a discussion about an
HTTPAppender
in Microlog, lead to a discussion about how to load a log from the RecordStore
. One developer wanted som examples on how to read the log content. The code was really spread out in the RecordStoreLogViewer
class. This is a MIDlet that is used for reading the log content. The idea is that you switch to this MIDlet when you want to read the log from another MIDlet. What I did was simple. I extracted the load logging parts from the RecordStoreLogViewer
into a new class called RecordStoreLogLoader
. This was a good thing. The log reading functionality has no right to exists within the RecordStoreLogViewer
MIDlet. The is a matter of separation of concerns, as some object orientation guru might have put it.I try to handle the requests with the same tactics I use for my wife; I try to be as responsive as possible. The initial code changes are in place, as well as a snapshot release. These changes will probably lead to a continued discussion. This shows the real power of open source development. With about 3-4 iterations I had a solution that satisfied the developers need, and it took 3-4 days to solve. What a joy it is to be part of an Open Source project (like Microlog)!
Dec 4, 2008
Software Development for Mobile Applications
Microlog was today presented at a German conference called "Softwareentwicklung für mobile Anwendungen". Translated to English it is "Software development for mobile applications". The presentation was done by Karsten Ohme, a Microlog team member. Many thanks Karsten for promoting Microlog!
Dec 3, 2008
Newsflash: Microlog Featured on the Mobile & Embedded Podcast
During the Öredev conference, yours truly and Darius Katz was interviewed by Terrence Barr, Sun Senior Technologist and Ambassador for the Mobile & Embedded Community. The interview should give you a little more insight into the Microlog project.
Please download and listen to the podcast:
http://today.java.net/pub/a/today/2008/12/03/javamobility-podcast62.html
Enjoy!
Please download and listen to the podcast:
http://today.java.net/pub/a/today/2008/12/03/javamobility-podcast62.html
Enjoy!
Nov 30, 2008
Short Review of "The Productive Programmer"
I have just finished reading the book "The Productive Programmer" by Neal Ford. For those it may concern; this is a short review of this book.
The first thing that struck me is that the book was not very thick. In my eyes this is a good thing. I have seen to many bloated books, that does have a problem to focus on the subject at hand. It appears that the book is inspired by the excellent book "The Pragmatic Programmer" by Andy Hunt & Dave Thomas. In fact it is recommended by Neal Ford.
The book consists of two parts; "Mechanics" & "Practice". The "Mechanics" part is about the tools you should use, and some tips & tricks on how to use them. For example, there are examples on how you could use Ant for more than building your software. The section "Focus" is the most interesting section. This is where you learn how to kill distractions, something along the lines of "Gettings Things Done" by David Allen.
The "Practice" part contains some best practices that Neal consider important to know, like Test Driven Design. I really like the YAGNI section, where YAGNI stands for "You Ain't Going To Need It". This part is all about a problem that many developers has encountered, namely speculative programming. For example, a class that contains "good to have"-methods, that is there to be future proof. The leason is; do not add anything that you do not need because "You Ain't Going To Need It". This is not something new, but it is still a common problem. Another section of the "Practice" part is the "Ancient Philosopheres". Neal uses ancient knowledge and adopts it software development. This is an unusual approach that I really liked.
If you want to be a more productive programmer, this is a good start. The book is short and easy to read. No fluff, just stuff kind of book.
The first thing that struck me is that the book was not very thick. In my eyes this is a good thing. I have seen to many bloated books, that does have a problem to focus on the subject at hand. It appears that the book is inspired by the excellent book "The Pragmatic Programmer" by Andy Hunt & Dave Thomas. In fact it is recommended by Neal Ford.
The book consists of two parts; "Mechanics" & "Practice". The "Mechanics" part is about the tools you should use, and some tips & tricks on how to use them. For example, there are examples on how you could use Ant for more than building your software. The section "Focus" is the most interesting section. This is where you learn how to kill distractions, something along the lines of "Gettings Things Done" by David Allen.
The "Practice" part contains some best practices that Neal consider important to know, like Test Driven Design. I really like the YAGNI section, where YAGNI stands for "You Ain't Going To Need It". This part is all about a problem that many developers has encountered, namely speculative programming. For example, a class that contains "good to have"-methods, that is there to be future proof. The leason is; do not add anything that you do not need because "You Ain't Going To Need It". This is not something new, but it is still a common problem. Another section of the "Practice" part is the "Ancient Philosopheres". Neal uses ancient knowledge and adopts it software development. This is an unusual approach that I really liked.
If you want to be a more productive programmer, this is a good start. The book is short and easy to read. No fluff, just stuff kind of book.
Nov 21, 2008
Öredev 2008: Android, Blackberry & Clean Code
The last day of Öredev 2008 started with a keynote by Robert C Martin (the picture above). It feels hard for me to reproduce the content of the keynote. His session about "Clean Code" was a little bit more tangible. He showed an example on how to simplify a method, and decompose into several small methods. The final example was very, very simple. The session gave me a new perspective on how to write good code. Maybe it is time to clean up some of my code?
I have never tried to develop for a BlackBerry device. The primary reason is that BlackBerry devices are not very common here in Sweden. Anyhow I thought it would be interesting to know a little bit more about the BlackBerry development. One thing that impressed me was that how Java friendly the device is. Every "native" application is written in Java. As a consequence all the APIs are written in Java. If you were to develop a Java application for a Symbian device you would be limited when writing your application in Java ME, since not all the APIs are reachable from Java. On many mobile devices the Java applications are hidden somewhere deep inside some strange folder. This means that your Java ME applications are some kind of "second class citizen". On a BlackBerry on the other hand, the Java ME applications that you write is as important as the pre-loaded applications. Really nice! If there is a new feature, like GPS, it is immediately available for you as a developer. That is not the case when developing for a lot of other mobile devices. The development environment seems to be pretty mature, including such stuff as memory statistics and a profiler.
A new kid on the block in Java world is the Android Open Source platform. For those of you that have not heard of it; it is a new mobile platform. It is developed by the Open Handset Alliance, which consists of many mobile operators, mobile manufacturers and software companies. The most famous company of this bunch is probably Google Inc. As mentioned it is Open Source, which gives a lot of new possibilities. For example, it could be possible to port it to any kind of embedded device. The Android platform is based on a Linux kernel. On top of that we have a Dalvik VM. You develop your application in Java and compiles to a Dalvik executable. Although it is not considered as Java by definition, you as a Java developer hardly notice any difference. The API is based in Java v1.5, with some unwanted APIs removed. As of today there are not many Android devices available, but inevitably there will be some more devices real soon. The Androiod platform seems to be targeted at the smartphone segment.
Before the last session it was time to attend a lottery draw. To be a part of the lottery you would have to solve a developer scrabble, which I did. Believe it or not, I won a brand new Eee PC 901. A real nice piece of equipment, although I have not tried it extensively. I guess it is nice to have when you are on the road.
Here are the rest of the photos from day 3 at Öredev 2008:
The Android session was pretty cool.
This shows how wrong it can get when a critical application fails. From the presentation by Kevlin Henney.
Kevlin Henney in action.
I have never tried to develop for a BlackBerry device. The primary reason is that BlackBerry devices are not very common here in Sweden. Anyhow I thought it would be interesting to know a little bit more about the BlackBerry development. One thing that impressed me was that how Java friendly the device is. Every "native" application is written in Java. As a consequence all the APIs are written in Java. If you were to develop a Java application for a Symbian device you would be limited when writing your application in Java ME, since not all the APIs are reachable from Java. On many mobile devices the Java applications are hidden somewhere deep inside some strange folder. This means that your Java ME applications are some kind of "second class citizen". On a BlackBerry on the other hand, the Java ME applications that you write is as important as the pre-loaded applications. Really nice! If there is a new feature, like GPS, it is immediately available for you as a developer. That is not the case when developing for a lot of other mobile devices. The development environment seems to be pretty mature, including such stuff as memory statistics and a profiler.
A new kid on the block in Java world is the Android Open Source platform. For those of you that have not heard of it; it is a new mobile platform. It is developed by the Open Handset Alliance, which consists of many mobile operators, mobile manufacturers and software companies. The most famous company of this bunch is probably Google Inc. As mentioned it is Open Source, which gives a lot of new possibilities. For example, it could be possible to port it to any kind of embedded device. The Android platform is based on a Linux kernel. On top of that we have a Dalvik VM. You develop your application in Java and compiles to a Dalvik executable. Although it is not considered as Java by definition, you as a Java developer hardly notice any difference. The API is based in Java v1.5, with some unwanted APIs removed. As of today there are not many Android devices available, but inevitably there will be some more devices real soon. The Androiod platform seems to be targeted at the smartphone segment.
Before the last session it was time to attend a lottery draw. To be a part of the lottery you would have to solve a developer scrabble, which I did. Believe it or not, I won a brand new Eee PC 901. A real nice piece of equipment, although I have not tried it extensively. I guess it is nice to have when you are on the road.
Here are the rest of the photos from day 3 at Öredev 2008:
The Android session was pretty cool.
This shows how wrong it can get when a critical application fails. From the presentation by Kevlin Henney.
Kevlin Henney in action.
Nov 20, 2008
Öredev 2008: Agile, Scrum & Boom Chicago
The 2nd day of Öredev was very long and thrilling. As a change I attended a lot of non-technical sessions. The first session was called "Scrum @ Yahoo" held by Gabrielle Benefield. She presented her own story about the introduction of Scrum within Yahoo. The story was presented in a funny and intense way. One thing that struck me was that the managers was afraid to loose their jobs when introducing Scrum. As she pointed out correctly; Scrum is very developer centric. For some reason I have never done this reflection. The same concern was also raised by Allan Kelly. But they seemed to have the same opinion; the managers should not be afraid of loosing their jobs. The most funny slide from Gabrielles session was the one above. This tells a lot about the power of Scrum.
During the day I had the privilege to meet up with Terrence Barr in person. He is a Sun Evangelist and Ambassador for the Mobile and Embedded Community. We had some interesting discussions about Microlog, the Mobile and Embedded Community and about the Java ME Open Source community in general.
We ended of the evening with some refreshing drinks and snacks. The improvisation group Boom Chicago entertained us with an funny interactive show. After the show I was pretty tired and got home rather early.
Here are the rest of the photos from day 2 at Öredev 2008:
Terrence Barr and me at the Öredev entrance.
Learn the Scrum way from Gabrielle Benefields presentation. Note; this is not the way Scrum should be introduced.
The keynote speaker of the 2nd day; James Bach.
James Bach showing a photo of where his laptop last was seen, namely the the central station in Stockholm, Sweden. He was a little bit disappointed that there was no swedish polices at the station on a Sunday afternoon.
The Boom Chicago group entertaining us.
"Mick Jagger" and "Amy Winehouse".
During the day I had the privilege to meet up with Terrence Barr in person. He is a Sun Evangelist and Ambassador for the Mobile and Embedded Community. We had some interesting discussions about Microlog, the Mobile and Embedded Community and about the Java ME Open Source community in general.
We ended of the evening with some refreshing drinks and snacks. The improvisation group Boom Chicago entertained us with an funny interactive show. After the show I was pretty tired and got home rather early.
Here are the rest of the photos from day 2 at Öredev 2008:
Terrence Barr and me at the Öredev entrance.
Learn the Scrum way from Gabrielle Benefields presentation. Note; this is not the way Scrum should be introduced.
The keynote speaker of the 2nd day; James Bach.
James Bach showing a photo of where his laptop last was seen, namely the the central station in Stockholm, Sweden. He was a little bit disappointed that there was no swedish polices at the station on a Sunday afternoon.
The Boom Chicago group entertaining us.
"Mick Jagger" and "Amy Winehouse".
Labels:
Agile Development,
News
Nov 19, 2008
Öredev 2008: Sun SPOT, Buglabs, Sun Java ME SDK , Benefits of Open Source Development etc
The first day of Öredev 2008 is over. It has been an interesting day, with many new impressions. There are a lot of exciting things happening within the Java ME community right now. The Java ME platform is becoming available on a numerous platforms and in different flavors. I really liked the Sun SPOT device when it was announced at JavaOne 2006, and the BUG demonstration today was impressive. Both these devices triggers a real "must have now" feeling. If you ever had the opportunity to try out the Sun SPOT, you know what I mean.
Sun SPOT in action at the Waygroup stand. The robot is about to knock down the Jayway mug.
I must remind you all that Microlog works on Sun SPOT out-of-the-box, and has some special classes for Sun SPOT development. These classes are merged from the Microlog4SPOT project.
Another new attention-grabbing technology is the JavaFX framework. Before the presentation I did not have deep knowledge of what it was, but now I think that I have grasped the vital parts of JavaFX. It could be seen as a new Java platform that is put on top of the existing Java platform. It is kind of write once, run everywhere but with a new twist. Looking forward to try it out.
A tool I would like to try out is the new Sun Java ME SDK. It is available as an early access release today. According to the people from Sun the 1.0 release should be available in the beginning of 2009. The new Java ME SDK is a combination of the Sun Wireless Toolkit and the CDC Toolkit. It has been re-worked and uses the Netbeans framework as its foundation. The aim is to have a tool that is useful for all Java ME development. As such it has support for Blu-ray development.
There was also a session about LWUIT, the new UI Toolkit from Sun. It could be used as a better version of the LCDUI. It is inspired by the Swing toolkit, but for Java ME. Please take a look at my article about the LWUIT Makeover demo. I believe there will be reasons to watch out for LWUIT.
Here are some additional pictures from Öredev 2008:
A couple of minutes before the first keynote speech with Ted Neward from ThoughtWorks.
The official Microlog t-shirt. This is a limited edition only used by a couple of developers in the world.
All the mugs knocked out. Again we see the Sun SPOT in action.
A LEGO Mindstorm NXT waiting for some action.
Some advantages of Open Source Software in development.
Some more advantages of Open Source Software in development.
Sun SPOT in action at the Waygroup stand. The robot is about to knock down the Jayway mug.
I must remind you all that Microlog works on Sun SPOT out-of-the-box, and has some special classes for Sun SPOT development. These classes are merged from the Microlog4SPOT project.
Another new attention-grabbing technology is the JavaFX framework. Before the presentation I did not have deep knowledge of what it was, but now I think that I have grasped the vital parts of JavaFX. It could be seen as a new Java platform that is put on top of the existing Java platform. It is kind of write once, run everywhere but with a new twist. Looking forward to try it out.
A tool I would like to try out is the new Sun Java ME SDK. It is available as an early access release today. According to the people from Sun the 1.0 release should be available in the beginning of 2009. The new Java ME SDK is a combination of the Sun Wireless Toolkit and the CDC Toolkit. It has been re-worked and uses the Netbeans framework as its foundation. The aim is to have a tool that is useful for all Java ME development. As such it has support for Blu-ray development.
There was also a session about LWUIT, the new UI Toolkit from Sun. It could be used as a better version of the LCDUI. It is inspired by the Swing toolkit, but for Java ME. Please take a look at my article about the LWUIT Makeover demo. I believe there will be reasons to watch out for LWUIT.
Here are some additional pictures from Öredev 2008:
A couple of minutes before the first keynote speech with Ted Neward from ThoughtWorks.
The official Microlog t-shirt. This is a limited edition only used by a couple of developers in the world.
All the mugs knocked out. Again we see the Sun SPOT in action.
A LEGO Mindstorm NXT waiting for some action.
Some advantages of Open Source Software in development.
Some more advantages of Open Source Software in development.
Labels:
Java ME,
News,
Open Source
Nov 16, 2008
Improving your Java Source Code with Open Source Code Analysis Tools; FindBugs, Lint4j & CheckStyle
One of the best way to improve your own code is by looking at other peoples code. Another way to be a world class programmer is to use a source code analysis tool, like FindBugs, Lint4j, CheckStyle. Here is a short & compendious summary of these tools.
FindBugs
This is my favorite source code analyzer, simply because it tends to find the most horribly, awful bugs. FindBugs is based on the concept of bug patterns. A bug pattern is a pattern in your code that implies a bug. The FindBugs tool is initially developed at The University of Maryland. According to Professor William Pugh, "Students are good bug generators". As such many of the students mistakes has generated a new bug detector implementation. One might think that these are mistakes only made by beginners, but as it turns out many of these problems are also part of production code. For example, the FindBugs tool was used on the Sun JDK and it found some serious bugs.
The FindBugs tool is available as a stand-alone GUI, Ant, Eclipse and Maven plugins. During development I prefer to use a plugin in my IDE, which in my case is Eclipse. The source code analyzer should also be a part of the build process.
For all the newcomers to Eclipse, this is how you install the FindBugs plugin from the update site:
Select this menu and within seconds you will have a list of potential problems in your code. These are all gathered together with the compiler warnings. When you click on a warning, your code will be displayed with a bug:
Double-click on the bug and you get an explanation on what the warning really means:
Now you could start figuring out what to do with the warnings. Hopefully FindBugs has found some bugs for you.
Here is where you find more information about FindBugs:CheckStyle
As the name implies, CheckStyle check the style of code. For example, it can check if you follow the Sun Java Code Convention. But CheckStyle can find more than this. It contains a multitude of rules that are considered bad programming practices. Some are very common, and others are a little bit more doubtful. In other words CheckStyle is not really in the same category as FindBugs, but I find it a tool that is worth having in your Java programmer toolbox. Installation of the CheckStyle Eclipse plugin is made the same way as with FindBugs, but you use another link (found below).
Here is where you find more information about CheckStyle:
The Lint4j tool is a tool that is similar to the famous lint tool for the C programming language. I have not used it very much, but it have found some code that smelled badly. When I have used it for a while I will communicate my opinions to you.
Here is where you find more information about Lint4j:
Some Final Words
Here are some final words of advice
I hope these tips will help you to improve your code, and will make you a better programmer.
Happy bug hunting!
FindBugs
This is my favorite source code analyzer, simply because it tends to find the most horribly, awful bugs. FindBugs is based on the concept of bug patterns. A bug pattern is a pattern in your code that implies a bug. The FindBugs tool is initially developed at The University of Maryland. According to Professor William Pugh, "Students are good bug generators". As such many of the students mistakes has generated a new bug detector implementation. One might think that these are mistakes only made by beginners, but as it turns out many of these problems are also part of production code. For example, the FindBugs tool was used on the Sun JDK and it found some serious bugs.
The FindBugs tool is available as a stand-alone GUI, Ant, Eclipse and Maven plugins. During development I prefer to use a plugin in my IDE, which in my case is Eclipse. The source code analyzer should also be a part of the build process.
For all the newcomers to Eclipse, this is how you install the FindBugs plugin from the update site:
- Select menu "Help" -> "Software Updates" -> "Find and Install..."
- Select "Search for new features to install" and press the "Next" button.
- Press the "New Remote Site..." button.
- Enter your name for the update site, for example "FindBugs Update Site", and enter the following into the URL field: http://findbugs.cs.umd.edu/eclipse
Press the "OK" button - Press the "Finish" button. Eclipse will now contact the update site and check for the latest version.
- After a while you will get a list with the features that are available to you. Press the "Next" button until you get to the "Install" page. Press the "Finish" button.
- When you get to the "Verification" page, press the "Install" button.
- Eclipse will now run the "Update Manager" and download the plugin.
- When everything is finished, you will be prompted to restart Eclipse. Please press "Yes" and Eclipse will be restarted.
Select this menu and within seconds you will have a list of potential problems in your code. These are all gathered together with the compiler warnings. When you click on a warning, your code will be displayed with a bug:
Double-click on the bug and you get an explanation on what the warning really means:
Now you could start figuring out what to do with the warnings. Hopefully FindBugs has found some bugs for you.
Here is where you find more information about FindBugs:CheckStyle
As the name implies, CheckStyle check the style of code. For example, it can check if you follow the Sun Java Code Convention. But CheckStyle can find more than this. It contains a multitude of rules that are considered bad programming practices. Some are very common, and others are a little bit more doubtful. In other words CheckStyle is not really in the same category as FindBugs, but I find it a tool that is worth having in your Java programmer toolbox. Installation of the CheckStyle Eclipse plugin is made the same way as with FindBugs, but you use another link (found below).
Here is where you find more information about CheckStyle:
- CheckStyle homepage
- The Eclipse CheckStyle plugin (that I use)
The Lint4j tool is a tool that is similar to the famous lint tool for the C programming language. I have not used it very much, but it have found some code that smelled badly. When I have used it for a while I will communicate my opinions to you.
Here is where you find more information about Lint4j:
Some Final Words
Here are some final words of advice
- Use it from the start of your project. Otherwise you could be overwhelmed by the enormous pile of things that you should correct.
- Do not use full checking from the beginning, start by using the default settings. When you have checked your code you could add the checks that you find useful.
- Do not check in your code without running your source code analyzer.
- Add code checking as part of your continuous build process. Your build should not fail when it detects some problem(s). The reports could be used to ensure that nobody check in code that is bad.
- Use common sense, you should not obey the tool relentlessly without questioning. The FindBugs tools is the most effective, but sometime it indicates things that are not really a bug. Use the filtering capabilities found in the tools to filter out what is not relevant. This let you focus on the real bugs.
- A source code analysis tool should not replace other good practices like unit testing and code reviews. These are all complementary tools to make your code close to perfect, and avoid those nasty bugs.
I hope these tips will help you to improve your code, and will make you a better programmer.
Happy bug hunting!
Labels:
Open Source,
Tips and Tricks
Nov 11, 2008
Yet Another Microlog 1.1.0 Snapshot is Available for Download
I have released yet another 1.1.0 snapshot release of Microlog. It contains very few, but important changes. To ease you from the pain of using the source repository, I prefer to make snapshot releases as often as possible.
Important changes:
Important changes:
- Performance improvements: the Microlog core has been optimized for speed.
- The level checking code was not working correct. This is now corrected.
Nov 9, 2008
Using Eclipse MTJ for Java ME (J2ME) Development
A while ago I was experiencing pre-verification problems with EclipseME. Rather annoying I must say. I spent several useless hours before getting it right. This is when I decided to upgrade to Eclipse Mobile Tools for Java (MTJ), even though it has not reached v1.0.
Eclipse MTJ is the official Eclipse plugin for Java ME (J2ME) development. I was started several years ago, but did for some unknown reason never took off. On the other hand, EclipseME, developed by Craig Setera, was actively developed. I must say that I am impressed by the work Craig has done with EclipseME. Fortunately foundation did something about the situation with Eclipse MTJ; they started "from scratch" with the source code. They imported the EclipseME code into the Eclipse MTJ project, which replaced the old code.
You might wonder what are the reasons for using the Eclipse MTJ. First of all I have not had any problems with the pre-verification since I upgraded, which save me a lot of time. There are numerous bugs that has been removed, and the environment feels more stable. Another reason is that all of the Java ME specific menus is easier to access. For example; the Java ME project wizard is accessible at the same level a standard Java project. I believe that it is important to support great open source project like this. One of the best way to do so, is by using it and providing feedback.
For those of you that already have EclipseME installed I recommend the article "Converting to Eclipse Mobile Tools for Java". The rest of the bunch could use the same article, but skip the migration part.
Eclipse MTJ is the official Eclipse plugin for Java ME (J2ME) development. I was started several years ago, but did for some unknown reason never took off. On the other hand, EclipseME, developed by Craig Setera, was actively developed. I must say that I am impressed by the work Craig has done with EclipseME. Fortunately foundation did something about the situation with Eclipse MTJ; they started "from scratch" with the source code. They imported the EclipseME code into the Eclipse MTJ project, which replaced the old code.
You might wonder what are the reasons for using the Eclipse MTJ. First of all I have not had any problems with the pre-verification since I upgraded, which save me a lot of time. There are numerous bugs that has been removed, and the environment feels more stable. Another reason is that all of the Java ME specific menus is easier to access. For example; the Java ME project wizard is accessible at the same level a standard Java project. I believe that it is important to support great open source project like this. One of the best way to do so, is by using it and providing feedback.
For those of you that already have EclipseME installed I recommend the article "Converting to Eclipse Mobile Tools for Java". The rest of the bunch could use the same article, but skip the migration part.
Labels:
Java ME,
Open Source,
Tips and Tricks
Nov 8, 2008
How I Created the Microsuite Website with Google Sites
I have been thinking about creating the Microsuite website for a long time. In fact it was several months ago that I registered the domain microsuite.org. The thing is that it does not amuse me very much to create websites. The latest couple of months has been filled with a lot of more interesting stuff. It has been very hard for me to prioritize between all the projects that I am involved in. There are still a lot of work with Microlog, there are many ideas that I want to try out for Microinstall, and I also want to be an active part of the Voxtr project. So on, and so fourth.
Just the other day I ran across Google Sites. It is a service that is built on top of a wiki software, formerly known as JotSpot. But you do not need to know any HTML at all :) At least that is what they claim on the Google site information pages. So this seemed like a perfect choice for me. I already knew what information I wanted to put on the site, so it was merely some hard work that was ahead of me. My experience it that computer related stuff does not always takes the time you wish it would do. Most of the time it takes much longer than expected, at least when you try something new. To my surprise this was an exception. I spent only one evening creating the first version. Rather nice!
For those of you that has not visited the Microsuite website, I can tell you a little bit about what it is. The Microsuite is a collection of the Micro projects that I am involved in. To this date they are; Microlog, Microinstall & Microproperties. Microlog is a logging tool for Java ME developers. Microinstall consists of some small classes that makes it easy to distribute your MIDlet(s). The Microproperties project has not yet delivered any code, but the intention is to create a good properties framework for Java ME. The plan is to create the code from scratch, with some inspiration from the properties classes found in Microlog. Please visit the Microsuite website to find out more about the different projects that are part of Microsuite.
Just the other day I ran across Google Sites. It is a service that is built on top of a wiki software, formerly known as JotSpot. But you do not need to know any HTML at all :) At least that is what they claim on the Google site information pages. So this seemed like a perfect choice for me. I already knew what information I wanted to put on the site, so it was merely some hard work that was ahead of me. My experience it that computer related stuff does not always takes the time you wish it would do. Most of the time it takes much longer than expected, at least when you try something new. To my surprise this was an exception. I spent only one evening creating the first version. Rather nice!
For those of you that has not visited the Microsuite website, I can tell you a little bit about what it is. The Microsuite is a collection of the Micro projects that I am involved in. To this date they are; Microlog, Microinstall & Microproperties. Microlog is a logging tool for Java ME developers. Microinstall consists of some small classes that makes it easy to distribute your MIDlet(s). The Microproperties project has not yet delivered any code, but the intention is to create a good properties framework for Java ME. The plan is to create the code from scratch, with some inspiration from the properties classes found in Microlog. Please visit the Microsuite website to find out more about the different projects that are part of Microsuite.
Labels:
Microinstall,
Microlog,
Microproperties,
Microsuite
Nov 5, 2008
Blog Post on Mobile & Embedded Community
I am proud and happy to announce that my blog post "Upgrading Voxtr with Microlog" has been featured on the Mobile and Embedded Community.
The Mobile and Embedded Community is a Java ME community for us developers. It consists of forums, blogs, some interesting podcasts etc. There is also a lot of open source projects. I regularly visit the forums and the blogs.
The Mobile and Embedded Community is a Java ME community for us developers. It consists of forums, blogs, some interesting podcasts etc. There is also a lot of open source projects. I regularly visit the forums and the blogs.
Nov 3, 2008
LWUIT Makeover demo
Ever since I heard about LWUIT for the first time, I have been following its progress. The LWUIT toolkit is an alternative to LCDUI. It is inspired by Swing, but is not a port of Swing. If you are looking for a port of Swing, take a look at JSR-209 "Advanced Graphics and User Interface Optional Package for J2ME Platform". I have not heard of any phone that implements JSR-209, but the SavaJE phone, which is not in production. But LWUIT is reality today. Since I consider myself as a fluent writer in Swing-lish, it was easy for me to get started with LWUIT. But I must admit that I have not done any real projects with LWUIT yet, but I have tried it out. It looks rather promising. Today I noticed a new LWUIT demo that was rather impressive.
What do you think about LWUIT?
What do you think about LWUIT?
Nov 1, 2008
Upgrading Voxtr with Microlog
What a sin! I am involved in the Voxtr open source project. The initial code was not made by me, so I found those awful
I would like to take the opportunity to describe how simple it is to use Microlog. First of all you must download Microlog. Next up is to unzip the file that you downloaded. The included
The second step is to setup Microlog. I prefer to use a properties file. The biggest advantage is that you do not need to change any code when you want to change your Microlog settings. Use the supplied file that is called
What good is all the logging if you do not know how to view the log? In this example, the logging is done in two destinations. The
What I have shown here is the setup that I recommend that you start with. The
System.out.println()
statements. But fear no more; The Voxtr has been upgraded with Microlog.I would like to take the opportunity to describe how simple it is to use Microlog. First of all you must download Microlog. Next up is to unzip the file that you downloaded. The included
microlog.jar
must be copied to your project and added to your buildpath. How this is done, depends on your development enviroment.The second step is to setup Microlog. I prefer to use a properties file. The biggest advantage is that you do not need to change any code when you want to change your Microlog settings. Use the supplied file that is called
microlog.properties
. Copy this to the source root of your project or to your resource folder if you have one. To configure Microlog using the properties file you add the following code to your main class, which in most cases is the MIDlet class. The setup code looks like this:Properties properties = new Properties();Microlog is now configured according to the settings in your microlog.properties file. In each class that you like to do some logging, you add the following code:
log.configure(properties);
private final static Logger log = Logger.getLogger();That is it! Insert logging statements where you would normally put
public void someMethod(){
// Do the actual logging
log.debug("MicroLog is working!");
}
System.out.println()
statements.What good is all the logging if you do not know how to view the log? In this example, the logging is done in two destinations. The
ConsoleAppender
outputs to the same place all your System.out.println()
would go. If you run your MIDlet in the emulator, the output is shown in some kind of console. In Eclipse, this is the "Console" view. The second output destination is the recordstore. To view it you use the RecordStoreLogViewer
. Add the RecordStoreLogViewer
MIDlet to the JAD file. When you have executed your main MIDlet, it is just a matter of switching to the RecordStoreLogViewer
MIDlet. Select the "Load" item in the menu and the log is loaded on the screen. The image below shows the RecordStoreLogViewer
with Voxtr log data.What I have shown here is the setup that I recommend that you start with. The
ConsoleAppender
is good when using the emulator, and the RecordStoreAppender
is good when executing on the target device. This is the default settings in the supplied microlog.properties
file. When it is time to do field test, or similar, it is recommended that you start using one of the off-device appenders, for example the MMSAppender
. The MMSAppender
could be used to send MMS and/or e-mails to the addresses of your choice. Other choices are the Amazon S3 appenders which I have blogged about earlier. I will not go into more details about the off-device appenders right now, I will save it for later. Stay tuned!
Labels:
Java ME,
Microlog,
Tips and Tricks,
Voxtr
Oct 30, 2008
New Snapshot Version of Microlog is Available
The Microlog project is as vivid as ever. A lot of things are improving at the moment. It is time for you to try it out.
Important updates:
* CLDC 1.0 compliant, except for the PatternFormatter class. Use the source code version to use Microlog with CLDC 1.0. The binary variant of Microlog is compiled with CLDC 1.1
* MIDP 1.0 compliant.
* Performance improvements.
* Microlog4SPOT code is now merged. It is now possible to use Microlog for Sun SPOT devices.
* The Microlog instrumentation tool is now available. This let you log things like the line number in your code.
Please download and provide us feedback!
Download Microlog snapshot.
Important updates:
* CLDC 1.0 compliant, except for the PatternFormatter class. Use the source code version to use Microlog with CLDC 1.0. The binary variant of Microlog is compiled with CLDC 1.1
* MIDP 1.0 compliant.
* Performance improvements.
* Microlog4SPOT code is now merged. It is now possible to use Microlog for Sun SPOT devices.
* The Microlog instrumentation tool is now available. This let you log things like the line number in your code.
Please download and provide us feedback!
Download Microlog snapshot.
Using Amazon S3 in a Different Way
You might have heard about Amazon S3, which stands for Amazon Simple Storage Service. Most people use it for backup. I will tell you a story about how I found a different way to use Amazon S3.
During the summer I felt a deep urge to implement a JDBCAppender for Microlog, like the JDBCAppender found in Log4j. In situations when the on-device logging is insufficient, this would give the developer a chance to log into a database. When searching the Internet I found less than a handful of JDBC implementations for Java ME with CLDC. Most implementation for Java ME devices was CDC compliant. Another problem was that I was to lazy to setup a database. Last but not least, my knowledge of JDBC was a little bit weak since I had not done any JDBC programming for many years. Soo my initial urge was gone like the wind.
But still I felt that there was a need for off-device logging in Microlog. How about Amazon S3? Could it work? Since Amazon S3 could be accessed with REST and/or SOAP, it should be possible to access it from Java ME. The developer resources for Amazon S3 are rather good, and it came as no suprise to find a J2ME Toolkit for Amazon S3. This was perfect for me since it was open source, and is using the Apache License 2.0. This is the same as we use for Microlog.
I coded two appenders for Amazon S3; the S3FileAppender and the S3BufferAppender. The S3FileAppender logs to file. When the file reaches a certain size and/or you log at a specified level, the file is copied to your S3 account. The S3BufferAppender logs to memory instead of a file. This is useful for applications that do not have access to JSR-75, i.e. file access.
But how do you use the S3 logging capabilities of Microlog? It is dead simple. The code look like this:
As you can see, you need to insert an access key id and a secret access key. These are obtained from the Amazon AWS pages. If you have ever bought something on Amazon, you already have an account. The only thing that you have to do is to active the AWS service. When you do this you could access these auto-generated codes. Copy and paste them into your code. A word of caution. Be aware that if you somehow loose your mobile device or your account details, you have to change your codes at Amazon AWS. Another solution would be that you enter these codes when starting your MIDlet or that you store them encrypted in a file. But do not say I did not warn you!
The rest of the code is simpe. The appender is added to the logger and the log level is set to DEBUG. The S3FileAppender is by default set to send the file to the S3 server when an ERROR or FATAL message is logged, or when the file is to big. But if you like to send the file only when the file is big this is possible as well. It should be noted that this setup could also be done in a properties file. Please take a look at the Microlog documentation for more details on the different setup options that are available.
When you have compiled and transferred your MIDlet to your device, the logs will be saved on your Amazon account. I use the Jungle Disk application to mount a virtual drive. The logging file will be accessible in your Microlog folder. It is as simple as that. The Jungle Disk application is available for $20 for the version that I use. There are nearly a zillion solutions for Amazon S3, and one of those will fit your purposes.
The benefits of using Amazon S3 for Microlog are many;
I would like so say some words about the future of S3 logging in Microlog. There is room for improvements. For example, I think it would be useful to log several users log files. As it is now, the S3 appenders are only for a single user. Of course there are other improvements, some of which I am unaware of. Maybe YOU are the one that could help me improve Microlog? Please use the Microlog forums if you have any suggestions.
During the summer I felt a deep urge to implement a JDBCAppender for Microlog, like the JDBCAppender found in Log4j. In situations when the on-device logging is insufficient, this would give the developer a chance to log into a database. When searching the Internet I found less than a handful of JDBC implementations for Java ME with CLDC. Most implementation for Java ME devices was CDC compliant. Another problem was that I was to lazy to setup a database. Last but not least, my knowledge of JDBC was a little bit weak since I had not done any JDBC programming for many years. Soo my initial urge was gone like the wind.
But still I felt that there was a need for off-device logging in Microlog. How about Amazon S3? Could it work? Since Amazon S3 could be accessed with REST and/or SOAP, it should be possible to access it from Java ME. The developer resources for Amazon S3 are rather good, and it came as no suprise to find a J2ME Toolkit for Amazon S3. This was perfect for me since it was open source, and is using the Apache License 2.0. This is the same as we use for Microlog.
I coded two appenders for Amazon S3; the S3FileAppender and the S3BufferAppender. The S3FileAppender logs to file. When the file reaches a certain size and/or you log at a specified level, the file is copied to your S3 account. The S3BufferAppender logs to memory instead of a file. This is useful for applications that do not have access to JSR-75, i.e. file access.
But how do you use the S3 logging capabilities of Microlog? It is dead simple. The code look like this:
public S3FileLogMidlet() {
S3FileAppender appender = new S3FileAppender();
// You must set the accessKeyID & secretAccessKey in order for this to work.
// For more information, see your Amazon account.
appender.setAccesKeyID("accessKeyID");
appender.setSecretAccessKey("secretAccessKey");
log.addAppender(appender);
log.setLogLevel(Level.DEBUG);
log.info("Setup of log finished");
log.error("This error message shall trigger file => S3.");
}
As you can see, you need to insert an access key id and a secret access key. These are obtained from the Amazon AWS pages. If you have ever bought something on Amazon, you already have an account. The only thing that you have to do is to active the AWS service. When you do this you could access these auto-generated codes. Copy and paste them into your code. A word of caution. Be aware that if you somehow loose your mobile device or your account details, you have to change your codes at Amazon AWS. Another solution would be that you enter these codes when starting your MIDlet or that you store them encrypted in a file. But do not say I did not warn you!
The rest of the code is simpe. The appender is added to the logger and the log level is set to DEBUG. The S3FileAppender is by default set to send the file to the S3 server when an ERROR or FATAL message is logged, or when the file is to big. But if you like to send the file only when the file is big this is possible as well. It should be noted that this setup could also be done in a properties file. Please take a look at the Microlog documentation for more details on the different setup options that are available.
When you have compiled and transferred your MIDlet to your device, the logs will be saved on your Amazon account. I use the Jungle Disk application to mount a virtual drive. The logging file will be accessible in your Microlog folder. It is as simple as that. The Jungle Disk application is available for $20 for the version that I use. There are nearly a zillion solutions for Amazon S3, and one of those will fit your purposes.
The benefits of using Amazon S3 for Microlog are many;
- No need to spend time on setup and maintenance of a database. This will save many $ for you.
- It is cheap to store the logs at Amazon S3. Even if you log huge amount of Microlog data, it will be very cheap. For example; let's say you store 1 GB of Microlog data. That would cost you $0.20 for the transfer and $ 0.15 if you save it on the server for a month. I believe that under normal circumstances you do not store it for that long.
- No need for JDBC knowledge. You only need to learn how to use Microlog.
- Focus on the development.
I would like so say some words about the future of S3 logging in Microlog. There is room for improvements. For example, I think it would be useful to log several users log files. As it is now, the S3 appenders are only for a single user. Of course there are other improvements, some of which I am unaware of. Maybe YOU are the one that could help me improve Microlog? Please use the Microlog forums if you have any suggestions.
Labels:
Java ME,
Microlog,
Tips and Tricks
Install MIDlet on a Motorola C380
Yesterday I had some problems when installing a MIDlet on a Motorola C380. Before doing this I believed that this was something I could do fast and easy. As it turned out, this was not the case. Here is the story.
As in all good cooking programs I had prepared myself. The document "Java ME Developer Guide for Motorola OS" seemed to be the right one. It describe the following ways of downloading a MIDlet to your mobile device;
I used the brute force method for USB connections. Attach the mobile device through USB to your computer, and see if Windows figures out which drivers to install. My Windows Vista installation did not. But I was a little bit surprised when Windows Vista suggested that I should download the Motorola Device Drivers. The link worked and within minutes the device drivers where downloaded.The documentation described a tool called MIDway which could be used for downloading MIDlets to your mobile. This was possible if you could find the "Java App Loader" in the Java menu on your mobile device. It was written that the "Java App Loader" is NOT available on devices that you buy from a standard consumer outlet. You should use the MWay tool found in Motorola MOTODev Studio for Java ME V2 instead. No problem, it was only a "small" download about the size of 112 MB. Estimated download time; 1 h 30 min. This gave me time to be a little bit social with my family. What a bummer :)
I installed the device drivers and Motorola MOTODev Studio. This worked like a charm. I attached my mobile device through USB and now it worked. The device manager showed that a Motorola US modem was installed, as well as some other devices. Now it was time to start MOTODev Studio. Surprise! The MOTODev Studio is Eclipse in disguise. Me like a lot! I found a document about Motorolas MWay Tool v1.0, which was the tool that I was supposed to use. The first step was to find the configuration tool, the second was to activate the "Java App Loader" menu. But wait... the other document stated that this was not available on mobile phone purchased in the consumer market. Appearently it was possible. After restarting the phone the menu was finally available. Connected the phone once more and used the deployment tool to install the MIDlet. Rather easy once you figured it out. But it took quite some time; I started right after the dinner at five and finished about eleven.
I now comes the short version, the version that you could use and save yourself a lot of time.
Prerequisites
Some kind of Windows environment. Windows Vista worked for me.
Preparations
I hope that you could save an hour or two when using this guide. Unfortunately you have to download a couple of megabytes, but hopefully you have a faster Internet connection than I have. If you have any problems, you could still use the Motorolas MWay Tool v1.0 document to figure out how to do it.
As in all good cooking programs I had prepared myself. The document "Java ME Developer Guide for Motorola OS" seemed to be the right one. It describe the following ways of downloading a MIDlet to your mobile device;
- OTA (Over The Air)
- Bluetooth
- IrDA
- USB Cable
I used the brute force method for USB connections. Attach the mobile device through USB to your computer, and see if Windows figures out which drivers to install. My Windows Vista installation did not. But I was a little bit surprised when Windows Vista suggested that I should download the Motorola Device Drivers. The link worked and within minutes the device drivers where downloaded.The documentation described a tool called MIDway which could be used for downloading MIDlets to your mobile. This was possible if you could find the "Java App Loader" in the Java menu on your mobile device. It was written that the "Java App Loader" is NOT available on devices that you buy from a standard consumer outlet. You should use the MWay tool found in Motorola MOTODev Studio for Java ME V2 instead. No problem, it was only a "small" download about the size of 112 MB. Estimated download time; 1 h 30 min. This gave me time to be a little bit social with my family. What a bummer :)
I installed the device drivers and Motorola MOTODev Studio. This worked like a charm. I attached my mobile device through USB and now it worked. The device manager showed that a Motorola US modem was installed, as well as some other devices. Now it was time to start MOTODev Studio. Surprise! The MOTODev Studio is Eclipse in disguise. Me like a lot! I found a document about Motorolas MWay Tool v1.0, which was the tool that I was supposed to use. The first step was to find the configuration tool, the second was to activate the "Java App Loader" menu. But wait... the other document stated that this was not available on mobile phone purchased in the consumer market. Appearently it was possible. After restarting the phone the menu was finally available. Connected the phone once more and used the deployment tool to install the MIDlet. Rather easy once you figured it out. But it took quite some time; I started right after the dinner at five and finished about eleven.
I now comes the short version, the version that you could use and save yourself a lot of time.
Prerequisites
Some kind of Windows environment. Windows Vista worked for me.
Preparations
- Download the Motorola device drivers
- Download the MOTODev Studio.
- Optional; if you have a slow Internet connection you could take a long coffee break, watch a movie or something.
- Install the device drivers
- Install MOTODev Studio.
- Connect your Motorola mobile phone. Wait for Windows to do the installation of the drivers.
- Start MOTODev studio.
- Open the "JavaME" view and select the "Tools" tab.
- Select the "Config tool".
- Refresh the "Config Tool" and you it should now show some information such as IMEI number etc.
- Select the "JAL" option (short for "Java App Loader").
- Disconnect your mobile device and restart it.
- Choose the "Java Settings" menu found in the settings menu. Select the "Java App Loader". You are now prompted to connect your mobile device. The mobile device should confirm that your JAL link is active.
- Select the "Deployment Tool". This is also found under the "Tools" tab.
- Select the JAD file that you want to transfer. The JAR file shall be in the same directory.
- Select the COM port for your Motorola USB modem. This is found Windows device manager.
- Press the "Deploy" icon found in the upper right corner of the "Deployment Tool" view.
- Accept the download on your mobile device. Follow the instructions on the mobile device.
I hope that you could save an hour or two when using this guide. Unfortunately you have to download a couple of megabytes, but hopefully you have a faster Internet connection than I have. If you have any problems, you could still use the Motorolas MWay Tool v1.0 document to figure out how to do it.
Labels:
Java ME,
Tips and Tricks
Oct 24, 2008
Open Source Software Development; Microlog, Microinstall & Voxtr
A couple of years ago I started my first Open Source project; Microlog. This was an attempt to make something similar to Log4j. At that time I was new to Java ME programming. What I wanted was a really simple, but yet powerful logging tool. I started from scratch and within a couple of hours I did have something that I liked. For some reason it just felt right; I wanted to release it as Open Source. Said and done! I also showed it to some of my colleagues and got some feedback. My colleague Darius suggested that I would make the setup of Microlog very simple. Before I knew it, he had contributed with some code for the setup. After that he joined the project. Since I believe in "Release early, release often." I released a couple of small releases rather quickly.
During the years that have gone since then, I have from time to time taken a look at the Microlog project site. The statistics showed that there was a fair amount of downloads. But there was no activity in the forums. Nada, zero, null! :( Since I was not involved in any Java ME development project, there was no natural reason to use Microlog, nor updating the code.
But then there came an e-mail from a developer who wanted to contribute with some code. Wow! Somebody thinks that Microlog has some potential. A couple of days later another person wanted to contribute, and join the project. This was Karsten who now is our Maven specialist in the Microlog team. During the spring and the summer I and the rest of the team has been working very hard to get out the first "real release", i.e. V1.0. We also replaced our old static homepage with an autogenerated site by Maven. During this period we finally got some action in the forums :) Thank you all for the great feedback I have received, this is really motivating me to continue with Microlog.
I have heard many people complain about long URLs that you have to enter to download a MIDlet. Of course you can download the MIDlet to your computer, and then transfer it to your device. Both ways are rather tedious ways of doing the installation of a MIDlet. Therefore I started to think about different ways to distribute MIDlets. My experiments are now available for you to take a look at. Please visit the Microinstall project page site for more information.
I am the co-founder of the Voxtr project. This is a simple voice recorder MIDlet. Since I have a hard time to remember things, it is very practical for me to take "voice notes". No need to find a pen and paper or use that hard-to-use-notepad-application that is bundled on your mobile phone.
That is all for now folks!
During the years that have gone since then, I have from time to time taken a look at the Microlog project site. The statistics showed that there was a fair amount of downloads. But there was no activity in the forums. Nada, zero, null! :( Since I was not involved in any Java ME development project, there was no natural reason to use Microlog, nor updating the code.
But then there came an e-mail from a developer who wanted to contribute with some code. Wow! Somebody thinks that Microlog has some potential. A couple of days later another person wanted to contribute, and join the project. This was Karsten who now is our Maven specialist in the Microlog team. During the spring and the summer I and the rest of the team has been working very hard to get out the first "real release", i.e. V1.0. We also replaced our old static homepage with an autogenerated site by Maven. During this period we finally got some action in the forums :) Thank you all for the great feedback I have received, this is really motivating me to continue with Microlog.
I have heard many people complain about long URLs that you have to enter to download a MIDlet. Of course you can download the MIDlet to your computer, and then transfer it to your device. Both ways are rather tedious ways of doing the installation of a MIDlet. Therefore I started to think about different ways to distribute MIDlets. My experiments are now available for you to take a look at. Please visit the Microinstall project page site for more information.
I am the co-founder of the Voxtr project. This is a simple voice recorder MIDlet. Since I have a hard time to remember things, it is very practical for me to take "voice notes". No need to find a pen and paper or use that hard-to-use-notepad-application that is bundled on your mobile phone.
That is all for now folks!
Labels:
Java ME,
Microinstall,
Microlog,
Open Source,
Voxtr
Oct 23, 2008
My First Blogpost :)
This is my first ever blogpost in the history of cyberspace. My wife has been nagging me for not blogging, since she has been a frequent blogger for nearly 2 years now. But as they say; better late than never.
To motivate me I have decided what to blog about. Something that really interests me, that inspires me to write regularly about. I have found a couple of things that I plan to blog about. These are (in no particular order):
Of course there will be other subjects to write about, but this is at least the things that I feel I have something to write about. I hope that I will have time to write regularly and that somebody will find my blogging of somewhat interesting.
To be continued...
To motivate me I have decided what to blog about. Something that really interests me, that inspires me to write regularly about. I have found a couple of things that I plan to blog about. These are (in no particular order):
- Interesting Open Source Projects, e.g. tools that I use.
- The Open Source projects that I am involved in. News and stuff.
- Experiences from my life as an (Open Source) developer.
Of course there will be other subjects to write about, but this is at least the things that I feel I have something to write about. I hope that I will have time to write regularly and that somebody will find my blogging of somewhat interesting.
To be continued...
Subscribe to:
Posts (Atom)