exratione

My specialties: devops, cloud computing, full stack software engineering, architecture, leading teams.

I am a senior full stack software and devops engineer, experienced with cloud infrastructure, and as an architect and team lead. My experience in the industry is divided fairly evenly between early stage startups, larger companies, and more traditional consulting. I am strongly in favor of cloud computing, open source software, comprehensive documentation, empowered user communities, and unregulated markets.

Website: https://www.exratione.com

GitHub: https://github.com/exratione

Location: Austin, TX

Remote: Yes

Willing to relocate: for the right position

Technologies: Primarily Javascript, PHP, and Java stacks for application engineering, then just about every known scripting language and flavor of Unix for the devops side of life.

If you make third party web applications, Javascript or whatnot to include on someone else's page, then Charles or similar is a must-have when you have non-technical and semi-technical people helping with customer issues. Almost anyone can use Charles to make the simple assessments of a problem, root cause, wolf-fencing, etc.

In the technical groups, Charles can usually be bettered for ease of use by custom tools for specific use cases. It is pretty quick and easy to use the proxy libraries in Node.js to throw together internal tools with a command line interface, for example.

In a world that is increasingly data, the ability to process and react to that data becomes worth.

Marking worth is just more data processing, a declaration of subjective value in the scheme of your choice. Nothing special.

The nature of your interactions with those of lesser worth, and your views of them, however...well, there is a defining thing for a human being.

Well, yes: https://en.wikipedia.org/wiki/Lysander_Spooner

So: Dwarf Fortress in a forest with an aquifer down in the soil.

It takes a year to build a wooden hall large enough for most of the workshops, on one side of the river, while on the other side digging out a collapse to drop soil into the acquifer. A lovely wooden bridge and wooden tile road is the meeting area to keep the dwarves happy while they have no stone.

The dwarf with the only pickaxe falls into the watery pit under the collapse and drowns. I have to wait half a year to trade for another while the dwarves live on fish and berries in their hall. They are haunted by the ghost of the miner, as there is no stone for for a engraved slab in the graveyard. Cherry blossoms litter the ground, and blow into the half-finished excavation.

A crafter is possessed and wants stone, the one thing we don't have. What little the drwarves traded for had to go to other uses. A great pile of wooden crafts is building up. Just as well there are no elven neighbors. The crafter becomes melancholy, and wanders about the fisherdwarves, watching them. Sometimes he stands in the middle of the river.

After trading a new pick, the next miner knocks out the remaining support, and the collapse happens. But, alas, the aquifer is two levels thick! Only one level is smushed dry with the collapsed soil. We trade for rock, build a new structure in the now open watery pit. Two dwarves fall in that season during the construction, adding more drowned victims and wailing ghosts.

The construction of stone walls in the pit is knocked down at the cost of yet another dwarf - yet it isn't enough to breach the aquifer. Woe. The pit is now littered with rock and bodies and materials.

There is only one other thing to do; build a stack of wooden pumps, stairs, landings down into the pit, and an aquaduct to the river. Pump it dry and send in dwarfs to build walls and lock away the water.

All of this and still not at the point of the exercise - to raise a great hollow tower of stone over the river and a deep pit of stairs beneath, and tear down the hall of wood for charcoal. So it continues.

Your comment rather illustrates my point.

Comparative advantage isn't abolished just because the advantage is large.

Economic participation by a class of entities who have a lower capacity for production than every other class of entities is still useful to all involved.

A great many of the world's prejudices, fears, and passionate causes are driven by ignorance of basic economic principles, and this is another example.

Here's another alternative interpretation that's been around for a couple of decades:

https://en.wikipedia.org/wiki/Transactional_interpretation

Though at a much earlier stage in the development of such things.

For multiple domains, you have to validate each one separately via the webroot method unless they are all getting served from the same webroot.

If it is all the same webroot, then yes, add them all to the domains variable.

If different webroots you might need to use the command line, which lets you run

--w /x/y/z -d example1.com --w /a/b/c -d example2.com

in one command. I'm not sure how to make that work in the configuration file, though I'm sure there's a way.

This example script assumes that the server has a running webserver, either Apache or Nginx. Since it doesn't use a package install for Certbot, this script should work on most Linux distributions. It installs Certbot, obtains the certificate, and sets up the cron task for renewal.

---

  #!/bin/bash
  #
  # This sets up Let's Encrypt SSL certificates and automatic renewal
  # using certbot: https://certbot.eff.org
  #
  # - Run this script as root.
  # - A webserver must be up and running.
  #
  # Certificate files are placed into subdirectories under
  # /etc/letsencrypt/live/*.
  #
  # Configuration must then be updated for the systems using the
  # certificates.
  #
  # The certbot-auto program logs to /var/log/letsencrypt.
  #

  set -o nounset
  set -o errexit

  # May or may not have HOME set, and this drops stuff into ~/.local.
  export HOME="/root"
  export
  PATH="${PATH}:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

  # No package install yet.
  wget https://dl.eff.org/certbot-auto
  chmod a+x certbot-auto
  mv certbot-auto /usr/local/bin

  # Install the dependencies.
  certbot-auto --noninteractive --os-packages-only

  # Set up config file.
  mkdir -p /etc/letsencrypt
  cat > /etc/letsencrypt/cli.ini <<EOF
  # Uncomment to use the staging/testing server - avoids rate limiting.
  # server = https://acme-staging.api.letsencrypt.org/directory

  # Use a 4096 bit RSA key instead of 2048.
  rsa-key-size = 4096

  # Set email and domains.
  email = admin@example.com
  domains = example.com, www.example.com

  # Text interface.
  text = True
  # No prompts.
  non-interactive = True
  # Suppress the Terms of Service agreement interaction.
  agree-tos = True

  # Use the webroot authenticator.
  authenticator = webroot
  webroot-path = /var/www/html
  EOF

  # Obtain cert.
  certbot-auto certonly

  # Set up daily cron job.
  CRON_SCRIPT="/etc/cron.daily/certbot-renew"

  cat > "${CRON_SCRIPT}" <<EOF
  #!/bin/bash
  #
  # Renew the Let's Encrypt certificate if it is time. It won't do anything if
  # not.
  #
  # This reads the standard /etc/letsencrypt/cli.ini.
  #

  # May or may not have HOME set, and this drops stuff into ~/.local.
  export HOME="/root"
  # PATH is never what you want it it to be in cron.
  export
  PATH="\${PATH}:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

  certbot-auto --no-self-upgrade certonly

  # If the cert updated, we need to update the services using it. E.g.:
  if service --status-all | grep -Fq 'apache2'; then
     service apache2 reload
  fi
  if service --status-all | grep -Fq 'httpd'; then
     service httpd reload
  fi
  if service --status-all | grep -Fq 'nginx'; then
     service nginx reload
  fi
  EOF
  chmod a+x "${CRON_SCRIPT}"

---

Clustered timing of reviews is unfortunately not a great metric for determining whether or not they are legitimate. Many - probably most - companies send out emails to buyers asking them to review, no compensation provided. This is pretty effective, and a big driver of legitimate reviews. The timing of those emails is determined by response rates, which tend to be better on specific days - hence the mails are batched. So for some large entities, you'll see reviews clustering on Thursday to Saturday for example.

I just updated my Ubuntu mail server recipe for Ubuntu 16.04 (https://www.exratione.com/2016/05/a-mailserver-on-ubuntu-16-...). It only took a day of work to find all the holes and fall into them.

Everything core Ubuntu and core mailserver worked fairly well. The standard issue Apache/PHP 7 seems to have some odd kinks around the edges, though - at one point the only thing that worked to make it recognize a newly installed PHP module package was to restart the whole server. I have to wonder if this was something relating to systemd, but I'm not familiar enough yet to tell.

Subsidiary packages had a number of issues, but this is probably just standard PHP ecosystem raggedness at the edges for a new distribution. The Roundcube version installed via package is just outright broken due to bad symlinks, for example.

On the whole I was pleasantly surprised as to how much of a nonissue the transition to systemd was.

Looks like picking the simpler option precisely because it was simpler was the sensible choice. I've had no issues with react-simple-router: it routes, it works with react, what else do you really need?

The simulation hypothesis is, sadly, perhaps the only self-consistent solution to the Fermi Paradox, one that doesn't require very unlikely propositions.

https://www.exratione.com/2015/05/the-cosmological-noocene/

All of the other suggestions require all intelligent life without any exceptions in our past light cone to behave in a consistent way, i.e. fail to build obvious megastructures, fail to come calling, etc, so as to leave everything with the appearance of being natural. The Fermi Paradox is more the Wilderness Paradox in nature. Given that a tiny faction within any sufficiently advanced civilization could on their own generate self-replicated probes that converts the observable universe to computronium, and that some portion of humanity will do that if not stopped, and that we appear in no way to have exceptional origins or be in an unusual region, that really suggests there is something fundamental that we don't yet understand.

Down that road lies Greg Egan's Dust hypothesis; it is a slippery slope.

http://schwitzsplinters.blogspot.com/2009/01/dust-hypothesis...

http://gregegan.customer.netspace.net.au/PERMUTATION/FAQ/FAQ...

Equally, https://github.com/git-land/git-land

"This is a git extension that merges a pull request or topic branch via rebasing so as to avoid a merge commit."

You might also compare this with the traditional system of distributed dispute resolution that held sway in Iceland at the time of the sagas. While quite different cultures, many similar solutions and incentives acted to minimize violence between familial groups. In that case the system failed when it fell out of decentralization and into control of a sufficiently small elite for them to become a defacto government, but it took 300 years to reach that failure case.

A very high-level summary: https://mises.org/library/medieval-iceland-and-absence-gover...

No video, I'm afraid. It is responsive, but not as feature-rich or advanced an interface as Android or ioS, of course. My main complaints on that front are lack of some idioms and that it isn't as smart about what the intent of touches are in some situations. It is like venturing a good six years into the past in terms of overall polish of the interface.

Also the web browser in Ubuntu Touch is painfully lacking in features, and you can't yet put Firefox on there - but then I'm not using it for browsing.

Well, it still does all the other Ubuntu things, and it is a cheap tablet. My survey of the ereader space didn't turn up anything I liked, or that seemed to come without strings. It is very possible that I missed an obvious and better.

I recently build myself an ebook reader from a Nexus 7 using Ubuntu Touch:

https://www.exratione.com/2015/10/turning-a-nexus-7-fhd-tabl...

Dealing with other tablets and Touch is pretty hit and miss - you might be able to get it to work, but more likely not unless you're pretty experienced in low-level hacking in OS and devices.

Certainly that hardware doesn't have enough memory to keep Beru happy all the time, which is a pain, but I'm prepared to put up with the minor inconvenience in exchange for not having an reader that reports everything I do back to central.

If an official Ubuntu tablet can be disconnected from their report-everything-to-central mechanisms to the same degree that Ubuntu on the desktop can, then an official tablet may be worth the additional cost just to use as a reader.

The real issue is not that we haven't been visited (for which read, we exist, because the matter of the solar system wasn't turned into computronium by some group billions of years ago), but that everything we see is a wilderness. All of the observable universe appears natural in every place we can assess whether or not it is natural. No dyson spheres in evidence, no class 3 civilization in any of the nearest 100,000 galaxies, etc, etc.

This makes no sense given that we exist, and the laws of physics show no indications that we are a special case, or that transforming the universe into intelligent matter is impossible. All it takes is one small group in one species to create the self-replicating probes that dismantle every natural grouping of matter to create more efficient arrangements to support more intelligence, and on a small timescale compared to the age of the universe entire galaxies are turned from wilderness to structure.

https://www.exratione.com/2015/05/the-cosmological-noocene/

"Per our present understanding of physics and intelligent economic activity, we will turn every part of that great span into our descendants if not diverted or stopped by some outside influence, stars and all. The cosmological noocene, an ocean of intelligence. That the natural universe remains present to be used by us indicates that something is awry, however, that some vital and important understanding is missing, and as a species we are still just making the first fumbling explorations of the bounds of the possible with regards to what it is that we don't know."

Most of the issues with Grunt and the like can be done away with by following good coding practices. i.e. keep your code outside the Grunt context and write unit tests for it. See the Thin Grunt Manifesto:

https://www.exratione.com/2015/08/thin-grunt-manifesto/

I'm not sure I buy fleeing to the command line as a viable alternative. You are in essence going to have to write a bash script at some point because the command will bloat beyond what can be sanely contained in a JSON property. Then you have to write tests for it. So why not just do that in Javascript, since you already have the infrastructure sitting there.

I think it is the case that most groups simply write lazy Grunt code in ways that make it hard to test. This is a chronic problem throughout the devops space; the code is frequently terrible. So don't do that. Don't drag the Grunt instance out into your code. Separate your concerns. Write testable functions and classes.

You might also look at https://github.com/nodesecurity/nsp

The Node.js ecosystem is still fairly immature with regard to formalized security, certainly in comparison to, say, the Java ecosystem. There just aren't as many people filing CVEs on packages as a part of vetting their stacks, and certainly far fewer people focused on that part of the security process.

To a certain degree tools are only going to be as good as the security environment. If people aren't filing CVEs at an appropriate pace given the level of vulnerability out there, and it takes a village, etc, etc, then no one group is going to be able to deliver a good security service on their own, since these services are individually (a) a megaphone and filter for a CVE RSS feed, and (b) a minor source of CVEs.

My contribution to the Lambda application construction party:

https://github.com/exratione/lambda-complex

Lambda Complex is a Node.js framework for applications that run entirely within Lambda, SQS, and other high abstraction layer AWS services. It is well suited to non-realtime content generation and other types of application driven by message queues and which require enforced concurrency limits. Examples include high volume generation of static content from data or other types of workflow initiated in response to messages placed into SQS queues.

A different and less comprehensive recipe to compare with for Ubuntu:

https://www.exratione.com/2014/07/setting-up-spf-and-dkim-fo...

Since you absolutely have to run everything you plan on sending to a mailing list via spamassassin beforehand, mail-tester.com is a great tool. It saves the annoying work of cobbling together a spamassassin test script and integrating it into your workflow, and gives you a bunch of other checks while you're at it.

Spamassassin is half of the bane of my life when it comes to maintaining deliverability on a scientific mailing list:

https://www.exratione.com/2015/08/spamassassin-is-an-inadequ...

It stops being a useful tool and starts being a mode of censorship that is in effect controlled by the people who practice fraud and abuse. It is very annoying to find all sorts of things that effectively can't be discussed by mail in a list: specific drugs and technical terms used in research, any research discussion or published research that uses long technical words in close proximity, fundraising for research, and so on and so forth. Every newsletter to the opt-in, well-gardened list becomes a little minefield of self-censorship as you go through multiple iterations with spamassassin, weeding out and rewording things.

It is all very trying. One has to think that there's a better way.

The pain point for what you want there is the versioning and deployment side of things: how you update the application as atomically as possible.

I need to get Lambda Complex into real apps for a while in order to understand what is really, actually needed around the transition of the interface with other AWS resources on update of version. Currently I'm sure it's going to be a major pain to have to write some code to redirect the flow of events to a different queue, but that's still better in my mind than to try to manage versioning with a single queue or other source of events that is not included in the CloudFormation template or has to be managed as a special case during updates.

The other pain point is monitoring of the application state and clearing up after it. Lambda functions spawn infinite log groups in CloudWatch, and they don't get deleted without some sort of automation to go do that. It isn't clear to me what the best approach is at this point in time to attach monitoring and alerting to CloudWatch Logs. I'd almost rather leave them alone and primarily monitor via SQS queue attributes, leaving the CloudWatch logs for manual inspection.

It has been the case for years now that you really have to include ad and tracking blockers for browsers in your testing process somewhere, even if it's just a manual run-through in the smoke test section. Though I think that more than that is needed; e.g. adblock-enabled pools in your Selenium grid.

You really have to start from the bottom up assuming that things are going to get blocked for some people and build in graceful degradation of performance:

https://www.exratione.com/2014/12/practice-defensive-javascr...

Though the problem in this article looks more in the way of something to be caught by a sufficiently well constructed QA process, followed by a bug filed with the ad blocker in question.

Once you are over the initial hurdle of creating a config file, which is sort of like picking words you like while browsing a dictionary, ESLint is a great replacement for the JSHint and JSCS combination - much more compact and less finicky.

Here's a simple .eslintrc that hits pretty much all the high points and syntax conventions that people fight over, while leaving the things that most people agree on as the standard defaults:

https://www.exratione.com/2015/07/eslint-as-a-replacement-fo...

I've carried out that alteration/redlining in every tech work contract I've signed. It has never been a blocking issue, and it is usually the case that the people handling the details of hiring are unaware of the details of the clauses in the contract - they just take what the lawyers hand over as boilerplate.

https://www.exratione.com/2011/11/the-miserable-state-of-int...