I recently described a way for apps to identify unique humans while maintaining personal privacy. I briefly mentioned basic income as a potential application, and in this essay I’d like to make a strong case for why basic income is important, and why now is the time to build it.
User authentication is a mess. Rolling your own auth is a pain, but implementing SSO with Google, Facebook or Github leads to loss of privacy for users, and also user confusion (anyone who has run a webapp knows users are constantly forgetting which sign-in option they chose). This post proposes a new SSO system I’m calling FixedID, which I believe is strictly superior to “Sign In with Google/Facebook” for both users and app developers, and in many cases superior to email/password auth as well.
All taxes are distortive, but some are necessary. Most people agree that governments provide many useful services, but there’s plenty of disagreement about how to pay for them. In the USA we’ve mostly settled on a combination of income and (depending on your state) sales and property taxes to fund the government. There are some other minor revenue sources (customs duties, gasoline tax) but that’s basically it.
I’m writing this at the tail end of long-planned vacation to Chile. When we first arrived two weeks ago I had planned on buying a cheap prepaid data plan immediately, since my US carrier still has outrageous international roaming rates. Unfortunately, we took a long time to get out of the airport and I had a commitment that first evening, so I didn’t get the chance.
It feels like the world is getting faster. It’s become a cliche to refer to the “exponential progress” of technology, but between Moore’s Law and similar (if less easily measured) trends in software development, exponential progress is a reality. This reality is reflected in the history of tech leaders as well. IBM dominated the computer industry from the release of System/360 in 1964 until the commodization of PC hardware thanks to Microsoft, which consolidated its position with the release of Windows 3.1 in 1992. Microsoft was the industry king and Wall Street darling until it became clear that the web was the new desktop, catapulting Google (almost by default) to the top of the industry circa 2004. Sometime in the next decade – the timeline is unavoidably fuzzy, because the transition isn’t over – it began to feel like Facebook has a greater claim to the title of sector leader.
I didn’t particularly want to move to Silicon Valley. In August of 2016 I had recently passed Google’s hiring committee, and was going through the team matching process trying to find a home. I talked to 3 teams in the Bay Area and one in Colorado, but I kept pestering my recruiter to send me more – specifically, to send me some matches in my hometown of Seattle.
This is a short post just to point to a library I published on npm today. react-native-keep-awake allows you to prevent the screen from going to sleep while your app is active. It’s useful for things like navigation or video playback, where the user expects the app to remain visible over long periods without touch interaction.
It’s been nearly eight months since I first played with React Native. Since that time I’ve spent a lot of time working with the framework, eventually joining the core team. For the last six months, I’ve also been using React Native full time and building my business’s primary iOS application, Emberall, in it. We just released our first public version to the App Store, so now is a great time to do a retrospective on how development with React Native feels. I want React Native to succeed and believe it will, but I’ll also try to be honest about the places where the project still needs to improve.
React Native is an exciting technology, as I’ve written about before. Facebook and outside collaborators are working hard and iterating fast on the core technology, and a community of users and library authors is growing and maturing quickly.
Typically, when designing a view either on the web or mobile it should be responsive to changes in size and be usable in a variety of aspect ratios. When done correctly, this allows a mobile app to provide a useful UI in landscape or portrait orientation. However, sometimes it’s still useful to know the display orientation of the device.
Last month I wrote a bit about debugging React Native in the Chrome console. For some types of development, particularly experimenting with APIs that you’re not familiar with, the console is a very productive environment.
My sister Jackie recently asked me to review her resume. She’s planning on taking a break from her PhD program in physics to try out work in software development through an internship (and if you’re looking for an extremely bright, motivated intern this summer, especially in the Seattle area, let me know). This is what the resume draft she sent me looks like, more or less:
At Emberall we’re using React Native for our newest mobile video history recording application, which should be available in a few months for both iOS and Android. Given that React Native was only open sourced in April and is still under very active development, the tools are in flux as well.
As I’ve been experimenting with integrating React Native into the existing Emberall app (post coming soon) I found that the app consistently crashed on the Nexus 9 I was using for testing with the strange error:
At Emberall we use rails_admin as an easy way to administer data in our backend. It’s convenient because it gives us a visual way to edit data and fix customer issues that any employee can use without having to learn SQL.
At Emberall we’re in the relatively uncommon position of developing a consumer Android application while enjoying complete control over the hardware it’s deployed to (our Emberall video recorders). This gives us the ability to integrate the way our software and hardware work together extremely tightly, leading to a delightful user experience.
Since I wasn’t able to find any information online on the best way to integrate Clojurescript into the Rails asset pipeline, I’ve decided to write up our experiences here. If you’ve found a more straightforward way to accomplish this, please feel free to chime in in the comments!
For our main Rails application, we’re currently migrating from the process-based Unicorn server to the thread-focused Puma. This should allow us to serve more requests with a smaller memory footprint, and paves the way for a possible future transition to JRuby, which can benefit from true multi-thread concurrency.
Quick tip for better Rails performance when working within a VM with a shared folder: keep the 3rd party gems out of the shared folder! I recently noticed a performance regression in the Emberall test suite that caused the tests to consistently take about 3x as long to run as before. We hadn’t made any changes to the version of Ruby or Rails, and the CI server build times weren’t affected.
In my last post I discussed some of the attractive elements of the Clojure ecosystem. The primary Emberall app is still written in Rails and that’s still where most development happens, so I decided to take some time to enable the auto-refresh functionality built into Clojure’s Ring. Rails already gets us halfway there by automatically reloading updated files on the server, but by following these steps any open pages will also automatically refresh when code is updated in development.
I’ve been experimenting with Clojure for a new product we’re working on at Emberall. We’re already using React fairly extensively in our front-end code in the main app, and I became intrigued by the possibilities of Reagent, a ClojureScript wrapper for the framework.
This morning I got an email from New Relic informing me that the CPU load on Emberall’s staging server had been over 80% for over 5 minutes. It’s not unusual for the CPU to peg pretty high during video reencoding, and even to hit 100% for a limited time when a user has uploaded a lot of videos at once and they’re all being processed. But this was on the staging server, which only I use, and I hadn’t done any uploads this morning.
As emberall.com has grown in the last few months, I’ve had to implement some new processes to make sure the development flow can scale as well. When we only had a couple of active users it was no problem if a bad deploy took the production server offline for an hour while I got around to fixing the issue, but now that we’ve grown and have real, paying users, that kind of approach to downtime doesn’t cut it anymore. These days I have a better defined process surrounding deployments, including a full suite of functional tests that have to pass before a deploy goes live on production. We also recently configured a staging server to perform manual testing of prospective changes before pushing them live.
Pypeline DB is a new Python package that makes it easy to import, explore, transform and export data sets. All data is stored on disk, making it especially appropriate for data too large to fit in RAM or data that you’d like to keep persistent between sessions.
About 8 months ago now I decided it would be handy to have my own server in the cloud, in addition to the limited resources provided by my university and the I’m-still-not-sure-if-I’m-allowed-to-use-it server in the research lab I was part of on campus. Over the next month or so corbt.com was born.