Lista de herramientas para generar datos de prueba

ByLuis

Una de los grandes problemas con los que nos podemos enfrentar a la hora de desarrollar una aplicación web es que el rendimiento en las etapas iniciales no es similar a cuando hay muchos datos y muchos usuarios concurrentes. Para los usuarios se pueden hacer pruebas de estrés, pero para el volumen de datos que debe manejar la base de datos hay que rellenar las tablas con datos de prueba. Para ello, este listado puede sernos bastante útil:

  • GenerateData: para mí uno de los mejores, y del que ya hablé hace tiempo.
  • DBMonster: para generar datos aleatorios en la base de datos. Muy completo pero algo más complejo.
  • CSV Data Generator: basado en Ruby genera ficheros CSV.
  • Datagenerator: este me ha gustado bastante, es sencillo y no por ello simple. Permite introducir datos en Mysql, Firebird, Interbase, MSSQL, Oracle, SQLite y PostgreSQL.

En el post original mencionan otros, pero no me han llegado a gustar.

Test (Sample) Data Generators

Similar Posts

Concurso: enseña a realizar una página Web

ByLuis

mdw.pngEn Maestros del Web han lanzado un concurso en el que se pide enseñar a realizar una página web. En Sentido Web nos gustan todo este tipo de iniciativas, sobre todo cuando se trata de ayudar a otros a aprender lo necesario para introducirse en el mundo del desarrollo web.

Además, me han pedido que forme parte del jurado, lo cual, a parte de un honor, es una oportunidad de aprender de los concursantes que no pienso desaprovechar.

Bases:

Necesitamos que desarrolles una página web y la publiques en cualquier espacio a tu disposición. En donde debes explicar a los internautas los pasos necesarios para crear su página web. Puedes utilizar cualquier recurso: textos, audios, vídeos y animaciones, estructurados, en un sitio web. Los contenidos deben estar en idioma español.

El material debe ser inédito, de la autoría del participante y ceder los derechos de reproducción por medio de una licencia Creative Commons de Reconocimiento 2.5 (lo que significa que todo el mundo podrá difundir tu creación una vez se mantenga tu crédito correspondiente).

A quién va dirigido:

Toda aquella persona que tenga conocimiento de publicación de contenidos en la web.

Fechas importantes:

30 de noviembre 2006 – último día de recepción de trabajos.
11 de diciembre – presentación de los 10 mejores trabajos.
15 de diciembre – anuncio del ganador.

Premio:

Un iPod de 30GB en tu color favorito.

Procedimiento:

Para participar necesitarás estar inscrito en forosdelweb.com para que tengamos tus datos. Deja un mensaje en el tema de Inscripción al concurso para confirmar tu participación.

La dirección URL del proyecto deberá ser enviada por correo a concurso(AT)maestrosdelweb.com antes del 30 de noviembre. Deberás incluir tu nombre de usuario de forosdelweb.com y una breve descripción del proyecto.

Vía / Maestros del Web

Torii: aplicación para crear portales

ByLuis

torii.pngTorii es una aplicación que desarrolla portales de forma sencilla mediante el uso y desarrollo de módulos. Incluye una extensa documentación y una serie de módulos iniciales como integración de feeds, tiempo, sistema de información, listas to-do y mucho más.
torii2.png
Además incluye temas que nos permite modificar el aspecto de nuestro portal de forma rápida.
No hace mucho uso de Javascript para evitar que el gasto innecesario de los recursos del navegador. A parte, el porta se cargan con mucha rapidez ya que los datos se cargan asíncronamente más tarde.
Es necesario disponer de PHP 5.2 y las siguientes extensiones: SimpleXML, DOM, PCRE y SPL, JSON, PDO y PDO/SQLite, y Curl. PDO/SQLite es necesario porque algunos módulos necesitan almacenar información.
Torii

|

HTML5′s “email” and “url” Input Types

ByLuis

I’ve already covered some subtle HTML5 improvements like placeholder, prefetching, and web storage.  Today I want to introduce a few new INPUT element types:  email and url.  Let’s take a very basic look at these new INPUT types and discuss their advantages.The SyntaxThe syntax is as basic as a text input;  instead, you set the type to “email” or “ …

Post original

|

9 fallos que hacen que Google no te indexe

ByLuis

Muchas veces el intentar desarrollar aplicaciones demasiado diferentes o mal implementadas, hace que las páginas que la página web de nuestro cliente no sea indexada por Google:

  • Menús Javascript: los buscadores no siguen los enlaces javascript.
  • Mapa de imagen: al igual que los javascripts, no pueden seguir las imágenes.
  • Enlaces con imágenes o rollover: cuando contienen javascript y no están desarrollados por CSS.
  • Pop-ups: desarrollados mediante Javascript.
  • Menús por combos: cuando los menús se crean mediante SELECT, normalmente se accede por un formulario.
  • Enlaces en etiquetas NOSCRIPT: debido al abuso de esta etiqueta por parte de spammers, los buscadores no le hacen caso.
  • Frames: debido a su mal uso, Google ha penalizado su uso.
  • Java: no puede acceder a su contenido ni ejecutarlos.
  • Flash: ya tratado con anterioridad el uso del Flash o no, los motores de búsqueda no los tratan. De todas formas, siempre es recomendable presentar una alternativa al Flash.

Resumen: cuidado con el Javascript.

9 Common Web Design Mistakes Prevent Google From Indexing Your Site

Vía / dzone

Diferencias entre un buen diseñador y un gran diseñador

ByLuis

Estando a la espera de que nos cuenten las diferencias entre un mal diseñador y un buen diseñador, que sería algo que necesitamos algunos, nos quedamos con un buen artículo que nos explica las diferencias entre un buen diseñador y un gran diseñador.

Se trata del típico post que todo el mundo referencia y que uno se da cuenta que se entera de las cosas el último, por eso voy a referenciar donde lo he visto originalmente, donde lo he leido en español y por su puesto el original.

Entre las cosas que más me han gustado destaco lo siguiente:

Mientras un buen diseñador dispone de ciertos elementos y los organiza de manera estética, un gran diseñador se preocupa además porque el mensaje que expresa su diseño llegue a destino.

…los artistas crean problemas, los diseñadores los solucionan. Pero un gran diseñador se adelanta a un problema potencial, tiene visión.

La conclusión a estas ideas nos lleva nuevamente a la razón de ser del trabajo de diseño, que es justamnente lo que diferencia además a un diseñador de un artista: las necesidades y problemas que atiende el diseño suelen ser -por lo general- ajenas al diseñador. El diseñador no es más que un instrumento comunicativo en esencia.

Nine skills that separate good and great designers

9 habilidades que separan buenos y grandes diseñadores

Vía / Criterion

Qué debería tener un proyecto web Open Source

ByLuis

El uso de herramientas web open source es muy frecuente tanto en proyectos personales como profesionales. Existen alternativas de código abierto para casi todo lo que podemos necesitar: blogs, CMS, gestión de proyectos, galerías de imágenes, … Desgraciadamente, algunas veces estos proyectos open source no son demasiado “buenos” y trabajar con ellos puede ser un verdader suplicio.

Quizás hablo desde la desesperación que sufro últimamente por tener que lidiar con el desarrollo de otros, pero me gustaría compartir una serie de aspectos que debería tener un proyecto web open source, sobre todo aquellos que ya tienen unos cuantos años, lógicamente, sin desmerecer el trabajo altruista de nadie.

  • Buena documentación: imprescindible, ya sea para el usuario como para el desarrollador.
  • MVC: bueno, cualquier proyecto debería seguir esta arquitectura, pero en el caso de un proyecto open source en el que cualquiera puede echar mano al código, se convierte en algo absolutamente necesario ya que normalmente se requiere una personalización y si se ha de tocar el core para realizar los cambios necesarios, mal vamos. Además, el MVC te permite quitar las odiosas tablas que te encuentras en muchos proyectos.
  • Plugins: el proyecto deberá permitir que otros añadan funcionalidades a tu código. El éxito de un proyecto open source depende de la comunidad, y es la comunidad la que se suele encargar de los plugins. En versiones iniciales es posible que esta funcionalidad no exista, pero debería ser una futura implementación.
  • Themes: para proyectos de CMS, blogs o con frontend público, siempre viene bien tener una lista de themes donde poder elegir y diferenciar tu aplicación de otras similares. Además, también es un origen de colaboraciones por parte de la comunidad (al igual que los plugins) y existen numerosas webs o empresas que ofrecen themes de pago, lo cual aporta negocio e interés para los usuarios/desarrolladores.
  • I18N: aunque muchos estamos acostumbrados al inglés, es necesario que el proyecto permita la internacionalización para que existan versiones en diferentes idiomas; a todo el mundo le gusta usar las aplicaciones en su propio idioma.
  • Comunidad: el Santo Grial, si tienes comunidad, tendrás éxito (o casi). Creo que esto debe ser lo más complicado de obtener, porque en parte no depende de tí, depende del gusto de los otros desarrolladores, por eso, quizás, los puntos anteriores sean tan importantes.
  • Foro: aunque algunos crean que los foros están obsoletos, no hay nada más utilizado y necesario que un foro para resolver dudas, sobre todo si existe un foro mayoritario y no tienes que buscar en otros 100, y más importante aún, que las respuestas las ofrezcan, entre otros, los desarrolladores del proyecto open source.
  • Gestor de errores: da igual si es Trac, Bugzilla u otro similar. El problema de todo proyecto es la detección, corrección y seguimiento de errores, si se ofrece una herramienta para que la comunidad se involucre en esta fase el proyecto irá mucho mejor.
  • Gestor de versiones: SVN, git o similares, para que la gente se pueda descargar las últimas modificaciones
  • API: al igual que los plugins, permite que otros interactuen con tu aplicación, sobre todo desde otras aplicaciones diferentes, por lo que se añade riqueza al proyecto.
  • Código documentado: aunque exista una documentación del uso de las funciones “públicas”, siempre viene bien tener la documentación de core.
  • Sencillez: por favor, que para crear un plugin, módulo o componente no sea necesario crear 20 archivos y 30 directorios
  • Estándares: si todos vamos a nuestra bola, al final habrá que aprender 100 métodos distintos, siempre es mejor seguir los eśtandares y no volver loco al personal. Por ejemplo OAuth, no te crees tu propio método de autenticación porque si la gente lo necesita usar le causarás un inconveniente, y si no lo necesita usar se echará para atrás y cambiará de opinión porque no le apetecerá usarlo.
  • Interacción con otras aplicaciones: en el punto en el que nos encontramos es absurdo pensar únicamente en nuestra aplicación, ahora es necesario que todo se conecte con todo, no nos olvidemos de los archifamosos Google, Facebook y Twitter

Actualizado desde aquí

  • Administración: existe algunos proyectos que van por ficheros de configuración, lo cual no quiere decir que sea difícil de administrar, pero no todos los usuarios son avanzados y hay que poner las cosas fáciles a la gente.
  • Instalador: como bien dice Chema un instalador sencillo y paso a paso puede ser fundamental para el éxito del proyecto, ya que si la instalación es complicada, probablemente el usuario no avance y descarte usar nuestro proyecto.

No son nuevas verdades, pero aunque parezca mentira en muchos proyectos que he visto algunos puntos brillan por su ausencia y en otros se hace justamente lo contrario