r888888888

I am building HomeBidder (https://homebidder-web.fly.dev), a tool for figuring out a realistic bid price for houses. I got sick of seeing artificially low listing prices on sites like Zillow so built this tool to give me a more realistic number based on comps. Along the way I've learned to add confidence intervals, adjust for lot size and fixer status, and provide QOL information like access to transit and how bad the pollution is. It is heavily optimized for SF but I'm starting to iterate and validate on other cities.

The way this works in terms of design is:

1) A game mechanic is introduced 2) The player is subject to slowly increasing difficult that requires the mechanic 3) The player is forced to demonstrate mastery of mechanic in some new situation, often by combining with other mechanics 4) The player has mastered the mechanic and has the option of using it whenever they want in the future

It's not that simple.

If you're using a secondary data store like Elasticsearch presumably you're combining it with a traditional relational database like Postgres or MySQL. And in most use cases, you're going to require additional constraints on top of full text, like restricting to a specific customer or topic, etc. This means data duplication. Any experienced developer should be breaking out in hives at this point because this means (1) keeping two data stores in sync; (2) adding another service to the deployment process; (3) adding another service to development environments; (4) adding another service to debug when problems crop up; (5) large scale schema changes and migrations are complicated because of two data stores; (6) operational overhead from maintaining Elasticsearch like separate backup scripts and deployment scripts and sharding config (across production, qa, and dev); (7) queries are potentially complicated because you may have to aggregate information from two data stores (pagination and delayed updates makes this even more hellish); (8) if your company is anal about devs accessing production data then ES just introduces another layer of requesting permissions and every time the schema changes you have to ask again.

And maybe the advantages of Elasticsearch far outweigh these negatives, but this is a conversation you're going to have with your devs because the cost of using ES is not zero. There are tradeoffs, and maybe just using Postgres full text search is adequate for your use case given sufficient additional constraints.

StyleForum and reddit /mfa/ would both recommend SuitSupply. For the cost they're hard to beat.

IMO it was when Oracle bought MySQL and effectively killed development. MySQL still lives on with MariaDB I suppose, but in the years since Postgres has leapfrogged it in terms of functionality.

I do it all the time.

If you don't want to sit at a table, typically restaurants have a bar area where you can order food and it's not as strange to see people dining solo there. It's also socially acceptable to chat with other people at the bar.

I run a similar semi-pornographic site. The problem is payment gateways like Paypal do not like sites with adult content, and traffic typically isn't high enough to justify splurging on a merchant account.

I feel that cast iron pans are overrated. Stainless steel is easier to clean, lets you build fond, lets you cook acidic pan sauces, and are lighter so you can be more aggressive about pan flipping. The only advantage cast iron has is heat retention and there are few cases where that's useful (like deep frying for example, or baking bread). Iron is actually a relatively poor conductor of heat also and a good tri-ply pan will heat up faster.

Cast iron dutch ovens are another story because you will frequently use them in ovens where the heat retention properties are useful.