Bom, quem usa linux já ouviu falar (e talvez até tenha ficado um pouco curioso) sobre os efeitos do "rm -rf /" em modo root... os geeks de plantão sabem, mas em todo o caso, "rm -rf /" conhecido por touch of death é um comando que simplesmente diz para o linux remover todos os arquivos começando pelo raiz e descendo nos subdiretórios recursivamente. Como o linux depois que carrega um programa em memória deixa o executável dele liberado (o Windows 98 não deixa remover um arquivo que está em execução, os XP, 2000 e Vista eu não testei como se comportam), esse comando vai
se remover, vai remover o shell, vai remover todo o sistema.
Confesso que quando ouvi falar desse cara, fiquei com uma pequena curiosidade para saber o que aconeteceria... mas nunca achei que o esforço fosse compensar a curiosidade. Até que... algum desocupadodesbravador resolveu publicar um vídeo com os efeitos do rm -rf /
Bom saber que o gatinho sobreviveu!
Bom, depois de umas férias não tecnológicas (6 dias sem internet e praticamente sem celular), a contagem de mortos e feridos ficou em 69 emails, 28 spams, 298 feeds e 12 comics não lidos... e como não acho que vou conseguir zerar esses contadores hoje, e vou para mais um recesso tecnológico até o próximo ano agora (tô me sentindo muito radical! e reusando descaradamente todas as piadas já batidas, gastas e desbotadas de final de ano!), acho que a situação tende a piorar!
Anyway, como não devo postar mais nada e nem entrar no MSN, feliz 2008!!!
Saturday, December 29, 2007
Monday, December 17, 2007
Achmed
Me falaram desse vídeo um tempo atrás, vi ele ontem. Muito bom! Vale a pena gastar os 11 minutos assistindo :).
Allah dammed! I kill you!
Allah dammed! I kill you!
Sunday, December 16, 2007
Enfeite de Natal geek
Eu não ia fazer 2 posts no mesmo dia, mas isso me chamou a atenção...
A explicação tá em ingles, mas mesmo que não entenda, a imagem já é interessante. Basicamente, o cara usou LEDs e um ventilador (com um pequeno toque de microcontrolador) para fazer um enfeite de natal. O microcontrolador fica acionadno os LEDs numa determinada seqüência enquanto a hélice do ventilador está girando, causando um efeito interessante...
Tentar lembrar de fazer algo assim no próximo natal ;)
A explicação tá em ingles, mas mesmo que não entenda, a imagem já é interessante. Basicamente, o cara usou LEDs e um ventilador (com um pequeno toque de microcontrolador) para fazer um enfeite de natal. O microcontrolador fica acionadno os LEDs numa determinada seqüência enquanto a hélice do ventilador está girando, causando um efeito interessante...
Tentar lembrar de fazer algo assim no próximo natal ;)
Bug do ano 2038 e segundo bissexto
Pra começar o post, vi uma tirinha do LibMan e APIBoy, com uma pequena referência ao bug do ano 2038. Bug do ano 2038?! Isso que eu chamaria de evolução no planejamento de software. Eu ainda não consigo nem saber que features vão ser implementadas no TAF no próximo ano, e já tem gente sabendo que bugs vão existir em 2038! Bom, parando com a brincadeira. Quem não conhecia e ainda não seguiu o link para o segundo guru da internet (wikipedia), o bug do ano 2038 é basicamente um problema para quem usa representação de datas estilo POSIX (e quem não usa???), onde a data é representada pelo número de segundos passados desde o início da era, no caso, 1-Jan-1970. O problema é que esse valor é representado por um inteiro sinalizado de 32 bits. Mas por que usar uma representação de datas usando inteiros de 32 bits e com sinal? Primeiro, lá em 1985, mais ou menos quando o POSIX foi lançado, acho que parecia bastante lógico que 2147483647 de segundos no futuro nenhum daqueles computadores estariam em uso, então, pra que se preocupar? Afinal, no ano 2000 já teríamos carros voadores, computadores com uma inteligência praticamente humana, no melhor estilo HAL, ponte aérea (??) entre a Terra e Marte, etc, não havia a menor chance de ainda usarmos os obseletos computadores de 32 bits - que ainda nem existiam. Mas tudo bem, podiam ter pelo menos colocado um unsigned na frente do time_t, né? Não exatamente. E como ficariam as datas antes de 1970? Certo, a decisão de usar signed int parece bem razoável. Então, assim como em 2000, os sistemas que usam datas vão entrar em colapso, certo? Bom, mais ou menos. É possível que se nada for feito, o segundo seguinte a data 03:14:07 de 19-Jan-2038 será 13-Dez-1901, 20:45:42. Ei, mas já estamos colocando processadores 64 bits agora, até 2038 ninguém mais vai usar 32 bits, certo? Eu espero que sim, mas existem algumas indicações contrárias. Já com o negócio do bug do ano 2000, vários sistemas extremamente legados, ainda em Cobol e fortran, ainda estavam em utilização, e recodificar alguns bugs pode não ser uma opção adotada por algumas empresas, para reduzir o custo. Além disso, temos os vários sistemas embutidos (ou embarcados - esse último parece ser o termo mais utilizado, mas tem algo nele que eu não gosto. Pessoal da área de embedded systems, qual o certo?) que provavelmente não usam 64 bits, e muito provavelmente vão continuar em operação até além de 2038. Só espero que os sistemas que controlam aviões, satélites, e outras coisas grandes que correm um risco de cair nas nossas cabeças não sofram nenhum efeito colateral sério por causa desse bug, assim como sistemas de monitoração de usinas nucleares e outras coisas que possam fazer um "grande boom". E também, mudar para 64 bits não resolve o problema, só posterga para 4 de dezembro de 292.277.026.596 as 15:30:08, mas aí acho que podemos deixar para as futuras gerações resolverem, ou postergarem ainda mais usando 128 bits ;).
Bom, e o que isso tudo tem relacionado com segundos bissextos? Nada, na verdade, exceto que a contagem de segundos na data POSIX não leva em consideração os segundos bissextos. Eu só achei um termo novo e resolvi comentar :D. Já é de conhecimento natural que a cada 4 anos temos um ano bissexto, que inclui um dia extra em Fevereiro. Essa acho que é uma das maiores gambiarras da humanidade. Ao invés de fracionar as unidades de tempo de forma a todo ano ficar bem alinhado, a preguiça imperou e inventaram esse negócio de incluir um dia a mais em alguns anos para "limpar" a imprecisão. Bom, é da natureza humana ir pelo lado mais fácil, por isso, eu simplesmente critiquei a solução e nem procurei saber se existe alguma forma de fazer um fracionamento exato ;). Mas parece que mesmo a divisão do dia em 86400 segundos não é lá muito preciso. Na verdade, dessa vez a culpa é da própria Terra. A cada século, o dia solar (que não respeita nossos relógios) fica 1,7 milissegundos maior, ou seja, daqui a 6 séculos, nossos dias terão 1 segundo a mais. Mas, a nossa divisão de datas continua 1 dia * 24 horas * 60 minutos * 60 segundos, sem espaço para esse segundo adicional, então fizeram esse negócio de segundo bissexto. Em alguns anos específicos é inserido 1 segundo a mais, sincronizado mundialmente. Normalmente, esse segundo adicional é colocado no dia 30-Junho ou 31-Dezembro. No caso, quando o relógio em UTC chegar a 31-Dez, 23:59:59, ao invés de mudar para 01-Jan, 0:00:00, ele primeiro vai para 31-Dez, 23:59:60, e depois para 0:00:00. Esse ajuste é feito simultaneamente em todo o mundo, por um sistema de difusão, ou seja, aqui no Brasil o ajuste é feito as 21:59:59, considerando o horário de verão. Agora eu me pergunto, será que meu relógio de pulso se ajusta automaticamente em relação a segundos bissextos? Se não, acho que descobri porque em 2005 ele estava errado em 1 segundo.
Só pra constar, os últimos 10 anos que sofreram ajuste de segundo bissexto foram: 2005, 1998, 1997, 1995, 1994, 1993, 1992, 1990, 1989, 1987.
Bom, e o que isso tudo tem relacionado com segundos bissextos? Nada, na verdade, exceto que a contagem de segundos na data POSIX não leva em consideração os segundos bissextos. Eu só achei um termo novo e resolvi comentar :D. Já é de conhecimento natural que a cada 4 anos temos um ano bissexto, que inclui um dia extra em Fevereiro. Essa acho que é uma das maiores gambiarras da humanidade. Ao invés de fracionar as unidades de tempo de forma a todo ano ficar bem alinhado, a preguiça imperou e inventaram esse negócio de incluir um dia a mais em alguns anos para "limpar" a imprecisão. Bom, é da natureza humana ir pelo lado mais fácil, por isso, eu simplesmente critiquei a solução e nem procurei saber se existe alguma forma de fazer um fracionamento exato ;). Mas parece que mesmo a divisão do dia em 86400 segundos não é lá muito preciso. Na verdade, dessa vez a culpa é da própria Terra. A cada século, o dia solar (que não respeita nossos relógios) fica 1,7 milissegundos maior, ou seja, daqui a 6 séculos, nossos dias terão 1 segundo a mais. Mas, a nossa divisão de datas continua 1 dia * 24 horas * 60 minutos * 60 segundos, sem espaço para esse segundo adicional, então fizeram esse negócio de segundo bissexto. Em alguns anos específicos é inserido 1 segundo a mais, sincronizado mundialmente. Normalmente, esse segundo adicional é colocado no dia 30-Junho ou 31-Dezembro. No caso, quando o relógio em UTC chegar a 31-Dez, 23:59:59, ao invés de mudar para 01-Jan, 0:00:00, ele primeiro vai para 31-Dez, 23:59:60, e depois para 0:00:00. Esse ajuste é feito simultaneamente em todo o mundo, por um sistema de difusão, ou seja, aqui no Brasil o ajuste é feito as 21:59:59, considerando o horário de verão. Agora eu me pergunto, será que meu relógio de pulso se ajusta automaticamente em relação a segundos bissextos? Se não, acho que descobri porque em 2005 ele estava errado em 1 segundo.
Só pra constar, os últimos 10 anos que sofreram ajuste de segundo bissexto foram: 2005, 1998, 1997, 1995, 1994, 1993, 1992, 1990, 1989, 1987.
Saturday, December 8, 2007
Computadores a luz!
Apesar de muita gente ainda usar no dia-a-dia luz como sinônimo de energia elétrica (quem nunca ouviu a célebre frase "faltou luz" quando o fornecimento de energia elétrica é interrompido durante o dia, as vezes com certa abundância de luz solar?), a "luz" nesse caso é luz mesmo, fótons e cia.
A IBM está anunciando um modulador eletro-óptico de silício Mach-Zehnder (do inglês silicon Mach-Zehnder electro-optic modulator), que basicamente converte pulsos elétricos em ondas luminozas. A principal vantagem é transmissão de dados sem fio dentro de um processador, reduzindo custo de produção - bom, depende de quanto custar esse modulador, na verdade - e principalmente, como não haverá resistência na transmissão elétrica, as perdas com transmissão de dados reduzem bastante, e o consumo de energia reduz também. Fala-se em 4 mil núcleos de processamento em um notebook - imagino que com a duração de 2 ou mais horas de bateria. Até agora, estão falando apenas em usar essa tecnologia dentro do processador. Todos os barramentos externos aparentemente continuam usando o bom e velho sinal TTL ou CMOS.
Estava pensando, quanto tempo até tornarem toda a comunicação interna de um PC baseada em luz? Quer dizer, parece meio estranho o caminho que a coisa vai tomar.
Um sinal elétrico de algum periférico ou placa PCI e afins chega até o processador, é convertido em luz, o processador reage ao estímulo, bota no barramento de saída, o sinal é demodulado pra sinal elétrico novamente, vai para algum periférico. Até entendo a comunicação com HDs, leitores de CDs, etc ser baseada em pulsos elétricos por uma questão de alinhamento e simplicidade para montar (bom, mais ou menos, não seria possível usar fibra-óptica?), mas a comunicação processador-memória, barramento-processador, barramento-memória, basicamente toda a comunicação interna de uma placa mãe poderia ser totalmente baseada nessa tecnologia, não? De qualquer forma, acho que o negócio agora é esperar isso ficar barato suficiente para chegar até nossas casas. Enquanto isso, vou ficar pensando no problema "o que fazer com o poder computacional de 4 mil cores?" (um passo mais próximo de dominar o mundo, mwahahahaha!)
Fonte: Meio Bit
Thursday, December 6, 2007
10 dicas para reduzir o esgotamento mental
Pra quem não conhece, o lifehacker é um site muito bom sobre produtividade, e outras dicas em geral. Já passaram por lá assuntos sobre como melhorar a qualidade do sono, técnicas de "GTD" (Getting Things Done), eficiência, dentre outras coisas boas. Dessa vez um artigo (em inglês) bastante interessante sobre brain drain (algo parecido com esgotamento mental) surgiu lá.
O brain drain é algo que eu "experimento" algumas vezes durante o mês. Normalmente acontece quando a pessoa está muito ocupada por um tempo bastante longo. As vezes no trabalho isso acaba acontecendo comigo, e com o mestrado ainda tem um agravante. Infelizmente não descobriram ainda a bolha de tempo, uma cápsula (?!) usando algumas caracteristicas da malha do espaço-tempo, e alguns fundamentos da mecânica quântica e teoria da relatividade geral onde alguém entraria, passaria tempo suficiente para fazer tudo que precisa, e quando saísse teriam passados apenas alguns minutos ou segundos no "mundo real". Claro, teria o efeito colateral que você envelheceria muito mais rápido se usar muito essa bolha, mas acho que se pesar bem as coisas, valeria a pena. A gente pode sonhar, não? De qualquer forma, sem essa bolha, as vezes nos sentimos "pressionados" a fazer 1 semana de trabalho em 1 dia, e isso acaba levando ao brain drain. Não sei as conseqüncias disso a longo prazo, mas quando eu percebo os sintomas de brain drain normalmente percebo que minha produtividade cai bastante, eu me irrito bem mais fácil com as pessoas, entre algumas outras coisas desagradáveis. No artigo comentam que isso pode levar ao stress!
Se você já tem problemas com brain drain, o artigo é bastante interessante. Nele são dadas 10 dicas de como voltar ao normal quando você percebe que está chegando perto do esgotamento. Vou resumir elas aqui.
Espero que as dicas ajudem alguém ;).
Boa sorte!
O brain drain é algo que eu "experimento" algumas vezes durante o mês. Normalmente acontece quando a pessoa está muito ocupada por um tempo bastante longo. As vezes no trabalho isso acaba acontecendo comigo, e com o mestrado ainda tem um agravante. Infelizmente não descobriram ainda a bolha de tempo, uma cápsula (?!) usando algumas caracteristicas da malha do espaço-tempo, e alguns fundamentos da mecânica quântica e teoria da relatividade geral onde alguém entraria, passaria tempo suficiente para fazer tudo que precisa, e quando saísse teriam passados apenas alguns minutos ou segundos no "mundo real". Claro, teria o efeito colateral que você envelheceria muito mais rápido se usar muito essa bolha, mas acho que se pesar bem as coisas, valeria a pena. A gente pode sonhar, não? De qualquer forma, sem essa bolha, as vezes nos sentimos "pressionados" a fazer 1 semana de trabalho em 1 dia, e isso acaba levando ao brain drain. Não sei as conseqüncias disso a longo prazo, mas quando eu percebo os sintomas de brain drain normalmente percebo que minha produtividade cai bastante, eu me irrito bem mais fácil com as pessoas, entre algumas outras coisas desagradáveis. No artigo comentam que isso pode levar ao stress!
Se você já tem problemas com brain drain, o artigo é bastante interessante. Nele são dadas 10 dicas de como voltar ao normal quando você percebe que está chegando perto do esgotamento. Vou resumir elas aqui.
- Meditação - ficar uns 20 minutos deixando o cérebro em stand by, somente observando os pensamentos que tendem a aparecer, sem focar em nenhum deles. Isso é bem mais fácil dito do que feito, é verdade, mas mesmo que você não consiga um estado meditativo 100% eficiente, já vale a pena, pode acreditar.
- Dar uma caminhada - o efeito aqui é basicamente tirar o foco do cérebro para alguma outra função, deixando ele relexar um pouco.
- Ouvir música clássica - bom, quem não gosta acho que não vai ter benefício nenhum, mas quem gosta sabe do "poder" relaxante de Mozart, Beethoven, Bach e cia.
- Ler algo interessante - apesar de parecer contraditório, ler pode mesmo relaxar o cérebro, desde que não seja algo técnico ;)
- Reiniciar o cérebro com uma caffeine nap - Essa eu confesso que nunca testei. Mas parece que alguns estudantes desesperados por projetos de mestrado fizeram alguns estudos em universidades e chegaram a conclusão que tomar uma xícara de café e logo em seguida tirar uma soneca de 10-15 min liga o "turbo" do cérebro.
- Ver um filme - se você conseguir umas 2h para ir ver algum filme...
- Ouvir CDs motivacionais - Esse parece meio estranho também, mas esses CDs costumam por o cérebro em um modo robótico em que ele se preocupa basicamente em pegar as informações prontas, então menos trabalho para ele ;)
- Praticar algum esporte - a técnica basicamente é mover a fadiga do cérebro pro corpo. Essa eu tenho experiência. Diversas vezes que eu saí do trabalho com vários sintomas de fadiga mental jgoar o voleizinho sagrado resolveu o problema muito bem.
- Divide et impera - pra que fazer tudo de uma vez? Divide o problema em partes e resolve cada uma de maneira simples...
- Jogar algum jogo - sim, jogadores viciados, não é esporte mesmo, é dar atenção ao Wii, ao
PS 3, Xbox, PC, PS 2, etc. Pronto, agora ganhei uma desculpa pra passar mais horas jogando no PC :D. Quem não é muito fã desse tipo de jogo, no artigo falam que Sudoku (pronúncia normal é algo parecido com suudóku - diz a wikipedia ;)) ou palavras cruzadas são excelentes também para reduzir a fadiga.
Espero que as dicas ajudem alguém ;).
Boa sorte!
Monday, December 3, 2007
Piadinha boa para variar um pouco
Um casal tinha dois filhos, que eram terríveis. Os pais sabiam que, se
houvesse alguma travessura onde moravam, eles com certeza estariam
envolvidos. A mãe dos garotos ficou sabendo que o novo padre da cidade
tinha tido bastante sucesso em disciplinar crianças. Então ela pediu a
ele, que falasse com os meninos. O padre concordou, mas pediu para vê-los
separadamente.A mãe mandou o filho mais novo.
O padre, um homem alto com uma voz de trovão, sentou o garoto e
perguntou-lhe austeramente:
- Onde está Deus?
O garoto abriu a boca, mas não conseguiu
emitir nenhum som. Ficou sentado, com a boca aberta e os olhos
arregalados. Então, o padre repetiu a pergunta num tom ainda mais severo:
o garoto não conseguia emitir nenhuma resposta. O padre levantou ainda
mais a voz, e com o dedo no rosto do garoto berrou:
- ONDE ESTÁ DEUS?
O garoto saiu correndo da igreja direto pra casa e trancou-se no quarto.
Quando o irmão mais velho o encontrou, perguntou:
O que aconteceu?
O irmão mais novo, ainda tentando recuperar o fôlego, respondeu:
- Cara, desta vez tamo fudido. Deus sumiu, e acham que foi a gente.
--
Otavio Pereira
otaviofp@gmail.com
---------------------------
Programmer (def): An organism that converts caffeine into software.
"Why are we all forced to go to work at the same time? Who arbitrarily decided that 8 AM was a good time for everyone to go to work?" (Dilbert)
houvesse alguma travessura onde moravam, eles com certeza estariam
envolvidos. A mãe dos garotos ficou sabendo que o novo padre da cidade
tinha tido bastante sucesso em disciplinar crianças. Então ela pediu a
ele, que falasse com os meninos. O padre concordou, mas pediu para vê-los
separadamente.A mãe mandou o filho mais novo.
O padre, um homem alto com uma voz de trovão, sentou o garoto e
perguntou-lhe austeramente:
- Onde está Deus?
O garoto abriu a boca, mas não conseguiu
emitir nenhum som. Ficou sentado, com a boca aberta e os olhos
arregalados. Então, o padre repetiu a pergunta num tom ainda mais severo:
o garoto não conseguia emitir nenhuma resposta. O padre levantou ainda
mais a voz, e com o dedo no rosto do garoto berrou:
- ONDE ESTÁ DEUS?
O garoto saiu correndo da igreja direto pra casa e trancou-se no quarto.
Quando o irmão mais velho o encontrou, perguntou:
O que aconteceu?
O irmão mais novo, ainda tentando recuperar o fôlego, respondeu:
- Cara, desta vez tamo fudido. Deus sumiu, e acham que foi a gente.
Piada enviada pelo mestre João Amorim
--
Otavio Pereira
otaviofp@gmail.com
---------------------------
Programmer (def): An organism that converts caffeine into software.
"Why are we all forced to go to work at the same time? Who arbitrarily decided that 8 AM was a good time for everyone to go to work?" (Dilbert)
Saturday, December 1, 2007
To final or not to final? That is the question...
Essa frase Shakespeareana provavelmente já rendeu mais trocadilhos do que qualquer outra frase na história da humanidade. Mas é incrível a quantidade de situações que ela se aplica, não? De qualquer forma, o motivo do post não é discutir Shakespeare, mas sim a palavra chave final do Java.
A maioria dos desenvolvedores em Java estão bastante acostumados em ver esse carinha associado com sua quase comanheira de longa data static para formar constantes. Constantes em Java além de permitir algum grau a mais de manutenção e prevenção de bugs ajudam o compilador a fazer algumas pequenas otimizações. Como assim "constantes ajudam na manutenção e prevenção de bugs"? Simples, vamos supor que precisamos desenvolver uma classe com diversas funções de manipulação de circunferências. Nessa classe provavelmente vamos usar uma porção de vezes a constante matemática PI. Se a cada vez que fôssemos usá-la fosse necessário escrever o literal 3.14159 aumentamos muito o risco de usar valores diferentes de PI em métodos diferentes. Imagine que um desenvolvedor novato precisou codificar o método para calcular a área do circunfência, e usou 3.1415 como valor de PI, e um outro desenvolvedor fez um método para calcular o perímetro da circunfêrencia e usou o valor de PI como 3.14, afinal ele é um desenvolvedor mais experiente e sabe que 2 casas de precisão são suficientes para o projeto (!?). Alguém que fosse usar as 2 funções em momentos diferentes poderia ter resultados diferentes. Já temos a "precisão" característica do ponto flutuante, e ainda introduzimos uma variação nos próprios valores usados nos cálculos. Nada bom pode sair disso. A solução aqui é bastante trivial: definir uma constante final static PI, e usá-la ao invés do valor hardcoded de pi. Na verdade, uma solução melhor é usar a constante PI da classe Math do Java ;). Mas esse tipo de coisa não prejudica a performance? Não, pois o compilador do Java na primeira passada da compilação (são 3, acho) ele troca as referências das constantes de tipos primitivos e Strings pelos valores declarados, então o efeito no código é o mesmo de ter os valores hardcoded. Mas por que só primitivos e String? As demais variáveis são referências, o código ficaria incorreto:
Se o compilador substituísse a refeência da constante GERENTE, os 2 métodos usariam uma instância diferente da classe Pessoa, o que não estaria de acordo com a lógica do código fonte.
Mas essa característica de inline de constantes pode trazer alguns problemas para desenvolvedores descuidados. Suponha que você colocou uma constante public static final int MAX_VALUE = 100 numa classe de sua biblioteca. Alguma aplicação externa faz uso de sua biblioteca e em certo momento faz uma comparação (value > MAX_VALUE). Como Murphy ainda impera na informática, algum tempo depois que o código entrar em produção vai surgir a necessidade de um value maior que 100 ser usado em uma condição válida. Solução óbvia: redefine o valor da constante MAX_VALUE (supondo que não há nenhuma outra lógica que impeça isso), recompila a biblioteca, troca o JAR na aplicação do cliente e voilà, tudo pronto, certo? Errado. No momento que a aplicação foi compilada o Java trocou MAX_VALUE por 100, então a alteração não faz efeito sem uma recompilação da aplicação.
Mas o uso do final não é restrito a membros static nas classes para evitar coisas hardcoded simplesmente. Na verdade, o final pode aparecer praticamente em qualquer lugar, e em alguns lugares ele deve aparecer. Um pouco sobre a biografia do final:
Na verdade, o final tem várias aplicações em um código Java. Declarar uma classe como final é equivalente a dizer ao compilador que a classe está completa e não pode dar origem a subclasses. Exemplos de uso seriam para classes utilitárias, onde gerar subclasses pode levar a sobreescrição de métodos importantes, ou classes singleton, etc. De uma forma genérica, todas as classes que definem apenas construtores private são automaticamente final. Eu particularmente não recordo de algum caso em que o uso do final fosse importante em alguma classe. Talvez classes que validam restrições de segurança devem fazer bom uso desse cara, para evitar que algum código malicioso troque em tempo de execução uma instância de um autenticador de login, por exemplo. Algo bastante óbvio que surge da característica do final é que não é possível declarar uma classe simultaneamente abstract e final, pois o último modificador não permite a geração de subclasses e o primeiro exige que uma subclasse complete alguns métodos não definidos.
Um outro lugar onde é possível usar o final é na declaração de métodos. Tornar um método final é equivalente a dizer para o Java que nenhuma subclasse pode redefinir aquele método. Essa restrição é garantida tanto em tempo de compilação através de erros, quanto de execução através de um VerifyError.
Existe uma pequena discussão sobre o uso do final nesses casos, pois em geral é bastante difíci prever quando alguma classe precisará ser extendida. Eu mesmo ao longo do desenvolvimento de software vi alguns casos em que uma classe não foi pensada para gerar subclasses e em algum momento na manutenção do sistema uma subclasse foi necessária. Então a recomendação que eu deixo é somente usar o final em classes ou métodos se houver uma razão no design do sistema para isso.
Agora o uso do final nos pontos que me deixaram mais curioso sobre ele e me levaram a esse post. Uso de final em variáveis, parâmetros e atributos de classe é útil? Bom, pra tentar responder essa pergunta eu fui atrás de algumas fontes, e acabei cruzando com um livro do O'Relly, "Hardcore Java". A julgar pelo conteúdo, parece um livro muito bom. Consegui acesso ao 2o capítulo do livro em PDF, não tenho certeza se a lincesa me permite linkar aqui, então vou deixar o link de fora, mas uma busca no google deve trazer a referência ;). Ele dedicou 31 páginas falando os diversos usos do final. Em geral, ele recomenda usar o final em todas as variáveis, atributos e parâmetros, principalmente pelos benefícios que o uso traz em relação a manutenção de código. Achei alguns exemplos forçados, mas tem algum fundo de verdade. Já vi alguns casos de código em que variáveis de nomes semelhantes são usadas ao longo de um método e fica bastante simples atribuir o valor na variável errada. Um ponto a favor do final para esses casos: ele forçaria um erro de lógica a aparecer durante a compilação - ou da edição, se estiver usando uma boa IDE. Sem dúvida, detectar e corrigir um erro nessa fase é bem mais barato do que durante os testes, ou, de acordo com Murphy, quando os clientes começarem a gritar pedindo uma correção para o problema do relatório X estar dizendo que o salário do faxineiro é negativo. Praticamente só esse argumento (de detectar o problema antes, e não o salário) já me deixou com uma coceira para ligar todas as opções de inserção de final do Eclipse (nesse post). Até então eu liguei apenas para ele inserir nos atributos private. Mas vamos lá, um pouco mais de desconfiança e vamos ver se há mais benefícios. Indo na especificação da linguagem Java, há razoavelmente bastante referências ao final, mas nenhuma dizendo claramente as vantagens de usá-lo. Então uma pequena busca no google, e alguns foruns mais tarde, a conclusão que parece óbvia. Tanto os compiladores quanto a própria JVM podem se valer da informação de algo ser final para aplicar otimizações. Uma variável ser declarada como final pode fazer ela ir parar em uma área especial da heap, fazendo o acesso ser ligeiramente mais rápido. Observe o "pode" nessa frase. Eu fiz alguns testes com os compiladores do Java 6 e do Eclipse e o bytecode gerado com e sem final foi o mesmo. Nem sequer uma indicação de se a variável é final ou não. Vi algumas referências de fontes "confiáveis" (leia: posts em foruns) de que a máquina virtual consegue otimizar essas coisas. Mas procurando um pouco mais, fiu atras da especificação da máquina virtual, e no bytecode só é anotado se um atributo é final, e não se uma variável ou parâmetro é. Dessa forma, acho que do ponto de vista de otimização de código, não tem diferença nenhuma para a máquina virtual. O HotSpot(tm) vai identificar os pontos de otimização de variáveis e parâmetros por conta própria mesmo, sem ajuda do compilador.
Bom, eu vou procurar usar o final em todos os cantos mais por precaução contra atribuições em lugares errados, de qualquer forma.
A maioria dos desenvolvedores em Java estão bastante acostumados em ver esse carinha associado com sua quase comanheira de longa data static para formar constantes. Constantes em Java além de permitir algum grau a mais de manutenção e prevenção de bugs ajudam o compilador a fazer algumas pequenas otimizações. Como assim "constantes ajudam na manutenção e prevenção de bugs"? Simples, vamos supor que precisamos desenvolver uma classe com diversas funções de manipulação de circunferências. Nessa classe provavelmente vamos usar uma porção de vezes a constante matemática PI. Se a cada vez que fôssemos usá-la fosse necessário escrever o literal 3.14159 aumentamos muito o risco de usar valores diferentes de PI em métodos diferentes. Imagine que um desenvolvedor novato precisou codificar o método para calcular a área do circunfência, e usou 3.1415 como valor de PI, e um outro desenvolvedor fez um método para calcular o perímetro da circunfêrencia e usou o valor de PI como 3.14, afinal ele é um desenvolvedor mais experiente e sabe que 2 casas de precisão são suficientes para o projeto (!?). Alguém que fosse usar as 2 funções em momentos diferentes poderia ter resultados diferentes. Já temos a "precisão" característica do ponto flutuante, e ainda introduzimos uma variação nos próprios valores usados nos cálculos. Nada bom pode sair disso. A solução aqui é bastante trivial: definir uma constante final static PI, e usá-la ao invés do valor hardcoded de pi. Na verdade, uma solução melhor é usar a constante PI da classe Math do Java ;). Mas esse tipo de coisa não prejudica a performance? Não, pois o compilador do Java na primeira passada da compilação (são 3, acho) ele troca as referências das constantes de tipos primitivos e Strings pelos valores declarados, então o efeito no código é o mesmo de ter os valores hardcoded. Mas por que só primitivos e String? As demais variáveis são referências, o código ficaria incorreto:
private static final Pessoa GERENTE = new Pessoa("Gerente");
...
public void desenvolvedorFezMerda(Pessoa desenvolvedor) {
GERENTE.mata(desenvolvedor);
}
public void desenvolvedorEntregouAntesDoPrazo(Pessoa desenvolvedor) {
GERENTE.parabeniza(desenvolvedor);
}
}
Se o compilador substituísse a refeência da constante GERENTE, os 2 métodos usariam uma instância diferente da classe Pessoa, o que não estaria de acordo com a lógica do código fonte.
Mas essa característica de inline de constantes pode trazer alguns problemas para desenvolvedores descuidados. Suponha que você colocou uma constante public static final int MAX_VALUE = 100 numa classe de sua biblioteca. Alguma aplicação externa faz uso de sua biblioteca e em certo momento faz uma comparação (value > MAX_VALUE). Como Murphy ainda impera na informática, algum tempo depois que o código entrar em produção vai surgir a necessidade de um value maior que 100 ser usado em uma condição válida. Solução óbvia: redefine o valor da constante MAX_VALUE (supondo que não há nenhuma outra lógica que impeça isso), recompila a biblioteca, troca o JAR na aplicação do cliente e voilà, tudo pronto, certo? Errado. No momento que a aplicação foi compilada o Java trocou MAX_VALUE por 100, então a alteração não faz efeito sem uma recompilação da aplicação.
Mas o uso do final não é restrito a membros static nas classes para evitar coisas hardcoded simplesmente. Na verdade, o final pode aparecer praticamente em qualquer lugar, e em alguns lugares ele deve aparecer. Um pouco sobre a biografia do final:
final, s.m.: Texto da família palavras-chave, do gênero Java. Pode ser visto habitando classes não abstratas, métodos, parâmetros e variáveis locais em códigos Java.
Na verdade, o final tem várias aplicações em um código Java. Declarar uma classe como final é equivalente a dizer ao compilador que a classe está completa e não pode dar origem a subclasses. Exemplos de uso seriam para classes utilitárias, onde gerar subclasses pode levar a sobreescrição de métodos importantes, ou classes singleton, etc. De uma forma genérica, todas as classes que definem apenas construtores private são automaticamente final. Eu particularmente não recordo de algum caso em que o uso do final fosse importante em alguma classe. Talvez classes que validam restrições de segurança devem fazer bom uso desse cara, para evitar que algum código malicioso troque em tempo de execução uma instância de um autenticador de login, por exemplo. Algo bastante óbvio que surge da característica do final é que não é possível declarar uma classe simultaneamente abstract e final, pois o último modificador não permite a geração de subclasses e o primeiro exige que uma subclasse complete alguns métodos não definidos.
Um outro lugar onde é possível usar o final é na declaração de métodos. Tornar um método final é equivalente a dizer para o Java que nenhuma subclasse pode redefinir aquele método. Essa restrição é garantida tanto em tempo de compilação através de erros, quanto de execução através de um VerifyError.
Existe uma pequena discussão sobre o uso do final nesses casos, pois em geral é bastante difíci prever quando alguma classe precisará ser extendida. Eu mesmo ao longo do desenvolvimento de software vi alguns casos em que uma classe não foi pensada para gerar subclasses e em algum momento na manutenção do sistema uma subclasse foi necessária. Então a recomendação que eu deixo é somente usar o final em classes ou métodos se houver uma razão no design do sistema para isso.
Agora o uso do final nos pontos que me deixaram mais curioso sobre ele e me levaram a esse post. Uso de final em variáveis, parâmetros e atributos de classe é útil? Bom, pra tentar responder essa pergunta eu fui atrás de algumas fontes, e acabei cruzando com um livro do O'Relly, "Hardcore Java". A julgar pelo conteúdo, parece um livro muito bom. Consegui acesso ao 2o capítulo do livro em PDF, não tenho certeza se a lincesa me permite linkar aqui, então vou deixar o link de fora, mas uma busca no google deve trazer a referência ;). Ele dedicou 31 páginas falando os diversos usos do final. Em geral, ele recomenda usar o final em todas as variáveis, atributos e parâmetros, principalmente pelos benefícios que o uso traz em relação a manutenção de código. Achei alguns exemplos forçados, mas tem algum fundo de verdade. Já vi alguns casos de código em que variáveis de nomes semelhantes são usadas ao longo de um método e fica bastante simples atribuir o valor na variável errada. Um ponto a favor do final para esses casos: ele forçaria um erro de lógica a aparecer durante a compilação - ou da edição, se estiver usando uma boa IDE. Sem dúvida, detectar e corrigir um erro nessa fase é bem mais barato do que durante os testes, ou, de acordo com Murphy, quando os clientes começarem a gritar pedindo uma correção para o problema do relatório X estar dizendo que o salário do faxineiro é negativo. Praticamente só esse argumento (de detectar o problema antes, e não o salário) já me deixou com uma coceira para ligar todas as opções de inserção de final do Eclipse (nesse post). Até então eu liguei apenas para ele inserir nos atributos private. Mas vamos lá, um pouco mais de desconfiança e vamos ver se há mais benefícios. Indo na especificação da linguagem Java, há razoavelmente bastante referências ao final, mas nenhuma dizendo claramente as vantagens de usá-lo. Então uma pequena busca no google, e alguns foruns mais tarde, a conclusão que parece óbvia. Tanto os compiladores quanto a própria JVM podem se valer da informação de algo ser final para aplicar otimizações. Uma variável ser declarada como final pode fazer ela ir parar em uma área especial da heap, fazendo o acesso ser ligeiramente mais rápido. Observe o "pode" nessa frase. Eu fiz alguns testes com os compiladores do Java 6 e do Eclipse e o bytecode gerado com e sem final foi o mesmo. Nem sequer uma indicação de se a variável é final ou não. Vi algumas referências de fontes "confiáveis" (leia: posts em foruns) de que a máquina virtual consegue otimizar essas coisas. Mas procurando um pouco mais, fiu atras da especificação da máquina virtual, e no bytecode só é anotado se um atributo é final, e não se uma variável ou parâmetro é. Dessa forma, acho que do ponto de vista de otimização de código, não tem diferença nenhuma para a máquina virtual. O HotSpot(tm) vai identificar os pontos de otimização de variáveis e parâmetros por conta própria mesmo, sem ajuda do compilador.
Bom, eu vou procurar usar o final em todos os cantos mais por precaução contra atribuições em lugares errados, de qualquer forma.
Simulador de corrida
Muito empenho do cara, mas se ele gosta de jogos de corrida como eu, aposto que valeu a pena! Ele só precisa trocar o conta giros pra não ficar tanto tempo em "over rev" (não sei como dizer isso em português :( ) ;)
Mas ficou simplesmente muito bom, não reparei se a temperatura do motor tá mostrando direito, mas pisca alerta, indicador de combustível - com direito a luz piscando na reserva, temperatura deve estar funcionando também ;)
Cheguei nesse video por esse post do MeioBit. O jogo é Live For Speed. Não fucei muito, mas não é open source. Imagino como ele fez para conseguir essa interação com o jogo.
Quanto tempo será até encontrarmos um negócio desse pra vender?
Sobre as cotas na universidade
A algum tempo uma amiga minha passou um link para a relação candidato/vaga do vestibular da UFSC esse ano. Considerando o sistema de cotas, vários cursos estavam com uma relação < 1, aliás, acho que eram poucos os que estavam acima disso. E hoje ela passsou um link para esta notícia.
Para quem está com preguiça de ler a notícia, um magistrado aqui de Santa Catarina decidiu em favor de um candidato que ele poderia concorrer a todas as vagas para o curso de Geografia.
Um dos pontos que eu achei interessante é que
Outro ponto que discordo são as vagas para escola pública. Certo, essas não são tão racistas ou discriminatórias quanto as vagas para negros. Um professor que eu tive na graduação comentou uma vez que o vestibular hoje está servindo como um alarme, que está disparando avisando que tem algo muito errado com o sistema de ensino no Brasil, e que a solução adotada para que esse alarme pare de incomodar foi desligar o alarme, e não consertar a raiz do problema. Parece fazer sentido, afinal, é o que todo mundo faz quando o alarme do carro dispara, certo? Só desliga, e se ele disparar de novo, aí sim vai ver o que está errado. Perfeitamente lógico. Não vai tocar a segunda vez caso tivesse um ladrão para roubar o carro. Ou porque o som já foi da primeira, ou porque o carro resolveu passear com o ladrão. Espero que o alarme do vestibular dispare novamente logo.
Enquanto isso, professores da graduação, boa sorte!
Para quem está com preguiça de ler a notícia, um magistrado aqui de Santa Catarina decidiu em favor de um candidato que ele poderia concorrer a todas as vagas para o curso de Geografia.
Um dos pontos que eu achei interessante é que
"A supressão de vagas ao ‘não-negro’ viola o princípio constitucional da igualdade, sem que haja real fator para privilegiar o denominado ‘negro’, em detrimento do denominado ‘não-negro’". Eu não sou a favor de quotas para negros. Para mim, é uma forma "legalizada" de discriminação. Não somos todos iguais perante a constituição? Por que então alguns são favorecidos com um número especial de vagas? Fazendo isso só vai diminuir a qualidade do ensino superior no Brasil. Não que eu ache que negros não possuem condições de disputar vagas, muito pelo contrário, acho que eles têm capacidade tanto quanto os demais. A questão é que o sistema de quotas diminui a concorrência, fazendo com que os auto declarados negros concorram por uma quantidade de vagas, alguns por vagas de escolas públicas, e os demais no pacote "dos discriminados" (sim, os demais são os discriminados, pois só eles não ganharam vagas especiais!). Alguns candidatos que antes não passariam agora vão passar, pois parte da concorrência migrou para outras categorias. Claro que eu ainda posso queimar a língua (ou nesse caso, os dedos) e ver que os candidatos que entraram com cotas todos atingiram média de classificação no sistema de "balaio único", mas nesse caso, para que as cotas então?
Outro ponto que discordo são as vagas para escola pública. Certo, essas não são tão racistas ou discriminatórias quanto as vagas para negros. Um professor que eu tive na graduação comentou uma vez que o vestibular hoje está servindo como um alarme, que está disparando avisando que tem algo muito errado com o sistema de ensino no Brasil, e que a solução adotada para que esse alarme pare de incomodar foi desligar o alarme, e não consertar a raiz do problema. Parece fazer sentido, afinal, é o que todo mundo faz quando o alarme do carro dispara, certo? Só desliga, e se ele disparar de novo, aí sim vai ver o que está errado. Perfeitamente lógico. Não vai tocar a segunda vez caso tivesse um ladrão para roubar o carro. Ou porque o som já foi da primeira, ou porque o carro resolveu passear com o ladrão. Espero que o alarme do vestibular dispare novamente logo.
Enquanto isso, professores da graduação, boa sorte!
Mestre do Universo
Sério, me identifiquei muito nesse comic:
Fonte: PHD Comics!
Pra quem não conhece o PHD Comics, é um excelente comic sobre a vida de um pós granduando (e em partes de um graduando), e também uma excelente fonte de procrastinação, seguindo o lema "se nós não estamos trabalhando, por que você deveria estar?". Brincadeiras a parte, muitas tirinhas boas sairam lá, como o princípio da relevância, campo de negação (estou com muita preguiça de achar os links), etc.
Não sei se os programadores menos nerds que eu (de acordo com alguns, isso é a maioria dos programadores) também sentem isso, mas essa tirinha é uma descrição muito boa de como eu me sinto quando estou programando. Cada bug detonado, cada problema de design resolvido, cada solução nova representado na forma de um pedaço de software faz eu me sentir como o mestre de um universo, um universo só meu e bem pequeno, mas ainda assim que eu sou o mestre, um deus.
Há algum tempo eu usava na minha assinatura de email a seguinte frase:
Sempre gostei dela, mas ela foi substituida por uma do Scot Adams (criador do Dilbert) que tem um senso de humor um pouco mais apurado ;).
Um pouco mais sobre comics, não sei se outras pessoas também fazem esse tipo de maluquice ou se sou só eu, mas sempre acho um ou mais personagens nos comics que eu acompanho com o qual eu me identifico. Por exemplo, no Dilbert, me identifico com o próprio Dilbert, com o Dogbert (bom, quem não tem um desejo secreto de dominar o mundo?) e com o Wally e sua difícil tarefa de levar litros e litros de cafeína para o banheiro. Outro personagem com o qual me identifico bastante (e nesse me identificam com ele também) é o Garfield. Dizem que é por causa do estilo de humor (sínico eu? Capaz), mas talvez seja só porque eu como pouco, e gosto de lasagna. Mas nem sou laranja e nem gordo (eu acho). No PHD Comics eu me identifico bastante com a Cecília, a nerd que falou do código nessa tirinha que eu coloquei aí.
Bom, é isso. De pensar que antes de decidir montar o blog eu comentei com a Tetê (a segunda culpada por vocês lerem esse monte de besteira) que eu achava que não teria assunto suficiente pra escrever aqui. Incrível como é fácil escrever bobagem :D.
Chega por hoje, que esse sábado de manhã eu estou pensando sério em aproveitar um voleizinho na praida :D
PS: Preciso acertar o layout do site, tá complicado inserir esses comics :S
Fonte: PHD Comics!
Pra quem não conhece o PHD Comics, é um excelente comic sobre a vida de um pós granduando (e em partes de um graduando), e também uma excelente fonte de procrastinação, seguindo o lema "se nós não estamos trabalhando, por que você deveria estar?". Brincadeiras a parte, muitas tirinhas boas sairam lá, como o princípio da relevância, campo de negação (estou com muita preguiça de achar os links), etc.
Não sei se os programadores menos nerds que eu (de acordo com alguns, isso é a maioria dos programadores) também sentem isso, mas essa tirinha é uma descrição muito boa de como eu me sinto quando estou programando. Cada bug detonado, cada problema de design resolvido, cada solução nova representado na forma de um pedaço de software faz eu me sentir como o mestre de um universo, um universo só meu e bem pequeno, mas ainda assim que eu sou o mestre, um deus.
Há algum tempo eu usava na minha assinatura de email a seguinte frase:
"The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." (Joseph Weizenbaum, Computer Power and Human Reason)
Sempre gostei dela, mas ela foi substituida por uma do Scot Adams (criador do Dilbert) que tem um senso de humor um pouco mais apurado ;).
Um pouco mais sobre comics, não sei se outras pessoas também fazem esse tipo de maluquice ou se sou só eu, mas sempre acho um ou mais personagens nos comics que eu acompanho com o qual eu me identifico. Por exemplo, no Dilbert, me identifico com o próprio Dilbert, com o Dogbert (bom, quem não tem um desejo secreto de dominar o mundo?) e com o Wally e sua difícil tarefa de levar litros e litros de cafeína para o banheiro. Outro personagem com o qual me identifico bastante (e nesse me identificam com ele também) é o Garfield. Dizem que é por causa do estilo de humor (sínico eu? Capaz), mas talvez seja só porque eu como pouco, e gosto de lasagna. Mas nem sou laranja e nem gordo (eu acho). No PHD Comics eu me identifico bastante com a Cecília, a nerd que falou do código nessa tirinha que eu coloquei aí.
Bom, é isso. De pensar que antes de decidir montar o blog eu comentei com a Tetê (a segunda culpada por vocês lerem esse monte de besteira) que eu achava que não teria assunto suficiente pra escrever aqui. Incrível como é fácil escrever bobagem :D.
Chega por hoje, que esse sábado de manhã eu estou pensando sério em aproveitar um voleizinho na praida :D
PS: Preciso acertar o layout do site, tá complicado inserir esses comics :S
Friday, November 30, 2007
Idéias para posts futuros
So pra não perder a inspiração...
- Sobre o uso de final em atributos, parametros e variaveis locais
- Sobre o uso do "this" em métodos
- Sobre usar ou não construtor em suites JUnit
- Tools de refactor do Eclipse
E como estamos perto do Natal, um pequeno lembrete "by Garfield".
http://www.garfield.com/comics/comics_archives_strip.html?2007-ga071129
- Sobre o uso de final em atributos, parametros e variaveis locais
- Sobre o uso do "this" em métodos
- Sobre usar ou não construtor em suites JUnit
- Tools de refactor do Eclipse
E como estamos perto do Natal, um pequeno lembrete "by Garfield".
http://www.garfield.com/comics/comics_archives_strip.html?2007-ga071129
--
Otavio Pereira
otaviofp@gmail.com
---------------------------
Programmer (def): An organism that converts caffeine into software.
"Why are we all forced to go to work at the same time? Who arbitrarily decided that 8 AM was a good time for everyone to go to work?" (Dilbert)
Wednesday, November 28, 2007
Sunday, November 25, 2007
Save action on Eclipse
A post in English, for a change. This morning I was configuring my Eclipse workspace to work on my master thesis project and found something interesting. I was not really into working on the project, so I decided to make a small tutorial showing the "save actions" feature from Eclipse 3.3. There probably is some better tutorials out there about this.
Eclipse is a great IDE, and the more I use it, the more I believe in this. Today I came across the save actions feature, new in Eclipse 3.3. Didn't think it would be so great. For a start, you can make Eclipse format and organize your imports after every save. This alone might save the lifespan of some keys in your keyboard, if you are a freak like me that can't write more than a few lines of code without issuing the combo ctrl+shift+f and ctrl+shift+o :). The save actions can be configured in Window -> Preferences -> Java / Editor / Save Actions.
This is the preference page:
After enabling it, you can right away tell Eclipse to format the source code and to organize imports. It'll use your project defaults in every file.
The additions actions section has lots of treasures, and I'll walk trough each one of them. When you click on "Configure" a screen will appear with some tabs, each one for each action category. The leftmost one is Code style that goes very well with the code format options.
Most coders have they own coding style, but when working in a coding team some care must be taken so that the great number of individual coding style doesn't jeopardize productivity. Most companies define their "coding standards" that every single programmer is required to follow.
One of the things that can be enforced by a code style is the use of blocks (or curly brackets) for single-statement control statements. While some might say that not having the brackets reduce the visual complexity of the code, others might say that not having them at all is "bug door" waiting to be open. Whatever is the policy, Eclipse can help enforcing it.
On the "for" side of the things, I'm not really sure if using the enhanced for generates better code at all, but one thing I experienced. It certainly does help in code reading. You see the enhanced for structure, you know that for is iterating over an specific array, the line is shorter than the regular Iterator use. And I also know that going trhough an old Java 1.4 code and converting the fors to the enhanced version is boring. No challenge at all and you just waste some effort time. Why don't let just eclipse handle it by selecting the "Converting for loops to enhanced"? It is pretty smart, but has its limitations.
The following code will not be converted:
for (Iterator iterator = list.iterator(); iterator.hasNext(); ) {
Number number = (Number)iterator.next();
/* ... */
}
I can't see a clear reason, but my guess is that it would be just complicated to ensure in a safe way that every iterator use in a raw type list is safe to be converted (someone correct me if I am wrong, but in my tests here this was not converted).
The conversion works for arrays too:
public void method(int[] array)
{
for (int i = 0; i < 2 ="=" 2 ="=">Rename action :). One limitation it has that I can't really see why is that if had you wrote the for increment as ++i instead of i++ the loop wouldn't be converted.
More on the code style, you can tell Eclipse to handle your parenthesis also, by reducing the number of parenthesis, letting him cleanup unnecessary ones, or by summing up a great number of them by always surrounding the expressions.
Another thing it can manage is the existance of the final modifiers. Some like to have private fields that are never modified marked as final. Others say that parameters should never be reassigned, and so on. Eclipse can add final modifiers to private field, paramters and local variables. Just choose your preferred combination :).
A few words on member access rules. It's possible to have Eclipse to policy your use of the qualifier to non-static members. Some programmers like to have all non-static members qualified with a this, others avoid having this at all (by naming non-static fields with a leading or trailing _, or with some prefix such a 'm', etc), and others just like to have the this when it is necessary. If you are on the latter 2 groups, tell Eclipse to just use this when necessary, or if you are in the first, let him ensure every access is qualified by this. Works for methods and fields.
You can as easily let Eclipse handle your access to static members, by qualifying field or method accesses so every static access will have the class qualifier even in the declaring class. You can also let it change static access through subtypes (for instance, using a member of IResource from an IFile class), or through instances (using a member from IResource from your local variable instance). Eclipse can be programmed to show compiler warnings for those 2 items, but isn't it just better to just have him solve the problems?
During the lifecycle of a source code, many members will be introduced, some other will be removed, and some will just loose the purpouse but will be left unremoved because the programmer didn't see them. This is another situation that ever since I can remember Eclipse is good in warning us, but now he just be configured to solve the problem by himself by removing unused imports, removing unused private members or unused local variables. Just let him remove the garbage. Casts and $NON-NLS$ tags can also be automatically cleaned up.
But wait! Eclipse is not just powerful to remove code, he can also insert some stuff. But, it's easier to destroy than to construct, so the options to insert code are just a few, yet they are useful. You can let Eclipse ensure that every overriding method has its @Override annotation, so if for some reason the original method is removed it is just easier to figure out that the code won't work (it'll not even compile, to be honest).
Eclipse can insert the new @Deprecated annotation to members or classes that carry the old @deprecated javadoc tag.
And in the very end, you can have Eclipse doing some code organization for you. If you have strict policies over trailing whitespaces (you know, that extra whitespace that the IDE inserted when you decided to add that extra blank line before the method by placing the cursor just before the declaration and not on the first column), you can let Eclipse wipe them, or wipe them only if the line is empty, or leaving them alone. The choice is all yours.
And another little help Eclipse can do is if you have policy for member ordering, such as "place all your constructors togheter, after the fields" and so on. You can have Eclipse applying the "Sort members" action in every save, so you can guarantee the members are ordered.
You could've figured out just about everything I wrote here, but hey, I had a sunday to waste ;).
Eclipse is a great IDE, and the more I use it, the more I believe in this. Today I came across the save actions feature, new in Eclipse 3.3. Didn't think it would be so great. For a start, you can make Eclipse format and organize your imports after every save. This alone might save the lifespan of some keys in your keyboard, if you are a freak like me that can't write more than a few lines of code without issuing the combo ctrl+shift+f and ctrl+shift+o :). The save actions can be configured in Window -> Preferences -> Java / Editor / Save Actions.
This is the preference page:
After enabling it, you can right away tell Eclipse to format the source code and to organize imports. It'll use your project defaults in every file.
The additions actions section has lots of treasures, and I'll walk trough each one of them. When you click on "Configure" a screen will appear with some tabs, each one for each action category. The leftmost one is Code style that goes very well with the code format options.
Most coders have they own coding style, but when working in a coding team some care must be taken so that the great number of individual coding style doesn't jeopardize productivity. Most companies define their "coding standards" that every single programmer is required to follow.
One of the things that can be enforced by a code style is the use of blocks (or curly brackets) for single-statement control statements. While some might say that not having the brackets reduce the visual complexity of the code, others might say that not having them at all is "bug door" waiting to be open. Whatever is the policy, Eclipse can help enforcing it.
On the "for" side of the things, I'm not really sure if using the enhanced for generates better code at all, but one thing I experienced. It certainly does help in code reading. You see the enhanced for structure, you know that for is iterating over an specific array, the line is shorter than the regular Iterator use. And I also know that going trhough an old Java 1.4 code and converting the fors to the enhanced version is boring. No challenge at all and you just waste some effort time. Why don't let just eclipse handle it by selecting the "Converting for loops to enhanced"? It is pretty smart, but has its limitations.
The following code will not be converted:
for (Iterator iterator = list.iterator(); iterator.hasNext(); ) {
Number number = (Number)iterator.next();
/* ... */
}
I can't see a clear reason, but my guess is that it would be just complicated to ensure in a safe way that every iterator use in a raw type list is safe to be converted (someone correct me if I am wrong, but in my tests here this was not converted).
The conversion works for arrays too:
public void method(int[] array)
{
for (int i = 0; i < 2 ="=" 2 ="=">Rename action :). One limitation it has that I can't really see why is that if had you wrote the for increment as ++i instead of i++ the loop wouldn't be converted.
More on the code style, you can tell Eclipse to handle your parenthesis also, by reducing the number of parenthesis, letting him cleanup unnecessary ones, or by summing up a great number of them by always surrounding the expressions.
Another thing it can manage is the existance of the final modifiers. Some like to have private fields that are never modified marked as final. Others say that parameters should never be reassigned, and so on. Eclipse can add final modifiers to private field, paramters and local variables. Just choose your preferred combination :).
A few words on member access rules. It's possible to have Eclipse to policy your use of the qualifier to non-static members. Some programmers like to have all non-static members qualified with a this, others avoid having this at all (by naming non-static fields with a leading or trailing _, or with some prefix such a 'm', etc), and others just like to have the this when it is necessary. If you are on the latter 2 groups, tell Eclipse to just use this when necessary, or if you are in the first, let him ensure every access is qualified by this. Works for methods and fields.
You can as easily let Eclipse handle your access to static members, by qualifying field or method accesses so every static access will have the class qualifier even in the declaring class. You can also let it change static access through subtypes (for instance, using a member of IResource from an IFile class), or through instances (using a member from IResource from your local variable instance). Eclipse can be programmed to show compiler warnings for those 2 items, but isn't it just better to just have him solve the problems?
During the lifecycle of a source code, many members will be introduced, some other will be removed, and some will just loose the purpouse but will be left unremoved because the programmer didn't see them. This is another situation that ever since I can remember Eclipse is good in warning us, but now he just be configured to solve the problem by himself by removing unused imports, removing unused private members or unused local variables. Just let him remove the garbage. Casts and $NON-NLS$ tags can also be automatically cleaned up.
But wait! Eclipse is not just powerful to remove code, he can also insert some stuff. But, it's easier to destroy than to construct, so the options to insert code are just a few, yet they are useful. You can let Eclipse ensure that every overriding method has its @Override annotation, so if for some reason the original method is removed it is just easier to figure out that the code won't work (it'll not even compile, to be honest).
Eclipse can insert the new @Deprecated annotation to members or classes that carry the old @deprecated javadoc tag.
And in the very end, you can have Eclipse doing some code organization for you. If you have strict policies over trailing whitespaces (you know, that extra whitespace that the IDE inserted when you decided to add that extra blank line before the method by placing the cursor just before the declaration and not on the first column), you can let Eclipse wipe them, or wipe them only if the line is empty, or leaving them alone. The choice is all yours.
And another little help Eclipse can do is if you have policy for member ordering, such as "place all your constructors togheter, after the fields" and so on. You can have Eclipse applying the "Sort members" action in every save, so you can guarantee the members are ordered.
You could've figured out just about everything I wrote here, but hey, I had a sunday to waste ;).
Tetris
Pra comceçar bem o domingo... acho que não tem ninguém no mundo que não conhece tetris. Eu sempre achei que ele era um jogo sem fim, que depois de cada nível sempre teria um próximo até que a velocidade do computador superasse a do jogador. Bom, tem um japonês (tinha que ser! =oP) que me mostrou em 6:23 (6 minutos e 23 segundos, e não 6 horas!!!) que pelo menos em um tetris específico o "Master mode" tem fim. Alias, eu tenho a leve impressão que ele trapaceou, ele sabia a seqüência de peças antes do jogo... o final do vídeo me deu essa impressão. Sem mais spoilers, sorte minha que eu tava sentado quando vi isso, assim meu queixo só da altura do pescoço até as pernas.
Artigo original: http://www.gamesradar.com/us/pc/game/news/article.jsp?articleId=200711239291393082&releaseId=2006032219817514003§ionId=1006&pageId=20071123103336234046
PS: A teoria dos cyborgs parece fazer sentido...
Artigo original: http://www.gamesradar.com/us/pc/game/news/article.jsp?articleId=200711239291393082&releaseId=2006032219817514003§ionId=1006&pageId=20071123103336234046
PS: A teoria dos cyborgs parece fazer sentido...
Friday, November 23, 2007
Aventuras com JUnit
Bom, hoje aconteceram 2 eventos importantes que levaram a esse post, um deles foi a Thânia, software developer na minha equipe, me colocar na cabeça a idéia de que seria uma boa coisa eu fazer um blog - portanto, já sabem uma das culpadas desse blog existir - a outra culpada eu aponto em um momento futuro ;). O outro evento foi uma pergunta que a Thânia me fez. O cenário, descrito em um post dela, é resumido em: eu inicializava alguns atributos da suite de testes em um método @Before, agora cheguei a conclusão que esses atributos devem ser inicializados apenas 1 vez para todos os testes. A solução que ela relutantemente aceitou é mover a inicialização para um método @BeforeClass, e transformar os atributos em static (pois todo método @BeforeClass deve ser static, e não é possível acessar atributos não static em um método static, bom, pelo menos não de modo simples e direto no código). Depois vi o post no blog dela falando sobre isso, e como ela não tinha aceitado muito bem, resolvi ir atrás e descobrir algumas razões para fazer desse jeito.
A primeira coisa que eu fui ver foi a FAQ do JUnit, onde encontrei uma pergunta falando sobre os @BeforeClass e @AfterClass, e nessa pergunta, eles basicamente diziam que @BeforeClass e @AfterClass são do lado negro da força, e normalmente indicam um problema. Bom, o fato é que as vezes eles são um mal necessário, por exemplo, quando os testes dependem fortemente de algum recurso caro para ser inicializado, como uma conexão a um banco de dados, ou algo do gênero. Não vou entrar no mérito de se o caso dela é um indicativo de problema ou não, mas sim levar o foco à pergunta não bem respondida: por que fazer os atributos virarem static ao invés de usar inicialização em um construtor ou na declaração.
Entre as duas últimas opções, pessoalmente prefiro a opção do construtor. Fica a promessa de um novo post sobre isso. Mas independente disso, as duas são equivalentes. Então a pergunta se resume a: tornar static ou manter como atributos de instância. Quando respondi pra ela me ocorreu uma primeira ideia para justificar a transformação para static: execução paralela dos testes. Isso não foi suficiente pra convencê-la, e para falar a verdade, nem eu acredito mais nisso. A outra justificativa para ela surgiu depois uma busca nos meus arquivos de memória por alguma coisa na documentação do JUnit que garantisse que cada suite seria instanciada uma única vez. Não achei. E isso para mim já é motivo suficiente para adotar a alternativa mais segura. Resolvi pesquisar um pouco mais sobre isso quando cheguei em casa, mas optei dessa vez por um método "hands on". Montei alguns cenários e mandei rodar o JUnit. Basicamente, fiz testes com System.out.println() em vários momentos do ciclo de vida de um teste JUnit. Inicializadores static, métodos @BeforeClass e @AfterClass, métodos @Before e @After, inicializadores regulares, métodos @Test, e depois usei herança entre testes, para ver como a coisa se comportaria.
Mandei rodar, e estava quase pensando em o que mais procurar para justificar a transformação em static, achando que eu veria a saída dos inicializadores somente antes do primeiro @Before. No entanto, o que eu vi foi: o JUnit cria uma nova instancia da suite para cada teste, portando, colocar código em construtor ou em inicializadores não-static é a mesma coisa que definir eles em um método @Before, que era a solução anterior e por algum motivo deixou de ser adequada.
Não fui na documentação do JUnit buscar se isso tem alguma explicação ou foi simplesmente decisão de projeto. Parece fazer sentido do ponto de vista de independência de testes essa decisão, dessa forma, o framework dá uma mãozinha para evitar que um teste influencie no resultado de outro.
That's all, folks!
A primeira coisa que eu fui ver foi a FAQ do JUnit, onde encontrei uma pergunta falando sobre os @BeforeClass e @AfterClass, e nessa pergunta, eles basicamente diziam que @BeforeClass e @AfterClass são do lado negro da força, e normalmente indicam um problema. Bom, o fato é que as vezes eles são um mal necessário, por exemplo, quando os testes dependem fortemente de algum recurso caro para ser inicializado, como uma conexão a um banco de dados, ou algo do gênero. Não vou entrar no mérito de se o caso dela é um indicativo de problema ou não, mas sim levar o foco à pergunta não bem respondida: por que fazer os atributos virarem static ao invés de usar inicialização em um construtor ou na declaração.
Entre as duas últimas opções, pessoalmente prefiro a opção do construtor. Fica a promessa de um novo post sobre isso. Mas independente disso, as duas são equivalentes. Então a pergunta se resume a: tornar static ou manter como atributos de instância. Quando respondi pra ela me ocorreu uma primeira ideia para justificar a transformação para static: execução paralela dos testes. Isso não foi suficiente pra convencê-la, e para falar a verdade, nem eu acredito mais nisso. A outra justificativa para ela surgiu depois uma busca nos meus arquivos de memória por alguma coisa na documentação do JUnit que garantisse que cada suite seria instanciada uma única vez. Não achei. E isso para mim já é motivo suficiente para adotar a alternativa mais segura. Resolvi pesquisar um pouco mais sobre isso quando cheguei em casa, mas optei dessa vez por um método "hands on". Montei alguns cenários e mandei rodar o JUnit. Basicamente, fiz testes com System.out.println() em vários momentos do ciclo de vida de um teste JUnit. Inicializadores static, métodos @BeforeClass e @AfterClass, métodos @Before e @After, inicializadores regulares, métodos @Test, e depois usei herança entre testes, para ver como a coisa se comportaria.
Mandei rodar, e estava quase pensando em o que mais procurar para justificar a transformação em static, achando que eu veria a saída dos inicializadores somente antes do primeiro @Before. No entanto, o que eu vi foi: o JUnit cria uma nova instancia da suite para cada teste, portando, colocar código em construtor ou em inicializadores não-static é a mesma coisa que definir eles em um método @Before, que era a solução anterior e por algum motivo deixou de ser adequada.
Não fui na documentação do JUnit buscar se isso tem alguma explicação ou foi simplesmente decisão de projeto. Parece fazer sentido do ponto de vista de independência de testes essa decisão, dessa forma, o framework dá uma mãozinha para evitar que um teste influencie no resultado de outro.
That's all, folks!
Hello, world!
Bom, todo programador que começou com uma nova linguagem de programação ou tecnologia já fez um "Hello, world!", a pedra fundamental do mundo da computação. Então, já que estou começando aqui, nada melhor que um hello world para ver como a coisa se comporta =).
Bom, vamos ver quanto tempo eu duro com esse blog =oP. Não vou me restringir a um assunto específico (apesar de que acho que é isso que faz um blog de sucesso, mas quem quer sucesso já na primeira vez?!).
Boa sorte!
Bom, vamos ver quanto tempo eu duro com esse blog =oP. Não vou me restringir a um assunto específico (apesar de que acho que é isso que faz um blog de sucesso, mas quem quer sucesso já na primeira vez?!).
Boa sorte!
Subscribe to:
Posts (Atom)