HN user

slow_donkey

394 karma

hn at raindeer dot io

Posts3
Comments203
View on HN

I tried solving this with a search engine that accounted for reviews with some manual curation, but I realized there's actually an extremely limited set of 'good' recipe sites and kept returning the same 10 sites with a long tail of average sites.

You could improve upon this by establishing site authority for a topic (cuisine), but it still seemed pointless to me.

To be fair this is a very very old list dating back to 2006/2008 and these were the pizza names that came up constantly at that time - it's also only rating the shops that he personally traveled to which were predominantly NY/Neapolitan because that's likely what he was benchmarking his own restaurant against.

IMO before react native came on the scene there were no well performing hybrid app frameworks except possibly xamarin. So it likely wasn't your fault

I highly recommend reading Vincent Woo's piece about Lambda to understand the criticism better with actual evidence. https://vincentwoo.com/2020/05/19/on-lambda-school/

It's also arguably not an equivalent comparison. Many people attending these bootcamps have already graduated college and tend to forgo work to attend - there is a huge opportunity cost even if they don't directly lose money. I have no reason to believe the model wouldn't work, but there's ample evidence that the implementation of the model via Lambda is flawed.

I'm building a search engine for this exact issue - there's 10000 recipes for every dish but they have to be contextualized: Do I want mac and cheese in the next 30 minutes or am I serving this for Thanksgiving? Those are 2 different experiences and recipes.

Even the base issue of at least ranking recipe blogs by quality isn't solved by other aggregators such as Google / Yummly which are more of a recipe dump.

If you or anyone else is interested I'm planning to release a version in the coming weeks - email is in profile.

I don't disagree with you, but graphql just lends itself well to bad decisions and many times when I've poked at graphql endpoints they share these issues (missing auth after first later, exposing schema by accident, no depth/cost limit). I think a combination of new technology w/o standardized best practices and startups being resource constrained proliferates poor security with graphql.

Of course, the same could happen for standard REST as well, but I think the foot guns are more limited.

If you're in a major metro local meetup/slacks are a great tool. They'll provide the intro without you needing to 'know' the person. I've done that successfully with engineering positions and you could likely go through engineers if the (JS) community is larger.

Wish he didn't make fun of bad English from non-native speaking posts - of course they'll seem cringey to us. There's plenty of legitimate examples he could have used instead.

SpaCy 3.0 5 years ago

This sounds super cool, is there a public link to your work? I'd love to check it out

Ah yeah I saw this initially but haven't given CRFs a try yet. I was hoping ml had advanced enough that I could throw newer solutions at the problem. Thanks for linking this though, I just realized there's a lot of labelled training data the NYT provided which I will definitely use.

There's a more practical but relevant cooking problem that I haven't seen discussed - when extracting recipes from websites it's tricky to parse the actual ingredients and quantities.

For example, "1/2 cup of diced tomatoes or a can of tomatoes (preferably san marzano)". This sort of freeform text doesn't suit regex very well but also lacks substantial context clues. You'd most likely use named entity recognition which could recognize that "1/2" is a quantity, "cup" is the unit, etc. but I haven't gotten very good results yet.

Maybe I'll write up a post when I land on a solution.

I wrote an Android app for managing recipes with bakers percents so I definitely agree - being able to scan over the ratios of water, salt, and sugar tells you a lot about the recipe and what the dough will feel like.

I do wish normal cooking recipes had a similar convention - it's rare that I've ever used exact amounts since the ratio and technique are always more important.

It's hard for me to see the value in monetizing posts from OSS projects. If I wanted to pay for someone's thoughts I'd be using substack or paying for pictures from OF - in both cases the value I receive is directly tied to the subscription.

Possibly a more interesting approach could be gated support similar to an exclusive discord for patreon subs to ask questions.

What's the purpose? Do finely tuned job descriptions attract more candidates? I'm guessing the point isn't to actually describe the job if the copy can be automatically generated.

I've been building an app for bread baking with bakers percentages. It's been hard to find a solid recipe app that's not hell-bent on monetizing via a shipping list or even supports easy recipe creation.

Conversely, renewed competition may also be a good sign that there's a market for such products. You do need a place to differentiate, fortunately the surface area of the problem is fairly broad.

As an example, look at low-code for inspiration to determine what features people need which aren't being filled by existing solutions. Hopefully that reduces the need to compete via feature checklist.

I had the same feelings as the parent - this article did not make good arguments for using Haskell specifically in building production systems, it instead argues that Haskell is a good programming language yet many of the benefits listed can be found in other languages.

Even if Haskell was objectively the 'best' language, it'd likely be a poor choice for most teams simply due to familiarity and developer speed.

I'd be extremely hesitant to hire the services of this company entirely because they use Haskell and it'd be a nightmare to maintain after their contract.

Yeah g-suite is a dam bargain especially since it also gets you conferencing, SSO and is one of the few SaaS you'd truly want to buy and retain.