el holgazán

Me gustaba la física...

2008-11-18T22:57:00.002+01:00

Al hilo de Cerrar bucles y unir puntos, de ensilicio.com:

Me gustaba la física por los siguientes motivos:

Nos permite predecir algunos acontecimientos futuros con cierta exactitud.

Nos permite diseñar y construir herramientas y otros sistemas que pueden mejorar nuestra forma de vida.

Pero sobre todo: me parece maravillosa la idea de que exista una ley universal que unifique todas las teorías de la física. Me produce una satisfacción filosófica el hecho de conocer "la causa de todo". Satisfacción por el conocimiento como fin en sí mismo.

Digo me gustaba porque he dejado de prácticarlo. Me he vuelto terriblemente pragmático y holgazán.

¿Cómo nos va afectar la crisis?

2008-11-05T22:51:00.003+01:00

Iban dos muchachos de safari por la selva, cuando de repente, entre unos arbustos aparece un león.

Ellos en un primer momento quedaron inmóviles. Pero de repente uno se quita la mochila y saca unos playeros más ligeros que las botas que llevaba y se las empieza a poner.

El otro, soprendido ante la reacción del amigo y con el miedo en el cuerpo le pregunta: “¿Para qué te cambias los playeros si corre más que tú y te va a coger igual?”.

A lo que el que se estaba poniendo las playeros le contesta: “Puede ser, pero lo que yo quiero es correr más que tú”.

(Vía Habilidades Directivas).

10 ideas para la reducción de defectos del software

2008-11-02T16:33:00.013+01:00

Encontrar y arreglar un problema en el software después de la entrega suele ser 100 veces más caro que encontrarlo y arreglarlo durante la fase de análisis y diseño.
Por ello la importancia de verificar y validar el software desde fases tempranas recurriendo a prototipos y simulaciones.

Los proyectos de desarrollo de software invierten entre el 40% y el 50% de sus esfuerzos en trabajo evitable.
La mayoría de este tiempo se invierte resolviendo problemas que se podrían haber descubierto antes y resuelto a menor coste o incluso evitado.

El 80% del trabajo evitable proviene del 20% de los defectos.
Las 2 mayores fuentes de trabajo evitable tienen que ver con requisitos, diseños y arquitecturas que se especifican de forma precipitada.

El 80% de los defectos provienen del 20% de los módulos, y la mitad de los módulos suelen estar libres de defectos.
Por tanto, merece la pena identificar las características de los módulos que son más propensos a errores.

El 90% del tiempo de mal funcionamiento proviene, como mucho, del 10% de los defectos.
Por tanto, es importante prestar especial atención a los escenarios de alto riesgo e invertir más en sus pruebas.

Las revisiones por pares (peer reviews) detectan el 60% de los defectos.
A veces se detectan más defectos de esta forma que mediante pruebas y otras herramientas análisis.

Las revisiones basadas en perspectiva detectan el 35% más de defectos que las revisiones no dirigidas.
Las técnicas de lectura basadas en escenarios se aplican en documentos de requisitos, diseño orientado a objetos e interfaces. Además, la inspección de estos documentos facilitan la formación del personal más inexperto y mejora la comunicación.

Las prácticas del personal más disciplinado y ordenado pueden reducir el 75% de los defectos.
Conviene analizar la causa raíz de los defectos y elaborar checklists y prácticas para evitar la recurrencia futura.

Cuesta el 50% más desarrollar productos altamente fiables que productos de menor fiabilidad.
Sin embargo, la inversión merece la pena si el proyecto entraña altos costes de operación y mantenimiento.

Entre el 40% y el 50% de las aplicaciones contienen defectos no triviales, aunque los desarrolladores piensen que los programas son fiables.
Con el aumento del número de programadores será cada vez más fácil encontrarse con programadores con poca experiencia encargándose de la detección de riesgos.
Es importante por tanto que las herramientas de desarrollo ofrezcan cada vez más mecanismos de seguridad.

Fuente: Artículo de Boehm y Basili.

Ejecución remota de procesos en paralelo

2008-11-02T12:50:00.005+01:00

JPPF es un framework Java de computación distribuida que facilita la ejecución de procesos en paralelo de forma remota en diferentes ordenadores (nodos), proporcionando la información y reuniendo los resultados desde un ordenador central (driver).

Así, un driver puede tener múltiples nodos y cada uno de estos nodos puede ser a su vez un driver con otros nodos, configurando así un arquitectura peer to peer.

Es particularmente apropiado para resolver problemas de los denominados "embarassingly parallel problems", donde un problema o programa puede dividirse en muchas tareas independientes y cada tarea puede ser ejecutada en paralelo.

Un ejemplo de este tipo de problemas es el conocido SETI@home, que analiza información recibida del espacio para detectar posibles señales extraterrestres, usando para ello el ordenador de un gran número de personas que participan a través de Internet.

Ver la guía de inicio y las instrucciones para instalar y ejecutar el driver y los nodos.

Tiempo y dinero

2008-10-18T13:15:00.002+02:00

No puedo permitirme gastar tiempo en ganar dinero.

Louis Agassiz

Otras citas sobre la vida, el universo, los ordenadores y todo lo demás, en la web de Peter Norvig, Director de Desarrollo de Google.

Commodities y factorías de software

2008-10-12T21:46:00.005+02:00

Existe un gran debate en torno al funcionamiento del modelo de desarrollo de software offshore (centros de trabajo en lugares de menor renta).

Argumentos a favor:

El software es una commodity: Con buenas especificaciones, formación, herramientas y automatización, el desarrollo es una actividad de bajo riesgo, no son las tareas de mayor valor añadido y pueden externalizarse fácilmente.
El offshoring reduce los costes: Ya que el desarrollo tiene lugar en lugares de menor renta.

Argumentos en contra:

El software no es una commodity: Porque en gran medida es una disciplina compleja y creativa. Los requisitos y las tecnologías son cambiantes. El riesgo es alto.
El offshoring no reduce los costes: Ya que se requiere cierta inversión inicial, la coordinación/planificación/documentación es más costosa y usualmente se requiere mayor esfuerzo para asegurar la calidad.

He hablado de "especificaciones" a propósito, ya que en algún caso podría ser un catálogo de requisitos y en otros casos podría ser un diseño detallado, según se quiera que el diseño esté de un lado o de otro. En caso de que el diseño esté en la parte externalizada, las exigencias de cualificación del personal serán obviamente mayores.

Al hablar de análisis, diseño y construcción no quiero decir que obligatoriamente haya que aplicar un modelo clásico en cascada. También podrían utilizarse metodologías ágiles, y en este caso el análisis/diseño/construcción sería iterativo y a pequeñas proporciones. Ver este artículo de Martin Fowler sobre metodologías ágiles y desarrollo offshore.

En conclusión:

Si los equipos son suficientemente buenos para el problema en cuestión (es decir, uno genera buenas especificaciones y otro desarrolla con alta calidad y buenos tiempos), y no hay demasiados cambios en los requisitos, seguramente el offshoring favorezca la productividad.
En otro caso (y creo que es habitual que los recursos disponibles para resolver un determinado problema sean escasos, en número y en perfil), seguramente no merezca la pena dividir el trabajo.
Por otra parte, puede ocurrir que en un proyecto de desarrollo, por los motivos anteriores, convenga externalizar sólo cierto tipo de tareas más "mecánicas", si su volumen fuera suficiente.

¿Y tú que opinas?

Desarrollar sistemas CSS mantenibles

2008-10-04T11:52:00.001+02:00

De Natalie Downe en Barcamp London:

CSS Systems

View SlideShare presentation or Upload your own. (tags: bulletproof robustness)

Model Driven Development en práctica

2008-09-27T17:11:00.008+02:00

Un diagrama muy bueno sobre la forma de estructurar las aplicaciones siguiendo el llamado Model Driven Development.

Cada cosa en su sitio. Cada capa se encarga de lo que tiene que hacer, sin contener código que debiera estar en otras capas y de forma desacoplada.

La capa de acceso a daos (DAOs) usa las funciones del motor de persistencia para ofrecer los servicios de creación, recuperación, actualización, eliminación y búsqueda de información. Utiliza objetos de dominio. Las transacciones (@Transactional) y el contexto de persistencia (@PersistenceContext) se definen mediante anotaciones Spring y JPA, respectivamente. En esta capa no se capturan las excepciones.

Los objetos de dominio (DOs) son objetos planos (POJOS) que definen los atributos (estado) y métodos de negocio. Algunos de estos métodos pueden ser campos calculados o bien métodos de creación, recuperación, actualización, eliminación y búsqueda, usando la capa de acceso a datos mediante inyección de dependencia (@Autowired en Spring). Si son persistentes tienen la información del mapeo objeto relacional de forma no intrusiva, mediante anotaciones JPA (@Entity, @Id, @GeneratedValue(strategy = GenerationType.AUTO), etc). En esta capa se controlan las excepciones que puedan ocurrir en las capas inferiores.

La capa de servicios utiliza directamente los objetos de dominio (mediante inyección de dependencia), intercambiando información con la capa de presentación en forma de DTOs, XML, etc. No añade lógica de negocio, sólo conversiones de tipos de datos y control del flujo de las operaciones. Ver: mapeo de DTOs y objetos de dominio, de objetos Java a XML, RESTful web services.

El controlador de aplicación puede ser JSF, Struts, Spring MVC, etc. Maneja la trasferencia de información entre la capa de presentación y la de servicios, mediante DTOs u otras formas de representación (XML, JSON...).

Los componentes de infraestructura, como el manejo de excepciones, la gestión de transacciones, la seguridad, el control de operaciones (logging), etc. estarán disponibles desde todas las capas de forma no intrusiva.

Mapeo de DTOs y Objetos de Dominio

2008-09-27T16:30:00.006+02:00

Cuando desarrollamos una aplicación con múltiples capas es deseable que los objetos que se intercambian la capa de presentación y la capa de servicios sean diferentes de los objetos de dominio o entidades persistentes.

El motivo es sobre todo de seguridad: el objeto a intercambiar con la capa de presentación (DTOs) no tiene por qué presentar la misma granularidad y todos los atributos/métodos que tienen los objetos de dominio (DOs). Sobre todo en aplicaciones en las que la capa de presentación y la capa de servicios no se ejecutan en la misma máquina (SOA).

En este caso se recurre al patrón de diseño Assembler.

Dozer es una utilidad de mapeo que implementa este patrón.
El mapeo entre clases se define mediante ficheros de configuración XML. Ejemplo:

La conversión, que puede realizarse en ambas direcciones, sería de la forma:

MapperIF mapper = new DozerBeanMapper();
DestinationObject destObject =
(DestinationObject) mapper.map(sourceObject, DestinationObject.class);

Árbol Ajax con jQuery

2008-09-27T11:49:00.010+02:00

Es el que más e convence de los que he visto. Más incluso que los de Ext JS.

jQuery File Tree (ver demo)

Dispone de conectores en servidor para mostrar un sistema de ficheros, en distintos lenguajes (PHP, ASP, JSP, Python, Ruby, ColdFusion y Lasso).

También puedes hacerte tu propio conector. Basta que devuelva una estructura con dos listas simples sin anidar, una de carpetas y otra de ficheros. jQuery se encarga de formar el árbol atendiendo a la ruta especificada para cada elemento: "/this/folder/", "/this/folder/filename.txt"...

<ul class="jqueryFileTree" style="display: none;">
<li class="directory collapsed"><a href="#" rel="/this/folder/">Folder Name</a></li>
(additional folders here)
<li class="file ext_txt"><a href="#" rel="/this/folder/filename.txt">filename.txt</a></li>
(additional files here)
</ul>

Además es personalizable mediante CSS y tiene la posibilidad de cambiar los iconos según sea la extensión de los archivos.

Ver también:

RESTFul Web Services con JAX-RS

2008-09-26T19:23:00.003+02:00

Estas son algunas implementaciones de la especificación JAX-RS (JSR-311) para construir RESTFul Web Services:

Jersey - Parte de Glassfish (Servidor JEE open source de SUN).
CXF - Antes XFire, de Apache.
RESTeasy - Implementación de JBoss.
Restlet

Ver este ejemplo en DZone donde se mapean los servicios mediante anotaciones:

@Path("/orders")
public class OrderEntryService {
@GET
@Path("{id}")
@Produces("application/xml")
public String getOrder(@PathParm("id") int orderId)
{
...
}
}

Fluent Interface

2008-09-18T22:34:00.004+02:00

Qué fácil es utilizar una interfaz de la forma:


customer.newOrder().with(6, "TAL")
                .with(5, "HPK").skippable()
                .with(3, "LGV")
                .priorityRush();

en vez de:

Order o1 = new Order();
     customer.addOrder(o1);
     OrderLine line1 = new OrderLine(6, Product.find("TAL"));
     o1.addLine(line1);
     OrderLine line2 = new OrderLine(5, Product.find("HPK"));
     o1.addLine(line2);
     OrderLine line3 = new OrderLine(3, Product.find("LGV"));
     o1.addLine(line3);
     line2.setSkippable(true);
     o1.setRush(true);

Ver más sobre fluent interface en la web de Martin Fowler.

Un ejemplo de herramienta con este tipo de interfaz es xmltool, para manipular documentos XML.

De objetos Java a XML y viceversa

2008-09-13T17:43:00.002+02:00

Estos son algunos motores de mapeo O/X, es decir, utilidades que permiten serializar un objeto Java a XML (también llamado "marshalling") o parsear un fichero XML para construir un objeto Java ("unmarshalling").
El objeto Java a mapear podrá contener otros objetos y así sucesivamente, formando grafos arbitrariamente complejos.

JAXB de Glassfish.
Castor.
XMLBeans de Apache.
JiXB.
XStream.

Spring OXM es un framework que es capaz de encapsular cualquiera de estas utilidades con una interfaz común, aunque con diferentes opciones de funcionamiento y configuración según el producto seleccionado.
Esta abstracción de Spring permite que la configuración sea más sencilla, proporciona una interfaz y unas excepciones homogéneas, de forma que se pueda sustituir un producto por otro sin realizar cambios en la programación (o con pequeños cambios).

En fin: al estilo de Spring...

Ejecución de scripts desde Java

2008-09-09T23:13:00.004+02:00

Spring es capaz de integrar la ejecución de scripts de lenguajes dinámicos como Groovy, JRuby y BeanShell.

En el caso de Groovy basta añadir las librerías groovy-1.0.jar, asm-2.2.2.jar y antlr-2.7.6.jar que vienen con la propia distribución del producto.
De esta manera, implementando una clase en Groovy y su interfaz en Java, podrá verse como cualquier otro bean de Spring configurando el contexto de la siguiente manera:

 <id="messenger" 
        script-source="classpath:Messenger.groovy" 
        refresh-check-delay="1000"/>

Además, indicando el parámetro refresh-check-delay podrán realizarse cambios en caliente !!

Ya se me ocurren algunas formas de usarlo...

(Vía DosIdeas.com).

Una semana sin blog

2008-09-07T23:14:00.005+02:00

Es lo que puede ocurrir cuando no controlas todos los hilos...

Cuando intentamos mapear un subdominio propio (web.elholgazan.com) con el servicio Google Pages de Google Apps, por un error en el propio Google Pages perdimos la asociación del dominio principal alojado en Blogger (www.elholgazan.com), ya que Google Apps y Blogger comparten repositorio de DNS.
El resultado: un "Server Not Found. Error 404" que se ha estado viendo durante una semana cuando se intentaba acceder a "el holgazán".

La solución que daban en Blogger era la de eliminar la asociación del blog con el dominio personalizado y volver a crearla... pero entonces ocurría un error bX-f42977 de Blogger que parece ser que ya han resuelto.

Ver más información en los errores conocidos de Blogger o en numerosas páginas de Internet que hablan de ello.

Moraleja: hay que tener siempre un plan B, una acción de contingencia.

¿Otra cuenta de Blogger de respaldo? ¿Otro alojamiento? ¿Es sencillo migrar de Blogger a WordPress?

El cerdo y la gallina

2008-08-28T15:12:00.002+02:00

Tomado de la wikipedia, en relación a la metodología SCRUM:

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice, "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta, "¿Por qué no lo llamamos 'Huevos con jamón'? "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tu solamente estarías involucrada".

A qué huelen los proyectos

2008-08-28T14:50:00.004+02:00

A veces hemos escuchado decir "esté código huele mal"... pues bien, en este catálogo se recopilan los "olores" relacionados con la refactorización del código, es decir, aquellos indicios de que algo no se está haciendo del todo bien y de que puede ser necesario realizar algún tipo de refactorización.
Algunos ejemplos:

Comentarios: deben usarse sólo para aclarar el "por qué" y no el "qué". Demasiados comentarios pueden reducir la claridad. En estos casos se puede extraer un método, renombrar un método o introducir una aserción.
Métodos largos.
Demasiados parámetros.
Etc.

De la misma manera, si la metodología que utilizais en el proyecto es SCRUM, en este catálogo se recojen aquellos "olores" que indican que algo puede ir mal y se presentan algunas alternativas para resolverlos.
Ejemplos:

Pérdida de ritmo: las reuniones periódicas dejan de mantenerse, o cambian de horario constantemente, o se vuelven incosistentes, etc.
Gallinas parlanchinas: personal externo que habla en las reuniones diarias, prioridades o planificaciones que cambian fuera de estas reuniones, etc. Algunos remedios: no permitir hablar a las gallinas, mantener a las gallinas fuera de la pocilga de los cerdos, etc.
Desaparecen los cerdos.
Etc.

Demasiados olores, ¿no?
¿Algo que huela mejor?

Rebaños de caballos y carreras de ovejas

2008-08-28T11:49:00.008+02:00

Dave Tomas comenta que el software lo hacen las personas, no las herramientas, los procesos y las metodologías.
De hecho, señala cómo el número de bugs en 1000 líneas de código se mantiene desde hace 25 años: aunque las herramientas han evolucionado, las personas son similares, y seguimos cometiendo los mismos errores.

Con "rebaños de caballos y carreras de ovejas" se refiere a la práctica muy común de tratar a todos los miembros de un equipo de la misma manera, esperando respuestas brillantes de los principiantes y tratando a los expertos como si fueran novatos.

Dave muestra el modelo Dreyfus, que presenta 5 niveles de experiencia en las personas:

Principiante: sin experiencia o con poca experiencia. Necesitan que se les diga qué hacer y requieren objetivos a corto plazo.
Principiante Avanzado: tienen más experiencia, han comenzado a observar patrones en su propia actividad, han empezado a integrar cosas por sí mismos, pero aún requieren que se les diga qué hay que hacer.
Competente: saben lo que hay que hacer y pueden planificar su actividad. Son buenos en su dominio.
Hábiles: han descubierto otros dominios además del suyo propio y comienzan a explorarlo.
Expertos: son los genios de sus equipos, puedan dar todo tipo de respuestas en muchos ámbitos, y están interesados e probar cosas simplemente para ver si funcionan.

Un pequeño consejo que nos da:

No permitas nunca a un experto que elija la arquitectura de un nuevo proyecto. Simplemente sienten la necesidad de ver si la solución funciona.

(Vía InfoQ).

Comunícate con códigos QR

2008-08-27T16:06:00.005+02:00

Puedes generar el código QR para una URL, un texto, un número de teléfono o un SMS, en diferentes tamaños.
Este es el código pequeño de http://www.elholgazan.com:

<img src="http://qrcode.kaywa.com/img.php?s=5&d=http%3A%2F%2Fwww.elholgazan.com" alt="qrcode" />

¿Que cuál es su utilidad?
Con Kaywa Reader instalado en tu móvil puedes hacer una fotografía del código y obtener así la información subyacente.

Vamos a probarlo: adivina qué es esto!

OJO: Al hacer la foto puede que tengas que poner la camara apaisada. Suerte!

OSGi no es otro buzzword

2008-08-27T15:05:00.009+02:00

Estamos de acuerdo en que OSGi va a cambiar nuestra forma de desarrollar, que la "orientación a servicios" va a ser algo más que otro buzzword (SOA).

Algunas plataformas de orientación a servicios OSGi, que permiten instalar, iniciar, detener, desinstalar, etc. los llamados "bundles" (módulos):

Spring Dynamic Modules facilita el desarrollo con plataformas OSGi.

Un ejemplo de servicio OSGi "Hola mundo":

Un bundle servidor HelloServiceImpl implementa y exporta la interfaz HelloService. Además, implementa la interfaz BundleActivator, de forma que la plataforma OSGi ejecute los métodos start y stop cuando la plataforma inicie o detenga el bundle. En este método start el objeto puede registrarse como servicio en la plataforma.

Un bundle cliente HelloConsumer usa e importa el servicio HelloService. Siendo también un BundleActivator, en el método start obtiene el contexto de la plataforma OSGi, a partir del cual puede obtener el servicio y utilizarlo.

Algunas ventajas de estos sistemas de módulos dinámicos:

Desarrollo e instalación más modular.
Mejor gestión de las dependencias.
Módulos con gestión de versiones.
(Re)Despliegue individualizado y dinámico de los módulos.
Control de activación/desactivación de los módulos.

Aunque el debate entre OSGi (JSR 291) y la JSR 277 continúa...

SmartClient: a la altura de Ext JS

2008-08-26T11:35:00.004+02:00

SmartClient es un framework Ajax con bastantes capacidades (a la altura de Ext JS), con diferentes opciones de licencia (una de ellas LGPL) y buena documentación. Además, parece ser bastante maduro y está siendo usado por bastantes sistemas en producción.

Ver demos.

Merece la pena descargarlo y echarle un vistazo.

¿Alguien lo ha usado? ¿algún comentario?

Una noticia reciente: Sanjiv Jivan, el creador de GWT-Ext, anuncia SmartGWT, un wrapper GWT para SmartClient.

Paginar datos con una sola query

2008-08-25T21:42:00.003+02:00

Un requisito bastante frecuente es el de realizar una consulta en una base de datos que devuelva sólo los registros correspondientes a una página concreta (para no recibir y almacenar todos los registros, que pueden ser bastantes), a la vez que devuelve también el total de registros existentes en la base de datos.
Habitualmente se recurre a realizar 2 consultas diferentes (con el consiguiente efecto en el rendimiento de la aplicación).
He aquí una forma de resolverlo con una única consulta en Oracle, usando funciones analíticas:

SELECT product_name,
 product_details,
 total_rows
FROM   (
  SELECT product_name,
         product_details,
         total_rows,
         rownum row_counter
  FROM   (
          SELECT product_name,
                 product_details,
                 count(*) OVER () total_rows
          FROM   products
          WHERE product_name like '%Television%'
          ORDER BY product_name
         )
 )
WHERE row_counter between v_start_row and v_end_row;

En SingleQuery.com nos muestran también una forma en que se puede optimizar la consulta cuando la ordenación es por un identificador único numérico.
Además muestran como resolver el caso en que se requiera mantener una misma imagen de los datos aunque se inserten o eliminen registros.

Crea un índice para todas tus foreign keys

2008-08-25T18:16:00.003+02:00

Una query muy útil para comprobar si todas tus foreign keys tienen un índice.
Es para Oracle. Parece ser que MySQL hace esto automáticamente.

SELECT OWNER, TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME
FROM DBA_CONS_COLUMNS c
WHERE position=1 AND
(OWNER, TABLE_NAME, COLUMN_NAME) IN
(SELECT c.OWNER, c.TABLE_NAME,cc.COLUMN_NAME
FROM DBA_CONSTRAINTS c, DBA_CONS_COLUMNS cc
WHERE c.CONSTRAINT_NAME = cc.CONSTRAINT_NAME
AND c.TABLE_NAME = cc.TABLE_NAME
AND c.OWNER = cc.OWNER
AND c.CONSTRAINT_TYPE = 'R'
AND cc.POSITION = 1
AND c.OWNER LIKE UPPER('TEST_USER')
MINUS
SELECT table_owner, table_name, column_name
FROM DBA_IND_COLUMNS
WHERE COLUMN_POSITION = 1
AND TABLE_OWNER LIKE UPPER('TEST_USER')
)
ORDER BY OWNER, TABLE_NAME, CONSTRAINT_NAME;

Tutoriales W3Schools

2008-08-11T10:17:00.004+02:00

W3Shools tiene unos tutoriales bastante interesantes.
Escuetos y sintéticos: para holgazanes.

Sobre HTML: HTML, XHTML, CSS, TCP/IP

Sobre XML: XML, DTD, XML DOM, XSL, XSLT, XSL-FO, XPath, XQuery, XLink, XPointer, Schema, XForms, SOAP, WSDL, RDF, RSS, WAP, Web Services

Sobre scripts en cliente: JavaScript, HTML DOM, DHTML, VBScript, AJAX, E4X, WMLScript

Sobre scripts en servidor: SQL, ASP, ADO, PHP

Sobre .NET: .NET Microsoft, .NET ASP, .NET Mobile

Sobre multimedia: Media, SMIL, SVG, Flash

Incluye además algunas guías de referencia:

¿Conoces algún otro sitio con tutoriales así de sencillos?

Aplicaciones para la gestión de proyectos

2008-08-09T11:03:00.009+02:00

Algunas aplicaciones expuestas en tutorialblog.org:

Basecamp - De 37 signals. Ver precios, entre 24$ y 149$ mes.
Active Collab - Puedes comprar el producto, código fuente incluido, entre 199$ y 399$ (soporte y actualizaciones a parte).
Go Plan - Puedes usarlo a diferentes precios, entre 10$ y 100$ mes, según capacidad de almacenamiento. Tiene una opción gratuita limitada en funcionalidad.
Copper - Se puede comprar (499$ - 2999$) o bien usar las opciones de alojamiento en sus servidores (29$ - 199$ mes). Ver más.
Wrike - Entre 3,99$ y 11,99$ por usuario y mes.
Nozbe - Utiliza el método "Getting Things Done" ("Organízate con Eficacia"). Se puede usar a diferentes precios, según número de usuarios, capacidad y forma de pago.
Redmine - Open source (GPLv2). Realizado en Ruby on Rails. Descargar.
ActionThis - 10$ al mes, grátis para uso personal. Ver más.
Achievo - Open Source. Descargar.
Zoho Projects - Se puede usar gratis para un proyecto o para proyectos open source. Hasta 80$ mes para empresas sin límites de proyectos. Ver más.
Project 2 Manage - Se puede usar gratuitamente.
DevShop - Gratis para un usuario, 24$ por usuario y mes.
Open Workbench - Open source. Para Windows. Descargar.
dot Project - Aplicación PHP open source. Descargar.
Task Juggler - Open source. Principalmente para Linux. Descargar.

Otros:

Project.net. Open source comercial.
Openproj. Alternativa open source a Microsoft Project.