Documenting a Clean MacOS Mojave Install

I’m reviving a 2013 MacBook Pro with a clean install and fresh setup. This is mostly documentation for myself.

System Preferences

System Preferences > General

System Preferences > Dock

System Preferences > Mission Control

System Preferences > Display

System Preferences > Trackpad 1

System Preferences > Trackpad 2

Install some apps

LastPass
Dropbox
Chrome
Chrome Sync + Extension Settings (must check each extension and copy from previous settings manually)
Mac App Store Apps

Homebrew

At this point I decided to take the opportunity to learn something new. A coworker had recently taught us about dotfiles at our weekly tech check-in, so I wanted to see if I could install the rest of my apps using Homebrew.

I installed Homebrew and Homebrew Bundle and created a Brewfile based on what I had installed on my work machine. I created a dotfiles folder in my Documents folder and stored the Brewfile in the dotfiles folder. Then I opened that directory in Terminal and ran brew bundle.

Mischief managed!

Last couple of steps to reach basic usability:

• make bash auto-complete case insensitive with echo "set completion-ignore-case On" >> ~/.inputrc
• setup git/ssh keys

At this point it’s been about 1.5 hours since I started.

My Specific App Setup / Persnickety Shit

Add licenses for Alfred, Bartender, BetterTouchTool and HyperDock
Setup/log into Airdroid, Alfred, Bartender, BetterTouchTool, Franz, HyperSwitch, HyperDock, Kindle, ReadKit, Slack, Spillo, Stretchly, Todoist (copy settings for ReadKit and Spillo from previous settings manually)
Add Spillo, ReadKit, Chrome, Slack, Franz to dock
Install SetApp apps
Customize right-click menu
Enable dragging by swiping on trackpad:
System Preferences > Accessibility > Mouse & Trackpad > Trackpad Options > Enable dragging
Enable git colorized output: git config --global color.ui auto
Setup VSCode with Settings Sync extension (Gist)

Reducing dependency on console.log

A co-worker recently brought to my attention that I always reach for console.log when I’m trying to figure out why some code is not behaving as I expect. It’s rather like always reaching for a hammer and ignoring the screwdrivers and wrenches. Sometimes a hammer is the right tool. Sometimes it’s not. Ultimately, scattering console.log around your code like fairy dust is not a particularly effective debugging method.

 
These are some things I’m reading to branch out and get comfortable with more debugging tools and techniques:

• Get Started with Debugging JavaScript in Chrome DevTools
• /dev tips
• How to stop using console.log() and start using your browser’s debugger
• CSS Debugging and Optimization: Browser-based Developer Tools
• Art of debugging with Chrome DevTools
• Tips and Tricks for Debugging in Chrome Developer Tools
• Learn How To Debug JavaScript with Chrome DevTools
• Conditional Breakpoints in Chrome are Awesome

I hope these links are helpful to others looking to improve their debugging processes!

Reflecting on my years of teaching web development with ScriptEd

A new school year means another year of teaching with ScriptEd. This will be my 5th year! I’ve been reflecting on how much I’ve grown since my first year with ScriptEd:

I had the worst stage-fright and could barely get through a 5-minute lecture without becoming breathless and shaky. Once I actually stopped in the middle of a lecture and ran out of the classroom, leaving the other volunteers to pick up where I left off. While I’m still no TED speaker (though ScriptEd’s co-founder is), I can get through a class without heart palpitations. I don’t have to read directly off the slides and it doesn’t completely throw me off-track when I stumble over something or when a student interrupts with a question. I’ve even given talks at QueensJS and DjangoGirls events.

I knew just enough JavaScript when I started teaching to read a simple function, mostly understand it and maybe edit it. I learned JavaScript by teaching. Nothing is more motivating than having students depend on me. I’m driven to understand the material at a deeper level and find engaging ways to help them understand it.

Now I write JavaScript almost every day at work. Over the past 4 years I’ve built websites with advanced animations (pieces of a car that fall into place as a user scrolls, a tumblr-style lazy-loading masonry page that scrolls forever and ever) and several applications using React.

Teaching has also improved my ability to communicate at work: I use similar strategies to explain technical concepts to producers and product managers so they understand what I’m working on, struggling with, or need clarity on.

I have more empathy, patience, self-confidence, and new friends among my fellow volunteers.

Teaching is one of the hardest things I’ve ever done, and its also an amazing way to learn.