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
M6

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.

A minha visão vem precisamente do facto de não ser a de um dev/webdev, como me parece ser o teu caso.

A minha visão vem do facto de me focar no negócio e nas necessidades do cliente.

Nenhum cliente, com dois dedos de testa, quer um sistema em que fica agarrado a ti e que qualquer alteração simples lhe vais custar mais tempo e dinheiro do que o necessário. 

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.

Lá está: estás a pensar puramente em desenvolvimento, enquanto eu estou focado naquilo que interessa, no negócio do cliente.

O que tu indicas como problema do CMS é, na verdade, um problema independente do CMS e transversal à programação.

Esse problema existe também na tua solução de desenvolvimento à medida: mandam umas marteladas para a coisa funcionar.

Fazer como deve ser custa, seja dentro de um CMS seja num sistema à medida.

Quanto à acomodação do cliente, isso acontece quando o cliente já tem um negócio morto e nada tem a ver com a tecnologia de suporte ao seu negócio.

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

Não compreendeste mesmo ou estás a fazer de conta que não compreendeste?

Parece-me bastante simples de perceber que o problema não está na tecnologia. Mais, dentro de um CMS é estupidamente mais fácil de trocar de design, o que duvido que aconteça num sistema desenvolvido à medida.

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.

Como? Não percebeste?

Então vou voltar a repetir. Quando o cliente necessita de uma nova funcionalidade:

1. terá de falar obrigatoriamente contigo, o que oferece zero no que toca a flexibilidade de escolha;

2. terá de esperar tanto ou mais tempo em comparação com um plugin existente, porque terá de esperar pelo o teu desenvolvimento, e um desenvolvimento à medida é sempre mais demorado do que uma solução já existente no mercado;

3. terá de pagar tanto ou mais em comparação com um plugin existente, porque terá de pagar o teu desenvolvimento, e tipicamente um desenvolvimento à medida é sempre mais caro do que uma solução já existente no mercado;

Ou seja, a tua solução à medida é sempre igual ou menos flexivel do que uma já existente.

Isto tem óbvios impactos no que realmente interessa: o negócio do cliente, que sofre e se torna teu prisioneiro precisamente porque a tua solução é a menos flexível das duas...

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.

Ah, espera, no teu sistema?

Estaremos por acaso a falar se um CMS ou similar que foste tu que implementaste e que, como tal, te coloca mais ou menos em pé de igualdade a um CMS? Se sim, então isso não é desenvolvimento à medida...

Além disso referiste aqui um problema que tu tens: não estares familiarizado com outros CMS! Mas isso é um problema de produtividade teu, não é um problema de oferta de funcionalidades do CMS.

Lá por não seres produtivo numa coisa, não te dá o direito de servir pior o cliente empurrando-lhe uma solução tua apenas porque te sentes mais à vontade e, com essa escolha, não servindo o cliente da melhor forma.

De novo confirma-se: escolhes a solução tecnológica a pensar em ti e não no cliente.

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.

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.

Claro. Desde que o cliente pague o facto de continuares a não querer oferecer-lhe a melhor opção, acredito que continues a desenvolver em menos tempo numa coisa que conhececes...

Mas... E quando não necessitas de extender ou modificar um plugin e ele já existe para o CMS?

Ups...

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?

Diz-me tu...

Eu penso no cliente e no negócio do cliente, tu pensas em ti e no teu negócio...

Não conheço negócios que prosperem muito baseado nesse modelo... Mais, costumo apanhar negócios precisamente de clientes descontentes com esse modelo...

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).

É um facto. Mas o plugin já existe, não há 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).

Versus algo que requer zero de esforço...

Seja como for, parece-me claro que no teu CMS o custo é sempre igual ou superior a soluções já existentes...

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.

Essa frase, bonita, sem dúvida, aplica-se a qualquer developer e a qualquer CMS...

Ou seja, de novo, implementar no teu CMS custa tanto ou mais do que uma solução já existente.

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.

E no entanto, acabamos de descobrir neste post que tens um CMS, que, parece-me óbvio, não tem os milhares de utilizadores nem os updates de segurança de um CMS usado à escala mundial...

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.

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?

Estás claramente de má fé ou então és um completo desconhecedor do mundo dos CMS...

É 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, não, não é, não, não está, e não, não implica, pelo contrário.

Estás em fase de negação...

Creio que ficou bastante claro que acabaste por criar um CMS por essa ser a melhor opção - dado que estás em fase de negação podes chamar-lhe outra coisa do tipo framework - mas claramente sofres do facto de ninguém, além de ti - e eventualmente alguns que trabalham contigo - mexer nisso.

Creio que ficou também bastante claro que atribuis as "falhas" do CMS à tua falta de produtividade nestes vs a produtividade que tens no teu CMS.

Por fim, creio que não restam dúvidas que desenvolver para a tua solução tem um custo igual ou superior à de um CMS.

Creio que nada mais há a dizer...


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

M6, continuas errado em mais que um ponto.

Na minha empresa apanhamos clientes de empresas que trabalham com CMS, vê lá tu.

Vêm ter connosco, precisamente porque as nossas soluções são cuidadosamente criadas especificamente para as necessidades daquele cliente, de raiz; porque sabem que podem sempre contar connosco, mediante novo contracto, para alterações e novas funcionalidades - novamente, criadas especificamente para o que o cliente quer. Não são adaptações e costumizações.

E conheces muito mal os clientes: o cliente está-se nas tintas se vai precisar de ti daqui a um ano para implementar uma porcaria qualquer; o cliente não sabe, nem quer saber, se usaste uma CMS, se fizeste tu uma, ou se fizeste magia negra para aquilo funcionar. O cliente quer é ter o site online rapidamente, a fazer o que ele quer.

Também acho piada à forma como continuas a insistir que demora mais tempo, quando não sabes como é que eu trabalho, e não tens, sequer, a experiência necessária para o avaliar.

Como informação adicional, eu não tenho uma CMS - até há pouco tempo tinha uma framework proprietária e uma ferramenta de geração de conjuntos MVC para cada canal necessário; recentemente, implementamos uma versão revista e melhorada dessa ferramenta de geração para trabalhar com uma framework pública, cujo motor foi extendido para algumas situações mais comuns. Cada canal é, como tal, criado de raiz: tabelas SQL, modelos, controladores e vistas. Eu nunca disse que batíamos o código necessário tecla-a-tecla.

Mas mesmo que não tivéssemos essa ferramenta, há certas coisa que não passas a vida a reescrever. Um bom motor ORM dura-te anos, e permite-te criar modelos em menos de 50 linhas, incluindo comentários e espaçamento.

E também estás errado quando dizes que não conheço as CMS. Com um bocadinho de esforço, até poderias verificar que o blog do meu site pessoal é Wordpress. Não usei Wordpress para o resto do site (que é bastante possível), propositadamente, porque ia demorar mais tempo a pô-lo a fazer o que eu queria, como eu queria. E mesmo o blog foi um trinta e um para o afinar como eu queria (tive que o pôr a trabalhar duma forma que não está prevista).

Encaixa isto: eu (e o yoda, e, pelos vistos, também o falco, tendo em atenção o primeiro post dele neste tópico) não demoro mais tempo à minha maneira do que com uma CMS pública, para fazer exactamente o que o cliente quer. Pode custar a aceitar, mas é a verdade.


"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

mjamado, continuas a não querer ver o óbvio.

A tua produtividade advém, como tu mesmo afirmaste, do facto de estares mais à vontade no teu CMS do que nos, usemos o teu termo, públicos. Isto, é óbvio.

Como é óbvio que numa solução out-of-the-box demoras tanto ou menos tempo a desenvolver como numa solução à medida.

A verdade é que a tua solução à medida é, na verdade, algo muito próximo de um CMS público, o que corrobora o facto de ser claro que uma solução CMS é, à partida e para a larga maioria dos casos, a melhor escolha.

E o mais giro é que num CMS público também consegues fazer exactamente o que o cliente quer, haja vontade...

Quanto aos clientes, conheço-os suficientemente bem para saber que eles querem saber se daqui a um ano necessitarem de algo vão ter onde recorrer.

Quando lhes mostro que não lhes faço customer lock-in, é vê-los com um sorriso nos lábios...

E com isto termino a minha discussão sobre este assunto, dado que nada mais há a acrescentar.


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

M6, continuas a não querer ver o óbvio.

A tua produtividade advém, como tu mesmo afirmaste, do facto de estares mais à vontade no teu CMS do que nos, usemos o teu termo, públicos. Isto, é óbvio.

Eu não tenho um Content Managment System. Para cada cliente, eu crio um System para que o cliente possa fazer o Managment da forma que pediu, para o seu próprio Content, modelado de raiz segundo as suas especificações. O nosso sistema não cria meia dúzia de tabelas por defeito, onde o conteúdo das páginas a criar há-de ir parar. Cada tabela, cada modelo, cada controlador, cada vista, é criado especificamente para as necessidades do cliente, para o conteúdo do cliente.

A verdade é que a tua solução à medida é, na verdade, algo muito próximo de um CMS público

Nem a milhas.

Quanto aos clientes, conheço-os suficientemente bem para saber que eles querem saber se daqui a um ano necessitarem de algo vão ter onde recorrer.

Têm sempre. A nós. Ou a outros. O nosso código não vai encriptado para o servidor. O cliente, ou alguém por ele, pode fazer o que lhe aprouver. Obviamente que não nos responsabilizamos assim que alguém lhe mexer.


"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
yoda

Da parte que me toca, dá tanto trabalho montar um sistema de raiz como adaptar um sistema aberto às necessidades dos clientes. O trabalho que desempenho é à volta do conceito DDD (Domain Driven Design), o que implica sempre alterações / customizações em número razoável para me fazer optar por trabalhar de raiz. O tempo que leva é o mesmo também, sensivelmente, com a vantagem de o cliente no fim ter o sistema proprietário e devidamente comentado para facilitar possíveis futuras alterações.

Não sei se dá para chamar às ferramentas que faço de CMS, pois estão sempre a mudar.

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.