Facebook's profile image bug
Monday, June 22, 2009
Software bugs are part of our daily lives. This is a small item, but it's a bit annoying: Facebook's resizing of GIF profile pictures is not working, or at least it didn't work for my profile picture. My profile looks like:
The image should be cropped so that it doesn't overlap with the rest of the profile. It seems to work with other image formats. Maybe it's just a GIF issue, or maybe it's just my He-Man profile picture, as other GIFs seem to work all right.
I wonder how long it will take for this to get fixed...
UPDATE: looking further into the issue, the problem is with the CSS (the image doesn't go behind the other profile elements). The image "cropping" works in the public profile, but it uses a different style.
Open source projects: one-to-one marketing
Thursday, June 18, 2009
Open source projects are great for many reasons. I like them because you get almost instantaneous feedback on legitimate problems. And I also like them because they provide great one-to-one marketing opportunities.
I just finished writing a full chapter on Restlet (Restlet is one of the few RESTful Java frameworks available today). While implementing sample code for Chapter 6, I found the latest version, 2.0, lacking support for the HTTP Accept header (version 1.1 is the official released version; 2.0, is still under development). Because Restlet is open source, I downloaded the code and found what the problem was: version 2.0 doesn't have that functionality implemented yet.
I had 2 options: first, I could have chosen not to write about Restlet 2.0; or I could have chosen to contact the project's lead developer to find out what was going on with automated content negotiation. I opted for the latter option. (In theory, I had a third option, by modifying the code to fix the problem; however, I wasn't willing to do that.)
I sent the tech lead of the project a message and got a reply within a day. What's more, I now know when the feature will be released to the public, as I got a message yesterday saying that the code is already in the repository and it will become part of the next release. Once the update is available, I will be able to rewrite the portion of the chapter that needs rewriting (if at all).
I'm not a paying customer, but I'm a satisfied customer. This is a case of making a good product better and the spread of information about it more accurate.
I have found problems with commercial products and tried to get the issues resolved, though not in the same capacity I have here: individual to individual. In past cases, I was asking on behalf of a corporation, which was a paying customer. The incentive to fix the problems, and quickly, were greater--money tends to have that effect.
Open source project are like that, though. I mean that all the cards are on the table; there is no exchange of money; but there's always the potential to spread knowledge, and, of course, to make money by creating value out of free information.
Is Spain the best team of the world?
Sunday, June 14, 2009
It looks like it. If Spain wins this year's Confederation Cup, I give them a better than 50% chance of winning the World Cup next year. They have incredible players: Xavi, Torres, Villa, Iniesta, Casillas, etc.
Facebook's personalized web address
Saturday, June 13, 2009
Yes, Facebook's vanity URLs are now available for the taking. You have to be quick, because they are going fast. I just got mine, by chance.
What's the point of having a unique Facebook web address? We don't know yet--at least I don't know. It's vanity thing, I guess. You can ask the same question about vanity plates: what's the point? No point, really.
I usually like to claim my personalized stake everywhere; therefore, I exists as Jose Sandoval anywhere you look: domain name, gmail, facebook, twitter--though, no MySpace; I don't like MySpace--and anything else popular. What's more, if you are looking for me (Jose Sandoval) on the web, chances are that the top result will be me. Except for images: none of the pictures are me.
I like the way Facebook's personalized address works. It works similar to Gmails email addresses. I mean that
facebook.com/josesandoval is the same as
facebook.com/jose.sandoval, or any combination of delimiters in the username. Gmail works the same way: jose.sandoval@gmail.com is the same as josesandoval@gmail.com.
It's a smart move, obviously, as we don't come with unique names, and there will likely be many more people with the same name as ours. In a social networking site there shouldn't be any difference between jose.sandoval and josesandoval: it would get too confusing.
I've been told that there are many Jose Sandovals in Facebook. To all of them, I say, you were too late.
Restlet version 1.1 and 2.0
Monday, June 08, 2009
For Chapter 6 I finally decided to cover Restlet versions 1.1 and 2.0. The chapter is longer, but it's fairly comprehensive because of it. My thinking is that if you buy the book because you want to migrate an existing version 1.1 web service to the new and improved version 2.0, then you'll be covered, for you'll know where the differences between each version are. On the other hand, if you buy the book to start developing web services using either 1.1 or 2.0, then you'll also be covered because I go through everything you need to know to create a full RESTful web service from scratch.
Note that this book is not only about Restlet. This book is about RESTful Java Web Services. I cover the most popular RESTful Java frameworks today. For example, in Chapter 5, I cover Jersey, the JAX-RS implementation. So if you decide that Restlet doesn't do everything you need, you can play around with the code and compare between them. The advantage of my approach for this book is that I implement the same requirements for multiple frameworks: the code does exactly the same, but using different REST architectures. Chapter 1, of course, covers the theory of REST, but this is a developer's title full of examples and working code.
In general, the architecture of a web service doesn't change regardless of the framework you use; however, there are a few subtleties that could give you some grief if you don't know where to look. I've tried to cover all those subtleties in my book. What's more, because of how I've broken down the implementation code, you will be able to compare between RESTful frameworks and then be able to decide which approach works best in your case.
I'm a great believer of just enough documentation to be productive quickly. For each chapter, where required, I include architectural diagrams before any code is written. This is the architecture for Chapter 6 (and for all frameworks, really, as I just swap the web layer with the desired RESTful framework and I'm done):
Yes, for each framework (Jersey, Reslet 1.1 and 2.0, RESTEasy), I implement the same web service that I defined in Chapter 4. And, for the same price of the book, all the source code is included in the book and will be available for download. Shameful plug; and, yes, I'm wearing that kind of sweater. Take your pick:
I think this entry (or part of it) will become the introduction to the book.
Equal time for players, Part One
Tuesday, May 26, 2009
I'm coaching my son's U-9 (under 9) soccer team. We have 11 players, and I need to have 7 players on the field at all times: we have a goalie and 6 in-field players.
In the division Gabriel is playing, we are not looking for position specialization yet. The main goal of the program is to get all the players interested in soccer and to help them learn a bit about the game. Therefore, everyone playing equal amounts of time is advisable and preferred. (The club does have a rep league that kids can try out for, though; at that level, I think they have them playing specific positions.)
Having to spread equal time among 11 players is tricky. It's a combinatorial problem that is not hard, but it's not trivial if you don't think about it first. The issue is that I have a large number of combinations: 7 players in the field out of 11--that's a lot of combinations.
To get all the players playing all positions, I have a 1-3-3 lineup (a goalie, 3 defenders, 3 forwards). This means that I now have 2 sub-problems: 3 out of 5 players for the defenders, and 3 out of 5 players for the forwards (the goalie is not a problem because one he's is in that position, I can't sub him for the rest of the half).
In the first 2 games, I thought I wing it and do subs every 5 minutes by rotating the players around. It worked all right, but I had to do too many calculations in my head figuring out who had been on the field the longest and who hadn't. This, of course, was error prone and I think I got a couple of players playing too long, because they asked to be substituted.
This is the kind of problem I like to solve, and the kind of problems, I guess, I paid so much money to learn how to solve. I sat down for 5 minutes and I have a solution that equally divides playing time among the kids. I should say, more or less equally, as some players will always play a bit more because of the rotations. Nevertheless, my head calculation time has now shrunk to 0, because I have everything automated.
Actually, I have the algorithm worked out. I will code it over the next couple of days and post it here. Check back for my next entry
Equal time for players, Part Two.
Java JTextField Field Validator
Thursday, May 07, 2009
There are different ways to validate form fields in Java Swing applications, but the one I found the easiest to work with is extending
javax.swing.text.PlainDocument.
If you use this method, field validation is accomplished in 2 easy steps.
Step 1Create a validator class, as follows:
public class OnlyNumberValidator extends javax.swing.text.PlainDocument {
@Override
public void insertString(int offs, String str,
javax.swing.text.AttributeSet a)
throws javax.swing.text.BadLocationException {
StringBuffer buf = new StringBuffer(str);
int size = buf.length();
char c;
for (int i = 0; i < size; i++) {
c = buf.charAt(i);
if (!Character.isDigit(c)) {
buf.deleteCharAt(i);
}
}
super.insertString(offs, buf.toString(), a);
}
}
The idea here is that every key stroke is accounted for. If the key stroke is a digit, we add it to the buffer and update the view; if it's not, we remove it from the buffer and update the view. The result is a field that doesn't allow unwanted characters.
Step 2Set a
Document object to the field that needs validation, as follows:
// Assume you have the following JTextField object
javax.swing.JTextField jTextFieldOnlyNumber = new JTextField();
// We now set the validation
jTextFieldOnlyNumber.setDocument(new OnlyNumberValidator());
Simple as that. Now our
jTextFieldOnlyNumber object only accepts numbers.
You can create more sophisticated validator classes by adding error checking and by limiting the type and number of characters per field. But the idea is the same: extend
javax.swing.text.PlainDocument and override
insertString().