Secondly, this is my personal option based on the daily things I have seen from the middle of the year 2015 to now. This post is for advanced users that handle many servers on a regular basis.

Let’s start with the micro review.

CVE-2016-0728 – The local privilege escalation vulnerability in the Linux kernel:

Privilege escalation vulnerabilities aren’t very common with GNU/Linux distributions. Especially because the daemons and process usually don’t run at the top of the root user.

Since Shellshock, we do not see big bugs of this type:

http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/

CVE-2016-0777 and CVE-2016-0778 – The roaming feature for SSH clients:

We see server sides vulnerabilities every time during the management duties. What about a client side issue that makes you vulnerable while accessing a server?

If you run SSH on the wrong server and have the UseRoaming feature active (that is, by default) someone could steal your SSH private key:

https://www.digitalocean.com/community/questions/openssh-client-bug-cve-2016-0777-and-cve-2016-0778

CVE-2015-7547 – THE DNS exploit

This one caused sleepless nights of many engineers in late 2015.

Considered the bug that caused the 3th worst DDoS attack to DNS Root Servers the history of the Internet it caused DNS resolutions errors for the most part of the planet triggering intermittent instability for internet service providers and hosting providers everywhere for months.

No more comments on this one:

https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

http://root-servers.org/news/events-of-20151130.txt 

Bonus:

This one is not new but started to be an issue again recently with the popularization of private networks accessible only via SSH Tunnels due to lack of IPv4:
https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking

Feel free to post at the comments your personal rank.

Thanks!

In this new version, 7.0, the installation has deprecated ssh-dss and diffie-hellman-group1-sha1 key exchange method for security enforcement.

So, the best fix if you face issues would be updating your OpenSSH Servers to the most recent versions.

However, if you don’t have access to the servers configuration, there’s a temporary workaround for keep using the legacy implementations.

For the ssh-dss error, create an entry in your ~/.ssh/config with the following content:

Host somehost.example.org
    PubkeyAcceptedKeyTypes +ssh-dss

And, for the diffie-hellman-group1-sha1 error, the following entry:

Host somehost.example.org
    KexAlgorithms +diffie-hellman-group1-sha1

You could also add other hosts, followed by comma:

Host somehost.example.org, otherhost.example.org

Or even regular expressions and IP addresses:

Host app*.example.org, *.example.com, 192.168.0.1

That’s all, folks.

For example, a physical kanban board is more suitable for communicating as a digital version. As everyone will see the progress and obstacles as they get close to a team (and, of course, the board should be near the team). The digital version is not bad, but it needs a lot more self-discipline than the physical one.

I will talk more about good practices to give visibility to digital kanbans over the next posts. Today I want to tell a little about how to do this with the continuous integration process.

Throughout continuous integration, we have a distinct scenario because typically only the development team members follow this process, where it is quite common:

• The build agent starts to send e-mails when someone breaks tests;
• Developers do not open the mailbox very often throughout the day. Usually, they are focused on making code with due heroic dates that the dev team stipulated themselves (or at least agreed);
• When devs start to being disturbed by the build agent, they move the related emails to a label and skip the inbox;
• These emails never will be seen again.

What if we create a physical way to communicate these changes? As the physical kanban, everyone would know what’s going on when they approach the team workspace, instantly.

Here’re some interesting examples:

However, before you start learning basic electronics and buying a bunch of stuff, I would like to teach you a very simple way to get started.

Start small, as people start enjoying it (especially people who sponsor the project), you should starting building complete lights for all your build pipeline.

For my example, I will use this light:

http://www.blynclight.com/products/blync-light?variant=328886579

You will need a machine with a USB port and connectivity to your local network. You could use a Raspberry Pi or a Linux machine that is close to the team.

That parts could be more expensive than buy an Arduino and some lights, however, you will only need 5 minutes to make it work. As the working hours of your team should be more expensive, this will be the cheapest way to get started as start from scratch with the electronic components.

The fun part about this light is a NodeJS library:

https://www.npmjs.com/package/blync

Some examples of usage (finally):

Ayrton, what is the build status?

A video posted by Ayrton Araújo (@ayrtonfreeman) on Jul 24, 2015 at 4:47pm PDT

How does it work?

First you need add a user to plugdev group and create the 90-libusb.rules inside this path:

/etc/udev/rules.d/

Reload udev rules:

sudo udevadm control --reload-rules

You could test if everything is working fine with the light-cli.coffee:

coffee light-cli.coffee green
coffee light-cli.coffee red
coffee light-cli.coffee white
coffee light-cli.coffee magenta
coffee light-cli.coffee blue
coffee light-cli.coffee cyan 
coffee light-cli.coffee yellow 
coffee light-cli.coffee off

Expose a REST API:

coffee light-api.coffee

You could use forever to keep the API working after system restart.

Getting the things real:

When a build starts, you could call in the job:

curl http://lightmachineIPorDOMAIN:3333/api/v0/yellow

When a build succeed, you could call:

curl http://lightmachineIPorDOMAIN:3333/api/v0/green

If if fails:

curl http://lightmachineIPorDOMAIN:3333/api/v0/red

Now you can use your imagination. I’m color blind.

What are the main advantages?

• Extended globbing: For example, (.) matches only regular files, not directories, whereas az(/) matches directories whose names start with a and end with z. There are a bunch of other things;
• Inline glob expansion: For example, type rm *.pdf and then hit tab. The glob *.pdf will expand inline into the list of .pdf files, which means you can change the result of the expansion, perhaps by removing from the command the name of one particular file you don’t want to rm;
• Interactive path expansion: Type cd /u/l/b and hit tab. If there is only one existing path each of whose components starts with the specified letters (that is, if only one path matches /u/l/b*), then it expands in place. If there are two, say /usr/local/bin and /usr/libexec/bootlog.d, then it expands to /usr/l/b and places the cursor after the l. Type o, hit tab again, and you get /usr/local/bin;
• Nice prompt configuration options: For example, my prompt is currently displayed as tov@zyzzx:/..cts/research/alms/talk. I prefer to see a suffix of my current working directory rather than have a really long prompt, so I have zsh abbreviate that portion of my prompt at a maximum length.

Font: http://www.quora.com/What-are-the-advantages-and-disadvantages-of-using-zsh-instead-of-bash-or-other-shells

The Z shell is mainly praised for its interactive use, the prompts are more versatility, the completion is more customizable and often faster than bash-completion. And, easy to make plugins. One of my favorite integrations is with git to have better visibility of current repository status.

As it focuses on the interactive use, is a good idea to keep maintaining your shell scripts starting with #!/bin/bash for interoperability reasons. Bash is still most mature and stable for shell scripting in my point of view.

So, how to install and set up?

sudo apt-get install zsh zsh-lovers -y

zsh-lovers will provide to you a bunch of examples to help you understand better ways to use your shell.

To set zsh as the default shell for your user:

chsh -s /bin/zsh

Don’t try to set zsh as default shell to your full system or some things should stop to work.

Two friends of mine, Yuri Albuquerque and Demetrius Albuquerque (brothers of a former hacker family =x) also recommended using https://github.com/robbyrussell/oh-my-zsh. Thanks for the tip.

How to install oh-my-zsh as a normal user?

curl -L http://install.ohmyz.sh | sh

My $ZSH_THEME is set to “bureau” under my $HOME/.zshrc. You can try “random” or other themes located inside $HOME/.oh-my-zsh/themes.

And, if you use Ruby under RVM, I also recommend to read this:
http://rvm.io/integration/zsh

Happy hacking

Começando com as duas fatídicas perguntas, uma máxima que ouço com muita frequência e uma triste realidade:

“Já fez o TDD?” – Referindo-se a testes de unidade

“TDD vs BDD? Qual é o melhor e quando usar cada um deles?” – Ser humano perdido

“Você só pode usar o BDD para testes de tela, não serve para outro tipo de testes.” – Maximus Decimus Meridius

“Faço os testes unitários depois, porque aí tenho o que testar. Não vejo sentido fazer os testes primeiro.” – Desenvolvedor que não quis ser identificado

Vamos às minhas explicações e considerações:

De volta ao básico

O Desenvolvimento Orientado a Testes (TDD) é uma técnica de desenvolvimento de software multiplicadora do seguinte workflow:

• Escrever os “testes”;
• Fazê-los falhar;
• Implementar nosso código;
• Fazer os testes passarem;
• Refatorar;
• Volte para o primeiro passo.

Defina “testes”

A técnica descreve “teste” como toda e qualquer expectativa tida sobre um código-fonte. Vezes, expressamos essas expectivas por meio de testes unitários, mas não impede que possamos especificar usando testes de integração ou testes de tela, por exemplo.

Por que temos que falhar os testes?

Porque é só uma especificação, não implementamos nada ainda. É como o roteiro de uma palestra ou show. Descrevemos para tomar nota do que esperar da apresentação final e não nos perdermos durante a implementação do “show”.

Testes de integração? Testes de tela? Testes de unidade?

A técnica não impede que definamos essas espectativas por meio de testes de integração ou testes de tela, por exemplo. Mas é sempre bom ter em mente que cada um desses possui objetivos e focos diferentes. Nada impede também o uso conjunto deles, até encorajo.

Pesquisando um pouco, vemos que existem muitos outros tipos de testes.

E o BDD?

Dan North, um importante coach do mundo agile, descobriu que as pessoas passaram a entender melhor os princípios do TDD quando ele parou de usar a palavra “teste”. Ele passou a substituir isso por “cenários”, “comportamentos”, “exemplos”, resultando na compreensão mais rápida dos princípios do desenvolvimento orientado a testes.

Num caso pessoal meu, comentando sobre testes de unidade, vejo muito a justificativa de escrever os testes após o desenvolvimento ser mais natural, pois escrever primeiro sem ter o que testar não faria sentido. Parando para analisar numa perspectiva “testicentrista”, esse raciocínio faz todo sentido e é perfeitamente natural, o que acaba causando toda a confusão conceitual acerca do TDD.

Aslak Hellesøy, em seu livro sobre o Cucumber, diz que o Desenvolvimento Orientado a Comportamentos (BDD) é nada mais nada menos que uma formalização das das melhores técnicas descritas no Desenvolvimento Orientado a Testes (TDD) feita por bons praticantes.

Basicamente, o BDD é uma tentativa dos usuários bem sucedidos de TDD de re-explicar o conceito de Desenvolvimento Orientado a Testes (TDD), incrementando suas próprias experiências ao longo de quase uma década de uso.

Refatoração

Após implementar seu código de acordo com os padrões de arquitetura escolhidos e assegurar-se de que as expectativas (testes) estão passando, o passo seguinte é a refatoração. Na minha humilde opinião, esse é o objetivo da coisa toda.

Como assim?

Na minha compreensão, todo esse workflow tem o objetivo de garantir a refatoração do nosso código com tranquilidade, checando sempre se as expectativas estão batendo. Porque, inicialmente, além do nosso código ser mais verboso, a qualidade dele é geralmente duvidosa. Não devemos postergar esse passo para dar andamento à construção de novas expectativas.

“Os custos de correção de defeitos e refatorações após a implantação são 10x maiores que na fase de construção e 100x maiores que na fase de design.” (Barry W. Boehm: Software Process Management)

Esta prática pode ser comparada à uma monografia escrita para conclusão de curso – quando refatorada durante toda a produção, o custo nas correções aplicadas ao texto é menor, e a qualidade terá um padrão elevado. Diferente de quando as correções acumulam-se, de modo que tudo será corrigido no final. Independente da escolha, a refatoração será sempre necessária para manter a qualidade da monografia, porém, a quantidade de esforço e os resultados serão distintos para os dois casos.

Fontes:

• http://blog.mattwynne.net/2012/11/20/tdd-vs-bdd/
• https://github.com/cucumber/cucumber
• http://pichiliani.com.br/2014/06/15-fatos-sobre-programacao-que-voce-provavelmente-nao-sabia/
• Treinamentos da K21 e Adaptworks;
• The Cucumber Book;

Quer só o áudio?