Some time ago, I had a bunch of CSV files that I needed to extract some data from. They were all organized into tables with related columns between them all that made me think of a relational database–and it’s really easy to query relational databases, just use SQL. So what did I do? I wrote a script that will let me query CSV files as if they were a relational database.
Memoization (yes, that’s the correct word) is a method of optimization in computer science where the first time you run a function you cache the result. After that, rather than re-doing the work, you can simply return the previous result. It’s not always perfect as you’re trading time for space.
A relatively simple script today. When I was working with Twitter data, it quickly became apparent that it’s a lot of data. So I needed some way that I could reduce the amount of data that I was dealing with while still keeping many of the same properties. To that end, I wrote a really simple script that would forward lines from stdin to stdout but would only do so a given percentage of the time.
As I’ve previously noted, I’ve been writing a fair bit recently. Everything that I write is stored in a series of plain text files (actually here and it requires the here.
Similar to my previous post about backing up Gmail, this time I want to back up my here, from there it should be easy enough to derive the one for Google Calendar.
First, we have the same setup as last time. Yes, I’m still storing the passwords in plaintext. Perhaps I’ll write up a way to avoid this in the future.
#!/usr/bin/env python
import urllib, urllib2
username = '#####'
password = '#####'
For the next step, I’m going to fetch Google’s login page using urllib. Note the service we’re sending in the POST parameters. This tells Google what we want to access (Google Reader in this case).
A little while ago, I decided to finally get around to backing up everything. I’m pulling all of my files from both my website and the servers on campus to my desktop at home, backing my desktop up to an external hard drive, and pushing those backups to an offsite location.
The former two steps are using here.
First, some basic setup. Of course, I’ve blanked out my own username and password. This definitely isn’t the best way to authenticate (storing the password in plain text? :(), but it works out well enough.
…but if you have an unfair coin, you can fix it!
Based on this post over at Lauren Ipsum, you can use statistics to make any unfair coin (defined as something that can return either heads or tails with some arbitrary but constant percent chance) into a fair one with a 50/50 chance of heads or tails.
Lifehacker had an interesting post today where they outlined a simple dice game where you have three distinct six-sided dice, each with a different number scheme. The neat thing was that the dice had a mutually intransitive set of win probabilities, similar to rock paper scissors. So if your opponent chooses first and you choose the die that has the 5/9 edge over theirs, you will win about 5% more of the rolls (1/18). What the author claims is that this results in a 98% chance of winning over the course of 20 rolls.
Since deciding that I cannot use MATLAB because of the additional addons necessary to use webcams, I have been deciding between C# and Python as the next language to try. I’ve settled on Python for the time being, using VideoCapture to connect to the webcams and Numpy to process the data. It turns out that Python + VideoCapture + Numpy is actually rather similar in functionality and syntax to MATLAB with its image processing library.
During the computer architecture class I took at Rose-Hulman, we were working with a simple assembly language that we had to compile by hand down to MIPS bytecode and that’s no fun (also there’s nothing not worth over doing 😄). So I decided to write a program that would allow for modular XML definitions of a language or translation and run it on pretty much any given code.