Author: giedrius

Regular Meetings vs. Online Meetings

Let’s try something a bit different – this article will be more a bit more fluffy and geared more towards presenting my opinion in addition to generating more discussion. Let me know your opinion and if you disagree/agree with this in the comments below!

With most of the world in lockdown nowadays, the majority of real-life meetings have moved into the virtual world. With it, comes the negative and positive consequences. Having gone through this myself, I have gathered some of my thoughts on this and presented them in this article. Overall, I think that unless you are putting a lot of conscious effort into your virtual meetings, the real-life ones are better. Let me explain why.

First of all, it is very easy to create a bunch of virtual meetings that you most likely do not even need. It is not surprising that a lot of advice is given out there on whether you should create a meeting at all. Perhaps it could be a simple e-mail? A quick Google search of the phrase meeting can be an email gives me 3410000000 results 😮. Real-life meetings typically entail moving from one physical location to another. As a consequence, you cannot cram so many of them in the same time period. That, however, could also be looked at as a downside. But, in my humble opinion, making it a bit harder to organize also means that proportionally more thought will go into whether it is worth organizing them in the first place.

All of the features baked into modern meeting software like Microsoft Teams improve the experience but also bring some drawbacks. For example, it is very nice to be able to collaborate on meeting notes with other meeting participants in real-time. You do not have to perform any extra manual steps like going to an external site that provides such functionality, registering there, and sharing the link. For software developers, it means that you can work together on some code together easily.

At the same time, the meetings being virtual makes them very easy to over-extend. In my experience, a lot of meetings, unfortunately, do not have a strict agenda so it is easy to fall into this trap. It seems like I am not the only one that thinks this way. There are a lot of projects for making leaving meetings easier. One thing is that in Zoom you need two mouse clicks to leave a meeting. Another thing is that you can actually leave them when you mean it. For example, Alan Mond built a button just for this purpose:

The meeting exit button. Image copyright 2020 Alan Mond, “Zoom Button“.

You can find all of the information here. I am definitely considering making something like this myself! What an awesome project.

Another thing to consider is that going between different meetings in real life most likely means that you are going to bump into someone on your way. Even though a lot of those conversations are ordinary small talk however sometimes you might get some knowledge that you could never get otherwise. Some go even further and say that informal meetings such as these are the keys to innovation. Of course, such informal meetings should be avoided when the participants need to focus on some specific material or numbers. With remote meetings, you lose this spontaneity that sometimes sparks new ideas. The closest thing to this that I have seen are “breakout rooms” between talks in virtual conferences where you can go to rooms to talk about some topics. So, not all is lost.

All in all, just like most things in life, different types of meetings have their own pros and cons. However, remote meetings bring some downsides that make it easy to fall down the rabbit hole. I think that besides the typical technical difficulties that people encounter, these things are also (huge) problems. You have to be conscious to minimize the impact of these problems. With that in place, remote meetings kind of become like a well-oiled machine that is better than the alternatives. Then, the only issue left is loneliness – but I think that this is not necessarily related to meetings, it is more related to what we do after work. But that is a completely different topic that I will not touch here.

Related Posts

Equivocal Puppet Class Parameters

While working with Puppet recently I have noticed that there is some funny business going on with the rules of parameter naming. The Puppet’s documentation states:

Parameter names begin with a dollar sign prefix ($). The parameter name after the prefix:

Must begin with a lowercase letter.

Can include lowercase letters.

Can include digits.

Can include underscores.

Let’s see if this is true. Tried applying this manifest with Puppet 5.5.10 which is available on Ubuntu Focal Fossa (20.04):

class test(
  String $_content
){
  file {'/tmp/helloworld':
    content =>  "${_content}\n",
  }
}


class { 'test':
  _content => "123"
}

And it does not work as expected:

$ puppet apply hello.pp
Error: Could not parse for environment production: Syntax error at '_content' (file: /home/gstatkevicius/dev/puppet_testing/manifest/hellofile.pp, line: 11, column: 3) on node gstatkevicius-desktop

Now, let’s try creating a simple hiera configuration:

---
:backends:
  - yaml
:yaml:
  :datadir: /home/gstatkevicius/dev/puppet_testing/hieradata
:hierarchy:
  - test
:logger: console
$ cat hieradata/test.yaml 
test::_a: "Hello World!"

It looks like the hiera part works:

hiera -c ./hiera.yaml -d test::_a
DEBUG: 2020-11-03 23:39:00 +0200: Hiera YAML backend starting
DEBUG: 2020-11-03 23:39:00 +0200: Looking up test::_a in YAML backend
DEBUG: 2020-11-03 23:39:00 +0200: Looking for data source test
DEBUG: 2020-11-03 23:39:00 +0200: Found test::_a in test
Hello World!

Now let’s see if applying the manifest with Puppet works:

$ puppet apply --hiera_config=hiera.yaml manifest/hellofile.pp
Notice: Applied catalog in 0.01 seconds
$ cat /tmp/helloworld
Hello World!

Oh, so now everything is OK? It seems that for APL – automatic parameter look-up – the rules are a bit different. My guess at this point would be that they are treated as regular variables instead. I personally haven’t found a way to instantiate a class where one parameter starts with an underscore. Thus, I think we can formulate one lesson:

To prevent your class from ever being instantiated by other classes in Puppet with explicit arguments, start at least one class parameter with an underscore.

But, one question remains – why is it actually considered a syntax error? What makes the underscore character forbidden in names of class parameters whereas it works for regular variables?

Now, I’m not an expert in how Puppet parsing but let’s take a short trip down Puppet’s code-base and see what’s happening.

A quick grep of Syntax error at shows that there is some kind of function SYNTAX_ERROR that gets used whenever there is a need to print a message that a syntax error has occurred.

Digging a bit deeper, it seems that there is some kind of parser being generated from a grammar. Other Puppet developers have kindly documented this process for us in docs/parser_work.md. We are finally able to find the grammar in lib/puppet/pops/parser/egrammar.ra.

Valid name of a variable seems to be expressed here in lexer2.rb:

PATTERN_DOLLAR_VAR     = %r{\$(::)?(\w+::)*\w+}

I believe that what is a valid argument passed to a class is defined here:

#---ATTRIBUTE OPERATIONS (Not an expression)
#
attribute_operations
  :                                                { result = [] }
  | attribute_operation                            { result = [val[0]] }
  | attribute_operations COMMA attribute_operation { result = val[0].push(val[2]) }

  # Produces String
  # QUESTION: Why is BOOLEAN valid as an attribute name?
  #
  attribute_name
    : NAME
    | keyword

A valid NAME is defined here in lib/puppet/pops/patterns.rb:

NAME = %r{\A((::)?[a-z]\w*)(::[a-z]\w*)*\z}

So, it seems like the argument’s name is rejected because it does not follow this regular expression even though it is accepted by the lexer. To be fair, Puppet’s documentation also states:

CAUTION: In some cases, names containing unsupported characters might still work. Such cases are bugs and could cease to work at any time. Removal of these bug cases is not limited to major releases.

All in all, it’s probably best to follow the letter of the law laid out in Puppet’s documentation as it says here but if you want to forbid the users of your class to pass arguments explicitly, start one of them with an underscore 🙃.

Related Posts