Remember To Turn On Antialiasing

April 23rd, 2007

If you're doing some graphic work in Java that you want to look pretty (as opposed to most UI stuff where this doesn't make any real difference), you probably want to make sure antialiasing is on for the graphics object. By default Java usually honors the OS settings for antialiasing, particularly for text, but you can get much smoother antialiasing by setting the appropriate rendering hint.

For example, originally the new progress bar I added last week didn't have antialiasing on, but in the tweaks I've done this morning (now live on our internal systems) antialiasing is on and it looks much better. It's also changed to be more dots than lines since the last post too. However, setting the antialias rendering hint for all the components in the editor simply slows everything down (rather dramatically) and doesn't actually improve the appearance anyway. Definitely a setting to be aware of but be cautious in its use.

For the benefit of my memory and those who haven't played with rendering hints much, here's how to enable antialiasing on a Graphics2D object:

g.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);

How In Touch Should I Keep?

April 23rd, 2007

As of next week I'll officially be a product manager instead of an engineer. I'll no longer be spending my days coding and for our core products I won't be allowed to make changes to them. I will however be doing a bunch of prototypes and smaller integrations of our products etc so it's still a hands on role.

Obviously I need to keep my general technical skills really high so that I can quickly whip up prototype integrations and stay on top of new technologies etc. For general technology issues like that I'll probably need to be more on top of things than I am now, and I'll wind up working in a much wider range of languages and with a much wider range of technologies. Definitely interesting stuff ahead. What I'm not sure about though is how in touch I should keep with the Ephox development team and how they are going about developing our products. I clearly need to know what the new features they've added are, but I'm not sure how much of the implementation details I'll need.

There's a couple of factors at play here. Firstly, I need to be focussing on finding out what clients want and be living in the client world more than the technical world so if keeping in touch pulls me away from that it's a problem. At the same time, when you're doing integration work, there's a lot of advantages in knowing some of the implementation details as that knowledge can give you some extra flexibility and power to get what you want done. It also makes it easier to track down problems when things go wrong. I suspect what I need to do is find an efficient way to keep my overview level understanding of the products up to date. Maybe that will happen just from the fact that I'll be in the same office with the engineering team or maybe I'll have to skim commit logs or something. I suspect I will at the very least keep a copy of the source code checked out and reasonable up to date for reference, but hopefully I won't need to actually look at it too often (otherwise we need to improve our docs).