<world> as a player<world> kills a player, add -1 to player’s kill countWorking with files is a common practice for any developer. Using awk not so much, even though it is IMHO one of the best tools for doing so:
Intending to spread the knowledge of the tool to more people, let’s solve the challenge with AWK and get to know how you can effectively start using it today in your workflow. I assume you know well a programming language, your way around a (*nix) CLI and that we are using GNU awk.
As it is common with other Unix tools, it is better to break the program into smaller pieces, Awk programs bigger than ~150 lines are difficult to maintain. Here are the different programs we are going to create:
clean.awk will read input files, which are the original log files,
and output a cleaner version of their content.
Containing just the data we need to manipulate and use.scoreboard.awk will use the output from the previous program to produce
the score boards for each game.Let’s create a walking skeleton to run and debug our progress while tackling the challenge:
$ mkdir /tmp/awk-quake
$ cd !$
$ curl --remote-name -L https://gist.githubusercontent.com/cloudwalk-tests/be1b636e58abff14088c8b5309f575d8/raw/df6ef4a9c0b326ce3760233ef24ae8bfa8e33940/qgames.log
$ tail qgames.log
13:55 Kill: 3 4 6: Oootsimo killed Dono da Bola by MOD_ROCKET
13:55 Exit: Fraglimit hit.
13:55 score: 20 ping: 8 client: 3 Oootsimo
13:55 score: 19 ping: 14 client: 6 Zeh
13:55 score: 17 ping: 1 client: 2 Isgalamido
13:55 score: 13 ping: 0 client: 5 Assasinu Credi
13:55 score: 10 ping: 8 client: 4 Dono da Bola
13:55 score: 6 ping: 19 client: 7 Mal
14:11 ShutdownGame:
14:11 ------------------------------------------------------------
$ cat clean.awk
{ print }
$ watch gawk -f parse.awk qgames.log
Above we:
qgames.logclean.awk that prints everything passed to itwatch) to see its result
while we change it in another session (to stop watch, use CTRL-C)Let’s change clean.awk to filter just the lines useful to us, and help us debug
what to do with them:
BEGIN {
FS = " "
LFS = "\n"
}
/Init/ { print }
/kill/ { debug_fields() }
function debug_fields()
{
for (i = 1; i <= NF; i++) {
printf("%d: %s\n", i, $i)
}
}
Don’t despair yet, it is pretty simple what we are doing:
BEGIN is a special block, that gets executed once at the start
of the parsing:
FS defines the field separator (space). It is used to break
a matching line into a smaller array of objects.LFS defines the line separator (new line). Everything until
that character will be treated as a line./match/ { action } blocks execute a set of actions when a match (regex supported) is found:
/Init/ { print } prints every line that has Init on it, without doing anything more./kill/ { debug_fields() } executes the debug_fields() function for every line that has a matching kill string on it.function debug_fields() prints all fields identified after breaking the line with FS:
NF is a special variable containing the number of fields parsed for the current line.$n is the field n parsed. Inside the loop $i will become $1,
$2 and $3 allowing us to retrieve the contents of every field on that
line, displaying something like:
1: 20:54
2: Kill:
3: 1022
4: 2
5: 22:
6: <world>
7: killed
8: Isgalamido
9: by
10: MOD_TRIGGER_HURT
debug_fields() action to print $6 " killed " $8.With little changes, we can use $6 (killer) and $8 (killed) to display who
killed who, which is pretty much everything we need.
🐛 If player names would not contain spaces we’d be ready. But Assassinu Credi, for example,
breaks our algorithm because we use spaces to separate fields.
When he kills someone $8 will killed instead of the other player name.
Let’s see this happening:
BEGIN {
FS = " "
LFS = "\n"
}
/Init/ { next }
/Assas/ { print $6 " killed " $8 }
The program above ignores (with next action) lines matching Init and prints
just lines matching Assas.
$ awk -f clean.awk qgames.log
Zeh killed Assasinu
<world> killed Assasinu
Isgalamido killed Assasinu
Zeh killed Assasinu
Assasinu killed killed
Note that Assasinu killed killed line is wrong. It doesn’t have the name of
the killed player. Let’s fix this!
The end clean.awk program is below. It substitutes some strings by nfs
(new file separator) variable and removes the prefix on lines that notifies
of a kill:
BEGIN {
FS = " "
LFS = "\n"
nfs = "|"
current_game = 0
}
/Init/ { current_game++ }
/kill/ {
sub(/^[ 0-9:]+ Kill: [0-9: ]+/, "", $0)
sub(/ killed /, nfs, $0)
sub(/ by /, nfs, $0)
print $0 nfs current_game
}
BEGIN section, declares 2 new variables:
nfs to separate output by something other than spaces, so next programs
easily support player names with them.current_game is a variable that gets incremented every time a new game starts./Init/ marks a new game:
current_game for the next time it gets used/kill/:
sub(regex, replacement, target) will put replacement into every matching
regex on target, replacing target. $0 is the whole current line.sub(/^[ ... removes the prefix of the line until the player name.sub(/ by... and sub(/ killed... replaces these matches by nfs (the
new field separator), allowing us to easily identify ($1) the killer,
($2) who got killed and ($3) how he got killed.print will print the current line ($0) with the current game as a suffix:
sub() replaces the current line ($0), we now have only
what we needed.Executing the program above, produces:
$ awk -f clean.awk qgames.log | tee qgames-clean.log
<world>|Isgalamido|MOD_TRIGGER_HURT|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
Isgalamido|Mocinha|MOD_ROCKET_SPLASH|2
Isgalamido|Isgalamido|MOD_ROCKET_SPLASH|2
Isgalamido|Isgalamido|MOD_ROCKET_SPLASH|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
<world>|Isgalamido|MOD_FALLING|2
<world>|Isgalamido|MOD_TRIGGER_HURT|2
Isgalamido|Mocinha|MOD_ROCKET|3
<world>|Zeh|MOD_TRIGGER_HURT|3
With the qgames-clean.log file we can now easily achieve every objective of
the original challenge without having to deal with:
FS = "|" we use | as field separator and have:
$1 as the killer$2 who got killed$3 how killer killed killed$4 in which game that happenedHow about you try to figure out the rest? I will post my solution and, if you learned something from this, I promise you will learn something else on the next one as well.
The Gnu awk’s manual is really good - from a time technical documents were worth reading. You don’t need to read everything, the index will take you where you need. Pinky promise!
I won’t leave you without anything though, here is a beginning for scoreboard.awk:
BEGIN {
FS = "|"
}
{
# Sets a player as a key in the players array
players[$1] = $1
players[$2] = $2
}
END {
# Removes <world> from players
for (name in players) {
if (name == "<world>")
continue
print name
}
}
Let me know of your solution, suggestions or doubts in the comments! ❤️
]]>Meu objetivo com essa estrutura é mostrar que você já sabe testar. Minha hipótese é que mostrando como automatizar um teste sem nenhuma ferramenta fica mais fácil entender como usar o PHPUnit.
Automatizar testes não é tão óbvio quando pode parecer e é bem difícil escrever bons testes - justiça seja feita que é difícil até definir o que é um bom teste. A receita pra isso é tentar, falhar e aprender com isso. Levei mais de 5 anos pra me sentir confortável com o conceito.
Você sempre checa se o que você fez funciona ou não, isso é testar. É normal escutar pessoas dizendo que “não sabem testar” quando na verdade elas querem dizer que não sabem fazer isso de forma automática. A exemplo o teste abaixo:
$ echo "Hello World!"
Hello World!
O output é exatamente o esperado então o teste é um sucesso! Falhas podem acontecer de diversas formas:
$ echp "Hello World!"
-bash: echp: command not found
O output do comando acima é uma falha, por exemplo. Se você que automatizar seus testes precisa aprender que eles possuem basicamente duas condições: sucesso ou falha.
Automatizar significa criar um programa que faça essa verificação sozinho pra nós e nos diga se tudo deu certo ou não. Daí vem a primeira confusão:
Um teste pode ser composto por várias verificações e se uma verificação falha o teste falha como consequência. Para automatizar o um teste precisamos saber quais verificações podemos ou iremos fazer, seguindo o exemplo anterior podemos verificar:
A mim, a lista de verificações passíveis de automatização são uma das tarefas mais difíceis e que nenhum framework de teste unitário irá fazer por você. Implementar todas as verificações é uma excelente ideia mas com o tempo você nota que existe um ideal e o ideal agora é só verificar se o comando é executado com sucesso.
Toda shell, ao executar um comando, popula a variável $? com 0 (zero) caso
sucesso e é nesse comportamento que vamos verificar todo nosso comportamento:
$ echo "a"
a
$ echo $?
0
$ echp "a"
-bash: echp: command not found
$ echo $?
127
Sabendo o que precisamos verificar, podemos escrever nosso teste. Ele será
um programa shell que terminará com 0 (zero) no caso de sucesso além de
imprimir “ok”.
#!/usr/bin/env sh
# 1. Executa o comando
# O `> /dev/null` faz com que o output do comando não seja exibido
echo "Hello World!" > /dev/null
# 2. Verificamos a saida
if [ "$?" == "0" ]
then
# 3. Imprime sucesso
echo "Ok"
# 4. Sai com status 0 (zero) de sucesso
exit 0
else
# 3. Imprime erro
echo "Error"
# 4. Sai com status 1 (um) de erro
exit 1
fi
Toda vez que executarmos o programa acima, ele fará a verificação de forma automática. Apesar do programa acima não parecer muito útil, ele é a estratégia que todas as ferramentas de Integração Contínua usam: verificar o exit code de um comando. Apesar dele não parecer muito útil, você aprendeu uma lição fundamental para fazer seu próprio sistema de integração contínua.
É aqui que a maioria dos frameworks de teste entram. Apesar deles já possuírem diversas ferramentas que auxiliam na verificação, o que eles inicialmente provêm é uma forma de organizar suas verificações e de executar elas.
O PHPUnit, por exemplo, trata todas as classes com sufixo Test e que
herdam PHPUnit\Framework\TestCase como uma suíte (conjunto) de testes e todo
método com o prefixo test como um teste. Se nós quisermos algo semelhante,
precisamos:
A estrutura que nossos testes terão é simples e eficiente, e não muito diferente do que várias ferramentas oferecem:
testAgora precisamos de um programa para executar todos os testes. Esse programa, assim como nossa verificação automatizada e nossos testes, irá terminar com exit code 0 (zero) em caso de sucesso.
$ ls tests/*.sh
tests/hello.sh
O ls acima irá listar todos os arquivos .sh dentro do diretório tests,
podemos usar a saída desse comando em um for que será executado para cada item
encontrado:
#!/usr/bin/env
# 1. Busca todos os testes existentes
for test in $(ls tests/*.sh)
do
# 2. Garante que o teste possa ser executado
chmod a+x "${test}"
# 3. Executa o teste
$test > /dev/null
if [ "$?" != "0" ]
then
# 4. Saída com status 1 (um) de erro
exit 1
fi
done
# 4. Saída com status 0 (zero) de sucesso
exit 0
Agora não importa quantos testes tenhamos no diretório tests, sempre que
executarmos o programa acima vamos ter o resultado de sucesso caso todas as
nossas verificações passem.
Falta fazer a parte de relatório, mas acho que você já pegou as manhas do que estamos fazendo. Existem padrões de relatório de testes automatizados:
Esses formatos padrão de relatório de execução são importantes só para integração com outras ferramentas, que normalmente são ferramentas de Integração Contínua.
Existe um vídeo deu apresentando essa ideia e como usar o PHPUnit para automatizar seus testes que vai um pouco além do escrevi aqui.
Recomendo alguns livros também:
Se você quiser qualquer dica, ou tiver alguma crítica ou sugestão, dê um toque! Se eu puder der uma dica a você que nunca fez um teste automatizado ela é a de começar logo. Além da curva de aprendizado natural, leva um tempo aprender que nem todo código é automaticamente testável e mais tempo ainda em como fazer isso e os livros acima ajudam bastante a reduzir esse tempo.
Como eu convenço meu chefe de que isso é importante?
No começo desse post eu tentei explicar que você faz isso de um jeito ou de outro. Começar a fazer testes de maneira automática reduz o seu trabalho e se tudo der certo você vai começar a entregar trabalho com mais qualidade.
Se você precisa aprender a fazer testes automáticos, daí a conversa com seu gestor é outra.
Como eu testo algo que já existe e o código é ruim?
Você pode usar testes de comportamento para testar a aplicação inteira. Eles são mais lentos e precisam de algumas condições anteriores (usuário existir, produto, etc) mas vão entregar valor rápido e costumam ser mais simples de entender e fazer no início.
]]>Um código bom é como um livro do Isaac Azimov: curto, expressivo e inspirador. Ele esconde camadas e mais camadas de decisões nos lugares onde elas pertencem, através de uma interface clara e extensível.
Você precisa consumir código bom, como o Unix, e ser preguiçoso. Pegue uma tarefa repetitiva no seu dia a dia e a automatize. Considere o terminal como sua IDE e viva com ele:
Estude código de outras pessoas, pegue um projeto que você usa e vá aprender como ele funciona. Pare de achar que ignorância e economia de tempo são a mesma coisa, que esse conhecimento em nada vai agregar na sua vida. Você sabe como os Mocks do PHPUnit funcionam, por exemplo? Que praticamente tudo que usa no ZSH é possível no BASH, sem todos os problemas?
Nada me ensinou, e me ensina, tanto quando o Unix. Então leia. Se permita ser mais preguiçoso e pare de reinventar a roda.
]]>Continuando a mesma série de exemplos, vamos ver como unir dado e comportamento para melhorar a comunicação com nossos usuários (desenvolvedores).
Nos examplos anteriores, tínhamos um valor de desconto em dinheiro. Um desconto só é útil se aplicado à alguma coisa, certo? Como nossa empresa fictícia vende livros, vamos ver como seria usar dar desconto em um livro:
namespace MyApp\Promotion;
$book = new Product('Object Thinking (Developer Reference)', 60.00);
$blackFriday = new Discount\Money(10.00);
$finalPrice = $book->getPrice() - $blackFriday->getValue();
$book->setPrice($finalPrice);
No exemplo acima temos duas classes representando dois dados diferentes: desconto
e produto. Veja que o comportamento de cálculo do desconto não esta encapsulado
em nada, vamos resolver isso:
namespace MyApp\Promotion;
class DiscountCalculator
{
public function applyDiscountOnProduct(
Discount\Money $discount,
Product $book
) {
if ($discount->getValue() >= $book->getPrice()) {
$message = sprintf(
'Discount (%01.2f) is greater than book price (%01.2f).',
$discount->getValue(),
$book->getPrice()
);
throw new \UnexpectedValueException($message);
}
return $book->getPrice() - $discount->getValue();
}
}
Agora temos nosso comportamento agindo em dois dados diferentes. Apesar de ser um exemplo com classes, nada impede os seus dados de serem um array ou qualquer outra estrutura de dados (apesar de saber que você prefere objetos 😉).
Vamos ver como fica o uso deles com nossa classe tilanga:
namespace MyApp\Promotion;
$calculator = new DiscountCalculator;
$book = new Product('Object Thinking (Developer Reference)', 60.00);
$guguFriday = new Discount\Money(50.00);
$customerCart = $calculator->applyDiscountOnProduct($guguFriday, $book);
Repare como a calculadora depende sempre dos dois objetos mas principalmente do desconto, que é quando ela é necessária. Separar dados de comportamento pode ser útil em alguns casos mas existe um grande poder (de comunicação) em unir ambos, além de ser um dos fundamentos da Orientação a Objetos:
Código procedural pega uma informação e toma uma decisão. Código orientado a objetos pede que objetos façam coisas.
Alec Sharp
Separando dado de comportamento você cobra do usuário o conhecimento dos comportamentos associados ao dado. Toda vez que alguém quiser saber o preço que algum cliente pagou (ou vai pagar) por algo, ela precisa saber dos descontos e aplicá-los. Você acha mesmo que elas vão sempre saber disso?!
Papai Noel não existe, nem o coelhinho da páscoa. #prontofalei
O Tell, don’t ask basicamente diz que juntando os dois (dado e comportamento) em uma única classe, o desenvolvedor precisa saber menos e o código tende a ficar mais conciso (e coeso, como consequência).
Como ficaria nosso exemplo de desconto em dinheiro usando ele?
namespace Myapp\Promotion\Discount;
class Money
{
private $amount = 0.00;
public function __construct($amountToDiscount)
{
$this->amount = $amountToDiscount;
}
public function calculateProductFinalPrice(Product $product)
{
$newPrice = $product->getPrice() - $this->amount;
if ($newPrice <= 0.00) {
$message = sprintf(
'Discount (%01.2f) is greater than book price (%01.2f).',
$this->amount(),
$product->getPrice()
);
throw new \UnexpectedValueException($message);
}
return $newPrice;
}
}
Pronto. Jogamos a calculadora fora, tiramos o método de acesso pra retornar o valor do desconto e colocamos o método da calculadora dentro do desconto.
Antes o desenvolvedor precisava saber o que fazer com aquele valor, agora ele precisa decidir se o que ele precisa é o valor do produto com o desconto aplicado ou não. É justamente desse fato que sai o nome do princípio: antes de permitir algum usuário de pedir alguma coisa (dado), diga/ofereça a ele as ações (comportamentos) que ele pode usar naquele objeto (dado+comportamento).
$book = new Product('Object Thinking (Developer Reference)', 60.00);
$blackFriday = new Discount\Money(10.00);
$customerCartValue = $blackFriday->calculateProductFinalPrice($book);
Pensando sempre em quem vai usar seu código, inclusive você, o código acima é mais simples e menos propenso aos erros de interpretação no futuro.
Como todo comportamento de desconto está disponível e pronto pra usar, expor o valor de desconto através de um método de acesso é desnecessário. Esse menor nível de exposição torna o encapsulamento dos algoritmos melhor e portanto, mais fáceis de evoluir.
É comum nas discussões de segregar (ou não) dado de comportamento, o pessoal a favor da união de ambos citar o argumento dos modelos anêmicos em DDD mas, acho que ninguém precisa ir tão longe pra defender os benefícios desse princípio.
Agora precisamos aplicar um desconto em porcentagem. Refletindo sobre o problema, não temos muito a fazer além de criar outra classe de desconto e mudar ou pouco como o valor final do livro é calculado.
Acho sempre válido você pensar nas soluções por você, se possível envie elas pra mim depois. Como agora não tenho muita opção, segue minha solução pro problema:
namespace MyApp\Promotion\Discount;
class Percentage
{
private $fraction = 0.00;
public function __construct($percentageToDiscount)
{
$value = $percentageToDiscount / 100;
$this->fraction = (float) $value;
}
public function calculateProductFinalPrice(Product $product)
{
$discountValue = $product->getPrice() * $this->fraction;
$newPrice = $product->getPrice() - $discountValue;
if ($newPrice <= 0.00) {
$message = sprintf(
'Discount (%01.2f%%) makes product cost nothing!',
$this->fraction * 100
);
throw new \UnexpectedValueException($message);
}
return $newPrice;
}
}
Usar o princípio força você a imaginar como um objeto vai ser usado e nas informações que o usuário terá quando for consumir a funcionalidade da sua classe. Pra resolver isso, eu costumo tentar fazer o código imitar uma conversa entre duas pessoas.
Quando você recebe um desconto, como a pessoa comunica esse desconto a você?
Imaginando que as três conversas fossem um código de verdade, eu penso imediatamente nos códigos abaixo:
namespace MyApp\Promotion;
// 1. Você tem 25% de desconto em qualquer produto.
$blackFriday = new Discount\Percentage(25);
// 2. Você só vai pagar 75% do produto.
$blackFriday = new Discount\Percentage(75);
// 3. Você vai pagar o valor do produto menos o valor dele multiplicado por 0.25.
$blackFriday = new Discount\Percentage(0.25);
Qualquer um dos três códigos pode funcionar, mas qual é a real expectativa do desenvolvedor quando for consumir o código existente? Deixar implementação próxima da forma como vocês conversam sobre uma funcionalidade dentro da empresa evita diversos problemas. Como na nossa empresa fictícia nos comunicamos usando o primeiro caso, implementamos ele.
Repare no nome do primeiro argumento: $percentageToDiscount. Ele tira toda a
ambiguidade do processo e elimina a necessidade do desenvolvedor precisar ler o
resto da classe. Através de um código limpo estamos sempre evitando a ambiguidade
e a dúvida onde pudermos.
As diferenças entre os casos 1 e 2 são a forma como vocês conversam sobre a funcionalidade. Já no caso 3 a coisa se degringola um pouco: Você expõe a conta de porcentagem pro cliente, o que pode ser prejudicial no futuro, como no caso dos métodos de acesso.
Existem alguns vários argumentos a favor de manter os dois separados mas de forma alguma vou esgotar essa discussão, nem que eu fosse presunçoso o suficiente pra achar que tenho essa capacidade, então minha intenção é te dar opções (ou novos problemas) pra ao menos facilitar sua escolha.
O primeiro argumento contra a separação costuma ser o da violação de SRP, o que é ótimo se a pessoa se embasar na questão de responsabilidade. É ótimo porque a questão de responsabilidade em nada viola a unidade de dado e comportamento. “Um motivo pra mudar” é o que define “responsabilidade” no SRP, se você fizer um bom trabalho de design você consegue ter ambos. Ninguém disse que ia ser fácil.
O segundo argumento é chato e costuma tocar objetos que precisam ser mapeados ou serializados. Nesse caso, você tem uma classe que possui informações além de um método que retorna o mapamento daquele objeto pra outro. Você pode isolar o mapeamento em outra classe e sempre que a estrutura de dados mudar, mudar essa classe-mapa também - resumindo, uma bosta. Você pode usar Reflection e fazer esse mapeamento com Inflexão, é um jeito melhor de resolver esse determinado problema e tenho certeza que não é o único. Aqui o argumento é chato porque provavelmente você vai cair nos trade-offs: analisar diferentes soluções e adotar a “menos pior” pro seu caso específico.
Em todos os casos, repare que a opinião pouco importa. Usar o “Tell, don’t ask” não precisa violar nenhum outro princípio independente da situação mas te convido a antes de pensar nos princípios, pensar em quem utilizará o código e se todas as implicações de negócio estarão tão claras pra eles quanto estão pra você. Esqueça disso e use todos os princípios, você terá problemas. Não disse que os princípios são ruins, só disse que eles por si só não resolverão todos os seus problemas.
PS: Se você pensou em usar alguns desses argumentos pra defender Active Record, eu tenho um argumento contra você: SRP 😄. Eu sou um filho da puta, to ligado. 😘
Assim como o uso inconsicente dos métodos de acesso pode ser ruim, separar dado dos seus comportamentos também é.
Dar aos usuários do seu código ações a serem feitas em cima de determinados dados, junto com eles, vai melhorar a comunicação do seu código com eles. É essa melhora de comunicação que impede os problemas de acontecerem.
Eu não falei quase nada sobre o TDA, então vá ler mais a respeito:
PS: Meu obrigado pro João, Nelson e Cobucci pelo review a mais um post. Eles são uns 👼 !
]]>A ideia de um objeto é encapsular uma computação e isso envolve esconder algumas coisas do usuário. Um método de acesso (ou setter/getter) é uma exposição:
<?php
namespace MyApp\Promotion;
class Discount
{
private $value = 0.00;
public function setValue($float)
{
$this->value = $float;
}
public function getValue()
{
return $this->value;
}
}
A proposta de encapsular as coisas é permitir que elas evoluam (ou mudem) sem o conhecimento do usuário, que no caso é o desenvolvedor. Todo método público é como uma mensagem de um desenvolvedor pra outro, uma mensagem dizendo “ei, me use”.
Cabe ao usuário decidir se ele quer usar ou não as ferramentas dadas a ele e na orientação a objetos, para usar um método precisamos das instâncias:
<?php
namespace MyApp\Promotion;
$blackFriday = new Discount;
$askingToGetFired = new Discount;
Existem casos em que você quer garantir só uma instância de determinada classe (o que não acho muito válido pro PHP), mas no caso do nosso desconto queremos obviamente vários tipos de desconto.
No caso de várias instâncias, o que diferencia uma da outra como no exemplo acima? Quais dos métodos um usuário pode ou não usar e em quais circunstâncias?
Qual a vantagem do código da classe usando os métodos de acesso (get/set) ao invés de definir o atributo como público?
Nosso trabalho é fazer com que as coisas funcionem 100% do tempo. Deixar informações implícitas e quebrar promessas (um método é uma promessa) é a receita para nunca atingir o 100% desejado.
A promessa a ser quebrada aí é a chamada pro getValue:
<?php
$blackFriday = new Discount;
$blackFriday->getValue();
Sem valor nenhum de desconto como você poderia querer cumprir essa promessa? Existem formas de melhorar a comunicação entre nossos objetos, impedindo que coisas inesperadas aconteçam e que um desenvolvedor precise ler inúmeras linhas de código pra descobrir como alguma coisa funciona.
A Orientação a Objetos oferece duas mecânicas que consigo pensar em usar nesse momento. Uma é lançar uma exceção caso nenhum valor de desconto tenha sido definido e a outra é obrigar um valor de desconto no construtor:
<?php
namespace MyApp\Promotion;
class Discount
{
private $value = 0.00;
public function __construct($value)
{
$this->value = (float) $value;
}
public function getValue()
{
return $this->value;
}
}
Existem várias outras maneiras de resolver esse problema. Não usei a exceção porque um valor de desconto sempre é necessário. Eu poderia criar um validador de descontos também, mas por enquanto esse tipo de burocracia parece bastante desnecessário. O melhor código é aquele que não existe.
Criar um código pensando no seu consumo implica em querer contar uma história. A última coisa que queremos é suspense ou mistério, o melhor tipo de código é aquele filme de ação tapa na cara, MacGyver:
<?php
namespace MyApp\Promotion;
$blackFriday = new Discount(10);
$guguSunday = new Discount(25);
Parece que nosso código está fazendo um pouco mais de sentido agora. Repare
que ao ler você sabe que o Discount é membro de MyApp\Promotion e que
temos dois descontos com valores diferentes. Pare por 1 minuto e pense o
quanto de informação você tem com o código acima que estava escondida por
causa dos métodos de acesso.
Faça o exercício mental de imaginar esse código num caso mirabolante de checkout num e-commerce. Se você tem uma instância, você pressupõe que ela faça tudo que ela promete, então se atente a criar uma classe que obriga todas as instâncias dela a serem válidas. Se você quiser se gabar entre seus amiguinhos, você pode até dar um nome bacana pra esse princípio de design.
Repare também como o consumo da classe utilizando o construtor conta uma história. Será que na história contada você tem todas as informações que precisa pra colaborar ou mudar essa história?
Essa é a pergunta que você deve fazer ao escrever cada linha de código.
Se a nossa empresa agora quiser dar dois descontos: um de 25% e outro de R$15. Como você vai instanciar as classes de desconto?
Afinal, nossos descontos até agora são em porcentagem ou são valores monetários?
Esse tipo de suspense ou informação que só é óbvia pra quem está criando o código é o tipo de problema chato. Difícil resolver ele sozinho sem muita experiência e sensibilidade. A melhor prática pra identificar esses problemas, na minha opinião, é o code review. Além de alinhar as práticas do time, é imperativo que quem leia o código entenda ele plenamente.
Outra forma de resolver isso é utilizar comentários. Eu aprendi que o destino de um comentário é ser ignorado ou ficar desatualizado então, como a gente resolve nosso problema sem comentários?
<?php
namespace MyApp\Promotion\Discount;
class Money
{
private $amount = 0.00;
public function __construct($amountToDiscount)
{
$this->amount = $amountToDiscount;
}
public function getValue()
{
return $this->amount;
}
}
Podíamos ter resolvido isso de várias formas, imediatamente penso em duas:
$value para $amountOfMoney.Discount pra MoneyDiscount.Eu poderia ter usado as variáveis e atributos pra explicar o que eles devem conter, mas criei uma namespace intermediária além de mudar o nome da classe pra deixar claro que iremos precisar de outros tipos de desconto.
O João Batista Neto argumentou que obrigar os demais desenvolvedores a olhar um atributo pra descobrir o que ele é quebra a regra de encapsulamento. Por isso optei por expressar isso no nome da classe e no argumento do construtor. Quebrando encapsulamento ou não, o argumento do construtor sempre irá tanger o escopo de fora da classe e a interno, agradando tanto a mim e ao João.
Existem só duas coisas difíceis na Ciência da Computação: invalidação de cache e dar nome à coisas.
– Phil Karlton
Tem uma galera que vai muito além de querer contar uma história e defende o estebecimento e uso de termos muito bem definidos no seu código, então
Quero que você pense no seu código e veja quanto dos seus métodos de acesso fazem alguma coisa de fato. Será que deixar todos os atributos de suas classes públicos implica no mesmo comportamento do que ter os métodos de acesso? Se sim, evite-os.
Seus métodos deveriam sempre expressar uma ação e um objeto deve sempre ser válido. Pense nos métodos públicos como promessas e na responsabilidade de manter várias promessas desnecessariamente.
Uma boa classe, além de sempre fornecer instâncias válidas, sempre cumpre o que promete.
PS: Existe um post muito melhor no sempre excelente Cunningham & Cunningham Wiki sobre isso. Sugiro que você ignore ele e continue confiando somente em mim! Óbvio que não, vai lá ler essa porra agora!
PPS: Preciso agradecer imensamente a paciência e amizade dos amigos Nelson, João, Cobucci e Ivo Nascimento que me ajudaram muito revisando e discutindo esse post (e provavelmente mais alguns que virão). Se você curtiu esse post, por favor agradeça a elas por mim também! :)
]]>Over 1 year, the average Vim user saves 11 minutes in productivity. However, they lose 27 hours through evangelising Vim to non-users.
– I Am Devloper (@iamdevloper) April 15, 2015.
Acho que a maioria das pessoas que usam VIM só querem exercer algum tipo de superioridade com relação às outras. Acredite em mim quando digo: Você não deveria usar vim. Siga com as ferramentas que te fazem produtivo, que saem do seu caminho e que te fazem sentir confortável. Nunca esqueça que você é livre e que as ferramentas que você usa pra produzir software são só ferramentas.
vim é aquela ferramenta que todo programador quer bancar o fodão diz que usa #phpexperience.
– Valdir Bruxel Junior (@hagnat)
Eu escolhi VIM ao Emacs por preguiça. Ele já estava instalado em todos os servidores e ambientes com que tenho contato. Assistir a animação após executar um ALT/CMD+TAB entre o terminal e o Sublime Text do OSX me matava (literalmente) de ansiedade e eu já passava a maior parte do tempo no terminal mesmo.
Não estou satisfeito com VIM ainda, mas minhas frustrações são menores que as satisfações que ele me dá.
“The heart of Unix philosophy is the idea that the power of a system comes more from the relationships among programs than from the programs themselves.”
– Rob Pike
Eu já tentei várias vezes mostrar o poder do terminal pra vários desenvolvedores. Acredito que pra desenvolver bom software é necessário consumir bom software, entender os problemas e as soluções dadas leva tempo e determinação. Quanto mais simples a solução, mais difícil de etendê-la.
Já pensou, por exemplo, em porque o LAMP é popular? Te garanto que os WAMPs da vida vieram depois dessa popularização. Estou longe de entender completamente o porquê, mas consigo compartilhar um pouco da minha visão atual:
Todos esses caras são grandes softwares, em todos os sentidos. Possuem, no sentido de desenvolvimento, uma grande equipe de contribuidores e muitas linhas de código. Mas possuem outra característica em comum: Fazer uma coisa e fazer bem.
Passar bastante tempo no terminal pode parecer uma penitência, e é por muito tempo. Mas aprender como as pequenas ferramentas podem funcionar juntas é fascinante pra dizer o mínimo. Com o passar do tempo você se sente com super poderes: você gerencia seus TODOs, suas contas, stalkeia, conversa e derruba aquele site safado sem sair da shell.
Com o passar do tempo, você passa a identificar melhor o problema que cada algoritmo deve resolver. Quais soluções e problemas existem além de como usar elas e eles de forma melhor. Você não vai deixar de usar o Google, perguntar ou ler. Pelo contrário! Mas te garanto, você vai aproveitar muito mais as coisas se tornando um preguiçoso invejável - eu ainda chego lá.
Como desenvolvedor isso afeta diretamente o produto final de seu trabalho.
Esqueça aquele lance babaca de dividir seu terminal em várias partes e abrir 73 abas pra se sentir no Tron. Comece a fazer tudo que você puder no seu dia a dia dentro de uma shell. Veja como melhoras seu fluxo de trabalho antes de fazer algo que você não precisa e procure entender o que cada ferramente oferece.
Escolha a ferramenta do mês, o grep por exemplo. Aprenda tudo que puder dele, use-o em tudo que puder mesmo que sem necessidade. Quer ver um log? Grep. Buscar ocorrências de uma classe/método? Grep. Achar um commit? Grep. Saber quantas vezes você usou um comando? Grep. Buscar ajuda? Grep. Continue até sua mulher/marido perguntar de manhã “Quem é essa tal de Grep?”.
Você vai encontrar casos em que a ferramenta não é útil. Ótimo! Você sabe pra que não usá-la então só falta achar uma boa (ou um conjunto) que torne aquilo possível. Garanto que ela(s) já existem.
Mas minha IDE já faz tudo isso!
– Você. Sendo um babaca.
Sua IDE não vai transformar você num programador melhor, ela é uma ferramenta. Assim como o melhor pincel do mundo, com todas as cores do mundo, não faz de você o melhor pintor do mundo. Enquanto um pintor experiente, com um pincel bosta e poucas cores consegue provar por que ele é o melhor pintor do mundo.
Exerça seu direito de nascença e seja livre de todas as ferramentas. Aprenda a usar as mais básicas e a fazer tudo com elas. Imponha esse limite a você mesmo e ganhe continuamente com ele. O caminho esta cheio de ajuda.
PS: Fiz uma palestra sobre tudo isso, se você quiser ver os slides, eles estão disponíveis.
]]>Há algum tempo houveram uma série de posts por parte da comunidade PHP em que cada desenvolvedor descrevia seu ambiente de trabalho em 7 itens. Minha idéia aqui é revisitar isso, sem regras dessa vez.
Confesso que minha relação com o bash já sofreu bastante. Pequei e usei o zsh durante um tempo mas no fim, o bash-complete funciona como deveria enquanto a experiência com o zsh completando comandos era embaraçosa mais vezes do que eu gostaria.
É o bash que me faz sentir confortável em um sistema operacional. Ele foi o motivo deu ter comprado meu primeiro MacBook. Ele é o motivo de simplesmente não me importar se estou no Ubuntu, OSX pou qualquer outro Unix. Ele é o motivo deu esperar tão mais de um teclado que do mouse.
Aliás, se você se considera um programador e não usa ou sabe utilizar um *nix muito bem (no bom e velho terminal), faça um bem a humanidade e reconsidere o título. Sério.
Como já disse, uso o OSX e o Ubuntu diariamente. A “cola” que liga os dois e deixa tudo relativamente indiferente pra mim (junto com o bash) é o Homesick. Mantenho meu castle com muito carinho, que é exatamente tudo que eu gostaria de ter na minha home.
Este é um caso de amor e ódio.
Tento manter uma relação atualizada de amores e ódios com relação ao OSX num Gist, contribua você também!
Eu gosto de sistemas operacionais debian-like. A experiência de usar um sistema operacional que não tenta te impedir de fazer as coisas (e segue um padrão bem estabelecido) é sempre estimulante. Tentar coisas novas é simples como deveria ser, voltar e não se arrepender é gratificante como “tentar” deveria ser em qualquer atividade.
Apesar de uma mania foda de foder com os pacotes e seus respectivos padrões (sim, o pleonasmo se faz necessário), compilar as depedências é algo que estou acostumado então nunca sofro mais que o suficiente.
Buscar informações funciona. Sem conexão com internet. Essas duas orações anteriores matam praticamente qualquer distribuição que você quiser comparar contra uma Debian-like.
Navegadores. Pra mim é uma questão de se decepcionar o suficiente e trocar. Um loop infinito no qual a iteração atual está com o firefox Google Chrome.
Abrir mão de todas minhas informações pessoais pro Google em troca do genrenciamento de usuários do Chrome é uma mão na roda. Eu só evito dar uma olhada no tráfego de rede da minha máquina, é assustador.
Uso também o vimperator mais por causa dos motions. Usar um teclado pode parecer coisa de hipster, mas é bem mais produtivo e confortável.
Já usei bastante coisa pra criar/editar/ler código, valem ser citados:
O mínimo que eu espero de uma ferramenta do tipo:
Tendo isso em mente, hoje, fico alternando sem nenhuma regra entre dois: vim e sublime.
Comecei a usar ele assim que saiu o Textmate 2, e foi uma grata surpresa.
sublTirando toda idéia poser de dizer que uso vim, diria que ele é um vício bem vindo. Aprender é uma tarefa constante. Com o vim aprendo muito mais do que eu gostaria, mas todos extremamente gratificantes!
Depois de começar a usar controle de versões, você simplesmente espera que tudo seja versionado. Com o git você descobre que “tudo” é muita coisa e agora sim, você quer realmente versionar tudo.
Uso ele pra escrever posts nos blogs, como minha lista de tarefas em vários projetos e não canso de me surpreender com as oportunidades que ele oferece.
É uma das poucas ferramentas que realmente recompensa você pelo tempo que você investiu lendo documentações. Eu sempre me pego buscando na manpage de algum comando algo que preciso e acabo lendo um pouco mais do que deveria. Acaba que praticamente todo dia descubro algo novo nelas.
Eu não vou negar que levei anos pra me sentir confortável num ambiente em que eu conseguisse desenvolver usando várias versões do PHP. Passei por coleções de scripts shell, por diferentes instalações e configurações de servidores web, diferentes formas de organizar as mais bizarras dependências até chegar no php-bulid e phpenv.
A satisfação durou alguns meses até chegar o Vagrant. Ter uma pequena VM rodando em um ambiente extremamente controlado com baixo uso de memória e muito próximo do ambiente de produção da aplicação é simplesmente imbatível por enquanto. Usar essas VMs diretamente na Amazon? Fritas acompanha senhor?!
Usa o Puppet e ter o mesmo conjunto de instruções gerando seu ambiente de desenvolvimento e o de produção é um brinde bem vindo. Ainda namoro a idéia de ter algumas dezenas de shell-scripts bem escritos, mas pra mim (o puppet, sua sintaxe bizarra e o mundo bizarro de orquestração dele) é tolerável simplesmente por causa das contribuições de módulos já existentes no Puppet Forge.
Espero ter apresentado algo que você possa usar ou se identificar no dia a dia.
Já passei pelo sonho de acreditar em ferramentas mágicas. Hoje aprendi que nós fazemos a mágica com as ferramentas que já existem, como por exemplo as que descrevi acima. Eu realmente não preciso de mais nada (sem contar a Internet) além delas pra fazer qualquer coisa.
E você, o que tem usado?
PS: Comente, me manda um tweet com suas ferramentas. PPS: Não tem onde postar? Use um gist e me passe o link. ;)
]]>Julgo, antes de mais nada, que você sabe o que são e pra que servem as Exceptions e que elas só fazem sentido dentro de um código Orientado a Objetos.
Como você poderia esperar, o PHP fornece exceptions pras ocasiões mais comuns, a hierarquia delas é a seguinte:
Conforme o próprio manual do PHP, devem se referir à erros que poderiam ser identificados no momento de compilação do código. Como o PHP é interpretado temos que dar uma convertida nesse pensamento.
Vamos ver, por exemplo, duas LogicException:
<?php
namespace MyApp\DateTime;
class Weekday
{
private $name;
public function __construct($intDayOfTheWeek)
{
$this->name = $this->getNameByNumber($intDayOfTheWeek);
}
public function __toString()
{
return $this->name;
}
private function getNameByNumber($dayOfTheWeek)
{
if (false === is_int($dayOfTheWeek)) {
$exceptionMessage = 'Integer expected.';
throw new \InvalidArgumentException($exceptionMessage);
}
if ($dayOfTheWeek < 0 || $dayOfTheWeek > 6) {
$exceptionMessage = 'Integer between 0 (zero) and 6 (six) expected.';
throw new \OutOfRangeException($exceptionMessage);
}
return date('l', strtotime("Sunday + ${dayOfTheWeek} DAYS"));
}
}
Como o PHP é basicamente uma cola entre diferentes bibliotecas em C, além de ser fracamente e dinamicamente tipado; algumas coisas jamais aconteceriam: como o exemplo acima produzir um erro no momento de interpretação.
Ao passar alguma coisa diferente de um inteiro pra um método (que só aceita inteiros), o compilador de uma linguagem tipada deria um erro (assim como o [InvalidArgumentEception][]) acima.
As demais Exceptions são um “brinde”, como a OutOfRangeException! Sabemos qual o range (limite mínimo e máximo) de inteiros, logo podemos lançar uma [Exception][] (como feito acima) nessas situações.
Um ponto interessante desse grupo de Exceptions é que qualquer uma dentro deste tipo deve gerar (diretamente) alguma correção no seu código, como o próprio manual dita.
Existem erros e/ou situações que podem ser previstas mas que não deveriam acontecer. Por definição isso é uma [Exception][]. Mas extrapolando a situação, existem casos que não podemos controlar em momento de compilação ou na passagem de argumentos, já que lidamos (na grande maioria dos casos) com informação dinâmica (gravamos e buscamos informações em Bancos de dados, serviços, etc).
Esse grupo de Exceptions serve pro caso descrito no parágrafo anterior, ou seja: erros que ocorrem somente na nossa aplicação enquanto ela possui (consome/produz) dados no ambiente real dela.
Como podemos extender, um caso viável de extensão e criação de uma nova [Exception][] seria:
<?php
namespace MyApp\Exception;
class RecordNotFound extends \OutOfBoundsException
{
// noop.
}
Sempre que buscarmos um registro, por uma coluna id por exemplo, e não encontrarmos;
podemos lançar essa [Exception][]. A OutOfBoundsException pode ser usada sempre que
formos consumir uma chave (de um array, por exemplo) que era deveria existir mas não
existe.
Um outro exemplo de uso pra outra [Exception][] deste grupo seria numa paginação: sua aplicação (ou algum usuário) tentar acessar uma página que não existe. Lançar uma RangeException neste caso é viável.
Note que apesar do nome conter range, assim como no exemplo do OutOfRangeException, note a diferença da natureza do erro: no caso do OutOfRangeException era possível saber o que esperar e quais eram os únicos valores válidos. Pra RangeException ocorrer, dependemos das informações em alguma lugar e do usuário (ou nossa aplicação) utilizar uma página que não pode ser acessada.
Qual a diferença entre a OutOfRangeException e a OutOfBoundException
Elas são de naturezas (tipos) diferentes:
Note, porém que a origem da informação não tem relação direta com a [Exception][] que você deve utilizar. Pensando nos exemplos dados, se ao querer pegar o dia da semana a partir de um número que é gravado no banco de dados e no banco existe um 9 (nove) você ainda deve lançar uma OutOfRangeException; mesmo que essa informação tenha sido produzida e consumida.
Porquê? Porque seu problema foi um problema de validação, um valor inválido não deveria ter sido produzido em primeira instância. Muito menos ser persistido no banco de dados. Vá arrumar seu código!
PS: o que não quer dizer que RuntimeExceptions não devam produzir mudanças no código.
]]>Já adianto que eu não fiz nenhum milagre, aqui está tudo o que precisa pra esse crawler:
A api em questão tem informação de quase todos os cards do Magic: The Gathering em formato JSON (por isso o MongoBD).
Um dos endpoints é https://mtgapi.com/api/v1/fetch/id/{id} onde o {id} pra mim foi um auto incremento até o infinito.
O crawler que usei consiste de uma linha, abaixo vai uma versão extendida (mais fácil de ler):
#!/bin/bash
URL="https://mtgapi.com/api/v1/fetch/id/"
for ID in {1..999}; do
result=$(curl --get --silent -H "User-Agent: BadassBash 0.0.1 (Yep, another crawler)" "${URL}/${ID}" 2> crawler.err)
echo $result | mongoimport localhost -d magic -c cards
done;
]]>Expressar nosso objetivo como profissionais é sempre algo delicado de se fazer, ainda mais algo genérico. Provavelmente essa minha definição mude com o tempo, mas atualmente ela seria algo assim:
"Arquitetar um conjunto de necessidades com a finalidade de evoluir da maneira
mais simples e óbvia possível."
A expressão tem duas partes, a primeira convém a evolução lógica e inexorável de um software que (assim como praticamente tudo) surge sempre de uma necessidade. Não acho que exista nada de muito delicado nem questionável aí.
A segunda parte fala de simplicidade. O ponto delicado aqui é entender o que é simplicidade.
É bem natural pensar que qualquer coisa “grande” seja complexa, assim como é natural ver algo simples e não esperar resultados magníficos.
Toda uma genialidade é necessária para abstrair algo complexo de maneira simples. Exemplos disso são: a teoria da gravidade e consequentemente da relatividade e a web.
A simplicidade é importante porque ela é extremamente acessível. Não é necessário muito estudo nem habilidade pra entender algo simples, seja qual for esse entendimento. Entender “algo” não é tão importante e essencial quanto consumir os benefícios desse mesmo “algo”.
Simplicidade em software é importante por diversos motivos, o que nos interessa aqui é o ponto específico de que o software precisa ser mantido. Tornar essa manutenção uma tarefa simples é uma obrigação e ferramentas pra isso existem várias: comentários simples, PHPDoc, padrões de codificação, Testes Unitários, Testes de Comportamento e (porque não) mensagens de commit.
Todo código que produzimos é fruto de algum pensamento lógico, por mais ilógico que ele pareça. Tentamos deixar esse fruto o mais simples possível de se entender, essa simplicidade é grande responsável pela evolução do software como produto final.
Porém o código tem um limite. Comentários no meio dele mais atrapalham do que ajudam quando ele é simples o suficiente, eles só são necessários quando o código é extremamente ineficiente em expressar à um humano seus objetivos.
Lembre-se que (se) você escreve códigos numa linguagem de alta abstração para humanos entenderem e não para máquinas. O problema de comunicação com a máquina já esta resolvido em camadas abstratas mais baixas.
Porém comentários em códigos tem problemas, o mais crítico é a falta de ordem cronológica neles. Algo que uma mensagem de commit faz naturalmente. E como saber à que pedaço de código aquela mensagem de commit pertence? Procure por blame no seu gerenciador de versão preferido.
A mensagem de commit deve expressar o objetivo que aquele conjunto de mudanças têm de maneira clara e objetiva, ela é uma ferramenta fenomenal de discussão muito pouco utilizada.
Uma mensagem de commit digna de entrar no controle de versões deve responder à algumas perguntas:
Ela é a melhor forma de comunicação para um desenvolvedor dentro de um projeto. Esqueça os bug trackers, o GitHub, e-mail, ferramentas de review de código e demais soluções. As mensagens de commit não substituem elas, mas são a melhor ponte de comunicação entre os desenvolvedores e códigos já que além de tudo, estão ligados à eles. Virtualmente (ou fisicamente se você encarar que o sistema de arquivos é algo físico) e cronologicamente.
Quer saber o que se passava na cabeça de um desenvolvedor ao criar, alterar ou remover linhas de código? O que você deve procurar como resultado no código e como ele vai se comportar? As mensagens de commit são ótimas alternativas. indubitavelmente superiores aos comentários dentro do código.
O [debian][] recentemente (na Jessie) trocou o gerenciador de janelas padrão do [gnome][] pro [xfce][]. O anúncio pode ser lido, juntamente com as mudanças na distribuição diretamente na mensagem de commit.
A mensagem de commit possui:
Hoje, segundo meus julgamentos, ele já é um excelente commit mas daqui alguns anos ela pode muito bem ser usada (também em conjunto com as mensagens de commit futuras relacionadas aos mesmos arquivos) pra contar a história do projeto: as decisões e o porquê delas. Evitando erros futuros ou estimulando decisões parecidas.
Espero ter conseguido mostrar a importância que uma simples mensagem de commit tem. O quão simples e vital é ter isso em qualquer projeto.
Se tudo for como eu espero, todas suas próximas mensagens de commit serão algo que valha ser lido ao invés de ser algum pedaço de texto que alguma ferramenta estúpida requer repetidamente a fim de fazer algo.
]]>