Re: [Ovillo] [OT] Re: CMS para desarrollo de portal
> > Con estas premisas, y estoy hablando de proyectos para clientes, evalúo > muy cuidadosamente todos y cada uno de los elementos que voy a utilizar > en un proyecto. El caso de Drupal no me ha convencido hasta ahora porque > según mi cálculo de riesgos la cantidad de módulos externos que necesito > es muy grande *en comparación* al beneficio que obtengo en lugar de > programar yo misma el gestor de contenidos (obsérvese que se ha > resaltado "en comparación"). Mmmm, yo aquí no estoy tan de acuerdo... por externos entiendes ajenos al core y no desarrollados por ti o simplemente los ajenos al core?. si es así a mi me parece que con drupal puedes hacer lo qeu quieras con el simple uso de su core y con todo lo que quieras añadir de tu cosecha, con el añadido de que podrás reutilizar esos desarrollos en otros proyectos tuyos... yo ahí sí que le veo ganancia (al menos a nosotros nos ha acortado tiempos) con respecto a intentar programar un cms propio... ya hay casos de gente que se ha construido cms propios basándose en drupal, no? hace bien poco hablábamos de lo qeu usa publico.es por ejemplo. el problema que yo veo es que pasaría si la gente de publico.es le pregunta a los desarrolladores "oye, hemos visto que ya ha salido la versión 6 de drupal, todo el mundo dice que es muy buena!. a qué esperáis para actualizarla" y el desarrollador tenga q decir "es que poco de lo que hicimos servirá... casi vale más que os hagamos uno nuevo..." ___ Lista de distribución Ovillo Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
Re: [Ovillo] [OT] Re: CMS para desarrollo de portal
No me lo tomo a mal Martín, sólo faltaba!! Pero intenté resumir algo que para mi es largo de exponer si antes no lo trabajo un poco... te expondré los puntos clave y no insistiré en el tema en la lista, ya que yo misma lo etiqueté OT, a menos que realmente haya interés por parte del resto de co-listeros (siempre dispuesta a debatirlo en privado o en lista de interesados, por supuesto) * Al afrontar un proyecto para un cliente tengo que estar segura de que todo elemento involucrado cumple con unos mínimos en mi "análisis de riesgos" del proyecto * Un software que, aunque maduro, dependa en gran parte de módulos externos, me añade mucho riesgo precisamente por ¿qué ocurrirá en la actualización? Yo no puedo garantizar que en pocos meses mi cliente no quiera un cambio y que ese cambio no afecte precisamente al proyecto de tal modo que precise la nueva versión y revisar uno a uno esos módulos que parecían inofensivos. * Cuando mi credibilidad ante el cliente está en juego, procuro que los riesgos sean mínimos. Con estas premisas, y estoy hablando de proyectos para clientes, evalúo muy cuidadosamente todos y cada uno de los elementos que voy a utilizar en un proyecto. El caso de Drupal no me ha convencido hasta ahora porque según mi cálculo de riesgos la cantidad de módulos externos que necesito es muy grande *en comparación* al beneficio que obtengo en lugar de programar yo misma el gestor de contenidos (obsérvese que se ha resaltado "en comparación"). Pero eso no quiere decir que no valore el trabajo que se realiza en proyectos de software libre. Lo valoro, lo aprecio, me sirve para aprender y para pequeños proyectos personales, y para evolucionar, y para tener nuevas ideas, y ... Yo estoy dentro de las locas que ya hicieron sus pruebas reinventando la rueda e innovando (construir un CMS que sólo utilizaba XML, XPath, XForms cuando algunas de estas especificaciones eran sólo un draft fue todo un desafío). Pero precisamente por la experiencia ahora a un cliente lo atiendo con criterios de "curarme en salud" (una frase muy de uso aquí en Cataluña) y ser yo la responsable última de lo que se instala y/o se desarrolla. ¿Eso quiere decir que no esté a favor de que Drupal evolucione? NO, al contrario. Estoy a favor y espero en ascuas el día que la funcionalidad BÁSICA (o core) de ese CMS me ofrezca unos mínimos que hasta ahora no cumple. Sí lo hace con ayuda de módulos, y he visto que algunos se han incorporado en el core de la versión 6, así que le daré una oportunidad a la versión 6, pero no en una instalación a cliente hasta que no lo haya probado yo primero ;) Y creo firmemente que si se detecta un error en el diseño de las estructuras de datos y/o procesos, debe solventarse cuanto antes mejor, aunque la nueva versión requiera cambios algo difíciles en las migraciones desde versiones anteriores. Al menos si están bien analizados en esta fase es posible que se ahorren en el futuro (yo misma he sido "culpable" de algunos cambios drásticos de ese tipo en algunos programas). El punto que quería levantar (y creo que no conseguí resaltar suficientemente), es que la mayoría de los proyectos de Software libre (algunos de software comercial también, pero eso es otra historia que no creo venga al caso), se inician sin un análisis concienzudo, sólo en base a una idea general y sin una noción de quienes son los usuarios potenciales y/o las características a largo plazo que quieren desarrollarse (que no hay que implementar necesariamente desde la versión 1, pero sí preveer). Eso es lo que generalmente repercute en malos diseños de estructuras de datos y procesos, lo que hace que al atacar un nuevo desafío haya que "romper" la compatibilidad. Y puestos a generar polémica y discusión (en el buen sentido), yo a eso no lo llamaría "maduro" sino "relativamente estable". En mi escala sería un 5 sobre 10, pero no me arriesgo a utilizarlo en casa de cliente hasta que alcanza un 8 sobre 10 a menos que el cliente haya comprendido muy bien los riesgos y/o costes que puede requerir un cambio tras la primera versión de nuestro proyecto. Espero haber arrojado algo de luz desde mi humilde experiencia en hacer el cabra loca por los mundos del software de innovación durante un par de décadas ;) Saludos Victoria El sáb, 16-02-2008 a las 13:00 -0200, Martin Szyszlican escribió: > El día 16/02/08, Victoria Gracia <[EMAIL PROTECTED]> escribió: > > > > Yo, por ese motivo, no soy muy partidaria de los productos que dependen > > en gran medida de los módulos o añadidos, no me gusta Drupal por eso. > > Quizás cuando esta versión 6 llegue a una versión más estable lo pruebe. > > Mi principal criterio para la selección de programa de código libre > > (cuando es para clientes) se base en el tiempo que lleva en el mercado, > > la fiabilidad y las funciones que tiene (a lo mejor no necesito muchas, > > pero las que necesita el proyecto deben estar inc
Re: [Ovillo] [OT] Re: CMS para desarrollo de portal
El día 16/02/08, Victoria Gracia <[EMAIL PROTECTED]> escribió: > > Yo, por ese motivo, no soy muy partidaria de los productos que dependen > en gran medida de los módulos o añadidos, no me gusta Drupal por eso. > Quizás cuando esta versión 6 llegue a una versión más estable lo pruebe. > Mi principal criterio para la selección de programa de código libre > (cuando es para clientes) se base en el tiempo que lleva en el mercado, > la fiabilidad y las funciones que tiene (a lo mejor no necesito muchas, > pero las que necesita el proyecto deben estar incorporadas). Si es > necesario yo misma desarrollo a partir de mis propios módulos (que esos > sí los conozco bien). Victoria: Lamento disentir con tigo, pero no lo tomes a mal... Creo que Drupal es un proyecto muy maduro en ese sentido y no me parece que hagan mal en romper la compatibilidad hacia atrás de las extensiones en un cambio de versión. ¿Te parece que hay hoy un proyecto tan maduro que, después de 2 años de mantener una versión y con la promesa de seguir manteniéndola por un tiempo más, no rompa la compatibilidad hacia atrás de las extensiones con el objetivo de mejorar? Creo que no hacerlo sería no innovar por mantener sólo por mantener la compatibilidad, o de lo contrario mantener la compatiblidad mediante unas "traducciones" de los métodos antiguos que lo único que harán será hacer más lento y pesado todo el programa. Personalmente no le veo nada de malo, creo que, como vos decís, la idea que un proyecto tiene de sus usuarios va cambiando, en el caso de drupal sus usuarios son tan diversos que no pueden hacerle la vida fácil a todos. Martín. ___ Lista de distribución Ovillo Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
Re: [Ovillo] [OT] Re: CMS para desarrollo de portal
> Hola co-listeros, > > encabezo este mensaje OT porque si bien tiene relación con la elección > de CMS, el comentario que inicio tiene relación a la "compatibilidad > hacia atrás" a que aludía Carlos en su mensaje. > > El problema general del software libre (del cual por otro lado soy > partidaria) es que suele iniciarse como un proyecto de un colectivo con > experiencia en programación pero no en la realización de proyectos (ojo, > estoy generalizando y sabemos que eso quiere decir que no siempre es > así!). > Coincido. Aunque la ventaja sobre el software "no libre" o "de pago", es que en muchos casos los de pago tienen los mismos problemas (cuando no más) que el software libre ;). ___ Lista de distribución Ovillo Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
[Ovillo] [OT] Re: CMS para desarrollo de portal
Hola co-listeros, encabezo este mensaje OT porque si bien tiene relación con la elección de CMS, el comentario que inicio tiene relación a la "compatibilidad hacia atrás" a que aludía Carlos en su mensaje. El problema general del software libre (del cual por otro lado soy partidaria) es que suele iniciarse como un proyecto de un colectivo con experiencia en programación pero no en la realización de proyectos (ojo, estoy generalizando y sabemos que eso quiere decir que no siempre es así!). Abordar un proyecto desde la perspectiva de un grupo de gente, con buenas intenciones pero sin análisis concienzudo de las necesidades reales de los potenciales "clientes" (entiéndase aquí por cliente tanto el desarrollador que va a utilizar ese desarrollo como el usuario final del producto), es que cuando estas se hacen patentes y manifiestas algunas decisiones tomadas en la fase de diseño se muestran ineficientes, deficientes o contraproducentes. Eso lleva a rediseños complejos de todo el software (en el mejor de los casos) que no hacen fácil una "migración hacia atrás" o bien a intentar mantener esa "compatibilidad hacia atrás" a base de parches que ralentizan la eficiencia o requieren trucos que complican el código. Si además el software se ha utilizado con otros añadidos (plug-ins o módulos o como se llamen en cada caso) desarrollados por gentes con igual de buena voluntad y para satisfacer un caso concreto pero que no son el equipo original, es muy probable que nos encontremos en esa situación. Yo, por ese motivo, no soy muy partidaria de los productos que dependen en gran medida de los módulos o añadidos, no me gusta Drupal por eso. Quizás cuando esta versión 6 llegue a una versión más estable lo pruebe. Mi principal criterio para la selección de programa de código libre (cuando es para clientes) se base en el tiempo que lleva en el mercado, la fiabilidad y las funciones que tiene (a lo mejor no necesito muchas, pero las que necesita el proyecto deben estar incorporadas). Si es necesario yo misma desarrollo a partir de mis propios módulos (que esos sí los conozco bien). Es una visión de alguien que ya lleva muchos años peleándose con actualizaciones, de software comercial y de software libre, con necesidades cambiantes de los clientes y de los usuarios, y, por supuesto, con posibilidades cambiantes en este apasionante mundo que sigue en evolución ;) Un saludo Victoria El sáb, 16-02-2008 a las 08:58 -0100, Carlos Revillo escribió: > > > > > > Carlos: > > Si entendés inglés, tenés información sobre actualizaciones en las > > siguientes direcciones: > > > > http://drupal.org/drupal-6.0 > > http://drupal.org/videocasts/upgrading-to-6 > > > > Y para los módulos aquí: http://drupal.org/node/114774 > > > > Martín. > > > Gracias. por actualización no me refería a una reprogramación de todo lo > que has hecho anteriormente. me refería a un proceso mas simple. el típico > "haz un backup de tu bd, corre este script para actualizarte al nuevo > formato. no te preocupes por lo de antes, todo te funcionará." Algo así > como hacían cuando migrabas de la 5.5 a la 5.6, por decir algo. > me refería a ese tipo de procesos y no a reprogramar todos y cada uno de > los módulso que programaste previamente... > a ver si me explico mejor. supón que tienes un proyecto en drupal > llamesmole mediano. has usado muchos modulos enviados por la gente (que se > yo, gmaps, buddylist, etc.) y has programado tu otros que te requería tu > cliente. ninguno de esos funcionará después de la migración. > > Otro ejemplo. el famoso módulo "pathauto". permite trabajar con urls > amigables para buscadores. ahora mismo no hay una versión estable > (todavía) para la versión 6 de drupal. hay una en desarrollo que > seguramente funcione pero nadie te lo asegura. si ahora migras un sitio > que tienes hecho en 5, con tus urls amigables a la 6, las urls dejarán de > funcionarte... > así con muchos otros casos. > > de igual forma que he visto esos vídeos, también hemos visto opiniones de > gente que dice que la migración completa (es decir, hacer funcionar un > sitio programado en drupal 5 para drupal 6) les llevó dos semanas de > trabajo. > > seguramente drupal 6 sea mucho mejor que la 5 y por ello me alegro. pero > me da un poco de lástima que no se hayan preocupado de mantener la > compatibilidad hacia atrás. > ___ > Lista de distribución Ovillo > Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org > Puedes modificar tus datos o desuscribirte en la siguiente dirección: > http://lists.ovillo.org/mailman/listinfo/ovillo ___ Lista de distribución Ovillo Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
