Need to mail something? Request a pickup in the Shyp app, we'll pick it up from you, package it, and find the best deal out of UPS, Fedex & USPS to get your items to their location safely, cheaply & on time.
5 server-side engineers are serving operations in 5 cities. We just raised $50m and we're looking for engineers to help us grow.
Lots of interesting problems to work on, including:
Re: Remote opportunities - We are super interested in hiring great people who can't move to SF. We believe our processes can support remote work, but we understand this is a hard thing for us to assert with confidence. That said, we are extremely interested in building remote-work processes that scale - let's talk!
Not looking, but based in SOMA? You might be interested in our lunchtime tech talks - ping me, firstname.lastname@example.org.
hey! thanks for the reply. I'm sure it would be fine if we had it configured correctly - the issues we're seeing are a) unexpected behavior in the queue/worker library we are using, b) it was installed before most of us got there, and we don't understand the failure modes, and c) we don't have good visibility into the state of the system when it fails.
I have full faith in Redis as a tool, and I'm sure there are reliable queue/worker libraries that work with it but we don 't have one of them. even with a reliable datastore you need to make sure you're not dequeueing things twice or putting things back on the queue or suddenly having your workers stop processing things - we've seen all of these, and like everything, it's been tricky to balance "rewrite the entire thing" vs. "make it good enough & focus on delivering business value".
Should add, a problem with `rsync-auto` is some files in node_modules (bcrypt, among others) are compiled at runtime, and produce different outputs for Mac/Linux - you can't just copy them from Mac to Linux and expect it to work. Probably some things we could do to hack around this but it didn't seem worth it.
May want to check out the patch - after a syscall in a directory failed because the directory didn't exist, node would issue 4-5 additional stat() calls for the other filetypes (.js, .index.json, .json, .coffee, etc) even though the directory didn't exist. Solution was to abort after the first failed stat(). https://github.com/nodejs/io.js/pull/1920
I don't think it's your fault, though. Chrome loves crashing and throwing away all of my research tabs. That wasn't the first time. It's only the first time I could reproduce it with a specific website. Still, as I said, I don't think it's your fault.
I'll just finish reading the article when I'm back at my PC. Test optimization is a great thing.
Hi Shane, thanks for the tip about sails-memory. We've seen a lot of inconsistencies in the way Waterline behaves, so we're hesitant to run it against a different backend than the one we use in production. We'd also lose all of the uniqueness constraints that we use in Postgres.
In general we're trying to write and run more tests that only create and manipulate objects in memory, especially for testing business logic. Unfortunately we still have to have some level of integration with the database to test things at a higher system level.
Re: transactions, most of our database code uses the ORM, so we thought other test speedups would give a bigger benefit. We recently added an interface for getting/querying with a `pg` connection directly and we're using that to implement transactions in a few critical places. I'm planning to release the code soon - hopefully in a blog post in a few weeks.
Yep - we've run into a lot of really unexpected behavior with it and with the ORM (Waterline), so we try to restrict ourselves to "the minimum possible framework subset that gets the code to run".
For example, we disable `dynamicFinders`, don't use policies, don't use blueprints, don't use Waterline's associate/populate/destroy, don't use the "turn any controller function into a named route" setting, don't use globals, disabled all of the Grunt/websockets junk, and overwrote all of the error response handlers.
The result is that day to day we're writing something that resembles an Express app with its own `routes` file. We're looking to move off of Waterline/Sails entirely, it's slow going though since we're a small team and it's tough to prioritize that, as it "works" now.
Every company has parts of their tech stack that don't do a great job - we're somewhat fortunate this one is easy to mitigate.
Sounds like you guys pulled out everything except for Express. I too found the more I used Sails the less useful it became, as though it was missing a solution for anything lying outside of the very basics. Compare Sails to say, Laravel, and you begin to see how much work needs to be put in to bring it up to date.
That happens with every Framework.
That's why we migrated from Django to Playframework.
Django is great, except for the thing we do / the expertise I / we have. Play framework is way more "raw" than the most of the framework's I've seen. Also I use Slick but only the SQL part of it and the Codegen. It's so great to write RAW Sql while persisting objects easily and type safe without a big layer in between.
You are correct Playframework still does too much for the most people, however we are using a lot of things from the framework, basically json, forms, templates, the new DI layer, the ws library (which still is not usable on spray :(:() and the plugin layer.
Mostly I think we could easily switch to Spray, however currently I really liked Play in his current version.
Need to mail something? Don't worry about boxing up your packages or finding the best deal. Request a pickup in the Shyp app, we'll pick it up from you, package it and find the best deal out of UPS, Fedex & USPS to get your items to their location safely, cheaply & on time.
5 server-side engineers are serving operations in 4 cities. We just raised $50m and we're looking for engineers to help us expand.
Lots of interesting problems to work on, including:
- Warehouse optimization
- Driver dispatch/routing optimizations
- Figuring out the best carrier for a given package
- Communicating sundry shipping options across different carriers in a standard way
- People ship a lot of interesting stuff! Tons of opportunity to give everyone a great experience at scale, no matter what they're sending.
Some of the benefits of the job:
- No waking up in the middle of the night! Open hours are 8am to 8pm.
- Whatever laptop setup you want.
- We host tech talks over lunch twice a month - have had people from Bugsnag, Stripe, Twitter, Medium, ngrok, and Layer come give talks in the past four months.
- $400 a year in travel credit, we want you to get away
- Daily Volume (compared to tweets or push notifications or text messages) is low, so systems aren't constantly falling over or about to.
- Our data is stored in Postgres, no worries about writes being acked and not actually saved.
- Servers/stored data are all UTC :)
- No long hours - pretty much everyone leaves the office at 6pm sharp.
- Really generous health/dental/vision coverage
- Office is about two blocks from Montgomery BART, lots of food/culture options nearby.
- We'll help you relocate to SF
If you're interested, we'd love to talk to you! You can't waste our time by getting in touch. We'll answer your questions about Shyp and tell you a little more about what our interview process looks like.
Please drop me a line - email@example.com.
Not looking, but based in SOMA? You might be interested in our lunchtime tech talks - ping me, firstname.lastname@example.org and I'll let you know the next time we have a speaker in.