Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Broke Justin.tv

blog.socialcam.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: I Broke Justin.tv

#31

Post by 9999 »

wildmXranat wrote: post #18
9999 wrote: post #8

Earlier quoted context omitted.

You're assuming that they actually have real control over player performance on your particular hardware setup, when in fact they have almost no control over it. Go ask Adobe and Apple why flash video (especially anything that isn't h.264) playback occasionally (definitely if you're talking about pre-10.6) sucks on OS X.

Why is your reading comprehension so bad? I said other sites play HD streams very well. I've got a high end Macbook air 10.6 for your information, but they already should know that since I asked their support about it and failed to get a response.

Please give me examples of these other sites that take heterogeneous user generated live streams of varying codecs, profiles, etc. that are being delivered to the flash player that perform much better than Justin on your Macbook.

I think you do not understand the underlying technology well enough to be pointing fingers at Justin's player.

Re: I Broke Justin.tv

#32

Post by aaronblohowiak »

abstractbill wrote: post #15
emmett wrote: post #11

Earlier quoted context omitted.

We're not the wild west we once were, but neither are we a paragon of testing. When I started Justin.tv, I had 1.5 years of software development experience, never on a team larger than 2 developers; I've now been at it for almost 7 years and yeah I don't think I'd do everything the same from the beginning. Here are some things we now do at Justin.tv because of experiences like the one you mentioned: - Everything gets…

sorry Bill, they're really quite helpful in the right circumstance I don't think I've ever claimed they're never useful ;) But I do still believe that, out of the things you listed, they have the lowest utility for the amount of effort involved. Personally, I would do fully-automated deploy and rollback first, closely followed by monitoring, then code reviews, and then if problems were still slipping through the net…

Code review has larger organizational benefits like reducing the "bus factor."

Re: I Broke Justin.tv

#33

Post by timr »

jdeseno wrote: post #30
timr wrote: post #12

Earlier quoted context omitted.

Just to be clear: Bill's opinion on this isn't universally shared at JTV. When you're two guys in a garage, unit tests probably slow you down. But at some point, they begin to dramatically speed things up -- working on someone other person's code becomes orders of magnitude easier when there's a comprehensive test suite to validate your changes. The problem is that at some point between first employee and a dozen (or…

Having been at JTV, looking back it almost seems insane to try to do as much work as we we're without good coverage. If it matters, it should get a test. I think a lot of people also see tests as slowing things down but, they also provide a lot of value in documenting intentions, make upgrades easier, etc.

It also matters a lot more when you're hiring relatively new/inexperienced people, and throwing them in the deep end. I disagree with Bill mostly because I see the purpose of testing differently than he: the point is not to catch All Of The Bugs; the point is to make it easier to confidently work on code that you didn't write.

There's a lot of counter-intuitive stuff that happens in production code for a big website, and it's not totally fair to throw inexperienced people at it without at least some safety belts in place.

Re: I Broke Justin.tv

#34

Post by abstractbill »

timr wrote: post #33
jdeseno wrote: post #30

Earlier quoted context omitted.

Having been at JTV, looking back it almost seems insane to try to do as much work as we we're without good coverage. If it matters, it should get a test. I think a lot of people also see tests as slowing things down but, they also provide a lot of value in documenting intentions, make upgrades easier, etc.

It also matters a lot more when you're hiring relatively new/inexperienced people, and throwing them in the deep end. I disagree with Bill mostly because I see the purpose of testing differently than he: the point is not to catch All Of The Bugs; the point is to make it easier to confidently work on code that you didn't write. There's a lot of counter-intuitive stuff that happens in production code for a big website,…

Yeah, this is a fair point.

I think, as much as I dislike pair-programming overall, that's something I would prefer to use as a safety belt here (because it's only expensive for the period during which a new employee is still learning). Pair programming hasn't ever been tried at justin.tv either though, as far as I recall. I'm probably going to give it a try at ZeroCater for new engineers actually (we're hiring!).

Re: I Broke Justin.tv

#35

Post by dsl »

emmett wrote: post #28
wildmXranat wrote: post #26

Earlier quoted context omitted.

I subscribed to the NASL stream and paid $25 and suffered a similar awful experience related to video quality. Any questions on how to fix it on their chat was met with anger from mods, with answers not to spam even though I asked once or twice the most, and now my comments are getting downvoted in this thread. I really liked Justin.tv and had intended on paying for more streams, but it seems like a big joke to me as…

We are always working really hard on quality of service for video. For example, note the button we have added to report video problems. The biggest problem here is measuring quality - none of the obvious metrics really correlate. That said, sorry you had a bad experience and we will strive to make sure in the future you have a good one.

Go to YouTube and play a video. Right click and hit "Show Video Info." Right click again and do "Copy Debug Info."

The top left of the video and your clipboard should give you a pretty good idea of the metrics you should be tracking.

Re: I Broke Justin.tv

#36

Post by abstractbill »

dsl wrote: post #35
emmett wrote: post #28

Earlier quoted context omitted.

We are always working really hard on quality of service for video. For example, note the button we have added to report video problems. The biggest problem here is measuring quality - none of the obvious metrics really correlate. That said, sorry you had a bad experience and we will strive to make sure in the future you have a good one.

Go to YouTube and play a video. Right click and hit "Show Video Info." Right click again and do "Copy Debug Info." The top left of the video and your clipboard should give you a pretty good idea of the metrics you should be tracking.

I would be very surprised if the most appropriate metrics were the same for static and live video.

Re: I Broke Justin.tv

#37

Post by dools »

jrockway wrote: post #3

Finally, a few months into the job, I wrote “break” where I meant “continue,” and caused our payments servers to shutdown one-by-one over the course of several weeks. So, they don't write tests at justin.tv, and they don't do automatic deployment? Sounds like a great place to work at...

The goal of testing is not to never have bugs, but to never have the same bug twice.

Re: I Broke Justin.tv

#38

Post by MPiccinato »

jrockway wrote: post #3

Finally, a few months into the job, I wrote “break” where I meant “continue,” and caused our payments servers to shutdown one-by-one over the course of several weeks. So, they don't write tests at justin.tv, and they don't do automatic deployment? Sounds like a great place to work at...

I knew this post reminded me of another post from a while back, over 2 years ago now, on not writing unit tests for justin.tv: http://abstractstuff.livejournal.com/60388.html

Re: I Broke Justin.tv

#39

Post by ctide »

abstractbill wrote: post #7
jrockway wrote: post #3

Finally, a few months into the job, I wrote “break” where I meant “continue,” and caused our payments servers to shutdown one-by-one over the course of several weeks. So, they don't write tests at justin.tv, and they don't do automatic deployment? Sounds like a great place to work at...

There seems to be a general assumption that writing [unit?] tests is always the "right thing" to do, even at a startup, and no matter what the code in question does. In my experience that's absolutely not the case.

The only time tests aren't the right thing to do is when you can guarantee that you will completely trash that system at some point and that code is never going to see the light of a production machine. Most code gets refactored out of it's initial state, and that's where your tests offer huge benefits. I can say that I didn't truly appreciate the full value of tests until the first time I had to do a massive refactoring of a well tested app.

Being able to change core fundamental components of a system and trust that everything will Just Work™ when you're done is an awesome feeling.

Post reply on HN