Posts about software development written by Nick Pachulski
I have a few providers which initialize state, shove it in a context, and then ensure that the state is synchronized with AsyncStorage so that if the app is quit and restarted, the context’s state is rehydrated from AsyncStorage. A few examples of the types of state I tend to treat this way are API tokens and user IDs.
There’s a common complaint - not a problem, per se - that people run into when building applications which use React Contexts to share state.
Today I needed to test drive a feature which allows users to confirm their account. Users find their name in a list and tap a “👋 This is Me” button by it. When the button is tapped, they’re sent a text message with a 6-digit confirmation code and asked to enter it into a react native alert prompt, which is also shown on screen after the “👋 This is Me” button is tapped.
Recently I’ve been working on a universal Expo app (iOS, Android & web) intended to help my hockey team keep track of our player and game stats, track who’s RSVP’d to our weekly games, and so on. To keep track of all those things, the Expo app communicates with a restful Ruby on Rails API. I decided, for typical reasons which aren’t the subject of this post, to mock that rails API as I test drove the React Native app.
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: