Hacker Newsnew | past | comments | ask | show | jobs | submit | hox's commentslogin

That, and it would be an FBI van, not an NSA van. But the point holds.


Sometime there’s vehicle from at least three businesses and two government agencies gathered round an inconspicuous looking civil infrastructure element, and I have to wonder who spying on who. And how much that’s costing.


True in some regards, but it’s also incredibly easy to learn how to do things the wrong way, if you have no one to learn from.


>but it’s also incredibly easy to learn how to do things the wrong way, if you have no one to learn from

Yep, say hello to startups who go cheap by outsourcing to developers who are not as good in their craft or don't care about learning more.


These startups also don't stay in business for very long ;)


I guess I might phrase it something like, if you're going to make L5 it is probably the result of excessive competence. If that is you, you will get their faster cutting your teeth in at least a few different startups. Develop judgement and a variety of experiences.


Make the changes on a non-active replica database (assuming your database supports replication), then promote the replica to be primary. If you don’t have replicas, the concept of “zero downtime” is really at risk as your primary database becomes a single point of failure.


That's not great either. Moving the "master" role from one server to a replica isn't instantaneous (meaning you have a period of read-only state), and while your replica is performing the schema operation you still need to keep the data in sync with changes made on the master server (which to the best of my knowledge is non-trivial).

There are tools that "replay" data changes though: - FB's OSC (https://www.facebook.com/notes/mysql-at-facebook/online-sche...) - GH's gh-ost (https://github.com/github/gh-ost)


Twilio | Software Engineering | San Francisco, CA | Onsite or Remote | Full Time

The Messaging Channels team is responsible for building the future of the Twilio Messaging API to embrace new forms of communication, starting with Chat applications (such as Messenger, iMessage, RCS) and digital assistants (such as Alexa).

This unique opportunity will offer engineers direct and highly visible impact towards one of the largest products at Twilio. The Channels team requires high velocity iterations and experiments with a keen eye towards operational stability of existing infrastructure, building microservice-based products in Scala / Java in a highly distributed cloud environment.

https://boards.greenhouse.io/twilio/jobs/875610


You've never been to a grocery store? Avocados are by no means exotic...


Remember, "exotic" depends on where you live. If you watch Iron Chef, the original one from Japan, you'll see whenever they have a dish with avocado, the guest judges always proclaim "Avocado! How Exotic!"

Even within the US the availability varies widely.


I doubt the grocery stores carry many around here if they do at all. They probably blend in with all the other greens. I'll check for them next time I'm at the store.

Walmart's online stock search returns no avocados for the local store, so I doubt the smaller grocery stores have them: https://www.walmart.com/store/520/search?query=avocado


> They probably blend in with all the other greens.

...yes. It is a vegetable.


Actually it's a fruit.


Perhaps botanically it's a vegetable, but that doesn't stop it from being a vegetable.


A vegetable is anything edible that doesn't respond to stimulus while it's alive. Like a coma patient, or tomatoes.


It grows on a tree, so it's no less a fruit than a peach or an apple.


Conpletely agreed; using DynamoDB for primary storage suffers from needing to design data models around the underlying technology. This is true for secondary keys as well, and is even constrained by the odd pricing model that DynamoDB follows.

I've been happy using DynamoDB as a large-scale caching layer, but even that only fits very specific use case criteria.


> using DynamoDB for primary storage suffers from needing to design data models around the underlying technology.

Every database system, at large scale, suffers from this problem.


I laugh every time I see this because everyone seems to forget the rough time they had the first time they encountered a relational database and how to map their problem into that space... Sure it's pretty straight forward now but that's the point... You're still doing it... You are still using your domain knowledge of relational to map your problem ilto the underlying tech. You just don't notice it. "Oh companies have people and people have multiple addresses with one marked as primary and addresses have 1-3 address lines and several optional fields based on local and and and and..." That's several years of learning if you had to discover it yourself there, not just on the address domain but also on how to decompose it.


The biggest issue faced with DynamoDB from my perspective has been the problem with any hosted service - that is, the operational stability is in the hands of others entrusted with operating a massive multi-tenant system, and any outage cannot follow your own operational recovery mechanisms unless you plan for failover yourself. And the moment you plan for failover, you need to evaluate why you don't just handle the primary system as well.


There are many things people justifiably complain about DynamoDB, but operational support has rarely been one of them.


Dynamodb experienced a severe outage in us-east in September of 2015, dropping the service to three nines of uptime on just the single event. During the incident there was little-to-no knowledge of when service would be restored, so companies that relied on the service were flying blind.

Such an outage can sometimes be mitigated when operations are internal to a company; but with DynamoDB, one has to build internal failover or implement a complex cross-region replication scheme. The complexity and reliability starts to reduce the attractiveness of the hosted service in general.


I mean... of course? But I feel like the idea here is that you can "entrust" them with operating the system and not worry about rolling your own failover mechanism, as long as they seem to be upholding their SLAs.

(Of course, cloud vs. bare metal is a long-running debate, but I think I take the position that multitenant clouds are generally cheap enough that it's worth the cost for the extra feature velocity, if you're not truly at scale.)


you should play dwarf fortress.


Why would you even ask this? Please don't contribute to the ageism debate. My hunch is the programmer was qualified for the job.


Don't tell me what to do. I didn't say only reason I said one of the reasons. Something that separated the applicant from the pack of otherwise qualified people.

In any case unclear to me why it's a bad thing to note that someone older has a better chance of getting hired because it's easier for them to find living accommodations.


Twilio | San Francisco, US | Full Time | Onsite | Messaging software engineers & managers & all the stuff

The Twilio platform enables companies to integrate communications directly into their applications via simple cloud API’s and with on-demand global reach. Twilio is therefore challenged with abstracting away a world of complexity so that our customers can go global without concern for managing a global communications network, carrier integrations and relationships throughout the world.

The Programmable SMS team is hiring engineers and managers to help build the future of asynchronous communication. In addition to helping bridge the complexities of SMS and MMS communication to a simple API, you will also have a vital role in empowering our customers to build messaging solutions beyond the SMS platform.

https://boards.greenhouse.io/twilio/jobs/146183#.WBj6h5MrKRs or https://boards.greenhouse.io/twilio/jobs/147129#.WBj7n5MrKRs


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: