VLANs with pfSense, Unifi, and VMware ESXi

For setting up VLANs in my home network I basically followed the tutorial from Crosstalk Solution on YouTube:

The result, however, was not working as expected. As it turned out the critical difference was that I have my pfSense firewall running virtualized on VMware ESXi 6.5. By default the latter “removes” VLAN tags.

But it is very easy to change this and not even a reboot is required. So here are the steps you need to perform:

  • Log in to the admin web UI of ESXi
  • Go to the network port groups and open your internal network
  • Open settings for internal network
  • Change VLAN to 4095
  • Save change

That’s all 🙂

Larry McEnerney: The Craft of Writing Effectively

Mr McEnerney presents a really good “strategic” approach to writing in a professional context. On the one hand nothing really new, but the way it is presented and details being put into context, make this a wonderful framework for me.

In particular it became even clearer to me why knowing a lot about a subject often makes it more difficult to write about it or discuss things with non-subject-matter-experts. This is also described nicely in the course description for professionals.

And finally I want to direct your attention to this nice blog post about a personal encounter with Larry McEnerney.

pfSense Upgrade to 2.4.4 p1

Just a few short lines to let you know that for me the upgrade from plain 2.4.4 to p1 went really smooth.

I have the following plugins installed:

  • bandwidthd (0.7.4_1)
  • iftop (0.17_2)
  • net-snmp (0.1.5_2)
  • ntopng (0.8.13_3)
  • Open-VM-Tools (10.1.0,1)
  • suricata (4.0.13_11)

All plugins had been updated some time ago and thus prior to the pfSense core, which is not recommended. In my case, though, it did not cause any issues. This was a pleasant difference to the upgrade from 2.4.3 to 2.4.4 (also see this video on YouTube), where the fact that plugins had been installed was cause for a completely broken system after the upgrade.

It’s Not Beautifying but Reduction of Complexity

I am writing this on a Saturday afternoon after having spent several hours going over Java code that is about a year old,  needed only occasionally, and has not caused issues for quite a while. Still I spent personal time to improve or, shame on me, even add the Javdocs. Also, some additional error checks were added and the code structure simplified.

None of this had been asked for by anyone else. And probably quite a few people would call it a terrible waste time, given the various new features still needed so badly. So why did I do it?

It was an experiment, a successful one  from where I stand. In the beginning I merely wanted to see in how many ways the code could be improved with sufficient time gone by after the initial writing. I ended up doing the following things:

  • Renamed class ServiceWrapper to ServiceWrapperManager, because the class is not an actual wrapper but creates and deletes them.
  • Renamed variable adapterServiceNode to node, because via a wrong user input it could point to a node object of a different type and not an adapter service. (The same was done in two other cases.)
  • Added multiple checks that would throw an IllegalArgumentException, if the user had provided wrong input. So rather than having to wonder why the creation of a wrapper had failed, I would be “shouted” at early in the process.
  • Added and improved multiple Javadoc entries. This, in turn, made me look at the code more closely where I discovered multiple things to improve or even fix.

When I look at the code now, it is cleaner, more robust, and easier to read. And the latter is the most important aspect on my case, because it reduces technical debt. So here you have your argument.

And for business people this means that I “keep my head above water level”. Or in other words: It is an absolute prerequisite for fast time-to-market that my code base is tidy and well-structured. Only then can I react quickly and change things without having to think hours what might break in other places, should I now add this or that new feature.

Ten Years of Blogging

It is still a somewhat strange feeling that I have been running this blog for a bit more than ten years now. There were phases when I posted pictures from my (job) travels and others when I focused more on genuine content. The latter is mostly about software engineering and management. This may seem like an odd mixture, but it pretty much reflects my interests as well as professional development.

Another type of posts are just links to videos that I find interesting or amusing. These “articles” have the nice side-effect to not require too much time to write ;-). I had discovered YouTube as source of non-trivial content rather late and all the more fascinated I still am with some of it. Two channels stick out in particular for me: GOTO Conferences and TED.

During the second half of 2018 I had to slow down my blogging activities quite a bit due to family commitments. But I will try to slowly increase the pace again. After all, there is a lot of things that I would like to write about. This helps me to become clearer on the topic at hand, because a consistent story line requires a lot more thinking than a few (mental) bullet points.

So I am looking forward for the next ten years :-).

Job Interview Question: What is Your Favorite Algorithm?

While watching the video below, I was intrigued, when this interview questions was discussed (timestamp 56:30-57:35).

It made me think about my response, had I ever been asked the same. And it did not take too long before the answer was clear: the B-Tree. There is a very good section on it in Martin Kleppmann‘s book “Designing Data-Intensive Applications“. And I highly recommend this book anyway.

But as a starting point on B-Trees the following video is also quite helpful:

Structure of Development Teams

I just came across another interesting statement about the size of development teams:

The good systems that are presently working were written by small groups. More than twenty programmers working on a project is usually disastrous.
 

What makes this so interesting is its origin. It was said in 1968 during the famous NATO Conference on Software Engineering. Fifty years later I think this is still remarkably true. But why?

In my post on the size of development teams I was aiming at complexity and scope as drivers. The interesting question, though, is whether there are additional points to consider. Having worked pretty closely with some other projects in the meantime, I came across another influencing factor: availability of qualified staff.

You can look at this in several ways. The first hurdle is obviously to have enough developers with the required experience at your disposal. The second is how to allocate their capacity to the portfolio of activities you run. Or put differently: How do you deal with the shortage of know-how you face? Because, let’s be honest, there is always more demand for highly skilled developers than can be supplied. (I am having a déjà vu with my “beloved” macro economics lecture 😉 back in 1996.)

If your organization is above a certain size, chances are that overall a sufficient numbers of good people work there. Does that put you in a better position than some poor fellow working for a small company? Not really. Because your project competes for these folks with all the other work within the organization. And what is the difference compared to competition with an external market? Yes, if you have really good connections to higher management, you can escalate things and possibly get additional people. But you will also burn bridges in the process, which is usually too high a price.

So instead you probably end up with the usual mix of folks: Very few rock stars, many middle-of-the-road folks, some promising newbies, and the occasional looser that nobody wants. Can you deliver something really great with such a mix? It will be difficult in a typical corporate setup where you have to somehow involve everybody. And this involvement of the less qualified half of people will slow down the “upper” half.

It is a very delicate subject and there are many fine lines, some from a legal perspective and many more from decency-to-others point of view. Also, the organization needs to think about tomorrow and therefore must have a “funnel” of to-be-rockstars, which need the best training they can get. And the latter is always working on a difficult project with experts and learn from them. But what few organizations do, is look at competence levels in detail and factor them in.

In other words: You can learn a lot from someone who is one, two, or perhaps three levels above you. But if someone is ten years ahead of what you currently know, the difference is just too big. You will only grasp a small fraction of what they teach you, and even that with a considerable risk of misunderstandings. And they honestly cannot understand why you are not following their great advice. Mutual frustration and dislike are usually the result.

Whether you take competence levels into account or not, considerable effort needs to be spent on non-development activities. If you have a taste for management and leading people that will be a great opportunity for you. But if your primary concern is getting something great and possibly visionary delivered, you should seriously consider a totally different approach: an underground project.

Flying under the radar can really be liberating. This must not be confused with idling around or working on some obscure pet project. It is truly about delivering what the organization needs but cannot accommodate in its own structure. Of course you should be certain that your boss will not fire you, if he or she finds out. But as you probably already guessed, driving an underground project does not mean that you are freed from politics, lobbying etc. On the contrary! You must prepare upfront quite carefully how you counter resistance or outright attacks. And yes, you are running a personal risk. But there is no reward without risk.