nrh

Anyone who digs this should take a look at the art (and process) of Barry X Ball. https://www.barryxball.com/ https://www.instagram.com/barryxballstudio/

needs the ball sizes to represent the storage capacity!

Listen to his charming and deeply entertaining story of his early years at SF Examiner, told at The Moth in 1999: https://themoth.org/stories/rookie-reporter

15 minutes you won't regret!

I'd love to try this, but most of the places that I would want to use it are servers, and the rust requirements are way beyond where debian-stable lives.

Too much hassle to muck with backports and package pinning for a QoL tool - my feedback would be to try to make this install without tomfoolery on the stable branch of major distros.

I'm pretty into this place's business philosophy: just ship us your stuff with a little bit of information and we'll repair it. don't call ahead, don't ask for a quote, don't send us garbage that's not worth repairing. mucking around and/or unnecessary communication will just slow things down. We'll fix it and ship it back and bill you. End Of Story. I wish my work-life were so simple.

ATE0!

Once upon a time I worked for what was (once) the world's largest BBS. Remember the US Robotics Courier HST? 16.8kbps! Now imagine a room filled with shelf after shelf of Couriers, several hundred individual lines, at least a few hundred amps worth - all negotiating vigorously, clicking on-hook and off, all the time. Fun times.

Pretty sure I could still tell the difference between a 14.4k and 16.8k negotiation by ear.

An article much more relevant to that question: https://techcrunch.com/2017/02/02/slowchat/

It took Instagram Stories two quarters to catch up to Snapchat's total MAU.

it seems to come down to two main points, as far as consumer tech companies go:

1. GAAP says that revenue from a software service subscription (e.g. cloud service) can only be counted as revenue once the service has been delivered, not at time of sale.

http://www.marketwatch.com/story/ea-to-ease-non-gaap-usage-a...

http://www.grayboxpdx.com/blog/post/revenue-recognition-for-...

2. Equity-based compensation is accounted for as a cost.

http://mercercapital.com/financialreportingblog/equity-based...

I'd say the data platform overall, bigquery is certainly great . So are some other bits.

Spotifier here. For the record, I hate puppet with the fiery intensity of a thousand suns. It's also pretty hard to magically make go away. I could probably do a whole talk on why puppet is difficult to kill, it's the kudzu of config management. I think it is the worst.

We've got our warts and a pile of tech debt, and I wouldn't want anyone to think otherwise. Containers are a part of a long-term strategy to get away from puppet and onto more idempotent units of deployment, and move a lot of what is considered to be "configuration" back into the build process where it belongs.

I would categorize data tooling as a moving target - we have some, it's never enough, it probably won't ever be enough. It's a moving target (p.s. obligatory we're hiring!).

I think this Quora post does a good job of redshift vs. bigquery: https://www.quora.com/How-good-is-Googles-BigQuery-as-compar...

More generally speaking, (excuse me for being a little hand-wavey here) many of the AWS offerings feel like polished, managed versions of familiar tools. Redshift, for example, feels a bit like "hey we figured out how to abstract away a bunch of mysql instances to feel like a big processing cluster". That's not a bad thing, necessarily. The google stuff feels much more intentional - "we need to solve the problem of doing these sorts of queries at scale" vs. "we need to solve the problem of scaling mysql to solve these types of queries"

Maybe they're just better at abstraction, but whatever - that works for me!

Spotifier here. Frankly, price is not the biggest factor in a decision like this. If we were going for the lowest cost cloud option, it probably wouldn't be either AWS or Google - there are other providers who are hungrier for business that would be willing to do deep cuts at our scale.

The way we think about this is that there are basically two classes of cloud services: commodities and differentiated services. Commodities are storage/network/compute, and the big players are going to compete on price and quality on these for the foreseeable future (as with most commodities).

The differentiated services stuff is a bit more interesting. Different players have different strengths and weaknesses here - AWS has way, way better capabilities when it comes to administration and access control and identity management, for example (which is actually pretty important when trying to do this in a large org). The places were Google is strong (data platform) are the places that are most important for us as a business.

Compelling: dataproc+gcs, bigquery, pubsub, dataflow Made it safe: high-enough quality, cheap enough.

What more would you like to know?

Spotifier here. This is an important point. I have nothing bad to say about Cloudera or HWX (disclaimer: we're an HWX customer - we've had a pretty good experience), but I don't really see a compelling reason at this stage to manage your own cluster(s) (HIPAA/regulatory constraints, maybe?)

Getting shared-storage and indepedently operated/scaled compute clusters on top of that storage isn't easily achievable with the standard Hadoop stack, and building that on top of HDFS is non-trivial.

Spotifier here. One of the big risks that we identified with the Google partnership was exactly this: Google isn't exactly known for awesome customer service.

We've been very pleasantly surprised. The cloud team has been pretty awesome to work with, including lots of engineer<->engineer contact, walk-throughs of systems and code for critical dependencies, and solid support and collaboration. Exceeded our expectations.

  To fix this problem, we introduced the simple rule that new 
  stable releases of the software must (a) talk to old stable 
  releases and (b) they must support existing apps, without 
  changes. We more or less succeeded with that, so ZeroMQ 
  versions 3.2 and 4.0 work nicely with 2.2 and 2.1, for  
  example.

...and pain ensued.

This. This is so often overlooked. Getting your architecture to roughly align with your team structure can do wonders, even if there's only a hallway dividing people. When a small team can iterate and evolve a chunk of code independent of anyone outside the team, it really unshackles them.

There are obviously patterns for doing this in monoliths (or, say, mobile clients - another type of monolith), but at some point you are bound by the dependencies inherent in a single runtime.

We use it pretty extensively at Spotify. Google will turn up a handful of public talks we've given about it.

Spotify, NYC and Stockholm, for...lots of stuff!

- Backend Engineers: Improve our ad systems and enable better, more relevant targeting. Build and scale our backends.

- Frontend Web Developers: Mine, aggregate and visualize complex data. Engage users and optimize front-end experiences. Build advertising platforms and tools.

- Web Developer Team Lead: Build and lead a team of web engineers to create the next generation of Spotify experiences

- Machine Learning: Improve our music recommendations, mine those datasets!

- Mobile (iOS and Android): I heard something about 1B smartphones by 2015.

- Mobile Team Lead

- Backend Infrastructure: Build the stuff that the guys building the stuff are building it with; Storage, high-performance messaging, service registration and discovery.

- Lots of things not-mentioned (http://www.spotify.com/se/jobs/)

On the backend, we have an (extremely) service-oriented architecture written primarily in Python and Java with smatterings of C++ and others thrown in. Storage is Postgres or Cassandra. Messaging is zmq and protobuf and a few other interesting things.

On the frontend, we do hybrid native+CEF for most platforms.

Our website gets a lot of oohs and aahs for being a particularly good example of parallax scrolling.

We're looking for experienced developers, no junior roles, sorry. Apply on the website, but mention HN and get bumped to the top of the resume pile!

Spotify, NYC and Stockholm, for...lots of stuff!

- SRE

- Backend Infrastructure

- Machine Learning

- Mobile iOS and Android

- Team lead positions for most of the above

- Lots of things not-mentioned (http://www.spotify.com/se/jobs/)

On the backend, we have an (extremely) service-oriented architecture written primarily in python and java with smatterings of C++ and others thrown in. Storage is Postgres or Cassandra. Messaging is zmq and protobuf and a few other interesting things.

On the frontend, we do hybrid native+CEF for most platforms.

We have (I think, anyway) a pretty interesting approach to how we work, which you can read some more about here: http://de.scribd.com/doc/113617905/Scaling-Agile-Spotify and here: https://hep.cat/d/nrh-how-we-work.pdf

We're looking for experienced developers, no junior roles, sorry.

Apply on the website, but mention HN and get bumped to the top of the resume pile!

NYC - Spotify - Full-time

Backend: SRE, Software Engineer (Infrastructure), Software Engineer (Backend)

Primarily Python & Java, also C/C++, deployed on Debian with Puppet. Looking for dev and ops (and devops?) with experience working at scale.

http://spotify.com/jobs/