Month: April 2019

A quick ‘Pro Tip’. If you’re testing out a UI action inside of ServiceNow, and you’ve got to windows open, one where you’re making changes to the UI action and another that has an incident open where the UI action is located, refresh the incident window before testing changes to the UI action.

I was testing out a UI action recently, and there were definitely times where the changes I made to the UI action didn’t propagate out to the window with the incident until after I did a hard refresh of the page. I wasted a bit of time there trying to figure out why my UI action wasn’t behaving as intended when the problem turned out to be that I was still running an earlier version of the UI action.

(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.)

Hello, and welcome to another week of writing code.

I’m still trying to progress in my actual programming skills — and it’s not going all that spectacularly — but fortunately I have something else that I’ve been wanting to talk about for a little while now.

When the development manager here at work first approached me about making the switch over from accounting to development, one of the questions that came up was what computer I was going to end up programming on.

I had — have — a perfect good HP Spectre 13, but the advice from the development manager was that I should go ahead and get a MacBook. Our company seems to of fully switched over to a bring your own device policy for the development team, which meant I was looking at having to spend $2k to $3k buying a MacBook if I was going to take his advice, which was a little hard to stomach for a number of reasons, but I went ahead and did it anyway simply because at the time we had no Windows programmers at work. We had a whole bunch of programmers working on MacBooks or other Apple computers, and a couple of people working on Linux-based computers, but I would have been the one and only programmer who was trying to do what needs to be done on a Windows-based laptop.

There was a part of me that wanted to push forward using my Windows laptop out of sheer stubbornness, but I knew that choosing that option would just mean that I would either spend a lot of time on my own troubleshooting problems that nobody else had (with very little actual understanding of how to do what needed to be done), or I would constantly be going to him or one of the other developers asking for help troubleshooting problems that only I had.

Given all of the other things that I knew I was going to need to learn in order to be a adequate developer, and given that the development manager was already facing a pretty large investment to get me up and running to the point where I was adding more value for him personally than I was requiring in the way of training, the only smart decision was to go ahead and pick the platform that the majority of the other developers were using.

I’ve never actually read Stephen R Covey’s seven habits of highly effective people, but it’s my understanding that he relates a story about two guys out in a forest who are competing to see who can chop down the most trees or something along those lines.

The story is told from the point of view of the one guy, who is convinced that he’s going to when because his opponent keeps walking off into the trees for several minutes at a time on a regular basis. The first guy figures that there’s no way that his opponent can keep up with him given that his opponent is taking so much more in the way of breaks and he is.

Flash forward to the end of the story, and it turns out that the second guy was walking off into the trees so that he could sharpen his ax. So, even though the first guy spend more time chopping trees, the second guy was using a sharper ax (and therefore a better tool), and as a result managed to cut down a lot more trees than the first guy.

This isn’t quite the same thing, Covey’s seems — from my secondhand understanding at least — to be advocating taking time off to improve your skills and ability to do the work, but it’s a close cousin. What I’m advocating is to be actively looking for tools that can simplify your life, make you more effective, or save you time.

The $2500 or so that I spent on my refurbished Mac Book was a lot of money for me, but if my time is worth 50 bucks an hour, then at some point the time that I’ve saved by not having to troubleshoot my Windows PC in order to get it properly set up and keep it properly set up should more than offset the money that I had to spend on my Mac Book.

Of course, I could’ve gone with a Linux computer, but when I was being told by both the development manager, and another developer who’d switched from Lenox to a MacBook approximately a year ago, was that while a Linux computer requires a lot less ongoing troubleshooting than a Windows PC, it still requires a significantly greater amount of troubleshooting on an ongoing basis than an Apple product.

I’m sure that there are any number of people reading this who could provide perfectly reasonable arguments why going with an Apple laptop was the absolute worst thing I could have done, but regardless of the realities of everything, even if both the development manager and other developer I talked to were completely wrong in their appraisal of the situation, the simple fact that I’m using the same platform as the two of them should mean that they’ll be a lot more willing to help me as I run into problems with the set up on my box.

Again, this is a very specific instance and not extremely useful in and of itself for most of you, but there is a principle there that I do think is very valuable. Back when I was writing novels full-time, I figured out that I could write between 1000 and 2000 words per hour by typing on the keyboard.

I’m sure there are a lot of people out there that can type — and think — a lot faster than that, but I found that a typing speed in that neighborhood was enough to allow me to write a book in roughly 30 days. However, as time went on I started hearing reports from other self published authors that they were seeing really good results using the latest version of Dragon Naturally Speaking for voice recognition while they were writing their books.

I had actually used Dragon Naturally Speaking 10 or 15 years before that point while I was in college, and was never able to get it to work satisfactorily. Part of that was probably my poor enunciation, part of it was the fact that all of the microphones I tried were likely not up to spec for working with voice recognition, and part of it was the fact that Dragon Naturally Speaking wasn’t as good back then as it is now, but the result was that I relatively quickly stopped using Dragon Naturally Speaking and went back to typing (back in my college days).

As it turned out, with the right microphone, and the new version of Dragon naturally speaking I found that I was able to routinely turn out 2600 words per hour via dictation, and occasionally even break 3000 words per hour.

Getting myself up and running with Dragon Naturally Speaking was a lot of work. I went through a couple of different microphones before I found one that really seemed to work well — even though my original microphone was highly rated by the company that makes Dragon NaturallySpeaking — and even more than that, it took some practice to get myself to the point where I was comfortable speaking my thoughts rather than just simply writing them out via my keyboard.

In spite of all of the (metaphorical) pain and effort involved, being able to increase my productivity by 30 to 50% was hugely helpful at that time in my life, and if there hadn’t been such a huge uptick of piracy when it came to my titles, that increase in productivity would’ve been enough to ensure that I made a very good living writing.

So, the moral of that story — or the principle that I’m trying to communicate — is that don’t be afraid to try new things that seem like they will have a significant impact on your life. Even things that have a small impact can end up making a large difference if you chained together enough things that all individually only make a small difference.

The ‘competition’ is going to end up using anything that is hugely helpful at some point, and if you let yourself get left behind from a productivity standpoint, you just asking for problems at some point in your career or life. That being said, I don’t advocate doing anything stupid. Don’t risk your help, and don’t spend money that you don’t have in the pursuit of efficiencies in areas that you haven’t proven you can make enough money at to eventually repay the investment.

A lot of times it’s human nature to look for a magic bullet to solve all our problems, which results in a lot of people going the debt for what can only be described as get rich quick kind of solutions, but more often than not if you stop and take a hard look at what you doing, there’s a productivity enhancement that you could unlock which is much closer to what you’re already doing, and therefore much more likely to pay off in a reasonable amount of time.

That’s it for me for the week, good luck with your endeavors in the coming week!

(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.)

I can’t believe it’s been another week already! I’m afraid that I don’t have the exciting update I was hoping for, which means I’m still stuck on my side project, but I do have something that I hope will be useful to some of you.

I fully expected that transitioning from accounting to development was going to be tough — which it has been — but I’ve been consistently surprised at all of the things about it that I didn’t realize were going to be so tough.

I think that it’s human nature to forget how hard it was when you started something once you’re a decade or more down the road and have achieved a very high degree of mastery in your current field. You tend to think that you’re just really smart, and that’s why things come so easily to you, but in many instances I’ve been under calling all of the beneficial experience that went into getting me to where I currently am as an accountant.

One of the things that I’ve noticed this week is that I’m tending to skim through stuff when I’m working on a programming task even though I really should know better. At first, I thought that I was just tired and overwhelmed given some of the other accounting commitments that I’m still trying to satisfy while simultaneously attempting to get my feet under me as a developer, but as I’ve watched the development manager review code, he scanned through stuff with incredible speed, and I am starting to realize that I read quickly on my development tasks because I’m used to being able to read through stuff very quickly when it relates to accounting.

In accounting, I have sufficient master the subject that it’s generally easy for me to pick out the relevant points of whatever it is that I’m reviewing without having to slow down significantly. With development, that tendency to read through stuff quickly — relying upon a mastery of the subject that I don’t have to make sure I pick out the key points of what I’m reading — will continue to get me in trouble until I finally manage to break myself of that habit.

In fairness, the other thing that I think I have working against me is the high degree of pressure that I’ve been under in this most recent role to turn things around quickly in an effort to keep up with everything that was changing on a monthly and sometimes even weekly basis.

Either way, I have made a renewed commitment to slow down and take the time needed to stop making so many stupid mistakes. For those of you who are making a similar kind of transition — whether it be from accounting, or from a completely unrelated field — tried to keep an eye out for the habits and assumptions that you developed in your previous roles. Yours might not be exactly like mine, but the chances are that sooner or later you come across something that you’re going to have to unlearn in order to achieve your goals as a developer.

That’s it for this week from me, good luck with all of your efforts in the coming one.

I recently had a client (a sizable multinational with employees speaking 9 different languages) that needed real-time translation inside of ServiceNow.

The translation of labels on a given form–and of UI Actions–is already built in. It’s not real-time, but the translation plugins for the various languages already have translations defined for the baseline labels.

Translating things like description, short description and resolution notes (especially in real-time) is a whole different ball game.

I created some custom tables, set up an outgoing REST message, and then did a whole bunch of coding. I can’t give away any of the secret sauce, but here is the outcome:

First we start with a standard incident with the short description and description populated with English. You’ll also notice that we’ve got two new buttons at the top of the form, ‘Translate’ and ‘Translate Notes’.

Next, you can see a screenshot showing the same incident, but with the user’s language switched to French. You’ll notice that the labels are translated (‘Caller’ is changed to ‘Appelant’), which is standard with the French Translation plugin.

The ‘Translate’ and ‘Translate Notes’ buttons have been translated, but the values in the description and short description fields are still in English.

Then, after clicking the ‘Traduire’ button, French translations are added below the short description and the description fields. (In the blue field decorator.)

 

Then, if another user (with their language set to Spanish) opens up the same incident, the labels and buttons are both translated, but since the ‘Translate’ button hasn’t ever been clicked by a user with Spanish set as their language, we don’t have a translation for the description or short description.

Once the ‘Traducir’ button is clicked, the Spanish translation is displayed.Below is a screen shot of a new incident, once again in English. This time from the service portal.

Here is the same incident, this time as it would be viewed by the ITIL user with their language set to Spanish. The additional comments in English that were visible on the ESS view are visible here as well, untranslated.

Clicking the ‘Translate Notes’/’Traducir Notas’ button brings up a UI Page with the original value in English in the 4th column, and the Spanish translation in the 5th column.

Looking at this particular screenshot, I can see that I probably should have made the title “Work Notes & Additional Comments” and the work_notes/comments label in the second column dynamic. I should also probably duplicate the Spanish value from the 1st row, 4th column and push it into the 5th column. I’ll have to circle back around to the client and see if they want that change made.

Finally, here is the ESS view with an English translation for the Spanish additional comments response which was input by the ITIL User.

There were some other wrinkles with this particular engagement that I won’t go into here, but overall I’m very pleased with how everything came together.

It would have been very easy to set the description, short description, and resolution notes to translate automatically rather than requiring the user to click a button, but there was some concern about things being translated unnecessarily.

I did however set it up to re-translate anything that has been previously translated if the source value of the original field is changed. All of the translations are saved off so that the API doesn’t have to be called (and charges incurred) unless the value of a field changes, or a particular field hasn’t ever been translated.

There is an app on the ServiceNow store with a price tag of $9,500 per month that has a few extra bells and whistles, but this replicates a significant chunk of the functionality, and the only ongoing charge is a $20 per million characters.

I think this is a big win for everyone involved, and I’m happy to have been able to automate the translation process so that the ITIL users at that company can spend more time doing other, higher-value work instead of manually translating incidents.

I ran into a problem recently when trying to run a fix script with my then-boss.

It’s been a couple of weeks now, but to the best of my memory, we had queried the database for a list of records, and then were wanting to insert into another table using one or more pieces of data from the list of records.

It seems like an easy problem to solve.

var gr = new GlideRecord(‘table_name’)

Then add your query parameters and run gr.query()

Finally, you then use while(gr.next()){} to step through the records, and inside of your while loop, you create a new GlideRecord object that you can use to insert the new record.

However, after several iterations, we weren’t able to get the insert to work while it was nested inside of the while loop.

My workaround for that is to step through the records using the gr.nex(), and push the information I need from the records onto an array (or an array of objects). Then, further down I can step through the array and do whatever inserting I need to. That worked without problem, and more closely mirrored what I do with function calls (since you can only return one item, if I want to return anything complex I end up placing the information I need into an array, an object, or an array of objects, and then just returning that).

Hopefully that will save some of you fifteen minutes at some point when you avoid replicating the problems we had.

Given that I’m in the middle of a job search right now, getting posts up displaying my skills is more important than sticking to a regular posting schedule.

Due to that, I’m going to try and get a bunch of content posted in the next few days even if it means that I ultimately end up having a gap in posts at some point in the future.

For my first ‘show my skills’ post, I’m simply going to link to a post I wrote for the Lumagent blog that recently went live. It describes how I went about setting up an automated time sheet reminder inside of ServiceNow.

You can find the post here:

Creating Email Reminders For Missing Time Sheets