Steve Zeidner — Blog

Restoring a 1990 Macintosh Classic

Tue, 14 Jul 2026 00:00:00 GMT

The finished restoration — a 1990 Macintosh Classic, cleaned, recapped, and running again.

I picked up a 1990 Macintosh Classic for $25 at an auction a few years ago. It was just the computer with no keyboard or mouse and there was no indication of the status of whether or not it was working. I got it home and plugged it in to see if it would power up. It turned on but booted to a checkerboard screen. After some initial cleanup and running the motherboard through the dishwasher, it briefly powered to a sad Mac, but then went back to a checkerboard. After a bit of research, I found that any Mac Classic would need the capacitors replaced if it was ever going to run again. I decided that was more than I wanted to invest at that point so it sat on a shelf for several years.

Recently, I came across some people replacing the internals of original Macs with Raspberry Pi’s and iPads. This looked interesting, but as I thought about it more, I realized it was basically just a fancy case for modern hardware and I’d rather have the actual vintage hardware in place. So I looked into what it would take to get this Mac Classic up and running for real. The first order of business was to find a keyboard and mouse. I purchased a pair on eBay for $46 in an auction. About the best price I have seen for a working version. They were quite dirty and yellowed, but that could be cleaned up later.

The eBay keyboard and mouse as they arrived — dirty and badly yellowed, but complete and working.

Next, I figured both the analog and digital boards would need to be re-capped. I followed a wonderful guide here going through all the details of how to properly tear down the Mac Classic and which capacitors needed replacing. I bought a set of capacitors for both boards from Console5. The analog board was pretty straightforward to replace as these are all through-hole capacitors. I replaced all the ones that came in the kit I ordered which I matched by part number but didn’t seem to be an exact match. This seemed to be enough, however to get everything working.

Fully torn down following the guide — CRT, chassis, analog board, and digital board all separated.

The digital board has all surface-mount capacitors which I found much more difficult to both remove and solder on the new ones. They weren’t impossible, just took some patience and more heat to remove. I ended up accidentally removing the pad from one of the capacitors so I had to solder a patch wire to get it to connect. During this process, I used IPA to clean up all the goop that had leaked from the faulty capacitors as best as I could.

The original electrolytic capacitors — the usual failure point on these machines, and the reason for the checkerboard screen.

The analog board back together with a fresh set of capacitors.

After re-capping both boards, I wanted to clean up the plastic that had been yellowed over the years. If you look up how to do this, there are a lot of posts talking about retrobrighting old hardware like this. I thought at first that this was a particular product, but it’s actually using hydrogen peroxide and heat/UV to brighten up and clean up the plastic significantly. There are many guides out there for doing this. I used this restoration as a basic guide for myself. I ended up pulling every key on the keyboard (3D printing a key puller makes this possible) and retrobrighting the computer case, keyboard, and mouse. I think it turned out pretty decent (I ended up doing the keys twice because it was hard to keep them from floating).

Every keycap pulled (a 3D-printed key puller made it possible) so the case, keys, and mouse could all be retrobrighted.

Another thing about these old Macs is that the SCSI hard drives often go bad after sitting for years (or even with a lot of use). The solution here is to replace the hard drive with a BlueSCSI controller and SD card to boot from. This is what I did which allowed me to load an image with a lot more applications than would normally fit on one of those old hard drives.

I also replaced the fan with a quieter Noctua fan and added 2MB of RAM to the expansion card to max out at 4MB.

After re-assembling everything, I was greeted with a very wavy checkerboard pattern again. After warming up for 5 minutes or so, it would actually power on, so it seemed that maybe it just needed some more cleaning. I did an IPA soak of the digital board and really scrubbed every area as best as I could. After that, everything seemed to work as it should. There was a still bit of flicker after booting, however, so I adjusted the potentiometer PP1 slightly on the analog board after measuring the voltages of the floppy drive external port. This is covered in the guide here that I had followed from the beginning. The pot is in the center of the analog board and only needs very slight adjustments to make a large change. It was a bit tricky to get to, but a long small screwdriver did the trick.

So, there it is, the restored Mac Classic. It’s a lot of fun to play with MacPaint, HyperCard, Oregon Trail, and all kinds of fun old apps from my childhood.

Booted up and running Oregon Trail again.

Back in service — 35 years on and still a joy to use.

Load Android Fragments Asynchronously

Sun, 09 Feb 2020 00:00:00 GMT

If you are like me, you may occasionally receive design requests to build a more complex screen in an Android app. So, you set about building the layout, making it look just like the design mocks, and everything works great, except for one small problem. Animating to that screen either stutters or hangs until the screen is loaded. You may have gone back to the layout and refactored everything to be in one ConstraintLayout as Google suggests doing, but it still takes a bit of time to inflate the view because it’s so large. Another trick you may have tried if it’s a long scrolling view is using a library like Epoxy to only load what is currently visible in the scrolled section. This can work in some cases, but it may cause stuttering or undesired visual artifacts while scrolling due to loading each view on the screen as it appears. It may also just be too much time and effort to refactor a complex view in this way.

Thankfully, Google gave us an option to inflate a view asynchronously. It’s called, unsurprisingly, AsyncLayoutInflater and is available both in the v4 support library and is part of AndroidX. Until I discovered this, I thought that all UI (including inflating views) had to be run on the main thread. It turns out that entire layouts can actually be inflated on a background thread with very little change to existing code. There are a few caveats to be aware of before going down this route, but this method works for many different situations.

Caveats

AsyncLayoutInflater does not support inflating layouts that contain fragment. However, a layout can be inflated within a fragment.
The layout’s parent must have a thread-safe implementation of generateLayoutParams(AttributeSet)
All the views being constructed as part of inflation must not create any Handlers or otherwise call myLooper()
When a layout is inflated with AsyncLayoutInflator it does not automatically get added to the parent (i.e. attachToRoot is false)

Some of these caveats may sound like a big deal, but in practice they are not typically an issue.

Converting an existing fragment

The first thing to note if you are converting an existing fragment to inflate asynchronously, is that you can’t just swap out LayoutInflator for AsyncLayoutInflator. The reason being that onCreateView, where the layout inflation occurs, expects a view to be returned. The solution to both asynchronously inflating a layout for a fragment and returning a view from onCreateView is to inflate a small view that the larger view can be attached to. To start with, I created loading_view.xml with a ConstraintLayout and a ProgressBar so there isn’t just an empty screen while loading the rest of the content:

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <ProgressBar
        android:id="@+id/progressBar"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

All that is left then is to inflate this view, asynchronously inflate the large layout and attach it to the loading_view. We should also hide the ProgressBar once the large layout has been loaded.

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    super.onCreateView(inflater, container, savedInstanceState)

    // get view binding
    val v = inflater.inflate(R.layout.loading_view, container, false)
    val asyncLayoutInflater = context?.let { AsyncLayoutInflater(it) }
    asyncLayoutInflater?.inflate(R.layout.large_layout, null) { view, resid, parent ->
        (v as? ViewGroup)?.addView(view) // add large view to already inflated view
        progressBar.visibility = View.GONE // hide progress bar
    }

    return v
}

And, there you have it. A way to load a fragment’s layout asynchronously.

Cloud Backups for a Synology

Sat, 05 Jan 2019 00:00:00 GMT

I have a Synology DS415+ that performs wonderfully as a NAS. It’s used mostly as a place for shared content, Time Machine backups and redundancy of video data. It’s great to have 16TB of available network storage, but there are limited options for a cost-effective cloud backup of multiple terabytes of data.

A couple of years ago, there was one decent option for backing up Synology data to the cloud. Crashplan had an unlimited personal plan for less than $5/month and their client could run directly on the Synology. The downside to Crashplan was that every time the Synology OS would be updated there was risk of the client breaking and needing to be re-installed and/or re-configured. For the price and the self-contained solution, this was an acceptable tradeoff, at least for me. In 2017, Crashplan did away with their personal plan, so this route is no longer an option.

Over the last year, I’ve tried some other options (like hubiC) for larger inexpensive storage. They offer 10TB for €50/year. I didn’t find their control panel or service to be consistently reliable, so I’ve been on the search for other solutions and have two that work decently well. They aren’t without some tradeoffs, but if you are looking for inexpensive, unlimited cloud backup, these are two decent options.

Backblaze over iSCSI

Backblaze offers an unlimited personal backup plan for $5/month that will back up any local drives from a computer. Their client only runs on a Mac or PC, but is written natively for the platform (unlike Crashplan which had a memory-intensive Java client). So, this option requires a dedicated computer to run the Backblaze client and the Synology has to be mounted as a local drive as Backblaze does not support network shares. Remember, I said there were tradeoffs.

A Mac Mini is perfect for this task. It’s small and quiet and can easily be run headless. To set up an iSCSI target on the Synology, open up the iSCSI Manager (from the main menu), click on Target and create a new target and LUN. The wizard will walk you through the creation of both and will have you create a LUN of a size of your choosing. Note that this will be a new drive on your Mac or PC that will be formatted by the operating system. Any data you wish to have backed up will need to be moved or copied to this drive. Again, tradeoffs.

macOS does not come with an iSCSI initiator which is required to mount the iSCSI target as a local drive. The options out there are pretty bleak. Most people recommend globalSAN ($89) or Xtend SAN($249), both of which are pricey options (remember, we are trying to keep this solution cost-effective). A third option I came across was KernSafe, which has a free pricing tier for personal use. This seemed promising from a cost perspective, but I could not get it to work (at least on Mojave). After trying and failing with KernSafe, I decided to give the open source iSCSIInitiator a try. Before installing, you will need to disable unsigned kernel extensions protection by running csrutil disable. I also had a lot of trouble with the downloadable binary on Mojave. I would get segfaults nearly every time I ran the tool (about 1 in 10 tries would give me a successful run). So, you do need to build the tool and install from source which is not a difficult task as the shell scripts work very well (just make sure you have Xcode and tooling installed). This is a command line only tool, so once it’s installed, here is a quick guide to getting it up and running:

> iscsictl add target <target_IQN>,<synology_IP>:3260
> sudo iscsictl modify target-config <target_IQN> -auto-login enable
> iscsictl login <target_IQN>

After running the login command, you should see a prompt that an external drive has been connected. Open DiskManager and format the drive to the file system of your choosing. Add the data to this drive that you wish to back up, install Backblaze, and start backing up to the cloud.

Google Drive Sync

A second option is to sync all your data to Google Drive using Synology’s Cloud Sync app. You can get unlimited data on Google Drive for $10/month if you sign up for G Suite business plan. The admin user on this account will get unlimited storage on Google Drive which is perfect for syncing a large set of data from a Synology. This has none of the tradeoffs of Backblaze over iSCSI; the need for a dedicated computer, a complicated setup, and a separate drive that can’t be easily shared on the network like other NAS shares. However, the big tradeoff of Google Cloud sync is that it is only syncing your data (you can choose if this is bi-directional or one-way sync) and not creating backup sets like Backblaze would do. The Cloud Sync app will also hog all of the upload bandwidth where Backblaze will throttle the upload. To alleviate this, I set the sync schedule of Cloud Sync to only run at night. This method also costs $5 more per month, but does not require the upfront cost of a dedicated computer or the cost of running and maintaining one.

Because each of these options has their tradeoffs, for now, I run both of them to get the best of both worlds. I was already paying for a G Suite business plan and already had a Mac Mini, so there was little additional cost. It also has the benefit of multiple backups being created which is far better than just one backup.

A Small Rust API with Actix

Thu, 10 May 2018 00:00:00 GMT

I had the need for a very small API for this website. So small, in fact, that only one endpoint was required. I’ve been doing a lot of development in Rust lately, so naturally Rust seemed like a good candidate to build this API in. I also wanted to try out a newer Rust web framework called Actix web. It claims to be a “small, pragmatic, and extremely fast rust web framework”, which sounded perfect for what I needed.

Getting started with Actix web is pretty straightforward. First create a new Rust project

cargo new my_api --bin

Cargo (the Rust package manager) is installed along with the popular Rust installer, Rustup. Adding Actix web server to your project can be done by first adding dependencies to Cargo.toml:

[dependencies]
actix = "0.5"
actix-web = "0.6"

and then starting a server in main:

extern crate actix_web;
use actix_web::{server, App, HttpRequest};

fn index(req: HttpRequest) -> &'static str {
    "Hello world!"
}

fn main() {
    server::new(
        || App::new()
            .resource("/", |r| r.f(index)))
        .bind("127.0.0.1:8088").expect("Can not bind to 127.0.0.1:8088")
        .run();
}

The Actix web quickstart guide gives a pretty good overview of getting started with Actix web.

The functionality I wanted for this particular API was to return some stats about my running for the year to display on this website. In order to get that data, I needed to make a couple of GET requests to Running Ahead, parse that data and return a JSON structure showing the total mileage run for the year and mileage from my 5 most recent runs.

{
  "year": "422",
  "latest": [
    "6.9",
    "7.78",
    "6.98",
    "7.71",
    "6.96"
  ]
}

The first thing to do was to figure out how to do the GET requests. Actix (the underlying Actor framework for Actix web) has a ClientRequest struct that allows you to make standard HTTP requests. I used ClientRequest to fetch a page from Running Ahead and return a Boxed Future which parses the resulting content into Vec of String.

/// get mileage for 5 latest runs
fn get_latest() -> Box<Future<Item=Vec<String>, Error=Error>> {
    Box::new(
        client::ClientRequest::get("https://www.runningahead.com/scripts/<my_user_id>/latest")
            .finish().unwrap()
            .send()
            .map_err(Error::from)
            .and_then(
                |resp| resp.body()
                    .from_err()
                    .and_then(|body| {
                        let re = Regex::new(">([0-9]*?.[0-9]*?|[0-9]*?) mi").unwrap();
                        fut_ok(re.captures_iter(str::from_utf8(&body).unwrap())
                            .into_iter()
                            .map(|item| {
                                item[1].to_string()
                            })
                            .collect())
                    })
            ),
    )
}

Note that I’m using str::from_utf8 to convert the body that is returned into a String that can be matched in a regular expression.

The request to get the total mileage for the year is very similar.

/// Get total miles for the year
fn get_year() -> Box<Future<Item=String, Error=Error>> {
    Box::new(
        client::ClientRequest::get("https://www.runningahead.com/scripts/<my_user_id>/last")
            .finish().unwrap()
            .send()
            .map_err(Error::from)
            .and_then(
                |resp| resp.body()
                    .from_err()
                    .and_then(|body| {
                        let re = Regex::new("(?s)<th>Year:</th><td>(.*?) mi</td>").unwrap();
                        let mat = re.captures(str::from_utf8(&body).unwrap()).unwrap();
                        fut_ok(mat[1].to_string())
                    })
            ),
    )
}

Remember that these functions both return Futures as we want to make the requests simultaneously and combine the results when they have both returned. In order to do this, the calls can be chained together and combined in an endpoint like so:

fn running(req: HttpRequest) -> Box<Future<Item=HttpResponse, Error=Error>> {
    get_year()
        .and_then(|miles_year| {
            get_latest().and_then(|miles_latest| {
                Ok(HttpResponse::Ok()
                    .content_type("application/json")
                    .body(serde_json::to_string(&MilesData {
                        year: miles_year,
                        latest: miles_latest,
                    }).unwrap()).into())
            })
        }).responder()
}

All of this got me most of the way to where I needed to be. However, since the calls to Running Ahead are https, SSL needs to be enabled for the Actix dependency. This can be done by adding the alpn feature to Actix:

[dependencies]
actix-web = { version="0.6", features=["alpn"] }

Once I had alpn enabled, all worked well on my local (macOS) machine. However, when I went to deploy to a Linux server with an nginx process to provide SSL, I was met with a strange error message:

Error occured during request handling: Failed to connect to host: OpenSSL error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1245:

Very strange. After much Googleing, I found a reference that suggested trying openssl-probe. This tool searches out locations of SSL certificates on the system and was exactly what I needed. Using openssl-probe requires adding the dependency to Cargo.toml

[dependencies]
openssl-probe = "0.1.2"

and adding adding this to the src/main.rs

extern crate openssl_probe;

fn main() {
    openssl_probe::init_ssl_cert_env_vars();
    //... your code
}

Here is the final Cargo.toml

[package]
name = "stevezeidner-api"
version = "0.1.0"
authors = ["Steve Zeidner <steve@stevezeidner.com>"]

[dependencies]
futures = "0.1"
env_logger = "0.5"
actix = "0.5"
actix-web = { version="0.5", features=["alpn"] }
openssl-probe = "0.1.2"

serde = "1.0"
serde_json = "1.0"
serde_derive = "1.0"
json = "*"
regex = "0.2"

and source for src/main.rs

#![allow(unused_variables)]
#![cfg_attr(feature = "cargo-clippy", allow(needless_pass_by_value))]

extern crate actix;
extern crate actix_web;
extern crate env_logger;
extern crate futures;
extern crate json;
extern crate openssl_probe;
extern crate regex;
#[macro_use]
extern crate serde_derive;
extern crate serde_json;

use actix_web::{App, AsyncResponder, error, Error, fs,
                HttpMessage, HttpRequest, HttpResponse, pred, Result, server};
use actix_web::{client, middleware};
use actix_web::http::{Method, StatusCode};
use futures::{Future, future::ok as fut_ok};
use regex::Regex;
use std::{env, io};
use std::str;

#[derive(Debug, Deserialize, Serialize)]
struct MilesData {
    year: String,
    latest: Vec<String>,
}

/// Get total miles for the year
fn get_year() -> Box<Future<Item=String, Error=Error>> {
    Box::new(
        client::ClientRequest::get("https://www.runningahead.com/scripts/<my_user_id>/last")
            .finish().unwrap()
            .send()
            .map_err(Error::from)
            .and_then(
                |resp| resp.body()
                    .from_err()
                    .and_then(|body| {
                        let re = Regex::new("(?s)<th>Year:</th><td>(.*?) mi</td>").unwrap();
                        let mat = re.captures(str::from_utf8(&body).unwrap()).unwrap();
                        fut_ok(mat[1].to_string())
                    })
            ),
    )
}

/// get mileage for 5 latest runs
fn get_latest() -> Box<Future<Item=Vec<String>, Error=Error>> {
    Box::new(
        client::ClientRequest::get("https://www.runningahead.com/scripts/<my_user_id>/latest")
            .finish().unwrap()
            .send()
            .map_err(Error::from)
            .and_then(
                |resp| resp.body()
                    .from_err()
                    .and_then(|body| {
                        let re = Regex::new(">([0-9]*?.[0-9]*?|[0-9]*?) mi").unwrap();
                        fut_ok(re.captures_iter(str::from_utf8(&body).unwrap())
                            .into_iter()
                            .map(|item| {
                                item[1].to_string()
                            })
                            .collect())
                    })
            ),
    )
}

fn running(req: HttpRequest) -> Box<Future<Item=HttpResponse, Error=Error>> {
    get_year()
        .and_then(|miles_year| {
            get_latest().and_then(|miles_latest| {
                Ok(HttpResponse::Ok()
                    .content_type("application/json")
                    .body(serde_json::to_string(&MilesData {
                        year: miles_year,
                        latest: miles_latest,
                    }).unwrap()).into())
            })
        }).responder()
}

/// 404 handler
fn p404(req: HttpRequest) -> Result<fs::NamedFile> {
    Ok(fs::NamedFile::open("static/404.html")?
        .set_status_code(StatusCode::NOT_FOUND))
}

fn main() {
    openssl_probe::init_ssl_cert_env_vars();
    env::set_var("RUST_LOG", "actix_web=debug");
    env::set_var("RUST_BACKTRACE", "1");
    env_logger::init();
    let sys = actix::System::new("stevezeidner-api");

    let addr = server::new(
        || App::new()
            // enable logger
            .middleware(middleware::Logger::default())
            .middleware(middleware::DefaultHeaders::new()
                    .header("Access-Control-Allow-Origin", "*"))
            .resource("/running", |r| r.method(Method::GET).a(running))
            .resource("/error", |r| r.f(|req| {
                error::InternalError::new(
                    io::Error::new(io::ErrorKind::Other, "test"), StatusCode::INTERNAL_SERVER_ERROR)
            }))
            // default
            .default_resource(|r| {
                // 404 for GET request
                r.method(Method::GET).f(p404);

                // all requests that are not `GET`
                r.route().filter(pred::Not(pred::Get())).f(
                    |req| HttpResponse::MethodNotAllowed());
            }))

        .bind("127.0.0.1:8888").expect("Can not bind to 127.0.0.1:8888")
        .shutdown_timeout(0)    // <- Set shutdown timeout to 0 seconds (default 60s)
        .start();

    println!("Starting http server: 127.0.0.1:8888");
    let _ = sys.run();
}