Concrete Logo
Hamburger button

Os 10 links do mês – Janeiro

  • Blog
  • 24 de Janeiro de 2014
Share

O pessoal aqui da Concrete Solutions adora compartilhar conhecimento. Um dos meios de comunicação neste sentido é nosso fórum, no qual aparecem diversos links com temas variados para discussão. Decidimos selecionar alguns deles para compartilhar o conhecimento também com os leitores do Blog. Na última contagem, os selecionados foram:

1. TDD Is Not An Algorithm Generator! (indicação de Daniel Lemos)

Alexandre Bairos concorda: encontrar o algoritmo correto para o Sudoku é uma tarefa como outra qualquer. O TDD entraria na implementação do algoritmo previamente conhecido e definido. O mesmo se dá para implementar um método de ordenação ou outras coisas previamente conhecidas. Dependendo do problema e da habilidade da equipe é provável que a escolha do algoritmo saia como resultado de uma tarde de pesquisa e planejamento no quadro.

Victor Lima acrescenta que no final do livro do Kent Beck (TDD by examples) ele faz (ou “resolve”) um método que implementa a sequência de Fibonacci usando TDD.

2. CannotMeasureProductivity (indicação de Alexandre Bairos)

Artigo de Martin Fowler para quem já ouviu falar de function points, que é um método aplicado normalmente em RFPs de governo (prefeituras, secretarias, etc). Faz sentido medir produtividade se não for para medir a geração de valor entregue por um time?

3. Shit Programmers Write (indicação de Daniel Lemos)

A proposta é “Finding awesome code and sharing it with the world”.

Com a dica, Guilherme Siepmann lembrou de uma função de arredondamento:

E o André Cardoso contou que quando estava na PUC RJ, um colega dele participou de um projeto do Arndt com o objetivo de fazer uma árvore n-ária, simulada por uma binária – e os nós poderiam ter qualquer valor. Esse colega escreveu uma função que recebia todos os tipos possíveis de variáveis. Algo do tipo:

…bizarro, segundo ele.

4. A Postmortem of Failed Products (indicação de Victor Lima)

Grifo de Victor Lima: “Most of my failures weren’t technical. With the exception of some of the arbitrary sandbox restrictions imposed by Apple, most of the technical problems are solvable given enough time. Which brings me to another conclusion: although Apple can make some things far more difficult than necessary, they’re not really the reason for my failures either. My products were failures before Apple said they couldn’t be in their store.”

5. Uso otimizado de queryset para saber se há objetos que atendem os critérios (indicação de Daniel Lemos)

Versão mais profunda de uma dica simples:

Se você for pegar todos os objetos retornados pela queryset, p/ ex. num loop sobre todos objetos encontrados, use:

Já que nesse caso o queryset será transformado uma query SQL que será executada no banco, os registros encontrados serão transformados em objetos e cacheados dentro desse queryset e a quantidade de objetos ser maior que 0 (zero) é que vai determinar se a avaliação do queryset é True ou False

– Se você quiser só a quantidade de objetos ou saber se há ao menos um objeto encontrado use:

ou

Paula Grangeiro lembrou que em Python qualquer sequência não vazia (seja um queryset, list, dict, ou até mesmo uma string) é considerado True.

5. 12 Outdated Web Features That Need to Disappear in 2014 (indicação de João Felipe)

Scott Gerber says: We’ve all been there — yelling at a computer screen or particular website because the antiquated design prevents you from getting where you want to go. But outdated features on your company’s website can do more than annoy — it can cost you potential clients or customers. To figure out what exactly agitates users the most, we asked 12 entrepreneurs which website features small businesses should avoid (or get rid of) at all costs. Here’s what they had to say.

6. Best development book I’ve read, has no code in it (indicação de Daniel Lemos)

Grifo de Daniel Lemos: ” If you hang on long enough, people will start calling you “experienced,” but that should not be your goal. All experience indicates is that you have been able to survive. It does not indicate the amount you have learned, only the time you have spent. Your goal should be to become skilled rather than experienced.

Software is not a product, it’s a medium for storing knowledge. Therefore, software development is not a product producing activity, it is a knowledge acquiring activity.”

7. Towards a Good Scrum Master Job Description (indicação de Victor Oliveira)

Descrição de uma vaga para Scrum Master criada por Charles Bradley com algumas colaborações.

Victor Lima acrescentou algumas definições do Marty Cagan (SVPG), que não necessariamente são idênticas às noções do Ken Schwaber/Scrum.org:

Great scrum masters have:

 – sense of urgency

 – willing to do anything to help

 – constantly asking how they can help

 – lives to ship

 – good judgement

 – “just do it” attitude

 – Pushy but not bossy

 – Constantly strives to remove impediments/obstacles

 – Concerned with process health

 – Eliminates need for meetings rather than increasing them

 – Attends meetings on your behalf when possible

 – Never lets issues or impediments persist longer than 48 hours

 – coordinates daily with other scrum masters and releases manager to manage interdependencies

O que NÃO faz parte do papel de um Scrum Master:

 – ser o administrador do time

 – ser o gerente das tarefas do time

 – ser a “Process Policeman”

 – pegar cafezinho, comprar chocolate, ou fazer cafuné em pessoas do time

8. Getting away with rewriting code from scratch (indicação de Daniel Lemos)

Independente da opinião do cara do artigo, uma forma para lidar com isso é:

Depois que você entrar em produção, dedique 20% do tempo do seu time para “improvements”, que podem ser desde refactoring no código, ou o designer ter a chance de revisitar alguma coisa no layout que não ficou como ele queria, ou ainda o time investigar a possibilidade de aplicar uma nova tecnologia. É critico quando você chega ao ponto em que a sua própria base de código impede a sua capacidade de inovar.

Em caso de pânico/crítico: 50% da capacidade do seu time deve ficar em tarefas desse tipo e a outra metade focada em andar pra frente.

Isso vai um pouco de encontro com a abordagem mais “XP”‘/lean de só refatorar aquilo que você mexer. Isso pode fazer sentido no curto prazo, mas por outro lado pode ter um impacto na sua capacidade de ser ágil/veloz na hora de mexer naquela parte especificamente para adicionar /alterar/remover uma funcionalidade crítica para o seu produto.

9. Microsoft SharePoint Server on AWS: Reference Architecture (indicação de Alexandre Bairos)

Implementação de referência de MS Sharepoint na AWS. A arquitetura de referência sugerida veio do uso interno da ferramenta feito pela própria Amazon.

10. Python and Flask Are Ridiculously Powerful (indicação de Rodrigo Deodoro)

Uma loja em 100 linhas de Python.