Responsive Design, el desarrollo de páginas Web plenamente dinámicas que ajusten la visualización y experiencia de usuario a las características diferenciadas y cambiantes de los múltiples dispositivos actuales sobre las que se puede correr un navegador, representa una revolución en la industria.

Pero no solamente para los programadores puros y duros que deben aprender técnicas en HTML5, CSS3 o Java Script con sus decenas de framework asociados, para conseguir que el contenido de un Site se expanda o comprima según el espacio de visualización que ofrezca el soporte físico. Si no que los diseñadores gráficos se enfrentan a un nuevo tipo de reto en donde la interfaz gráfica y sus elementos dejan de ser estáticos y el feel & look del Site también deben adecuarse al tamaño y orientación del lienzo en donde pintar.

Para estos últimos, los diseñadores gráficos y de UIX, quiero compartir una página muy interesante en donde una comunidad propone Webs que funcionan siguiendo los principios de Responsive Design; las valoran entre todos sus miembros; y las publican en orden de puntuación para servir de inspiración a otros profesionales o aficionados del diseño de la experiencia de usuario.

El nombre de la Web, Media Queries, indica el tipo de contenido que nos vamos a encontrar al estar inspirado en la denominación del nuevo estándar descrito en la recomendación del W3C de análogo nombre, y que define las expresiones que permiten comprobar ciertas capacidades de los navegadores en donde se visualiza el contenido.

Así, encontraremos un listado en donde observar una serie de capturas de pantallas de una misma página Web en cuatro resoluciones diferentes, para poder observar cómo se ajusta el interfaz de usuario y el diseño gráfico a las limitaciones de reproducción.

• Smartphone : 320px
• Tablet : 768px
• Netbook : 1024px
• Escritorio : 1600px

Sin duda un buena fuente de inspiración.

Más información | Media Queries

En GenbetaDev | Introducción al Responsive Design (serie)

Lo primero de todo es decir que RIM está haciendo todo lo posible para que BlackBerry 10 llegue a lo más alto, por este motivo ha creado el Port-A-Thon, un hackton casi maratón donde repartirán 2.000.000 de dólares entre los concursantes, el problema es que estamos en el último plazo que fue difundido hace dos días y ¡os podéis registrar hoy! (y ya está).

Facebook también ha abierto el plazo de inscripción para su competición anual, la Hacker Cup, finalizando el plazo de inscripción el 27 de enero y se opta a un premio de 10.000 dólares (el doble que el año anterior) y Google por su parte también tiene abierto el plazo de inscripción para la Google Code Jam, que finalizará su trámite de inscripción a principios de marzo y optaríamos a 15.000 dólares (un tercio más que el año anterior).

RIM – BlackBerry 10 Last Chance Port-A-Thon

Esta competición empieza hoy (viernes 18 de enero a las 6 de la tarde) y termina mañana a última hora (domingo 20 de enero a las 5:59:59, ya que la hora oficial es con el huso horario EST), ha surgido a partir de la gran aceptación que tuvo este mismo evento el fin de semana pasado, donde se consiguieron crear 15.000 aplicaciones para la tienda de BB10.

Para participar en el evento tenemos que registrarnos (a contra reloj), pedir unas firmas para las aplicaciones y tener todo el software a punto (todo disponible dese aquí) y pese a la falta de tiempo, puede que no os preocupe a todos, ya que podéis adaptar de forma express vuestras aplicaciones escritas en HTML5, las creadas para Android, en código nativo C y C++, AIR, Marmalade, Qt y con tecnologías que migran el código HTML5 para que sea una aplicación de cabeza a pies (PhoneGap – Cordova, Sencha…).

La buena noticia es que por cada APP aceptada en la tienda se reciben 100 dólares y si mandas más de 5 APPs optas a bastantes packs de desarrollo de regalo.

Más información | BlackBerry 10 Last Chance Port-A-Thon

Facebook – Hacker Cup

En su edición anterior participaron 8.000 personas de 150 países distintos y el ganador se embolsó 5.000 dólares, era procedente de Rusia (¿quién lo iba a decir?). La forma de competir es simple, se da un problema, un código fuente básico y una salida para comenzar a andar, a partir de ahí tienes 6 minutos para crear una forma distinta o varias.

Os podéis registrar ya (hasta el 27 de este mes) y la ronda preliminar se llevará a cabo entre el 25 de enero y 16 de febrero y la ronda final será el 22 y 23 de marzo, en la sede de Facebook (Menlo Park, en California). Esta es una oportunidad estupenda, además de para los participantes, para Facebook para buscar grandes talentos y para poder innovar en distintos aspectos.

Los requisitos para poder participar son casi los típicos: ser mayor de edad o no vivir en Quebec (o cualquier otro lugar donde no se permita participar en este tipo de eventos).

Más información | Hacker Cup

Google Code Jam

Google Code Jam cumple su décimo aniversario ya y no se conformaban con los 10.000 dólares de las ediciones anteriores y han aumentado la cuantía del premio a 15.000.

Este año ayudarán a llevar a cabo el torneo los ganadores de varios años, para lograr hacer el evento más interesante (si cabe), que tiene un funcionamiento simple, te dan un código pequeño que tienes que resolver rápido y posteriormente otro que puedes resolver con un poco más de tiempo, al ser más complejo.

Podéis registraros ya, también podéis practicar mucho (hay más de 50 días por delante) y están todas los problemas y soluciones de la mayoría de concursantes y concursos, que os servirán de guía.

Más información | Google Code Jam

El termino checklist, se refiere a una lista de acciones o tareas que debemos de asegurar que hemos cumplimentado para dar por buena un trabajo. Es una forma muy sencilla y útil de realizar una serie de operaciones de forma ordenada asegurándonos no olvidarnos de ninguno de los pasos.

Quisiera compartir contigo una pequeña web en donde tenemos acceso a listas de revisión orientadas al desarrollo Web, Web Developer Checklist, que está en plena construcción pero que nos brinda checklist detallados que debiéramos revisar en todo Site que construyamos (y que muchas de ellas no cumplimento nunca).

Por ejemplo, seguir Buenas Prácticas como revisar que no haya enlaces rotos, que funcione el Site en todos los navegadores – o al menos en el que nos indique el cliente -; ortografía del contenido; comprobaciones de SEO – posicionamiento en buscadores –; superar las pruebas de estrés estándar; validar la calidad del código; o revisar los niveles de usabilidad.

Para todas esas validaciones que nos indica los checklist, en cada de los puntos que debemos dar por bueno, podemos acceder al manual, a la herramienta o a la información relacionada con lo que debemos construir y de qué forma, para poder cumplir con los requisitos mínimos que toda aplicación debiera cubrir.

Actualmente están configuradas tres listas: General de HTML, ASP.NET y perfomance. Según indica en la propia página, están en construcción las listas de procedimientos de NodeJS, PHP, Python yRails.

Más información: Web Check List, Repositorio en GitHub

La biología, meteorología, sismología, medicina, psicología… requieren de la informática para tratar esas cantidades ingentes de datos atómicos y convertirlos en información, más o menos estructurada, de la que se pueda inferir un conocimiento, aplicable a dichas ciencias. Y de esa necesidad de tratar con datos surgieron los lenguajes de tratamiento estadístico, como R.

‘S’, el antepasado de R

En 1976, la mayor parte del análisis y computación estadísticos se realizaba por medio de subrutinas en Fortran, algo que era bastante tedioso. Por eso, John Chambers, Rick Becker y Allan Wilks, pertenecientes a Bell Labs, desarrollaron ‘S’ como un conjunto de bibliotecas de macros Fortran, que se convirtieron en su entorno de análisis estadístico interno.

Como eran rutinas de uso exclusivo dentro de Bell Labs, no le buscaron ningún nombre, y aunque barajaron unos cuantos, todos tenían en común lo mismo: la palabra “Statistical”. Como por aquella estaba de moda nombrar a los lenguajes con una única letra (con C como mejor ejemplo), se quedaron con la S inicial, por lo que en 1979 comenzó a conocerse como ‘S’, antes de salir por primera vez de los laboratorios Bell como un producto distribuible.

Nuevo S y S4

En 1988, se reescribió completamente S (la versión 3) en código C, siendo la primera versión parecida a lo que es hoy día. Además, se sustituyeron las macros por funciones y se modificó la sintaxis para hacerla más consistente, aunque también más estricta. También se añadieron las funciones de modelado estadístico, ausentes hasta entonces. John Chambers publicó el libro “Statistical Models in S” para documentar dicho análisis, el cual por su importancia es conocido como el libro blanco.

Diez años más tarde, en 1998 se liberó la cuarta versión, que actualmente es vigente, también denominada S4. Con un conjunto de características orientadas a objetos más avanzadas que las de S3, las clases propias del lenguaje también difieren mucho entre ambas versiones. Chambers también sacó un libro verde para documentar esta versión: “Programming with data”.

Ese mismo año, S ganó el prestigioso premio “Association for Computing Machinery’s Software System Award”, 15 años después que UNIX, 7 después que TCP/IP, 4 antes que Java u 11 años antes que VMWare, por poner ejemplos conocidos por todos.

S-Plus y los cambios de manos

En 1993, Bell Labs vendió a StatSci la licencia para la explotación comercial de S. StatSci se fusionó con MathSoft, para pasar a denominarse Data Analysis Products Division, y sacaron su versión comercial bajo el nombre S-Plus, haciendo referencia a las múltiples características que habían añadido a S (principalmente interfaz gráfica).

8 años más tarde, MathSoft se volvió a separar, rebautizándose como Insightful Corp. En 2004 adquirió la totalidad del lenguaje S y en 2008 fue comprada por Tibco, que es el propietario actual. Sin embargo, tras todos estos cambios de compañía, los fundamentos de S apenas han variado desde 1998, y sólo se han añadido nuevas capacidades.

R, el dialecto libre de S

Mientras S cambiaba de dueño y denominación, Ross Ihaka y Robert Gentleman, decidieron implementar su propio dialecto. Era 1991 cuando estos dos neozelandeses crearon R. Tardaron dos años en anunciarlo públicamente y otros dos años más en licenciarlo bajo GPL. Y posiblemente esta decisión sea la responsable de que a día de hoy R tenga cada vez más repercusión, y sea más fácil encontrar cursos y tutoriales para este lenguaje que para su predecesor.

Entre las ventajas de R, está su gran similitud sintáctica con S-Plus, lo que ha facilitado la migración de muchos usuarios, sus frecuentes versiones (es un lenguaje activo, con más de una liberación anual) y el hecho de que puede ejecutarse sobre cualquier sistema operativo convencional, e incluso en plataformas tan inverosímiles como puede ser una PlayStation 3.

Pero también tiene pegas: muy poco soporte para gráficos dinámicos o en 3D, funcionalidad basada en la demanda expresa de los consumidores (si necesitas algo, hazlo tú mismo o paga para que te lo hagan) y obligación de que todos los objetos se guarden en memoria física, con el problema que esto puede suponer a la hora de intentar cargar objetos de gran tamaño (aunque se están produciendo avances en este aspecto).

Resumiendo: R no es un lenguaje ideal para todas las situaciones, pero sin duda es uno de los más útiles a la hora de estructurar y manipular datos, especialmente grandes colecciones de ellos.

Y para que no todo sea historia y podáis ver un poco de código antes del próximo artículo de esta serie introductoria, os dejo con un hola mundo personalizado en R.

> print("Hola, Genbeta Dev")      # Hola mundo para nuestros lectores
[1]  "Hola, Genbeta Dev"

Página oficial | The R Project for Statistical Computing

Es el caso de HTML5 Boilerplate, que para su versión 5.0 propone retirar completamente el uso de clases condicionales para las versiones 6 y 7 del navegador de Microsoft. Su decisión, más allá del posible gusto de los committers por el trabajo sencillo, está basada en argumentos razonados de entre los que destaca el hecho de que Microsoft anunciase que Internet Explorer 10 no soportará comentarios condicionales.

Esto significa que habrá que adaptarse a los navegadores modernos y olvidar la poco ortodoxa detección del navegador (que se puede basar en prejuicios o gustos personales de quien desarrolla) y empezar a utilizar la detección de capacidades, que es lo que realmente importa a la hora de usar una u otra feature.

Para quien no los haya usado nunca, comentar que los comentarios condicionales son una estrategia utilizada por las distintas versiones de Internet Explorer para ofrecer código que sólo será interpretado por alguna versión. Dichos condicionales van incluidos dentro de comentarios HTML aparentemente normales, por lo que son completamente ignorados por cualquier otro navegador. Un ejemplo habitual de su uso es el siguiente, en el que se incluye una librería javascript que suple algunas de las funcionalidades carentes en la versión antigua.

<!—[if lt IE 7]>
<script src=“http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE7.js”></script>
<![endif]—>

Otro motivo para desechar la detección del navegador son los modos de compatibilidad de Internet Explorer, que hacen que por ejemplo su versión 9 se pueda comportar como tal, reconociendo los elementos de audio de HTML5, o pueda comportarse como IE5, renderizándolos como un elemento cualquiera. En ese caso, aunque el navegador real sea el mismo, es mejor preguntar directamente si existe la capacidad de reproducir ese audio:

function supportsAudio() 
{
   var o = document.createElement( 'audio' );
   return ( o.canPlay ); 
}

Si todos los desarrolladores web empezásemos a pensar de esta manera, podría suponer un nuevo avance para la guerra de navegadores, ya que dejaríamos de lado nuestras preferencias por uno u otro para centrarnos en nuestro problema: que la página haga lo que tiene que hacer. Y se agradece que desde plataformas de moda como Bootstrap o Boilerplate, se tomen iniciativas que intenten facilitar al desarrollador esta forma de trabajar.

Lista oficial de HTML5 Boilerplate | Remove IE conditional classes
Microsoft MSDN | About conditional comments
En Genbeta Dev | ie7.js y HTML5 BoilerPlate 4.0.0

Por eso conviene comprobar que hemos seguido todos los pasos de esta infografía que nos trae Blue Caribu, ya que aunque algunos pudieran resultar obvios, a menudo son olvidados. Desde la buena elección del nombre, icono, descripción y capturas de la aplicación, hasta la publicidad en medios y buscadores, pasando por la interacción del usuario, invitándole a valorar y compartir su opinión sobre tu aplicación.

Vía | Blue Caribu – Guía de Marketing para Aplicaciones

• Si un cambio hace que fallen programas de usuario, es un bug del kernel y nunca se echa la culpa a los programas. Linus lo denomina la “primera regla de mantenimiento del kernel”.
• Nunca se debe quebrar el espacio de usuario. Y particularmente, menos todavía para introducir mierda (perdón, cualquier otra traducción para crap sería un eufemismo).
• Y lo más importante: si no cumples las dos reglas anteriores, por lo menos procura haber usado correctamente las constantes y valores de retorno, ya que si no Linus puede hacer escarnio público de ti.

Como imaginaréis, eso es precisamente lo que hizo mal Mauro, usando la constante ENOENT (fichero o directorio no existente) como respuesta a una operación con drivers cuyos ficheros ya han sido abiertos correctamente. Eso, y culpar a las aplicaciones pulseaudio y tumbleweed de un error que probablemente había introducido él. De ahí el cabreo del dictador benevolente.

¿Quién dijo que en el Software Libre no había jefes y el trabajo es más agradable? Os aconsejo que leáis el mensaje completo para juzgar a qué hay que atenerse si tus aportaciones a Linux no cumplen los requisitos de calidad.

Mensaje original | gmane.linux.kernel

Durante una auditoría de seguridad, es frecuente encontrarse con formularios web de acceso que no incorporan un sistema de ‘captchas’ para evitar los ataques por fuerza bruta.

Ejemplos de esta clase de formularios es fácil encontrarlos en todo tipo de organizaciones, grandes y pequeñas, y pueden ser un importante vector de riesgo si un atacante, armado con un buen diccionario, intenta averiguar credenciales de acceso.

Para hacerlo aun más ‘divertido’ existen herramientas que permiten crear un diccionario en base al contenido de una web. Extraen todas las palabras, y con ello generan un diccionario de términos relacionados con la organización. En muchos casos el ratio de éxito con esos diccionarios es asombrosamente alto. Un ejemplo de este tipo de herramientas es WLAuthor o CeWL

Hoy voy a explicar cómo implementar un ataque a esos formularios de una forma artesanal, paso a paso y construyendo nuestro propio código para explotar la vulnerabilidad.

Ejemplo práctico de un ataque a un formulario

Tomemos como ejemplo este formulario web que lleva asociado un fichero .php que procesa las peticiones de login. El ejemplo es MUY sencillo, el script en php tan solo comprueba contra un usuario / contraseña predefinido en el código. Claramente, en un escenario real, realizaría esta comprobación contra un backend SQL. No obstante, la técnica que voy a explicar es plenamente válida tanto en este escenario como en otros más complejos.

Si colgamos estos ficheros en un servidor y accedemos a index.html nos encontramos con lo siguiente:

El formulario nos pide un usuario y una contraseña. Si probamos uno cualquiera, nos encontramos con lo siguiente:

Un mensaje de error diciendo ‘Acceso denegado’

El siguiente paso es averiguar que ha pasado y como hemos llegado a ese mensaje de error. Hay que analizar exactamente como se construye esa petición. Para ello podemos hacer uso de una extensión para Firefox llamada Tamper Data que, entre otras cosas, permite ver las peticiones del navegador en crudo.

Si lanzamos ‘Tamper Data’ y repetimos la petición podemos ver lo siguiente:

Ahí tenemos exactamente los datos de la petición que genera el formulario web. Es una petición de tipo POST con los valores :

username
password
Submit

De lo que se infiere que realmente los dos parámetros que tenemos que adivinar son username y password.

Para ello vamos a crearnos nuestro propio script para lanzar un ataque de fuerza bruta contra ese formulario. Usaremos como lenguaje de programación Perl, dado que es un lenguaje flexible y muy rico en módulos que simplifican las tareas a la mínima expresión. Además, todo lo que vamos a desarrollar va a funcionar tanto en Windows como en Linux

El último dato necesario para poder construir nuestro script es hacer ‘fingerprinting‘ de los mensajes de la aplicación, lo que buscamos es un patrón fijo que indique error para poder buscar justamente lo contrario: la ausencia de ese mensaje, que será señal de que hemos acertado en nuestras pruebas.
Si analizamos la respuesta con Tamper Data (botón derecho —> ver fuente):

Vemos la respuesta HTTP del servidor en caso de un intento fallido. Con esa información es más que suficiente para programar el script

El script funciona de la siguiente manera:

1. Carga los módulos necesarios para lanzar peticiones http
2. Abre un fichero llamado diccionario.txt que empleará para el ataque de fuerza bruta (podéis obtener diccionarios para pruebas desde PacketStorm http://packetstormsecurity.org/Crackers/wordlists/ )
3. Con una función de tipo ‘foreach’ (función de bucle ultra-optimizada) recorre el diccionario y va construyendo pares usuario / contraseña
4. Lanza la petición http de tipo POST contra el servidor por cada par usuario / contraseña
5. ‘Parsea’ la respuesta en busca del patrón ‘MUY mal’
6. Si no encuentra ese texto en la respuesta, asume que ha encontrado el usuario / contraseña y lo muestra

Podemos verlo en acción:

$ perl brutter.pl http://127.0.0.1/test/login.php 

Más información | Tamper Data

La raíz del problema está bastante clara y es conocida en nuestro mundillo: a día de hoy, sigue siendo muy difícil hacer ver a los clientes el valor de nuestro trabajo. Nuestra profesión está muy infravalorada y nos encontramos con muchos clientes que piensan que programar una web es poner cuatro botones y que diseñarla artísticamente es hacer tres garabatos. Así, cuando llega el momento de la entrega y pasamos la factura, nos podemos encontrar con la desagradable sorpresa de que el clienta no se crea nuestros precios y decida no pagarnos.

Ante una situación así, ¿qué podemos hacer para cobrar lo que nos corresponde? ¿Cómo podríamos haber evitado llegar hasta aquí?

El dilema moral

Hacer un defacement es una decisión que no debería tomarse a la ligera. Sí, vale que tenemos la mala costumbre de querer comer a diario, pero antes de elegir ese método para reclamar tu dinero debes recordar el sabio dicho que aconsejaba:

No tomes decisiones estando enfadado, ni hagas promesas estando contento.

En el caso de una pequeña o mediana empresa es bastante probable que haya recaído sobre ti toda la responsabilidad tecnológica, desde el alquiler del hosting y el dominio, hasta la programación y diseño de la web. Es probable que tú tengas todas las claves del ftp, e incluso que seas el único que las conoce, pero tener ese poder no te da derecho a modificarlo a tu gusto. Por eso lo llaman ser el responsable del apartado tecnológico.

Al cambiar la web de tu cliente para mostrar tu reclamación en lugar de su producto, te estás rebajando al nivel de un cracker o de un chantajista. Pero es más, aparte de tu dilema ético está el hecho de que darías al cliente la potestad de denunciarte por diversas faltas o delitos, desde el incumplimiento de contrato hasta la difamación y otros delitos contra el honor.

Por otra parte, no hace falta tener acceso a las claves del dominio de la propia web para crearle una campaña en contra. Ahora son muchos los que se dedican a crear cuentas específicas de Twitter o páginas de empresa en Facebook con el nombre de la empresa morosa pero con contenidos que denuncian dicho impago. Una táctica similar fue usada por la “Plataforma per la llengua” para exigir el uso del catalán a varias marcas conocidas, registrando un dominio .cat por cada una de ellas y denunciando sus prácticas, aunque se ofrecían a ceder dichos dominios a las marcas de marras.

Aunque la estrategia dio algunos de sus frutos y las marcas adoptaron el dominio .cat, buena parte de la opinión pública lo vio como una extorsión a las multinacionales. Polémicas aparte, es precisamente con estas grandes empresas, tan preocupadas por su imagen pública, cuando más fácil es que funcione la táctica de la publicidad negativa, mientras que a una pyme puede afectarle mucho menos lo que se diga de ella.

Reputación vs cobro

Pero no todo queda ahí. Independientemente de cómo acabe la situación con el cliente con el que tienes la disputa, el deface puede convertirse en tu peor tarjeta de presentación. El mundo de la informática, y especialmente en algunos sectores concretos, es bastante endogámico, y tus posibles futuros clientes podrían tener conocimiento de las malas artes con las que has reclamado el cobro.

¿Qué opinión se puede hacer de ti un cliente que buscando tu portfolio se encuentra una página de denuncia que deja en mal lugar al cliente o anunciante? Ten en cuenta que este futuro cliente no sabrá si eres tú quien llevaba la razón contra tu no pagador, y es probable que se posicione junto al otro cliente y te vea como alguien con exigencias económicas muy altas o poco sentido de la ética profesional.

Salvo que la mordida por este proyecto sea muy importante en lo económico, es importante que sopeses cuánto podrías ganar si consigues que finalmente te pague, y cuánto puedes llegar a perder en proyectos futuros no concedidos por culpa de una reputación beligerante.

Cómo evitar llegar a este punto

En un mundo utópico tú sabrías reconocer todas las necesidades de un cliente, él sabría reconocer tu trabajo y ambos llegaríais a un acuerdo sobre el precio más justo para ese trabajo, tú entregarías la web con toda la funcionalidad en el plazo acordado y por último él te pagaría lo pactado. Demasiado utópico todo, ¿verdad?

En primer lugar, hagamos un poco de introspección. ¿Hemos cubierto las necesidades planteadas por el cliente? Si es así, ¿queda patente que están cubiertas? Si queremos hacer valer nuestro trabajo, lo primero que tenemos que conseguir es que quede constancia de que con nuestro desarrollo se van a satisfacer las necesidades por las que se nos llamó en un primer momento. Si la web no cumple alguno de los requisitos descritos, o la operatividad es tan compleja que no se ve de forma sencilla que la funcionalidad está realmente ahí, el cliente pensará que no hemos hecho el trabajo para el que nos contrató.

En segundo lugar, hay que acordar un precio que sea justo tanto para ti como para el cliente. Aquí no existe ninguna panacea, pero sí que puedes usar herramientas como la aplicación CuantoCobrar para que te sirva de guía para no inflar demasiado tus precios, al tiempo que le puedes mostrar al cliente unos baremos aproximados de cómo está el mercado y de los distintos costes en los que incurres, que van mucho más allá del teclear un poco y dibujar unos trazos.

Si hasta aquí ha ido todo bien y has conseguido involucrar al cliente en tu trabajo hasta el punto de reconocer su valor, ahora es toda tu responsabilidad el seguir con el plan trazado y entregar toda la funcionalidad en plazo. Desgraciadamente, los imprevistos son inevitables y siempre puede haber algo que lo impida, pero si has sabido demostrar tu implicación en el proyecto es menos probable que el cliente se aferre a la excusa de los plazos para incumplir su deber de pago.

No obstante, en esta vida hay mucho caradura y aunque hagas todo bien puede dejar de pagarte alegando fallos que no son tales o falta de liquidez debido a sus proveedores, etc. Puede que incluso se apodere de tus diseños sin haber pagado por ellos y los utilice en la rotulación de su establecimiento, coches de empresa, branding, etc. Ahí, inevitablemente, te ves en la misma situación que el compositor cuya obra han plagiado o el panadero al que le han robado su pan. No es plato de buen gusto, pero en esa situación debes denunciar y esperar que la justicia te conceda lo que es tuyo.

No obstante, si durante la fase de desarrollo (especialmente si te acercas al final y ya has invertido mucho tiempo y esfuerzo) sospechas que tu cliente pueda ser uno de esos caraduras, puedes intentar forzar una renegociación de las condiciones de pago y sólo activar ciertas funcionalidades conforme te vaya pagando la parte proporcional de las mismas.

Puestos a meter una bomba lógica dentro del programa, mejor que sea para activar funciones en el momento en el que cobres, que para desactivarlas si la otra parte incumple el trato. Si entregas una maqueta consistente, aunque sin funcionamiento real, será más fácil convencer al cliente de que si cumple con su obligación, activarás los datos y procesos reales.

En Tecnología Pyme | Si contratas a un profesional para diseñar tu web, deja que haga su trabajo
En Genbeta Dev | Los límites de la ética del programador mercenario, Autoempleo no es prostitución
Imagen de danone.cat | Plataforma per la llengua

Hoy se ha lanzado la versión once del navegador de Mozilla. Lo más sorprendente de esta nueva versión es sin duda el inspector DOM 3D que incluye como parte de su toolset de desarrollo web.

El nuevo inspector está basado en el addon Tilt con el que se pueden navegar las páginas en 3D. Esta nueva versión incluye ademas un editor de CSS en vivo.

También se han mejorado otros aspectos de las herramientas para desarrolladores para reducir así la dependencia de los usuarios de Firefox del plugin Firebug.

Otros aspectos como mejora en el consumo de la memoria, animaciones 3D con CSS y mejora del rendimiento quedan, me temo, completamente eclipsadas por lo awesome del inspector DOM 3D.

Aunque Mozilla ha mejorado mucho en éste último año su navegador, sigue siendo bastante más lento que su competidor directo Chrome de Google, eso si, las nuevas herramientas para desarrolladores son ya todo un referente.

Sitio Web | Mozilla.org
Más en Genbeta Dev | Mozilla Firefox 10 con nuevas herramientas para desarrolaldores