Comentarios en: Pongamos a dieta nuestro Script.aculo.us (18KB) http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/ Desarrollo web, Wordpress, y alguna cosilla más Sun, 21 Mar 2010 23:01:01 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Por: Zenhaust http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40351 Zenhaust Fri, 21 Sep 2007 20:03:39 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40351 Yo no digo que no haya que utilizar el código de terceros. Pero al menos se debería estar en posesión de un mínimo de decencia para reconocer que el trabajo es de otro. Es precisamente ese otro el que debe establecer la forma de distribución de su trabajo, que para eso le ha llevado sudores varios y cabezazos contra la mesa. Si luego decide distribuirlo libremente será su decisión personal, la cual alavo profundamente. Lo único que yo expongo es que existe la posibilidad de que aquel desarrollador que lo desee pueda proteger su código con unas medidas, por supuesto no irrompibles, pero al menos suficientes para espantar a todos aquellos intrusos y enteradillos, que resuelven aplicaciones complejas en dos patadas, apropiándose del código y la autoría de desarrollos de terceros. Y aún diré más. Si consiguen romper las protecciones se habrán ganado el uso del código en discordia, puesto que para eso hacen falta conocimientos más bien avanzados, que se suponen en un desarrollador experto, capaz por otro lado de desarrollar un sistema de parecidas características si fuera el caso. Resumiendo. ¿El código libre? Sí, pero con permiso del autor. Yo no digo que no haya que utilizar el código de terceros. Pero al menos se debería estar en posesión de un mínimo de decencia para reconocer que el trabajo es de otro. Es precisamente ese otro el que debe establecer la forma de distribución de su trabajo, que para eso le ha llevado sudores varios y cabezazos contra la mesa. Si luego decide distribuirlo libremente será su decisión personal, la cual alavo profundamente. Lo único que yo expongo es que existe la posibilidad de que aquel desarrollador que lo desee pueda proteger su código con unas medidas, por supuesto no irrompibles, pero al menos suficientes para espantar a todos aquellos intrusos y enteradillos, que resuelven aplicaciones complejas en dos patadas, apropiándose del código y la autoría de desarrollos de terceros. Y aún diré más. Si consiguen romper las protecciones se habrán ganado el uso del código en discordia, puesto que para eso hacen falta conocimientos más bien avanzados, que se suponen en un desarrollador experto, capaz por otro lado de desarrollar un sistema de parecidas características si fuera el caso.
Resumiendo. ¿El código libre? Sí, pero con permiso del autor.

]]> Por: eduo http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40057 eduo Wed, 12 Sep 2007 07:43:38 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40057 O sea, que está muy bien usar el código de otros pero malditos sean los que quieran usar el nuestro? La exclusividad del código se perdió cuando se inventó la web. Aprendamos a vivir con esto. O sea, que está muy bien usar el código de otros pero malditos sean los que quieran usar el nuestro?

La exclusividad del código se perdió cuando se inventó la web. Aprendamos a vivir con esto.

]]> Por: Zenhaust http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40048 Zenhaust Tue, 11 Sep 2007 22:37:38 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-40048 Conozco el gran trabajo de Dean Edwards. El problema que encuentro es que el código no es para nada ilegible. Basta con escribir el resultado de la funcion de desempaquetado en el body de una nueva ventana y voila. No obstante creo que resulta enormemente interesante combinarlo con <a href="http://jsblock.ath.cx/cry" rel="nofollow">CopyRightParser</a> (made in spain). En este sitio se modifica el código de forma que solo funcione para el dominio especificado, evitando la portabilidad del mismo. Además puede añadirse una linea de copy right visible y muy difícil de eliminar. Con esto no solo se empaqueta el código, sino que además se protege la autoría del desarrollo, de forma que su distribución corresponda única y exclusivamente al autor, y no a terceras personas ajenas al desarrollo del mismo y sin permiso expreso del propietario. Conozco el gran trabajo de Dean Edwards. El problema que encuentro es que el código no es para nada ilegible. Basta con escribir el resultado de la funcion de desempaquetado en el body de una nueva ventana y voila.
No obstante creo que resulta enormemente interesante combinarlo con CopyRightParser (made in spain). En este sitio se modifica el código de forma que solo funcione para el dominio especificado, evitando la portabilidad del mismo. Además puede añadirse una linea de copy right visible y muy difícil de eliminar. Con esto no solo se empaqueta el código, sino que además se protege la autoría del desarrollo, de forma que su distribución corresponda única y exclusivamente al autor, y no a terceras personas ajenas al desarrollo del mismo y sin permiso expreso del propietario.

]]> Por: Heinsk.net blog » Blog Archive » script.aculo.us http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-39822 Heinsk.net blog » Blog Archive » script.aculo.us Wed, 05 Sep 2007 01:36:11 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-39822 [...] Aunque debo de decir que el uso de esta librería es temporal y espero obtener mejores resultados que los “famosos” Widgets que tení­a hace rato con Dojo Toolkit, ya que como toda librería de Javascript proporcionan efectos geniales pero a un costo muy alto: son librerias muy pesadas y hacen lento el acceso a sitios Web (script.aculo.us pesa 131 kb!! y por lo general no se hace uso de todas sus funciones). Por cierto existe un receta para poner a dieta a script.aculo.us. [...] [...] Aunque debo de decir que el uso de esta librería es temporal y espero obtener mejores resultados que los “famosos” Widgets que tení­a hace rato con Dojo Toolkit, ya que como toda librería de Javascript proporcionan efectos geniales pero a un costo muy alto: son librerias muy pesadas y hacen lento el acceso a sitios Web (script.aculo.us pesa 131 kb!! y por lo general no se hace uso de todas sus funciones). Por cierto existe un receta para poner a dieta a script.aculo.us. [...]

]]> Por: aNieto2k http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-26470 aNieto2k Sat, 10 Feb 2007 11:32:58 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-26470 #4 La caché es una gran aliada de script.aculo.us. Pero ¿por que usar 180kb de javascript para hacer lo mismo que con 30kb de MooTools? #4 La caché es una gran aliada de script.aculo.us. Pero ¿por que usar 180kb de javascript para hacer lo mismo que con 30kb de MooTools?

]]> Por: Gerardo http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-26451 Gerardo Sat, 10 Feb 2007 05:11:12 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-26451 Bueno, tienes razon en cuanto al peso de la libreria, pero bien es lo que puede llegar a pesar una o dos imagenes de tamaño mediano. Por otra parte para algo existe el cache de los navegadores, para que no siempre se tenga que estar descargando. Bueno, tienes razon en cuanto al peso de la libreria, pero bien es lo que puede llegar a pesar una o dos imagenes de tamaño mediano.

Por otra parte para algo existe el cache de los navegadores, para que no siempre se tenga que estar descargando.

]]> Por: 5 reglas del desarrollo web - aNieto2K http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-21177 5 reglas del desarrollo web - aNieto2K Fri, 29 Dec 2006 01:45:51 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-21177 [...] En este punto me he repetido hasta la saciedad de lo importante que es reducir bytes y kbytes de nuestros ficheros, la suma de ellos siempre nos ayudarán a mejorar la experiencia del usuario, poder reducir el ancho de banda contratado,… [...] [...] En este punto me he repetido hasta la saciedad de lo importante que es reducir bytes y kbytes de nuestros ficheros, la suma de ellos siempre nos ayudarán a mejorar la experiencia del usuario, poder reducir el ancho de banda contratado,… [...]

]]> Por: Script.aculo.us selectBox, mejorando los select - aNieto2K http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-11853 Script.aculo.us selectBox, mejorando los select - aNieto2K Fri, 27 Oct 2006 10:05:45 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-11853 [...] La gente de script.aculo.us, estará contenta, ya que su librería pese a ser una de las más pesadas de la red, tambien es de las más usadas. Y esta versión de <select></select> demuestra que la gente la usa y desarrolla para ella. [...] [...] La gente de script.aculo.us, estará contenta, ya que su librería pese a ser una de las más pesadas de la red, tambien es de las más usadas. Y esta versión de <select></select> demuestra que la gente la usa y desarrolla para ella. [...]

]]> Por: Nueve reglas para mejorar tu Javascript - aNieto2K http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-11185 Nueve reglas para mejorar tu Javascript - aNieto2K Sat, 21 Oct 2006 00:38:05 +0000 http://www.anieto2k.com/2006/09/24/pongamos-a-dieta-nuestro-scriptaculous-18kb/#comment-11185 [...] Piensa en apurar al máximo el tamaño de tus ficheros, pero son abusar de estructuras y funciones muy pesadas para el procesador del cliente (no sabes donde se va a ejecutar). Encontrar un équilibrio entre estos dos puntos puede ser más complicado de lo que parece (recuerdo haber leido que no se recomienda comprimir nuestro Javascript aunque no se por donde). [...] [...] Piensa en apurar al máximo el tamaño de tus ficheros, pero son abusar de estructuras y funciones muy pesadas para el procesador del cliente (no sabes donde se va a ejecutar). Encontrar un équilibrio entre estos dos puntos puede ser más complicado de lo que parece (recuerdo haber leido que no se recomienda comprimir nuestro Javascript aunque no se por donde). [...]

]]>