Corregir los estilos de Google maps si se utiliza Bootstrap o Fundation

Hace unos dias me encontraba checando un sitio de un buen amigo utilizando el api de google maps y para generar la maqueta usó Fundation de Zurb, cuando llamó mi atención que al cargar los mapas, la barra de zoom y el icono de street view no se visualizaba de forma correcta.

Esto es provocado porque el css del framework “resetea algunos estilos que usa google maps” propiamente estos:

img { max-width: 100% }

Para corregir esto, basta con agregar a nuestro archivo css las siguientes lineas:

.gm-style img { max-width: none; }
.gm-style label { width: auto; display: inline; }

Con esto el problema se habrá solucionado.

Instalando psycopg2 usando virtualenv en Mac OSX

Intentando instalar psycopg2 para desarrollar una aplicación en Django, utilizando el entorno de Heroku me encontre con el siguiente error:

    Error: pg_config executable not found.
    Please add the directory containing pg_config to the PATH
    or specify the full executable path with the option:
        python setup.py build_ext --pg-config /path/to/pg_config build ...
    or with the pg_config option in 'setup.cfg'.
    Complete output from command python setup.py egg_info:
    running egg_info
creating pip-egg-info/psycopg2.egg-info
writing pip-egg-info/psycopg2.egg-info/PKG-INFO
writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
writing dependency_links to pip-egg-info/psycopg2.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
Error: pg_config executable not found.
Please add the directory containing pg_config to the PATH
or specify the full executable path with the option:
    python setup.py build_ext --pg-config /path/to/pg_config build ...
or with the pg_config option in 'setup.cfg'.
----------------------------------------

Cleaning up…

 El error indica que no encuentra el directorio conteniendo  el archivo pg_config.

Lo solucione agregando el PATH a mi enviroment de mi aplicacion.

export PATH=/Library/PostgreSQL/8.4/bin/:”$PATH”

Ahora probamos:

Successfully installed psycopg2

Cleaning up…

Perfecto! :D

Gobierna mejor quien gobierna menos.

Por cuestiones de salud en los últimos días me he alejado un poco del seguimiento que tenía de algunos proyectos, y debo decir que qué complicado es delegar. Esa parte tan seductora de tener el control. Y en ocasiones resulta muy difícil perder la organización y control de un proyecto para que el equipo sea más independiente. Pero más difícil es pensar que el propio equipo se limita, se detiene, y llega al punto de sentirlo estancado por el mismo control ejercido.

Es obvio que se tienen que delimitar objetivos, seguir una metodología, reunirse y acordar un plan de trabajo y tomar decisiones, pero también muy importante es dejar ser al equipo y sus integrantes, que hagan lo que mejor saben hacer y exploten todo su potencial.

Que será complicado al principio, es probable, que genere confusión y errores, también lo es, como también es posible que no pase nada y el equipo se sienta en confianza, que comiencen a aportar al proyecto y que la fuerza jedi se manifieste y todo fluya. Sea como sea si el resultado no es positivo, también resulta satisfactorio, el equivocarse es parte del aprendizaje como equipo y sirve para adquirir experiencia entre todos.

Al final me quedo con la frase de Lao-Tsé. Gobierna mejor quien gobierna menos.

Es complicado lo se, pero quien sabe, probablemente no estoy dejando ser y si funciona, seremos un mejor equipo de desarrollo.

Propiedad colectiva

Haciendo una reflexión sobre metodologías ágiles y demás, ya sabes de esos días en que no puedes levantarte, y se da por hacerla al filósofo. Y recordando una experiencia personal me vino a la mente una de las características más peculiares que tiene la programación extrema XP, la de la propiedad colectiva del código generado.

Y es que bajo este supuesto, todo el equipo que esté involucrado tiene acceso al código que se está desarrollando, ya sea en un repositorio, el servidor, respaldos o bien vete-tu-a-saber donde guardas lo que estas programando. Y se tiene una propiedad colectiva del mismo, un conjunto de líneas construidas con el esfuerzo de varias personas que dan vida y presentan una solución real a problemas concretos. Vamos, algo casi idílico…

Pero este solo es un supuesto y se lee muy bonito pero en la práctica podría no ser la forma mas romantica de la representación del trabajo en equipo, suele ocurrir en el desarrollador una suerte de complejo de dios, un surgimiento  poderoso del ego, que evitara a toda costa que alguien venga y toque todo lo que con tanto esfuerzo ha construido. Así somos, así seremos si no no seriamos nosotros no?

La finalidad de esta ideología no es más que cualquiera del equipo pueda mejorar una porción del código, y proporciona flexibilidad, disponibilidad y reducción de dependencia. Pero esta claro que que para que este concepto se aplique la palabra mágica en todo esto se llama respeto.

Y es que es muy facil reirse o incluso llevarse las manos al cabeza y maldecir el código y porqué no al generador de ese código al momento de echar un vistazo a alguna función, clase u objeto. Pero probablemente haríamos lo mismo si revisamos código producido por nosotros mismos hace tiempo o porque no, un día antes(….).

La importancia de todo este asunto es que al final de cuentas, todos somos dueños del código, y con todo y fallos de codificación, y nuestra misión es la mejora continua y porqué no ayudar de forma colectiva a la generación de mejor código en equipo. Creceremos como desarrolladores, personas y equipo… Vuelvo a caer a lo idílico… Tengo un problema con eso.

Mi razón de programar.

Hace unos días, mientras esperaba a que diera media noche, cuando todo esta en calma y se respira tranquilidad y paz en el ambiente, estaba listo para comenzar mi jornada en la cual esperaba que algunas cuantas lineas de codigo hicieran productiva mi noche, y de pronto comencé a meditar sobre todo este asunto de la programada y el desarrollo y todo cayó en una pregunta, por que carajos programo? Qué es lo que nos mueve para hacer software…

Que de esto vivo? claramente, pero independientemente de eso, me gusta, amo y disfruto mucho todo el proceso, pelear con tecnologías nuevas, contemplar como poco a poco todo fluye y se va construyendo poco a poco, como si de un edificio se tratase, o bien ver como no funciona nada, y todo se desploma un piso a la vez…

Programo porque hay dias que despiertas y sabes que eres una especie de Neo en la matrix, capaz de encontrar y ver aquello que los demás no ven, y otras en que te arrancas los cabellos y todo el mundo te explica hasta con manzanas y tu no comprendes nada.

Programo porque todos los días hay algo nuevo, una enseñanza, una experiencia, porque de una dia a otro sabes que JSON es la ley, que xQuery no es JQuery, que REST es la panacea y que porqué no, qué podemos jactarnos de usar términos que suenan extraños para el mundo mundial, CRUDS, UI’s, restful, api, push, path y demás lenguaje alienígena.

Programo porque al platicar con colegas es como participar en peleas de gallos, solo que en vez de gallos son egos, una lucha de poder, de conocimiento en la cual gana el que se queda sin argumentos, sin conocer sobre el tema y así sin más de la forma mas etica, noña y cruelmente posible, sales vencedor, sin violencia solo con el código derramado entre las manos.

Programo porque lo disfruto,porque lo aprendo, porque lo comparto, porque lo presumo, amo programar, el saber que esta ahi,  tu le das vida, lo ves crecer y muchas veces lo ves morir… programar escreaciónn pura, es hacer alquimia en tiempos modernos… y como disfruto eso.

“Me gustan las fechas límite. Me encanta el zumbido que producen al pasar de largo”

Douglas Adams

Desarrollo de software y el valor de la gente.

computadoras

En el ámbito del desarrollo de software tal vez un tema que está por demás comentado pero que no por eso deja de tener relevancia sea el papel de las personas y de su impacto brutal que tienen en el software. La gente es la que tiene necesidades, gente que recopila especificaciones y elabora un plan de acción, es gente la que desarrolla, gente que es usuaria del software, gente, gente y más gente. Todos involucrados de una u otra forma en un proyecto.

Y es que en los tiempos donde la alta competitividad nos fuerza a elaborar software con la mayor rapidez, la mejor calidad, la mejor eficiencia, el nacimiento de las metodologías ágiles han venido a alimentar ese monstruo de la “Agilidad”.

Pero si bien es cierto que no es necesario recurrir a innumerables test, pruebas o una prestigiosa empresa consultora, que la misma solución metodológica aplique y funcione para todos los casos que se presenten, porque al final eso solo nos convierte en “cumplidores” de la metodología sea-como-se-llame, y ese esfuerzo solo distrae de las tareas que realmente serían prioritarias, en vez de seguir o usar una metodología paso a paso.

Lo peor que puede pasar es que al no cumplir con los procesos, inmediatamente se piensa en que la metodología no tiene el nivel de detalle adecuado, burocratizando y haciendo cada vez más complicados las tareas.

Hay que entender que una organización quiera conseguir una predecibilidad en los resultados que sea escalable al resto de proyectos de misma: “si aplico esta estrategia probablemente la mayoría de los proyectos conseguirán buenos resultados”, y de ahí la intención de conseguir esa repetibilidad a través de los procesos.

Y es que si continuamos pensando de esta manera solo nos enfocamos en que las técnicas, las prácticas y las metodologías no funcionan y pasan a ser cambiadas como piezas desechables, considerando a las personas como únicamente instrumentos y ejecutores de las tareas y no al revés.

Es cuando nos damos cuenta que el punto central en el desarrollo lo hace la gente. Que si el responsable de cada tarea colabora y propone, que el solicitante tenga claro que quiere y que no, del equipo de desarrollo comprometido en comprender especificaciones, todo esto en un ambiente de interacción y colaboración, en donde las prioridades se pueden cambiar, en donde el espíritu de integración es más fuerte que el de independencia. Y es en ese momento que ninguna metodología, técnica y buena práctica puede superar al esfuerzo en conjunto, que si bien el uso de ellas puede ser un apoyo importantísimo, aun existiendo sin la gente es como una espada muy muy filosa pero al mismo tiempo muy pesada y sin la fuerza necesaria para empuñarla.

El éxito si bien no es 100% asegurado, al menos te da más confianza en alcanzarlo, ese es el truco, la gente aportando su valor al proyecto, porque el software necesita de ese esfuerzo, dedicación, energía por parte de todas las personas que participen en el. No todos funcionamos igual ni seremos igual de efectivos, pero si iniciamos un proyecto con esa idea, podemos sino garantizar que el proyecto llegue a buen puerto, al menos tendremos la certeza que todos nos esforzamos y pusimos una parte de nosotros en el.

"La física es el sistema operativo del Universo"

Steven R Garman

Hasta pronto Steve…

The Crazy one… te extrañaremos.

Foto

Jwerty. Manipula eventos del teclado con javascript

Jwerty es una libreria de javascript, para poder manipular eventos del teclado, para implementarlo en nuestros diferentes sistemas o sitios web. Como caracteristicas encontramos que es muy liviana(1.5kb minimizado) y soporta diferentes tipos de eventos, como “dejar presionado”, orden o combinaciones de teclas.

Su uso e implementacion es sumamente facil, y puede ser utilizada como una libreria independiente o como extension de frameworks como jQuery, Zepto.js y Ender.

Enlace: Jwerty