RWilson

That's a great link, I had not seen that article before. Though, in practice,the actual framerate to vary from the specified by much more than the -10 / +5 fps that he lists.

His final sentences might be relevant to this topic:

On high CPU load we might actually cut [the max framerate] into half, e.g. 30 frames/sec. OS X already does this in certain conditions.

Wish he had expanded on that a little more. Any idea what conditions cause OS X to halve the framerate?

I would really, really love to know the answer to this too.

It's hard to describe my surprise that my 5-year-old PC, with a low power 1.6Ghz CPU, can easily breach 100fps while playing JamLegend, and my 9-month old, dual-core 2.66Ghz MacBook Pro can barely squeak out 40fps.

Speaking of framerate in Flash, setting the framerate on a particular SWF does not actually make the SWF run at that framerate, even if the client machine can run at that framerate. Rather, the framerate seems to be more a measure of CPU resources dedicated to running the SWF.

For example, back to JamLegend: My MBP can run JamLegend at 40fps, but not if the framerate is set to 40fps. If it's set to 40fps, I'll get 20. It it's set to 60fps, I'll get 30. In order to get 40fps, the framerate has to be set to 100. Meanwhile, on my old XP machine, setting it to 40 gets 40, 60->60, and 100->100.

So, very good question, why is it that Flash performance is so different on OS X than Windows?

Criticizing Dustin for an incident regarding which you have not sought his side is very poor form. Similarly, criticizing his argument ad hominem highlights only your own bias without refuting or examining any of his points.

To quote John Stewart Mill here, "He who knows only his own side of the case, knows little of that. His reasons may be good, and no one may have been able to refute them. But if he is equally unable to refute the reasons on the opposite side; if he does not so much as know what they are, he has no ground for preferring either opinion."

Nice! That's great to hear, since it's always perplexing when native code ISN'T the fastest... Kind of makes you have to ask, "If there is a better way, why isn't that the native way?" But, for Tamarin, that question will be moot.

Cuil made it on in the special category for the "Failure to Launch" award as did MobileMe.

Hmmm... a larger version of the most annoying kind of flash ad on the web. I want those 15 seconds of my life back.

This is something we looked at for a while when starting out, and even posted on HN to ask about (http://news.ycombinator.com/item?id=203864). In the end, we chose Flex because it seemed like we could get good enough performance while enjoying the benefits of quicker development. We mostly use pure AS3, but we saved some time with a few components. Hopefully someday we can strip those out and cut the Flex framework overhead.

But yes, Flash player has an unpredictably crappy internal clock and performance varies significantly based on the browser and OS, so synchronizing the notes with the music has been a challenge. For the most part, I think we've done a fairly good job compared to the existing players. We scale intense tasks dynamically in game but there is definitely room to improve (custom a/v delay, controller delay, really-crappy-performance mode, etc).

It's not a programming book but... "The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal"

It's an awesome book about the history of computing, human-computer interaction, and all sorts of things you're familiar with but may never have known where they came from or how they evolved.

http://www.amazon.com/Dream-Machine-Licklider-Revolution-Com...

Vote for JamLegend too! Gotta love the underdog in the music category...

It would be nice if all the TechCrunch trolls could go back to TechCrunch.

Those links are all to companies who have the puzzle sent in with the application, not given in the interview. Also, on that note, Joel Spolsky advises (http://www.joelonsoftware.com/articles/SortingResumes.html) that this will reduce the number of applicants you get, but not increase the quality. The reasoning is that, since great programmers will have options, including the problems will be equally likely to dissuade good candidates and bad candidates from applying and what you're left with will be desperate candidates that are willing to jump through any hoop. Perhaps just one take. Anybody that has used the with-application puzzles, how did they do for you?

As for in-interview questions, Joel also had some good advice (http://www.joelonsoftware.com/articles/GuerrillaInterviewing...), use two types of questions: (1) softballs, and (2) complex questions requiring a grasp of multiple layers of abstraction, like C pointers or recursion. With type 1, he recommends caring more about how quickly they do it than if they eventually get it right. For type 2, the goal is more to see how they think, and you're free to help them along with the trivia that is easy to forget but easy to find on Google in 15 seconds.

By the way, at the bottom of that, I discussed a few thoughts I had on how to tackle the issue of triggering concurrent cache refreshes in a clustered environment. Would appreciate feedback on (1) those ideas, if you've tried any or anything similar, and (2) additional possibilities I missed.

You're technically right. For reference, look and feel fall under "trade dress" [http://www.ivanhoffman.com/tradedress.html]. In brief, the relevant case law is:

"To recover for trade dress infringement ... a plaintiff must prove by a preponderance of the evidence: (1) that its trade dress has obtained “secondary meaning” in the marketplace; (2) that the trade dress of the two competing products is confusingly similar; and (3) that the appropriated features of the trade dress are primarily nonfunctional."

Continuing ...

"Strength of ... trade dress depends upon the interplay of two elements, the uniqueness of the trade dress and the investment in imbuing a trade dress with secondary meaning."

... which makes trade dress difficult to prove, even to only a preponderance of the evidence.

I agree. The idea is great, and would save some dev time and learning about various communication streams, but it's not affordable.

Were we to switch to MessagePub just for the e-mails we send from JamLegend for friend requests, challenges, referrals, new songs, etc, our communication costs would increase by 600%. For reference, we use sent.com at a price of $25 for 6 months, which lets us send up to 2K messages/hour. Paying $2500/month would be a vertical hike from $4.16/month. I know your pricing page lists that custom solutions are available for high volume, but I can't imagine that the price would come down enough to be reasonable.

So, I think the idea of one service to hit your users on whatever communication medium they like is cool, but the pricing isn't affordable at scale. Think about it like this: if somebody else had built MessagePub, could you afford to have ShareMeme use it?

It makes more sense for products that don't send a lot of messages, and need to be able to send to all sorts of devices. One example that comes to mind is for server monitoring: if a server is misbehaving, you want to be notified, and if you don't see the first message, the message needs to escalate quickly on multiple mediums, perhaps to other people.

some of those are obvious, but the Ad Planner was an interesting trick...

There's a subtle difference here that isn't being highlighted: Releasing often does not mean giving in to feature creep. Feature creep and lack of coherent direction was the failure, not release timing nor release frequency.

Releasing often is about gauging user feedback to evolve features, seeing how user's really use things and discovering what nobody foresaw. That, however, does not mean that you're supposed to give in to each and every feedback request from users. Most of all, releasing early does not absolve you of the responsibility to consider the effect the feature will have, in either its requested form or your translation thereof, on the direction of your product.

To expand on that, your users will have ideas for features that would take your product in a direction that you do not want to go. Releasing often does not mean that you have to go that way. It's perfectly fine to say, "You know what, we're not going to build that," and still keep releasing changes every couple days. Users provide feedback, but ultimately, you control the direction of the product.

So the question becomes: (1) Do you embark on this journey as a ship, taken by the winds and currents of user feedback wherever they may roam? Or, (2) Do you get out some oars and influence your path.

Remember, it was your vision that caused you to start this. You shouldn't discount that just because users want things you're not providing. That's not to say that you shouldn't listen to user feedback, just that you have to decide upon your philosophy and either stand firm with your product direction, be comfortable with having the direction swept out from under you when the site begins to grow, or drift somewhere in between.

It's nice to see such a rational comparison of languages. So often, I see blogs written by people who only understand one language and blindly compare its' elegant solutions to arcane versions in another language because they don't understand the other enough to recognize their blunder. This post, on the other hand, is written by somebody with a strong understanding of both languages and how to approach the same problem with two different hats.

So, rather than another "Lisp rocks, Java sucks" post, we get to read a intellectually sound argument. Refreshing.

Lower your burn, move to Detroit and buy a house for 2-3 months SF rent.

Ideally we should use the right tool for the job, but sometimes time constraints pressure us to try to use the tool we know best for any job, and the next thing you know we're using a wrench to twist a nail into the wall. We might get it in there, but it's ugly, crooked, and likely to fall apart with little weight, and all because we didn't have, or didn't want to take, the time to learn to use a hammer.

To be fair, one equally shouldn't try to program in Java with python on the brain, it's going to turn out just as hideous and slow, and the developer will probably be more furious at the number of recompilations caused because approach the problem with the right mindset.

flickr is a photo sharing site, that also supports video. Facebook is a social network that supports video. Both are inherently made up of many-to-many personal relations without much direct focus. Neither of those, though, allows you to create a video site dedicated solely to a community of you-to-many. So, first, the ability to upload a video and share it with your friends is not equivalent to running your own video site. The two have different value propositions to you, the user.

Secondly, there is a business/blog play that you overlooked. There is a reason TechCrunch didn't build Elevator pitches as a Facebook Group, or on flickr, and it's the same reason we (I'm one of the founders of JamLegend) didn't waste our time using a social network as a video site. The point of the mockup video sites (for Techcrunch Elevator Pitches, VentureBeat, and Mashable), is to show that the video services of all of those businesses could have been built on Fliggo, quickly and easily, and at what I presume to be a reduced cost. The hack solution is wordpress + YouTube, but that's not very elegant, lacks a certain amount of professionalism, and can be difficult to monetize effectively. So, to have a more professional solution before Fliggo, you had to develop your video site in-house, outsource/contract/etc, or use something like Brightcove. Now that there is Fliggo, the process became as easy as point-and-click, while still allowing a full array of customization (as we took full advantage of).

Hmm... not sure what justified the -1 on this. Perhaps that in some languages if (a) can be used as a shortcut for if (a != null), where a is an object and not a boolean. So, as a correction to my previous comment. If (typeof a == "Boolean" || a instanceof boolean), I still stand by reducing redundancy, but if a is an object, then fine, if (a) return true;

While I wasn't assuming that, good catch that I neglected to mention otherwise. That said, we don't have a measure of the positive externalities to ones life, whereas we do have karma.

So, fully recognizing that there is more to HN than earning karma, I'm still intrigued by what these graphs might look like.

You reached these Keeeeds!

agreed, if (a) then just return a;

if (a) { return true; } is just as redundant as an if (a == true) statement.