I know I am about two years late to the 2048 Clone Wars, but I finally got around to finishing my variant, 2048 Chess. Originally I wanted to have multiple chess pieces on a larger 2048 board. What I ended up developing was simply the kings. The gameplay doesn’t lead to terribly interesting strategy. It’s ultimately a game of button mashing and luck. Whatever, I’m calling it done: http://danielbank.github.io/2048-chess/.
Making a GitHub page for a forked repository that already has a gh-pages branch:
My biggest hurdle in finishing this project was when I attempted to view the GitHub page for the repository. GitHub was overriding the game’s index.html with an automatically generated GitHub page. I found this incredibly useful StackOverflow question for fixing that problem. The prescribed steps were to:
Make a file called index.md.
Edit the contents of index.md to be:
Make a file called _config.yml.
Edit the contents of the _config.yml to be:
Create a _layouts folder.
Move your index.html into the _layouts folder.
Commit the changes and push them to the gh-pages branch of your repository on GitHub.
The automatically generated page should be replaced by your page when Jekyll generates it.
First a little background on the problem I needed to solve. I use the Google Calendar extensively. In addition to the regular events I put on my calendar (lunch with friends, doctor appointment, anniversary), I also put reminders for tasks that need to get done. I realize that Google already has a Tasks list for this very purpose. Call me crazy but I find it easier to whip out the Calendar app on my phone and insert a new event. The only problem is that I also procrastinate. Weeks will go by and the task’s calendar event is still languishing on my Calendar. At the end of every month, I have to clean up my Calendar and decide which tasks are actually important or not. The ones that are all have to be moved to the next month.
Enter my new Google Apps Script, Calendoo. Calendoo looks at yesterday’s calendar events and either advances them into the future, if they’re important, or moves them off the Calendar and into a Tasks list (called TasksFreezer), if they are unwanted. In order for Calendoo to recognize which events belong where, you simply add a Calendoo symbol in the name of your calendar event. The Calendoo symbols are as follows:
:. (colon period) = Unimportant event, advance yesterday’s unimportant events to next month.
:! (colon exclamation-point) = Important event, advance yesterday’s important events to today.
:? (colon question-mark) = Semi-important event, advance yesterday’s semi-important events to next week.
:- (colon dash) = Unwanted event, take it off the calendar and put it in the TasksFreezer Tasks list.
:+ (colon plus) = Wanted task, take it off the TasksFreezer Tasks list and put it on the calendar today at noon.
If you want to use the Calendoo script, read on for an explanation of how to set it up.
1. Import the script into your own Google Drive
Click on the link at the bottom of this blog post. The Google Apps Script IDE page should open up showing the Calendoo code. Click the [File] menu and choose [Make a copy]. The Calendoo script should be downloaded to your own Google Drive. Access it by going to drive.google.com. The Calendoo script file should be in your root folder. Click on it to open it. At this point, you may have to go through a wizard for installing Google Apps Scripts in Google Drive if this is your first time using them. The Google Apps Script IDE should open again, this time with the Calendoo script installed in your own Google Drive.
2. Set up APIs and Permissions for the script
Next, click on the [Resources] menu and choose [Advanced Google services]. An Advanced Google services dialog will appear. Next to Tasks API, click the radio button to turn it on. This allows the code to access Tasks API functionality (used for managing Task lists in your calendar).
Now you will need to enable the services. Click the [Google Developers Console] link at the bottom of the dialog. The Google Developer Console website should open. In the list of APIs, click the radio buttons next to Calendar API and TasksAPI to turn these services on. Now close the Google Developers Console page and the Advanced Google services dialog.
Back in the Google Apps Script IDE, we need to run a function in the Calendoo script so it can request permissions from you the user (yes, this step is a little strange, I know). Click on the [Run] menu and choose the [processEvents] function. A dialog will appear saying, “This app would like to: manage your calendars, manage yours tasks, view your tasks”. Accept the dialog and it will close. The Calendoo app is ready for action, we just need to pull the trigger.
3. Set up a trigger for the script
To create a trigger to run the script periodically, click on the [Resources] menu and choose [Current project’s triggers]. A dialog will appear with a link, “No triggers set up. Click here to add one now”. Click on that link. The dialog will now show the options for our new trigger.
Choose to run the processEvents function. This is the main function that drives the entire Calendoo script. Make the event Time-driven and set it to run everyday at Midnight to 1am. This will cause the processEvents function to be executed everyday at midnight, pushing yesterday’s events forward. Click Save. The Calendoo script is now completely configured for your Google account. Hurrah!
An online friend of mine recently brought to my attention PCE.js, a browser-based emulator of the Macintosh Plus. Click the link and experience it for yourself. This emulator is solid gold. The machine it is emulating is solid gold. It’s a throwback to a world of computing almost 25 years ago. Those were the days of System 7 (which, in my opinion, is still a more intuitive interface than every other Mac OS since then). At the time, I was three years old. The Macintosh Plus was the first computer my family owned and it will always have a dear place in my heart. Between the ages of three and seven, I was inseparable from the Macintosh Plus. I fondly remember playing games like Dark Castle, Dungeons of Doom, Rogue, StuntCopter, and more. By the way, for anyone who saw the Angry Video Game Nerd’s review of Dark Castle for CDi, the Macintosh version was much easier to control with a mouse and keyboard.
Firstly, when you open the emulator you might be astonished by the specs of the machine. It has 4MB of memory and about 20MB of disk space. Really powerful stuff for 1986. Now I can run System 7 in a web browser on my computer while I simultaneously listen to music and write this blog post in another window. And my computer is still only using 12% of its CPU. I know it’s not a fair comparison, but I always have two feelings when I reflect on this. One feeling is, “How did I think that was so awesome back then?” The other feeling is, “What if I could see then how powerful the computer I use now is?” There is also a third follow-on feeling, “How awesome are computers going to be thirty years from now?”
Now for a little side lesson in Human Machine Interaction. Open the PCE.js emulator. If you go to the Special Menu of the Finder, you will see it has some familiar options: restart, shut down, empty trash, and… erase disk? Wait a second, are we sure we want to put that potentially disastrous functionality next to all these other innocent ones? Well why not? Every computer user can read the options can’t they? Not if you are three-year old Daniel Bank who likes computing even though he can’t read. Three-year old Daniel memorizes where things are physically on the screen and clicks OK until dialog windows go away. Maybe you can see where this is going (hint: I was trying to empty the trash and I accidentally reformatted my dad’s external hard drive… he was not happy).
Lastly, this post wouldn’t be complete if I didn’t talk about HyperCard. Essentially, it was a stack of “cards” that you could add scripting to. You could save your stack as a file and share it with others who could then open it with a HyperCard viewer. The scripting really made things interesting because you could transition to different cards when a part of one card was clicked, you could prompt the user for input, you could keep track of variables, and so on. Sadly, you won’t be able to experience HyperCard in the emulator because it only has a viewer.
HyperCard actually represented probably 80% of my play time on the Macintosh Plus. Sometimes I played other people’s stacks, but mostly I was creating my own. I created dozens of HyperCard games and finished maybe a handful of them. Mostly my stacks consisted of just a title screen and maybe the first few cards of an actual game. I was learning the fine art of creating VaporWare. The first words that I actually wrote with a pencil were go next, a command from the HyperCard scripting language to move to the next card. This was the start of a mad desire to create my own software gaming studio that lives on to this day.
So ends my nostalgic reflection on the Macintosh Plus as experienced through PCE.js. Tremendous kudos to James Friend for making this emulator. I have no idea how he did it but it is an awesome example of running a virtual machine in a browser.
You can get the LogisticMap application and its source code on GitHub.
Here’s some background on the logistic map, chaos, and the Lyapunov exponent. In the application, we are evaluating the following function:
f(x) = 4μx(1-x)
This function is called a logistic map because it takes a point between 0 and 1 and returns a different point that is also between 0 and 1. It maps the unit interval (0,1) into itself. We can think about the trajectory of an initial point, x0, on the map as being the successive results of plugging the previous result back into the function: f(x0), f(f(x0)), f(f(f(x0))), …
The trajectory depends on the value of the constant μ. When μ = 0 obviously all trajectories will immediately converge to 0. When μ = 0.5 all trajectories converge on 0.5 but not immediately. When μ = 0.9 the trajectories do not converge on one value, but instead wind up within a certain range of values (roughly between 0.3 and 0.6 and between 0.8 and 0.9).
Now when μ = 1, the trajectories do not converge on one value and their range of values is still between 0 and 1, the same range of values that we chose for the initial point. As Sethna states, “for μ = 1, it precisely folds the unit interval in half, and stretches it (non-uniformly) to cover the original domain”. Furthermore, two very close initial points will have dramatically different trajectories. This sensitive dependence on the initial point is what makes the logistic map with μ = 1 a chaotic system.
It turns out that the separation between the trajectories of the two initial points grows exponentially at a rate which is called the Lyapunov exponent. This exponential drifting eventually stops because the two trajectories are still pegged between 0 and 1, so there is a limit to how far apart they can be. At this point, the distance of their separation will fluctuate randomly.
If you would like to compute the Lyapunov exponent for a chaotic system, try using the following values:
X: 0.9 (X can be any number between 0 and 1, but not 0, 0.5, or 1)
E: 0.00000001 (E is the small difference between the two initial points, x0 and x0+E, so it should be very small)
N: 50 (N is the number of computed trajectory points, so it should be reasonably large enough that the exponential spreading of the two points can be computed)
Mu: 1 (this is what makes the logistic map a chaotic system)
You can get the RandomWalk application and its source code on GitHub.
Here’s some background on random walks. A random walk is a series of steps, each having the same length and going in a random direction. In one dimension, the random steps can go left or right. In two dimensions, the random steps can go left, right, up, or down.
Now it turns out that if you have many walkers all starting at the same starting location and you record where they end up, the most likely end point is exactly the starting location. The least likely end point is the furthest possible distance away from the starting location. The graph of these points approximates a bell curve (also called a normal distribution or a Gaussian distribution). In mathematics, the explanation of this phenomenon is called the Central Limit Theorem.
If you would like to see the bell curve in the RandomWalk application, try using the following values:
Number of Steps: 3 (if the walkers move only one step, they cannot return to the starting location)
Number of Walkers: 100000 (this is the key to getting the bell curve shape, there needs to be enough random walks for the histogram of their endpoints to “smooth” out)
Number of Dimensions: 1 (the RandomWalk program only graphs the histogram for 1-D walks)
Number of Bins: 100 (this parameter just lumps the random walks into a discrete number of bins – so instead of 100000 points on your graph, you only have 100 points)
The creation of this library arose out of my need to save data to Parse.com from a PhoneGap application. The app was not guaranteed to have internet connectivity so I needed a way to put the data in a temporary queue where it could be kept until I got a success callback from Parse.
OfflineSaveQueue is not being maintained anymore and I don’t recommend using it. However, if interested you can still take a peek at the GitHub repository.
Usage of OfflineSaveQueue is simple:
Instantiate an OfflineSaveQueue object:
var offlineSaveQueue = new OfflineSaveQueue();
Set the callback function which is executed when the queue is processed: