DEV Community: MN Mark

Terminology and structure of defining record relationships

MN Mark — Mon, 05 Aug 2019 18:24:52 +0000

Looking for some opinions on naming and structure when matching a data entry to another data entry.
Specifically the use case is matching a file to a host, but this same methodology will be applied to other relationships.

A file on disk contains yaml front matter with a separator after which is the contents of the file, very similar to posts here on dev.to. In the front matter I need to list attributes of a Host to match and attributes that should not match as well as define greater/less-than tests. It is important that the naming and structure be understandable and approachable by systems administrators.

Base context

Simplified example without matching criteria, this will be the static context used in all examples:

path: /etc/hosts
mode: 0644
user: root
group: root
---
127.0.0.1 localhost
::1 ip6-localhost

First Option

Now to add criteria to match only Hosts which have a OS.Type of "Linux", and OS.Version greater than 18.00 but not matching a Platform of "prlvm":

path: /etc/hosts
mode: 0644
user: root
group: root
assert:
  - os.type: linux
  - os.version: 18.00+
refute:
  - platform: prlvm
---
127.0.0.1 localhost
::1 ip6-localhost

Here the assert key contains a list of Host attributes and values that must match. The os.version would need special treatment to be compared as a floating-point value even thought it's stored and transmit as a string and the operators + and - would need to be parsed out and evaluated accordingly. I think this is mostly clear and concise from the users' end, but special treatment of values such as os.version could make this nightmarishly complex later down the road.

I also am considering match and except terms in place of assert and refute, respectively, because they might be more intuitive to sysadmins.

Second Option

Another approach is to thin out the abstraction and use a more direct representation of the matches happening in the program. I think this is more accurate at the cost of being more verbose.

path: /etc/hosts
mode: 0644
user: root
group: root
match:
  equal:
    - os.type: linux
  greaterthan:
    - os.version: 18.00
  not:
    - platform: prlvm
---
127.0.0.1 localhost
::1 ip6-locahost

That would produce the same end result but have simpler logic in the application processing it. We could reasonably assume that values submitted under the greaterthan key could be treated as numbers without special parsing. We could more clearly differentiate between equal and contains and even add operators such as startswith. I think this is starting to look like elasticsearch filters which I was never a big fan of, but it does make the backend coding safer and easier and I think more clearly set expectations for the user.

In the last example, match could instead be select or other term.

Ultimately I am trying to make it the most friendly to the sysadmin end user while still being reasonably safe, testable, and not overly complex for the developer.

Update

I am moving forward with the Second Option. I think the benefits of clarity are worth the increased verbosity. While the baseline complexity is more than other options I believe the complexity will not significantly increase with the number and size of records. It also requires more logic in the application but not more complex logic, this should make the program easier to maintain and test.

Pointers in practice

MN Mark — Thu, 04 Apr 2019 21:58:41 +0000

I generally understand what pointers are and how they work. Where I run into trouble is when to use them in my own code.

When I have a struct that I want to create a new instance of, when should I return the instance and when should I return it as a pointer? Say I have a function to get a Session instance in a web app. It either looks up the session from a cookie or creates a new one. In any situation it will always return a valid Session. Should this return Session or *Session? Why?

Now consider a card game that has Card, Deck, and Hand structs. When creating a Hand, a Card is removed from the Deck and put in a Hand. There can only ever be 1 instance of a particular Card, such as 8 of hearts, should Card be passed around as a pointer? Would this be more memory efficient? Is there a concern about garbage collection here? Or can the GC still keep track of memory only being passed as a pointer?

My experience is in languages like Java, Ruby, Lua, Php, if that helps know where I'm coming from.

Failing First / Failing Fast

MN Mark — Wed, 06 Mar 2019 18:29:44 +0000

Failing First and Failing Fast

When writing new code I typically focus on the successful path first, and this seems to almost always result in terrible code. Terrible code on the first pass isn't really a problem, a brain dump into code usually produces bad code, at least for me. The important thing is that the brain dump code gets followed up on one or more times to simplify the logic. Too often those passes are months or even years later.

Example case is validating a Single-Sign-On (SSO) token in a cookie with Lua and Nginx.

My first pass included something like this:

code is simplified for illustration

function check_sso()
  local cookies = ngx.req.get_headers()['Cookie']
  if cookies then
    local token = cookies:match('sso_token=([^; ]+)')
    if token then
      local username = get_username_from_token(token)
      if username then
        if is_member_of(username, GROUP_NAME) then
          return true
        else
          ngx.log(ngx.WARN, username .. ' is not in group ' .. GROUP_NAME)
          return false
        end
      end
    end
  end
end

That follows a simple logic when you read through it, but it's hideous to look at and easy to lose your place in the nesting. The actual code with debug logging and token caching is worse due to the length of the nested blocks.

Consider what it looks like when we handle the failing side of the checks first:

function check_sso()
  local cookies = ngx.req.get_headers()['Cookie']
  if not cookies then
    return false
  end
  local token = cookies:match('sso_token=([^; ]+)')
  if not token then
    return false
  end
  local username = get_username_from_token(token)
  if not username then
    return false
  end
  if is_member_of(username, GROUP_NAME) then
    return true
  else
    ngx.log(ngx.WARN, username .. ' is not in group ' .. GROUP_NAME)
    return false
  end
end

Despite being more lines I find this version simpler and visually easier to read. When I come back to code written like this I find it much easier to modify and troubleshoot. Yet I still struggle to modify my thinking to use this type logic in the first place.

Anyone else have similar trouble with thought process differing from optimal code logic?

Does anyone disagree and think the first example is better or at least no worse than the second?

Returning type-safe & non-nil failure in Crystal?

MN Mark — Mon, 18 Feb 2019 18:37:07 +0000

I am having design doubts in Crystal and would like to hear how others have implemented similar functionality.

The User class has a method to fetch data based on some attribute value and return an instance.

class User
  def self.get_by_login(login : String)
    obj = DB.irrelevant_method(login)
    return obj
  end
end

(I am using superfluous return statements to be more illustrative of intent)

The issue comes in when the database does not find a record to return. I do not want to return a union type such as (User|Nil) or (User|Bool). My idea is to return a User instance to satisfy the return type with the specific error added to an existing errors array I'm already using for validation on the creation side.

class User
  def self.get_by_login(login : String)
    user = User.new
    begin
      user = DB.irrelevant_method(login)
    rescue ex
      user.errors << ex.to_s
    end
    return user
  end
end

This leaves it up to the caller to check if the returned object is valid or has any errors before knowing what to do with it.

Any thoughts or concerns about this approach in Crystal or in general? I've used this pattern before in other languages and it does work, but I've never really felt great about it. I'm curious to hear how others have solved this or similar issues in Crystal or other strongly typed languages.

Go zero values finally hit me

MN Mark — Tue, 12 Feb 2019 20:44:41 +0000

I decided to learn Go (not my first language) by opening the docs and an editor and just Going for it. After 2 weeks and a few hundred lines, I had a functional and useful tool and am mostly enjoying working with Go.

I had seen references to "zero values" here and there but didn't pay much attention. My variable definitions, assignments, flow control, and such were all working as expected so I didn't feel I was missing anything.
Then, suddenly, the idea of a Boolean variable's zero value being false penetrated my willful ignorance and I re-examined my code. What I found were lots of familiar patterns like this:

type Test struct {
    Pass    bool
}


if len(test.Passes) > 0 && len(test.Fails) == 0 {
    test.Pass = true
} else {
    test.Pass = false
}

But if a "zero value" means that simply declaring a variable name and type guarantees it gets initialized with a known value, then test.Pass was already false as soon as it existed. Meaning that all those else branches were redundant.

type Test struct {
    Pass    bool
}


if len(test.Passes) > 0 && len(test.Fails) == 0 {
    test.Pass = true
}

I was able to cut out a large portion of lines and simplify logic just by knowing and using the zero values of all the basic types.

After this I decided to not learn solely by the language specification and bought a book. The Go Programming Language book covers "zero values" within about the first dozen pages. (palm.Smack(&forehead))

The lesson here isn't only that Go's zero values make Go code more succinct, safe, and readable, but... well, I'm pretty sure there is another lesson in here. Maybe someone can spot it and explain it to me? ;)

A better way to handle magic values and constants?

MN Mark — Tue, 19 Jun 2018 17:15:30 +0000

It seems pretty well known that "magic values" in code are a bad idea and should be given descriptive names instead. Instead of this:

throw new Exception("invalid state: 0x02")

it's preferred to define "magic values" as constants:

Integer STATE_OK = 0x01;
Integer STATE_BAD = 0x02;
...
throw new Exception ("invalid state: {STATE_BAD}")

This works well thus far. However, what the user sees in either case is:

$ invalid state: 02

I am thinking of frameworks and tools designed for technical users here, not non-tech end users.

In my actual use case I was able to find the source code and search out the constant name of the value reported to discover the actual problem, but this is rather inconvenient and not always possible like when using closed source tools or the user isn't familiar with the given language.

As a developer I am interested in how this experience can be improved. On the surface it seems string values would be an improvement but that clearly doesn't scale well. Is this just a documentation failure and no better way to deal with it in the code? Ever see a drastically different approach?

Is bubbling scroll events terrible?

MN Mark — Wed, 23 May 2018 15:10:19 +0000

First, as a user, when on a web page that scrolls and contains elements which scroll, I find it terrible behavior to scroll the parent of an element when it has reached it's end. To be clear: a page that is 1000px high with a window that is 700px high will scroll. This page then has an element that is sized to 200px high with 400px of content scrolling inside it. When you place your mouse cursor over the 200px element and scroll, the content in that element will scroll. When you reach the end of that content, and the mouse cursor is still hovering that same element, the page will then begin to scroll.

I find this behavior insane and terrible, am I the odd-ball or outlier on this? Or do others also find this at least irritating or problematic?

Related but not addressed here is the issue of scrolling down a long page and a scrollable element becoming focused by moving under the stationary cursor and then acting on the scrolling event?

Is there just a bigger problem of bad user experience from nested scrolling?

Second; is there a way, maybe with injected javascript from a browser plugin, to change this behavior? Is it possible to find all scrolling elements and prevent them from bubbling the scroll event? (I'm ok with JS, but I'm years out of practice with DOM)