| Exibir tópico anterior :: Exibir próximo tópico |
| Autor |
Mensagem |
yuri
JS Guru
Registrado: 27/03/07
Mensagens: 793
Localização: Rio do Sul - SC
|
 Enviada: Ter 08/Abr/2008 11:33 Assunto: |
 |
|
Ok, na verdade você foi claro e eu entendi sobre as recomendações.
Mais seguinte, se você for penssar, se um framework tem que ser modular,
e não ter muitas especializacoes para os objetos nativos, você pode fazer essas especializacoes e o desenvolvedor importa apenas se quizer, claro não pode haver dependencias internas no framework
uma coisa importante é a distribuição no estilo mootools, ja que em questoes de performance é recomendado colocar todo codigo javascript em um unico arquivo JS, mas o JBox para ser flexivel e modular foi separado em varios arquivos assim depende da forma de distribuição colocar apenas o nescessario em um unico arquivo js
_________________
The Web Renaissance
# jProton
# Blog Pessoal
# frameBox
# Twitter |
|
| Voltar ao topo |
|
 |
pedrosimonetti
Small Talk
Registrado: 26/03/08
Mensagens: 11
|
| Enviada: Qui 17/Abr/2008 01:16 Assunto: |
|
|
Olá Pessoal,
Desculpem a demora na resposta. Como disse anteriormente, estou com o prazo apertado pra entregar um projeto grande, então estou trabalhando 24 horas por dia.
| Código: |
Mais seguinte, se você for penssar, se um framework tem que ser modular, e não ter muitas especializacoes para os objetos nativos, você pode fazer essas especializacoes e o desenvolvedor importa apenas se quizer, claro não pode haver dependencias internas no framework |
É algo para discutirmos. Eu acho que seria mais produtivo ainda se essas questões mais complexas fossem discutidas via voice chat, ou na pior das hipóteses, em chat/irc/msn.
Mas... aqui vamos nós.
Não é só o Dean Edwards que recomenda isso.
Por exemplo, estou trabalhando agora em um projeto ajax de mapas online. Na versão beta que lançamos há dois anos atrás, estávamos usando o ka-Map, mas estou migrando o projeto agora para o OpenLayers, que além de possuir uma comunidade de desenvolvedores muito maior, possui uma série de funcionalidades a mais que o ka-Map.
Eu estranhei ao ver no código do OpenLayers que eles estavam usando String.prototype. E estranhei mais ainda em ver que esse método não estava funcionando no FF. Após debugar no IE, percebi que um waring estavam sendo gerado, dizendo que o método entrou em desuso, e que ao inves de String.prototype.trim() e outros métodos de strings, devem ser usados através de um novo namespace OpenLayers.String.trim().
Curioso, eu pesquisei mais sobre o assunto, e constatei que o uso do prototype dos objetos nativos estavam gerando incopatibilidade com outros frameworks. Primeiramente, eles fizeram uma gambiarra, que testava se o método já exisita, e só incluia o método se ele não existisse.
Mas logo em seguida, eles tornaram essa prática obsoleta (deprecated), e passaram a usar o OpenLayers.String para isso. Sim, é um pouco maior de se escrever, mas não conflitará com nenhum framework, bilioteca, nem códigos isolados que são copiados e colados em aplicações. O problema do tamanho é resolvido com um bom compressor como o YUI Compressor. Com o uso de algumas técnicas simples, é possível ampliar o fator de compressão dos arquivos, tornando eles praticamente do mesmo tamanho da versão sem OpenLayers.String, quando ambos comprimidos.
Por mais que esse não seja um problema aparente à primeira instância, ele só vai se manifestar a medida que a aplicação toma proporções maiores, e um número maior de usuários passa a usar o código em suas aplicações, e muitas dessas aplicações usarão também outras bilbiotecas/frameworks para completar as funciolidades que não são atendidas pelo primeiro framework.
Mas, como disse, é o caso de debatermos essa questão. Nesse meio tempo, vamos pesquisar pra ver o que os gurus do JavaScript andam falando por aí. Vamos pensar e discutir, juntos, qual de fato é a melhor alternativa para um framework.
| Código: | | uma coisa importante é a distribuição no estilo mootools, ja que em questoes de performance é recomendado colocar todo codigo javascript em um unico arquivo JS, mas o JBox para ser flexivel e modular foi separado em varios arquivos assim depende da forma de distribuição colocar apenas o nescessario em um unico arquivo js |
Concordo plenamente com você. Esse é inclusive, meu próximo passo no framework jProton. Acho que seria um boa hora para começarmos a botar em prática a colaboração entre nós.
Tenho muito o que falar... mas teclar mata o cidadão. Olha a tendinite aê gente!!! 
Brincadeiras à parte, mais do nunca estou convencido de que a parte mais importante de um framework não é suas funcionalidades, nem sua arquitetura, e sim, a quantidade e qualidade dos desenvolvedores que o desenvolvem. Claro que as funcionalidades contam. Mas sem desenvolvedores, elas nunca serão implementadas!
Por esse motivo eu acho tão interessante a possibilidade de juntar os dois projetos, e gostaria de ouvir mais opiniões de vocês envolvidos com o JBox.
abraços,
Pedro Simonetti. |
|
| Voltar ao topo |
|
|
victorino
JS Child
Registrado: 21/05/07
Mensagens: 447
Localização: Curitiba
|
| Enviada: Qui 17/Abr/2008 08:57 Assunto: |
|
|
Bom, pelo que vi você Pedro, gosta muito de se basear em fatos, e isso com certeza faz um projeto ter a razão de existir. Acredito que temos aqui vários perfis de desenvolvedores. Juntos vai ser somado muitas coisas.
Eu concordo que um método não pode subescrever o outro. Ainda mais que alguns frameworks devem usar dentro deles mesmos os métodos próprios, e se isso ocorrer, gera incompatibilidade, como você explanou bem.
Acredito que isso realmente seria um diferencial, até porque ninguém vai deixar um prototype da vida para ficar usando o JProx, ProBox, JBox ou JProton.
Poderia ser para complementar o que já foi desenvolvido.
O que o Yuri falou é extremamente importante, carregar apenas o necessário, a maioria dos aplicativos javascript se tornam 'pesados' por esta razão.
Fiquei empolgado com essa equipe
_________________
Thiago Victorino
Clarity
jProton
 |
|
| Voltar ao topo |
|
|
pedrosimonetti
Small Talk
Registrado: 26/03/08
Mensagens: 11
|
| Enviada: Sex 18/Abr/2008 00:59 Assunto: |
|
|
Victorino,
Bom ler seus comentários aqui.
| Citação: | | Bom, pelo que vi você Pedro, gosta muito de se basear em fatos |
Pois é... eu adoro programar, de verdade. Mas pesquisar... eu gosto mais ainda. Às vezes me arrependo de não ter dado continuidade à carreira acadêmica quando me formei em Ciência da Computação, mas é a aquela velha história, o dinheiro falou mais alto, afinal, precisamos dele pra nos sustentar. Mas espero daqui há uns dois anos voltar aos estudos pra fazer um mestrado. E não é só pela titulação, realmente o conhecimento faz a diferença. Hoje, eu não consigo pensar em codificação sem pensar em engenharia de software, que apesar de estar ligada exclusivamente ao desenvolvimento de software, seus princípios valem também para o desenolvimento web, principalmente nas aplicações ricas, pois elas são, na verdade, "softwares" remotos.
| Citação: | | Acredito que temos aqui vários perfis de desenvolvedores |
E é o que faz a diferença em se ter um time. (N > 1) cabeças pensam melhor que (N = 1).
| Citação: | | Ainda mais que alguns frameworks devem usar dentro deles mesmos os métodos próprios, e se isso ocorrer, gera incompatibilidade |
Ficou um pouco confuso. Você concorda que os tipos nativos devem ser deixados intactos? Ou não? Eu entendi que sim, pra evitar possíveis incompatibilidades. Ou vc se refere apenas a sobrescrever métodos de uma forma geral?
| Citação: | | O que o Yuri falou é extremamente importante, carregar apenas o necessário, a maioria dos aplicativos javascript se tornam 'pesados' por esta razão. |
Esse é o ponto que eu acho mais importante: a eficiência. O jProton surgiu justamente pra suprir uma lacuna existente no desenvolvimento de certas aplicações. Me refiro às aplicações de pequeno e médio porte, em especial os widgets/plugins. Com o surgimento o OpenSocial, cada vez mais sites vão permitir a inclusão de plugins em suas páginas, um exemplo disso é o Orkut, Facebook, e tantos outros. Imagine que você queira criar um plugin pra mostrar os seus amigos que mais fazem contato com você nessas redes sociais? É algo que ocuparia apenas uns 200x200 pixels, e não deveria tornar a página pesada. Mesmo usando a versão compactada desses frameworks, é um disperdício usar os 90kbs do prototype, ou os 30kbs do jQuery pra fazer apenas isso. Pode-se usar gzip e reduzir ainda mais esses números, mas como nem todos servidores suportam ele, estou considerando os valores comprimidos apenas.
No caso de plugins o tamanho ainda é mais crítico, pois pressupõe-se que já existe uma aplicação grande rodando. Além disso, você pode incluir vários plugins em uma página.
Outro ponto na hora de decidir criar o jProton, foi a questão da língua. Acredito que um projeto brasileiro pode trazer benefícios para uma parcela grande da comunidade de usuários e desenvolvedores brasileiros.
Eu falo sobre essas questões no site do jProton. Se ainda não leram, acho que acrescentaria bastante à nossa discussão se vocês dessem uma olhada. Estou terminando de escrever um artigo pra publicar no site também, que fala sobre os desafios de se manter um projeto open source ativo. Aqui vai uma prévia dele. Segundo Andy Singleton, o grande segredo de se construir um time de alta performance é que os membros do time compartilhem um objetivo único em comum:
| Citação: | | The key thing that ties these teams together is that all of the team members share a single goal. It helps if the goal is concrete, and clear to people inside and outside the team - for example, a product release. |
As experiências de Andy mostram que os membros não precisam estar geograficamente próximos, e que nem precisam sequer gostar uns dos outros, nem precisam se conhecer, eles precisam apenas de um objetivo em comum:
| Citação: | | The book's analysis reveals factors that do not seem to influence the formation of a high performance team. Team members don't have to like each other. They just need to share a single goal. In my experience, team members don't even have to know each other. |
Por isso acho importante traçarmos nossos objetivos, pra vermos quais deles nós temos em comum, e definirmos nosso plano de ação.
| Citação: | | Fiquei empolgado com essa equipe |
Eu também. Acho que estamos indo no caminho certo! 
abraços,
Pedro Simonetti. |
|
| Voltar ao topo |
|
|
victorino
JS Child
Registrado: 21/05/07
Mensagens: 447
Localização: Curitiba
|
| Enviada: Sex 18/Abr/2008 10:03 Assunto: |
|
|
| Citação: | | que apesar de estar ligada exclusivamente ao desenvolvimento de software, seus princípios valem também para o desenvolvimento web, principalmente nas aplicações ricas, pois elas são, na verdade, "softwares" remotos. |
Concordo, a ainda mais...acredito que somos nós quem definirá os padrões de desenvolvimento web. A Web está engatinhando e nós um pouco atras, poderemos ser os gurus de amanhã 
| Citação: | | Ficou um pouco confuso. Você concorda que os tipos nativos devem ser deixados intactos? Ou não? Eu entendi que sim, pra evitar possíveis incompatibilidades. Ou vc se refere apenas a sobrescrever métodos de uma forma geral? |
È mais prático modificar, pois aí eu colocaria um object.fazerTalCoisa(). Porém a incompatibilidade pode ser um agravante e atrapalhar a divulgação. Isso se pareceria mais com uma biblioteca do que um framework.
Mas acho que esse é o ponto, carregar X para fazer X, e não XYZASDASDO para fazer X.
_________________
Thiago Victorino
Clarity
jProton
|
|
| Voltar ao topo |
|
|
pedrosimonetti
Small Talk
Registrado: 26/03/08
Mensagens: 11
|
| Enviada: Sáb 19/Abr/2008 10:40 Assunto: |
|
|
Fala Victorino!
Eu e o Yuri tivemos uma longa conversa ontem. Falamos de tudo do mundo da tecnologia, desde jogos de Atari até implantes de chips no cérebro para aumentar a capacidade mental humana. Só não falamos sobre os frameworks!!! ahhahahahahaha... brincadeira. É bom nos conhecermos um pouco antes de entrarmos logo nos assuntos de quebrar o coco.
| Citação: | | Isso se pareceria mais com uma biblioteca do que um framework. |
Cara, não concordo. Pra mim, seria framework do mesmo jeito. Sei que existem várias definições, mas eu penso que, em programação, um framework é uma biblioteca de código projetada para auxiliar no desenvolvimento de aplicações.
A diferença, na minha opinião, está no seu propósito e na extensão do código. As bilbiotecas geralmente têm foco mais restrito, e possuem uma API de "alto nível". Um framework, geralmente possui um foco mais amplo, e é escrito em um "nível mais baixo".
Um código que realiza a impressão de um documento é uma biblioteca; Um código que provê métodos gerais para diversas etapas no desenvolvimento de aplicações é um framework. |
|
| Voltar ao topo |
|
|
pedrosimonetti
Small Talk
Registrado: 26/03/08
Mensagens: 11
|
| Enviada: Sáb 19/Abr/2008 10:40 Assunto: |
|
|
| Ah esqueci de dizer, solicitamos sua presença no próximo encontro. Vamos marcar uma conferência. |
|
| Voltar ao topo |
|
|
victorino
JS Child
Registrado: 21/05/07
Mensagens: 447
Localização: Curitiba
|
| Enviada: Ter 22/Abr/2008 11:47 Assunto: |
|
|
| Citação: | | Cara, não concordo. Pra mim, seria framework do mesmo jeito. |
Questão de definição
| Citação: | | Ah esqueci de dizer, solicitamos sua presença no próximo encontro. Vamos marcar uma conferência. |
Como? Quando? Onde? Por que? Quanto?
_________________
Thiago Victorino
Clarity
jProton
|
|
| Voltar ao topo |
|
|
pedrosimonetti
Small Talk
Registrado: 26/03/08
Mensagens: 11
|
| Enviada: Qua 30/Abr/2008 22:49 Assunto: |
|
|
Fala Victorino,
Foi mal pela demora, estou na maior correria.
| victorino escreveu: | | Citação: | | Cara, não concordo. Pra mim, seria framework do mesmo jeito. |
Questão de definição
|
Na verdade eu acho que fizemos uma pequena confusão. Quando eu disse "daí poderia se usar outro framework pra complementar as funcionalidades" eu me referia aos outros frameworks como prototype, etc.
Eu não penso no jProton como um framework apenas complementar. Penso nele como um framework de propósito múltiplo, completo. Mas mesmo assim, sempre vai ter gente querendo usar funcionalidades de outros frameworks, daí a importância de manter a compatibilidade com bibliotecas externas.
| Citação: |
| Citação: | | Ah esqueci de dizer, solicitamos sua presença no próximo encontro. Vamos marcar uma conferência. |
Como? Quando? Onde? Por que? Quanto? |
Não marcamos nenhuma data, mas pra facilitar nossa comunicação, me passe seu email em uma PM. |
|
| Voltar ao topo |
|
|
|
|
Você não pode enviar mensagens novas neste fórum
Você não pode responder mensagens neste fórum
Você não pode editar suas mensagens neste fórum
Você não pode excluir suas mensagens neste fórum
Você não pode votar em enquetes neste fórum
|
|
|
