FOSSwire

So maybe you have a backup solution in place and running periodically to make sure your databases are safe. At any point in time if the system fails, you're prepared. But what if, right before a backup, an unruly visitor finds an expolit on your application and wipes out a few tables? Your "backup" is then no longer a backup you can rely on.

How do we fix this? Versioning. While popular source control management systems, such as Subversion, Git, and Bazaar, are normally used for collaborating on code together, they can also be extremely handy with backups.

In this example, we'll be using Bazaar, but everything can easily be applied to Git or Subversion. Or CVS, but... let's not go there.

To start, find a directory to store your backup repository. I personally use /root/mysql. Inside that directory, start up your repository:

bzr init

Setup complete! But we haven't actually done anything yet. Next, make a backup script and fill it up:

#!/bin/bash


# cd to the script dir to make sure files are put here

cd "$(dirname $0)"

DATABASES="$(mysql -Bse 'SHOW DATABASES')"

# loop through the databases

for DB in ${DATABASES[@]}

do	

    mkdir -p "$DB"	

    TABLES="$(mysql $DB -Bse 'SHOW TABLES')"

    # loop through the tables in the database

    for TABLE in ${TABLES[@]}

    do

        mysqldump "$DB" "$TABLE" > "${DB}/${TABLE}.sql"

    done

done

# version control

bzr add

bzr commit -m "cron backup"

Save that backup script inside the repository directory you just created. Mark it as executable, and add it to a system cron job. You may also want to tweak the mysql and mysqldump lines to add a password, or more simply, use a .my.cnf file in your home directory:

[client]

user = root

password = PASSWORD

Every time the script is run, it will look for all databases on the server (line 6) and make a directory for each of them. It will then look through each database individually (12) and write a separate .sql file for each table (16).

Finally, any new tables dumped will be added to the version control system (21) and the revision will finally be committed to disk (22).

Every change detected between backups can be reverted. Say the 'posts' table in the 'wordpress' database was fine at revision 17, but something went wrong on version 18. Let's revert the table back:

bzr revert -r 17 wordpress/posts.sql

That will reset the SQL backup back to revision 17, but not the database. You will still need to put the data back into the database:

mysql wordpress < wordpress/posts.sql

Again, the mysql command may need to be tweaked before using. Also, the 'posts' table will most likely need to be cleared before importing the data again.

That's it! I recommend running the cron job at least every six hours to minimize any potential data loss. If the repository is made on site, be sure to back up offsite as well. As with any backup script, your mileage may vary, and we cannot be held responsible in the event of a failure. You are encouraged to modify the script for your own needs.

While it might seem a little of a mundane task, counting the lines of code in your programming projects can be a useful thing to do, and provides you with interesting statistics.

Cloc is a Perl script written to allow you to do just that. Download the script, and then from a command line, you simply pass it a directory of source code, or a single file if you wish.

$ perl cloc.pl /path/to/code

Cloc is more than just a tool for counting the number of lines in the file, it is more clever than that. Cloc detects the programming language if it can, and then shows you the number of blank lines, code and comments of each file.

With a single file, Cloc might give output similar to this:

As I've mentioned, however, Cloc's real strong point is when you point it at a directory or several directories of source code.

Quite frankly, I think this is a pretty indispensable tool for any programmer interested in getting statistics on their code, especially when you want an overview of the whole project.

Cloc can be downloaded from here. The Perl script version should work on any operating system where you have a working installation of Perl. Windows users can download the pre-built exe as well.

There are two kinds of fast in programming: Fast to code and fast to run. 3D applications and games are known to be speedy. But the time it takes to write and understand the code behind it? Not so much. On the flipside, many abstraction layers designed to make coding easier usually aren't very efficient. So where's the median?

Meet Pyglet for Python. Pyglet, as described by their website is "a cross-platform windowing and multimedia library for Python." While it is certainly that, there is so much more that Pyglet does. The key focus of Pyglet? OpenGL.

With many windowing libraries, just opening a window is complex, let alone one using OpenGL. With Pyglet, it is just one line:

window = pyglet.window.Window()

That simple method will open a fully-initialized OpenGL window. You don't have to accept the defaults, so alternate properties could be specified, such as a window caption and size.

Pyglet is also purely event driven, meaning that all events (keyboard, mouse, window, etc) are caught and sent to your application functions. In fact, only two more lines are needed to make the above code fully functional: an import statement and a run(). Of course, your application will just sit open with an empty window, but hey, it's a start!

One of the great things I like about Pyglet is that it allows a seasoned OpenGL programmer to still work directly with it. If you want to go beyond what Pyglet provides and use glTranslatef(), you can. As long as you have pyglet.gl loaded, you can use OpenGL inline with the rest of your code:

glLoadIdentity()
glTranslatef(10.0, 20.0, 0)
batch.draw()

The only downside to this? If you want to write true 3D software, you'll still need to know OpenGL. Maybe that's an upside to some. Pyglet is not (yet) able to handle 3D on its own, meaning that if you want to write an application using only Pyglet functions, you're restricted to a 2D plane or an orthographic projection.

That said, there are a plethora of features included that all are useful in some way. From a two-line framerate display and limiter and time scheduling, to full text and media support, almost everything needed for a game-development environment is there.

Both Python and OpenGL are known for having extremely well-written documentation. Since Pyglet is a little bit of both, it should have good documentation as well, right? Actually, it really does. The level of documentation and examples provided with Pyglet is enough that you could sit on a plane for five hours with only a text editor and documentation and program without ever needing to look something up online. Even the yet-to-be-released Pyglet 1.1 already has an phenomenal amount of provided documentation.

If you're looking to start a new Python project or game but just didn't know where to begin, Pyglet is your building ground. I'll personally admit: In one of my projects, I have switched between programming languages four times before finally finding Pyglet. I rewrote the entire application in less than a week, whereas it took a few months to develop the other versions.

Give it a try, even if you're not into graphics or games. You'll love it.