Just wanted to let you know about my Android blog, Buzzing Android. I am posting more often there
Over the last many months, I have been working on my social board gaming app for Android.
I am proud to announce: Partia for Android
Partia is a fun place to play your favourite games against your friends.
Partia is a free multi-game app that allows you to play a variety of classic turn-based games against your friends.
- Reversi (Othello)
- More coming soon!
Link Partía on to Android Market: Partia on Android Market
One of the nice features of developing a project with Django’s development server, is the server’s ability to restart/reload the project if its source has been modified.
I wanted to accomplish the same thing for an arbitrary Python program, and thus wrote a script,
SourceChangeMonitor, to monitor a Python program for changes in the source code, and restart it when a change is detected.
Download: SourceChangeMonitor.py, a Python source code monitor
To make it work with your Python project, you have to edit some constants:
# How often should we check for changes (in seconds) POLL_INTERVAL = 1 # Which files should be monitored for changes? # Here, we deliberately exclude files beginning with a dot (.) FILE_PATTERN = r"[!.]*.py" # Which directory is the root of the source files? ROOT_DIRECTORY = r"/home/jesper/projects/SourceChangeMonitor" # Entry point program to run PROGRAM = r"test.py"
POLL_INTERVAL defines how many seconds should pass between each check for changes. 1 second is fine for development scenarios.
FILE_PATTERN determines which files of the project should be monitored for changes. The pattern in the example chooses all files with the extension
.py, that do _not_ start with a dot.
ROOT_DIRECTORY sets the top-level directory of your project.
PROGRAM is the entry point program to your project. (The file you would normally execute to run the project)
Normally, there is no need to edit the first two constants, but
PROGRAM should be set to match your project.
With the setup complete, you now run your project by running SourceChangeMonitor.py (or whatever you decide to call it )
I wanted to make my laptop running Ubuntu automatically mount a Samba share whenever it connected to my wireless home network. I quickly discovered the
/etc/network/if-down.d folders which contain scripts that are run whenever a network interface is started or stopped.
I devised the following simple scripts to mount and dismount the share when needed:
#!/bin/bash if [ "$IFACE" = "<INTERFACE>" ] then if iwconfig|grep -c <SSID> then sleep 10s mount -t smbfs <SHARE> <MOUNT-FOLDER> -o username=<USERNAME>,password=<PASSWORD> fi fi
#!/bin/bash if [ "$IFACE" = "<INTERFACE>" ] then if cat /etc/mtab|grep -c <MOUNT-FOLDER> then umount -t smbfs <MOUNT-FOLDER> fi fi
In order for it to work with your local network settings, you have to replace the following values:
<INTERFACE>: Your wireless network interface. Normally
eth2or the like. Can be found by running the
<SSID>: The SSID of your wireless network.
<SHARE>: The Samba share that you want to mount, e.g.
<MOUNT-FOLDER>: The path to an existing empty folder in which to mount the share.
<PASSWORD>: The username and password to use when connecting to the share.
Note the 10 second sleep command (
sleep 10s) run when we want to mount. This is due to the fact that
mount cannot mount a network share immediately after connecting to the network. This bugged me for quite some time, but is easily solved by waiting 10 seconds before trying to mount the share.
Several times before, especially while developing applications for Android, I have found myself (re)implementing TCP clients and servers in different programming languages, most notably Java for Android clients and Python serverside. Everytime a new message or parameter had to be implemented, this would mean writing (or at least copying) a lot of boilerplate code… twice – once for each language.
In order to make things a easier for me, and honor the DRY (Don’t Repeat Yourself) principle, I came up with the idea for a way to define network communication between clients and a server regardless of the programming language(s) in which the client and server would be implemented.
Therefore I am proud to annouce the Network Protocol Specification Language (or NPSL), currently in version 0.1. This early version is capable of outputting both a client and a server in Python (of course, more languages will come later – I am currently working on Java), who are perfectly able to communicate through the defined network protocol.
I intend to release the code into public domain, but I have yet to find an appropriate license for it.
If you are curious to take a look, the code is publicly available on GitHub: https://github.com/jesperborgstrup/NPSL
An example NPSL-file looks like this:
mediaplayer 100 ( => 10 set_volume (Volume, byte) => 20 get_volume <= 20 get_volume (Volume, byte) => 150 get_playlist <= 150 get_playlist (Tracks, strings) )
The resulting protocol is defined primarily through messages, which follow the format:
<direction> <id>, <name>, [<parameters>].
The direction is either
<=, meaning “from client to server” and “from server to client”, respectively and defines which way the message goes. (There is also a
<> direction, meaning both ways). The id is the internal value that actually gets sent through the connection, name is, well, a name for the message, and finally a message has a (possibly empty) list of parameters, where a parameter consists of a name and a data type.
Seven data types are possible as of this version: Byte, integer, list of integers, float, string, list of strings and arbitrary binary data.
Messages can be arranged into modules (which can also contain other modules) as the mediaplayer in the example, which allows for easy distinction of messages in the message handling code.