Yo vs emprendimientos TI

Inicialmente iba a ser un artículo lleno de argumentos y explicaciones. Era sobre mi propio enfoque y el porqué de mi incompatibilidad con los emprendimientos. Al final el éxito de un emprendimiento se resume en una sola cosa: 

SACRIFICIO.

Hace algún tiempo tuve la oportunidad de conversar en extenso con un suizo, residente en Chile. La conversación con este exitoso empresario del rubro inmobiliario pronto derivó en su visión sobre los emprendimientos en Chile.
Me comentó sobre una experiencia que tuvo con unos amigos de él. Tenían una idea muy buena, auspiciosa en cuanto al mercado y a las potenciales ganancias a obtener. Él con su experiencia les señaló:

"La idea es buena, tiene potencial, pero para poder llevarla a cabo tienen que destinar al menos 10 horas diarias para trabajar en ella."

Se podrán imaginar que la réplica fue que no podían destinar 10 horas diarias de trabajo, ya que todos los involucrados podían entregar dedicación parcial al proyecto, debido a que trabajaban jornada completa.

Me arriesgo a decir que un alto porcentaje de los emprendimientos que quedan en nada (léase sólo en la idea y las buenas intenciones) se debe a que los integrantes no pueden destinar el tiempo necesario para trabajar en el proyecto.
Lamentablemente los emprendimientos no pueden llevarse a cabo a ritmo propio o cuando tengas ganas/puedas de dedicar tiempo a ello.

Finalmente todo se reduce a SACRIFICIO. ¿Cuánto estás dispuesto a sacrificar?:

• ¿Sacrificarías no ver a las personas que amas? 
• ¿Sacrificarías horas de sueño y descanso? 
• ¿Sacrificarías dejar de ganar una remuneración por hacer lo mismo (o similar)? Nota: Puse dejar de ganar y no perder, hay una sutil diferencia.
• ¿Sacrificarías rendir en tu trabajo actual por dedicar tiempo a tu emprendimiento? y de paso asumir el costo que esto puede significar (normalmente ser despedido).

Y quedo corto en este listado. Responder NO a cualquiera de estas preguntas ya es un riesgo que no estás dispuesto a tomar.

¿Cuánto estás dispuesto a sacrificar?

¿Cuánto?

En mi caso las cuentas eran negativas, demasiadas responsabilidades en mi quehacer cotidiano, repercusiones familiares, costo de oportunidad descompensado y una que por donde la mirara tenía demasiado peso. Después de una jornada de 8 horas diarias frente a un computador, resolviendo problemas de las más variadas especies, física y mentalmente termino disminuido para seguir haciendo lo mismo en casa (fuera de horario).

Hay que ser sincero con uno mismo y no tratar de auto-convencerse con falsas ilusiones. Las charlas TED y de la universidad suenan muy lindas y convincentes, pero llevarlas a la práctica dependerá de realidad personal de cada uno.

Spring REST Services y el error Required String parameter is not present

Desarrollando una API REST utilizando Spring MVC, y consumiéndola con AngularJS, me enfrenté al problema "Required String parameter is not present". Así es como lo solucioné.

Hace poco "vendí" (en rigor sólo convencía  mi jefe que es buena idea tomar este enfoque) una idea para abordar nuevos desarrollos. Consiste en desarrollar una API REST, utilizando el generador de código Telosys, y generar las interfaces con HTML5, CSS3 y JavaScript de modo de consumir los servicios con AngularJS.
Nada nuevo dirán, pero ofrece la ventaja que el mismo desarrollo web puede ser portado sin demasiado esfuerzo a una aplicación móvil usando Phonegap, o bien a una aplicación de escritorio utilizando Node-Webkit.

Este tipo de desarrollo resulta bastante rápido, y si logras una combinación entre Angular-UI-router y plantillas web con controladores propios (los controllers de AngularJS), se obtiene una modularidad bastante atractiva.

El problema

El código no tenía problemas, pero al tratar de realizar una llamada POST con Restangular a pesar de que el JSON con los datos que debía recibir la petición estaba bien construido, la llamada arrojaba el error:

Required String parameter 'usr' is not present

Soluciones propuestas

De las soluciones propuestas, después de realizar muchas búsquedas, ninguna funcionó:

• Forzar que todas las peticiones POST indicaran en sus headers
  Content-Type = 'application/x-www-form-urlencoded' con el código:
• $httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';   
• Agregar el atributo enctype="application/x-www-form-urlencoded" a la etiqueta form.
• Realizar la llamada con AngularJS nativo vs usar Restangular.

Hasta pensé en cambiar el enfoque y usar HATEOAS, pero significaba realizar demasiados cambios a la aplicación (en rigor regenerar el código, Telosys se encarga del trabajo sucio).

Solución

Dí con este artículo de StackOverflow, donde explican que el servicio debe recibir un objeto que tenga todos los parámetros de la petición. Algo como:

@RequestMapping(value = "events/add", method = RequestMethod.POST)
public void addEvent(@RequestBody CommandBean commandBean){
    //some code
}

donde se debe indicar que el objeto (puede ser un POJO) CommandBean es el  @RequestBody. Y Spring se encargará de capturar los parámetros adecuadamente.
Y eso funcionó sin problemas.