Categoria: Geral

Software desejável

Um dos processos mais eficientes para melhorar a performance e o valor de um software é a análise de funil.

Isso é, você procura pelos “gargalos” de performance, aqueles pontos onde, se você melhorar as coisas, tudo vai fluir melhor.

Bem, software é feito para ser usado por pessoas. E aí está, geralmente, o gargalo mais óbvio para que um software dê o retorno que se espera dele.

Nós não somos racionais como gostamos de achar que somos. A maior parte de nossas motivações é emocional e intuitiva.

Por isso, se você construir software que as pessoas gostem de usar, isso pode com facilidade dobrar ou triplicar os retornos que seu software gera para seu cliente.

Isso inclui fatores objetivos, como responder rápido, ser fácil de usar, automatizar tarefas repetitivas e exigir menos passos para completar tarefas.

Mas inclui fatores subjetivos. Coisas que fazem as pessoas gostarem de um software.

Por exemplo, não basta que ele seja fácil de usar, precisa parecer fácil de usar. Não basta ser produtivo, precisa parecer produtivo.

Estou falando do valor de um bom design. O pessoal que desenvolve sites já descobriu isso há uns vinte anos.

Mas muita gente no mercado de software ainda está desperdiçando essa oportunidade. Você já reparou como são feios e complicados os ERPs, por exemplo?

É sobre pessoas

Você está no negócio de atender pessoas.

Se você desenvolve software, lembre-se de que alguém vai usá-lo. Para gerenciar coisas que importam para outras pessoas.

Se você desenvolve sites, lembre-se de que ele será acessado por pessoas. Para comunicar algo sobre outras pessoas.

Computadores são máquinas determinísticas. Ou pelo menos, são feitos para ser. Isso significa que, recebendo as mesmas entradas, um computador deveria se comportar sempre do mesmo jeito.

Seu comportamento pode ser completamente compreendido e previsto. E, se você é um programador, é exatamente isso que você estudou para fazer.

Já pessoas são o oposto. Não são máquinas, não são determinísticas. Seu comportamento também pode ser estudado e previsto, mas nunca com a mesma precisão. E isso exige um conjunto completamente diferente de conhecimento e ferramentas.

Talvez você precise gastar algum tempo para entender de pessoas. No post de amanhã vou falar sobre o porquê.

Aprenda os fundamentos: cores no CSS

Quando você se deparar com algum tipo de código, tenha a curiosidade de decifrá-lo.

Me impressiono com a quantidade de programadores que precisam escrever CSS com regularidade e nunca pararam para entender o significado dos código de cores.

É simples: uma cor RGB é composta de três números, representando as cores vermelho (R), verde (G) e azul (B). Cada um desses números pode ir de 0 a 255 (1 byte).

Então o vermelho vivo é:

rgb(255, 0, 0)

Que também pode ser escrito como:

rgb(100%, 0, 0)

Ou, em hexadecimal (255 = FF):

#FF0000

As cores que podem ser “arredondadas” para duplas de letras iguais, como essa, podem também ser escritas assim:

#F00

E é isso. Da próxima vez que você escrever uma cor, vai saber o que significa. Agora pesquisa sobre RGBA, você via ver como fica fácil entender.

Mas não é só sobre cores. Faça isso sempre que se deparar com qualquer tipo de código, tente entender o que ele significa, você vai gastar um pouquinho de tempo no início, mas a vida vai ficar muito mais fácil depois.

Você está no negócio do conhecimento

Joel Spolsky diz que um bom programador pode ser 5 ou 10 vezes mais produtivo que um programador medíocre.

Esses números, postos desse jeito, talvez não dêem a dimensão do que isso significa. Você preferiria trabalhar com alguém porque ele é 10% mais produtivo? Que tal 20%? Com certeza!

Não estamos falando de um ganho de 10% ou 20%, estamos falando de um ganho de 400% a 900%!

Você quer ser esse programador? Então vai estudar, filhão!

Eu sei que tem assuntos demais para ser estudados, que é difícil escolher qual linguagem, framework, ferramenta ou técnica aprender em seguida. Mas não use isso como desculpa! Larga um pouco o Free Fire e investe na sua carreira.

Faço uma aposta com você: meia hora por dia, por seis meses. Daqui a seis meses você pede um aumento, ou arruma um emprego melhor. Duvido que não funcione.

Não seja escravo das suas ferramentas

Muita gente que, como eu, tem um blog, usa o plugin Yoast SEO para WordPress. É muito bom, uma escolha óbvia. Ele praticamente lê seu texto e te diz o que você tem que fazer para melhorar a indexação.

O problema? Muitas vezes, otimizar seu texto para uma determinada palavra-chave o torna chato de ler. Seu texto fica mais ou menos assim:

… Ao usar um plugin de SEO para WordPress, você corre o risco de escrever um texto mecânico. É verdade que plugins de SEO para WordPress são uma coisa boa, mas você precisa tomar cuidado para não deixar seu plugin de SEO para WordPress mandar em você…

Você quer apenas ser encontrado? Tem um monte de sites por aí tão cheios de publicidade que tornam quase impossível ler o que está escrito. O objetivo é ser encontrado e gerar um clique patrocinado, apenas isso. Se é isso o que você está construindo, vá em frente, siga as regras do plugin e você vai poupar um bocado de tempo.

Mas se seu objetivo é que as pessoas encontrem, leiam e entendam o que você está escrevendo, então seguir cegamente as regras não é a melhor decisão.

Escreve para pessoas, depois faça o que for possível para agradar os robôs.

Há um tempo que eu tenho usado o Pylint em alguns projetos. Ele me avisa se eu deixo de seguir algum padrão de código. Ele até dá uma nota para o meu código!

Mas o recurso mais legal do Pylint é poder fazer isso:

import config # pylint: disable = relative-import

Ou seja, não preciso seguir as regras cegamente.

Você também pode decidir quando quebrar as regras. Escolha com cuidado.

Não é sobre quantas linhas de código você escreve

Parece haver uma certa fixação entre os programadores, principalmente os menos experientes, em quantas linhas de código são necessárias para resolver determinado problema.

Às vezes isso é bom. Veja como ler um arquivo texto em Java:

import java.io.*; 
public class ReadingFromFile 
{ 
    public static void main(String[] args) throws Exception 
    { 
	FileReader fr = 
	new FileReader("arquivo.txt"); 

	int i; 
	while ((i=fr.read()) != -1) 
	    System.out.print((char) i); 
    } 
}

Agora compare com a mesma coisa em Python:

print(open('arquivo.txt').read())

Nesse caso, parece óbvio que a resposta em Python é muito melhor, não? Agora olhe esse código em JavaScript:

urlscore = url.indexOf('http') ? -1 : (url.indexOf('https://')+1)*5 + 
                                      (url.split('/')[2].indexOf('www')?1:0)*2 + 
                                      (url.split('/')[1].indexOf('@')>-1?-1:1)*3

Uau! O sujeito reduziu a função inteira a uma única expressão! Parece uma boa ideia pra você? Coitado de quem tiver que dar manutenção nisso!

Seu inimigo não é a quantidade de código, é a complexidade. É difícil dar uma boa definição técnica de complexidade, mas você a reconhece quando vê.

Seja conservador (não, não é sobre política)

Eu tenho andado por aí com um caderno. Não um desses Moleskines descolados. O meu é um clássico Tilibra de dez matérias, que você pode comprar por doze reais em qualquer papelaria.

Durante milênios a humanidade, ou a parte dela que tinha o privilégio de saber escrever, escreveu a mão. Eu, que vivo de tecnologia, acho uma maravilha poder escrever com um teclado, como estou fazendo agora.

Mas percebi que alguma coisa diferente deve acontecer no cérebro quando a gente escreve a mão. E isso está me fazendo um bem enorme.

A gente usa teclados há duas gerações. Telas touch, há uns quinze anos.

Talvez, daqui a cinquenta anos, a humanidade esteja lamentando o quanto a gente perdeu por deixar de escrever e terceirizar nossa memória. Por deixar que os alunos simplesmente tirem fotos da lousa ao final da aula.

Talvez não. Mas por que correr esse risco? Você pode continuar usando teclados, esfregando suas digitais em pequenas telas de vidro ou falando com seu telefone. Mas experimente o velho e bom papel com caneta, pode funcionar pra você.

O ano do Linux no Desktop (não como você esperava)

O Windows 10 vai incluir um kernel Linux completo. O ChromeOS é baseado no kernel Linux.

Seria 2019, finalmente, o “ano do Linux no Desktop”?

Eu não certeza das implicações disso.

Eu sei que o que você esperava era a popularização do Gnome. Ou do KDE, ou XFCE, ou Enlightenment, ou Mate… Tanto faz, certo? Não importa qual interface gráfica, se o coração for Linux.

Então, será que faz diferença se a interface é Windows ou ChromeOS? O resultado final é que você vai poder escrever aplicações baseadas no Linux para rodar em todo lugar.

E, sinceramente, a web já tinha tornado essa discussão meio irrelevante.

Exceto para nós, programadores, que vamos poder desenvolver usando qualquer sistema operacional. Para o resto do mundo, a maior parte do tempo, o sistema operacional é o navegador.

Quanto mais óbvio, melhor

Quando você está escrevendo código, pense sempre em quem vai ter que lê-lo no futuro. Pode ser você mesmo. Pode ser você mesmo, daqui a cinco, às duas da manhã, correndo para consertar um bug.

É por isso que padrões e convenções são uma ideia tão boa.

Quanto tempo você já passou olhando o código de alguma aplicação, tentando descobrir onde estão as coisas? No web2py, um dos meus frameworks favoritos, quando você cria uma nova aplicação, a pasta de código se parece com isso:

Aplicação nova em web2py, ainda sem nenhum código.

Web2py é um framework MVC, que, você sabe, é a sigla para model, view e controller. Para acessar o banco de dados você escreve um model. E como se chama a pasta onde estão seus models? Ok, models. E as regras de negócio devem ir num controller. E onde estão seus controllers? Na pasta controllers, claro. E as views na pasta views.

Zero esforço para entender, zero esforço para decorar.

Eu sei que é bem pouco esforço decorar que, no seu novo framework da moda, as views estão dentro de /presentation/templates/html, os controllers em /app/core/controllers e os modelos em /persistence/rdbs. Mas pouco é infinitamente mais do que zero. E, acredite, esses pequenos esforços, somados, fazem um bocado de diferença.

Site não seguro – como resolver de graça com Let’s Encrypt

No começo de 2017, o Google Chrome passou a mostrar um aviso para os usuários, com o texto “não seguro” na barra de endereço quando um site sem HTTPS pede dados do usuário. Classificou a maioria dos sites como “site não seguro”. Assim:

Aviso de site não seguro do Chrome

Essa mensagem aparecia apenas em situações onde o site potencialmente ia coletar dados dos usuários. Basicamente, quando havia um formulário na tela. Principalmente formulários de login, mas a mensagem aparecia para praticamente qualquer formulário. Logo, durante todo o ano passado, você poderia manter um site de conteúdo sem HTTPS, sem problema nenhum, desde que não tivesse formulários.

Recentemente, porém, o Google passou a avisar site não seguro para qualquer site sem HTTPS. Assim, até o Pudim, um site que não tem formulário, nem scripts, nem nada, só uma foto de um pudim, está marcado, veja:

Site Pudim marcado pelo Chrome como site não seguro
Até o Pudim agora é um site não seguro, pobre Pudim 🙁

Tenho um site não seguro. Como resolver? Let’s Encrypt!

Essa iniciativa do Google Chrome não está sozinha. Faz parte de um esforço de várias frentes para tornar a web mais segura. O próprio Google anunciou que está privilegiando nas buscas sites com HTTPS. Quer dizer que, ao estar marcado como site não seguro, seu site não apenas vai assustar os usuários que receber, também vai receber menos usuários.

O próprio Google Chrome, junto com empresas como GitHub, Facebook, Cisco e Akamai, patrocinam uma iniciativa chamada Internet Security Research Group, que oferece, através do Let’s Encrypt, chaves SSL grátis e automáticas para qualquer site.

Assim, se o seu provedor dá suporte a Let’s Encrypt, você provavelmente pode ter seu site marcado como seguro em poucos cliques. Meu hosting predileto, por exemplo, é a Dreamhost. Se você hospeda seu site lá, pode ativar SSL em seu site em três cliques, aqui:

Página Secure Hosting no painel da Dreamhost
Viu ali? Let’s Encrypt SSL.

Se você mantém seus próprios servidores, dedicados ou VPS, você vai ter que instalar o Let’s Encrypt você mesmo. O processo é bastante simples. Expliquei nesse vídeo:

HTTPS com Let’s Encrypt

Mantenha seus servidores enxutos

Foi divulgada ontem uma vulnerabilidade no servidor de compartilhamentos Samba, usado por máquinas Linux e FreeBSD para compartilhar arquivos e recursos em redes Windows. É uma falha grave, simples de explorar, e que afeta versões do Samba desde a 3.5.0, lançada há sete anos.

Então, se você usa Linux, confira se você tem o Samba instalado. Se tiver, confira a versão menor (aquele terceiro número no código da versão). Se você estiver usando uma das seguintes, você está seguro: 4.6.4, 4.5.10 ou 4.4.14.

Se não. Você pode fazer uma das seguintes coisas:

  1. verificar se há atualização do Samba para sua distribuição, e se a versão mais atualizada é uma dessas acima; ou
  2. baixar o código fonte e compilar o Samba você mesmo, de preferência da versão 4.6.4; ou
  3. desligar o serviço vulnerável, adicionando ao seu smb.conf a linha abaixo: 
    nt pipe support = no

    E em seguida reiniciando o Samba; ou

  4. desinstalar o Samba

A última alternativa pode parecer a mais preguiçosa, e talvez você simplesmente não possa cogitá-la. Mas eu recomendo que você se pergunte, antes de qualquer outra atitude: eu preciso mesmo desse serviço? Dessa vez foi uma falha no Samba, mas praticamente todo dia saem atualizações de segurança para os diversos softwares e serviços que você pode instalar em seu sistema. Cada software não utilizado que você mantém instalado aumenta suas chances de ter problemas de segurança e suas preocupações com atualizações de versão.

Nesse caso, menos é mais. Reduza os pacotes que você tem instalados aos essenciais, removendo tudo o que você não usa. Principalmente em servidores. Isso vai tornar suas máquinas mais seguras e vai tornar mais fácil para você manter tudo atualizado.

Assine a companhe os boletins de segurança dos softwares que você usa. Você não quer correr o risco de não ficar sabendo de uma atualização crítica e ter seu sistema vulnerável simplesmente por não ter sido avisado, não é?

Por fim, é importante que você saiba que a essa falha de segurança no Samba é especialmente preocupante porque muitos dispositivos NAS e outras soluções de armazenamento de dados usam Samba. Então se você possui um equipamento de armazenamento de dados, é bom investigar se ele usa Samba e está vulnerável a essa falha.

PS: obrigado ao Rodrigo por me avisar.

Hacker instalou um Backdoor secreto em servidores do Facebook para capturar senhas

Você viu essa notícia?

Hacker Installed a Secret Backdoor On Facebook Server to Steal Passwords

Resumindo, um hacker descobriu um servidor do Facebook (files.fb.com) rodando uma versão desatualizada de um software de compartilhamento de arquivos e conseguiu, através disso, fazer upload de um PHP Web Shell. Ou seja, acesso shell ao servidor.

No post original do cara que descobriu a falha você pode achar uma porção de detalhes técnicos muito interessantes.

O que é esse backdoor secreto?

Backdoor (“porta dos fundos” em inglês) é um software oculto que permite a quem o instalou acesso ao servidor. Um webshell é um backdoor que pode ser acessado em uma interface web. Existem webshells em PHP, ASP, Python, Ruby, C#, Perl e é muito fácil construir um em sua linguagem predileta.

Veja um exemplo de tela de um web shell em PHP:

Webshell em PHP
Webshell em PHP (clique para ampliar)

E seu site, é seguro?

Lição importante que você tirar desse episódio: uma corrente é tão forte quanto seu elo mais fraco. Seu servidor de controle de versão, seu software de gestão de projetos, seu webmail, todas as aplicações web acessórias ao seu site, todos os seus servidores e os computadores da sua equipe precisam estar seguros.

Por exemplo: se seu servidor git tiver o Open SSH desatualizado, se um dos programadores que desenvolve seu site instalar um software malicioso por engano ou se a sua senha do registro de domínios não é forte o suficiente, seu site estará vulnerável, não importa quão bom seja seu código.

Salvando diff em HTML

Comece instalando as ferramentas:

sudo apt-get install colordiff kbtin

Agora você pode:

diff arquivo1.txt arquivo2.txt | colordiff | ansi2html > diff.html

Ou, com git:

git diff | colordiff | ansi2html > gitdiff.html

Você também pode salvar a saída de qualquer comando que retorne ANSI colorido:

ls -lha --color | ansi2html > ls.html

Escondendo processos dos outros usuários

Por padrão, todos os usuários de uma máquina podem ver todos os processos rodando. Tente, por exemplo:

ps aux|grep root

Quase tudo em Linux é representado como arquivos. As informações sobre os processos rodando estão em arquivos virtuais dentro de /proc. Você pode remontar /proc, passando uma opção para controlar a visibilidade dos processos, assim:

sudo mount -o remount,rw,hidepid=2 /proc

Em seguida, tente novamente:

ps aux|grep root

Você vai ver que os usuários, com hidepid=2, não poderão ver processos de outros usuários. Para desfazer, execute:

sudo mount -o remount,rw,hidepid=0 /proc

Assim, você pode configurar seu servidor para que um usuário não possa saber o que os outros estão fazendo.

Yes we can! Minha apresentação no TDC 2015.

Agora que o Internet Explorer 8 morreu, e o número de usuários do Internet Explorer 9 é quase insignificante, há uma porção de recursos do CSS que finalmente podemos usar.

Essa é a primeira palestra de uma série, que inclui outros recursos do CSS, HTML5, SVG e Javascript. Em breve publicarei as outras, incluindo vídeos. Enquanto isso, veja os vídeos que publiquei recentemente:

Para onde foi a performance do seu Linux? Glances nele!

Glances é a melhor aplicação que eu já vi para análise de performance no Linux. Veja um screenshot:

glances

Numa tela simples de terminal temos uso de memória, CPU, rede, I/O e espaço em disco. Aperte h para ver a ajuda.

Para instalar:

sudo apt-get install glances

E para executar:

sudo glances

Claro, se você não usa Debian/Ubuntu, troque apt-get por yum, pacman, emerge ou o comando correspondente em sua distro.

Easter eggs no Python e um pouco mais

Todos gostamos de easter eggs, certo?

Então rode o python e se divirta:

import this
import __hello__
from __future__ import braces
import antigravity

E uns outros que eu acho interessantes:

No vim, tente:

:help 42
:help holy-grail
:help UserGettingBored
:help!
:Ni!

Esses agora, são apenas para Debian, Ubuntu e derivados. Tente isso e dê uma olhada na última linha:

apt-get help

Depois tente:

apt-get moo

E depois de ter visto esses dois do apt, esse aqui vai fazer um bocado de sentido:

aptitude help
aptitude moo
aptitude -v moo
aptitude -vv moo
aptitude -vvv moo
aptitude -vvvv moo
aptitude -vvvvv moo
aptitude -vvvvvv moo

E o último dessa série (talvez você precise instalar o apt-build para ver):

apt-build moo

Se você é um administrador de servidor, pode deixar um easter egg para seus usuários sudoers. Rode:

sudo visudo

E inclua, no bloco de configurações começando com “Defaults”, a seguinte linha:

Defaults insults

Salve e saia. Agora, quando um usuário sudoer errar a senha, o sudo vai insultá-lo em retribuição.

Esses próximos estão na internet, mas devem ser aproveitados num terminal:

telnet towel.blinkenlights.nl
traceroute -m 254 -q1 obiwan.scrye.net

É isso. Conhece mais? Deixe aí nos comentários.

Faça o Google falar por você

Ah, a internet! Você, usuário de Linux, comece pela preparação:

sudo apt-get install curl mpg123

Depois crie o script falador:

#!/bin/bash
l=pt-BR
if [ "$1" == "-l" ];then
  shift
  l=$1
  shift
fi
curl -A "Falador" translate\.google\.com/translate_tts -d "tl=$l&ie=UTF-8&q=$@" |mpg123 -;

Dê permissão de execução:

chmod +x falador

E divirta-se:

./falador "Onde está o futuro que nos prometeram?"
./falador -l en "Luke, I am your father."