Hoy en día todo desarrollo empresarial de cierta complejidad debe realizarse usando todo tipo de técnicas de QA como pueden ser los tests de aceptación, unitarios, motores de integración continua, herramientas de calidad de código… Todas estas técnicas proporcionan mucho beneficio al largo plazo, aunque a corto plazo, mientras se sufre la curva de aprendizaje y los cambios en los procesos, pueda parecer todo lo contrario.

El testing es importante por muchos motivos, pero si queremos traducirlos a KPIs de negocio para que la gente de producto lo comprenda y os ayude a convencerlos, os dejo aquí tres motivos que os ayudarán:

• Disminución del tiempo dedicado a corrección de bugs, con el consecuente aumento del tiempo disponible para crear producto nuevo
• Disminución de los bugs en producción en partes que ya funcionaban, mejorando la experiencia y percepción de calidad de tu site de los usuarios.
• Disminuir el tiempo de testing manual liberando a la gente de producto del mismo, proporcionándoles así mucho más tiempo para la creación y evolución de producto.

Nosotros en El Confidencial realizamos los siguientes pasos para asegurar la calidad de nuestros productos:

1. Buenas prácticas, patrones de diseño y comportamiento

En primer lugar animamos y formamos a nuestros desarrolladores para que usen las buenas prácticas, intenten cumplir principios SOLID y sean capaces de aplicar patrones de diseño (Command, executor, visitor, decorator…) para cumplir con nuestros objetivos de tener el código lo más desacoplado y modular posible para que esto nos garantice mucha velocidad de desarrollo y simplifique la programación de cada parte del mismo

2. Test unitarios

Todo desarrollo, ya sea de front o de back, debe ir con sus tests unitarios implementados y con la mayor cobertura posible (hay que testear tu negocio, no hace falta testear un método “get” anémico), para tener cubierta cada pieza de nuestro código y garantizar tanto el buen funcionamiento de la funcionalidad nueva como la posible regresión en un futuro.

3. Tests de Linting y estándares de código internos

Analizamos la calidad de nuestro código para detectar posibles errores como pueden ser:

• Clases con muchos métodos
• Métodos con muchas líneas
• Variables declaradas sin uso
• Posible uso de algunos patrones
• Estándares definidos por el propio equipo como puede ser el uso de PSR-12, uso del PHP-DOC etc

4. Mutantes

Para que nuestros tests unitarios sean realmente útiles y no simplemente tests que cubren cobertura utilizamos librerías que nos lanzan tests de mutación de código. Estos tests básicamente lo que realizan son pasadas de tu suit de tests y entre cada pasada mutan el código fuente de tus clases para detectar que realmente los tests comprueban la lógica de negocio programada. Si te cambian una condición y no se rompe un tests… algo mal está en ese test!

5. Tests funcionales o de UI

Para comprobar que al usuario no le falla nada en su experiencia creamos tests funcionales o de UI de todo lo que suponga una iteración del usuario con el interfaz de la aplicación, ya sea web o mobile. Para esta parte hay que tener en cuenta varios aspectos:

• Tener claros los criterios de aceptación y declarados en el estándar Gherkin, para orientarnos a BDD.
• Solo testear de inicio el “happy path.”
• Crear nuevos tests de UI solo tras el reporte de un bug para demostrar y reproducir el propio bug y su existencia.

Ejemplo de declaración del test en modo Gherkin

y ejemplo de cómo se visualiza en la suite de Cypress

6. Test manual de la funcionalidad nueva

Una vez el desarrollador da por terminado toda la parte de QA de su funcionalidad, junto con el desarrollo de la misma, se pasa a probar manualmente, por parte de otro compañero, la funcionalidad para salirnos del happy path e intentar encontrar problemas en el desarrollo

7. Code Reviews

Por último, teniendo ya pasadas todas las fases anteriores, se pueden realizar los pull request, donde hay una revisión del código por parte de varios compañeros para garantizar la calidad del mismo, detectar problemas en los acuerdos de trabajo acordados etc

8. Releases

Automáticamente los jueves a las 15:00 horas se saca una rama release con todas las funcionalidades que se han integrado hasta ese momento, cosa que nos permite hacer el siguiente paso que es el de realizar las “review de producto” y “bugfixing” de errores funcionales, diseño o negocio encontrados en las “reviews”, sin que le afecte el hecho de que se estén integrando nuevas funcionalidades en la rama de integración que saldrán en la siguiente release a la actual.

Además dicha release se comunica al canal interno de Slack para que todo el mundo sea cosciente de su creación y de qué es lo que ha entrado en la misma

9. Review

Una vez hemos garantizado este nivel de calidad la tarea puede ser revisada por los stakeholders para verificar que cumple todo lo que se ha acordado con dicha funcionalidad y tenemos su ok para su integración en la rama de integración y poder ser desplegada a producción

10. Integración continua

Es muy importante disponer de una herramienta de integración continua que, una vez se van integrando todas las funcionalidades individuales, verifique que todos los tests unitarios, funcionales y de calidad de código siguen pasando y todo está en verde. En nuestro caso usamos GOCD como dicho motor.

11. Sonarqube

También es fundamental tener una herramienta como Sonarqube que te permite detectar estos problemas de Linting y más reglas customizadas que hemos definido para nuestros desarrollos y mantener su evolución, así como asígnar responsables para su resolución en el caso de tenerlos. También nos permite definir reglas de límites de código duplicado y cobertura como, por ejemplo, nunca bajar la cobertura global de un proyecto con una subida, mínimo ha de mantenerse.

12. Deployment automático

Por último es fundamental tener un sistema de despliegue automatizado para eliminar el factor humano de la ecuación y así minimizar los errores en la puesta en producción del código nuevo de la release que se está sacando. Para este paso también usamos la herramienta de GOCD

13. Performance sintético del front en producción

Como el SEO para nosotros es muy importante tenemos todo tipo de métricas para controlar que el performance en el front no se degrade por una subida. Hemos definido budgets para todas ellas y disponemos de un sistema de monitoreo y también un semáforo visual que nos permite tener todas ellas controladas. Algunas de esas métricas son:

• Time to interactive
• Número de elementos en el DOM
• Total de peticiones
• Respuesta del servidor
• CLS
• FID
• LCP
• Tamaño del js
• Tamaño del css
• …

Para ello usamos una herramienta que se llama speedcurve. Aquí os dejo un pantallazo de cómo se ve

Next Steps

Los siguientes pasos que queremos introducir para seguir creciendo en la calidad de los productos que usamos son los siguientes:

1 Tests de performance en backend en la integración continua: Introduciremos la herramienta de Blackfire para que nos indique cómo es el performance de cada parte de nuestro backend para poder introducir budgets de performance tambien en backend e impedir una subida si alguna parte incumple su budget.

2. Performance y Alertas del front en producción en casos reales: En este caso lo que se pretende es poder tener información real de usuarios, con una gran variedad de navegadores y sistemas operativos, para poder tener una información más fiable de tiempos, métricas, budgets y errores.

La importancia de los procesos de QA (Cómo lo hacemos en El Confidencial) was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is Part 2 of a series of tutorials whose purpose is to help iOS programmers better understand the potential ofCoreAnimation framework. The animations described in this article are based on CSS SpinKit library. You can find the iOS implementation “SpinKitFramework” here.

In the previous article we talked about view and layer animations. We went over CALayer class and finally implemented two beautiful spinners. In this last part we’ll focus on another spinner from the SpinKit library, the folding cube spinner, which is the most difficult and complete of the set.

Analysis

This one is a bit of a total challenge, isn’t it? Give yourself a minute, what do you see here? What is happening? There’s for sure more than one solution. Think about the “actors in the play”, the time they show up, the different effects you see here…

Let’s take a look at the facts. In this animation, it looks like there’s a mix of:

• Rotations
• Fade-in and fade-out
• Color darkening

All this happen to affect four squares… is it? Here’s what’s happening behind the scenes:

• The view has a sublayer which is a CAReplicatorLayer that, we know, replicates its sublayer the number of times we set it to. In this case, four times aCAShapeLayer .
• Our instance of CAReplicatorLayer applies an instanceTransform so that each cube is rotated.
• Each instance of the CAReplicatorLayer runs an animation which could be divided in two parts. First, the layer rotates and shifts while darkening, leaving a blank space behind. It starts fading out while this motion occurs so that it’s gone the moment it overlaps the contiguous cube. When all cubes are gone, they animation “reverses” and for that, it keeps the rotation motion but fading in this time.
• The view that contains all these layers is rotated as well.
• The transform applied to the CAReplicatorLayer makes it look like each cube rotates from a different angle.

But wait, something’s missing. If there was 4 squares appearing and disappearing we would be aware of 8 rotations. That’s right, there are 3 of time fading out and 3 showing up. The missing one never fades out completely. You can see it better here:

In terms of simplicity, it’s better to have two differentCAReplicatorLayer . One will replicate 4 instances that will fade out and the other one will have 3 that will fade in. By adjusting the timing we’ll manage to have this half-fade-in-half-fade-out effect at the middle.

Implementation

Before we start with the coding, I encourage you to take a look at my repository in GitHub as I won’t be sharing all the code in this article. If you’re not sure how the code works or where you should put this code, take a look the previous article Demystifying iOS Animations, Part 1.

Okay so first let’s create the replicator layers and set them up:

let fadeOutDiamondLayer = CAShapeLayer()
let fadeInDiamondLayer = CAShapeLayer()
let fadeOutReplicatorLayer = CAReplicatorLayer()
let fadeInReplicatorLayer = CAReplicatorLayer()

fadeOutReplicatorLayer.instanceCount = 4
fadeOutReplicatorLayer.addSublayer(fadeOutDiamondLayer)

fadeInReplicatorLayer.instanceCount = 3
fadeInReplicatorLayer.addSublayer(fadeInDiamondLayer)

Don’t forget to tell the CAShapeLayer how it should render. fadeInDiamondLayer will be originally transparent:

fadeOutDiamondLayer.fillColor = UIColor.green.cgColor
fadeOutDiamondLayer.strokeColor = UIColor.green.cgColor

fadeInDiamondLayer.fillColor = UIColor.green.cgColor
fadeInDiamondLayer.strokeColor = UIColor.green.cgColor
fadeInDiamondLayer.opacity = 0

Add the layers to your custom view and make it rotate Double.pi / 4 radians:

layer.addSublayer(fadeOutReplicatorLayer)
layer.addSublayer(fadeInReplicatorLayer)

transform = CGAffineTransform(rotationAngle: .pi / 4)

Position the layers in the view so that they’re visible and take all the available space in the view:

let diamondFrame = bounds.applying(CGAffineTransform(scaleX: 0.5, y: 0.5))

fadeOutDiamondLayer.frame = diamondFrame
fadeOutDiamondLayer.path = UIBezierPath(rect: diamondFrame).cgPath

fadeInDiamondLayer.frame = fadeOutDiamondLayer.frame
fadeInDiamondLayer.path = fadeOutDiamondLayer.path

fadeOutReplicatorLayer.frame = bounds
fadeInReplicatorLayer.frame = fadeOutReplicatorLayer.frame

Set the rotation transform to CAReplicatorLayer:

fadeOutReplicatorLayer.instanceTransform = CATransform3DRotate(CATransform3DIdentity, .pi / 2, 0, 0, 1)

fadeInReplicatorLayer.instanceTransform = fadeOutReplicatorLayer.instanceTransform

We’re all set now for the animation. Why don’t we give another look? Based on the analysis we did above, we’ll need:

• opacity animation so that fadeOutDiamondLayer vanishes.
• another opacity animation so that fadeInDiamondLayer shows apps (remember it’s hidden).
• transform animation to rotate both diamond layers.
• fillColor animation to darken both diamond layers and give the user a better notice of the 3D rotation.
• Set up the timing and delay of all these animations so that they start at the right time.

Having all this into account, let’s start by defining some constants we’ll use to set up each of them:

let darkGreen: UIColor = UIColor(red: 0, green: 0.78, blue: 0.32, alpha: 1)

let totalDuration: Double =  4
let delayFactor = 0.2

let effectiveDuration = (1 - delayFactor) * totalDuration
let individualDuration = effectiveDuration / Double(2 * fadeOutReplicatorLayer.instanceCount)

totalDuration is the number of seconds our animation will take in completing plus the delay at the end before start repeating. effectiveDuration is the real duration of “each lap” and individualDuration is number of seconds each diamond will take to rotate.

As some of the animations (rotation, darkening and fading in/out) happen at the same time, we can use a CAAnimationGroup to set up some common properties such as duration or fillMode . Another use of CAAnimationGroup is to delay the next run of the animations it contains and that’s something we’ll use later.

Okay, why don’t we start with the rotation? Here is the code for that:

var transform = CATransform3DRotate(CATransform3DIdentity, CGFloat.pi, 0, 1, 0)
transform.m34 = -1 / 200

// Why not use transform.rotate.y?
let rotateAnim = CABasicAnimation(keyPath: "transform")
rotateAnim.fromValue = CATransform3DIdentity
rotateAnim.toValue = transform
rotateAnim.timingFunction = CAMediaTimingFunction(name: .linear)
rotateAnim.duration = individualDuration

Why are we using a CATransform3D rather than just using transform.rotation.y as keyPath and then setting the values in radians? What does the m34 property mean and why that value? Well, this is out of scope but rotations can be expressed as a matrix (see more info here) . The property m34 simply tells us the inverse distance to the projection plane z. By changing its value we’ll get a much more realistic rotation as we’ll be achieving a 3D-like perspective.

One more thing: we need to indicate the anchorPoint in both diamondLayers. This property sets where the rotation axis is placed:

The default is (0.5, 0.5) which means the layer will rotate around its center. We don’t want this as we need the layer to rotate around one of its edges so we need to change it. This will affect the final position of the layer as it’ll be shifted.

fadeOutDiamondLayer.anchorPoint.x = 1
fadeInDiamondLayer.anchorPoint.x = fadeOutDiamondLayer.anchorPoint.x

Once this is has been dealt with, we can go on with the fillColoranimation. In this case, we need a CAKeyframeAnimation as the we need the animation to start and end with the same value:

let colorAnim = CAKeyframeAnimation(keyPath: "fillColor")
colorAnim.values = [UIColor.green.cgColor, darkGreen.cgColor, UIColor.green.cgColor]

colorAnim.keyTimes = [0, 0.5, 1]
colorAnim.duration = individualDuration

As for the opacity animation, we’ll use a CAAnimationGroup as a wrapper of a CABasicAnimation . This way, the animation last value will be still rendered as the group (used as a wrapper) is delaying it.

let fadeOutAnim = CABasicAnimation(keyPath: "opacity")
fadeOutAnim.fromValue = 1
fadeOutAnim.toValue = 0
fadeOutAnim.fillMode = .forwards
fadeOutAnim.duration = individualDuration

let fadeOutWrapper = CAAnimationGroup()
fadeOutWrapper.animations = [fadeOutAnim]
fadeOutWrapper.duration = effectiveDuration / 2

This wrapper is a key of the animation as it wouldn’t work unless we used it. Finally, we need to add all this animations to another group so that they’re delayed till the cube has showed up again. We’ll set an instanceDelay for the replicator layer as well:

let fadeOutAnimGroup = CAAnimationGroup()
fadeOutAnimGroup.animations = [fadeOutWrapper, rotateAnim, colorAnim]
fadeOutAnimGroup.duration = totalDuration
fadeOutAnimGroup.repeatCount = .infinity

fadeOutReplicatorLayer.instanceDelay = individualDuration
fadeOutDiamondLayer.add(fadeOutAnimGroup, forKey: nil)

THAT’S IT! Now we have the first part of the animation, the fading out of the diamonds. Now we need to do the same to fade in the hidden cubes:

let fadeInAnim = CABasicAnimation(keyPath: "opacity")
fadeInAnim.fromValue = 0
fadeInAnim.toValue = 1
fadeInAnim.fillMode = .forwards
fadeInAnim.duration = individualDuration

let fadeInWrapper = CAAnimationGroup()
fadeInWrapper.animations = [fadeInAnim]
fadeInWrapper.duration = fadeOutWrapper.duration

let fadeInAnimGroup = CAAnimationGroup()
fadeInAnimGroup.animations = [fadeInWrapper, rotateAnim, colorAnim]
fadeInAnimGroup.duration = totalDuration
fadeInAnimGroup.beginTime = CACurrentMediaTime() + effectiveDuration / 2
fadeInAnimGroup.repeatCount = .infinity

fadeInReplicatorLayer.instanceDelay = individualDuration
fadeInDiamondLayer.add(fadeInAnimGroup, forKey: nil)

The only difference is we’re delaying when it starts to run so that we get effect we’re looking for. Note we’re creating a newopacity animation and not reusing the existing one. This is because we’re adding it to a CAAnimationGroup and not directly to the layer so reusing it might affect the previous animation.

If you’ve got to this point you’ll hopefully have a beautiful spinner ready to use in your App. I hope helped you understand layer animations and give you some insights about how to divide and structure your animations.

Demystifying iOS Animations, Part 2 was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

How many times have you struggled with an animation in your App? You had this whole idea of how to do it, you’d seen some tutorials and you knew the basics. How come it isn’t working this time? How frustrating, isn’t it? I mean, it can’t be that hard: it’s one of the keys for an App to look friendly, different, appealing… all in all, to gain an audience for your App.

Here is what’s happening, my friend:

The problem when coding an animation is not the framework itself. The problems is YOU and the way you interpret how the animation you want to make actually works, how you divide the task into simpler tasks.

WHAT!!!??? I ain’t no problem, dude. I’m done with this…

Okay, that might’ve been a little rough, my apologies. What do I mean by this? Well, I recently ran into this beautiful library, SpinKit, written in CSS. There are several implementations of this library for iOS. As a challenge, I wanted to code it myself. I ended up losing a bunch of time messing around because I didn’t think it through and I impulsively went for it without thinking of how it actually worked every single animation.

The results of my experiment you can find here. This series of tutorials are based in what I learned from this experience. We’ll introduce a bit of CoreAnimation and then we’ll get to code some of the animations in SpinKit.

View vs Layer animations

Let’s give this a quick look to understand the difference between them and when to choose one or another. What’s a View Animation?

// Inside custom View
UIView.animate(withDuration: 0.4) { [weak self] in
    self?.transform = CGAffineTransform(scaleX: 2, y: 2)
}

Here above the size of the view is doubling as a result of the View Animation. Below you can find the same effect by means of a layer animation:

// Inside custom View
let anim = CABasicAnimation(keyPath: "transform.scale")
anim.fromValue = 1
anim.toValue = 2
anim.duration = 0.4
anim.isRemovedOnCompletion = false
anim.fillMode = .forwards
layer.add(anim, forKey: nil)

What’s the difference between both animations? In the first one we are actually changing the size of the view whereas in the second one we are changing the size of the layer. But not the size of the view!

What does this mean? Imagine your custom view is a UIButton. If you double the layer size you might expect the interaction surface to have doubled too, but that’s not the case. Actually, have a look at the properties isRemovedOnCompletion and fillMode . In order for the layer to keep the animation at its final state we needed to say: “hey, don’t remove after you’re finished” and “keep your final state.”

All in all, UIView is a wrapper of CALayer. All the animations you can make for UIView you can make for CALayer but not the other way around. Among the UIView properties you can animate these are the most common:

• frame (never animate its bounds property)
• backgroundColor
• alpha (the property isHidden isn’t animatable)
• transform (I like this one a lot. Usually it’s the one I use for its simplicity. You’ll see it soon)
• constraints (don’t forget to call layoutIfNeeded method on the view that holds them)

I rather use layer animations as they provide many more properties to animate, they are technically more efficient and have a better performance than view animations, although it’s barely noticeable. Also, if you want to do “magic” in iOS you’ll have to end up learning about CoreAnimation one way or another.

What can you animate on CALayer? Basically, any property exposed in its interface:

• opacity
• frame
• cgPath
• backgroundColor

You just have to use the name of the property as the keyPath when instantiating the animation.

Working with CALayer

CALayer exposes a great deal of properties so we’ll just talk about those which we’ll use through this tutorial. First of all, let’s instantiate a CALayer , position it inside your custom UIView and add it as a sublayer:

// 1
let myFirstLayer = CAShapeLayer()

// 2.1
myFirstLayer.frame = bounds

// 2.2
myFirstLayer.bounds = bounds
myFirstLayer.position = CGPoint(x: bounds.width / 2, y: bounds.height / 2)

// 3
layer.addSublayer(myFirstLayer)

What’s have we just done?

1. Instantiate a CAShapeLayer . This is a subclass of CALayer and it’s the one you’ll probably use the most. There are other interesting subclasses as we’ll see such as CATextLayer to render text, CAReplicatorLayer to replicate a layer and CAEmitterLayer to render a system of particles.
2. Set the layer frame, that is its size and origin. This can be done in two different ways. Either you set the frame of the layer or its bounds and position . Don’t be confused by the last one. It sets the layer position, not its origin.
3. Add the layer to an instance of UIView which is the class in charge of drawing and rendering in iOS.

Facts to have in mind:

• Instantiate and add the layer as sublayer of the view just once. I normally do it in viewDidMoveToWindow method, although you could also use an init.
• Set the layer frame when the view has been rendered and laid out, otherwise the result won’t be as expected. You should code this part in layoutSubviews method.

How do we actually tell the CAShapeLayer what we want to render? We can either tell the layer to draw an image:

let someImage: UIImage = ...
myFirstLayer.contents = someImage

Or we can use a path to define the layer:

myFirstLayer.path = UIBezierPath(ovalIn: rect).cgPath
myFirstLayer.fillColor = UIColor.blue.cgColor

Now that we have understood how layers work, let’s move on to animations.

Double bounce spinner

Have a look at this first spinner and try to figure out how it works.

As I said at the beginning of the article, the key for this is to figure out the best way to accomplish a “complex task” by dividing it into simpler ones and synch them so that they beautifully work together as expected. Taking a look at the GIF, this spinner is composed by two concentric circles. When the outer circle shrinks, the inner one expands and viceversa.

Let’s get to work!. In your custom view add the properties:

private var outerCircleLayer = CAShapeLayer()
private var innerCircleLayer = CAShapeLayer()

Then in the didMoveToWindow method, let’s add these two layers to the view layer and set their style.

layer.addSublayer(innerCircleLayer)
layer.addSublayer(outerCircleLayer)
innerCircleLayer.fillColor = UIColor.blue.cgColor
outerCircleLayer.fillColor = UIColor.blue.cgColor

Set their content and position in the view inside layoutSubviews:

outerCircleLayer.path = UIBezierPath(ovalIn: bounds).cgPath
outerCircleLayer.frame = bounds

/* We're using a CGAffineTransform to easily define innerCircleLayer
path rect as half the size of outerCircleLayer bounds */

innerCircleLayer.path = UIBezierPath(ovalIn: outerCircleLayer.bounds.applying(CGAffineTransform(scaleX: 0.5, y: 0.5))).cgPath

innerCircleLayer.frame = CGRect(origin: CGPoint(x: bounds.width / 4, y: bounds.height / 4), size: innerCircleLayer.path!.boundingBox.size)

Note how we defined innerCircleLayer bounds. Isn’t it cool how easy it is to modify an existing CGRect? No need for calculations, just apply a CGAffineTransform to scale, rotate, or translate a CGRect . All this as part of the CoreGraphics framework.

And finally, the animation itself. The cool thing about layer animations is that you can reuse them as they’re copied when added to a layer. That way you can just change some of its properties and use the same object for another layer:

// 1
let anim = CABasicAnimation(keyPath: "transform.scale")
anim.fromValue = 1
anim.toValue =  0.5
anim.timingFunction = CAMediaTimingFunction(name: .easeIn)
anim.duration = 0.4

// 2
anim.autoreverses = true
anim.repeatCount = .infinity

// 3
outerCircleLayer.add(anim, forKey: nil)

outerCircleLayer.add(anim, forKey: nil)

// 4
anim.fromValue =  0
anim.toValue =  1

innerCircleLayer.add(anim, forKey: nil)

1. Create the animation to scale the outer circle layer. Set bothfromValueand toValue properties so that its size is divided by 2.
2. Set it as reversible and make it repeat endlessly.
3. Add the animation to the outer circle. The animation is copied and you’re free to change your CAAnimation instance and reuse it.
4. Reuse the animation for the inner layer. Change its fromValueand toValue so that it starts with a size of zero and then grows till its real size.

Simple, right? We’ve analysed the animation and divided it into two different animations which run at the same time, with no delay between each other. Let’s look at another example now.

Wave spinner

In this case, the spinner is composed by five parallel bars which increment their size with a delay between each other. Finally, the whole animation takes some time before starting over.

One might think of instantiating five different layers but for this case we’re going to introduce the CAReplicantLayer . This kind of CALayer replicates each of its sublayers and applies some “offset accumulative transformation” to each instance. Among these transformations you have:

• instanceRedOffset , instanceGreenOffset and instanceBlueOffset to change the color of the layer.
• instanceTransform to rotate, scale or translate the layers.
• instanceDelay to apply some delay to the animations run by its sublayers.

The code needed for this animations looks like this:

// 1
let barsReplicatorLayer = CAReplicatorLayer()
barsReplicatorLayer.instanceCount = 5

let barLayer = CAShapeLayer()
barLayer.fillColor = UIColor.blue.cgColor

// 2
barsReplicatorLayer.addSublayer(barLayer)
layer.addSublayer(barsReplicatorLayer)

let barRect = CGRect(origin: .zero, size: CGSize(width: bounds.width / 6, height: bounds.height))
barLayer.path = UIBezierPath(rect: barRect).cgPath

barLayer.bounds = barLayer.path!.boundingBox
barLayer.position = CGPoint(x: bounds.midX, y: bounds.midY)

// 3
barsReplicatorLayer.instanceTransform = CATransform3DTranslate(CATransform3DIdentity, CGFloat(barsReplicatorLayer.instanceCount) * barRect.width / 4, 0, 0)

barsReplicatorLayer.frame = bounds

1. Instantiate CAReplicatorLayer and set the number of instances it has.
2. Pay attention to this: the layer to be replicated MUST be added as a sublayer of your CAReplicatorLayer instance whereas it’s the latter that’s added as sublayer of the view.
3. Finally, each instance must be shifted along the X-axis. This translation looks slightly different in code from the one found in CoreGraphics with CGAffineTransformbut it essentially has the same effect.

Time for animations! Keep in mind that:

• The animation is going to be shared by all five instances of the replicator layer.
• When the animation completes for one instance, it should’t start over right away but “wait” for the rest to finish.

// 1
let anim = CAKeyframeAnimation(keyPath: "transform.scale.y")
anim.values = [0.4, 1]
anim.keyTimes = [0.5, 1]

anim.duration = 0.5
anim.autoreverses = true
anim.repeatCount = .infinity

// 2
anim.fillMode = CAMediaTimingFillMode.backwards
anim.timingFunction = CAMediaTimingFunction(name: .easeIn)

barLayer.add(anim, forKey: nil)

// 3
barsReplicatorLayer.instanceDelay = anim.duration / Double(barsReplicatorLayer.instanceCount)

1. We introduce CAKeyFrameAnimation . This CAAnimationsubclass interpolates the values at the relative keyTimes to generate the animation. In this case, we’re using it to delay the beginning of the animation.
2. As we’re starting the animation setting each instance to be 0.4 times its original size, we need to “fill” the animation in a way the layer is rendered with this scaled size. Otherwise, it would make a weird glitch.
3. Finally, we set instanceDelay so that each layer starts at a different time.

Nice! If you made it this far you should have two beautiful spinners ready to use. In the next chapter “Demystifying iOS Animations. Part 2”, I’ll give you more insights about CoreAnimation framework by implementing a new spinner.

Demystifying iOS Animations, Part 1 was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why would we think of creating our own library?

At ElConfidencial we follow Scrum and, truth be told, my Product Owner (PO) and good friend, Juan, is quite picky and is often telling me about design patterns and solutions other great Apps implement. He wanted something very specific and unique as a walkthrough or show case for new features we were to release in future versions and this is how it all started.

Honestly, I first started by googling “show case”, that’s what every good developer would do. My mom would call me lazy for that, I just applied one of my favorite principles in programming: KISS (Keep it simple, stupid). This is actually meant for new features: don’t try to foresee the future, just meet your requirements because, as Clint Eastwood would say in The Bridges of Madison, “tomorrow is promise to no one”. The same way we could extrapolate this principle and use it here: if there’s something out there that works, it’s tested and it’s free to use, why would you take any time on doing it yourself, “stupid”? We could come up with a couple of reasons:

• There’s nothing similar to what you’re looking for.
• You cannot customize the library you found to meet your PO expectations.

The latter was our case. The results in Google showed me my PO wouldn’t like the options I’d give him and most importantly: the cost of developing this library was assumable for us.

What made us even think of releasing it?

When I saw the face of my PO in the Review that Friday when we showed him the result of that Sprint I knew we’d done a wonderful work. And I don’t wanna sound cocky or bragging but we had.Don’t misunderstand me, it’s good to be conscious about your own mistakes… but also about your successes and we were very happy with the results. So happy I’d say that, why not, we thought of making the library public.

Was our framework better than the ones already in the market? Probably not. Was it clean code that we published, fully tested and had high performance? Let me doubt about it.

Why did we still publish it? We were proud of ourselves and we had something that was different from other available products. We’d been always using others’ code and we wanted to contribute to the community, that’s the goal of all this, right? The same way we’d been making use of third party libraries, others might find ours interesting and use it in their projects. But most importantly: we wanted to improve our skills as developers. Hearing from other developers feedback would help us face new issues, improve the product as well as achieve new knowledge.

Have some code that might be useful to others?

Here are some steps to follow if you wanna publish it. The first thing to do is refactoring your code, making it clear to the rest. This isn’t just about releasing a first version of your library and forgetting about it: other developers might want to contribute and pull request your repository so making it legible and easy to understand isn’t such a bad idea. As Uncle Code would say, there’s no better documentation than the code itself. Extract new methods and classes, rename variables and functions, avoid repetition of code… You probably know what I’m talking about if you’ve happened to take a look at Clean Code. However, even if your code is pretty understandable… comments will kill nobody if they’re useful and constructive.

But wait, how will your prospective users know how to use it? Will they read the large documentation you’re preparing for them? Speaking for myself, I always try to find a quick example to follow and then rely on the usual hotkey most IDE’s have: control + space. This usually shows some quick documentation about the public methods and properties of the class. So how does this work? Is this magic? I’m sure you’ve heard about javadocs or any other kind of markdown. Most languages have their own and it’s basically a set of “escaping expressions” contained in a comment that an IDE knows how to interpret. For example, below I’m describing the class constructor and its parameters as well as remarking some requirements for the parameters:

The next step is to create a git repository and share your code, make it public. The most widely used repositories are GitHub and BitBucket. I personally use the former for personal projects and public repositories whereas I use the latter for private ones so you’ll most probably end up using GitHub.

Besides the repository, you’ll need to add several extra files to your project in order to provide meta information about your repository. The first one is a LICENSE file which is usually requested when creating a repository in GitHub. Wait, a license? I don’t know anything about the current legislation.

Don’t panic, a LICENSE file is just a formality. Here’s a good resource to help you understand why you need a license and what’s the best one for your project. The most common licenses are MIT and APACHE.

Once you’ve chosen the most appropriate one for you, it’d be a good idea to add a README. A README is the file where you’ll explain what your framework does, why it is so special, which features it provides you with and how it works. Basically, it’s like a quick introduction to your framework. And guess what? It uses its own markdown language! There’s a good tutorial about it here. Additionally, it’s very common to complete this file by adding badges that describe certain aspects of your project like the last version, support, … Take a look here.

You won’t usually need a very extensive documentation but if that’s the case, you might want to take a look at the Wiki option of your repository to structure your API in sections.

Optionally, there’s an extra file you can add which is the CHANGELOG file. This helps developers know about new features and fixes to bugs that new versions of your framework introduce. This is optional as I said but it usually gives you more visibility in a package manager repository. Hold on, is there more about it? What’s a package manager repository? Well, you have so far done the hardest part: you’ve developed a framework, you’ve generated an API and documented it, you’ve uploaded your project to a public git repository… nonetheless, how’s anyone going to use it? Are they suppose to just download it and manually install it? I mean, that could be an option… but that’s not elegant at all. That’s why there are different places depending on the platform you’re coding for where you can find stored thousands and thousands of third party libraries which you can easily reference by means of a simple file, such as pod in CocoaPods and pom.xml in Maven. These two platforms are actually package managers which allow you to quickly install in your project any library you might need.

You should try to support as many package managers as you can. After all, you’re trying to get to as many users as possible so it makes sense your library shows up in the more package managers the better.

Last but not least, marketing comes to play: you’ll need to let developers know about your product. No one will use it if they don’t know it exists, so use everything in your hand to make it visible:

• StackOverFlow is a must. Your product will probably answer some other developer’s question.
• Blogs. Again, depending on your platform you’ll need one or another. We used Android Arsenal to advertise our Android version.
• Social Networks. No, I’m not talking about Instagram or Snapchat… although you might be surprised. I was actually talking about LinkedIn. Everyday I read a bunch of articles about other people’s projects and experiences so I guessed a mention to this achievement of ours in my wall would perfectly fit.
• This blog itself, Medium. After all, if you’ve come so far you’ve probably got a good idea about what we’ve done and isn’t that the purpose?

Conclusion

You should not be afraid of sharing what you’ve coded as the feedback you’ll get will just help you improve your code your product while making other developers lives easier. You’ll also learn about the experience.

The steps to release your framework might seem tough but it’s a once-in-a-lifetime thing that will give you more credit as a developer and help you in your career.

Share your code, make it open source was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Todos cometemos errores y, si además programamos, vamos a generar bugs. Pero también tenemos a nuestro alcance herramientas para limpiar nuestro código, detectar a tiempo los posibles fallos y estar seguros de que no cometeremos el mismo error dos veces.

Si queréis saber más sobre cómo escribir buen código en R:

Y un vídeo de cómo trabajar con Test-Driven Development en R:

Testeo y depuración en R was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Global Editors Network (GEN) y El Confidencial, con el apoyo de Google News Lab, reunieron en Madrid durante los días 18 y 19 de enero a algunos profesionales de los medios comunicación para desarrollar prototipos periodísticos enfocados a mejorar la cobertura de las noticias de última hora.

El equipo ganador de la competición Editors Lab Madrid fue La Sexta/Maldita.es con su proyecto Breaking Hoaxes.

Breaking Hoaxes es una webapp para editores que permite acceder a información verificada en momentos de crisis. Además, posibilita desmentir noticias falsas casi en tiempo real. La webapp recoge información de varias fuentes -redes sociales, páginas web, notas de prensa institucionales- y las clasifica en información procedente de fuentes oficiales, fuentes fiables o información sobre el terreno. Toda esta información se almacena en una base de datos que permite realizar búsquedas rápidas. De esta forma, al recibir datos nuevos de fuentes desconocidas, el editor puede corroborar si esa información ha sido confirmada por otras fuentes de peso y cruzarla con docenas, incluso cientos de fuentes diferentes.

David Fernández, el desarrollador del equipo ganador, afirmó tras el evento:
‘Uno de los problemas principales que tratamos de resolver es la dificultad de filtrar toda la información que los periodistas reciben durante un evento muy importante de última hora. En ese momento es muy complicado saber qué informaciones son ciertas y cuáles no. Por tanto, nuestro trabajo pretende eliminar el ruido y las noticias falsas para facilitar la labor del periodista’.

El hackathon comenzó con una seria de charlas el pasado miércoles 17 de enero en Growth Space Barrabes. En ella participaron Alejandro Laso (El Confidencial), David Dieudonné (Google News Lab), Alvaro Ortiz (Populate) y Nathalie Malinarich (BBC). Los ponentes debatieron sobre cómo mejorar la cobertura de las noticias de última hora y destacaron las mejores prácticas y herramientas para ello.

Los once equipos participantes — compuestos por periodistas, desarrolladores y diseñadores — tuvieron dos días para experimentar y crear sus prototipos para mejorar la experiencia de redactores y lectores en la cobertura de las noticias de última hora.

El jurado, formado por Ana Ormaechea (Cuonda.com), Eva Morell (Flipboard Inc.), Nathalie Malinarich (BBC News), Rafael Höhr (Prodigioso Volcán), Ramón Puchades (Metrópolis Comunicación) y Sarah Toporoff (Global Editors Network), seleccionaron los prototipos mejor ejecutados antes de premiar a Breaking Hoaxes de La Sexta/Maldita.es.

Nathalie Malinarich destacó algunas de las claves del prototipo ganador:
‘Fue una decisión difícil porque todos los proyectos alcanzaron un alto nivel de ejecución. Breaking Hoaxes piensa en el usuario, en este caso el periodista, y le permite verificar las historias en tiempo real. Una idea pensada para el móvil, muy fácil de utilizar y muy necesaria’.

Las menciones especiales del jurado se otorgaron a los equipos de Ara por su prototipo Ara Stories y a El Confidencial por Funnel. El premio del público fue también para Ara.

Si quieres ver las fotos del evento y toda la información sobre los proyectos desarrollados durante El Confidencial Editors Lab haz click en los siguientes enlaces:

Proyectos El Confidencial Editors Lab 2018

Fotos de El Confidencial Editors Lab 2018

El equipo de La Sexta/Maldita.es competirá en la final mundial del Editors Lab Final que tendrá lugar durante la conferencia GEN Summit 2018 en Lisboa, del 30 de mayo al 1 de junio, enfrentándose al resto de equipos ganadores de la VI edición del programa.

GEN Summit 2018 tendrá lugar en el corazón de Lisboa, en el histórico Pátio da Galé, bajo el lema ‘Towards the augmented newsroom’. Los tres días de conferencias explorarán el rol de la inteligencia artificial en las redacciones y los medios de comunicación. Además, se promoverán debates sobre cómo los medios pueden servirse de la inteligencia artificial para maximizar sus resultados e impacto.

Breaking Hoaxes: proyecto ganador de El Confidencial Editors Lab 2018 was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Los días 18 y 19 de enero tendrá lugar El Confidencial Editors Network, ‘hackathon’ sobre innovación periodística, organizado por Global Editors Network (GEN) y El Confidencial, con el apoyo de Google News Lab. El evento reunirá a algunos de los mejores profesionales de los medios nacionales para desarrollar herramientas periodísticas que mejoren e innoven la cobertura de las noticias de última hora.

¿Cómo pueden mejorar las coberturas de última hora los medios de comunicación? Hablamos de coberturas de desastres naturales, terrorismo, deportes, política… ¿Qué herramientas pueden facilitar una cobertura rápida y precisa de este tipo de acontecimientos?

Las jornadas darán comienzo el miércoles 17 de enero en un evento previo en el espacio Growth Space Barrabes, donde ponentes como Alejandro Laso, de El Confidencial, David Dieudonné, de Google News Lab, Fernando Blat, de Populate, y Nathalie Malinarich, de BBC News, compartirán sus experiencias sobre el terreno, destacarán las mejores prácticas y herramientas de las que se pueden servir los periodistas para cubrir los temas de última hora y compartirán los mejores ejemplos en este tipo de coberturas. A buen seguro, una ayuda que será de inspiración para los participantes, ya que les será útil para definir sus ideas y construir sus prototipos, y para los asistentes y profesionales del sector.

Los participantes del ‘hacakthon’ tendrán dos días para construir sus prototipos de innovación. Los equipos estarán formados por un periodista, un desarrollador y un diseñador. Al final del evento, mostrarán sus prototipos a un jurado de expertos de los medios de comunicación. Este panel de expertos elegirá el prototipo ganador y, por tanto, qué equipo recibirá una invitación para participar en la final mundial del Editors Lab durante el GEN Summit 2018 de Lisboa, entre el 30 de mayo y el 1 de junio de 2018.

Los medios de comunicación que participarán en esta nueva edición de El Confidencial Editors Lab son:

El Diario de Navarra
NacióDigital
Ara.cat
Cadena SER
DataLab Madrid
El Confidencial
Videona
CCMA
Vocento
Mèdia.cat
Maldita.es

El jurado estará compuesto por Ana Ormaechea, de Cuonda.com, Eva Morell, de Flipboard, Rafael Höhr, de Prodigioso Volcán, Ramón Puchades, de Metrópolis Comunicación, Nathalie Malinarich, de BBC News y Sarah Toporoff, de Global Editors Network.

El evento se podrá seguir por Twitter a través del ‘hashtag’ #EditorsLab.

El Confidencial organiza por segunda vez la edición española del #EditorsLab was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

El equipo de innovación de El Confidencial lanza una actualización de su aplicación de elecciones para seguir toda la actualidad informativa de los comicios en Cataluña: la última semana de campaña, el seguimiento del escrutinio electoral durante la noche del 21D y los pactos entre las formaciones que puedan dar origen a un nuevo gobierno en Cataluña.

• Descarga la app de Elecciones 21D en la tienda App Store (Apple).
• Descarga la app de Elecciones 21D en la Play Store (Android).

La aplicación tiene tres entornos y alguna funcionalidad interesante para no perderse ningún detalle de lo que suceda este 21D: un entorno de noticias, donde los lectores podrán filtrar los artículos según los distintos partidos; uno de encuestas, que permitirá acceder a los sondeos y una media de encuestas; y el de resultados, con un seguimiento del escrutinio en tiempo real, con el reparto del Parlament y una gráfica por bloques (independentistas vs. constitucionalistas).

Como funcionalidad destacada, los lectores de El Confidencial podrán suscribirse a nuestras notificaciones personalizadas por formaciones políticas desde la pantalla de configuración. Los usuarios podrán recibir alertas con informaciones que estén centradas en sus partidos políticos de interés, o bien suscribirse a las notificaciones por bloques (seguir todos los partidos que apuestan por la independencia de Cataluña o bien por el mantenimiento de la constitución y la unidad de España).

Las notificaciones generales estarán enfocadas a enviar alertas sobre sondeos y encuestas durante la campaña y los resultados de los comicios una vez cerrados los colegios electorales del próximo 21D.

La aplicación de El Confidencial Elecciones 21D está disponible ya para su descarga gratuita en la Google Play Store para todos los dispositivos Android y en la App Store para dispositivos iOS como iPhone e iPad.

Elecciones 21D, la app para seguir campaña, resultados y pactos en Cataluña was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hoy en día Blockchain es una de las tecnologías más buscadas en los motores de búsquedas en 2017 y está llamada a ser la tecnología más disruptiva de los últimos años. Por ello que desde El Confidencial nos estamos informando sobre dicha tecnología a través de cursos, charlas y meetups.

El jueves pasado tuvimos la suerte de contar en nuestras oficinas con la presencia de Covadonga Fernandez, fundadora de BlockchainMedia, que nos vino a dar una charla sobre cómo puede influir el tema de Blockchain en los medios de comunicación. Durante su charla se introdujeron conceptos como son el internet del valor, la tokenización, las ICOS … y se comentaron ciertos ejemplos de empresas que ya están introduciendo blockchain en el ecosistema de los medios de comunicación como son publiq, steemit, brave y decent. Al final se generó un debate interesante sobre el posible encaje de esta tecnología en los medios de comunicación.

Unos de los puntos que nos quedó claro es que Blockchain va mucho más allá de las criptomonedas y su uso se está extendiendo practicamente a todos los sectores, creándose cada mes cientos de startups en el mundo con productos globales basados en esta tecnología, y cuyas inspiraciones no tienen límite

Otro de los puntos que nos quedó claro es que su principal uso es el de eliminar intermediarios gracias al funcionamiento del propio protocolo y la configuración de la red de nodos que conforman cada blockchain, a través de lo cual se establece la confianza necesaria entre desconocidos, concepto clave en el éxito del uso de Blockchain.

El tema candente llegó a la hora de hablar de Tokenización y cómo aplicar este concepto a los medios de comunicación, si tiene sentido o no crear tu propio ecosistema económico, y los pros y contras de financiar proyectos blockchain a base de ICOs y su preventa de tokens.

Desde el laboratorio creemos que Blockchain es una tecnología a la cual poner foco y seguramente, más bien pronto que tarde, acabemos experimentando con ella a través de algún proyecto de I+D.

Os mantendremos informados :)

Blockchain en los Medios was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nuevas versiones de El Confi: registro y consumo de datos en iOS y servicio del tiempo y geolocalización en Android

El Confi, la aplicación hermana de El Confidencial, tiene nuevas versiones para sus testers tanto en iOS como en Android. Los usuarios de iPhone y iPad podrán personalizar la aplicación en función del consumo de datos y los de Android dispondrán de información meteorológica en tiempo real, noticias relacionadas en editoriales de Opinión y otras mejoras.

El Confidencial sigue dando pasos importantes en la evolución de uno de sus productos móviles estrella: su nueva aplicación de noticias, con una navegación más sencilla y cómoda para nuestros lectores y una experiencia más personalizada. Con el tiempo, el objetivo de este diario y su equipo de innovación, El Confidencial LAB, es avanzar en la posibilidad de que los usuarios puedan adaptar la aplicación a sus gustos e intereses. El Confi, la aplicación hermana de El Confidencial, seguirá siendo un banco de pruebas excepcional para funcionalidades que, al principio, sean experimentales.

El Confi, tanto en su versión en iOS como en Android -puedes descargarlas y probarlas en los enlaces-, ya disponen de dos versiones actualizadas: los usuarios de Apple disfrutarán de la adaptación de la vista de las noticias en portada y portadas de sección en función del consumo de datos, una mejora que necesitará registro y login dentro de la aplicación. El login está disponible, por ahora, con la red social Facebook o bien a través de un correo de Google. Los usuarios Android encontrarán novedades como información meteorológica, contenido relacionado en Opinión, publicidad en interiores y secciones, cambios de diseño y la mejora en la visualización de gráficos e SVG con información de datos.

• Descarga El Confi en la App Store (iPhone y iPad).
• Descarga El Confi en la Google Play (dispositivos Android).
• Descarga la app oficial de El Confidencial en la App Store.

¿Vistas en función del consumo de datos?

En la versión para iPhone y iPad, los lectores de El Confidencial podrán reducir el consumo de datos de la app a través de la forma en la que verán las noticias en portada y portadas de sección. La nueva versión de El Confi en iOS permitirá que los usuarios puedan escoger una vista por defecto con imágenes en tamaño grande, otra con imágenes pequeñas y una tercera sin fotos. Esta funcionalidad no afecta al interior de las noticias.

Para aprovechar esa ventaja, es necesario que los lectores de El Confidencial estén registrados y logados dentro de la aplicación. Para hacerlo podrán usar su cuenta en Facebook o un correo electrónico de Google. En ambos casos es un proceso rápido y sencillo. En un futuro, algunas de las ventajas de personalización de la aplicación necesitarán del registro, en gran parte porque nos exigirá a conocer mejor los gustos de nuestros lectores.

Novedades en Android

Los avances en El Confi en Android son el paso previo al lanzamiento de la actualización de la aplicación de noticias de El Confidencial en la Google Play. El pasado 4 de agosto publicamos la gran actualización de la app para iOS, y ahora le toca el turno a los lectores de este diario en dispositivos Android. En esta versión de la aplicación hermana El Confi, los lectores encontrarán novedades interesantes que son un movimiento natural en ese proceso de cambios y de mejora de la aplicación oficial.

Entre las novedades, los lectores de El Confidencial dispondrán de un servicio de información meteorológica en tiempo real y vinculado a su geolocalización. Es un servicio que evolucionaremos asociado a otro tipo de ventajas. La información estará disponible en un entorno propio a través del menú y también a través de un indicador en la portada de la aplicación donde se le mostrará el lugar donde se encuentra, la temperatura y si el día está soleado, se encuentra nublado o bien se espera lluvia.

Además, esta última versión de El Confi en Android incorpora la posibilidad de leer otros artículos relacionados en los editoriales de Opinión -noticias que hayan sido escritas por la misma firma-, algunos cambios de diseño para mejorar la jerarquía de la información en portada y la incorporación de una publicidad más respetuosa con el lector dentro de las noticias y en portadas de sección. También es importante la solución de algunos errores detectados por los propios testers durante el uso de la primera versión.

Nuevas versiones de El Confi: registro y consumo de datos en iOS y servicio del tiempo y… was originally published in ECLaboratorio on Medium, where people are continuing the conversation by highlighting and responding to this story.