Colin Devroe

Photographer. Podcaster. Blogger. Reverse Engineer.

React is an ecosystem

Jonathan Snook, on his learning curve when joining a new organization that uses React:

When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.

Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”

Most of the time React is merely a piece of an app’s overall puzzle. There are so many other pieces that make up the entire thing it can be an overwhelming experience.

I’m not new to building apps. In fact, the vast majority of my life I’ve been building apps. But learning React this year has been one of the more haphazard experiences of my career. It is not straightforward.

It isn’t that I think React itself is poorly made or documented. In fact, out of the box you can spin up a simple Hello World React app about as quickly as any other technology. But, as my boy Snook points out, it never ends there. Any somewhat mature app built on React has many, many other parts to learn.

He points most of them out in his blog post but I’ll reiterate here some of the things I personally see that could be overwhelming to people jumping in…

  • Build routines
  • Servers
  • State managers
  • Component hierarchies
  • JavaScript specifications
  • Myriad JavaScript packages (such as design libraries)
  • JavaScript style guides (naming and positioning of things)
  • CSS pre-processors (like SASS)

Any one or all of these things could potentially be new to a web developer coming into React. And, equally so, an app developer.

The only way to avoid being overwhelmed would be to take one bit at a time. Understand that what you’re looking at isn’t a single thing but a collection of many new things and that each of them will become natural to you over time. If your team is large enough, perhaps there are pieces you won’t need to worry too much about. But if not, you’re essentially diving into the “full stack” and will eventually become familiar with that entire thing.

I will say, lastly, that it has been very fun. React sort of combines the things I like about building apps with, say, Swift (typing, “stricter” rules, reusable bits) and the things I like about building things for the web (HTML, CSS, app runs on literally everything).

Microsoft releases WSL 2

Lots of Microsoft developer related announcements over the last few days. Since I use WSL every single day I am really looking forward to this WSL 2 release.

Initial tests that we’ve run have WSL 2 running up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake on various projects.

Significant speed improvements. But this bit really takes the cake:

WSL 2 uses an entirely new architecture that uses a real Linux kernel.

WSL 1 used an entirely different approach. They described it like this:

It is the space between the user mode Linux binaries and the Windows kernel components where the magic happens. By placing unmodified Linux binaries in Pico processes we enable Linux system calls to be directed into the Windows kernel. The lxss.sys and lxcore.sys drivers translate the Linux system calls into NT APIs and emulate the Linux kernel.

WSL 1 is a light-weight emulated Linux experience that allows us to use things like Bash commands within Windows without a full VM. WSL 2 is full Linux kernel properly piped to use the Windows stack.

I’m no expert in these sorts of things but this work seems pretty amazing on the surface and using it every day has been great and it has gotten better very rapidly.

Xamarin videos, now on YouTube

Me, 17-minutes into an audio bit in 2017 (paraphrasing):

If you go onto YouTube search for a problem you’re having for Xcode and Swift you’ll find 15 well-produced videos to solve your problem. […] But you won’t find 15 well-produced videos with Visual Studio + C# (or Xamarin).

For the last few years I’ve thought that Microsoft needs a much larger presence on YouTube (in addition to Channel9). They also need other developers that make these sorts of videos to do them as well. I’ve long thought they should directly sponsor a series of videos from Lets Build That App’s Brian Voong.

But, perhaps this new channel will help.

Boring is good in software development

I use the term “boring” here to describe that which isn’t brand new. Sometimes we’re only excited about the new. The new car! The new house! Rather than being content with what we have, because it works or is paid off or we’re familiar with every nook and cranny, we sometimes can get wrapped up in the excitement of something new.

Chris Coyier, co-founder of CodePen, writing on CSS Tricks:

Perhaps the worst reason to choose a complex solution is that it’s new, and the newness makes it feel like choosing it makes you on top of technology and doing your job well. Old and boring may just what you need to do your job well.

Me, in 2016, discussing a topic very similar to this in a piece I then titled Use what works, play with the new:

The very same reasons Kyle uses Ruby on Rails is why I use PHP. I do like the way Ruby looks far better than PHP. (Insert GIF of DHH saying Ruby is gorgeous here) I also think that the Rails framework is well structured for web applications. I do think Go looks succinct and interesting. And Node is likely better for some of the things I’m trying to accomplish. However, I’m faster with PHP, a lot of people know it, it is very fast and stable, and has been used in large-scale projects. So I’m perfectly happy using PHP.

New (and therefore sometimes more complex to Chris’ point) may be exciting but it may not be the most reliable choice. Or the most widely tested. So you may do well to choose the old or boring choice.

This topic comes up on the blogosphere every few years. It is a good reminder.

I recommend reading the entirety of Coyier’s post as well as mine.

Testing inconsistent Web Share Target API data with a Progressive Web App

One of the latest things I’ve been working on for Unmark is turning the app into a Progressive Web App (PWA). Among other benefits, this affords Unmark the capability of being a “Web Share Target” on Android. (Sadly, only Android for now)

A Web Share Target is very similar to a feature you likely use every day and may not realize it. When you “Share to” or “Share via” an app (say, Twitter or Facebook or’s iOS app) it automatically picks up the URL, title, etc. from the web page you’re currently on – this is using a similar feature set. For PWA’s, this is called the Web Share Target API.

What happens is that the app you share from sends a small little packet of data to the app or PWA. According to the spec it should be sending three specific items: title, url, and notes.

The issue I’ve been working through is that each app has a different way of sending that data. Some of them exclude one or more of the items and each of them have very different ways of sending “Notes”.

I don’t know why these apps aren’t consistent. I suppose it might be in part because they are handling PWAs the same way they are handling other apps. They are just sending a “chunk” of data and they expect the target app to work through it all.

Today I was noodling how best to set up a test application to install on my Android phone so that I can inspect how these apps share their information. This way I can see exactly what information is being shared how Unmark could work with each of them. And I was going to open source it so that others working on this same issue had something they could use.

But it turns out I don’t need to, the Web Incubator Community Group already has a Web Share Target Test PWA already in place to do this. Just install this app on your Android device’s home screen and “Share To” it.

Thanks to Matt Giuca on the Google Chrome team for pointing me in the right direction. I’m glad this already existed.

Xamarin.Forms 3.1

David Ortinau on the Xamarin Blog:

Earlier this year, we surveyed Xamarin.Forms developers about the kinds of custom controls and extra platform code being written repeatedly that should be considered for support “in the box”. From these conversations, we created an initiative to deliver as many as we could in the next several releases. Just six weeks after shipping Xamarin.Forms 3.0 at Build 2018, we are excited to introduce Xamarin.Forms 3.1 with a batch of those enhancements to make your lives easier.

I shipped a Xamarin.Forms app on iOS and Android in 2017. I thoroughly enjoyed exploring and using Xamarin and in some circumstances, for some teams (especially those with deep C# experience) I’d wholeheartedly recommend Xamarin. The Xamarin team continues to keep on top of the latest OS/SDK/API releases as well as making it very easy for developers to ship cross platform applications.

Hopefully by the end of this year I’ll be able to say the same about React/React Native. I’m looking forward to exploring this deeper than I have in the past. I like to use different things so that I know what the best tool for each job is – rather than using the same tool for every project.

Developers, Let me tell you about Microsoft (audio)

I’ve been writing about Microsoft’s moves for the last three years. This week everything has come together and I’ve been writing my first multi-platform application using C# and Visual Studio. In this long rant I go on and on about how Microsoft needs to spread the word about what they are up to.

Links for this bit:



Mina Markham:

In August, we released a major redesign of, and we want to give you a peek behind-the-scenes.

She goes on to show tons of details on their latest redesign. There are several bits I found interesting such as their attention to accessibility, how they handle fall backs for IE11, and how they made responsive illustrations.

/via Brad Frost.

What’s new in WSL in Windows 10

Tara Raj for Microsoft:

We’ve been documenting many of these new features and improvements on this blog over the last few months, but we’ve often been asked for a single document listing all the new improvements, and with FCU (version 1709, build 16299.15) shipping on October 17th 2017, we thought it was time to publish a list these improvements!

We’re coming up on our first year of using Windows Subsystem for Linux (WSL) at Condron Media. I mentioned in January of this year that we’ve been using it pretty extensively. Since then Tucker Hottes has been getting the insider updates (or, beta updates) of Windows 10 and has enjoyed the incredibly fast pace that Microsoft’s teams are on. If you look at the linked blog post you’ll see the improvements are myriad.

A request: If you’re a developer using Windows 10 and know about WSL do Microsoft a favor and let other Windows-using developers know. Tucker and I are always amazed at the number of developers that have no idea about WSL still. In fact, just yesterday we met one and made sure to tell them about it.

To put this in perspective; Tucker is on Windows 10 and I’m on macOS. Yet, we use nearly the same development environment, configuration, tools, etc. This allows us to collaborate in a way that was previously much more difficult. Microsoft is doing great work on WSL and more developers need to know.

More on Firefox Quantum Developer Edition

Dan Callahan:

Compared to Firefox six months ago, today’s Developer Edition is twice as fast on benchmarks like Speedometer 2.0 that simulate the real-world performance of modern web applications.

See, on a tear.

Firefox Quantum Developer Edition

Julian Descottes, for Mozilla Hacks:

Firefox 57 Developer Edition was just released! It’s such an advance that we’ve given this browser a new name: Firefox Quantum.

I’ve been using Firefox as my default web browser on the Mac, iPad, and iPhone for a little over a week. I’ve also been using Developer Edition for most of my development needs. The Mozilla team is on a tear and this latest version is incredibly good.

iPhone X’s new margins

Brian Voong on his excellent YouTube channel Let’s Build That App:

With the introduction of iPhone 10, we as developers are now faced with another option for our apps to be displayed in. Fortunately, Apple has provided us with the necessary APIs to get around the unsafe regions of this phone. We do this by using the new safeAreaLayoutGuide anchors in our code. Enjoy.

Great overview of the very easy to implement adjustments.

Side note: If you’re jumping into iOS development I highly recommend subscribing to this channel and going back through his videos. It is a trove.

John George shares a solution

John George, fellow NEPA.js attendee:

I’m writing this because I discovered the hard way that .NET Core’s ‘dotnet run’ command is NOT meant to be production ready. My biggest headache was that my website shut down when I exited my shell. Not even the ‘disown’command would dissociate the running service from the user.

Posts like this by John often do not get enough attention. While it may not be applicable to you right now – dozens, hundreds, or perhaps thousands of people searching for this issue over the following months and years will be very glad that John took the time to do the write-up.

Kudos to him. More developers should write about their solutions.

Brad Frost on “full-stack developers”

Brad Frost:

The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.

In many of the descriptions I’ve seen it goes even further than that. Sometimes full-stack developer refers to someone who can also administer server architectures or cloud services or do database work.

There are certainly a number of people who can fumble their way through all of these things. I consider myself one of them. But I wouldn’t call myself great or even very good at any one of them. There is nearly no one that is great at all of these things. I’ve only seen perhaps one or two in over 20 years of banging away at this keyboard.

This is also an excellent point from Brad:

Large organizations have the ability to hire specialists, which is why I get so confused why so many companies proudly declare they only hire full-stack developers. Having team members that can own the frontend experience is a good thing. Having team members that can own all things backend is a good thing. Having everyone work together to create successful products is a good thing.

No one should be ashamed that they are very good at one thing and not as good at another. Embrace that fact and become an expert.

Tom Dale: “Compilers are the new frameworks”

Tom Dale, Senior Staff Software Engineer at LinkedIn and co-creator of Ember.js, in a post where he argues that compilers are the new web frameworks:

Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. And AAA game titles accept minutes-long load times in exchange for consistent 60fps performance, but I shudder to think what a 30 second load time would do to the conversion rate of your e-commerce site, 60fps or not.

While I agree with most of his post, that compilers are becoming increasingly more a part of a web developers workflow and thus becoming very important to learn, this particular bit isn’t a fair one-to-one comparison in my opinion.

Web apps do not need to pre-load every single asset onto the device prior to running. If you were to weigh a fully native app next to its counterpart web app* you’d likely get a very similar result. It is just that a native app is downloaded mostly all at once and a web app can be loaded as needed.

But his point remains, more and more web apps are looking more like native apps. They are compiled, loaded, and completely obfuscated from the source code they originally started out at. I’m not sure if I feel this is good or bad for the web. But I do know that the barrier to entry in web development is higher than ever.

* Most web apps that have a direct counterpart on a mobile platform share lots, if not all, code these days so these comparisons are getting tougher and tougher to do fairly.

Observations on building my first iOS app in Swift

In early June I decided I wanted to learn iOS app development using Swift.

I’ve made a lot of progress over the last month, building two apps that I can use on my own phone, and one app that I’m now in beta testing via TestFlight with a few friends. Over the last month I’ve made some observations on the process of building an iOS app, the Swift programming language, Xcode, iOS frameworks, and the various other bits needed to make an app. I thought I’d take the time to jot those down.

These are in no particular order:

  • Swift is growing on me rather quickly. The idea behind Swift has always interested me, but I hadn’t really given it a try until now. Like any new language you need to work with it for a time before some of the things that you may not like about it, you end up seeing the wisdom in.
  • I’m very glad I waited until Swift 3 before trying it in earnest. The tutorials I’ve come across for earlier versions make it clear the language has matured in a short period of time.
  • Using Storyboards in Xcode is not intuitive whatsoever. I know many people avoid them altogether (from what I’ve seen on YouTube). Unless you watch someone build a Storyboard you’d likely never, ever just figure it out.
  • iOS frameworks are bulky. It is no wonder so many apps are so big. Just including one or two frameworks for my very simple first app ballooned the app to over 15Mb.
  • That being said, iOS frameworks are very useful. With just a few lines of code you can get something working quickly.
  • Playgrounds are very useful to learn Swift.
  • The Playgrounds compiler can become stuck rather easily. Especially if you paste in a bunch of code from your project to mess around with and get it to work. I’ve had to restart Xcode several times.
  • Xcode has crashed on me a few times over the last month. Crashes on macOS (and also most Apple apps) are very rare. So to be working on something so fragile seems out-of-character. Especially with how simple my apps are currently.
  • Auto Layout baffles me still. I have a working UI for one of my apps that works across multiple device screen sizes. But it is far from what I’d want to ship with. I’ve watched a lot of videos on how to use Auto Layout but I still can’t make heads or tails of it. I’m waiting for the moment it clicks.
  • The connection between labels and buttons and other UI elements in your Storyboard and your Controller class is far too fragile. You should be able to rename things, delete things, move them around without completely blowing everything up and starting over. Example: If I CNTRL+Drag a label onto my Controller and create an Reference Outlet for it… I should be able to rename that Outlet without needing to CNTRL+Drag again. I don’t know how, but somehow.
  • Did I mention that Auto Layout baffles me still?
  • Building and deploying an app to iTunes Connect in order to add to the App Store or Test Flight is an entirely un-Apple-like experience. There is no Step 1, Step 2, Step 3 type of workflow. Similar to Storyboards it is not something you can figure out – you must watch or read to learn. It feels like it was never designed by a Product person.
  • Building an app that resides on a device like the iPhone is an amazing experience. While I’ve always been able to load my web apps on a phone, and I’ve built some apps that use a WebView to deploy across multiple platforms, this is the first time I feel like I’m touching my app when I use it. There is nothing that comes close to native UI.
  • Also, building an app that requires no connection to the web has been really fun. It is so fast! I’d like to move forward by trying my best to keep HTTP request at zero or as low as possible.
  • The amount of information an iOS device knows at any given time is pretty amazing. It can know (with the user’s permission) where it is, what altitude it is at, which way it is pointing, how many times the person’s heartbeat that day, what it is looking at, etc. etc. Amazing to play with these features.
  • The Xcode IDE is really incredible to use. You may not remember a framework’s properties but you can just begin typing a reasonable word and expect that Xcode will figure out what you’re trying to accomplish. Also, if you happen to write older syntax because you’re following an out-of-date tutorial, it will automatically convert it to the most recent syntax.

Overall I’ve had a positive experience learning to build an iOS app on my own. Going from having an app in TestFlight to shipping an app feels like preparing to cross a desert on foot. But, I’m enjoying my experience so I’m going to trudge forward to do so.

I hope to ask for public beta testers of the app in a few weeks or a month.

Google’s AMP is a gilded cage

Terence Eden:

If, like me, you made the mistake of trying out AMP on your website – you’re in a tricky position if you try to remove it. Google doesn’t like anything leaving its clutches.

I appreciate nothing about AMP. In fact, I don’t click any links that use it in protest.

/via Jeremy Keith.

Make accessibility job one

Jeffrey Zeldman:

One small thing designers and developers can do is to make accessibility and usability Job 1 on every project.

I need to heed this advice. Thanks for the reminder Jeffrey.

Loren Brichter on web apps

K. Q. Dreger interviewed Loren Brichter about his recent sale of Letterpress (my favorite iOS game). The interview is full of little behind-the-scenes tidbits on Letterpress and how it was made and where it is going.

However, when Dreger asks Brichter what he’s been up to and what he will be doing next, I thought his thoughts on web apps was worth noting:

My work for the last few years has been on the web, and honestly, it’s a breath of fresh air. Instant refreshing, surprisingly good debugging / perf tools, intrinsically multi-platform, and most importantly, open.

I find the entire concept of App Review morally questionable despite Apple’s good intentions. So I sleep better at night not being part of that anymore. Sure, the web is messy, and it’s delicate, but it’s important and good and getting better fast.

Wouldn’t be surprised if I never went back.

Strong words from someone who has made a big, big name for himself in iOS development. Welcome to the web Loren, you’ll love it here. I’ll be watching Atebits.

Migrating Subscriptions from one Stripe account to another

One of my recent client programming projects (hire me here) was to help a company migrate all customers, cards, plans, and subscriptions from one Stripe account to another as a result of an acquisition. I hadn’t needed to do anything like this in the past and I ended up fumbling my way through a few of the steps. So, I thought it worth the effort to jot down the process.

Here is a graphic of the overall process with notes to follow below.

Stripe Migration

I made some notes along the way during this project. Using the numbers above, here is the process step-by-step and some things you’ll want to keep in mind before you begin.

  1. Send an email to to request Customer and Card migration from Account A to Account B.
    • Remember that both accounts need to be activated
    • Stripe cannot transfer live accounts into test accounts (a shame)
  2. Stripe transfers Customer and Card information from Account A to Account B
    • Stripe cannot “schedule” this transfer for an exact date or time
    • Stripe can run the migration more than once should new Customers be added
    • Customer IDs are retained from one account to another
    • Card IDs cannot be retained
    • Stripe will not migrate Plans or Subscriptions
  3. Transfer Plans from Account A to Account B
    • Retain all plan information (recommended)
    • The most crucial piece to keep the same is plan_id
    • You may want to make adjustments to “Statement Description” at this time if the business name has changed
  4. Transfer Active Subscriptions from Account A to Account B
    • There is no need to transfer cancelled or inactive accounts
    • During the transfer, request Subscription on Account A to cancel at period end
    • Create a new Subscription on Account B based on plan_id, using billing_cycle_anchor will allow the Subscription on Account B to begin the moment the Subscription on Account A is cancelled
  5. (not in graphic) Verify all Plan and Subscription information has been moved

Whether you’re using Stripe’s excellent API to migrate your Plans and Subscriptions or doing it manually via their admin the process is basically the same. The customer I was working with had nearly 5,000 customers and over 1,000 active Subscriptions on 4 Plans. So writing a script to do this saved huge amounts of time.

Aside: How do you calculate whether or not it is worth building a script to do this or doing it yourself via Stripe’s admin? Well, the pessimistic view would be something like this comic from the always excellent XKCD re: automation. However, the more practical approach is this comic from XKCD titled Is It Worth The Time?

How did I write the code? Depending on your exact needs and your familiarity in different languages you may want to find a completely different approach to the one I took. However, I’m a PHP guy, this is what I did.

I started by doing a search on Github for “Stripe Migration” (always worth starting here) which led me to this set of simple scripts from Nyalex for migrating Plans and Subscriptions on Stripe from one account to another. This likely saved me 5 to 10 hours of development. (Thanks Nyalex!) I then reached out to him on Twitter to let him know I was about to use his script. We had a nice conversation that helped me to get my head around how his scripts worked.

My modifications to Nyalex’s script were fairly minimal but vital. Since he hadn’t used the scripts in some time they fell out-of-date with Stripe’s latest API version. So I had to make some subtle updates to account for those. Also, the client was using Easy Digital Downloads, a WordPress ecommerce plugin, as their backend so I had to write a few SQL queries to update the Subscription IDs in EDD’s customer table as the process ran. I plan on writing a Pull Request for Nyalex so that I can help keep his set of scripts up-to-date for future uses.

There were, of course, a few hiccups when running the scripts.

First, the client’s server would time out if I tried to process all 4,800 accounts at once. Each account creates several Stripe API calls (about 7) so even with Stripe’s limit of 100 accounts at-a-time that is still a hefty 700 API calls. So understandably I had to find the right number that the server’s setup could handle without choking. I also slimmed down the number of API calls slightly from the default. I did this by creating some mock API calls for the cancel and create Subscription calls and let the script run a few times until I found the right number. For this particular client it was 20 accounts at a time being processed. Which meant the script ran over 200 times to complete the process. Because I was purposefully doing this manually, rather than setting up the script to run end-over-end, this process took a little over an hour.

Second, prior to creating those mock calls I accidentally duplicated a few subscriptions for 23 accounts and needed to go back and manually cancel them all before re-running the script. I recommend not doing this. Again, it is a drawback that Stripe cannot migrate live Accounts as Test accounts so that you can do test runs on this sort of thing but it is understandable.

And, lastly, I didn’t properly create a log file for all of the transfers as they were done so I had to manually save the output of Nyalex’s script to a text file. I think I’d like to update the scripts to create a log file of old subscription ID, customer email address, and new subscription ID at the very least. This would have saved me a lot of time and would give me a “back up” of sorts should any customers have been missed. Also, since the scripts only attempt to migrate active Subscriptions it would have been nice to extend the scripts to log inactive Customers too just as a double-check that those Customers were looked at.

Overall this was an interesting project to take on and I’m hoping that my knowledge from this project will get reused in the future. If you need to migrate from one Stripe account to another please reach out.