Last December, I was bestowed with the opportunity to get feedback about a children’s game I helped make, Fractionauts, from the game’s ideal demographic: 4th grade students! Last week, I was again graced with an opportunity to return and gather more feedback. Within that lapse of time, a new team of students forked (Git jargon for “made a copy of”) Fractionauts and improved it in pretty much every way possible.
Their fork’s improvements include, among other things
- Totally overhauled graphics (with a theme evocative of NES/Super NES games).
- Expansive rendering optimizations that make smooth animations possible, even on the XO-PC.
- Sounds including ambient music and feedback/effects.
- Infinite auto-level generation, while maintaing support for pre-defined levels.
- Removed dependency on GTK.
- Improved scoring.
The kids enjoyed the game in its prior state, but they loved it in its current form. Through the magic of open-source and RIT’s IGM courses, we have created a game that helps kids learn an important skill, that they don’t despise playing. It even helps me learn!
I’m bad at fractions.
The following screenshot comparison alone should sum it up nicely.
Check out Fractionauts on GitHub!https://chrisknepper.com/2014/05/when-kids-want-to-learn/
As humans, we typically like to know that our stuff is safe, even when we can’t be near it. Smoke detectors are nice, but they typically aren’t connected to the Internet. To that end, I, along with my friends Dustin and Lance, created In-Glass. On the hardware side, it utilizes a TEMPer USB thermometer, connected to any PC running a Linux distro that supports PyUSB. On the software side, it makes use of the excellent temper-python driver by padelt, and the awesome Flask framework.
In-Glass works by serving a website using Flask. On an HTTP query to the main page, it retrieves the temperature from the device and displays it, with the background of the page colored based on the warmth. Optionally, users can enable auto-updating at an arbitrary number of seconds, as well as choose to use the philistine centigrade measurement system. The app remembers these preferences via HTML5 LocalStorage, so I’m sorry to say that if you feel compelled to use old versions of Internet Explorer, the app won’t work for you. Stop it.
The app generates a JSON API for the current temperature and the logs of the temperature for times the app was running. The app uses its own API for the front-end: The current temperature and graphing pages call the API to get the data. The excellent D3 graphing library is used to create the graphs, though I fear we have barely tapped its potential in this regard.
Another neat feature of In-Glass is its method of generating temperature logs. A separate thread is created which is responsible for logging the data every 15 minutes. Logs are stored as CSV files, because the files are hella small compared to JSON. But outputting the CSV as the API would be stupid as hell, so when a request is made to a particular log, the app parses the corresponding CSV file and generates appropriate JSON.
#Output logs for a given device and day as JSON
def json_history_output(device, year, month, day):
file = build_log_path(device, year, month, day)
history = 
with open(file, ‘r’) as log:
log_read = csv.reader(log)
for row in log_read:
if(len(row) > 0):
A similar app, PiThermo, was created by wowo last year. We based certain parts of In-Glass’s architecture on it. It’s a great program, but there are a few key differences between it and In-Glass…notably:
- PiThermo uses a Dallas digital thermometer, which are significantly cheaper, but require an adapter or pin breadboard to connect to the PC. The TEMPer connects via USB.
- PiThermo stores logs in a Mongo database, rather than CSV files as In-Glass does.
- PiThermo doesn’t require any drivers and reads the temperature from the system bus, as far as I can tell.
- In-Glass has an auto-updating temperature display, while PiThermo doesn’t, as far as I can tell.
- In-Glass uses D3, while PiThermo uses Google Charts.
RIT, like many other universities, sets aside a day for its students to prepare for final exams.
Reading day, possibly known in español as “día de leer,” relieves most students of lecture/lab duties for the day. But sometimes, we need more time to prepare. And buffalo chicken pizza. And music.
As for the pizza, a decadent offering included buffalo chicken pizza sauced with bleu cheese, traditional pepperoni, plain cheese, and even a vegan option. Personally, I think veganism is incredibly stupid (primarily because meat is delicious, and secondarily because of these things), but everyone deserves pizza!
Because of the work done at HSH, I was able to use reading day to relax. And longboard. Longboarding rules.https://chrisknepper.com/2014/05/homestretch-runner/
There’s no time of year quite like this. Spring is in the fullest of swings here in the swampy enclave of New York we call RIT, and nothing says Spring like “software sprinting.” Many associate Spring with baseball matches, grilling sessions, and a statistically significant increase in the presence of beautiful women. Of course, RIT has no shortage of any of those, (despite popular rumors to the contrary), but we also have some things few other places do…
- An uncapped mirror of every notable recent Linux and BSD release.
- The country’s first minor in Open Source and Free Culture.
- A small cafe with the world’s nerdiest name: Ctrl Alt Deli.
Of course, hand-in-hand with that sort of notoriety is the hard work students here endure in the pursuit of their degrees. We are currently in the final week of classes. Project due dates approach with rapidity unforeseen by anyone. Semesters suck. SIS sucks. Finals loom. So what better way to relieve the stress than some good old fashioned coding?
Oh, actually, this is an assignment for a class. But I just said it was stress-relieving! Ah, that’s the hypocritical beauty of coding. It’s work, but it’s also fun! So the assignment is to originate 10 tickets on GitHub and close 5 of them. Let’s get crackin’ then:
The main selling (Haha, selling. Because it’s free.) point of in-glass is live temperature monitoring via the web. Another handy feature, though, is the generation of temperature logs. It would sure be nice to be able to see the what the temperature was at a particular time in the past, assuming the in-glass node was running at that time.
The neatest thing about USB ports is that there are usually more than one of them on a mainboard. Noting that, in-glass should support more than one TEMPer thermometer.
Perhaps, in some less-civilized countries, they use silly logical systems to measure things. Systems that are so logical, we can’t really come up with a good reason to not switch to it (other than budgetary concerns). I’m of-course referring to centigrade, a.k.a. celsius, a.k.a. Canadian Mercury. I recognize that some of those kind people may use in-glass, so we should support that unit of temperature. We already had an option to switch units (and it remembers what unit you picked for next time, because localStorage). But that required a manual refresh, and those are so 2006. Clicking a temperature preference should instantly switch the displayed temperature accordingly.
We mentioned earlier that we’d like to be able to record the temperatures. Computers geeks such as myself have no trouble reading sparse log files, but what about John Everyman, a.k.a. The End User? We should read in recent temperature data and graph it all pretty-like.
What’s software without documentation? Still software, but it raises the barrier to entry significantly. I cannot recall how many programs I’ve wanted to use that I couldn’t because the documentation was shit. Yes, I said shit. A lot of documentation is shit. But my catbug library doesn’t even have any. I gotta change that.
I mean, we deserve some credit here.
Our README is saying “write me!”
In catbug’s current state, a string representing the content of the response is the only thing the callback method returns. There is a lack of other potentially useful information, like the HTTP Status Code, content-type, and so on. Ideally, the method should return an object containing these things as properties, instead of a straight string.
Swipe is a fantastic library for touch-scrolling. While carousels are a less-than-desirable user experience, there are certain situations in which they are an efficient way of conveying important information. Swipe slides the image nicely, but it would be really neat if the images were scaled down and faded when being “slid,” to give the user more feedback that they’re interacting with the element.https://chrisknepper.com/2014/05/pre-homestretch-homestrech/
A common complaint levied against older Android versions and devices is the presence of lag. The immaturity of the software combined with weak hardware multiplied by rapidly increasing user expectations equalled an inferior experience to Apple’s iOS. Using an antique smartphone today can be more painful than using an antique computer.
Yet, for all of the blame placed on the un-optimized OS and struggling hardware, another source of lag were the apps themselves. A perfect example of this is running blocking operations, such as network requests. If an app is programmed to perform such an operation on the app’s main thread, also known as the UI thread, the UI will freeze until the operation is over. In the case of a network request, it is not predictable how long the operation will take.
Obviously a frozen app is a bad user experience, so a witty developer would choose to perform the request on a different thread. The catch is knowing how to do that; fortunately, Android provides a handy class for this purpose called AsyncTask. Also helpful is the Java class HttpUrlConnection, which facilitates the request itself. Catbug is a library I developed using these classes to make it easy to make an HTTP request on a thread. Catbug creates a thread which performs a request with passed-in parameters (data keys/values, GET/POST, etc…) and returns the response to the main thread via a callback interface. It is designed to be simple to use and a lightweight addition to any (Gingerbread 2.3+) Android project.
Catbug is available on Github under the GPLv3 license. It is in need of documentation and unit-tests, which I hope to add soon!
Of course, it wouldn’t be right to pretend that this has never been done before. Other (awesome!) projects that perform similar tasks include android-async-http and http-request. They are both fantastic libraries with more robust feature-sets than catbug at the moment.
Recently, Aio Wireless, an AT&T-owned budget carrier, merged with Cricket Wireless. In fact, the first phase of the merger has already begun: Aio will be shedding its name in favor of the more well-known brand, Cricket. Pretty much everything else about Cricket will be going away, including the fact that it uses Sprint’s network. AT&T’s network is vastly superior, both because of the technology it uses (GSM), and having a significantly larger blanket of LTE.
Mergers are as American as apple pie. Since 2011, it’s been a tangled web of acquisitions. AT&T was blocked from purchasing T-Mobile by the federal government, while Japanese carrier Softbank bought Sprint, which wants to buy T-Mobile, which recently purchased MetroPCS. Perhaps it shouldn’t be surprising that the carriers continually seek to better their positions in the market. Sprint has a laundry list of MVNOs and other carriers using its network: Virgin, Boost, Ting, it’s own prepaid option, and Cricket. AT&T will now have a well-known budget carrier under its belt, which will help it compete with the likes of T-Mobile. But due to the merger, Cricket will eventually cease CDMA operations.
This turn of events carries with it some implications for Cricket customers, because they will eventually be forced to buy a new phone. Older phones typically do not have hybrid CDMA/GSM radios, so most Cricket phones are incompatible with the network switch. Luckily, I joined Aio in February because of frustration with T-Mobile’s network. T-Mobile’s LTE was fast and the super-secret $30 plan was great for a college student’s budget, but I found that I would lose the signal in most buildings at RIT. Aio’s plan offered a better network and unlimited talking for not much more dosh. That’s the beauty of contract-free, unlocked phones: if you don’t like the service, get rid of it. Aio is/was a great option because the value of the discounted rate of using the second-best wireless network in the country is unmatched.
And now it is a bittersweet goodbye to Aio. All hail the royal Cricket name. Kind of. I’ll miss the brand. The colors, the name, the website, the pretty letterhead…It’s a much more desirable brand identity than Cricket’s. I guess it doesn’t matter as long as Aio’s beast-mode $45 plan stays. That thing is schaweet.https://chrisknepper.com/2014/04/vale-aio-wireless/
An interesting behavior of developers is our propensity to join together for extended periods of time and engage in community-centered discussion about everything from Apache to xterm. These events cover a Boeing-sized variety of things, yet typically have most or all of the following: free stuff, free food, and freakin’ awesome talks.
BarCamp Rochester is no exception to this. It is a bi-annual gathering of technology enthusiasts in the Flower/Flour (Flaur?) City. Taking place in GCCIS at RIT, the event is a godsend to local devs looking to network. A week ago today, a sizeable crowd filled the atrium and surrounding rooms with a high level of energy. The talks were informative and interesting, but the real gem here was the potential to speak with people from local tech companies who love what they do.
To enjoy BarCamp, you have to love technology. You’re also supposed to give a talk, but they’re mad chill peeps that let you attend even if you don’t (I didn’t.
My senses were also serenaded by the delicious pizza. (Note to event organizers: Pizza always makes nerds happy. Always.)
I got a lot out of BarCamp for not a lot of input. That’s probably why the mandatory talk rule is a thing. It’s a great event, and one to which I hope to contribute a talk or two in the future 🙂https://chrisknepper.com/2014/04/a-bar-and-a-camp-walk-into-a-university/
Last weekend, I had the pleasure of attending PAX East in beautiful Boston, Massachusetts. Aside from the free stuff (which included a packet of Pwnmeal, the “official porridge of e-sports”), the convention was filled with some bad-ass-looking new games. Among them was “Evolve,” a title which requires no more explanation than this:
There were booths for popular titles like League of Legends and World of Warcraft, the nerdy operations of NewEgg and Twitch.tv, plus tons of cute cosplayers! The opportunity to mess with one of Valve’s upcoming Steam Machines was had with pleasure. Sweet merchandise for every title from Minecraft to Zelda to Pokemon was on sale. Every conceivable type of gaming interest was covered: tabletop, handheld, console, PC, board games, all with tailored exhibits or activities. The icing on the cake was the classic original Xbox title “Steal Battalion,” with its rare-and-expensive cockpit controller contraption available for multiplayer battles.
If you’ve never attended PAX East before, you should. Seriously. And not just because of the conference itself. The people of Boston possess a lucid candor I adore. The city itself is astonishing: everything from the parks to the public transportation to the restaurants will leave a good taste in your mouth. Perhaps the following pictures will convince you. They are a rough pictorial chronicle of the trip.
A lot of people like Python. It’s a versatile language. It can be used to write for many platforms. It has an easy-to-use package distribution system. It is used at RIT in many curricula, including Computer Science. It powers YouTube, Instagram, and Meetup.
There are developer conferences and group meetings large and small, local and national, dedicated to this wonder of indentation. This week, two of them coincided: RocPy, a monthly gathering of 585-area Pythonistas at the University of Rochester and PyCon, an annual conference which was held in Montreal, Quebec this year.
Remy DeCausemaker, an RIT professor with the FOSSbox at RIT, was lucky enough to attend PyCon. Even luckier, he held a live teleconference with us Rochesterians at RocPy:
RocPy is always a great learning and social experience. The connection to something the magnitude of PyCon is even greater.https://chrisknepper.com/2014/04/rocpy-pycon-6-28/
“Cloud” is perhaps the new “Web 2.0” in terms of its efficacy as a buzzword. Everything is moving to it, everybody wants it, and quite a few people don’t understand what it means. We better get ready, too. But both terms are actually quite easy to define. Web 2.0 can generally be defined as Internet resources (read: websites) where a significant portion of the content is user-generated. Cloud simply means using a remote computer (usually owned by a corporation) to do some type of work or storage instead of, or in-tandem with, your own computer.
The cloud is not without its problems, however. It is an abstraction of interaction with computers in the sense that it becomes a service, rather than something you “own.” There are many great options for cloud storage, and most offer a free tier with limited space. But people have a lot of stuff (as we’ll discuss below), so many will pay to increase the storage. And it may be worth it, considering that storing content in the cloud means that it is extremely safe from hard drive failure; cloud providers worth their salt always maintain redundant backups. But it also depends on trusting your files to a corporation. It depends on maintaining good security practices. It also usually requires installing non-free software, which some take issue with. Despite these potential pitfalls, the cloud can be a developer’s best friend.
We live in a world of devices, all of which vary wildly in capabilities. As an example, I might own a laptop, Android phone, iPad, and video game console. It’s now not uncommon to find the same application available on most or all of these platforms. Developing for these different platforms, including web development, creates immense implications for both developers and consumers.
15 years ago, a primary technical challenge was optimization. A significant problem back in the day was resources: conserving bandwidth, conserving RAM, conserving CPU cycles. With low-power devices, optimization is still an important component to the art of programming, but today the developer must consider device compatibility foremost. Even if the developer is rollin’ in phat stacks, livin’ on Easy Street and/or has life made in the shade, he or she still will likely have to target no less than 3 discrete platforms and is usually expected to make the experience work equally well within the limitations of each platform.
So, people have lots of stuff. We increasingly expect to be able to access all of our TV shows, pictures, personal videos, and whatever else you might be able to think of, in some form, on all of those things. So, people have lots of things. Because we’ve reached a sufficient level of bandwidth*, the Internet’s ubiquity has lent itself well to syncing our stuff to all of our things.
As a developer, this can be seen as a boon or a bad thing. On one hand, syncing files automagically means that I can begin development on one device and pick up the code on another, perhaps in another physical location. But this creates a problem: development requires the use of tools. These tools usually have configuration files that are imperative to working. Using cloud storage and very simple shell commands, it is quite easy to sync these settings between systems (say OSX and Windows).
To demonstrate, let’s take a look at the file-sharing program, FileZilla. This free and open-source (holla holla git dolla) FTP program is fantastic for fetching and uploading files, a common task for web developers. One of the key configuration aspects is the “Site Manager,” which allows saving FTP connection credentials. Because who wants to remember an array of hosts, passwords, and ports? This is driven by an XML configuration file. According to the FileZilla FAQ, this file is located in
~/.filezilla on good operating systems, and in
%appdata%/FileZilla on Windows.
I’ll use the powers of the shell and the cloud to
become Captain Planet sync this file between my OSX laptop and Windows desktop. The zero-th step is to make sure FileZilla isn’t running. If it is, it may make changes we don’t expect to the file. The first step is to create a place on Dropbox to store the file. I use Dropbox for many purposes, and I don’t want a dog-gone floating XML file in my root Dropbox folder, so I’ll create a folder inside it called “config” to store the file, using the Terminal rather than Finder because that’s hardcore, bro:
So now we need the file within
~/Dropbox/config and FileZilla obviously won’t be able to find the file if we just move it there. If we just copy it, it won’t be very synced up, will it? If only there were a way for the operating system to combine these operations. Well, thanks to the wizardry of transistors, this is possible! It is known as “symbolic linking,” and is actually a very basic command:
[bash]ln -s ~/.filezilla/sitemanager.xml ~/Dropbox/config/sitemanager.xml[/bash]
This creates a symbolic link, essentially creating a sort-of omnipotent ghost-file that mirrors the original. Changes made to either “version” will stick in both, and it will be accessible from both locations. The key part of the command is the
-s flag, which results in the link being “symbolic,” rather than “hard.” For this purpose, we don’t want those.
Now that the file is in the Dropbox, it will show up in the Dropbox folder on the synced Windows machine, with any changes I might make on the Mac side. The next and final step, you might guess, is to create a symbolic link between the Dropbox copy and FileZilla on Windows’ copy. It’s just as straightforward as in Unix-land, surprisingly. The command name is different and no flag is required, unless you want to sync a directory, in which case use
/d as a flag on Windows:
[bash]mklink “F:\Dropbox\config\sitemanager.xml” “C:\Users\Chris\AppData\Roaming\FileZilla\sitemanager.xml”[/bash]
Now we have a configuration file accessible by the program on both platforms that is synced between them. If I add or alter credentials on one side, they’ll update on the other. And this isn’t just limited to FileZilla: any development environment can likely be managed this way. Another practical, although more in-depth use-case is to sync Apache configuration between MAMP on OSX and WAMP or XAMPP on Windows.
There is one security consideration, however: Your files are now online (and on the provider’s server), so secure credentials and encryption are essential to prevent snooping eyes. As a double-security-whammy, in this case, the XML file contains FTP passwords in plain-text. Thankfully, the files are stored encrypted by Dropbox and transferred over SSL. This makes the password the weak point. Barring a bad password or malware on your device, the only third party that should be able to get at your files is your friendly federal government agency.
So embrace the cloud! You can still own your files (just kidding NSA lol) and keep them synced. It makes it a lot easier if you use different devices to develop. The time you save dealing with configuration twice can be spent building something better.
*Well, it’s enough bandwidth, but we could really do with more. Thanks to our amazing American infrastructure, being able to upload 75 kilobytes in just one second (while being promised “up to 100”) is commonplace! Bravo!https://chrisknepper.com/2014/03/developing-on-a-cloudy-day/