Fanciful Magic

Getting a USB sound card configured for Raspberry Pi 2

2015-05-24T18:02:00.001-05:00

I recently tried to get a USB sound card working on a Raspberry Pi 2. My motivation was to start working on audio applications like writing my own synth. It's something I've wanted to do for a long time, but some odd reason never got around to it. At first, I simply tried to output sound via the built-in sound card. This experiment was successful of course, but there was a lot of noise in the output. I tested using the SonicPi program that comes with the Pi.

My next experiment was to use a USB sound card that I had gotten for cheap. Apparently, these are hit and miss and if I were to do it over again, I would get one from Adafruit where they sell ones that have been tested for the Pi. Everything worked out so I lucked out, but the path to success was not obvious. For your information, I used the CMedia HS100 from NRGtech. I also used the latest version of Raspbian (Debian Wheezy) and updated my pi firmware with "sudo rpi-update" before I even started since most guides mentioned to do this for latency.

Before I begin, I was repeatedly given the ALSA (Advanced Linux Sournd Architecture) document. There's a lot of information in there. I hope to spend sometime read it more thoroughly, but when you're trying to get something simple working, it's like drinking from a fire hose.

Plugin the USB sound card.
Navigate to the Menu>Preferences>Audio Device Settings.
At the top of the dialog, there is a drop down for the sound card. Mine displayed "bcm2835 ALSA mixer) (Default)". Click it and you should see your new USB sound card. Again, mine displayed "USB PnP Sound Device (Alsa Mixer)".
Select the USB sound card.
Click "Make Default" button.
You can click "Select Controls..." which brings up a dialog for you to be able to select things it can use to change settings on your sound card. I selected everything.
Make sure volume is up and USB soundcard is connected to either headphones or speakers. To verify, my speaker setup, I used the built-in audio output first before connecting USB sound card.
Edit /etc/modprobe.d/alsa-base.conf with your favorite editor (sudo vi /etc/modprobe.d/alsa-base.conf). I strongly recommend making a backup of this file. You can also follow this from an Adafruit article as well.
Find the line "options snd-usb-audio index=-2" and change it to "options snd-usb-audio index=0".
Add another line below the edited line: "options snd_bcm2835 index=1"
Save the alsa-base.conf and reboot the pi (sudo reboot).
speaker-test -c2 -D hw:0,0. This should work. You will hear white noise from left to right on your speakers.
aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
Success? Or did you get "Channels count non available". If success, you can stop now and celebrate. Have some fun with SonicPi!
sudo aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
This probably worked. If so, the answer is simple. Edit the $HOME/.asoundrc (vi $/.asoundrc). Back up the original is again strongly recommended.
Clear the existing contents of the .asoundrc.
Add "defaults.ctl.card 0"
Add "defaults.pcm.card 0"
Add "defaults.pcm.device 0"
Save .asoundsrc. Try "aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav" again.
Success? Excellent. Glad this guide can help. If you are still having issues: this article and this one too helped me figure out what was going.

I wrote this guide up mainly for myself so I don't forget it and to use again. Hope it helps you as well.

Why Smalltalk is the productivity king

2015-02-02T21:21:00.000-05:00

I've been thinking about why I'm so much more productive in Smalltalk than any other language. The reason is because I'm curious if you could bring some of it to other languages. So, what makes Smalltalk so special?

Incremental compilation. There is no cognitive drift. Compilation happens at the method level when one saves the code. It's automatically linked in and can be executed. Smalltalkers enjoy programming in the debugger and changing code in a running program. The concept of having to restart an entire application is foreign to a Smalltalker. The application is always alive and running. In other languages, you code while the application is not running. Programming a live application is an amazing experience. I'm shocked that it's hard to find a language that supports it. Java running the OSGi framework is the only example I can think of. But, one still has to compile a bundle (which is larger than a method).
Stored application state. Smalltalkers call it the image. At any point in time, you can save the entire state of the application even with a debugger open. I've saved my image at the end of the day so that I could be at that exact moment the next morning. I've also used it to share a problem that I'm having with another developer so they can see the exact state. It takes less than a second to bring up an image. It has the current running state and compiled code. One never spends time waiting for compiles or applications to start up.
Self contained. All of the source code is accessible inside the image. One can change any of it at any time. Every tool is written in Smalltalk. If one doesn't like how something works, one can change it. If one wants to add a feature, one is empowered to. Since everything is open, one can even change how the language works. It's programming without constraints. The original refactoring tools were written in Smalltalk.
Freedom from files. Allows Smalltalk to store the code in its own database. The shackles of the file system makes compilation and version control trickier. Smalltalk can incrementally index code to make searches quick and efficient. The structure of the code is not forced to fit into the file system mold.

Now, the question one has to ask is why don't we have these features in languages that we use now? Personally, I would love to be able to keep my application running and change the code as it runs. I just want to end productivity lost to application restarts and compilations.

Pharo 3.0 Projects - JavaLoader and iTunes Parser

2014-05-02T12:58:00.002-05:00

I've been inspired recently with the new release of Pharo 3.0. I updated my JavaLoader project and added a brand new project called iTunes Parser. The JavaLoader project is an old project that can load serialized java objects and Java classes. The iTunes Parser can load the xml iTunes library file. Check them out if you use Pharo 3.0 and give me any feedback.

One Year Of Pomodoro

2013-11-17T11:00:00.002-05:00

I gave my first Pomodoro talk this year at the Tampa Bar Camp. Needless to say, I'm still a firm believer and practitioner of the technique. I've spent this year experimenting with what works best and makes me more productive. It has been invaluable. Now, I do it slightly different than what is discussed in the book, but I find productivity to be personal: do what works for you. For the most part though, I follow the technique strictly.

Let me begin by describing my use of pomodoros. I begin every morning with a blank sheet of paper. I draw a line down the middle and on the top left write the date and "Unplanned" on the right. I then write every task that I need/want to accomplish today. I write left over work from the day before first. I put estimates next to each item by placing empty boxes for each pomodoro. I then prioritize each task by placing numbers to each one based on urgency. With coffee in hand, I begin my day.

I set my timer for 10 minutes and go through my email. Any requests get written down in unplanned and I put estimates on the task. I then determine urgency for each one and update my priorities accordingly. I try to keep my urgent unplanned work to a minimum. If any email needs a reply, I will try to respond immediately. If it will take more than the 10 minutes to respond, I will star the email to get back to it later. The point of the first 10 minutes is to get through my inbox. It's about minimizing distractions. If I have enough starred emails, I make an email task to get to in the afternoon. I don't prioritize this task. I want to use my productive morning time to do real work.

For the rest of day, I work in 25 minute chunks with 5 minute breaks. I try to do 3-4 pomodoros followed by a longer 10 minute break, but most of my days get broken up with meetings anyway. I try to get in as many pomodoros as I can. For each one accomplished, I check off a box next to a task and put a mark on top of the page. The marks at the top allow me to see how productive I've been that day. The marks on the boxes allow me to see how well I'm estimating. If a task takes longer than what I have estimated, I draw a circle to notate that I under estimated. This is valuable data for learning.

At the end of the day, I look back at what I accomplished and make some notes for what I need to do the next day. The day sheets are invaluable for determining productivity. When I first started the technique, I was shocked that I was finishing only 3-4 pomodoros a day. This means I was doing only 1.5-2 hours of productive work a day! This evidence allowed me to have direct and frank discussions with my management. This meant moving meetings around and minimizing which ones were really needed. It also forced me to manage my emails accordingly. Now, I get 6-8 pomodoros per 8 hour work day. It's still not to the level I would like, but I'm constantly trying to figure out how to be more productive. I would like to get to 12 pomodoros per day eventually.

That's the basics, but the most powerful part of the pomodoro is handling interruptions. This is what keeps me doing pomodoros. At work, I bought a children's timer that has a huge light on it. I got it as a huge visual clue for my co-workers . Now instead of interrupting, they will send me an IM or email. They know if it's urgent to send an IM and I will get back to them after my current pomodoro, otherwise send an email. I try to only check my emails twice a day.

I use pomodoros on my off-time projects as well. It allows me to time box all the things that I want to do. I used pomodoros to write this blog post (it took 3). I love it for its simplicity and allows me to concentrate on all the things that I want to accomplish. It might not work for everyone, but I encourage you to least try it. After a year, pomodoros are an integral part of my work and I can't see myself abandoning them anytime in the future. It's the best technique for managing interruptions, estimating, and measuring productivity.

Java Reader Update

2013-02-18T10:19:00.004-05:00

I just updated my old Java Squeak project to SS3 and Pharo. It now works with Pharo 2.0. You can find it here. If you find any bugs, let me know. I plan on doing more with it in the future. Stay tuned. For a quick reminder, it allows you to load Java class files and read in serialized streams. The only drawback right now is if the Java objects have customized read/write methods. But, I'm working on a solution for that. There are tests to make sure all major functionality works.

Pomodoro Technique

2012-06-22T10:29:00.000-05:00

I was reading Robert Martin's excellent "Clean Coder" and he mentions a productivity tool called the "Pomodoro Technique". The premise is simple. Work for 25 minutes, then take a 5 minute break. During a 25 minute period (called a Pomodoro), you concentrate on one and only one task. If you are interrupted, you deal with it once the 25 minutes is up. Sounded simple and I was looking for a way to increase my productivity.

The first day that I tried it, I was enlightened and shocked. First, I was amazed how much progress I could make on a task in 25 minutes. I loved the 5 minute breaks for short walks. But, I was shocked how little productive time I got done in that first day. I only got through four Pomodoros. The rest of my day was meetings and helping my team mates. But, in that time, I got more accomplished than the previous day.

I kept doing my work for the rest week using this simple technique. I discovered that I loved working this way. First, it was an effective way to manage interruptions. Instead of addressing an interruption immediately, I would simply delay until the end of the current Pomodoro. After a few days, everyone got the swing of it and supported me. Another one was taking the break in the middle of a task that spanned multiple Pomodoros. At first, it was hard and wanted to keep on working. But, I decided to stick with the program. What I found was that a lot of times, just the 5 minutes to walk away when I came back, my work would take surprising turns. It forced me to evaluate where I wanted to go at the beginning of the next Pomodoro. By the end of the week, I was getting more work done, tracking better on my estimates, and felt better about the work I was getting done even the number of Pomodoros was low. I was marking more tasks off my to do list than ever before.

The next week I decided to read Pomodoro Technique Illustrated and the free ebook. And I made adjustments to how I was doing it based on what was in those books. When I got in the morning, I looked at my to do list and prioritized what I needed to get done that day. Next, I estimated how many Pomodoros it would take to complete the task. If the task was longer than 4 Pomodoros, I broke it up into smaller tasks. What I found out by doing this is that I could make head ways via 25 minute chunks on multiple projects. I could spend a Pomodoro on a bug as a break if I wanted to to help break up the monotony of a long task. I also noticed that I was getting more Pomodoros done because I wasn't jumping up at every interruption.

Every day I'm tweaking how I work within such a simple constraint of working for 25, break for 5. In conclusion, the Pomodoro Technique will forever be something that I do to track work. I've been amazed how much it has helped me thus far. I love that it's easy to track time on my projects, forces me to take mental breaks and exercise, breaks my flow in a good way, gives a graceful way to handle interruptions, allows me to reassess my work, and is simple. I've even started to using it on my spare time projects, so I can better allocate time to the things that matter to me. I've even playing around with the 30/30 off-shoot as well to handle free time and working on household chores. But, that is another blog post.

Lost two of my heros

2011-10-26T21:26:00.001-05:00

This month I lost two of my heros: Steve Jobs and John McCarthy. As a child, I dreamed of being Steve Jobs. I admired him for what he accomplished and his impeccable showmanship. I learned so much from him and his vision. I'm sad that I will never be able to meet him.

When I got older and learned about how Xerox Parc and John Engelbart inspired the Mac, I found Lisp. My love affair with Lisp goes back to college when I didn't quite understand it, but thought it was strange yet elegant. The light eventually went on and the true power of macros and functional programming was eventually revealed. To this day, there is a source of amazement that comes with Lisp and I thank John McCarthy for that. I wish I could have met him as well.

I can't express how I much these men touched my life without ever meeting them. They both hit the ball so far out of the park that they will be revered for generations to come. The bar has been set and I plan on standing on their shoulders. Thank you.

The days of templates are over

2011-06-04T08:30:00.000-05:00

When I first started to work with web applications, it was just servlets and then came JSPs. At the time, I didn't like JSPs (and to this day I still don't). They seemed like a necessary evil that got the job done. The thing I found repulsive about them was the mix of server and client code together. The switching of contexts just made both look ugly and hard to maintain. But, it was easier than generating pages directly from servlets by hand. Of course, there were other solutions that I looked for, but nothing got away from the horrid markup. Then, I fell in love with Seaside which did away with markup and generated content through a custom DSL. It felt better to me and loved it until I realized that it was only for the developer, not the web page designer. It made their life harder. Now, we all know we should use minimal content and have CSS do the layout. But, in this modern world, you need folks who are experts at web page design. You can not and should not alienate them.

Fast forward to now. Currently, I've been using Javascript frameworks and working mainly from the front-end. The project I'm currently working on is pure HTML/Javascript/CSS for the front-end with RESTful calls to the backend. I must admit, I had my reservations about this arrangement, but after working with it; it is the right thing to do. No more ugly markup. The separation of concerns is well in place. And finally, the web designer is allowed to concentrate on making a rich user experience and the developer to concentrate on business logic. Perfect.

My feeling is that the days of template engines are over. It's a waste of time and all of them are a pain to debug. A pure Web 2.0 AJAX solution allows each to utilize their tools and do things separately. To me that is exciting and I will gladly leave ugly code behind.

App Dev Today

2011-06-04T08:13:00.000-05:00

I'm pleased to announce the start of a new venture. It's a new company to launch new mobile applications. The ball is just starting to roll and exciting times are ahead. We have some cool stuff up our sleeves and will be showing soon.

Easier Memory Release In Objective C with Blocks

2011-04-04T15:10:00.000-05:00

I've been getting my head around Objective C recently and remembering all that is great about about manual memory management. I found myself repeating code that either a) autoreleased or b) released with try finally loops. The autorelease puts a drag on your pool so you want to use it sparingly (with APIs where you don't know who will be calling it) and it's mentioned in several places in the Apple documentation to favor "release" over "autorelease". So, that leaves me with option b in most of my code with a lot of boilerplate code. And I hate boilerplate code. Well, did some more reading and found out that blocks are a new thing in Objective C and I quickly whipped this up:

typedef void (^Monadic)(id value);
typedef id (^Niladic)();

-(void)use: (Niladic)calc during:(Monadic)monadic {
    id toUse = calc();
    @try {
        monadic(toUse);
    }
    @finally {
        [toUse release];
    }
}

Basically, it allows you to send in one block to get the allocated object and then use it in a try finally. It automatically cleans up after itself! I then decided to try it out on some code:

-(IBAction)calculateClicked:(id) sender {
    [self 
     use: ^() { return [[Cents alloc] initWithString: [startView text]]; } 
     during: ^(id startAmount) {
         [self 
          use: ^() { return [[Cents alloc] initWithString: [eachYearAmountView text]]; }
          during: ^(id eachYearAmount) {
              [self
               use: ^() { return [[NSDecimalNumber alloc] initWithString: [interestView text]]; }
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
}

I think I made it too generic in that I now have to type "^() { return [blah blah blah]; } every time. I realized I could get rid of those blocks and just pass in the object I want to clean up. Remove Niladic block and take two looks like this:

typedef void (^Monadic)(id value);
-(void)use:(id)toUse during:(Monadic)monadic {
    @try {
        monadic(toUse);
    }
    @finally {
        [toUse release];
    }
}

And this is what it looks like when you use it:

-(IBAction)calculateClicked:(id) sender {
    [self 
     use: [[Cents alloc] initWithString: [startView text]]
     during: ^(id startAmount) {
         [self 
          use: [[Cents alloc] initWithString: [eachYearAmountView text]]
          during: ^(id eachYearAmount) {
              [self
               use: [[NSDecimalNumber alloc] initWithString: [interestView text]]
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
}

As long as the Monadic blocks stay on the stack we don't need to do the copy autorelease business on block objects. I like this code better than nested try finally code because I'm not repeating the name of my variable to release in the clean up code. I'm still not 100% happy with the code, but I'll keep playing around with other things until then. I do like the fact that it is simple. Just something I wanted to share as I learn Objective C.

Singleton Pattern in Dojo

2011-03-11T19:19:00.000-05:00

Recently, I needed to have a singleton object. So, I came up with the following implementation to give me just that.

var makeSingleton = function (aClass) {
    aClass.singleton = function () {
        var localScope = arguments.callee;
        localScope.instance = localScope.instance || new aClass();
        return localScope.instance;
    };
    return aClass;
};

When declaring my class in Dojo, I did the following:

makeSingleton(dojo.declare(...));

Then, to use it:

var instance = myClass.singleton();

I like the fact with this implementation that it's obvious that I'm creating a singleton object up front around the dojo.declare. Of course, there's nothing preventing someone from creating the class with new, but we could easily get around that with throwing an exception in our constructor after our singleton has been initialized.

Functional Programming In Python 2

2011-01-22T10:55:00.001-05:00

I gave a talk this month to the Tampa Bay Python User Group on functional programming in Python. It's actually the second part of the talk. I've put the slides up for all to enjoy here. If you have any questions or complaints, feel free to contact me. I welcome all comments.

Collaboration Not Pairing

2011-01-22T10:28:00.000-05:00

One of the tenants of Extreme Programming is pairing on all production code. At first, it seems to make perfect sense. Four eyes on all code is better than two, right? There is another partner to help solve issues, take over when one is tired, and to keep each other honest. What could be wrong with that? Plenty. I feel that pairing is good in spurts of time or as I like to say, "Collaborate not pair".

I want someone to help me on the hard problems. I don't need someone peering over my shoulder to make sure I'm coding a for loop correctly. I think big picture. I want a pair to help with the design and make sure it is sound. The physical act of coding might have some hard problems too and I would like a pair for that as well. But, for the mundane boilerplate code, I don't need to watch someone type that.

I believe you need a mix of alone time on a problem and together time to exchange ideas. Pairing constantly stops that and it's easy to fall prey to a stronger partner's ideas even if those ideas are bad. The stronger personality wins. This should not be the case. But, I've seen it many times on XP projects. A pair put into production code that was clearly not good and hard to maintain. The very thing pairing is supposed to prevent.

This doesn't mean I don't want four eyes on all code either. I think a collaborator should read over every line of code that is written in isolation and ask questions. This is where time away is helpful. The partner brings an outside perspective than if the pair was sitting side by side. This prevents group think or one partner overbearing another. There's also the case where some developers are intimidated working with someone all of the time. They need to have space to properly think. These developers can be prone to letting a stronger partner always have their way. Again, not what we want.

As you can see, I'm not against pairing, but against constant pairing. Collaborate when necessary and make sure to leave time to think in isolation. You need both. You can't be all one side or the other. Either one all of the time is not healthy. But, how much collaboration versus alone time is needed? This is where you have to use your best judgement. Agility is about thinking and finding the right solution for the right situation. It's not a one size fits all world.

Domain Driven Design Immersion

2011-01-21T08:14:00.002-05:00

I've been meaning to write about my experience at the Domain Driven Design Immersion training that I took back in November. But, I've been so busy that I haven't had the time to put down my thoughts on it properly until today. First off, I had a great time; met many wonderful and intelligent people; and learned quite a few new techniques. Just given that, it was well worth the time. The course was simply fantastic.

I read Domain-Driven Design when it first came and fell in love with it. I've read it several times and consider it one of the greatest books on design. It's a tome of knowledge on being practical in design and getting closer to mapping user language to code. There are no silver bullets, just great advice and a road map of thought to get there. Despite the book being well-written, there were questions I've had when applying DDD throughout the years. I jumped at the chance to spend a week immersed in DDD and learn a few more tricks.

The training was excellent: well-paced, interactive, and loads of discussion. DDD is something that you must practice and the training provides a lot of it. From hands on coding to white board design sessions, you get your mind in the middle of the whole process. The trainers guided discussion and encouraged us to be creative in our solutions: messy whiteboards are good! I've been to a lot of training and seminars. Normally, little thought was given to pacing of the material. This was not the case with DDD Immersion. I felt there was an excellent mix of lecture, hands-on, and discussions. Each day felt like it went by too fast. Four days is not a lot of time to cram the amount of material that the DDD book covers, but the course materials provided abbreviated documents to bullet point the important ideas. I personally thought the materials made the course all worth it.

Even if you have read the DDD book, I still think the training is worth it's weight in gold. I work with Eric on his Time and Money library and I still got new ideas out of it. The training does add new material to the book and expands on Eric's new ideas concerning DDD.

The one thing that I took from the training is it's all about practicing to get better at design. Eric has laid out a path of thought on design. It still takes ingenuity and playing around with ideas to be successful. Design is a creative process and it takes hard thinking to match the language of users into code. The training brings that home. I whole heartily recommend the training and would go again given the chance. The real world keep giving me problems where questions arise to the best way to tackle them. You can never stop learning.

Functional Python Talk In Tampa

2010-10-14T08:41:00.000-05:00

Here's my presentation from last night for anyone that missed it.

I mentioned several books and articles as well.
Peter Norvig's "Tutorial On Good Lisp Programming Style"
Thomas Kuhne's "Functional Pattern System For Object-Oriented Style"

Imitation and Repetition

2010-08-29T12:20:00.000-05:00

I was recently reading Alice Cooper, Golf Monster: A Rock 'n' Roller's 12 Steps to Becoming a Golf Addict and had an epiphany. In one of the chapters Alice talks about the way to be great at anything. He explains one should mimic the greats by watching and then repeat what they do until it's natural. I immediately started to think about programming, of course. We all have programmers that we admire. For me, most of my admired heros are great writers. It's their advice that I adore. I soak their words in and then practice what they talk about. But, it's not the same as reading code. What Alice was talking about was studying what the greats do and repeating it until it's as natural as the way you breathe. Where can we find great code? I always felt my programming took a huge leap forward with Smalltalk. The reason I think that is now crystal clear: Smalltalk encourages you to read other people's code. All of the tools embrace reading code. If you don't know how to do something, you can search via the tools to find something similar and then repeat what they did. There is a plethora of patterns and good programming in any Smalltalk system. All of the GoF patterns came from Smalltalk originally.

That's fine and dandy, but what about Java, Python, Ruby, or other developers? It's just as easy as finding an open source framework you love and diving head first into the code. Study it, practice writing in that style, and repeat until it feels natural. Open source gives us opportunities that only Smalltalk and Lisp did in the past: a limitless supply of software to study in any language we choose. But, this begs the question: How do I know I'm studying good code? Alice touches on this in his book by saying that as you pass milestones in competence, you know what the next level looks like. Start with code that looks good to you now and keep practicing. For me, I strive for readability. How can I remove all noise until the code I write is nothing but the language of the problem I'm trying to solve. I'm always reading code to find new techniques for removing noise. I study code written in different languages and see how I can apply any new techniques in the language I am currently using. I've found a lot of gems by studying from functional programming and applying them to object-oriented languages.

This brings up another interesting observation. If it's good to read code and practice writing it, when should you use a new technique? For me, I always practice a new technique a lot before I apply it to production code. Normally, once a technique feels natural and I know it like the back of my hand. Most of the open source libraries I've written have been to explore an idea that I saw somewhere else to play around with it. There's nothing worse than not having mastery and immediately applying it because it was new at the time. Be patient. Read, code, repeat. Always be reading and practicing. It's the only way to get better.

Partial With Frozen Arguments In Any Position

2010-05-13T18:10:00.000-05:00

Recently, I was working on a problem where I wish I could have frozen arguments using a partial, but could not. The reason was that I needed to freeze the last argument instead of the first. Here's a simple example of what I wanted my function to behave like:

def contains_three(string):
  return '3' in string

But, I wanted to define it like so:

contains_three = functools.partial(operator.__contains__, '3')

But, partial only freezes the first arguments and you can't mix and match. I've ran into this before and I thought it would be nice to define a partial function that would allow you to freeze arguments in any position. Here's my implementation:

def custom_partial(func, *const_args, **const_kwds):
    def result(*args,**kwds):
        args_iter=iter(args)
        def convert(value):
            if value is None:
                return args_iter.next()
            else:
                return value
        to_call = map(convert, const_args)
        new_kwds = const_kwds.copy()
        new_kwds.update(kwds)
        return func(*(to_call + list(args_iter)), **new_kwds)
    return result

Is there a test? Of course, there is...

from operator import __contains__
import unittest
class Test(unittest.TestCase):
    def testContains(self):
        has_three = custom_partial(__contains__, None, '3')
        self.assertTrue(has_three('1234'))
        self.assertFalse(has_three('124'))

By looking at the test and code, the implementation I chose was to have the value of None to denote any argument I don't want to freeze. I could have created a placeholder value for it, but decided since I haven't had a need to freeze an argument with None to just leave it.

Now, I'm not excited about the implementation, but it satisfies my initial requirements. I'm going to continue to work on this to come up with something more elegant, but for now it works.

Devilishly Clever

2009-10-17T20:17:00.004-05:00

I was doing my usual research on Python when I ran across this recipe to make tail recursive calls not blow the stack in Python: Tail Call Optimization Decorator. I read through the code and thought, "Wow! This is devilishly clever!" As a thought exercise, I think it's awesome. But, it got me thinking about clever and production code. In my opinion, clever is never good or wanted in production code. It's great to learn and understand clever code though. It's a great mental workout to keep you sharp.

So, what's my point with all of this besides to say that clever is bad? The example in the above link is factorial (which as everyone knows is hated by me, but that's another story). But, the amazing thing about factorial examples are that they are dead simple, yet there's several ways to get the answer. Here's a few that I came up with:

def reg_fact(x):
    if x is 1:
        return 1
    return reg_fact(x - 1) * x

def tail_fact(x):
    def func(acc, x):
        if x is 1:
            return acc
        return func(acc * x, x - 1)
    return func(1, x)

def not_rec_fact(x):
    result = 1
    for each in range(2, x + 1):
        result *= each
    return result

def not_rec_fact_fancy(x):
    return reduce(lambda result, each: result * each, range(1, x + 1))

import operator
def not_rec_fact_super_fancy(x):
    return reduce(operator.mul, range(1, x + 1))

Each of these compute factorial. Amazingly, there's even more ways than what I listed (the math wizards in the audience know what they are). Now, think about this: Computing factorial is dead simple. What happens when we get to harder problems? Being clever can actually get in the way of making the code easy to understand. It might even kill performance. Let's think back to the devilishly clever code. The performance of making Python tail recursive is awful. Sure, it's pure and tail recursive, but in production code that is deadly. What we want is simple and to the point. It's why I generally like solutions that need less code. There's less noise to get in the way of understanding and generally can mean better performance as well.

Real world problems are hardly ever as straightforward as factorial. The balancing act comes when you drop a solution because it's not working for whatever reason. Raising and catching exceptions so you can have a tail recursive factorial is overkill. It took more code than the non-recursive version. It begs for the programmer to know their tool set and to know how to solve problems in that tool set that are straightforward. Tail recursion is powerful in languages like Haskell and Erlang. But, there's always another way of doing things that can make more sense in the language you are using. In our case, the other ways were just as easy yet more scalable for our tool set. Food for thought the next time you go down the path of clever and end up writing more noise than solution.

Freezing Objects in Python

2009-10-10T20:45:00.000-05:00

Someone stop me. I like freezing simple objects or what Eric Evans calls "Value Objects" in his excellent "Domain Driven Design" book. Python doesn't have immutable objects (ala freeze in Ruby) explicitly, but we can easily create it. Python gives us the power to get under its covers. Here's my implementation:

class ValueObject(object):
    def __setattr__(self, name, value):
        if name == 'value' and hasattr(self, 'value'):
            raise AttributeError("Can not change value attribute")
        else:
            self.__dict__[name] = value

Do you have to ask? Yes, I made a test. Here they are:

import unittest
class Test(unittest.TestCase):

    def testSimple(self):
        class Cents(ValueObject):
            def __init__(self, value):
                self.value = value
            def __str__(self):
                return str(self.value) + " cents"
        subject = Cents(5)
        self.assertEquals(5, subject.value)
        def set_value():
            subject.value = 6
        self.failUnlessRaises(AttributeError, set_value)

method_missing in Python

2009-10-05T21:40:00.000-05:00

OK, I know there is a few implementations of this knocking around on the net already, but I'm in learning mode. So, here's my implementation of Ruby's method_missing:

class PossibleMissingAttribute(object):
    def __init__(self, object, name):
        self._object = object
        self._name = name

    def __call__(self, *args, **kwargs):
        return self._object._method_missing(self._name, *args, **kwargs)
    
    def __str__(self):
        return self.__class__.__name__ + ": " + str(self._object) + "." + self._name
    
    def __getattr__(self, name):
        return None
    
    def __nonzero__(self):
        return False
    
class MethodMissingError(Exception):
    def __init__(self, object, name, *args, **kwargs):
        self.object = object
        self.name = name
        self.args = args
        self.kwargs = kwargs

    def __str__(self):
        return repr(str(self.object) + "." + self.name)

class Missing(object):
    def __getattr__(self, name):
        return PossibleMissingAttribute(self, name)
    def _method_missing(self, name, *args, **kwargs):
        raise MethodMissingError(self, name, *args, **kwargs)

Three objects and that's it! One to be a placeholder when an argument is missing. One object to represent the MethodMissingError and the last to be an abstract class to inherit from. But, you could easily just put these methods anywhere. Here's my tests:

import unittest

class TestMissing(unittest.TestCase):
    def test_missing(self):
       class TestClass(Missing):
           def __str__(self):
               return self.__class__.__name__
           def existing(self):
               return "i am"
           def _method_missing(self, name, *args, **kwargs):
               return args[0]
       self.assertEquals("am not", TestClass().missing("am not"))
       self.assertEquals("i am", TestClass().existing())
       self.assertEquals(None, TestClass().missing.something_else_missing)
       self.assertFalse(TestClass().missing)
       self.assertEquals("PossibleMissingAttribute: TestClass.missing", str(TestClass().missing))
       
    def test_exception(self):
        class TestClass(Missing):
           def __str__(self):
               return self.__class__.__name__
        self.failUnlessRaises(MethodMissingError, lambda: TestClass().missing())

You've seen my implementation. Here's another one that I found on the net: method_missing in Python

class MethodMissing(object):
    def method_missing(self, attr, *args, **kwargs):
        “”" Stub: override this function “”"
        raise AttributeError(”Missing method %s called.”%attr)

    def __getattr__(self, attr):
        def callable(*args, **kwargs):
            return self.method_missing(attr, *args, **kwargs)
        return callable

Um, this version is much shorter than mine. It gets the same job done and is more obvious of what it is doing. Simply returning a function on __getattr__ is the best way to go. It's what my PossibleArgumentMissing was doing. But, where I tried to get all fancy using __call__ to mimic a function which caused my version to be longer. I was also trying to get the argument to come back to return false in if conditions and be almost like None (again, I'm learning and was looking at what was possible). Simplest is best.

This was a fun thought exercise. I love all the hooks Python provides to allow you to get underneath the hood if need be. I will be soon doing a post on descriptors and even decorators. I find Python tends to sway heavier on the functional side of programming versus object-oriented. I'm loving the succinct, yet readable code. Too many languages get into the being so terse that they sacrifice readability or debugability (is that a word? Is now!).

Prototypes in Python

2009-09-29T18:54:00.003-05:00

I'm in love with prototype-based languages, but there only a few to play with ECMAScript (Javascript) and Self. Since I'm learning Python, I thought it would be a good experiment to implement prototypes in Python. For one thing, I would get to learn some of the meta capabilities and other advanced features. A pure thought experiment just for learning and seeing how far I could push another paradigm onto Python. Here is what I came up with:

class Prototype(object):
    def __init__(self, *args):
        self._parents = []
        for each in args:
            self._parents.append(each)
        
    def clone(self, *args):
        return self.__class__(self, *args)
    
    def __getattr__(self, name):
        for each in self._parents:
            try:
                return getattr(each, name)
            except AttributeError:
                pass
        raise AttributeError(name)

The implementation is suprisingly simple: three methods!

The first is the initialize method for new instances. It takes a list of objects that we will use as the parents of our new object. Of course, by simply calling Prototype's constructor with no arguments, we get a clean object. I made the ability to have multiple inheritance simple because of Self.

The second method is the clone method and it simply calls the constructor for another object makes itself the first parent with the rest of the arguments becoming the other parents. Nothing to it!

The last method is the real meat. It only get called by the Python engine when an attribute fails to be looked up. All I do is call each parent and if one succeeds, it returns the answer. This is a depth first search of the parent hierarchy. Simple.

And that's all we need to implement prototypes in Python. Now, I just need to explain some practical uses of this in some later blog entries.

How do I know all of this works? Here's my tests:

import unittest
class Test(unittest.TestCase):

    def testSimple(self):
        parent = Prototype()
        child = parent.clone()
        
        parent.value = 0
        self.assertEquals(0, child.value)
        child.value = 1
        
        self.assertEquals(1, child.value)
        self.assertEquals(0, parent.value)
        
        self.failUnlessRaises(AttributeError, lambda:parent.unknown)
    
    def testMultipleParents(self):
        parent1 = Prototype()
        parent2 = Prototype()
        child = parent1.clone(parent2)
        
        parent2.value = 2
        self.failUnlessRaises(AttributeError, lambda:parent1.value)
        self.assertEquals(2, child.value)

If anyone sees anything wrong in my implementation or un-Pythonic let me know. I'm still learning, but I thought it would be cool to show my progress.

Constraints in Python

2009-09-13T14:55:00.006-05:00

With every language that I learn, I pay close attention to my work flow. I take note of anything that gets in the way of getting my task accomplished. In a perfect language, I should never have to worry about the language ever. A free flow of ideas should come out. Whenever I find myself totally immersed in a problem, I keep track of what made it so. Recently, the one feature that surprised me the most was Python's forced indention. At first I thought, how nice not to use curly brackets to denote scope, but what about that white space? But, I put my best foot forward and worked on some code. I must admit that I love it now! It makes code more readable by keeping the rules consistent (you have to be or your code will have bugs). Formatting my code is now one less worry I have. I am forced to indent as I go along. This constraint is liberating in the fact that it allows me concentrate on the problem at hand and is one less thing to worry about. No more worrying about if the curly braces go on the same line or not depending on local coding standards. It makes code easier to read across Python programmers. In fact, I have yet to meet a Python program that I could not understand easily from first glance which is a rare accomplishment in other languages.

I also love the constraint about one line lambdas. I thought it was going to drive me crazy, but I have embraced completely. It keeps your lambda functions short and sweet like they really should be. But, the best side effect is that if that lambda needs to grow, you simply move it out to a named function automatically making your code more readable. Excellent.

Both of the features that I just mentioned are merely constraints that take away thinking about the language and force you to write readable code. I always like and embrace the design decisions to constrain the coder to make more maintainable code. The less I have to think about the language, the more time I spend on the problem I am trying to solve and that's the way it should be. It just amazed me that sometimes I find them in the strangest of ways. I would have never thought that forced indention or one lined lambdas would bring me so much coding pleasure.

The Dead Year

2009-09-12T07:48:00.003-05:00

This blog has been dead for a year and it's not been a lack of passion. I had some rather large life changing events to deal with. I have emerged stronger than ever before and I plan to start posting regularly here again. To let you know what to expect, I hope to do some new articles on my exploration of Python and Django. I've been enjoying my time with Python quite a bit. I also hope to spend some time digging into Google's V8 ECMAScript. It's time for me to kick this blog back into gear. Hold on!

Domain Change

2009-01-04T13:21:00.004-05:00

Update your bookmarks from blainebuxton.com to blainebuxton.net. The new blog address is: blog.blainebuxton.net. I plan on to start blogging again soon in the next year. Things are going on that I'd rather not discuss in a public forum. But, I will be back soon!

Forced Pairing

2008-10-11T18:34:00.004-05:00

Let's be honest. I'm not a big fan of "forced" pairing. I believe in active collaboration between cooperating team members. In other words, two people should pair if they want to. The energy of pairing is incredible when both partners are engaged and having fun. The code is better and so is the resultant design. It's the other side of the coin that I don't like and think the results are worse, even if the two programmers were working separately. A good pairing starts with the pair liking to work with one another. They don't have to see eye to eye, but they must enjoy the journey of working on code together. They will push and encourage each other to do better. A fun competition that will result in another problem being pushed past and the winner being a well-maintained system.

"Forced" pairing is what XP advocates and I see a huge problem with it. The reason is if the pair doesn't like or respect one another, the code quality will be on par with that of the worst of the pair. When pairs don't get along, one side will disengage. When this happens, you get none of the benefits. The team still thinks its safe from doing code reviews because they had four eyes on all code. Not so. To ignore the effects of "forced" pairing is to ignore that the team is human.