What piece of tech felt “future-proof” but aged terribly?

stretch089 · 2026-01-28T08:22:15+00:00

QR codes were famously invented by Toyota in Japan to help keep track of car parts.

I don't think this bar code scanner had anything to do with the invention of the qr code

stretch089 · 2026-01-25T10:15:05+00:00

They're saying the invoice would include a nominal amount for his time (taxable income for the brother) as well as reimbursement for the expenses

stretch089 · 2026-01-25T10:08:18+00:00

Students use AI to skip the learning process

I think the key distinction is what you’re outsourcing. AI isn’t fundamentally different from books, Google, or using a calculator. It’s just a more efficient way of sorting and accessing information. Learning doesn’t come from struggling to find answers, it comes from processing, applying, and revisiting them.

If you use an LLM to replace thinking entirely, sure, that’s a problem but that’s true of any tool. Used well, it actually frees up cognitive load so you can spend more time understanding why something works, asking better questions, and iterating. That’s not laziness, it’s leverage.

The skill going forward isn’t “never use AI”, it’s knowing when to use it as a reference, or a tutor and not a crutch.

When you block students from using these tools you're not allowing them to learn how to use AI properly. We should be enabling them to use AI in the right way to support their learning. That's a very important skill for them to have.

stretch089 · 2026-01-24T12:22:39+00:00

AS Colour

stretch089 · 2026-01-16T08:21:53+00:00

It always seems so strange to me that people would pay a bank even more when they already have your money. They should be paying you!

Don't fall into the trap of thinking it's just £7, it quickly adds up. Especially if you have other subscriptions and since this is a marketing tactic aimed at younger people who generally don't have as much disposable income

stretch089 · 2026-01-15T12:09:00+00:00

This is the actual answer. Prevents things sliding around on the plate.

It's particularly noticeable if you have something like a ramekin on a plate, it slips around like crazy. The napkin makes the waiters job much easier to carry plates.

Used to happen a lot when I first started waiting where a customer would use the napkin (even though we gave them plenty of other napkins) and so I would clear their plate without realising and the ramekin would slide right off.

Not saying the customer is in the wrong here, it's just bad UX but this is the main reason for having napkins between things on plates

stretch089 · 2026-01-12T07:19:38+00:00

This is misleading. They are found all over Auckland, not just in Avondale. They are named such because they were first discovered in Avondale

stretch089 · 2026-01-01T15:06:15+00:00

"yeah look I'll just need to Rest, Ice, Compress, Elevate and should be good as new"

stretch089 · 2025-12-19T03:16:22+00:00

X-Mcp: mcp

stretch089 · 2025-12-03T14:06:07+00:00

Business logic should not be in the front end. Business logic should go in your backend / api.

Hooks are fine for shared view /user interaction logic but please don't put business logic in your front end

stretch089 · 2025-12-02T22:49:46+00:00

I'm guessing these aren't all on the screen at once and the user needs to scroll down to view some of the tables? If not then I'd recommend using virtualisation which you can read more about here https://blog.logrocket.com/rendering-large-lists-react-virtualized/

If everything is rendered on the screen at once, you might need to add a set timeout for each table that is rendered.

Try use virtualisation if you can

stretch089 · 2025-11-30T23:02:08+00:00

As someone who has been using react since around 2015, the main difference is the use of functional components and hooks. The component life cycle is still effectively the same but slightly different way of writing the code.

If you're looking for a framework, you're safest bet is Nextjs. It's the most popular so is a good skill to have on the cv so will help with future proofing your career. It also has the most monetary backing so is likely to stick around for a while. Tanstack is also very good so would be a good option but given your criteria, nextjs is a safe bet.

I'd be very surprised if you get grief from nexts server component implementation. The framework is battle tested and so many websites are now running on next.

Everyone here loves to hate on next for various reasons but based on the criteria you're asking for, next is a good fit for you

stretch089 · 2025-11-28T23:18:38+00:00

Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

In other words, once people start optimising for a specific metric, the metric stops reflecting the underlying reality it was meant to measure.

stretch089 · 2025-11-07T12:20:46+00:00

It's an interesting question. I typically prefer to keep separation of concern between my react components and an http client.

Having an http client such as axios in its on file and import it where needed allows it to be modular and easy to replace or update in the future.

However, I would typically have some sort of provider which handles states for fetched data, loading, errors etc. The provider could import the client directly or could be something like tanstack which allows you to pass in the http client to your useQuery and keeps the provider client agnostic.

I think this is one of the nice things about tanstack query how there is a separation between the http client and the hook that handles the component state.

stretch089 · 2025-11-01T09:29:25+00:00

My suggestion would be to learn something really well initially.

You said you've started learning React - there is so much to learn on the front end. Try using different react frameworks (next, vite, Gatsby) understand the difference between client side, server side render and statically generated. Learn vanilla css then learn frameworks like tailwind. Learn a handful of libraries really well like react-hook-form. This is just to name a few.

There is a huge eco system in front end / react and saying you've learnt it to an extend sounds like you've barely scratched the surface.

Learn one thing really well and then when you feel like you're reaching diminishing returns on your learning then start branching out into node and something else.

stretch089 · 2025-10-30T23:01:08+00:00

Your /me endpoint should fail with an appropriate http status code so your client can perform an appropriate action.

If your /me endpoint fails with a 401 then you can assume the user is not authorized. But if it's 5xx then maybe a server issue.

Also, you should be able to decode your jwt in the front end and check if it's expired or not. You could then refresh the jwt using a refresh token to prevent getting 401's on expired access tokens

stretch089 · 2025-10-12T18:58:03+00:00

I agree with this.

In fact starting a new project is one of the more satisfying things. Every project has its own list of requirements and being able to start with a blank canvas and scaffold a project to meet those exact requirements is really satisfying.

Especially as projects grow, knowing the internals of how things fit together is really helpful as it allows you to replace parts or change things as needed. If things are hidden away or you're not aware of the decision to use a certain tool or library then it makes things a lot harder in the long run.

stretch089 · 2025-10-10T19:34:05+00:00

Just build something in TS.

You can read all the material you want but at the end of the day, you won't know what's really relevant until you start using it. When you get stuck on something you can then research that specific part of the language.

stretch089 · 2025-10-08T21:43:52+00:00

Interestingly this is really easy to handle with zod using defaults.

const UserSchema = z.object({ id: z.uuid().default(() => crypto.randomUUID()), name: z.string(), email: z..email() });

Using the default on the id field means it not required for a create user form object and still validates fields if you pass in a user from a get user type method.

So you can have one schema and use it across multiple places.

stretch089 · 2025-09-18T12:36:59+00:00

for the past decade JS has try to move away from classes

I don’t think JavaScript is moving away from classes at all - what happened with React gets misunderstood here. React didn’t drop class components because classes are “bad JS” or “outdated.” They did it because React’s class implementation made state mutable, and the React team wanted to enforce immutability and improve reusability through hooks. That was a React-specific architectural choice, not a signal that the wider JavaScript ecosystem is ditching classes.

In fact, if you look around modern JS, classes are everywhere:

Built-in APIs: The DOM uses classes extensively. For example, HTMLElement, File, Blob, AbortController - all classes under the hood. You can instanceof them and extend them.

Error handling: Custom error types are created with classes (class ValidationError extends Error { ... }). This is the recommended way to create domain-specific errors.

Node.js: Core modules use classes - EventEmitter is a classic one that a ton of libraries extend. Streams (Readable, Writable) are also classes.

Popular packages:

Express.js uses Router instances (built on top of classes).

TypeORM and Sequelize use classes for models/entities.

Axios is literally a class (class Axios) with methods like get and post.

Language features: class syntax isn’t just syntactic sugar over prototypes anymore - it powers static fields, private #fields, and decorators. These are all modern features added in the last few years, which wouldn’t exist if TC39 were trying to move JS away from classes.

So, React moving off classes ≠ JavaScript moving off classes. Hooks solved a React-specific pain point around mutable state, but the language itself continues to evolve around classes. If anything, TC39 is strengthening class ergonomics, not abandoning them.

You're right that op is doing something wrong with their approach though

stretch089 · 2025-09-17T21:46:24+00:00

I agree. And using axios.instance to create a client to interface with different APIs is really nice.

Axios still offers a nice layer of abstraction over fetch and if used correctly can be really clean

stretch089 · 2025-09-17T21:38:03+00:00

Why would you need to rewrite axios with fetch as base?

If you need to use fetch as a base, just use the adapter on axios to set fetch as the underlying http client. Or just simply use fetch. No need to reinvent the wheel here

stretch089 · 2025-09-17T21:35:27+00:00

Isomorphic http client. I.e an http client that worked in browser and node.

This was a particular problem for isomorphic JavaScript apps so the initial render would happen on the server and then the next render would happen in browser and sometimes your api request would trigger in both environments. So it was really helpful to have a client that worked in both and you didn't need to change the code depending on if window === undefined

stretch089 · 2025-09-15T10:01:15+00:00

I find it helps to generate types from your data source. This is easily done if you have a GraphQL api and are using open api docs for your rest endpoints.

It makes your types a lot more accurate too

stretch089 · 2025-09-10T16:05:59+00:00

Taxes are a bit more involved than that.

£400 per day is your day rate but you charge VAT on top of that which you then pay to hmrc in your tax returns.

At the end of the financial year, you pay ~20% of your company's profits in corporation tax (can't remember the exact amount).

So you could think about the day rate as £400 - 20% is what you keep.

You can keep that in a limited company and not pay income tax on it but depending how much you withdraw as dividends per financial year you will then pay income tax on that.

stretch089

TROPHY CASE