sergiotaborda wrote:

Ironlynx wrote:
public class MathUtils{ public long fatorial(long n){ if (n==0) return 1; else return n*fatorial(n-1); } }

melhor como:

public class MathUtils{ public long fatorial(long n){ retunr n<=1 ? 1 : n*fatorial(n-1); } }

A forma recursiva é apenas ruim porque polui o stack. Tlv melhor seja assim

sergiotaborda wrote:
public class MathUtils{ public long fatorial(long n){ if (n<0){ throw new IlegalArgumentException(); } F f = new F(n); while(!f.isFinished()){ f.factorize(); } return f.value; } private class F { long n; long value=1; F(long n){ this.n =n; } boolean isFinished(){ return n<=1; } void factorize(){ value *= n; n--; } } }

boaglio wrote:Esse post é só para ter uma idéia do que se tem hoje em RoR por aqui

plentz wrote:Agora estava pensando...qual é a difrenteça de eu colocar

<a href="#" onclick="minhaFuncao()">Ativa função</a>

para

<a href="javascript:minhaFuncao()">Ativa função</a>

Alguém saberia me dizer se tem alguma?

emerleite wrote:

xandroalmeida wrote:Mas eu acho que ajuda bastante você olhar um diagrama de classes do seu dominio, mesmo que você já conheça o projeto. Desde que esteja atualizado, mas se for para fazer um diagrama deste e não manter atualizado é melhor não fazer mesmo.

O que você acha em dar uma olhada na suite de testes para saber as funcionalidades do sitema? Caso não exista nada, é muito simples usar um Jude da vida pra fazer engenharia reversa. Caso já existam os tais diagramas, haverá 99% de chance de estar desatualizado.

cv wrote:

xandroalmeida wrote:Os projetos geralmente não morrem depois de entregues. Tem-se as melhorias, correções e migração, e muitas vezes são outras equipes que fazem isso.

Sim, e alguma vez vc ja pegou um projeto que foi deixado por outra equipe e pensou "puxa, a primeira coisa que eu preciso fazer eh ler o UML!"?

louds wrote:
Quase todos diagramas da UML não tem muito valor depois do sistema estar pronto, fora que 99% dos clientes pedem documentação porque alguem falou que é importante ter e nunca vão se quer ler.

louds wrote:
Além disso, qual o problema de entregar fotos digitais dos diagramas? Se precisar editar existe sempre o paintbrush.

louds wrote:Todo UML, e modelagem em geral, que eu preciso fazer, uso lapis, borracha e papel. Muito mais produtivo e facil de usar. Se precisar armazenar digitalmente o resultado, tiro foto.

cv wrote:De qualquer forma, vc provavelmente esta bastante acostumado com esse padrao (request.getParameter e request.getAttribute, alguem?)

saoj wrote:Java tem um suporte maravilhoso para programaçõa concorrente. Não vou entrar no mérito se ERLANG ou XXXX é melhor, mas se vc quer ou tem que usar Java vc estará em boas mãos.

LuizClaudio wrote:
Eu concordo com vc, mas eu estou pensando no seguinte, em algum tempo teremos máquinas com n núcleos, se vc não fizer seus programas com programação concorrente que vantagem eles vão tirar dessas máquinas, evitemente terei de usar novas tecnologias e novas/velhas linguagens "melhores que java" para esse cenário, mas estou estudando com seria um ambiente de produção com um cenário desse.

cv wrote:

xandroalmeida wrote:No mais, não concordo com parâmetros em hash e continuo achando que usar isso é gambi. Até entendo a preferencia pela legibilidade exposta pelo cv, mas o código vai ficar cheios de if else

Cheio de if/else ai na sua cabeca.

def foo(args) bar = args.delete :bar baz = args.delete :baz bar * baz end foo :bar => 2, :baz => 2 # 4

Maurício Linhares wrote:
Bem, então estude Ruby, entenda porque a linguagem não tem overloading de método e explique pra nós porque overloading de método é uma coisa interssante

...