Health to the Web

Is this code ok? customer ?. type || '' Probably, but strictly semantically speaking this should use '??' ( nullish coalescing)  instead of '||' The left side condition uses optional chaining which resolves to a value or undefined, ?? is more strict and only fires for null or undefined. Whereas '||' will execute for more values than null or undefined (also 0, false, NaN, '') So if customer.type was 0 then using '||' will resolve to the right side customer ?. type || 'none' // 'none' whereas if customer.type was 0 then using '||' will resolve to the left side customer ?. type || 'none' // 0

There are some things AI coding assistants are not good of assisting at this time. But because AI assistants always want to predict, it will. And ais will sound very confident in the prediction. Sometimes the answer can be completely misleading and just garbage. Which is much worse than no answer at all. We recently upgraded our react version and some cypress tests for the app then started failing. I did some investigation and could see an unexpected failing api call in the tests. Why?  I asked the llm for assistance with some context such as new version of react, some libraries, details on the test failure.  It's prediction was a reasonable guess given the prompt but a wrong guess. It suggested a bunch of code changes such as the following: 1. adding timeouts to every cypress element check e.g.   `cy.contains('button', 'Save', { timeout: 10000 }).should('be.visible').click();` 2. new cypress helper functions to handle a double action and then changed tests ...

Periodically we need to remind ourselves of good common sense coding practices. Two simple but very powerful are: 1. write less code Sometimes the best solution is just to write less code. We need to think before implementing: how can I write less code?  I may come up with an acceptable solution, but there may be a better solution with less code. Its possible my first solution is not the best. A good time to do this thinking is before you get too far into an implementation. At a certain point you're too deep, too far along to easily change or reverse course. But even if you are, don't be afraid to change course, even if you may lose some time. Its still typically more efficient to change when building a feature than after its been released to production. 2. "go with the grain" Systems are often built in a certain way and when we change those systems we should try to follow that way. Build on the existing architecture, on the current algorithm on existing conventions o...

Update: after I wrote this post I thought more about it and have realized I was thinking too small. Jony Ive doesn't partner with you just to "build a better iphone". These guys have got to be thinking bigger. Much bigger than that. Jony Ive designs the future. Pair up massive compute with some of the most advanced AI models. What do you get? A new world. They mentioned replacing "decades old legacy products". Think form factors that fit the new technology. Like Apple devices did. Think ecosystem. Think holistic AI user experience that's end to end.  Think a world of autonomous devices. Think robotics, and not just the sci fi classic 2 legs 2 arms types.  I know this sounds "hypyie" but they have to be thinking this big. OpenAI spending more of that investment round. A cool ~$6.5bn to buy/merge Jony Ives startup company, so cute picture .  (yeah, that Jony Ive). The announcement this past week says they've been collaborating for two years and J...

Matt Pocock of "Total typescript" has shared his cursor rules files for typescript.  Thank you Matt. 14 rules files.  I already opened a PR and added to our codebase. I recommend.  Some adjustments: removed this rule from ts-naming-conventions "Use kebab-case for file names (e.g., my-component.ts)"  installing-libraries, jsdoc-comments, default-exports added as global advice in cursor, not just typescript

This is a post I wrote in linkedin about cursor rules We use cursor as the IDE in work and defining rules makes it better.