Tags: coding

171

sparkline

Saturday, August 7th, 2021

Making Reasonable Use of Computer Resources

The paradox of performance:

This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?

Because we prioritise the developer experience over the user experience, that’s why:

Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.

We would do well to heed Craig’s observations on Fast Software, the Best Software.

Tuesday, August 3rd, 2021

How To Build Resilient JavaScript UIs — Smashing Magazine

The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:

Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.

Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.

I love, love, love the emphasis on reducing assumptions:

Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.

Hell, yeah!

Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).

Friday, June 4th, 2021

Beginner JavaScript Notes - Wes Bos

A very handy collection of organised notes on all things JavaScript.

Thursday, April 29th, 2021

CSS Hell - To Hell with bad CSS!

Collection of common CSS mistakes, and how to fix them.

I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.

Sunday, April 18th, 2021

trapped in the technologist factory

New technologies don’t have power; for that they’d need a community, documentation, and a thriving ecosystem of ancillary technology. What they have is potential, which resonates with the potential within the startup and the early adopter; perhaps they can all, over time, grow together.

This means startups don’t adopt new technologies despite their immaturity, they adopt them because of that immaturity. This drives a constant churn of novelty and obsolescence, which amplifies the importance of a technologist’s skillset, which drives startups to adopt new technologies.

This flywheel has been spinning for a long time, and won’t stop simply because I’ve pointed out that we’re conflating novelty with technological advancement. Hopefully we can slow it down, though, because I believe it’s causing real harm.

Tuesday, April 6th, 2021

Web Browser Engineering

It’s heavy on computer science, but this is a fascinating endeavour. It’s a work-in-progress book that not only describes how browsers work, but invites you to code along too. At the end, you get a minimum viable web browser (and more knowledge than you ever wanted about how browsers work).

As a black box, the browser is either magical or frustrating (depending on whether it is working correctly or not!). But that also make a browser a pretty unusual piece of software, with unique challenges, interesting algorithms, and clever optimizations. Browsers are worth studying for the pure pleasure of it.

See how the sausage is made and make your own sausage!

This book explains, building a basic but complete web browser, from networking to JavaScript, in a thousand lines of Python.

Wednesday, March 31st, 2021

esoteric.codes

Languages, platforms, and systems that break from the norms of computing.

Friday, March 12th, 2021

Vendor by default - macwright.com

I never knew that the way I add other people’s code to my projects is called “vendoring.” I thought it was just copying and pasting.

Monday, December 21st, 2020

Web Audio API weirdness on iOS

I told you about how I’m using the Web Audio API on The Session to generate synthesised audio of each tune setting. I also said:

Except for some weirdness on iOS that I had to fix.

Here’s that weirdness…

Let me start by saying that this isn’t anything to do with requiring a user interaction (the Web Audio API insists on some kind of user interaction to prevent developers from having auto-playing sound on websites). All of my code related to the Web Audio API is inside a click event handler. This is a different kind of weirdness.

First of all, I noticed that if you pressed play on the audio player when your iOS device is on mute, then you don’t hear any audio. Seems logical, right? Except if using the same device, still set to mute, you press play on a video or audio element, the sound plays just fine. You can confirm this by going to Huffduffer and pressing play on any of the audio elements there, even when your iOS device is set on mute.

So it seems that iOS has different criteria for the Web Audio API than it does for audio or video. Except it isn’t quite that straightforward.

On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!

It’s almost like playing a video or audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.

This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.

Following my theory that the browser needs a “kick” to get into the right frame of mind for the Web Audio API, I resorted to a messy little hack.

In the event handler for the audio player, I generate the “kick” by playing a second of silence using the JavaScript equivalent of the audio element:

var audio = new Audio('1-second-of-silence.mp3');
audio.play();

I’m not proud of that. It’s so hacky that I’ve even wrapped the code in some user-agent sniffing on the server, and I never do user-agent sniffing!

Still, if you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.

Tuesday, November 10th, 2020

Operator Lookup - Search JavaScript operators · Josh W Comeau

Operators in JavaScript—handy! I didn’t know about most of these.

Sunday, September 27th, 2020

‘Real’ Programming Is an Elitist Myth | WIRED

The title says it all, really. This is another great piece of writing from Paul Ford.

I’ve noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.

Friday, July 31st, 2020

Pinboard is Eleven (Pinboard Blog)

I probably need to upgrade the Huffduffer server but Maciej nails why that’s an intimidating prospect:

Doing this on a live system is like performing kidney transplants on a playing mariachi band. The best case is that no one notices a change in the music; you chloroform the players one at a time and try to keep a steady hand while the band plays on. The worst case scenario is that the music stops and there is no way to unfix what you broke, just an angry mob. It is very scary.

Saturday, July 11th, 2020

A little bit of plain Javascript can do a lot

I decided to implement almost all of the UI by just adding & removing CSS classes, and using CSS transitions if I want to animate a transition.

Yup. It’s remarkable how much can be accomplished with that one DOM scripting pattern.

I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do.

Monday, June 22nd, 2020

Always bet on HTML | Go Make Things

I teach JS for a living. I’m obviously not saying “never use of JS” or “JavaScript has no place on the web.” Hell, their are even times where building a JS-first app makes sense.

But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.

Monday, June 8th, 2020

Easily rename your Git default branch from master to main - Scott Hanselman

Nice and straightforward. Locally:

git branch -m master main git push -u origin main

Then on the server:

git branch -m master main git branch -u origin/main

On github.com, go into the repo’s settings and update the default branch.

Thanks for this, Scott!

P.S. Don’t read the comments.

Saturday, May 30th, 2020

Global CSS options with custom properties | @mdo

This is clever—using custom properties to enable if/else logic in CSS.

Tuesday, May 26th, 2020

Today’s Javascript, from an outsider’s perspective | Lea Verou

This is a damning and all-too typical example of what it’s like for someone to trying to get to grips with the current state of the JavaScript ecosystem:

Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?

I think it’s even worse than that. Not only are potential new devs being put off ever getting started, I know plenty of devs with experience who have pushed out by the overwhelming and needless complexity of the modern web’s toolchain. It’s like a constant gaslighting where any expression of unease is summarily dismissed as being the whinings of “the old guard” who just won’t get with the programme.

John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.

The End.

(Just watch as Lea’s post gets written off as an edge case.)

Sunday, May 17th, 2020

Write Libraries, Not Frameworks by Brandon Smith

This is a very clear description of the differences between libraries and frameworks, along with the strengths and weaknesses of both.

A library is a set of building blocks that may share a common theme or work well together, but are largely independent.

A framework is a context in which someone writes their own code.

I very much agree with the conclusion:

If your framework can be a library without losing much, it probably should be.

Wednesday, May 13th, 2020

Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY

Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.

This is all just mwah—chef’s kiss!—perfect:

Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.