Goodbye Gatsby! Hello Eleventy!
For the last few years, I had been running this blog using Gatsby. In general, I liked Gatsby. I liked that it was so simple up front, but had such deep complexity under the hood. I liked that it supported React out of the box. I liked that it could generate websites in so many different ways.
I liked it enough that I made my own minimalist blog starter called Empress, which was a fully featured blog based on the tutorial but with several key features added. I used that for this blog for several years and I liked it.
But man, the leadership of Gatsby was bad. They took it in such weird directions. They tried and failed at so many weird features that the documentation, and the product itself just became a dumping ground.
It really went off the rails when they created Gatsby "themes" that had nothing to do with the colloquial use of "themes". Themes were really more like plugins, but they were already using that term, too. So it was a hot mess, and soon enough the feature seemed to disappear from the docs and from existence.
Then they were bought by Next. I still don't understand that acquisition. Next.js is a good product with sensible leadership. I liked using it at my prior job, and I considered using it for this site, but it was just overkill.
So when I could no longer navigate the crazy web of dependencies to upgrade my blog to the latest version of Gatsby, I essentially stopped writing. I was just so frustrated with it.
Until this weekend, when I decided it was time to change.
Hello, Eleventy!
I decided to switch to Eleventy mostly because it's the static site generator with the most hype right now. Sometimes it's good to try the tech that is currently being hyped. It's good to stay up to date and have that line on your resume.
But also, Eleventy is a good product. I planned on spending a few weekends getting my blog switched over, but it only took me a few hours on Saturday, Sunday, and Monday to get it 95% switched over. There are still a few minor bugs here and there - don't check the title tags on tag pages, and ignore the reverse chronological sorting in some places - but in general the switch was very easy.
I've been around web programming since the 1990s, and Eleventy feels like a return to an older way of working, but with some of the good infrastructural tech we picked up along the way. Like now I'm writing in markdown, and I don't need to run MySQL on my server, nor do I even need to run a traditional "server". I can just host my static site on S3, and use GitHub Actions to deploy it, just like with Gatsby.
And I've heard some of the blowback against Jamstack architecture sites in the last few years. It's why I briefly considered using Next for this. But I still think JavaScript + API is the best/fastest/cleanest way to run a website, whether it's a blog or something more complex. I don't have an API for this site, but I feel like I could attach one without too much trouble if the need arose.
I do wish that I could use React. I saw some people try to get Eleventy working with React experimentally, but I didn't see any updated package to do it. Nunjuks and markdown are okay for the basics, but I do think that a true component-based architecture is ultimately a cleaner way to build UIs than a template based architecture.
Until next time...
So I'm going to give Eleventy a shot for now.
But we all know that those of us who still quixotically maintain personal blogs in 2024 are on a perpetual upgrade cycle. We all know that no "upgrade" is the final upgrade.
I wonder what I'll "upgrade" to in a few years? Maybe Wordpress will come back around?
My Electrification Budget
2023 was the hottest year in human history, and 2024 looks like it's going to be even hotter. This has everyone wondering what they can do to lower their carbon footprint.
If you're thinking about electrifying your life, then you aren't alone. Millions of people are starting to rid their lives of gas burning cars and appliances, and replacing them with safer, more efficient electric options.
Still, there are a lot of barriers to electrification, and budget confusion is a big one. In this post, I'm going to walk you through our electrification journey so you can get an idea of how much it cost for us, and maybe avoid some of the mistakes we made.
Small home lifestyle
We live in a small house. This was a choice partly dictated by where we live; Silicon Valley is one of the most expensive places in the world, so we could only afford a small house. But it's also something dictated by energy efficiency; it's much more energy efficient to only maintain as much house as you need.
Our house is 990 square feet. This makes it an especially good example for other people to look at. Round it up to 1000 square feet, then the math is easy for figuring out how electrifying your home might relate to ours.
Still, we live in one of the most expensive parts of the country, so you might want to divide by some cost of living. The 2023 median home price in San Jose was $1,100,000 million according to realtor.com. The median home price in the us for the same time was around $412,000. So you might reasonably divide this total in half for your area.
The total cost
These prices include the cost of installation, but they don't include rebates, and again, this is from one of the most expensive parts of the country. Also, we generally didn't purchase the cheapest of anything; we opted for the devices we wanted rather than the most affordable ones.
This work was done over more than five years from 2018 to 2024, so this table was created from memory, and most of the costs are rounded to the nearest thousand dollars.
Item | Cost |
---|---|
Initial solar | $8,000 |
More solar plus battery | $25,000 |
Heat pump water heater | $8,000 |
Induction stove | $2,000 |
Electric vehicle | $45,000 |
Heat pump HVAC | $17,000 |
TOTAL | $105,000 |
As you can see, electrifying our lives wasn't cheap. Even with the incentives offered by local and national governmental organizations, we still paid nearly $100k to go green. Obviously, this isn't practical for most people. Fortunately, we did make a few mistakes that made this a bit more expensive than what most people will pay.
Mistakes and savings
The biggest mistake we made was adding solar to our garage in the initial installation. The problem is that we eventually wanted to add a battery in order to ensure we aren't hitting the grid. Well, the battery has to be connected to our house for it to be useful, but we added the solar to our garage, which is on a separate electrical panel. So we either had to trench out to our garage in order to connect the panels to our house, or we had to install a new solar setup on our house. The latter ended up being cheaper. We should have just installed our initial set of solar panels on our house.
The biggest cost on this chart is the electric car. We bought an Ioniq 5 because we thought that it had the best range at the price when we bought it. Still, you can get good used electric cars for less than half that cost. On Carvana, there are 2023 Hyundai Konas listed at under $20k. Generally, you shouldn't worry about range. Most people drive less than 40 miles a day, and modern electric cars will charge more than that overnight.
So the total cost here is high, even for California. If you eliminate the battery and install your initial solar setup correctly, then you can save $25k, bringing the total cost down to $80k. If you then buy a used EV, you can shave off another $25k, bringing the total cost down to $55k.
$55k is still a lot of money, but when you add government incentives, I think it's possible for anyone who owns a home.
Bay Area Oktoberfest Events Calendar 2023
Well, the 2023 Oktoberfest season for the Bay Area is as packed as ever. This year I decided I wanted to attend as many Oktoberfest events as I had the stomach for. So I did what any self-respecting beer nerd would do: I made a calendar, then I made a schedule. Here's the result of my labors. If you see me at these events, please come lift a glass with me!
20 questions you should answer before your senior fullstack programmer interview
I've been writing up some questions to help some friends prepare for interviews. I thought it might be worthwhile to share them here. I think that most senior fullstack developers should be able to answer these questions, and I think they're worth reviewing before you go into an interview.
20 fullstack engineer review questions
- What do the HTTP response codes beginning with 1-5 indicate?
- Name 5 different types of databases. Give examples of each.
- Name three different Chrome developer tools or extensions that you use for debugging. When do you use each? Why?
- What is the Big O access time for an array, a linked list, a hashmap, and a binary search tree?
- How does the schema differ between relational databases and document stores? When does this matter?
- Name three different types of caching that come into play in any web request.
- What is database sharding? Why does it matter? How does it differ between relational databases and NoSQL document stores?
- What is the difference between a traditional row-store database and a columnar database? Why would you choose one over the other?
- How fast are the fasts sorts we know about in Big O notation? Name one sort that is that fast.
- What is binary search? Can you walk through an example? When is binary search useful?
- What is the most complex operation to perform on a binary search tree? Why?
- What is a database index? When is it appropriate to use one? How are database indexes implemented?
- What is a DNS?
- What is a CDN? When is it useful?
- How does Java scale differently from JavaScript? Why?
- Name three frameworks for building websites. Which do you prefer? Why?
- What is vertical scaling? What is horizontal scaling?
- What are the security concerns that arise when using a package manager like npm?
- What is a serverless environment? What performance concerns arise when deploying a website using serverless technologies?
- What are the advantages and disadvantages of a REST API versus a GraphQL API? Why would you choose one over the other?
Bonus questions
Some of these are more about your informed opinion than about being right or wrong, but I still think it's important to review them and have a prepared answer.
- Name three different cloud service providers. Which do you prefer? Why?
- What is your preferred IDE? Why?
- How do you determine when a feature can be used in a given browser?
- When is a key-value store a good choice?
- What is your favorite programming language? Why?
Project: Client-side web form
This post contains the second assignment in my free web programming course.
Project: Client-side web form
Forms are how users enter data on the web. When you register for a website, you enter your username and email into a web form. When you buy an item from a web store, you send your payment information using a web form.
Generally speaking web forms have input components on them like text boxes and dropdowns and buttons. But this isn't always the case. Web forms can be cleverly hidden using JavaScript and CSS.
Typically a web form submits data to a server, which processes that data and responds to the user with something interesting. For instance, you might submit your username and password and get back an authentication token that allows you to use the private portion of a website.
Requirements
I want you to build a single web page using html and javascript only.
It should have three things on it.
- A page title in h1 tags.
- A label that reads "title:".
- An input text box.
- A submit button.
When the button is clicked, the title of the page should change to the title entered by the user without reloading the page.
Also, the user input must validated. The user should be prevented from using dirty words like "MacOS" and "iphone". Don't let them use either of those words in any capitalization. If those words occur in the input, then a red error message should be displayed underneath the text box that reads "Please refrain from using dirty words such as 'MacOS' and 'iphone'.".
Extra credit
For extra credit, make the form beautiful using CSS. Be creative, but try to make something that a typical web user might like.