JWS debugging

How to debug applications launched using Java Web Start

Just set the following parameter:

set JAVAWS_VM_ARGS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8200

where address specifies the port on which you can connect for remote debugging. Then launch your application using javaws yourfile.jnlp

Outra alternativa:

1.1) Using version 1.5.0 or 1.6.0.

Use the Java[TM] Control Panel to turn

on console and tracing to a file. By default the file will be put in log directory under $deployment.user.home. (for per-platform definition of $deployment.user.home see the Deployment Guide )

Turn on additional tracing messages by adding the following property to the deployment.properties file:
deployment.trace.level=all.

You can also use specific options delimited by "|", all is the same as:
deployment.trace.level=basic|cache|net|temp|security|ext|liveconnect.

The last 2 in the above may only apply to Java[TM] Plug-in and have no effect on Java Web Start apps.

Autenticar aplicação Java

Em algumas situações, é necessário que uma aplicação Java seja autenticada por um certificado digital para que tenha, por exemplo, acesso ao disco local ou mesmo à rede.
Ora, isso é exactamente o que acontece ao executar uma aplicação com o Java Web Start.
Então, para assinar os ficheiros JAR da aplicação (com um certificado self-signed) existe aqui um pequeno guia.

Se for uma aplicação JWS (Java Web Start), no ficheiro JNLP devem introduzir o seguinte para que a aplicação deixe de ter restrições de segurança ("sandbox"):
<security> <all-permissions/> </security>

Java Web Start

Despertei para o Java Web Start (JWS) quando surgiu o desafio de migrar uma das nossas aplicações Java (MobileIPCentrex, consola de operadora) de forma a que fosse integrada no web browser ou invocada remotamente, para evitar instalações de software no cliente e controlo de versões...

Com o JWS é possível executar uma aplicação Java através de um link numa página web. O link aponta para um ficheiro JNPL que descreve a aplicação alojada num Web Server, fazendo com que o JWS descarregue, coloque em cache e execute a aplicação.

A execução da aplicação é independente do web browser (ao contrário das Java Applets), e o utilizador pode eventualmente executar a aplicação off-line, desde que esta esteja ainda em cache.

Por ser uma aplicação "on-line", existem alguns constragimentos de segurança, por exemplo no acesso ao disco local e à rede (aplicações serão executadas num ambiente limitado - sandbox). No entanto, a aplicação pode ser autenticada com um certificado digital e, se o utilizador o aceitar, a aplicação poderá aceder ao disco local e à rede.
Ver este post para assinar aplicações com um certificado self-signed (para testes).

NDrive S300

I recently brought the NDrive S300, released at the end of 2007 with the tag "the first portuguese mobile phone" (even if it is based on a form made in China, and the only thing portuguese being the GPS and camera software).
But in fact is way more than just a mobile phone... It's a PocketPC (Windows Mobile 6.0) with GSM, GPRS, GPS (SIRFIII), 802.11 and bluetooth support (just to mention the network features).
For some weeks, I tried to look for a GPS client. I was very teased by the features on TomTom Go520, oh and NDrive G280R has navigation with satellite pics available for a couple of cities, but frankly it was a bit confusing for me to give away €250~€300 for something that I would use once, twice a week, or mostly during road travels (another drawback of those popular navigations systems is that they are made for the road, and not for the off-road). Another issue that I give importance is how to keep the maps up-to-date...
So, I ended up with the choice of buying a cheap GPS or, instead of a top GPS, get my hands on a PDA with GPS! Since at the time my mobile phone was already old-school, it seamed the perfect choice...
So the NDrive S300 was the winner! And how lucky and happy I am! =)

PS: check this blog for some more user experience on NDrive S300 (in portuguese)

RoR: script/console autocompletetion

script/console is a very useful tool when building your RoR application.
And one of my favorite features is the ability to autocomplete the method name (just by pressing tab).
This gives me a kind of Ruby on Rails IDE taste, since when I'm at Windows I (happily) use Notepad++ (which has a ruby plugin) to code.

multiples screens with SSH ("screen")

When remotely accessing a host with SSH, you may (frequently) want to run a shell command, track the output, leave a console free for more commands input, and leave everything running even after you close the remote connection.

When working locally, you can count with the multiple screens (ctr+alt+[0..9]).
Remotely, you can simulate that same behavior with the command "screen".

> screen -h
Use: screen [-opts] [cmd [args]]
or: screen -r [host.tty]

Options:
-a Force all capabilities into each window's termcap.
-A -[r|R] Adapt all windows to the new display width & height.
-c file Read configuration file instead of '.screenrc'.
-d (-r) Detach the elsewhere running screen (and reattach here).
-dmS name Start as daemon: Screen session in detached mode.
-D (-r) Detach and logout remote (and reattach here).
-D -RR Do whatever is needed to get a screen session.
-e xy Change command characters.
-f Flow control on, -fn = off, -fa = auto.
-h lines Set the size of the scrollback history buffer.
-i Interrupt output sooner when flow control is on.
-l Login mode on (update /var/run/utmp), -ln = off.
-list or -ls. Do nothing, just list our SockDir.
-L Turn on output logging.
-m ignore $STY variable, do create a new screen session.
-O Choose optimal output rather than exact vt100 emulation.
-p window Preselect the named window if it exists.
-q Quiet startup. Exits with non-zero return code if unsuccessful.
-r Reattach to a detached screen process.
-R Reattach if possible, otherwise start a new session.
-s shell Shell to execute rather than $SHELL.
-S sockname Name this session .sockname instead of ...
-t title Set title. (window's name).
-T term Use term as $TERM for windows, rather than "screen".
-U Tell screen to use UTF-8 encoding.
-v Print "Screen version 4.00.02 (FAU) 5-Dec-03".
-wipe Do nothing, just clean up SockDir.
-x Attach to a not detached screen. (Multi display mode).
-X Execute as a screen command in the specified session.

ActiveRecord error : duplicate key violates unique constraint

I'm currently working (and still exploring) Ruby on Rails for a VoIP services management web portal project.
I frequently stumble upon some doubts about the correct RoR way of doing things - I admit, I tend to do it java style =( - but this one was really driving me crazy...
When creating a new record for a table named "groups", the ActiveRecord was hitting me with the following exception:

«ActiveRecord::StatementInvalid: RuntimeError: ERROR C23505
Mduplicate key violates unique constraint "pk_groups"»

after some "googlening", I manage to solve this. Apparently, the problem was with the expected sequence, from RoR, for that table "groups".
Since the postgresql was returning the correct next sequence number:

# select nextval('groups_group_id_seq');
nextval
---------
17
(1 row)

it was only a matter of resetting the ActiveRecord sequence (on script/console)
>> ActiveRecord::Base.connection.reset_pk_sequence!('groups')
=> "17"