Citizendium: la competencia de Wikipedia

citizendium.pngCitizendium nace como la competencia de la Wikipedia, aunque yo más diría que se trata de otro gran punto de información. Siguiendo la misma filosofía que la Wikipedia y creada por un fundador de esta, Citizendium pretende ser más estricta que la Wikipedia ya que requerirá registro con nombre real y los artículos serán llevados por un junta editorial.
Usando el modelo wiki, quiere ofrecer una enciclopedia con un cierto toque de expertos. Por ahora han usado 1100 artículos de la Wikipedia que están refinando.
En estos momentos disponen de unos 820 autores y 186 editores. Los editores decidirán que versión de un artículo será la que se publique y cual necesita una revisión más académica.
Cada cual que se registre con su nombre real está invitado a participar en este proyecto, pero cada usuario estará controlado por una especie de “policía”, el cual deberá ser licenciado universitario.
Un buen proyecto que intenta evitar los problemas con los que se enfrenta la Wikipedia.
Citizendium
Vía / CNET News.com

links for 2007-03-27

MySQL Migration Toolkit

mysql.pngEl otro día nos preguntaban una forma de migrar una base de datos Access a otra MySQL. En ese momento no conocía ninguna aplicación que pudiera hacerlo, pero hoy me he enterado que los propios de MySQL tienen MySQL Migration Toolkit, que permite mediante una serie de pasos realizar una migración de forma correcta.
mysql_migration.png
Entre las base de datos que podemos migrar nos encontramos: Oracle, Microsoft SQL Server, Microsoft Access y otras. A parte reduce riesgos usando una metodología, ahorra costes incrementando la productividad, elimina días de trabajo de querys manuales, test y debug.
He visto también en en artículo desde el que hacemos referencia, que MySQL Workbench, del que hicimos referencia en su día, no está disponible para su descarga como lo estaba anteriormente, esperemos que sea porque anden mejorando este producto.
MySQL Migration Toolkit
Vía / Conexiones Razonables

Mejor técnica para herencia en Javascript

Muy buen artículo que nos explica paso a paso cómo conseguir implementar la herencia en Javascript. Aunque Javascript no es un lenguaje pensado en la orientación a objetos, últimamente debido al Ajax y a las librerías que van apareciendo, nos solemos encontrar con la necesidad de implementar OO en nuestras aplicaciones clientes y, en casos menos frecuentes, tratar el tema de la herencia en Javascript.
Este artículo nos explica desde el inicio de herencia entre clases, hasta los problemas con los que nos vamos encontrando. El problema más frecuente es cuando una clase llama a un método de la clase padre, si se usa this en la clase padre, usará la clase padre, y no la hija, que es lo que se supone que se espera que haga.
Otro problema que nos explica, es la necesidad de indicar cuál es la clase padre, para poder referenciarla. Si se especifica directamente, se puede solucionar el problema, pero si la estructura de clases es compleja, especificar en cada una de ellas cuál es el progenitor, nos encontramos con una estructura difícil de mantener.
A parte de resolvernos la realización de herencia entre clases en Javascript, este artículo nos enseña a resolver los problemas que nos podemos encontrar, ya que hubiera sido más sencillo darnos la solución, explicarla y listo, pero sin embargo lo que hace es ofrecer soluciones iniciales, ver que problemas representa y luego solucionarlos y pasar a otra versión mejorada.
También me gustaría destacar la explicación de los métodos call() y apply() que poseen las funciones en Javascript. Hay que tener en cuenta que en Javascript las funciones son tratadas como objetos, admiten propiedades y métodos. El método call() permite especificar el this utilizado, mientras que el método apply() el array de argumentos que se le pasa a la función.
Introducing the best Javascript Inheritance Technique

links for 2007-03-25

links for 2007-03-24

|

Laboratorio: mostrar que thumbnails has visitado

Una de las cosas que más me ha gustado de Design Meltdown es que te indica que thumbnails has visitado.

Se trata de lo siguiente, tienes un enlace que contiene una imagen en miniatura que accede a la imagen con el tamaño original (thumbnail). Cuando ya has visitado la imagen el thumbnail cambia y te dice que ya lo has visitado.

imagenes-visitadas.png

Para hacerlo es sencillo, creas una capa con un tamaño específico (el del thumbnail), le indicas mediante estilo dentro de la propia etiqueta HTML la imagen de fondo, que será el thumbnail en sí.

Dentro de la capa incluyes un enlace que se mostrará como un bloque (display: block) y que no mostrará nada, bueno, en este caso si mostrará un texto que referencie a lo que enlaza, pero mediante estilos el texto no se verá, esto lo hacemos así para que los dispositivos que no admitan estilos puedan ver algo.

Modificaremos el estilo de enlace visitado para que muestre como fondo una imagen parcialmente transparente y que muestre el texto “visitada”.

.contenedor-imagen {
width: 150px;
height: 85px;
}
.contenedor-imagen a {
text-indent: -100000px;
display: block;
width: 150px;
height: 85px;
border: 2px solid #FFFFFF;
}
.contenedor-imagen a:hover {
border: 2px solid #FF0000;
}
.contenedor-imagen a:visited {
background: url(visitada.gif);
}
<div class="contenedor-imagen" style="background: url(miniatura.png)">
<a href="http://sentidoweb.com?ejemplo1">Sentido Web</a>
</div>

Ejemplo

Por qué es mejor Subversion que CVS

Cinco motivos por los que Subversion es mejor que CVS, el otro día lo hablábamos en el trabajo porque lo más seguro es que pasemos a Subversion y hoy encuentro esta entrada en la que lo explica muy bien:

  • Histórico de directorios y no solo de ficheros.
  • El histórico de ficheros se conserva aunque el fichero se mueva, renombre o se haga una copia.
  • Facilidad de restructuración de directorios.
  • Las revisiones son a nivel del head.
  • Sistema de resolución de conflictos, usando tres ficheros: revisión antigua, la nueva y la que tienes en local.

¿Por qué es mejor subversion que cvs?

Vía / Prográmame

links for 2007-03-23

Consejos para evitar crear malas aplicaciones web

Una lista con consejos para evitar realizar aplicaciones web que no tengan una buena calidad. Lo malo de las listas es que normalmente se basan en la experiencia del autor, por lo que a veces no se está de acuerdo totalmente con ellas. En este caso yo estoy bastante de acuerdo con la mayoría.

  • Pon los estilos y los javascript en ficheros independientes: complica la lectura, el debug y dificulta que varios desarrolladores modifiquen el mismo archivo.
  • Comprime: comprime la salida para ahorrar ancho de banda. Con esto no estoy del todo de acuerdo, ya lo hemos comentado antes en Sentido Web, hay que pensar que el comprimir la salida en el servidor requiere tiempo de ejecución en la máquina, no me imagino a Technorati, que a veces tarda un poco en darte la respuesta, despilfarrando tiempo de ejecución.
  • Valida: valida según el DOCTYPE que hayas especificado.
  • Cuidado con los mensajes de error: los mensajes de error deben estar enfocados en el usuario, no en el desarrollador para luego saber qué ha fallado. Además, mostrar mensajes de error de la aplicación específicos para los desarrolladores puede proporcionar información sensible a terceras personas.
  • No uses tablas: a parte de ser más fácil de mantener, y más claro de leer, ahorras ancho de banda al escribir menos código debido a la ausencia de TDs y TRs. Luego está, lógicamente, todas las otras razones que todos conocemos para no usar tablas.
  • Desarrolla para todos los navegadores modernos: no te centres solo en IE, existen otros, y aunque se usen menos, cada vez se usan más. Imagínate que una tienda por internet solo funciona para IE, ya que solo el 15% de los usuarios usa Firefox (por ejemplo), es bastante posible que la mayoría de ese 15% no entre en esa tienda online y busque una alternativa. Ese 15% de usuarios de Firefox quizás pueda representar un 15% de ventas.
  • Comprueba los requerimientos: si tu página necesita Javascript, cookies, flash o un plugin, comprueba que el navegador del usuario lo admite, si no es así hazlo saber.
  • Prueba la usabilidad con usuarios reales: a veces algunos sitios son difíciles de usar debido a que quienes lo usan no son quienes lo diseñan.
  • Usa una base de datos real: no uses Access u otro tipo de base de datos de ese estilo, si no puedes pagar Oracle usa MySQL.
  • Que sea multiplataforma: no uses ActiveX o cosas que sean específicas de una plataforma.
  • Piensa en el ancho de banda: no todo el mundo debe tener una línea con un ancho de banda grande, si la página tarda en cargarse es posible que el usuario huya de ella.
  • Ten en cuenta la internacionalización: si desarrollas algo para todo el mundo y solo lo realizas en inglés, es posible que no logres lo que buscas.
  • Testea: esto es lo de siempre, los test es lo más aburrido pero lo más necesario. Que los desarrolladores hagan sus pruebas primarias, pero que los verdaderos tests los hagan personas ajenas al desarrollo.

Ways to Avoid Building Web Applications That Suck

Vía / dzone