Docker Permission Denied on Ubuntu 16.04

docker, ubuntu

Recently, I have been messing around with writing and deploying AWS Lambda Functions and Microsoft Azure Functions - two “serverless” technologies that have a lot of promise for certain applications.

For development environments, both rely on using docker images provided by the respective vendors to run your functions locally.

I attempted to set up Docker on Ubuntu 16.04 by running sudo apt install docker, which appeared to succeed.

However, when attempting to run docker run hello-world - a command which should pull a ‘hello world’ image from one of the public docker repositories, then run it - I received an error to the effect of:

1
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

The solution to this problem is to either (a) run your docker commands as root, or (b) add your login user to the docker group.

Option (a) is not preferred, as introducing a sudo dependency will quickly lead you to ‘sudo hell’ where everything of use requires sudo.

For option (b), you can run sudo usermod -a -G docker $USER, which will add your user to the docker group.

For the change to take effect, you will need to fully log out of your account and log back in.

Things I Am Reading

reading, thinking,

Over the past week or so, I have been spending a lot more time reading blogs.

Upon reflection, I am trying to fill a specific hole in my life: I’m not having enough interesting discussions with smart people who have interesting things to say about things that I don’t know about.

That sentence seems a bit long, and maybe convoluted, but I think it is about right. The absence of it is grinding on me.

Prior to 2006, I think this mostly came from speaking to my parents. Being under 12, this was acceptable.

From 2006 to 2009, this mostly came from spending an inordinate amount of time on a old-school web forum that, while centered around a particular game, had a politically diverse, tight knit community who liked to talk about all sorts of things.

From 2009 to 2011, I had truly fantastic teachers and classmates as conversation partners at Robinson High School in Tampa, Florida. In particular, three of my History teachers spent hundreds of hours in ‘study hall’ discussing all manner of things, ultimately teaching me much more than the State of Florida would’ve liked.

From 2011 to 2014, interesting discussions came from a combination of college classes (interesting, but outside of the mathematical classes, lacking), the University Economics Society at the University of Florida (light on economics, heavy on interesting discussion), and thousands of hours of discussion with Steve Spalding (@sbspalding) and Miguel Barbossa (@MiguelABarbossa, check out citizenaudit.org).

I graduated, I threw myself into my company, and then another. For a period in 2016, I got my fill from a wonderful private Facebook group. But like most communities, its moment ended; while it tided me over, after the 2016 election, the high quality discussion ended1.

Then, for three months in 2017, I had a taste of this again, hanging out with the wonderful Richard Stein in Hong Kong.

Given that for the majority of my life I’ve gotten most of my interesting discussion online, it shouldn’t be hard to reconstruct this.

But since 2014, the world has moved. Going through my old follow lists, many people are no longer active. Those who are active are posting less interesting (alternatively: less controversial) ideas in public spaces2.

I am resolved to rebuild. I’ve started by rejecting algorithmic aggregation3: I want to find content that makes me a better thinker and person, not content that monetizes well. The ‘indie web’ (we used to call it ‘the web’).

Here are the blogs that I find interesting and you should check out, along with a couple of keywords:

Dan Luu’s Blog: Low level programming, computer engineering, excellent essays about the market for technical talent.

DaedTech: Mostly commentary on navigating freelance technology roles; excellent writing.

Ben Kuhn: I’ve not read the archives, but general technology, effective altruism.

Decibels and Decimals, Brady Fowler’s music / data sci blog; not super active but every post is a delight.

Brute Reason, social justice, social issues.

Ribbonfarm, tech, culture, deep thinking

Evan Miller, statistics, programming. I love his post on dealing with floating point exponentiation when plotting the F distribution

If you have any recommendations, I’d love to hear them. Please reach out.

I’m also looking to correspond with people who want to discuss whatever is interesting to them at the moment. Please reach out.


  1. My assessment is the very real consequences of the 2016 election made discussing politics just a little too serious.

  2. I’m not sure if this is sampling bias, or just natural attrition. The number of blogs I used to follow that no longer provide RSS, or switched to Medium, then died, is too high, though.

  3. For now, feedly is working well - it appears to have a quasi-magical ability to subscribe to some sites that don’t have an RSS feed

List of Email Marketing Service Providers 2017

email

There are many email marketing service providers - more than one person could reasonably keep in their head. This is an incomplete list, created for my own notes.

Marketing Automation Tools with Email Delivery

Email Marketing Campaign Providers

These ‘Email Marketing’ providers each do email delivery, but only through their ‘email marketing’ platform. These providers only provide tools to send emails to ‘contacts’ - not generic or transactional emails. Each generally has some sort of campaign / newsletter creation tool, and usually some analytics and often optimization options. Pricing is generally based on the number of ‘contacts’ that you have in your contact database.

Email Delivery Providers

These providers provide an SMTP API to provide email delivery from your application via an SMTP server and/or an API. Some of them also provide ‘email marketing’ or ‘marketing automation’ services. Pricing is generally based on the number of emails sent per month, and may be per-use or tiered into subscription levels.

Other Email Tools

Materialized Views Part 2 - MVs in Rails

rails

In Supercharge your app with materialized views, we discussed some of the benefits of using materialized views in a web application, and some of the situations in which a Materialized View may be a good choice.

My framework of choice is Rails. Rails’ default ORM, ActiveRecord, is very good, but it does not provide any real integration for views, materialized or otherwise. This becomes an issue, as views can only be dropped and re-defined - not incrementally changed with add_column or the like - thereby requiring us as developers to manually ensure that we’re correctly defining the view each time we wish to update it.

Originally, this post was going to be a discussion of some of the ways of managing this complexity, but I have since discovered scenic, a gem by thoughtbot designed specifically for managing materialized views. I recommend you check it out for all of your view management needs.

Supercharge Your App With Materialized Views

rails

Materialized views a very powerful PostgreSQL feature that can allow you to dramatically speed up complex reads. Since they aren’t often used in Rails, here are some notes on when to use Materialized views and how to effectively use them

On Views & Materialized Views

A database view is a result of a stored query. You can read from a view just like one would read from a table, and perform additional filtering on the results of the view. They’re particularly useful when the stored query is very complex, for example, when the query is the result of several complex JOINs. Evey time that a view is read from, the query that defines it is performed.

A materialized view is a view that has been executed and has its results stored on disk, effectively caching the results of the query. Because the results of the query are written to disk, reading from and querying a materialized view is just as fast as doing a straight read on a single table - scary fast. For complex database operations, this can be a significant speedup.

The cost of that increase in read performance is that the materialized view does not automatically change with changes underlying data. A materialized view must be periodically “refreshed” to bring it up to date - essentially, performing the query that defines the view again, and storing the results. Depending on the complexity of the query that defines the view, it could be practical to refresh the view frequently, even upon every write to the underlying table, but it is not done automatically.

A short example

Here’s a quick example. Let’s say that we have a website that allows customers to book cruises.

What makes up a cruise? Well, a cruise is a specific customer renting a specific cabin, which has a type, during a specific sailing of a ship, which itself is from a specific port. Maybe our schema looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
cabins
  - id
  - cabin_number
  - ship_id
  - cabin_type_id

cabin_types
  - id
  - price_per_day

sailings
  - id
  - ship_id
  - departure_port_id
  - embark_date
  - return_date
  - price_adjustment_factor

ships
  - id
  - name

ports
  - id
  - name
  - port_fee

cabin_sailings
  - cabin_id
  - sailing_id
  - booked

We want to show the user CabinSailings that are not booked, but allow them to search by criteria that’s stored through a lot of JOINs. To allow the user to search by the name of the port, for example, we’re going to need to do something like:

1
2
3
SELECT * FROM cabin_sailings
  JOINS sailings ON sailings.id = cabin_sailings.sailing_id
  JOINS ports ON ports.id = sailings.departure_port_id

Not too bad, but then we’re going to need to select by the ship as well -

1
2
3
4
5
SELECT * FROM cabin_sailings
  JOINS sailings ON sailings.id = cabin_sailings.sailing_id
  JOINS ports ON ports.id = sailings.departure_port_id
  JOINS cabins ON cabins.id = cabin_sailings.cabin_id
  JOINS ships ON cabins.ship_id = ships.id

Oh, and while we’re at it, let the user select only, say, four day cruises, and sort by price:

1
2
3
4
5
6
7
8
9
10
11
12
SELECT
  cabin_sailings.*,
  (sailings.return_date - sailings.embark_date) AS duration,
  (duration *  cabin_type.price_per_day) * sailings.price_adjustment_factor + ports.port_fee AS price,
FROM cabin_sailings
  JOINS sailings ON sailings.id = cabin_sailings.sailing_id
  JOINS ports ON ports.id = sailings.departure_port_id
  JOINS cabins ON cabins.id = cabin_sailings.cabin_id
  JOINS ships ON cabins.ship_id = ships.id
  JOINS cabin_types ON cabins.cabin_type_id = cabin_types.id
WHERE duration = ?
ORDER BY price DESC

That’s not too bad, but you can quickly see how this is getting a little out of hand. Putting this much SQL into any traditionally define model is going to be unwieldy.

And as our application gets more complex, and our data set grows, doing these very complex JOINs will rapidly consume significant database power. Soon, we’ll be taking ten seconds to display results to the user - every time they search.

This is the perfect situation for a (Materialized) view. We can keep the complexity of the SQL that defines the concept we’re interested in - let’s call it a “Listing” for now - out of the application, and in the database where it belongs by using a view. And by using a materialized view, we can keep the queries super speedy, at the cost of having to put a bit more work into keeping them up to date.

Next Up

Next up: Some tips and tricks for using materialized views with Ruby on Rails.