Jump to content
RMCosta

Pequena dúvida

Recommended Posts

RMCosta

Se tivesse de implementar um website de venda de produtos para um cliente de modo a permitir que ele mesmo faça depois a actualização do site com novos produtos, alteração de preços, etc, o que sugeririam ? Usar para CMS o Drupal ou o Joomla ?

Share this post


Link to post
Share on other sites
mjamado

Se tivesse de implementar um website de venda de produtos para um cliente de modo a permitir que ele mesmo faça depois a actualização do site com novos produtos, alteração de preços, etc, o que sugeririam ? Usar para CMS o Drupal ou o Joomla ?

Nenhuma CMS está preparada, de raiz, para e-commerce. Pessoalmente, penso que nenhuma CMS deve, sequer, ser usada como base para e-commerce (nem para nada).

Se precisas mesmo de uma CMS, e isso é mau, mais vale começares por ver que sistema de e-commerce cumpre com os requisitos, e depois veres que CMS são suportadas por esse sistema.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
M6

Já fiz essa avaliação e a minha resposta é: Joomla!, sem dúvida.

O Drupal é mais complexo e em muitas situações torna-se demasiado complexo para um utilizador não técnico.

Dentro do Joomla! tens o Virtuemart, que é, para mim, a melhor solução de ecommerce para Joomla!.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
falco

Eu não gosto dos CMS que existem. Eu a ti criava uma interface especifica para esse teu cliente de forma que faça sentido para o negócio dele.

Share this post


Link to post
Share on other sites
RMCosta

Eu já programei sistemas de informação semelhantes apenas com os métodos standart (mysql,php,html,css,javascript,...) e nunca recorri a CSMs. Aconselharam-me a aprender porque supostamente torna as coisas mais fáceis e é uma ferramenta exigida em bastantes empregos, mas depois das vossas opiniões estou a pensar abandonar a ideia  🤔

mjamado: Há algum sistema de e-commerce que aconselhes ou o melhor é mesmo fazer tudo de raiz?

Share this post


Link to post
Share on other sites
yoda

Há situações em que usar um CMS ou E-commerce é benéfico, mas na maior parte das situações, quando o requerido é que o sistema se adapte a situações particulares que ocorrem no modelo de negócio, faz mais sentido dar uma interface e resultados finais o mais amigáveis possível ao cliente, assim como adaptar o sistema consoante o modelo de negócio para que haja mais coerência e flexibilidade de futuro.

Eu faço sempre tudo de raiz, e não me arrependo disso. Para quem gosta de projectos grandes, essa é a "especialização" prioritária :thumbsup:

Share this post


Link to post
Share on other sites
mjamado
mjamado: Há algum sistema de e-commerce que aconselhes ou o melhor é mesmo fazer tudo de raiz?

Nunca experimentei nenhum a fundo para que te possa recomendar.

Mais vale fazer "tudo" de raiz, sendo que esse "tudo" diz respeito apenas à camada aplicacional mais alta. Se já tens alguma experiência com aplicações deste tipo, onde já implementaste mesmo tudo de raiz, talvez esteja na hora de experimentares algumas frameworks e veres com a qual te dás melhor; depois, partires daí.

EDIT:

Eu faço sempre tudo de raiz, e não me arrependo disso. Para quem gosta de projectos grandes, essa é a "especialização" prioritária ;)

Aqui o yoda também não faz mesmo tudo de raiz, que eu sei que ele usa o Kohana... :thumbsup:


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
M6

Estou a ver que devo ser o único que acha que, numa situação normal, fazer de raiz é uma tolice...

A menos que existam requisitos tão especificos que não sejam suportados por componentes existentes para as soluções de ecommerce existentes, ou que não seja possível (em rácio custo vs. benefício) implementar/customizar, não há razão nenhuma para que não se use uma solução de ecommerce existente.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
mjamado
Estou a ver que devo ser o único que acha que, numa situação normal, fazer de raiz é uma tolice...

A menos que existam requisitos tão especificos que não sejam suportados por componentes existentes para as soluções de ecommerce existentes, ou que não seja possível (em rácio custo vs. benefício) implementar/customizar, não há razão nenhuma para que não se use uma solução de ecommerce existente.

O que é que fazes da vida, M6? És webdev ou só dev?

Em primeiro lugar, está a satisfação e costumização do cliente; como exemplo, vê estas três lojas: parece o mesmo site, caramba. É dever de um webdev providenciar ao cliente uma experiência única e diferenciadora da sua (do cliente) concorrência.

Em segundo, está a flexibilidade inerente a código que é nosso. No caso em que escolhias um sistema de e-commerce que se aplicasse aos requisitos do cliente, o que é que fazias se as especificações mudassem ligeiramente? Voltavas a fazer um round-up dos sistemas para ver o que se aplicava de novo? E os clientes mudam de ideias. Isto é um facto. Essa coisa do "as especificações estão assinadas" é o caminho mais rápido para se ficar sem clientes. Com o nosso código, sabemos exactamente o que fizemos, como fizemos e porque fizemos. As alterações são óbvias e claras, sem necessidade de consultar manuais infindáveis.

Em terceiro e último, mas não menos importante, está a segurança. A quantidade e gravidade dos buracos de qualquer CMS pública é assustadora. Não é que qualquer sistema proprietário seja inerentemente mais seguro (que não é), mas a sua disseminação bastante inferior reduz o flanco de ataque de forma brutal. Só o facto do funcionamento interno não estar disponível desvia logo a grande maioria de ataques script kiddie.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
falco
O que é que fazes da vida, M6? És webdev ou só dev?

Acho que fizeste mal a pergunta...

Um programador é algo mais abrangente que um programador web...

Semanticamente a tua frase não faz sentido.

Essa coisa do "as especificações estão assinadas" é o caminho mais rápido para se ficar sem clientes.

Não, não é!

É a única forma de teres engenharia sustentável.

Se o cliente pode alterar sempre as especificações, quando quer e lhe apetece, sem que seja responsabilizado por isso. Então é o caos e facilmente um projecto ultrapassa o orçamento.

As especificações para serem alteradas, têm que ser alteradas em determinadas fazes do projecto. E qualquer alteração implica rever o projecto, desde a viabilidade técnica, passando por prazos a custos.

Isso do cliente ter sempre razão e ter ter que se fazer tudo o que o cliente quer, como ele quer. É um disparate!

Se o cliente sabe tudo o que é melhor para ele, então que o faça. Caso contrário não faz sentido andar a consultar especialistas. Um gajo que vende gelados, não sabe mais de programação que eu. Por isso o cliente sabe as suas necessidades e eu e os outros especialistas é que decidimos como as satisfazer.

Share this post


Link to post
Share on other sites
mjamado
Acho que fizeste mal a pergunta...

Um programador é algo mais abrangente que um programador web...

Oh falco, toda a gente entende, deixa de ser melga, pá.

Se o cliente pode alterar sempre as especificações, quando quer e lhe apetece, sem que seja responsabilizado por isso. Então é o caos e facilmente um projecto ultrapassa o orçamento.

As especificações para serem alteradas, têm que ser alteradas em determinadas fazes do projecto. E qualquer alteração implica rever o projecto, desde a viabilidade técnica, passando por prazos a custos.

Isso do cliente ter sempre razão e ter ter que se fazer tudo o que o cliente quer, como ele quer. É um disparate!

Se o cliente sabe tudo o que é melhor para ele, então que o faça. Caso contrário não faz sentido andar a consultar especialistas. Um gajo que vende gelados, não sabe mais de programação que eu. Por isso o cliente sabe as suas necessidades e eu e os outros especialistas é que decidimos como as satisfazer.

Tive que colocar mais um campo num modelo de produtos agora mesmo. A tua sugestão era que negasse e/ou cobrasse um extra por isso ao cliente?

Toma juízo.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
falco
Oh falco, toda a gente entende, deixa de ser melga, pá.

Espero que programes melhor do que isso...

Tive que colocar mais um campo num modelo de produtos agora mesmo. A tua sugestão era que negasse e/ou cobrasse um extra por isso ao cliente?

Toma juízo.

Não foi isso que eu disse. Tenho pena que estejas de muito má vontade. E que tenhas tão fracos conhecimentos de engenharia de software.

Os requisitos podem mudar. Não podem mudar é em qualquer momento e sem que os seus efeitos sejam considerados. Adicionar um campo até pode não ser muito do ponto de vista visual, mas até pode exigir muita trabalho para passar a utilizar esses dados para alguma coisa. Como tal isso deve ser considerado. Se cobras essa alteração ao cliente, ou não, no fim de conta é uma questão comercial, mas se permitir determinadas alterações e determinadas quantidades de alterações tem custos. E acho que não estás nisto para ter prejuízo.

Eu prefiro ter poucos clientes, mas que me dão lucro, do que ter muitos clientes que me dão prejuízo. Tu trabalhas para aquecer?

Share this post


Link to post
Share on other sites
mjamado
Espero que programes melhor do que isso...

Os computadores não têm discernimento criativo, por isso é que as linguagens de programação têm regras tão estritas. As linguagens humanas, sejam faladas, escritas, gestuais ou comportamentais, permitem-se algumas liberdades porque o ser humano tem capacidades que uma máquina nunca terá. Pelo menos alguns seres humanos.

Os requisitos podem mudar.

Pronto, ainda bem que concordas comigo, porque foi só isso que eu disse. Não disse quando; não disse em que termos; não disse se era à borla ou se tinha que se pagar. Só disse que, com arquitectura feita por nós, era mais fácil. Tu é que falaste nessas coisas todas sem qualquer sentido ou propósito.

Para variar, estás a agarrar-te a um pintelho de nada para virares mais uma discussão para sítio nenhum. Anda, ajuda aí o OP, que é para isso que serve um fórum.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
falco
Os computadores não têm discernimento criativo, por isso é que as linguagens de programação têm regras tão estritas. As linguagens humanas, sejam faladas, escritas, gestuais ou comportamentais, permitem-se algumas liberdades porque o ser humano tem capacidades que uma máquina nunca terá. Pelo menos alguns seres humanos.

E no entanto foste para além das regras e cometeste um erro semântico. E envez de o admitires e agradeceres a chamada de atenção para que para a próxima estejas mais alerta e não cometas o mesmo erro. Escolheste reagir de forma mais "violenta" e atacar-me.

Pronto, ainda bem que concordas comigo, porque foi só isso que eu disse. Não disse quando; não disse em que termos; não disse se era à borla ou se tinha que se pagar. Só disse que, com arquitectura feita por nós, era mais fácil. Tu é que falaste nessas coisas todas sem qualquer sentido ou propósito.

Para variar, estás a agarrar-te a um pintelho de nada para virares mais uma discussão para sítio nenhum. Anda, ajuda aí o OP, que é para isso que serve um fórum.

O que tu disseste não foi nada disso. Tu falaste contra a responsabilização do cliente perante as especificações pré-determinadas e acordadas:

    Essa coisa do "as especificações estão assinadas" é o caminho mais rápido para se ficar sem clientes.

Sem este compromisso do cliente perante algo pré-determinado, nada do que eu disse é possível.

Nada do que eu disse são pintelhos. Falar, escrever e ler bem a nossa língua é essencial para o correcto estruturar do nosso pensamento. E o que tu estás a dizer agora, contraria o que tu disseste, deixa de ter essa atitude. Se achas que foste mal compreendido diz isso. Mas tudo o que eu disse tem sentido e tem propósito e são óbvios. Tu que tanto falas das capacidades dos humanos, pareces estar a falhar quanto tal...

Share this post


Link to post
Share on other sites
M6

O que é que fazes da vida, M6? És webdev ou só dev?

Não compreendo o que isso tenha a ver para o caso...

(Além de que a questão está colocada ao contrário, és dev ou só webdev?...)

Em primeiro lugar, está a satisfação e costumização do cliente; como exemplo, vê estas três lojas: parece o mesmo site, caramba. É dever de um webdev providenciar ao cliente uma experiência única e diferenciadora da sua (do cliente) concorrência.

São as três bem farsolas...

A culpa do design igual, e igualmente mau, das tuas três lojas é por culpa do CMS?

Não me parece.... Ora vê estas três lojas. São todas Joomla! com Virtuemart.

Em segundo, está a flexibilidade inerente a código que é nosso.

Que é, admitamos, muito pouca!

Neste caso há que pensar no cliente e esta tua posição pensa apenas numa coisa: em ti próprio. O foco está totalmente errado, tens de pensar no cliente e não em ti.

E do ponto de vista do cliente, estás a dar-lhe uma solução muito pouco flexivel, e vá vais compreender o porquê à frente.

No caso em que escolhias um sistema de e-commerce que se aplicasse aos requisitos do cliente, o que é que fazias se as especificações mudassem ligeiramente? Voltavas a fazer um round-up dos sistemas para ver o que se aplicava de novo? E os clientes mudam de ideias. Isto é um facto. Essa coisa do "as especificações estão assinadas" é o caminho mais rápido para se ficar sem clientes. Com o nosso código, sabemos exactamente o que fizemos, como fizemos e porque fizemos. As alterações são óbvias e claras, sem necessidade de consultar manuais infindáveis.

Vejamos:

1. O cliente adopta uma solução de ecommerce que se adapta aos seus requisitos.

Depois as coisas mudam ligeiramente ou totalmente. Alguém tem de pagar por essas alterações: ou o teu cliente porque mudou o âmbito do projecto, ou tu que papas essas alterações e as implementas a sairem-te do pelo. Independentemente de quem paga, estás a partir de um pressuposto errado: não é necessário fazer uma nova avaliação de soluções ecommerce (a menos que tenhas escolhido uma totalmente errada). Todas as soluções permitem adjuste, costumizações e expansões.

Ou seja, cada alteração ou evolução num sistema de ecommerce costuma resolver-se em poucas horas de trabalho: encontrar a extensão/plugin correcta, instalar, testar e passar a produção. No caso em que tal não é possível, então é necessário usar os mecanismos de extensão para desenvolver a coisa à medida.

2. Optas por desenvolver um sistema à medida para o cliente.

O cliente está totalmente locked-in, está preso a ti e sempre que o cliente quiser uma alteração ou evolução, vais apresentar uma factura de desenvolvimento muito superior, tanto em preço como em tempo. O time-to-market é muito superior e o cliente vai andar sempre agarrado a ti.

Exemplos práticos:

- o cliente tem pagamentos contra-entrega e passa a querer suportar pagamentos por Visa. Quantas semanas vais demorar a desenvolver e testar estes desenvolvimentos versus usar um plugin que já faça este trabalho?

- o cliente tem a loja em português e agora quer internacionaliza-la para inglês. Qualquer CMS faz isso de graça, mas quantas semanas vais demorar a desenvolver e testar este desenvolvimento?

Em suma: o desenvolvimento à medida implica mais custos financeiros, temporais e estratégicos para o cliente.

Em terceiro e último, mas não menos importante, está a segurança. A quantidade e gravidade dos buracos de qualquer CMS pública é assustadora. Não é que qualquer sistema proprietário seja inerentemente mais seguro (que não é), mas a sua disseminação bastante inferior reduz o flanco de ataque de forma brutal. Só o facto do funcionamento interno não estar disponível desvia logo a grande maioria de ataques script kiddie.

Ah, a segurança... Esse bicho papão... Portanto, tu achas que os teus sistemas são muito mais seguros do que um sistema cuja segurança é testada e cujos buracos vão sendo corrigidos... Diz-me, por acaso usas o teu próprio SO ou usas algum que, por acaso, tem buracos e os mesmos vão sendo corrigidos?

Já agora, sempre que detectas um problema de segurança, vais a todos os teus clientes actualizar-lhes o sistema para resolver esses problemas de segurança, ou simplesmente ignoras o problema e deixas os clientes entregues à sua própria sorte?....

Volto a repetir que, a menos que haja requisitos muito particulares, optar por uma solução existente no mercado é a melhor solução.

No caso de termos de extender a solução com um desenvolvimento próprio, isso estará em pé de igualdade com o desenvolvimento de uma extensão para o teu próprio CMS.

Ou seja, tipicamente o desenvolvimento à medida implica mais custos financeiros, temporais e estratégicos para o cliente.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
M6

[...]

Não, não é!

É a única forma de teres engenharia sustentável.

Se o cliente pode alterar sempre as especificações, quando quer e lhe apetece, sem que seja responsabilizado por isso. Então é o caos e facilmente um projecto ultrapassa o orçamento.

As especificações para serem alteradas, têm que ser alteradas em determinadas fazes do projecto. E qualquer alteração implica rever o projecto, desde a viabilidade técnica, passando por prazos a custos.

Isso do cliente ter sempre razão e ter ter que se fazer tudo o que o cliente quer, como ele quer. É um disparate!

Se o cliente sabe tudo o que é melhor para ele, então que o faça. Caso contrário não faz sentido andar a consultar especialistas. Um gajo que vende gelados, não sabe mais de programação que eu. Por isso o cliente sabe as suas necessidades e eu e os outros especialistas é que decidimos como as satisfazer.

Subscrevo.

O cliente tem sempre razão, desde que esteja disposto a pagar por essa sua razão.

As alterações fora do âmbito têm um custo, e também eu não estou disposto a que seja eu a pagar para o cliente ficar satisfeito.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Share this post


Link to post
Share on other sites
falco
As alterações fora do âmbito têm um custo, e também eu não estou disposto a que seja eu a pagar para o cliente ficar satisfeito.

Claro!

Há pequenas coisas, que podemos oferecer gratuitamente ao cliente, uma vez por outra, para fidelizar o cliente. Mas no "fim do dia", trabalhamos por gosto, mas queremos ser devidamente compensados e isso implica cobrir os custos e ter lucro.

Share this post


Link to post
Share on other sites
mjamado
Não compreendo o que isso tenha a ver para o caso...

(Além de que a questão está colocada ao contrário, és dev ou só webdev?...)

Entendeste-a, ou não?  ;)

A questão só é pertinente para saber se a tua visão (errada, na minha opinião) é fruto de pouca experiência na área, ou se é mesmo assim que trabalhas com os teus clientes.

São as três bem farsolas...

A culpa do design igual, e igualmente mau, das tuas três lojas é por culpa do CMS?

A "culpa" do CMS é apenas a de facilitar em demasia, o que não será propriamente mau; no entanto, induz os devs, especialmente os novatos, a esforçarem-se cada vez menos. Com soluções que just work, os devs, e muitas vezes os próprios clientes, acomodam-se assim que chega a um estado funcional.

E depois acontece aquilo: carradas de sites semelhantes. Acontece exactamente o mesmo com toneladas de blogs dentro do mesmo sistema...

Que é, admitamos, muito pouca!

Como é que a flexibilidade do teu próprio código é "muito pouca"? Estou a partir do princípio que sabes o que é que andas a fazer, e que a arquitectura seja em condições, claro.

Neste caso há que pensar no cliente e esta tua posição pensa apenas numa coisa: em ti próprio. O foco está totalmente errado, tens de pensar no cliente e não em ti.

Eu estou a pensar no cliente. Demora menos tempo implementar três ou quatro modelos à medida no meu sistema, do que costumizar um qualquer plugin num sistema de e-commerce com o qual não estou familiarizado.

1. O cliente adopta uma solução de ecommerce que se adapta aos seus requisitos.

Depois as coisas mudam ligeiramente ou totalmente. Alguém tem de pagar por essas alterações: ou o teu cliente porque mudou o âmbito do projecto, ou tu que papas essas alterações e as implementas a sairem-te do pelo. Independentemente de quem paga, estás a partir de um pressuposto errado: não é necessário fazer uma nova avaliação de soluções ecommerce (a menos que tenhas escolhido uma totalmente errada). Todas as soluções permitem adjuste, costumizações e expansões.

Ou seja, cada alteração ou evolução num sistema de ecommerce costuma resolver-se em poucas horas de trabalho: encontrar a extensão/plugin correcta, instalar, testar e passar a produção. No caso em que tal não é possível, então é necessário usar os mecanismos de extensão para desenvolver a coisa à medida.

Em vez de sequer tentar extender ou modificar um plugin que não conheço, implemento a mesma coisa directamente no meu sistema - em menos tempo.

2. Optas por desenvolver um sistema à medida para o cliente.

O cliente está totalmente locked-in, está preso a ti e sempre que o cliente quiser uma alteração ou evolução, vais apresentar uma factura de desenvolvimento muito superior, tanto em preço como em tempo. O time-to-market é muito superior e o cliente vai andar sempre agarrado a ti.

O tempo de desenvolvimento do meu sistema, em comparação com um sistema com o qual não estou familiarizado, é menor. É melhor para mim, que conheço o que implementei de olhos fechados, e é melhor para o cliente, que tem resultados em menos tempo.

O cliente vai andar sempre agarrado a mim? Duma forma maquiavélica, mas perfeitamente aceitável do ponto de vista do negócio, isso é mau?

- o cliente tem pagamentos contra-entrega e passa a querer suportar pagamentos por Visa. Quantas semanas vais demorar a desenvolver e testar estes desenvolvimentos versus usar um plugin que já faça este trabalho?

Se eu perdesse mais do que um dia a implementar um sistema de pagamentos por Visa, não fazia o que faço (partindo do princípio que não tenho que me haver com o respectivo contracto com a Redunicre, ou outra, mas isso teria sempre de o fazer, mesmo para o plugin).

- o cliente tem a loja em português e agora quer internacionaliza-la para inglês. Qualquer CMS faz isso de graça, mas quantas semanas vais demorar a desenvolver e testar este desenvolvimento?

No sistema que uso actualmente, não demoro mais do que uma hora a converter um site inteiro para multilingue (exceptuando as traduções de textos fixos, que dependem da quantidade e complexidade - mas isso é igual a uma CMS).

Em suma: o desenvolvimento à medida implica mais custos financeiros, temporais e estratégicos para o cliente.

Estás errado. Por isso a minha pergunta inicial fazia sentido: um webdev experiente tem o seu sistema afinado ao longo dos anos para acomodar rapidamente qualquer tipo de alteração mais ou menos comum.

Ah, a segurança... Esse bicho papão... Portanto, tu achas que os teus sistemas são muito mais seguros do que um sistema cuja segurança é testada e cujos buracos vão sendo corrigidos...

Eu disse, bastante claramente, que um sistema proprietário não é inerentemente mais seguro. Por favor, relê o meu post anterior com atenção. O que eu disse foi que, sendo um sistema proprietário, logo, menos disseminado, o flanco de ataque é substancialmente reduzido.

Já que fazes o paralelismo com sistemas operativos, sabes tão bem como eu que o MacOS (e o próprio Linux) não é mais seguro do que o Windows. A elevada penetração de mercado do Windows é que o faz um alvo mais apetecível para ataques.

Já agora, sempre que detectas um problema de segurança, vais a todos os teus clientes actualizar-lhes o sistema para resolver esses problemas de segurança, ou simplesmente ignoras o problema e deixas os clientes entregues à sua própria sorte?....

Porquê, quando saem actualizações de segurança para as CMS também passas em todos os teus clientes passados, a actualizar? E quando essas actualizações têm breaking changes? Quem paga?

É rigorosamente a mesma coisa. Se detectarmos uma falha de segurança grave, passamos pelos clientes mais recentes. Os mais antigos, serão notificados, e o custo da operação, cobrado.

Volto a repetir que, a menos que haja requisitos muito particulares, optar por uma solução existente no mercado é a melhor solução.

No caso de termos de extender a solução com um desenvolvimento próprio, isso estará em pé de igualdade com o desenvolvimento de uma extensão para o teu próprio CMS.

Ou seja, tipicamente o desenvolvimento à medida implica mais custos financeiros, temporais e estratégicos para o cliente.

Volto a repetir que, não, não é, não, não está, e não, não implica, pelo contrário.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
falco
Já que fazes o paralelismo com sistemas operativos, sabes tão bem como eu que o MacOS (e o próprio Linux) não é mais seguro do que o Windows. A elevada penetração de mercado do Windows é que o faz um alvo mais apetecível para ataques.

Isso não é verdade!

A maior penetração no mercado não é a única coisa que torna um alvo mais interessante. Isso é um mito!

A facilidade de exploração de uma falha tem a ver com a qualidade de do design/arquitectura do software, com a forma como foi implementado, com a forma como é mantido e suportado e com a forma como é utilizado.

Assim como há sistemas pouco utilizados mas que têm muito mais impacto se forem explorados do que os mais utilizados.

Por exemplo anos a fio o II$ foi explorado activamente de forma muito superior a qualquer outro servidor HTTP e nunca foi o mais utilizado... Assim que a m$ começou a melhorar a qualidade do servidor, a segurança do mesmo melhorou. Assim como o window$ também melhorou muito a sua segurança nas últimas versões graças a um esforço da m$ nesse sentido.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.