Já ouviu falar de Stanford? é uma faculdadezinha gringa onde surgiu umas empresinhas como Yahoo, Sun, HP, Cisco, Netscape e uma caixinha de busca chamada Google.

Pois bem, eles estão lançando um curso online oficial de Introdução à Inteligência Artificial com ênfase na skynet pelo Professor Sebastian Thrun juntamente com o diretor de Pesquisa e Desenvovilmento do Google. Quer mais? É completamente de grátis.

“Tá, mas e o que eu ganho com isso?” vc pergunta. Bom, além de ter contato direto com alguns dos maiores pesquisadores de vanguarda no assunto (o que já vale muito), vc recebe um certificado de conclusão da disciplina num formato de carta acadêmica dos instrutores do curso, tendo nela uma breve avaliação da sua participação na disciplina. Com essa cartinha, eu agarantcho que sua vida para ingressar na carreira acadêmica (de pós ou mestrado) ficará muito mais fácil do que apresentar somente a cartinha de recomendação do seu professor querido. Tirando isso, somente o privilégio de ter acesso ao conteúdo que é lecionado numa faculdade top de linha, já é vale a participação por si só.

Conforme pode-se consultar no site do projeto, eles pretendem lecionar o maior curso online já feito na história. E pelo gabarito dessa faculdade, eu não duvido.

Apesar de ser à distância e free, não quer dizer q o curso será meia boca. Os trabalhos e cobranças seguirão o mesmo padrão de exigência do ensino tradicional de Standford, sem reposição e com muita pesquisa sobre o assunto estudado.

Todas as aulas e conteúdo serão em inglês, onde serão abordados assuntos de representação do conhecimento, inferência, aprendizagem em máquinas, planejamento e game-playing, recuperação da informação, visão computadorizada e robótica. Ou seja fundamentos de IA conexionista e simbólica.

Tem coragem? Então agora é a hora. Visite o site do projeto e assista o vídeo de introdução do curso, apresentado pelo próprio Professor Thrun.

Anotaí a data de início-fim: 10/out até 16/12.

E não se subestime: não é porque vc está aqui no Brasil, às vezes muito distante da realidade tecnológica dos gringos, que você não vai mandar bem e ter idéias bacanas que podem (inclusive) chamar atenção de algum gringo.

Se você for fazer a inscrição, avise a gente nos comentários! Vamos ter orgulho de saber que tem um xicano tupiniquim presente (virtualmente) numa disciplina no maior berço da tecnologia moderna.

site do curso: http://www.ai-class.com/

fonte: http://meiobit.com/89094

Todo mundo que estuda um pouquinho do funcionamento de um Application Server repara logo que existe a necessidade de pessoas para zelarem pelo seu funcionamento e responderem pela sua administração. O Servidor de Aplicação está para o ASA (App. Server Admin), assim como o Banco de Dados está para o DBA. A diferença é que no modelo de desenvolvimento Cliente-Servidor ainda não existia a necessidade do ASA, já que não havia a existência do Servidor de Aplicação.

Acho um assunto muito interessante, e pesquisando sobre isto, verifiquei que já existiam artigos tão bons e que tratam o tema de maneira tão completa que dispensa a criação de outro artigo sobre o mesmo assunto.

Repasso para que vocês possam ler a matéria completa.

“O ‘Deployer’ ou Administrador é a pessoa (ou empresa) responsável por configurar e realizar o deploy de aplicações Java EE, administrar a infraestrutura de computação e rede onde aplicações Java são executados, e monitora o ambiente de execução. Entre suas atribuições, está o ajuste dos controles transicionais e atributos de segurança, além de especificar conexões de Banco de Dados.“

Esta é a definição oficial da Sun para o perfil “Application Deployer and Administrator“, segundo o Tutorial Java EE.

Desde quando comecei a trabalhar com o Java EE na sua versão 1.3, toda a equipe ganhou “de brinde” uma nova atribuição: Administrar o servidor de aplicações! Claro que no ínicio tudo não passava de alguns deploys e restarts. Com o amadurecimento foi inevitável o crescimento da quantidade de componentes, bibliotecas, datasources, filas JMS e também do “parque” de servidores de aplicação; esta nova atribuição já tomava um tempo considerável da equipe. Foi assim que resolvemos seguir a “sugestão” da Sun e contratar um perfil específico para esta função.

É comum as pessoas que tem seu primeiro contato com o Java EE, enxergarem o Servidor de Aplicações como uma espécie de Web Server estando ele para o Java, como o mod_php/Apache está para o PHP ou como o IIS está para o ASP. Na verdade, como diz Bruno Souza (o Javaman), o Java EE é uma especificação! É um documento que pode ser obtido na página da JSR 244! O Servidor de aplicação nada mais é que a implementação do que foi especificado. Não vou entrar no mérito da compatibilidade do Servidor com sua especificação mas sim deixar claro que o Servidor de Aplicações é muito mais que um Web Container Java e entre os serviços providos pelo Servidor de Aplicação estão: e-Mail (Java Mail), Transação (JTA), Filas (JMS), Conectores (JCA), Segurança (JAAS), Monitoramento (JMX), Pool (Conexão e EJBs),  Registro de nomes (JNDI), além dos conteiners de EJBs (Entity Beans, Session Beans e Message Driven Beans); WEB (JSP, Servlets, JSTL e JSF) entre outros.

Cada um destes serviços possuem suas próprias configurações como números de Threads, número máximo e mínimo dos Pools, sem contar o próprio tunning da JVM (Não deixem de ver a palestra do Cláudio Miranda – Performance em Aplicações Java).  Fora estas atribuições, o ASA (Application Server Admin) também é responsável por: Realizar o deploy da aplicação Java EE, Configurar a aplicação Java (modificando os descritores) para se adequar ao ambiente operacional, Verificar o conteúdo da aplicação e garantir que o arquivo está de acordo com a especificação Java EE e também que as dependências de bibliotecas de terceiros está correta (e não quebra a compatibilidade com a API de outras aplicações no servidor).

Como é possível ver, para praticamente todas as atividades citadas, é necessário um conhecimento específico da plataforma JAVA. Entretanto o que muito se vê nas corporações é a administração do Servidor de Aplicações sendo realizada pela “equipe da rede” onde muitas vezes a instalação do Servidor é feita através do apt-get, descompactação do ZIP ou “Next, Next, Finish”. O resultado é que muitas vezes o servidor é executado com uma configuração padrão para a JVM (o que é insuficiente na maioria dos casos), nível de Logging e segurança: Basta ver a quantidade de servidores JBoss na internet que possuem o JMX console aberto (permitindo total controle da instância).

Não é nenhum exagero dizer que hoje, assim como todos os Bancos de Dados sérios e críticos precisam de um excelente DBA, também todos os Servidores de Aplicações sérios e críticos precisam de um ASA. É perceptível o nível de profissionalismo que uma empresa atinge quando o profissional implanta servidores de aplicações com alta disponibilidade; sistemas de monitoramento que notificam o Administrador quando o Servidor está indisponível ou próximo do limite de Threads e Pools e ainda é capaz de rastrear data, hora e versão da aplicação disponibilizada em produção.

Não deixem de considerar este perfil se quiserem aumentar o profissionalismo das aplicações/ambiente Java EE!

fonte: http://www.jroller.com/rafaelbenevides/entry/a_import%C3%A2ncia_do_asa_app

“Pelos poderes de Grayscow, EU ODEIO JAVASCRIPTT!!!”

Que javascript está se tornando a linguagem de programação de cliente de facto isso ninguém pode negar, mas isso não me faz gostar dessa linguagem tãão mequetrefe. Principalmente pq parece que function é a salvação da lavoura, tem tipagem fraca, e também pela péssima impressão que é passado pelos códigos que vemos nas interwebs afora.

Mas não é por isso que não tem nego que consegue quase fazer chover com essa linguagem. Confira na apresentação abaixo:

Só pra você ter uma idéia de como a coisa está caminhando, parece que a Adobe não está dormindo no ponto e já se prepara para o renascimento (ou pelo menos sobrevivência) de uma das tecnologias mais amadas por Estevão Trabalho (Steve Jobs): o Flash.

Conforme algumas demos que pode ser encontradas no blog da adobe, podemos ver uma galeria de exemplos de animações complexas feitas em flash que são compiladas para o próximo triunvirato da web: javascript + html5 + css3. E são demos bem expressivas. Não pude deixar de fazer uma correlação com o outra tecnologia também compiladora para js, o GWT (mas isso é assunto para outro post).

Só sei que podemos aguardar mais e mais belos exemplos de trabalhos visuais e efeitos em javascript. Infelizmente é uma pena que essa linguagem não sofreu a evolução necessária pra virar a queridinha dos programadores web. :(

http://blogs.adobe.com/conversations/2011/03/flash-to-html5-conversion-tool-on-adobe-labs.html

Quem nunca se sentiu perdido na hora de escolher qual framework para desenvolver? Quem já não escolheu um framework/lib e depois pensou “hum… não estou conseguindo ser produtivo nessa parte” ou “pq diabos eu tenho q preencher esse xml maluco e colocar essas tags sem sentido no código”. Ou pior ainda “MEU DEUS, onde está o maldito erro??!!!”.

Para ajudar vc, caro leitor, embedamos uma pequena palestra comparando os mais famosos frameworks web da atualiadade, tentando abordar seus pontos altos e baixos, fazendo uma análise crítica sobre nossos queridos ajudantes de infraestrutura.

Mas e vc? qual framework vc usa? E pq? E seja sincero, o que vc não gosta nele que poderia ser mudado?

Mais um conjunto de piadinhas que somente quem for nerd vai entender. Vc deu uma risadinha? Vc é nerd! hehehe

1. “Algumas coisas que o homem nunca sabe. Para todo resto, existe o Google.”
2. “Falhar não é uma opção – ele vem com o Windows.”
3. “Jogos de computador não afetam crianças, quero dizer, se o Pac-Man tivesse nos afetado quando crianças, estaríamos todos correndo em salas escuras, mastigando pílulas mágicas e escutando músicas eletrônicas repetitivas.”
4. “Inteligência Artificial geralmente bate estupidez natural.”
5. “Errar é humano … para realmente estragar requer a senha do root.”
6. “Se na primeira você não tiver sucesso, chamem-lhe a versão 1.0″
7. “Se Python é pseudocodigo executável, então o Perl é ruído na linha executável.”
8. “Programadores são ferramentas para a conversão de cafeína em código”.
9. “Porque queremos terminais inteligentes, quando há tantos usuários estúpido?”
10. “Eu não consigo desinstalá-lo, parece haver algum tipo de”
    Uninstall Shield”.”
11. “Ei! Compila! DEMANDA CONCLUÍDA!”
12. “Supercomputador:. Era o que parecia antes que você o compre”
13. “Windows Vista: É como a atualização de Bill Clinton para George W. Bush.”
14. “A vida seria muito mais fácil se tivéssemos o código-fonte”.
15. “Meu software nunca tem bugs. Isso são features aleatórias.”
16. “Relaxe, são apenas e zeros!”
17. “Rm-rf / bin / laden”
18. “A melhor coisa sobre código Object Oriented é que ele pode fazer simples e pequenos problemas parecem grandes, mais complexas.”
19. “Se a força bruta não resolve seus problemas, então você não está usando o suficiente.”
20. “Programação é como sexo, um erro e você tem que conviver com isso para o resto de sua vida.”
21. “Unix é amigável. Ele apenas é muito seletivo sobre quem são seus amigos.”
22. Microsoft: “Você tem perguntas? Nós temos clipes dançando..”
23. “Eu não sou anti-social, eu não sou apenas user friendly”
24. “O mundo está chegando ao fim … SALVEM SEUS BUFFERS!”
25. “É melhor ser um nerd do que um idiota.”
26. “A Internet: onde os homens são homens, as mulheres são os homens, e as crianças são agentes do FBI”.
27. “Existem 10 tipos de pessoas no mundo: aqueles que entendem binário, e aqueles que não.”
28. “A diferença entre um vírus e o Windows? Vírus raramente falham.”
29. “Hacking é como sexo. Você entra, sai, e espera que não deixou algo que pode ser rastreado até você.”
30. “1f u c4n th1s r34d u r34lly n33d t0 G37 l41d”
31. “Helpdesk: Há um ícone no seu computador chamado”
    Meu Computador “Dê um duplo clique sobre ele..
    Usuário: O que o seu computador está fazendo dentro do meu”?”
32. “Se a depuração é o processo de remoção de bugs, então programação deve ser o processo de colocá-los”
33. “Namoro por computador é bom, se você é um computador.”
34. “Qualquer tolo pode usar um computador. Muitos fazem.”
35. “Hardware: as partes de um sistema de computador que pode ser chutada.”
36. “Aqueles que não pode escrever programas, escreva arquivos de ajuda.”
37. “Você sabe que você é um geek quando … Você tenta espantar uma mosca no monitor com o cursor.”
38. “Design de linguagem de computador é como um passeio no parque. Jurassic Park, digo”.

fonte: http://www.junauza.com/2010/02/top-50-funny-computer-quotes.html

Este post é para aqueles que desejam aprender um pouco mais sobre a interação do GlassFish 3 com o JEE6. Recomendo baixar gratuitamente o livro Java EE 6 com GlassFish 3, aonde a maioria das APIs do JEE6 são descritas com detalhes.

Ainda não tive a oportunidade de ler, mas já testei os links e dei uma passada de olho pelos capítulos, e realmente são bem completos e detalhados. Consegui baixar mais facilmente pelo link “Normal”.

O livro conta com 10 capítulos e 448 páginas.

Dentro os capítulos podemos ver os seguintes tópicos:

• Overview do JEE 6 e GlassFish
• Instalando o GlassFish
• Publicando aplicações JEE6
• Desenvolvendo, configurando e empacotando servlets
• Utilizando JSP
• Aprendendo Todas as Tags JSTL
• Introdução em JPA 2
• Rest entre outros vários tópicos.

Fonte:
http://www.wowebook.com/java/java-ee-6-with-glassfish-3-application-server.html

Por muito tempo as stored procedures foram consideradas ótimas soluções para desenvolver as regras de negócio de uma aplicação, porém atualmente com a grande diversidade de tecnologias existe a grande dúvida se as stored procedures continuam sendo a melhor escolha. Recentemente passei por uma situação destas, aonde os sistemas Java precisariam interagir com regras de negócios que estavam dentro de stored procedures, e aí, será que vale a pena reescrever o código para Classes Java (EJB’s)?

Vou compartilhar um pouco da experiência que adquiri tentando compreender um pouco mais as vantagens e desvantagens de cada uma destas opções.

Na maioria das vezes quando uma aplicação está lenta a solução mais “fácil” é o upgrade do servidor. Porém, “não adianta colocar uma ferrari se o motorista é o Rubinho” (Longhi, Fulvio). Algumas vezes a solução pode ser rever as soluções tecnológicas que estamos usando. Até porque Ferrari é um excelente carro, todos sabem, mas será que você conseguiria dirigir uma da mesma forma que dirige seu carro?

Fica mais fácil quando entendemos que não é porque uma tecnologia é mais nova que ela será melhor do que uma tecnologia já existente. Já vi muitos programas utilizando Java 1.3 que eram ótimos, mas quando foram migrados para Java 1.5 tiveram que ser refatorados depois pois não atendiam tanto quanto a versão antiga.

Vantagens em utilizar EJB:

1. Portabilidade: EJB’s são independentes do banco de dados que estiver sendo utilizado. A forma de recuperar o initial context pode ser diferente para cada banco de dados, porém o código SQL no XML é para ser rodado em várias bases de dados;
2. Temos Atomicidade, pela utilização de session beans (ou tudo é executado com sucesso ou seu estado original é retomado – rollback);
3. Temos aplicações mais escaláveis
4. Pode ser tudo desenvolvido na própria IDE em que está sendo desenvolvida a sua aplicação

Vantagens em utilizar Stored Procedures:

1. Melhor performance devido a menor quantidade de transito entre redes (menos camadas até o banco de dados);
2. Podemos alterar tabelas no banco de dados sem necessidade de recompilar as classes Java e restartar o servidor;
3. Pode ser compartilhado entre várias aplicações utilizando a mesma base de dados;
4. Portabilidade parcial (mudar de SO por exemplo, de Windows para Linux);

Assim sendo, a decisão irá depender de algumas questões como:

1. Qual a importância da aplicação?
2. A aplicação será reconstruída, ou sofrerá constantes manutenções?
3. A aplicação terá diversas bases de dados?
4. Existe a possibilidade do banco de dados ser alterado?
5. Qual a expertise da equipe desenvolvedora?

Já ouvi argumentos de pessoas dizendo que Stored Procedures facilitam a duplicação de código, porém não vejo isto como uma exclusividade das Storeds, na minha opinião o mesmo problema pode acontecer com os EJB’s se o desenvolvedor não for cauteloso.

Podemos ver que algumas decisões acabam não sendo técnicas, e sim estratégicas, aonde as vantagens técnicas não são o mais importante.

Não existe também nenhum impedimento em utilizar um repositório misto, tendo regras de negócio em stored procedures e em EJB’s, desde que exista uma organização deste repositório, ou um responsável para prover uma organização.

Referências:
http://www.codinginstinct.com/2009/05/never-ending-store-procedure-debate.html
http://www.theserverside.com/discussions/thread.tss?thread_id=2613
http://extreme-java.blogspot.com/2011/01/debate-over-ejb-and-stored-procedures.html

Me recordo que antes de aprender Java, quando desenvolvia em Visual Basic (Sim, eu já fui do lado negro da força), um dos argumentos de quem desenvolvia em Java era de que Java seria orientado a objetos. Durante anos esse foi o grande diferencial do java até que surgiu o .net com alguns conceitos de OO também.

Como este artigo servirá para municiar muitos desenvolvedores .net a formularem argumentos contra o java, vale a pena fazer vocês refletirem sobre o assunto.

• Tipos Primitivos:

Este primeiro argumento acredito não ser discutível mesmo. Todos sabem que tipos primitivos não são e nem pretendem ser objetos. Alguns acreditam que por razões históricas, desempenho, facilidade de utilização, os desenvolvedores acabavam utilizando tipos primitivos. Com o atualização do Java 5, e a funcionalidade de autoboxing, esta situação acaba sendo contornada, porém por uma perspectiva puramente OO é uma razão válida.

• Construtores

Construtores somente podem retornar uma instância de si mesmos, a classe específica. Por esta razão foram criados padrões de projetos (Factory) e Frameworks de DI (Dependecy Injection). Em linguagens puramente OO como no Ruby, podemos retornar tipos de instâncias diferentes do construtor.

• Objetos de primeira classe

Isso significa que a linguagem suporta a passagem de funções como argumentos para outras funções, devolvendo como valores de outras funções e armazená-los em estruturas de dados.
Java não possui objetos de primeira classe. Normalmente são representados por uma interface com um único método (usualmente Callable), com a implementação através de uma inner class.

• Static

Objetos estáticos são iguais funções, que equivalem a não orientação a objetos. Frameworks DI afirmam que objetos estáticos não são testáveis, porém existem vários frameworks que simulam testes em classes e métodos estáticos, porém, acaba sendo mais um “contorno” para a situação.

• Sem Herança Múltipla

Todo mundo que trabalha com Java já ouviu este argumento no mínimo umas 10x. Apesar de não ser recomendada a herança múltipla, partindo do princípio que quem tem vários pais não tem nenhum! No Java esta situação é simulada utilizando a implementação de várias interfaces.

• Strings

A classe String é imutável por natureza (até estou pensando em fazer um post sobre a imutabilidade das Strings), ou seja, seu estado não pode ser alterado. O principal objetivo de se utilizar a imutabilidade é de melhorar a eficiência em tempo de execução no instanciamento de objetos, economiade espaço físico de memória e velocidade no instanciamento. Para versões mutáveis de String em Java,
utiliza-se o StringBuffer e StringBuilder (recentemente criado no
JavaSE 5.0).

• Sobrecarga de Operador Limitada

Mesmo com a quantidade de vezes que foi utilizada de forma errada no C++, algumas pessoas acham que esta funcionalidade faz falta no Java, já que qualquer funcionalidade pode ser usada de forma correta por bons programadores. Para quem quiser ver os motivos de ainda não ter no Java, acesse o seguinte link.

• JNI

Este existe no Java para tirar vantagens das soluções que já existem, e fornecer algum nível de extensibilidade. Sua utilização é feita de forma procedural, além de ser muito feio também!

• Acesso a nível de Pacote

Este não pode ser considerado Orientado a Objetos pelo fato de quebrar o encapsulamento de nível de classe, permitindo que todas as classes em que estejam neste pacote possam ter acesso.

O grande número de ferramentas existentes permite que o Java seja efetivamente desenvolvido, testado e utilizado de forma segura. Vejo estas situações como forma de tentar minimizar a possibilidade do desenvolvedor ter soluções “desagradáveis”, já que quanto mais coisas que possam dar problemas possam ser feitas, tenha certeza que os problemas ocorrerão.

A única conclusão que chegamos é uma que todos nós já sabíamos: Java não é TOTALMENTE orientado a objetos como outras linguagens.

Referência:
http://www.beilers.com/2011/02/interview-question-name-five-reasons-java-is-not-object-oriented/

C#, Java, Ruby, PHP, Perl, C e C++, entre outras, possuem defensores e detratores e invocam constantes guerras santas em fóruns e listas de e-mail. Antes de entrar nessas discussões, lembre da origem de sua linguagem preferida e perceba que nessa área, “ninguém é santo”.

Java, por exemplo, foi criada para “set-top boxes”, ou seja, caixas que ficam em cima da TV. Agora fazem a web funcionar, talvez de forma escalável e ineficiente.

C# foi criada pela Microsoft apenas para competir com a Sun, copiando tudo de Java e inserindo algumas melhorias.

C foi um hack criado em cima de assembly para permitir implementar o Unix de maneira portável.

C++ e Objective-C eram basicamente hacks para trazer OO para o programador C.

Pascal foi criada para a sala de aula. Basic também.

PHP, Perl e Ruby, bem, eu acho que essas só foram criadas para satisfazer o ego de seus criadores.

Na década de noventa estudei a origem e evolução das linguagens OO. Querem saber a verdade? Ninguém, até hoje, conseguiu fazer algo mais elegante que Smalltalk-80. E Smalltalk-80 era uma mistura de sintaxe inovadora, o ambiente de Lisp que já existia na Xerox e o conceito OO lançado por Simula-67 (outra verdadeira inovação feita como um hack em cima de Algol).

Ruby, uma das mais elegantes das “trending languages” é basicamente um Smalltalk-80 renovado com algumas invenções posteriores e a sintaxe “vencedora” de Pascal/C. Para mim é impossível programar em Smalltalk-80 hoje em dia, mas também é uma lição de como as coisas podem ser boas se não forem mexidas. Smalltalk ainda é puro porque não evoluiu.

Na minha opinião a verdadeira divisão de linguagens está entre as “linguagens de autor” e as “linguagens de comitê”. As primeiras normalmente se iniciam com um objetivo único, alta consistência e pouca funcionalidade extra.

As segundas se iniciam como uma grande massa de funcionalidade e propriedades. O problema é que, a longo prazo, todas as linguagens de sucesso acabam virando “linguagem de comitê”: inchadas, difíceis de aprender e, em um tendência mais atual, cheia de bibliotecas, módulos e arquiteturas associadas. Além disso, dependendo do autor, as linguagens são cheias de idiossincrasias, como Perl e PHP, por exemplo, dependendo do comitê, misturando alhos com bugalhos para atender mercados incompatíveis.

Normalmente, na academia, você encontrará linguagens mais puras, como Smalltalk-80 que introduziu uma sintaxe que mantinha a consistência entre operadores, funções e palavras da linguagem (if, por exemplo). Ou Prolog, onde tudo são regras.

Na academia as linguagens geralmente “dão filhotes”. Nesse raciocínio, Aspect J é um filhote de Java, mas não é mais Java. Normalmente os filhotes não se “somam” e a pureza é mantida.

No mercado, ao contrário, as linguagens tem que atender não só o público em geral, mas também cada nicho específico que acha que precisa de uma funcionalidade. Elas vão evoluindo ou, melhor
analisando, “inchando”.

Qual a chance de um código atualizado em Java compilar em um compilador original? Se você usa as regras certas de programação, zero! Porém o inverso, as chances de um código Java original rodar em uma compilador atual tem que ser muito alta. Para isso, “inchamos” a linguagem, colocando muito e tirando quase nada.

Cômite ou autor? Eu escolho as linguagens pelo que me fornecem e o apoio para desenvolver os projetos que participo. Hoje eu trabalho em um “universo Java”. Em volta de mim, na Universidade e na Engenharia, cresce o “universo Python”. Usar essas linguagens me traz algumas vantagens. Em algum momento da vida eu parei de usar as linguagens da Microsoft e não pretendo voltar. Mas não posso me esquecer de como foi legal programar nos tempos de Turbo Pascal e Delphi. Consistência!

Hoje as demandas são outras. Precisamos de arquiteturas escaláveis. Precisamos de camadas e mais camadas. Temos que nos curvar a necessidade de WebServices ou Beans. Temos uma independência de
linguagem em certos momentos, mas que não se realiza dentro das empresas, que não podem investir em mais de uma ou duas.

Que linguagem escolher não é apenas uma questão de qualidade da linguagem, mas sim de todo ambiente que vem em torno dela.

Quer saber que linguagem usar? Olhe a sua volta. Se você é engenheiro, aprenda Python, Matlab ou Mathematica. Se vai programar para viver, se especialize em Java, C# ou outra linguagem e mantenha o olho nas novatas, como Ruby, fazendo tutoriais e projetos caseiros. Se não vai viver de programação, use uma planilha eletrônica ou software especializado no que você faz.

Meu conselho ágil: procure o caminho mais fácil que funcione.

Quem estiver a fim de aprender um pouco mais sobre Jquery, vale a pena dar uma lida no livro Jquery – Novice to Ninja.

Trata-se de um livro de perguntas e respostas que aborda soluções para vários problemas conhecidos, como também uma compilação das boas práticas de desenvolvimento com Jquery.

Todo o código utilizado no livro também está disponível para download.

O livro aborda dentre alguns assuntos:

• Slideshows;
• Menus, Tabs e Panels;
• Buttons, Fields e Controls;
• Interatividade com Ajax
• Utilizando a interface Themeroller
• Escrevendos seus próprios plugins Jquery;

O livro pode ser baixado neste link.

Fonte:
http://www.wowebook.com/javascript/jquery-novice-to-ninja.html