Se nao quiser receber este tipo de mensagens queira por favor informar-nos atravas do contacto de email geral incluido na pagina “Contactos” do nosso site vatranquilo.com . A sua mensagem devera conter a palavra ANULAR no assunto. Obrigado.

Sugiro uma alteração:

Podiam começar a incluir perguntas de cultura geral que teriam que ser correctamente respondidas para que o e-mail fosse removido. Assim continuava a ser difícil fazer o opt-out, mas pelo menos podia ser que fosse interessante!

E agora cá vou eu adicionar um filtro para o domínio atm-sgps.pt…

Para os mais apressados, as conclusões mais imediatas são bem ilustradas pelas imagens seguintes:

Os resultados completos do inquérito, que agora se encontra encerrado, podem ser consultados aqui:

https://www.survs.com/results/XIXME1XP/FIW9EEF052

Convém ressalvar que a amostra é muito pequena (pouco mais de 200 respostas) e os resultados são seguramente muito enviesados. Encarem-nos como uma curiosidade e não como dados com relevância estatística.

Para quem quiser explorar os resultados em detalhe e fazer as suas próprias estatísticas, os links abaixo disponibilizam os resultados do inquérito em Google Spreadsheet.

• Sumário dos resultados
• Respostas individuais

Até encontrar esta situação, todos os casos com que me tinha deparado eram sempre causados por uma colecção static que não estava a ser devidamente mantida. Esta situação, é ligeiramente diferente, no sentido em que a colecção em causa não é mantida directamente pela aplicação, mas sim pelo SWT. É um problema conhecido como “Lapsed Listeners” e está bem descrito aqui:

http://www.javaworld.com/javaworld/javatips/jw-javatip79.html?page=1

Resumidamente: lembrem-se sempre de remover os listeners que já não são acessíveis, ou então implementem-nos com uma WeakReference.

Basicamente queria que em vez de ser invocado o executável que lança a JVM fosse primeiro chamado um shell script para fazer umas validações antes de chamar o executável. Pareceu-me que a forma correcta de o fazer seria editar o ficheiro:

Info.plist

dentro do application bundle, nomeadamente a propriedade:

CFBundleExecutable

que como o próprio nome sugere, indica qual é o executável que deve ser lançado quando o utilizador faz duplo-clique na aplicação em causa.

Infelizmente, por muito que alterasse a bendita propriedade, nada. O sistema continuava tranquilamente a invocar o executável. Aparentemente a alteração estava a ser ignorada por algum motivo.

Não foi fácil de encontrar, mas já alguém tinha tentado fazer o mesmo e obtido o mesmo resultado:

Hi,
I’m trying to customize the behavior of certain application bundles by editing the Info.plist preferences. The idea is to change the CFBundleExecutable key to point to a different file. Unfortunately, my changes seem to be ignored. — by Chadrik in Apple Support Forums

E felizmente alguém tinha respondido:

Some of those things are only read at startup or logiin, hence no change will happen until you logout or restart. — by BDAquain Apple Support Forums

Enfim, só foi pena as horas perdidas… as caches são umas gajas lixadas… sobretudo quando não se sabe que elas existem

Mas ainda assim, não há quem me convença que a coisa está mal feita… seria assim tão difícil ao leopardo, no momento em que guarda o ficheirito em cache registar-se na FAM (ou no kqueue que parece ser a alternativa em Mac / BSD…) para receber notificações de alteração?

Um exemplo prático é calcular o valor de uma encomenda em que o preço unitário varia (progressivamente) com o número de unidades encomendadas.

Está aqui explicadinho como é que se faz, mas para referência rápida ficam as anotações principais:

=SUM(IF(IF(B$5>=F6:F10,F6:F10-F5:F9,$B$5-F5:F9+1)>0,
IF(B$5>=F6:F10,F6:F10-F5:F9,$B$5-F5:F9+1),0)*G5:G9)

em que a tabela com os escalões está em F5:G10 e o número de unidades cujo valor se quer calcular está em B5.

… como diria alguém conhecido, é por isso que “uma coisa é uma coisa e outra coisa é outra coisa”.

Porto: Cidade Linux, Cidade Tecnológica

e cá está a prova de que estive lá…

http://groups.google.com/group/ptjug-emprego/msg/55aba884f854c500

http://blogs.fe.up.pt/mpadilha/jobs/

O que é se faz a uma coisa destas? A solução parece óbvia: “alteras o método instance() para devolver sempre um objecto novo”, efectivamente desfazendo o comportamento de singleton. Ok, funciona, mas e se o impacto em termos de performance for demasiado elevado? O que fazer quando se pretende manter o comportamento de singleton, mas ao nível do Thread, em vez de ser ao nível da JVM?

A resposta é substituir as variáveis existentes que guardam informação de estado por outras do tipo ThreadLocal<T>.

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

Ok, perfeito, não é?

Hmm… quase. Funciona bem se a criação dos threads for feita exclusivamente “antes” da primeira utilização da classe. Dessa forma cada thread inicializa a sua própria cópia uma só vez e trabalha com ela daí para a frente.

Mas e se forem necessários vários níveis de multi-threading, alguns dos quais “depois” da primeira utilização da classe? De acordo com a forma de funcionamento das variáveis ThreadLocal, cada thread filho teria uma instância nova, o que pode corresponder a esforço desnecessário e, dependendo dos casos, ter um impacto significativo no desempenho.

O nome diz tudo:  InheritableThreadLocal<T> é uma subclasse de ThreadLocal<T> que permite herdar a instância do thread pai se ela existir.

 This class extends ThreadLocal to provide inheritance of values from parent thread to child thread: when a child thread is created, the child receives initial values for all inheritable thread-local variables for which the parent has values. Normally the child’s values will be identical to the parent’s; however, the child’s value can be made an arbitrary function of the parent’s by overriding the childValue method in this class.

Agora sim, perfeito.