Nito

Developers, working to create abstracions

Everyday software development is composed mostly of non scientific related problems, meaning less time working on complex new algorithms, and more doing simple, action-reaction development, like UI, database queries, reports and so on. Meaning that the bulk of our everyday tasks should involve more effort on how to organize and write the code than how to solve a particular problem, thinking more on abstractions and code interactions ratter than the algorithms themselves.

It is like that lazy developer that delivers a simple functionality, like an UI interaction, but through a highly coupled and dispersed solution, with code being written in places it shouldn’t be. Sure it could be said that the value was delivered, but a big amount of legacy code was created in the process, and that is because the developer is focusing on the easy part of the task, the algorithm, ratter than a proper abstraction to define it.

It is easy to make something work, but making it maintainable, that is another story. We should, as developers, excel at creating abstractions. This is our real job.

Tags: abstraction, developer, responsability, software craftsmanship

Scrum Management: The Brain Dashboard

This post is a follow up to the original at the OnCast blog, regarding our dashboard creation, but before digging into the specifics, I would like to a summarize few goals we had in mind when we (as a team) come up with the current solution we use at our daily scrum lives.

First some background: we are a medium size team, composed of six developers working usually in pairs and doing sprints of 2 to 3 weeks on a project that is already in production, most of our stories are about improving the existing code base while adding some new functionality, and our sprints are usually composed of 20 to 30 stories, demanding quite some space on our dashboard.

A recurrent issue was some small bugs popping up during our client demo, giving them a bad impression about the quality of our code while bringing the team moral down.

Based on these we established some few goals to out new dashboard design:

• More flexibility: writing your name and status on a story/task is not a good idea, since whose working on it can change over time;
• Focus on people: enforce the team members importance on the project;
• A dashboard that would breathe quality: more testing and validation;
• Sense of accomplishment: it should be pretty visible to see when tasks/stories are completed;
• Pleasant to the eye, after all we will be using it everyday.
• Support a good amount of stories/tasks to be done and completed;
• Impose a limit to our WIP (work in progress);

The result is the following design, that according to Eduardo Moreira, resembles the way a brains operates, concentrating the most important things on the core of the dashboard:

More »

Tags: Agile, brain, dashboard, management, scrum, story, tool

Java movie playback: JOGL + Fobs4JMF

Recently I had to integrate video playback on my job’s Java OpenGL engine, which uses JOGL.

Java has a support to media playback through it’s Java Media Framework, which unfortunately, on it’s current version (2.1.1e) does not support many formats for video playback.

So I quickly looked for alternatives, including IBM Toolkit for mpeg4, that hadn’t a sufficient production performance I was looking for, and didn’t offer an easy option for frame grabbing or plugin extensions as JMF does.

Next was Fobs4JMF, which is JMF + ffmpeg. This solution was much more interesting, since it offers a wide variety of codecs (ogg, mp3, m4a, divx, xvid, h264, mov, etc) and is based on the solid ffmpeg solution to decode audio and video.

My implementation, uses the plug-in capabilities of JMF to extend a custom renderer that does a pixel type conversion and rendering to a texture:

More »

Tags: fast, Fobs4JMF, how to, Java, JMF, JOGL, OpenGL, performance, plugin, RGB, tutorial, VideoRenderer