Hack ‘n’ Cast v0.7 - O.P.A.

Hoje, dia 21 de Outubro, está sendo instituído o dia do podcast e, para comemorar, estamos lançando um episódio extra (e por que não especial) do Hack 'n' Cast. Como todos sabemos, ouvir podcast se torna um vício, então resolvemos criar um grupo de ajuda e apoio para os que são afligidos por este mal.

Baixe o episódio e leia o shownotes

Hack ‘n’ Cast v0.6 - Python

Python é uma das linguagens que mais cresceram nos últimos anos. Boa parte se deve ao fato de sua simplicidade, sintaxe intuitiva e de fácil aprendizagem, mas não podemos negligenciar a grande força motriz desta linguagem, sua comunidade.

Baixe o episódio e leia o shownotes

Usuários Java: intervenção manual necessária antes da atualização

Leandro Inácio escreveu:

Para contornar a questão do conflito de arquivos, é necessário uma intervenção manual apenas se o pacote java-common estiver instalado. Pode ser verificando com o comando a seguir:

$ pacman -Q java-common

java-common ...

Se sim, por favor execute os comandos a seguir, antes da atualização:

# archlinux-java unset

# pacman -Sydd --asdeps java-runtime-common

:: java-runtime-common and java-common are in conflict. Remove java-common? [y/N] y

# archlinux-java fix

Você pode continuar e atualizar:

# pacman -Su

Por favor, note que o novo pacote java-runtime-common não usa o suporte forçado da JAVA_HOME como o pacote java-common. Veja a página do Java na wiki para mais informações.

URL da notícia: https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/

Windows 10 de graça? Não, obrigado

Olá a todos, como vão?

Muitos de vocês sabem que a Microsoft divulgou recentemente o Windows 10, sim do 8.1 pulou para o Windows 10, e os usuários da MS ficaram felizes com as “novidades”. O grande destaque da apresentação foi a volta de um recurso que eles removeram e praticamente todos os usuários habituados a um Menu Iniciar reclamaram da remoção e voltaram a ficar felizes porque a Microsoft reconheceu seu erro e escutou a comunidade. Será? Uma outra coisa que foi amplamente divulgado foi a possibilidade de você tem múltiplas áreas de trabalho, algo realmente inovador não é? Não! Esse recurso já existe e é utilizado faz tempo por pessoas que utilizam o GNU/Linux.

Porém o que mais me preocupa nesta versão é a alegria que as pessoas ficaram ao ler/escutar “O Windows 10 será de graça”. Ai você pensa que a Microsoft está pondo fim a pirataria que sofre em seus Sistemas Operacionais e agora não existem mais razão de usar GNU/Linux porque ele também é de graça e ponto final. Irei explicar porque este pensamento é errado abaixo.

Talvez você não sabia, mas uma das coisas que muito se falava para se adotar o GNU/Linux é que ele era de graça e economicamente era muito mais viável que Software Proprietário porque reduziria custos e o dinheiro economizado poderia ser gasto com outras coisas e etc. Porém além de ser gratuito o GNU/Linux respeita e segui premissas que o impedem de te vigiar, coletar, armazenar seus dados, compartilhar seus dados e por ai vai. As Políticas de Privacidade do Windows 10 deixam bem claro o que eles querem do usuário coisas que os mesmo sequer sabem que são coletadas, pois grande maioria utiliza o Sistema Operacional sem ler as condições de uso e acabam sendo vítimas sem saber de espionagem, coleta massiva de informações que o usuário sequer faz ideias que são coletas sem saber como são armazenadas, onde e quem tem acesso a elas e por quanto tempo isso fica armazenado. Isso nunca é divulgado ou esclarecido pela Microsoft, e você já se perguntou o por que?

Nos dados que eles coletam são destacados quatro pontos que são:

1. instala o Programa, podemos coletar informações sobre seu dispositivo e aplicativos e usá-las para fins como determinar ou melhorar a compatibilidade,

2. usa recursos de entrada de voz como de fala para texto, podemos coletar informações de voz e usá-las para propósitos como de melhorar o processamento da fala,

3. abre um arquivo, podemos coletar informações sobre o arquivo, o aplicativo usado para abrir o arquivo e quanto tempo ele é usado para fins de melhorar o desempenho, ou

4. digita texto, podemos coletar os caracteres digitados e usá-los para fins de melhorar os recursos de preenchimento automático e correção ortográfica.

Leia atentamente, eles utilizar a palavra podemos do verbo vou fazer mesmo você querendo ou não e vão capturar absolutamente tudo o que você faz com o computador. Você é obrigado a ceder, não existe a opção de não enviar absolutamente nada ou saber o que está sendo capturado ou não, a Microsoft simplesmente coleta e pronto.

O que você digita, o que você fala, o que você abre, seja ele um programa ou site da internet, é coletado para fins de melhoras que também não são totalmente especificados pela empresa. Ao utilizar o sistema de graça você abre mão completa de sua privacidade e de seus dados sem saber o real motivo dessa coleta. Já foi dito pelo Snowden que a Microsoft é conivente com o Governo dos Estados Unidos e a NSA então certamente a mesma sede a pressões por entregar informações de terceiros para ambos.

Fica um fragmento da parte que trata de Manipulação de Dados que a Microsoft informa ao usuário ao concordar com suas condições.

A Microsoft pode reter algumas informações pessoais por uma variedade de motivos, como para atender às nossas obrigações legais, resolver disputas e reforçar nossos acordos.

Você sabe quais motivos vão levá-la a fazer tal atitude? Saberá quais informações serão retidas? Quais obrigações legais são necessárias para reter informações? Faça apenas essas perguntas e veja se vale a pena usar um Sistema Operacional que é de graça e que você tenha que está de “acordo”com tudo isso.

Se você não quer correr esses riscos escolha uma distribuição GNU/Linux e seja feliz!

Até a próxima!


A História do Python

Julgo que a história do Python é extremamente importante para a comunidade, pois ela além de mostrar fatos importantes da linguagem, explica algumas de suas características e como seus desenvolvedores lutaram para manter esse projeto um dentro dos moldes do Software Livre e Open Source (antes mesmo de existir esse ...

A História do Python é um artigo original de Mind Bending

Planejando no Macro para entender o micro

Finalizei o último post deixando um suspense no ar. Se não viu, recomendo que leia! Pois bem, quando falei sobre planejar no macro e codificar no micro, deixava ali uma ideia útil de fato, muito bem abordada, que quase todo developer já ouviu pelo menos falar o nome e que porém, já foi muito mal utilizada.

Código Exercitado é código em forma

A UML, pode ser um aliado forte no seu planejamento macro de uma funcionalidade do software. Calma! Nada de fechar a aba e ir me xingar no twitter. Estou afirmando para você que é desenvolvedor e cria seus próprios testes a esboçar numa visão macro o que planeja fazer e com a UML, você obtém esse rascunho rapidamente.

Porque a UML e não (coloque aqui seu outro método) ?

UML é uma linguagem de modelagem de diagramas e sua simplicidade (no uso simples dela) a torna uma vantagem no esboço de rascunhos macro de seu software. Outro ponto a favor da UML é o shareable que ela permite: mande-me um esboço UML que eu entenderei o que você quer me falar.

Esboço!

Não estou falando para chamar o arquiteto de software para ele criar todo o software em UML e mandar você fazer. Vou repetir: crie você seus esboços para ajudar no seu próprio entendimento do que pretende e como fará os relacionamentos. Geralmente, eu faço micro esboços que resolve uma e somente uma funcionabilidade. Após criá-la, consigo ver se fará sentido aquela minha ideia do ponto de vista arquitetônico e daí então, crio meu teste de unidade e sigo adiante.

  • Eu não faço uma funcionabilidade e depois ligo com outra que liga com outra;
  • Não guardo estes rascunhos depois que acreditei na solução macro e segui adiante com a micro (Teste de Unidade) ajustando meu design de código, e;
  • Não faço rascunho macro em UML para toda e qualquer nova feature. Apenas naquelas onde as fronteiras da classe alvo do teste estão meio obscuras para mim.

Isto quer dizer que se Order se relaciona com alguns atores (outras entidades/classes puras) e este relacionamento está estranho para mim, eu tenho subir o nível de abstração, saindo do micro e indo para o macro, buscando entender como dar-se-á o futuro relacionamento ou/e se ele faz mesmo sentido naquele contexto.

Tipos de macro-esboço

Geralmente eu apelo para o Diagrama de Objetos por ser algo simples: coloca dentro do retângulo o nome da classe e pronto. Onde ele por ser útil: a) quando você está procurando quais as fronteiras seu objeto terá; (lembre-se de que todo e qualquer objeto deve ser planejado como se o mesmo fosse uma API provendo serviço através de métodos públicos a outros objetos do mesmo sistema - por isso uso muito o termo fronteira [boundary]). b) quando você precisa entender se o objeto deverá ser Aggregate Root de algum outro via composição. c) traçar fluxos possíveis dentro de um conjunto de objetos.

Quando a coisa aperta e eu fico desconfiado das responsabilidades de cada método em objeto(s) em uma feature, eu recorro ao Diagrama de Sequência. Ele torna-se muito útil nos cenários macro-micro (nome horrível), onde estou planejando o macro, mas entrando um pouco no detalhe da responsabilidade (SRP, alguém?) da feature. Ele te ajuda a lembrar sempre da Lei de Demeter com seu Tell Don’t Ask.

Já acabei utilizando raramente o Diagrama de Classe, onde rascunhava um pouco sobre os métodos de uma classe, mas no meu uso ele acabava não agregando na visão macro, por especular a visão micro sem conhecimento de causa.

Porque não usar a UML como documentação de software?

Quer tentar? Vá em frente (e quebre a cara). Eu e alguns amigos já tentamos manter um Diagrama Caso de Uso em um software anos atrás e sinceramente? Totalmente inútil. Precisava de atualização a todo instante; Ficando desatualizado tornava-se um peso a mais e não ajudava no design pois era um punhado de diagrama e não código executável que te prova que sua teoria no código de produção funciona ou não. Imagina você tendo que atualizar todo diagrama de sequência assim que resolve mudar o input ou output de um método. This is madness! - além de ser esforço inútil pelos motivos já citados (não exercita o código de produção).

Concluindo

Diagramas UML, rabiscos, círculos interligados, etc., ajudam você a planejar sua visão macro quando sente-se desconfortável com certa integração entre objetos. São valiosas ferramentas para esboçar sua ideia e reorganizar sua mente antes de seguir para seu próximo Teste de Unidade, que diferente do primeiro, exercita código de produção como ninguém.

nvidia-340xx e nvidia

Leandro Inácio escreveu:

Como a NVIDIA tirou o suporte as GPUs G8x, G9x e GT2xx na versão 343.22, existe agora um conjunto de pacotes nvidia-340xx com suporte a estas GPUs antigas.

340xx receberá suporte até o fim de 2019 de acordo com a NVIDIA.

Usuários de GPUs antigas devem considerar a mudança para nvidia-34xx. Os pacotes nvidia-343.22 e nvidia-34xx-340.46 estarão em testes por alguns dias.

URL da notícia: https://www.archlinux.org/news/nvidia-340xx-and-nvidia/

mesa atualizado para 10.3.0

Leandro Inácio escreveu:

mesa está disponível com algumas mudanças no empacotamento:

  • Trabalho relacionado ao megadriver está feito, drivers dri separados não fazem mais sentido, todos os drivers dri estão empacotados no mesa-dri.

  • drivers vdpau agora estão no pacote mesa-vdpau.

URL da notícia: https://www.archlinux.org/news/mesa-updated-to-1030/

Como manter sua suite de testes saudável

Depois de uma longa pausa por causa da demanda que o #S7TDD me gerou, retorno das sombras para continuar com as polêmicas do Test-first. Hoje, retomo com algo primordial, principal, essencial, o must have em Test-first: nada menos do que ele, a manutenção da suite de testes.

Voltando

O que é a manutenção da suite?

Partindo do princípio de que sua suite está em constante crescimento, você uma hora ou outra irá se perguntar em como organizar a casa para evitar se perder e não se enrolar com seus testes de unidade.

Para tanto, a manutenção da suite é importante e, quanto mais você praticar Test-first, mais simples e eventual torna-se-á tal manutenção.

E para que preciso saber/fazer isso?

Como nem todo mundo está no nível de Robert Martin (@unclebob), se reorganizar torna-se importante para continuar vendo resultado no Test-First e principalmente, continuar entendendo como o software funciona só de olhar um punhado pequeno de testes de unidade.

Perder o controle da suite é relativamente fácil principalmente quando estamos começando com testes de unidade, pois como muitos questionam: “mas e as junções? você não une as coisas nunca?”. A vantagem do Teste de Unidade mora justamente no cerne apontado nesta frase, mas como tudo tem um viés, você precisa estar atento justamente com a manutenção deste monte de teste de unidade espalhados pelo seu /specs.

Sejamos pragmáticos aqui: sua suite está precisando de uma reorganizada quando você lê um teste e não entende o que aquilo está fazendo dentro de um contexto macro. Deixando a explicação fancy de lado, temos:

  1. Pegue um teste de unidade aleatoriamente;
  2. Leia e veja o que ele implementa (funcionabilidade);
  3. Tente reproduzir aquela situação em um Controller, Command, etc, ou seja, suponha que você viu o teste e deseja criar a funcionalidade numa Action de Controller qualquer;
  4. Ache uma outra funcionalidade que se relacione com essa primeira que você reproduziu;
  5. Leia o teste dela, tente reproduzi-la ligando a primeira funcionalidade na segunda.

Conseguiu entender ambos os testes e relacionar as funcionalidades? Parabéns, sua suite está saudável (por enquanto haha).

Restabelecendo a ordem na casa (dos testes)

A primeira coisa a se fazer caso os steps acima não tenham dado resultado é verificar a anatomia dos testes de unidade. Às vezes, você acumulou duas ou três funcionalidades em um mesmo teste de unidade sem perceber. Ao splitar estes testes em testes específicos para cada situação, a legibilidade irá saltar de um espaguete para algo compreensível. Costumo dizer que esta é a principal dica para quem quer arrumar a legibilidade dos testes.

Supondo que o problema da anatomia está resolvido, podemos melhorar a legibilidade seguindo o Ubiquitous Language descrita por Eric Evans em seu renomado livro Domain-Driven Design cujo já o mencionei aqui algumas vezes no passado. Dar nomes é algo complicado (veja pelas ruas das cidades). O nome é a coisa mais importante do seu código. Isto é o elo entre o código e a vida real, solicitada e falada o tempo todo por alguém de business. Quanto mais você incorporar os nomes que ouve no código, mais natural ficará as reuniões de planejamento/sprint.

Nosso item número três do check-list é o Princípio da Responsabilidade Única (SRP, sigla em inglês). Lê isso: seu método em teste precisa fazer apenas uma coisa. Ele pode entretanto, se relacionar com outros objeto#metódo para complementar sua atividade, pedindo uma espécie de suporte. Pode também delegar atividades para outros objeto#método. Pode inclusive, se passar como parâmetro para outros objeto#método. Veja a quantidade de recursos em Design Orientado a Objetos que você tem a disposição para não violar a SRP e você aí fazendo 3, 4, 5 steps em um único método sem a menor necessidade. Vai entender, né?

Sério. SRP é TOP 3 não é por acaso. Ela é aqui na minha lista a primeira que trata de código e OOD. As outras duas são mais arquiteturais e convenções do que código na prática.

Acredito que estas três dicas farão o trabalho de reduzir o caos que sua suite possa estar enfrentando enquanto lê isso. Um chute nada estatístico seria 80~90% de problemas resolvidos.

Como evitar on the fly que isso aconteça?

Planeje no macro; Codifique no micro. Não entendeu? Segunda-feira que vem você entenderá o que isso quer dizer.

Shellshock, o Novo Heartbleed?

Um bug (CVE-2014-7169 e CVE-2014-6271) descoberto por Stephane Chazelas no Bash está causando uma enorme preocupação na Internet, alguns estão colocando este bug lado a lado com o Heartbleed. Mas um bug em um shell deveria causar tanta preocupação assim? O Shell não passa ser executado apenas após você se autenticar no servidor via SSH ou FTP e outros serviços? Sim… e não.

Shellshock

Shellshock, o Novo Heartbleed? é um artigo original de Mind Bending