[Agile Tales] Comment on When you are struggling: what agile is really about by Jeff Patton

January 20th, 2016


I really like this… and I think you know I agree wholeheartedly.

There’s lots of odd paradox about process. We need just enough of it to work together. Too much moves our focus from what we’re trying to accomplish to the process – it makes the process what we’re trying to accomplish. Too little makes it challenging for us to work together.

In classes these days I do a quick word association. That is I write down the word “process” and ask participants to give me first words that come to mind. The words that come up usually aren’t particularly uplifting and give some strong hints about the culture they work in. I then write down the word “game” and ask participants to shout out the first words that come to mind. In addition to words like “fun,” and “team,” I often hear words like “competitive,” and “winning.”

It seems to me that games have just enough rules to allow us to play together as a team, have fun, and focus on the real object of the game – ideally to win. Winning in software [for me] is building a successful product.

Contrast that to the processes most companies labor under. Just surviving a process seems like winning at times. Winning at process is often “doing it right,” or “following the rules.”

One thing I recall from working with your company is that your leaders, most of them, seemed focused on winning the game. That’s the best cultural foundation a process can have.

Reminding people that process should feel like we’re playing a game has helped me a lot lately. Some folks still don’t like the Scrum game. I’ve often South Americans complain about US football that there’s “too many meetings.” :-) One agile “game” may not be right for every culture – but within an organization and especially a team, it’s important that we all be playing the same game.

[Agile Tales] Comment on When you are struggling: what agile is really about by Gebhard Greiter

January 20th, 2016

We need to think beyond the Agile Manifesto — the Manifesto’s approach is not abstract enough:

For defining Agile we should focus on the goal of Agile rather than on the misleading, very problematic way suggested by the authors of the Manifesto. Please read

The New (2011) Definitions of Agile or
The Manifesto can be Poison
The Manifesto is ignoring CIO’s Interest.

[Flávio Ribeiro] Working at the Video Team of The New York Times

December 22nd, 2015

So, after more than 3 years of the publication of this post and almost 9 months working here, I’ll give my two cents and elaborate a bit about my experience on the day-to-day work at the video team of The New York Times.

the new york times


The technology of the video team is split into three teams: Video Players (VHS), Times Video and the brand new Video Publishing API team. We are growing really fast and things are changing in every direction; it’s clear to me that everyone is excited and committed to our upcoming challenges.

We work in a fast-paced environment and always adapting our agile processes. However, I never feel rushed and everyone is committed to do deliveries with meaningful impact. The engineers have the freedom to give input on process, features and backlog. For example, after this quizz I was able to implement and send the thumbs on seekbar feature to production (http://nyti.ms/1jaFlVK).

We have frequent 1:1’s and occasional brainstorm meetings. Our daily meeting is around 11 AM and takes no longer than 10 minutes, we usually have people working from home and the meeting always happens on Google Hangouts.

video team at nytimes

one of our daily meetings some time ago

Our team consists of people from all around the world such as U.S., China, Brazil, Canada among others. Our cultural differences are always the subject during lunch.

Speaking of lunches, while we don’t have free food we do have a restaurant inside the building that serves typical food from a different country every day (somedays the food is awesome, sometimes not much).

Generally, a new hire rotates between all projects during the first month. This helps with understanding the whole video platform and familiarize with both team members and the codebase.

The Times also hosts a tech blog, 100% days (two days to do whatever you want) and hackweeks. There’s also some events open to the public, you can find the schedule of events here.


We use JIRA to track our projects, milestones and sprints. I personally don’t like it — it’s too slow, hard to glue with the code and full of buttons. We use Github for code and Slack for communication throughout the entire company. Some of my favorite channels include #coffee for caffeine addicts, #conferences-events for events and #snacks for free goodies around the building.

The VHS team uses plain JavaScript for the players. We use Grunt for tasks and Karma + Chai + Mocha + Sinon for tests. One of our targets this year was to get rid of Flash so we needed to integrate the player with VPAID for ads and use hls.js for live streams. This whole journey deserves it’s own post, we’re planning to do that on our tech blog.

The Times Video team is responsible for Times Video product. We are using ES6 with Babel and moving from Backbone to React. The back-end is made with Node + Express + Memcached. For testing, we’re using the same stack as VHS.

The Video Publishing API is still being assembled and will support our encoding pipeline, including the production & editing integration, security, encoding profiles, and syndication among others. The company is in an adoption movement of the Go language and we are willing to use it to build the API’s.


I was hired in April 2015 as a contractor and waited until October for the H1B visa, when I started working as a full-time employee. During this time I went to New York twice to get to know the team. I also used those trips to pick out apartments in different neighborhoods to get a better idea of where I would live.

It was my first experience working remotely and it was tough, I was living in Rio de Janeiro at the time and decided to spend some time with my parents and friends in Campina Grande, where I grew up. My life became a whirlwind during those months and my productivity was well below normal.

flavioribeiro github streak

my github streak proving I’m going back to a good shape

Since I arrived in New York, I feel much better. I have a routine, the commute works and the city surprises me everyday. As a natural Brazilian accustomed to a hot weather, I’m afraid of the upcoming winter. However, I’m lucky the cold is slow to arrive this year.

At the building, every engineer has it’s own cube and it’s huge. More than twice as size as my last table. It fits some books, figure toys, a small whiteboard and sometimes another coworker when pairing. You get a little isolated and is quite different from how are the open tables in startups, but I personally like the privacy that the cube give to me. The office is calm and quiet, I never turned on the noise cancellation of my headphone.

I’m very happy and hope to contribute even more on next year. If you want to be part of this amazing team, we are hiring.

video team

united colors of video team!

Related links:

[Tiago Motta] Dados abertos do Web Democracia

November 28th, 2015

Nas minhas conversas com os participantes do RecSys de 2015 em Viena foi possível notar o esgotamento deles em relação aos dados existentes para análise. Os acadêmicos longe de grandes empresas como Linkedin, Google, Facebook e Netflix, estavam sempre em busca de mais dados para tunar e implementar novos algoritmos. Em resumo, ninguém aguenta mais o MovieLens.

Por essa razão resolvi disponibilizar todos os dados de avaliações de políticos no Web Democracia publicamente.

Para garantir a privacidade dos usuários utilizei a total aleatorização dos IDs de forma a evitar qualquer engenharia reversa, deixando então as avaliações anônimas.

A descrição completa dos dados de avaliações de políticos do Web Democracia você encontra aqui.

Um exemplo simples de análise desses dados com pandas pode ser visto aqui.

Agora então os quase meio milhão de avaliações de políticos do Web Democracia é mais uma fonte de informação e de um domínio bem diferente que os tradicionais livros e filmes.

[Renan Oliveira] Big Data na Globo.com

November 23rd, 2015

[Renan Oliveira] Excelsior – Perfil usando Big Data e Web Semântica

November 11th, 2015

[Igor Macaubas] Comment on Scrum Beyond the basics – palestra no Agile Brazil 2012 by Scrum Beyond the basics – palestra no Agile Brazil 2012 | Planeta Globo.com

August 30th, 2015

[…] [See image gallery at macaubas.com] […]

[Igor Sobreira] Decoding JSON numbers into strings in Go

April 11th, 2015

You have a JSON documents with numbers:

    "num_integer": 10,
    "num_float": 10.5

Go’s JSON decoder is smart enough to decode those into your struct with correct types, like the one bellow:

type Message struct {
    NumInt   int     json:"num_integer"
    NumFloat float64 json:"num_float"

If the JSON value doesn’t match your struct type encoding/json will return an error. Trying to decode the JSON document above with the following struct:

type Message struct {
    NumInt   string  json:"num_integer"
    NumFloat float64 json:"num_float"

will return an error:

json: cannot unmarshal number into Go value of type string

Yesterday I had this specific scenario where I needed just this: having JSON document with numbers and decode them into my struct with string fields. I found the solution in stackoverflow (of course). encoding/json has a Number type which stores the value as a string and has methods to convert to integer or floats. Here is how I used it:

type Message struct {
    NumInt   json.Number json:"num_integer"
    NumFloat json.Number json:"num_float"

just decode it as usual. Note how the underlying type is still a string, but you also have convenient methods to convert to both int64 or float64

var message = {
    "num_integer": 10,
    "num_float": 10.5
var msg Message
if err := json.Unmarshal([]byte(message), &msg); err != nil {
fmt.Printf("%#v\n", msg)

numInt, err := msg.NumInt.Int64()
if err != nil {
numFloat, err := msg.NumFloat.Float64()
if err != nil {
fmt.Printf("Integer: %v. Float: %v\n", numInt, numFloat)

Here is the full example at play.golang.org

I still had to change my struct field from string to json.Number, but that’s ok because I can still assign string literals to it. By the way that’s an important distinction. string and json.Number are different types with the same underlying type. From the spec:

Each type T has an underlying type: If T is one of the predeclared boolean, numeric, or string types, or a type literal, the corresponding underlying type is T itself. Otherwise, T’s underlying type is the underlying type of the type to which T refers in its type declaration.

This works:

type Message struct {
    Num json.Number
var msg Message
msg.Num = "ten"    // string literal

but this doesn’t:

type Message struct {
    Num json.Number
var msg Message
var num = "ten"    // variable of type string
msg.Num = num

cannot use num (type string) as type json.Number in assignment

oh, and just for completeness, this also works:

type Message struct {
    Num json.Number
var msg Message
const num = "ten"  // now an untyped constant
msg.Num = num

[Emerson Macedo] Minha palestra na QCON SP 2015

April 1st, 2015

Na semana passada, mais precisamente no dia 25/03/2015, palestrei na QCON SP pela segunda vez. A última vez que palestrei no evento foi em 2011.

Minha palestra foi sobre o case do GloboTV e Globosat Play. O objetivo era seguir pelos passos que fizemos até chegar no estagio atual, desde lidar com o nosso monolito, até quebra-lo em diversas apps, cada uma com suas responsabilidades. Vou tentar expor mais tecnicamente os detalhes aqui no blog.

Os slides seguem abaixo e o InfoQ Brasil deve publicar o vídeo em breve.

Microservices Case: GloboTV e Globosat Play from Emerson Macedo

[Flávio Ribeiro] It's time to move on

March 26th, 2015

After almost 4 years immersed in a lot of exciting challenges, it’s time to move on.

Sunset by instagram.com/fanydantas

Sunset from my balcony by Fany

When I started working at Globo.com, I realized that every if that I wrote would run in hundreds of thousands of computers around the country. Until then, I’ve only worked on small startups in the Northeast of Brazil where the impact of their products have smaller proportions. Describing this feeling is hard. I would argue that, for a software developer like me, knowing that your code is being used is as rewarding as receiving real money.

During the time at Globo, I faced huge projects. As we’ve worked developing software for the video delivery stack, almost every big transmission - like elections or FIFA World Cup - had their special issues and corner cases. Following the trend, we developed a live video streaming stack from scratch and seeing this new infrastructure beating the concurrent users peak twice was priceless.

United Colors of WebMedia

Part of WebMedia Team during the World Cup. We were still believing we would be Champions.

I could also work with the most awesome engineers I’ve ever met. Sometimes I felt that the lunch time was kind of a graduate class (actually, I should had taken a pencil and paper to it). The discussions ranged from writing tests to how telecommunications works.

Since the beginning of last year I’ve worked full time on an open source project which was the real reason for me to get up out of bed to go to work and sometimes even rise up early to answer one issue or fix a bug that someone dropped on github. I’ve already said this here but…Damn, how awesome is working with FOSS!

About 6 months ago I was catching myself visiting LinkedIn, hypothetically looking for a new job, and this made me think that it was time to move on. I’ve read somewhere that when you’re feeling attracted by other opportunities, it’s a big red signal that you’re not happy anymore and need a change. I’ve applied to some companies and met a lot of great guys during the interviews but the last one was mind changing.

If you get the chance to work overseas, take it. There is never a right time. And we always regret the things we don’t do far more than the things we do. (Shane Rodgers)

I’m joining the Video Team at The New York Times. Next week I’m heading to New York to visit the office and meet my coworkers. I must say that I’m totally anxious and excited about it, but a lot of things need to happen before I move definitively to America. Until there, I’ll work remotely (which will be a challenge apart).

I hope that everything that I lived these years were only the beginning and I’m sure I have a lot of things to learn. I’ll try hard to publish more posts regarding the obstacles I’ll face and I hope you’ll be cheering for me.

Related Links:
Hey Feio, how is working at The Times?
What I whish I knew when starting out as a Software Developer
The career advice I wish I had at 25