jeffasinger

I was at a severely overloaded grocery store pre-storm this past weekend, which had implemented two global queues (one for 20 items or less, one for everyone else) in order to attempt to increase throughput and block the store less.

The manager was actually going around asking people at the front of the line the time they got in line, in order to be able to measure time in queue. Didn't really matter, as they had every lane open already, but seemed like a way for the manager to know if more lanes were needed.

Sure, let's go back to my payroll example.

I need to make 8 HTTP requests to properly setup my test from a clean slate, including setting up the deductions, previous earnings, company location and employee home address. If each of those requests takes 50ms, and then I need to make a request to actually execute my test, and verify everything went well, that could easily be 500ms.

And that's just what needs to happen to run one end to end test of the payroll calculation feature. It's absolutely valuable to have a few such tests, but I'm not going to run tests for all the weird one off scenarios (like what happens if someone lives in NJ, and works in Yonkers, and the company has a location in NJ as well?) because they'd take minutes to run. I could run that entire test as a unit test in 2ms for the payroll calculation. That lets me run all of the tests I need very quickly.

I think your argument is missing the "cost" of feature tests, which is that they necessarily must run much slower than tests that are only testing a small unit of code.

For example, I worked on payroll software at some point. After finding a bug, we'd want to ensure that could never happen again, and would want to add a test for it going forward. So for example, I may have needed to write a test around someone who worked in one city in Ohio, lived in another, previous income above some amount, and with certain tax advantaged benefits. Setting up this test via feature testing is certainly possible, but it's likely the test itself will take a significant amount of wall time to execute. It's way faster to just test the payroll calculation code, which means you can run the tests more often, and with less developer inconvenience.

Never having a cold boot isn't quite the same as being able to set a minimum concurrency level, though both would be very valuable.

At re:invent this year, someone on the Lambda team indicated that they were working on something in this space, but couldn't say exactly what, or give any real timeline.

Depending on the industry, if the training is somewhat universal (like in the mig welding example) it's possible employers could offer 0% interest loans for training, with forgiveness after some payback period as part an offer.

I'd be curious if you interviewed at the company I work for (DraftKings) or not yet. If you have, I'd be interested in any feedback you had on our process, and if you haven't, I'd be interested in why you hadn't considered the company. Either way, it's worth getting in touch.

My personal email is in my profile.

DraftKings | Backend (C#), Web, Android, iOS, DevOps | Boston, MA | Full-Time | Onsite | http://draftkings.com

DraftKings has a wide array of interesting technical problems to solve, and we are hiring engineers widely across the entire organization.

Apply here: http://careers.draftkings.com/ or reach out to my personal email address (in my profile).

I really think they're going to have to consider using forward facing radar as well.

I'm not entirely sure I get your argument.

The MBTA faces a bunch of horrible infrastructure limitations:

1. Only two rails for all subway lines, so a lot of the maintenance requires downtime.

2. The green line is on horribly dated signaling mechanisms, and also has to deal with traffic at various points.

3. The commuter rail has terrible stations, often requiring a very long time boarding, and single tracks at many points.

Alot of that would make your operational complaints better. Sure, there are problems with the MBTA, but likely the solution isn't to avoid fixing anything.

At a minimum, I'd like to see something half the size of the r4.large. The current r4.large is definitely bigger than I'd want to use for an experiment with a few users.

In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement.

The project just ended up getting scrapped.

I think a majority of their processing traffic goes through Wells Fargo. They would be a possible acquirer.

There are other Amazon services that were affected. For example, we're still not seeing auto scaling groups working correctly.

This is an unsigned int, so the expectation would be to do integer division, which would not get you the same result as multiplying by the inverse.

While probably not what you're looking for if you're mentioning Cassandra, RDS does let you have read replicas in any region.

It's not functional, and not automatic but Rust has an arena type which supports very fast allocation and de-allocation, with the restriction that de-allocation has to happen all at once.

Where I work we use several different MySQL replicas in production, where we don't expect them to be in sync.

So long as the source of truth (Master MySQL node) is up to date, it's okay.

For example, if we show a user how much money is in their account on every page, we can run query that on a replica, since it's fine if this is a few seconds delayed. However, immediately after an action changed their balance, on a confirmation screen, we'd want to show the value from Master.

It's entirely possible that any place elasticsearch is being used just don't need consistency.

ZIP Codes are 5 digits.

I can't think of a good reason why 6 would be so popular.

At work we use a rather idiosyncratic tool called RoundhousE to deploy our SQL. It treats sql labelled as a stored procedure differently, and will run the file on every deploy, as opposed to scripts that alter the schema, which are only ran once, and may not be modified.

The system works pretty well.

My best guess is that they're actually going to use the ITS first stage for this. If that's true, we may see as many as 500 of these launched in one go, with a reusable first stage.

I installed a firefox plugin to specifically remove those results from Google.

Where I work, the hardest scaling problem we face really boils down to lots of users contending for the same resources. It's very possible that HotelTonight sees the same issues around room availability.

At one company that did a take home, the first step of the onsite was some pair programming to add a few new small features to my submitted solution.

There are two sides to this though. There should be a sane middle ground. At a college, maybe the thing to do is have a fire sale on (or give away) things that are about to expire.

I remember that my college food service had a policy that food that was considered waste had to be thrown in the dumpster, and not doing so was grounds for being fired. A friend had to throw out around 20 pounds of fresh fruit every Friday because the venue that they were at wasn't open over the weekend.

For the most skilled players, it would certainly be worth it to them to treat it as a full time job. They make more doing that than most jobs.

I work at a Post Series B startup (so really medium size tech company). I typically work about 9:00am-6:30pm, with a decent break in the middle for lunch. Fridays are usually shorter.

This is busy season for us, in the winter, I'd probably leave around 5:30 instead of 6:30.

I often fly out of a smaller airport in Upstate NY. For a morning flight, my routine is to set my alarm for 1:15 before the flight takes off. I get up, pack, and am out the door about with about an hour to go. I get to the airport with about 45 minutes to go, and arrive at the gate in time to wait 20 minutes to actually start the boarding process.

With precheck, most airports aren't much worse, other than the uncertainty of transport in. I've never had precheck take me longer than about 10 minutes in security. So as long as I'm not checking a bag, it's still pretty reasonable to arrive 45min before departure.

If the infrastructure being built isn't disposable, then it makes a lot of sense. For example, building a new transit line to the airport would make a lot of sense.

Building a gigantic temporary stadium does not.

I work with some people who worked at Karmaloop. I've heard that it simultaneously was a great place to work (plenty of challenge and room for growth), but also a terrible place to work (bonuses paid out in virtual currency, very poor product management, etc.)

It looks like it's open source with an MIT License, so at least you should have the option to self host.

https://github.com/CSSE497