Sergio Gago

En áRes:desarrollo estamos cambiando nuestro modelo, de ser una agencia de diseño Web 2.0 a ser asesores de estrategias en la red, pero han sido unos cuantos años que nos han enseñado muchas cosas. Una de las cuales es, cuándo no aceptar un proyecto, aunque estés escaso de clientes. Y es que un mal cliente es mucho peor que no tener clientes.

Sin embargo, Jeffrey Zeldman la ha clavado en su post 20 signs you dont want that web design project.

Parece un post irónico, de coña, pero señores… la cosa va muy en serio. Si tu cliente va por estos lindes, es mejor no aceptarlo!

Voy a traducir algunos de los mejores puntos de la lista:

• El cliente tarda seis meses en responder tus bocetos y propuestas, pero no cambia la fecha final de entrega.
• En la primera reunión del proyecto, después de un análisis previo y de haber viajado bajo tus propios costes, el cliente te dice que no tiene presupuesto, pero que está abierto a hacer un intercambio de servicios.
• El cliente no puede articular un solo objetivo de usuario. Tampoco una estrategia de negocio, una estrategia online, una razón para la mera existencia de su sitio Web un una única métrica para mejorar su Web. Pero a pesar de todo, ha diseñado un increiblemente detallado boceto.
• El cliente te asegura que aunque él, que es un “hombre de visión”, no se involucrará en el diseño de la web, su empleado, el contacto, estará dedicado completamente para aprobar cada entregable.
• En la reunión de entrega, el anteriormente mencionado “hombre de visión”, entrega dibujos de su idea de cómo debería ser la estructura de la Web. Estos dibujos no tienen nada que ver con la investigación que has hecho, con las recomendaciones aprobadas, con los bocetos aprobados o con el diseño final aprobado.. Tampoco con el diseño final de las páginas, ni siquiera con las plantillas HTML que estás integrando en el CMS.
• Justo antes de llegar, la empresa despide a tu cliente. Un asistente sobresaturadose encarga del proyecto. El site nunca llega a nada. Dos años después, una nueva persona al cargo te envía mails para que rediseñes el site.
• El cliente te envía un request for proposals de 40 páginas, incluyendo diagramas de flujo aprobados por el comité hechos en Microsoft Art.
• El cliente te dice que ha realizado un estudio de usabilidad con su mujer.
• Cuando elt rabajo del back-end está a punto de terminar, el cliente se replantea la arquitectura.

Lo peor de todo es que muchas de estas cosas, son completamente impreisibles, y te pueden fastidiar entero. Cuando la empresa cliente es de más de 10 personas, hay que evitar que todo el mundo opine, y que todo el mundo proponga funcionalidades que no estén cerradas. Intentar que el contrato esté bien cerrado y las fechas de pago bien señaladas en el calendario.

En fin, un artículo muy recomendable. Y en breve os mostraremos el nuevo camino que está tomando áRes!

Ojalá hubiera tenido este video cuando empecé a programar en C, años ha.

[youtube]http://es.youtube.com/watch?v=UvoHwFvAvQE[/youtube]

Un puntero (o apuntador) es una variable que referencia una región de memoria; en otras palabras es una variable cuyo valor es una dirección de memoria. Si se tiene una variable ‘ p ‘ de tipo puntero que contiene una dirección de memoria en la que se encuentra almacenado un valor ‘ v ‘ se dice que p apunta a v.

(wikipedia)

Gracias Tomy!

Tutrabajo.org es una Web creada por la Confederación Vallisoletana de Empresarios, hace ya más de cinco años, para fomentar el empleo en Castilla y León, y que tras la celebración del quinto aniversario, inició un proceso de transformación, tanto a nivel de imágen como de usabilidad y accesibilidad.

Han sido unos cuantos meses los que hemos estado en áRes trabajando para este proyecto, junto con la inestimable colaboración del equipo de Miel Works! que han hecho un trabajo excelente. Pero ahora, podemos decir que por fin estamos en la fase final del desarrollo. Aunque ya lleva unas semanas online esta nueva versión, todavía faltan funcionalidades y mejoras que aplicar, y por supuesto, toda sugerencia es buena.

Esta Web, que en ocasiones funciona incluso mejor que infojobs, es un referente en Castilla y León, y sobre todo en Valladolid, dando la posibilidad de encontrar trabajo a miles de usuarios, y de buscar a sus candidatos a los cientos de empresas registradas.

Sin duda hacía falta un cambio radical, no solo de imágen, sino también a nivel de SEO y de usabilidad, tanto la parte pública, como el back office de las empresas. Es un auténtico placer trabajar en plataformas que luego hacen un gran favor a la comunidad.

Estos cambios harán que los usuarios tengan más facilidad para usar el site, así como las empresas, y que la web tenga más tráfico de diversas fuentes, así como una mejora en funcionalidades.

Os dejo un par de capturas para que veáis las diferencias:

Versión antigua

Nueva versión, after aRes.

Muchas gracias a todos los implicados!

A través de un correo de Jordi, llego al blog de desarrolladores de Atlassian, creadores entre otras cosas del sistema de bug tracking JIRA, donde explican su experimento del 20% del tiempo, como ya hizo en su momento Google, y modelo que muchas empresas de nuestro perfil están intentando implementar:

Su aportación es la siguiente:

1. No quieren quedarse simplemente en el modelo de Google, sino ir más allá. Para eso plantean las siguientes propuestas:

• ¿En qué momentos un desarrollador puede usar su tiempo?
• ¿Qué restricciones aplicar sobre qué es lo que se puede y no se puede hacer en ese tiempo?
• ¿Cómo van a manegar sus agendas los jefes de equipo?
• ¿Cómo va a contabilizar su tiempo el ingeniero? ¿Registrará absolutamente todo?
• ¿Cómo paras el proyectod e alquien si se estima como poco útil? ¿Quién hace la estimación? ¿Un comité? ¿Revisión conjunta?
• ¿Cómo evoluciona un proyecto “20% del tiempo” a producción?
• ¿Cómo juzgar el éxito general del programa? ¿Monetariamente? ¿Valor para el cliente? ¿Satisfacción de la plantilla?

La verdad es que son preguntas muy interesantes y que ayudan a estimar el proceso.

Pues lo que han preparado estos señores, no tiene desperdicio: 6 meses y 70 ingenierios dedicando el 20% de su tiempo a proyectos “propios” dentro de la compañía, cuyo coste estiman en 1 millón de dolares (casi nada!).

Lo que harán será lo siguiente:

• Una prueba de 6 meses.
• Con las reglas más sencillas posibles.
• Que cambiarán conforme vayan aprendiendo
• Bloguearán todo el proceso
• Y serán totalmente honestos, para que otros puedan aprender de la experiencia.

Personalmente me encanta el approach que hacen para los ingenieros. Cuando estás en una startup haces de todo: Administrador de sistemas, programador, soporte al cliente, product manager, developer… pero conforme pasa el tiempo y la compañía crece, cada vez se tiene menos tiempo creando las cosas que realmente se quieren crear en el producto, y aquí está la clave.

Finalmente, parece que medirán el éxito en cuanto a funcionalidades y mejoras internas realizadas. Sin duda, merece la pena hacer un seguimiento de cómo les funciona: en el Atlassian Developer Blog.

Una de las ventajas de Barcelona, son las impresionantes posibilidades de hacer networking y ampliar tus conocimientos en práctivamente cualqueir ámbito.

Los que me conocéis, sabéis que soy una especie de mezcla entre programador, project manager y emprendedor, y esto me permite tocar cosas de casi todos los puntos (aunque eso me vuelva loco de vez en cuando!).

El caso es que el otro día fue la primera PHP conference en la ciudad condal, organizada por la gente de phpbarcelona, y aunque no pude asistir personalmente, ya me han puesto al día, y ha sido muy muy interesante. Con ponencias de calidad y un ambiente de colegueo que en ocasiones, se pierde en otras conferencias.

Podéis descargar de su Web todas las presentaciones de la conferencia.
Me quedo con esta de Manuel Aguilar, realmente buena!

Y por cierto, el proximo 7 de marzo organizan la tercera Beers & PHP, espero poder ir por alli!

Bueno, pues por culpa del compañero Francesc, que me ha metido el mono en el cuerpo, voy a empezar a trabajar con Ruby.

He estado investigando un poco, y a estas alturas ya hay una comunidad bastante grande, de forma que resulta fácil encontrar introducciones, manuales y recursos. Aunque yo quería una introducción rápida, que me pusiera en contexto y que me explicara las diferencias esenciales, así como los pros y contras de PHP vs Ruby.

Primero quise ver de qué es capaz el interprete. Esto se lo han montado muy bien con los screencasts y ejemplos que tienen en la web oficial.

Lo más destacado fué el interprete – manual online, que en unos 20 minutos vas siguiendo un paso a paso que te pone en siutación. Ves lo básico del interprete, del lenguaje de objetos y referencias, librerías, etc…

Luego descubrí el famoso manual “Rolling on Ruby on Rails“, y vi que había una magnífica traducción en sobrerailes. En marcha con Ruby 1 y 2. (Ahora que RoR está entre mis intereses, sobrerailes ha pasado a mi lista de feeds).

Y claro, no podía faltar una buena referencia del API de Rails.

Por último, una buena biblioteca. Ya está en el wishlist de amazon, pero mientras tanto, emule los quema para ir abriendo boca:

   

Powered by ScribeFire.

Lista de la compra para tener una productividad explosiva por las mañanas:

• Playlist con AC/DC. Empezando por cosas suaves, como The Jack, o Hell’s Bells, y terminando por todo live special. A ser posible, Bone Scott.
• Desconexión de internet: Si estás conectado te puedes sorprender escribiendo artículos como este en lugar de programando.
• Y por ende, desconexión de mensajería instantánea, msn, skype, avisos del mail…. y por supuesto, lectores de feeds, notificaciones de comentarios, y twitter (el que lo use).
• Intenta evitar contacto con no programadores. Las interrupciones de los comerciales, operaciones, marketing, etc… son mortales y te destrozan el ritmo.
• Una funcionalidad a la vez. Si tienes muchas encima de la mesa, acabas pasando de una a otra sin terminar nada.
• Y sobre todo, olvídate de todo lo demás. Nada de chequear estadísticas, analytics, adsense ni nada que se le parezca. Nada de pensar en negocio. Solo funcionalidad.

Genial artículo en Eioba que resume algunas de las leyes que se suelen aplicar al desarrollo de software, concretamente, leyes epónimas, que viene a decir que su nombre es el de su propio creador o descubridor. Algo bastante común en matemáticas.

Me limitaré simplemente a poner la versión “española” de dichas leyes, ya que se explican por si mismas.

Ley de Postel

Se conservador (cuidadoso) con lo que envías, y liberal en lo que aceptas

Ley de Parkinson

Un trabajo se expande hasta llenar el tiempo disponible para que se termine

Principio de Pareto

Para muchas situaciones, el 80% de las conecuencias viene producido por el 20% de las causas

Revelación de Sturgeon

El noventa porciento de todo es basura

Principio de Peter

En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia

Ley de Hofstadter

Hacer algo te va a llevar más tiempo de lo que piensas, incluso si tienes en cuenta la ley de Hofstadter

Ley de Murphy

Si algo puede ir mal, irá mal

Ley de Brook

Añadir recursos a un proyecto con retraso, hará que tenga más retraso

Ley de Conway

Todo producto de software refleja la estructura organizativa que lo ha producido

Principio de Kerchkhoff

En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información

Ley de Linus

Con los suficientes ojos, todos los errores son obvios

Ley de Reed

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red

Ley de Metcalfe (anterior a Reed)

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red

Ley de Moore

La potencia de los ordenadores se ve duplicada cada 24 meses

y…

El número de transistores en un circuito integrado se duplica aproximadamente cada 18 meses (aunque llegaremos al límite físico, claro…)

Ley de Rock

El coste de los equipos de fabricación de semiconductores se duplica cada cuatro años

Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware

Ley de Zawinski

Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad

Ley de Fitts

Time = a + b log₂ ( D / S + 1 )

El tiempo para llegar a un objetivo (visual) es una función de la distancia a dicho objetivo y su tamaño

Ley de Hicks

El tiempo para tomar una decisión es una función de las distinas elecciones que existen

Time = b log₂(n + 1)

Et voilá!

Rahul Batra escribe en dreamincode un artículo donde expone sus cinco libros para ser ingeniero informático.

Lo interesante, realmente no está en la lista de libros, sino en el concepto de “ingeniero informático”. Y es que hoy en día, cualquiera puede saber programar. La red está plagada de manuales de distintos lenguajes, y de páginas y referencias muy buenas con las que te puedes convertir en un gran gurú del lenguaje. Conocer todos los entresijos y saber resolver cualquier problema. Pero no tendrás esa base de “ingeniero” que te ayuda a resolver los problemas de una forma más organizada.

Me tomo la libertad de copiar su lista, y poner mis propias anotaciones, así como poner las carátulas y unos enlaces a amazon, por si alguien se anima.

Computer Organization by Hamacher, Vranesic & Zaky
Quizá, la base fundamental para todo ingeniero que quiera tratar con computadoras, ya que trata los procesadores RISC desde el principio, llegando a comprender elementos de estabilidad y rendimiento. Que para un “hola mundo” no hacen falta, pero si programas para el S.O. quizá lo necesites.

Concepts of Programming Languages by Robert W. Sebesta
Debemos saber de “dónde venimos” para saber cómo ser los mejores en los lenguajes que salgan ahora. En este libro se atacan los conceptos básicos de la programación, sobre todo funcional.

Operating System Concepts by Silberschatz, Galvin & Gagne
El libro de cabecera de todo técnico de sistemas, y programador que tenga que tocar las tripas del S.O. De hecho, suele utilizarse de pe a pa en casi todas las universidades en la asignatura de sistemas operativos.
Fundamentals of Database Systems by Elmasri & Navathe
A veces, es necesario ir un poco más allá de las formas normales, y conocer a fondo como funciona un DBMS. Y no vale con tener un phpmyadmin atacando un mysql.

Computer Networks by Andrew S. Tanenbaum
Mi favorito. El alma de las redes. Desde las capas OSI, hasta el funcionamiento de cada capa TCPIP. VPNs, tunneling, seguridad, encriptación. Quizá menos necesario para informáticos propiamente dichos, pero imprescindible para trabajar sobre red.

Y por supuesto, a esta lista tengo que añadir dos libros para entrar en materia en cuanto a cómo programar en objetos, y cómo usar patrones de diseño: Head First Java, y Head First Design Patterns. En ningún otro libro he encontrado una explicación mejor del wrapper, o del factory!

Como aclaración, no quiero decir que para ser un buen programador haya que haber estudiado ingeniería informática (la eterna discusión!). De hecho, yo no soy Ing. Informático. Pero el hecho de haber pasado por una serie de materias, y haber tenido que trabajar unos conceptos fundamentales, dan una visión mucho más global, y ayudan a comprender mejor ciertos problemas, así como a generar soluciones más eficaces.

En alemán:

Kernell = núcleo. Así, cobra más sentido la frase Tengo que recompilar el kernell del linux

null = cero. Aunque en la mayoría de los lenguajes de programación, el valor 0 sea distinto de null!