| Autor |
Mensagem |
|
|
Com essa iniciativa eu acho que vai aumentar muito o número de apps para o Android, mas vai ter muita app que "não faz nada", que foi criada por alguém que nem é da área de TI em um ou 2 dias.
Essa parte eu acho um pouco negativa se o android market não for evoluido e ter alguns filtros avançados de ordenação das apps...
Mas o lado bom disso é que vai movimentar o Android. Hoje um grande problema no Brasil (somente no Brasil) é que as empresas só falam de IPhone e só tem app para IPhone. Exemplo: checkin da gol, apps para acesso a bancos, veja restaurante, etc... Todas são para o IPhone e não tem uma app correspondente para o Android.
Com essa iniciativa do google acredito que as apps para o Android vão ficar mais populares no Brasil e as empresas vão sofrer mais pressão para olhar também para esse mercado.
Os clientes vão poder falar / pensar: até o jornaleiro da esquina tem uma app para o Android, o meu banco não tem? Só tem para IPhone?
Por mais que as apps do App Invento não sejam boas, essa pressão do mercado vai fazer a diferença.
|
 |
|
|
|
como demorou muito a expectativa é grande pela qualidade
|
|
|
|
comprado
depois tenho até que ver se tem jeito de atualizar a versão do Android do meu HTC Hero unlocked...
|
|
|
|
Falando em Copa:
Concurso Melhor Jogador de Futebol.
O Ronaldinho Gaúcho, Messi e cia ficam empolgados e vão participar....
Quando leem as regras: só pode participar usando elifoot versão DOS!! (http://www.elifoot.net).
kkkkk =)
|
|
|
|
good news!
Ricardo Pelegrini (gerente geral IBM Brasil) e o Governo brasileiro mandaram bem.
|
|
|
|
Polêmicas, polêmicas.
rogelgarcia wrote:Novo framework brasileiro liberado
Acho que toda essa discussão foi motivada por essa frase do Rogel.
Se ele tivesse escrito simplesmente: Framework Neo renomeado para Next, teriam menos criticas a um "novo framework".
As pessoas estão cansadas de novos frameworks web e eu compreendo porque.
Mas no fundo tudo isso foi bom. Foi bom "cutucarem" o Rogel para ele criar um exemplo de app com o Next (o software da padaria), criar o artigo explicando a motivação do framework, etc.
Tenho certeza que agora as coisas estão mais claras para novos usuários ou pessoas que queiram aprender sobre o Next.
Por isso uma pequena polêmica de vez enquando é bom para sair da rotina, chamar atenção para algo, acertar o que estava faltando, etc.
Não sou a favor de criticar sem avaliar o trabalho, mas no fundo quem ganhou com tudo isso foi o Next. Isso que é legal de projetos Open Source - o contato com a comunidade. Até das coisas ruins podemos tirar coisas positivas.
A proposito, já conhecia do Neo (agora Next) a muito tempo e ele realmente é um fw bem antigo.
Todo esse envolvimento com Open Source é bom. Devia fazer mais parte da nossa cultura. Daqui a um tempo o Next pode ser O framework e utilizado por muitos ou o Rogel pode usar toda essa experiência adquirida e contribuir com outros projetos de sucesso, ou mesmo usar no dia a dia.
Sigam em frente.
|
|
|
|
|
bacana =)
|
|
|
|
Tenho um Android também da HTC (HTC Hero) e não tenho nada a reclamar.
O aparelho é excelente.
Sobre instalar programas no cartão SD (que alguem comentou que não é possível), é possível, desde que você tenha acesso root no Android.
Para o HTC Hero eu instalei um ROM customizado pela comunidade para ter acesso root, mas para o Nexus o processo é bem simples.
|
|
|
|
Se o "Meu Projeto" for o projeto do eclipse e "core", "web" e "infra" forem sub-pastas é mto facil gerar nessa estrutura.
Um jeito facil de conseguir isso e mantendo a separação que vc quer é criando o "Meu Projeto" como projeto do eclipse e dentro dele o SPIDER pode gerar o "core", "web" e "infra" como sub-projetos (pastas com o arquivo .project). Depois que a estrutura tiver gerada vc pode dar close no "Meu Projeto" (que é o principal) e import project nos outros 3 pelo eclipse.
Editei para explicar melhor. Estou postando via mobile (android) e antes tinha mais confuso / escrito correndo 
|
|
|
|
Opa,
Então, eu estava dando uma olhada no TextUML e acabei achando o xtext do eclipse antes de ler o forum. O xtext pode ajudar a criar uma DSL para isso. O textUML ja é algo pronto para criar modelos UML. N entendi ainda onde ele pode ajudar, mas depois a gente conversa.
Sobre o exemplo que deu dos artefatos, o que é um projeto no eclipse? "Meu Projeto" ou "core", "web", "infra"?
|
|
|
|
Thiago Senna wrote:então.. eu dei a sugestão da DSL pq eu acho wizards mais complicado. Você poderia manter ambos - os wizards e a DSL. Os wizards por exemplo, poderiam gerar a DSL. Se o desenvolvedor quiser, ele que opte por não usar os wizards e atuar direto na DSL.
Eu sugeri que desse uma olhada no TextUML não é pelo fato de que me interesso por MDD. É que no TextUML já existe uma DSL que representa a UML e talvez valesse a pena reaproveitar ao invés de criar do zero. Valeria muito a pena manter uma DSL onde à partir dela você gera todo o Scaffold da aplicação. Como o seu público alvo são programadores editar as configurações em uma DSL pode ser mais interessante do que editar wizards, é minha sincera opinião 
Ok Thiago. Agora as sugestões / ideias estão começando a tomar forma (não seria MDD, usar o DSL como opção ao wizards, etc), apesar de que eu acho os wizards bem simples e da para clonar as configs de um projeto para o outro.
Vou fazer o seguinte: vou dar uma olha no TextUML e depois a gente conversa para entender melhor o q está sugerindo e ver se é possível de implementar. Se não for atrapalhar nada e só for agregar, tranquilo.
Thiago Senna wrote:
Por exemplo, algo q eu senti falta em alguns projetos por aí é a opção de você gerar código para multi-projetos. Se tenho por exemplo um projeto usando maven com dois subprojetos, como faço pra gerar alguns artefatos no projeto A e outros no projeto B?
A geração do SPIDER e incremental e baseada em assuntos (divididos em abas no wizard).
Vc pode gerar o conteúdo de uma aba em um projeto (ex: layout) e o conteudo de outra em outro projeto (ex: codigo java).
É isso que quer?
|
|
|
|
Alex Basto wrote:Acho que você esta usando um modelo antigo e não entende o que é percebido hoje, algo como Drools usa DSL para implementar regras de negocios.
Não Alex, acho que vc não entendeu. A sugestão era para escrever a DSL em vez de usar os wizards. Não estamos falando de regras de negocio. O assunto regra de negocio está fora do escopo da ferramenta. As regras tem que ser escritas pelos desenvolvedores usando o que eles quiserem - DSL, codigo java puro, patterns, etc...
|
|
|
|
Opa Mauricio,
Usar DSL internamente nos geradores ou ate gerar um projeto que possua DSLs, ok.
O que eu quis dizer é só que eu não sei se o usuário final precisa escrever uma DSL para dizer a ferramenta o que ela deve fazer. A ideia é descomplicar ao máximo a vida do desenvolvedor para que ele se preocupe com o que realmente importa que são as regras de negocio, arquitetura e etc.
Eu tenho muita preocupação em não tirar o foco do que realmente importa em um projeto (regras de negocio e etc). Então eu quero evitar que as pessoas escrevam códigos, comandos ou modelos para gerar algo descartavel (CRUDs). Esse é o objetivo desse projeto. Mas enfim, concordo que podem existir outras soluções 
Vamos ver como as coisas caminham com o tempo. Atualmente a preocupação é essa.
|
|
|
|
Ei Thiago,
Bom, vamos por partes:
Sobre o TextUML eu não conheço. Mas se a sugestão é colocar annotações nas classes para gerar diamagras UML também, isso pode ser feito de forma muito fácil (apesar de que eu não sei qual o valor desses diagramas para CRUDs).
Agora se a sugestão é gerar código a partir de diagramas (ao estilo MDD), isso não está nos planos porque muda totalmente o conceito / foco da ferramenta. Neste caso é melhor utilizar alguma ferramenta MDD que ja tem pronta.
Segue um comparativo entre a geração de código do SPIDER e MDD:
spideronrails.org/cnf/display/docPT/Comparativo
*SPIDER versus MDD*
Algumas ferramentas de geração de código são Model-Driven Development (MDD) e o SPIDER possui outro conceito. Vamos tentar explicar as diferenças:
No SPIDER você não precisa criar diagramas e não tem dependência com a ferramenta se quiser alterar o código. Nós suportamos você a criar o código do seu projeto e após criar os arquivos eles tem como único dono o próprio desenvolvedor. O SPIDER não precisa manter qualquer sincronismo regular com o código. Você pode continuar o seu projeto manualmente, após algumas semanas pode usar o SPIDER novamente, para novos Use Case.
o SPIDER não possui dependência entre o código e a ferramenta, os dois são completamente independentes. Se na metade do projeto você decidir não usar mais o SPIDER, ok. Você pode fazer isso.
Algumas outras ferramentas parecidas tem alguns passos manuais como: muitos "comandos maven", ou entrada de dados usando somente comandos (command line). A abstração do SPIDER é mais elevada e você não precisa "conhecer ou aprender" nada para usar a ferramenta... é muito mais fácil e permite mais features por exemplo: escolher layout (skin) visualmente. Fazer isso em um prompt seria ruim.
As facilidades do SPIDER permitem que você crie projetos muito mais rápido do que com ferramentas MDD ou ferramentas baseadas em comandos.
A qualidade também será boa porque o código gerado é baseado em templates. Você pode usar o seu template com as customizações que quiser.
A documentação e diagrama UML são importantes, mas nós não precisamos delas para configurar o projeto ou criar CRUDs. O SPIDER é mais ágil e consegue criar código (como você quiser) sem usar o conceito de MDD, então você economiza tempo.
Na nossa opinião MDD é importante (por exemplo) para modelar um sistema e criá-lo em várias tecnologias diferentes. Se o seu sistema terá somente uma tecnologia (JEE), MDD não é necessário ou não agrega muitas vantagens. Por isso o SPIDER não é uma ferramenta MDD.
Então o projeto tem um objetivo muito bem definido, e (felizmente ou infelizmente) MDD ou DSL não fazem parte dele. Essas tecnologias são bacanas para alguns casos especificos, mas sinceramente não sei se precisa de tudo isso para configurar um projeto e criar CRUDs. Veja bons exemplos no django e ruby, tudo é feito da maneira mais simples e rápida possível. No SPIDER também sempre foi com esse objetivo, só que tentando ser mais fácil ainda (visualmente), integrado a IDE e sem ter que aprender nenhum comando.
Se está procurando por MDD e DSL, realmente não vai se adaptar (mas não estou dizendo que essas tecnologias são ruins, só que o objetivo é outro).
Abçs,
|
|
|
|
alandasilvaferreira wrote:Em primeiro lugar espero que todos tenham tido um ótimo natal ...
cara achei fantastico o seu artigo citado no link acima realmente muito bom só gostaria de resaltar mais um item, que muitos programadores e arquitetos fazem mal uso dessas ferramentas por falta de experiencia e conseitos mal formados sobre a real utilidade desses softwares, que somente estão ai para dar uma assistencia isso sem contar que em contra partida muitos desses softwares não cumprem nem 30% do que eles vendem ... posso estar me preciptando mas na real, eu acho que a maioria desses caras que produzem esse tipo de software não tem experiencia o suficiente para criar tais tipos de ferramentas ... eu mesmo sou um desses mas pelo menos eu não fico criando porcarias e jogando na internet ...
me desculpem se fui meio grosseiro ou pareci um pouco arrogante mas eu não consigo entender como esses softwares que estão no mercado conseguem ganhar dinheiro com esses produtos ...
Alan, eh o artigo ficou bacana. Sobre as ferramentas tb acho que tem muitas ruins. Por isso criei uma Open Source para que todos possam colaborar e criar algo free melhor do que as pagas.
Na verdade uma vez procurei uma ferramenta nesse estilo e fiquei meio desapontado com a qualidade, nenhuma gerava codigo util, permitia customização ou era facil de usar. Então resolvi começar a fazer uma no tempo livre. No primeiro quartil de 2010 qdo tiver uma release estavel, espero que possa te ajudar com esse problema em comum.
Apesar do parenteses sobre ferramentas, espero ter ajudado a discutir o conceito "geração de código". Ver que se bem entendido o objetivo e bem aplicado pode agregar e não ser um inimigo.
|
|
|
|