No way... NO WAY!

Pic Related

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.