At Second Spectrum we use spatial-temporal pattern recognition to tell stories about sports. We have lots of interesting challenges in machine learning (how to recognize patterns from moving dots), user interface/experience, (how to intelligently display the mountain of information that we gather from a single game or even play), and computer vision (how to augment video to display semantic information from our pattern recognition layer).

And yes, we are hiring in LA, in those areas, as well as for full stack developers. Feel free to reach out at noel@secondspectrum.com or work@secondspectrum.com

Second Spectrum - Los Angeles, CA, Shanghai, and Boston, MA - http://www.secondspectrum.com

Big data has come to sports, and Second Spectrum is using it to transform the sports experience, for everyone from coaches and players to the most hardcore or casual fan. We have trained machines to understand sports at a level of sophistication that exceeds that of most collegiate players. Using this machine understanding, we deliver analytics software that is helping eight NBA teams win more games, is enabling national broadcasters to tell better stories, and will give every fan their own personal sportscast.

We are looking for both full stack engineers, and machine learning and computer vision engineers. The responsibilities range from sophisticated GUI design that supports detailed but intuitive analytics, to front-end interfaces that will appear on national sports broadcasts, to scalable backend infrastructure that supports robust video streaming, to ML and CV engineering that enables the semantic layer that understands the game.

If you're interested in joining us, our jobs email is is work@secondspectrum.com. I'm also available for any questions you might have at noel@secondspectrum.com

Shameless Plug: If you're interested in this sort of stuff, we're looking to hire engineers at Second Spectrum. We work with 8 NBA teams to deliver insights like the ones in this paper on an everyday basis. Feel free to shoot me an email at noel@secondspectrum.com if you have any questions, or email our jobs address at work@secondspectrum.com

It appears that Paxos will be used in the third lab, http://pdos.csail.mit.edu/6.824/labs/lab-3.html.

In the 2010 version of this course, we implemented paxos on one of the later labs. It was considered one of the hardest I think.

How is Paxos hard? Inventing Paxos is hard. Implementing it is implementing a well-specified state machine.

If it was so easy papers like this would not exist: http://research.google.com/archive/paxos_made_live.html

The first lab is due Monday, six days after class began, so we were given about a week for it. The professor told us it was not supposed to be a very intensive lab, and its main purpose was to get us up to speed with Go and the scaffolding code that we are using. In addition to the labs and tests we are required to read a research paper for every class and write a paragraph answering a question about it, and we must also do a project at the end of the term. You can find examples of old tests at the OCW site http://ocw.mit.edu/courses/electrical-engineering-and-comput..., if you'd like to see what they are like.

I'm currently taking the class. C++ was used before. The main reasons the professor cited for using Go are that it has a very easy to use RPC library and that the labs are designed so that you will spend most of your time working on the distributed systems aspects of the problems, not dealing with the intricacies of the language or libraries used. Apparently he felt Go was better for that than C++, though he didn't spend any time comparing the two.

I took 824 last Spring and the labs were often terrible because of the level of debugging necessary (but very informative and well made). In particular it was bad for those without much C++ experience like myself. I think the difficulty of testing and worrying more about small bugs rather than the concepts of distributed systems was a common complaint and it's awesome to see it being changed. This class was also taught by rtm the semester I took it.

"Taught by RTM" == "taught by read the manual"?

RTM = Robert Tappan Morris, http://en.wikipedia.org/wiki/Robert_Tappan_Morris

Another reason may be that it's easy to let students validate their work with the built in `go test`.

> Your job is to modify client.go, server.go, and common.go so that they pass the tests in test_test.go (which go test runs).

I wonder if it was would be easier (and legal) to just mock the functions so that tests pass, without writing any actual functionality.

I don't think you could do this without actually solving the labs the way we wanted you to.

I took this class in 2008, in C++, and the RPC code definitely felt like a mess. I expect the Go version must be nicer, plus a fresh rewrite probably helps regardless of language.

Enjoy the course, it's a great one!