However, when nginx reverse proxies to the Nuxt server using a configuration like the following, the application will load correctly in the browser but Vite (bundled with Nuxt) will no longer be able connect to its backend websocket server to provide hot module replacement (HMR).

location / {
    proxy_pass http://localhost:3000;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

To fix this, Vite needs to be made aware it’s being reverse proxied, and nginx needs to pass through Vite’s websocket connection.

In the Nuxt config (nuxt.config.ts), add the following Vite config:

vite: {
  server: {
    hmr: {
      protocol: 'wss',
      clientPort: 443,
      path: 'hmr/'
    }
  }
}

Vite will now use the secure websocket protocol over the same HTTPS port as the application, but it will request it at a new, distinct path.

In the nginx config, add a new location directive to match the configured Vite path (/_nuxt is always prepended), have it perform an HTTP Upgrade, and then reverse proxy to Vite’s websocket server, which always listens on port 24678:

location /_nuxt/hmr/ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_pass http://localhost:24678;
}

After restarting the development server and nginx, Nuxt 3 and Vite HMR work great behind nginx, which now handles TLS termination and reverse proxying of HTTP and websocket traffic.

Update 2023-09-28

As of Nuxt 3.7.4, the nuxt.config.ts configuration is unnecessary, though having the following nginx config in place avoids a WebSocket error about the WebSocket host being undefined:

location /_nuxt/ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
    proxy_pass http://localhost:3000;
}

Note the differences from the above config – the location path dropped hmr/, the Vite HMR port (24678) became the default Nuxt port (3000), and the Host header was also added (but the Host header is likely not critical for this scenario).

1. Install XQuartz from the official distributed disk image
2. brew install cmake glew
3. git clone https://github.com/n64dev/cen64.git
4. cd cen64
5. mkdir build
6. cd build
7. cmake ..
8. make

If you’d like to enable cen64’s debug logging, create a debug build when running cmake:

cmake -DCMAKE_BUILD_TYPE=Debug ..

When running cen64 outside of an XQuartz X11 terminal, it may report:

Using NTSC-U PIFROM
create_device: Failed to initialize the VI.
Failed to create a device.

To fix this, you can run it within an XQuartz X11 terminal, or set the DISPLAY environment variable to something like :0 either in your .bashrc file or inline during invocation:

DISPLAY=:0 ./cen64 /path/to/pifdata.bin /path/to/rom.z64

DISPLAY needs to be set because cen64 calls XOpenDisplay with a NULL display name (presumably to default to your DISPLAY environment variable), but if it’s not set, XOpenDisplay returns NULL and cen64 has no display within which to create a window for rendering Nintendo 64 content.

For extremely verbose register-level output, edit CMakeLists.txt and set DEBUG_MMIO_REGISTER_ACCESS to ON. Make sure to remove any cached data in build/ to ensure your changes are reflected, then recompile and re-run.

Update 2024-03-02

Development on cen64 has not progressed in many months and is now considered unmaintained. ares, a cross-platform, open source, multi-system emulator is now regarded as the best emulator for Nintendo 64 development.

We also use Slack for team chat and various notifications, so integrating the coffee machine status was a no-brainer. Using a non-invasive/inductive current sensor and Raspberry Pi, the following setup monitors coffee machine energy consumption and waits for a significant rise in current draw, followed by several minutes of sustained usage. Once a time threshold has passed, it does an HTTP POST to a Slack webhook, sleeps for about 15 minutes, then starts monitoring again. This “brewbot” code is available on GitHub, and a parts list can be found below.

Full parts list:

• MCP3008 8-Channel 10-Bit Analog to Digital Converter
• Raspberry Pi model B
• 16-pin IC socket
• Assortment of heat shrink tubing
• Panel mount to Micro USB adapter
• 10KΩ 1/4W LED resistor
• Half-size Perma-Proto Raspberry Pi Breadboard PCB Kit
• 5mm Yellow LED
• 1/8” panel mount audio jack
• 10uF electrolytic decoupling capacitor
• 33Ω 1/2W burden resistor
• 2x 470KΩ 1/2W voltage divider resistors
• 30A non-invasive current sensor
• 22 AWG Solid Core Hook Up Wire
• 5x7 photo box, from The Container Store
• 8 GB Class 10 SDHC card
• Edimax EW-7811Un Wireless Nano USB Adapter
• 6x Nylon screws washers and nuts
• 8” AC Cord Clips
• HDMI to Mini HDMI adapter
• 6’ Mini HDMI to HDMI Cable
• 10’ USB A Male to B Male Cable

Related reading: Hyper Text Coffee Pot Control Protocol

Working with Joe Taylor and Eric Littlejohn, our Hackathon project set out to make the office bathroom availability more visible and accessible through a combination of hardware and software. The piece of the project that lets this all work is a microswitch installed inside each door jamb, such that when the locking bolt is engaged, the switch is tripped. That way, we can do anything with resulting data, knowing that when the door is locked, the room is in use. Running wire down through the hollow metal trim was tedious and time consuming, and involved a lot of false starts and fishing around with a straightened coat hanger, but we finally got a run of wire inside each frame.

On each office floor there are two bathrooms side by side, and the pair of switches inside the door jambs are wired to a single Arduino fitted with an Ethernet Shield for network connectivity. The Arduino samples the switches many times per second, providing near-instant feedback.

After debouncing the switch input signal over about 50 milliseconds, the Arduino waits for a definitive change in state – from locked to unlocked, or unlocked to locked – before illuminating LED lights on the wall.

After the light corresponding to the now-occupied bathroom is lit, the Arduino also performs an HTTP POST, sending the event details (floor level, which room, and current occupancy state) to an in-house webserver running Node.js and MongoDB. The webserver records the data and makes it visible on a web page for viewers to check the availability digitally, for those who can’t see the wall mounted lights from their seating position.

If you’d like to employ a project like this, the code we hacked together is available on GitHub, and the wiring is rather straightforward:

• All components share a common ground
• LED anodes are wired to room_a_led_pin and room_b_led_pin and brought high when doors are locked, and low when unlocked
• Switches bring room_a_switch_pin and room_b_switch_pin low when triggered, and the Arduino uses the INPUT_PULLUP pinMode for the unlocked state

Our Hackathon project came in at second place, losing to an as-yet-unannounced software project, but we had a lot of fun staying up and hacking all night!

Installing the Nest is pretty straightforward with a modern forced air heating and cooling system:

• Remove the old thermostat and mounting plate from the wall
• Disconnect the wires
• Patch and paint any holes
• Install the Nest mounting base and connect the wires
• Pop the Nest onto the base and configure the software

My initial install went well physically, but not long after, I discovered that the Nest would regularly run out of battery power. I quickly learned that due to how the HVAC circuits are arranged, the Nest can only draw power while the system is running. When the system is not busy heating, cooling, or running the fan, the Nest is left to run under its own battery power. And in sunny California during the springtime, the system doesn’t run often enough to let the Nest keep a charge. Several times per day, I would have to unplug the Nest from its base and charge it over micro USB. Not a great solution.

Reading more about the Nest and HVAC circuitry, I found that there is a solution for situations like this. A “common wire” that provides a path back to the HVAC controller would allow the Nest to draw the power it needs while not running any systems. As luck would have it, my system provided this common wire, but connecting it to the Nest had no effect on the battery. More telling was the fact that the Nest did not detect that the wire was connected.

So, I decided to find out what was at the other end of that common wire. I put up a ladder and ventured into the attic of my home and scouted around the furnace. On top of it, inside an easily-opened metal enclosure, was the thermostat controller, a ZTech ZTE2S. Double checking the wiring diagram and comparing it with the wires on the left (coming from the Nests), it’s clear that the blue common wire is simply not connected to the controller. In the photo below, you can see that it’s clipped short, close to the brown jacket covering the bundle of five wires.

Reconnecting the wire was a matter of disconnecting the wires that were already connected, snipping them all to the same length, and stripping a little plastic off the end so that all five can be connected to the HVAC controller.

A few hours after leaving the Nest installed with the common wire attached and the HVAC controller all closed up, its battery has fully charged and the features work great.

To ensure your app performs well under real-world conditions, you can load up the code on a device and go outside, but then you can’t debug as easily. And even if you bring your MacBook Air with you, what if your Verizon iPhone is everything you hoped, and it performs admirably on the worst of days? To get around all of this, you can approximate an unreliable network with SpeedLimit. SpeedLimit is a System Preferences pane for intentionally and selectively slowing down specific ports and domains.

Download and install SpeedLimit, add one or more hosts (separated by commas, as seen above), select a target speed, and click Slow Down. Subsequent network requests matching the criteria you set will be throttled, giving you time to go all out testing your app’s performance and error handling. Does it crash when users hit the Back button while a UITableView is loading? Does it lock the UI while downloading avatars or thumbnails? SpeedLimit lets you find out, and be confident in your networking code.

Find Out Who Made the Device

Figuring out which company made the device(s) in question is the first step towards getting it working. Start by opening the Windows Device Manager. My preferred quick way of doing this is clicking Start, Run, type devmgmt.msc, and pressing Enter. Once there, choose the device in question and right click it, and select Properties. Select the Details tab to see something like the view below:

Note the PCI VEN and DEV 4-character identifiers. PCI, USB, and many other system devices have Vendor and Device IDs. The Vendor ID is specific to the manufacturer, like Broadcom or nVIDIA. The Device ID is specific to the particular make or model of device you have. These are expressed in hexadecimal (0 through 9 plus A through F), so don’t be surprised to see letters there, as well. Some common Vendor IDs are 8080 and 8086 for Intel, 0A5C for Broadcom, 10DE for nVIDIA, 1002 for ATI, and many more.

Look Up Vendor and Device IDs

A common way to express both the Vendor and Device IDs in a single string is 1022:2000, Vendor ID first. Combine your Vendor and Device IDs in this manner, and wrap it with quotes: “1022:2000”. Google that, and you should quickly figure out who made your “Unknown device” and what model it is. With this knowledge, you can either find the appropriate driver on your computer manufacturer’s website (Dell makes a good note of which manufacturer’s devices they use for a particular system), or you can visit the device manufacturer’s website directly.

I hope this information can help those looking to simply get their hardware working under Windows, whether it’s running on a Mac or PC.

What You’ll Need

• a MacAlly IceKey
• a small, narrow USB hub (a cheap Targus hub worked fine for me)
• a screwdriver set
• a soldering iron, solder, and spare wire
• a pocket knife (I’m not sure any project I’ve done didn’t require this…)

Open the Hub

USB hubs generally aren’t too complicated to open, and this Targus on is no exception. A single screw on the underside holds together the hub’s two plastic halves, which snap apart with little effort. Write a note or take a picture to document the wire colors and order relevant to the orientation of the board inside – it will come in handy later.

Open the Keyboard

The MacAlly IceKey is slightly trickier to get apart, but not much. Remove all the obvious screws on the bottom of the keyboard, including the one under the “Do Not Remove”/Quality Control/Warranty sticker. Then, flip open the pivoting feet to expose two more screws covered by a protective piece of rubber. The final two screws are under the front rubber feet.

Starting with the keyboard upright and facing you, begin unsnapping the plastic hooks around the perimeter starting at the front middle. A plastic pry tool might come in handy, but isn’t required. Once the top is removed, you can clearly see all the important electronics, including a very common Cypress USB controller chip.

Test Fit Everything

Just to make sure the rest of this modification is physically possible, fit the USB hub board in the open space at the top of the keyboard and set the keyboard bezel on top. Luckily, the IceKey has plenty of room to spare. I was planning to have to remove the USB ports from the hub board to make everything fit, but there was so much extra space that I didn’t even have to go to that length.

Unhook the Keyboard

Carefully pull the keyboard ribbon cables straight away from their matching plugs on the controller board. Gently flip the keyboard pad over, and unscrew the two short ground wires to completely free the keyboard keys from the plastic housing. Set it aside for later; it does not need to be modified – all the action happens on the two remaining circuit boards. Unscrew both boards to get at the backs of each.

Cut Wires

Cut the gray ribbon that leads from the controller board to the left port. Since that wire only provides USB 1.1 speed, we won’t be using it. You’ll note that it has two extra wires that run to an unpopulated LED on the left board, so we can skip those when doing the re-wiring. (I wonder what MacAlly had in store for that, or if this keyboard is a “port” from another language or something?)

Unplug the USB cord from the controller board and cut off the connector. This cord needs to run to the input on the new USB hub, and not to the input on the keyboard controller board where it currently connects.

Cut Traces

Since the right port also needs USB 2.0 speeds, it too will need to be disconnected from its USB 1.1 source. However, it is soldered directly onto the controller board and is effectively hard-wired into the slowness. This is perhaps the trickiest part of the whole project: desolder the USB connector and use a knife to scrape away the traces that run to the port. Some are on top of the board, and some are on the bottom. (You might be able to get away with cutting the traces without removing the port, as a little bit of the traces are exposed on the top before routing into electronic components, but you’ll want to test with a multimeter and make sure you’ve done this successfully.) Once all four traces to the port are cut, re-solder the USB port in place (if you removed it).

Re-wire the Keyboard Controller and Ports

Here’s a simple before and after block diagram to help your wiring layout:

Solder Keyboard Cord to Hub Input

Strip about an inch of plastic from the cut end of the keyboard cord to expose its individual wires, and strip just a millimeter or two from each of those. Using your note from earlier, solder the keyboard wires to the matching USB hub input connections. On this Targus hub, the wires were in the same order as the standard USB pinout.

Solder Keyboard Controller to a Hub Port

Solder four wires from the keyboard input port (where the cord originally connected to) to one of the USB hub ports, effectively making the keyboard controller into one of four devices on the hub. Previously, the keyboard supplied its own hub, but we’re bypassing it altogether. Luckily, most everything is either color coded or silkscreen labeled on the circuit boards (V/5V is red, D- is green, D+ is white, and G/GND is black).

Solder Keyboard USB Ports to Hub Ports

Solder wire from the left USB port board to another free USB hub port, making sure to get the order correct. With the traces cut on the right port, run wire from the connections under the board to yet another free hub port. You should end up with a hub layout like this:

Test and Close It Up

With each new component wired up, double-check your connections and plug it in. Initially, my first test failed and Windows complained about a malfunctioning USB device (I tested it on an old PC, just in case I shorted out the computer’s USB controller. I’d rather fry an old computer than my new iMac!) The key to making everything work properly was to reconnect those two shared ground wires from early on – the keyboard must have a common ground with the controller and hub!

Once it works, secure all the wires and boards. I used a few short pieces of electrical tape to stop everything from bouncing around, too. Snap the plastic top back on, replace all the screws, and enjoy your USB 2.0 MacAlly IceKey!

Graphics Drivers

Visit nVidia and download the “GeForce 9M Series (Notebooks)” driver package, as this is graphics chipset in the Early 2009 iMacs. Run the downloaded setup utility, next-next-nexting your way through the steps, and reboot at the end when prompted. Upon restart, you’ll be able to properly max out your display to the iMac’s native resolution.

Audio Drivers

Boot Camp 2.1 actually ships with RealTek HD audio drivers, as evidenced by the lack of a yellow exclamation mark for this system in Windows’ Device Manager, but they don’t seem to work properly, since there’s no sound output. Visit RealTek and download the “High Definition Audio Codecs” driver package for your OS. In this instance, I downloaded “Windows 2000, Windows XP/2003(32/64 bits) Driver only (Executable file)”, since I’m running Windows XP Pro SP2. Run this setup utility as well, rebooting again when done. After restarting, you should be greeted with Windows’ standard login sound, confirming the install worked.

Update: The Mac OS X 10.6 Snow Leopard disc includes Boot Camp drivers for these iMacs. The Snow Leopard disc is a hybrid image: it provides the Mac OS X installer when viewed under a Mac OS X system, but shows Windows drivers when viewed in Windows. Just run the setup in Windows right off the disc, and you should be set.

Sync Your Apps with iTunes

Assuming you already have the target application on your iPhone or iPod Touch (just “iPhone” from this point forward for brevity’s sake), simply sync your iPhone with your Mac or PC. Doing so will backup your device and transfer any purchased applications in both directions. With the target application now on your computer, navigate to your iTunes “Mobile Applications” folder, where iTunes typically does its own file housekeeping. Under Mac OS X, the default location is /Users/yourname/Music/iTunes/Mobile Applications/.

Unzip an App

Copy your target .ipa-suffixed application to a different location, ensuring that the original stays in the Mobile Applications folder to keep iTunes happy. To get inside the application, rename its extension to .zip. Open the zip file, and you will have access to the guts of the app (except the source code, of course).

High-res App Artwork

Directly inside the unzipped application folder, you’ll find a file named iTunesArtwork, with no extension. A hex editor revealed that the file is typically a jpeg image, so rename it to include .jpg at the end, and you’ll end up with the same 512x512 pixel artwork displayed by iTunes when browsing downloaded Applications. To get at other resources, open up the adjacent “Payload” folder, and you’ll find a .app file – the application bundle that runs on the iPhone. Right- or Control-click on the .app, and choose “Show Package Contents” to open up the bundle.

Sounds

Sounds are typically found among the many resources directly inside the application as files with extensions like .caf, .mp3, .aif, and .m4a. At this point, the organizational structure is up to the application’s developer, so you may need to look around a little. Leopard’s QuickLook feature is a boon in times like this, helping assess a file’s purpose without opening half a dozen applications.

Other Graphics

Also nestled inside iPhone applications are many of the graphics used throughout the app. It’s possible that some may be drawn by code, but complex graphics are generally stored as images. However, viewing the images isn’t as easy as renaming the files as before. This will be a bit trickier, as the iPhone works some magic on the images before finishing the app build process, leaving images in an iPhone-optimized state. Fortunately, the process can be reversed with a little bit of Terminal trickery:

1. Copy all .png images to a new folder elsewhere. Images of other formats (.jpg, .gif, etc.) should be readily viewable.
2. Download David Watanabe’s modified iPhonePNG command-line application, unzip the archive, and open up Terminal from your /Applications/Utilities folder.
3. Type cd , then drop the iPhonePNG folder into the Terminal, and tap Return to switch to that folder.
4. Type ./iPhonePNG , drop the folder of encoded images into the Terminal, and tap Return to decode the whole folder full of images.
5. The output folder sites beside iPhonePNG, so type open . and tap Return (open space dot) to open the current folder (a dot, in Unix terms) in the Finder. Open the decoded images folder and have a look around!