The thing is that we switched to Mercurial and CodeBaseHq.com instead of Git and Github.com and are quite happy with the change.

Stuff they send to customers (manuals and more)

CodeBase surprised me when I got a letter from the UK the day after making the payment. They send a manual and some other stuff that you can see in the picture, to every customer, no matter what kind of customer you are. The letter took just one single day to arrive from UK to Canary Islands, which is a record. The tools provided by CodeBase in the website are great, even better than Github.com

Now, regarding Mercurial, I believe it is what we were looking for. The concepts are pretty much the same than apply to Git, so the learning curve has been shorter because we already knew basic things. However, I'd say it is more user friendly. From the very moment you clone a repository from the main repo (CodeBase for us), everything gets configured, you can start working without telling Mercurial where do you want to push or pull, nor managing any configuration file. Straightforward. Every repository keeps its own revisions count. So commits are identified by a hash, but they got also a revision number that humans understand better. I like that because we don't have many branches, we work mainly against the central repository.
Merges and conflicts are easy to work around. We haven't had to deal with any weird issue. The "incoming" and "outgoing" feature is very nice, together with the fact that the working directory doesn't change when you bring changes from other repo, till you decide you want it to be updated. Cloning local repos is fast, so you can clone when "incoming" reveals big changes or merge goes crazy and can step back quickly recovering your local changes.
Regarding the log, you get the sample problem than with Git, merges are difficult to read in the log. However, the "hg pull --rebase" make it work as SVN, merge does not appear in the log, so it keeps clean and readable. We know now that Git has also a rebase command, but we fond it naturally in Mercurial documentation and not in Git. Yeah, that is probably our fault, but the fact is that we found a solution sooner.

So far so good with Mercurial. It is very similar to Git, but those small things that annoy me, are easy and natural in Mercurial. Documentation is better in my opinion.

However, none of my applications are so simple. They go beyond CRUD. They got business logic which I need to test drive.

The big mistake in my opinion is to clutter the controller with the business logic. In the development of MavenCharts.com, we never have business logic within a controller. The mission of the controller, is to get the input from the user, call the application core, get the response, render a view and send it back to the user. The controller should not even manage entities (models if you want). It just gets inputs and send outputs.

Web MVC and TDD

If you test drive your code, you manage the dependencies using injection. Creating a business class might not be easy. For that reason we use factories. The factory might use an IoC container in order to get instances. In the case of languages like Python or Ruby, I believe that IoC container is not necessary, so we just use static factory methods (functions defined in the global namespace of a module).

The code of an action in the controller should be something as simple as this:

 
@render_error_if_method_is_not("POST")
@login_required()
def save_new_profession(request):
    logging.info(str(request))
    profs = request.POST.getlist(dom_constants.PROFESSION)
    info = __get_basic_info(request)
    user = info['user']
    factory.get_user_updater().add_professions(
                                    user, profs)
    return HttpResponseRedirect(reverse(my_professions))
 

The "add_professions" method is implemented regardless the MVC framework. It can run in the console. We test drive it with the xUnit framework as easy as always.
The common mistake people make is to implement that method in the controller itself, making it hard to reuse, develop and test.

The controller might still contain defects. For that reason we write one test for every action (controller method), using WebDriver. But we don't test all the cases through the controller, just one case. Other cases were designed with TDD even before writing the controller.

MVC frameworks are great but they are dangerous when we want them to solve all our problems. Their mission is to help with plumbing, help avoid writing same tools once again.

For those starting with Django, it is worth noting that names are confusing. They call Views what should be named Controllers, and they call Templates, what really are Views. Eventually, they call Models, what should be entities, but that is something everybody does.

What we have realized today is that, default values for optional arguments might share its state among multiple calls. You might have a Borg pattern where you don't want it, and that is dangerous:

 
def my_func_with_optional_list(arg1, arg2=[]):
    arg2.append(arg1)
    return arg2
 
def my_func_with_optional_dict(arg1, arg2={}):
    arg2[arg1] = arg1
    return arg2
 
if __name__ == '__main__':
   print my_func_with_optional_list(1)
   print my_func_with_optional_list(1)
   print my_func_with_optional_dict('carlos')
   print my_func_with_optional_dict('oscar')
 

Can you see anything that could keep the state between calls? I can't, however, this is the output:

 
[1]
[1, 1]
{'carlos': 'carlos'}
{'oscar': 'oscar', 'carlos': 'carlos'}
 

What happen? My understanding is that, because the list and dictionary objects are mutable and they are defined along with the function itself, python creates them in the global namespace.

We are now reviewing again every function we've written searching for this pattern.

Los sistema de control de versiones de dos niveles, tambien llamados distribuidos, tienen la ventaja de que el desarrollador cuanta con un repositorio completo en su propia máquina y puede tomar instantáneas del código en cualquier momento (commits), sin que eso afecte necesariamente a los builds. Esto es estupendo, ya que uno tiene la libertad de guardar el estado de su codigo cada vez que lo necesita sin que afecte al resto del equipo. Llegado el momento de integrar el código con el resto de compañeros, se realiza la mezcla.

Nos decidimos por Git, gracias a Github.com, que ofrece hosting de pago para proyectos cerrados. Para mí era cómodo porque se hacen cargo de copias de seguridad y disponibilidad, ademas de una agradable interfaz web.
Sin embargo, Git ha sido un dolor desde que lo empezamos a usar.

La documentación se limita a páginas tipo man de unix. Las páginas man son la documentación más inútil que conozco. Tienes la información de todos los flags de cada cosa pero no hay un maldito ejemplo. Ni siquiera está explicado el caso más sencillo y típico que uno quiere hacer.
En Github.com hay algo de info para casos sencillos, pero muy poca info sobre cómo resolver conflictos, hacer branches y cosas asi.

La sintaxis es totalmente inhumana, imposible de recordar para mí.

En la mayoría de los casos, la gente quiere integrar el código de todo el mundo en un punto central, en el servidor de integración contínua. Eso de que cada uno tenga su rama y sea dueño de su repositorio, estará bien en un proyecto como Linux, pero en mis proyectos queremos integrar contínuamente. Git por defecto no está preparado para esta configuracion. Para usar Github.com como repo central, tuvimos que buscar por internet cómo crear el fichero de configuracion. Su contenido es este:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:carlosble/repo
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[gui]
wmstate = normal
geometry = 1024x651+0+56 207 294
[remote "carlos_1"]
url = git@github.com:carlosble/repo.git
fetch = +refs/heads/*:refs/remotes/carlos_1/*


Por más que lo leo no lo entiendo. Lo de "origin" y "remote" nunca lo he terminado de entender. Es más fácil entender un código perl ofuscado.

Bueno, una vez tuvimos este fichero, trabajar como si usaramos SVN, parecía fácil. Haces commit cuando quieres una instantánea y luego cuando quieres subir codigo haces "git pull" (svn update) y "git push) (svn commit). Te descargas el código del repo central y si no hay conflictos, subes el tuyo. Parece fácil, parece de puta madre.
El problema lo tienes cuando hay conflictos.
Si al hacer "git pull" hay un conflicto, el código del repo central no se termina de descargar en tu máquina. Se queda cortado a la mitad, o algo asi entiendo. Tienes que resolver el conflicto, hacer commit y volver a intentar terminar de mezclar el código del repo. En ese punto, Git cree que los ficheros que todavia no ha mezclado son cambios que tú has hecho, aun cuando no es asi. Al intentar resolver y concluir la mezcla te pueden ocurrir cosas rocambolescas como que de repente te situas en "ningun branch" (no-branch) y entonces haces commit pero ya no lo haces en el master (head). Dependiendo de la complejidad de la mezcla, puede ser un infierno que finalmente llegues a subir tus cambios al repo central.
En estos casos nos ha ocurrido que tras subir los cambios, vemos que algunos cambios que había subido otro compañero antes, se han perdido, porque Git entendió que tu versión, es más nueva, aun cuando tú no has tocado esos ficheros.
El problema basicamente es que Git intenta hacer automerge y no solo se arma lío cuando dos personas tocan el mismo fichero, sino cuando uno subió un nuevo fichero que el otro no tiene.
El resultado es que despues de cada mezcla que resulta conflictiva, tenemos que revisar todo el equipo, que ningun cambio ha sido sobreescrito y descartado.
Cuando no sabíamos que esto ocurría, nos llegó a pasar que incluso un bug corregido, volvío a estar en producción.
Incluso cuando no hay conflictos, te acojonas con los automerges que hace el tipo.

Por supuesto, interpretar el log de Git es tambien un puzzle. Cuando haces push despues de un merge, Git dice que tú eres el autor de cambios que hizo un compañero tuyo. Así que miras el log de un commit concreto y realmente no sabes quién es el autor de los cambios. Git te los atribuye a tí. Asi que intentar conocer el historial del proyecto por el log de Git, es imposible. Todo lo que te queda es marcar con tags las releases que van a producción para poder bajartelas en algun momento concreto.

Ahora veámos cómo es la sintaxis para crear un branch y ponerlo tambien en el repo central, Github:


git branch bname # create the branch
git checkout bname # switch to the branch
git remote add bname_1 git@github.com:carlosble/repo.git # create a remote "folder" remotely
git fetch bname_1 # initialized the remofe "folder" locally
git push bname_1 bname:refs/heads/bname # initialize the remote "folder" remotely
git config branch.bname.remote bname_1 # add lines to .config file
git config branch.bname.merge refs/heads/bname # add lines to .config file


Los comentarios no son necesariamente ciertos, son lo que yo he interpretado que estaba haciendo. De nuevo la sintaxis es absolutamente disparatada. No la voy a recordar en la vida.

Pensaba que al crear el branch, metería el código de mi máquina en él y lo subiría a github. Sin embargo, lo que hace es subir el último código que me bajé y no añade los últimos cambios que acabo de hacer. No he conseguido averiguar cómo poner los ultimos cambios que tengo, y que los suba otra persona.
Para bajar el código de mi branch, otro compañero tardó media hora en averiguarlo.

En cuanto a hacer mezclas entre compañeros sin pasar por el repo central, tampoco lo hemos conseguido hacer. Estuvimos media hora intentandolo con git-daemon, es decir, levantando un demonio en un puerto para que la otra persona se trajese los cambios de uno y finalmente lo dejamos por imposible. La página man de git-daemon tiene 0 ejemplos de cómo hacer al menos el caso más normal.

Git será superpotente, pero es un infierno. Para un proyecto donde queremos integrar contínuamente, no nos sirve. No puede ser que cada vez que mezclamos tengamos que encender una vela.

Lógicamente si conociera Git tanto como quienes lo han parido, no tendría estos problemas, pero es que a mi me da igual cómo está implementado Git. Quiero una herramienta que incremente mi productividad, no que me obligue a hacer horas extras para aprender cómo pensó el desgraciado que ideó su maldita sintaxis.
A estas alturas y después de años usando Subversion, no puede ser que la curva de aprendizaje de un control de versiones sea tan fuerte. Es inaceptable.
Si por la naturaleza del kernel linux, necesitan una cosa tan compleja, me parece estupendo, pero nuestros proyectos no son precisamente el kernel linux.

Estoy seguro de que todos los que habeis dicho por twitter que Git es muy fácil, trabajais en solitario. Seguro que no habeis trabajado con Git en un proyecto con 3 o 4 desarrolladores ni habeis tenido que controlar las releases ni crear branches.

Se dice que Mercurial tiene mucha menos funcionalidad pero es mucho más fácil de usar. Vamos a ver si con Mercurial nos ahorramos tantos quebraderos de cabeza y podemos tener nuestro branch de desarrollo y nuestro branch de producción. Algo que parece tan sencillo y que no hemos sido capaces de hacer con Git.

Crucemos dedos :-S

Estamos buscando grandes inversores en EEUU pero tambien queremos intentarlo en España.

Aquí va nuestra oferta para pequeños y grandes inversores:

• La inversión mínima es de 100€
• Cuando empiece a haber beneficio, cada inversor recibirá el doble de lo que invirtió
• El pago a los inversores se realizará por orden: El primero en invertir (por fecha) es el primero en cobrar
• Los inversores tendrán acceso a las cuentas anuales de manera que sabrán cuándo hay beneficio y qué inversores están recibiendo su dinero de retorno
• Los inversores estarán informados de los planes de negocio y de las nuevas funciones de la web. Tendrán acceso a un foro interno donde se debatirán decisiones estratégicas
• Los inversores que pongan más dinero tendrán más peso en las decisiones estratégicas

¿Cuándo se espera que tengamos beneficio? Estimamos que a partir de los 100.000 inscritos empezaremos a facturar. Si lees el blog de MavenCharts verás que el modelo de negocio gira en torno a los micropagos (SMS) y en un futuro muy proximo, tambien a micropagos por acceso a funcionalidades extra para usuarios que lo demandan.

Intentaremos tener presencia en tantos paises como la economia nos permita. Por lo pronto USA, UK, Irlanda y Australia serán los primeros. Luego implantaremos en paises con otras lenguas.

Trabajaremos en MavenCharts mientras seamos capaces de generar sueldo para ello. Si llegase el momento en que no conseguimos pagar el sueldo del equipo que trabaja en el proyecto, se declararía fracasado y los inversores perderían su dinero.

Como ves las posibilidades son muchas y el riesgo el que cada uno quiera asumir. La apuesta es doble o nada. Nosotros ya llevamos un año de inversión, aproximadamente 40.000 euros. Y tu... ¿te animas?

Cuando empecé a escribir código en diciembre, planeaba tener lista la version que ha salido ahora, en abril. O sea que nos hemos retrasado 3 meses, practicamente el doble de la previsión. Calculo que trabajando sobre un sistema SQL tradicional y un servidor web como Apache, hubiesemos de verdad terminado en abril o mayo a más tardar. Realmente desarrollar sobre GAE ha sido un dolor. En primer lugar porque es NoSQL y eso significa que tienes que aprender a acceder a datos de otra manera. Tienes que pensar diferente. En segundo lugar, porque el Datastore (la base de datos) tiene tal cantidad de restricciones que hacer consultas medio complejas es muy muy complejo. Las consultas del buscador de MavenCharts son complicadas sin duda. Esto ha hecho que haya más tests de integración de los que hubiesen sido deseables.
Por otro lado, cargar la base de datos con las poblaciones de España tambien ha sido complejo. Primero habia que buscar los datos, tratarlos y subirlos. Los tenemos georeferenciados vía google maps para las nuevas funciones en las que estamos trabajando. Eso también llevó su trabajo.
GAE no te permite hacer ningun request que dure mas de 30 segundos, lo interrumpe con un error 500. Entonces te las tienes que ingeniar para dividir la tarea. Menos mal que hemos usado python y los scripts se hacen rápido porque hemos automatizado mil cosas de ese tipo. Para subir datos no puedes hacer un dump de SQL, todo lo que tienes es CSVs, que puedes subir si te programas las clases que los saben interpretar. Te lo tienes que hacer todo tu.
Otro problema importante es que el entorno de desarrollo de GAE en el pc local no es igual que el de la nube, y los tests de integracion que te van bien en local, luego arriba petan por falta de indices en la BD y cosas asi. Gracias a WebDriver, el cual hemos manejado desde Java, hemos podido automatizar las pruebas de integracion mas intensivas y complicadas.

El otro gran problema que nos supuso 3 semanas de retraso y unas 1500 lineas de código tiradas a la basura, fue el de la gestion de cache de datos. GAE te permita usar memcache. La gran pregunta es... ¿cómo gestionas la cache cuando tienes datos que actualizar? Despues de intentar mil cosas hemos adoptado la politica de Google, es decir, el buscador no refresca los datos inmediatamente sino que necesita unas horas. En nuestro caso unas 24 horas. Francamente es lo más optimo que se puede hacer. Todo lo demas, no escala. Realmente no vale con usar GAE para que tu aplicacion escale, sino que tienes que tener en cuenta mil cosas mas, y pensar que, cada peticion a la web, podria ser arrancada en una instancia distinta, en un servidor distinto, y si tenias un singleton por ahí, tienes un gran problema. Todo esto lo hemos ido aprendiendo a bofetadas. Menos mal que nuestras baterias de tests estaban ahí, porque sino, el caos nos hubiera ganado.

Finalmente, como todo el mundo sabe, la maquetación ha sido muy dura por aquello de que cada navegador (sobre todo Internet Explorer) pinta las cosas como quiere. Hemos cometido el error de dejar toda la maquetacion para el final pensando que seria sencilla, y no lo ha sido. En lo sucesivo iremos armando las pantallas a medida que el backend esté hecho. De hecho ahora hay que darle un gran refactoring a las css, pero al menos ya se ve bien en casi todos los sitios.

En la foto teneis al equipo de MavenCharts 1.0. En desarrollo, Oscar Moreno, Dani Latorre y un servidor. En diseño Lucas Carmona, Carlos Sosa y Pedro Gracia. En QA tenemos a Dácil a la cabeza de un grupo de amigos y colaboradores.

Ya tenemos la web internacionalizada y todo listo para soportar más paises e idiomas, asi que en las próximas semanas vamos a intentar salir en EEUU y en varios paises europeos, a la par que ir abriendo más funcionalidad. Hay ya cientos de lineas de codigo esperando a ser puestas en produccion

Nos hacen falta 4 buenos desarrolladores pero por desgracia todavia no hay pelas para contratar. Ojala podamos seguir creciendo pronto.

Tenemos mucha ilusión y estamos poniendo mucho esfuerzo en este proyecto. Cualquier feedback es bienvenido. Gracias a todos los que lo habeis retuiteado y lo comentais en facebook.

Seguimos trabajando

http://www.MavenCharts.com

Pocos dias despues, 10 y 11 de Junio estaré en Madrid en la Conferencia Agile Spain 2010. Allí tengo una sesion con Juan Guitiérrez y un taller de introduccion a TDD con Gregorio Mena. La sesion es de entrada libre para los asistentes a la conferencia y el taller es de pago. Sera una version resumida del curso de TDD, con algunos ejemplos distintos para ir mas rapido. Recomendable para las personas que no pudieron venir al curso de TDD.
Gracias a Plain Concepts, dispondremos de 50 ejemplares impresos del libro de TDD en su stand, que se venderán a 15 euros. Precio de costo.

He estado en la lista de coordinacion del evento, aunque no he participado y estoy impresionado con el trabajo tan grande que los organizadores han hecho para que salga adelante. Quiero dar las gracias a las personas que durante los ultimos 5 meses han dedicado unas 4 horas a la semana para que esto sea realidad. En los ultimos dias me consta que han sido muchas mas de 4 horas. En fin, es un esfuerzo abrumador que agradezco mucho.

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
remote = origin
merge = refs/heads/master

[remote "origin"]
url = git@github.com:username/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[gui]
geometry = 1018x659+9+104 382 207

Branches

1.Create a branch:

git branch bname # create the branch
git checkout bname # switch to the branch
git remote add bname_1 git@github.com:username/project.git # create a remote "folder" remotely
git fetch bname_1 # initialized the remofe "folder" locally
git push bname_1 bname:refs/heads/bname # initialize the remote "folder" remotely
git config branch.bname.remote bname_1 # add lines to .config file
git config branch.bname.merge refs/heads/bname # add lines to .config file

2.Switch branch:

git checkout bname # switches to bname
git checkout master # switches to master

3.Which branch am I on?:

git branch

4.Get branch from github:

git checkout --track -b bname origin/bname

5. Download a everything from github:

git clone git@github.com:username/project.git
cd project
git checkout --track -b bname origin/bname

Tags

git tag "v0.2"
git push --tags

En mi opinión la parte más interesante es la última hora, donde hacemos un pequeño ejercicio práctico.

Por cierto, aprovecho la ocasión para recordar que los dias 2 y 3 de junio estaré en Zaragoza impartiendo el curso de TDD. Todavia hay plazas para inscribirse

En Valladolid la acogida fue excepcional. Todo el mundo se esforzó a tope para que el curso saliese bien. Además Jorge Jiménez, Amalia Hernández y Pencho Herrero han sido unos anfitriones de lujo. Me enseñaron Valladolid e incluso pude ver lo contundente que es el Cocido Castellano. La ciudad y su gente me han conquistado.
Además grabamos un podcast aprovechando que la gente tenía un nivelazo tremendo.
Pencho me dió también la oportunidad de conocer a Pablo Santos de Plastic y a Jacinto Canales de Tecsidel, lo cual ha sido genial!
Por si todo esto no fuera suficiente, Pencho ha escrito este estupendo post sobre el curso!
Acabamos de colgar las fotos en Facebook.
Espero poder volver pronto a Castilla

En Barcelona fuimos pocos pero la cosa estuvo bien. No me dieron tregua. DoubleYou puso las instalaciones a cambio de algunas plazas para el curso y gracias a ello pudimos celebrarlo ya que no habíamos llegado a cubrir el minimo de plazas requeridas. No sabemos cual es el motivo de haber captado tan poca atención. Desde luego no acertamos con la campaña.
Lo cierto es que lo pasamos muy bien y aproveché para conocer el bonito barrio de Gracia, donde se come muuuy bien. No tuve tiempo de hacer turismo pero afortunadamente ya he visto la ciudad otras veces (y me encanta). Grabamos otro podcast muy interesante y tuvimos tiempo de debatir-cerveza-en-mano bastantes cosas. Ha valido la pena el esfuerzo para conocer a gente tan interesante y tan profesional.

Ahora vuelta a casa, a programar a muerte, que en junio tenemos el lanzamiento de nuestro producto estrella