The State Fair of Texas:

After extensive consideration of the current landscape related to the COVID-19 pandemic and the health and safety of all fairgoers, staff, business partners, and overall community, the State Fair of Texas Board of Directors has voted to cancel the 2020 State Fair of Texas. 

 “This was an extremely tough decision. The health and safety of all involved has remained our top priority throughout the decision-making process,” said Gina Norris, board chair for the State Fair of Texas. “One of the greatest aspects of the Fair is welcoming each and every person who passes through our gates with smiles and open arms. In the current climate of COVID-19, there is no feasible way for the Fair to put proper precautions in place while maintaining the Fair environment you know and love. While we cannot predict what the COVID-19 pandemic will look like in September, the recent surge in positive cases is troubling for all of North Texas. The safest and most responsible decision we could make for all involved at this point in our 134-year history is to take a hiatus for the 2020 season.” 

I'm not surprised, but seeing the news still makes me sad.

This won't be the first time in the Fair's 134 years that it's been cancelled.

The State Fair of Texas has previously canceled Fairs because of World War I (1918), planning for the 1936 Texas Centennial Exposition and 1937 Pan American Exposition at Fair Park (1935 – 1937), and World War II (1942 – 1945). 

The 2021 State Fair of Texas is scheduled to run Friday, September 24 through Sunday, October 17 in historic Fair Park.

I look forward to being there.

If you want to look at historic homes in Dallas, there are a a few options of places to look. You could visit the Dallas Heritage Village. Located on what used to be Dallas's first city park, the Dallas Heritage Village is a collection of 21 historic buildings that functions as a glimpse of what life used to be like in Dallas in the late 19th century.

Your other option would be to visit one of Dallas's designated landmark districts. These are neighborhoods protected by ordinances with preservation criteria, specific to each district, administered by the the city's Landmark Commission. These ordinances preserve the homes within the districts by protecting them from willful neglect, demolition, and any renovations that aren't appropriate for the time period.

Visiting either DHV or a landmark district will be like taking a step back in time. You will get a sense of how things used to be (for better or for worse) and learn a little about our history.

There is however, one crucial distinction between DHV and a landmark district. While DHV is a collection of actual buildings, it functions as a large outdoor museum. Those buildings exist to educate. Landmark districts, however, are functioning neighborhoods. You can learn some history from these buildings, but they primarily function as homes for families today.

This distinction influences how these buildings are maintained. DHV's main concern is preserving every historical detail possible with their buildings. Any renovation work needs to be carefully done, so the final product still looks like a preserved historical artifact.

Homes in landmark districts are, well, … homes. The families that live in them have 21st-century needs and expectations. You can't live in a preserved historical artifact. These building need modern amenities like electricity, plumbing, central air conditioning, and internet access. They need bathrooms, kitchens with modern appliances, etc. Maintaining a home in a landmark district means finding ways to add these modern affordances while still maintaining the original character of the building.

I am familiar with this because my family lives in a house inside a landmark district, and we are currently renovating the kitchen.

And while it would be fun to dig into the details of our kitchen project, this is actually a blog post about software.

For the past several years I have been maintaining a software project called Frontier. I'll save the story of how I came to be doing this for another time. I also hesitate to use the word maintain to describe my actions. Mostly I've been tinkering, reading the source code, learning, and doing the bare minimum to keep it running on modern computers.

If you read through the source code, you can get a sense of the time of when this application was built. Frontier started it's live as a (classic) Macintosh application. Most of the design decisions in the code seem to be built around the constraints of that computing platform. In the late 1990s it was ported to Windows, and in the early 2000s the application was Carbonized to run natively on Mac OS X. You can see all those layers in the source code.

Sadly, Frontier doesn't run at all on the latest version of Mac OS X macOS. While software doesn't wear down or rot like physical structures, computing platforms do change, and if the software doesn't change with the platform, it will eventually stop working.

So I've been thinking about how to approach "restoring" Frontier, and this ties back to the beginning of this post. What is Frontier today? Is it a historical artifact that needs to be preserved "just as it was", or is it a functioning application that caters to the needs of modern computer users?

If it's the former, then I don't think there's much more to do. Frontier runs fine under emulation. I could put together some documentation for how to emulate a classic Macintosh system that runs an older copy of Frontier. I would keep the source code up on GitHub for people to study and that would be it.

If it's the latter, then there's a lot of work to do. I basically need to strip the structure down to the studs and begin to rebuild. I would need to find a way to build a modern application that meets the needs of modern computer users while still preserving the "character" of the original application.

Anyway, these thoughts have been swirling around in my mind lately. Does this comparison make sense to you? Are you familiar with Frontier? If so, which category does it belong in today?

In a post on GitHub, Dave Winer asks, “What do promises do/make possible that callbacks don’t?"

This is a great question, and one, IMHO, that is not often addressed or answered well. It often seems that developers embrace new patterns and API, taking for granted that they are better simply because they are newer.

This question brings me back to when I first had to work in a Promise-heavy codebase. It was five years ago, and I had very similar questions. The answers I got at the time weren’t very convincing. Here’s some sample code that uses the callback pattern:

request.get('http://api.someurl.com/api/resource', function (error, data) {
  if (error) {
      console.error('An error happened', error);
  }
 
  console.log('Response received:', data);
});

Now, here’s the same code using the Promise pattern:

request.get('http://api.someurl.com/api/resource').then(function (data) {
  console.log('Response received:', data);
}).catch(function (error) {
  console.error('An error happened', error);
});

It’s different, but is it better? It really doesn’t seem to do anything that couldn’t be done with callbacks.

Where Promises started to shine for me was when I needed to compose multiple asynchronous responses. I provided code examples on the GitHub thread.

Dave replied with a link to some code he had written that had some pretty hairy logic involving many levels of nested callbacks.

I decided to refactor this code to use Promises, and then provide it as an example for further discussion of whether the Promise code is better or not. Along the way, I decided to take it a step further and I used some async functions and generator functions. I recorded my screen while I was making this edits. The finished product is on GitHub, the video is below.

Let me know what you think. Is this better or just different?

It is exactly what it says on the tin.

www.youtube.com/watch

Delightful.