Quizlet is hiring in SF! We are looking for designers, software engineers, infrastructure engineers.
Quizlet is one of the rare companies to have achieved scale in K-12 education. Our team of 11 engineers ships code to 22 million students and teachers per month. We are a bootstrapped, mission-driven company with a goal of building amazing studying and learning tools to the world. We spend a ton of time talking to teachers and students, through our feedback center  and by visiting local schools. And we've barely gotten started on all the great tools we're planning to make.
Thanks a lot! The polish came from a hack night we did to redesign it.
I don't think there's much to open source -- it's about 2,000 lines of code. It's mostly just writing custom sql and elasticsearch queries to show data related to the users we're about to respond to.
Re: the log integration, all our application logs get written to logstash/elasticsearch/kibana, and one of the fields on the logs is the person_id (they're unique id whether logged in or out). When we show the logs in the feedback center, we just query elastic search and group by the different log types.
We're looking for someone to start and lead our iOS team as our first iOS engineer. We've put together a killer team across web, infrastructure, android, design, support, but iOS is still open. We would love someone strong enough to lead a team that should grow to 3-4 in the next 6-9 months.
Quizlet helps students practice what they're learning. Students absolutely adore us, just read the twitter search for Quizlet. Quizlet is a top 100 Website in the U.S. (20m uniques/mo), and during school our current iOS app is always in the top 2-3 for education. We are one of the few education companies succeeded in going directly to students, as opposed to selling through schools and districts. We have big plans for building learning tools that truly empower kids and make them enjoy the learning process.
Our experience was that backbone was very helpful in laying out code and providing clean event triggering, but that a lot of it was simply too slow to use. We started out with a View per card, but that was impossibly slow with 100+ cards (and we need to support ~1000+). We ended up with just one view for the Card section, and a view each for the sidebar and options sections. That made it much faster, but also took away many of the benefits of backbone.
Overall to us, backbone was probably worth it, but also cost us many long days of performance debugging, and we're still not 100% happy with it. For our next project we may try something else.
I am surprised by your experience, as there are Backbone projects which have used considerably more objects to no ill effect.
Backbone's three major components, Models/Collections, Views and Events do take some planning to coordinate effectively, but that's part of laying out your application.
Also, using bare JS objects is not an anti-pattern in Backbone. Use Models/Collections when you need to manage data, Views when you need to monitor parts of the DOM, and Events to manage messages between your components. Apply as necessary.
Backbone's View is incredibly slow and is very ill-suited for views that need 1000+ of them on a single page. The reason is not so much Backbone's code is particularly inefficient but the fact that Backbone.View creates a separate a jQuery context in its constructor, and then delegates events in it, also using jQuery. Both are among the slowest parts of jQuery because they have to go thru Sizzle. So if you have 1000+ of Views, each creating a separate jQuery context of its own, you can easily run up to taking seconds to render a page on Mobile.
On Backgrid (my project), naively creating 1200+ view objects on a Macbook Pro on a 2.4gz i7 takes 700ms. It really does take seconds on mobile.
I'm in the process of getting rid of jQuery and coming up with a performant View class that works more or less like Backbone.View but uses the DOM API directly. Implementing event delegation with straight DOM methods have proven to be troublesome and unreliable so I might need to come up with a different way to attach event handlers on a DOM tree.
Backbone uses jQuery's event delegation, so there should've been minor differences between the two cases you describe, mostly with how listening to the Models/Collections worked.
Additionally, it sounds like you might've been binding a render to a change in the collection? In that case, you'd want to debounce the render or only start listening to changes after the view is actually rendered with data (say the parent only renders that view when it has the data for the 200 cards, then the subview listens for changes on the collection it's given).
Anecdotally, ~1000+ views can be performant in Backbone.
It's hard to say what bottlenecks you were hitting but zombie views that can't be GC'd, rendering to the page thousands of times (instead of to an in memory DOM element), or sorting your collections on dynamic, non-memoized values could have caused those kinds of slowdowns.
Lead iOS engineer - we're looking for a person to lead the development of our iPhone and iPad apps.
We care deeply about education and do a lot of unique things to get in the minds of our users (16M uniques/mo, mostly high school and college kids).
- Every week we attend a different high school or middle school in the San Francisco area, where we test new features or ask for improvements. Everyone on the team attends.
- We personally respond to 1,200 feedback messages a week. Everyone on the team pitches in. It sounds hard but our tools are amazing for this
- We use our product a lot. Our team of ~12 combined knows about 10 languages, and groups of us are always taking classes or trying online learning tools. We take group tests (last week we all learned Sushi terms).
While I am still a student, I would love to give some feedback. I've found that when using your quiz feature, and you have to type the word or definition, you have to spell it correctly. I have found this as a huge problem when working with foreign languages, because I may not be used to spelling, so it count is wrong. If there is a way to implement some auto correct or spell check with words in the set, I would love that.
I was at a big edtech conference last week (Education Innovation Summit in AZ).
Something like a dozen of the 100 presenting companies came through Imagine K12, which is incredible. I know a lot of the people involved, and if you're thinking of starting something in edtech you should DEFINITELY apply. It's a great program.
The logging thing is really really dumb. Having logs in a real database lets you do incredible things (e.g. correlating user feedbacks to random problems you noticed). We use our db-driven logs many times a day to debug issues and find patterns.
Don't be afraid of putting logs in databases and then figuring out how to scale it. It's not that hard and it's very worth it.
Splunk, last I checked, used PostgreSQL for it's backend. While maybe badly worded, my point was more toward the users who have a two column log table with a timestamp and a syslog style line of text. The problem with "advice" posts like these is you can't cover every possible scenario without confusing the less experienced readers. Do I think loggly or splunk cloud should store their logs as flat files? Hell no, their app IS logging. But in the general case of application architecture I don't think it is appropriate or terribly useful for most. I know they say "never say never", but I felt it justified when I believe it's a bad idea in 99% of apps.
It's really more about using the right tool for the job, Splunk, Loggly, NoSQL solutions, etc. are a MUCH better fit than an RDBMS for this sort of work.
We took this photo in a classroom last week where we were beta-testing our educational game. We want to hire engineers who are excited by helping kids learn, and creating similar reactions to the one above on a scale of millions of kids. We're building web and mobile software that makes a significant difference in the lives of its users.