My take on Awesome

I'd been meaning to post about the exciting stuff going on with the awesome foundation, but I hadn't had the chance. We have now had 4 funding cycles (collectively giving away $4000 to awesomeness) and seen over 700 awesome grant applications. The most awesome of all lately, is that we've expanded to include a Providence chapter.

But enough gushing...

The other day, a friend of mine asked me what makes a good proposal to the awesome foundation. For the most part, I can only speak for myself. That said, I have seen a few project cycles now, so I have insight into what we collectively tend to ignore, like, and ultimately fund. I do not have any insight into our Providence branch, but imagine they will share some of these qualities. Also, our Boston chapter has not always had the same focus on a group or individual level every month, but there seem to be some consistencies. Here is a rough idea of what I told him.

Everybody in the group has a slightly different take on awesome, but I would say that everyone universally likes the following traits in a project/application:

1. Awesome quotient- This is almost like quirkiness, but a little more productive. It is a little like creativity, but not so wishy-washy. Although it shares some common features with "social good" it is a bit of a diversion. We are definitely interested in social good, but we're looking for awesomeness. There are a few reasons for this, but it's largely about where there currently are and aren't sources of funding.

Social good says "stop hunger." Awesome says "I will create a robot who can work at a soup kitchen. This may not replace a volunteer, but will attract a new crowd of volunteers." (I made this up, so it's not nearly as awesome as actual submissions)

Talk about how awesome the solution is as well as the impact. The awesomeness quotient is important because it lets you do more with less money. If you look at our funding history, it might provide some insight. The fun theory people also have the right idea.

2. History of achievement/Feasibility- "I have built a robot who can bartend. I know how to modify this to serve soup. See pictures here (link)"

3. Short application- We're seeing over a hundred applications every month. It is awesome when they're just a paragraph or two with contact info links. Ironically, I think that we're more likely to read/watch/listen to the off-app content when the pitch is short and engaging.

4. What is the money for- Why do you need the $1000? Break down the cost. If you don't need it or don't explain why you do, then it seems a little strange to fund you.

5. Our impact- We don't want to be a drop in the bucket among a much larger pool of funding. It's a much different proposition when we will make or break an effort.

6. Timeframe- Given that we fund once per month, it's awesome to know that we'll see results before the next round.

7. Location- Where are you? It would be nice to see the project and hang out.

As I said, this is not part of any official mandate. I myself may drop any of points given the right circumstances. We have and will continue to fund awesome things that run contrary to any or all of these principles. None of these are requirements. But they all have factored into past discussions of funding.

Looking forward to seeing your submissions.

A little nerd fanfare to brighten up my Monday

Music Hack Day Boston

First off. I have to make this disclaimer. Echonest is bad ass. Last fm is bad ass. Noteflight is bad ass. Sound cloud is fairly bad ass. A lot of other companies represented were bad ass as well. They are solving interesting and difficult problems. After seeing some of the demos, however, I'm a bit uneasy.

Remixing, discovering, listening, sharing, etc. are all important. There is a great opportunity when you make something easy to do for others through an API. For one, it becomes very hard to say, for example, this interface sucks or they have too many (or few) features, I'm going to rebuild the entire system to compete with them and their shitty product. It gives you insulation against competition. Second, it gives you an awareness of where your main product could be expanded. Third, the world gets more ways to benefit from your hard work. Fourth, it's nice to have other businesses dependent on your success for their success. Lastly, it's just good karma.

The proliferation of Web API's has been great for entertainment. It's even great for some businesses. Some people are getting paid via google ads, and others are offering social media consultancy. I am not claiming that this is a house of cards or that these companies do not offer anything to the world.

When it comes to music though, I found it striking that there was so little offered in the way of creation. The emphasis seemed to be on consumption, or on making consumption easier for others. Remixing is not excepted in this. If it is automatic, it sounds like shit. Always. Yes, you can use the echonest API to find the key center of a section. Yes, you can use another tool to mix samples of other songs, and form a reasonable progression out of it. It is not complete. It sounds cheap. If anything, this is the genesis of something else, but it cannot stand alone.

It's made easy by today's tools. Only an idiot would consider it as anything more than a curiosity. In I don't know, 20? lines of code, you get some sound. Anyone else who makes the smallest bit of effort can do the same. That is an amazing accomplishment for Echonest. Not for you. Don't take the credit. It's insulting to everyone who has made an effort. You're not contributing anything of value, just consuming in a different way.

Please keep in mind that I'm not saying that the demos were bad. They used the technologies provided and pulled a lot together in a couple of days. It just felt a little redundant that most projects were focused on consumption. Given the wealth of legal and illegal solutions for end users looking to find/listen to/share/experience music, it was a little underwhelming to hear about more solutions to seemingly solved problems. After all, when a user has years of music, listening to 7 seconds of a song just to hear the beginning or the hook before moving on, it's hard to imagine that these solutions are good for an audience that already over-consumes and under-appreciates. Naturally, this isn't everyone, but it's a sizable demographic that is likely to only become more gluttonous when music is treated as data.

Two classic and difficult music tech problems were attempted for the demos. Automatic composition and automatic transcription. The end products were cool, but incomplete. The composition, which aimed to use Bach fugues as training data for some type of machine learning was abandoned because it was harder than expected. The transcription programs were cool for a start, but both were far from providing a transcription that resembled the audio source. In any case, I actually found these attempts more impressive than some of the easy win projects.

Also impressive was Jimmy Rodgers. His circuit bending workshop was great. He was very attentive and respectful of the hardware beginners, and going home with some toys that I screwed with really added an exclamation point to my time at musichackday.

On a side note, I considered a career as a video game composer when I was in college. I joined G.A.N.G. and participated in the community. From what I read, I gathered that the odds were against me. Programmers and producers got paid more. The talent pool was huge. It was hard to break into it. Composers also have to be effects engineers. Audio budgets were always shitty in games... ok. Maybe I could have dealt with all of that. But the most damning thing to my potential career was that licensing was taking over. In other words, game companies are also increasingly taking the easy way out. I actually didn't make it out of the first town in FFXII. The musical loop was too short and unimaginative. The idea of adaptive audio has been around for a long time. If Square-Enix has that little regard for music innovation, they don't care about my patronage.

Anyways, maybe I'm being a little too hard on the world. I guess maybe I expected a little more out of the demos. Maybe it's just the spirit of consumption that underpinned the conference getting to me. Still, I'm left wondering. Does anyone still want to do the hard stuff? Play instruments? No, not Rock Band instruments. Actual instruments. Does anyone want to write music, instead of mixing it?

After my Japanese test in early December, I'm going to make a little more effort with composition. And with Sibelius (the composition software I used in college) being kind of a big ticket item, I think that Noteflight and I are going to become really good friends.

Code Kata

This has been bothering me for a while. I don't like to rant without a solution though. I have one now, so a small rant, and then a solution:

Code Kata, as they're described by Dave Thomas, are NOT really kata in any traditional usage of the term. He sums it up fairly accurately:

Kata (Japanese for form or pattern) are an exercise where the novice repeatedly tries to emulate a master. In karate, these kata are a sequence of basic moves (kicks, blocks, punches, and so on), strung together in a way that makes sense. You’ll never be attacked in such a way that you could repeat a kata to defend yourself: that isn’t the idea. Instead the idea is to practice the feel and to internalize the moves. (Interestingly, kata are not just used in the martial arts. Calligraphers also learn using kata, copying their masters’ brush strokes.)

Yep. That's the idea PrgDave. A series of repeated moves to get you ready for a potential attack. Just to internalize the motions.

So how has PragDave applied them? Code Kata One. Does this resemble what he described? Is this a series of movements that you would practice over and over to internalize the response to a situation? No, this is asking for you to give your response to a situation. This is the equivalent of saying "How would you handle a straight punch to your coccyx?"

If we REALLY try to keep the martial arts/code study metaphor intact, we have a few different levels to look at:

1. Physics- Basic F=M*A. Knowing the forces at work to land a successful hit or in the case of computers, knowing the cs stuff(algorithms, data structures, time complexity, etc.). A bag that tells you your killing power and benchmarking tools are good, but they won't tell you why. This is essential to being good at either. Naturally, a good fighter doesn't have to be a physicist. She can rely on the integrated experience of past teachers to give her the expertise. A good programmer should know at least enough to look it up, but depending on the problem, a lot of the hard questions are abstracted away in the environment (ie. garbage collection is rarely something you need to think about when developing a basic Rails app). More on this in a later post.

2. Biology- Do you have both arms and legs? Are you fat? Do you have a trick knee? Do you have all of the packages installed? Which implementation are you using? Are you on Windows?(I won't say which one this is)

Ok. So as far as applications:

3. Fight- A feature to implement, a bug to fix. This may be a grouped collection of bugs and features to deal with.

4. War- Your job. A stream of fights which may or may not be easy.

Practice:

5. Pair work- Ruby quiz, PragDave's code kata. This is when you have a problem, and have to figure out the solution. This is a mock fight when you know the attacks, and have to invent the response. I'm not suggesting that this isn't an essential part of training, but it is not the same as practicing "code kata."

6. Kata- Practicing the moves that you will need to do automatically. Basically, this is what you to cache in your brain as opposed to having to look up the API. So... what does a kata look like? public static void main {
}
It looks like that. That is the first thing I learned about java. I didn't know what it was in response to, or what it was actually doing. I just knew that I had to memorize this for usage in nearly every fight I would encounter.

A suggested kata for ruby would be something that practices basic motions that you're likely to forget but need to use frequently. These are naturally going to be somewhat specific to a person, but to develop your own, keep track of what you look up. If you find yourself looking up the same thing very often, work out an exercise that uses that code. Alternatively, develop kata that use features that you don't use, but would be useful if you did.

Ruby's hash, array, and string classes are good places to start. contains, in_array, include and all of the question mark variants are all possibilities to find out whether an array contains the element. Which one is it? What does it return? Are there hash and string variants? Are there other methods that cover most use cases better than include?

But isn't this what "tutorials" and "recipes" are for? Yes. It is for the most part. However, most "recipes" are a little too coarsely grained. Most "tutorials" cover only the basics. Neither emphasize caching your knowledge to prevent expensive lookups to google, wikipedia, the reference itself(recipe book or blog post) or a person later on.

What should and shouldn't be cached/known is a topic for another post.

Musical Improv Class

I recently took an 8 week musical improvisation class from Improv Boston. Everyone else had a strong improv background, so it was pretty intense. The teacher, Adam Brooks, dropped a lot of science. Also, you get 5 free passes to see Improv Boston shows. Classmates were really friendly and very involved in other aspects of the theater. In short, I would recommend the class.

The class was structured around a few different activities:

Warmups:

Vocal Exercises- some basic warmups/tongue twisters. Difficult one: "The blue black bug bled blue black blood, the other blue bug bled brown" sung to the tune of the battle hymn of the republic.

Shay Shay Coolay- This warmup was pretty basic. Stand in a circle. One person says "shay shay coolay" with a motion. Everyone repeats. Then the same person does a motion with some other noise. Everyone repeats. Another motion/sound. Repeat. Count off. Next person's turn.

Up my butt- Rhyming practice. Caller: "I've got a *" Everyone: "up my butt." Next caller: "I've got a (something that rhymes with *)" Everyone: "up my butt." And so on.

Signals(not sure on the name)- Probably my favorite of the warm ups. You point to someone and say a word, they do the same to someone else, saying a word that is related and form a category. This goes on till everyone has been pointed at and the last points back to the first person. After the first signal is sent through a few times, a new signal, category, and path are added from a different origin. It gets complicated.

Hardcore stuff:

IDS(Irish Drinking Song)- Given a topic, create 2 rhyming couplets.

Other forms:

Tagline Songs- AABA Pattern. All sections were 4 lines. The A's have the tagline as the 4th line. B is a 2 rhyming couplets without the tag, like the IDS.

Verse Chorus- Alternates between chorus and verse starting on chorus. The 3rd line of the chorus changes every time, but the rest stays the same.

Application of forms:

Duets/Solos- These were typically done with the tagline song pattern.

Full Cast- Verse chorus pattern with one person setting the chorus and always singing the variable third line of it (the rest of the cast sings 1,2,4) alternating with verses which are mini solos.

Mini Musicals- Combo of the first two bits with a persistent narrative throughout.

Generating content:

We worked on duets from a lounge singer perspective from just a suggested word. We also worked on finding a song through a scene. The two cues for the song to begin in the latter were when one person expressed a strong urge for something or when a clear theme or especially tag line was presented and landed on by the performers.

We didn't get too much into a taxonomy of musical numbers, but it was helpful that Adam pointed out the "I wish/I want" type as an easy target for solos.

Lessons Learned

Improv is a skill that takes work. I sucked going in, and I sucked a little less/knew why I sucked afterward. Basically, I would say that I'm in the conscious incompetence phase as far as the musical side of improv, and in the unconscious incompetence phase as far as normal improv ability. Damn if I had any trouble harmonizing in the groups though :)

Another lesson learned- Jumping in is hard. Start a scene or a song with a strong choice. Stick with it and pay attention. With so many great players around it was easy to play off of them, but really tough to make a strong competitive choice of my own. I think that I worried a little too much that it wouldn't be as convincing or as important, so I might as well wait for them to hand me something.

This was wrong in two ways.

First off, it's unfair to make the other person do all the work in setting up the story. Secondly, 9 times out of 10, the two players will end up creating somewhat inconsistent situations. A lot of the fun is untangling the mess.

The main problem with it was that the scenes had less conflict and interest than scenes where people made strong and most likely inconsistent choices. I found myself playing the role of the guy who is interested in something or the guy who isn't quite sure. Those are not interesting characters.

Also, I had a brief existential contemplation after the last class when I wondered... Is that me? Am I always this passive, just waiting to see what reality hands me? Do I go through life with nothing to offer anyone? And then I thought, nope, I'm just not that good at improv.

It's an interesting thing to learn about. I'd to revisit it at some point, but next I'd like to try the stand up comedy class.

Sqlite Gotchas

I am in the process of writing a twitter wrapper wrapper. That is to say, something that can, given a small list of params, perform a giant twitter search for you, taking care of the iterations.

I'm using a sqlite db for the testing db. Coming from rails, it takes a bit of getting used to. That said, it works really well for the most part. It saves a lot of complexity at the low low cost of maintaining two schemas. It's not so bad. I have one dev/production schema set up by migrations, and a leaner version that is loaded by the test suite. So far, I can find only a couple of things to look out for.

1. Not the prettiest or clearest errors. This one comes to mind:

ActiveRecord::StatementInvalid: SQLite3::SQLException: SQL logic error or missing database

If you're thinking "that could mean damn near anything!" then you are right.

2. On some of the larger postgres tables, using this in the migration allowed for a high number of ids:

change_column :confidences, :id, :integer, :limit => 8 

This works great for postgres. For some reason, when you do this with sqlite, without warning, your ids will not save, which means you will have to find based on.... well, good luck.

Fortunately, my test data has no reason to be large enough to need a bigint. Problem solved.

For a gem-sized project, this setup has worked pretty well. I'll be rolling open sourcing it in a couple of weeks.

For a good reference on when to use sqlite, I'd check this out.