Two reasons why Facebook will kill his son, Parse.

Two days ago I was shocked when I read the Parse announcement, that after 5 years they will be closing a impressive service for mobile developers.
parse-2013.png
It is clear to me that Facebook wanted to control mobile when in 2013 started investing money in the best services around. In 2016 we can say now that Facebook is pure mobile.

In less than one year Facebook bought WhatsApp, Instagram, and Parse, among others. And yes, due to owning Parse they were in a position to control the situation in the independent startup scene.

Facebook had the privilege of knowing the data, and developed Facebook towards mobile quicker. Who said that information is Power? Facebook knew the data of thousands of small and medium Apps and how thousand of App has been performing during all this time.

It is clear to me that Facebook now doesn’t need to provide this service anymore in order to survive, as Facebook is the number one platform in mobile nowadays.

Another factor to consider, is that Facebook now is not that interested in helping developers to enjoy their lives by building apps that could potentially remove a tiny slice of the market, today the slice is 1% only, but still it is one percent of a huge market.

It seems clear that it is an business decision, but I would really like to know the real reason of what has been  happening behind the scenes.

Nevertheless, I would like to thank the Parse team for providing us the best mobile backend server so far.

Best of luck.

PS: I wish this was only one representation of the faith of Abraham, and at the last minute nobody turned off the button.semana-15-1

 

El motivo por el que a algunos no le gustara conocer la diferencia entre TDD y BDD

La diferencia entre TDD y BDD está en la primera letra. Test Driven Development no es lo mismo que Behaviour Driven Development.

bddtdd.png

La diferencia es que TDD se enfoca en verificar como funciona el sistema, sin embargo BDD, comprueba que las funcionalidad del sistema, como un ente global, funciona de la manera deseada por todos.

El problema de la comunicación y compartir responsabilidades.

Y claro, BDD es mucho más ambicioso, y mete el dedo en la llaga del principal problema en el desarrollo de Software, y a veces de la vida. El problema de la comunicación de las personas, el modo en el que hablamos y nos plantea un marco y un vocabulario especial para intentar que todos los que trabajan en el sistema, tengan claro lo que se espera del sistema.

Por resumir, BDD no sería necesario si TDD funcionara al 100% una vez cubierto el 100% de nuestro código con pruebas.

Te preguntaras, ¿y como puede fallar TDD? Pues puede fallar porque los requisitos, aunque parezca que son evidentes, en el mundo real la mayor parte de las veces, no están claros, son ambiguos, o inexactos.

Por lo que BDD va a tratar de enmarcar esos requisitos a nivel de ´feature´, tratando de definir cada feature del sistema, dejando por escrito el criterio de aceptación de cada una, en un lenguaje que dueños de producto puedan pedirlo.

GIVEN _____________

WHEN _____________

THEN______________

Pero claro, hablar y compartir responsabilidad es costoso, y exige que los dueños de producto, analistas de negocio, arquitectos de software y programadores dialogen, pregunten, se comuniquen y redacten cada criterio de aceptación.

Pero ¿De verdad hace falta este dialogo para hacer BDD?

Por supuesto, si no existe ese dialogo, aunque te vayas a casa orgulloso viendo como todos tus test han pasado, en realidad no estarás probando que el comportamiento del sistema es el adecuado. Con el paso del tiempo, cuando los interesados se den cuenta, te pedirán cambios de especificaciones, y algunos de tus tests empezaran a no valer.

Al repetir este proceso, te encontraras con unos test pobres que no valen de mucho, porque la verdad, ya  todos que dos y dos son cuatro, y probar eso tampoco nos aportaba gran cosa.

Con BDD, estamos hablando de una vision que cruza el proyecto en diagonal, que asegura que estamos probando la calidad de las funcionalidades del producto que en realidad se está intentando construir.

Y la ironía, es que las pruebas, esas gran olvidadas para el último momento, se convierten en la espada de Damocles, de aquellos con poder pero que no se quieren implicar, ansiosos de empezar a explicarte una nueva idea fantástica.

Precisamente, con BDD, todo el equipo, debe responder a la pregunta ¿Porqué estamos haciendo esto? Y algunas preguntas sólo podrán ser respondidas por los aquellos con autoridad. BDD no va de validar tu trabajo como programador, sino de compartir el comportamiento esperado entre todos los miembros del equipo.

 

Conclusión: ¿Como resolvemos el problema de no entregar software con errores a los clientes?

Asegurando que las pruebas no es algo que sólo los programadores se deben preocupar. Mas bien, y muy al contrario, describir las necesidades del sistema tiene miles de beneficios mucho mas allá de la corrección del código: con el desarrollo dirigido por comportamientos, se trata de establecer el dialogo entre los departamentos y personas interesadas, para que todas las preocupaciones sobre el sistema sean resueltas primero dialogo, y construidas con software que verifica que ese dialogo se ha reflejado en el código.

Esto si es calidad de Software y doy fe que se puede hacer. Cuanta tus experiencias con TDD y BDD y lo hablamos!

Por último, os dejo un video en inglés con un ejemplo donde se ve como TDD se puede quedar cojo muy pronto.

BDD vs TDD (explained) – YouTube

Las 3 únicos caminos de la concurrencia que Apple quiere que conozcas para que mejores tus Apps

Unknown.jpeg

La concurrencia de procesos es dificil, ya que plantea un problema que es intrínsecamente difícil de resolver, la organización necesaria para dotar de acceso y uso en exclusividad a un recurso valioso, público y compartido.

Ejemplos hay muchos en la vida real, imaginemos miles de coches que quieren circular por los mismas carreteras a la vez, donde necesitamos la ayuda de semáforos y de guardias de trafico. ¿Podríamos vivir sin ellos? Si, en algunos países lo hacen, pero la experiencia de usuario conduciendo en eso países no puede ser peor.

El sistema operativo de Apple proporciona tres mecanismos que permite coordinar la ejecución de los procesos.

 

Hilos o hebras de ejecución.

Esta opción, aunque posible, puede llegar a ser tan complejo que ni Apple te la recomienda, a no ser que resulte que tu App tenga que lidiar con procesos que tengan restricciones de uso en tiempo real, donde prefieras tener el control total de los hilos, y no dejarle al sistema operativo que los maneje; incluso en este caso, Apple te advierte que crees el menor número posible de los mismos.

Si te preguntas porque te desaniman en que trabajes con hilos directamente, simplemente piensa que el sistema operativo tiene optimizado al límite el uso de los escasos recursos que tienen los teléfonos móviles, tabletas, relojes y Apple TV. Cada uno de estos dispositivos, tiene una configuración de recursos distinta y desde que se introdujo el chip A5, tenemos dos o mas microprocesadores.

La pregunta que debes hacerte es si crees que vas a ser capaz de mejorar la gestión que hace el sistema operativo de los cientos de hilos que internamente ya se maneja y optimiza para cada teléfono iOS.

Si es así, ponte la chaqueta de Chuck Norris y di:

pzhuc6

 

GCD. Dispatch queues.

Una cola de despacho, como su propio nombre indica es una cola que almacena y despacha bloques de código en modo FIFO, es decir la primera tarea que entra en la cola de despacho, será la primera en ser despachada, es decir, ejecutada.

Lo único importante que necesitas diseñar es la estrategia, primero tienes que decidir si la ejecución de las tasas será síncrona, bloqueando la ejecución de las restantes en la cola hasta que el proceso acabe, o bien asíncrona, permitiendo que empiezan a trabajar de una y una y secuencialmente, el resto de tareas que estén en la cola.

El despacho síncrono, es delicado de manejar, ya que va a bloquear tareas, por lo que una buena practica es usar, en la medida de lo posible, el asíncrono y en los casos que necesites esperar seguir el siguiente patrón, por el que le pediremos a una nueva cola que haga la tarea pesada cuando pueda, y cuando termine haga lo que crea conveniente en la cola original. De esta forma, el asincronismo optimiza de manera educada el flujo de trabajo, sincronizando la ejecución de la tarea pesada primero (3)y la dependiente después(4), tan pronto como sea posible(0), pero sin bloquear al resto de tareas que tenían que ser ejecutadas en el flujo principal(1)(2), y que en realidad no tenían porque esperar a nada.

(0)
dispatch_async(otherQueue,
    ^{
          (3)
		 id result = doSlowTask();

           dispatch_async(originalQueue,
               ^{
					(4)
                     	didGetResult(result);
               });
    });
(1)
(2)

NSOperationQueue.

Una cola de operación, es algo propio de Cocoa, que aunque usa colas de despacho internamente, el arranque de las tareas es más sofisticado que eso de que ejecuto lo primero que entro, en realidad las va a tratar de ejecutar todas a la vez, pero nos deja jugar con algunos parámetros, como cuantas tareas queremos que se ejecuten a la vez, y el orden de ejecución de las tareas, permitiendo incluso organizar una cadena compleja de procesos dependientes los unos de los otros. ¿Esto mola, verdad?

¿Y a ti, cual te gusta más?

Pues mira, tu tendrás que buscar el modelo que te guste más, según mi criterio, no son excluyeres.

Aunque como idea general, siempre debemos tratar de usar el modelo de abstracción más alto para solucionar el problema que se nos plantea, como ingenieros debemos para a pensar sobre los pros y contras de usar GCD o NSOperationQueue.

Si se trata de tareas sencillas, y sin dependencias, yo tiraría por GCD, para no matar moscas a cañonazos.

Si no nos importa que se ejecute un poco más lento, y queremos programar todos los detalles de nuestro flujo de trabajo en las colas, o cancelar algunos de las tareas ya encoladas, entonces si que tiraría por las colas de operaciones. En definitiva, procesos más complejos y repetitivos como tratamiento de imágenes, procesamiento de textos, peticiones de red, y cosas así. Y a ti, cual te gusta más, deja tu comentario y lo hablamos. Gracias!

A good reason to use reuseIdentifier in your TableViews

Providing that a TableView may have a very large number of cells in real time, and every cell can be composed internally with heavy subview, the system will only allocate the memory needed for those UITableCellViews objets that are shown on real time.

This is a good idea in terms of performance.

The reuse identifier is associated with a UITableViewCell object that the table-view’s delegate creates with the intent to reuse it as the basis for multiple rows of a table view.

What if the user wants to scroll ?Scroll_opened.png

The UITableView inherits from UIScrollView, and scrolling is great for the user experience, but now we need to think about the case that the number of cells is larger to the size of the screen.

Should the system allocate the new cells from scratch or maybe is there a better way to do it? It is, of course. Cocoa allow us to reuse the memory reserved for the cell, as the user it is just scrolling and showing a new cell.

For every new cell shown the system it is forced to show, and therefore, to allocate a new UITableViewCellObject, which can be very slow if the user is scrolling through a large TableView with tons of cells, and will show a poor performance, especially if the cellView it is composed by downloaded images,  potentially leading to laggy animations.

Is there a solution to avoid this lag ?

Fortunately, Apple provides a nice solution to this common situation. The API of the delegate counts with what we call de Identifier of the cell. You can set the identifier of the cell in the Interface Builder or programmatically. If reuseIdentifier is set to a non-nil value, then when the table view is scrolled, UITableView will first attempt to reuse an already allocated UITableViewCell with the same reuseIdentifier.

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
	let cell = tableView.dequeueReusableCellWithIdentifier("DefaultCell")!
	return cell
}

 

 

Heisenberg, now Say my name in Swift

Las funciones en Swift son son bloques autónomos de código que realizan una tarea concreta. A ese pedazo de código, pecador de la pradera, le das una nombre de función que identifique bien lo que hace, y este nombre se usa para “llamar” la función para realizar su tarea cuando sea necesario.

 

La sintaxis de función en Swift es es lo suficientemente flexible para expresar cualquier cosa, desde una función de estilo C simple, sin nombres de parámetros a algo mas al estilo mensaje de Objective C, con nombres de parámetros locales y externos para cada distinto parámetro.

Los parámetros pueden tener valores predeterminados por defecto, con lo que se simplifican las llamadas que hacemos.

Además, las funciones pueden ser el valor de retorno de una función, lo cual es algo innovador comparándolo con Objective-C, que no con JavaScript.

Además, tenemos la novedad de que podemos pasar parámetros por referencia, con lo que si el valor del parámetro es modificado, ese mismo valor sera obtenido fuera del mismo.

Por último,  las funciones también se pueden escribir dentro de otras funciones para encapsular funcionalidad útil dentro de un ámbito de función anidada.

Con todo esto ya podemos intuir la potencia de todo lo que se esconde detrás de estas cuatro letras que componen la palabra reservada func.

Funciones sin parámetros y sin tipos de retorno.

No hace falta parámetros de entrada en las funciones de Swift, solo acordarnos de que tenemos que poner los paréntesis finales vacios.

    func whoTheHellAreYou() {

        print("You know. You all know exactly who I am. Say my name.")

    }

    func whoTheHellAreYou() {</code>

        print("You know. You all know exactly who I am. Say my name.")

    }

    whoTheHellAreYou()

    //Cuando Walter White te pide que le digas el nombre, esta claro que necesitas ponerle un parámetro a tu función.

    func nowSayMyName(personName: String) {
        if (personName != "Heisenberg") {
            return false
        } else {
            print("You are damm right")
            return true
        }
    }
    
    
    nowSayMyName("")
    
    nowSayMyName("Heisenberg")

¿En que se parecen Swift y Objective-C ? Se parecen lo que un huevo a una castaña

Se parecen en que son de Apple, y punto. O lo que es lo mismo, lo que un huevo a una castaña.HuevoCastaña.jpg

Swift es un lenguaje bastante distinto y bastante más complejo que Objective C, ya que incorpora elementos de programación funcional. La desaparición de las llaves hace su lectura bastante más amigable a primera vista, pero no nos engañemos, detrás de esta ascética belleza, se esconde un lenguaje mucho más complejo de lo que que podría parecer.

Objective-C ha evolucionado los últimos años para dar soporte a bloques, literales, módulos y permitiendo que la adaptación a tecnologías modernas se haya podido realizar sin producir un gran caos. Swift resulta similar a Objective-C en cuanto que comparte el nombrado de las variables y el modelo de ejecución dinámico de objetos. Provee el mismo acceso a los frameworks de Cocoa y permite usar código escrito en Objective-C.

A partir de aquí, Swift en un lenguaje mas complejo y potente, ya que aporta nuevas formas de trabajar, es un lenguaje mucho más expresivo, y unifica las porciones mas arcanas y procedurales con las nuevas y orientadas a objeto.

Además, soporta playgrounds para probar y el código en tiempo real, sin tener que realizar la compilación y linkado de tu proyecto. Esta genialidad es posible porque los ingenieros de Apple se han preocupado por optimizar el compilador para que el lenguaje ofrezca una gran rendimiento tanto su uso, como en el desarrollo del software que construimos con el.

Si no estas muy de acuerdo, y mas bien crees que si que se parecen en mas cosas, escribe un comentario, y lo hablamos.

Como reorientar el liderazgo y mejorar tu carrera profesional en 4 fáciles pasos.

¿Y ahora qué? Para saber que hacer con tu carrera, en primer lugar tienes que diagnosticar en qué situación estás, tus conocimientos, recursos y habilidades. Esta es la fase de análisis de la situación, donde trataremos de responder el porque. Muchas veces te encuentras en el punto que te encuentras simplemente por las circunstancias de los proyectos y empresas para las que has trabajado previamente, pero es el momento de tomar responsabilidad y seguir estos cuatro simples pasos para reorientar tu carrera y crear tu marca profesional.

La primera, es la etapa del análisis, hay que descomponer el todo en partes para poder estudiar la estructura, ese momento de buscar razones y motivaciones, descargar internamente tus fortalezas y debilidades, tus hábitos, tu historia todas aquellas características que moldean tu carácter, conocerte a ti mismo, hacer una búsqueda profunda de tus raíces.

En segundo lugar, es importante diseñar el plan y tus metas de forma clara sobre lo que quieres conseguir. Ésta etapa es crítica, ya que requiere no perder de vista el verdadero objetivo, ya que no se trata sólo de establecer un plan de acción, sino de enlazarlo con tu propósito de vida, y saber que realmente se puede llevar a la práctica. Como sabes, muchas veces los proyectos fallan debido a que se pone demasiado énfasis en un diseño maravilloso, que nunca puede verse completado, por lo difícil o imposible que resulta ejecutarlo. Hablar de diseño es también hablar de lo bien que va a funcionar el plan.

En tercer lugar, hay que desarrollar el plan llevarlo a la acción inmediata, sin dilación ninguna. Este es una etapa bastante compleja de lograr que implica comenzar a hacer actividades que probablemente no estás acostumbrado. Y eso, cuesta y va a requerir esfuerzo de tu parte, además de una buena dosis de habilidad para adaptarse al cambio. Pasar a la acción te obliga a concentrar tus esfuerzos, a pesar de lo difícil que pueda llegar a ser, en la acción es donde la curva de aprendizaje tiene sentido, pasar a la acción nuestra recompensa de ver cómo se ejecuta nuestro plan. Sobre todo hay que evitar el efecto de parálisis por análisis.

En cuarto lugar la estrategia de control, aumentando los sentidos sobre que está subiendo a tu alrededor y evaluando los resultados, ser flexible para ir cambiando la manera de actuar. El dominio y control de tus acciones te llevará al lugar donde quieres llegar. Controlar y dominar el campo específico de tu formación te llevará a conseguir el liderazgo y la marca profesional.

Sobre todo se trata de la capacidad de influir, en primer lugar, sobre ti mismo, para poco a poco comenzar a hacerlo sobre los demás, pasando de la habilidad de comunicarte contigo mismo sobre lo que quieres alcanzar o hacerlo sobre los demás.

Decía John Maxwell que el liderazgo es Influencia. Ahora bien, en la era de la información, para conseguir influencia es necesario agregar la capacidad de comunicar para hacer de este liderazgo clave en la marca profesional y un factor de diferenciación. En este sentido el liderazgo es influencia y la comunicación la capacidad más poderosa para ahora. Es por eso que muchos profesionales animan a escribir tu propio blog, para expresar tus ideas personales, y comunicarlas desde su propio punto de vista. La relación entre liderazgo en la marca profesional radica la capacidad de controlar tu vida, comprometiéndote con el loro de tus objetivos. Se trata de alinear tus talentos y habilidades naturales dentro de tu carrera profesional, para presentarla y posicionarla en el mercado laboral.

Hablando sobre liderazgo, para mi es clave considerar el liderazgo hacia uno mismo, uno debe liderarse a si mismo conforme a sus valores, para después poder liderar a otras personas. Decía San Agustín,”Señor, concédeme coraje para cambiar las cosas que pueden ser cambiadas serenidad para aceptar las cosas que no pueden cambiarse para saber ver la diferencia”. Stephen Covey decía que cuando se nos presenta un problema, siempre que pensemos que el problema esta fuera ese pensamiento es realmente el  problema.

 

Enfocarnos en nuestro liderazgo personal los invita a realizar el cambio de dentro hacia fuera, ser diferentes y de esta manera provocar un cambio positivo externo. Dicho de otra forma si realmente quiero mejorar la situación, lo que tengo hacer es trabajar en lo único sobre lo que realmente tengo control, que es yo mismo, después de hacerlo poder recomponer la situación, alinear el entorno y aplicar los cambios que crea oportunos.

Para obtener buenas respuestas en el liderazgo personal debe estar basado en en principios, los cuales  nos ayudaran a que las decisiones sean tomadas con mayor facilidad.

De que lo que sientes lo sientes porque tú lo aceptas si puedes aceptar las cosas como son estarás listo para subir la responsabilidad esta situación y de todos los sucesos que perciba como problemas. Asumir la propia responsabilidad es no culpar a nadie de tu situación para reciclar tu del liderazgo desarrollando tu fuerza interior. La marca profesional no busca convertir a los profesionales en productos materiales más bien el objetivo es que la persona no sea catalogada como currículum igual que el de los demás Sino que profesional se ha visto como diferente capaz de aportar una contribución única aquí la redes sociales o muy importante.

En pocas palabras la marca profesional es como vender lo que sabes hacer  a los demás. Que se crea entre tu audiencia y tu. Se trata de cómo la gente percibe aún antes de entrar en contacto contigo. Aunque lo creas o no tú ya tienes una marca profesional con las personas que tiene una percepción de ti así sea sólo para decir es otro profesional más está desafortunadamente ha sido creada de manera accidental incluso sin haberte dado cuenta. En el proceso de marca profesional se debe ser intencional tomando control de la percepción pública. Esto no sólo te ayudará mostrar diferente, sin obtener mejores oportunidades, Sin embargo se hace muy poco nivel profesional para construir la. Porque necesitamos la marca profesional, En realidad, La mayor ventaja competitiva con las que cuentas eres tú mismo. En vez de enfocarte en cual será tu nuevo salario paquete de facturas, debes enfocarte en ti mismo, tú eres el tu negocio o trabajo en el que te desenvuelve como este contratan porque hiciste algo que hacer. Tu cara cambiará si tienes una marca fuerte. Recuerda el dicho que dice que nunca y la segunda oportunidad para causar una buena primera impresión.

La clave para una carrera exitosa es tener un conocimiento de quién eres y qué haces mejor porque encontrarás personas interesadas en lo que ofreces, podrás construir una red de contactos que te traerá nuevas oportunidades personales y profesionales.