| Autor |
Mensagem |
|
|
Bani. Que viagem é essa?
O que eu falei foi dakela cena (que inclusive passa no trailer - sem spoiler) de Neo sentado e uma sentinela, meio q em forma de luz, atravessando ele.
Agora sim é spoiler
Nada a ver. Ele está sentado na nave e as sentinelas estão do lado de fora. Ele ve as sentinelas como feixes de luz. Uma sentinela meio que "colide no hover", mas logo em seguida, é mostrada a cena de Neo sendo atravessado por ela dentro da nave.
Viagem total.
Mais Spoiler
O filme deixou de ser ficção científica e passou a ser de fantasia. Tudo no filme, até o segundo pelo menos, era explicado dentro da matrix. Os lobisomens e fantasmas por exemplo: programas rebeldes que vagavam pela matrix. Neo consegue fazer o que faz por que como o mundo era virtual, e não real, ele "podia manipula-lo como bem entendia", segundo palavras do próprio Morpheus.
Mas no fim do segundo filme e no terceiro, ele, no mundo real, manipula as máquinas. Então: ou Zion tb era virtual, e apenas mais uma forma de controle, ou o filme virou "a vida e morte de Jesus".
Eu esperava explicações no terceiro. Queria que eles mostrassem se Zion era realmente virtual ou não. Não explicaram nada (embora que agora eu ache que Zion seja real) e levantaram ainda mais dúvidas.
A melhor explicação (altamente subjetiva e sem nenhuma base de sutentação, mas ainda assim interessante) foi a de Richardson, de que, como as máquinas "fabricam os humanos", Neo já foi concebido com hardware que o permitisse manipular as máquinas fora da Matrix. E ele já era o predestinado (lembrando que essa onde de predestinado era viagem de Morpheus e que Neo era apenas a anomala que surge de tempos em tempos).
Só que essa teoria tem um problema. O filme passa a entender que as máquinas não queriam que Neo conseguisse fazer o que faz fora da Matrix. O objetivo da anomalia era reinserir seu código na fonte, destruir Zion, salvando algumas poucas pessoas, e recomeçar o ciclo. Provavelmente, qd Morpheus se refere ao "primeiro de nós que se rebelou cotra a Matrix", ele, na verdade, se referenciou a quinta anomalia sistemica. Dito isto, as máquinas não colocariam hardware especial em Neo para que ele fosse tão poderoso fora dela.
Mas ainda há um porém: Neo deveria escolher a porta da direita: destruição de Zion e recomeço do ciclo. Mas ele faz o contrário e o Arquiteto parecia saber a decisão que Neo eria tomar. Veja bem. Se o Arquiteto queria que o ciclo se perpetuasse, por que ele mostrou trinity? Ele mesmo diz que consegue prever o sentimento se formando em Neo (o amor). Então ele sabia que Neo escolheria a outra porta. Mais uma coisa: por que se preocupar em dar uma chance a Neo a essa altura do campeonato. Por que não engana-lo e manda-lo logo para a porta da direita.
Quando você termina de assistir ao segundo filme, você vê a conversa do Oráculo com o Arquiteto. Ele não aprecia muito a paz entre humanos e máquinas e diz que o Oráculo tomou uma atitude arriscada, que eu interpreto como: ao invez de destruir Zion e recomeçar o ciclo, vou fazer Neo tomar outra rota e tentar trazer paz entre humanos e máquinas. O oráculo parece se afeiçoar dos humanos enquanto o arquiteto os despreza.
Li uma vez uma teoria, muito interessante por sinal, em que o amor entre Neo e Trinity foi induzido pelo o Oráculo. E os biscoitos e confeitos que o Oráculo oferece são programas para garantir que Neo siga uma determinada rota. Com Neo apaixonado por Trinity, é mais fácil ele escolher a outra porta (loucuras da paixão :P). O Oráculo conseguiria então mudar o ciclo e trazer a paz entre humanos e máquinas.
E afinal. Como é que o Oráculo prevê coisas fora da Matrix? Ela diz que só percebe o futuro das escolhas que alguém já fez e blah, blah, blah. Não entendi nada.
E mais. No terceiro filme ninguém da uma resposta direta a nenhuma pergunta, por mais simples que seja. Ora bolas.
Não vou assistir o terceiro filme de novo nos cinemas para tentar entender. Esse filme não vale meus R$14,00 suados.
|
 |
|
|
Ah sim. O senhor dos anés será exibido novamente nos cinemas dias 9 e 12 de dezembro (ou será 6 e 12 ou 9 e 16 - sei lá).
Exibirão o filme com a meia hora a mais que foi cortada. por isso que não lançaram o DVD especial aqui no Brasil.
Já sei que ano que vem vou estar comprando os DVDs novamente :( .
|
|
|
|
:x
Uma droga (em se tratando de história)
Nota 10 (para as cenas de ação)
Duvido que Matrix tenha sido concebido como uma trilogia. Acho que na verdade quiseram é ganhar mais dinheiro e vieram com essa onda. O estilo do filme muda radicalmente: pouca história, muita ação sem sentido.
Acho que a crítica do cara do Terra foi correta: "Os irmãos wasdnfbjdfjjd escolheram o elemento errado que fez de Matrix um sucesso". Optaram pelo visual e deixaram a história de lado.
<editado pela moderação - passe o mouse em cima para ler>
E que diabos significa aquela sentinela passando por dentro de Neo???
</editado>
|
|
|
|
Oi galera. Como é que vai a força.
O RecJUG iniciou um grupo para desenvolvimento de Jogos para celulares utilizando J2ME. Tivemos nossa primeira reunião e já temos um monte de trabalho pra fazer. Quem se interessar em ajudar, visite nosso fórum:
http://forum.recjug.com.br/viewtopic.php?t=171
Espero a ajuda de vocês
[]
Daniel Freitas
|
|
|
|
|
XML - XMLBuddy ou Oxygen (este último é pago).
|
|
|
|
Saiu o novo lomboz. Agora com JSP code assist :D (finalmente).
http://www.theserverside.com/home/thread.jsp?thread_id=20925
To baixando para testar. :)
|
|
|
|
Umlauf wrote:Eu li uns artigos na net há algum tempo atrás, que provavam por a+b que a idéia original do .NET foi da Borland e a Micro$oft fez um acordo com ela pra ser a dona da tecnologia e a Borland só poderia lançar sua IDE para .NET após alguns anos depois do VS.
Vou procurar os links e posto aqui, mas não deve ser difícil de achar no Google, se algém quiser arriscar. :)
Quem desenvolveu o frameowrk notYET (incluindo a IL e a VE) foi Andrews "sei q lá", que fez parte da fundação do Delphi.
EDITED:: Ih já tinham postado isso :P.
|
|
|
|
pelo visto o Yoder ta fazendo um tour pelo Brasil!
É. Ele está participando do SugarLoafPLoP 2003 que acontecerá por aqui (na praia de Porto de Galinhas).
Mas, sabe como é. Congresso em praia... Não sei se dá muito certo não :P
http://www.uol.com.br/portodegalinhas/
|
|
|
|
Como prometido, acabei de voltar do workshop de agile modeling promovido pelo CESAR/Recife. Teve uma palestra muito interessante lá de Joseph Yoder sobre Adaptive Object Model, cujo conceito básico é que as entidades são representadas através de INSTÂNCIAS ao invés de classes propriamente ditas.
Com isso, há a possibilidade do próprio "cliente" (business people) implementar alterações no sistema, sem necessidade de compilação e conhecimento técnico de programação.
O link abaixo sumariza o conceito. Aconselho a leitura.
http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsWICSA3.pdf
http://www.adaptiveobjectmodel.com/
|
|
|
|
Acabei de ler um artigo sobre como não confundir "manter simples" com "reinventar a roda". O exemplo do cv veio bem acalhar.
Vejam só o que aconteceu aqui na empresa:
Estamos desenvolvendo um projeto aqui e seguimos o modelo clássico. Tive a tarefa então de levantar as entidades do sistema(sim, isso significa todas). Pois bem, estava lá muito feliz, construindo as classes com o Together até que chegou numa parte de frequência para funcionários. Pois bem, como é que diabos vou controlar a frequência? Apenas um apurado das faltas por mês ou um sistema de ponto completo, com hora extra e tudo o mais?
Como não sabia o que vinha pela frente, comecei a modelar a solução mais genérica possível, mas como não dominava o assunto, parei no meio e deixei para terminar quando fosse realmente implementar.
Pois é, tivemos várias reuniões exaustivas (2+ horas de reunião) pensando em como fazer essa parte (não tínhamos contato com o cliente - na verdade, o cliente nem sabe que precisa de um software - coisas de governo). Depois de perder muito tempo (que devem ter totalizado, pelo menos, 2 dias e meio só de análise), conseguimos do cliente o que eles necessitavam: um apurado de faltas no mês.
Toda nossa análise foi perdida e substituida por "FALTAS DO FUNCIONARIO X ONDE MES = Y"  .
Analisando via XP, notei que muitos desses problemas poderiam ter sido evitados. Caí no problema do "desenvolvedor vidente", que tenta imaginar todo o sistema e que quando chega na hora H vê que não era necessário tanto esforço. Achei interessante uma colocação que lí: "o problema com desenvolvedores videntes é que o ser humano é péssimo como vidente"  .
Pena que seja difícil usar XP aqui na empresa... Acho que vou ter que usar em um empreendimento próprio.
Como é que vou convencer o chefão que pair programing e tão, se não mais, produtivo ?
|
|
|
|
Eu sabia que isso ia causar um pouco de confusão. Eheh. Mas já tinha pensado na resposta. Esqueci de mencionar que essa é a visão do desenvolvedor. Lógico que se os requisitos mudarem, você deve mudar sua implementação. Só que agente sabe que, pelo menos na grande maioria das aplicações (comerciais pelo menos), mudanças nos requisitos não impactam no framework escolhido para persistência.
Mudando de assunto.
Então, por que simples ao invés de flexível? (http://www.xispe.com.br/wiki/wiki.jsp?topic=SimplicityKey)
Caramba, realmente parece que a filosofia do XP é "não pense no futuro, não desenvolva frameworks que suprirá todas as suas necessidades, simplesmente coloque o código para rodar".
É por isso que XP causa tanta comoção. Eu mesmo, como desenvolvedor, tendo a procurar soluções brilhantes em vez de simples, sempre querendo implementar uma grande funcionalidade/framework ao invés de mandar ver nos "INSERTS". Afinal, o desafio é o que me mantém trabalhando com informática.
Gostaria de trabalhar com XP. Tudo que falo aqui é mera especulação e tenho certeza que minha visão mudará drasticamente após usar XP na prática.
Por enquanto, a aplicação da teoria nos projetos que participo hj é muito divertida. Estamos lidando com dezenas de problemas de projeto que o XP aponta. E eu sempro digo: "Segundo o XP...". Eheheh o pessoal já ta ficando de saco cheio :D.
|
|
|
|
Mermão. Pode até ser. Mas veja bem, o trabalho para colocar o hibernate funcionando é tão pequeno que é melhor começar por ele mesmo.
Afinal, session.save() e oos.writeObject() são bem semelhantes não acha (em questão de esforço)?
Claro que se você estivesse usando SQL na mão, você poderia retardar a implementação até quando ela fosse realmente necesária. Mas acho que no caso do hibernate o overhead é pequeno e dificilmente surgirá outra coisa que possa ser usada no lugar dele, e apresentar vantagens, durante o trasncorrer do projeto (calma, veja a explicação abaixo ;)).
Qualquer coisa nova que surja durante o desenvolvimento do projeto provavelmente ainda estará em versão beta, ou o projeto já está tão avançado que não valha mais a pena mudá-lo. E existe ainda o tempo de aprendizagem da nova tecnologia. Você poderia deixar as novas tecnologias para novos projetos.
E, afinal de contas, o cliente não se importa como você implementou a funcionalidade, desde que ele saia satisfeito com o produto.
|
|
|
|
Valeu pela dica. Sem bronca ser em inglês. Essa semana vai ter um workshop na Universidade Federal de Pernambuco sobre Agile Modeling.
Vão vir uns gringos palestrar. Após assistir as palestras, posto o que achei sobre elas aqui.
|
|
|
|
Eheheh
Vou levar um papo com Júlio Lins. Ele já trabalhou na Qualiti. deve saber algo sobre...
Valeu galera
[]s
Recife é arretado de bom ;)
|
|
|
|
Era como eu imaginava...
Caraca esse XP me parece porreta mesmo :D.
Ei e o livro que eu estou lendo fala sim de refactoring o tempo todo.
Teste, Implemente. Tarefa pronta, refatore.
Vai começar nova tarefa, refatore novamente para melhorar o código para a nova funcionalidade.
Teste, implemente. Tarefa pronta, refatore.
Vai começar nova tarefa, refatore novamente para melhorar o código para a nova funcionalidade...
E por ai vai :D.
A bronca é que vc nunca consegue aprender um processo só por livros. Queria ler alguns casos de sucesso, como eles se desenrolaram, antes de começar a usar por aqui na empresa.
|
|
|
|
|
|