jeffasinger

I worked at a company where the founder had started with some local contractors to build an initial version of the product.

He hired a CTO, who took a look at the current code, list of bugs, and new features desired, and made the call to do a complete rewrite.

In retrospect, this was absolutely the right call. It can definitely be wasteful, but sometimes starting with a completely new design is the right thing to do.

One issue with this is the idea of competition from physical hardware.

At some price point, if the prices are too high, it will be cheaper to hire extra people, and get a cage in a few datacenters and some physical hardware.

One potential issue with spinning up new instances on EC2 is that for larger instance sizes, if you care about the instances being in a certain AZ, there may not be enough available to do this.

The ID requirement and address requirement were not enforced all that strictly when I was last in Germany.

I bought a 10EUR SIM with a US driver's license (had left my passport in the hostel, and just wrote down the address of the hostel I was staying at).

I think the article means to say is JSONB modification.

Prior to 9.5 there weren't commands to edit values within a JSONB column.

Sometimes that doesn't help.

At work we were debugging why a process that is usually quite fast (< 5min) was taking close to 2 hours once we got to the load we predict for this coming fall.

We noticed the box it was running on was running out of memory, so we assumed resizing it to have ~4x the RAM would help, but surprisingly it didn't. The actual answer turned out to be algorithmic, and we were able to rewrite it to use an O(n) algorithm rather than an O(n^2) algorithm.

Also, I wouldn't necessarily limit yourself to a single page. Lots of companies have offline processes that are painfully slow, and are very good candidates for optimization.

I once worked at a company where I noticed an employee would come in over an hour earlier than normal on Monday mornings. It turns out she got in early to run a report that the CEO liked to see every Monday morning. An hour or two later I added an index, and refactored some SQL so that we could do more in a single query rather than N queries, and the report time went down from 45 minutes to 3 minutes.

I don't think this is enough, because it assumes that all clients are connected to the same server. What we need is something federated (like XMPP) and with a design that is reasonable for mobile.

At least ACH is slowly working towards being faster. In less than 2 years, next business day ACH should be pretty universal. In about 6 months, some ACH transactions will clear the following morning.

Where I work we have a big directory with one file for each stored procedure.

On deploy, all the stored procedures will get updated from that directory. Rolling back would consist of deploying an earlier version of the repository with the procedures in it.

Slack does a pretty okay job messaging that everything you say is available to your companies administrators. At the minimum, assume that everything said on your corporate IM system (even private to two users) is discoverable in a lawsuit.

I've gotten one or two wrong before. Sometimes the questions aren't well defined for a given picture.

For example, the question was "Does this have a river in it?" with a picture of the Grand Canyon, where you couldn't quite see down to the Colorado River.

If you are a valuable enough target, this is not an option.

IPs are cheap, if you let someone try 20 times in an hour before banning an IP, there are targets that people will cycle through IPs that quickly for.

CAPTCHAs are useful when you want to rate limit something to an extremely low rate, like for example attempting to login with a username and password.

I agree that the Instacart economics don't quite work out.

However, to be fair to them, it is also expected that you'll tip.

Active Directory https://en.wikipedia.org/wiki/Active_Directory

This conforms to a somewhat surreal experience I had talking to an internal recruiter in Chicago a few months ago.

"Oh, you already have offers on the table in NYC and Boston, with no family here? Yeah, I understand why you wouldn't be interested in Chicago"

I don't really buy this.

In any modern language there's going to be pretty battle tested libraries out there to handle requests/response/decoding/encoding for you. This is stuff that is almost never need to be debugged.

If you have a small team and uncomplicated infrastructure, you're only hurting yourself by moving to microservices. However, if developer synchronization problems make core changes to your monolith difficult and block the work of a ton of people regularly, your monolith takes minutes to build or start up, and you're already having to shard the data your monolith deals with across many datastores, then there's no definitely no developer tax to switching to microservices.

The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith (this can be a mostly manual process only doable by 1 or 2 people). However the cost of deploying 100 services is still only about 5x the cost of deploying the single Monolith.

There's certainly a size threshold below which a microservices approach hurts more than helps.

Makes sense. I recently tried to send someone money on PayPal. They froze my account, and then CS suggested I wait 2 to 3 weeks for the account to unfreeze itself.

Welcome to new money.

I've seen companies willing to pay >100k in Chicago and relocate people there, for engineers with only ~4 years of experience.

Storing the a cryptographic hash of the credit card number would allow for searching for receipts by credit card number without storing the actual credit card number.

Things should get better, to some extent, with Same Day ACH.

Starting September 2016, their should be relatively cheap next day ACH transactions available to the majority of US bank accounts.

It's far from perfect: still not instant, will probably cost money (interbank fee of about $0.09), and won't immediately support debits. However, it's a big step forward for US banks.

So if you're aiming for zero downtime rollbacks with Django, here's how adding a new field to a model might work:

  1) Add a Migration that adds the new field, but allows null. Deploy.
  2) Add the field to the model. Also make sure it sets it's default on write. Deploy.
  3) Execute a background task to set the field to whatever it's default value should be.
  4) Add migrations to enforce integrity and add indexes. Deploy.
  5) Actually deploy code that needs the new field.

Yes, this is super annoying, no, most people don't do this. Separating out #1 and #2 means you can always roll back all the way to right after #1 without losing any data. An extra, nullable field on a model with no indices on it shouldn't hurt anything.

This is a pretty big first step towards easily deploying highly available services on DO. Unfortunately it sounds like you won't be able to fail over to another datacenter, which is unfortunate, but understandable.

If this becomes the main type of switch, then HP would be in a great position to offer integrations and consulting.

I think Seamless offers an API: http://www.seamless.com/business-development/

The even crazier thing about your example, is that they have different offerings for their high net worth" clients, and with those offerings, the structuring is usually much more in the favor of the client than what someone walking in off the street will get.

Essentially, a poor person will be charged higher fees than a rich person.

This is a pretty cool idea.

One thing that would make it more useful to me, though much more difficult to implement, is that when you click a reused value, it store a reference to that result, so if you change the calculations for that result, all the references change also.

For example, that way I could have some initial parameters up top, and use those in a complicated calculation, with the end result changing if I change those parameters.

One difference is that the Rochester Subway operated for almost 30 years [1].

Interestingly enough, it was actually used as a freight railroad until 1996. It is easy to walk right down into, with two different public access points that have no impediment to traffic. There is a lot of cool graffiti down there, especially in the area underneath the broad street bridge. I'd recommend anyone in the area to grab a flashlight and explore at some point.

1: https://en.wikipedia.org/wiki/Rochester_Subway