Queremos que suene mucho y fuerte entre todos vosotros y estamos trabajando muy duro para que en breve veáis la idea en funcionamiento.

Y así para empezar… os gusta el nombre? Y el logo?

Stay tuned!

Estos son algunos de los sitios donde daremos guerra:

• Quomai
• Twitter
• Facebook

Si has respondido que sí a cualquiera de las preguntas anteriores, entonces te gustará Kukers.

Kukers es un pequeño proyecto personal que iniciamos unos amigos hace ya algún tiempo en nuestros ratos libres y que por fin ha visto la luz. Poco a poco iremos añadiendo más funcionalidad, pero siempre atendiendo a lo que más os guste para que Kukers sea realmente esa red de cocina y recetas que siempre te hubiese gustado tener.

Si tienes cualquier sugerencia, ves cualquier fallo o simplemente quieres contarnos qué te parece la web, no lo dudes: info@kukers.com

Puedes seguir la actividad de Kukers en Facebook y en Twitter.

Sigue también a los otros padres de la criatura:

• Eslomas: Lanzamos Kukers, una nueva red social de cocina
• Sonesu: Kukers, la comunidad para organizar, compartir y descubrir recetas de cocina
• Carloswes: Fotolog, Kukers.com
• David (hace mute)

Lo primero que me llamó la atención del libro fue su propio título. Conocía libros blancos pero, ¿libro negro? La duda no fue más allá de la segunda página de la introducción. Este libro, en vez de ser un “libro de recomendaciones sobre buenas prácticas y usos” se dedica a listar y detallar 14 factores clave de fracaso (14 FCF como los denomina) en contra de los comunes factores críticos de éxito. Como el propio subtítulo del libro dice: “no digas que nunca te lo advirtieron”.

Como el propio autor dice, “para evitar que un emprendedor fracase ha de saber por qué fracasaron aquellos a quienes nos les fue bien”. Si bien parecen recetas a seguir, realmente está dejando claros muchos de los aspectos que, si reconoces en tu forma de ser o actuar como emprendedor, pueden provocar que tu negocio termine mal, o al menos no tan bien como esperabas.

Desde mi punto de vista que acabo de dar el salto a emprender, al leer todos y cada uno de los puntos, por tontería que parezca, es importante ponerte en la situación que propone el libro en cada capítulo y preguntarte, sin mentiras, si realmente estás en esa situación o no. Es un libro nada complicado de leer y tiene conceptos e ideas que no hay que olvidar, da igual que lleves -30 días como emprendedor, 1 día ó 2 años.

Como me han parecido muy importantes y quiero tenerlos bien recogidos, aquí van:

Respecto a la persona que emprende

1. Emprender con un motivo, pero sin una motivación
2. No tener carácter emprendedor
3. No ser un luchador

Respecto a los socios

1. Contar con socios cuando en realidad puede prescindir de ellos
2. Escoger socios sin definir criterios de elección relevantes
3. Ir a partes iguales cuando no todo el mundo aporta lo mismo
4. Falta de confianza y comunicación con los socios

Respecto a la idea de negocio

1. Pensar que de la idea depende el éxito
2. Adentrarse en sectores que no gustan o se desconocen
3. Escoger sectores de actividad poco atractivos

Respecto a la situación familiar del emprendedor

1. Hacer depender al negocio de las necesidades familiares y ambiciones materiales
2. Emprender sin asumir el impacto que tendrá sobre nuestro equilibrio vital

Respecto a la gestión del crecimiento

1. Crear modelos de negocio que no dan beneficios rápidamente y de modo sostenible
2. Ser emprendedor y no empresario, y no retirarse a tiempo

Reitero, lectura recomendada para todos aquellos que alguna vez se han planteado emprender, o quieren saber a qué se van a enfrentar, así como para emprendedores neófito o natos.

• A fecha 1 de enero de 2011 tenía casi (por muy poco) 6700 tweets
  • Ha desaparecido el “Buenos días”
  • Cumplido: 100%
• Durante 2010 he escrito 37 posts
  • Cumplido: 30%
• En el período 01/10 – 31/12, el blog ha tenido:
  • +42,19% visitas
  • +27,39% páginas vistas
  • Cumplido: 100%
• He leído 3 libros
  • Comentarios para después
• Android/iOS:
  • He realizado dos aplicaciones sencillas para Android (una de uso personal y otra sin publicar)
  • Poco a destacar de iOS y Objetive-C
• La emisora sigue teniendo poco uso
• Este año no he desconectado como el pasado, pero he sabido distanciarme cuando era necesario.

Este año la lista ha sido larga, pero voy a hacer unos cuantos comentarios que creo que son justos ya que mi cabeza es de ingeniero y por un lado está el lado científico, el de las cifras que me van a dar datos objetivos sobre los resultados (seguro?) pero también está el racional que me hace pensar las cosas y llevarlas un poco más allá.

Más allá de la cantidad de tweets de este año, que realmente han sido muchos (casi el 60% de total de tweets que tengo) valoro muy positivamente donde me ha llevado esta red social que es la que más uso. He conocido a mucha gente, he podido desvirtualizar a unos cuantos (muchos menos de lo que me gustaría) y, lo que es más importante, ha sido uno de los métodos por los que más he podido aprender, no sólo por la cantidad de información que puedes recibir, sino del feedback que consigues cuando tu das la información. Ayuda a sintetizar las frases ya que son 140 caracteres e incluso he establecido reuniones y encuentros mediante esta vía, algo que me parece fantástico.

Este año la verdad es que he posteado muy poco comparado con el objetivo que me puse, pero no por ello estoy descontento. Creo que he aumentado mucho la calidad y me he centrado en temas como vim, git, PHPConference y algunos de mis desarrollos como Burndowngenerator.com, Equation (con el July Innovation Award de PHPClasses incluído), Matrix, symfony autocompleter, etc. Y bueno, como colofón, uno de mis posts ha aparecido en meneame.net que, aunque no haya alcanzado portada, la verdad es que me ha hecho ilusión.

El tema de la lectura, con las cifras que se ven, la verdad es que parece que no he hecho mucho este año. Y la verdad es que podía haber hecho más, eso sin dudarlo. He leído 3 libros de los 5 que me propuse, pero he aprendido que esta medida, si realmente quiero saber si he leído más o menos, no es válida ya que debo fijarme en una medida con mayor relevancia, como por ejemplo el número de páginas. Y para hacernos una idea, este año 2010, comparado con 2009 en número de páginas, he leído +2,5 veces más. ¿Por qué? Pues está claro, porque eran libros “más gordos”

En concreto, me he leído los 3 primeros libros de la saga de Eragon: Eragon, Eldest y Brisingr (a la espera de que el autor saque por fin el cuarto libro). Y, ya que en la métrica establecida no podía contar, he empezado con el primer libro de la saga La brújula dorada que es con el que me encuentro actualmente y que contará de cara al año que viene.

Y bueno, este creo que es todo el repaso.

Ahora me queda terminar de fijar los de este año, que creo que van a ser mucho más interesantes

• es_ES
• en_GB
• en_US
• …

Para que no cometáis el mismo error que yo al confundirlos más de una vez, el guión bajo (_) separa cada una de las dos partes:

1. idioma, con dos letras minúsculas según el estándar ISO-639-1
2. país, con dos letras mayúsculas según el estándar ISO-3166-1

De esta forma, es_ES y es_AR tienen el mismo idioma, español, mientras que distinto país, España en el primero caso, Argentina en el segundo.

La diferencia entre mayúsculas y minúsculas debe servirnos de ayuda para identificar ambos datos, aunque nos los den por separado, de modo que por ejemplo, cuando obtenemos una lista de países, deberíamos indicarla con dos letras mayúsculas.

Coincidiendo con mi cambio de década (acabo de cumplir los 30) y como regalo de Reyes, he decidido que el próximo 7 de enero me lanzo a la aventura de emprender. No ha sido una decisión fácil, hay que dejar muchas buenas cosas atrás, pero es algo que me llama desde hace algún tiempo y lo cojo con mucha ilusión.

Han sido más de 5 años y medio los que he dedicado a aprender y a crecer profesionalmente dentro de Biko (y New Media Publishing en sus primero pasos antes de la fusión con SPI Navarra Virtual). Siempre estaré agradecido a Biko y a todas las personas que forman y han formado parte de ella ya que me ha permitido llegar hasta donde estoy hoy en día. Todavía recuerdo con cariño mi entrevista con Diego Cenzano, Diego Fernández y Patxi Echarte antes de formar parte de esta gran familia que se estaba gestando.

No puedo dejar de agradecer a todos mis compañeros todas esas horas que hemos pasado juntos y todo lo que hemos aprendido. Me quedo en especial con los buenos momentos, que han sido muchos  y de lo más variados, y de los malos me quedo con la lección aprendida, porque siempre hay que mirar hacia adelante. Sois grandes profesionales de los que he aprendido mucho, muchísimo y esta es una marca imborrable que se queda conmigo.

Pero creo que ha llegado una buena oportunidad en un momento en el que me puedo permitir esta aventura. Voy a seguir aprendiendo, mi motivación principal. Ya no sólo de temas técnicos (que me siguen encantando), sino también en otras facetas que llevo “cortejando” algún tiempo.

Me toca a mi ahora dar el paso y lanzarme a esta nueva e ilusionante aventura. Os tendré informados es este, mi blog personal y también por twitter.

Gracias a todos los que habéis mostrado vuestro apoyo, significan mucho para mí.

Es realmente sencillo y he tenido he podido comprobar (conmigo y con otros) como la eficacia de este método es elevadísima. Hay que seguir unos sencillos pasos:

1. Conseguir un patito de goma, preferiblemente variedad baño
2. Colocar el patito cerca nuestra, en el escritorio por ejemplo e informarle que vais a ver un poco de código, a ver si está de acuerdo.
3. Explicar al pato qué es lo que se supone que hace el código y tras esto, entrar en detalle explicándolo línea a línea.
4. En algún momento le dirás al patito lo que se supone que es lo siguiente a hacer y te darás cuenta que eso no es lo que realmente está haciendo tu código. El pato se mantendrá sentado serenamente, contento de saber que te ha ayudado en tu tarea.

Existen variantes al patito de goma, como otro tipo de peluches y objetos, pero su efectividad no está tan demostrada como con el patito de goma.

Supongamos que tenemos una clase como esta que queremos mockear:

class MyClass {
  public function check($param) {
    // Código
  }
}

En el caso concreto de querer comprobar si se realizan, por ejemplo, dos llamadas a esta función pasando $param = ‘one’ y una llamada con $param = ‘two’, es cuando nos encontremos el problema. Por ejemplo:

$mock = $this->getMock('MyClass');
$first = 'one';
$mock->expect($this->exactly(2))->method('check')->with($first);
$second = 'two';
$mock->expect($this->once())->method('check')->with($second);

Aunque la clase que programemos realice correctamente las llamadas, PHPUnit nos indicará que se esperaban 2 llamadas a check, pero se han realizado 3 y, por lo tanto, no pasará el test.

Esta misma semana comentaba con Carlos Ble y hay posibles soluciones, como es generar una clase intermedia que separe ambas llamadas, siempre teniendo en cuenta que podamos hacer ese código y quizás no sea tan sencillo con código legado o con mucho acoplamiento.

A ver si en los próximos releases de phpunit-mock-objects se soluciona este problema.

1. Crear un fichero hosts en tu ordenador (o usar el que ya tienes en /etc/hosts)
2. Remontar el emulador y copiar el fichero anterior

La necesidad de remontar viene porque si no, el dispositivo está como sólo lectura y por lo tanto es imposible escribir nada en él.

Supongamos que tenemos partimos de nuestro /etc/hosts, iríamos al directorio donde tenemos las tools del SDK y teclearíamos:

adb remount
adb push /etc/hosts /system/etc/

También es posible coger el fichero hosts que tiene el emulador (por ejemplo, copiandolo a nuestro directorio /tmp):

adb push /system/etc/hosts /tmp

¿Y en qué casos nos puede hacer falta? Bueno, yo en concreto lo he necesitado cuando estaba desarrollando una aplicación que se alimentaba de un webservice. Realizaba el desarrollo del webservice en paralelo y por lo tanto no estaba (todavía) en la máquina de producción. De esta forma, gracias al fichero hosts obligaba al emulador a buscar en mi entorno de desarrollo en vez de ir al de producción, haciendo que la aplicación tuviese un comportamiento transparente, en código, sobre dónde atacar.

El truco está en hacer un echo del valor y asegurarnos en la llamada de la función que se asigna a una variable. Es decir, nuestra función sería:

function retorna_texto {
    echo -n "este es el valor a retornar"
}

Y la llamada:

VALOR=$( retorna_texto )

Ahora en ${VALOR} tendremos el texto tal y como queríamos