When I started to work as a developer, I remember that my fellow programmers used to hate JavaScript.
I myself was not a real fan of this incredible language.
That’s why I decided to study it more deeply.
During my studies, one thing came clear to me:

JavaScript is one of the most powerfull languages I ever seen.

But… There is always a but.

Its API is terrible.

But since JavaScript is a language ready to be extended, we solve this problem using some great tools like jQuery or Undescore.js, that make the JavaScript API be really beautiful.

JavaScript is a really powerfull language, so, we can program in JavaScript using a lot of paradigms.

Let’s talk about how to implement your JavaScript code using Object Oriented Programming.

JavaScript and OOP

To understand how to make OOP code using JavaScript, we first need to understand how the variable this works.

console.log(this);

If you run this code, the console will log to you an instance of the DOM Window object representing the window of your browser (this will change if you are running this on a Node.js server).

That means that in the global scope this is the Window object.

Okay, so what if we run this code:

function some(){

console.log(this);

}

some();

If you run, you will see that again Window is logged.

That means that the this of a function is the same this from the scope where the function is defined.

So, how can I create an object and make its this referencing it?

Creating a JavaScript Object

var myObj = {

some: function(){console.log(this);}

};

myObj.some();

Now we are getting somewhere, When you run this code, it’s an Object that is logged, not a Window Object, just an Object.

If you inspect the logged object, you will se that it has a property called some. This property is a function, the function that we called.

Once we have an object, we can add properties to it:

myObj.coolProperty = “JavaScript rocks”;

And also retrieve these properties:

console.log(myObj.coolProperty)

console.log(myObj[‘coolProperty’]

Note that the properties are like keys of a map. You can retrieve them using the [] syntax, so, you can pass the properties as parameters.

var myObj = {

func1: function(){console.log(“Called 1″)},

func2: function(){console.log(“Called 2″)}

}

myObj[“func2″]();

This will prompt “Called 2″.

Creating constructors

There is another way to create an object:

function MyObject(){

this.some = function(){console.log(this);};

}

myObj = new MyObject();

console.log(myObj.some());

We just created a constructor. If you run this code, you will se now MyObject at the console.

Since we created this object using the function new, this was redefined from Window to MyObject.

Thats why when we make this.some = function(){console.log(this);}; inside the function MyObject the function is defined inside our MyObject instance.

So what happens if we run this code:

function MyObject(){

this.some = function(){console.log(this);};

}

myObj = MyObject();

console.log(myObj);

some();

Now, we don’t used new when we invoked MyObject function. That means that inside the function this remains to be Window.

Wich means

console.log(myObj);

log undefined. We don’t return anything from MyObject function, so myObj is undefined.

And that’s why we can invoke some at the global scope and it log Window.

So its very important to remember that you have to use new when you are creating an Object from a Constructor.

Creating Public Methods

All right, now we know how to create objects and even how to create this objects from constructors.

But how can we add methods to a Object definition.

Let’s see two ways.

Using properties:

function MyObject(){

this.method = function(){console.log(“I’m a public method”);};
}

new MyObject().method();

or

var myObject = {

method: function(){console.log(“I’m a public method”);}

}

myObject.method();

In both examples we defined a property in an object that is a function. So we can use this function like a method.

Using prototype

function MyObject(){};

MyObject.prototype.method = function(){console.log(“I’m a public method”);};

new MyObject().method();

We just created a construtor for MyObject, after that, we defined in the prototype of our constructor an attribute that is a function.

Every attribute defined in the prototype of an object, is automatically, accessible by the instances of that object.

Using Inheritance

We can use prototype to define Inheritance.

function Animal(){};

Animal.prototype.eat = function(){console.log(“eating…”);};

function Dog(){};

Dog.prototype = Animal.prototype;

new Dog().eat();

Setting the prototype of the Constructor of a Dog as the prototype of Animal makes that our Dogs to have the method eat.

Defining private members

Well, you may also want to create properties and methods that are not public. This is really easy.

Every variable in JavaScript has function scope

function a(){

var b = 1;

console.log(b);

}

a();

console.log(b);

This code will log 1 and then will log undefined. That’s why when we use the word var we are saying that the variable b exists only inside the function a.

Since our objects are functions, we can use the same idea:

function MyObject(){

var privateMethod = function(){console.log(“I’m private”);};

this.publicMethod = function(){console.log(privateMethod());};

}

new MyObject().publicMethod();

console.log(new MyObject().privateMethod).

This code will log I’m private and them undefined. And thats was what we expect.

First we call the public method. It has access to our private method inside the Object instance so it con log our message.

Motivated by Leandro, today I’m gonna write a bit about Clappr, an open source media player for the web. If you’re Brazilian or know portuguese, there’s also some useful information at Thiago’s talk. Actually, I will inadvertently and explicitly steal some data from it.

History

During the last 4 years at Globo.com there was no team focused specifically on the development of the video player. It was a monolitic flash component based on OSMF, mainly designed for playing progressive download videos on on-demand scenarios and also cover live streams through RTMP protocol.

Previous Globo.com player

At the beginning things were good, but in the course of time, a lot of new features were added (like support for subtitles, advertisement, DRM, new streaming protocols, picture-in-picture, etc). Since there wasn’t an official owner of the project and maintenance programming is a dirty work, we were building a wall with crooked bricks. Player tasks started to be faced with revulsion and pain.

As the FIFA World Cup 2014 project came with a bunch of new requirements and knowing that our live video streaming stack was rebuilt (HLS in favor of RTMP), we decided to go against Joel and bootstrap a brand new video player in order to support the requirements and improve the overall performance on serving the matches and upcoming transmissions.

Open Source

At Globo.com we use hundreds of open source projects and when starting a project from scratch, we usually ask ourselves Why not open source it?. First, there’s the motto of give something back to the community, but I personally believe that committing and pushing on Github, put your code available to the world and maybe build a community around your baby acts like a fuel for your brain, pushes you to the limits of productivity.

Open source software acts like a fuel for your brain, pushes you to the limits of productivity.

Since we are in times where video delivery is very heterogeneous between browsers and devices, we choose for a plug-ins based architecture, allowing us to provide almost everything as open source, except the components that interact with our internal infrastructure.

Clappr Architecture

With CBSE in mind we could figure out that there were three different plug-in types:

Playback Plugins: Responsible for playing a given source. When embedded, Clappr will search through playback plugins until find one who canPlay() the source.

Container Plugins: Every playback is associated with a container. In most cases, only one container and a playback will be instantiated. It is inside containers that, guess what, the container plugins work. Some examples are the built-in stats plugin that listen for playback events (buffering, bufferfull, play/pause, etc), the spinner and the watermark.

Core Plugins: These are the ones who control everything. Let’s say you want two videos playing at the same time, the main one and one smaller at the corner, like a picture-in-picture. A core plugin is able to instantiate two containers with a playback plugin each, set the size of the secondary video and put it on a bigger z-index.

There’s also a bunch of built-in components, like the Mediator who is responsible for routing events between scopes (and even make the Flash ↔ JS bridge when necessary) and the Loader who manage to load all built-in and external plugins. Wat? External plugins?

External Plug-ins

It’s not only possible but simple to create your own external plug-in. There’s a Clappr Plug-ins Generator that will ask you the kind of plug-in you want to create and build the structure for you. I’ve used it to create BemTV plugins, the playback and a container plugin to show peer-to-peer statistics. Globo.com has some proprietary plug-ins such as media control bar, thumb-on-seek and others.

Clappr with some Globo.com proprietary plugins used at World Cup

Technology

Current Status

Clappr already supports the mainstream formats and has some special features like DVR (travel in time on live streams). We’re heading to 1.0.0 release, but first we need to create a decent documentation and landing page. Both are on the go.

We tought that the architecture was so solid that motivated us to bootstrap mobile versions of Clappr. We already created iOS and Android repositories in case you want to follow our future progress.

Contributing

We are just three commiters, but there are some easy issues opened. If you felt encouraged in contributing, I’ll be more than glad to help you. You can find us at clappr discussion list and I’m always online as flavioribeiro at freenode.

During the last three years I’ve been working on the Live Video infrastructure at Globo.com and I’ve realized that one of the biggest problems we had here in Brazil is related to CDN throughput and telecom infrastructure in general. Looking at what has been happening with online streaming of live events around the world (as The Oscars and True Detective Finale) and the fights involving OTT services and telecom carriers, one can realize that this is a common problem everywhere.

With that in mind, I decided to explore this problem and as I’m attending the last year of my Master’s and my colleagues at work were bootstraping a new team to develop a video player from scratch, it happened to be the perfect timing. I joined this new team and defined my Master’s thesis theme aiming to develop a Hybrid CDN/P2P architecture for online live broadcasts using the popular HLS protocol together with WebRTC.

First, we baptized the new player as Clappr - the name “clapper” comes from clapperboard - and open-sourced the project. You can follow our progress on github and yes, we’re aware that we’ll need to write some documentation on how to deploy the player and write plugins, it is already on our backlog. A nice logo and better UI are also on the go.

After that, I’ve created a clappr plugin that tries to drain video segments from peers in order to decrease the number of requests to CDN servers, reducing the cost of transmission and enhancing system’s scalability. If something goes wrong between the peers, it will get from the CDN without impacting user experience. This project is called BemTV and today I’m releasing its first version.

BemTV is open source. I must warn you that this is a nightly build and needs some improvements before debut on production environment (I’ve performed just some controlled tests) but I’m inviting you to test it on http://bem.tv and also look at the code. The video in there is in loop, emulating a live video streaming behavior.

I’ll be more than happy to answer questions and fix bugs or problems that arise. Call friends near you, look at the statistics box and tell me if the video segments are being exchanged between you guys!

I’ve always been a huge fan and advocate of using tests for developing applications. For me, working on a software without a decent suite of test is like walking on eggshells, each modification brings out the risk of breaking something on the system. To mitigate this risk I always make sure I have a minimum set of unit, integration and acceptance tests covering my application.

But does all that gives us the confidence that the system will work perfectly when it’s deployed to any of the environments, on its way through the release pipeline? I thought so until work with this guy and read this book. Tom Czarniecki firstly introduced me the concept os smoke tests, then reading Jez Humble and David Farley’s Continuous Delivery I could grok the real values of using it in conjunction with a build pipeline.

What are smoke tests?

As aforementioned, deployment smoke tests are quite handy because they give you the confidence that your application is actually running after being deployed. It uses automated scripts to launch the application and check that the main pages are coming up with the expected contents, and also check that any services your application depends on— like database, message bus, third-party systems, etc —are up and running. Alternatively you can reuse some acceptance or integration tests as smoke ones, given that they are testing critical parts of the system. The name smoke test is because it checks each of the components in isolation, and see if it emits smoke, as did with electronic circuits.

Provide clear failure diagnostics

If something goes wrong, then your smoke tests should give you some basic diagnostics explaining the reasons why your application is not working properly. In our current project at Globo.com, we are progressing towards start using Cucumber to write our smoke tests, thus having a set of meaningful and executable scripts, like this one below.

Feature: database configure
System should connect to the database
Scenario: should connect to the database
When I connect to "my_app" database as root
Then it should contain tables "users, products"

For those who like using Nagios for monitoring infrastructure, Lindsay Holmwood wrote a program called cucumber-nagios which allows you to write Cucumber tests that output the format expected of Nagios plugins, so that you can write BDD-style tests in cucumber and monitor the results in Nagios.

Knowing quickly whether you are ready or not!

Clearly rapid feedback and safety are the two major benefits of introducing smoke tests as part of a release process.

Rapid feedback

In our project, we implemented a deployment pipeline, so each new commit into the source repository is a potential deployable version to any environment, even to production. So we have the commit-stage where we run all the quick tests, and as soon as all of them passes, the acceptance-test-stage is automatically triggered, and the longer tests— integration and acceptance —are run, and once they’ve also passed, the application is automatically deployed into the dev environment. Getting a green at this stage means that it’s successfully deployed and smoke tested. But there still some exploratory testing to be performed before releasing this version into the staging environment. And in our team, this is done by the product owner, together with a developer. So as soon as they are ready to sign the story off, all they have to do is click the manual button which in turn deploy the application into the qa1 (UAT) environment, and if it’s green they can proceed, otherwise they pull the cord because something is malfunctioning, as you can see on the picture.

Don’t let the application deceive you

It’s quite frustrating, when all you need is the system to work as expected, because you are about to showcase it to your customers, and the first thing you click, all you see is a big and ugly error screen, instead of the page they were expecting. And later on you find out that it was due to database breakdown. What an embarrassing situation that could have been avoided by simply checking the smoke test diagnostics before showcasing.