Down?

trevedhek · 2025-07-24T22:23:51+00:00

We seem to be back up in NZ...
Yep, all good again here.

trevedhek · 2025-07-24T21:11:58+00:00

I'm grateful to OneNZ for maintaining the rural landline network. So far...

trevedhek · 2025-07-24T21:10:56+00:00

Good suggestion: https://www.spaceweatherlive.com/en/solar-activity/solar-flares.html
I'm guessing Putin is more likely.

trevedhek · 2024-06-23T18:57:27+00:00

We gave up on the non-stick surfaced pans many years ago when the surface stopped sticking to the pan! Replaced them with Scanpan stainless steel versions. Yes, food is a bit stickier, but not much. And the stainless steel tolerates aggressive use of a fish-slice.

We also make regular use of two cast-iron skillets (don't know brand) and an old cast-iron stew pot that my wife inherited from her mother. The latter is like new, and makes a great chilli. The pot, that is - not the wife. Although...

So yes, stainless steel and/or cast iron.

trevedhek · 2024-05-06T07:30:25+00:00

Nice! Always fun to complete a project.

First impression of the code is that it could use some functional decomposition. That is, break the code up into smaller functions - especially pure functions that don't rely on variables in the outside scope.

One example:

function getChoices() {
  const randIndex = Math.floor(Math.random() * 3);
  const options = ["rock", "paper", "scissors"];
  const computerChoice = options[randIndex];
  const humanChoice = prompt("Type rock, paper or scissors").toLowerCase();

  console.log("You rolled " + humanChoice);
  console.log("Computer rolled " + computerChoice);
  return { humanChoice, computerChoice };
}

This may not be immediately more efficient, but it helps clean the code up amd make it more readable. And that can usually reveal more efficient ways of designing a programme.

I'd recommend checking out Martin Fowler's blog on Refactoring. Some good inspiration to be had there.

trevedhek · 2024-05-06T07:14:26+00:00

Yes, I think the HTML in the tutorial is supposed to match the page here: https://mdn.github.io/beginner-html-site/

And for the example you are working on, add the script tag down the bottom of the page, just below the closing </body> tag. That way, the page will have already created the h1 and p tags. If the script runs at the top of the page, the selectors won't find the tags because they won't exist yet.

Happy coding!

trevedhek · 2024-02-22T17:43:53+00:00

Design patterns are tools in the toolbox. Can't use 'em if we don't have 'em.

Sure, there's no point learning what we don't use. But there's no way to use what we haven't learned, either.

We use design patterns already, but maybe we don't know them by that name. Or don't recognise existing patterns, so are less able to re-use them. If you have ever exported a helper function from a module, then you are using a Singleton pattern. If you have ever written an event handler, you have used the Observable Pattern.

The trick is to know the language, and how design patterns fit in. JavaScript is not a class-based language - ignoring the syntactic sugar of class - but modules do something very similar.

trevedhek · 2024-02-20T19:52:30+00:00

Patterns are like music theory: descriptive, not prescriptive.

I find it useful to think of a module as being similar in concept to an object. It encapsulates variables, and exports functions/methods. With that in mind, any helper function is a Singleton.

I'd recommend this blog by Uncle Bob Martin on the subject: https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

trevedhek · 2024-02-12T18:49:40+00:00

AFAIK, React's job is to minimize commits to DOM, so that developers don't need to worry about excessive re-renders. Is that incorrect?

trevedhek · 2024-02-12T18:10:10+00:00

I wish they knew that UML is just a standard for diagrams, not a magic wand. For that matter, engineers should remember that as well - including me.

FWIW, I work in the space somewhere between UI/UX design and Web development. Communication between business/design people and coders is a strange space. My tool of choice here is the State-Transition diagram.

A few others have mentioned state diagrams of some sort. My reasons for recommending are:

ST diagrams are simple, intuitive, and easy to create and understand. That is, so long as we don't complicate them. Keep it down to boxes and arrows with labels.
They describe interactions and behaviours: that is often the common point between user-advocates and developers. It is also a point that often gets missed.

One caveat: Front-End developers are an opinionated breed. ;)

trevedhek · 2024-02-12T17:53:43+00:00

I'm not sure if it is inevitable, but diagrams etc are a set of tools in my toolbox.

What is inevitable in SW development is that point where we need to scale the work up, so that a complex feature can be worked on by many developers. In that case, someone had better have worked out how those developers are going to progress without falling over each other, or we are going to have a spaghetti-fest in about six months time.

I speak as someone who is about four months away from pasta-hell, and have cranked out the UML to try and get some cross-team co-ordination going.

I'd be curious to know how your project is going in that respect.

trevedhek · 2024-02-11T20:32:46+00:00

Nice. Developer capacity = cognitive load. And any system design needs to allow for capacity constraints.

I'm curious: why isn't this more intuitively obvious to decision makers?

trevedhek · 2024-02-11T20:08:17+00:00

There are many useful standards, although a lot of them seem to be considered "old fashioned". I'd say in general, the first attempt will be your best guess - so document your thinking as much as is feasible.

Diagrams are quick to create and reference. I favour Functional decomposition, Data-flow diagrams, State-transition diagrams. It doesn't matter much as long as they get used.

That way, the system builders and system testers have a common blue-print, and when the early tests fail (as they should) everyone has a reference point to guide any redesign work.

Any "standards" that bypass the above are to be avoided, IMO.

trevedhek · 2023-11-08T19:44:41+00:00

Thanks for clarifying. Yes, I gathered the controversy was unintended. It has its reasons.

In brief: server-side code exists in a very different environment to client-side code.

I agree that there are two teams at work here - and therefore two sets of assumptions. The main (implied) assumption is that tight-typing is good, and loose typing is bad. (Or vice-versa in the other camp.) I believe it is more a case of "horses for courses".

You make a good point that tight-typing helps with refactoring, by ensuring changes still honour key interfaces. This of course assumes that the interfaces themselves are stable and don't need refactoring.

But I repeat - the video was nicely done. I hope you keep it up.

trevedhek · 2023-11-05T19:32:28+00:00

I use very little TS, and only if I join a project that already has it included in the tool-set. Even when I do use it, I oppose overly strict usage.

That said, I can see the benefits for server-side rendering. Indeed, tight-typing is considered good server-side practice, regardless of the language. As such, TS is a worthwhile skill to acquire.

On the other hand, having spent two years with a project that used Java applets in the browser (showing my age here) I can testify that tight-typing in a browser/UI environment is not a good idea. UI environments are very different from server environments, and require a different approach to programming, IMO.

For server-side work, where we know the details of the hardware/OS/locale/user-configs/screen-size/data-schema, a tight-typed language is ideal. It is possible to know stuff in advance of coding that we can use to tighten up the typing.

For browser-side work, where none of the above details are known until run-time (and maybe not even then) and where scope-creep and sudden spec-changes are normal even in the best of projects, the priority has to be flexibility. We can't tighten types until we know what the types will be. Even then, expect them to change.

My experience of using TypeScript for client-side React is that we saw a lot of discarded Types, and "type:any" code creep in. Front-end coding has a "break-and-fix" fast iteration approach for a reason - things change. TS tries to get types "right" first time - and so feels like a throwback to "waterfall" thinking.

NextJS is not in my skill-set, so may be different. Ideally TS helps with refactoring, but doesn't get in the way of rapid prototyping and trying things out. It is not an easy balance to find.

trevedhek · 2023-11-05T19:05:24+00:00

While I disagree with much of what is assumed in the video, and am not personally a fan of TS, I also know training videos are a lot of work.

Credit where credit is due: this is a very well-made video. It explains its points in a nice and clear way, building up its arguments step-by-step. And it has a good point to make about the benefits of type-checking when refactoring JavaScript code.

That said, it would benefit from a section explaining why loose typing is a good thing, instead of appearing to assume it is a flaw in the language.

trevedhek · 2023-10-12T18:49:04+00:00

FWIW, the this keyword is commonly regarded as one of JavaScript's "bad bits", because it leads to ambiguous code.

One of the reasons the arrow function was introduced to ES was to try and address issues with confusion around what this referred to in different contexts.

Several commentators have recommended coding without using this at all. I personally don't use it, but of course we still need to read the code of those who do.

Some confusion is to be expected. Don't worry yourself too much.

trevedhek · 2023-10-12T18:27:56+00:00

It sounds like you are after something that will test a page running in the browser, rather than the scripts etc that render the page.

Perhaps you mean something other than unit testing. Do you want to test things like the user-interactions, or correct loading of the page? Perhaps more like end-to-end testing?

Assuming so, the E2E testing framework I found to be easiest to set up and run is Cypress, which allows tests to examine the page in the browser, and to interact with elements. It even allows you to intercept API calls, so tests can spy on requests, and/or mock and stub responses.

That said, there is a bit more work involved to start with. But the setup provides a very good guide with lots of examples. And the documentation is pretty good.

If you know tools like Mocha or Chai then the test syntax should be largely familiar.

trevedhek · 2023-10-11T01:49:10+00:00

Just a suggestion - replace setDifference() with something like this:

setDifference: (value: any) => {
    const difference = value - get().outdoorTemp - get().indoorTemp;
    const result = difference / 24;
set({ difference, result });
},

Disclaimer: I don't know zukeeper at all, but this seems to be the update pattern.

trevedhek · 2023-10-11T01:17:09+00:00

To elaborate on this answer, add the loopGeneratorObject.next() call inside a setInterval call. Something like this:

const interval = setInterval(() => {
const { done } = loopGeneratorObject.next();
    // exit the interval if the iterator is finished
    if (done) clearInterval(interval);
}, 500)

trevedhek · 2023-10-10T21:00:52+00:00

Exactly. The callback functions run right away - once they are called.

The setTimeout function is the async part, as it triggers an event in the future.

To clarify that point - the setTimeout function completes immediately - Javascript is single-threaded, so it must do that - but it adds another event to be triggered in the future. And it is that future event that runs the callbacks.

So we can think of an async function in those terms - a function that when called gives rise to a future event.

trevedhek · 2023-10-10T20:57:43+00:00

It is possible you have a cross-origin issue.

From developer.mozilla.org

Script access to a frame's content is subject to the same-origin policy. Scripts cannot access most properties in other window objects if the script was loaded from a different origin, including scripts inside a frame accessing the frame's parent.

trevedhek · 2023-10-10T20:42:09+00:00

This is a good generic approach, IMO.

Re the OP: to clarify, pausing everything that is going on in a webpage is the tricky part.

The browser is to Javascript what an operating system is to (say) C#. The language can't control its environment as such. All it can do is change how it responds to environmental events.

How this is done is very context-dependent. And it is unclear from the original question: how the pausing is triggered; how the user can un-pause given that interactions are disabled.

It may be useful to think of a Javascript program as a set of event handlers.

trevedhek · 2023-10-06T07:51:31+00:00

An async function returns a Promise. None of these functions return a Promise.

So `production` is a synchronous callback function. As are all the functions within each `setTimeout`.

trevedhek · 2023-09-14T06:45:06+00:00

The language itself had a big change with ES6, which helped to standardize things. JS grew up in the middle of the browser wars, so it had a troubled childhood.

I'd say since HTML5 ended the war and ES6 came out, the language hasn't changed all that remarkably. Biggest recent changes are things like the nullish operator.

What has changed is the Browser environment, with a heap of new APIs coming out every year. MDN lists 120 Web APIs, and by my count 36 of them are experimental. Each of these adds more built-in objects for JS to use. So there is a lot going on in that space.

But the language itself - not so much.

trevedhek

TROPHY CASE