The Mobile Times 2010 conference in Dusseldorf, which took place last Thursday, featured a lot of talks on how to do approach cross platform development. A lot of them suggested web development technics as a way to escape native vendor lock-in, such as Apple's iPhone OS.
There are mainly two approaches:
1. You develop a web site using HTML, JavaScript and CSS zip it and deploy it together with a Player
2. Or you develop a custom website which is served from your servers
The first approach is usually tackled using a framework such as PhoneGap. It event provides an API to include platform specific functionality such as GPS in your application.
The second approach either uses traditional web development technics or targets a specific browser, such as WebKit. One example is jQTouch, a jQuery plugin with cross platform support - unfortunately only WebKit.
The presentations, advocating those two approaches, mentioned mainly two advantages:
1. No need to comply with platform policies (think of Apple's App Store)
2. And you can leverage cheap web coding skills
Those are the facts, I collected during Mobile Times 2010. Unfortunately, the benefits using the web development approaches were not really balanced by any downsides.
I really doubt that the web development approach is the way to go in terms of cross platform mobile app development. I think frameworks like PhoneGap are doing an awesome job, putting an abstraction around the native platform.
Unfortunately you get the least denominator of your platform is capable of and that's a real downside to me. If I put on "average Joe head", I want an app that is using the full potential of my phone. I don't care that it was cheaper to develop a web-based solution and I definitely don't care that the framework I'm using is only offering partial support for my phone features.
Another problem is platform defragmentation! I won't go into it - don't worry - I simply want to point out one downside: In my humble opinion, it is not possible with web development technics to "write once, run anywhere"! You will have to tweak the CSS and work around the abstractions of the framework your are using! It might be cheaper, because we all know that the average web development frickler (amateur craftsman), only charges what he deserves. However, I don't think it gets you anywhere in the long run.
I think we shouldn't approach mobile application development with only the engineering side in mind. Instead we should rather focus on the customer and what he asks from a mobile app. I think the success of the App Store has proven that native apps are the way to go, even if they mean more effort on the development side.
Showing posts with label web development. Show all posts
Showing posts with label web development. Show all posts
March 08, 2010
February 09, 2010
GWT @ JUG-Ka
Tomorrow night there'll be the another event of the Java User Group Karlsruhe. It'll feature a talk on the Google Web Toolkit by Papick Taboada, who is quite an expert on the topic. The second part of the event will be a get-together after the talk, where you can discuss GWT over a beer. My company Synyx GmbH & Co. KG is kindly sponsoring the drinks. The talk will take place at University Karlsruhe in room 101 and start at 7:15pm. The room is located in the basement, which you will find easily, if you follow our duke featured logo.
If you are interested in our lottery, where you can win a JetBrains or ZeroTurnaround license, submit your details through our online form. The winners are going to be announced at the end of the talk and must be present.
Last but not least, check us out on Twitter and subscribe to our Google Calendar or join our Xing Group.
November 30, 2009
Playing with Spring's RestTemplate
A couple of week ago, I saw a talk on Spring 3.0's MVC REST support. It's quite impressive how simple SpringSource made REST development by applying the proven concepts of the core Spring Framework.
One of those great core concepts is Templates. Spring's Data Access Framework is an example, where templates are used extensively. One of the templates is the JDBCTemplate. It provides a set of predefined methods to access a database, without worrying about Connection management or Exception handling. Templates are a nice way to help you the the job done, without constraining flexibility. The book "Building Spring 2 Enterprise Applications", which I reviewed last year, there's a whole chapter on Data Access and the corresponding Templates.
The RestTemplate is the latest child in the family. Arjen Poutsma from SpringSource wrote a blog entry about it and describes it as follows:
In the before mentioned blog post, Arjen shows how to pull pictures from Flickr, using their REST API, and display them in a JFrame. He uses an XML based approach, whereas I'll show you some code, which handles JSON:
You can see it's quite easy to work with a RestTemplate. You simply create an instance, tell that instance what your expected content is going to be and you are good to go. In this case we expect the request and response to be JSON. Spring is using the Jackson JSON Processor, to automagically map POJOs to JSON and all the way back.
The concept of a MessageConverter is really neat. You can set multiple converters and specify to use a certain converter for certain POJOs. You can also handle multiple content types by setting multiple instances of MessageConverter.
In order to make a REST call with the predefined MessageConverter, you simply use the getForObject method. You pass the url to call, the type the response is supposed to be mapped to and the values to be replaced in the url. The type of the response is actually a wrapper class:
It is necessary since the following JSON response, which is represented in the POJO Issue, needs some kind of holder object:
As you can see, it's really easy to work with Spring's new RestTemplate. These couple of lines are enough to retrieve a JSON or XML response from a REST call. With the Template approach, you have the full flexibility to hook almost every method and tweak it to your needs.
One of those great core concepts is Templates. Spring's Data Access Framework is an example, where templates are used extensively. One of the templates is the JDBCTemplate. It provides a set of predefined methods to access a database, without worrying about Connection management or Exception handling. Templates are a nice way to help you the the job done, without constraining flexibility. The book "Building Spring 2 Enterprise Applications", which I reviewed last year, there's a whole chapter on Data Access and the corresponding Templates.
The RestTemplate is the latest child in the family. Arjen Poutsma from SpringSource wrote a blog entry about it and describes it as follows:
The RestTemplate is the central Spring class for client-side HTTP access. Conceptually, it is very similar to the JdbcTemplate, JmsTemplate, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that the RestTemplate is thread-safe once constructed, and that you can use callbacks to customize its operations.
In the before mentioned blog post, Arjen shows how to pull pictures from Flickr, using their REST API, and display them in a JFrame. He uses an XML based approach, whereas I'll show you some code, which handles JSON:
You can see it's quite easy to work with a RestTemplate. You simply create an instance, tell that instance what your expected content is going to be and you are good to go. In this case we expect the request and response to be JSON. Spring is using the Jackson JSON Processor, to automagically map POJOs to JSON and all the way back.
The concept of a MessageConverter is really neat. You can set multiple converters and specify to use a certain converter for certain POJOs. You can also handle multiple content types by setting multiple instances of MessageConverter.
In order to make a REST call with the predefined MessageConverter, you simply use the getForObject method. You pass the url to call, the type the response is supposed to be mapped to and the values to be replaced in the url. The type of the response is actually a wrapper class:
It is necessary since the following JSON response, which is represented in the POJO Issue, needs some kind of holder object:
As you can see, it's really easy to work with Spring's new RestTemplate. These couple of lines are enough to retrieve a JSON or XML response from a REST call. With the Template approach, you have the full flexibility to hook almost every method and tweak it to your needs.
November 06, 2009
RESTful applications in practise @ JUG-Ka
This coming Wednesday Gregor Roth from 1&1, you might know him from his InfoQ article, is going to give a talk on RESTful applications at the Java User Group Karlsruhe.He will show how to implement applications leveraging a RESTful architecture and point out the mismatch between a RESTful and RPC-style approach. Furthermore Gregor will highlight the difference between HTTP PUT and POST and finally demonstrate how to implement none CRUD operations using REST.
I'm really looking forward to this talk. In my spare time I developed the REST interface for an Android game and it's going to be interesting to see what we could have done better and hopefully what we've got right.
As usual, the talk will be held at University Karlsruhe in room 102, which is located in the basement. We'll start at 7:15pm, if the door opens as planned this time.
JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in our monthly lottery, send me an email. The winners will be announced at the end of the talk. In addition to that, Atlassian sponsored a couple of great T-Shirts, which you can pick up at the end of the talk.
If you want to know more about upcoming talks, subscribe to our Google Calendar. You'll also be able to see the planned talks for 2010.
October 26, 2009
Push IRC messages to your iPhone
In my new company one of the main communication channels is IRC. Unfortunately, I'm not able to hang out on IRC all day. That means, I'm not only missing interesting discussions, but I'm also always the last to get to know about interesting developments. To put an end to my offline-misery, I came up with a solution to push IRC messages to my iPhone.
First a couple of things you need to know. You'll need an iPhone app to receive push notifications, more about that later on. Furthermore, you'll need a server, which is able to host a Java-based IRC bot.
The bot is leveraging the famouse PircBot library, which unfortunately is based on inheritance:
I stripped out some of the code, you can find the full version on GitHub.
The usage of PircBot, as you can see above (line 11, 16 and 22), is quite easy. You simply override the methods you want to hook into, and execute your code. That's pretty much all the magic that is to PircBot. In order to limit the notifications pushed to the iPhone, I batch a certain number of messages for a pre-configured time and eventually send them to a NotificationService. I'll come back to the NotificationService in a second, but there's another feature I'd like to point out - silent mode. I don't want to be notified on my iPhone, when I'm actually on IRC myself. So whenver a pre-configured user enters the channel, the Bot will switch to silent mode. As soon as the user leaves the channel, it'll switch back.
As you can see, the NotificationService implementation, simply makes a Http Post request to a service called App Notifications. The request contains a couple of key/value pairs, which are used to configure your iPhone's push notifications.
I'm using Commons HttpClient to makes the Post request, since I have some experience with it. In order to use App Notifications, you'll need to setup an account. After the setup, you'll receive a credential String, which must be passed along with the Post request.
The only part missing is the iPhone app, that you need, in order to receive push notifications. The app is not free, but it's quite reasonable. Actually it's a good deal to pay for the app once and not on a request or monhtly bases. However, keep in mind, that the app can only receive push notifications - nothing else. If you that's what you need, this app is for you.
Putting together all parts of the puzzle, you'll get an IRC bot, which connects to the channel you want to be notified about. The bot batches messages and sends them to a service, which in turn pushes them to your iPhone. On your iPhone you have the notification app, which displays the messages from IRC.
The App Notification service is very reliable and super fast. However, there is one downside to the iPhoen app. You cannot switch off the notification sound without also switching off the vibration feedback. The App Notification developer told me, he'll address this issue in a future update.
I also had to play with the batch size and delay, since there are a lot of messages on the channel, I'm interested in and it got quite irratating getting pounded with notifications constantly.
Overall, I do admit, that this combination is quite adventurous, but it works very well. If you'd like to check it out, grab the code from GitHub and let me know what you think.
First a couple of things you need to know. You'll need an iPhone app to receive push notifications, more about that later on. Furthermore, you'll need a server, which is able to host a Java-based IRC bot.
The bot is leveraging the famouse PircBot library, which unfortunately is based on inheritance:
I stripped out some of the code, you can find the full version on GitHub.
The usage of PircBot, as you can see above (line 11, 16 and 22), is quite easy. You simply override the methods you want to hook into, and execute your code. That's pretty much all the magic that is to PircBot. In order to limit the notifications pushed to the iPhone, I batch a certain number of messages for a pre-configured time and eventually send them to a NotificationService. I'll come back to the NotificationService in a second, but there's another feature I'd like to point out - silent mode. I don't want to be notified on my iPhone, when I'm actually on IRC myself. So whenver a pre-configured user enters the channel, the Bot will switch to silent mode. As soon as the user leaves the channel, it'll switch back.
As you can see, the NotificationService implementation, simply makes a Http Post request to a service called App Notifications. The request contains a couple of key/value pairs, which are used to configure your iPhone's push notifications.
I'm using Commons HttpClient to makes the Post request, since I have some experience with it. In order to use App Notifications, you'll need to setup an account. After the setup, you'll receive a credential String, which must be passed along with the Post request.
The only part missing is the iPhone app, that you need, in order to receive push notifications. The app is not free, but it's quite reasonable. Actually it's a good deal to pay for the app once and not on a request or monhtly bases. However, keep in mind, that the app can only receive push notifications - nothing else. If you that's what you need, this app is for you.
Putting together all parts of the puzzle, you'll get an IRC bot, which connects to the channel you want to be notified about. The bot batches messages and sends them to a service, which in turn pushes them to your iPhone. On your iPhone you have the notification app, which displays the messages from IRC.
The App Notification service is very reliable and super fast. However, there is one downside to the iPhoen app. You cannot switch off the notification sound without also switching off the vibration feedback. The App Notification developer told me, he'll address this issue in a future update.
I also had to play with the batch size and delay, since there are a lot of messages on the channel, I'm interested in and it got quite irratating getting pounded with notifications constantly.
Overall, I do admit, that this combination is quite adventurous, but it works very well. If you'd like to check it out, grab the code from GitHub and let me know what you think.
October 05, 2009
Google Sitebricks
Last week I stumbled upon an interview on InfoQ with a Google developer working on a new web framework called Google Sitebricks. On my research day at Synyx, I had time to produce some sample code.
Google's mission statement goes as follows:
A Sitebrick based web-application is deployed as a good old WAR file in a servlet container. That's the first information not explicitly stated on the website. If you have worked with another web framework before, you probably know the concept of a controller or a REST-based Resource. You can find the same concept in Sitebricks, too:
You can see that the class is pretty simple and it reminds me a lot of Restlet, which I used extensively the past few months. With the At annotation you declare the Uri under which your resource should be available. You can also define variable parts in your Uri, e.g. /guestbook/:id, which is used in my sample to access an entry of the guestbook.
The methods annotated with Get and Post are being called upon a request with the corresponding method. If you take a closer look at the method load(), you can see, that it doesn't return any value. That's where the convention or should I call it magic, of the framework begins:
In your Html file, that you define along with your resource, there are expressions, that access members of your resource class. In the Html snippet above we iterate over a Collection named "entries". It's a member of the Guestbook class and is assigned whenever there's a Get request, which triggers the method load() to be called. The expression items=entries calls the getEntries() method on Guestbook, to return the Collection.
Frankly, this strikes me kinda odd. You call a method to populate a member and then its getter to retrieve the value? Shouldn't the annotated Get method return the value directly? I'm not quite sure what the design goal was here, but the first thing that comes into my mind is concurrency. If your resource class is a Singleton, you could run into quite some trouble.
Take a look at the form in the Html snipped above. It has two input fields, which are properties, mapped by name to the member newEntry. The member must be accessible under the resource declared in the action attribute of the form. This was not mentioned in the Sitebrick docs either. When you submit the form, the getNewEntry() method is called and the input field values are set at the returned instance. After that, the annotated save() method is called with the member newEntry already populated.
Again, the design here is rather unusual. You are working on a member, which in case of a Singleton resource, means there is shared state. Of course, if you define your resources not as Singleton, you don't have any problems. However, it's definitely a pitfall, in my opinion.
Overall, I think Google Sitebricks contains a couple of cool ideas. I like the expression language kind of approach, which makes it easy to work with Html snippets. The possibility to define little components (Bricks) and add them in other sites, is another really cool feature.
The project is still in its early stages and I hope they'll address those odd design decisions, mentioned above. Although it's not standards-based, with Google backing the framework, I could imagine Sitebricks getting some traction.
Google's mission statement goes as follows:
Sitebricks is a simple development layer for web applications built on top of Google Guice. Sitebricks focuses on early error detection, low-footprint code, and fast development. Like Guice, it also balances idiomatic Java with an emphasis on concise code.
A Sitebrick based web-application is deployed as a good old WAR file in a servlet container. That's the first information not explicitly stated on the website. If you have worked with another web framework before, you probably know the concept of a controller or a REST-based Resource. You can find the same concept in Sitebricks, too:
You can see that the class is pretty simple and it reminds me a lot of Restlet, which I used extensively the past few months. With the At annotation you declare the Uri under which your resource should be available. You can also define variable parts in your Uri, e.g. /guestbook/:id, which is used in my sample to access an entry of the guestbook.
The methods annotated with Get and Post are being called upon a request with the corresponding method. If you take a closer look at the method load(), you can see, that it doesn't return any value. That's where the convention or should I call it magic, of the framework begins:
In your Html file, that you define along with your resource, there are expressions, that access members of your resource class. In the Html snippet above we iterate over a Collection named "entries". It's a member of the Guestbook class and is assigned whenever there's a Get request, which triggers the method load() to be called. The expression items=entries calls the getEntries() method on Guestbook, to return the Collection.
Frankly, this strikes me kinda odd. You call a method to populate a member and then its getter to retrieve the value? Shouldn't the annotated Get method return the value directly? I'm not quite sure what the design goal was here, but the first thing that comes into my mind is concurrency. If your resource class is a Singleton, you could run into quite some trouble.
Take a look at the form in the Html snipped above. It has two input fields, which are properties, mapped by name to the member newEntry. The member must be accessible under the resource declared in the action attribute of the form. This was not mentioned in the Sitebrick docs either. When you submit the form, the getNewEntry() method is called and the input field values are set at the returned instance. After that, the annotated save() method is called with the member newEntry already populated.
Again, the design here is rather unusual. You are working on a member, which in case of a Singleton resource, means there is shared state. Of course, if you define your resources not as Singleton, you don't have any problems. However, it's definitely a pitfall, in my opinion.
Overall, I think Google Sitebricks contains a couple of cool ideas. I like the expression language kind of approach, which makes it easy to work with Html snippets. The possibility to define little components (Bricks) and add them in other sites, is another really cool feature.
The project is still in its early stages and I hope they'll address those odd design decisions, mentioned above. Although it's not standards-based, with Google backing the framework, I could imagine Sitebricks getting some traction.
August 31, 2009
Java & Flex @ JUG-Ka
I was amazed how many people showed up at our last session on JavaFX and I would love to see such a crowd at every session. Was it the new technology, that made so many people show up? Was it the fact that it was about client development? Or was it simply because we had a speaker from Sun? I'm really curious to know and I would love to get some feedback, in order to improve the topics of our sessions.
This Wednesday, our new theme on client development continues with a session on Flex & Java. Adobe Flex is a framework for building web and desktop clients. Corneliu Vasile Creanga from Adobe, will give us an overview of the framework and how it can interact with Java. The session starts at 7:15pm, this Wednesday and takes place at University Karlsruhe room 101 in the basement.
There will also be our monthly lottery, where JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.
We have a lot more exciting talks coming up this year. To stay on top of things, sign up for our Google Group or join us on XING.
June 21, 2009
Jazoon 2009
I'll be at Jazoon 2009, which is starting next week on Monday with a Glassfish Day. It's going to be my first time in Zurich this year and I'm really excited, because they have a great line up of speakers. Among others, there's gonna be the father of Java himself Mr. James Gosling. For me it's always something special to listen to a keynote of him.
There's gonna be sessions on a wide range of topics, e.g. "Concurrency and Performance Reloaded" with Kirk Pepperdine, "Development for the iPhone" or "Design Patterns in Dynamic Languages" with Neal Ford, to name only a few of the first conference day.
May 25, 2009
Make it Easy to Contribute
The past couple of weeks, I've been playing a lot with Restlet, a Java based REST framework. I like the it a lot, because it's easy to use and you can get it up and running in no time.
The current version of Restlet is 1.1, but when I compared it to the upcoming version 1.2-M2. it was clear that I would start using that right away. It has built in Google App Engine support and uses an Annotation driven approach, which increases testability and ease of use. This is one of the rare uses cases, where I think Annotations are perfectly suited, but I'm digressing. Overall, it was a natural choice to use the milestone build 1.2 right from the beginning.
After a couple of weeks of coding against 1.2-M2, I started to encounter a couple of weird side effects. After testing the code against the current stable version, it was clear, that it must be a bug in the 1.2 milestone release. So I checked the Restlet site, which nicely describes the process of reporting bugs.
As a decent developer, I followed the link to the issue tracker and saw this:
I was shocked to see this kind of interface! I know I'm a developer and I should love these kind of fine grained and detailed options to query an issues tracker, but that's too much! It's not the first time that I see this interface, Java.net uses it too and I just think it's a PITA to use! Compare it to google's code hosting issue tracker interface:
It's worlds apart in terms of usability and ease of use! And the screenshot above even shows the "advanced" search mode. In most cases, you can find everything with a single search box - google like!
I think, if you want the community to interact and contribute to your project, make it as easy as possible for them. They are trying to help you! We all know the problem of issues reported multiple times or reporters not taking time to correctly file an issue. However, every feedback is valuable and you can always ask for further and more detailed descriptions, if necessary.
Coming back to my bug in Restlet, after I managed to query the issue tracker, I saw that it had already been reported. So I decided to switch back to the current stable version. Unfortunately, I had to jump through a couple of hoops to make it work on the GAE, but that's another story altogether.
The current version of Restlet is 1.1, but when I compared it to the upcoming version 1.2-M2. it was clear that I would start using that right away. It has built in Google App Engine support and uses an Annotation driven approach, which increases testability and ease of use. This is one of the rare uses cases, where I think Annotations are perfectly suited, but I'm digressing. Overall, it was a natural choice to use the milestone build 1.2 right from the beginning.
After a couple of weeks of coding against 1.2-M2, I started to encounter a couple of weird side effects. After testing the code against the current stable version, it was clear, that it must be a bug in the 1.2 milestone release. So I checked the Restlet site, which nicely describes the process of reporting bugs.
Before entering a new report, you should query the current issue database for similar open issues.
As a decent developer, I followed the link to the issue tracker and saw this:
I was shocked to see this kind of interface! I know I'm a developer and I should love these kind of fine grained and detailed options to query an issues tracker, but that's too much! It's not the first time that I see this interface, Java.net uses it too and I just think it's a PITA to use! Compare it to google's code hosting issue tracker interface:
It's worlds apart in terms of usability and ease of use! And the screenshot above even shows the "advanced" search mode. In most cases, you can find everything with a single search box - google like!
I think, if you want the community to interact and contribute to your project, make it as easy as possible for them. They are trying to help you! We all know the problem of issues reported multiple times or reporters not taking time to correctly file an issue. However, every feedback is valuable and you can always ask for further and more detailed descriptions, if necessary.
Coming back to my bug in Restlet, after I managed to query the issue tracker, I saw that it had already been reported. So I decided to switch back to the current stable version. Unfortunately, I had to jump through a couple of hoops to make it work on the GAE, but that's another story altogether.
May 18, 2009
Is JavaFX Really the Future?
A java.net poll, which took votes over the past week, shows that a lot of developers are not quite sure, if JavaFX is the way to go in Java UI space. The "Editor's Daily Blog" tried to blandish the numbers:
The first thing to note is that more than 600 votes were cast. That means that this poll stimulated more community participation than any of the other recent polls. Does this matter? I think so. I think it suggests that, whatever may people think about the future of JavaFX, JavaFX is something that has captured their interest. People are following JavaFX.
To be fair, I voted for "It will endure as a secondary option". I'm not too sure if JavaFX will take off in the future. There was a lot of fuzz about it at last year's Devoxx. I talked to a couple of people back then, but all of them had different opinions. Some of them liked it, other were sceptical. However, the general opinion was "We'll have to wait and see!".
I rarely push out this kind of bash blog posts, but with Sun putting a lot of resources into JavaFX and this significant developer refusal, I think it's worth mentioning it.
August 25, 2008
Preposterous Bugs
As a developer you tend to be very sensitive about how software works and how it's not supposed to work. You know that it's hard to write good software, because you deal with it every day. So if you are using a web site or a program, every now and then you put on your developer's hat and analyze the software from your point of view.
I recently got a new phone, the Nokia E51 and the jolly bug parade already started with the website I tried to order it from. They provide a nice step-by-step order process. The current step is highlighted on top of the site, so you would know how much further until you are done. The steps consist of the usual order workflow, which has been implemented a zillion times on other websites. Unfortunately the people responsible for the website haven't ordered anything on the web before or didn't pay attention. First of all there was no distinction between shipping and billing address, which to me sounds like someone didn't do his homework in requirements engineering. The second thing that I noticed, was the cruel fact, that you cannot go back in single steps. You have to work your way through all the steps again, just to change your zip code, which was added in step 1 of 8. Looking at the website from a software developer's perspective, it was clear to me, that it was just so much easier to implement it this way. They don't have to synchronize state between steps and the workflow is somehow a directed graph.
If you are someone like myself, who pays attention to usability, you know that this is a no-go! Whenever I see something like this I try to be a nice customer and give them feedback.
After I received my phone, the jolly bug parade continued, this time with Nokia. They provide a great isync plug-in to enable syncing your contacts, calendars and todo-list from you phone to the mac. It works really well and I was quite surprised to see some apple magic from Nokia. Unfortunately the magic ended right after syncing, because although all my contacts are on my phone, they are not used by the phone. That means when I received an SMS or phone call of my wife, it just displayed her number instead of her name and picture. After googling for the problem, I found a couple of postings on the Nokia Forums, which suggest to clean up your contact's phone numbers. They recommend not to use blanks or dashes. According to the posting on the forums, the country prefix must use the "+" sign instead of the "00". Although I was suspicious, I removed all the blanks in my wife's contact to make sure it suits the "Nokia-Standard". After all, people on the forums reported that it helps to solve their problem, eventually. In my case it didn't! There was still no name on my display, when my wife called.
After a couple of hours research, I found out, that it works when I added my wife's contact manually or only isynced her contact in isolation. That lead me to the suspicion, that there must be contacts which screw with my phone. To my surprise it was my own contact, in particular my own cell phone number. All contacts worked fine, even with blanks or dashes, except for the contact with my own number. After excluding it from syncing, my Nokia E51 now picks up contacts when someone calls or messages.
Putting on my software developer's hat again, I have to say that this is one of the most ridiculous bugs I have ever encountered. If you stumble across a bug in a software or on a website, you sometimes think of similar bugs, that you produced yourself or that you had to fix. It's like this intuition you develop. With this Nokia E51 bug, it's nothing like that. I'm sure Nokia haven't intended to exclude your own mobile number from the contacts. There must be some weird stuff going on in the phone, that causes this strange behavior. I just cannot come up with a reasonable explanation.
As a consumer, I'm just happy that it works now. As a software developer, I'd still like to know what's the cause the problem.
I recently got a new phone, the Nokia E51 and the jolly bug parade already started with the website I tried to order it from. They provide a nice step-by-step order process. The current step is highlighted on top of the site, so you would know how much further until you are done. The steps consist of the usual order workflow, which has been implemented a zillion times on other websites. Unfortunately the people responsible for the website haven't ordered anything on the web before or didn't pay attention. First of all there was no distinction between shipping and billing address, which to me sounds like someone didn't do his homework in requirements engineering. The second thing that I noticed, was the cruel fact, that you cannot go back in single steps. You have to work your way through all the steps again, just to change your zip code, which was added in step 1 of 8. Looking at the website from a software developer's perspective, it was clear to me, that it was just so much easier to implement it this way. They don't have to synchronize state between steps and the workflow is somehow a directed graph.
If you are someone like myself, who pays attention to usability, you know that this is a no-go! Whenever I see something like this I try to be a nice customer and give them feedback.
After I received my phone, the jolly bug parade continued, this time with Nokia. They provide a great isync plug-in to enable syncing your contacts, calendars and todo-list from you phone to the mac. It works really well and I was quite surprised to see some apple magic from Nokia. Unfortunately the magic ended right after syncing, because although all my contacts are on my phone, they are not used by the phone. That means when I received an SMS or phone call of my wife, it just displayed her number instead of her name and picture. After googling for the problem, I found a couple of postings on the Nokia Forums, which suggest to clean up your contact's phone numbers. They recommend not to use blanks or dashes. According to the posting on the forums, the country prefix must use the "+" sign instead of the "00". Although I was suspicious, I removed all the blanks in my wife's contact to make sure it suits the "Nokia-Standard". After all, people on the forums reported that it helps to solve their problem, eventually. In my case it didn't! There was still no name on my display, when my wife called.
After a couple of hours research, I found out, that it works when I added my wife's contact manually or only isynced her contact in isolation. That lead me to the suspicion, that there must be contacts which screw with my phone. To my surprise it was my own contact, in particular my own cell phone number. All contacts worked fine, even with blanks or dashes, except for the contact with my own number. After excluding it from syncing, my Nokia E51 now picks up contacts when someone calls or messages.
Putting on my software developer's hat again, I have to say that this is one of the most ridiculous bugs I have ever encountered. If you stumble across a bug in a software or on a website, you sometimes think of similar bugs, that you produced yourself or that you had to fix. It's like this intuition you develop. With this Nokia E51 bug, it's nothing like that. I'm sure Nokia haven't intended to exclude your own mobile number from the contacts. There must be some weird stuff going on in the phone, that causes this strange behavior. I just cannot come up with a reasonable explanation.
As a consumer, I'm just happy that it works now. As a software developer, I'd still like to know what's the cause the problem.
July 21, 2008
Configuration Notations
I've been using XML as a configuration notation since I've started doing web development. It's a basic building block when it comes to Java EE. Unfortunately I think it's also one of the most common source of errors, especially because there's no compiler which tells you what's wrong. How many times have you deployed your web app in a Java EE container, only to find out, that you have a typo in your web.xml. One advantage of XML, in my opinion, is readability. If you have a configuration file, XML does a decent job in suggesting what you are actually trying to configure and how it relates to your code. I do admit that it can become very verbose very quickly, but using XML namespaces, like the Springframework, you can keep it under control - at least to a certain extend.
I'm currently working on a project which leverages the Springframework. We are using the container to manage dependencies, Dynamic Modules to leverage OSGi and a lot of other stuff which sometimes makes life easier. Spring's default configuration option is XML. So if you want the Spring container to know about your class you'd write something like the following:
Of course that's not the whole story, there's lot's of namespace configuration and all the other XML stuff in your configuration file. Basically every class you want Spring to know about, needs a complement in your configuration. It quickly gets more and more, e.g. if you add transaction management or logging. In short: your XML configuration virtually outgrows!
I said this before, but here it is again: I like Spring's XML configuration and I believe it's all a question of proper tooling. If you have a tool like IntelliJ IDEA, it's a lot easier to handle your Spring configuration.
There's another configuration notation, which has been around for a while: properties files. They contain simple key value pairs:
In my last project, we used properties files excessively to configure global variables, which are set at startup of the Java EE container for the lifetime of the JVM. Properties files are also the standard way of internationalizing your application. For each language you can provide a file which contains keys that are used throughout your application and values, containing the translated messages. The keys are being substituted at runtime with the appropriate values, depending on the currently chosen language. As with XML, there is no compiler warning or static check, which could tell you that you haven't configured your properties file correctly. It's generally a good idea to add a null check before accessing a property, since it can lead to nasty NPEs if it's undefined. In my opinion readability of properties files can't keep up with XML. Usually your files are sprinkled with comments, which indicate where and how the properties are used. That doesn't really scale and comments are not always the best way of enforcing a contract.
Another problem with properties files is encoding. As soon as they contain none Latin-1 characters, you need to do extra work more work to avoid problems. Usually you shouldn't have those encoding problems with XML. Proper tooling is a real problem when it comes to management of properties files. I haven't found a really good tool, which conducts some kind of check if my code and properties files are in-sync. I have to plug IntelliJ again here. They are doing a somewhat reasonable job of managing your properties.
One of the most exotic configuration notation, at least in my opinion, is JSON. Yes, I know! You are probably raising your eyebrows right now, like I did the first time I read about it. JSON is used as the configuration notation of SpringSource's Application Platform - S2AP. You can among other stuff configure logging using JSON:
As probably most of you, I've used JSON only for web development. I think its most common application is calling server-side code from JavaScript. Using it for configuration is an interesting idea, though. When looking at the example above, I think the readability is quite reasonable. The hierarchical structure, similar to XML, makes it easy to figure out what you are trying to configure. There are frameworks out there, which are converting JSON to Java and vice versa, so there's no need to write a parser yourself. Like with the perviously mentioned notations, catching mistakes before deployment is rather limited, since there is no compilation step involved. As for tooling, every decent IDE supports JavaScript nowadays and most of the time that includes JSON. It shouldn't be a problem, getting some tool support when editing JSON snippets.
Comparing these different configuration notations rather subjectively, there is no clear winner for me. The only real difference is proliferation. Despite its somewhat bad reputation, XML is clearly the most widely used configuration notation, directly followed by properties files. JSON is kind of the "new kid on the block", because I've never seen it being used for configuration, before S2AP.
Besides its wide usage and ubiquity, XML has DTD and namespaces, which I believe can eliminate the two major downsides: verboseness and misconfiguration. The strong tool support, which came with the proliferation, can help to handle spelling errors and management of large numbers of XML files. I think working with XML can be quite painless today, if you have the right tools.
I'm currently working on a project which leverages the Springframework. We are using the container to manage dependencies, Dynamic Modules to leverage OSGi and a lot of other stuff which sometimes makes life easier. Spring's default configuration option is XML. So if you want the Spring container to know about your class you'd write something like the following:
<bean id="person" class="de.linsin.sample.spring.contracts.PersonImpl"/>Of course that's not the whole story, there's lot's of namespace configuration and all the other XML stuff in your configuration file. Basically every class you want Spring to know about, needs a complement in your configuration. It quickly gets more and more, e.g. if you add transaction management or logging. In short: your XML configuration virtually outgrows!
I said this before, but here it is again: I like Spring's XML configuration and I believe it's all a question of proper tooling. If you have a tool like IntelliJ IDEA, it's a lot easier to handle your Spring configuration.
There's another configuration notation, which has been around for a while: properties files. They contain simple key value pairs:
authentication.factory=de.linsin.sample.factory.LDAPAuthFactory
admin.email=dlinsin@gmail.comIn my last project, we used properties files excessively to configure global variables, which are set at startup of the Java EE container for the lifetime of the JVM. Properties files are also the standard way of internationalizing your application. For each language you can provide a file which contains keys that are used throughout your application and values, containing the translated messages. The keys are being substituted at runtime with the appropriate values, depending on the currently chosen language. As with XML, there is no compiler warning or static check, which could tell you that you haven't configured your properties file correctly. It's generally a good idea to add a null check before accessing a property, since it can lead to nasty NPEs if it's undefined. In my opinion readability of properties files can't keep up with XML. Usually your files are sprinkled with comments, which indicate where and how the properties are used. That doesn't really scale and comments are not always the best way of enforcing a contract.
Another problem with properties files is encoding. As soon as they contain none Latin-1 characters, you need to do extra work more work to avoid problems. Usually you shouldn't have those encoding problems with XML. Proper tooling is a real problem when it comes to management of properties files. I haven't found a really good tool, which conducts some kind of check if my code and properties files are in-sync. I have to plug IntelliJ again here. They are doing a somewhat reasonable job of managing your properties.
One of the most exotic configuration notation, at least in my opinion, is JSON. Yes, I know! You are probably raising your eyebrows right now, like I did the first time I read about it. JSON is used as the configuration notation of SpringSource's Application Platform - S2AP. You can among other stuff configure logging using JSON:
"trace": {
"directory": "serviceability/trace",
"defaultLevel": "info",
"specificLevels": {
"com.foo.*" : "verbose",
"com.foo.UnimportantClass" : "info",
"com.bar.ImportantClass" : "verbose"
}
}As probably most of you, I've used JSON only for web development. I think its most common application is calling server-side code from JavaScript. Using it for configuration is an interesting idea, though. When looking at the example above, I think the readability is quite reasonable. The hierarchical structure, similar to XML, makes it easy to figure out what you are trying to configure. There are frameworks out there, which are converting JSON to Java and vice versa, so there's no need to write a parser yourself. Like with the perviously mentioned notations, catching mistakes before deployment is rather limited, since there is no compilation step involved. As for tooling, every decent IDE supports JavaScript nowadays and most of the time that includes JSON. It shouldn't be a problem, getting some tool support when editing JSON snippets.
Comparing these different configuration notations rather subjectively, there is no clear winner for me. The only real difference is proliferation. Despite its somewhat bad reputation, XML is clearly the most widely used configuration notation, directly followed by properties files. JSON is kind of the "new kid on the block", because I've never seen it being used for configuration, before S2AP.
Besides its wide usage and ubiquity, XML has DTD and namespaces, which I believe can eliminate the two major downsides: verboseness and misconfiguration. The strong tool support, which came with the proliferation, can help to handle spelling errors and management of large numbers of XML files. I think working with XML can be quite painless today, if you have the right tools.
February 18, 2008
Quote Of The Week
-- the ultimate unit test is whether or not users want to use your application. All the other tests you write are totally irrelevant until you can get that one to pass.The Ultimate Unit Test Failure
January 24, 2008
Design for Failure
Dealing well with failure ... is one of the characteristics that distinguishes a well-behaved application from one that merely works.says Brian Goetz in Java Concurrency in Practise and I completly agree.
I recently was forced to use a web site of the Singapore government to register for marriage. Well, I have to say that I'm quite happy that they even provide a web site. Germany's government is offline in comparison to Singapore.
Anyways, the process was simple: You provide your personal details, pick a date&time and pay the fee. Sounds simple, right? Well it turns out not to be that simple after all.
After picking the date&time, I was redirected to a 3rd party web site, which is handling the payement. Unfortunately, that site needs the latest JRE installed, for whatever reason, which I didn't have. My only option was to cancel the transaction and switch to another computer, which has the latest JRE installed.
After punching in our personal details again, I wanted to pick the same date&time. Unfortunately the web site said, that the spot was blocked. I immediately thought: did they really cancel the transaction?
I know that there is the possibility that someone picked the exact same date&time that I chose, while I was switching computer, but I think that is very unlikely. The whole web site is really brittle. For instance, it heavily uses JavaScript, which only works in IE and if you submit your personal details, you can't go back to change them, you need to start from scratch.
If you design a consumer application like this and use the term transaction, I think you should really make sure that you handle your transactions properly. I know it's hard, but it's even more important when money is involved. You have to assume that the client will abort the transaction at any step in the process, for various reasons: browser crashes, no credit card at hand or the internet connection dies.
January 22, 2008
Choosing a Web Framework == Choosing a Spouse
Another greate analogy, which I think is rather funny than true:
When buying jam, yes, I want to make a 5 second decision and not have "too many choices." When choosing a spouse, buying a house, or making any kind of long term or expensive commitment like selecting a framework I will be using for the next few years, I don't want less choice, I WANT MORE.
November 26, 2007
Java Applets II
The past couple of weeks I wrote quite a bit about Applets and the Java browser plug-in. I was pretty sure that Sun would come up with something great. At least that was my impression after reading a lot and checking out the new Consumer JRE aka Java SE 6 Update N.
However, after I read an interview on InfoQ with Nicolas Lorain from Sun, my optimism disappeared. It is my impression, that Sun is not interested to bring Applets back to life.
First mistake, in my opinion, is that Firefox 2 won't be supported. Apparently Sun thinks everybody will upgrade to Firefox 3 right away. In the interview Nicholas uses technical details as an excuse.
Second mistake: Sun puts off Safari and Opera support. I do understand that it's not Sun's responsibility to supports those browsers, but in my opinion they should give it a thought. Making it easy to adopt the plug-in is a first step, but in order to bring Applets back to life and improve the Java browser experience it's not enough.
If you wondered why the Consumer JRE was renamed to Java SE 6 Update N here's the reason: The new shiny browser plug-in will be turned off by default! Apperently Sun thinks that every consumer will know, that they have to switch on the new plug-in, after hitting a website and looking at the Java Applet loading screen for minutes, until the JVM finally decided to start up.
However, after I read an interview on InfoQ with Nicolas Lorain from Sun, my optimism disappeared. It is my impression, that Sun is not interested to bring Applets back to life.
First mistake, in my opinion, is that Firefox 2 won't be supported. Apparently Sun thinks everybody will upgrade to Firefox 3 right away. In the interview Nicholas uses technical details as an excuse.
Second mistake: Sun puts off Safari and Opera support. I do understand that it's not Sun's responsibility to supports those browsers, but in my opinion they should give it a thought. Making it easy to adopt the plug-in is a first step, but in order to bring Applets back to life and improve the Java browser experience it's not enough.
If you wondered why the Consumer JRE was renamed to Java SE 6 Update N here's the reason: The new shiny browser plug-in will be turned off by default! Apperently Sun thinks that every consumer will know, that they have to switch on the new plug-in, after hitting a website and looking at the Java Applet loading screen for minutes, until the JVM finally decided to start up.
November 23, 2007
November 21, 2007
October 15, 2007
2 years @ blogger
I'm using blogger for 2 years now and I still like it a lot! I've never regret moving here! I moved here to get rid of patching and hosting my own blog software. Blogger does a reasonable job in doing that for me, so I'm gonna stay here until something else comes along.
September 04, 2007
Follow up on broken Blogger comment feed
A lot of people wrote me on how to fix the broken Blogger comment feed. So here are the steps to use my Yahoo pipe that I created:
I hope this helps to as long as the Blogger feed is still broken.
- go to my Yahoo pipe
- add your broken Blogger comment feed url to the input box, e.g. http://dlinsin.blogspot.com/feeds/comments/default and hit "Run Pipe"
- the result is a pimped version of your broken feed, that you can use instead of the original feed. With a click on "More options" you can get the url of the feed, e.g. http://pipes.yahoo.com/pipes/pipe.run?_id=
PLT8bvBS3BGOfg6BYEsBXw
&_render=rss&feed=
http://dlinsin.blogspot.com/feeds/comments/default
I hope this helps to as long as the Blogger feed is still broken.
