rodeoclown

There are several ideas here about how to elegantly combine physical switches, knobs, and dials with digital displays that I quite appreciate in this design.

Some nice details: - There's digital readouts around the binnacle gauges - The physical needle on the speedo comes from the outside to leave the center available for the digital screen - The drive selector has a small screen (light?) in the center as an indicator

The combination seems like it may create a quite polished feel if it's done well in motion.

The issue with conferences is not where they are held, but that people come from afar to visit them.

Start with the animal table:

Animal(animal_id PK, ... animal attributes)

No need for join tables or surrogate keys on these tables. The animal_id can serve as both the primary key and foreign key.

Dog(animal_id PK FK, ... dog only attributes) Cat(animal_id PK FK, ... cat only attributes)

No need for surrogate key on pet, and don't forget the owner key:

Pet(owner_id PK FK, animal_id PK FK)

This allows multiple owners of one animal. If you don't want that you need a unique constraint on animal_id.

Part of the safety of standard cruise control is the fact that it is clearly crude and dangerous - it keeps the driver engaged.

Just because you've made a team and given them the job of doing something (incredibly) difficult, doesn't mean you've actually solved that problem or even should expect them to solve it most of the time.

You're absolutely right that having a "blue team" is much better than not having one - but it doesn't mean that calling out the reality that many organizational activities can't be easily measured is a "rubbish excuse made by people who don't understand".

You can even do SQL DDL ALTER TABLEs in a Transaction on production, do the change, run smoke tests in a nested transaction that are all rolled back when complete, and if anything fails you roll back the DDL changes and are back where you started clean.

When breaking up your records into multiple rows by attribute - you then require multiple read units due to how DynamoDB charges you for each row read which costs a minimum of a read unit. So each complete record would have a cost for each attribute as if they were each sized at 4kb (minimum size of a read unit) on read and write.

You also very likely need to use DynamoDB transactions (not really mentioned in the article) or else you're taking big integrity risks with partially incoherent records and so you're paying more for their transaction bookkeeping as well.

Doesn't this seem to map badly to DynamoDB's cost model?

I've head this comment before, but from my own speech I don't find this to be true at all. It usually means I'm saying something I perceive to be more vulnerable or direct than any party to the conversation has been to that point - not at all that I was being deceptive before that point or after.

In my opinion, the two most important features as a developer for the App Store:

1. Rolling deploys - right now releasing on iOS is scary and big bang, combined with the review process it keeps devs up at night worrying. 2. AB Testing on images and copy - you can only update this on each (scary) release, so you can't learn what works quickly.

You're missing something: The way to project an iPhone onto your Mac screen with OSX is to use Quicktime movie recording mode and select your iPhone.

Couldn't you just use a dimpled ball to get however many numbers you'd like?

This is from their kickstarter page:

"The real challenge now is to deliver a sequel that we will all be satisfied with after 14 years of waiting. After much research and planning, we set the funding goal at this level believing it will make possible a fulfilling Shenmue experience."

The camera is to recognize what recipe you put in the oven. Not sure if full HD was required, but maybe they found it gave better accuracy for the cost difference.

Scalability is a reason that many growing companies use open floors. When you are growing rapidly, you're often put in a situation where you need the most flexible possible floor plan, otherwise you have to move offices. Having way more offices than employees sitting empty waiting for the hiring to happen in the next few years feels too much like a waste of space. This makes the open office plan very seductive when making decisions about how to lay out the floors.

Model your data first using foreign keys, then if you have performance issues with specific queries consider ways of optimizing those queries.

Materializing that data in a graph may be one of those optimization candidates.