Forcing SDL to Use a Certain Window Size

4. December, 2011

SDL doesn’t play well with a multi-monitor setup: Either the game window is split over the two displays or one display is set to a different height than the other (making part of the surface unreachable with the mouse) or your desktop is messed up when you exit the full screen mode.

I’ve written a patch that allows you to force SDL to use a certain window size/resolution by setting the environment variable SDL_VIDEO_SIZE to “widthxheight” before starting the game: https://gist.github.com/1429985

Example (bash):

export SDL_VIDEO_SIZE=1024×768

Works best when running the game in a window.


Debugging v2.0 With Chronon

1. December, 2011

“… Okay, let’s just set a breakpoint there … run again … continue continue continue next next next *argh* run again … continue continue continue next next … Why is it still null?? Who changes this field? Oh, damn … breakpoint … run again … where is that coming from? … oh no …”

Sound familiar? How often do you rerun your code just because you can’t step backwards in time? How often did you ask yourself “who is calling this method?” Or “where did this value come from?”

Meet Chronon. In a nutshell, Chronon runs your code, saves all state changes (method calls, variable assignments) somewhere and allows you to browse the result.

So with this tool, the text above would have been: “… Okay, it’s null here. Where does that value come from? *click* Oh, ok. Who called this method? *click* Oh, I see.”

This makes you find the source of an error much more quickly. Other questions that Chronon can answer:

  • Find all instances of a class that were created. A special window lists all exceptions that were thrown.
  • Step backwards (just like stepping forward)
  • Go to the code that printed a certain output on the Console (just click on the output in the Console window!)
  • Show me all the values of some variable (Post Execution Logging)

The tool is surprisingly fast. You’d expect something like that to hog your computer but collecting the data is pretty quick (just a small increase in the time it takes to execute the code; I didn’t time it).

It does take a mental leap, though. Stop thinking like you were executing the code. It’s more a specialized database browser where the data is all the states of your application.

Things that I don’t like:

  1. Opening a recording takes a few moments (<< 1 minute) while it “decompresses” the recording. I’m not sure what happens here. It seems stupid to compress the latest recording because chances are that you probably want to use it soon. But I guess this stage creates a couple of indexes so the UI can quickly navigate the data, so it’s just an unhappy label.
  2. The plug-in messes with my eclipse.ini! Bad plug-in, down! I understand that Chronon needs lots of RAM. And I think it does take your total memory into account (it allocated 2.5GB of my 8GB). Still, it should ask before doing something like that. And it absolutely should not do it again, after I reset the values to something sane. GCing 2.5GB of RAM does take a long time!

Logging From JavaScript

24. November, 2011

Logging is a recurring issue in JavaScript. There are a  couple of frameworks which support you. I’ve picked out two:

Some pros and cons:

log4javascript is very powerful. It contains lots of options, it has timers, several appenders (in page or using a popup window), the console supports tons of filters. If you know log4j, you’ll find almost everything replicated. If you need fewer options, there is even a lite version.

Despite the many options, log4javascript is still simple to set up and use (so it’s not like log4j in every respect). The default setup needs 3 lines of code (not counting the script element to load the framework).

There are two minor points: The console is pretty big and the in-page version can’t be moved.

Blackbird is a really small logging framework. No frills, just the basics. So no exception logging, for example. A profiling option is the most complex feature. In the world of the logging frameworks, it’s the iPhone: Nice look and only the useful features. The console is always in page, it sits in one of the four browser corners, it can be hidden and shown with F2.

My main complaint about Blackbird is that you can’t use the mouse to move the console. Also disabling the framework needs several lines of code. A single variable would have been more comfortable.

 


Peace Between Java and SQL

23. November, 2011

There are various attempts to get Java and SQL to behave with each other. We have JDBC, OR mappers like Hibernate and EclipseLink, language support like in Groovy. All of those have advantages and drawbacks.

JDBC is powerful but low-level. The API is not really friendly. You need to write a lot of boiler plate code for even simple tasks.

Languages like Groovy wrap JDBC to make simple tasks simple. The code becomes much more readable but changes in the database schema become runtime errors.

OR mappers try to turn a relational database into a OO database. It works better than you’d expect but it also causes odd problems and leaks into design of your code: You must no’t use the ID field in equals, hiding the session in a thread-local variable can cause exceptions when you use lazy loading, failing to understand the requirements of the OR mapper causes spurious bugs. At least the OR mappers will complain when the schema changes.

Enter jOOQ. It’s like a OO wrapper for JDBC:

  • You get all the power of JDBC if you need it
  • The readability of a fluent interface
  • The database schema is part of the code (so you get compile time errors if it changes)
  • You can iterate over results as if they were a plain Java collection

Related:


David Eaves Keynote at DjangoCon

17. November, 2011

David Eaves gave a great speech at the DjangoCon: The Science of Community Management: DjangoCon Keynote

It raises many important points that you should be aware of when you are or are planning to get involved with a OSS project. All those have communities and if you don’t keep an eye on staying the lone rider committer, you’ll eventually get tangled up in the social net – the community.

This can be a painful experience, especially when you’re a coder. We, as a species, are wary of human interaction and social forces when we maybe should be aware instead. One symptom is that people start to bother you with stupid questions. The natural reaction is to troll. This works (people will leave you along) but it also means spending from your reputation budget.

Realizing that “stupid question == someone cares about my work” can turn this into a win-win situation.

Go see the talk.


Why You Shouldn’t Deploy Overnight

8. November, 2011

If you’re with a big company and want to do it “right”, chances are that you’re only allowed to deploy during the night, on weekends and never, never, never in December (or any other date were mission critical systems must not fail).

Looking for some reasons why this is wrong? Go here: Why are you still deploying overnight?

In a nutshell: You’re deploying overnight because your processes are brittle, the product is riddled with bugs and you have no fall-back strategy.

Overnight deployment is nothing but a red flag saying that you’re not doing it “right”.


Raphaël – Impressive Vector Graphics Framework for JavaScript

2. November, 2011

If you need a framework for vector graphics, try Raphaël.

MIT License, impressive demos, readable source code.


Excellent Presentation How To Treat New Committers

31. October, 2011

By Michael Meeks: Interacting with new Developers …

Four pages of wisdom.

 

 


ZK

27. October, 2011

I’ve been developing web applications for the past few years. Recently, we evaluated many of the web frameworks out there to select one for the next major release of our product.

We looked at Wicket, GWT, Vaadin, ZK, Roo and a couple of others.

Wicket was quickly dropped from the list. It’s a nice framework but it lacks one important feature: A library of reusable, cross browser components. Yeah, there are a couple but they are all very basic and building complex UIs with Wicket is done in HTML and that’s just painful.

Roo is too slow and immature and suffers from the same problems as Wicket. Maintaining cross-browser compatibility for a complex web application is something that a small team of developers can’t do anymore today.

GWT was dropped because Vaadin is based on it.

That left Vaadin and ZK.

Vaadin looks good, it’s free and based on GWT which is backed by Google. The main issue with Vaadin is that the technology is … unapproachable. There is a decent set of components but tweaking them is a pain. Plus the Java -> JavaScript compilation takes a lot of time. It’s better than most other frameworks but doesn’t compare to ZK.

Why?

ZK has a big set of well designed components with a huge documentation how to tweak them. The docs explain in detail how the components are built from HTML elements, which CSS styles are used and how you can override them. There is even a visual CSS editor that helps doing this.

When working with ZK, you often run into situations where something doesn’t work but so far, I’ve found a good solution within a short time. This might also be possible with Vaadin but it didn’t happen for me.

There are a lot of powerful layouts to arrange your UIs. You can cleanly mix ZUL (the UI descriptions) with Java code to get the best from both worlds: A clean UI description and compact code to attach listeners, publish events and connect components.

Also, ZK hides the request cycle. This is one of the biggest source of problems with developers. Yeah, the request/response cycle makes it easier to write web browsers and server frameworks but it’s a major pain for application developers. With ZK, you’re writing code that looks like a desktop application. It’s a bit like GWT in this respect but GWT feels … “proprietary”. In ZK, a lot of the API is public. In GWT, a lot of the API is hidden away in final static factory methods buried in calls between 50 classes.

You can use JavaScript but the JavaScript isn’t hidden in pseudo-native functions. That ZK5 is based on jQuery is an additional bonus if you really need to get your hands dirty.

The demo page contains lots of useful examples (instead of simply listing the available components like many other frameworks). There is a sandbox where you can modify small ZK projects online.

ZK does have its share of problems, too. Testing is a weak point. Selenium probably works well enough for mouse-driven apps but if you have components which can be controlled by keyboard alone, Selenium doesn’t cut.

The documentation on the web site could be better; for beginners, it’s especially confusing that the documentation for ZK3 and ZK5 is hard to tell apart.

But all in all, I’ve been faster to solve any problem I’ve had so far with ZK than with any other web framework.

Well done.


Using Maven to Patch Third Party Code

26. October, 2011

If you have the source for the dependency, patching the code is simple: Just create a small Maven project that compiles the source with your changes. Since your changes are probably small, you need only a few tests: What’s the point to test the code that you didn’t touch? Also the build will be simple (just compile the sources for your need, no fancy resource processing/filtering).

But what if you don’t have the sources? Jakub Holý has a solution: Hacking A Maven Dependency with Javassist to Fix It