DEV Community: Ryan Burmeister-Morrison

How I Do More by Being Lazy, Impatient, and Over-Confident

Ryan Burmeister-Morrison — Mon, 24 Feb 2020 04:02:58 +0000

Laziness, impatience, and hubris. These are the three virtues of a great programmer written by Larry Wall (the creator of Perl) in his book, "Programming Perl". More specifically, he wrote them as the "Virtues of the Perl Programmer", but they certainly span beyond Perl.

This post is about how being lazy, impatient, and over-confident has improved my efficiency and the quality of my work. More importantly, though, it's about how these virtues allow me to enjoy my job while solving the problems at hand quicker, and how it can do the same for you.

Laziness

I fell in love with programming when I was in high school. I had a fantastic teacher who had more to offer than most college professors I've encountered. I think what made her so effective was that she really focused on teaching the mindset that a programmer should have rather than the syntax of any particular language. One thing that stuck with me more than anything else that she taught was laziness. It's the first of the three virtues of a great programmer. Here's the description of laziness, straight from "Programming Perl":

Laziness sounds like the vice of the same name, but there’s a difference. The vice is about the avoidance of immediate work. The virtue is about the avoidance of future work.

And oh man, did I take that to heart. Laziness has become my core philosophy as a programmer, and it's a key ingredient to doing quality work. After all, it's the job of a programmer to do as much work now as they possibly can to ensure that they will do as little work as they possibly can later. A lazy programmer is a programmer that creates software that scales and source code that's maintainable. A lazy programmer is a magician that makes future problems disappear.

Organization

So many frustrating problems can pop up when working on software. You get bugs, "it worked on my machine" syndrome, and things working when you have no idea how. Hours and hours are spent trying to solve these problems when they could all be prevented in the first place. They all stem from the same problem: a lack of organization.

Take this snippet of a file structure inspired by several projects I've seen before:

.
├── api.go
├── capMon.go
├── health.go
├── kubernetes.go
├── logs/
│   └── output.txt
├── processor.go
├── procMon.go
├── projectBinary
├── send.go
├── sync.go
└── yamlMon.go

All I can say is YIKES.

I'm only kidding, I can say more. I mean what is capMon? Are we playing Pokémon? Where is the main starting point? Turns out the answer is in processor.go, right in the middle of the 1000 line file. What about api.go? That might make sense if it wasn't for the fact that kubernetes.go, health.go, send.go, and sync.go were all part of the API as well. You would never know that without looking through the code, which is buggy and unorganized as well. It's a tar pit - once you get in, you'll struggle, and the more you struggle, the deeper you sink.

There are several other problems with a file structure like this, but I have to stop or I'll go on forever. Months are wasted on code bases like this one, and unfortunately, this is more common than not.

Here's a revised structure for the software:

.
├── api/
│   ├── api.go
│   ├── health.go
│   ├── kubernetes.go
│   ├── send.go
│   └── sync.go
├── cmd/
│   └── program/
│       └── main.go
└── database/
    ├── capability.go
    ├── process.go
    └── yaml.go

The code itself may not be fixed, but even a small change like this can save weeks worth of time, and the best part is that it's not much work at all to do this from the beginning.

This goes beyond software structure, though. I can't count how many times I've tried to help somebody with a problem only to wade through a swamp of scattered files and directories just to find something simple. I get it, we're only human, but the mindset of "I can always fix it later" rarely does anybody any good. Yes, you can fix it later, but it'll be much more of a pain. Once I learned to save myself the pain and do it right from the start, I was surprised with how much time I saved.

Automation

I currently go to an online school, but it wasn't too long ago that I was taking in-person classes on a campus. At that school, I had a particularly terrible class due to a particularly terrible professor. We were made to grade each other's homework, which he claimed was a "learning opportunity", and he had incredibly arbitrary rules that we were required to follow. Par for the course as far as college goes, but his biggest offense was that he had us create his quiz and test questions for him.

We were separated into groups, and every week, for fifteen weeks, each team had to create five multiple choice questions, five short answer questions, and five code snippet questions. Every question we wrote had to be written in a very particular format, and the file's line endings had to be \r\n since it worked in Windows notepad, which he was using. It was a lot of work on top of the work we were already given.

For the first two weeks, we tried to do the work manually. It was a mess. Some of the team was doing work last minute, losing questions, and everybody was forgetting their secondary roles (editing, submitting, etc.). So what did I do to fix the problem? Well, I created an entire website from scratch in two weeks, of course. This is what it looked like:

It was full with an in-built code editor, interactive multiple choice inputs, and progress statistics. Most importantly, it would keep track of who was doing what and format the questions exactly the way the requirements stated. I almost got to the point where the server would automatically email the professor when everybody voted to submit it, but the class ended before I was able to.

The moral of the story is that you won't always be able to prevent frustrating work from presenting itself, as organized and prepared as you may be. Some things will be thrust upon you against you will. But never fret; you can always automate it.

At work, I automate almost everything that takes me over a minute to do and I do often. I no longer set up my machines with my tool set, a script does it for me. I don't deploy my software to a test machine, I have another program that does it for me and live-streams the logs back to me. Automation can be easy, or it can be hard. It can be a simple script, or it can be a complex program. When thinking about automating something, you have to assess how much time it saves you. Will the time to develop the script take longer than it would to do the task manually? Most of the time, you'll find that the answer is no, and you can completely automate those tasks away.

Impatience

This is the second virtue of a great programmer. From the book:

Impatience is that nasty feeling you get when the computer is doing what it wants instead of what you want. Or, more correctly, when the programmer on the other side of the software chose the wrong default settings, made a poor GUI, or doesn’t give you access to this data. You’ve experienced it enough to not inflict the same pain on other programmers, turning your frustration with your wasted time into a benefit for other people.

Any programmer that has had to work with another has faced this problem. It's an innate annoyance of any inefficiency that disrupts the instant gratification we crave. Yet, the problem is common enough that I'm inclined to not believe a programmer who claims they have not dealt with this problem.

But impatience doesn't always apply to working with others. A lot of time time, the one you find most difficult to work with is yourself. This section is about being impatient with yourself, and making it more tolerable for you to work with you.

Using the Right Tools

You shouldn't have to create your own chainsaw from scratch to cut down a tree, yet I see people using vanilla JavaScript to build complex user interfaces instead of a framework all the time. The time and resources that takes to do is ridiculous for the task at hand. Using the right tool for the job can quite literally make you go from taking months to finish a task, to weeks or even days.

The biggest thing that clicked for me was realizing just how inefficiently we write text. Have you ever thought about how much time it takes to copy and paste something with your mouse over and over? Or how long it takes to use the arrow keys to move to another part of your document? All that time adds up, and it's not anything you'd ever notice until you don't do it anymore. And it's all because we use tools designed for ease-of-use, not efficiency. That's fine for the layfolk, but as tech professionals, it's downright unacceptable in my opinion.

This changed for me after I learned Vim. If you're not aware of what Vim is, it's a text editor designed around using shortcuts exclusively. I mean, the mouse is disabled by default. It has a high learning curve, but the amount of time you save yourself in the long-term is unparalleled. After all, most of us write text all day, every day. Take the example of a group of lines that need their prefix changed. Here's how I'd do it in Vim:

What might take the casual copy-paster 15 seconds to do, I've condensed into a maximum of two seconds. Not only that, but it's scalable. While it may not be practical, you can give me 1000 lines and I can do it at the same speed.

Let's look at a more complex example. Say, perhaps, that you have a CSV file full of peoples' names, jobs, and cell phone numbers, and you need to convert it to JSON format. Here's what it looks like in Vim:

That's not something you can do in any other tool I know of. All it needed me to do was teach it how to format the text once (which I didn't include since it takes 15 seconds), and then I simply told it to repeat that work 15 times. I've had to do things similar to this countless times, and each time it comes up, I can't help but appreciate how much time I save. The alternative is to write a whole program that will format it for you, or go line by line and manually copy and paste the text for each one, which is something I see people do a lot.

I focused on Vim a lot here because it's a perfect example of using the right tool for the job, but it's only an example. There are so many things you do on a day to day basis that you're probably using the wrong tool for. As a general rule of thumb: if a task feels like there's a better way to do it than the way you're using, there probably is.

Side Note: Know Your Tools

This might seems self-evident, but even if you are using the right tools, they won't help if you don't know how to use them. I can't count the number of times somebody has told me "I wish tool W did X, Y, and Z", just for me to point out that tool W does, in fact, do X, Y, and Z, if only they read the instructions they'd know about it.

I get it, instructions are boring, but if you are using (and cussing at) a particular tool every day, you ought to know what it does. Take the time to read the five-page manual on what it does. It'll be boring, but it will save you frustration later on.

As a special case, it particularly concerns me how many people are writing software in professional setting when they hardly know the language they're working with; how they download libraries with functionality that is already built into it and incur security risks. There is great value in learning in-depth about a tool such as a programming language that's used to make content for other people. This is a problem that's in more software than you know, and you can find it pretty easily by looking at open-source software on GitHub.

Over-Confidence

Hubris, the last virtue has this description in "Programming Perl":

Hubris is the sense that, with the right tools, you can do just about anything. It’s all a Simple Matter of Programming, right? It’s also the thing that’s likely to make you fly too close to the Sun.

Hubris is the over-confidence a programmer gets from winning and solving problems all the time. It's the yeast that inflates laziness and impatience and makes them relevant. Why be organized if you feel like it won't matter anyway? Why learn your tools if you feel like it won't help? Over-confidence is the thing that makes a programmer move forward even when something seems impossible.

Perhaps it's the hubris in me, but I'm not concerned with flying too close to the sun. In fact, I think it's entirely necessary. Tech is at the forefront of innovation. We are becoming a software-defined world, and somebody needs to test the boundaries. Somebody needs to see how far we can go.

After all that I've learned so far - and I still have a ways to go - anything seems possible. Every problem is simply a matter of difficulty, not possibility, and it's that mindset that drives me to do more; it's that mindset that inspires me to be lazy and impatient so that I can focus on moving forward.

So in conclusion, whether you're young or old, experienced or inexperienced, you should strive to be the laziest, most impatient, most stubborn person you can be. Your co-workers will respect you more for it, and so will you.

Language Review: Gophers Galore!

Ryan Burmeister-Morrison — Thu, 16 Jan 2020 03:57:23 +0000

For a relatively young language, Go's doing pretty well. Other than having the best mascot, it has been used to create several very popular products, such as Docker, Kubernetes, and Ethereum's Geth.

Go's currently my favorite language for several reasons. Let's get to what's good, bad, and meh about Go.

Good: Simple Syntax

Go has only 25 keywords. For context, here's a graph of some of the most popular languages and the number of keywords they have.

That's not a lot! And that's a good thing. There's not much magic in Go. That means that there's less to learn and more clarity by default. There's a post I love by Dave Cheney (a contributor to Golang itself) called "Clear is better than clever". It's a short post about the difference between readability in code and clarity, and the principles of effective Go code. It's well worth the 5 or 10 minutes it takes to read.

The lack of keywords makes it easy for new programmers to get started as well. I often hear about the ease of Python and its clarity. Take the following two snippets to compare them:

# add.py
def add(one, two):
    return one + two

if __name__ == '__main__':
    a = 3
    b = 4
    total = add(a, b)
    print(total)

// add.go
func add(one, two int) int {
    return one + two
}

func main() {
    a := 3
    b := 4
    total := add(a, b)
    fmt.Println(total)
}

To me, the Go code is more clear. That's not born out of familiarity; I've known Python far longer than I've known Go. For the most part, the code feels the same. But the addition of static typing in Go makes it very clear what my parameters must be in order to use add(), and what I should expect back. I can't say the same about Python.

Good: Static Typing and Type Inference

Not everybody likes static typing, and I get it. It can feel like a hassle sometimes. Some things are just so obvious as to what they are that it feels like overkill to have to specify types for every variable, and in a lot of cases, it is! Fortunately, Go has type inference. Look at the following snippet:

func main() {
    a := 1
    b := 4.6
    c := "Hello, world!"
}

In that snippet, a is an int, b is a float64, and c is a string. I didn't have to specify the types, but they're defined. If I were to try to assign the value 3 to c, I'd get a type mismatch error. As a consequence, Go's typing system feels reasonable; the obvious stuff is taken care of for you, and the not-so-obvious stuff asks you to define the types. Surely that's not too much to ask to make your code easier to decode, right?

Good: Detailed Documentation

Go has some very good documentation written by the official team. You can find it all in one location, and it's split up nicely. If you want an interactive taste of the language without committing fully, take the tour. If you like what you saw in the tour, look at How to Write Go Code. If you really like Go, read the Effective Go document. It's all organized pretty well and well-written in my opinion.

Good: Easy Documentation Tools

Go puts a lot of emphasis on code documentation. If you use a tool like golint which reports problems with your code style, you'll get several warnings if you don't add comments to exported functions. It might be annoying at first, but Go makes it easy to document your code properly and can generate a nice HTML document that maps out your code. It certainly helps that Go is statically typed, as it takes care of type definitions for you. All you need to do is add a short comment above the function you want to document, like so:

// Add returns the result of adding one and two.
func Add(one, two int) int {
    return one + two
}

Of course, that's a simple and impractical example, but it really helps for large projects. If you want to see an example of what the generate documentation might look like, check out a package from Go's standard library: https://golang.org/pkg/os/. Fair warning, it does get a little getting used to, but once you are, it's very nice.

Good: A Large and Useful Standard Library

I've written a lot of projects in Go, and in most of them, I only need one or two third-party dependencies max. Compare that to NodeJS, where you typically need 20-30 for regular-sized projects minimum. To me, that really speaks to the utility of Go's standard library and what's possible with it.

I've written many servers and microservices in Go using only its standard library. Here's an interactive basic server implementation:

There's a lot of power in that little bit of code that isn't nearly as easy with the standard libraries of any other language I know. That's just a taste of all that Go's standard library can do. You can check out all the packages it has here: https://golang.org/pkg/.

Good: Verbose Error Handling

Here's some code to open a file named temp.txt for writing in Go:

func main() {
    file, err := os.OpenFile("temp.txt", os.O_WRONLY|os.O_CREATE, 0755)
    if err != nil {
        fmt.Fprintln(os.Stderr, "There was an error opening your file")
        os.Exit(1)
    }
    defer file.Close()
}

A lot of people I've known that use Go can't stand this level of verbosity. In Go, functions return errors like that all the time, and you have to manually check if the error is nil or not (to determine whether an error actually occurred). I get it; it does seem very verbose, particularly when compared to other languages.

I'd like to make a counter-argument, however. In other languages like Python and Java, if you're doing it right, your error handling will be just as verbose. Here's Python's equivalent code:

if __name__ == '__main__':
    try:
        file = open('temp.txt', 'w')
    except:
        eprint("There was an error opening your file")
        exit(1)
    finally:
        file.close()

To me, Go is the winner again.

Meh: Package Management

Go's package management has traditionally been very messy. Originally, packages were pulled straight from places like GitHub and had no versions. Each time you needed to download new dependencies, they'd pull the newest commit from the repo's master branch by default, which had the possibility of breaking your codebase. To combat it, projects would vendor their dependencies, meaning they would be re-downloaded and placed in a special vendor/ folder in your project's root. This made the codebase large and hard to keep up with.

More recently, since Go v1.11, modules have been implemented. They still feel a bit wonky, but everything has versions, and the dependencies are managed automatically. It's also very easy to migrate old projects to the new module system, as it only needs to add one configuration file, go.mod. It still needs work, but it's improving for sure.

Bad: No Generics, Overloading, or Default Parameters

When trying to get into Go's advanced concepts, or when trying to build large projects, Go can feel really inflexible. To an extent, that's part of its design, but it really hurts when you need to create a custom data structure and you have to do a lot of extra work to get it working properly. Here's a (very) minimal stack implementation in Go:

type Stack struct {
    Position int
    Items []interface{}
}

func NewStack() Stack {
    return Stack{
        Position: 0,
        Items: []interface{}{},
    }
}

func (s *Stack) Push(item interface{}) {
    s.Position++
    s.Items = append(s.Items, item)
}

func (s *Stack) Pop() interface{} {
    s.Position--

    item := s.Items[len(s.Items)-1]
    s.Items = s.Items[:len(s.Items)-1]
    return item
}

func main() {
    stack := NewStack()
    stack.Push(3)
    stack.Push(5)

    fmt.Println(stack.Pop())
    fmt.Println(stack.Pop())
}

This will work as expected, but for a language that prides itself in clear and readable code, all of the interface{} types (which match any type in Go) are hard to look at. The only other option is to create a separate Stack for each type, which is a problem because Go doesn't support overloading either! As a consequence, you'd have to name each one as StackString, StackInt, StackFloat64, and so on, and that's pretty darn WET.

In a lot of cases when you have interface{} declarations everywhere, you end up having to do a lot of manual type assertions to verify that you're working with the proper type. It's just plain frustrating when you have to deal with it.

Conclusion

Go really shines when working within a team. It is easy to learn while still enforcing well-defined standards that maintain clarity. Learning new languages can sometimes feel like a curse after learning Go due to its ease and utility. Most of the co-workers I work with daily have converted to Go as their primary language. I could go on and on about other things that I like about Go, such as its speed and portability, but I have to stop somewhere.

I hope it's obvious that the "Good", "Bad", and "Meh" labels are my opinion; I'm not trying to pass those off as fact. If you disagree with anything, let me know! I'd enjoy discussing it. And if you noticed that I said anything that is objectively wrong, post a comment! I'm open to having my mind changed.

If you're interested in learning Go, leave a commment! I have some resources that have worked well for both myself, co-workers, and people who have never programmed before.

Thanks for reading!

Language Review: Yikes! A Python!

Ryan Burmeister-Morrison — Wed, 15 Jan 2020 04:06:30 +0000

It's no doubt that Python is popular, but to me, it's too similar to the snake it shares a name with; cool to look at, but too unreliable to handle.

Of course, there are exceptions to every rule, and some people are great at writing in Python. Take the team that created Ansible, for example. Its code is well-organized and readable. Clearly, they have a set of defined standards that they follow. The way they use Python as a language is fantastic too. They take advantage of the fact that Python is deployed on most Linux systems to make Ansible agentless. If you're unsure of what that means, you should check out my Theoretically: Ansible post, but just know it's pretty cool!

Alright, enough complementing Ansible. Let's get to the points.

Good: Easy to Get Started With

A lot of people are learning Python as their first language, and it's understandable. For one, it doesn't have all the symbols that other languages have. Look at the following two snippets from C++ and Python, respectively.

// age.cpp
int age = 18;

if (age >= 18) {
    std::cout << "Welcome!" << std::endl;
} else {
    std::cout << "Sorry, you must be at least 18 to enter." << std::endl;
}

# age.py
age = 18

if age >= 18:
    print("Welcome!")
else:
    print("Sorry, you must be at least 18 to enter.")

It's obvious, but the C++ snippet is more verbose in several ways. For new programmers, it's just too much too fast.

Another thing that makes Python easier to work with is the abstraction of pointers. In my experience, pointers are the hardest learning point for new programmers. In Python, everything is pass-by-reference, meaning that you can get around pointers. No need to worry about making references and dereferencing.

Good: Healthy Standard Library

Python's standard library clearly ate its veggies as a kid, and that's great. It means that out of the box, you can do a lot with it. Anything from cryptography, to drawing in the terminal, to GUI applications, to database interfacing is at your fingertips, and that's something I love to see in a language.

If you use Python a lot, seriously look into what's available. You may not need as many third-party packages as you think you do.

Good: Strong Community

Because Python's so popular, its community is huge. You can find a library to do just about anything. Here are the statistics for PyPi as of writing this:

That's pretty good! They're not as high as something like Maven or NPM, but that can be a good thing. It means there's a lot less clutter to filter through when dealing with dependencies, but there are also enough options to look at.

Meh: Slowness

"But machine learning is done with Python all the time! It must be fast!", I hear you say. That's actually false. Python wrappers are created that call compiled C libraries in the background, and the majority of the work is done in C. Python is really, really slow. I recently found a machine learning library written in pure Python that takes 3-4 days to finish! If that were written in something like C, it would take less than an hour. If you want metrics, check out either of the below resources. Whether you trust them or not is up to you, but the code is available to inspect for yourself.

The reason this is only listed as "Meh" is because, in most modern applications, speed doesn't really matter. Most software tends to be "good enough", and if you need to do something fast, you can always write the C code to interface with it. But you're certainly not going to write a fast system monitor in pure Python.

Meh: Everything's Public

There's no access control in Python. Have a utility function that's only going to be used in your package? It doesn't matter, anybody can access it anyway. If you don't think this is a problem, you're probably not considering the documentation that will be generated for your code. For other developers that want to work with what you make, it won't be immediately clear what you intend for them to use as opposed to what you wrote for internal use only. You can get around this by using an underscore (_) as a prefix to a private function like this:

def _my_helper():
    # do something
    pass

def my_worker():
    # do something
    _my_helper()

This is only a "Meh" because if you can make sure that everybody follows this simple rule, you can get around a lot of the issues that everything being public causes.

Bad: Dynamic Typing

Dynamic typing is another selling point for new developers. Why wouldn't it be? There's no need to worry about the extra overhead of variable types. When you assign a number to a variable, the variable contains a number. It's as simple as that. Here's another C++ vs. Python example:

// add.cpp
int addOne(int num) {
    return num + 1;
}

int main() {
    int n = 0;
    n = addone(n);
    std::cout << n << std::endl; // => 1

    return 0;
}

# add.py
def addOne(num):
    return num + 1

def main():
    n = 0
    n = addOne(n)
    print(n) # => 1

If you're a fan of that, I get it. And when working on your own project that's just for you, it's fine. But when you want to work with other people, it's very frustrating. What's to stop me from doing this?

# add.py
def addOne(num):
    return num + 1

def main():
    n = 0
    n = addOne("hello") # adding a string
    print(n) # => ERROR

Absolutely nothing. There's no getting around the fact that, because of dynamic typing, anybody can pass anything to that function. If I were to try that with C++, I'd know that I made a mistake before the program even ran. There's are tons of subtle errors that occur from accidentally using the wrong types in the wrong places; problems that would be solved with static typing.

So how do you get around it? Documentation. You're expected to write good enough documentation to let users know what they should expect to work with your code. Let's re-write the function to include some.

# add.py
def addOne(num):
    """
    Add 1 to 'num'.

    @type int
    @param The number to add 1 to

    @return The result of adding 1 to 'num'
    """
    return num + 1

Okay, so we've documented it, and it's clear what should be expected now, right? Well, sure. At the same time, though, you had to do a lot more work than just adding the keyword int like you could have done in C++, which takes care of what you needed the documentation for in the first place. The other problem is that you just can't trust most developers. Most developers just won't bother writing documentation like that, and Python won't force them to. Static typing will, though. At the very least, even if a developer is bad at documenting, you'll know what the parameters need to be, and what you'll get back from it.

Bad: Poor Default Documentation Tools

Okay, okay. So you're willing to write the documentation for your code, and you want to do it right. Good! But also, good luck. Python's documentation tools are just about the worst I've seen in any language I've worked with. Python's default documentation tool is PyDoc, and here's an example of what its output looks like, generated from the official sys package of the standard library.

I'm not going to bother discussing how ugly it is, because it's beside the point, but it's just so barebones. There are links to the functions and all, but that's about it. Let's compare that to Ruby's yard gem.

To me, the difference is night and day. Ruby has dynamic typing as well, but the documentation tools are so good, with support like official typing notation and a side navbar tree, that it makes it so much easier to work with. That's a big deal when working with other people.

To be clear, there may very well be better documentation tools for Python out there; in fact, I'm sure there are. But Python's default tools are what most people are going to use, and if the default tools are bad, the documentation is likely to be as well.

Edit [1/15/20]: I recently played around with Doxygen, which was a lot better than the built-in tools, and can get the job done to a decent extent. Still, due to the dynamic typing, it's a lot more work than it would be with static typing.

Bad: Poor Dependency Management

I'm not a fan of the way Python handles dependencies at all. For whatever reason, "wheel files" were created, which is a format for Python dependencies. The problem with them is that they are sometimes tied to specific architectures or Python versions. For example, if I download a wheel file for Python 3.7, and you have Python 3.5, oh well, you can't use it! I get version compatibility, but this goes beyond that. You must have the exact specifications to install certain wheel files. For people working in an offline environment, this is very frustrating. They can't simply keep a folder of the dependencies they need for their offline machine since they could easily be useless if they update my Python version.

The other option is to download the archived source code, and that tends to work pretty well. It doesn't require specific versions of Python or architectures. It works well enough that you may wonder why wheel files exist. From my perspective, it feels like somebody said: "Ya know, archived source files work great, but why don't we make it harder for the developers to work with dependencies instead?" Maybe I'm missing something, but no other language that I've dealt with has that problem.

But what am I complaining about if I can just use the tar files, then? Well, it turns out that some package developers just don't offer them. Of course, you can always go to the GitHub repos where the source is, but you then run into issues with different directory structures and a lack of official releases like PyPi has.

Bad: Not Very Portable

Python is not alone in this problem since it's mostly just a problem with interpreted languages in general. The issue is that when you want to send your Python code to anybody else to use, it takes a few steps.

For example, if you used any third-party dependencies, the other person will have to download them themselves too. You're not going to make something in Python and have your computer-illiterate friend use it like you would be able to do in a compiled language.

Portability is a particular problem for folks in offline environments, where every dependency change and deployment is a huge deal. It'd be much more convenient to have the dependencies bundled with each other, which is possible through a process called "freezing", but I've had tough luck with freezing Python code in more cases then I care to talk about, where it either required internet connectivity where I had none, or the resulting executable just doesn't work.

Conclusion

There was a time when I loved Python. When was that time? It was when I only knew C++. Of course Python's going to look great if that's the only language you know. It was easy, and it did the work for you. But in a real, practical, everyday environment, it just doesn't fly for me. There are just too many better options for languages to start with that fix the problems Python has.

Thanks for reading!

5 Reasons Why Nim Is Becoming My Favorite Language

Ryan Burmeister-Morrison — Wed, 08 Jan 2020 03:04:59 +0000

If you haven't heard of Nim yet, you're in the majority. It's a very young language that only hit version 1.0.0 late last year. I've been looking at it for a while, however, and with its v1.0.0 milestone, I decided to give it a try. Here are 5 reasons why it might take the place of my favorite language.

1. It's Fully Compiled

The difference between a compiled and an interpreted language can be a thin line. Take Java, for example, in which the code is compiled to bytecode that is then interpreted by the JVM. Nim has no such confusion; it's a fully compiled language with no gimmicks. That makes software that's created in Nim faster and more portable than if it were interpreted. If you want performance metrics, check out this benchmarking repo: https://github.com/kostya/benchmarks.

2. It's "Pythonic"

There's no doubt that Python is incredibly popular right now. Just take a look at its Tiobe index:

I hear people talk about Python's easy syntax and the ability to prototype quickly with it. If you're one of those people: good news! Python is one of Nim's main inspirations, and it shares a lot of the same syntax. Take a look at the following two snippets.

Python:

# conditional.py

num = 30

if num > 10:
  print("More than 10!")
else:
  print("Less than 10!")

Nim:

# conditional.nim

let num = 30

if num > 10:
  echo("More than 10!")
else:
  echo("Less than 10!")

Not bad, huh? If you have experience with Python, you'll get Nim's basics quickly. There's also a great resource for Python developers that shows the conversions from Python concepts to Nim concepts. You can find that here: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers.

3. Cross-Platform GUIs

Nowadays, if you want to create a cross-platform GUI, you don't have a whole lot of options. They are: Electron, C libraries like (https://wxwidgets.org/) and QT, Java Swing or JavaFX. Because Nim is built on C and it can use its libraries, it makes using its UI libraries that much easier. Even in Nim's standard library, there's a wrapper for the IUP toolkit, which provides an easy way to create native, cross-platform applications like this:

The Nim team is also working on a separate UI package for the standard library based off of libui. Combined with the several other third-party libraries availaible on https://nimble.directory/, you have options! People are already doing cool things in Nim, like making a NES emulator!

4. A Great Package Manager (Nimble)

The fun name aside, Nimble does its job well. One of the first things you'll notice about it is the automation that it provides. When initializing a new Nimble application, it will walk users through about 6 quick questions needed to set everything up. Past that, you can just start coding! It makes posting packages to https://nimble.directory/ for the world to see easy and makes your project's dependencies consistent.

5. It Has a Macro System (Metaprogramming)

If you're not familiar with metaprogramming, it can be boiled down to "code that reads and writes code". This means that the code you're writing can manipulate itself and write complex, tedious bits of other code for you that you would otherwise have to do manually. This may seem confusing at first but what if you wanted to create a function called debugPrint that does this:

debugPrint(3 + 3) # output: 3 + 3 => 6
debugPrint(pow(2, 2)) # output: pow(2, 2) => 4

If you can do this without metaprogramming, I'd be thoroughly impressed. In fact, as far as I'm aware, it can't be done. However, if you have a macro system, you can have those lines write themselves. Here's what debugPrint would look like as a Nim macro:

macro debugPrint(expression: untyped): untyped =
  let prefix = newLit(expression.repr & " => ")
  result = quote do:
    echo(`prefix`, `expression`)

Don't get hung up on the syntax. Nim has some good resources to learn how its macro system works, and it's an advanced concept anyway. What you might want to know is that with this macro, the previous example's code gets converted to the following:

# conditional.nim

echo("3 + 3 => ", 3 + 3)
echo("pow(2, 2) => ", pow(2, 2))

Even if you don't ever see yourself using macros, it allows other package developers to create them for you, making your life easier. Take this shell package, for example, which allows you to write shell commands directly in your source code, which then get converted to the appropriate Nim syntax automagically.

Final Thoughts

Look, I could keep going on about Nim's features. Things like easy C interop, Python bridges, machine learning, multiple paradigms, a sub-scripting language and the possibility for game engines get me excited, but I have to stop somewhere! If you're interested in checking out Nim, look at their official tutorial. And if you have any questions, leave them in the comments.

Good luck!

Summary: Ansible

Ryan Burmeister-Morrison — Mon, 06 Jan 2020 23:17:01 +0000

Welcome to Summary, a series where I summarize a concept or tool for you so you can understand your coworkers when they talk about it. In this post, I cover Ansible: a smooth, powerful, and versatile automation tool.

Concept

Ansible shines brightest in two fields. The first is configuration management, which is the idea of keeping the configuration between a cluster of computing devices consistent and predictable. The other is automatic deployment, which is the process of automatically and continuously deploying software to a target machine or machines, usually for testing or demonstrations. Your idea of Ansible should not be limited by these fields, however, as it is capable of much more.

To manage any number of nodes (computational devices), Ansible requires a master node. A master node is a machine that has access to all other nodes and is where Ansible itself resides.

The master node must be running Linux; however, child nodes can run either Windows or Linux. Apart from installing Ansible on the master node, child nodes must have SSH and any recent version of Python. SSH is the mechanism that the Ansible master uses to remotely access child nodes, while Python is what it used to perform any tasks. Because of the use of both these tools, Ansible is agentless, meaning that no additional Ansible-specific software is required to exist on child nodes.

Inventory

Ansible isn't magic and doesn't know what its child nodes are until you configure it yourself. The inventory file is what Ansible provides to you to set them. It exists at /etc/ansible/hosts and accepts either the INI or YAML formats. Here's an example of what one might look like (YAML):

all:
  children:
    devgroup:
      hosts:
        10.0.0.133:
        10.0.0.209:
        10.0.0.103:
    demogroup:
      hosts:
        10.0.0.182:
        10.0.0.114:
        10.0.0.235:

There is a root level "all" group that can have any number of child groups. Child groups can also recursively have children and can share nodes. Inventory allows for a high level of control and organization for your infrastructure that most small-scale environments may never need but is available nonetheless.

When trying to perform any task in Ansible, you will need to provide the group of child nodes you would like to perform it on. It's important to note that if you improperly configure the inventory file, it is difficult to tell since Ansible isn't very straightforward with its error messages about it. Make sure to double-check your formatting after editing!

For any host listed in your inventory file, Ansible expects that you have already set it up. As I mentioned before, each child of the master must have SSH and Python. Further, the SSH access to the child from the master must be passwordless through a tool such as ssh-copy-id. If you can manually access the target machine with SSH without a password, so can Ansible.

Modules

Ansible is designed to be easy for both beginners and professionals to use, and to accomplish this, the Ansible team created modules. Modules are at the core of Ansible and are the basic building block for any action. They are pre-defined functionality for almost any automation task that you can fathom. There are modules for networking, cryptography, databases, files, and a ton more. There are many, and it would be more than impractical for me to list them all here. If you want to see a list of all of the modules provided by Ansible, click this link.

Modules are designed to be idempotent when possible. That means if you run the same module multiple times in a row, the module will only do its job once. For example, if you try to transfer a file that already exists on a target, nothing will happen. This philosophy saves Ansible from being inefficient and allows you to be more liberal in terms of what modules you run. If you want to transfer a file to a group of nodes in which some already contain it, it doesn't hurt to run the module to make sure; Ansible will only perform the task for the nodes that don't.

For small tasks like sending a file or restarting a service across a group of nodes, it is possible to run modules in isolation. To do this, you can run the ansible command itself, specifying the inventory group, username on the machines (it must be shared amongst them all), and the module to run. For example, the "Hello World" of Ansible is to ping every child node to ensure the master can contact them with ansible all -u username -m ping. In most situations, however, modules need to run in groups.

Playbooks

In a typical environment, when multiple modules must run in succession to accomplish a more significant overall task, playbooks can be leveraged. Ansible requires users to write playbooks in YAML, and the file can be stored anywhere. A playbook must contain the target group from the Ansible inventory file, the username to use for all the machines, and a sequential list of modules to run called the task list. Here's an example playbook to install the "tmux" and "neovim" packages with apt:

---
- hosts: demogroup
  remote_user: username
  tasks:
    - name: Ensure tmux is installed
      apt:
        name: tmux
        state: present
    - name: Ensure neovim is installed
      apt:
        name: neovim
        state: present

Ansible detects a lot of information about the target nodes, including what operating system they are running, and even what Linux distro it has if it's a Linux machine. Ansible stores these values in variables called "facts" that are available in playbooks. It's possible to use these variables to run tasks on nodes that require different tools selectively. For example, it's possible to use apt for Debian systems and dnf/yum for RedHat systems.

The ansible-playbook command is available to run an Ansible playbook. A playbook is executed by running ansible-playbook X, where X is the path of the playbook to run.

Roles

Roles are a way to sequentially group a group of tasks that are reusable between multiple playbooks. Take compiling software from scratch, for example. Software compilation takes several steps. It requires the transfer of many files to the target machine, the installation of several packages, and several other commands to perform their tasks. Multiple, unrelated playbooks may require the compiled software, and re-writing the tasks for each playbook would be inefficient. Instead, the tasks specific to the compilation can be separated and imported by each playbook that requires them.

Roles require a concrete file structure to work, and they get into advanced Ansible. However, anybody that uses Ansible regularly should also be using roles.

Resources

To learn Ansible, I would suggest looking at the official documentation, as it's well-written. The "Getting Started" guide is an excellent place to start. Below are the concepts covered in this post, and the documentation links for them:

Inventory: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#intro-inventory
Modules: https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
Playbooks: https://docs.ansible.com/ansible/latest/user_guide/playbooks.html#working-with-playbooks
Roles: https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html
Best Practices:: https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html