Month: September 2017

Why not JavaScript *Without* a Framework?

Posted on by Brian Castelli

For months now I have been thinking about the design of a web front end for a collection services. There are *SO MANY CHOICES* out there that it’s sometimes difficult to turn off the incoming streams and make a choice. The exercise of thinking about a design often starts with thinking about frameworks. Code frameworks, primarily written for Javascript with a few for Python, do a bunch of work for you. But there’s a price. Frameworks are often large and regularly force you to implement things in one and only one way. Frameworks are not compatible with one another, so a choice locks you into a heavy investment. Should we use NodeJS? React? Flask? The list is seemingly endless.

Yesterday, I stumbled upon a podcast that takes an alternate approach. The guest on the show, Chris Ferdinandi, asserts that the conversation need not start with a framework. He acknowledges the fact that it can be overwhelming to thinking about frameworks. In some cases, it’s better to just use JavaScript directly. The code is smaller. There’s no framework lock-in. And JavaScript has come a long way from the state it was in several years ago that led to the proliferation of frameworks for it. To help people figure out what to do, Ferdinandi created a website, Go Make Things, where we can find small guides to help us learn to do things *without* resorting to frameworks.

The podcast uses quite a bit of jargon. I didn’t understand it all. But I did find the exposure to another way of thinking to be very helpful. I plan to check out Ferdinandi’s website.

Go Make things:

https://gomakethings.com/

Hanselminutes podcast:

https://www.hanselminutes.com/598/maybe-just-use-vanilla-javascript-with-chris-ferdinandi

AnsibleFest 2017, Network Modules in 2.3, and Ansible connection type

Posted on by Brian Castelli

I had the opportunity to attend AnsibleFest 2017 in San Francisco. The sessions I attended were of high quality. It was well worth the cost of attendance.

One of the cool things the Ansible folks setup were “Ask an Expert” sessions. Attendees could sign up for a 15-minute appoitment to discuss whatever issues have been troubling you. I signed up for a session with a network-module author to talk about my recent struggles running network modules using Ansible 2.3.

In Ansible 2.3, network modules require connection: local. When I ran my existing playbooks using Ansible 2.3, I saw errors of the form:

invalid connection specified, expected connection=local, got smart

I spent a bunch of time online before AnsibleFest trying to find out why this was happening. I didn’t understand connection: local, and the documentation was vague. The expert at AnsibleFest set me straight. The explanation was so simple that I had a solid “duh!” moment.

connection: local simply means that the module being invoked will be run on the Ansible node. That’s it. The default, connection: remote, pushes the module’s Python code to the inventory host and executes it there. Starting in Ansible version 2.3, network modules enforce connection: local because they operate against inventory hosts that usually don’t have Python installed, e.g. SROS.

I’ve now adopted the following best practice:

  • Configure my inventory to set connection type for localhost to ‘local’
    • [local_host]
      localhost ansible_connection=local
  • Delegate tasks that I want to run on the Ansible host to localhost
    • delegate_to: localhost