Using AutomateIt & Pressy Plugin, without Pressy

I see that since when we began using touch phones, without a real keyboard, many of us had the problem of doing complex things without having to look at the screen. This is also what motivated the authors of pressy. This is a nice little device that can be plugged into a phone's audio jack.
Pressy is not so cheap, 15$ for something so simple can be considered not cheap...
Anyway my problem with pressy, is that I find it not so useful as you cannot have both pressy and the headphones plugged together. Additionally, my main point with such a thing is that I would really want to use the phone without looking at it, when I walk with my phone in my pocket and the headset plugged.

I found quite a simple and cheap solution for Android. I make use of AutomateIt (both free and paid versions are ok) and its pressy plugin, along with a headset that has a button as most phone headsets as of today. The pressy application is not needed, nor the real pressy button.
When you plug the headset, AutomateIt asks you what you plugged in, and you tell it that's a headset to use as pressy.
Now, I defined some nice rule... a short press, open/play/pause my podcast player... two short presses, the radio... long press short press, low volume... long and long, high volume.
This is really nice... you can go along with the phone in your pocket, and do some operation on it without looking nor touching it.
The results are not so perfect, as you have to practice a bit in order to use the right length for pressions, and the right distance between them... anyway that's something I have been looking for for some year, at least since I abandoned my old nokia phone, plenty of keys that I could reach while in the pocket, without looking at anything.
I hope that someone else likes this solution... I really like squeezing a bit more from my plain old hardware.

Protecting critical files in SVN by means of "needs lock"

In my company we (still) make use of the SVN version control system. Yes I know this is considered obsolete, anyway I have to make use of it losing the advantages of modern VCSs, so I try to get the best from it.
We have a problem that arises for a variety of files. Sometimes someone wants to modify an important project file for experimenting or for local purposes, knowing in advance that he will not want to commit the file to the repository.
Tipical files are:
1. eclipse project files: when a developer wants to circumvent a local problem such as some automatic formatting that he temporarily does not want to take place;
2. portlet.xml file: while developing portal projects, you end up defining a lot of portlets. Deploying a lot of portlets slows down the local development a lot, so you want to have a slimmer portlet.xml file by commenting all unneeded pieces;
3. hibernate.cfg.xml: increasing verbosity and changing options in order for performance investigation and debugging purposes.

In these cases, if you want to protect the files, you could revert to using authorizations mechanisms, or using commit hooks (see here and here for example), but I suggest a quick and easy way to
obtain something that's enough in my cases. You protect the file by means of setting the "needs lock" property on the critical files plus a small "local" trick.
This way, every developer must obtain a lock in order to modify the file.
But you instruct every developer to avoid obtaining the lock. Better, they go to the local file properties and change the "read only" flag to false (valid both for windows and linux). So they can locally modify the file and every IDE will not complain.
But, should they mistakenly commit the file before deciding carefully what to do, the file won't be committed because they don't own a lock!
And the developer will understand and has the opportunity to decide what to do, in most cases, by avoiding a commit and reverting changes.
Summing up, the steps are:

1. locate single files that developers often modify for local development purposes, plus very important file that are still meant to be public modifiable;
2. for each one of this file, use your favorite SVN client in order to set "needs lock" to true, and commit the "needs lock" property modification as well;
3. every time you want to modify some of the files selected at point (1), instead of taking the lock, navigate to the physical file on the filesystem and set it to "readwrite";
4. modify the file as you want;
5. if you do not remember to revert changes and it happens to you to commit the file anyway, the system will abort the commit operation;
6. because of a missing lock - you still can acquire the lock if you really want to commit the file.

Although you may think this is not optimal, please remember that this procedure is quick and simple and does not involve administering SVN on the server side, so I strongly suggest it as I saw this working quite well in practice.