| Autor |
Mensagem |
|
|
ViniGodoy wrote:Também sou dessa opinião.
Mas, no caso, o servidor fica em Java puro e matamos mesmo o Applet. 
No máximo, para o cliente, faria como o Java o que a Adobe fez com o flex.
Possibilidade de escrever as UIs na linguagem Java (ou melhor ainda, em JavaFX) e então compilação do resultado em HTML5.
Sabe Vinícius, acho que com a maturidade vêm o desapego. Esse negócio de "ficar com medo porque minha tecnologia favorita vai morrer" é tão tolo depois que algum tempo se passa, porque quando você olha pra trás, percebe que se foram abandonadas, normalmente coisas muito melhores vieram pro lugar.
Ta na hora do plugin do Java morrer. O nicho em que é usado é tão pequeno, e tão sem sentido quando olho pro modo como minha irmã mais nova, por exemplo, usa o celular e o computador.
|
 |
|
|
Oi Viny,
sabe, eu me pergunto se o plugin do Java REALMENTE é disponível e, indo um pouco além, se a vida não seria melhor para nós Javeiros SEM ele. E a razão é muito simples: pra criarmos aplicaçoes ricas, precisamos de basicamente duas coisas:
* Uma área de desenho no formato bitmap ou vetorial
* Audio
E os browsers já nos fornecem isto com o canvas e suporte a audio do HTML 5 (podem incluir video também na lista, os browsers já deveriam dar suporte). Acredito que o futuro do "applet" esteja melhor se o mesmo for executado do lado servidor ao invés do lado cliente.
A idéia não é nova, se não me engano, o Gtk já tem algo similar. A aplicação seria executada do lado servidor, enviando os comandos para renderização que seriam executados no canvas E o audio também pelo browser. Resultado? Renascimento do Applet desta vez com suporte universal SEM plugin. Tudo o que precisaríamos seria uma biblioteca javascript pra fazer esta sincronização.
Fica a idéia!
|
|
|
|
juliocbq wrote:
kicolobo wrote:
juliocbq wrote:
kicolobo wrote:Muito bom. É ótimo ver como o Java FX, visto por todo mundo como natimorto de repente tá começando a se mostrar mais interessante.
Cara, esse glass é muito bom. Roda liso. É uma evolução pelo menos pra desktop. Também traz muitos recursos pra web.
Oi Julio, interessante isto. Não sabia que o glass também trazia recursos para a web. Tipo o que hein?
Além de todos os recursos multimídias, o plugin jfx que são embarcados nas páginas funcionam como desktop e vice versa. Você pode muito bem destacar a aplicação da página web e levá-la para o desktop.
Imagina um video player que é carregado via uma página e pode ser trazido para o desktop. É como se as duas plataformas interagissem e você não percebe que a aplicação executa no browser ou desktop. Acaba ficando indiferente.
Julio, é tipo um applet turbinado?
O plugin é similar aquele que usavamos com os applets?
Desculpa a ignorância, mas faz alguns anos que não trabalho com applets e acabei ficando muito por fora.
|
|
|
|
juliocbq wrote:
kicolobo wrote:Muito bom. É ótimo ver como o Java FX, visto por todo mundo como natimorto de repente tá começando a se mostrar mais interessante.
Cara, esse glass é muito bom. Roda liso. É uma evolução pelo menos pra desktop. Também traz muitos recursos pra web.
Oi Julio, interessante isto. Não sabia que o glass também trazia recursos para a web. Tipo o que hein?
|
|
|
|
Muito bom. É ótimo ver como o Java FX, visto por todo mundo como natimorto de repente tá começando a se mostrar mais interessante.
|
|
|
|
Eu aplicava uma prova de seleção na qual criei um exercício que era basicamente o seguinte: "De 1 a 100: se o número for divisível por 3, imprima zag, se for por 5, imprima zug, se for por 3 e 5, imprima zagzug"
Um teste simples, idiota, no qual nada poderia dar errado. Eis que apliquei a um caboclo e DUAS horas depois recebo a seguinte resposta
Detalhe: este foi um dos poucos caras que CONSEGUIU fazer o teste.
|
|
|
|
diegosammet wrote:
Cara, eram extremos. No caso, precisavamos reaproveitar a nossa lógica de negócio não só entre servidores de aplicação diferentes, mas em versões do sistema que eram desktop. (yeap, estas coisas acontecem)
Cara, mas é só anotar suas classes com @Alternative, implementar a mesma interface e voila.. Depois é só mudar no beans.xml e mudar a regra de negocio em tempo de execução..
Yeap, hoje. Mas naquela época não tinhamos isto.
Além do que, eram ambientes muito variados, por exemplo: tinham implantações que só podiam executar no notebook de um sujeito sem conexão a rede (monstruosidades deste tipo).
No caso do CDI, temos esta possibilidade hoje, mas mesmo assim, quando você vai ler a especificação, percebe que é um negócio muito preso ao servidor de aplicações ainda (eu sei que você pode usar o Weld fora de um servidor).
|
|
|
|
benflodin wrote:
kicolobo wrote: No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA.
Quanto diferente eram esses ambientes ? se eram apenas application servers tem algo errado não ?
Cara, eram extremos. No caso, precisavamos reaproveitar a nossa lógica de negócio não só entre servidores de aplicação diferentes, mas em versões do sistema que eram desktop. (yeap, estas coisas acontecem)
|
|
|
|
Existe um outro ponto que ainda justifica o Spring como solução "light weight". As pessoas costumam achar que "light weight" é igual a "consumir menos recursos computacionais".
Não é nada disto. Um framework "light weight" é aquele que é mínimamente intrusivo, ou seja, que não requer que você altere o código fonte de suas classes para que funcionem com ele.
No caso do Java EE, não temos um framework tão "leve" assim, porque o simples fato de você incluir uma anotação em uma classe já adiciona acoplamento (mesmo que apenas estático) entre esta e o framework em questão. No caso do Spring, usando XML você pode reaproveitar o seu código legado sem precisar "tocar" no mesmo. Sendo assim, pra manter código legado (e código legado não quer dizer código ruim, mas aquele que simplesmente FUNCIONA), Spring ainda é uma das soluções mais "leves" que existem hoje.
|
|
|
|
Bom, li o artigo e discordo de alguns pontos.
"Spring Always Depended on Java EE" - discordo devido a minha própria experiência profissional com Spring. Sim, há vários wrappers no Spring que envolvem componentes do Java EE como JMS, JPA, Transações, etc, mas é importante lembrar um ponto aqui: estes wrappers nunca foram o core do Spring ou a razão de adoção principal do framework, mas sim o seu excelente container de injeção de dependências E o fato de podermos usar AOP sem muita dificuldade (AOP ainda não está no Java EE até aonde pude observar com tamanha facilidade quanto a que encontramos no Spring).
Na realidade, eu usava o Spring sem Java EE desenvolvendo aplicações desktop. Como meu cliente possuia inúmeros ambientes de deploy, o Spring caia como uma luva, porque bastava eu alterar o xml de configuração de beans, sem a necessidade de recompilação e voilá, configuração nova prontinha para o "ambiente hostil". Até tentei simplificar o Spring em um experimento chamado miocc (http://miocc.itexto.com.br), mas no final das contas, me rendi ao container do Spring que era anos luz superior e sempre muito, MUITO leve. Sendo assim, discordo: o foco do Spring é o seu container DI E AOP, que ainda são excelentes E, mais interessante, oferecem uma flexibilidade de opções de configuração (XML, Anotações ou Java) que o Java EE ainda não oferece.
"Annotations were a game changer" - Se for pra pensar numa evolução do Java que mudou tudo, sem dúvida foi a introdução das anotações. Com elas se tornou possível incluir metadados nas nossas classes Java e uma gama monstro de soluções surgiu via reflexão. Infelizmente, dentre as novidades que vieram com as anotações foram os "xiitas anti-XML". Enquanto há documentos XML monstruosos cuja manutenção é um inferno, muitos vendam os olhos para o fato de que também há monstruosidades usando anotações e com um "probleminha" a mais: ao contrário do XML, você não consegue externalizar anotações sem a necessidade de recompilação. No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA.
(Outro ponto importante em prol do XML. No ambiente de produção, o analista de sistemas não pode contar com a recompilação do sistema, mas sim com alteração de configurações externalizáveis. Imaginem como seria um ambiente sem estes arquivos.)
"CDI closed API hole" - De novo discordo porque no caso do CDI, este está muito mais focado em aplicações Java EE do que "não EE". Além disto, é interessante observar alguns fatos: o primeiro deles é que CDI é uma abstração em cima do conceito de injeção de dependências, assim como o JPA para ORM. Consequentemente, temos aqui o menor denominador comum. Sim, o Weld é lindo e tal, mas baseia-se em dois pontos que não são a última bolacha do pacote: auto wiring e anotações apenas. Quem já trabalhou com auto wiring sabe dos problemas que costumam acontecer quando o sistema cresce, e com relação ao uso exclusivo de anotações, como mencionei acima, há o problema de não serem fácilmente externalizáveis. (tenho 25 páginas de argumentação a este respeito http://www.itexto.net/devkico/?p=859  )
"App Servers got their act together" - as pessoas não usavam Spring por causa do tempo de boot dos servidores, mas porque o modelo de desenvolvimento era superior por ser baseado em POJOs ao invés da implementação daquelas interfaces melequentas. Sim, havia o ganho do tempo de boot, é claro, mas convém lembrar que mesmo hoje, com servidores que startam em segundos, desenvolver e testar contra estes servidores, versus desenvolver e testar versus POJOs não é só mais eficiente na questão tempo, mas performance também.
"Arquillian made a mock of mocks" - ai há um problema na argumentação sério também. Bill Burke diz que um dos fatores da "derrota" do Spring é que um outro projeto, fora da especificação Java EE surgiu??? E outra: quem aqui adotou o Spring ao invés da especificação padrão Java EE por causa das suas funcionalidades de teste que atire a primeira pedra. Nunca encontrei ninguém.
|
|
|
|
Mais um post sobre o Maker criado por uma pessoa que possui menos de 10 posts no GUJ.
Coincidência ou mais uma tentativa fajuta de propaganda. Bom, desde 1986 o Fred Brooks prova que o Maker não funciona (e ele nem existia!).
Leia este texto (No Silver Bullet): http://people.eecs.ku.edu/~saiedian/Teaching/Sp08/816/Papers/Background-Papers/no-silver-bullet.pdf
Responde a todas estas dúvidas sobre o Maker e ACABAM com este papo furado de uma vez por todas pra quem lê.
|
|
|
|
O Jonathan Schwartz, antes de sair da Sun tinha planos de criar uma App store http://www.infoworld.com/d/applications/jonathan-schwartzs-app-store-dream-274
Como podem ver, não deu certo 
|
|
|
|
perdeu wrote:
Programador Baixa Plataforma (1 vaga)
Cargo:
Descrição:
Programador VBA Excel
Elaboração de documentação de Design (simplificada);
Desenvolvimento de macros para Excel, VBA;
Elaboração de plano de testes (simplificado);
Superior completo ou cursando;
Inicio imediato.
Salário: A combinar
Empresa: DTS LATIN AMÉRICA vagas
Cidade:
CURITIBA/PR
QUE LEGAL!
|
|
|
|
drsmachado wrote:Eu me sinto completa e terrívelmente amedrontado sempre que falam em macros.
Uma coisa que não sai da minha cabeça é que, se a MS desenvolveu um sistema que precisa de gambiarras para aumentar a própria produtividade, este jambre não pode ser coisa boa.
É a minha opinião, simples.
Mas detestaria ter que abdicar de programas de verdade, em java, PHP ou o que for, em prol de vba...
É uma opinião bem furada.
Não chamaria de "gambiarra" uma DSL, muito pelo contrário. Se a empresa desenvolveu uma linguagem para que você, usuário, possa ampliar a sua funcionalidade, não é negativo, mas positivíssimo!
O mesmo argumento se aplicaria portanto ao Auto CAD, no qual você tem o Lisp pro mesmo objetivo? Aliás, AutoCAD tem suporte a VBA também. Isto faz dele uma ferramenta ruim? Pelo contrário, mostra versatilidade.
Aliás, o mesmo argumento se aplica a qualquer sistema que possua uma DSL.
E o papinho de "programas de verdade são feitos em linguagem X...". Bom: isto o tempo cura com a maturidade (se esta aparecer).
|
|
|
|
Vale mais à pena do que você imagina.
Vou te contar minha experiência pessoal: trabalhava em uma empresa de engenharia desenvolvendo em Java/VB/C/O que você imaginar, mas em diversos momentos, em que estava frente à frente com a diretoria, o que REALMENTE resolvia o problema na hora era uma combinação de teclas muito fácil de aprender no Office: ALT + F11. Abria a IDE do VBA e conseguíamos soluções rápidas para problemas imediatos em tempo recorde. É impressionante: você pode fazer práticamente QUALQUER COISA com VBA.
(profissionalmente, devo muito ao VBA )
Claro: você não vai desenvolver sistemas com isto (apesar de conhecer alguns surpreendentemente bons), mas é uma ferramenta fantástica para o seu dia a dia e, em situações limítrofes como esta que contei, são o que decidem se você vai crescer profissionalmente ou não.
É algo que há demanda no mercado? Não: nunca vi uma vaga para "programadores VBA", mas é uma ferramenta poderósíssima. Infelizmente, alguns anos atrás escutei alguns rumores de que a Microsoft estaria pensando em abandonar o recurso (no Office pra Mac, por exemplo, já não vem mais), mas mesmo assim é uma ferramenta pro seu cinto de utilidades que convém DEMAIS ter.
|
|
|
|
|
|