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.

Enhancing Toshiba Eco Utility

Some days ago, I made the first commits of a new script of mine.
I bought a Toshiba laptop, and found that the program "Toshiba Eco Utility" (for Windows only) allows one to choose an option called "Peak Shift". This allows you to reduce energy consumption when the energy costs more, by relying on the battery.
This is handy, but it is not practical to configure in details. It supports only 4 time spans, it does not support some"intelligent" rule like "every Saturday and Sunday, including national holidays".

So, I wrote this small ruby script to support some more option. The script does not actually modify the settings: instead, it produces a .reg file. This .reg file must be imported via regedit.exe (double clicking on the file and saying "yes" is enough), but then the "Peak shift" settings are just fine.

It does not overcome the 4 periods limitations... it seems like it is not overridable at all. You have to run this about once in a month in order for the settings to be perfectly suited to the current month.
In the next days I'll enrich this post with further details, and I'll improve the script a little... in the meanwhile if you want to try, go to https://github.com/cvicari/teco_autosettings

winlocalepurge - removing undesired localization files in windows

A short blog post just to announce a recent work of mine.
I just published on github a short ruby script, whose aim is to remove undesired localization files from installed programs in windows, as of my thougths expressed in an older post.
As this program is quite dangerous, I will never make a GUI for this, and I'll always keep it constrained to command line usage, so that it will never be too easy to make damages to your system!
Anyway, I hope that someone will enjoy it. My first attempts on personal systems have been satisfactory, although I know that on modern systems sparing some hundred Mb is not so useful.
If you enjoy it, please let me know!

Choosing a JavaScript logging frameworks

I've been recently writing some web-based javascript application, and found myself confronting with the problem of choosing a proper way of logging, in order to understand what happens to the application itself (potentially, even on someone else's PC). There are many frameworks around and many persons had the same problem, now I want to share my experience. Due to node.js being very popolar, it's quite easy to find something that works with node.js but is not so suitable to a web application, so this quest has become a bit more difficult.

After some crawling, I chose to test:

1. log4javascript - http://log4javascript.org;
2. stritti log4js  - http://stritti.github.io/log4js/;
3. loglevel - http://pimterry.github.io/loglevel/.

The first one, log4javascript is really easy to setup and it is nice, as it provides you with complete capabilities and a nice custom GUI, that's really independent from the browser.

It does not preserve the original code's line numbers, this is quite uncomfortable.

The second one, stritti log4js, is also very complete, is similar to log4j and is very flexible. It is not so easy to setup, and I found it to do much more things than I really needed.

The third one has been my choice - it is trivial to setup, the library is only 3Kb in size, and does only what I finally realized I was really looking for.
It fully integrates with the browser's console window, so you have to use that one, but modern browsers have quite a good console window so this is good. It does not break on older browsers, although in these cases it does not log anything.
It completely preserves original line number - this is a really important feature.
So, I chose the third option, loglevel, and even after having worked with it I really recommend it for basic scenarios.
If you want to redirect logging elsewhere, the other two choices are really fine.