theswan

Samsara | Product, Infrastructure, Mobile, Site Reliability, Security Engineers | San Francisco, Onsite

Build aws for physical infrastructure.

Samsara was started by the founders of Meraki and has a small, tight-knit engineering team that's quickly growing. We are looking for people who love building and seeing their code get used by customers.

Our backend is powered by golang/graphql/grpc and our frontend applications use react/react native/typescript.

Apply/more info at https://www.samsara.com/jobs

At Samsara our golang graphql implementation (https://github.com/samsarahq/thunder) works this way. We write out resolver functions using plain old go types and use some reflection magic at startup to compute the graphql type information.

Our docs are a bit spare at the moment, but this means with code like:

  type User struct {
    Id int64
    Name string
  }

  func rootUser(ctx context.Context, args struct { id int64 }) (*User, error) {
    // ...
  }

  schemaRoot.FieldFunc("user", rootUser);

I think this is something that graphql implementations are still trying to figure out. At work (samsara.com) we use a time-based batch[0] for our queries to help with n+1 issues in our graphql server.

Separate branches of the the graphql query are handed to independent goroutines. When batchable rpcs (to the database, or other services) occur, we delay execution by ~1ms and wait for any other rpcs of the same type (and keep delaying for up to ~20ms). This works pretty well for our more expensive field resolvers. We've also thought about ways to examine and track the execution of the goroutines (similar to the facebook/dataloader approach), but the time-based batches have worked pretty well for us so far.

We also aggressively cache queries and rpcs so that the same data is not expensive to fetch across different branches of a query.

[0] You can see the batching implementation here: https://github.com/samsarahq/thunder/blob/master/batch/batch...

Clara Labs (https://claralabs.com/, YC S14) - San Francisco, Engineering, Full-Time

Clara is building the simplest possible interface to getting work done. Every person on our team is involved in the thinking that creates their work - full stack in the broadest sense of the term. This means identifying, owning, and driving projects to completion.

We believe shipping early and frequently builds better products. An extreme example: we scheduled thousands of meetings entirely manually for our first Clara customers before building any software at all.

Accepting human dependency is the fastest way to building useful machine intelligence. The failure of intelligence products to date has fundamentally been a failure to build trust. It is the consequence of unreliability and lack of focus (think: Siri). Conversely, Clara has delivered a highly reliable, focused, and useful natural language interface from day one.

We’re looking for frontend, backend, and machine learning engineers to join our early team. Check out our full descriptions for each role [1], and feel free to ping me directly at stephen@claralabs.com if you have any questions!

[1] https://jobs.lever.co/claralabs/

Clara Labs (https://claralabs.com/, YC S14) - San Francisco, Engineering, Full-Time

Clara is building the simplest possible interface to getting work done.

Every person on our team is involved in the thinking that creates their work - full stack in the broadest sense of the term. This means identifying, owning, and driving projects to completion.

We believe shipping early and frequently builds better products. An extreme example: we scheduled thousands of meetings entirely manually for our first Clara customers before building any software at all.

Accepting human dependency is the fastest way to building useful machine intelligence. The failure of intelligence products to date has fundamentally been a failure to build trust due to unreliability and lack of focus (think: Siri). Conversely, Clara has delivered a highly reliable, focused, and useful natural language interface from day one.

We’re looking for frontend, backend, and machine learning engineers to join our early team. Check out our full descriptions for each role [1], and feel free to ping me directly at stephen@claralabs.com if you have any questions!

[1] https://jobs.lever.co/claralabs/

Clara Labs (https://claralabs.com/, YC S14) - San Francisco, Engineering, Full-Time

Clara is building the simplest possible interface to getting work done.

Every person on our team is involved in the thinking that creates their work - full stack in the broadest sense of the term. This means identifying, owning, and driving projects to completion.

We believe shipping early and frequently builds better products. An extreme example: we scheduled thousands of meetings entirely manually for our first Clara customers before building any software at all.

Accepting human dependency is the fastest way to building useful machine intelligence. The failure of intelligence products to date has fundamentally been a failure to build trust. It is the consequence of unreliability and lack of focus (think: Siri). Conversely, Clara has delivered a highly reliable, focused, and useful natural language interface from day one.

We’re looking for frontend, backend, and machine learning engineers to join our early team. Check out our full descriptions for each role [1], and feel free to ping me directly at stephen@claralabs.com if you have any questions!

[1] https://jobs.lever.co/claralabs/

Equally interesting/appalling: private keys on github

https://github.com/search?p=4&q=extension%3A.key+BEGIN+RSA+P...

Hmm, GoodReads seems to be an imdb for books.

I'd be more interested in a format more suited toward discussion/annotation - like what you'd get out of a good college-level literature course.

Tangentially - I consistently find myself wanting to discuss a book I've read, but unable to do so for lack of others who're in the same position.

Are there places on the internet for good discussion around individual books?

Where do the 10 microstellars go? Are they actually destroyed?

The problem there probably wouldn't be the node.js code, rather, the library has a dependency for mp3 encoding with LAME (used on the Sonos end for streaming), which I've found hardware like the raspberry pi sometimes has trouble with.

Some other proof of work protocols: http://en.wikipedia.org/wiki/Proof-of-work_system#List_of_pr...

Thank you! Would love further feedback (stephen at stephenwan.net) if you find yourself having any problems using it. The code is very-much early stage, so there are some issues to squash.

Thanks! Behind the scenes, I've written an node.js component that's able to talk to OS X/iOS devices (https://github.com/stephen/nodetunes) via AirTunes and stream in raw audio data. From there, AirSonos converts the audio into a "radio" stream that Sonos can understand.

The code is still very much 'alpha-stage' at the moment; functional but not completely consistent yet. I'm planning on doing a writeup with further progress!

@por and @berberous -

Does audio play at all even when the error happens, or completely doesn't work? I've noticed that sometimes it occurs but the streaming still works fine.

"strange error flushing buffer" is emitted from one of the dependencies, the lame encoder - I'm currently looking into the issue..

Would love to diagnose this further, via github or stephen at stephenwan.net.

Tangential point - what does the phrase "any dish?" mean?

Very cool!

I bought a Play:3 a few months back and was also dissatisfied with the given OS X/iOS apps - I'm currently working on enabling AirPlay support for Sonos devices. (http://stephen.github.io/airsonos/)

Would love feedback from any Sonos users!

Had this very probably on Friday - wanted to learn more about what was new with the SpaceX launch and ended up spending a couple hours on Wikipedia.

Thanks for this!

Just nabbed https://github.com/stephen was inactive since 2008.

What editor were you using previously, and what in Atom made you switch over?

In re the sections on "hiding the lag" - Bungie (the guys behind the original Halo games) have a pretty cool presentation on how they hid lag in Halo Reach.

http://downloads.bungie.net/presentations/David_Aldridge_Pro...

Looks like they've been sitting on this joke for a while.

  Updated Date: 2014-03-28T14:26:39-0700
  Creation Date: 2012-02-20T19:27:58-0800

Makes me wonder - would we ever get to a point where it's in Square/Stripe/Coinbase/et. al's interests to contribute mining power to help their own transactions along? Or is that pretty much taken care of by transaction fees?

How is Square/Stripe getting around the issue that most exchanges wait for 6 confirmations before a transaction is accepted? Are they ignoring the risk of a double spend and just going ahead once a transaction has propagated to the network for mining?

In a way, I think Google really did orphan "Android," the open source project. Key parts of the current Android experience (Google Now, Google launcher, music player, Hangouts/Messaging, etc.) are now closed source and only available to OEM parnters who sign with Google (http://www.tested.com/tech/android/458759-android-44-kitkat-...). The AOSP equivalent components are painfully ancient.

This has happened over the last few years as Google began exercising more control over the platform and secure a better experience; now - there's Android, the somewhat orphaned OSS, and Android, the Google experience OS.

Interesting that just a little bit ago there was an article on software installation security (albeit from a different angle).

Theoretically speaking, is it safe to curl and install something via plain http:// and no checksum verification?

Am curious who is in charge on manufacturing the device.. Both car manufacturers and Apple have history of wanting build the "whole widget."

I think this suggests either talks between Tesla and Apple didn't go well, or something even bigger (integration wise) could be coming up.

Do you mind providing examples of use cases re Google Now vs Siri? Not disagreeing with you - just haven't owned an Android device in the last year to know.

I think downvoting != disagreeing to the point, but rather, downvoting = disagreeing that this article is worth the time to read.