Saturday, January 21, 2012

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.

Tuesday, January 17, 2012

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?".

Sunday, January 15, 2012

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.

Friday, January 13, 2012

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.

Thursday, January 12, 2012

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?

Wednesday, January 11, 2012

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.

Thursday, January 5, 2012

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.

Wednesday, January 4, 2012

Hello, World

New Year's resolutions are evil. We decide to do lots of things, knowing well that we are not going to keep doing them after the initial excitement is gone. And yet, come next New Year's Eve, we do the same. What is the point?

It just so happened that one of my resolutions this year was "go and learn what this social media buzz is all about". Lets admit it: I have never really participated in any blogging before (be it as a commenter or an author), I still fail to understand what Twitter is about and I avoid Facebook like a plague (especially after every new article describing its privacy problems). According to this, I may as well not exist, right? Thing is, I wanted to start an IT blog for quite some time, but there was always an excuse not to - it is too time consuming, I have better things to do, I am not experienced enough, etc etc. What finally motivated me to start one was, funnily enough, a post by an experienced Java developer whose blog I read on a regular basis: he just discovered a thing about computers which is so basic that it is being taught during the first year of University studies. So, if he can admit not knowing some basic things (although I can guess he is not aware that they are basic) and yet publish a successful IT blog, why shouldn't I give it a shot? After all, worst thing that could happen if I turn out to be ignorant about something is that I learn something new.

Since this is supposed to be a programming blog, the post would not be complete without some code (that's an excuse, in fact I just want to test if the fancy syntax highlighting script is working). Behold, then! This snipped sums up what I am planning to do here (for the purists:  yes, I know this will not compile):

public abstract class Blogging {
    public static void main(String[] args) {
        new Blogging().blog();

    public abstract void blog();

To cut to the chase, this is going to be my attempt at running an IT blog, describing things as I learn them, as well as some I know for some time that may be worth sharing. Since lately I am mostly into mobile development, this will most probably be the thing that will be covered in the near future. However, I will try to keep the content more varied; in fact, the next post most probably won't be related to mobile apps at all (at least not directly).

So, any bets on how long is this New Year's resolution going to last?