Clean Solutions with Maps in JavaScript

Tonight I was faced with writing a function for the chemistry applets I work on that returned the proper cutoff value (the size of an atomic orbital) for a given orbital at a given probability percentage of something with  the electrons in an atomic orbital. Let’s be honest here, I don’t understand much of the chemistry behind what I’m doing. I just know enough to code everything, but I’m quickly learning and understanding it all more and more!

So basically, I had 45 numbers to match to a given input. At first, I threw all the cutoff values in an array and started writing a complex series of nested if and switch statements to return the correct value. But quickly I realized that there was a much better way to do this. Why not use a map?  I never get to use maps and I want to use one! The code is pretty straightforward so let’s jump right in and then explain it.

Android 3.0 ActionBar Class: Maintaining Compatibility with Pre-Android 3.0 Apps

My goal for version 2 of the Fake Name Generator app was to have a single APK that ran on Android 3.0 and Android 1.6-2.3 while being optimized for tablets. While the Android Compatibility Package allowed me to use the Fragments API on pre-3.0 versions of Android, it does not provide support for the ActionBar class. The ActionBar is paramount to having an app properly optimized for tablets! Thus, I had to get creative.

The problem: How to instantiate an object in Android 3.* that doesn’t exist on pre-Android 3.0 in an APK that will run on both pre-3.0 and 3.*?

The answer, as it turns out, is not very straightforward.

But wait, won’t a catch-able exception just be thrown if an class isn’t found? Nope. An exception is thrown, but it is not able to be caught. Why? Because of the Bytecode Verifier of course! Basically, the bytecode verifier is going to check if all the necessary classes exist before it tries to instantiate and object from a class. Normally, code that references a non-existent class wouldn’t even compile. However, the build target here is Android 3.0, where the ActionBar class does exist. But when it’s run on Android 2.3 and lower, well, uh oh, or more formally, a VerifyError is thrown, which we can’t catch.

So, how to solve it? Well, we need to make a wrapper class that checks if the ActionBar class is available in a static initializer and throws an exception that we can catch if it is not.

Let’s take a look at aptly-named ActionBarWrapper class to start.

Penn State ACM Magnetic Card Check-in Script

The other officers and I of the PSU ACM have been talking about implementing a magnetic card based check-in system for our meetings and other events. When you check-in (swipe your card) you would receive a certain number of points. The member with the most points at the end of the semester would win a prize like most likely a half eaten bag of Skittles or something. I found the whole project interesting so I took it up and had the whole thing working in just under a day.

Skip to the bottom for a link to the full source.

To formalize… the goal: Write a program that reads data from a magnetic card, queries a database for the card info, and updates a points field in the database. It must also have an option to display the current point values of everyone in the database and run under the best OS ever, Linux.

So how does it all work?

First, and most importantly, I needed a card reader! After looking into cards readers a little bit I determined that the best option was to get one that emulated a keyboard (which is apparently most of them). This way, the program could just use a regular input statement to get the info off the card. At the end of the day, I ended up going with the Magtek 21040108. It’s a no-frills card reader; that is, it reads all three tracks and gets the job done.

With a card reader acquired it was time to turn my attention to the database. This part was easy, I set up a new database on our web server with the following structure:

cardID varchar primary key
accessID varchar
points int
lastCheckin timestamp on update

The cardID is the info directly from the cards. This is absolutely guaranteed to be unique so it is a natural choice for the primary key. We also want to keep track of the time of last check-in which will automatically update with the current time whenever a record is updated, but more on this later. With the database design complete, it was time to write some code.

I decided to take this opportunity to become acquainted with Python. I had wanted to play with Python for a long time and this seemed like the perfect opportunity, and the perfect application for it.

After writing a quick Hello World program to become familiar with the new little nuances of a new language, I went searching for a way to talk to MySQL through Python. Enter the MySQLdb module. Import that sucka’, read the manual, and you’re off and running.

So, let’s take a look at some of the more interesting parts of the code.

Hello World!

I can put it off no longer… time to finally start a blog.

About what you say? I haven’t the slightest idea! Whatever I’m interested in for a given week. How’s that? Cool? Cool.

Thus, without further ado… blog!