Monthly Archives: January 2012

My personal top 5 of Videogame Music

This top ten list has the following rules:

  1. Each game music has to be created on a console using the internal sound chip – recorded music via high-quality DACs, as modern game consoles have, don’t count. The limit I’ve set is to the SNES/Genesis generation.
  2. Only original music – no modern remixes allowed.
  3. PCM samples are allowed.
  4. The game must have good music throughout the whole game
  5. I list only one track per game, except for the winner
  6. You will most likely disagree with my choices, that’s why this is my personal top 5.

Rank 5: Secret of Mana (SNES)

This game has pretty ok music, but a highlight was the “Fear of the Heavens” tune.

Rank 4: Mega Man (Gameboy)

I am always amazed how great music the people have written for the Gameboy. Mega Man features very cool music, and it’s really a pleasure.

Rank 3: Starfox (SNES)

I especially love the orchestral hits and guitars in this tune.

Rank 2: Golden Axe – Wilderness (Sega Mega Drive/Genesis Version)

The harsh FM sounds really rock and fit perfectly to the rough gameplay, even if they might be too bright for weak ears. The other tracks are also very good, but the track from the first stage is the best – it really has blown away my mind the first time I’ve played it.

 

Rank 1: Phantasy Star IV (Genesis)

»As soon as I turned on the game, and this awesome music with this awesome song came up, I knew that it was an awesome game«

And I fully agree. The whole game has brilliant music, there are almost no repeating tracks. The music really aids the gameplay, or vice versa – you decide.

 

ExtZabbix: Anatomy of a Group Selector

In case you’re wondering: ExtZabbix is the project name for the ExtJS-based Zabbix frontend, at least for now.

I’ve been working quite hard on a good method to assign groups to templates and hosts. I wasn’t satisfied with the way the Zabbix frontend currently does it, for several reasons:

  • The group selector takes lots of space
  • It becomes unhandy with lots of groups
  • No chance of adding groups which were added by somebody else (requires page reload to update the group list)

The Zabbix Group Picker, as of Version 1.9.8

While the picker works pretty well on most installations, the widget size is simply too huge for me. It took me quite some time to test with some alternative implementations. My requirements were these:

  • Slim widget footprint – don’t take up much space
  • Hide groups which are already added
  • Allow selection for removing multiple groups at once
  • Have pagination for a large number of groups
  • Add new groups on the fly [not implemented yet]
  • Allow searching by the group name [not implemented yet]

The ExtZabbix Group Picker

The result is a very lightweight group widget, which can be re-used for everything which uses a host group. The embedded grid which appears after clicking the “Add group…” button (“Assign group” probably would be a better naming) already has pagination support and only includes the groups which haven’t been added so far.

One drawback is that each time the button is clicked, the grid reloads the groups from the server. I’m not sure if I should change this; it ensures that the group list is always up-to-date, even if somebody else removed a group in the meanwhile. Of course, when you have added a group to a template and then somebody removes a group prior saving the template, you’ll end up with an error.

The embedded grid for selecting groups

What’s missing for now is a search field and the ability to create groups directly. While the search field isn’t a big problem, I’m still thinking about how to add groups the “best” way. Basically I have two options:

  • Do it like the current Zabbix frontend and have a simple text box to enter a new group name
  • Open the group editor (or the “Add Group” form) and let the user configure a group with all options

While the first option should be obvious, it has one drawback: If somebody decides to create a new group, chances are good that he also wish to add hosts or other templates to that new group, which would mean: Add the group, navigate to the newly created group and add the hosts/templates to that group. That’s an additional navigational step I’d really like to avoid.

This might be a bit of over-engineering for groups, but as I also developed the host picker as a “showcase” and also about best practises, there are other areas of interest where it isn’t over-engineering anymore – namely items and triggers. I find myself navigating back- and forwards between items and triggers all the time; the navigational overhead is really huge. That’s what I want to avoid from the beginning, making the frontend as easy and intuitive as possible.

Last but not least, I’m also thinking of allowing the user to add multiple groups at once. Right now, when you click any group in the drop-down, it gets immediately added to the group list. By enabling multiple selections, an additional button would be required to add the selected groups to the list, which is quite an overhead for users (2 clicks instead of one), but I really can’t judge. If you have feedback regarding this one, I’d be grateful to hear it!

Developing a Zabbix ExtJS frontend: Part Two

After quite lots of work, I’ve now a basic editing workflow done. As I’m using RESTful methods (due to the lack of a JSON-RPC on ExtJS), I’ve written a proxy which eats RESTful methods on the ExtJS side and proxies that to JSON-RPC for Zabbix.

Honestly, this doesn’t sound pretty amazing, but was necessary to work around one limitation of the Zabbix API: Pagination. This is an emulated pagination, which processes a big result set coming from the Zabbix API, counts the records and then applies a simple array_chunk() on the result. That way, the amount of data transmitted to the client is kept at a minimum.

Regarding the amount of data transmitted: I don’t filter individual fields of each record, even if much space is wasted. This is for two reasons:

  • Performance. Even if I could remove 50% of the fields transmitted, the CPU time (and of course, development manpower) wasted would probably be more than simply transmitting the data to the client. Most Zabbix users are on corporate networks, and even people who are using Zabbix remotely often have DSL connections. Sorry for all GPRS users, but a Zabbix Sencha Touch Frontend is not even planned.
  • Object Model. As the ExtJS frontend is using models, I never know when I need which data. So it’s better to transmit all properties, which saves headaches.

That brings us to a new topic:

How to handle relations for reading and writing objects

When writing a PHP frontend, things are pretty easy: You can write very specific SQL queries, and if you are missing data, you can simply load it prior displaying the page.

When implementing remote frontends, things are a bit worse: Think of each SQL query as a request to the server. On a LAN connection, things aren’t that bad: On my development environment, queries take 20-100ms to complete, so users even won’t notice that something is being loaded. Things are different on remote connections; with requests taking an unpredictable amount of time, one wants to reduce requests to the server to an absolute minimum.

I’ll make an example using templates: When I load a template, I simply request the linked templates, macros etc when loading the template. No problem here.

But the user will eventually come to a point where he needs to add additional templates or macros, which aren’t transmitted. I basically have two options here:

Keep a cache of templates on the client.

I’ve used that in the first place on PartKeepr, but with mediocre success. The advantage was that data was immediately available. The biggest disadvantage was when somebody else added something; that required the ExtJS store to load all entities in a timed interval. And often it was confusing because there was no indication when a reload appears.

This method could probably be improved by creating a checksum and only asking the server if the checksum was changed, so the client would know to reload the data. However, I don’t feel too comfortable with that approach, and lately I’m rewriting things on PartKeepr to avoid that.

Load templates on demand.

This could happen using a specific kind of drop down or even grids, complete with filtering and pagination. While this might create quite some requests on-demand, it works better than caching, because the current data is available and not a cached copy of it.

Conclusion

Data handling in the world of AJAX applications is not easy, especially if you write a full-blown AJAX frontend where you have no page reloading at all. You have to decide carefully which data with which relations you really need, and which data you better load on demand.

Developing a Zabbix ExtJS frontend: Part One

Richlv asked me to give feedback about my experiences on the Zabbix PHP code, and this is the first blog post in that series. This posting is not intented as a “rant” at all, but as feedback and discussion for the development of Zabbix.

Why another frontend isn’t needed, but most probably wanted

There is always a controversy if somebody comes up with a new idea. People argue that there’s no need for something new, but obviously they miss one point: The person who says: “I want something new” really wants something new.

The current frontend has some drawbacks. However, the main drawback is the navigation:

The workflow is sometimes very unhandy. You have to switch back and forth between menu items, and end up with many open tabs or windows to achieve a single task.

An example of this is when you create a new host and notice that you’d better put some items into a template. You would need to save the host and navigate to the templates, create a template, navigate to the items, create the items, the triggers and then get back to the host to apply the template.

The exact same issue occurs when you have an alert; you don’t have the item’s history graph at your fingertips (=one click and you see the related charts).

In theory, much usability could be added in the existing frontend, but this would need a huge effort, due to the old-style implementation of the frontend.

How can ExtJS help here?

ExtJS is a JavaScript frontend library which is implemented in an object-oriented way. This helps with code deduplication and enables developers to implement reusable components. I’ve had very good experiences while working on the PartKeepr project.

In fact, while working on PartKeepr, I enjoyed the complete separation of business logic (which goes onto the PHP side) and frontend (ExtJS side).

Now where are the problems?

There are quite a few. First of all, ExtJS doesn’t support JSON-RPC, while JSON-RPC is the only API Zabbix currently supports. I can’t really judge if JSON-RPC is common or not, but I do feel that a RESTful API is more common. I solved that by implementing a wrapper which takes RESTful requests on the one side and converts them into JSON-RPC and calls the Zabbix API from there.

Another issue is that Zabbix doesn’t really use normalized entities. There are many tables, which are re-used for different things (example: Hosts and Templates share the same table). Some fields are probably used for hosts and not for templates, and vice versa (I’m really not sure about this, I haven’t created an in-depth analysis so far). If normalized entities would exist, one could write entity classes based on that, which in turn could implement the serialize/deserialize methods. That would give the following benefits:

  • Implementing additional Web APIs is very easy, because the entities themselves handle their serializing/deserializing.
  • You could minimize the Web API call implementations to a minimum when using an ORM. Right now, each API call has 1000-2000 SLOCs and if there’s something which needs to be added, like pagination, you would need to touch every Web API call. In turn, when using an ORM and an OO model, you would only have to change a single base class to make that happen.
  • Duplicate business logic could be unified, where it doesn’t matter if the Web API or the native PHP frontend uses the entity API; the business logic would stay exactly the same.

There are probably more benefits, such as reduced code error rate and better unit testing.

Another issue is the database model: It is purely created by a set of different SQL scripts for each database type. Migrations from one version to another is achieved by running an update SQL script. There’s no real code which could aid with type migrations in order to create a normalized database model. Also, it seems that Zabbix is using inappropriate data types (e.g. using int(11) on MySQL for boolean instead of boolean and also int(11) for timestamps). Additionally, it is virtually impossible to know what each column in the database does.

Conclusion

Zabbix was first released in 2001. Since then, much has happened. However, the code could be improved in many many places; which is a virtually impossible task to achieve for a very specific version. As Zabbix is used by customers and Zabbix SIA creates revenue out of Zabbix, any code refactoring needs to be done very carefully.

As much as I’d love to create a fork and throw in modern technologies like Symfony2 and Doctrine2, this would not be practial. As the plans for Zabbix 2.0 are already settled and customers are still using PHP 5.2 due to RHEL5 and others; this is virtually a KO for Symfony2 and Doctrine2.

While implementing the ExtJS frontend, I try to give as much feedback and patches to the Zabbix Developers as I can. I am not sure if it is even possible what I have in my mind for an ExtJS frontend; however, I am sure that it can be done, even with many nasty workarounds.

Building OpenChronos for TI eZ430-Chronos on Debian

I just have received my eZ430-Chronos two hours ago, and it is already running OpenChronos.

There were a few gotchas:

  • The OpenChronos repository is at https://gitorious.org/openchronos/openchronos and not at https://github.com/poelzi/OpenChronos anymore.
  • The current openchronos builds with debian’s gcc-msp430 just fine (wheezy/sid unstable with 4.5.3~mspgcc-20110716-3) . No need for external repositories.
  • You might want to install mspdebug to flash the chronos manually
  • mspdebug might spit out strange error messages if you don’t have permissions. Flashing as root did the trick for me.

You might wish to add the following rule into /etc/udev/rules.d/46-TI_launchpad.rules:

I hope that helps a bit

Modular Synth: Week One

A modular synthesizer in classic design, CC BY-NC-SA 2.0 RAETHIER

Well, crazy as I am, I decided to build a modular synthesizer. The question is: WHY?

Well, if you go out into a store and say: “Gimmez Modular Synthesizerz!”, vendor sayz: “Gimmez big $$$$”. Yes, modular synth modules aren’t that expensive, but they aren’t cheap, either. For a small modular synth, I can easily pay 2k€.

So DIY is the way to go. But it’s not only the cost, it’s also the things I will learn about analog synthesis and the electronics behind. I decided to go with the modules from Yves (yusynth.net) because there are many modules, and even multiple versions of the modules with easily obtainable parts.

I haven’t decided on which module format I will use; I believe I will most probably use MOTM (+-15V, 8.75″ Module Height), simply because yusynth also uses them. And Yves also got plans to easily build a case.

I already have the parts for the following modules:

  • ADSR-2
  • 2x VCO
  • 1x VCA
  • 1x Steiner VCF
  • 1x LFO-1
  • 1x ARP4072
Next step will be etching of the PCBs, and putting the parts together. Front panels and case will follow after all modules are done and tested.

In contrast to most modular synthesizers, I don’t like their old-school look. So I already ordered 700 of nice-looking knobs (they were cheap and very good quality), and I plan to cut the panels either with the RaumZeitLabor FaZzZ0r or via an external supplier. I’ll not reveal many details yet, stay tuned :)