Re: EP3

[Fabio Silva Dias <fdias@linux.ime.usp.br>]

Professor e alunos,

S�o duas faces da mesma moeda. Eu acho que o professor est� dando um
prazo curto para fazer o EP3, assim como o prazo do EP2 j� tinha sido
relativamente curto considerando que todo mundo tem muitas provas e
trabalhos. Mas isto ocorre porque foi definido no come�o do semestre que
ter�amos 4 exerc�cios-programa. 
Acho invi�vel a id�ia de 4 EPs porque o 1.o. demorou demasiado para ser
formulado e o 2.o tambem. Caso o primeiro tivesse sido formulado umas
duas semanas antes, isto tudo n�o ocorreria. Mas tem o outro lado, n�o
sei se t�nhamos mat�ria suficiente para tal. Talvez o EP2 devesse ter
sido solicitado no dia da entrega do EP1...
Fico imaginando que transtorno n�o ser� o EP4, onde todos ter�o
trabalhos finais e provas finais e subs, onde ir�o decidir o futuro do
semestre e, talvez, do tempo de formatura. Com certeza ser� uma
sobrecarga desagrad�vel e, considerando as 3 semanas que temos para o
EP3, s� restar�o, na melhor das hip�teses mais 3 semanas para o EP4! Se
simplesmente adiarmos o EP3 porque o prazo � pequeno, haver� uma
inconsist�ncia pois sobrar� muito menos tempo para o EP4. Provavelmente
faltar�o as duas semanas a que me referi antes.
Destarte, sugiro um planejamento melhor entre alunos x professor,
principalmente para os pr�ximos cursos, mas para solucionar este
problema, torna-se discut�vel a id�ia de transformar o EP4 em optativo,
ou como o EP de recupera��o ou alguma outra forma. Ou ent�o gerar um
apendice ao EP3 tornando-o mais complicado, mas deixando-o como o �ltimo
EP. Com certeza seria no EP4 que iriamos tratar de assuntos mais
interessantes, mas creio que, devido aos erros de planejamento iniciais,
n�o compensa sobrecarregar os alunos para um mero cumprimento de uma
formalidade.

Pensem nisto,

Fabio

Tiago wrote:
> 
> Andr� Rodrigo Sanches wrote:
> 
> > Professor. J� vou lhe avisando de antem�o que esta data � invi�vel dado as
> > provas e trabalhos que alguns ter�o e apenas 15 dias para fazer o ep...
> 
>     Tamb�m considero invi�vel este prazo de 15 dias. Fazer a parte de network,
> mesmo conhecendo sockets do Java, d� trabalho. Ainda tem a concorr�ncia, com todas
> aquelas op��es (-cozinh, -suicida, -atraso n) que na verdade guiam o
> desenvolvimento (j� que um rascunho do software j� teria todos estes problemas),
> mas que podem demorar para implementar. Paralelamente faremos o(s) cliente(s).
>     Ou seja, s�o 2 camadas mais o(s) cliente(s) em 15 dias, e infelizmente eu perdi
> a palestra sobre programa��o extrema. ; ) E a documenta��o do util.concurrent �
> extensa e fica dif�cil encontrar as classes relevantes.
> 
>     N�o tenho certeza se um adiamento � necess�rio, nem de quanto tempo deveria
> ser. Por enquanto, s� aconselho que o pessoal comece logo, fa�a um exerc�cio de
> engenharia OO antes de sair programando, mas os profs. est�o dando EPs (sem contar
> os semin�rios do Mandel) s� agora, depois do break. Vai ficar apertado...
> 
>     Uma d�vida concreta: as contas v�o estar em arquivo? Um bin�rio, com a
> serializa��o do vetor? Texto? Eu escolho? O BD tem que ter suas altera��es
> persistentes entre se��es do servidor, ou posso ter valores padr�o toda vez que o
> servidor inicia (por exemplo, usando Properties)? A princ�pio, nenhuma restri��o,
> certo? "As grandes perguntas encerram a pr�pria resposta"? : )
> 
> Por enquanto � s�, espero n�o ter sido agressivo, hj tomei caf� demais.
> Tudo de bom!!