Forem: Greg Nokes

Bringing Buddha into leadership

Greg Nokes — Thu, 08 Jun 2023 21:34:05 +0000

Leadership in tech isn't just about being the best coder in the room; it's also about creating an environment that encourages growth, promotes understanding, and fosters collaboration. How we lead impacts our team's performance, job satisfaction, and even our company's bottom line. That's why I believe it's important to continuously broaden our perspectives on leadership.

In light of this, I wanted to share an article I recently published that explores a thought-provoking approach to leadership: Bringing Buddha into Leadership.

In this piece, I delve into the principles of Buddhism and how they can be applied to leadership, especially in tech. The article discusses mindfulness, empathy, and compassion —qualities inherent in Buddhism and vital for effective leadership.

The goal isn't to turn everyone into a Buddhist, but rather to open up new avenues for thought and discussion about how we can enhance our leadership skills. And while we typically don't associate ancient Eastern philosophies with modern tech workplaces, you may be surprised to see just how relevant and beneficial these principles can be.

I hope this exploration can serve as a starting point for a broader conversation on what effective, compassionate leadership looks like in our industry. I'd love to hear your thoughts, experiences, and ideas on this topic.

Let's build more than just software; let's build better environments, better teams, and better leaders!

Reflections on a Decade at Heroku

Greg Nokes — Tue, 14 Jun 2022 00:00:00 +0000

At about 7:45am March 26th 2011, I walked up to the doors at Heroku for the first time. I was early because that’s what you did where I came from.

The doors were locked. No one responded to the buzzer.

So I went and got some really bad coffee at the DNA Lounge next door, and waited. As I recall, I saw someone walk in at about 9, and followed them in. That’s how the next chapter in my life started.

Building a Time Machine for Salesforce Data, the Easy Way

Greg Nokes — Fri, 16 Oct 2020 00:00:00 +0000

So, you want to have every change made to the data in a Salesforce Object stored.. forever?

Let’s explore how we used out of the box tools and a little coding to build a time machine, and what it looked like after I ran it on test data for several months.

First about our test data environment: We are using a test org with randomly generated accounts, and opportunities associated with those accounts. We also have a service that runs every few minutes to make changes to a small, random subset of the accounts.

The first step was to set up an collector app. This app will emit all of the changes as messages into Kafka.

Set up a Heroku App in a Private Space
Add a Heroku Private Postgres Database
Add Heroku Connect
Choose and Configure the objects to sync in Heroku Connect

We then needed to stream changes somewhere:

Add a Heroku Private Kakfa cluster to the app
Configure the Streaming Data Connector to point at the Heroku Connect tables

We were then mirroring our Salesforce Data into Heroku Postgres, preforming CDC on the data, and streaming the changes into Kafka.

We decided to use Node to listen to the event stream in Kakfa, and take the updates and insert them into a table on Postgres.

Created another Heroku App in the Private Space
Share the Kafka add on with the new app
Add a Heroku Private Postgres database
Create a table in the Postgres database - insuring that the validations would allow for duplicate values in things like External_id__c and sfid fields.
Write code that listens to Kafka for events, and inserts the events as new records into the TARDIS ..um.. Postgres.

This is not only scalable to many objects in a single Salesforce org, it’s also scaleable to many Salesforce orgs - including Work.com, Service Cloud and SalesCloud. Not only can you easily provide visibility across orgs, but you are capturing all changes and you can report on how records have evolved over time, as well as how records relate to each other in diffrent orgs.

What are the results now that we have all of this data flowing?

Looking at the collector app. We have just over 50k accounts total, and we are using only 350 MB of data. Picking an account at random, we can see that we have the most up to date info for that account in Postgres.

~ ☯ heroku pg:psql --app ggn-pg2k-test 

--> Connecting to postgresql-rigid-10449
psql (12.4)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

ggn-pg2k-test::DATABASE=> SELECT pg_size_pretty(pg_total_relation_size('"salesforce"."account"'));
 pg_size_pretty 
----------------
 349 MB
(1 row)

ggn-pg2k-test::DATABASE=> select count(*) from salesforce.account;
 count  
--------
 501646
(1 row)

ggn-pg2k-test::DATABASE=> select name, sfid, score__c from salesforce.account 
where External_id __c = '7f4acaad-6c77-4342-a533-83bb580aaf681586878813' ORDER BY score__ c;

           name | sfid | score__c 
--------------------------+--------------------+----------
 Borer, Braun and Gutmann | 001f400001MDeYzAAL | 2
(1 row)

Switching over to the time machine app, we have a total of 88,577,70 records on the same data source - so on average over 160 changes per record stored. Looking in detail at a single account, we can see a total of 21 changes on it.

The total data storage for all of the records and changes took just over 4GB of space.

~ ☯ heroku pg:psql --app pg2k-gregs-drain

--> Connecting to postgresql-rugged-63570
psql (12.4, server 12.3 (Ubuntu 12.3-1.pgdg16.04+1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

pg2k-gregs-drain::DATABASE=> SELECT pg_size_pretty(pg_total_relation_size('"account"'));
 pg_size_pretty 
----------------
 4274 MB
(1 row)

pg2k-gregs-drain::DATABASE=> select count(*) from account;
  count  
---------
 8857770
(1 row)

pg2k-gregs-drain::DATABASE=> select name, sfid, score__c, id from account 
where External_id__c = '7f4acaad-6c77-4342-a533-83bb580aaf681586878813' ORDER BY id;

           name | phone | score__c | sfid | id    
--------------------------+---------------------+----------+--------------------+---------
 Borer, Braun and Gutmann | 5555551212 | 1 | 001f400001MDeYzAAL | 33351
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 34165
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 34699
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 35523
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 376946
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 971802
 Borer, Braun and Gutmann | 967-160-7974 x6487 | 15 | 001f400001MDeYzAAL | 1041819
 Borer, Braun and Gutmann | 5555551212 | 15 | 001f400001MDeYzAAL | 3006621
 Borer, Braun and Gutmann | 1-151-183-4668 x379 | 5 | 001f400001MDeYzAAL | 3006628
 Borer, Braun and Gutmann | 1-151-183-4668 x379 | 5 | 001f400001MDeYzAAL | 3006634
 Borer, Braun and Gutmann | 1-151-183-4668 x379 | 5 | 001f400001MDeYzAAL | 3006648
 Borer, Braun and Gutmann | 5555551212 | 5 | 001f400001MDeYzAAL | 5140095
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 5140108
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 5140114
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 5140120
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 5390250
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 5620956
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 7002900
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 7031300
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 7788503
 Borer, Braun and Gutmann | 504.976.9652 x047 | 2 | 001f400001MDeYzAAL | 7906202
(21 rows)

This pattern can be used for Salesforce objects via Heroku Connect, or any table that you have on Heroku Postgres. As you can see, it is super easy to set up - the only coding you have to do, is to create the listener who will grab all of the updates, and store them into your target database.

This is really the power of the Heroku Platform - using it’s tools to reduce the amount of work needed to be done to accomplish powerful things, in data as well as in traditional apps.

Condos and Lumberjacks, or Why PaaS?

Greg Nokes — Wed, 16 Sep 2020 00:00:00 +0000

I have been involved in and with various infrastructure as a service and platform as a service providers for well over 12 years now. Often I am asked to explain “why use a IaaS provider?” or “why use a PaaS?” or “Why use Heroku?”.

I wrote this out to try and explain these concepts in concrete terms.

Lucky for me, a few co-workers decided to help me with art and video production help, and we were able to remove the “with bad drawings” subtitle. Also we made a cool animation explaining this. You can see the video here.

Thanks to the awesome Nicole Johnson, Jennifer Hooper and the entire Heroku marketing team for taking my idea and making it shine.

Icebergs and Lumberjacks

With bad drawings

AWS loves to say “AWS is for builders” and I cannot agree more. AWS is for builders, but Heroku is for developers.

Why?

And what does that even mean?

And what is the difference?

Professional Development is hard. It is a skill that can take years to hone. The tools that developers use can be foreign to other folks. Things like “the CLI” or “IDE’s” or “git”. Like any other specialization developers speak their own language, and over the decades have developed tools that are aimed at their use case.

Also the craft of development is hard. If you think about it, we are writing step by step instructions for computers to execute. We are pretty darn close to running at the bottom of the stack, right?

Wrong.

They say that 90% of the iceberg is underwater, and not visible. The same can be said about development. Writing code in Java, Ruby, Python or what have you is the easy part. It’s the details that you do not see that cause you the most trouble.

The 90% of the tasks that are invisible are what gets you. What sort of things are these?

This is where the builders come in. They have to build the parts of the app that no one ever sees. They build the plumbing that the app runs on. Before you write a line of code, you have to acquire or build and configure a lot of things.

Say, you want to have an application that simply serves HTML traffic and has part of it’s data connected to Salesforce. What would you need to build to accomplish this?

Well, at it’s most basic this is what you would have to build, before your developers even starting writing code!

This does not include things like autoscaling, auto-healing, multi-AZ failover, build environments, developer tooling, CI/CD pipelines and a host of other things that you will need.

Oh you want to use Kuberntes (K8s)? That’s just as hard.

Functions as a Service is getting closer to “Heroku easy” for certain use cases and certain architectures. For example, if your code can handle intermittent “cold start” delays, then FaaS might be for you. However it is not a silver bullet, and it does not solve every problem.

If we think of it like needing a house, AWS is going to the lumber yard, and buying wood so that you can build a house. Even with K8s, EKS, Lambda, Docker, you still have to assemble, configure and maintain all of those things, and the interconnections between them.

And, K8s, FaaS, Docker? They were born out of looking at how Heroku was and is doing things.

12factor? Heroku wrote it.
Buildpacks? Heroku invented them.
git push heroku master? You guessed it. Invented at Heroku.

When I started in the industry, we did not even have lumber yards. We had to cut down trees and get our lumber that way! We had to call Dell or HP or Gateway and have them send us servers. We then had to assemble those servers, and put them into racks. Next we had to install the operating system and any software packages that we needed.

That’s on premises for you. The most control, and the most manual labor and time.

AWS has elevated the game. AWS gives us a lumber store. And it is really awesome. You can go in, and find a vast array of different types and sizes of lumber, lots of connectors, electrical stuff and plumbing. You can pick and choose from a huge menu of services on AWS. However you have to choose the correct menu items, and then you have to configure them correctly, integrate them, and manage those services and integration.

Oh and by the way, after you are done with all of that lumber and your house is built, who’s going to fix your house when something goes wrong with it?

You.

You will.

When we say Heroku is easier to use then AWS this is exactly what we mean. Instead of buying lumber, you are buying a Condo with landscaping and maintenance included.

You buy the Condo and your interior decorators (developers) can get started on choosing the color of the tile, ordering couches and hanging the art.

Heroku allows developers to skip the building, and get straight to development. It also manages those built parts for our customers. These two things allow Heroku customers to be able to focus on the development of the apps they want to build, and not focus time on building infrastructure to host their developers and code.

What are your thoughts? Do you prefer to rack and stack, use IaaS or develop on a PaaS?

The Simplest Heroku Demo Ever

Greg Nokes — Wed, 26 Aug 2020 00:00:00 +0000

One of the things that I have done literally thousands of times over the last 9 years is show folks the power of Heroku. Over the years I have come up with, dare I say it, the simplest Heroku demo script ever:

mkdir directory
cd directory
git init . && git checkout -b main
touch index.php
echo "<h1>this is a heroku app</h1>" >> index.php
git add . && git commit -m "first commit, yay"
heroku create
git push heroku main
heroku open

There you go - a few lines to create a new app, build environment, load balancers and everything else you need to run a highly scaleable, secured, web application. All thanks to the power of Heroku.

How I post an article

Greg Nokes — Fri, 21 Aug 2020 00:00:00 +0000

I think that the workflow I have developed for this blog is pretty interesting, so I decided to write up how I currently approach it.

The first step is to write an outline. I currently use Textmate 2, but I am thinking about trying out Visual Studio, as a few friends have been gushing about it. On my iPad I will use Working Copy.

The second step is to create a local branch for the article:

The third step is to push the branch to Github and create a pull request:

Since I have a pipeline set up on Heroku with review apps enabled, once the PR is opened on Github you will notice that Heroku automatically creates an app tied to that PR.

I can hand out review app to folks that I want to get feedback from. Also, as I revise the app and push those changes to my PR, those changes automatically appear in the review app.

Once I am done with the article, I can push it into staging. I do this by simply merging the PR into my master branch. Once the PR is merged or deleted, the review app is disposed of.

If the PR is merged into the master branch, my staging app detects the new code, and automatically deploys it. If I had unit tests written, I could hook up Heroku CI to automagically run my tests previous to the deploy.

Once I am happy with the article, I can promote it into production.

What is super nice about this workflow is when I want to do larger changes (for example, swapping out the theme) I can do that with out a fear of breaking the running app. When I used to host on Wordpress, I would often be making larger changes live on my site, with exciting results.

You can read about how to create a pipeline on Heroku’s Devcenter.

How to Heroku

Greg Nokes — Wed, 08 Apr 2020 00:00:00 +0000

How do people who use the Heroku Platform actually use it? What is a day in the life of a Heroku user? What does it mean “to Heroku”? Read on to find out the answers to these and other questions….

Universal Containers, Day 1

It was Jane’s first day at Universal Containers (UC). Jane’s expertise was in Ruby on Rails, as she had just graduated from a bootcamp which taught “full stack development” using Rails.

Jane was given the following user stories that she had to solve for on her first project:

As a consumer of UC information I want to be able to find news and up to date information about the company.
As a consumer of UC information I want to be able to search older information in a logical fashion
As a consumer of UC information, I want to be able to view older blog posts in a time series fashion
I want to be able to deliver this to a potentially very large group of people in an unauthenticated manner, with precise control over the UX

Being a Rails developer, Jane started to formulate a plan based on Rails to serve content to a wide variety of users. She envisioned a rails app, backed by a PostgresSQL database. This would give her an abstraction from having to deal with coding things like an application web server, application request router, and layout engine. All of that and more comes out of the box with Rails!

Jane fired up her tool of choice, Terminal.app, and got started:

Next, Jane went to www.heroku.com and signed up for an account, and downloaded the Heroku CLI to her new machine.

She then decided to set up a CI/CD Pipeline to help her with her development work, so she consulted the devcenter and searched for CI/CD. She found the article on Heroku CI. That was half of the CI/CD problem. In the article about CI/CD, she found a link to Heroku Pipelines and that completed the equation for her.

Using this she would be able to use automated unit tests on her code, and deploy working branches to automatically provisioned and managed development environments! She got to work.

Her first task was to set up her first app. She decided to start with the staging environment, as the production app would be added after User Acceptance Testing (UAT)

She returned to her trusty command line.

She first needed to commit the initial framework of the Rails app to git. Jane knew that using git and Github was a best practice, and it would allow her to leverage advanced Github and Heroku integrations later.

She used the following commands to insure that git was set up correctly, add all of the files, and then commit them locally.

~/Code/uc_blog ☯ git status

~/Code/uc_blog ☯ git add .

~/Code/uc_blog ☯ git commit -m "First Commit"

She then created a private repository on Github to hold her code:

She added the git remote and pushed her code to Github:

~/Code/uc_blog ☯ git remote add origin git@github.com:tsykoduk/refactored-robot.git

~/Code/uc_blog ☯ git pull --allow-unrelated-histories origin master

~/Code/uc_blog ☯ git push origin master

Jane was then ready to deploy the skeleton of her application into Heroku. She knew that she would need a build environment to transform her code into an executable format, that she would need containers to run her code, she would need a container orchestrations system to manage the containers and insure they were self healing, and finally she would need load balancers to get web traffic to her app.

~/Code/uc_blog ☯ heroku login
heroku: Press any key to open up the browser to login or q to exit: 
Opening browser to https://cli-auth.heroku.com/auth/cli/browser/fed60
Logged in as jane

~/Code/uc_blog ☯ heroku create
Creating app... done, ⬢ murmuring-reef-21813
https://murmuring-reef-21813.herokuapp.com/ | https://git.heroku.com/murmuring-reef-21813.git

And that was all there was to that! She had just done all of the work needed to setup the environment to build, run and manage her application.

Time to grab a cup of coffee!

When Jane got back from meeting some of her new coworkers and getting some coffee, she put her headphones back on. She had a bit to do before lunch!

She decided that she would first deploy the skeleton of the app, and then set up Pipelines and Review Apps, and then hook it all together with Github.

Jane first headed over to the Elements Marketplace, as she knew that her application would need some backing services. She knew that she would need PostgresSQL, and a logging tool. She also chose to install a Redis instance, as she could. use that as a cache with Rails to speed up application performance. With that knowledge in hand, she switched back to her Terminal used the Heroku CLI to provision Postgres:

~/Code/uc_blog ☯ heroku addons:create heroku-postgresql:standard-0
Creating heroku-postgresql:standard-0 on ⬢ murmuring-reef-21813... $50/month
The database should be available in 3-5 minutes.
! CAUTION: The database will be empty. If upgrading, you can transfer
! data from another database with pg:copy.
Use `heroku pg:wait` to track status.
postgresql-defined-69446 is being created in the background. The app will restart when complete...
Use heroku addons:info postgresql-defined-69446 to check creation progress
Use heroku addons:docs heroku-postgresql to view documentation

And next up was Redis:

~/Code/uc_blog ☯ heroku addons:create heroku-redis:premium-0 
Creating heroku-redis:premium-0 on ⬢ murmuring-reef-21813... $15/month
Your add-on should be available in a few minutes.
redis-cubic-39558 is being created in the background. The app will restart when complete...
Use heroku addons:info redis-cubic-39558 to check creation progress
Use heroku addons:docs heroku-redis to view documentation

And finally Papertrail:

~/Code/uc_blog ☯ heroku addons:create papertrail:choklad
Creating papertrail:choklad on ⬢ murmuring-reef-21813... free
Welcome to Papertrail. Questions and ideas are welcome (support@papertrailapp.com). Happy logging!
Created papertrail-acute-05007 as PAPERTRAIL_API_TOKEN
Use heroku addons:docs papertrail to view documentation

That would give her new Rails app what it needed to be successful from the start!

Now it was time to package up her code, send it to the build environment, and then move the assembled slug into a container.

~/Code/uc_blog ☯ git push heroku master
Enumerating objects: 113, done.
Counting objects: 100% (113/113), done.
Delta compression using up to 8 threads
Compressing objects: 100% (94/94), done.
Writing objects: 100% (113/113), 148.28 KiB | 5.49 MiB/s, done.
Total 113 (delta 9), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
[...]
remote: -----> Launching...
remote: Released v8
remote: https://murmuring-reef-21813.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.
To https://git.heroku.com/murmuring-reef-21813.git
 * [new branch] master -> master

Her new app was up and running. She opened a web browser and browsed to the new app’s address:

Her final task was to set up the pipeline and development environments. She knew that she would have to create a pipeline, integrate it with GitHub, and enable CI and Review Apps.

She opened the dashboard, and selected the new app. She then selected Create a Pipeline. She then answered a few questions, and the pipeline was created for her.

Next she clicked on the Enable Review Apps button, and selected a few options

Next, she clicked on Enable CI

All done. In the course of a single morning, and on her first day at work, Jane had set up a Heroku App and all of the load balancers, build environments, containers that come with that allow someone to run an application on the internet. She had also configured and set up a full CI/CD pipeline including GitHub integration.

Now she could roll up her sleeves, and get started building the app.

But first, Lunch!

Setting up DHCPD on MacOS

Greg Nokes — Sat, 28 Mar 2020 00:00:00 +0000

One of the frustrations with my current network setup is that the router is very inflexible. For example, it would not allow me to set the Domain Name servers that I wanted to use for my internal devices. It would only deliver the DNS servers that my internet provider delivered to it. And who wants that?

Well, since I have set up many DHCP servers in the past, I did not think this would be a problem. I have an older Mac that I could use, as it stays plugged into the network and is already operating as a Apple iCloud Cache server.

I also wanted to be able to deliver IPv6 DNS servers to my machines as well.

Well, it was not quite as easy as I thought it was going to be. I had to learn how to use launchctl and launchd. I come from a background of using init and systemd so I assumed this would be fairly easy.

Here are the steps that I found to work on a machine running 10.15. I set up IPv4 first.

Step 1

Install the DHCP server via brew.

~ ☯ brew install isc-dhcp

Step 2

Set up the IPv4 plist and config files.

The config file was pretty simple:

/usr/local/etc ☯ cat dhcpd.conf 
# dhcpd.conf
#

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;

# My First Subnet
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.200;
  option domain-name-servers 1.1.1.1, 1.0.0.1;
  option routers 192.168.1.1;
  option broadcast-address 192.168.1.255;

  # Let's let folks keep their IP's for a while
  default-lease-time 6000;
  max-lease-time 72000;
}

Next up was getting it installed as a service. The brew stuff was unhelpful, and, honestly I wanted to play with the underlying plist files anyways.

After some gnashing of teeth and frantic googling, I came across a helpful article by Steven Diver that outlined the syntax of the org-isc-dhcpd.plist file.

Anyway, this is what I came up with:

/Library/LaunchDaemons ☯ cat org.isc.dhcpd-6.plist 
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<dict>
     <key>Label</key>
          <string>org.isc.dhcpd</string>
     <key>OnDemand</key>
          <false/>
     <key>ProgramArguments</key>
          <array>
          <string>/usr/local/sbin/dhcpd</string>
          <string>-q</string>
          <string>-f</string>
          </array>
     <key>RunAtLoad</key>
          <true/>
     <key>ServiceDescription</key>
          <string>ISC DHCP Server</string>
</dict>
</plist>

Next I figured out that I had to load the plist, and then it would hopefully start up.

~ ☯ sudo launchctl load /Library/LaunchDaemons/org.isc.dhcpd.plist

I could then use sudo launchctl list |grep dhcp to see that the service was in fact started.

~ ☯ sudo launchctl list |grep dhcp
47891   -15 org.isc.dhcpd

I also rebooted the machine to insure that it would survive a reboot - no one wants their DHCP server vanishing, right?

Step 3

Next up was setting up IPv6.

I did a bit of reading, and figured out that you would have to have 2 DHCPD services running, one for IPv4 and one for IPv6. I also learned a bit about IPv6 and SLAAC. It seemed that I could keep using my ISP’s SLAAC to hand out proper addresses, and use DHCP to deliver additional information to the hosts, like a proper DNS server’s address.

This is the config file that I came up with:

/usr/local/etc ☯ cat dhcpd6.conf 
# dhcpd6.conf

default-lease-time 600;
max-lease-time 7200;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
# log-facility local7;

# Subnet declaration

subnet6 2601:601:cc00:370::/64 {
        # keep it simple, just hand out DNS
        option dhcp6.name-servers 2606:4700:4700::1111, 2606:4700:4700::1001;
}

And the plist:

/Library/LaunchDaemons ☯ cat org.isc.dhcpd-6.plist 
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<dict>
     <key>Label</key>
          <string>org.isc.dhcpd-6</string>
     <key>OnDemand</key>
          <false/>
     <key>ProgramArguments</key>
          <array>
          <string>/usr/local/sbin/dhcpd</string>
          <string>-f</string>
      <string>-6</string>
          <string>-f</string>
      <string>-cf</string><string>/usr/local/etc/dhcpd6.conf</string>
      <string>-lf</string><string>/usr/local/var/dhcpd/dhcpd6.leases</string>
          </array>
     <key>RunAtLoad</key>
          <true/>
     <key>ServiceDescription</key>
          <string>ISC DHCP-6 Server</string>
</dict>
</plist>

The only thing left was to load the plist and see if this all worked. Again, with the reboot test.

~ ☯ sudo launchctl list |grep dhcp
47891   -15 org.isc.dhcpd
48425   0   org.isc.dhcpd-6

I also restarted the network interface on another device, and watched the logs on the server to see if this all worked together:

dhcpd: Information-request message from a0a0::a0a0:a0a0:a0a0:a0a0 port 546, transaction ID 0x158E3D00
dhcpd: Sending Reply to a0a0::a0a0:a0a0:a0a0:a0a0 port 546
dhcpd: DHCPREQUEST for 192.168.1.49 from a0:a0:a0:a0:a0:a0 via en6
dhcpd: DHCPACK on 192.168.1.49 to a0:a0:a0:a0:a0:a0 via en6

Presto, devices started to use the correct DNS servers.

Reflections on 12 years of 100% remote work

Greg Nokes — Tue, 03 Mar 2020 00:00:00 +0000

I started working 100% remote in early 2008. Over the years I have learned quite a few lessons, and have really come to appreciate the lifestyle.

I have worked as member of a majority remote company, as one of 7 people that made up the 10% of the company that was remote, and as a member of a fully remote team.

Honestly, early on it was pretty tough. There were tons of interruptions, a lot of stress and almost no work/life balance. Over the years I have come to realize that working from home can bring isolation, withdrawal and a feeling of disconnection.

I have a few go-to tactics that I make sure that I employ to combat these issues. As I discovered them over the years, my appreciation for remote work has increased to the point where I am not sure that I would take an office job in the future.

Dedicated Space

This is one of the first things that I discovered. I needed to set up a dedicated work space, with a door that closes, comfortable furniture, a sound system, good keyboards, microphones, cameras, and all of the other essentials.

I started years ago with a nice computer desk and a comfy chair in a spare bedroom.

Over the years, I have moved from a chair, to a yoga ball, to a standing desk. I have switched to full time at a standing desk. That has made a big difference as well. When I need a short break, I can simply walk out of the office, and do a lap around the kitchen.

I have some co-workers that go so far as install sound proofing in their offices, or build unattached offices in their back yards.

Dedicated Work Environment

I personally have found that having a distraction free work environment is important. So I have two computers on my desk. One that is dedicated to work - email, coding, chats, and calls. And a machine that is dedicated to my personal stuff - personal email, social media, and music.

I started with a work laptop and a 1st Gen Mac Mini as my personal computer. That was plugged into the speakers, and ran music, personal email etc. I had a KVM switch, and used that to swap my monitor, keyboard and mouse between the Mac Mini and my work laptop.

Now I have a laptop riser, a big monitor, a Yeti Blue mic on a boom, and my personal iPad for music and distractions.

A few years ago, I was forced to get a second cell phone for work, and that has been great. Now when I quit working for the day, I simply drop the work phone on the charger, and walk away. There is a lot less temptation to “just check my work email once before bed”.

Dedicated Hours

Having time set aside for “work hours”, and making sure that I take breaks is very important. It’s easy to get hyper focused on something and forget to eat, or spend the day in PJ’s by mistake.

I make sure that I set aside time to make myself human, and that I dress for work. Does that mean buttoned down? No, I would wear a tee-shirt and jeans into the office, so working from home is no different.

I also try hard to go work from a coffee shop a few times a week. Or at least drive to a coffee shop, get out of the car, stand in line and get something. Interaction with other humans is important.

Video On

I also try and have meetings with my video on. It’s more for me then for anyone else. I try and make sure that my workspace and myself are presentable every day. Good back lighting is important. I know that since I face a window, I look better on sunny day then I do on cloudy ones.

Healthy Snacks

This one took a few years and a few pounds before I got it. Having healthy lunches and snacks around the house is important. Not having boxes of Oreos is also important.

I used to have pretty bland lunches. I have really tried to up my game. One of the things that helps is blocking out 45 minutes or so for lunch, so I have time to make something good, and not feel rushed.

Water coolers

Having some sort of “water cooler” chat system is important. Over the years, I have seen IRC, Campfire, HipChat, Slack and Quip Chat in this role. As long as everyone has a “safe-ish” space to talk about coffee, dogs, weather, space, or what ever crosses their mind then this need is met. I have seen gaming groups, music chatter, coffee talk and technology randomness.

What’s important is a space for folks to talk with each other about work, work related, and not work related things.

Meetups

Meeting up with coworkers on the same team is vitally important as well. In the past I would spend a week every few months at HQ, to wander the halls, get face time with folks, and generally catch up.

Team off sites are also important. Some of the best team building times that I have had were at off sites. It does not need to be something fancy. A lot of the time we would all head to the same conference, and make some time to catch up.

Takeways

In closing, working remote takes a bit of thought and work, but it’s a great life style. I can take the time that I would loose to a commute, and get caught up on news, brew a Chemex of coffee, or even sleep a little more. The disconnection can be scary at first, however with some adjustments the focus that you can gain can return large productivity gains.

All it takes is discipline and a slightly diffrent way of looking at work/life balance.

Nginx Routing on Heroku

Greg Nokes — Thu, 27 Feb 2020 00:00:00 +0000

Sometimes, we want to be able to route requests based on URL paths easily, or have a front end app that serves data from private back end services.

For example, if you have several services in a Private Space that serve HTML, you might not want to expose them to the internet, and rather have a routing app in front which will handle this. Or you might want to route your asset delivery to S3, and completely offload that processing from the local app server. Nginx is a powerful, fast and lightweight web server which can also operate as a reverse proxy. It also runs well on Heroku.

For this example, we will set up 3 apps

ggn-nginx-router-test
ggn-nginx-test-target
ggn-nginx-test-blog

ggn-nginx-router-test will be running Nginx, with configs set to route requests back to the target app. ggn-nginx-test-target will simply deliver HTML with the requestors HTML headers. ggn-nginx-test-blog will simply be a second HTML target.

Setup nginx-test-target

Install PHP and Composer Locally (brew install php && brew install composer on a Mac)

Set up your working directory in your code directory:

☯ mkdir test-target
☯ cd test-target
☯ git init .
☯ heroku create ggn-nginx-test-target

Set up a .gitignore file:

☯ cat .gitignore 
/vendor/

Create a Procfile:

☯ cat procfile
web: vendor/bin/heroku-php-apache2

Create a composer.json :

☯ cat composer.json 
{
  "require" : {
  },
  "require-dev": {
    "heroku/heroku-buildpack-php": "*"
  }
}

Run composer update and then create an index.php:

☯ cat index.php 
<h1>This is not a Blog<br />
Requestor Headers:</h1>
<br />
<?php 

foreach (getallheaders() as $name => $value) {
    echo "$name: $value\n<br />";
}
?>

Setup nginx-router-test

Set up your working directory in your code directory:

☯ mkdir router-target
☯ cd router-target
☯ git init .
☯ heroku create ggn-nginx-router-test

Add the nginx buildpack:

☯ heroku buildpacks:add https://github.com/heroku/heroku-buildpack-nginx
Buildpack added. Next release on ggn-nginx-router-test will use heroku-community/nginx.
Run git push heroku master to create a new release using this buildpack.

Add a Procfile:

☯ cat Procfile
web: bin/start-nginx-solo

Add a Nginx config file. We use an .erb file as the build pack will process it, and generate a finished config file out of it. It needs to go in config/nginx.conf.erb

☯ cat config/nginx.conf.erb 
daemon off;
# Heroku dynos have at least 4 cores
worker_processes <%= ENV['NGINX_WORKERS'] || 4 %>;

events {
  use epoll;
  accept_mutex on;
  worker_connections <%= ENV['NGINX_WORKER_CONNECTIONS'] || 1024 %>;
}

http {
  gzip on;
  gzip_comp_level 2;
  gzip_min_length 512;

  server_tokens off;

  log_format main '$time_iso8601 - $status $request - client IP: $http_x_forwarded_for - <%= ENV['DYNO'] %> to $upstream_addr - upstream status: $upstream_status, upstream_response_time $upstream_response_time, request_time $request_time';
  access_log /dev/stdout main;
  error_log /dev/stdout notice;
  log_not_found on;

  include mime.types;
  default_type application/octet-stream;
  sendfile on;

  # Must read the body in 5 seconds.
  client_body_timeout <%= ENV['NGINX_CLIENT_BODY_TIMEOUT'] || 5 %>;

  upstream upstream_production {
    server ggn-nginx-test-target.herokuapp.com;
  }

  server {
    listen <%= ENV["PORT"] %>;
    server_name _;

    location / {
      set $upstream upstream_production;
      proxy_pass http://$upstream;
      proxy_set_header x-forwarded-host $host;
      proxy_set_header Host ggn-nginx-test-target.herokuapp.com;
    }

  }
}

You should now be able to hit ggn-nginx-router-test.herokuapp.com and get the app living at ggn-nginx-test-target.herokuapp.com delivered to you.

Or you can simply deploy this repo.

Setup nginx-test-blog

Set up your working directory in your code directory and create a .gitignore file

☯ mkdir test-blog
☯ cd test-blog
☯ git init .
☯ heroku create ggn-nginx-test-blog


☯ cat .gitignore 
/vendor/

Create a Procfile:

☯ cat procfile
web: vendor/bin/heroku-php-apache2

Create a composer.json :

☯ cat composer.json 
{
  "require" : {
  },
  "require-dev": {
    "heroku/heroku-buildpack-php": "*"
  }
}

Run composer update

Create an index.php:

☯ cat index.php 
<h1>This is a Blog!<br />
Requestor Headers:</h1>
<br />
<?php 

foreach (getallheaders() as $name => $value) {
    echo "$name: $value\n<br />";
}
?>

Adding in additional routes is as simple as setting up new location blocks and their corresponding upstream blocks. For example you could add

  upstream upstream_blog {
    server ggn-nginx-test-blog.herokuapp.com;
  }

and

    location /blog/ {
      set $upstream upstream_blog;
      proxy_pass http://$upstream/;
      proxy_set_header x-forwarded-host $host;
      proxy_set_header Host ggn-nginx-test-blog.herokuapp.com;
    }

Now when you visit ggn-nginx-router-test.herokuapp.com/blog/ you will get the contents of ggn-nginx-router-blog.herokuapp.com/.

In the config directory of this repo on github is a sample nginx.conf.erb which enables this example.

In closing, we created three applications on Heroku. One was a proxy and router, and the other two were backing services. The proxy examines the URL, and based on the path, renders one of the two backing services. This is a small example of the many uses of Nginx on Heroku. More use cases include delivering static content and reverse proxying into a Private Space.

Nginx as a static site server on Heroku

Greg Nokes — Mon, 07 Oct 2019 00:00:00 +0000

I was doing some performance testing on my blog, and while I was impressed, I felt like I could wring some more speed out of it. I decided to switch from Heroku’s Static Buildpack to a simple Nginx webserver using Heroku’s nice Nginx Buildpack. In theory this should be a little quicker and lighter.

The first step was to get Nginx set up on the Heroku App. I had the static buildpack already, so I simply had to remove it and add the Nginx Buildpack.

The next step is to modify the Procfile to run Ngnix in Solo mode:

web: bin/start-nginx-solo

Then I created a config directory and put my nginx.conf.erb file in it. The Nginx buildpack will grab that file, process it, and then use it to run Nginx on the dyno.

I found this config to work well:

daemon off;
# Heroku dynos have at least 4 cores
worker_processes <%= ENV['NGINX_WORKERS'] || 4 %>;
events {
  use epoll;
  accept_mutex on;
  worker_connections <%= ENV['NGINX_WORKER_CONNECTIONS'] || 1024 %>;
}

http {
  gzip on;
  gzip_comp_level 2;
  gzip_min_length 512;

  server_tokens off;

  log_format main '$time_iso8601 - $status $request - client IP: $http_x_forwarded_for - <%= ENV['DYNO'] %> to $upstream_addr - upstream status: $upstream_status, upstream_response_time $upstream_response_time, request_time $request_time';
  access_log /dev/stdout main;
  error_log /dev/stdout notice;
  log_not_found on;
  include mime.types;

  default_type application/octet-stream;
  sendfile on;

  # Must read the body in 5 seconds.
  client_body_timeout <%= ENV['NGINX_CLIENT_BODY_TIMEOUT'] || 5 %>;

  server {
    listen <%= ENV["PORT"] %>;

    error_page 404 /404.html;
  error_page 403 /403.html;

    port_in_redirect off;

    location / {
        root _site/;
    }
  }
}

The important parts are the port_in_redirect off; and the root _site/; directives. The port_in_redirect tells Nginx to not embed it's port into any redirects, and root tells Nginx where the static files are.

Well, is it fast?

I ran ab on the site before and after, and there is a large improvement. Larger than I expected.

The old configuration had a perc99 under load of 1.7 seconds per request, and the new has a perc99 of 0.6 seconds. More than a second per request faster!

Old Config

Concurrency Level: 100
Time taken for tests: 7.284 seconds
Complete requests: 5000

Failed requests: 0
Total transferred: 6922000 bytes
HTML transferred: 6722000 bytes
Requests per second: 137.28 [#/sec] (mean)
Time per request: 728.426 [ms] (mean)
Time per request: 7.284 [ms] (mean, across all concurrent requests)
Transfer rate: 928.00 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 307 449 233.8 380 1612
Processing: 103 204 84.1 212 1026
Waiting: 103 201 83.5 211 1026
Total: 424 653 247.2 591 1939

Percentage of the requests served within a certain time (ms)
  50% 591
  66% 627
  75% 658
  80% 670
  90% 822
  95% 1084
  98% 1738
  99% 1769
 100% 1939 (longest request)

New Config

Concurrency Level: 100
Time taken for tests: 26.680 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 34870000 bytes
HTML transferred: 33650000 bytes
Requests per second: 187.41 [#/sec] (mean)
Time per request: 533.592 [ms] (mean)
Time per request: 5.336 [ms] (mean, across all concurrent requests)
Transfer rate: 1276.36 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 297 385 42.1 378 620
Processing: 102 136 33.6 122 641
Waiting: 102 133 30.5 120 641
Total: 424 520 51.2 506 986

Percentage of the requests served within a certain time (ms)
  50% 506
  66% 524
  75% 536
  80% 544
  90% 577
  95% 643
  98% 685
  99% 696
 100% 986 (longest request)

But what about SSL?

One of the things that I really liked about the Static Buildpack is that it is based on Rack, and I could use the rack-ssl-enforcer gem to make sure that all requests were directed to the encrypted version of the site. I did some investigation and found the following stanza in the server block would work with the Heroku router:

if ($http_x_forwarded_proto != "https") {
  return 301 https://$host$request_uri;
}

A redirect would be preferable, however since we are behind the Heroku Router, a simple redirect seems to enter into an infinite redirect loop. The if loop slows down processing considerably.

With SSL Redirect

Concurrency Level: 100
Time taken for tests: 26.618 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 34870000 bytes
HTML transferred: 33650000 bytes
Requests per second: 187.85 [#/sec] (mean)
Time per request: 532.352 [ms] (mean)
Time per request: 5.324 [ms] (mean, across all concurrent requests)
Transfer rate: 1279.33 [Kbytes/sec] received

Connection Times (ms)
              min mean[+/-sd] median max
Connect: 305 385 40.6 381 1618
Processing: 101 134 31.4 123 471
Waiting: 101 131 28.0 120 469
Total: 422 519 48.5 510 1740

Percentage of the requests served within a certain time (ms)
  50% 510
  66% 523
  75% 533
  80% 544
  90% 569
  95% 596
  98% 630
  99% 704
 100% 1740 (longest request)

Still respectable, but you can see the impact of using the if statement in the Nginx config. The perc99 is only a few milliseconds slower with the SSL redirect, but milliseconds count!

I will continue to research and see if I can remove that if statement, and find a cleaner way to implement this.

One of the other uses for Nginx on Heroku is a on Dyno proxy and static file server. This experiment shows how efficient Nginx can be at hosting the static assets of a complex web application, like Ruby. Using Nginx as a front end to proxy requests, and serve static files offloads traffic from the language specific app server, and can improve overall performance of a web application.

Update 10/10/19

I quickly found out that I still needed the static buildpack in my development and staging environments. It’s used to build out the static assets that Nginx serves, after all.

If you refer back to How I post an article you will know that I use a Heroku Pipeline to manage posting. The nice thing is that I don’t need the Static buildpack or Ruby on my production site, as the slug is promoted intact between the Staging and Production apps. So I have Ruby and the Static buildpack installed and running in staging, but only the Nginx buildpack associated with the production app.