DHTMLSite: aprendiendo mediante ejemplos

170 cheat sheets para desarrolladores web

ByLuis October 31, 2006

Ya hace tiempo hablamos de un directorio donde podÃamos encontrar 30 cheat sheets, en este caso se trata de 170, que nos ayudarÃ¡n en nuestro desarrollo web.
Aunque no todas son de desarrollo web, si la mayorÃa. Organizada por categorÃas, podemos encontrar ‘chuletas’ sobre: ActionScript, Ajax, Apache, ASCII, ASP, C#, CSS, CVS, Firefox, Google, HTML, Java, Javascript, LaTeX, microformatos, MySQL, Oracle, Perl, Photoshop/Gimp, PHP, Python, expresiones regulares, Ruby, Linux, blogs, Windows y XMLs.
Yo ya le he dado a imprimir unas cuantas que me van a venir muy bien.
Cheat Sheet Round-Up: Ajax, CSS, LaTeX, Ruby
VÃa / Digg

Drupal

Drigg: clon de Digg con Drupal

ByLuis May 8, 2008

Aquellos que quieran crear una web al estilo Digg ya lo pueden hacer mediante Drigg, un módulo para Drupal que nos ofrece este servicio. Para su uso es necesario disponer de otros dos módulos: user_karma y un módulo para votaciones (preferiblemente extra_voting_forms.
Es sencillo de usar y permite modificar el theme de forma fácil. Los fotos se realizan también de forma simple, pudiendo elegir entre 4 tipos de votos. Además permite crear votos automáticos para el inicio de la aplicación para darle actividad aleatoria a la aplicación.
Drigg
Vía / Smashing Apps

Desarrollo web

Proteger tu aplicación web

ByLuis November 24, 2006

InteresantÃsimo artÃculo que nos guÃa a proteger nuestra aplicaciÃ³n web para evitar posibles ataques. Haciendo un corto resumen, separamos las distintas acciones que debemos seguir en:

Validar todas nuestras entradas (variables de sesiÃ³n y formularios). Los datos deben ser lo que se esperan, y si se esperan desde POST, que no vengan desde GET.
Evitar el cross-site scripting (XSS) que es la introducciÃ³n maliciosa de cÃ³digo mediante formularios que se ejecutarÃ¡ en nuestra aplicaciÃ³n.
Modificar el fichero de configuraciÃ³n php.ini para que no use super globals, para mostrar todos los errores y que estos se muestren por fichero.
Asegurar la conexiÃ³n a la base de datos. Este mÃ©todo no lo conocÃa y la verdad es que me ha gustado bastante.
Bloquear IPs de hackers, ya sea mediante PHP o htaccess
Si el otro dÃa hablÃ¡bamos del LDAP, ahora nos hablan del LDAP injection, otra cosa que no sabÃa (no, si ya he dicho que es un buen artÃculo).
Evitar que Google proporcione datos que no queremos (Google Hacking), para ello lo mejor es usar el robots.txt.
Restringir el acceso mediante .htaccess

Protecting your Site

VÃa / dzone

Desarrollo web

Consejos para evitar crear malas aplicaciones web

ByLuis March 22, 2007

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

Similar Posts