Troubleshooting UI Policies

My last post covered some of the issues I’ve had to troubleshoot with variables lately, but didn’t cover the strategy for doing so.

When troubleshooting UI Policies, often the best thing to do is simply to deactivate all of the policies and then turn them on one at a time until you see the behavior that you’re trying to stop.

Sometimes, depending on what you’re seeing, turning them off one at a time until you see a particular behavior start or stop is the way to go.

Really, when bug hunting, it’s always best to look for strategies that allow you to pin the bug down to a specific section of code. Generally, if you don’t find the bug right away, then it relates to something that you either don’t understand well, or which you understand incorrectly. By eliminating big chunks of code, you reduce what you have to look at to something that is much more manageable.

That drastically improves your odds of figuring out what is driving the bug. It’s a strategy that I’ve learned, forgotten, and then relearned again. I tend to use it instinctively until I run into a new tool, application, or technology. Then, for some reason, I seem to forget to bring the principles with me that worked so well with previous tools and technologies.

A big hat tip to my coworkers Kim and Tatiana for reminding me the right way to go about debugging something. Hopefully it sticks for the next novel situation I find myself in.

ServiceNow Variables

I’ve been working a lot with variables lately. Here are some things that I’ve learned that either weren’t in my classes up to this point, or which didn’t stick for me when my classes covered them.

1. If a variable is refusing to be hidden, check to see if it is mandatory. I can’t say categorically that mandatory variables can’t be hidden, but I’ve definitely seen instances where a variable refused to hide until after it was no longer mandatory.

2. If you have something that isn’t behaving the way you are expecting it too, check that you don’t have a container that isn’t closed out. That can cause behavior that has been applied to the container to apply to variables that you don’t realize are part of the container.

2a. It’s implied by 2. above, but worth being called out specifically. I’m used to more specific rules trumping more general rules. That isn’t how containers and variables work. Instead, the less specific (UI Policies applied to a container) trumps the more specific (UI Policies applied to the variables inside of the container). If you make a container mandatory, you can’t set one of the variables inside the container to not be mandatory. You would have to set the container to be non-mandatory, and then individually set the other variables mandatory.

 

They Need To Feel The Pain

By nature, I don’t like to be mean to people, or make someone feel bad. That predisposes me not to write blog posts that call someone out on something that they are doing wrong.

That being said, there are some things (actions or behaviors) that need to be described so that others can avoid making mistakes that could cause serious harm to their careers.

In a past position I witnessed a terrible dynamic between a founder and their development manager. The founder would go to the development manager with a feature request. The development manager would agree that the feature was a good one, but would raise concerns and highlight problems with the founder’s desired method of implementing the feature.

They would go back and forth for a while, and then the founder would say something to the effect of “I’m the boss, this is my company, do it my way”.

Which is of course the founder’s prerogative even if it’s the wrong decision.

The development manager would go off and build, or have built, the feature using the founder’s methodology. Subsequent to the feature going live, the very problems that the development manager had warned about would begin to surface, and the product would begin to suffer.

I’m not privy to the full history between the development manager and founder. I have some suspicions as to the cause of this dynamic, but I don’t know for sure what led to the subsequent behavior. In my opinion, the correct action to take would be to go back to the founder and say something like:

“We’re seeing problem ‘x’, which is the result of the decision to do ‘y’ while designing this feature. What do you want us to do next?”

or maybe:

“The system is breaking down because of ‘q’. I think we need to do ‘r’.”

Rather than doing that, the development manager would confirm to themselves that the problem was arising because of the issues that they had warned the founder about, and then the development manager would go off and ‘fix’ the code by stripping out the founder’s design and coding it the way that the development manager had wanted to write it all along.

The pros to that course of action:

The development manager avoided a fight with the founder.

The technical problems were solved.

The cons:

The founder became convinced that he could ignore the advice of the development manager who was the actual domain expert when it came to developing software. Rather than making a decision to over-ride the domain expert and then feeling the pain from making a bad decision, the founder became convinced that there was no need to listen to subordinates who disagreed with the founder.

In effect, the founder was always right and everyone else was always wrong. The founder would be cautioned against something, do it, and then as nearly as the founder could tell there were never any consequences for having ignored the domain experts in the company.

The issues that the domain experts cautioned the founder about never materialized, which meant that the founder either had to lose faith in the domain experts, assume that the founder was somehow infallible, or some do some combination of the two.

Secondary effects of this decision by the development manager included:

Lengthened development cycles (things were essentially being built twice).

Insufficient focus on technical debt (other problems that the founder had been warned against never materialized, therefore there was no reason to worry about big data problems or other technical debt).

My takeaway from watching this dynamic over an extended period of time is that you should always let people–especially people above you–feel the pain of their decisions.

I think that human beings who are drawing a paycheck have a moral obligation to warn our managers when we see a decision being made that will have negative consequences. How far you go on something like that is a judgement call based on your personal circumstances. The companies that most need someone to stand up and take a strong position against a bad decision are usually the companies that will make an employee suffer the worst consequences for taking that kind of position.

Depending on your role, seniority, and the consequences of the bad decisions being made, you may or may not want to get out of that company as soon as it becomes evident that the bad decision is going to be made in spite of your warnings.

If you stick around though, it is vital that you let people feel the pain from that bad decision. If you don’t, you’re undercutting your credibility and signing yourself up for more of the same.

Express App Guide

(This post was written back in October. I had it written, but didn’t get it edited before getting fired, so it’s just been sitting on my drive gathering digital dust. It’s still good information, but just keep in mind that the timing is off. Everything I’m talking about happening in the present actually happened almost half a year ago.)

Welcome to another week. This week was a little rough on the development front. One of the other, more experienced, developers is drowning in projects (actually, most of the more experienced developers are drowning in projects pretty much all of the time).

Being a naturally helpful sort, and possibly not nearly as smart as I like to think I am, I offered to give him a hand with what I thought was the easiest part of his task list, new rules in the rule engine that we used to provide all kinds of customization to the user experience.

As it turns out, the rules engine is pretty complicated because it’s called multiple times—from multiple different points inside of the code base—and therefore there is a lot of different context that needs to be understood in order to effectively write the rules.

I suspect that there are many things that the other developers are doing which are more complicated than the rules engine, but it’s feeling like I’m very much in over my head right now.

The week (when I wasn’t helping out with accounting tasks that haven’t fully transitioned away from me yet) was spent with me taking my best stab at writing new rules, sending them over to my manager (who is the one who wrote the rules engine) to approve and having him kick them back to me with a verbal explanation as to why they won’t work.

He’s not doing anything wrong—he’s been really patient and awesome, but it’s still a little wearing to continually come up short (inside the privacy of my own mind if not necessarily with regards to his expectations yet).

Added to the less awesomeness of the week is that I haven’t made very much progress on my side projects. So far, I’ve created a simple express app from scratch, got it working on my local box, and successfully loaded it up to Heroku (to serve as the cloud-based compute infrastructure).

I’ve also created a MySQL database using Google Cloud as my infrastructure provider, downloaded SSL certs, used those certs to connect from my local box to the database (using Navicat since that’s what I was using previously at work while doing the accounting).

That all feels like pretty good progress, but it all happened last week. Partially that’s because I’ve been putting in extra hours at work trying to get my arms around the rules engine, and partially that’s because I’ve been stuck on how to use Sequelize to connect to the database while using an SSL cert.

I think I’ve finally found a guide that is pointing me at the right direction as far as that’s going, so I’m hoping to make more progress later today on connecting my app to the database and making it stateful, but right now I need to be working on a blog post, and the logical thing to me would be to share the steps that I used to create my express app and push it up to Heroku.

There are tons of videos out there talking about how to do something like this, but my preferred way of consuming that kind of stuff is in written form. It saves me having to pause and repeat stuff all of the time as I’m trying to follow along with what the presenter is doing.

Putting my steps up on the blog has the benefit of checking the box on the blog post that I’m supposed to be writing today. Even better, it means that anyone who prefers written guides to video guides will have the ability to search down my guide. And, for a third (admittedly minor in this day and age of cloud-based backups) benefit, it means that I’ll have me steps recorded for future use in case I need them.

On to the guide:
Preliminaries:
1. I’m working on a Mac (more regarding that in a future post)
2. I’ve installed the Heroku command line interface using Brew
3. I’ve created a Heroku account and a GitHub account
4. I’m using Intellij. You can use Sublime or another editor of your choice.

The actual process:
1. Create a new repository on GitHub.com (or with Git desktop)
a. Say to initialize it with a readme
b. Fetch your new repository from Git. (I use Git Desktop to pull it down to my local machine)
c. I have a services directory, and then put each Git repository as a subfolder inside of services.
2. Create a .gitignore file at the root directory of your project.
a. For me this is in Services\Storage-App
b. At this point, I got a message from Intellij asking if I wanted to add .gitignore (if I wanted it to be part of the git repository). I said yes, but said no on all of the stuff that it asked about in the .idea/ folder.
c. I populated .gitignore as per this example:
d. https://github.com/expressjs/express/blob/master/.gitignore
# OS X
.DS_Store*
Icon?
._*

# npm
node_modules
package-lock.json
*.log
*.gz

.idea
.idea/

# environment variables
env*.yml
e. .idea and .idea/ are there because I’m using Intellij. The link above has options for windows or linux.
3. Run npm install express -g from the command line inside of the project folder.
a. This downloads and installs express (I’m pretty sure that you only have to run this the first time that you want to add express to an app).
4. Run npm init from the command line inside of the project folder.
a. This creates the package.json file that lists your dependacies and tells the computer what to use as your starting file.
b. I used all just the default options other than changing index.js to app.js. You can use either option.
5. Run npm install express –save from the command line inside of the project folder.
a. This brings a whole bunch of express dependencies into the project. (in the node_modules folder)
b. You should now have “express”: “^4.16.3” (or a later or earlier version depending on what version of express you have installed) in your list of dependencies in package.json.
6. Create app.js inside of the root directory (same level as package.json and package-lock.json)
a. I did this via Intellij. You should in theory be able to just do it from inside the command line via touch app.js if you wanted to.
7. Inside of app.js add the following lines:
const express = require(‘express’);
const app = express();

const normalizePort = port => parseInt(port, 10);
const PORT = normalizePort(process.env.PORT || 5000);

app.get(‘/’, function(req, res) {
res.send(‘Hello World’);
}).listen(PORT);

console.log(“Waiting for requests. Go to LocalHost:5000”);

8. Inside of package.json at the end of the “test” line, put a comma and then add a new line:
a. “start”: “node app.js”
9. Inside the app directory, type npm start
a. (You should see “Waiting for requests. Go to LocalHost:5000” in the terminal)
10. Open a browser window and got to http://localhost:5000/
a. (you should see “Hello World” in the browser)
b. This means that you’ve successfully run the app on your local machine
11. Create a Procfile at the root level.
a. Input (into the proc file) web: node app.js
12. Push the app up to heroku
a. Change to the directory containing the app.
b. Type git init
c. heroku create $APP_NAME –buildpack heroku/nodejs
i. I left the app name blank and just let Heroku create a random name.
ii. That means my command was heroku create –buildpack Heroku/nodejs
d. git add .
e. git commit -m “Ready to push to Heroku”
i. You should also be able to do the commit via github desktop.
f. git push heroku master
g. heroku open
i. This should open your browser and show you “Hello World”.
h. You’ve successfully pushed the app up to Heroku. Congratulations!

That’s it for this week. I’ll come back and add some additional detail as I get a better understanding of what some of these commands do.