DEV Community: Zak Miller

The Micropreneur Toolkit

Zak Miller — Thu, 14 Nov 2019 03:59:22 +0000

If you’re building a software product during your nights and weekends, then you don’t have any time or money to waste. That doesn’t stop most people from writing code they don’t have to write, spending time configuring things they don’t have to configure, and paying bills they don’t have to pay.

Here are some tools I’ve found that will save you thousands of dollars and hours as you build a software product in your spare time:

A static site generator (e.g. Hugo, Jekyll, Gatsby)

What it is: A tool that transforms a config file and markdown files (that you write) into a complete website.

What it replaces: Wordpress, Squarespace, or a bespoke website written from scratch.

Why it’s better:

Cheap (plenty of free themes and great ones for less than $100).
Quick to configure (you’re just editing a config file and writing markdown).
Totally customizable (you can always edit the HTML and CSS if you want to).
Hostable for free on Netlify (because there’s no PHP backend like Wordpress).

Netlify

What it is: A hosting platform with excellent tooling.

What it replaces: AWS EC2, Digital Ocean, a server in your garage.

Why it’s better:

No server to manage.
Completely free for teams of one.
Amazing integrations with GitHub (every time you open a PR it creates a unique URL previewing the changes).
Handles migrations and rollbacks for you (just click a button).
Automatically requests and renews SSL certs for you (once you configure it).

Firebase

What it is: A service built on top of Google Cloud that solves common problems for you. It was originally intended to support mobile apps but works just as well for SaaS.

What it replaces: A standard backend web API.

Why it’s better:

Handles common use-cases like account creation, email validation, and password resets (you just make an API call from the front-end and Firebase handles the rest).
Database support (SQL and NoSQL) that you can effectively and securely query from front-end code.
Extremely cheap (especially for MVPs). You’re charged based on usage - not a flat fee per month like if you were running a server.

Looka.com

What it is: A website that lets you design your own logo by browsing through thousands of variations on logos, colors, and fonts.

What it replaces: Making something yourself or hiring a designer for thousands of dollars.

Why it’s better:

Probably higher quality than something you could do yourself.
Fast (you’ll be done in 30 minutes).
Cheap (you can get both SVGs and PNGs for $65).

Unsplash.com

What it is: A place to find high-quality images.

What it replaces: Subscribing to some image repository, limiting yourself to images in the public domain, or desperately searching for “free images” and hoping they don’t have an attribution clause.

Why it’s better:

Hundreds of thousands of images.
Free.
No attribution necessary.

Those are some of the tools I’ve found especially useful in my micropreneurial journey. Hope you found it useful! Anything I’m missing?

5 Mistakes to Avoid When Building Your First Product

Zak Miller — Tue, 12 Nov 2019 08:30:32 +0000

Mistake #1 - Solving a problem that no one has (or that no one is willing to pay for)

Paul Graham wrote about how trying to come up with a startup idea is a pretty bad way to come up with a good idea. You generate a bunch of plausible-sounding ideas (that superficially resemble products you’re familiar with) that are doomed to fail. To paraphrase Mark Twain, the difference between a plausible-sounding idea and a good idea is the difference between the lightning bug and the lightning.

Mistake #2 - Writing off an idea because someone else has already done it

Facebook wasn’t the first social network, Google wasn’t the first search engine, and the iPhone wasn’t the first smartphone. More importantly, many markets are not monopolies and can easily support multiple products. The fact that someone built something similar to what you’re thinking about is a good thing. They proved it’s an economically viable idea, and you can learn from their successes and failures. The alternative (building something no one has made into a successful business before) is much riskier.

Mistake #3 - Not having a marketing plan

If you build it, they won’t come. Go ahead, spend the next six months building something and put it out on the internet. No one will know it’s there unless you do something about it. For a product idea to be a good idea there has to be an economically viable way to gain new customers. Maybe that’s inbound traffic through blog posts (content marketing), maybe that’s Google Ads, or maybe that’s outbound cold calls. Regardless, without a viable channel, you don’t have a product idea - you have a fun project. Check out Traction to learn more.

Mistake #4 - Not setting your sights low enough

With large markets comes lots of money. Thus, lots of competition, a large (required) marketing budget, and a relatively small number of viable business ideas (it’s hard to make something that everyone wants). It’s much easier to build something that’s perfect for a few thousand people. Better yet, once you have a target niche in mind it’s much easier to find ideas that will delight your customers.

Mistake #5 - Not being remarkable

People are busy and won’t care about your little app. Cut through the noise and give them an experience they’ll remark about. Seth Godin has written about this.

Conclusion

A good way to find out if your product has legs is to build an MVP as quickly as possible and try to sell it (this is the premise of The Lean Startup, which you should read). The longer you put that off, the more likely you are to be wasting your time. Even better, know that people will pay for it before you start to build it (get them to fund the development!).

How to Serve Vue with Nest

Zak Miller — Tue, 12 Nov 2019 02:58:30 +0000

Want to serve a VueJS app from a NestJS backend? Here's how you do it.

Create a new Nest app

Install the Nest CLI

npm install -g @nestjs/cli

Create the NestJS app

nest new nest-with-vue

Install the dependencies

cd nest-with-vue
npm install

Verify it's all working properly

First, run it (this will watch the folder so we won't have to restart the server as we make changes):

npm run start:dev

Then, hit it (in a separate terminal window):

curl localhost:3000

You should get Hello World!.

Set it up to serve static content

Install the package:

npm install --save @nestjs/serve-static

Use the package

src/app.module.ts:

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ServeStaticModule} from '@nestjs/serve-static'; // New
import { join } from 'path'; // New

@Module({
  imports: [
    ServeStaticModule.forRoot({ // New
      rootPath: join(__dirname, '..', 'client/dist'), // New
    }), // New
  ],
 controllers: [AppController],
 providers: [AppService],
})
export class AppModule {}

src/main.ts:

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.setGlobalPrefix('api'); // New
  await app.listen(3000);
}
bootstrap();

We're moving all the existing endpoints to under /api, and then serving the static content in the ./client/dist folder (which doesn't exist yet) when someone hits the root (in this case localhost:3000).

Also note that the name client here could be anything. It's just the folder where we're going to put the Vue app.

Verify that the controller endpoint moved

Now, if we hit the previous endpoint:

curl localhost:3000

You should get {"statusCode":500,"message":"Internal server error"}.

But if you hit the new /api endpoint:

curl localhost:3000/api

You get Hello World! again.

Now we just have to create the Vue app in that ./client/dist folder.

Create the VueJS app

Install the Vue CLI:


npm install -g @vue/cli
# OR
yarn global add @vue/cli

Create the app:

vue create client

Build the app:

cd client
npm run build

This will put all the static files in ./client/dist, right where the Nest app will be looking for them.

Verify that Nest is serving the compiled Vue app

curl localhost:3000

You should get something that looks like:

<!DOCTYPE html><html lang=en> ... <strong>We're sorry but client doesn't work properly without JavaScript enabled. Please enable it to continue.</strong> ... </html>

Which is the HTML being served by the Vue app.

Open it up in your browser and you'll see it's working!

Closing words

That's it. You can find the complete code here.

How to Access Firestore using Ionic

Zak Miller — Sun, 10 Nov 2019 16:27:09 +0000

When I created an app using Firebase and Ionic, I started my authentication
journey by trying a few different packages: firebase.js, firebaseui, angularfire2, ionic-firebase-authentication, and ngx-auth-firebaseui.

I found one that worked with Ionic, and used that for a while, only to
discover when I moved to testing on my mobile device that the auth didn't
work on the mobile device because it was using an in-app browser, and
Google had cracked down on using those inside of apps to authenticate.

I then found the official Firebase Authentication plugin for Ionic
and was pretty excited. After a bit, I realized that although it allows you to sign in, you can't actually access the Firestore database.

If you use another package, like the firebase.js package, to retrieve and
store data and you've locked down the Firestore database as you should
you'll quickly find that as far as the firebase.js package is concerned,
you aren't actually authenticated.

I'm not thrilled with my current implementation, but to allow facebook
logins it looks like this:

  async loginWithFacebook() {
    const permissions = ['public_profile', 'email'];
    this.fb.login(permissions)
        .then(response => {
            const accessToken = response.authResponse.accessToken;
            const credential = firebase.auth.FacebookAuthProvider.credential(accessToken);
            firebase.auth().signInAndRetrieveDataWithCredential(credential).then(() => this.allowUserIn());
        });
  }

I'm using the native Facebook Auth package to prompt the user for permission to Facebook (this seems to be what can't be done via a browser on Android), and then using firebase.js to take care of the rest.

Hugo - How to Filter Posts With a Tag

Zak Miller — Sun, 10 Nov 2019 16:22:36 +0000

While recently working on a website, I wanted to display a subset of my posts based on a particular tag. I hadn't had any prior experience with the go templating engine, so this took me a bit longer to figure out than I'd care to admit, so I thought I'd share it with all of you.

This example applies anytime you want to filter any list of pages with a taxonomy.

    <ul>
      {{ range where .Paginator.Pages ".Params.tags" "intersect" (slice "popular")}}
      <li>
        <span>{{ .Date.Format (.Site.Params.dateFormat | default "January 2, 2006" ) }}</span>
        <a href="{{ .URL }}">{{ .Title }}</a>
      </li>
      {{ end }}
    </ul>

The first line is really all that matters. We're range-ing over the pages, grabbing the tags from each of those pages and seeing if they intersect with a new slice that only contains popular.

A contains operator is what I would expect to use here, but as far as I can tell there isn't one, so you have to use this intersect workaround.

I hope that was helpful! If you have any questions please let me know.

Google Cloud Functions and the File System

Zak Miller — Sun, 10 Nov 2019 16:20:48 +0000

If you want to write a cloud function, and you need to write temporary data to the file system, how do you do it?

Using /tmp. Under the hood, it's actually just storing it in memory but if you must simulate reading and writing to the file system it'll work.

I was cloning a repo programmatically and parsing JSON files from that repo, so it made sense for my situation.

To write:

func write() error {
    text := "Hello World"
    filepath := "/tmp/file"
    fmt.Printf("writing file %v\n", filepath)
    b := []byte(text)
    err := ioutil.WriteFile(filepath, b, 0644)
    switch  {
    case err != nil:
        fmt.Printf("error encountered writing file %v, %v\n", filepath, err)
        return err
    default:
        fmt.Printf("file wrote successfully\n")
        return nil
    }
}

To read:

func read() (string, error) {
    filepath := "tmp/file"
    fmt.Printf("reading file %v\n", filepath)
    content, err := ioutil.ReadFile(filepath)

    switch {
    case err != nil:
        fmt.Printf("error encountered reading file %v, %v\n", filepath, err)
        return "", err
    default:
        fmt.Printf("file %v read, content: %v\n", filepath, string(content))
        return string(content), nil
    }
}

You can find a complete sample here.

If you care about preserving the files you're writing, then don't use this solution. Instead, use something like this.

The Technology Behind Carnivore Coach

Zak Miller — Sun, 10 Nov 2019 16:18:24 +0000

Carnivore Coach is an Android app that I designed to help people track their progress on the carnivore (zero-carb) diet. I wrote about the business decisions behind Carnivore Coach, but today I'm going to talk about the tech stack and the reasoning behind it.

Mobile Framework and Language

When it comes to mobile development you have a few options:

Native (Java/Kotlin or Objective-C/Swift)
Web Technologies + Cordova
Xamarin (C#)
Flutter (Dart)

There are some genuine tradeoffs here:

Native is fast but specific to either Android or iOS
Flutter is not quite as fast and is sort of arcane technology, but it lets you deploy on both platforms.
Xamarin lets you write in C# (a language I'm very familiar with) and deploy on both platforms, but the functionality is limited and slower than Flutter.
Web technologies are slowest of all, but the Ionic/Cordova ecosystem has a lot of great components, and it also lets you deploy to iOS or Android.

I chose web technologies for a simple reason: I wanted to get better at Angular and Typescript. I didn't know whether Carnivore Coach would make me any money, but I could guarantee that I would learn some technologies useful to me.

I used v4 of the Ionic Framework which I would highly recommend if you want to write an Angular app for mobile. I have heard good things about React Native but I wanted to learn more about Angular so it was off the table immediately.

Ionic really shines in a couple of areas:

It provides web components that mimic the look and feel of native controls, so you don't have to worry about styling HTML elements in a native-esque way.
It has libraries that abstract away native functionality (e.g. storing data locally, interacting with Facebook auth, etc) and will work with the same code on both Android and iOS, so you can just write the code once.

Ionic also integrates with Cordova to the degree that you don't ever really have to worry about it.

Backend

When it came to the backend, I chose Firebase.

I just needed:

Account management and auth
A place to store some data (e.g. resources to learn more about the diet, food statistics).
The users' data so that they could go back and review it (e.g. what they ate, their weight, etc).

This was mostly painless to set up using Firebase, and I plan on using Firebase in the future wherever I can. You can read about how I ran into a little bit of pain with Ionic Firebase Auth, but the fact that I didn't have to write any backend code at all really sold me. It's funny, because I've always been a backend developer, but I guess I'm more excited about quickly building things than backend design because I was happy to outsource all that work to Firebase.

The Website

I knew that I wanted to have a website to help market Carnivore Coach. As usual, my goal was to have something that looked professional and had the functionality I wanted, without spending any more time or money than necessary.

Hosting

I heard about Netlify on Traversy Media's Youtube Channel and it seemed like a great option. Basically, Netlify hosts websites created with a static site generator. It's free for a single user and makes it very easy to set up HTTPS and auto-deploys when you push to GitHub.

Technology

I hadn't had any prior exposure to static site generators, but it looked like the two options were Jekyll and Hugo. I assumed both would be fine, but went with Hugo because it was newer and I was more interested in Golang than Node.js.

It took me a couple of weeks to become really comfortable with Hugo, but I probably could have reduced that time if I had spent less time trying to figure things out and more time reading the docs. I wrote about how to filter posts with a tag using Hugo, one of the more interesting problems I ran into.

At the End of the Day

I'm happy with the technologies I chose. I was able to get all of this done in my free time over about a month. That's not bad for not being very familiar with Angular, and having basically zero experience with mobile development, and no experience with Hugo.

If I was going to develop another mobile app, then I'd be tempted to go fully native. When the app starts up it has this annoying blue Ionic graphic, and it does seem a little slower than I'd like. That's really my only complaint.

What Makes Ghost.org So Successful?

Zak Miller — Thu, 17 May 2018 00:00:00 +0000

Ghost.org, the markdown blogging non-profit, released a blog post covering its five-year journey to $82,000 in monthly recurring revenue and a customer list that includes Apple, Mozilla, and Cloudflare.

The post itself is great, especially if you’re interested in open-source software, but the most insightful bit wasn’t in the post itself. John O’Nolan (of Ghost) did a sort of AMA on Indie Hackers, after writing the article.

The Ghost Foundation is a non-profit that works on the open-source technology Ghost. They make their money through a paid solution called Ghost(Pro), where they host and manage blogs written in Ghost.

A commenter noted that he saw complaints all over the internet about Ghost(Pro)’s high price, and asked why the price was higher than people would expect (~20 dollars rather than ~10).

John responded with a detailed answer that I recommend you read in full. The gist is that they price their product very deliberately. Their goal is to have ~4000 customers, and they just charge the amount of money necessary to keep the number of customers constant. If demand increased sharply, they would increase their prices until they got about 4000 customers again. If demand fell, and the number of customers fell below 4000, they would decrease their prices.

That blew me away. Yes, of course, if you increase your prices you will get fewer customers, and if you decrease your prices you will get more customers (depending on elastic vs inelastic demand, and all that).

I never considered that a business model would center around keeping the number of customers constant. You suddenly look at customer acquisition and pricing differently.

His method wouldn’t make much sense for an app that scales well, but when your business model is hosting websites it makes sense to be extremely conscious of how many websites you’re hosting.

I’m tempted to say that it’s unusual that a non-profit would come up with such an interesting approach to pricing, but maybe it’s not strange. Maybe when you’re a little distanced from the profits you’re also more likely to innovate. Regardless, John’s thoughtfulness will serve the Ghost Foundation well in the future, and I look forward to his next blog post.

Originally published at https://www.zakmiller.com on May 17, 2018.