Over the years, the UBot team has watched in awe as the scripts our users created went from small, specific tools, to enormous, complex, multifaceted uBots. As software developers, this left us with an interesting problem: How should large scripts be organized in a way that allows UBotters to keep their sanity? In the latest update to UBot Studio, 5.5.12, we’ve taken a novel approach to begin addressing this question – by turning your scripts into a story.
The human brain is extremely good at managing stories. Our brains are notoriously bad at handling complex mathematical logic and data. So guess which path computer scientists decided to model programming after? The latter, of course.
At UBot Studio, our goal has been to make building applications easier for non-programmers, and also to create smarter ways to understand building programs overall. By introducing a set of smart logging commands, establish, purpose, activity, log, and ui log view, UBot Studio makes building your uBots less like math and more like a good book.
You’ll notice that the logging commands appear in black instead of the normal blue. This is to keep logging commands conceptually separate from other commands. Generally, a bot should work without having any logging commands in it, so the color difference helps to visually follow the main flow of your bot without being distracted by the log commands. Now, when I say that your bot should work without any logging commands, I mean this only speaking technically. Logging and testing are considered best practices that will help keep your bots robust and free of bugs.
The first command to understand is the ui log view. This works just like any other ui command, in that when you add it to your script, a ui element will be added to the ui panel. In this case, the element will appear as a large textbox that will show you the log as it updates.
Note that when you use any log command, it will write to two places: the log files, located in Users/{NAME}/AppData/Roaming/UBot Studio/Log; and a variable in UBot Studio called #log. In the log files, the log is stored as plain text. In the #log variable, the log is stored as html, which can be followed in the ui log view, or shown in full via UBot Studio’s web browser. You can accomplish this latter task with the following code:
ui log view("Log")
Great, now let’s look at some actual log commands. When creating a bot, the first thing you want to do is define your purpose. This should be the overall objective you wish to achieve for the bot or the script. Write a few words about what you are trying to do. When you run it, it looks like this:
Next, let’s take a look at the activity command. You can think about your bot as a series of activities or tasks. First, your bot does one activity. Then, it does another activity. The activity command is also identical to the log command, with a slightly different message. You’ll use it to split up and describe the various tasks that your bot accomplishes. You may also find it useful at the beginning of defined commands.
The log command is a little more general than purpose or activity. The log command is for writing quick bits of information to the blog. For instance, if you need to know what a particular variable is at any given time, the log command is a good choice.
The section command is similar to the other log commands, with an important difference. Besides writing to the log, it also allows you to organize your script and your log. The section command will describe a group of similar commands, and those commands will be children of the section command. Functionally, all the section command does is write to the log and run the commands inside of it. Visually, it make your script easier to mentally chunk.
The section command also helps keep the log organized. Any log command ran inside a section will show up inside that section in the log. We’re going to ignore this command for this lesson, but explain it further in Part 2.
Here’s a visual diagram of how you might use these commands in your script, and what the story would look like in your log when that script is successful:
The establish command is a bit more complex. With the establish command, you’ll be testing to see that the world is as you expect it to be. For instance, maybe you’re logged into a website, and you’re scraping or sorting through 1000 pages of search results. Maybe this website occasionally logs you out. You can use establish to check for some condition, for example, to see if there is text on the page that reads “results”. In practice, we would use establish to check for the condition “$searchpage(“results”), and this will establish that our browser is on the results page, or that we’re logged in. This way you’ll know you’re logged in and in the right place before you try to scrape.
If the condition passes, the establish command will continue on with your script. The log will show a pale green acknowledgement of the situation.
If the condition doesn’t pass, the establish command will run all the commands contained inside it. Once it does, it will test the condition again. If it passes this time, the log window will let you know with a brighter green color. If it still fails, the log window will show a red message. It’s important to write meaningful messages in your establish commands, so that if there ever is a problem, you can find it quickly and easily.
So, what should you put inside it? Generally, an establish command should contain script to correct the problem, or at least, to notify you that a problem has occured. In the latter case, you might also have it pause or stop the script, so that you can come back and fix it manually. Think of establish as a system for providing failsafes to your uBots. In a perfect world, your establish commands will never have to run. But using establish commands will make your uBots very robust, and your uBots will keep running even if the world isn’t perfect (and trust me, it isn’t).
You may also notice that the establish command also has an advanced parameter. This parameter allows you to use establish in a completely different way. I won’t be going over this now, but keep an eye out, as we’ll be writing a separate blog post for this in the near future.
Here’s that same diagram from before, but with the establish command included in place of a log command:
Logging and establishing conditions are habits that will require foresight and discipline. It will be tempting to just write the code that completes your scripts the quickest. But if you stick to this better coding practice, you’ll find that your uBots will grow more quickly, easily, and with more stability than your competitors. You will easily be able to track down and fix mistakes in your uBots, and determine where they need improvement. As your uBots grow and grow, you’ll be confident you can handle the larger scope.
And as I like to say, big bots means big bucks.
Next week, I’ll cover using these commands for unit testing!
Seth
