helsontaveras18

I agree wholeheartedly that debugging types is very difficult. The best we have is hovering our mouse over the definition to see what type was created from the definition. Obviously not great.

Also, debugging type differences with deeply nested objects (like what happens with graphql schemas) can be hugely painful. You need to copy the error message to its own file (since the errors can be huge) and debug what specific piece failed.

I do feel the Typescript documentation is lacking and the only way to get better is to read open source projects to see how others have done it… which is only helpful when they’ve solved the exact problem you’re looking for.

It’d be great to have a recipe book of common advanced typescript manipulations and how to compose them together.

Drop in replacement for Cypress is the line that’s getting me to sign up

A market cannot just be two people. If I sell you a brand new Rolex for $1, I would say I’m selling it to you at a discount from the market rate, because if I posted it on an open auction like eBay, I’d receive higher bids than $1.

I always have do not disturb on but I add my family, friends and certain coworkers to my favorites list. There’s a setting that allows contacts in your favorites to bypass do not disturb. Calls always come through.

Haha love it. Question regarding getting the most from your application logs. My practice is to prefix log statements with the file name and function that’s generating the log. Jumping to that code is just a quick search away. But it does require a bit of manual work to write that extra metadata. I do this because devs just put random logs and it’s so hard to know where they’re coming from. Any best practices?

Have the first two rows figured out on hard but can’t seem to move past that. Any ideas?

You should understand the fundamentals of the tools you use, so that when an error pops up in your webpack or SWC build, you understand how to debug the error and fix it.

Not sure why this sensible comment is being downvoted. The living room used to be a place for a family to congregate and spend time together doing shared activities. If everyone is on their own device… there is no opportunity for quality time and shared connection.

Linear is awesome. It gets out of your way and let’s you focus on creating tickets really quickly. The integration with GitHub means engineers rarely need to update the board since tickets sync with your pull request. The keyboard shortcuts are amazing and so is the performance. I’d highly recommend it.

This website is one of the fastest web pages I’ve ever used. Although it’s simple, it immediately loads pages and pages of images. Like in a flash. I’m on mobile web and it’s such a snappy experience.

I just bought it! I’ve always wanted a book that clearly lays out good UI tips.

How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.

Did you forget to add /s to that?

Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development).

Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud.

Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.