Does 0.1 Mean “Usable” or “Useful”?

In the time since my last post about making an Android app, I’ve had some time to re-familiarize myself with the process of mobile development. A lot has changed since CAB Manager, a project from just two years ago. Users have come to expect higher-quality apps. On the whole, Android development has gotten a lot better, from the SDK to the APIs, and everything in-between. Nerdy geeky code stuff is not for this post, though.

The exigency for the creation of this app is two-fold. Besides wanting to learn more Android, I want to make my own life easier. That may sound selfish, but it’s a totally great reason, I swear! I recently moved to Boston, Massachusetts. A great aspect about this place is the train system, which seems to go just about everywhere around. But this T (subway) thing presents a problem, however: How the heck should I know when the next train will be coming around?

During my first few days, I would simply open Google Maps, find the station I wanted by doing a text search, and tap it to see train arrival times. This soon proved to be inadequate for me. It is quite a process to view the transit times for a station, even if you save (star) it. It befalls good software to do one thing well. For Google Maps, that thing is maps, not transit times. The problem lies in the interface, which gives rise to the UX question: How to best present train times to the user, given arrival times being the highest priority?

I cannot lay claim to the invention of such an idea. ProximiT is an iPhone app which has this idea down pat. I was made aware of it by a co-worker. It’s awesome, but I don’t aim to simply copy it. The UI and UX patterns of Android and iOS do not have 100% overlap. Rather, my app will be heavily inspired by the work done by the ProximiT team, hopefully resulting in a similarly great experience on the other side of the smartphone world. I’ve made a decent amount of progress so far, but until now, I wasn’t sure what version I should call this.

According to Semantic Versioning, a program should generally become “production-ready” at version 1.0(.0). Of course, sometimes—okay, frequently, programmers ignore this rule. NodeJS, which meets every one of Semantic Versioning’s criteria for 1.0, is currently stable at version 0.12.7. By contrast, Google Chrome is currently at version 44.0.2403.157. The differences between 43 and 44 are incredibly minor. Like, what gives, guys?

I’m going to attempt semver with this. The current state of my app is somewhere between “useful” and “usable.” It is definitely useful in the sense that it is useful to me; the app displays (seemingly reliably) the current MBTA subway schedule, albeit in an extremely limited fashion. Only the stations which I use on a regular basis are listed, and only in the more “important” (to me) direction. This bare-bones behavior is suited more to a proof-of-concept than a user-ready experience. It also lacks all manor of visual hierarchy and design. The important thing, though, is that it’s a thing which does a useful thing, so I proudly christen this app as T Time 0.1!

Not production ready…not even close.

Further development is in progress. Check back soon, y’all.


Getting Back into Android

It’s been over a year since the last time I’ve created an app for Android. “App” is being used in a rather loose sense here, because said app, CAB Manager, was created and designed for a very small (15-30) group of people within a single university. While it served its purpose and was well-liked by its users, at the end of the day, it was simply too esoteric to warrant publication.

Although there have been some recent issues involving the Android platform, I still regard it as superior to the competition. I like that Android development is more accessible and open than iOS. Its SDK is available on Windows, OSX, and Linux. The fees for app publication are lower. The content rules on the Play Store resemble a democratic forum, contrasting with the App Store’s gulag-esque model, the content guidelines for which contain such risible gems as:

Apps that include games of Russian roulette will be rejected

It’s a great time to work with Android! In addition to the established phone and tablet platform of Android, there is a nascent array of Android devices which await great apps: Wear, TV, and Auto. Each of these device types are used in quite different contexts, yet in many situations, connect with more traditional mobile devices in different ways. For example, Google Maps’ navigation feature would make a lot of sense with Wear and Auto, but perhaps not so much with TV. Play Music, on the other hand, would be useful with all three.

In the time since CAB Manager, there have been a lot of changes with the platform: The introduction of Material Design, the release of Lollipop, and the official deprecation of the Android Eclipse plugin in favor of Android Studio, just to name the most resounding. In light of this, I’ve chosen to start from scratch, beginning with setting up Android Studio and running the BlankActivity Hello World on my phone.

I’ll post more as I develop the app, which will be my attempt at porting the functionality and interface of an existing iOS app to Android.


Introducing Entropy, a Pythonic Wallpaper Rater

Finding a good wallpaper is hard. The subject is, well, subjective. There are endless possibilities for the subject of the image: Sports cars, beautiful women, scenic vistas, cartoons, minimalistic patterns, and humorous/motivational quotes are all fantastic candidates. Rating the subject is best left to humans, but the machine can be manipulated to rate the image from a scientific standpoint.

To that end, we have released Entropy, a command-line tool to rate an image. Images are passed-in via a URL or file path. The image is assessed using features from the Pillow library, an excellent staple of Python’s community. We convert the image to Lab color and assess the individual L, a, and b values, per-pixel. An image with mostly warm pixels will get a higher rating than an image with few or no warm pixels. This logic stems from the Kruithof curve, which shows that there is a wider range of “pleasing” colors at higher luminance levels, so higher luminance + warmness means a higher rating. Below is the terminal output for a picture of an adorable little pug.


Picture resized. If you want the full-size, use Google Reverse Image Search.


Not bad, pup!

It could be argued that this isn’t the best way to determine an image’s aesthetic quality. It’s probably not, because humans are much better at rating that sort of thing. But it can help give a general sense of how you might feel repeatedly seeing the image. To that end, we also factor in size and aspect ratio differences if they exist between the image and screen. An insanely beautiful image probably won’t do you any good if it’s 250×800, after-all.

Entropy is open-source and available on Github.


RocPy: Advanced Edition

On February 18, I attended RocPy yet again. My classmates and I previously graced the meetup with our presence a few times, as part of the Humanitarian Free and Open Source Software class at RIT. This time, however, we have “graduated” to advanced status: we’re now in the second course in the sequence, known as Advanced FOSS.
The focus is still on creating free software to benefit humanity, but now the goal is to make small utilities, or “hacks,” with an emphasis on the Raspberry Pi. Being a meetup about Python, we gave a presentation on our wallpaper rating script, Entropy.
There were also some students from the first course present, many of whom are inexperienced with Python, so the presenters went over some basic nuances and best practices with the language. For example, in Python, it is possible to access a character index of a string like an array:
string = “python is cool”
string[2] #Returns ‘t’
Python arrays are zero-indexed, so the above code would return: “t”
The behavior in PHP is very similar:
$string = “PHP is cool”;
echo $string[2]; //Returns ‘P’
Both languages are wonderful products of the open-source community, and contain awesome features that reduce cognitive load on the programmer. Python is easy to pick up (especially if you already know PHP, Ruby, or JavaScript), but there are special nuances, so learning them in a communal setting is a great thing. Feedback from Python veterans on our projects is also an indispensable benefit. Rock on, RocPy.


A Raspberry Pi in the Face

Customizing hardware is a rewarding experience. There are few other things that can evoke the sense of wonder one experiences when they see something they made, or built, working. We certainly didn’t make the Raspberry Pi, but we are going to stand of the shoulders of the “giants” that did make it. THe best way to do this is make software that exploits the uncanny versatility of the Pi–its size, cost, and relative power give it a variety of efficacious applications.

The Pi is small, so it can go many places computers like the HP Probook 4530s cannot.

The Pi is small, so it can go many places computers like the HP Probook 4530s cannot.

Many people choose to use their Pi as an inexpensive HTPC (home-theater personal computer), and it works great for that. It can handle 1080p video decoding and its wide array of ports allows mass storage and fast internet/LAN connectivity.

In fact, when I’m not developing stuff for it, I’ll probably use it for that purpose. I wouldn’t have to connect my laptop or desktop to my TV, and it would consume negligible space and power.

The kit we got from RIT contains not only the Pi, essential accessories, and an SD card preloaded with four popular Linux distributions, tailored for the Pi’s hardware. It’s convenient to plug-in many places. It supports Wifi (with a dongle accessory), as well as connecting “home-made” peripherals through the use of an included breadboard. Because of this, DIY security cameras, motion detectors, door openers, light-switches, and other cool things are entirely feasible.

I can’t wait to make the Pi more whole by creating some good stuff for it.


Version Control Should Be Taught More

Software is complex. Like really complex. Like millions of lines of code, several year-long development period, countless contributors complex. More and more, software is something done with others. Collaboratively. As a team. It then stands to reason that developers need to learn the best way to work with other developers.

Version Control is an elegant solution to this program. It allows developers to visualize every single change made, who contributes what to the project, and how much everyone commits. At least, Git does this. I can’t think of a compelling reason to use any other version control system, other than “I don’t know Git.”. Git is easy to use, relatively ubiquitous, and popular among the FOSS community. But I don’t mean to advocate a particular version control scheme, as much as I mean to advocate version control itself.

Working with others breeds good software. So schools that teach programming should teach version control. At RIT, the HFOSS course does this well, but a surprising number of students in the class had no version control experience prior. That’s upsetting, given how much the web is a collaborative industry. I encourage high school programming classes and any at the college level to at least cover the what/why/how of version control. For the good of software.


WordPress, nginx, Linode, oh my!

I recently switched from HostNine to Linode for my web-hosting needs. Nothing against HostNine, they’re a great company with superb support and excellent shared hosting. It’s just that I needed more. Linode offers great pricing on VPS service, and it’s extremely fast. It’s also completely root, so I feel at home with complete SSH/SFTP filesystem access.

Transferring the site files was a trivial task (as it should be for anyone with at least rudimentary webserver knowledge). Transferring databases is made easy via phpMyAdmin.

But there is one thing I had to consider: what web server?

Most shared hosting providers choose this for you, and it’s almost always Apache. Apache is a great project; it is a facet of the FOSS community and has matured over many years of development into a powerful server. But there is always competition. nginx is another open-source web server with an emphasis on performance. nginx is insanely fast. But it is configured differently than Apache, so getting PHP, MySQL,  and WordPress to work with it took a bit of research.

The nginx article on the WordPress Codex was a fantastic resource. WordPress requires some URL rewrite rules to enable the pretty permalinks, like the one for this article. With Apache, rewriting is achieved via a .htaccess file. nginx uses configuration files similar to JSON. The core rules required to make WordPress permalinks be pretty are as follows:

# WordPress single blog rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
	try_files $uri $uri/ /index.php?$args;

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

That made WordPress work, but a problem persisted: I couldn’t upload pictures via the WordPress dashboard. This was obviously a permissions issue. I expected nginx to be running as root, but to my surprise, it was not:


On Linux, the following command will reveal the user a particular process is running as:

ps -elf | grep nginx

This revealed that nginx is a process of the “www-data” user. Changing permissions of the uploads folder appropriately solved the problem.

Interestingly, PHP also has a built-in way to see who owns the process:

echo exec("whoami");

Initial configuration was a bit of work, but I’m a happy camper. nginx and PHP with FPM is fast. Ricky Bobby-fast.


You Think This is a PyGame?

For the past 9 or so weeks, a team of RIT students, myself included, have been creating a math game in Python. The game is designed to run on the XO-PC from the One Laptop Per Child project. The XO has meager specs, including a minute amount of RAM and slow CPU. Therefore, software development should keep performance in-mind.

PyGame is seemingly oblivious to this. Python isn’t the world’s fastest language, but even our basic game has problems on the XO. One major flaw with PyGame is that it is ridiculously “low-level” considering that we’re using Python. We had to implement the state machine, game loop, and even buttons ourselves. In fact, text rendering is so crude that the text object provided only supports one line of text–newlines are ignored, so we had to bake-in multiline support.

It’s 2013. Other game libraries can do so much more, so why is PyGame so crippled? Well, maybe it’s because Python isn’t apt for game development. With PyGame and its dependencies, we found it impossible to run or build the game on OSX or Windows. Linux is an extreme minority on the desktop market. Gamers do not use Linux on the desktop (yet). Our game, as a result of using PyGame, is limited to Linux. Other languages, even Java (LOL) are faster and other libraries are better.

Of course, the merit of PyGame is that it is open-source. Unity, while faster and more powerful, costs quite a bit of currency. So we could make PyGame better. But when something as simple as a clickable button requires a complete implementation, and the only target platform comprises less than 2% of desktop computers, why bother?


The Most Adorable Feedback

When developing any type of software, particularly a game, it’s imperative that you get user feedback. Your target audience telling you whether or not your product stinks can have a huge impact on its future success. It’s sort of like debugging, but you’re debugging the human interaction, not the underlying code. For most games, play-testing involves a general audience. But how do you gather meaningful feedback for a children’s game?

It turns out that having kids play the game is a great way! This past Wednesday, part of the Fractionauts development team (including me) traveled to the Allendale Columbia school in Rochester, New York, and let the fourth grade students critique our in-progress math game. It was one of the more memorable experiences of my college career (so far), to say the least. The kids were a delight to talk with. An intelligent and inquisitive bunch, they had many positive things to say about our game and gave us some helpful tips to make it better.

This is our current game interface:


While it is functional, there are certainly some things to be desired. In general, the kids needed a bit of guidance to figure out what they needed to do to win. A major piece of lacking functionality (as of the current commit) is feedback when an incorrect answer is given; there is none. This was the most common complaint from the children, with the lack of contextual help being the next-most popular. We think both of these things can easily be implemented in our time frame.

Something a little more difficult to code is a way to account for differences in skill levels among the children. While it was a good challenge for the majority of the kids, a couple found it trivial and a couple found it impossible. While we can’t make it perfect for everyone, we’d like to fine-tune the question difficulty, thereby increasing the learning potential.

We’re far down the development road onthis great project. Getting valuable feedback from intelligent children at a breathtaking school has made this journey even more enriching.


A Simple State Machine with Python

Developing Fractionauts for the XO is quickly becoming one of my favorite things. Git(hub) makes it ridiculously easy for our team of 6 to all contribute and minimize destruction of each-others’ work. We’ve come quite far in the past month, rising from a paper concept to a working executable with a menu system.

Like almost all games, ours requires a state machine. It is simply a variable that determines what the game is “doing,” i.e. whether the user is on the main menu, help screen, or playing. From this, we can easily determine appropriate things to render and events to listen for, hence, a state machine.

With PyGame, we’ve implemented this with an if/else if block. In this case, the state is different than the “state” of being paused or un-paused. In our implementation, being paused is a separate variable, allowing the game to be paused regardless of the screen we’re on.

It may seem simple, and in our case, it is. But without this concept, video games would be nigh impossible to program.