I’m no longer really using this space; I’ve put all of my online accounts together and merged them under a new domain: ballpointcarrot.net. The project (which currently does not work with GNOME3, I know, I’m working on it), as always, can be found at Google Code.

Thank you to everyone who has used and appreciated this plugin in the past; I’m working on getting it functioning again soon.

That’s fun to say and all, but I’m sure that there would be people who would like to have some proof of this: see below.

My method, shown above, tends to perform slightly better at the task using the test parameter. So, I figured, why not do some more vigorous verification on it?

After setting up the system to run at multiple data points, I found something peculiar, yet interesting:

Hand-rolled (at 10^3):
Difference in time: 0.000569
mathn (at 10^3):
Difference in time: 0.001286
Hand-rolled (at 10^4):
Difference in time: 0.008029
mathn (at 10^4):
Difference in time: 0.014407
Hand-rolled (at 10^5):
Difference in time: 0.14803
mathn (at 10^5):
Difference in time: 0.165025
Hand-rolled (at 10^6):
Difference in time: 2.823072
mathn (at 10^6):
Difference in time: 2.687332
Hand-rolled (at 10^7):
Difference in time: 62.096438
mathn (at 10^7):
Difference in time: 64.990647


For powers of ten, it seems as though my process is faster. 10⁶ doesn’t quite follow the pattern, though.

I then ran the same test on different data points:
Hand-rolled (at 2^14):
Difference in time: 0.014882
mathn (at 2^14):
Difference in time: 0.009224
Hand-rolled (at 2^15):
Difference in time: 0.036732
mathn (at 2^15):
Difference in time: 0.022161
Hand-rolled (at 2^16):
Difference in time: 0.085459
mathn (at 2^16):
Difference in time: 0.044076
Hand-rolled (at 2^17):
Difference in time: 0.208553
mathn (at 2^17):
Difference in time: 0.076775
Hand-rolled (at 2^18):
Difference in time: 0.498292
mathn (at 2^18):
Difference in time: 0.151843

Running everything as powers of two show a reversal of position for the results; the standard lib does better. This gives me some insight as to why the above 10⁶ test is reversed; the value for 10⁶ is very close to a power of two (2²⁰), and so the optimizations that are in the ruby library to handle near 2ⁿ are in effect at that point. Logically, I would see something similar for 10⁹, but I’m not going to let my computer sit for a day to crunch that out.

I’ve been looking for work in new locations.  I am happy with my current job, in the fact that the people I work with are very skilled at what they do, and their attitude towards things is wonderful. Unfortunately, the actual work I am slated to do has put me in a lower tier than my peers: as an implementations role, I don’t end up writing as much code as I would like.

If anyone has any suggestions as this thing gets more used, I would like to hear them.  My current markets I am looking towards are in Seattle, WA, and the surrounding area; Boston, MA and the surrounding area; and the research triangle of VA/NC. Those locations seem to have a much better sense of what is being sought after for developers, and seems to have a greater market for the types of positions that I would like to have.

I guess I need to get myself sold to the world more, and maybe the world would in turn be more open to buying me.

Until today. Well, technically yesterday night. Whatever.

Yesterday, I had the wonderful experience of meeting a fantastic group of gentlemen called MadRailers.  These are not angry train workers, but a Madion, WI based group of software developers with an interest in the Ruby on Rails framework.

Through their discussions (dubbed “lightning talks”, based on the nature of the size of the presentations), I was able to pick up on some valuable pieces of the rails environment: some things I had already heard about, but got to see them in use, some things were new to me, and made things easier, which is every developers dream.

A discussion on proper testing techniques with Cucumber spawned a rigorous discussion on the correct use of the tool, and how the tests should be best written. One side had that the tests should test one logical piece of the feature, while the other side believed that the tests should be written in a way to show the full flow of the feature, from beginning to end. I would tend to agree with the first argument; if your tests aren’t clearly defining something to test, then they aren’t going to be very helpful if they break, and you’ll spend your time hunting down the error that caused all your tests to fail, instead of having one test tell you the error, and fixing the problem.

Another discussion was from a newer member to the community (relatively – as it was my first meeting, everyone had been there longer than I had) about why he found rails, and what he enjoyed most about it. These types of presentations can be more helpful than they set out to be: I found out about RVM, which is supposedly an indispensable tool (I’ll have to look into picking it up), and based off of a discussion generated from the presentation, I was able to see Haml in action. I had heard of Haml previously, but hadn’t had the chance to use it; now I really want to.

One of the later discussions focused on a rails plugin called active_scaffold, and a javascript library called Top Up. These were both new to me, active_scaffold greatly simplifies the amount of work needed to get a fast, decent looking data presentation available to make sure that all of your information works together correctly, and Top Up allows you to create modal windows as a container for virtually anything: text, html, swf, and even avi.

Overall, I think my greatest gain from the night isn’t a technical one, it is one of attitude.  From the level of organization that was provided, to the way that the conversation easily flowed between presenter and audience, and to the level of interest shown in the technologies presented, it showed to me that there really are more people like me. Living in Dubuque has some benefits, but the drawbacks are present as well; I never would have had the chance to do something like I did last night in Madison around home.  Some people were surprised at the fact that I would drive over an hour to come to a program like this; I think it was completely worth the trip (even through the weather, which was somewhat less than cooperative). Things that I’ve striven for and missed at work, like automated testing, simplification, and comfort with a product are things that these guys have at their disposal; it shows that there is light at the end of the tunnel, and there’s something to aim for.  After talking with some of the members, it looks as though they had been in similar situations before, so it looks like there is hope for me yet.

If they end up reading this, thanks for a wonderful evening, guys.

Called Paint, the idea is to have four main colors at the edge of the screens. By the phone’s tilt, those colors will bleed into the screen itself, causing the animation, and interactivity with the phone regardless of whether or not you’re actually accessing an app. The LWP actually becomes as fun to use as anything else on the phone.

The basic setup is contained in this Gist.  There’s more to add, but I made my quota for the day, and I want something to work on tomorrow.

I’m giving myself a challenge, and having my blog (Corner of Seven, for those of you reading this via Facebook) become the record of my success or failure of this challenge.

Starting today, my goal is to write *at least* 50 (fifty) lines of code per day.

This idea came about through the previously mentioned “Don’t Break the Chain” post on this blog (which worked oh so very well…),  and a recent experience that I had at work.

Most of my work duties are currently system configuration and setup, and less actual development on said systems.  With that, my ability to get code written has diminished.  I was asked recently to create a component in our software that renamed a file going out, based off of metadata contained within that file.  After sitting blankly at the computer screen, with my brain screaming, “I know what to do!!!!” and my hands frozen, unable to regain the muscle memory of the common actions of Java, I looked inside, and realized this had to change.

In a sense of betterment, I want to complete at least a small project daily.  Maybe it’s a coding kata. Maybe I work on stuff in Android.  Maybe I continue work on RBEQ.  Maybe I add new things to Corner of Seven.  Maybe it’s something I haven’t even thought of yet. All I know is that new code needs to come out of me, before I can’t do it any more.

Fortunately, I have tools at my disposal.  The afforementioned projects can keep me busy for a while, but what do I have to show the work that I’ve put in? Enter the Gist system at GitHub. This allows you to put small snippets of code out, configurable by language; it gets your code available on the internet, and embedded into a blog or webpage.

So there you have it.  Look to see some Gists from me shortly.

Cheers!

Note: This project is still in progress. Please travel to the Google Code Project for more.

Just when you thought it was safe…

1.4 of the RBEQ, the Rhythmbox Equalizer, is out and ready for download. The big change here is a switch from storing presets in a flat file to using the GStreamer Preset system. As always, downloads are at RBEQ Google Code.

A big thanks to Stefan Kost, who left this gem of a comment on the 1.3 release posting:

Any reason, you are not using the presets shipped with the gstreamer plugin?
Look at /usr/share/gstreamer-0.10/presets/GstIirEqualizer10Bands.prs and the GstPreset interface.
Users can install own presets to $HOME/.gstreamer-0.10/presets/

Since I didn’t know anything about them, after looking at the aforementioned docs, I’ve gotten things so that they use the GStreamer Preset interface, and it is more well-behaved.

Also a big thanks to Hicham HAOUARI, whose awesome work has gotten RBEQ into Fedora! That’s awesome; I was nearly flabbergasted when I saw that. Thank you for the support!

Comments and bug issues are always welcome; please let me know what you find while using it.

The previous statement isn’t much of a surprise in this day in age, but I think I should qualify what I mean.

I’ve been having a lot of fun playing with the software internals of my new phone.

The Motorola Droid has been quite the versatile little device.  I’ve thrown nearly all I can think of at the thing, and it handles it smoothly and without issue.  In the past 4 weeks, I’ve rooted, flashed, reflashed (I’m indecisive), cleared, recovered, flashed again, and customized to my heart’s content. Currently, it looks like this:

That’s right… Shiny.

There’s a fantastic community of people who create and contribute to these modifications over at alldroid.org, particularly in the forums.  I’ve met some good people out there, who really know what they’re doing.

I recently dual-booted my desktop, so I could get back in and do some fun playing around.  Unfortunately, I chose a 64-bit operating system, and they’re not supported for the android source tree and utilities. (A poor excuse, I want to see what I can do to fix that.) So I’ve been debating the past couple days, whether or not to clear my new install, and put on Ubuntu 32-bit edition when it comes out, so that I can tear into the source and help contribute to the site.  Most likely I’ll wait until 10.04 (Lucid Lynx) comes out; I’ve loved what I’ve seen and played around with so far, so it’ll be good to get in there and play around with my phone’s internals.

One of the big requests on the alldroid forums is the ability to hot-swap phone ROMS without the need for a full reboot.  I think I have an idea on how to accomplish that.  In the same way that the Xen environment handles virtualization, we need to create a custom kernel that handles virtual ROM running. There would obviously be a performance hit, but with people overclocking their droids to 800MHz up to 1.3 GHz, I don’t think there would be much complaining.  Basically, we need to let the ROM handle hardware switching from one ROM to the next, and let the internals provide the rom connection.

Just having ideas.  Others include a complete revamp of the Web, and a new OS.  I’ll get to those at another time.

Other phone screenshots:

Note: This project is still in progress. Please travel to the Google Code Project for more.

Hello all -

A new version of RBEQ, the Rhythmbox Equalizer plugin that I’ve been hacking away at, is out for public availability.  Of course, this means that I have to go update all of my previous links to point to the new download.  For ease of accessibility, you can find it at http://rbeq.googlecode.com, as the featured download. Installation instructions are the same: download the file, open a terminal, and type:

tar -xvzf rbeq-1.3.tar.gz -C ~/.gnome2

New in this release:

• The ability to save and load presets.  This has been a big request, and I finally found a decent way of handling it.
• Layout cleanup and arranging to add in the new preset functions.
• Backend code cleanup, so that it behaves more python-y.  I’m not a python programmer, so this has been a neat experiment in trying it out.

Thanks to all out there who have used and enjoy the past versions of this plugin.  Hope that the new one is to your liking.