“By failing to prepare, you are preparing to fail.” – Benjamin Franklin
There it was.
The flash, AKA the Ubot killer.
The entire website was Ubot friendly, but of course the registration page – the one I had saved for last – wasn’t.
Two weeks of work down the drain and a very pricey sale was lost.
Don’t let this happen to you!
Over the years I’ve make a lot of mistakes in Ubot. And slowly I’ve developed systems to help me not make those same mistakes again.
That’s OKAY to me. I don’t mind making mistakes. I don’t mind failing. Because I believe that it is how you overcome the failures and push on that makes you a better person.
But don’t take it from me. Because like the great Michael Jordan once said:
“I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.” – Michael Jordan
Now I want to talk about a subject that is almost never mentioned on the Ubot Forums – organization. It’s actually a really important part of creating programs. Without organization a lot of things can go wrong including:
- Sloppy code
- Loss of data
- Extra work
Time is money as they say and I doubt you want to be wasting it trying to figure out what you did two hours ago when your bot was working better.
Here are my tips on staying organized to produce better results in a shorter time period.
Follow The Functions
With all new programs I write I try to tackle the functions (and commands) first. These generally are going to be the worker bees of your program. Grabbing the data (honey) you need and returning it back to the engine (beehive) powering it.
These functions are going to be the important parts of your program in most cases and you want to tackle the important and hardest parts of the program first. The main reason for this is to save you loads of time. I can’t tell you how many projects I’ve done where I was 10 hours into the project only to find a big roadblock in my way. Sometimes these roadblocks make the program impossible to make, meaning you wasted all the time you used to create the rest of the program.
To give you an example let’s look at the following scenario. Amy and Bill are both creating a Facebook post scheduler:
Amy is smart and decides the main function of the program is to post to Facebook. She also takes into account the fact that Facebook probably has the most security on their post button. She knows that if she can create a function to post to Facebook that the rest of the program will be easy to make. After giving it her best shot she decides that the Facebook developers have clearly never seen the light of day and only exist to block potential spammers.
Bill on the other hand decides to put off the post function until last. He thinks that if he gets the rest of the program done first he will be motivated to do the hardest part. He spends a couple of hours making the rest of the program perfect so that all he needs to do is add in the posting function. Later he finds out that he can’t post to Facebook because it’s too difficult and is angry that he wasted his time making the rest of the program first.
I don’t know how hard or easy it is to post to Facebook but I do know that you want to be like Amy in this situation.
This is something that I learned the hard way and unfortunately it had to happen to me many times before I corrected the issue.
Use A Scratch Pad
When I start to write a new program I open up two instances of Ubot. And throughout the process I always keep at least two open. The second Ubot instance I call “Program Name TEST BOT” and use it as my scratch pad (think like a little notebook for code). I will create my functions in that scratch pad and anything else that needs figuring out before copying it over to the main program.
Think of your main program as more of a final place for code that has already been written, rather than something you actually code in. I don’t do much coding in the actual main program. Why? Because each piece of code should be individually tested first. That way it is easier to debug. More on that next.
Tabs And Programs And More Tabs And Programs
When you’re using your scratch pad you should be separating each piece of code. I usually do this in separate tabs. This is a reflection of what you main program will look like later. For example in the Ultra Keyword Scraper you will find 4 tabs: Main, GUI Functions, Add Letters, and Search Engines. Before this it was even broken down a bit more with a scratch pad that contained tabs for each search engine.
The reason you want to separate the code so much is to test it. It is much easier to debug a piece of code that is 40 lines long than it is 400.
In the above example I would create a new tab for each search engine which would contain a function. Then I would write a little bit of code above it to call that function based on the inputs (in this case it would be a variable called #keyword for each of them). When I was satisfied with the results I would then copy those functions into the Search Engines tab in the main program.
For the main program I don’t need to break it down so much and have 20 tabs. I can organize the tabs by adding several similar functions into them. That way if say Google were to break I know that I can go to the Search Engines tab and then to the Google function. I can open up my scratch pad, copy the function from the main program into it, fix it and then copy it back.
Now that you are a tab wielding ninja there is one more important thing you need to do. You need to create many versions of the same program. Saving your progress as you go.
Each version should be a milestone, this is good for a few reasons. The first is probably the most obvious, data loss. I have read horror stories of people losing entire bots from either computer error or even Ubot errors. Sometimes you run a bot and have a million error popups and need to close Ubot via the task manager. Having a scratch pad and multiple versions of the program will help keep you on track.
Sidebar: Keep your Ubot folder in a Dropbox folder or another similar service that way it is backed up to help prevent data loss.
I don’t like writing comments, I’ll admit. But they are important to do immediately after writing bits of code, especially if you know later on down the line that it may look like gibberish.
Comments can be used to either explain what you were thinking at the time or to help with readability.
Here are a few example comments taken from the Brandable Domain Name Finder:
Example of a comment that notes what I was thinking at the time:
“Only append to text if there is already text
there otherwise it will add a blank line at the top”
Example of a simple comment to help readability by breaking up the code:
“Popular” (in reference to which list is being used)
Example of a comment that explains what the function does:
“This function can return any combined keyword and list
from a file really easily saving us lots of coding and update
frustration. Any time you want to add a new list simply create
a new checkbox and write an if then statement in Add Keywords
then just give it the correct file name and this function will do the rest!”
Example of a comment that tells of a user action:
“The stop button has been hit”
When it comes time to update the program down the line I’ll be able to read the code easier and know what’s going on without having to think about it too much.
What To Do Next
So on your next Ubot project make sure you follow these simple guidelines:
- First, open at least 2 Ubot instances, one will be your scratch pad
- Create the hardest functions first and make sure the project is possible to complete
- Separate everything into tabs in your scratch pad
- Use separate tabs in your main program and group like functions together in them
- Save different versions of your programs to prevent data loss and for testing