| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Primeiro, falta o link. :)
Segundo, percebo a ideia, mas não concordo com ela. Um software deve fazer uma coisa, e bem. Não deve ser bloatware, como o MS Office, StarOffice, Mozilla, etc..
Claro que ter uma "feature list" maior ajuda, quando são engravatados (e não técnicos) a tomar decisões sobre software ("a partir de agora, a nossa empresa vai passar a usar IIS porque o IIS suporta Microsoft Advanced Webhancing Dual-Caching Technology e o Apache não").
Mas será que o objectivo mais importante é a quota de mercado? Quem acha que sim são os mesmos que querem estupidificar (nota - não é o mesmo que "tornar mais user-friendly") o Linux, para competir com o Windows... são os mesmos que QUEREM que os programas de email abram os attachments automaticamente, para "tornar mais fácil o uso".
"Mount up, you dogs! It is time for the hordes of General Fang to strike terror to those who were foolish enough to survive my missile attack!" |
| | | | | | (...)Um software deve fazer uma coisa, e bem.(...)
Do one thing, and do it well!
Aí está a máxima do software. Máxima essa que deve ser cumprida sempre (a MS ainda não a aprendeu). Mas (atenção não li o artigo) tornar o apache em mais do que um webserver parece querer dizer, do all things and do them equally bad. Not a Good Thing(tm).
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | "Primeiro, falta o link. :)"
Tinha escrito a herf= em vez de a href=
Shame on me.
Já está corrigido.
Mário Gamito
educação, ensino |
| | | | | O paradigma utilizado pelo autor no artigo é o Apache que segundo ele está a ser ultrapassado pelo IIS em funcionalidades e que aqui é que está o busílis da questão. E até o Zope na ultima Netcraft sobe 30%, em vez de descer como o Apache... Isto indepedentemente de o Apache per si lhe ser superior e que mesmo a versão 2 vai ser uma melhoria significativa sim, mas vai continuar a ser apenas... um webserver. Exacto. Saca-do-filesystem e-toma-lá-o-HTML-(com algum possivel preprocessamento PHP/Perl/XPTO pelo meio). É superior a fazer isso. Mas é apenas isso: um webserver. "Serves files through the web (ie HTTP)". O movimento no sentido dos "web application servers" já existe há 2 ou 3 anos. Foi quando, depois de analisarmos os varios application servers existentes, escolhemos o Zope . Porquê ? Bem, porque acima de tudo, da experiencia decorrida de outros projectos, nos apercebemos que continuar a desenvolver na base do CGI (mesmo que seja um mod_xpto qualquer) nao funciona. Nao escala. Assim como nao escala o modelo do ficheiro xpto_saca_dados.php3 na directoria /nova_versao3/dev1/xpto em que toda a gente mexe e que contem aspecto (HTML), conteudo (textos e mensagens) e funcionalidade (SQL e codigo). Era preciso algo que permitisse a gestão de versões, a gestão de acessos. E em que o codigo fosse necessariamente (e nao voluntariamente) legivel (vide Choosing the right server-side scripting language). Com suporte para distribuicao de carga e de serviços, acesso tecnologias como o XML, XSL e etcL. Com separacao de conteudo, aspecto e comportamento. E de preferencia Open Source ;-). O melhor candidato era o Zope. Os 5 primeiros artigos desta lista têm mais esclarecimentos e exemplos. Quanto ao artigo: - For example, has Apache even managed to deliver a standard GUI configuration tool in all this time?)
- Zope has it...
- when will PHP grow to become something more than a web scripting language? Where is the PHP enterprise component architecture? What about clustering and failover? Where are the WSDL and UDDI implementations?
- Zope and Python have it...
- another power has been successfully engaging them on the Eastern front. Far from being vapourware, this is a real Enterprise architecture, a set of well-designed interfaces, and plenty of stable implementations to actually provide a viable alternative to .NET. That's the Java 2 Enterprise Edition, or J2EE.
- No it's not...
- Most Open Source enterprise components such as databases, directory services, message queues, mailservers and the like already support J2EE interfaces. What we need to do now is add Open Source implementations of web services standards (WSDL, UDDI, ebXML) and combine them all with a nice user interface (can anyone say "drag and drop"?).
- Can anyone say Zope ? Can you say SOAP, XMLRPC ?
- "Java is not free", the refrain goes. That's right, it isn't.
- Zope is. And its Content Management Framework. And its Zope Enterprise Objects. And its Workflow.
- There is nothing in the Open Source stables to match J2EE (No, CORBA is a poor alternative).
- Yes it is. But XMLRPC/SOAP isnt. And Zope/Python is more than a match to J2EE. It runs on more platforms and faster. And its a lot less lines of code to do a simple task and you can f*cking read it too...
Cumprimentos Mario Valente PS - O autor fala no JBoss, um application server open source em Java. Testamos. It sucks.
|
| | | | | | Bem, mas vamos tornar isto em mais uma holy war ?
Esta história é sempre a mesma coisa, mas já agora, alguém me explica como é que uma solução assente em Mason (por exemplo) para a 'presentation' e módulos/objectos de Perl para a 'business logic' não é escalável e é dificil de compreender ?
E se ainda quisermos ser perfecionistas ao ponto de termos uma solução '3-Tier' ainda lhe adicionamos uns quantos de objectos que representam os nossos dados em BD.
Pensava que esta história de que uma certa linguagem, para programação para a web, é menos 'bloated' do que outra qualquer já tinha acabado...
(Mais curioso ainda, aposto que esta reply vai levar com um offtopic ou flame-bait, mas eu não sou editor aqui do sitio, né ?)
|
| | | | | mas já agora, alguém me explica como é que uma solução assente em Mason (por exemplo) para a 'presentation' e módulos/objectos de Perl para a 'business logic' não é escalável e é dificil de compreender ? Pensava que esta história de que uma certa linguagem, para programação para a web, é menos 'bloated' do que outra qualquer já tinha acabado... Nao é uma questao de linguagem. É uma questao de infraestrutura, de framework, de ambiente de trabalho, de arquitectura. Mas peguemos na qustao da linguagem: qual é que é mais legivel e mais facil de perceber o que faz?: - ($a,$b,$c,$d) = split /,/, $lines[@lines-1];
- a,b,c,d = splitfields(lines[-1], ',')
- list( $a,$b,$c,$d ) = split( ",", $last, 4 );
A primeira é Perl; a segunda é Python; a terceira é PHP. Todas fazem a mesma coisa. Sim, podes dizer que é uma questao de habituacao, uma questao de metodo. Mas o facto é que em equipas grandes (>3 programadores :-) e/ou em que as pessoas que mantêm o codigo mudam a legibilidade é importante. Por isso a escolha da linguagem não é fundamental, mas é importante. Continuemos com questao do Mason (ou podia ser o Midgard ou o Webware para quem usa PHP ou o JBoss ou Websphere para quem usa Java): como é que cada um destes sistemas guarda o codigo ou os varios modulos ? No filesystem (tipicamente). Para alem do problema potencial de seguranca, comecam os problemas de controle de acessos. Mesmo em Unix/Linux a granularidade do sistema de permissoes não é grande espingarda. Tenho um editor que pode adicionar novos artigos/conteudos, mas nao pode alterar/apagar. Como é que resolvo isso com Mason/Midgard/etc ? Depois tenho outros 2 editores que podem editar artigos. Como é que resolvo o problema da concurrencia, ou seja, o que é que acontece quando editam os 2 ao mesmo tempo ? Sinceramente dispenso andar a tratar de filelocks e quejandos. Isso era quando fazia sistemas de email distribuido em C com 50 mil linhas de codigo (deu-me 19 a Complementos de Sistemas e Redes de Computadores com o Prof. Legatheaux Martins). Mas prossigamos... Imagina o seguinte bloco de codigo num file qq (está em PHP): echo "<H5> Procura no nome da categoria </H5>\n";
$aux="select * from CAT where CAT.NOME like '".$palavra."'";
$select = sybase_query($aux);
if (!($row = sybase_num_rows($select))==0)
{
while ($row = sybase_fetch_row($select))
{
echo "<li> $row";
}
}
Como é que agora os teus designers/HTML people mexem no aspecto ? Como mudam de H5 para H3 ou para <FONT a cores e a piscar com vermelho e um fundo em degrade>? Mexem no ficheirinho à unha? É que eles gostam é de DreamWeavers e quejandos. E com o HTML no meio de "echos", népia. E se te lixarem um ponto e virgula qualquer ? E se o designer estiver a mexer e o programador tb precisar de alterar qq coisa ? Vais-me dizer que usas CVS... yeah right. Continuemos... Imagina que até fazes tudo no teu Mason/Midgard/whatever. Está tudo bem até aos 1000 utilizadores ou aos 100.000 hits/dia. Dá para o teu site correr numa unica maquina. Mas imagina que tens um site com 40 mil visitas dia e a servir 2 milhoes de hits ? Um servidor só já não dá (até dava... se fossem paginas estaticas...). Como é que resolves o problema ? Pois claro, metes 2 ou 3 frontends e usas um sistema qq de load balancing (round robin DNS, balance, LVS, Ciscos Directors, Alteons, etc) para distribuir clientes e hits por maquinas diferentes. Mas agora como é que mantens o codigo igual em todas as maquinas/frontends ? E se em vez de 2 ou 3 frontends forem 30 ou 40 ? O Google tem para cima de 1000. Rdist ? I dont think so... E se estiveres a usar um qualquer sistema de sessões/cookies para manter estados (ex: carrinhos de compras) ? Como é que tratas um visitante que começou uma sessão numa maquina e depois foi passado para outra durante o load balancing ? E se for necessario que o teu site aceda a multiplas BDs simultaneamente (Sybase, Oracle, MS SQL e MySql) ? Can you do it ? O Cold Fusion e o Vignette Story Server (web app servers comerciais) por exemplo nao podem. O Zope pode. E se for só um SGBD (p.ex. Sybase) e de repente o teu cliente mudar para Oracle ? Vais mudar os SQL statements todos à unha ? Boa sorte. E imagina que tens redactores e editores, programadores e gestores de projecto. O que os primeiros fazem, tem de depois ser aprovado pelos segundos antes de ser posto online. Chama-se a isto workflow. Fazes com o Mason ? Ah já sei: mandas email... Como podes perceber nao é uma questao de holy war ou de linguagens ou até do que é melhor ou pior. Perl, PHP, Mason, etc são perfeitamente porreiros para determinado tipo de sites, determinado tipo de problemas. Assim como o Frontpage é porreiro para quem quer fazer a pagina do gato. Mas para outro tipo de problemas, para sites de nivel diferente, a evolucao e a passagem a niveis de abstraccao superiores é inevitavel. É essa a Historia e a base da Informatica e o argumento do artigo original. De outra forma, e seguindo o teu raciocinio, porque é não estamos a fazer sites em Assembler ? Ou directo em código maquina... Cumprimentos Mario Valente
|
| | | por Anonimo Cobarde em 14-08-01 14:24 GMT (#7)
|
|
Mas prossigamos... Imagina o seguinte bloco de codigo num file qq (está em PHP): echo "<H5> Procura no nome da categoria </H5>\n";
$aux="select * from CAT where CAT.NOME like '".$palavra."'";
$select = sybase_query($aux);
if (!($row = sybase_num_rows($select))==0)
{
while ($row = sybase_fetch_row($select))
{
echo "<li> $row";
}
} Como é que agora os teus designers/HTML people mexem no aspecto ? Como mudam de H5 para H3 ou para ? Mexem no ficheirinho à unha? É que eles gostam é de DreamWeavers e quejandos. E com o HTML no meio de "echos", népia. E se te lixarem um ponto e virgula qualquer ? E se o designer estiver a mexer e o programador tb precisar de alterar qq coisa ? Vais-me dizer que usas CVS... yeah right. Porque não utilizar uma arquitectura que permita separar a logica do layout/markup ?
Um layer para logica, outro layer para design/layout/markup. Os programadores só tocam no layer de logica/codigo, os designers só tocam no layer de layout/markup/design.
Tenho trabalhado com arquitecturas de 3 layers, sempre com os designers a mecher a top layer, sem problemas. Codigo PHP em layer de design é minimalista, evita-se erros, como tu proprio dizes, nunca se sabe se nao tiram o ;
Outra boa ideia é separar o HTML do PHP mesmo no top layer.
Não fazemos echos de HTML. php ?> <tags html> <? php de novo
Senão tava no CGI a fazer printfs de tags html.
|
| | | | | Porque não utilizar uma arquitectura que permita separar a logica do layout/markup ? Sim, porque nao ? Outra boa ideia é separar o HTML do PHP mesmo no top layer. Não fazemos echos de HTML. Precisamente. A diferenca é que com o Zope (e/ou com outros web app servers) isso é garantido pela arquitectura. Quando dizes "Não fazemos echos de HTML" na realidade estás a dizer "Esperamos que ninguem faça". Boa sorte. Cumprimentos Mario Valente
|
| | | por Anonimo Cobarde em 14-08-01 16:22 GMT (#9)
|
| Precisamente. A diferenca é que com o Zope (e/ou com outros web app servers) isso é garantido pela arquitectura. E com PHP e ASP garantimos isso com a nossa 'arquitectura interna'. Quando dizes "Não fazemos echos de HTML" na realidade estás a dizer "Esperamos que ninguem faça". Boa sorte. Não não.. não tou a espera que ninguem faça. Ninguém faz, porque os programadores da empresa conhecem as normas, e não fazem echo de HTML. Da mesma maneira que com ASP, não fazem response.write de HTML. Nem devia ter falado de ASP para não começar uma thread anti-ms. A questão é que a separação de conteudo não é uma coisa limitada ao Zope, nem a outros sistemas do genero.
Já trabalhei com Zope, não tanto quanto gostaria, e reconheço que é um bom sistema. Quando li o artigoe as falhas que apontava ao Apache/PHP, lembrei-me logo de Zope... Até tive para comentar lá sobre isso.
Nem tou a dizer que o PHP é a solução para todos os problemas que surgem na web. Não é. Da mesma forma que as Active Server Pages não são. Mas para uma grande quantidade de sites e intranets, estas duas ferramentas são mais do que suficientes.
Simplesmente uma boa arquitectura não é propriedade exclusiva do Zope, e é implementavel com PHP, ASP, etc ... E não me digas que os designers não pode usar CVS ...
|
| | | | | Simplesmente uma boa arquitectura não é propriedade exclusiva do Zope, e é implementavel com PHP, ASP, etc ... A arquitectura de um prédio com 50 andares também pode ser boa e implementavel tendo só um baraço para fazer medições, um esquadro de plastico para verificar níveis e peças de Lego como tijolos. Dá é mais trabalho. Mas tens toda a razão. Uma boa arquitectura não é exclusiva do Zope. Até com assembler 6502 é implementavel (a parte mais chata é o processador ter só 3 registos de 8 bits; dificulta as multiplicações pra caraças...). Cumprimentos Mario Valente
|
| | | | Aqui está um bom exemplo de como a moderação por defeito a -1 é idiotice. O Mário Valente parece que está a falar sozinho. Ao menos tenham a decência de dar 1 ou mesmo 0 ao anónimo para se perceber a discussão. (e não me venham com histórias de que os AC são maus porque eu sou leitor da gildot desde a primeira ou segunda semanas de vida e já vi aqui de tudo, bom e mau, com nome ou sem nome) Cumprimentos a todos e um acordem aos editores.
|
| | | | heheheh
cada um come do que gosta.
eu cá prefiro um buraco quente, apertado e molhado a um punho.
:-]
|
| |
|
