As a geek, any time I have to do something more than a few times in a row, I start to ask the question, “Can this be automated?”  So when an online contest comes along requiring some mundane task, my mind gets in problem-solving mode and looks for the better way to win.  Now, there is an ethical question here that needs to be addressed, but as long as the game’s rules don’t prohibit automated entries and the entry form doesn’t include a CAPTCHA, I’m not sure there’s a problem.

A number of years back, there was a Flash game on a band’s website.  Essentially, it was Whac-A-Mole, where the band members popped up randomly and you had to click them.  Each click earned you a point and if you missed enough times, the game ended.  Ultimately, it was a game of patience, not skill.  The highest scores (those who would win prizes) indicated they had played the game for around a day, or more likely, automated the process.  I automated it simply by having my mouse click all of the locations over and over.  I used a program, but now I would probably code something up using Java’s Robot class.

Just recently, I found a contest that offered a daily game, then daily entry to the contest.  Really, you didn’t have to play the game to enter the contest, though.  And, the entry form is pretty simple: fill it out and click “Submit.”  Every day.  So I took it as an opportunity to learn a little bit about automating HTTP POST requests, which is how most web forms operate.  It really wasn’t hard, but to do it exactly the way I did it, you’ll need a bit of knowledge about HTTP requests, and an always-on Linux server.

The program at the center of it all is curl.  That’s what will send the HTTP POST request and return the contest server’s response (likely in HTML).  I also used shuf to generate random numbers in a range, and cron, at, and sleep to schedule the script to run in a random time frame each day.

First, the scripts. I put this in my home directory as enterContest.sh (with appropriate permissions):

#!/bin/bash
# Mar. 11, 2013 by KJK
sleep $(shuf -i 0-59 -n 1)
echo "===== $(date) =====" >> /home/MYACCOUNT/enterContest.log
curl --data "loadStage=2&contest=THEGAME&time=$(shuf -i 60000-780000 -n 1)&email=MYEMAIL&password=MYPASSWORD&comment=&SUBMIT=Enter" http://www.theurl.com/action/of/form >> /home/MYACCOUNT/enterContest.log
echo "

" >> /home/MYACCOUNT/enterContest.log

Then, I put a file called enterContest in the /etc/cron.daily directory which automatically makes it run daily:

#!/bin/bash
at -f /home/MYACCOUNT/enterContest.sh now + $(shuf -i 1-480 -n 1) minutes

In the second script, all it’s doing is calling the first script at a random time in a range. This is necessary because scripts in cron.daily are executed at the same time every day. at -f executes a file at a later time, and the shuf command (in parenthesis) is a nice little tool to generate a random number.

The first script pauses some number of seconds because I don’t think at will delay with anything finer than minute precision, and I didn’t want the request going in with the same seconds part of timestamp every day. Then, the two echo lines are simply to log the response for later review. curl is doing all of the work. Though the string with all of the & symbols looks like a GET request in a URL, it’s actually the POST data: still just named values. The URL is the action attribute of the form (where the data should be delivered) and the end of the line specifies the response should be logged to a file. The different variables in the POST data string are all named fields in the form. loadStage and contest were hidden fields, so I just copied the hard-coded values. time was the number of seconds I spent playing the game, so I randomized that. I didn’t fill out comment at all, as it was an optional field. password is written and sent over the web in plain text, but that’s not much different than what would happen if I were to use a web browser. It’s the responsibility of the web developers to enable HTTPS instead of HTTP.  Developers can prevent automated entries by employing the use of a CAPTCHA, but they still have weaknesses (e.g. modern computer vision algorithms, crowdsourcing).

So far, I haven’t won anything with this script yet, but according to the log, I’ve entered the contest every day.  Taking the time to write the script will end up saving time in the long run.  I’m just satisfied to know that it can be done!

Whenever I need to register a username and I don’t use my real name for whatever reason, I use “kjkjava.” (Spell check always changes that to “kick java.”) KJK are my initials and I first used it as my AIM screen name back in middle school. I was never a huge fan of it, but it stuck, and I grew into it.

Back then, I was learning how to make websites and didn’t really make a distinction between HTML (which I understood) and JavaScript (which I copied and pasted). In fact, I don’t even think I knew there was a difference between Java and JavaScript. I certainly didn’t know Java. But I do now! It’s currently my language of choice because I teach it. Also, I didn’t drink coffee then, but I love it now! How perfect!

In the screenshot above, you can see my first website on Geocities.  Also, there’s a chat log from an IRC channel I hung out in with a couple of friends.

Overarching Goals

• Central place for people to connect with, and learn about, me
• Contact information
• Place to share…
  • Things I’ve created or done
  • Things I’ve learned about
  • Other thoughts and ideas that are bigger than a Facebook status or a tweet

Two Main Reasons for the Redesign

Why is it that after designing numerous websites for other people, it’s so hard for me to design my own?  I’ve had this domain, kylekrafka.com, for years now, but I’ve not yet been fully satisfied with the website on it.  When I first purchased it, I went to considerable effort to write a site from scratch using clean and valid HTML/CSS/PHP.  I made images sprites for rollovers, wrote some good copy, and employed all the SEO techniques I knew (even though I don’t have much competition for “Kyle Krafka” searches).  Technically, I had designed my dream website.  Why then, did I never publicize it?  Why did I never announce its release on Facebook?  I wasn’t really happy with it, and in retrospect, I think this lack of pride was due to two problems: I’m not a graphic designer, and it wasn’t easy enough to add new content.

I have a great appreciation for quality design work, and I know how to work with design software, but that doesn’t make me a designer.  I was never really satisfied with the way my site looked, and I couldn’t put my finger on the problem.  This time around, I decided to suck it up, and use someone else’s talent.  No, it’s no longer entirely my work, but I’m okay with that.  I’ll stick to what I’m good with and I doubt anyone else will care.

As for adding new content, I had to make layouts in HTML, manually resize images, put everything in appropriate directories, update any files that would link to the new content, then upload via FTP.  No, it wasn’t terrible, and I knew how to do it all, but when my focus was on something worth sharing, I didn’t like the distractions.  The better solution is to have an administrative interface to edit in, and dynamically build pages from content in a database.  That’s not an easy solution to code up (if done right) but it’s definitely a more enjoyable experience for adding content.

Sure does!  Sweet.  Check out this picture.