Archive for June, 2010
Perfecting Imperfection
“Oh, you’re an art major?” This question makes me panic. After the fleeting moment of pride in doing what I love, that windpipe-crushing anxiety sets in. In about two seconds, one of two things will usually happen: 1) the person will follow up with a condescending “that’s fun,” and I’ll have to attempt to legitimize my career choice, or 2) I will be pressured to draw a dragon on the spot. If I cannot produce a fire-breathing beastie upon command, I risk losing many respect points. The person will give up on me and later tell someone, “oh, yea, she’s an art major now.”
It is this panic-stricken conversation that drives many young art/illustration students—and hobbyists—into a manic pursuit of photo-realistic drawing skills. We think that in order to be respected by our peers, by our professors, by the “non-creatives,” we need to be able to produce a carbon copy of a pineapple. While skills like this are incredibly useful in any art practice, young and budding creatives often lose so much in attempting to chase down realism. When we could be developing our creative process, our imaginations, our risk-taking, we are instead painstakingly copying strands of hair.
Annoyances with Android: MediaPlayer [Part 1]
For the past six months I’ve been a member of Grooveshark’s Android team. Before working on the Android project I was a Flash and Flex developer, working on the main Grooveshark web application and was moved to Android to, as I recall, help fix some of the problems with the 1.0 version of the application. Soon after joining the Android team my team member and I decided that the best way to fix 1.0 was to completely scrap it and start over. Many of the problems in the first version were because of some fundamental design decisions that did not fit well with the Android platform and to fix these problems would almost necessitate a complete rewrite either way.
User Expectations: Flash
This little gem popped up in my inbox not to long ago. VIP users of grooveshark are able to provide feedback and get to complain or file bug reports, which I randomly check (it would be a full-time job if I answered them). Most of the time it’s either feature requests, complaints that they spent about a cup of coffee’s worth of money, or in this case telling us how awesome we are.
Here’s the guts of the email (obviously removed some content for privacy):
mood: Impressed
feedback report:
Nothing too contributary to say to be honest.Just that your product is AMAZING.
It’s literally changed my entire view that every flash application is buggy and unreliable, you guys have done an absolutely stunning job. It’s so bug-less it’s suspicious!
Keep up the great work!
HTML Eats Babies and Spits Hot Fire
HTML5 is fast becoming the new hot thang that all the guys want to fuck. But, like the hot girl: she’s a raging bitch, requires a ton of maintenance, actually is just so-so in bed, and you cannot protect your investment (because she’s open, but remember she has standards). And all the boys want to have their way with her: Google is the new kid on the block, Microsoft the rich kid that wants to buy her, her best friend Mozilla has been holding her hands when time was tough, and now Apple the bad boy because he wants to prove to his gay lover that it’s really over.
Show Me More: Paging Array Collections
I have been working for a while recently on grooveshark’s newest feature: activity I needed to come up with a way for our array collections to only render or show a small set of what feeds actually have in them. [People stop listening to so much damn music.]
What is great about array collections is they handle all sorts of stuff for you, such as binding and updates. But what’s really great is the ability to differentiate a view from the underlying data, which allows you the use of filters for features like active searching on a collection.
So what I needed was a way to click show more and it would reveal the next set.
And extend and implement…
private var _pagesVisible:uint = 1;
[ChangeEvent("collectionChange")]
public function get pagesVisible():uint
{
return _pagesVisible;
}
public function set pagesVisible(value:uint):void
{
// allow it to be ready for soon to be populated data
if (value <= (pages+1)) {
_pagesVisible = value;
this.refresh();
}
}
private function feedFilter(item:Object):Boolean
{
var isIncluded:Boolean
= (source.indexOf(item) < PAGE_SIZE * pagesVisible);
hasMorePages = !isIncluded;
return (isIncluded);
}
The Openness of Flash
Thanks to Steve Jobs’ Thoughts on Flash post, there’s been a whole new flurry of posts on the subject of flash vs html5, this time with some focus on the issue of openness, since Steve made such a point to bring that up.
Some people have already pointed out that Adobe has been moving Flash to be more and more open over time, including the open screen project, contributing tamarin to Mozilla, and Flex being completely open source. That’s all well and good, but people seem to be forgetting that historically, Flash had a very good reason for being closed. If one remembers back to the early days of the web, the wild west era as I do since it was such an exciting time for a young whippersnapper like me, one must only think back to what happened to Java to realize why making Flash closed was a very smart move.