Triple Windsor

I am a pivotal tracker project

2010-02-25T21:38:00.000-08:00

Here's the project description:

This is a project for tracking myself. The things I should do, don't do, wish I did, etc.

"Bugs" are things that I don't like that I aim to change. They can be given by anyone at "failin.gs" email, or submitted in person. (nailbiting and the like)

"Chores" are things that I need to do that don't add business value directly. (unimportant meetings, cleaning the gutters)

"Features" are things that do add business value, ie. things that I enjoy, improve my skills, and benefit my relationships with others.

There are two complications to using this project management system for this that I can predict now:

One is defining deprecated features. If a bug is not really fixed, the bug ticket will be reopened or a new one will be created. If a chore is not done, it will be easy to tell (ie. do the trash). If a feature is to be deprecated, it can be coded considered a "bug." "This feature takes too many resources to support" is a valid reason to no longer support it. Ideally, there would be a "deprecation" type story, but there isn't, so "bug" will have to do. It may or may not take effort to stop supporting a feature.

The other problem is that so much of life is made of recurring tasks. One solution would be to force the pmp to conform to your life, meaning that a cron job would hit the tracker api, telling you to go to work or practice the oboe.

The alternative is to keep features small. This ensures an iterative process, and has the additional benefit of ensuring that you have a purpose in your daily life. If it doesn't add business value, you should not do it. If you can't think of a good reason to go to work in a given week, do something else. Also, it gives insight into why you took particular actions when reviewing later.

Play X on the oboe so that I can be first chair. Go to work this week so that I can get money. Go to a play to change how I think about life. Work out so that I can wear the too tight pants.

Not everything can be logged. Feeding the cat, brushing your teeth, climbing each of the stairs in a staircase, and running away from a fire would technically be considered "chores," but this is not the part of the "application" that I am working on. Basically, many recurring tasks like these can be thought of as features that are supported by the underlying architecture of a normal, conscious, sane person.

Sometimes the underlying system needs to be tweaked. This should be handled in steps also. A bug report of "Forgive everyone for everything the world for every way that they've ever wronged me or each other, so that I can regain hope" is way too big, and is focused on the underlying architecture.

Basically. It's a non-starter because you don't have access to the underlying architecture. The approach of "programming to an interface" is better. So a reasonable feature might be "Call mom to understand how I relate to people better." It's doable, finite, and approaches the problem at the interface level. If it becomes a regular thing, then you are still supporting the feature (or it has integrated itself a level deeper into your architecture). Address the feature again as "call mom," or a bug "did not call mom," or as a deprecation (bug story with "stop calling mom").

Paradigm Composition

2010-02-25T11:00:00.000-08:00

From my friend on facebook:

"Granted, I only skimmed this, but it seems like it might be right up your alley...." (link)

That is up my alley. I've been there in less significant ways. I conducted the same test type of test in the defense of my thesis on algorithmic composition. It was Bach vs. Robo Bach. I saw the tip of the iceberg of the same types uncertainty and paranoid bigotry.

The robots kick our asses on a lot of early styles. What's needed in later styles and to emulate quality "human" composers, namely breaking patterns in predefined ways, is just a variation of following a pattern, so they manage that well enough also.

But our definition of music and range of expression expanded a lot with 20th century music. Inventing new compositional paradigms (chance music, etc.) is much closer to "humanity," "creativity" etc. Robots still suck at that, and will for a good while, if not always.

What's interesting is that most humans don't give a fuck about new paradigms or expanded expression. They want a good "beat" or a nice "tune." If we stop caring about innovation, and "academics" refuse to recognize what actual innovation would mean, then all we have is "robots", "weirdos" and "composers" who lose handily to robots.

Composers will always lose to robots in "composition." If that was their only job, there would be nothing special about any of them. As it stands, I am not certain that there is anything special about current composers who strictly imitate past styles. If a "composer" is responsible not only for the generation of musical ideas, but also the creation of new compositional possibilities, then they don't lose. The trouble is that the we've got a lot of "posts" to prefix our modern by now, so anything they do in the paradigm expansion effort is going to be pretty out there.

The academics are in a tough place. They can take on the difficult challenge of expanding their definition of music to include styles which are more difficult to understand or even tolerate than CPE or pop music. Should they not do this, they are little better than the tune and beat seekers. They understand the comparatively easy and mechanical aspects of music, but they are rejecting humanity and creativity.

I don't know if or where the soul is, but it's not in the notes. Admitting this puts the emphasis in a different place. Basically, composers who did not invent a new paradigm of composition are irrelevant. All that we value is that which computers are incapable of.

Computers have largely solved the problem of automatic algorithmic composition. But if they are to solve the problem of automatic algorithmic paradigm composition (the true skill of a "composer"?), they will need a system to understand how humans break and define paradigms. This is in the works. A lot of content that is passed around online is interesting because it changes how we think about solving certain problems. So now we're down to the computer having to filter out the inane from the brilliant. Analytics are more ubiquitous than ever. Internet based products and services attempt to understand the information produced and used through them more and more by the day.

We're a ways off from the computer saying "PRODUCE NEW PARADIGMS HUMAN!" but how far, I'm not sure. "You want to be popular and make money, right?" is only slightly more subtle. I don't know if the singularity is on its way. To a large extent, I don't care. It might be horrible or benign, but if it is to come, I can't do anything anyways, so for now I say "meh."

But back to musical composition. Basically, if we don't make an effort and accept current paradigms that we may not be comfortable with(20th century, other cultures, etc.), and cultivate the creation of new ones, then we become irrelevant. But is the best way to accept old paradigms attempting to create systems to make them obsolete? I don't know. What is the best way to cultivate new paradigms of musical expression? I don't know. Should and is it possible for us to give computers insight into every aspect of our expression? I don't know.

Another question is whether what will become "human" in musical composition is limitation itself. Maybe the effort required itself becomes novel.

Or maybe the limit that we hit before computers is an ethical one. Throughout the centuries, music's dissonances have become more pronounced and intense. Is mass murder worth extracting the spectral analysis of the sounds of a knife against flesh, and seeing if over the course of many murders, it shares characteristics with the corresponding cries for help? Most musicians I know what say, "Ew. What? That's abhorrent. No." Most computers I know would say "beep boop beep 01010011100001"

So what's the lesson? Be nice to weirdos. Be accepting of things contrary to your world view, or hard to define, or ill defined, or undefined. Create new paradigms. That's our only insulation for protecting our humanity. Keep adding more "post-'s" to the post-modern. As far as I know, no computer or human has defined a human limit for where we can take that aspect of our humanity. If we keep pushing that possibly infinite limit, we have nothing to fear of analysis and automation robbing us of our humanity.

Another reason to hate fixtures

2010-02-15T22:22:00.000-08:00

Or maybe it's a reason to hate generators that create the fixtures.

I changed a migration, and all of my tests broke. I couldn't find the issue. What could possibly be calling an insert with the old column names?

A grep of the system turned up a long list of calls from the log, and because usually the relevant files are on top, I didn't scroll down, and missed the problem for an annoying little while.

If you use generators, and not fixtures, don't forget to:

git rm -rf test/fixtures/

Donkey Show

2010-02-06T22:20:00.000-08:00

As with everything I say or do, I usually put out a caveat that I am completely unqualified. Commenting on tonight's performance of the Donkey Show at the Oberon Theater is no exception. Did I know it was an adaptation of A Midsummer Night's Dream, yes. Did I know much about the original, no. Full disclosure: most of what I do know is just what I pieced together from a few episodes of Gargoyles where Puck appears.

I am sure there is a rich experience in understanding the connection between old and new, revamped and classic. I cannot offer an opinion on that front. Some people may think that would disqualify having an opinion on the show at all. I sympathize with that position, but after the performance, I am more willing to share my potentially less enlightened view point, despite being more sympathetic to would be detractors.

First, I can generalize about a few things. Shakespeare is hard for the consumer. Tonight's show was almost painfully easy for us. With reducing the script to just a handful of intense interactions, making it completely obvious what was happening, it really decreased the mental requirement for the viewing.

Besides the provided incentive to dance and drink (the second makes sense. You can make a lot more if you're selling throughout and not just at intermission). I would have felt completely comfortable using my phone for texting or calling. Even tweeting, ordering a book on Amazon, reading F my life or looking at pictures of cats would not have felt odd. Nor would I have faulted anyone else for doing this kind of thing. In a conventional theater performance, I would be the first one to give anyone the evil eye for distracting me or heaven forbid the performers.

But here, the show itself seemed to almost not care. I am not saying that it did not take effort or attention to present, but rather it just had a very incidental feel to it. They said what they had to say, and commanded attention through gestures, lighting and sound. There was no artifice in place to support their authority. The big dudes on security would prevent a complete coup, but overall, I got the impression that the performers just happened to be better organized and doing more interesting things than the other audience members.

As an aside, it would be an interesting to take this further. I'm sure someone in the last century has experimented with anarchical theater, but seeing/being in a show one or two notches more toward the king of the mountain style performance would be really amazing. Improv Everywhere has had a few skits along these lines, but I'm very interested in seeing if it becomes more standard and common.

Anyways, back to the not caring thing. It reminds me a lot of some aspects of the current internet experience. More and more services are emphasizing the ability to say something, with no guarantee that anyone will listen or care. The donkey show puts people in a big room, tells them to dance, drink, and continue with their mobile lives and carry on with their physically present friends as they wish. As aside number two, some audience members carried on with their friends quite a bit...

Ahem... So this performance was approachable, demanded little, and accepted a wild audience. I was left with a good many questions. Is this a good thing? Is this inevitable? Did the author make a call on either, or just raise the questions? Is the empty feeling of wondering if I deserve to comment the intended effect, or am I being too self-critical? Is the important thing the adaptation of the story, or is the story as (intentionally?) incidental as I am imagining? Is the audience as we knew it dead? Can we ever sit quietly through a show again? Can we read a book? Can we listen to a 3 minute song without skipping to the hook, and then to the next song? Does everything viewed as "content" command less attention than it once did? What are the benefits of this shift towards apparent egotism and consumerism? Can we protect the arts? Would we want to if we could?

In short, I don't know whether to feel complemented, insulted, ignorant or special. I don't know if the creator cares. Maybe it was all for the lulz. Anyways, as with most good experiences, it raised more questions than answers. Knowing the creator intimately and having the original memorized would only address a few of these. I think that validates my opinion.

Because of and despite not even having the attention to read the full wikipedia synopsis of the play, I sympathize with the hell in a hand basket position strongly. I realize that I'm part of the problem, if that is actually what we've got going on.

The final question it raised for me was one I had been considering for a while. At the risk of seeming even more consumptive than may already be apparent, I was wondering if there are new markets in unconventional types of theater.

From a software perspective, removing dependencies often leads to greater portability and more customizable interfaces and experiences. Generating a UML for theater might be a good start in looking for dependencies that are locking performance in a particular box.

Removing the audience's attention as a dependency allows for shows like the one I saw tonight. Remove the need for money paid by an audience, and you get the grocery store musical. Swap the money paid back in but this time by a fiance to be, and you get a proposal musical.

I had been speaking to a pro theater friend of mine about her opinions on removing some of these dependencies. To a large extent, she said that "software is a different world from the arts, at least for the time being." I don't think that she is wrong. In both cases, there are systems in place that define in radically different ways, what it means to be professional, altruistic, successful, wise, and profitable. There is no strong "open source" movement in theater, nor is it desirable for playwrights and composers to see their works torn apart and reconstituted.

Still, after tonight, I am more convinced than before that this difference is preserved as a not so comfortable tradition, and not because it is representing the current state of possibilities.

The rails creator, DHH said going too big is a mistake that a lot of people make when creating new companies. Every minor league that I know of in artistic sense of "making it" still sets the bar very high in being modeled after the majors. Get published, get noticed. Get cast, get noticed. In essence, you have giant dependencies (performing at a theater, selling a play) to resolve before you can execute (perform, see performed) or upgrade your software (performances, scripts).

I don't know why it has to be this way. Attention is easy. You ironically get more of it when you're not demanding it as in a traditional performance. I will be shocked if there isn't a large market for these types of small markets in 30 years.

At bad, this is a case of my liberal arts sensibility just saying software + music = something else cool? At worst, I reflect a terrible trend of inattention, technophilia, and shallowness that defines my peer group and younger.

At best, I had the chance to experience a type of performance that I haven't before, and more will become possible year after year until I die. And I will stop being a codger about kids today and their damn cell phones.

Thanks Donkey Show.

Metric_fu

2010-02-06T17:20:00.000-08:00

Some notes on metric_fu

It provides insight into code for new projects from a broad point of view.

It provides good guides for coding generally, or experimenting with new styles of coding. Joe Ferris from thoughtbot said that he found it a valuable experience to develop effigy "reek free."

Naturally, as with any tool, none of the metrics generators will tell you everything that you need to know or do the work for you, but there are a few benefits.

Unfortunately, the default gem install and the example rake task provided on the metric_fu docs will not give you a fully usable version. (I'm assuming this. I have not tested this process on your machine. I only know that they didn't work for me)

Solution in gist form

Follow this to fix the problems with rcov, saikuro, and reek.

Railroad gem

2010-01-07T18:30:00.000-08:00

This Gem is AWESOME. But it's also out of date in just one way that I've noticed.

application.rb was deprecated in Rails 2.X.

Comment out or delete the following two lines from the gem in
lib/railroad/controllers_diagram.rb:

files << 'app/controllers/application.rb'
require "app/controllers/application.rb"

I haven't tried it, but it looks like the railroad_xing gem takes care of this.

No way... NO WAY!

2009-12-06T22:07:00.001-08:00

Pic Related

2009-12-06T20:47:00.000-08:00

This is amazing. I'll give you money to tell me who made it. Seriously $10. 10 bucks. 10 little ones. 10 smackaroos.

My take on Awesome

2009-11-30T00:07:00.000-08:00

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

2009-11-23T08:22:00.001-08:00

Music Hack Day Boston

2009-11-22T16:26:00.000-08:00

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

2009-11-22T06:01:00.000-08:00

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

2009-11-17T07:37:00.000-08:00

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

2009-11-11T21:27:00.000-08:00

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.

Scott Chacon at Ruby Kaigi- Using git and github to develop one million times faster

2009-07-16T23:01:00.000-07:00

First presentation of the day by Scott Chacon was given in English and translated into Japanese.

Pro Git book- now at progit.org

Advantages to a DVCS

In git:
Everything is fast
Every clone is a backup
Works offline

Linux kernel was the first project to use it

Immutable, almost never removes data

Stores snapshots, not patches
Sees a commit as a full file version

Commit object is the meta data of the commit
Has a pointer to the parent

Branches- pointers to a commit

Automatically detects merge base

Object model- Branch- commits, trees, blobs

git saves the individual time because no network is needed for:
Diff calculation
file history
merging
branching
committing
etc.

Git allows for frictionless context switching, so you can try out new ideas and develop non-linearly.

Branching can be used as a patch queue system similar to "Quilt" or mercruial's "mq"

useful rebase commands-
Rebase –onto
Rebase –i

Git saves a team time because of the variety of workflows possible:
Centralized model
Integration Manager model- Sort of like github, don’t need to wait for maintainer to apply changes
Dictator/lieutenant model
Non-linear team model

It also saves time because:
Parallel development in separate repositories is possible

There is no necessary single point of failure
(You can push to a temporary repo if something goes wrong with the main repo)

Github purpose:
Share code, submit and accept patches, find projects

75% of forked projects have work contributed back

18000 projects with at least one watcher
25% of those have been contributed to.

Make it easy to put code online

Gitsourcing- take some generic code used at your company and put it online
Grit- 13 contributers, 41 commits, 1047 LOC
Jekyll- Cont 28, 1475 LOC, Commits 79
Github services andjavascript:void(0) gems- also open source

Q & A:

Why did you create git hub?
Git hosting was a pain in the ass.

Sometimes git acts weird on windows. Suggestions?
Git extensions, Tortoisegit, EGit for Eclipse

Git on Cygwin a good solution?
Some people don’t like cygwin.

(Handed out some github stickers)

Submodules?
“I don’t use submodules” “There are a lot of problems” “I use git subtree merging” “40 lines of Rake”
progit.org describes subtree/submodules

When do you merge and when do you rebase?
Rebase- Topic branches, back to the main branch
Merge- Get changes from other people
Rebase- Git-svn, use all the time

Password protect remote resource

2009-07-09T07:47:00.000-07:00

This came up the other day, and I wasn't sure how to handle it. The solution is simple, but not obvious. I'm trying to put as much code as possible in my posts, but this one is really more of a conceptual issue. The code is way simple.

Problem:

You have a link that points to a remote location, and you need to dynamically set params, which depend on login info.

Non-solution:

If the user is not logged in, send the user to the login page and then back to the page with the link, after they've logged in. This works, but asks to much of the user. They have to click the same link twice.

Solution:

What you really want is a way to wrap the remote resource with an action of your own. That index should do two things: redirect to the remote resource, and have a before filter that authorizes the user.

Gitcasts- Scott Chacon

2009-06-23T11:24:00.000-07:00

http://github.com/schacon/
Mother Futon. The source is strong with this one. But he also has a great video series on git.

http://gitcasts.com/episodes
These videos are great. They're almost good enough to be used as reference, but they're not. Why? They're videos, and 5, 10, 30 minutes is way too long to find a command that you were looking for. At the same time though, a reference of common commands (beyond the REALLY common 4 or 5) is not really anywhere that I've seen. So I'm just going to list off the less than super common commands that I learned in these videos.

For those less frequent times that you need to use git, I present the other half of the porcelain here.

Ruby Kaigi

2009-06-23T08:46:00.000-07:00

The lineup:
http://rubykaigi.org/2009/en/talks/

So I'm headed to rubykaigi in a few weeks, and I'm looking forward to meeting some of the people in the Japan ruby community, and of course, some of the more adventurous westerners. It's sure to be an interesting time, with heavy-hitters on both sides of the Pacific. Not to put down the western presenters, but it looks like the Japanese presentations will be a bit more technical, or at least low level (Yehuda Katz excepted). The most challenging talks will undoubtedly be complicated by my Japanese level.

That said, what the hell do I wear? It's a three day conference in Tokyo. It's going to be hot. Do I go with cool-biz? Are Japanese developers as sloppy as most western ones? Probably not possible. But the ruby crowd is fairly metro compared to some other communities... But the ruby crowd is fairly metro compared to some other communities, so what's it going to be? A suit? Cut off jean shorts? What to do...

Ah, phew. Three guys dressed fairly casually, this helps:
http://redhanded.hobix.com/cult/chairmanTakahashiInTaiwan.html

Weird path issues from upgrading rails

2009-06-22T11:57:00.000-07:00

This issue came up when a request to the update action was giving this error:
ActionController::MethodNotAllowed? (Only get and post requests are allowed.)

Okay. At first I thought it was an issue with the form itself or the params being passed, but then I looked at the route method in the view and saw this:

:url => members_path(current_member)

Looks okay, but it's not. At some point between Rails 2.1.0 and 2.3.2, pluralized calls changed their meaning. To debug this, I went to irb. "IRB?!?" you say? Yep. You can get to these methods by using the "app" variable.


> script/console
>> app.members_path(Member.last)
=> "/members.%23%3Cmember:0x3d8838c%3E"

There's a dot in the path? That's weird. What if I try:


>> app.member_path(Member.last)
=> "/members/721714"

Sweet, back to a normal slash, and it's smart enough to grab the id, instead of the object.

For more about tricks with the irb, see the irb mix tape post from err the blog.

Deploying a rails app to a sub uri with passenger and nginx

2009-06-21T17:59:00.000-07:00

This seems simple, but it could be a little tricky if you haven't done it before.

The documentation is a little unclear. The first thing to keep in mind is that you should not have both of the server blocks that are listed. Just add the extra lines:


     passenger_enabled on;        
     passenger_base_uri /rails;

Here are my parenthetical comments for doc code:


server {
     listen 80;

(port number, nothing new here)

server_name www.phusion.nl;

(server name. Nothing new here either)

root /websites/phusion;

(this is describing the root of the main site, not the app on the suburi)

passenger_enabled on;

(self-explanatory)

passenger_base_uri /rails;
}

(The suburi that will be tagged on at the end of the path)

And for the symlink

ln -s /webapps/mycook/public /websites/phusion/rails

This links the public directory of the webapp that you are deploying on the suburi to appear in the folder of the main site.

Other things to keep in mind:

If you're using a rails app from version 2.2.2 on, you will have to make an additional adjustment. This blog recommends opening up the ActionController and ActionView base classes for an "automatic fix" that doesn't "hardcode" the uri. This is clever, but for now I don't need that level of dynamism. Adding this line works fine for me:

config.action_controller.relative_url_root = '/myapp'

Besides this, one thing to look out for is any places in your application where you've hardcoded routes in params for url_for(link_to, etc) methods. These will not add the requisite '/myapp', causing potential breakage.

I'm sure you didn't do that though, because you know better. However, maybe you from 6 months ago didn't...

Unintuitive error

2009-06-18T11:03:00.000-07:00

Error:

>ruby script/server
config.gem: Unpacked gem mislav-will_paginate-2.3.2 in vendor/gems has no specification file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem ruby-hmac-0.3.2 in vendor/gems has no specification file. Run 'rake gems:refresh_specs' to fix this.
no such file to load -- hmac-sha1
...
(trace)
...
no such file to load -- unicode
...
(trace)

>rake gems:refresh_specs
(same as above)

Actual issue:

There is no spec for these gems because there was an attempt to rm, git rm, or svn rm them at some point which worked locally, but didn't end up working after going through the version control. A symptom of this is a version mismatch between what is in environment.rb, gem list, and /vendor/gems. Also, the gems in gem list will say that they're frozen, but they aren't. They just have hobbled directories.

Solution:
1. Try to install the gems.
2. Delete the offending gem folders in /vendor/gems
3. rake gems:install

Slicehost Setup- Part 2

2009-06-17T17:54:00.000-07:00

This article is pretty good for getting set up, but an important thing to note is this innocent seeming sentence:
"We are going to do this work as the git user so that we don't have to fiddle with permissions when we are done."

Later, when you don't have a shell as the git user, you don't have that option. So if you create a git repo later as any other user, this is the "fiddling" you need to do:

sudo chown -R git project

Here's the error:
~/projects/project (master) $ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 208 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
error: unable to create temporary sha1 filename ./objects/a7: Permission denied

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To ssh://git@IP/home/git/project/.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://git@IP/home/git/project/.git'

Screwing up git

2009-06-16T12:06:00.000-07:00

Egads. I just deleted my branch without pushing the changes. At first I thought that I might have lost a couple of days of work. But then I found this article. The first comment is particularly helpful. The docs about git log are also helpful.

Basically, what I did from this point was do a "git log -g", which allowed me to look through all of refs, whether they had associated branches or not. Next, I merged these back in one by one by their sha hashes using "git cherry-pick . Ideally, I might have done this in a new branch instead of master, but I didn't think ahead. Also, there may have been a better way to do it than going cherry-pick by cherry-pick, but there were only 10 or so, and merging smaller pieces worked out well.

Anyways, if I lose my changes like that again, my workflow will be something like this:


git log -g
git checkout -b new_branch_to_apply_cherry-pick_to
git cherry-pick  (until done, merging/committing stuff as necessary)
git push wherever
git checkout master
git pull wherever
git branch -D new_branch_to_apply_cherry-pick_to (after making damn sure things are in order)

Slicehost Setup- Part 1

2009-06-15T18:51:00.000-07:00

I'm not going to pretend that I figured out anything on my own. Here are the tutorials I used:

For setting up most things

For setting up git

Setting up Passenger/nginx

The only snag I hit was in running the git commands (remote add, clone, etc). Apparently, if you use the default port (22), you can do this:

git remote add origin git@YOUR-SLICE-IP:project

If you specified a different port, you would need to do this instead:

git remote add origin ssh://git@YOUR-SLICE-IP:PORT_NUMBER/absolute/path/to/git/project

Ones And Heroes

2009-06-14T13:30:00.000-07:00

The new blog. If you're looking for the old stuff, it's here.

In this post, I'm going to be profiling the github user who goes by semanticart, Jeffrey Chupp. He has a couple of really cool projects, and I would say is a little underrated based on his follower count. Lets go project by project:

Rack-roll. This is what led me to his profile in the first place. I was searching for rack projects and this came up. Basically, it uses rack to randomly redirect a visitor to your page to the now infamous video. This itself might be somewhat worthless, but it does show a simple rack app in action.

In contrast with that is is_paranoid. This does mass appeal as evidenced by the 176 watchers. This is similar to acts_as_paranoid, but with a few differences. That said, his Readme is a lot more informative than acts_as_paranoid's is. Another difference highlighted in the readme is "destroying is always undo-able, but deleting is not." It's pretty interesting that this package didn't get a message in this recent article.

The last project is "a simple wiki powered by sinatra" called "Hoboken." I've been really interested in microframeworks lately, but besides not knowing much about data-mapper or haml, it only has 9 watchers, compared to is_paranoid's high count. I might just wait this one out till either it gets a bit more traction or I get to know haml and dm a little better.

With this profile, we have project with a ton of watchers, and two that while not so popular, show examples of Sinatra and Rack. You can tell that he has a sense of humor and cares about what's hot, as well as what's useful.

Also, he had an awesome idea for how to design vanity page.

Thanks Japan

2009-06-14T12:08:00.000-07:00

I was in Japan for a year. Reverse culture shock has come and gone. I'm no longer horrified by the slovenly, overweight, rude, self-centered denizens of the home of the free and the brave. Although the MBTA trains are still mind-bogglingly shitty compared to even the back-woodsy* Hokuriku line which passed through Namerikawa, the town where I stayed. There was no inexplicable blue sparking from the third rail, no trash on the seats and floor, no delays due to signal problems or disabled trains, no overshooting the platform and having to back up to let out passengers, and there were no crashes due to the drivers texting. Another thing that I'm not quite over is the terrible rice here. Minute rice, Uncle Bens, and especially Rice-A-Roni are about the worst food products I can think of. Barring homelessness, I plan on having a rice cooker for the rest of my life. Scratch that, homeless or not, I want one.

Anyways, A year in Japan was long enough for me to pick up a few habits which, despite my best efforts, I cannot seem to be able to shake, even after almost a year. The first one is staring. I stare at nearly everyone I see. Because for a year my life worked like this: I know every person who isn't Asian. I know a lot of Asian people too, and I might have to work to recognize them because I meet so many new people all the time. So I'll stare at people of any race. Incidentally, if there's anyone in the greater Boston area who is bothered by a guy who is 5'11" with a shaved head (and more often than not unshaved face) staring at you, here's what I have to say: 1) That's me. 2) I'm sorry. 3) I'm working on it.

Habit two is paying for things by putting my money on the counter instead of handing it to the cashier directly. This still weirds me out. In Japan, there are always little trays that you put the money into, and take the change out of. Here, everyone just hands each other money?! With their hands?! It's so barbaric.

Habit three is slurping my food, especially noodles. In Japan, udon is meant to be slurped, as are ramen, and soba. Spaghetti is gray territory. That said, I've seen Japanese people slurp pizza and sushi also. Maybe it's just a cultural difference between tongue and slurp to get food that didn't quite make it in. Napkin is probably more polite in both cases, but as far as regular eating, here are some tough situations:
Spaghetti with whiteys- This one is obviously a bite, let fall sometimes, use napkin, and maybe a little tongue when needed situation. Doesn't always happen. Sometimes I just gotta get my slurp on, which is wrong. No slurping.
Udon with whiteys, Japanese restaurant in America- Everyone else is slurping, so I guess it's ok here, but all my friends will think I'm weird. No slurping.
Udon with Japanese, Japanese restaurant in America- This one's complicated. I guess it depends on their Americanization level.

Habit four is bowing. I can't help it. Especially when I pay for something or say goodbye to someone. It's slight, but not small enough to be a normal American head-nod.

Habit five started innocently enough. Japanese people at a certain point in their history decided to adopt the handwave, but at handshake distance. Me and my friends in Japan thought it was really funny. So we'd all do that when saying goodbye. And now, well, it's just like what your mother said about your face staying that way if you make a face too much. I wave to people from three feet away, and I look like a complete asshole.

Anyways, thanks Japan for making me cripplingly awkward for God knows how long.

*Japan's backwoodsy areas have no trains, and barely any people. Somewhere in Japanese law there seems to be a rule that nobody can live anywhere close to areas that have an abundance of trees. They're reserved for camp-grounds and tourist attractions. The Hokuriku region is "back-woodsy" in the sense that it's full of small towns, and brimming with parochialism. The fact that it is on the opposite coast of Tokyo is keenly felt, and despite the abundance of concrete, and lack of any natural surroundings to speak of, it is impossible to forget that you are in "uranihon" (裏に本), the "back side" of Japan.