A Look At The Small Web, Part 1

September 10, 2024 by Jenny List 62 Comments

In the early 1990s I was privileged enough to be immersed in the world of technology during the exciting period that gave birth to the World Wide Web, and I can honestly say I managed to completely miss those first stirrings of the information revolution in favour of CD-ROMs, a piece of technology which definitely didn’t have a future. I’ve written in the past about that experience and what it taught me about confusing the medium with the message, but today I’m returning to that period in search of something else. How can we regain some of the things that made that early Web good?

We All Know What’s Wrong With The Web…

It’s likely most Hackaday readers could recite a list of problems with the web as it exists here in 2024. Cory Doctrow coined a word for it, enshitification, referring to the shift of web users from being the consumers of online services to the product of those services, squeezed by a few Internet monopolies. A few massive corporations control so much of our online experience from the server to the browser, to the extent that for so many people there is very little the touch outside those confines. Continue reading “A Look At The Small Web, Part 1” →

Reverse Engineering A Soundsystem’s API

July 31, 2024 by Bryan Cockfield 12 Comments

We’ve all been stymied by a smart thermostat, coffee maker, or other device which would work fine on its own but ultimately seems to be worse off for having an Internet connection — so when something actually pulls off this feat it’s quite noteworthy. [James] has a powerful set of connected speakers and while they don’t have all of the functionality he needed built-in, an included web API at least allowed him to build in the features he wanted.

The major problem with these speakers isn’t that they’re incredibly loud (although they are), but rather that the wide range of available volumes for such a loud soundsystem doesn’t leave a lot of fine adjustment in the range where [James] typically uses these speakers. To tackle the problem, he first found the web interface the speakers present and then discovered a somewhat hidden application programming interface (API) within that allows for some manual control. He built a second website which serves as a volume slider within the range he wants, and the web server sends this volume to the speakers via this API which allows much finer control than the built-in user interface.

Having a usable API included with Internet-connected devices is not always the case, although it’s a great model for any company wanting to allow their customers better control of the products they buy. If you need to roll out your own API for connected devices that don’t have one already, take a look at [Sean Boyce]’s guide from 2019.

Squish That Stack With Rampart

November 24, 2022 by Dave Rowntree 18 Comments

[P B Richards] and [Aaron Flin] were bemoaning the resource hunger of modern JavaScript environments and planned to produce a system that was much stingier with memory and CPU, that would fit better on lower-end platforms. Think Nginx, NodeJS, and your flavour of database and how much resource that all needs to run properly. Now try wedge that lot onto a Raspberry Pi Zero. Well, they did, creating Rampart: a JavaScript-based complete stack development environment.

The usual web applications have lots of tricks to optimise for speed, but according to the developers, Rampart is still pretty fast. Its reason for existence is purely about resource usage, and looking at a screen grab, the Rampart HTTP server weighs in at less than 10 MB of RAM. It appears to support a decent slew of technologies, such as HTTPS, WebSockets, SQL search, REDIS, as well as various utility and OS functions, so shouldn’t be so lightweight as to make developing non-trivial applications too much work. One interesting point they make is that in making Rampart so frugal when deployed onto modern server farms it could be rather efficient. Anyway, it may be worth a look if you have a reasonable application to wedge onto a small platform.

We’ve seen many JavaScript runtimes over the years, like this recent effort, but there’s always room for one more.

Raspberry Pi Tally Lights

January 4, 2021 by Bryan Cockfield 25 Comments

Running a camera studio is a complicated affair from pretty much every angle. Not only is the camera gear expensive but the rest of the studio setup takes care and attention down to the lighting as well. When adding multiple cameras to the mix, like for a television studio, the level of complexity increases exponentially. It’s great to have a few things that simplify the experience of running all of this equipment too, without the solution itself causing more problems than it solves, like these network-operated Raspberry Pi-powered tally lights.

A tally light is the light on a camera that lets the person being recorded know which camera is currently in use. Networking them all together often requires complex wiring or at least some sort of networking solution, which is what this particular build uses. However, the lights are controlled directly over HTTP rather than using a separate application which might need a port open on a firewall or router, which not only simplifies their use but doesn’t decrease network security.

The HTTP interface, plus all of the software and schematics for this build, are available on the project’s GitHub page. We imagine the number of people operating a studio and who are in need of a tally light system to be fairly low, but the project is interesting from a networking point-of-view regardless of application. If you do have a studio like this and are looking for other ways to improve it, we do have a simple teleprompter hack that might be right up your alley.

Think You Know CURL? Care To Prove It?

December 27, 2019 by Donald Papp 5 Comments

Do you happen to remember a browser-based game “You Can’t JavaScript Under Pressure”? It presented coding tasks of ever-increasing difficulty and challenged the player to complete them as quickly as possible. Inspired by that game, [Ben Cox] re-implemented it as You Can’t cURL Under Pressure!

In it, the user is challenged in their knowledge of how to use the ubiquitous curl in a variety of different ways. Perhaps this doesn’t sound terribly daunting, especially if your knowledge of curl is limited to knowing it is a command-line tool to fetch something from a web server. But curl has a staggering number of features. The man page is over 4500 lines in length. The software’s main site offers a (free) 250+ page guide on how to use curl and libcurl. Reflecting on this is exactly what led [Ben] to create his challenge.

It’s a wonderful piece of work, but things get really interesting once [Ben] starts talking about the infrastructure behind it all. At its core the game works by giving the user a problem and a virtual machine, and catching outgoing HTTP calls to see whether they look correct. If the outgoing HTTP call is the right solution for the problem, terminate the current VM and start up the next one with the next problem. He’s put a lot of work into getting suitable VMs up and running quickly, securely, and properly isolated. The code can be found on the project’s GitHub repository for those who want a closer look.

But that’s not all. [Ben] says that in the past he’s had a bad habit of presenting interactive features in his blog posts that can’t keep up with sudden demand. So to address that, the system auto-scales as needed with a small Linux cluster; small brick-sized PCs are started and shut down automatically to meet demand. Hey, the only thing cooler than a functioning cluster is a cluster doing an actual job, like this one that detects NSFW images.

Measuring Web Latency In The Browser

July 21, 2018 by Tom Nardi 8 Comments

We’ll go out on a limb and assume that anyone reading these words is probably familiar with the classic ping command. Depending on which operating system you worship the options might be slightly different, but every variation of this simple tool does the same thing: send an ICMP echo request and wait for a response. How long it takes to get a response from the target, if it gets one at all, is shown to the user. This if often the very first step to diagnosing network connectivity issues; if this doesn’t work, there’s an excellent chance the line is dead.

But in the modern web-centric view of networking, ping might not give us the whole picture. But nature it doesn’t take into account things like DNS lookups, and it certainly doesn’t help you determine what (if any) services the target has available to you. Accordingly, [Liu Zhiyong] has come up with a tool he calls “pingms”, which allows you to check web server latency right from your browser.

Rather than relying on ICMP, pingms performs a more realistic test. It takes the list of targets from the file “targets.js” and connects to each one over HTTP. How does it work? The code [Liu] has come up with will take each target domain name, append a random number to create a gibberish filename, and then calculate how long it takes to get a response when trying to download the file. Obviously it’s going to be getting a 404 response from the web server, but the important thing is simply that it gets the response.

With this data, [Liu] has come up with a simplistic but very slick interface which shows the user the collected data with easy to understand color-coded graphs. As interesting as it is to see how long it takes your favorite web sites or service providers to wake up and start talking, watching the colored bars hop up and down the list to sort themselves is easily our favorite part of pingms.

[Liu] has released pingms under the GPLv3 license, so if you’re looking to utilize the software for your own purposes you just need to provide a list of test targets. If you need to perform low-level diagnostics, check out this handy network tester you can build for cheap.

Control A Quadcopter Over Websockets

December 23, 2017 by Adil Malik 6 Comments

Everyone’s favourite IOT module, the ESP8266, is often the go-to choice for any project that needs quick and cheap control over the web. [Andi23456] wanted to control his quadcopter using the luxury of his mobile phone and thought permanently tethering an ESP12-E module to the quadcopter was exactly what he required.

The ESP8266, really showcasing its all-round prowess, hosts both a web server for a HTML5 based joystick and a Websockets server so that a client, such as a phone, could interact with it over a fast, low latency connection. Once the ESP8266 receives the input, it uses interrupts to generate the corresponding PPM (Pule Position Modulation) code which the RC receiver on the quadcopter can understand. Very cool!

What really makes this realtime(ish) control viable is Websockets, a protocol that basically allows you to flexibly exchange data over an “upgraded” HTTP connection without having to lug around headers each time you communicate. If you haven’t heard of Websockets you really should look really check out this library or even watch this video to see what you can achieve.