Posts about software development written by Nick Pachulski
Expo sets you up with a new React Native project that will run natively on Android, iOS, and in the browser with a single codebase. You can also put that same code in an Electron app to get it running as Mac and Windows desktop applications.
Tagging blog posts in jekyll is straightforward if you can use plugins like this one. However, GitHub Pages only supports a set of whitelisted plugins and I don’t see any blog-post-tagging related helpers in that list. To make Jekyll tags work on GitHub Pages, you need to create an index page for each of your tags, which is painful.
A vanity metric looks good on paper but doesn’t inform future strategies. It falsely increases confidence. Code coverage can be a vanity metric. 100% test coverage means that the test suite runs every line of production code. That doesn’t mean it exercises the code’s entire intent.
Since 2014, I’ve spent untold hours on each of 13 iOS app side projects. Three of them made it into the App Store. Not because Apple rejected the others, but because my enthusiasm for them fell away. I even stopped work on the project I consider to have been most successful, which accrued just over 2.5K users.
Most of what I’m gonna say here has already been said really well by my favorite speaker, Sandi Metz. The Don’t Repeat Yourself (DRY) principle is overemphasized and misapplied. When you need a couple of lines of code that you’ve already written, copy and paste them. Seriously.
Some function components expand to manage a range of responsibilities. Tracking which parts of the function body relate to the task at hand gets harder. Use well-named hooks to separate concerns out of the function body and into their own files.
Try and keep names concise. Keep a thesaurus.com browser tab open while working. Type in phrases to get single word synonyms. You’ll learn some useful terminology and get better at writing more maintainable code. Good names convey purpose, so if a short name just won’t do, sacrifice brevity for clarity and camel case a whole sentence.
I’m almost ashamed to say this because I was once so proud of it but here’s a confession: I don’t always test drive my code anymore. But the lesson learned from strictly only writing code which contributes to the passage of a failing test lasts: Stay focused and do as little as is required. You’ll have less work today and someone - maybe you - will have easier work later.
I’m trying out Hey. It’s a new email provider made by some interesting people. Truth be told, the main motivation for switching is that I think Hey is pretty. It’s got personality. If you decide to try it out you’ll see what I mean.
Many of us split development work into segments called user stories. User stories deliver value. There should be no point at which a story is completed and no new value is delivered.
This article’s actually a podcast. Surprise! 🎉
The goal of this guide is to help teach you how to keep your repository’s history clear.
This article’s actually a sort of tutorial-walkthrough. Cheers! 🍻
The reason for having automated tests is to know whether or not code works. Working code fulfills product requirements.
This post will only be helpful to you if you intend to use Joe Masilotti’s strategy for stubbing network data in your UI Tests. You will run into a problem when you try to set a key of app.launchEnvironment to a string with an equals sign in it.
Let’s test drive an even number function
Immutability is great if you can swing it, but sometimes you run into tricky situations, like conditionally initializing an immutable value at the current scope.
I tried four or five gems that claimed they’d samba for me in a ruby-esque way. None of them worked. Installing or trying to use a couple of them resulted in pretty startling errors, like missing C header files. I tried resolving those issues to no avail before ultimately resorting to scripting the shell.
When I was introduced to the concept of squashing commits, I had a difficult time accepting it. I had been using git as a commit history time machine and I didn’t like the squash workflow because it reduced my time machine’s granularity.
Sometimes I want to know what server side endpoints I’m hitting as I click around in the browser. The app I maintain at work is large, containing a server side rails app and client side angular app all shoved into a single repository which (in large part) lacks tests and RESTful routes.
From Spotify’s iOS SDK documentation: