4.29.2010

desafío abredatos: cortesabiertas.org



Sí, participé junto a Félix López, Edu Lanchares y Antonio Garrote tratando de hacer una aplicación para mostrar el pueblo castellano leonés de que se habla en esas flamantes cortes.

Lo que pudimos hacer en 48h para el concurso abredatos: http://cortesabiertas.org/

y la explicación técnica detallada en en blog del sr garrote.

3.28.2010

Osadía

No hay vez que no vea un documental de construcciones u obras de ingeniería que no sienta una profunda envidia. Y siento envidia porque me doy cuenta que comparado con las empresas de software, ellos tienen claras muchas cosas que nosotros no tenemos.

Entre estas cosas hay una cosa que casi me hace llorar, y es que se tiene en cuenta al experto, si tienen que poner una plancha de un puente hay un -señor- ingeniero que es el que tiene los huevos pelados de pasarlas putas poniendo puentes, hay especialistas por cada una de las partes; especialista de hormigón, de neumática... y no se mueve ni un santo dedo si no hay un "ok" de esos expertos.

Otra de las cosas que me gusta es que saben hasta donde pueden llegar con más o menos deriva en el tiempo. Nadie pondría a 3 ingenieros a hacer un viaducto de 200m de altura y 500metros de largo y mucho menos les diría, esto tiene que salir sí o sí.

Sin embargo en el mundo del software, estoy ya acostumbrado a que se planteen objetivos sin sentido, metas a la vuelta de la esquina para algo que queremos denominar producto, planificaciones que no se ajustan en cuanto a personal...

Si algo he aprendido con el desarrollo de agroguía, es que el producto empieza a ser tal cuando tiene cierta madurez, se ha trabajado duro en los detalles. Esos que no se ven cuando se hacen planificaciones a boleo. Y esos detalles no son que la aplicación funcione -eso se da por hecho, que no es poco-, si no que sea simple de usar, que resuelva bien las situaciones inesperadas, que hable el mismo idioma que el usuario (no, no me refiero literalmente) y esos miles de cosas que hacen de una aplicación un producto.

Creo que uno de los grandes problemas del software es que no hay soporte material sobre el que basarse. Sabemos que llevar una piedra de 4toneladas de un sitio a otro no lo podemos hacer si no es con una grúa o un camión, es obvio, es algo palpable, sin embargo algo que no se puede tocar es difícil de cuantificar.

3.21.2010

Como hacer un demonio en python

Siempre llega ese día en el que necesitas tener un demonio funcionando en una máquina. Y cuando llegas ves que necesitas hacer un par de forks, cosas con stdin y stdout... un peñazo, por suerte en python existe una librería llamada python-daemon, aunque no está demasiado bien documentada (hay que bucear un poco en los fuentes), es muy útil para no tener que liarte demasiado para hacer el demonio. Aquí demo un ejemplo de uso de python-daemon con su log y sus redirecciones de los std*.

Para ejecutar el demonio se usa el interfaz típico de start|stop|restart, por ejemplo:
$ python daemon.py start



3.03.2010

Consejos para trabajar con python

Cada lenguaje tiene sus herramientas, su forma de trabajar, sus reglas de estilo, etc... aparte cada uno tenemos nuestros pequeños trucos y reglas para trabajar lo más ordenado posible. Por ello voy a dar una serie de consejos que he ido aprendiendo a medida que he ido programando en python que espero puedan ser de utilidad a otras personas que así lo hagan.

- Sigue las reglas de python. Para conocerlas basta con que ejecutes python -c "import this" en la consola. No son específicas python, creo que sirven para cualquier lenguaje, muy recomendable "lectura".

- Trata de seguir las recomendaciones de la guía de estilo del PEP-008 (Style Guide for Python Code). Los PEP (Python Enhancement Proposals) son documentos que se redactan y siguen cuando se implementa una nueva característica.

- Aprovecha la potencia del lenguaje. Si sabes ruby o similar sabrás de lo que hablo, los que vienen de java, C, C++ están acostumbrados a lenguajes más bien estáticos, se usa poco la metaprogramación. Python tiene cosas muy interesantes, por ejemplo las list comprehesions que agilizan mucho el desarrollo. Siempre con mucho cuidado de no pasarse (la gente de ruby me entenderá). Por ejemplo, la gente que viene de java suele escribir interfaces y luego heredar para a implementación. En python directamente usa duck typing.

- Cuidado con los imports. Salvo que sepas lo que haces trata de no hacer "from module import *". Primero porque si lo haces posiblemente es que no sepas ni lo que quieres usar, segundo porque puede ser una fuente de bugs importante. Es mejor hacer "from module import MyClass, MyClass2". A mi me gusta primero poner los imports de la librería estandard y después lo propios de la aplicación, pero es algo personal.

- Unicode: siempre especifica la codificación del fichero, en el pep-0263 tienes toda la información, pero el resumen es, pon la siguiente cabecera:

#!/usr/bin/python
# -*- coding: -*-

Si no lo haces tarde o temprano tendrás alguna excepción al ejecutar tu código por haber puesto caracteres fuera del ascii. Además, trata de entender como qué es unicode, como se hace para usarlo en python.

- Excepciones. No captures una excepción y no hagas nada. La gente que programa en java lo puede hacer (y de hecho lo hace), pero si eres un hombre de bien haz algo. Captura la excepción que corresponde, esto es, si esperas un socket.error no pongas un except que recoja a troche y moche, solo captura esa excepción.

- Las doctest son una verdadera virguería para documentar a la vez que testear. No en todos los sitios se pueden usar, pero por ejemplo si al comienzo de un módulo pones una explicación usando doctest mejorará bastante, por ejemplo:


"""
Este módulo sirve para sumar 3 números usando la función add3.
Un ejemplo de uso es:
>>> add3(1,2,3)
6
""""
def add3(....


Luego desde la consola puedes hacer:

python -m doctest modulo.py


y ver si algo casca. Más información de doctest y ejemplos. Además luego hay el módulo unittest, hay frameworks para stubs y mocks, helpers para facilitar los test como nose y pytest, todo lo necesario para estar a la última moda del TDD.

- usa la consola. Unas de las cosas más útiles es que tienes la consola siempre a mano para probar cosillas. La mayoría de las veces no me acuerdo como hacer algo, en la consola lo pruebas instantaneamente. Recomiendo usar ipython, que viene ser igual que la consola original python, pero con facilidades para acceder a la documentación, autocompletado, etc.

- Usar pip o easy_install. Es similar a gem en ruby, lo que hace es instalar módulos de terceros desde internet con un solo comando. Esto es fundamental y agiliza el desarrollo muchísimo. Para buscar el software usa Python Package Index donde tú mismo puedes subir tus paquetes. De hecho el paquete de la librería standard para empaquetar módulos lo sube automáticamente con un comando. Prefiero pip a easy_install porque pip está construído con más lógica (tiene uninstall) y más características que cuento dos puntos más abajo.

- Haz pequeños módulos y empaqueta. Empaquetar es súmamente sencillo, con hacer un fichero setup.py con pocos parámetros tienes el empaquetado hecho. Aparte de los benficios que tiene separar las aplicaciones en modulos, tiene otros muy interesantes. El módulo que se usa para estas cosas es distutils, donda hay un ejemplo de setup.py muy sencillo.

- Usa pip. Sí, es repetido, pero pongamos que tienes el caso que has separado tu aplicación en varios módulos que tienes en un repositorio. Desarrollas una aplicación que los necesita, pip te va a ayudar a resolver este problema ya que puede instalar módulos directamente del repositorio (siemre que tengan su setup.py), por ejemplo:


pip install svn+https://mirepo/project/module#egg=module


Todos los paquetes necesarios se pueden poner en un fichero requirements.txt que todas las aplicaciones tengan.

- virtualenv. Herramienta fundamental, permite aislar entornos de ejecución. Puedes crear tantos entornos como quieras, cada uno con una versión de python diferente, cada uno con sus librerías. Esta herramienta es, repito, fundamental. Yo lo uso junto a virtualenvwrapper que simplifica la creación y gestión de entornos. Además junto con pip hacen el combo perfecto. Por ejemplo, para tener un entorno de trabajo funcionando basta con hacer:


pip install -E env -r requirements.txt

pip creará un entorno nuevo, e instalará todo los especificado en el fichero requirements.txt, bajándose lo necesario. Luego basta con activar el entorno y a trabajar:


. ./env/bin/activate


- Aprender a usar el debugger, pdb. Sé que ya no mola hacer debug en la línea de comando, que eclipse te lo da todo mascadito, pero si estás en un servidor remoto es útil cuando solo tienes ssh y vim :).

- Usa el log. Python tiene un módulo llamado logging, úsalo, luego se puede configurar para redireccionar a un fichero, al syslog, a stdout. Tiene las típicas error, info, debug... pero lo importante es que lo uses.

En general, cuando no sé la mejor forma de hacer algo, suelo ir al código de la librería standard y mirar paquetes que suelo usar.

2.23.2010

Pycon 2010 Closing

Echando un ojo a la closing de la pycon de este año leo la siguiente frase:

I've always found a way to use Python as a strategic weapon, a tremendous source of leverage, to make that small group of people much more productive than the big companies that can— through the force of sheer mass— crush you like a bug.

2.11.2010

experimento de promoción


Como algunos sabéis, estamos desarrollando una aplicación para que los agricultores puedan llevar la trazabilidad de sus explotaciones agrícolas. Ya existen aplicaciones que hacen esto, pero son caras, complicadas y hacen demasiadas cosas.

Esta semana se celebra una de las ferias más importantes de agricultura, se celebra cada dos años y reune a una gran cantidad de agricultores. No tenemos stand así que nos hemos hecho unas camisetas con en logo de agrotrack y vamos a ir unos cuantos a ver que se cuece por la feria.

No es algo que creo que tenga repercusión, pero sí puede estar bien como experimento, veremos a ver si tiene impacto en el número de visitas, correos y suscripciones.

Por otro lado vamos avanzado muy rápido con el desarrollo, además tenemos la ventaja de ya tenemos mucho contacto con agricultores y una buena base de datos con los que probar.

1.31.2010

postmorten de NyxQuest

Leía el postmoreten de NyxQuest, que para el que no lo sepa es un videojuego creado por una compañía Española, overthetopgames, con gran éxito internacional en wiiware, y he visto ciertas frases que me han gustado mucho, sobretodo porque encajan bastante con la filosofía de tener recursos acotados para obtener mejores resultados.

Since we didn't have a lot of money to spend, we had to find ways to resolve some problems. Not enough work force for animation? Ask a friend with free time! No budget for voices? Get a voice actress girlfriend with her own studio! No testing department? Friends and family


Since we were a small team and couldn't have a lot of detailed models and textures, we chose a style that focused on lighting and shadows.


At the same time, we were telling the story of a burned and forgotten earth, full of deserts and ruins... this setting was not only chosen because of the story, it helped us to reduce work. Since the game world was ruined and deserted, we could create fewer assets and spend the time on making them stylish.


We decided to partner and fund the game with our own money. In the end this has worked very well, because we managed to do a good looking game in the time we had, and with scarce resources. But it was a very tight development cycle; we barely made it with the money we had saved.


El artículo es altamente recomendable y merece la pena leerlo detenidamente.

1.27.2010

¿ Como programarías si fueses ciego ?

Leo en stackoverflow una pregunta que me ha llamado muchísimo la atención "how can you program if you're blind". Las respuestas de personas ciegas son muy interesantes, sobretodo por ver como se las apañan, como valoran la usabilidad... también hay preguntas un poco estúpidas: "apagas la iluminación de la pantalla del portátil para ahorrar batería?".

Ser ciego seguro que hace mejorar ciertas capacidades; quién no ha tenido que volver al fichero de la clase que estamos usando constantemente a ver el nombre de vaya usted a saber atributo? seguro que ellos retienen toda esa información en la cabeza con más facilidad. Las combinaciones de teclas seguro que son el pan de cada día, el movimiento del cursor seguro es mucho más rápido al no tener que mirar donde está, etc.

También me viene a la cabeza un antiguo compañero de trabajo que era programador y tenía algunos problemas de movilidad. Me quedé muy sorprendido cuando le vi navegar entre carpetas con el explorador de windows. Para él usar el ratón era difícil, sin embargo con combinaciones de teclas se movía a una velocidad asombrosa, mucho más de lo que he visto moverse a personas con sus capacidades motrices perfectas. Él tenía una restricción y ha hecho de ella una ventaja.

Moraleja:

Let limitations guide you to creative solutions

1.24.2010

De pirámides y consultoras

Esta mañana veía uno de esos entretenidos documentales de construcciones, creo que era mega estructuras (o mega-algo) - por cierto, el título original es extreme engineering, imagino que en España algo con la palabra ingeniería de por medio no llamaría -

Explicaban, muy por encima dicho sea de paso, las hipótesis que tenían acerca de como las pirámides habían sido construídas, basándose en las construcciones aledañas a las pirámides, donde se supone que debían acampar los esclavos que las construyeron, en las tumbas que encontraban dentro de las pirámides, etc. Me gustaría destacar dos cosas con las que no pude evitar esbozar un sonrisa pensando en las mega-consultoras donde se hace software a lo bruto, algo parecido a como se hicieron las pirámides.

- Resulta que a tenor de la cantidad de huesos de animales allí encontrados, los esclavos no debían serlo tanto, parecía que estaban bien alimentados, si tenían accidentes les curaban y les mantenían aunque fuese sin, por ejemplo, un brazo. Es curioso como analizando los huesos es posible determinar esas cosas. Además, había grupos de trabajadores especializados...

- Un capataz de la obra, del que encontraron sus restos en un sarcofago dentro de la pirámide, no debía ser ningún mindundi por tanto, tenía los huesos de la columna "aplastados", síntoma de haber cargado con peso durante tiempo.

Conclusiones:

- Los egipcios ya sabían que al empleado había que tratarle bien
- Para saber llevar bien un proyecto tienes que bajar a descargar el camión. En el ámbito metalúrgico lo llaman "mancharse las manos de taladrina"

Igualito igualito que las mega-consultoras "españolas".

12.29.2009

visión comercial del técnico

Cuando te metes en un negocio, por pequeño que sea, te das cuenta de lo importante que es promocionar el producto, saber como y donde vender, posicionarlo adecuadamente, conocer el target... todas esas cosas que fundamentalmente _no_ hacen los técnicos... ¿no?.

A menudo los técnicos somos gente más bien raruna, menos sociables normalmente, que la gente comercial. Ellos son mucho más apuestos, mejor vestidos, más sociables y mejor vistos, normal, son los que hacen ganar el dinero en el fondo o por lo menos son el eslabón final para conseguirlo. Por lo general manejan a la perfección términos técnicos, lo justo para poder explicar a un posible cliente.

Esa ha sido la visión de toda la vida, pero en mi opinión es que es un gran error. Un técnico debe tener una visión comercial mínima, debe saber quienes son los clientes, debe conocerlos, tiene que ir a ferias a ver que se cuece... es posible que no sea el más adecuado para explicarle a un cliente algo, pero debe tener claro a donde va a parar lo que hace, saber los argumentos de venta del comercial, etc, etc.

Estoy harto de escuchar lo de "estáis ahí metidos con vuestras pantallicas y vuestros cacharros", cuando estoy eligiendo una tecnología no estoy pensando en lo guay que es, estoy pensando en, cúanto tiempo va a pasar desde que se plantee un producto hasta que esté vendible, va a dar problemas a los clientes(más soporte técnico), va a ser usable por el cliente, el hardware que requerirá será caro (en ciertos sectores es fundamental), cuanto va a suponer hacer un cambio para un cliente, puedo dar la __calidad__ que se necesita, hay argumentos de venta para la gente comercial...

Si quieres tener un producto de mucha calidad, no solo debes tener a un buen equipo que sepa enseñar esa calidad, si no que debes tener el equipo técnico que sea capaz de ofrecerla. Apple, BMW, El Bulli son ejemplos claros de que es necesaria gente de mucha calidad técnica para tener algo bueno que enseñar y vender.

Así que si quieres/tienes un técnico de calidad, hazle salir, dale libertad para ver cosas, que tenga claro lo que tiene que hacer, que se airee, estar 8 horas delante de un ordenador, a pesar de tener internet, NO es una solución.

12.25.2009

Vende la usabilidad?

El otro día fui a comprar unas cadenas (en realidad de tela) para el coche, llegué al eroski y en la sección de coche había dos marcas de cadenas, juntas, el tamaño de los paquetes que contenían las cadenas eran el mismo, mismos precios prácticamente, solamente había una diferencia, en la etiqueta para buscar el tamaño adecuado para las ruedas de mi coche.

Juzgad vosotros mismos:



Adivinad cual compré.

12.24.2009

Resumen del año, 2009

Primero de todo ver si he cumplido los objetivos que me puse a principio del año: No he cumplido nada, ni he leído más, ni he viajado más ni he aprovechado más las oportunidades.

Ahora, he cumplido varios de mis objetivos del 2008, he mejorado sustancialmente mi inglés (mis 7 horas semanales y levantarme a las 6 y pico de la mañana me cuesta), he aprendido a decir que NO y he mejorado agroguía:).

Los eventos/proyectos más importantes de este año:

- He ganado el premio 3M que un idea de esas felices, agroguía AR y preparamos un hoax que se tragaron casi todas las televisiones a nivel nacional.
- Llegué a la final del art futura con cubyshot
- He mejorado las ventas online de agroguía.
- He publicado artículos en dos o tres revistas referentes a la agricultura. Aunque no lo considero demasiado importante, forma parte de la mierda de la universidad.
- He sido tutor de un proyecto fin de carrera.
- Me he cambiado de trabajo nuevamente (y de ciudad, claro)
- He cambiando, en parte, la forma de desarrollar de la empresa en la que estoy.
- He comenzado un nuevo proyecto empresarial con unos amigos.
- He hecho alguna demo que otra, algún mini-proyecto( cipy, hg-wiki)...


Lo que he aprendido este año:
- He aprendido a decir que NO. Es mucho mejor decir NO que decir que Sí o no decir nada.
- Lo importante de hacerse ver, de la publicidad, de tatuar en el cerebro de los demás algo sobre tí o sobre tu marca. Agroguía ya es una marca XD
- He aprendido donde NO quiero trabajar y con quien NO quiero trabajar.
- He aprendido a cocinar un poco.
- He aprendido algunas cosas sobre tecnología, django, git, hg, javascript, qt... etc, etc.

Y he aprendido muchas más cosas, de esas que aprendes pero que luego no puedes explicar. Creo que las llaman madurez y cuando eres capaz de explicarlas las llaman sabiduría.

12.12.2009

carta desde Pamplona

Ayer hizo 6 meses que estoy en Pamplona y toca echar la vista atrás para hacer análisis y sacar las primeras conclusiones.

Tengo que decir que tomar la decisión de moverte de tu ciudad natal/habitual es algo en lo que vas a jugarte mucho más de lo que crees. Dejar atrás un entorno que conoces a la perfección, tus amigos y familia para meterte en otro lugar desconocido, donde no sabes nada, no conoces a casi nadie es complicado. Ahora, creo que por lo menos una vez en la vida debes hacerlo, yo lo he hecho ya un par de veces y aunque confieso que lo he pasado *muy mal* en algunos momentos, merece la pena.

Lo resumiré en unos pocos puntos:

- Pamplona es una ciudad con mucha calidad de vida. Es pequeña, tiene más o menos todo lo necesario. Para salir de pinchos es ciertamente cara, quedáis avisados. Aquí las cosas son algo diferentes, no saben coger las rotondas (*), la haciendo no es común con el resto de España, la gente tiene acento maño y hay unos policías forales vestidos de rojo poniendo radares por todas partes.

- Vivo en un pequeño pueblo (no creo que llegue a los 50 habitantes), en una casa entre montículos donde puedes respirar aire del fresco. Quedáis invitados, tengo habitaciones de sobra.

- Estoy conociendo a gente muy interesante, de esas con las que te apetece hablar de algo más que del tiempo.

- En el tema laboral he encontrado algo así como una empresa en el paleolítico hablando desde el punto de vista del software, aunque en 6 meses hemos avanzado. Para mi empieza a convertirse en un reto, aunque me preocupa y mucho el prácticamente no haber aprendido nada nuevo de la empresa.


(*) Pido perdón a los Salmantinos, sí, hay alguien peor que vosotros cogiendo rotondas.

11.19.2009

Por qué QT debería ser más popular

Llevo trabajando 6 meses con Qt y me estoy preguntado por qué Qt no es mucho más popular de lo que es. Apenas se ve código, fuera de aplicaciones con interfaz gráfico y zulos de talibanes pro-software libre, hecho con Qt.

Voy a enumerar las cosas por las cuales creo que Qt es una librería de muy buena calidad:

- Completa: tiene api para la mayoría de cosas comunes, no solo hablo de interfaz gráfico, hablo también de manejo de ficheros, threads, procesos... vaya lo típico que puedes necesitar a diario

- Documentación: Buena documentación, todos los métodos comentados adecuadamente, ejemplos de uso, ejemplos, demos. Todo lo necesario para hacer una aplicación lo puedes encontrar en la documentación que instalas al instalar Qt, no tienes apenas que estar mendigando por foros.

Ya solo con estas dos merece la pena ser usada, pero además tiene:

- Sistema de build: autotools y familia son realmente penosas de usar. Qt tiene qmake que permite, de forma sencilla y clara crear los ficheros de build. Es posible que no sea tan completo como autotools, pero es que normalmente es lo que necesitas.

- Integración con Webkit: puedes perfectamente tener todo el interfaz gráfico en html/css/javascript y la parte de controlador y modelo en C++.

- Sistema de script: tiene un sistema de script similar a javascript que se integra a la perfección con la aplicación. Símple de usar, fácil de comunicar (gracias a las signals y slots) e integrado.

- Signals/Slots: esto es una extensión de Qt sobre C++, pero es especialmente interesante. Puedes enlazar señales (por ejemplo un click en un botón), con acciones en otro objecto. Es _extremadamente_ útil cuando tienes una aplicación multithread ya que puedes hacer paso de mensajes usando esta técnica.

- Internacionalización: sí amigos, olvidaos para siempre de "char*". Qt usa QString para todo, lo cual te "fuerza" a olvidarte del ascii y trabajar con unicode. Además tiene herramientas para traducir.

En mi opinión Qt debería ser algo mucho más usado por los programadores C++.

La única pega de Qt es que ahora es propiedad de Nokia y esta está empeñada en hacer que todo vaya en symbian (lo peor que he visto en muchos años), como se puede ver en el anuncio de la rc 4.6.. Espero que Nokia la mantenga por muchos años.

11.18.2009

agroguia, anunciado en TV

Hace cosa de una semana la universidad de Valladolid publicó una nota de prensa acerca del premio de la fundación 3M que ganamos hace meses. Podría comentar lo poco detallista que ha sido la universidad de valladolid conmigo al no darme ni las gracias por hacer un desarrollo para ellos, darles el prestigio de un premio nacional y además un 15% en metálico, pero no lo voy a hacer, no merece la pena.

El caso que con esa nota de prensa, algún periodista ha creado una hoax terrible sobre que teníamos unas gafas de realvidad virtual y muchas televisiones se han interesado por nosotros (TVE, antena3, RTCYL), periódicos y radios (mañana tengo una entrevista con una de colombia).

Hoy hemos salido en el iformativo de TVE de Castilla y León, os dejo el video (el primer que habla soy yo):

11.08.2009

Haz caso a tu instinto

Hay veces que tomas una decisión, de pequeño o gran tamaño, en las que algo en tu interior, no sé qué, te dice si la decisión es buena o es mala, si debes tomar el camino o no.

Creo que unos le llaman instinto, otros corazonada, otros sexto sentido... para más definiciones acerca de esto podeis echar un ojo al siguiente video.

Hace unas semanas un agricultor me llamaba interesado por un GPS para su tractor, le atendimos exactamente igual que a todo el mundo, pero después de 1 minuto de conversación, "algo" me decía que aquello no iba a ir bien. No hice caso, pensé se merecía el mismo trato que el resto a pesar de una apreciación (subjetiva, todo sea dicho), así que hablé con él, le enseñe el equipo y decidió comprarlo. Trató de negociar, pero era una negociación donde solo él ganaba, así que mucho no tenía que negociar. Ahí fue el momento en el que yo ya sabía que esto acabaría mal.

Llego el día de la entrega, le instalamos el equipo y entonces dice que no quiere el equipo por diversas razones a cual más estúpida. Le dije 4 cosas desde el cariño y el sentido común y me fui contento a casa. Contento porque he aprendido el "a mi esto no me vuelve a pasar" y contento por la sutileza con la que le mandé a tomar por culo :).

Conclusión: Haz caso a tu instinto

11.02.2009

agroguía, datos de un pequeño negocio

Nunca he hecho públicos datos de agroguía, pero esta vez voy a comentar un poco los datos de ventas, visitas de la web y otros datos que pueden resultar interesantes. No soy especialmente bueno analizando datos de estadísticas web, no tengo experiencia, así que los análisis son a lo bruto y posiblemente algún argumento sea erroneo.

Hace cosa de un par de meses, cara a afrontar la nueva temporada (para nosotros la temporada empieza en septiembre), decidí darle un cambio a la web de nuestro sistema de guiado GPS para la agricultura, eliminando wordpress como la página inicial, cambiándolo por una página de producto donde se viese claramente el producto, cosas que se pueden hacer con él, un formulario de compra, el precio (que nunca habíamos publicado), etc.

La razón de cambiarla ha sido fundamentalmente una: el feedback del usuario. Cuando llegan muchos correos preguntándote cosas que no tienen demasiado que ver con lo que haces significa que no estás explicando bien lo que la gente quiere saber. También en parte a muchos comentarios que gente que sabe de este tema mucho más que yo, gracias a todos ellos :).

Opté por un diseño a lo 37signals, un titular dejando bien claro para que vale y a continuación otro explicando qué le va a solucionar al agricultor (no sé marketing, pero me suena a algo fundamental que explicar). Luego la típica imagen del producto y el resto de página explicando diferentes utilidades del producto.

Uno de mis principales miedos era el de perder el posicionamiento que había conseguido, no tengo claro como funciona, así que cerré los ojos e hice lo que me salió del cuerpo.


Y ahora los datos, estadísticas de la web en septiembre, según google analytics:
- Visitas (no páginas vistas): 533
- Media de tiempo en la página: 5:51 minutos

Si de las visitas resto los que no han estado en la web ni 10 segundos (por ejemplo gente que llega desde google buscando algo que no va a encontrar), 180 en total, me quedan 353 visitas en la web durante todo el mes. Más del 80% vienen de buscadores, la mayoría google.

Si esto se lo cuentas a alguien se rie de ti, son 11 visitas efectivas al dí­a. Bien veamos datos de ventas.

En septiembre hemos vendido 10 licencias, a 1000euros (+iva) cada una, en total facturado 11600euros, esto es un 2.8% de las visitas han comprado. No sé si es demasiado, para un producto de 1000euros creo que está bien. Recordar que de ahí, hay que restar gastos (hardware, SS, etc) e impuestos (16% iva y 20% del beneficio, del valor añadido vaya).

Conclusiones que saco:
- 11000€/mes para un negocio es realmente poco. Imaginemos que tuviesemos que pagar oficina, gastos y demás. Si quitas impuestos se queda en una verdadera miseria. Ahora, si tenemos en cuenta que somos dos personas, que hemos dedicado, tirando por lo alto, una media hora al dia (15horas/persona-mes) entre preparar envíos, hablar con clientes, responder correos... las cuentas salen un poco mejor. No se trata de ganar mucho, se trata de ganar lo máximo con el mínimo trabajo.
- Al contrario que el año pasado, este año todos los clientes han sido por la web. El año pasado era un hecho aislado cuando alguien compraba por web.
- No hemos hecho nada de publicidad, nada, ni revistas, ni webs, absolutamente nada.
- Mucha gente llega a la web buscando en google agroguia, esto es, ya nos conocen y saben lo que vienen buscando.
- El posicionamiento ha mejorado, a pesar de la maraña de redirecciones que tengo en nginx.
- El tiempo que me deja libre el no tener que mantener agroguía, lo estoy usando para sacar otro producto de trazabilidad para la agricultura (esta vez ya sé algo de css, aunque de diseño mucho no he aprendido, la verdad), para aprovechar los clientes que ya tenemos y meternos en un vacío de aplicaciones decentes.

Como curiosidad, decir que casi tengo más tráfico en el server de ataques a paquetes web PHP que de gente interesada. :).

Estoy realmente contento, no por las ventas, si no porque estamos jústamente donde quería: vendemos a un nivel aceptable, trabajamos no deamsiado, tenemos clientes cada vez más preparados (se nota por la bajada de llamadas de soporte) y encima haciendo lo que nos da la gana.

10.31.2009

Python y miniframeworks web

He empezado a colaborar con web.ontuts, una blog sobre tutoriales de programación web, con un pequeño artículo sobre juno, un pequeño framework web hecho en python muy útil para pequeños servicios.

Aquí está:
mini-aplicaciones web con python y juno

10.25.2009

Lo que debería haber en todas las empresas de software de España

En todas y cada una de las empresas de software de España debería haber un cartel, bien grande, donde todos pudiesen leerlo, con la siguiente frase

"El verdadero progreso es el que pone la tecnología al alcance de todos"


De un tal henry ford.

vía voolive visto en microsiervos.

10.23.2009

integración continua en 100 líneas de código

Actualmente estoy trabajando con un embebido con linux, la potencia de la placa es bastante limitada y a la hora de compilar una aplicación mediana el sistema demasiado. Como tengo varias placas decidí montar un servidor de integración continua en uno de ellos usando compilación distribuída con distcc. La forma de trabajar es la siguiente:

- programo haciendo mis commits en local (usando git)
- cuando necesito probar mi código en el embebido hago "git push ci" de forma que ci es un remote parecido a ssh://user@ciserver/home/ci/project.
- Este repositorio tiene un post-recieve-hook que lanza una petición al servidor de integración continua, este compila (distribuido, con distcc) y si la compilación va bien lanza un "build_pass" que usando rsync hace deploy en la máquina de pruebas.

Parece muy complicado, pero realmente es poca la configuración que se necesita, casi todo va sobre ssh.

Sentía la necesidad imperiosa de tener un servidor de integración continua pequeño y manejable, así que decidí hacer uno :).

Con juno, un miniframework web que permite en dos patadas tener una pequeña aplicación web.

Si quereis probarlo o ver el código, el código está en github: cipy, servidor de integración continua.

Funciona bien, realmente no hace demasiado, pero basta. Solo soporte un proyecto, pero no hay problema para lanzar varias instancias, cada una en un puerto diferente, apuntando ngnix ( o tu servidor web favorito) con un "proxy pass" a cada una con un "location" diferente.

Si realmente quieres un servidor de integración continua potente puedes usar hudson.

Un shot: