semi/signal

Netbean 7.4 introduced something really weird:

Apparently this is some sort of simplistic, ill-conceived metric for code quality. I can’t imagine the number of lines in a method matters at all compared to its role in the overall application architecture, its cohesiveness within its containing module, and its dependency on other methods and modules.

On an ArsTechnica article regarding why government IT projects fail so badly, one notable comment stood out to me:

I think that meaningless metrics may be one of the most dangerous things we see in modern society. I’m not saying that the metrics of the past were much better, but now it seems like we have so many more (more data is better right?) and people actually believe they’re somehow objective because they’re “data-driven” and numbers don’t lie. A worthless metric becomes a number that’s indistinguishable from a good one a spread sheet which leads others to see it to simply optimize the one they can most easily optimize. Of course this then leads to the highly tempting situation of designing your metrics to be easily optimizable. Combined with the fact that few people pay close attention to what the metrics actually say, it’s not wonder that most of these “objective” measurements basically say nothing.

I think lines per method clearly falls into the category of meaningless metric, and it’s terrible that code may be evaluated by it and programmers judged by it.

An interesting housing complex design in Montreal. Habitat 67 designed by Moshe Safdie:

Photo by Taxiarchos228 at the German language Wikipedia

I began experimenting with WebGL a while back and hit a wall when it came to importing geometry data into a scene, as you can only get so far with programmatically generated cubes and spheres. I looked into an Wavefront OBJ to JSON conversion tool (to just spit out the vertices, normals, and texture coordinates of the OBJ model), but couldn’t find much. There’s a Blender plugin for Three.js, but I didn’t want a dependency on Three.js nor the Three.js JSON file format; I have nothing against either, but I didn’t want to add a thick layer of abstraction like Three.js and, honestly, I wanted to delve into the OBJ format and deal with working on geometry data at the vertex level.

The result is a simple OBJ to JSON converter written in C++. The code for the entire program is below and also available via the bitbucket repository.

One of my test models was the Clocktower model by thinice and shown below is a WebGL rendering of the converted geometry data.

The program takes 2 arguments:

• The path of the input OBJ file
• The name of the output JSON file

Note that the converter does have some limitations:

• It will not deal with materials (i.e. it does not parse any corresponding MTL files)
• It will only parse triangle faces (no quadrilaterals). If the model has quadilaterals, you can convert them to triangles in Blender by going into Edit mode, selecting all vertices, and hitting CTRL + T.
• Named objects and polygon groups are ignored; the converter essentially treats everything in the file as a single polygon group.

One notable aspect of the conversion is denormalizing the geometry [done in denormalize_polygroup()]. An OBJ file stores unique lists of vertices, normals, texture coordinates, etc. and for each face there is an index into the list of vertices, an index into the list of normals, etc. This is great when it comes to storing data (as it eliminates duplicate geometry data, and decreases the file size) but when rendering you can’t have the data organized like this, as you can only have a single index buffer, where each index corresponds to the same location within the list of vertices, normal, texture coordinates, etc. Therefore, data must be duplicated such that every combination of vertex coordinate, texture coordinate, normal, etc. is uniquely identified by an entry in the index buffer (e.g. if 2 vertices have the same position but different texture coordinates, it has to be identified by a different index in the index buffer, and the position must be duplicated so that the new texture coordinate and position can be referenced by the different index).

EDIT (11/1/2013): In the initial code committed and presented was outputting Javascript variables set equal to arrays, the code has been updated to output valid JSON data instead. Furthermore, the namespace argument for the program is no longer required and no type of namespacing is done on the output data.

I was curious about the performance of PHP’s count() function a while back and whether it was worth it to store the result in a variable for repeated use. I discovered the following from this answer by FractalizeR on Stack Overflow:

PHP_FUNCTION(count) calls php_count_recursive(), which in turn calls zend_hash_num_elements() for non-recursive array, which is implemented this way:

ZEND_API int zend_hash_num_elements(const HashTable *ht)
{
IS_CONSISTENT(ht);

return ht->nNumOfElements;
}

So you can see, it’s O(1) for $mode = COUNT_NORMAL.

A long time ago I wrote some code to play CD audio tracks for a game engine I was writing. CD audio (via mixed mode CDs) was popular for video game music at the time because it allowed for high quality music without having to deal with large un-compressed audio files (e.g. uncompressed WAV) or relatively expensive decompression algorithms with compressed files (e.g. MP3).

I cleaned up the code a bit and decided to post it here. It’s surprising simple code as it uses the very high-level Media Control Interface (MCI).

Compiling and Linking

You must link with winmm.lib

cdaudio.h

cdaudio.cpp

main.cpp (example showing how to use cdaudio functions to play track)

Cleaning out old cards from my wallet and found my museum pass, for the Civic Museums of Venice, from a trip to Italy a few years ago.

In my previous post, I described computing row numbers for items within a result set. If items in the result set can be ordered into groups, you can use the same technique to number items within the groups. This is valuable as it allows you to get the top 3, top 5, top N … items within each group (note that GROUP BY isn’t appropriate here; we don’t want to aggregate items within a group, we want an ordering of all the items within a group).

Consider the following sample of data where we’ve done an ordering by the location and age fields (ORDER BY location DESC, age DESC). Every user’s email address is within a group (location) and within that group users are sorted by age in descending order.

By using two variables, one to keep track of the item number (@itm) and another to keep track of the current group (@grp), and incrementing the item number if the current group has not changed, else resetting it to 1, we get a numbering of each item within each group. In this example, the group item number tells us who is the 1st oldest, 2nd oldest, etc. user in each location.

Surprisingly straight-forward. Row numbers are useful is cases where you need the rank of a row within a result set.

The variable initialization can be done without a SET declaration by doing it as a JOIN:

Solution via Daniel Vassallo’s answer on StackOverflow. A comment mentioned the row numbers being calculated before ordering is done, but I haven’t found this to be the case.

While the above queries will give you the row numbers as expected, putting a HAVING or GROUP BY clause in the same statement might be dangerous. From Xaprb:

The result of assigning to a variable and using it in the same statement (in the HAVING, for example) depends on the query plan the server chooses, the phase of the moon, and probably other things too.

So, in such cases, a subquery is the safe bet:

Random timestamps are fairly simple to generate and useful when creating test data or fake data for demos. The technique involves converting a MySQL timestamp into unix time, adding or subtracting a certain time range (in seconds), then converting back to a MySQL timestamp.

I’ve used this technique presented on underdog-projects.net before, where a starting timestamp is specified and a random time span is added to the timestamp. However, I wanted to try something slightly different and, in my opinion, a bit more robust. Instead of specifying a starting timestamp, I wanted a pivot timestamp from which a random time span is randomly added or subtracted.

Of course all the variables can be made part of the SELECT statement to make everything more succient.

I’ve not posted anything in a while partly due to time constrains but mostly because I’ve been working on redesigning this blog and wanted my focus to be 100% on the redesign before publishing anything new. In addition to the redesign I also wanted to put this blog on it’s own domain and move away from aautar.digital-radiation.com/blog (when this blog was setup the digital radiation team was more than myself, hence the aautar subdomain, and I wanted other, non-Wordpress pages, to live in the root, hence the /blog folder). I snagged the semisignal.com domain a while back and thought it was a great choice for the blog and positioned it away from old or non-relevant content on digital radiation; this blog (and content linked to from this blog) have been the only things relevant on that site for quite a while.

With regards to the redesign, I had a few key goals in mind as I was working, which I’ll run through below.

• Clean and consistent design: One of the big problems with the old blog was that it was hacked together from the default WordPress template at a time when I knew very little CSS. There was a lot of bad things both in the code I wrote and in the base code I was working from. I kept making minor improvements over time but there were still a lot of things that didn’t look good (unstyled input buttons, tags, etc.) and things that only looked good if additional inline styles were applied. There were also a number of inconsistencies in regards to link styling, tag styling, search input location, etc… a lot being due to different rendering code for single posts vs multiple posts in the archives and search. This redesign attempts to address these issues, while providing a cleaner, fresher look to the blog overall.
• Bring content forward: At one of my first jobs, my boss mentioned that one of the design goals of our project was to “bring content forward”, pushing back superficial elements that took up real estate but had no real functional purpose. This has stuck with me since. With this redesign, I ditched the massive header, ditched the blurb and photo of myself, and increased the space given to posts.
• Responsive: Admittedly this was not a goal when I started this redesign, but more and more I wanted something that would at least scale comfortably on a tablet and allow navigation via touch. I probably did responsive design wrong here (it’s not mobile first, styles are hacked in here and there to accommodate for different sections and breakpoints), but the new design was simple enough that I really only dealt with scaling elements and not with stacking them. For the lowest resolution breakpoints (for phones), I simply dropped the sidebar, betting that search was a better means of navigation on a phone, where a user’s intent is more directed towards a specific need, and they likely aren’t looking to browse the site.

• Highlight projects & notable content: As with the old design, I wanted to keep a section in the sidebar to highlight my projects. Going forward I may add another section or expand this section to include notable posts as there are a handful of posts which are popular, but visitors really don’t have a way to find those easily.
• Meaningful gateway to content: With the old design, you could browse through posts by going to a month in the Archives or selecting a specific Category. Neither of these really made sense. Category (in the way I use it) is generally way too broad to browse over and digging into the Archives gives you, essentially, a random set of posts given that the only context binding the posts is the date they were published and my posts are not time sensitive in nature.
• Consistent gateway across all pages: With the old design there were 2 ways a post could be displayed: narrowcolumn where the post with listed with others and the sidebar content was displayed, and widecolumn where only a single post was displayed but the sidebar was empty (with a fixed width layout, going wider has always been preferable for me but I hated the layout of an article changing when you clicked to view a single post, so I had reduced the width on the widecolumn display as well). Search was also not available in the widecolumn display (I have no excuse for that). With the new design the sidebar (at non-mobile resolutions) and search field are consistent and visible across all pages.

The old design served me well for a long time and, looking back, it’s surprising how well it held up, given that so much was hastily hacked together. That said, I’m excited to move forward with this new design and begin focusing on content again.