getluky.net

Earlier this year, I presented a team prototype hack at one of Yahoo!’s internal Hack Days called “World of Y!Craft”, which was an attempt at creating a platform for incentive systems for various Yahoo! properties. For the purposes of making it a hack, the idea was to make a lightweight and easy-to-integrate platform, and limit it just to Yahoo! sites.

After the Hack Day was over, however, I was approached by Ash Patel, Chief Product Officer (and a Hack Day judge) about opening up that small prototype hack, and making it so that any website could give out awards, not just Yahoo! sites.

So, a handful of people and I worked in free time, met in spare moments, and developed that initial rough prototype into a vision that took our original concept much further than we imagined. We didn’t want to just open up the ability to send awards to websites, but we also wanted to open that up to everyday people, too.

Brickhouse, the internal group at Yahoo! on the lookout for great bottom-up concepts, took a liking to the project from the start, and encouraged our investigation of the concept. Once we got the official go-ahead and backfill for me sorted out, the real fun began.

So, over the past four months, if I’ve been unresponsive, difficult to get a hold of, stressed out, or any of those things - BravoNation is why. I’ve got so much to say about the project: insights about getting things done inside a big corporate culture, motivations for crossing disciplinary interests, and BravoNation itself. In the hopes of not rambling too far in a single blog post, i’ll split it up piece by piece. Of course, the last time I promised to blog a post every day, it was during my series of SXSW writeups (especially my Understanding Avatars triplet) that formed the genesis of the BravoNation concept. I basically had to break my post-a-day promise in order to spend my time building the damn thing, so I think this is probably pretty fair that I resume with some real blogging time now that I’ve more or less completed the original thoughts with an actual product.

See Andy’s coverage for a really great overview and screenshots, or my writeup on next.yahoo.com about the site itself, or us getting ripped on at Metafilter for some good, old-fashioned fun with critics.

Big ups to the BravoNation team, too. Kevin Cheng with his mad interaction design sense, Ernie Hsiung for his community advice and frontend layout-fu, Niki Bobb for jumping into the javascript fray super fast (and getting our coffee, haha), and Ray McClure for his work getting our Builder environment set up - and all the other folks who contributed to the project within Yahoo!. There’s no way we could have gotten so far so quickly (and in such style) without everyone’s personalities and contributions. Thanks Bravoteers! And yet, there’s still so much to do…

Tech

In case you haven’t heard, I’ll be starting to work remotely from the Los Angeles area in only another week. I’ll be continuing to work for Yahoo!, as there are still plenty of projects that I want to work on. Unfortunately for me, this happens to be an extraordinarily busy time. However, i’ve got to follow my priorities, and it’s time for me to move closer to my long-distance girlfriend and try out close-distance for a while. It’s going to be hard to stay on top of everything, but knowing myself, a good challenge and probably a beneficial change of scenery.

I’ll be back pretty frequently, so hope to see all my Bay Area people all the time. Zankou Chicken, here I come!

Change, Tech, Work

Do you ever have posts sitting around in wordpress for months at a time, delayed for one reason or another? This is one of them, and after re-reading it, I think I’ll go ahead and post it, but remember that it’s kind of a warp back in time to October 2006.

Yahoo! Open Hack Day was a massive, massive success, and i’m glad to have been a part of it. Now that i’ve had a few days to rest and reflect upon my experiences, I want to discuss an observation of Bradley Horowitz’s that has stuck in my mind.

Bradley’s one of the foremost advocates for social search development here at Yahoo. He’s one of the brightest minds around, and always makes my head spin a little bit when I talk with him. You can check out his Keynote presentation here (warning, this was 4GB to download!). Around the end of minute five, Bradley says some really interesting stuff. First, he showed the famous grainy video clip of a monkey trained to perform martial arts kicks in the context of what the worst-case scenario behind user-filtered content could produce. Then he went on to show some beautiful photographs from Flickr’s Interestingness, as a way to demonstrate the better side of what can be efficiently extracted from collaborative participation. His point that these photos bubbled to the top because of implicit user activity is key; as he mentions, the aggregate human cost of photo moderation borne by the user community on Flickr dwarfs anything possible by simply paying employees to review and rate them.

Ze Frank, seen in this video speaking at TED, a design conference, seems to also think hard about the new culture of participation on the Internet. Ze often invites his viewership to participate with him on various flights of fancy, including making silly faces, creating short video clips, playing with flash toys and drawing tools, etc. During his TED presentation, and also at various times on The Show, Ze talked about the hold that various groups have on the perception of art, and how many people are able to participate and create in a new culture without being ostracized by an established hierarchy. He seems to hold that the “ugliness” which seems to permeate MySpace is, in fact, a manifestation of participation outside of the boundaries of hierarchical editorial control. Thus, his position seems to be that the silliness and ugliness of the huge amount of web “design” on myspace depends heavily on perspective. At the minimum, he seemed to believe that participation culture removes barriers to experimentation that could lead to an overthrow of traditional design aesthetics.

These perspectives seem to be at odds. On one side, Bradley appears to be advocating the harvesting of social participation to come to results that select traditionally valuable content. In other words, using New Media platforms to efficiently perform the job of the Old Media publishing empires (Kung Fu Monkeys should be buried!). On the other side is Ze, who seems to be advocating not only a disruption of Old Media distribution through mass publication, but also seems to be leading a charge to disrupt traditional aesthetic values (Kung Fu Monkeys are beautiful, and should be encouraged!).

I think it’s an interesting contrast, and I worry that i’m mischaracterizing the arguments of each.

My personal viewpoint is a bit more nuanced. I believe that one day, web platforms will also be able to efficiently cluster their users based upon interests or tastes, similar to how Flickr can cluster tags to disambiguate meaning. These clusters will probably be designed not around user surveys or self-reported demographics, but instead will most likely be extracted through efficient methods of recording implicit participation information over the long term. There may well be a cluster (which I would belong to!) of folks that do enjoy Kung Fu monkeys, and there is almost definitely a cluster that find it degrading and offensive. The difference here between traditional preference filtering and clustered audiences is similar - one requires a great deal of potentially inaccurate user feedback about their preferences, whereas the latter acts more on implicit activity, and is thus more likely to produce the desired effects.

Not only would such a model be able to try and target clusters of preferences among users, but it would also allow for users to participate in cultures in which they feel welcome from the beginning.

Tech

This is going to be the first in a series of woolgathering posts that i’ll make with my random observations about programming. I don’t expect to be really serious in them, but I’d like to get some stupid ideas out in the open, and see if any catch.

Stupid ideas are actually pretty good to aim for, especially if you follow a less structured opinion of creativity. Ideas are things that appear unformed and unstressed by the rigor of actual work, and many programmers fall into the trap of belief that ideas are somehow an end unto themselves.

Any good idea i’ve had has only truly become good after going through the process of turning it into a reality. The constraints of the real world invariably force a programmer to embrace their own fluency in programming expressiveness, as well as the realities of operating systems and system architecture.

Typically, those ideas that survive the realities of implementation tend to be those that seem stupid at first glance. Growth tends to challenge a status quo; to propose ideas that challenge a system guarantees that objections will be raised both internally in one’s mental dialogue, and externally.

If you’ve ever woken from a dream and rushed to pen and quill to write down some grand master plan, novel plotline, or software design, you’ve had one of the stupid ideas that i’m talking about. Chances are, you look at them the next morning wondering what the hell you were thinking. However, it might be worth it to take one of them and see how far you can get - that’s the type of craft that I think makes for the genesis of really crazy good stuff. If the idiotic idea survives the process of making it happen, you might have something great on your hands.

Tech

Because i’m a lazy programmer, I like things that save me time. I don’t like having to keep phpdocumentor/doxygen style code up to date with the actual code inside a function. Also, including a documentation compilation step in a build process is annoying, and phpdocumentor/doxygen don’t result in a clean data source of functionality metadata that I can produce my own documentation interfaces from.

So, I guess you could say that there are two main problems I see with a phpdocumentor/doxygen style approach. First, it’s duplication of information. Aside from the DRY (Don’t Repeat Yourself) principle, this is a step worse because you end up repeating the information at least twice, both in code and also in some separate documentation format. That’s annoying, and it will be easily skipped by programmers in search of quick fixes. Secondly, there’s no live source of trustworthy metadata data where one can get at it easily in a programmatic way, without a compilation step.

A good solution presents both a structured data source of documentation, and also avoids needless repetition of information between the code and the docs.

So, since documentation about functions and their parameters is simply metadata about the function, why not store the documentation in data structures within the function itself?

The way I started solving this problem by taking a page from a subset of a hardcore approach to programming called Design by Contract. I’d heard about it before just as a general concept while doing my time in an undergrad CECS program, but always figured that it was too serious to get into. It was really fun to recall this old foggy concept while I was deriving a pretty useful solution to the problem described above.

The entire goal is to convert function docs from these specialized comment markup formats into a machine-readable data structure inside of each function. One will need to define a standard data structure in which to store metadata about a function’s parameters. This will vary depending on the programming language’s embedded types and parameter semantics.

Once a structure is defined, then one can standardize a method of passing in a documentation request struct reference to each method, and when the method notices it, it can simply fill it with the doc metadata and skip the normal control flow for the function. It’s essentially the same as asking a function to describe itself.

Secondly, one can immediately go about enhancing the parameter data structure to include detailed information about each parameter’s type, expected inputs, etc. This information can doubly be taken advantage of by writing generalized validation routines that use this metadata about parameters. If you were going to write validation routines anyway, this saves you having to needlessly repeat that metadata within code.

Thirdly, one now not only has quick, programmatic (and realtime, not compiled) access to function definition metadata, but it’s also more or less in exact sync with the actual parameters it expects, and it also in a standardized data structure. So one can dynamically generate an entire interface for say, spelunking through an API, out of the simple presence of functions that know how to document themselves.

You do pay the price of some realtime overhead, but the very real benefits in maintainability and elegance far outweight that, in my opinion. The implementation of this general derivative concept is pretty academic if you understand all the nerdery above. The key thing to do is to just take a page from Design by Contract, and have your program know about itself, rather than hiding its metadata within invisible comments.

Tech

By far, KSCU, Santa Clara’s college radio station, is the best radio station in the Silicon Valley. It’s more or less on permadial in my car, and because of it I haven’t had to go searching for interesting variety in music. Having college age kids with diverse tastes playing and saying whatever they want makes for very few boring shows.

My favorite one is Beer Run Bobby’s 408 Oldies Show. Track after track of oldies songs that i’ve never heard before, interrupted by shouts of “KSCU! MAKIN ALL THE CHOLAS HORNY!” I’ve probably heard very few radio shows as compelling, fresh, or original as this one, and i’m talking about the greats like Joe Frank and Garth Trinidad’s shows back in the KCRW of old. Anyway, i’m listening to it right now, and I love that shit. Give it a listen Sunday nights or anytime live 103.3 in the Yay, or via their streaming internet radio.

Tech

Feature f*cking: when you work nights and weekends to get a release or product shipped, and then the first thing that some people do is deliver a negative and disheartening soliloquy about what features it lacks.

Usage in real life:

You: “I just released this new thing! Check it out!”

Them: “You know, this would be good if only it had these billion features.”, or “I can’t believe you didn’t do X, are you stupid!?”

You: “Dude, you’re totally feature f*cking my product right now.“

Please just take this at face value, as a way of a defusing a negative situation with some good old fashioned vulgarity.

However, if you really want to know the full (mostly depressing) meaning behind the phrase, read on.

The choice to launch a product signifies an inflection point where the software works and fulfills an key need far more often than it breaks, and the fundamental use cases have been addressed. Chances are, the vision for the product is already far out there and the billion features suggested may already be in mind, but the reality of shipping code forces practical constraints on everything. It’s a compromise like that of politics, the “art of the possible.”

Of course, I understand people feel the need to deliver litanies of features.

Sometimes, it’s a genuine need that hasn’t been addressed (like internationalization). In most of those cases, the features will be addressed when possible and the developers have energy, but not before. However, ranting and raving about how idiotic a developer is because they haven’t internationalized yet is NOT the proper way to go about encouraging a developer to do so.

Other times, for the tech elite, there is too much software released to actually use it at all. It’s much easier for them to “see the big picture,” where every new product is just a puzzle piece joining in assembly of a vast futurist perspective. Keeping abreast of every startup that appears is surely overwhelming for anyone, and I can understand that to some, the only way to cope is to treat the creations of techies as assemblies of features that are always disappointingly short of science fiction.

The hidden story here is that of developer happiness. No matter how many community managers are out there trying to politely thank people for negative feedback, there are always human beings behind them writing code and deciding which features they are excited to work on or not. Certainly it is true that professionalism is somewhat about doing what you need to do despite whether you want to do it. However, the attention to detail and love of a product is difficult to cultivate in a negative atmosphere. Hearing about all the features you’re lacking or missed is one pretty negative way to influence a developer’s opinion of work that they probably had to do anyway.

Tech

Jefe: We have many beautiful profiles for your birthday celebration, each one filled with little surprises!

El Guapo: How many profiles?

Jefe: Many profiles, many!

El Guapo: Jefe, would you say I have a social network of pinatas?

Jefe: A what?

El Guapo: A social network.

Jefe: Oh yes, El Guapo. You have a social network.

El Guapo: Jefe, what is a social network?

Jefe: Why, El Guapo?

El Guapo: Well, you just told me that I had a social network, and I would just like to know if you know what it means to have a social network. I would not like to think that someone would tell someone else he has a social network, and then find out that that person has no idea what it means to have a social network.

Jefe: El Guapo, I know that I, Jefe, do not have your superior intellect and education, but could it be that once again, you are angry at something else, and are looking to take it out on me?

Tech

One of the things i’ve done without any modicum of regret is the switch to buying only all-natural peanut butter. It tastes like a completely different spread, much richer in pure peanut flavor, and missing all of that orangy preservative aftertaste. Not only that, but the first few spreads from the jar are gloriously creamy and delicious.

However, many people get turned off by the oil at the top of the jar. That’s why i’m writing this post - after a few years of eating this stuff for occasional PB&J’s, i’ve got a few tips to share that are more or less obvious in hindsight.

First off, to get a good initial spread, it’s really important to thoroughly mix the peanut butter paste with the oil. I usually jab downwards with a knife to the bottom of the jar, which allows the oil to seep down into the paste. After doing that for a while, it lowers the oil level somewhat so that you can move on to jabbing downwards then pushing around the jar. Since the paste is normally pretty hard, it’s easier to do this once the oil loosens up the spread a bit. After that, it’s a simple matter of stirring.

This will give you a great jar of peanut butter, until you get to about the halfway point. You’ll notice that the oil tended to float to the top, and now you’re left with a half jar of very stiff peanut butter. The second tip is just to go out and get some run-of-the-mill peanut oil, and add it into the jar, repeating the stirring process again.

The last problem that I sometimes deal with is that i’ve sometimes got a soft bread and cold PB, which can easily tear the bread when I try to spread it evenly. This becomes an issue when you refrigerate your PB after opening, especially when getting towards the bottom of your jar. Although some oil would help, if you’re feeling lazy, here’s an easy trick. You can take your butter knife and pre-spread the PB on the sides of the jar. Just take the big clumps of PB and smooth them out along the sides of the jar as if it were a really stiff bread. The more you work with it, the more pliable it becomes.

So anyway, I hope that if you’ve been previously dissuaded from using natural peanut butter because of the oil or the stiffness, you’ll come back to it and give it another try. That’s all for this food-related post.

Food, Fun

There he is! Get him!

(Context)

Tech