Ignore It, then Deploy It

Today I realized I wanted to set this thing up for real continous deployment — I no longer wanted to have to drag and drop to deploy the thing. I like using git even for personal projects, so it’s a no-brainer to make it so that pushing to remote causes a deploy.

I set it up on Netlify kinda by default, simply because it was in the eleventy tutorial’s deployment section, and I gotta say: it’s nice to be back! I used to play around with Netlify a lot in the past, but haven’t had a need to for a long time (as I was using surge.sh, Github Pages, or Blot, depending on what I was working on).

And those are all good tools for what they are! But with Eleventy, I’m trying to do it The Eleventy Way™️, and so using the first thing they mentioned in the tutorial felt right. 😀

A tiny gitignore explainer

I also knew that I never want to throw a git repo on GitHub without creating a .gitignore file. For the uninitiated, that’s a file that tells git, “hey, don’t ever include these files in the repo.” Briefly speaking, this prevents you from checking in:

• files that don’t need to be in your repo and that take up a bunch of space, like your nodemodules folder
• stuff that operating systems or apps use that have nothing to do with your project, like VS Code settings or all the junk that macOS dumps into folders
• most importantly: app secrets, environmental variables, and anything else that could result in something terrible like your API getting published for anyone to grab and use

That last one is a huge gotcha, and a bit of the reason why I use deployment services in the first place: people have built deploy tools that mean I’m not working too close to the metal. I like safeguards that prevent me from getting a giant web hosting bill, don’t you?

Let’s build that file

As a front end dev I’m absolutely well-versed in using a git ignore file, but I’m rarely the originator of it. At my last job, we inherited a lot of ignore files since our app began with us forking Backstage.

So this time, it ’s my turn!

The Eleventy docs weren’t super helpful, and neither was the actual Eleventy .gitignore file, since it…had a lot of stuff that felt very specific to the project, not to what a user like me would need.

After some Googling, I ended up finding a couple of sources for my main tools: VS Code, on a Mac. I also found someone’s basic boilerplate version and deleted ths stuff I figured I wouldn’t use. I kept the sources in the file, both for me, and so I can credit them. You can see the file in the now-published GitHub repo. Hooray for tools built by folks!

A non-zero amount of what’s in that file represents things I haven’t built yet, like environmental variables and such. To me, that makes it a good safeguard — it’s already there when I do need it, and it prevents my “go go go” hyperfocus brain from missing the important stuff later.

Time to deploy

After I’m sure I have that all ready to go, it’s time to deploy. I used the GitHub CLI to push the local folder to a GitHub repo. From there, I followed the defaults in Netlify, and I did run into one hiccup: because I’m using eleventy 3.0, the default eleventy build command failed.

I changed it to npx @11ty/eleventy@canary, which is the local build command, and now it’s all up and running! 🥳

Accessiblity Notes

One thing that I believe in strongly: accessibility needs to be part of any project from the start, not just afterwards.

Today I ran some Deque axe tests on the day one stuff I posted the other day, and it turns out I already caught some issues:

• I made the <h1> content for the site “Jim Withington,” but that header actually doesn’t describe what follows. This site will eventually be my portfolio/blog site, so even “Jim Withington’s Site” would be more appropriate.
• I didn’t have a language attribute in the main html tag.
• My links are marked as <h2>’s. I know better than that. A huuuge rule of accessibility: elements should not be used for presentation. To be honest, I think this resulted from me using a tutorial, and I also don’t think of this “design” as something I’m going to keep 😂 However, again, a11y from the start!
• I never checked the color contrast the other day…and, obviously, even though I used placeholder colors, the grey and pink are not contrasting enough.(see below) So I’ll probably go back to using my fave deeppink until further notice as the background color. 😂

So today, those issues were the first things I worked on! Anything else could wait.

That said, once I did all that, I decided I wanted to quit having the full content of each post show up on the homepage. Even this early in the game, that bugged me. I’m working on adding a new variable called “teaser” where I can pull out a single line, add it to the front matter, and use that to represent the post. But it’s getting late and I have other stuff I want to do, so…tomorrow!

progress pic for today:

And hey, the new deploy!

Working in Public

I’m currently unemployed, and one thing that that means is time. I’ve got a lot of it.

And I’m also a front end developer that misses doing the fun-for-me parts of web development.

And I also just attended the wonderful CascadiaJS conference, where my head got filled up with so much learning with so many fun people.

For about a week now, I’ve had this itch. I want to blog again. I want to make it a semi-regular practice, something like what so many of my fellow omg.lol folks talk about when they link to barry’s post. I think Chris Coyier wrote about this, too.

At the conference, I also discovered something: my main jimwithington.com site’s CSS was borked. Totally busted. And that makes sense, as it was a template site I built before I knew how to do anything, and then I hosted it on surge.sh, and then I always said to myself “hmm, I should update that.”

(this kind of thing happens! as a web dev you don’t always want to do this stuff after work hours, too!)

And theeeennnnn I considered maybe doing a process where I set up a new blog with a new blog service, then eventually replace it with…whatever I come up with.

After a bunch of that, I realized some things:

1. I have both website-from-scratch knowledge and stuff like, yknow, this here weblog space I’m not using.
2. I’ve been wanting to try eleventy for a long time.
3. Building something would both keep me from getting too rusty with my skills and hopefully provide me with talking points, stuff to show off, and new skills.
4. Instead of worrying that my new thing sucks, I could also document the process, doing the “work in public” thing that I’m even more interested in after Jason’s Cascadia Talk.

I’m especially excited about that last point, and feeling a lot of momentum around it. I’m a huge believer in using personal sites as playgrounds to try out new things.

And Jason’s talk taught me that, hey, if you have stuff you love, and you do it in public, that’s a really good way for folks to then ask you to do that kinda work for them.

So let’s see how it goes!

For the most part, my posts are going to live at my weblog.lol, because I haven’t really been using that site, so I figured that now’s the time! When I finish the new thing, I’ll probably roll one of my existing sites (probably this one!) into the weblog one and then go from there.

Anyway, here’s the very first version of what I’m building. I can’t wait to keep adding to it and making it real!

Promising Design Patterns

I talked to someone this evening about what I know and what I don’t know as far as web dev, React, JavaScript, and the like.

And I had to admit a couple of things, right then and there:

1. I only have a vague sense of what promises are (in JavaScript! in life, I’m good at keeping them).
2. I can visualize what algorithms and design patterns are, but I have no idea if I know any of them offhand.

So I figured: why not learn something tonight?

And then I can post it! Bonus!

Promises

The thing that I knew, in the moment (probably due to the name? It’s right there on the tin): promises are a way to deal with asynchronicity.

In plain english: Once this other thing is done, then do this thing.

In fact, it literally uses then to make the promise. What could be more readable?

This isn’t the only way to do this (see also: callbacks), but it does remove some complexity, in favor of more readable code.

On that linked example, I feel like the “single-use guarantee” portion is super important:

A promise only ever has one of three states at any given time:

• pending
• fulfilled (resolved)
• rejected (error)

A pending promise can only ever lead to either a fulfilled state or a rejected state once and only once, which can avoid some pretty complex error scenarios.

For the next post in that linked tutorial the author shows how to use promises in order to implement the fetch() api. It makes so much sense, and is so readable:

fetch(this.getApiUrl())
  .then(resp => resp.json())
  .then(resp => {
    const currentTime = resp.dateString;
    this.setState({currentTime})
  })

Even for someone who’s new to Promises, this makes so much sense. Give me the response, turn it into JSON, and use it to set the current time.

Woop! We just learned about promises.

As far as algorithms and design patterns? Those are less of a quick study. I did, however, find a pretty good React-oriented design patters site here:

React Patterns

I even saw some that I use all the time, like the spread operator in JSX and Style Components, or have learned about already, like Event Switches. Some of this feels like “unknown knowns,” as it were.

I’ve definitely got some more resources to add the list now — I’m glad I had this convo today, and took the opportunity to learn a bit more. Bit by bit, bird by bird. That’s all we can do!

Process

I’m definitely a visual thinker/learner (close second to audio learning style), and I also love to map a thing out ahead of time so I don’t have to track it in my brain.

Sometimes that means that if I’m breaking things down into components that I make some wireframe-y sketches! to Here’s a couple of examples of how that looks, from a thing I worked on this weekend:

Bonus: I get to use my fancy fountain pens!

Whoa ImageMagick!

Holy whoa this is cool: by using ImageMagick’s command line interface, you can combine images using terminal commands like:

convert +append a.png b.jpg c.tif

This is super cool if you don’t feel like fussing a ton with Preview.app, or worse, launching Photoshop, etc., OR if you need to convert to a different image type (note the different extensions, above).

I used it today becaue I had a few screenshots I wanted to combine and markup for posting in an pull request. Instead of having to do all that manually, I did this:

convert +append form1.png form2.png form3.png form-all.png

…and then marked up the new image (which was form-all.png) by just by hitting spacebar in Finder and using Markup.

Easy Peasy!

I learned about ImageMagick by Googling combine three images preview mac osx which led me to StackExchange).

I installed it with brew install imagemagick; this led to an error message (Permission denied @ dir_s_mkdir - /usr/local/Frameworks), which was resolved by Googling the Error message, which took me here.

Just a small glimpse into the way that anything involving web dev is time consuming. 😀

Happy combining!

Literally speaking

Yesterday I put in a pull request for the framework that we use at work. It was related to an issue I’d submitted; namely, that I wanted to be able to send folks style guide links to specific variants of components we build.

Building this had a lot of codey type things in it:

• Thinking about how to build it took longer than building it! This happens not infrequently, but it’s definitely surprising to newer folks.
  
• I played a bit with regular expressions. Regex is a weird thing, but I didn’t want to have spaces in URLs, since those can still cause problems. A bit of googling found me the expression I needed, but I also had to fully understand the JavaScript in order to do it.
• JavaScript! I’m working on learning a lot more JS; I think it’s a case of “I know more than I think I do,” but also, it took me a minute to figure out how to do this:

// for permalinks to examples
const exampleName = example.name;
const exampleNameNoSpace = exampleName.replace(/\s+/g, '');
const exampleLink = `#${exampleNameNoSpace}`;

However, I did it!

You see, when you look up examples for using these sorts of expressions, programmers like to use variables (like str for string) that feel like they mean more than they do. So many examples used str.replace(/\s+/g that I thought it meant something important. Nope! This was just convention, used by many folks, but not necessary.

And hey, it worked!

One of the main things I had to figure out is how .jsx — combined with the linting we use — would want me to combine the # needed for an anchor link on the same page with the exampleNameNoSpace variable I’d created above it.

These are “template literals,” and though I could have concatenated the two parts, ESLint wasn’t having it. The cool thing is that the linter’s warning taught me a new thing I needed to know.

So yeah! That’s what I learned yesterday. How bout you?

Hello, World!

This thing looks pretty swell. Let’s see how it goes!