jeffasinger

I'd imagine that airlines tend to give out free checked bags on these flights also changes the calculus.

Interestingly, I think we're seeing less people grow up with general purpose computers, and instead just have an iPad or an android tablet, or a chromebook.

I wonder what things will look in 20 years.

Not the OP, but the people I've seen this do it DIY have all done it with Ubiquiti products. A single link can get a mile of range with clear LoS. Depending on how far out you are, that lets you connect to a "real" internet connection for cheap.

One thing you may encounter is that a large company may be using it for many things internally, and that still shows up as just a handful of clones, because they have some central artifact caching service in place.

Essentially this is a way to lets you push all of the weird feature requests your customers might have off into one place.

From a customer point of view, maybe you need to rewrite the path based on the contents of a cookie, or maybe you want to shed certain types of requests in high load scenarios, or maybe there's a buggy upstream application that sends bad cache-control headers, or ...

If the goal is to let the customer specify infinitely complex logic at the edge, a programming language is a good way to do that. Function As A Service is a good billing model for lots of invocations of short, small functions across the customers choice of language.

I had written it this way because the OP had specifically ruled out using Django. Point taken though.

Why not start out by using the Django Admin features?

That allows you to start with next to no code, but you can easily add a little business logic anywhere you need it eventually, and it provides a way to long term transition to a true application if the need arises.

Almost every ad network does give you some type of API like what you're talking about, but unfortunately they usually actively discourage use of it.

Facebook will be pitching to your Marketing folks that's exactly where you need it.

Facebook want data on what actions users took before signing up, which users actually signed up and started paying, and how that relates to revenue. This UI is exactly where they can determine these types of actions.

Whether this actually makes Facebook better at marketing or not is a good question.

At my job, we evaluated moving from AWS hosted ES to several of the Elastic offerings. Many of them were more expensive than AWS was before taking hardware into account (as in comparing cost of Elastic licensing vs the whole cost from AWS). This made it exceedingly difficult to justify the move. It's not only the headstart with the client (billing relationship in place), but the cost that hampers them.

If dollars have no value, you should be willing to give away any dollars you have to anyone, no matter how they are using them, right?

Dollars don't have a direct value in gold, but there are people willing to take your dollars and exchange them for gold, it's just a ratio that varies over time, along with the value of gold and dollars.

Those types of errors are usually pretty easy for humans to find and fix.

I (sort of) work in the advertising industry. I'm really excited to see this change, but the major players in the industry just weren't ready for it, and it would have been very chaotic with lots of money on the line.

I think waiting until early 2021 is better than having anything that depends on ad revenue see a huge dropoff until the industry figures things out.

If the problem is that there aren't enough acceptable quality housing with good public transit access, it seems like building more transportation and housing would be a good solution rather than building similarly expensive suburban sprawl.

What I would do in your situation is try to measure the incremental value of future messages, the likelihood that a given message causes an unsubscribe, and the value of the current message to come up with a good balance.

For a small list like this, it may mean separating users into two segments:

* Actively engaged, send them a weekly update

* Not engaged, only send them big new announcements.

Marketers tend to look at link clicks, email opens (measured via embedded images), and engagement with the actual product (if you have it) for segmentation like this.

A good manager should be doing a lot more than just asking you for status updates in your 1:1s. At a minimum they should be:

1) Providing updates on things going on with the rest of the organization that may affect you. Technically this doesn't have be in a 1:1, but is often a good venue. 2) Learning more about any problems facing the team, and discussing potential solutions. 3) Giving feedback on both what the employee has been doing well and any areas they could improve. 4) Helping to set goals that will advance the employees career goals.

While you might be able to get everything done well with lots of autonomy, you're probably still leaving value on the table by not meeting more regularly.

I did an online food ordering startup a ways back, and it was very surprising how few of the restaurant owners we talked to had clearly thought through pricing strategy for things like this.

We had originally gone in with clever ways for owners to describe how different changes would affect the price of an item, but ended up landing on just a giant matrix where they could input the end result price for any combination. The owners couldn't articulate their own pricing well enough to model it well.

My understanding is that the prices are set by Instacart, based on estimates on what they've seen the store charge in the past, plus some markup for price change risk, and probably some amount of profit/cost of maintaining the pricing data and product catalog.

Not an expert on Houston, but did spend the past weekend there.

There's definitely a big car factor there. I had reserved a mid sized rental car to get to and from the airport and around the car centric area I was staying. When I got to the rental car center they apologized and said they were out of mid sized cars and said I could take a truck, a large suv, a jeep wrangler or what she referred to as a 2 door. It turns out a 2 door was a dodge challenger (large, overpowered and fuel inefficient car). The representative said they got rid of all the smaller cars because no one would be willing to rent them.

The concentration of pickup trucks being driven as day to day commuting vehicles seemed quite high as well.

This essentially happens in Boston to this day (though the date is September 1st).

This is definitely true.

Most of the online gambling operators in New Jersey take PayPal, though you usually have to use either a bank account linked with ACH or a balance you already have in PayPal.

We did actually get to use it at work, to real performance benefit.

We have a leaderboard with a list of users, which is normally a list of users totalling between 2 to 50,0000, but in rare circumstances can be several million. The scores users can achieve are in a rather small range, perhaps only 450k valid different scores, and we were doing this sort on average once every 30 seconds.

What we ended up doing was switching to a radix sort when the list of users got to be very long, as it was substantially faster in those cases, making the user experience much better, as the leaderboard was much more up to date for the very large cases.

Also not an accountant or lawyer, but I think that if you're paying someone by the hour, and directing them as to how they should do they job, they need to be classified as an employee, not a contractor.

This means a W2 instead of a 1099, plus you need to pay them on a fixed schedule, pay social security and medicare taxes (and likely other taxes depending on jurisdiction) on their wages, deduct income taxes, do an I-9 verification at the beginning of employment, change your own liability insurance, etc.

There is software as a service companies that help out with setting this up correctly, but I do see many ways you could do this incorrectly, and land yourself in trouble.

Sorry if I wasn't clear. You aren't relying on just the ack semantics, you're building bidirectional communication on top of software, in a way that's potentially a little unnatural.

Here's an example of how you'd accomplish this with Kafka. Whenever a new instance launches, it could generate a UUID, and create a Kafka topic with a matching name. Any messages it sends that it expects a response to could include a "reply-to" field, with this UUID. When something processes the request, they publish a message to that Kafka topic.

Essentially when people are talking about "Service Bussses", they're talking about frameworks that implement this and other similar patterns on top of generic queues like rabbitmq, msmq and sqs. One such framework I've personally used is MassTransit.

Often times these "Service Bus" type frameworks implement request/reply by creating a queue per host, and in every message adding envelope information that includes the queue that the reply should be sent to. This does allow a request/reply pattern. I've never actually done this, but I imagine in environments where reliability is more important than latency, it probably works pretty well.

One minor nitpick. The patterns you're talking about aren't typically implemented on Kinesis, since there's no concept of topics there. On AWS, you could do something like that with SNS + SQS.

That's fine, but reorganizations happen, teams can grow, and there is an advantage to having things be separate services in cases like this.

Definitely don't just stuff unrelated stuff into a service since a team that normally deals with that service is now working on unrelated stuff. If the unrelated stuff takes off, you now have two teams untangling your monolithic service.

That said, I'm a big fan of medium sized services, the kind of thing that might handle 10 or 20 different entities.

I think a bigger thing here, is that each deploy should have a REALLY good reason to not be backwards compatible for some pretty long time period. If that requirement is painful for you, then you probably have two pretty tightly coupled services.

My understanding is that biotech is actually better in Boston than the bay area by a pretty wide margin.

What I don't get about your strategy:

Why not work on something so valuable that even if it takes twice as long as the best estimate, with twice the headcount working on it, it would still be worth it?

As a a manager, I feel that helping to find projects that have that amount of value is an important part of my job, so that if I am fighting for a project my team's working on, I'm actually in the right from a business case point of view, not simply playing some BS political game.

If there are no projects that fit that value filter, then that's a completely different organizational problem.