If you’re a software developer working ethically you’re almost certainly using GnuPG to sign your work. And if you’ve been at it for any length of time you’ve almost certainly been forced to switch machines. Unless your aim is to create a new identity for each machine you use (please don’t) you need a simple, repeatable strategy moving GPG keys privately. Let me show you how.
Not interested in reinventing the wheel? Neither am I. Here’s a short list of awesome boilerplates – sometimes called starter kits or seeds – for getting your React applications off the ground in a hurry.
So without further ado…
One of the best parts of building with React is discovering new and awesome open source components to use. Rather than just throwing the kitchen sink at you, here’s a short list of React components and libraries I feel are truly awesome.
I’ve long been inspired by the work of Steve Souders. Back in 2009 Steve published an article titled Loading Scripts Without Blocking, which I first became aware of and studied during my time at Orbitz – where every millisecond a user waited for the page to load had a measurable impact to the business.
In 2016 this website underwent a major overhaul. I took it off my simple Docker set-up and moved it to S3 with CloudFront. The process of which enabled me to reduce hosting costs by 80% all while increasing reach and decreasing page load times globally.
But static websites have a perceived disadvantage: they’re static. They have no inherent dynamic functionality. What will you do when you want to add some piece of interactivity—a contact form, or an email distribution list? Sure you could go with TypeForm or TinyLetter. But you could also create your own service using FaaS (a.k.a. Serverless). Afterall, Serverless isn’t just a fad, and it’s not going away anytime soon.
One of the largest perceived drawbacks to creating a SPA or other Rich Internet Application is that they’re not SEO friendly or very accessible. With the advent of technologies such as ARIA, HTML5 and Node.js, things are changing. Web apps are becoming more usable and accessible, though also making them crawlable and highly performant is a formidable challenge.
When I started this blog back in 2008 I didn’t have a clear direction for what I wanted it to be. I just knew at the time I was working on closed source software and, without it, had no other way to convey my skills to potential employers and clients.
Over time the content direction for the blog became clearer. It eventually grew to become a tech tutorials site and made open source. It serves as a journal both for the community and a place for me to scribe how to do things I knew I’d otherwise forget. It worked, and has served both purposes well.
I’d originally planned to make this a tutorial on how to build a React Native app. But to give it justice I'm doing a Webcast. Instead, what I’ll share with you here are some of my top takeaways from building my first iOS app with React Native. These are coming from the viewpoint of an experienced Web developer building a native app for the first time. Things I wish I’d known earlier kinda stuff. So without further ado…
A year ago I built and open-sourced Lumpen Radio for iOS using React Native. A major takeaway during development was the importance of testing on actual devices. Not just my device. But, you know, like a responsible adult using a bunch of them.
At the time I was finishing development of the iOS app, Android support in RN was just getting its roots. I decided to let Android support bake a while longer, coordinated small group of people, beta tested with TestFlight and released to the App Store with confidence.
20 releases of React Native have passed since then and there have been great innovations like CodePush ( archive) and Lock, and many Awesome Boilerplates have continued to surface with increasing speed.
Given all the advancements, and after recent inspiration to create an Android version of Lumpen Radio, I decided it was time to go cross-platform.
As the Web shifts from a web of content as we’ve known it to an application platform there’s been a renewed emphasis on composition in web app architecture. To manage composition in our Web UIs at Trunk Club we use a number of techniques and patterns to help scale our suite of rich-clients while avoiding duplication of common componentry. This article will discuss some of the patterns we use, describe the concept of a component library and introduce software for sharing modules between apps without use of WebPack or Browserify.
Learn how to use JS modules and a simple component library to share code in a forward-looking way.