Novos estudos sobre efeitos da radiação de celulares no organismo humano

Qual o efeito da radiação de celulares no corpo humano? A dúvida vem desde o início da venda destes aparelhos para o público. E não impediu sua adoção em massa. O que sabemos até agora com certeza: existe radiação eletromagnética emitida, isso é a base de funcionamento do dispositivo, e que ela transmite energia. Essa energia é absorvida pelos tecidos humanos, principalmente pelo tecido cerebral. Sabemos também que as agências governamentais limitam a quantidade de energia emitida pelo aparelho. E mais, esta quantidade, para cada aparelho, geralmente vem indicada nas últimas páginas do manual. Até aqui são apenas fatos, sem sombra de dúvidas.


A limitação da quantidade emitida indica que existe uma suspeita sobre o efeito desta fonte de radiação. E a suspeita não vem do nada. A radiação eletromagnética na faixa de frequências utilizadas em celulares causa problemas, a questão é apenas qual a intensidade e tempo de exposição para que se torne relevante. Mas será que o limite de intensidade imposto pelas agências de saúde ou telecomunicações é seguro? Em outras palavras, se nas intensidades de emissão permitidas dos aparelhos, e com os tempos de utilização praticados, teria algum efeito relevante na saúde a longo prazo?

Quanto à esta última questão, a resposta da comunidade científica tem sido muito cautelosa até agora. Ou seja, não se afirma que sim nem que não. Isso pode estar mudando, veja esta notícia de hoje do portal G1 do Globo, que diz entre outras coisas:


"Os pesquisadores colocaram a radiação dos telefones móveis no mesmo nível de perigo que a emissão de gases vinda de automóveis, o chumbo e o clorofórmio, o "grupo 2-B", "possivelmente carcinogênico para humanos"."


Bom, o chumbo dos automóveis no Brasil já foi proibido (substituído pela adição de um percentual de álcool na gasolina) justamente por motivos de saúde. E o "possivelmente" do texto acima pode ser traduzido como "é um fator de aumento de probabilidade". Ou seja, o uso do celular não causaria câncer com certeza em todos os usuários, a maioria das pessoas talvez não tenha, mas ele pode ter alguma influência no surgimento dele em outras. Seria um fator de risco. E mais, sendo um efeito acumulativo e de longo prazo, talvez a humanidade não esteja exposta a tempo suficiente para fazermos as estatísticas necessárias.

E quanto a outros efeitos que não exatamente câncer? Já li sobre a radiação induzindo um acúmulo de algumas proteínas no cérebro que poderiam modificar o funcionamento dos neurotransmissores, e também sobre aumento de atividade cerebral nas áreas afetadas, e etc. É muita suspeita e pouca conclusão científica. Diante de tudo isso, eu fico no meio termo, não duvido totalmente, mas evito os excessos de tempo de ligação. (E a partir de quanto seria um excesso?) 


Seria interessante mesmo é ver o que aconteceria no mundo se saísse um estudo provando que aumenta sim a probabilidade de câncer, com dados mais confiáveis e conclusivos. Será que as pessoas abandonariam o uso destes aparelhos? Será que teria algum efeito sobre as vendas?  Será que as pessoas abririam mão da comodidade da telefonia móvel, e agora dos serviços de dados também?  Porque apenas com dúvidas e suspeitas, o uso de celulares está crescendo cada vez mais rápido!


Leia também artigo de hoje no Engadget:

Cellphones are dangerous/not dangerous: the WHO changes its mind

E no Portal G1 (link anterior):
Radiação de telefones celulares pode causar câncer, diz braço da OMS 

Review: Daemon, de Daniel Suarez

Este blog é sobre TI e não reviews de ficção científica. Mas este livro também não é um livro de ficção comum e tem tudo a ver com TI: "Daemon", de Daniel Suarez, é um livro de ficção mas com tecnologias reais e já existentes. A maioria delas é associada diretamente à TI, e citadas quase sempre de forma muito coerente (o que também é incomum). Isto porque o autor também é profissional de TI! O termo "daemon" se refere a um tipo de programa em Unix/linux que roda em background. Pelo que se conta os engenheiros do Unix escolheram a palavra "daemon" de propósito, com o significado de seres que trabalham continuamente em background, e depois se adaptou um acrônimo para ela ("Disk And Execution MONitor"). Mas a palavra também significa demônio em inglês, o que dá a conotação diabólica de como a tecnologia é utilizada na estória. A escolha do título foi genial.

O livro pode ser vagamente correlacionado com outras obras nas quais a humanidade é subjulgada pela tecnologia, como Matrix ou BattleStar Gallactica. A diferença é que a tecnologia aqui não é do futuro nem de outros planetas, são coisas que já existem, até triviais hoje em dia: bancos de dados relacionais, sistemas de respostas planejadas, scripts de servidores, redes TCP-IP, celulares, GPS, cavalos de tróia, backdoors, e muito jogo FPS e MMORPG. Tudo isso costurado para manter viva a vontade de um homem mesmo após a sua morte, influenciando a realidade concreta e as pessoas. Exatamente como e porque, só lendo o livro.

É tudo assustadoramente realista. A única licença artística aqui é a propensão dos sistemas criados de funcionarem perfeitamente como planejado. E quem trabalha em TI sabe que náo é bem assim! (ele tem uma explicação para isso na entrevista abaixo). Além da tecnologia, achei bem razoável a análise psicologica das pessoas em resposta às situações criadas: medo, inveja, egoismo, ganância, luxuria e etc, são explorados pelo autor para traçar um quadro completo de como o ser humano vai entrando na armadilha, e quando vê já é tarde ...

É tudo tão plausível que pela primeira vez em um livro de ficção me peguei tentando achar motivos pelos quais aquilo não daria certo, ou pelo menos não tão certo. Acabei achando uns quatro motivos mais ou menos bons. Não vou dizer aqui para não correr o risco de influenciar algum possível  leitor. Um deles é meu favorito, e me deixou mais tranquilo ... Mas não totalmente. A possibilidade de ocorrer é uma desgraça dessas é razoável. O que já não acho tão fácil é a desgraça se perpetuar indefinidamente e de forma cada vez mais implacável... mas deixo para cada um decidir. De qualquer modo o leitor mais cético possível vai perceber diversas situações que mostram como as tecnologias que são a base da economia, ou da própria civilização, tem muitas fragilidades. Como diz o autor, o espaço virtual tende a ser tão militarmente relevante quanto a terra, o mar e o ar. Algum dia talvez tenhamos uma força armada apropriada para ele, tal como temos a marinha, exército e aeronáutica...

A propósito, parece que o livro será lançado em filme em 2012. Como aparentemenre qualquer coisa feita nos EUA, o livro tem seus trechos de ação, sexo, intrigas e muitas reviravoltas na trama, o que o torna diversão garantida e facilmente adaptável ao cinema, com quase nenhuma mudança. Só espero que seja executado como merece. Além disso já foi publicada a continuação, cujo título original é "Freedom", mas não achei ainda versão aqui no Brasil. Pelo que vi em entrevista do autor no GoogleTechTalks, isso fecha a estória. Estou esperando. Veja a entrevista no fim do post.

Opinião: acho que vale a pena ler, pela originalidade do argumento e pela diversão. Quem estiver sem tempo pode esperar pelo filme, mas já não garanto que será tão bom.
Dados: Editora Planeta; tradução para português (bem razoável também); 431 páginas.
Página oficial do autor: http://thedaemon.com/


Observação (quase) nada a ver: Alguém aí lembra do "Daemon Tools"? Nunca mais usei... :-) Uma tecnologia está fadada a cair no esquecimento quando uma outra que é feita para emulá-la também já caiu antes... :-)

O que acontece com os desenvolvedores mais velhos?

Recebi ontem pelo twitter um link sobre como desenvolvedores "velhos" podem sobreviver no mercado. E por velho aqui estamos falando 30 anos... Durante mais de um terço da minha vida profissional em TI minha função foi desenvolvedor. Entendendo por "desenvolvedor" a pessoa responsável por projetar e escrever código, o que os americanos também chamam ainda de programador ou coder, mas aqui no Brasil esses termos tem tão pouco prestígio que foram quase banidos. E durante todo este tempo, realmente trabalhei com poucos colegas com mais de 30 anos. Havia algumas exceções, mas em geral a faixa de idade é entre 20 e 30.  Vivemos no capitalismo, e se um recém formado pode fazer a mesma tarefa por menos, a substituição é quase inevitável. Mas sempre fiquei pensando no que acontece com todas as pessoas que saem deste mercado por causa da idade. Não dá para todos irem para uma carreira executiva, e trocar totalmente de área pode ser traumático. O artigo que recebi no twitter, no link a seguir, dá umas dicas que um desenvolvedor, que queira realmente continuar como tal, poderia tentar:

http://www.exampler.com/blog/2010/05/10/old-programmers/

(Existe uma tradução em um site brasileiro, mas está tão ruim que não recomendo). Me chama a atenção o último ponto, cobrar menos pelo fato de ser mais velho, na suposição que a produtividade também será menor. Seria verdade? Infelizmente, nesse esquema em que a maioria dos desenvolvedores trabalha, eu teria que concordar que sim. A memória de curto prazo e agilidade para aprender novas tecnologias diminui na maioria das pessoas, embora não tão rápido como se é levado a crer pelo mercado. Ou seja, com 40 ou 50 anos o déficit  de memória de curto prazo e concentração seria plenamente aceitável em um ambiente de trabalho digamos, saudável, e seria compensado por outras habilidades até mais valiosas.

Mas o que se espera de um desenvolvedor na maioria dos casos é, como dito no artigo, pessoas trabalhando por mais de 10 horas por dia, as vezes virando noites, aprendendo linguagens e tecnologias de um dia para a outro. Nem é esperado que aprenda direito ou se domine uma tecnologia, basta o suficiente para dar alguma solução, entregar alguma coisa rápido, mesmo que em detrimento da qualidade e da robustez.  Por outro lado, o que se ganharia (mas nem isso acaba acontecendo) com o tempo e a experiência, que em resumo é a capacidade de fazer produtos de melhor qualidade, evitando os erros comuns, não é valorizado no mercado. Então é realmente compreensível que alguém com 33 anos, como é o caso citado no artigo, já esteja muito preocupado e pensando em mudar de área.  Trabalhar desse jeito realmente exige mais do corpo e da mente, e exige que a pessoa esteja disposta a se submeter a isso. E com o tempo acho que a tendência é se desiludir e perder a paciência com esse tipo de coisa.

Aqui no Brasil ainda existe o agravante do cargo de desenvolvedor ter se tornado muitas vezes um sub-emprego sem direito nenhum, pela contratação como PJ. Quer dizer, uma pessoa que trabalha anos a fio em expediente integral na mesma empresa, mas não tem contrato de trabalho com ninguém a não ser sua própria empresa fictícia, que geralmente é o próprio e mais um parente que tem 1% de participação e não sabe nada do que se passa. E sem os direitos trabalhistas e etc. Não que eu concorde com a CLT tal como é hoje, tinha que mudar muito na minha opinião. Mas não ter sequer um contrato formal de trabalho sim  que simplesmente reflita a realidade, acho aviltante. Claro que não sou contra alguém ser consultor independente, desde que realmente atue assim, em contratos temporários de curto prazo baseados em projetos específicos, ou em tempo parcial, vários clientes, etc. Dedicar anos em tempo integral a uma única empresa e ainda se achar consultor é ilusão.

Tudo isso me leva a pensar também em porque alguém iria afinal querer ficar na área de desenvolvimento! Quero dizer,  trabalhando nas condições descritas acima, desnecessariamente adversas. Pois também existem as exceções de empregos, os locais mais saudáveis, que valorizam experiência, a criatividade, os fundamentos de engenharia de software, a qualidade do produto, e outras habilidades mais nobres que capacidade de memorização e de ficar noites sem dormir tomando café, red bull e etc.

Pessoalmente, nunca me apeguei ao cargo de desenvolvedor, apesar de também nunca ter saído da área de TI. Já passei por desenvolvimento, análise, adminstração de dados e de bancos de dados, administração de redes, infra-estrutura, suporte a usuário, e neste exato momento, por acaso estou no desenvolvimento "em tempo parcial", ou seja, mexer com código não ocupa 100% da jornada de trabalho. Na realidade, não ocupa nem 25% ... mas seja lá como for,  consegui ser desenvolvedor aos 44 anos no mundo de hoje, o que aparentemente é um grande feito... :-)

Acho que se apegar a uma função muito específica é parte de problema. A outra parte é acreditar que apenas saber uma linguagem (ou muitas, não importa) e conseguir utilizá-la para codificar regras de negócio em sistemas de informação é realmente uma habilidade de muito valor, como o mercado as vezes leva a pensar que seja. E no fundo não é mesmo. A maior  parte das tarefas em um projeto  de sistemas de informação pode ser feita por recém formados. O valor alto da hora paga não é por causa do valor da especialização, e sim pelo desenvolvedor estar disposto a se submeter a qualquer condição de trabalho e por saber as tecnologias A, B ou C que são muito necessárias no momento, e deixarão de ser talvez daqui a dois ou três anos. De novo, nada contra esta opção. Mas quem está sendo pago por essas duas coisas, deve estar preparado para correr atrás das novas linguagens que estarão em alta daqui a algum tempo, e continuar a trabalhar em qualquer condição.

Então talvez mudar, sair da zona de conforto e aprender uma área nova, dentro de TI ou não, seja a uma alternativa bem razoável.

Como descriptografar o nome do pacote executado com DTSRun no SQL Server 2000

Obter o nome do pacote (DTS package do SQL Server) executado com DTSRun dentro de um job pode ser trabalhoso, pois ele fica critografado. O método a seguir descriptografa o nome do pacote. Foi testado no SQL Server 2000. Os passos tem que ser executados exatamente como descrito abaixo, senão pode não funcionar. Um espaço a mais ou a menos, ou uma cópia intermediária, pode invalidar o procedimento.

1) Abra uma janela do prompt de comando do Windows, copie e cole o comando do DTS. Para colar, clicar no ícone da janela do CMD, abrindo o menu, escolher "Editar" e depois "Colar". Exemplo:

C:\> DTSRun /~Z0x849CE5D77E921A44E6F6A5387C09371196F96F04AB99C12E334D64C4F5D5B6FAB21E24B9E6F1D620EE4DB419C95C7838DBB8BD6C8F113C70857AEA9XXXXXXXXXX66DA44892576FD6384C5D03508C3EEE66D0D6EFF8D16F321C55C3C77C9536CCF4722B23DFDC451E2FFCBD367ADAAE3CB

(Obs: se tentar com a string acima não funcionará, pois o teste foi com dados de um ambiente real, então alterei a string critografada para preservar as informações, os nomes do server e do pacote. N

ote os XXXXXXXXX no meio da string ... Isso invalida o código acima, que é mostrado apenas para ilustrar. Mas basta testar com o seu próprio comando.)

2) Adicione manualmente ao final do comando, com os espaços:

 /!X /!C

Aqui descobri por exemplo que se copiar e colar estes caracteres no final, tal como feito no passo 1, não funciona. Aparentemente não pode mexer na área de transferência.

No exemplo anterior, seria algo parecido com:

DTSRun /~Z0x849CE5D77E921A44E6F6A5387C09371196F96F04AB99C12E334D64C4F5D5B6FAB21E24B9E6F1D620EE4DB419C95C7838DBB8BD6C8F113C70857AEA9D2CD9XXXXXXXXXX66DA44892576FD6384C5D03508C3EEE66D0D6EFF8D16F321C55C3C77C9536CCF4722B23DFDC451E2FFCBD367ADAAE3CB /!X /!C

3) Execute comando do Windows o comando. Irá retornar:

DTSRun: Loading...
DTSRun: Executing...

4) Abra um novo arquivo no Notepad e cole o que estiver na área de transferência, que será o comando com o nome do pacote descriptografado. No exemplo anterior:

DTSRun /S "nome do server" /N "nome do pacote" /E /!X /!C

O que permite ter acesso ao nome do pacote que é executado pelo comando.

Parece até mágica... :-) ... o fato é que funciona. O /!C copia a linha de comando para a área de transferência, mas deve ser usado em conjunto com o /!X, que recupera o nome do pacote. O que faz  parecer um truque é justamente o uso incomum do clipboard. É um dos procedimentos mais esotéricos que encontrei ao trabalhar com SQL Server 2000.

Microsoft compra a Skype: quais as possíveis consequências disso?

Confirmada a notícia de que a Microsoft comprou a Skype. A Microsoft comprando mais uma empresa não é novidade. Me chama a atenção que tenha sido o maior valor pago até agora. O que acho estranho nisso é que uma empresa do porte da Microsoft e com tanto tempo de mercado não tenha produzido internamente uma tecnologia equivalente à do Skype. Mas pode ser outra coisa. Já existe VoIP no MSN messenger, mas ele nunca foi vendido como um substituto de ligações telefônicas, como o Skype fez. Eu acredito que tenha sido uma decisão proposital, a MS não devia querer confrontar o modelo de negócios de comunicações estabelecido. Se foi isso, mudaram de idéia. Não vejo outra forma de explorar o Skype comercialmente que não seja concorrendo com este modelo.

A decisão da compra em si estratégicamente é boa, e coerente com os esforços de investir em outras ferramentas de comunicação, como smartphones. Também abre diversas outras possibilidades. De que forma por exemplo o Windows Phone poderia ser melhorado e se tornar mais competitivo com uma integração maior com o Skype? E mais, eles teriam a chance de revolucionar de vez as comunicações móveis agregando no Windows o tráfego de voz mundial. A consequência disso seria popularizar o tráfego de voz sobre IP. Mas para isso para isso teriam que vencer duas barreiras: 1) Tornar o Windows Phone popular o suficiente para concorrer com Android e iOs e 2) Vencer a resistência das operadoras de telecomunicações, que querem vender planos de voz e de dados separados. A Microsoft tem poder econômico para negociar, mas as empresas de telecomunicações também... O caminho mais fácil talvez fosse comprar uma delas... :-)

As últimas iniciativas da MS na área de comunicações ainda não tiveram muito sucesso (sem falar da incrível derrocada do Windows Mobile, o produto anterior ao Windows Phone, que eu até hoje eu custo a acreditar que deixaram acontecer), mas a possibilidade aberta por esta compra é interessante. Caso seja a intenção da Microsoft popularizar o VoIP em celulares, e ninguém me disse isso, mas me parece o caminho mais óbvio, eu torço para que de certo!

Como consumidor, acho triste ter o Skype instalado no meu smartphone (no meu Android), um plano de dados de 500 MB, mas não ter ninguém para ligar, porque quase todo mundo ainda está usando plano de voz no celular e nem se preocupa em instalar o Skype! Aliás, como fica a ênfase dos apps de Skype para Android depois da compra pela Microsoft?

Atualizando o Nexus S manualmente para o Android 2.3.4

O Nexus S veio com o Android 2.3 pré instalado. A Atualização 2.3.1 veio por OTA, sem nenhum esforço, mas as demais não vieram, nem mesmo utilizando o procedimento do checkin (discar *#*#2432546#*#* ). Uma das maiores vantagens dos Nexus (One e S) é ter as últimas atualizações do Android direto da Google. Mas parece que as atualizações via OTA nem sempre funcionam. Para não esperar mais, hoje resolvi instalar os arquivos de update, baixados do próprio site do Google. Realizei os procedimentos abaixo, e agora estou com a última versão do Android para smartphones do momento, a 2.3.4.

Utilizando este processo nenhuma configuração, dados ou instalação de apps é perdida. Os links abaixo não são de arquivos de ROMs completas, e sim de arquivos de updates. Estes arquivos tem que ser aplicados sobre uma versão anterior específica. É preciso antes de mais nada ter certeza de que versão se está, para escolher o update apropriado.

Como existem builds intermediários, como o "GRI54", verificar também o número da  versão da ROM. Pode ser verificado em configurações, "Sobre o telefone", "Número da versão".

Versões do Android e número da versão da ROM:
2.3.4 - GRJ22
2.3.3 - GRI40
2.3.2 - GRH78C
2.3.1 - GRH78
2.3 - GRH55

Note que esses  números estão nos nomes dos arquivos, na forma AAAAA-from-BBBBB, o que permite fazer uma última checagem das versões antes de instalar.

Outra coisa que poderá ser observada é que embora estes arquivos estejam hospedados no Google, como pode ser visto na URL, achar estes links não é facil. Encontrei apenas em posts de foruns. Parece que a empresa prefere não divulgar, talvez pelo risco e complexidade inerentes ao procedimento manual.

2.3.4 a partir de 2.3.3
http://android.clients.google.com/packages/ota/google_crespo/a14a2dd09749.signed-soju-GRJ22-from-GRI40.a14a2dd0.zip

2.3.3 a partir de 2.3.2
http://android.clients.google.com/packages/ota/google_crespo/98f3836cef9e.signed-soju-GRI40-from-GRH78C.98f3836c.zip

2.3.2 a partir de 2.3.1
http://android.clients.google.com/packages/ota/google_crespo/353e267378cd.signed-soju-GRH78C-from-GRH78.353e2673.zip

2.3.1 a partir de 2.3
http://android.clients.google.com/packages/ota/google_crespo/a71a2082d553.signed-soju-GRH78-from-GRH55.a71a2082.zip

Para instalar cada update, utilizei o procedimento descrito aqui:
http://www.google.com.br/support/forum/p/Google+Mobile/thread?tid=1e094262682009a3&hl=en

Traduzindo:

1) Renomear o arquivo para update.zip e colocar no SD

2) Entrar no recovery: desligar o celular e religar, apertando volume para cima.

3) Escolher a opção de recovery no menu

4) Quando aparecer a tela com o sinal de exclamação, pressione o power e depois aperte o volume para cima.

5) Na tela do recovery escolha "update from /sdcard" e depois "update.zip".

6) Aguarde o processo terminar e depois escolha "reboot system now"

Comentários sobre a versão: como algumas pessoas já relataram, realmente na 2.3.3 (e também na 2.3.4) ocorre uma mudança das cores da interface que até o momento estou achando estranha. Parece que diminui o contraste da tela. Não sei exatamente o motivo pelo qual fizeram isso, mas eu gostava mais como era antes. Também não vou tentar downgrade só por causa disso. E está me parecendo também que o sinal 3G melhorou, embora não tenha como dizer com absoluta certeza, por falta de dados objetivos (medições). Mas o fato é que onde estou, o sinal varia o tempo todo de "E" para "3G", e depois o update ficou direto em "3G". E a grande feature da 2.3.4 é a vídeo-chamada no gTalk.

Dica: encontrando ocorrências duplicadas em um result set

A dica abaixo não é nada misteriosa, mas eu francamente como uso pouco funções agregadas no dia a dia demorei a montar a consulta. A situação é a seguinte: em determinado result set, qual ou quais combinações de determinadas colunas aparecem mais de uma vez? Um exemplo prático, se as colunas em questão são uma chave primária para inserir em uma outra tabela, quais as linhas que estão dando problema de PK duplicada? No exemplo abaixo, "coluna1, coluna2, coluna3, ..." representa as colunas que não podem ser duplicadas (ou que se deseja saber quantas vezes ocorrem).

SELECT coluna1, coluna2, coluna3, ...
                   
FROM   tabela(s)
WHERE  condição 


GROUP BY coluna1, coluna2, coluna3, ...


HAVING COUNT (*) > 1