DONN FELKER

Lessons Learned From the Software Industry

  • Home
  • About
  • Caster.IO
  • Fragmented Podcast
  • A Newsletter For Maximizing Your Life
  • Contact

Connect

  • GitHub
  • Instagram
  • LinkedIn
  • RSS
  • Twitter

Powered by Genesis

How To Fix: Jest Did Not Exit

October 23, 2019 by Donn Felker

I was recently doing some work on a Node.JS project and I decided to use Knex.js with Objection.js for my data access to PostgreSQL.

Problem

In usual fashion, I wrote some tests to validate the behavior of the application and while writing the tests in Jest I found the tests were not exiting. I was getting the following error:

Jest did not exit one second after the test run has completed.

This usually means that there are asynchronous operations that weren’t stopped in your tests. Consider running Jest with --detectOpenHandles to troubleshoot this issue.

I ran the tests with --detectOpenHandles and the tests just hung. Nothing happened.

Solution

After some experimenting, I realized I was not destroying my Knex instance and that was keeping the tests from finishing.

In the afterAll() method of Jest I’m now destroying the Knex instance so that the test can finish appropriately.

Here’s a very naive implementation that works for me as an example:

The model – Person.js:

'use strict';

const { Model } = require('objection');
const bcrypt = require('bcryptjs');

class Person extends Model {
    // Table name is the only required property
    static get tableName() {
        return 'persons';
    }

    async $beforeInsert() {
        this.created_at = new Date().toISOString();
        await this.updatePassword();
    }

    async $beforeUpdate(opt, queryContext) {
        await super.$beforeUpdate(opt, queryContext);
        this.updated_at = new Date().toISOString();
        await this.updatePasswordIfChanged(opt.old);
    }

    async updatePassword() {
      // not prod quality, do not copy, example only
      // bcrypt stretches should be much longer
        const hash = await bcrypt.hash(this.password, 1); 
        this.password = hash;
    }    

    async updatePasswordIfChanged(old) {
        if (old.password) {
            const passwordMatches = await bcrypt.compare(this.password, old.password);
            if (!passwordMatches) {
                await this.updatePassword();
            } 
        }    
    }

    static get jsonSchema() {
        return {
            type: 'object',
            required: ['firstName', 'password'],
            properties: {
                firstName: { type: 'string', minLength: 2, maxLength: 255 }
            }
        }
    };
}

module.exports = {
    Person
};

The Test:

const Knex = require('knex');
const knexConfig = require('../knexfile');
const { Model } = require('objection');
const bcrypt = require('bcryptjs');
const { Person } = require('../models/Person');

const knex = Knex(knexConfig.test);

Model.knex(knex);

afterAll((done) => {
  knex.destroy();
  done();
});


test('can update password when a user is already saved', async () => {
  const person = await Person.query().insert({ firstName: 'John', password: 'foo' });
  const passwordMatches = await bcrypt.compare('foo', person.password)
  expect(person.password).not.toBe('foo');
  expect(passwordMatches).toBeTruthy();

  const updatedPerson = await person.$query().patchAndFetch({ password: 'bar' });
  expect(person.password).not.toBe('bar');
  expect(person.password).not.toBe('foo');

  const updatedPasswordMatches = await bcrypt.compare('bar', person.password);
  expect(updatedPasswordMatches).toBeTruthy();
});

Now the test will pass and it will not get hung.

PS: Yes, this is a simple example and the code is not what I’d put into production, so please ignore the content there – this is just an example of how to fix the “Jest did not exit one second after the test run has completed.” issue.

Filed Under: Development Tagged With: development, NodeJS, Testing

Fix: Deploying Docker Instances to AWS Elastic Beanstalk without Default VPC

August 21, 2019 by Donn Felker

Docker Kubernetes

File this under “I hope this helps someone else in the future“.

I was learning Docker and Kubernetes recently and I was trying to get my docker instance running on Amazon AWS Elastic Beanstalk on the us-east-1 region.

I had to configure my beanstalk environment to use a t2.small instance because the npm install command on the t1.micro was timing out.

Upon upgrading and pushing a new version to Travis CI (flow was Git -> Travis CI -> S3 -> Beanstalk) I’d get these errors:

  • Environment named Docker-env is in an invalid state for this operation.
  • Auto Scaling activity failed 5 minutes ago with error: The specified instance type can only be used in a VPC.
  • Message:The security token included in the request is expired
  • Service:Amazon S3, Message:The provided token has expired.
  • A search on the web wasn’t that useful for any of these errors, so hopefully this helps someone by my including them here. Here’s how I fixed this …

The Problem

I didn’t have a default VPC for the us-east-1 region. I needed to create one. (If you accidentally deleted the AWS Amazon Default VPC – see below for how to set it up again).

My problem was that my account is a very old AWS account (I’ve had it forever – set it up probably in 2008-ish) and my us-east-1 did not have a default VPC (needed for a t2.small). I could not create a default VPC (under the ‘Actions’ menu in the AWS VPC section for us-east-1) because my account in us-east-1 was a EC2-Classic and it needed to be an EC2-VPC. Long story short, regions have certain configurations and my configuration was set to EC2-Classic and that was causing a mess of problems.

The Fix

If you can create a Default VPC, do so. There is a link below to show you how to do that. If you can’t … read on …

To fix this I had to submit a support request to Amazon to ask them to upgrade my us-east-1 region to EC2-VPC from an EC2-Classic configuration.

To do that you’ll create a support request (while logged into AWS).

  • Open a new support case in the support console
  • Regarding: Account and Billing Support
  • Service: Account
  • Category: Convert EC2 Classic to VPC

Then fill out your request (ask them to upgrade you to EC2-VPC for that region) and you should be good to go.

A Workaround

In order to keep continuing on my local developments while Amazon converted me to EC2-VPC, I changed regions to Ohio (us-east-2) and recreated a new beanstalk environment and application. This region almost always has a default VPC. If you deleted it on accident, see the link below for how to re-enable the default VPC on that region.

Once your new AWS Beanstalk environment is set up, go into the configuration and change it from t1.micro to t2.small.

Wait for the changes to take effect.
Redeploy.
Presto, docker instance is deployed and I can access the web app via the beanstalk url.

Links

  • How to create a default VPC in an AWS Region
  • Amazon Support request Forum

Photo:
unsplash-logofrank mckenna

Filed Under: Development Tagged With: docker, kubernetes

Flutter Just Might Work

May 23, 2019 by Donn Felker

Flutter

I’ve been posting on twitter about how mobile developers should not ignore the Flutter technology and in response I received a lot of questions to why I’m stating this. I hope this post clarifies why I’m bullish on Flutter.

Build the iOS and Android App at the Same Time

There are many reasons why I feel that Flutter might have a chance of succeeding in the long run, but one of the big ones is that with Flutter you can write the app once and run it on both iOS and Android.

I’m sure everyone is thinking … “well you can already do that with X”.  You’re right, you can build an app with React Native, Kotlin Multi-Platform/Native, Xamarin and as a PWA (Progressive Web App). I’ll talk about each of this later in this article, but first let’s talk about Flutter.

Current Problem: Two Apps, Two Teams and Duplicate Code

Duplicate Code

During my tenure as a mobile developer there’s always been two apps, and two teams (or individuals) managing these apps. One team for for iOS and one team for Android. We wrote the same exact app, but in different languages for different platforms.

Kind of normal right? Most people are thinking “yeah, so what … and the problem is?”

Businesses are paying for the same app to be written twice.

When you read that sentence a loud, it sounds crazy. That’s exactly what CEO’s/Businesses Owners/VP’s/etc think.  Who in their right mind would want to spend twice the amount of money to ship two apps that do the exact same thing but for different platforms? Shouldn’t we be able to write an app once and have it work on both platforms?

Immediately some of you reading this are thinking .. well.. uh NO – that’s not possible. Of course it has to be written twice – once for iOS and once for Android.

Well … not really, we don’t have to follow that same line of thinking … let’s dive in.

A Brief History of Write Once for Mobile

Take a look at app history and you’ll notice that there have been apps written to target both platforms for years. A prime example: Most games are written to target both platforms. This is why the widgets (buttons, text boxes, etc) never look like system widgets in games.  Widgets in games use their own custom built ui-widgets – giving them a style all their own, custom to the game (or app).  Not sure what I’m talking about? Go open a popular game and look at the buttons. They’re not native looking buttons you’d see in Android. Very often they’re some custom thing that is part of the game. Go look at that same button on the other platform (if you’re on iOS go to Android and vice versa) – you’ll notice that the button is exactly the same (in most cases – there are caveats to everything).

So how are game companies accomplishing this but not us day-to-day app devs?

These game companies are usually coding very close to the metal – using C as their language. They compile to the platform of their choosing (iOS or Android) and such. They draw directly to the canvas and they do not use system widgets (gaming sdk’s aside – e.g. – Google Play Games, etc).

In other words …

They’re drawing all of their own UI.

They have their own UI tool kit that they use to render a button, a text box, a dropdown, etc. This UI tool kit is written by them very often and is compiled as part of the game – it’s not part of the Android or iOS platform.

We as productive app developers don’t have that luxury, and let’s be 100% real here. Being a real-deal, low-level C-programming game dev is hard, real hard. Most of us are game dev and most of us are not going to create our own UI widgets just so we can get back to handling regular use cases like “adding a button and a text box to a form”

From a financial point of view, for a business, writing an app twice doesn’t make sense.  This is a big concern for businesses (large and small).

Cross-Platform Options

Since the inception of the two major players in mobile (iOS and Android) various cross-platform systems have attempted to solve the problem of creating two of the same app. Below are a number of options that folks have used.

Phonegap

PhoneGap/Cordova

This didn’t really work out.

PhoneGap was not performant, and just felt kind of clunky. Felt wrong from the jump.  When you tapped on a button or scrolled there was noticeable lag and it was to the point where it was frustrating to the user.

Integrating with existing platform components was rather painful and caused a lot of development issues.

Overall the solution aways felt half baked and the user experience was never top notch. It always felt as if the app is cobbled together.

I don’t recommend folks going this route. If they are evaluating this route I often will point them to just using. A PWA (Progressive Web App).

React Native

React Native

React Native get’s us really close but it still falls a bit short …

We still have this weird latency issue (sometimes), and a JavaScript bridge we that we have to deal with on both platforms if we need to get into lower level stuff.

We are using the native UI widgets under the hood (sorta), so we do get the true “native” feel which is nice.

Ultimately, we’re still running JS which call into native Android widgets and iOS widgets via a JavaScript bridge. With React Native we’re not running a custom UI, we’re writing JavaScript that gets mapped to native OS calls.  This does have a small performance penalty.

It “kinda” feels right, but still feels kind of wrong – however it’s a great step and in my opinion has  a lot of potential as technology improves. Don’t underestimate the JavaScript community, it is HUGE and powerful.

The problem I found here though (other than the bridge) is that I had to learn both platforms, in and out to really be effective at it when I needed to integrate platform specific things (this is normally where cross platform apps fall down anyway).  This is not something that is unique to my experience either. Gabriel Peal worked at AirBnb where they had a large React Native installation and he shared similar sentiments in his detailed blog post about how they migrated away from React Native.

Another thing that I found difficult was testing on React Native. It was “ok”, but I still felt I was being lied to in regards to the tests. Was I testing React Native? Or was I testing the app? Sometimes tests passed, but the UI didn’t work on a device. So my skepticism meter shot up. I’m sure there was something I was missing, but this goes back to having to know both platforms and the intricacies of both in order to get the bits to align properly.

All that aside, I still feel rather positive about React Native and my thoughts are:

If you don’t need to dive into the lower internals of an OS, and your app is 100% React Native, you can do some amazing stuff with it and it’s still a contender in that area

Great apps for this are LOB apps (Line of Business), simple forms over data, etc. You definitely would not want to build anything super complex with it as I could see it becoming rather iffy quickly. I’ve consulted with a few companies who have went really deep with React Native to run into problems when their apps were large. At that point they either had to re-write part of the their stack to be more native or had to re-evaluate certain pieces of their app.

As usual, it’s all about tradeoffs.

Xamarin

Xamarin works amazingly well, the problem here is that while I was able to achieve feature parity with Xamarin I felt that I had to learn both platforms due to the design nature of both platforms. This was rather painful. I was able to share 80% of the code, but the last 20% made it almost unbearable as I was having to learn both platforms again to create the UI. 

Learning both platforms is a show-stopper. I want to write the app once and be done with it.

That said, this technology is quite viable if your team is a .NET based team and you need an app that is not a game. I know many companies in the mid-west who use Xamarin to their success. Microsoft has done a great job of supporting this tool over the years.  This, with Xamarin Forms, makes it super easy to build and ship a cross-platform app, that “just works”.

However, for me, I can’t rely on it as I need to know .NET, iOS and Android systems and widgets. Under the hood these things map to existing widgets and while you can get featured parity quickly, you do have to maintain two platforms at some level and know the intricacies of each.

Kotlin

Kotlin Multiplatform / Native

I love Kotlin. In fact, I can’t imagine writing another Android only app in Java ever again.

However, I don’t think Kotlin native is where it’s at. I feel that Kotlin native is a distraction and many industry leaders are talking about how great it is and without a doubt it is a great technical feat … but … here’s where it falls down …

It’s a JVM based language.

Convincing iOS developers or anyone else that they need to learn Kotlin to write a cross platform app is simply not going to happen. Sure, some folks will follow suit, but the movement will be small.

For example, most non-Android devs that I know will just stop right at “Install JDK”. Most of those people are already thinking “NOPE, no thanks.”. Yes, I know that other Multiplatform tools require the same, but I’m trying to illustrate a point here.

I know this is hard to hear, but this is the reality out there. Java and the JVM, while still popular is not the shining knight most people want it to be. It’s more like some clunky armor that works. Kotlin just happens to be the new and improved armor that works 10x better and as some nice aesthetics. However, I still have to go through the pain of getting the armor on before I can use it.

In other words, you’re going to peel Swift away from a iOS developers cold dead hands. Convincing them to move to Kotlin, while possible, is something I’ve tried and it doesn’t work that well. It’s a pipe dream.

I feel that Kotlin Multiplatform and Kotlin to JavaScript are cool pieces of tech, but the user adoption might not be there. JavaScript already has a huge jump start on Kotlin in regards to adoption, but ultimately we get back to the same argument – what one person loves the other person hates. It is what it is.

 

PWA - Progressive Web App

PWA – Progressive Web Apps

This one is interesting because I’m in a very small camp of people who believe that the web will win one day. It’s the ultimate platform.

I do feel that one day we’ll see that there are a handful of super useful native apps (Navigation, Games, Entertainment, systems control, etc) but for the most part everything else will be web based. This is where PWA’s come in.

I’ve seen some really good PWA’s in the last few years.

The problem here is that it’s not a “native” app and you have to put a wrapper around it. That just feels clunky. People want “an app”. Actually they don’t want an “app”. They want an “icon” they can tap on, one they can search for on the App Store.

I don’t think were here yet, for PWA’s … BUT …. I will say this … when I consult companies for mobile apps and they ask me for a quote, more often than not I’ll end up talking them out of an app.

Why?

Because they don’t need one. Someone can go to a link and get a super fast loading HTML web app that does everything they need. I usually tell them “this is v1”, if you need XYZ later, then we can look at an app. The we get to that point though, I’ll usually look cross platform as most companies do not need to write a game/etc. 

Will Any of These Technologies Actually Work?

In the right situation, yes. They will work. However, I don’t think any of these are truly revolutionary. React Native and Xamarin really helped spearhead what some of the possibilities were like, but ultimately it felt like we were still writing two apps and debugging two platforms/etc. As much hype as Kotlin Multiplatform is getting in the Android world, I don’t feel it’s that popular. In the last few weeks I’ve spoken to close to a hundred devs and none of them have heard of Kotlin Multiplatform unless they were an Android dev.

Kotlin Multiplatform is cool, but thats where it stops currently. Maybe that will change – only time will tell.

That’s just my .02 and I know its not a popular one – especially since the majority of the work I do is in the Kotlin and JVM camp right now. When coming to this conclusion I did my best to step out of my own field of influence and observe things from alternative perspectives. I’ve talked to people in all of these areas – React Native, Xamarin, Kotlin Multiplatform and then day-to-day iOS devs.

The short of it is … people grow attachments to their tools. It’s hard to get people to change. Developers are optimistic by nature and due to that optimism our outlook is often shaded with a lens that is not often the reality that we live in.

Here’s the thing – all of these cross platform technologies suffer from a similar problem – we’re using an existing language and/or platform that you’re already familiar with to create a cross-platform app. This works well if you already write JavaScript, or .NET or Kotlin, but if you don’t … well… good luck with convincing others to try it. Habits are hard to break, especially when they’re not yours.

… and this is where Dart and Flutter come in to play …

Why Flutter Might Work

When I first heard of Flutter I was bearish on it. I’ve seen so many of these cross-platform technologies that I figured it was another fly by night type of tech that was nothing to write home about.

That changed when Kaushik Gopal (@kaushikgopal) and I talked to Eugenio Marletti (@workingkills) on the Fragmented Podcast about his experience with Flutter (Part 1 and Part 2).

I learned in that conversation what the power of Flutter really was and how, if executed properly, it could become a powerhouse in the industry.

The Flutter Developer Experience

Before I hop into the full developer experience I want to cover a brief history of Android and some of the things that have made developing for Android not as enjoyable as it could have been …

One of the things that is frustrating about Android development is that the system was not built with testing in mind. This makes testing very frustrating. I don’t blame the engineers at Android for this. Android was a small company before Google bought them and brought them in house.

In fact, Android was originally built to be a Camera operating system.

Read that again and let it sink in for a second.

Android was a small company before Google acquired them and the first lines of Android code were written in 2003. Yes. It’s that old. Google didn’t buy the company until 2005.

I’m sure you’re painting a picture in your mind that helps illustrate why things are the way they are in Android …  in short – its old and complicated.

Android started with a foundation back in 2003 that was not conducive to testing especially in a camera operating sense of the world. Fast forward to current day and we have Kotlin and many tools and frameworks to help us with testing, but thats what they do … they help. If you dive deep into these libraries you see there’s a lot of magic that’s happening to help combat the problem of dealing with a large legacy codebase like Android. Lots of retries, lots of special cases all over the place. I’m grateful for the libraries, but it doesn’t fix the root cause that we have a huge complicated legacy beast on our hands (Android itself).

I commend the Android team(s) at Google for helping make things better, but lets say it like it is …

Android is a pig with lipstick.

Albeit, its a great pig with lipstick. I favor Android over iOS any day, but … it’s easy to see why things are now rather brittle.

Which brings me back to experience … I’ve been developing android apps for nearly 11 years now. I started with v1 and I’m still here. Things have gotten a lot better, but there is s still a huge level of frustration with day to day development and that experience is a real downer.

I’m not going to lie, I’ve often thought about throwing in the towel on Android development because of the frustration level of it.

Before you say “Well Donn, you must have been working on the wrong apps, or the apps were built incorrectly.”

Possibly. Maybe. I’m a consultant. I see some amazingly built apps and I see some real piles of shit. It’s a mixed bag. I do my best to fix things, but at the end of the day there’s only so much budget to go around.

Back to developer experience …

I read the following quote somewhere, but I cannot find it (if you do find the source, let me know and I’ll link it):

Ruby on Rails is a joy to work with.

Wait, what? Android, now Rails?

Where are you going with this, Donn?

Hang in there, trust me, it’s going somewhere …

I’ve been doing Rails development for many years now and I completely agree. Working with Rails is a joy. The ruby language is fantastic and I find myself enjoying working on Rails projects. I can express my intent easily and I find it fun (I also feel this way about the Kotlin language, but not the  Android framework, in particular).

Flutter is the first tech that I’ve worked with in mobile where I truly enjoyed the development experience. You’re using very “React like” programming models (mutating state, uni-directional data flow, etc). My previous 10-11 years have been spent in antiquated Android development, and to be 100% honest, it’s been fun, but also very frustrating.

When I wrote my first Flutter app I was thoroughly impressed with what I was able to do. I had worked with React before so some of the concepts moved over easily for me. It simply made sense. State management, building the UI with components in code, a reactive like architecture. It simply felt right.

One of the real deal things that got me interested in Flutter was testing support. It’s baked in. Very rails-esque if you ask me.

I did run into some areas that were confusing during development, but thats normal during any exploration of any new tech. I was able to resolve them easily – same could be said of any of the other platforms too. It’s just part of the learning experience.

Overall, I found the experience of setting up a new project easy, fast and I was able to hop in real quick and be productive (after I grokked the system).

The Dart Programming Language

Flutter apps are written in Dart.

I like Dart.

That said, I’m not a raving fan of it either.

I think Matt Sullivan put it best in one of his talks (sorry can’t find the link) … and this is paraphrased …

“Dart is kind of a mundane language. It’s great at its job, but it’s nothing to rave about. In fact, some might find it boring, but that probably works in its favor as its easy to understand and apply.

I totally agree with that.

I first wrote dart back in 2012 at Google IO in a code lab. It felt very “JavaScripty”. In fact, Dart is an ECMA standard, so you’ll find a lot of similarity between Dart and JavaScript.

Learning Dart is fairly easy and if you have any experience with any C style language you’ll pick it up quickly.

Why Dart though?

As mentioned earlier – it’s hard to peel tools away from existing developers hands. If they like Swift and you tell them to write Kotlin, well … that’s going to be an interesting kerfuffle.

The Flutter team chose Dart for many reasons, as outlined in this article: Why Flutter Uses Dart – Hacker Noon and I think one of the huge benefits of using Dart is having a “newish” language to support a new cross platform technology. I can’t come to Flutter and be encumbered by previous notions of how I think Dart sucks or Dart this or Dart that.

Why?

Most likely I’ve not used Dart. I fact, I’ve never met a dev who has used it outside of Flutter, yet. I know they exist, but they’re rare.

This opens a door that was previously closed. Now, as a developer, I have the opportunity to learn a new framework for cross platform development and I’m not inhibited by a previous experience with a given language. Its a new landscape that I’m embarking on and that for a developer is a very freeing feeling.

It’s almost like a painter who is given a new set of brushes they’ve never used before on a canvas of a type they’ve never used before with a paint type they’ve never used before. Sure, they may be a great painter, but now they get to explore and see what they can do with these new tools. They see it as a playground.

The same thing happens when you start with with Flutter. It’s a new playground. You’ll find that you can/can’t do X with Dart or that you hav etc do it a different way. Like it or not, you’re learning and growing and that’s a good feeling as a developer.

Overall, Dart was a great choice and I think it has helped the adoption of the platform more than what most people give it credit for.

No More Native Widgets

I’m going to dumb this down a bit, but in short – Flutter doesn’t call out to the Android UI toolkit. It does not call the EditText or TextView or anything like that.

Flutter draws directly to a canvas (basically) and does not interact with existing iOS or Android widgets. Just like a game would – it’s drawing everything.

You might be wondering how this is done … kind of magic, right? It looks like regular Android and iOS buttons …

This is done with Dart at the higher level (where they recreate the widgets themselves or with a theme they create) and then render them to the screen with with Skia (C++), Dart and some Text components directly to the canvas.

Flutter Architecture

What this means is that Flutter controls the entire drawing of the widget. So they can say a button “looks like this” and a text box “looks like this” and they can (and do) make them look the same on each platform.

This also allows for the Flutter team to deterministically add platform specific features to each widget. For example, a list view item in Android would simply be a list item. In iOS it might have a chevron on the right hand side. Many things like this are managed by Flutter.

Just like a game, all the rendering is handled via Flutter. This can be seen as a risk because of being out of date with the platform during upgrades, but if you’re using the basic components that are provided by Flutter it’s a no brainer.  They also do a great job of keeping up with the changes.

Flutter Makes Design Easier (if you allow it)

As a developer one of the things I like to do is ship often. What deters this from happening is a good design language.

Back when I was a web developer full time I was ecstatic when Twitter Bootstrap was released for the web. I could easily build great looking sites with minimal effort as long as I use this design framework. It was great.

We needed something like this for Android and other platforms.

Material design enabled this to happen. Unfortunately, you had to often build your own widgets for Android and iOS (though that has changed recently with some of the design support libraries).

When building a Flutter app I prefer to use the Material Design Theme out of the box to build something. What the Flutter team has done is recreate the Material Design widgets for both platforms. So I will get a toolbar, buttons, inputs and text that looks and acts as it should for both Android and iOS, all without me having to do anything other than saying I need a Button here, and some text there, etc. Flutter renders it correctly on both platforms and it looks great.

This is huge.

Testing

I don’t have to rely on Espresso for Android and whatever tool is used for iOS.

That in itself is huge.

Testing is built in from the ground up. You can have one of the following three test types:

  • Unit Test: tests a single function, method or class
  • Widget Test: Tests a single widget (known as a component in other UI frameworks typically)
  • Integration Tests: Test a complete app or a feature of an app.

You can easily set up your tests and write code with confidence quickly. To me, this is a HUGE win and something that attracts me to the platform.

Greenfield vs Brownfield

As with anything there are some pitfalls with new tech. One such thing is Greenfield vs Brownfield development.

Let’s quickly define the terms:

  • Greenfield: Brand new app development
  • Brownfield: Existing app development, adding featureschangesetc

At the time of this writing, Flutter is great for Greenfield development where the entire app is in Flutter.

The same can not be said of the opposite. Brownfield Flutter apps are not possible at this time and the Flutter team is currently working on a solution.

I’m not sure its good to mix the two though. This creates problems later down the road as the platform zealots of each team (Android and iOS) want to rip out the Flutter stuff, while the Flutter devs want more of the app to be Flutter.

I had his same experience with React Native and brownfield development. Native devs wanted it gone. React devs wanted more React. Both have their preference.

When an app is build Greenfield with Flutter, the team embraces the tech and makes it work.

If you’re thinking about Flutter, I advise building an app from the ground up with Flutter or recreating another simple app you have with Flutter.

Skepticism

With each new piece of tech some high level of skepticism is bound to follow. Flutter is not immune to this.

Some common concerns I see is:

  • It’s a Google product, they could kill it tomorrow.
  • Dart will never be mainstream, it’s also a Google product that could be killed
  • I can’t do xyz with it.

Listen, Flutter is not a silver bullet, but it’s something that should be evaluated. Imagine fixing a bug ONCE and it’s fixed on both platforms. Kind of reminds me of the web days. Fix it once and it’s fixed for everyone. That would be fantastic and businesses drool over this idea. You know how much money could be saved? Productivity increase? This is why things like React Native and Xamarin have gained traction.

I do have my share of skepticism though too. I feel that Flutter is a fantastic cross platform tech for Android and iOS. The Flutter team has recently announced Hummingbird – Flutter for the Web. This is where I come to a hard stop.

I feel that HTML/CSS/JS are the web and thats what belongs there. They’ve been the incumbent since the inception of the web. They’ve been improved and this has not strayed. We’ve tried other cross platform tech on the web before and it’s always failed.

We tried Java Applets, we tried Active-X, we tried Flash, we tried Silverlight, etc. All were killed and dominated by HTML/CSS/JS. The closest was Flash, but web now how that panned out.

I know that Hummingbird is going to compile down to some form of HTML and CSS with canvas rendering, which is exactly what its doing (canvas drawing) in Android/iOS. So… this might have some legs … I’m not sure though. This is a bit iffy for me right now and I’m going to stand on the sidelines and see how it unfolds. I’m not confident it will work out, its such a huge jump from mobile web, that it’s hard to fathom what and now how that would work efficiently for performance and for development and debugging.

This is also why I’ve also felt that web will win one day. Our devices will get fast enough, the networks will have enough capacity and HTML/JS integration will become so good with the mobile devices that we will end up writing everything as a PWA/Web App of some sort.

When will that happen, I’m not sure. We’re definitely not there yet. However, watch Google IO and look at the sessions. You’ll see there are always a good amount of Web and PWA talks. For good reason, Google see’s it too. In fact, if we can get everything over to the web, things are easier for everyone. Easier to build for, easier to manage, though there is some skepticism about app stores/etc. I think those will go away one day too, we’ll see though…

The Flutter Community

This last point is one worth bellowing from a rooftop.

Without a community any piece of tech will fail.

Flutter has a raving community of fans. I’m in that camp. I’m not saying that it’s raving and great because I’m in it either. It’s not confirmation bias at work, not at all.

Look at all of the meetups, the blogs, the videos, podcasts, conference talks, etc. Flutter has gained a lot of momentum.

Whilst not covered here in detail – there is a significant open source movement with Dart packages that can be used on Flutter. Explore them here: Dart packages You can find a ton of packages to do all kinds of stuff that you need to do. All built, supported and used by the community at large. It sort of reminds me of the early Node.js days with NPM and early Rails and rubygems days. Exciting times.

Try It, You’ll Probably Like It

Flutter a new way to write cross platform apps that is not encumbered by previous technologies. It allows us to write apps that target both platforms with ease. It gives you a new programming language and paradigm (uni-directional data) to learn and follow. When you’re done compiling you’re left with two files – one for Android and one for iOS and they look, and act  like iOS and Android apps respectively – all the way down to how a list bounces when you hit the end of it (it varies per platform).

Filed Under: Development, Misc, Podcast Tagged With: flutter, kotlin multiplatform, phoengap, pwa, react native, xamarin

What Blog Platform Should I Use?

May 9, 2019 by Donn Felker

What Blog Platform Should I Use?

In a very recent email I wrote about how you need to have a blog.

The question that pops up next is usually …

What blog platform should I use? Medium? WordPress? Gatsby? Jekyll? Or something else?

This is a HUGELY important question that needs a bit of thought put into it … but first things first …

You Need to Focus on Writing

Before I get into comparing the vast array of options that you have out there I want to state that if your goal is to start bogging then ….

YOU SHOULD NOT BE FOCUSING ON BUILDING SOFTWARE TO RUN A BLOG

In other words, if you’re a software engineer (and some of you are) you should not get consumed with “building my blog” with some latest and greatest technology that you can learn along the way.

If your goal is to write ….

Then put your ego away and start writing.

If your goal is to learn a new technology then stop reading this and go learn a new technology.

Far too often I see software folks lose all of their time “building” something like a blog with technology X, Y and Z and then never ship a blog post because they were too busy optimizing CSS, HTML, JavaScript, deployment methods with integrated CI/CD pipelines.

All of that is a waste of time if your goal is to start writing a blog.

So focus on writing – not on building a blog engine.

Choosing a Platform

Choosing a platform can turn into a serious case of analysis paralysis. I hope to solve that for you today by comparing some of the top platforms and what they have to offer (on the good and bad front).

At this time I’m going to compare the following blog systems that you can use.

  • Medium
  • WordPress
  • Ghost
  • Static Sites (Jekyll, Gatsby, etc)

I’m not going to cover SquareSpace or Wix or Blogger or any of those because I don’t feel they’re in the top three choices for the folks that read this blog (mainly software engineers and entrepreneurs).

Medium

Everyone loves Medium because it’s drop dead simple to get started with blogging. You can sign up for a free account and then start writing in their editor in less than a minute.

The tooling that they have is top notch. The editor is gorgeous and they make it really simple to craft your content quickly. They also have a very powerful recommendation engine for readers. Meaning that if you have a blog on Dog Grooming and you write about Dog Shampoos then another reader who is reading another dog blog about walking dogs (on Medium) then there is a very high chance that Medium will recommend your article to them to read next. Again this is only for other blogs on Medium. Medium will not recommend other sites to visit for you to find similar content. Just doesn’t work way. The power of their network recommendation engines for exposing your content to others is fantastic.

However, that’s where the great news comes to a close. Medium has more downfalls than positives in my opinion:

  • You have no ability to customize your blog.
  • You CANNOT ADD features like:
    • Custom Domains
    • Email sign up forms
    • Payment forms
    • Customized landing pages
    • Contact pages
    • Custom integrations
    • Etc

I could write a small book about things I don’t like about Medium.

Lastly, and most importantly, if your content is on Medium –

You are the product.

Meaning that Medium is using YOU as their product to sell other services.

Medium is using YOUR content as a way to recommend other things to other viewers.

Medium is using your content as a place for them to throw up their pay wall to get folks to convert to paid members.

They own everything on the site and can do that they want with it (to an extent of course).

Lastly, one of the things that REALLY bugs me about Medium is that you cannot have your own domain (they use allow this, but not anymore). That means your blog will be medium.com/@yourusername

So … thats kind of lame.

Thats like having a business and then printing your AOL email address on your business card.

In other words – it looks like shit it makes you and your brand look half-assed.

That said, Medium is simply a “easy to get going” blog. Game over.

PROS

  • Super simple to get started
  • Gorgeous editor
  • Great Recommendation Engine

CONS

  • You are their product
  • No custom domains, have to use the ugly medium.com/@yourusername format
  • No ability to provide landing pages, payments, custom pages, forms, opt-in, etc
  • Locked into their platform
  • Integrations are poor

WordPress

WordPress is the 800 pound gorilla in the blogging world (and internet in general). It has been reported that WordPress powers over 1/3 of the internet.

Thats wild. That’s a lot of sites. Apparently WordPress is doing something right.

To get set up with WordPress, you have a couple of options:

  1. Host on WordPress.com (they manage it)
  2. Self host or managed hosting.

Hosting on WordPress.com makes it easy to get going, but you’re limited because WordPress.com restricts certain plugins from being installed or utilized and there are a few other restrictions. Therefore I’m going to focus on the self-hosted or managed hosting solution. I’ll provide some links for self hosting and and managed solutions below. Sure, you’ll pay a few bucks, but it’s worth its weight in gold.

WordPress is very powerful. You can build a blog to a full blow website using WordPress. In this instance you will be building a blog.

You can use one of the built in themes or you can search for free themes on the internet (you can also search for premium themes if you don’t mind spending a few bucks). I recommend searching for “WordPress Themes” or “Free WordPress Themes” or “https://www.google.com/search?q=premium+wordpress+themes” if you’re searching online.

One of the best things about WordPress is the powerful plugin ecosystem. There are hundreds of thousands of plugins for WordPress. If you can think of it, its very possible a plugin has been created for WordPress. Plugins allow you to quickly add new features to your blog/site without any additional coding.

With a WordPress plugin you’ll be able to easily add email newsletter option support by adding of any number of email plugins that will allow you to do that. (You may need a email list provider already, such as ConvertKit, MailChimp, etc) but the plugins will be there for you to easily add it to the side bar or bottom/top of your site.

You can create custom pages to house custom content that is perhaps not a blog post, but something like a landing page where you decide you sell a product. Speaking of selling things, you can sell products on WordPress if you use one of the premium plugins like WooCommerce or Easy Digital Downloads.

If you think about doing something down the line, most likely it can already be done with WordPress.

Writing in WordPress is drop dead simple too. You create a new post, give it a title and write your blog post as you normally would. Add images, audio, video, etc all via the online editor that is built into WordPress. Hit publish and you’re live.

Hosting WordPress

I recommend using managed solution to handle your WordPress installation. I’ve tried running my own servers and then moved over to managed hosting years ago and I highly recommend it.

I recommend using a hosted solution such as:

  • WpEngine
  • FlyWheel

What about GoDaddy? Meh.

GoDaddy overloads their servers with other sites which can be a real problem when your site needs to be responsive. WpEngine and FlyWheel have great response times and have fast servers and don’t overload you with other folks. If you have a problem with anything you can reach out to them and they’ll help you.

I’ve even had WpEngine representatives write some code for me to fix a particular image problem I had with their CDN – which brings up a good point. All of their images are stored on a CDN and delivered globally – making your site load that much faster.

Lastly, since you’ll be running your own blog you can have your own custom domain.

PROS

  • Simple to setup with a managed host
  • A huge plugin ecosystem
  • Very customizable
  • Good Editor
  • Supports Custom Domains

CONS

  • You have to pay $$ to host it
  • It can get slow if you over load your site with plugins
  • Often targeted by hackers because of how popular it is (if you stay with a managed host, like WpEngine they do a great job of keeping you up to date with security releases.)

Ghost

Ghost is another open source platform that is similar to WordPress but built on completely different technology. One of the biggest selling points of Ghost is that it’s fast.

The editor is simple and is very easy to use and you’ll find yourself creating some great looking pages quickly.

Ghost also offers a set of plugins, but it does not match the breadth of WordPress and that’s a downfall.

Hosting Ghost

Installation is where you’ll get stuck because you either need to install it yourself or host it. I’ll focus on hosting it.

At this point I’d only feel comfortable hosting on Ghost’s platform (Ghost(Pro) Pricing – Hosting from the creators of Ghost – Ghost.org) as they have the necessary skills to ensure that it runs correctly. I’d be skeptical that it would run correction or efficiently on another hosting platform.

Custom domains are also supported, which is great.

PROS

  • Simple to setup with a managed host
  • A growing plugin ecosystem
  • Good Editor

CONS

  • You have to pay $$ for managed hosting
  • Customization options are limited

Gatsby/Jekyll/Hugo/Etc

This section is meant to cover all static sites. Static sites don’t have a database and render pure HTML to the browser. This typically results in a site that is very fast with minimal configuration and can scale very well due to demand.

While these benefits sounds great there are a lot of downfalls.

Unfortunately you need to learn a templating language (such as markdown or something else). You’ll often need to work with HTML/CSS and perhaps some JavaScript. If you’re a coder, then this might be something that is interesting to you. Otherwise, this is something you’ll ant to avoid.

However, it is important to remember that the point of the blog is so that you can start writing, not create software to render the blog. If you find yourself writing HTML/CSS/JavasScript to render you’re writing … well … what are you really doing then?

Static sites do offer a lot of flexibility though. You can code them to do whatever you want.

Want a payment form?

Code it.

Want a email opt-inform?

Code it.

Want an Image Gallery?

Code it.

Sure, there are other tools that you could use to provide this functionality, and you should evaluate those … but you get the point… a static site through one of the many static site generators.

The real rub here is that your blog is going to be written in a text editor. You typically do not get a great editor to write your blog in. Furthermore, very often you’ll need to “compile” your pages so that they’re read to go on the web. Once again, you’ll need some technical prowess to handle this.

Hosting a Static Site

Hosting a static site requires that you have a place to put the files. Typically this can be done on a web server, Amazon S3, GitHub pages, or through other services like Nelify and Zeit. You will need some technical know how in order to set these up (which is beyond the scope of this article).

As you can imagine, since Gatsby is very customizable and can be hosted anywhere (it’s just HTML) you will be able to use a custom domain.

PROS

  • Very customizable
  • Very fast (response times)
  • Can Scale to many viewers due to it being raw html

CONS

  • Hosting is not simple
  • Most likely need to know how to code
  • Spend more time configuring the site and writing (most likely, yes I’m pointing at you engineers).
  • Technical Prowess is needed to fully use the platform

So, Which One Should I Use?

WordPress.

WordPress is the market leader for these types of sites (blogs). It has a rich plugin ecosystem that will be ready for you to grow when you need it and hosting with companies like WpEngine ensure your website is fast and secure.

You’ll find that as you need more from WordPress, it can offer almost anything you need.

Last piece of advice – try to build everything without code first.

WordPress allowed me to do that. It forced me to focus on my content and not on some cool engineering that ultimately would have acted as a distraction.

But … Can I go from X to WordPress if I like X better initially?

Sure, you can, but here again, if you decide to go to WordPress later you’re going to have to spend time migrating from one platform to another. If your goal is to write, why would you want to create more work for yourself?

Just go with WordPress now and save yourself the trouble.

📸Andrew Neel

Filed Under: Business, Development, Marketing

Podcast Equipment and Software

April 28, 2019 by Donn Felker

Audio quality is our #1 concern (other than content) on the Fragmented Podcast (a Podcast for Android Developers).

Our goal is to give you, the listener, the experience of sitting with us (and our guest) as if you were there in person.

Nothing will kill a podcast faster than shitty audio.

I can’t tell you how many times I’ve listened to a podcast that I really loved but eventually had to turn it off due to the terrible audio. If your audio is crap, it doesn’t matter how good your content is because terrible audio will kill your listenership.

Microphones and Audio Interfaces

You’ll want a quality microphone. We use the following from lowest to highest price.

  • ATR2100 USB (the same mic we use at Caster.IO and it’s the same one used on the Tim Ferriss podcast)
  • Shure SM58
  • Shure Beta 87A (our favorite and what we use to record the show)
  • Heil PR40
  • Shure SM7B (the same mic used on the Joe Rogan podcast)

 

Audio Interfaces

For the SM58, Beta 87A, PR40 and the SM7B you’ll want an audio interface to connect the mic and to power it (Beta 87A & SM7B require power).

The ATR2100 USB connects directly to your computer with USB, so you won’t need an interface, though it does have an XLR connector so you can also use to connect it to an Audio Interface. We recommend using one of the following interfaces:

  • Scarlet 2i2 Interface
  • Shure x2u Interface

If you’re going to use the SM7B you’ll need some more juice. We recommend adding the Cloudlifter inline amp to help as the 7B needs some more power to really sound great.

  • Cloudlifter CL-1 Mic Activator

Travel Interfaces

The interfaces above are rather clunky and will pretty much be sitting your home desk or studio once set up. If you need a mobile rig that can do both, you’ll want to use the following:

  • Zoom H6 Recorder

You can throw this thing in a bag with a couple of mics and you’er good to go. If you’re going to record on the road, I recommend using Shure SM58’s as those thing are road dogs – they can take a beating and keep on going.

Road Kit

  • Zoom H6
  • 2 Shure SM58’s
  • 2 XLR Cables

In fact, this exact setup is used by the Super Duty Tough Work Podcast (Blueprint is the producer of our show intro and ad music) and their audio is top notch.

 

What about Blue Yeti and the Blue Snowball Microphones?

Both of these mics also work. In fact, the first 5-10 episodes of Fragmented I used a Blue Snowball. Unfortunately, I had many problems with background noise. You could hear a door shut across the office, talking in the next room, etc. It was not good. The mic was good, but the pickup profile … not so much …

In short, these mic’s noise pick pattern is not great. Meaning that it can pick up a mouse fart at 200 yards. You don’t want that. You want a pickup profile that does not grab a ton of extraneous background noise – hence my other recommendations.

Audio Recording Software

When recording you’ll want something to grab the audio from the mic. We’ve used the following with success:

  • Audio Hijack Pro
  • Adobe Audition
  • Reaper
  • Logic
  • Quicktime
  • Audacity

Once you have your mic, you’ll want to grab some software to record with. Which one works the best? It’s up to you to decide.

Personally, I use Reaper. Kaushik uses Logic. I used Audio Hijack Pro before that. Why did I change? I wanted more audio editing features. If you don’t need audio editing features, then Audio Hijack Pro might be your jam.

Recording Quality Audio

There are a couple of things you need to record a good podcast.

  1. A quiet space with low or no echo.
  2. Quality Microphones

Find a Quiet Space

To record good audio, you’ll want to eliminate background noise as much as possible. Sirens, dogs barking, lawn mowers, etc will all be nearly impossible to get out of the audio in post-production.

Find the quietest room you can. This can be in your house, your office, a phone both at your office, anything

Can’t find one?

Use a Walk-In Closet

If you have one in your house/apartment use the walk-in closet. Closets are the best because they are lined with clothes which act as dampening material for sound to not reflect off of and they usually have a door of some sort that allows you to block additional sound.

The key thing is – eliminate the echo.

Kill the Echo

You’ll have echo if you have the following:

  • Hard surfaced floors
    • Tile
    • Cement
    • Wood
    • Laminate
  • Empty Walls
  • Large Open Space

The best way to see if you have echo is to do a test recording into the microphone. I tend to talk about 10-20 seconds about what the podcast will be about and then stop the recording.

Listen to the audio, if you hear some obscene echo, you’ll need to do something about it.

 

The first thing you can do is try to find a smaller room/mask floors with pillows

If you are. In a very large open room, try to find a smaller room. Once you have done that (if possible) then the next step is to try to remove the echo by adding sound absorbing material like pillows, couch cushions, blankets, etc. The goal is to line as much as the floor as possible with sound absorbing material to prevent echo.

Do a test a recording again and see if it has improved and then adjust the flooring material. Sometimes, if possible, its great to put some blankets on the wall (again, if possible) to absorb the sound that is bouncing off of them.

If you can’t do that or if you don’t have enough material to line the floor … then …

Create a blanket fort

Just like you did when you were a kid. Set up a small chair, set your laptop on it and then put your recording equipment in there. Perform a test recording under the blanket again and adjust from there.

Post Production

You’ll want to go through and clean up anything you want to be removed, cleaned up, etc.

After that, upload the audio and run it through Auphonic with the following settings enabled:

This will level your audio, remove any additional hum and background noise that it can and it will make your audio pop.

That’s it. Upload it to your podcast host and start marketing.

 

If this helped you, please comment below and let me know about your podcast. I’d love to see it/hear it.

 

📷- NeONBRAND

Filed Under: Business, Development, Marketing, Podcast Tagged With: podcast

« Previous Page
Next Page »
Fragmented - A Software Developer Podcast

Projects / Apps

Caster.IO
Fragmented Podcast
American Express Android
Aaptiv
AndroidJobs.IO
Groupon
MyFitnessPal
Poynt

Books

  • Android Developer Tools
  • Android App Dev For Dummies V2 (V1)
  • Android Tablet App Dev for Dummies

Categories

  • Book
  • Business
  • Development
  • Health
  • Marketing
  • Misc
  • Mobile
  • Podcast
  • Screencasts
  • Uncategorized