Comet in a socket: supporting the non-supporters

This is part 3 in WebSocket series. Read part 1 and part 2 here.

In the previous part of the series we have covered all the historical basis of WebSocket protocol and learned how to use it in order to implement a very basic webchat service. Unfortunately, the WebSockets protocol is still only a draft and a novelty, and as such it is not yet consistently supported across all the major browser platforms. Have no fear, though, as there are ways to easily add the necessary support to all the major browsers - though usually not with a pure JavaScript solution.

Before we cover it, though, lets see how bad the situation really is.

Daily dig: interfaces and JDBC

It is funny how fast we sometimes jump to conclusions or try to use the solutions we know without even thinking if they are right for a given problem. Just yesterday I had an opportunity to witness such a thing (and, moreover, fall victim to it myself) when this seemingly innocent question has been asked: "In C++ we split the class code between its declaration (.h) and definition (.cpp). Can/should we do something like this in Java?".

Android: First Encounters (newbie guide)

Yesterday I have finally found some time to start learning native Android development. I must admit that the official Android documentation is very good and the learning curve so far was pretty low. That being said, I am not a total newbie when it comes to mobile development - after all, I've done it in J2ME, WebOS and even on Android (but using PhoneGap, admittedly). Still, a new framework is a new framework and when it comes to learning, Android is definitely user-friendly.

Comet in a socket: implementing web chat in Jetty

This is part 2 in WebSocket series. Read part 1 here. If you are impatient, you can find a very brief WebSocket implementation cheat sheet at the end of this post.

In one of my previous posts, I have briefly described the history of real-time communication techniques used in web pages. As much as it is good to know, however, it will not help you much in implementing a working, modern solution to the problem. So, this time we are going to do just that - implement a simple website chat using HTML5 WebSockets and a Jetty server.

Daily dig: RESTful versioning

Even digging through mud can sometimes lead to a hidden treasure. Now, I don't want to imply that StackOverflow is an equivalent of mud (though the fact is, most of the questions asked there are uninspired, to say the least), nor that this question related to REST APIs versioning is treasure - it isn't. In fact, it was so terse that it might have been overlooked easily.

Luckily, this wasn't the case. This answer, although over 2 years old now, is still an interesting read for those interested in RESTful services. I agree with the author - older API / resource versions should be encoded as part of the URI. However, in most cases, the URIs containing version number should not be permanent and should be phased out after some time, preferably redirecting clients to the current version (unless the resource is intentionally versioned, like for example a Wiki page). Also, there should exist a "canonical" permalink versionless URI for resources, that should always serve the most recent version

Obvious? Perhaps, but as can be seen in various answers posted to that question, the opinion is divided between people preferring to keep version as part of the URI and those advocating to keep it as part of HTTP headers (and one answer stating that you should never, ever provide access to previous versions of your APIs / resources - but let's not fool ourselves, this is not realistic in the real world). Ask an IT guy a yes/no question and you will get three conflicting answers, eh?

Comet in a socket: let's talk real-time

I must admit, writing web applications which provide real-time functionality is a personal favorite of mine. It is still a novel thing among the mostly-static web pages - although the novelty is fading fast with more and more web pages providing real-time or pseudo real-time updates (like Twitter). It is also, to some degree, using (or abusing, as some would say) the HTTP protocol in a way it was not intended to. In short, a challenge! Don't all programmers like a little challenge now and then?

Unfortunately (or rather, fortunately) it is becoming less and less of a challenge every day, with new web technologies entering common use. Although there does not yet exist an agreed-on standard on how such a real-time communication should be done while still only using the HTTP protocol, the WebSockets proposal is gaining traction, with some major browsers already implementing it in their newest versions. And for those that don't - there is always Flash as a fallback.

But let us not get ahead of ourselves. Before we move on to WebSockets, it would be beneficial to quickly cover the other methods used for real-time communication in the past.

Weak and strong references in Java

Today, as I was busy implementing an id-object mapping class, I was forced to revisit the concept of weak and strong references - the topic not entirely new to me, but one where I have not had any practical experience. And surprisingly, one which is completely foreign to quite some Java developers (at least the ones that I have asked). Everyone knows what a strong reference (or just a reference, in short) is - they are the regular bread-and-butter references we all use in our everyday Java programming. What, therefore, are weak references? I will talk about them in a moment, but first - an example.