Atributo required

Utilizamos esse atributo para informar ao navegador que um elemento do formulário é de preenchimento obrigatório, ou seja, o usuário não consegue enviar o formulário se não preencher o campo com o atributo required. Seu uso é exclusivo com os elementos input, select e textarea.

Uma mensagem é informada ao usuário em uma tentativa de envio de formulário sem o preenchimento de um campo com required. Esse atributo apenas verifica se o campo foi preenchido ou não. Quero dizer que, qualquer caractere será aceito.

<form method=”post” action=”">
<label for=”nome”>Nome: </label><input id=”nome” type=text required name=nome/>
<input type=submit value=”OK”/>
</form>

Abaixo mostro as mensagens de alerta nos seguintes navegadores: Google Chrome, Firefox e Opera. Perceba que cada fabricante estiliza a mensagem de forma diferente.

type=”email”

Atributo type de um input com a opção igual a email significa definir o campo para receber um endereço de e-mail válido. A forma de validação não verifica se o e-mail digitado realmente existe, mas sim se o formato está correto. Exemplo de um formato de email aceito: teste@teste.com.

<form method=”post” action=”">
<label for=”email”>E-mail: </label><input id=”email” type=email required name=email/>
<input type=submit value=”OK”/>
</form>

Atente para o seguinte: além de ser um campo onde o usuário deve digitar um endereço de e-mail válido o campo é de preenchimento obrigatório.

Alerta para o usuário caso não seja digitado nada no campo input.

Alerta para o usuário caso não seja digitado um formato de e-mail no campo input.

Um recurso CSS3 pode ser usado para identificar se o elemento do formulário recebeu ou não um dado válido. Esse recurso é a pseudo classe :valid e :invalid. Assim que o usuário digitar um dado válido, o navegador altera a pseudo classe de :invalid para :valid. No exemplo abaixo o campo inicia com uma cor de fundo avermelhada, assim que o usuário digitar um formato de e-mail o campo é alterado para verde.

Veja o CSS:

#email:valid {background:#006600;color:#fff }
#email:invalid {background:#990000; color:#fff}

type=”url”

Um campo input com type igual a url recebe apenas url’s no seu formato correto, ou seja, http://www.site.com, http://www.site.com.br etc.

<form method=”post” action=”">
<label for=”site”>Site: </label><input id=”email” type=url required name=site/>
<input type=submit value=”OK”/>
</form>

Mensagem de alerta do navegador Chrome ao digitarmos uma url em um formato inválido.

pattern = “Expressão”

Com uso do atributo pattern você pode exigir que o usuário digite valores em um padrão feito com expressão regular, ou seja, o que for digitado no compo input deverá satisfazer a expressão regular criada pelo desenvolvedor.

Explicarei o atribudo criando uma expressão para entrada de um número de telefone. O valor inserido no campo de input deverá iniciar com (xx) logo terá um espaço em branco com uma sequência de quatro dígitos, um traço, e para terminar mais uma sequência de mais quatro dígitos, ficando assim: (xx) xxxx-xxxx.

Abaixo o código para criar a condição descrita acima.

<form>
<label>Telefone: <input required name=”tel” pattern=”\([0-9]{2}\)[\s][0-9]{4}-[0-9]{4}”/></label> (xx) xxxx-xxxx
<input type=submit value=Enviar/>
</form>

\([0-9]{2}\) usuário deve digitar dois números de 0 até 9 entre parênteses.
[\s][0-9]{4}-[0-9]{4} um espaço e duas sequências de números divididas por um traço.

Em HTML5 há um valor para o atributo type que é o tel. Ao utilizar esse valor não há máscara de formatação ou validação, já que não há um padrão para números de telefones. Ele serve apenas para informar que o valor do campo é um número de telefone.

Abaixo outro exemplo utilizando o atributo pattern, agora validando CEP

<form>
<label>CEP: <input required name=”cep” pattern=”[0-9]{5}-[0-9]{3}”/></label> (xx) xxxx-xxxx
<input type=submit value=Enviar/>
</form>

novalidate=”novalidate”

Quando presente dentro do elemento form, especifica que os elementos do formulário não devem ser validados quando submetidos mesmo que tenham em seu type atributos iguais a email, url, etc.

No exemplo acima mesmo que o usuário clique no botão enviar sem preencher os campos com required o formulário será submetido. Isso porque passamos o valor novalidate=”novalidate”.

Compatibilidade entre navegadores

Pelos testes que fiz a validação funcionou perfeitamente nos navegadores Chrome, Opera e Firefox em suas últimas versões. Navegadores como Safari e Internet Explorer não foram capazes de reconhecer tais elementos da HTML5.

Então, o que fazer?

A solução estaria então em adotar um Processo de Software bem definido. Muitos são os tipos de processos e muitas são as necessidades de equipes e das empresas em ter e utilizar um bom Processo de Software a fim de adquirir organização e qualidade em seus produtos, respeitando prazos de cronograma, administrando esforços de equipe, obtendo mais produtividade e padronização de desenvolvimento.

Porém, não acredito que exista um único processo perfeito para o desenvolvimento de software, ou seja, para adquirir um bom processo, deve ser levado em consideração fatores como:

• Tipo de software que está desenvolvendo;
• Tamanho de equipe (desenvolvedor único, dois desenvolvedores, equipe pequena, equipe com mais de 100 membros);
• Infraestrutura;
• Capital investido;
• Entre outros.

Entre diversos tipos de Processos de Softwares, destacam-se os modelos em Cascata (CMMI), Espiral, Iterativos (PU – Processo Unificado) e os modelos Ágeis (XP, Scrum).

Mas por que utilizar um Processo de Software?

Dentre alguns fatores, podemos definir que o Processo de Software visa à qualidade do produto como um todo, onde é estabelecida a lógica do domínio da aplicação para o projeto decidindo seu scopo e comprometimento do Patrocinador, levantamento dos requisitos, riscos de projeto, padronização de desenvolvimento, construção do modelo e prototipagem, implementação sistemática de testes, feedback do cliente, revisões técnicas, gerência de configuração, etc. Porém, todo este conjunto (o Processo) não basta apenas ser implementado, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele esteja sendo executado corretamente por seus envolvidos.

Em outras palavras, o Processo de Software não é uma tarefa simples de implementar numa organização. Ele “afeta” diretamente seus envolvidos, no qual em alguns casos, são obrigados a saírem de suas zonas de conforto. O processo também confronta a cultura de uma empresa, e todo este conjunto gera uma certa resistência dos envolvidos em colaborar para o sucesso do mesmo.

Meu artigo não é de forma alguma induzir o leitor a optar para um processo X ou Y, mas sim avaliar o nível caótico de não se utilizar um processo e os benefícios conquistados com sua aplicação.

Particularmente, um dos modelos que mais me apego são os modelos Ágeis, devido a suas práticas, valores e por serem iterativos.

Os modelos iterativo e evolutivo envolvem a imediata programação e teste de um sistema e considera que o desenvolvimento começa antes que os requisitos tenham sido definidos em detalhes. Evitando assim grandes desgastes e desmotivação na fase inicial.

Nesta abordagem de ciclo de vida, o desenvolvimento é organizado em uma série de mini projetos curtos, de duração fixa chamadas de iterações. O produto de cada um é um sistema parcial, executável, testável e integrável. Cada iteração inclui suas próprias atividades de análise de requisitos, projeto, implementação e teste. No modelo Ágil, os detalhes de requisitos são acrescentados no decorrer do processo, utilizando assim, a modelagem na perspectiva de principalmente entender o que foi pedido e não documentar.

Ao contrário, nos modelos em cascatas (ou sequencial), há uma tentativa de definir em detalhes todos ou a maioria dos requisitos antes da programação e também de criar um projeto abrangente, antes da programação. Igualmente, há uma tentativa de definir um plano ou cronograma confiável logo no início. Outro ponto a ser avaliado, é que neste modelo, modificações tardias de requisitos não são bem vindas. Deve levar-se em conta que custos de operações aqui são bem mais altos e é um modelo muito burocrático.

Apesar do meu apego ao modelo Ágil, o ideal é que as equipes criem seu próprio Processo de Software, olhando na perspectiva de não diminuir o valor de outros métodos e sim, agregando as boas práticas mais comuns que atendam as suas necessidades dentro da sua realidade, não se esquecendo de manter um contínuo amadurecimento do processo como um todo.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

Um assunto sempre polêmico, mesmo ainda iniciante nesta área, tenho visto algumas definições diversificadas de profissionais (especialistas ou não) sobre o tema.

Alguns definem Casos de Uso apenas em sua notação gráfica (os diagramas), porém, Casos de Uso vão muito além. Casos de Uso são elementos primários no desenvolvimento e planejamento do projeto. Ele facilita o entendimento e a comunicação com o stakeholder, pois Casos de Uso representam uma visão externa do sistema e aplicando uma boa técnica na sua utilização, eles são com certeza uma melhor maneira de levantar bons requisitos de sistema. Em outras palavras, Casos de Uso descrevem o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário, no qual este (ator primário) inicia uma interação com o sistema para atingir algum objetivo.

Um formato simples para captura de um Caso de Uso consiste na descrição de seu cenário primário como uma sequência de passos numerados e as alternativas como variações naquela sequência.

Existe muita variação no modo como você pode descrever os conteúdos de um Caso de Uso, porém, a UML não especifica padrão algum. Mas, acrescente informações sempre que julgar necessárias, principalmente, vendo isto pela perspectiva do risco, ou seja, acrescente detalhes de acordo com o grau de risco, quanto maior o risco, mais detalhes você precisa. Mas, não se desespere em detalhes, ou seja, entre neles aos poucos durante sua elaboração e durante as iterações, vá acrescentando mais detalhes à medida do necessário. Porém, chamo sua atenção para a simplicidade, pois um Caso de Uso bem escrito é fácil de ler, porém, aprender a escrever um bom caso de uso é difícil.

Mas, o que é realmente, um Caso de Uso?

Um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre o seu comportamento. Um Caso de Uso descreve o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário.

Alistair Cockburn

Uma outra definição mais compreensiva, explico primeiro o que é um cenário.
Cenário: é uma sequência de passos que descreve uma interação entre um usuário e um sistema.

Caso de Uso, então, é um conjunto de cenários amarrados por um objetivo comum de um usuário.

Martin Folwer

Finalizando, Casos de Uso têm uma grande importância na construção de projeto e é um assunto para mais de “Gigas”. Sobre diversos aspectos, eles são essenciais em uma infinidade de coisas desde o início ao fim das iterações do projeto. Para iniciantes na área, dedicar-se na leitura de bons livros sobre o assunto irá fazer toda a diferença na hora de analisar e/ou dirigir um projeto.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

Veja o que irei lhe ensinar nesse screencast:

• Criar um gemset no RVM e automatizar sua inicialização;
• Iniciar um repositório GIT local;
• Configurar o Ruby on Rails para utilizar RVM, GIT, HAML, SASS, COMPASS e o 960gs;
• Definir a time zone como Brasília;
• Criar um controller para páginas estáticas com uma página index.

Se você quiser ver os arquivos da aplicação, eu os disponibilizei no Github: https://github.com/diegobrito/screencasts

Fonte: Blog de Diego Brito

Inicialmente, eu separaria este texto em vários módulos. Porém, optei por fazer algo mais sucinto e criar apenas este módulo – que complementa o Módulo #0, sobre os comandos básicos do Linux.

Neste módulo, serão abordados vários temas da programação em Shell (Bash), desde variáveis e funções, até expansões, expressões regulares etc.

Sem mais delongas, vamos ao que interessa!

Sumário

0. Scripts Shell
1. Variáveis
1.1 Variáveis de Ambiente
1.2. Variáveis Especiais
2. Controle de Fluxo
2.1. Condicionais
2.1.1. if
2.1.2. case
2.1.3. select
2.2. Estruturas de Repetição (Loops)
2.2.1. for
2.2.2. while
2.2.3. until…do
2.2.4. break
2.2.5. continue
3. Padrão C/C++ em Expressões “(())”
4. Entrada/Saída
4.1. Redirecionamento
4.2. Usando Pipelines
5. Expansões
5.1. Expansão de Variáveis
6. Parâmetros de linha de comando
7. Definindo Funções
7.1. Retorno de Funções
8. Expressões Regulares em Bash
9. Expressões Matemáticas
10. O Arquivo .bashrc
11. Aliases (Apelidos)
12. Referências

0. Scripts Shell

Antes de mostrar os recursos do shell, vamos dar uma olhada na maneira como devemos criar scripts shell. Isso facilitará a compreensão do restante do artigo.

Todo arquivo com códigos shell deve ter, na primeira linha, o identificador do interpretador a ser utilizado. A “linha mágica” que chama o interpretado bash é:

#!/bin/bash

O mesmo vale para outras linguagens interpretadas, como PHP, Python, Ruby, Perl etc.

Tendo essa linha no início do arquivo, o segundo passo é dar permissão de execução ao arquivo:

$ chmod +x script.sh
 
Feito isso, basta executar o script:

$ ./script.sh

Também é possível executar o script usando o comando bash:

$ bash script.sh

Assim não é necessário haver a “linha mágica” no início do script. Também não é preciso dar permissão de execução ao arquivo.

1. Variáveis

O Bash, assim como muitas outras linguagens, possui o conceito de variável. Para definir uma variável:

nome_da_variavel="valor da variável"

É importante ressaltar que não deve haver espaços entre o símbolo de atribuição, o nome da variável e seu valor, para que o bash interprete o comando como atribuição, não chamada de comandos.

Para exibir o valor de uma variável, basta usar echo da seguinte forma:

echo $nome_da_variavel

1.1 Variáveis de Ambiente

As variáveis de ambiente são aquelas conhecidas pelos demais processos (programas em execução). Exemplos destas variáveis são: HOME, PATH, EDITOR, etc.

Para entender o seu uso, vejamos um exemplo: editores de texto, como Vi, possuem diferentes interfaces para os modos texto e gráfico e necessitam saber qual o tipo de terminal o usuário está usando. A variável de ambiente TERM é o modo pelo qual isto pode ser determinado. Outro exemplo são os programas de e-mail que permitem ao usuário editar mensagens com o editor de textos de sua preferência. Como estes programas sabem qual editor usar? É através da variável EDITOR ou VISUAL.

Qualquer variável pode se tornar uma variável de ambiente. Para isto, ela deve ser “exportada”, com o comando export:

export

Também podemos exportar e atribuir valores a uma variável numa única linha de comando:

export =

Podemos verificar quais são as variáveis de ambiente já definidas e seus respectivos valores usando o comando abaixo:

export -p

Para visualizar todas as variáveis basta usar set ou env. Uma importante variável de ambiente é PATH que ajuda o shell a encontrar os comandos que o usuário executa. Todo comando executado é, na realidade, um arquivo. Estes arquivos são chamados executáveis e estão armazenados em vários diretórios como /bin ou /usr/bin. O valor da variável PATH é uma lista de diretórios em que o shell procura toda vez que executamos um comando cujo arquivo não é encontrado no diretório corrente. Assim, não precisamos alterar o diretório de trabalho todas vez que necessitamos executar um comando que se encontra em outro diretório. Basta acrescentar o diretório que contém tal comando à variável PATH. Os nomes dos diretórios na variável são separados pelo caractere dois-pontos (:).

Caso o usuário joao queira adicionar um outro diretório, digamos /home/joao/bin à variável PATH, deve proceder como mostrado a seguir:

$ export PATH=$PATH:/home/joao/bin   # adiciona o diretório
$ echo $PATH                         # verifica
/bin:/usr/bin:/usr/local/bin:/home/joao/bin

O primeiro comando faz com que a variável receba o seu valor atual, concatenado com o nome do diretório a ser acrescentado. Observe que existe um “:” antes do nome do diretório. O segundo comando é utilizado apenas para visualizarmos o resultado do primeiro.

1.2. Variáveis Especiais

Existem algumas variáveis especiais, normalmente utilizadas em script shell, para verificação de parâmetros, valores de retorno de comandos e funções etc.

2. Controle de Fluxo

Controle de fluxo permite interromper, continuar e deslocar o fluxo de execução do script. Isso envolve controles de decisão (condicionais) e estruturas de repetição (loops).

2.1. Condicionais

2.1.1. if

Sintaxe:

if
then
    comandos
elif
    comandos
else
    comandos
fi

O if, ao contrário do que ocorre em muitas outras linguagens, testa o retorno de um comando, não uma expressão.

Por exemplo:

if test 5 -lt 7
then
    echo '5 é menor que 7'
fi

Porém, é possível posicionar a expressão entre colchetes, de forma a tornar o if mais parecido com o que acontece em outras linguagens:

if [ 5 -lt 7 ]
then
    echo '5 é menor que 7'
fi

O “-lt” significa “less than“, ou seja, “menor que“, equivalendo ao operador “< “.

Outros possíveis operadores são:

Comparação Numérica
-lt: É menor que (LessThan)
-gt: É maior que (GreaterThan)
-le: É menor igual (LessEqual)
-ge: É maior igual (GreaterEqual)
-eq: É igual (EQual)
-ne: É diferente (NotEqual)

Comparação de Strings
=: É igual
!=: É diferente
-n: É não nula (não vazia)
-z: É nula (vazia)

Operadores Lógicos
!: NÃO lógico (NOT)
-a: E lógico (AND)
-o: OU lógico (OR)

Testes em arquivos
-b: É um dispositivo de bloco
-c: É um dispositivo de caractere
-d: É um diretório
-e: O arquivo existe
-f: É um arquivo normal
-g: O bit SGID está ativado
-G: O grupo do arquivo é o do usuário atual
-k: O sticky-bit está ativado
-L: O arquivo é um link simbólico
-O: O dono do arquivo é o usuário atual
-p: O arquivo é um named pipe
-r: O arquivo tem permissão de leitura
-s: O tamanho do arquivo é maior que zero
-S: O arquivo é um socket
-t: O descritor de arquivos N é um terminal
-u: O bit SUID está ativado
-w: O arquivo tem permissão de escrita
-x: O arquivo tem permissão de execução
-nt: O arquivo é mais recente (NewerThan)
-ot: O arquivo é mais antigo (OlderThan)
-ef: O arquivo é o mesmo (EqualFile)

2.1.2. case

Sintaxe:

case  in
    opcao1)
        comandos
        ;;
    opcao2)
        comandos
        ;;
    *)
        operação padrão
esac

Exemplo:

echo "Digite um número"
read x
 
case "$x" in
    1)
        echo "Você digitou o número 1"
        ;;
    2)
        echo "Você digitou o número 2"
        ;;
    *)
        echo "Você digitou outro número"
esac

2.1.3. select

Sintaxe:

select  in   ...
do
    comandos
done

O comando select é pouco utilizado, mas pode ser muito útil para montar menus. Esse comando exibe um menu, associando cada opção a um número. Quando o usuário seleciona o número da opção, o seu valor é associado à.

Exemplo:

select i in lista_arquivos lista_arquivos_tree
do
    case "$i" in
        lista_arquivos)
            ls
            ;;
        lista_arquivos_tree)
            ls -R
            ;;
    esac
done

2.2. Estruturas de Repetição (Loops)

Loops são estruturas que permitem fazer iterações sobre algum dado.

2.2.1. for

Sintaxe:

for <var> in do done </var>

“var” é o nome da variável a ser usada no bloco de repetição. “lista” pode ser uma lista de dados, fixa ou retornada por outro comando (como o ls), uma sequência de números etc.

Exemplos:

Exibe uma sequência de números:

for i in 1 2 3 4 5
do
    echo $i
done

Lista os diretórios e arquivos da raiz do sistema de arquivos:

for i in $(ls /)
do
    echo $i
done

for i in $(seq 1 10)
do
    echo $i
done

for i in $(cat /etc/passwd)
do
    echo $i
done

2.2.2. while

Sintaxe:

while
do
 
done

Exemplos:

Exibe a sequência de 1 a 10:

i=0
while [ $i -lt 10 ]
do
    echo $i
    i=$((i+1))
done

Loop infinito que exibe “bash” na tela:

while true
do
    echo 'bash'
done

Lendo strings da entrada padrão:

while read i
do
    echo 'Voce digitou a string: ' $i
done

Exibe as linhas de um arquivo:

cat 'arquivo.txt' | while read i
do
    echo $i
done

Esse exemplo facilita o trabalho com arquivos de texto, cujas linhas possuem espaços. Se fosse usado um loop for nesse caso, seria necessário alterar a variável de ambiente IFS, definindo o separador para quebra de linha (\n).

Uma variação do exemplo anterior é esta:

while read i
do
    echo $i
done < arquivo.txt

A principal diferença entre estes dois últimos exemplos é que, no primeiro, o loop while é executado num subshell, devido ao uso do pipe (|). No segundo exemplo, o while é executado no shell corrente.

Para ilustrar o problema, crie um arquivo chamado “arq.txt” com algumas linhas de texto. Crie este script e execute-o:

#!/bin/bash
 
FILE='arq.txt'
 
total=0
cat $FILE | while read i
do
	total=$((total+1))
done
echo 'Total de linhas: ' $total
 
total=0
while read i
do
	total=$((total+1))
done < $FILE
echo 'Total de linhas: ' $total

O primeiro loop é executado num subshell, fazendo com que a variável “total”, usada no corpo do loop, existe apenas nesse subshell. No segundo caso, isso não ocorre. Isso pode gerar grandes dores de cabeça… (como já ocorreu comigo)

2.2.3. until…do

Sintaxe:

until
do
 
done

Nesse loop, a condição é oposta à usada no while. Por exemplo:

Com while:

i=0
while [ $i -lt 10 ]
do
    echo $i
    i=$((i+1))
done

Com unitl:

i=0
until [ $i -ge 10 ]
do
    echo $i
    i=$((i+1))
done

Para fazer a mesma coisa, tivemos que usar expressões diferentes na condição do loop.

2.2.4. break

O comando break encerra um loop imediatamente.

Exemplos:

i=0
while true
do
    if [ $i -ge 10 ]
    then
        break
    fi
    i=$((i+1))
done

while read i
do
    if [ $i -eq 0 ]
    then
        break
    fi
done

2.2.5. continue

O comando continue para a execução da iteração corrente e vai para a próxima iteração, mesmo que haja mais comandos no bloco de repetição.

3. Padrão C/C++ em Expressões “(())”

É possível usar o padrão C em expressões do shell, como em condicionais de estruturas de controle. Para isso, basta colocar a expressão entre dois parênteses.

Exemplos;

i=0
while (( i < 10 ))
do
    echo $i
    ((i++))
done

É possível, inclusive, usar o padrão do loop for do C:

for ((i = 0; i < 10; i++)
do
    echo $i
done

4. Entrada/Saída

Existem três dispositivos principais, que sempre estão abertos, que merecem destaque:

stdin (standard input): entrada padrão. Corresponde, em geral, ao teclado;
stdout (standard output): saída padrão. Corresponde, em geral, à tela do terminal;
stderr (standard error): saída padrão de erros. Corresponde, em geral, à tela do terminal, também.

Esses três dispositivos estão em /dev e estão sempre disponíveis. Quem programa em C, sabe muito bem disso, pois já deve ter usado stdin, stdout e stderr junto com fprintf, fread, fwrite e semelhantes; esses três dispositivos comportam-se como arquivos comuns, sempre abertos e que não devem ser fechados.
É possível brincar com eles no próprio shell. Experimentem dar um cat em /dev/stdin para ver o que acontece.

4.1. Redirecionamento

A entrada de um programa consiste nos dados que lhe são passados inicialmente, os quais são necessários para a execução do programa. A entrada de um programa pode vir do teclado ou de um arquivo, por exemplo. Argumentos passados à comandos constituem a sua entrada.
A saída é constituída pelas informações geradas pelo programa, ou seja, o resultado de sua execução. A saída pode ser mostrada na tela ou gravada em um arquivo de registro.

Muitos comandos do Linux têm sua entrada configurada para a entrada padrão e sua saída para a saída padrão. A entrada padrão é o teclado e a saída padrão é o monitor. Vejamos um exemplo usando o comando cat, que lê dados de todos os arquivos passados como parâmetros e os envia diretamente para a saída padrão. Usando o comando abaixo, veremos o conteúdo do arquivo “arq1″ seguido pelo conteúdo de “arq2″.

$ cat arq1 arq2

Entretanto, se nenhum nome de arquivo for dado como parâmetro, o comando cat lê dados da entrada padrão e os envia para a saída padrão. Para interromper, deve-se pressionar as teclas ctrl e d simultaneamente (ctrl+d).

$ cat
Ola! Tem alguem ai?  # usuário
Ola! Tem alguem ai?  # eco do sistema
Ate mais!            # usuário
Ate mais!            # eco do sistema
              # usuário pressiona ctrl+d

Como podemos ver, cada linha que o usuário digita é imediatamente ecoada pelo comando cat. Aqui um outro exemplo: o comando sort lê dados da entrada padrão – a menos que algum arquivo seja dado como parâmetro – e ordena os dados, enviando-os para a saída padrão:

$ sort
bananas     # usuário
peras       # usuário
goiabas     # usuário
            # ctrl+d
bananas     # eco do sistema
goiabas     # eco do sistema
peras       # eco do sistema

Digamos que queremos enviar a saída do comando sort para um arquivo, gravando os dados digitados anteriormente. O shell nos permite redirecionar a saída para um arquivo usando o símbolo “>”.

$ sort > lista
bananas  # usuário
peras    # usuário
goiabas  # usuário
         # ctrl+d

Como se pode ver, o resultado do comando sort não é mostrado imediatamente após o se digitar ctrl+d. Ao invés disso, é salvo em um arquivo chamado “lista”. Vejamos o conteúdo desse arquivo:

$ cat lista
bananas
goiabas
peras

Com o redirecionamento de saída, temos uma maneira simples de criar arquivos de texto. Para isso, utilizamos o comando cat para ler a entrada padrão (teclado) e redirecionamos sua saída para um arquivo.

Ao usar “>” para redirecionar a saída para um arquivo, estamos realizando um redirecionamento destrutivo, ou seja, o comando “ls > lista” sobrescreve o conteúdo do arquivo “lista”. Isto é equivalente a dizer que todo o conteúdo anterior de “lista” é apagado.
Se, ao invés disso, redirecionarmos usando “>>”, a saída será concatenada ao final do arquivo e o conteúdo (se houver) de “lista” será preservado. Para melhor entender isso, experimente executar a seguinte seqüência de comandos:

ls >> listagem
ls >> listagem
less listagem

O redirecionamento neste exemplo, diferentemente do exemplo anterior, é denominado redirecionamento não-destrutivo.

4.2. Usando Pipelines

Nos exemplos para o filtro sort, os dados de entrada eram digitados pelo usuário ou estavam gravados em um arquivo. O que aconteceria se quiséssemos ordenar dados vindos do saída de outro comando ? Para listar os arquivos do diretório corrente em ordem alfabética invertida devemos fazer com que a saída do comando ls seja ordenada pelo comando sort. Usando a opção “-r”, este comando ordena os dados na ordem inversa.

$ ls
historia  notas     tese      testes
$ ls > lista
$ sort -r lista
testes
tese
notas
lista                             # observe esse nome de arquivo
historia

Aqui, salvamos a saída do comando ls em um arquivo (lista) e usamos sort com a opção “-r”. Porém, isso faz com que tenhamos um arquivo temporário para armazenar os dados. Assim, toda vez que fizermos isso, teremos que, em seguida, remover o arquivo lista. A solução é usar o que chamamos de pipeline, outro recurso do shell que nos permite conectar vários comandos usando um pipe, onde a saída do primeiro comando é enviada diretamente à entrada do segundo e assim por diante no caso de haver mais de dois comandos conectados por pipes.

No nosso caso, queremos enviar a saída do comando ls para a entrada do comando sort. O símbolo “|” (barra vertical) é usado para criar um pipe:

$ ls | sort -r
testes
tese
notas
historia

Note que neste exemplo, nenhum nome de arquivo é usado na linha de comando, diferentemente do exemplo anterior que fazia o uso do arquivo intermediário lista. Outra diferença é que o nome desse arquivo intermediário aparece no resultado do penúltimo exemplo, mas não neste último. O comando é mais curto, mais fácil de digitar e o resultado é mais adequado pois não inclui nomes de arquivos intermediários.

É importante observar que o redirecionamento e o uso de pipes são características do shell e não dos comandos em si. É o shell quem provê a sintaxe dos símbolos “>”, “< ” e “|”. Logo, se você criar um programa que utilize entrada de dados via stdin, poderá usar redirecionamento para especificar uma entrada para o seu programa.

5. Expansões

Expansões são caracteres, ou uma sequência deles, que expressa outro significado. O intuito disso é facilitar e padronizar comandos.

~: path à home do usuário corrente
~user: path à home do usuário “user”
{a,b,c}: presença do caractere “a”, “b” ou “c”. Podem ser usadas strings em vez de simplesmente caracteres.

Exemplos:

ls ~

ls ~root

ls /dev/std{in,out,err}

5.1. Expansão de Variáveis

6. Parâmetros de linha de comando

Assim como em outras linguagens, é possível passar parâmetros para scripts shell. Para isso, usam-se as variáveis $1, $2, … A variável $0 contém o comando chamado via linha de comando.

Exemplo:

Crie um arquivo “test.sh” com este conteúdo:

#!/bin/bash
 
echo '$0 = '$0
echo '$1 = '$1
echo '$2 = '$2

Veja as saídas das execuções abaixo:

$ ./test.sh
$0 = ./test.sh
$1 =
$2 =
$ ./test.sh um
$0 = ./test.sh
$1 = um
$2 =
$ ./test.sh um dois
$0 = ./test.sh
$1 = um
$2 = dois

7. Definindo Funções

Sintaxe:

function nome_da_funcao()
{
 
}

Para chamar a função:

nome_da_funcao
 
# caso haja parâmetros
nome_da_funcao param1 param2 ...

Exemplo:

#!/bin/bash
 
function imprime()
{
	echo "Sou a função '${0}'"
	echo "Param 1: ${1}"
	echo "Param 2: ${2}"
	echo "Lista de parâmetros: ${*}"
}
 
imprime um dois tres quatro

Da mesma forma como foram usados $0, $1 etc anteriormente, aqui essas variáveis são usadas para retornar os parâmetros da função. Logo, percebe-se que, dentro de funções, não é possível acessar parâmetros de script, a menos que eles sejam passados por parâmetro para a função.

7.1. Retorno de Funções

Antes de tudo, é preciso diferenciar retorno de função e saída de função. Por exemplo, ao se executar o comando “cat /etc/passwd”, a saída é o conteúdo do arquivo; o retorno é 0 (ou outro valor, caso ocorra erro). O retorno de uma função shell é um valor inteiro, normalmente utilizado para definir o status da função, ou seja, se ocorreu algum erro ou e ela foi executada corretamente.

Para obter o valor de retorno de uma função, usa-se a variável “$?”. Ela exibe o retorno do último comando executado. Por exemplo:

$ cat /etc/passwd
echo $?

Para retornar valor (status) numa função, usa-se o comando return.

Exemplo:

#!/bin/bash
 
function retorna()
{
    echo "sou um valor"
    return 42
}
 
valor=$(retorna)
echo $?
echo $valor

Ao se executar a função, sua saída será “sou um valor”; seu retorno será 42.

Em shell, considera-se o valor 0 como execução bem sucedida. Qualquer outro valor representa erro. É por isso que recomenda-se que toda função main de um programa em C retorne o valor 0, desde que não ocorra algum erro.

8. Expressões Regulares em Bash

Expressões regulares em shell podem ser usadas em comparações (if’s), por exemplo. Em if’s, usa-se o operador “=~” para realizar comparações usando ER’s:

s="bash"
if [[ "$s" =~ ^b ]]
then
    echo 'começa com b'
fi

9. Expressões Matemáticas

O bash não trabalha com expressões matemáticas tão facilmente. Existe o comando “let”, que permite realizar expressões matemáticas, mas é mais comum se usar a sintaxe semelhante ao C, utilizando dois parênteses:

$ a=$((1 + 1))
$ ((i++))
$ x=$((x*2))
...

10. O Arquivo .bashrc

Na home dos usuários (~), é comum haver o arquivo .bashrc (o ponto no início indica que o arquivo é oculto). Esse arquivo é sempre executado quando se abre um shell. Nele, constam diversas configurações, como definição de variáveis de ambientes, definição de aliases etc. Você pode editar esse arquivo (ou criá-lo, caso não exista):

$ vim ~/.bashrc

É possível usar outros editores, não apenas o vim.

11. Aliases (Apelidos)

Algumas vezes usamos comandos que necessitam de várias opções e argumentos. Para amenizar o trabalho de digitarmos repetidamente estes comandos o bash oferece um recurso chamado alias com o qual podemos definir sinônimos ou “apelidos” para um comando. Um alias pode ser definido na linha de comando da seguinte forma:

alias =

Observe que não pode haver espaços em branco antes ou depois do “=”.

Esta sintaxe indica que nome é um “alias” (apelido) para comando. Toda vez que digitarmos o comando “nome”, o bash o substituirá por “comando”.

Exemplo:

$ alias lf='ls -F'

Isso fará o shell executar “ls -F” toda vez que usarmos “lf” na linha de comando. Ou seja, o que o alias faz na verdade é substituir a palavra “lf” por “ls -F”. Observe neste exemplo, existe um espaço em branco entre ls e -F. Sempre que houver espaços em branco na definição de um campo, todo o campo deve ser digitado entre aspas simples (‘) ou duplas (“).

É possível definir aliases em seu .bashrc, para que eles estejam sempre disponíveis na sua sessão.

12. Referências

Linux Básico:
http://www.inf.ufpr.br/nicolui/Docs/Livros/LinuxBasico/ ou http://www.inf.ufpr.br/nicolui/Docs/Livros/LinuxBasico.pdf

Linux Avançado
http://www.inf.ufpr.br/nicolui/Docs/Livros/LinuxAvancado.pdf

Canivete Suiço do Shell (Bash)
http://aurelio.net/shell/canivete/

Livro Shell Script Profissional (Livro físico):
http://www.shellscript.com.br/

—————————

Originalmente postado no meu blog, em: http://www.rberaldo.com.br/blog/curso-de-shell-script-modulo-1-scripts-shell-estruturas

Siga-me no Twitter: @rberaldo
Facebook: http://www.facebook.com/rberaldo42

O primeiro passo seria realizar uma busca na web para ter como base alguns parâmetros. A partir daí podemos lançar perguntas: Quais são as linguagens mais utilizadas no mercado hoje? Em quais delas os programadores da “elite” estão desenvolvendo? Nos chats e fóruns, qual é o tema que está sendo mais destacado? O qual estável é esse linguagem? Nas livrarias é fácil encontrar livros – ou até artigos, sobre ela?

Os dados apresentados aqui vem em grande parte da TIOBE, uma empresa – ou comunidade – especializada em pesquisas sobre softwares e que está localizada na Holanda. Essa comunidade lança dados mensalmente em uma espécie de ranking sobre as linguagens mais populares. Dados da Welton’s LangsPop.com, que mostram resultados de pesquisas individuais, também foram utilizados.

Como caso geral, as linguagens que tem sem mostrado mais populares pela TIOBE não são necessariamente as mais comentadas online pelo desenvolvedores ou as que tem mais material publicado (o C++ é uma exceção!). Uma das linguagens mais procuradas pelos empregadores é o PHP, usado no desenvolvimento web, e o SQL, utilizado nas queries dos bancos de dados (sem surpresas até aqui!).

O que é realmente interessante é observar o crescimento do Javascript para a construção de aplicativos baseados em Web que conectam o usuário a bancos de dados – como o Gmail. Na verdade uma das razões para o crescimento do uso do Javascript é a criação da ferramenta V8 Javascript, pela Google, que é um repositório de código de download para o motor JavaScript do Chrome, programado em C + +.

E temos também o Objective-C, que é base para os aplicativos iOS, mas que mal aparecia no Top 40 da TIOBE em 2008. Mas desde então, sua popularidade deu um salto, já que hoje as pessoas estão consumindo mais aplicativos no iPhone e iPad.

Com informações da publicação Spectrum.iee.org, Outubro-2011 (Pág. 68).

Publicado originalmente em Eu Faço Programas.

Mesmo que de certa forma tenhamos que trabalhar esses conflitos, é importante ter outra equipe que teste o que foi desenvolvido. Como já disseram por aí, “não existe filho feio para a mãe”, e o programador tem um tendência natural a achar que tudo que desenvolveu está perfeito.

Contudo trabalhar com somente com uma equipe pode não resolver todos os problemas. Ainda que essa seja boa o suficiente para cumprir o seu papel, o usuário é o verdadeiro tester, já que é quem usará o programa no dia-a-dia. Com a ideia do usuário como tester surgem dois conceitos, chamados de Teste Alfa e Teste Beta.

O Teste Alfa  é aquele realizado no ambiente do desenvolvedor, mas pelo usuário final do programa. Já o Teste Beta é realizado no ambiente do cliente, sem a presença do desenvolvedor, aonde o próprio cliente relata quais são erros observados que serão posteriormente corrigidos.

Os testes de software podem ainda ser classificados quanto a  técnica utilizada. Dentre eles os principais são:

• Teste Caixa Branca: São os testes estruturais, baseando-se na estrutura e procedimentos utilizados no programa, analisando os laços, condições de if/else. Através do código (ou algoritmo) são analisados casos a busca de erros.
  
• Teste Caixa Preta: O teste caixa preta baseia na especificação de interface do programa, observando-se entradas e saídas, ou seja, se a saída produzida realmente condiz com a saída esperada, em relação ao que foi inserido como dado de entrada.

Existe ainda a Técnica Baseada em Erros, que se baseiam na inclusão de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais).

Por fim, lembre-se: bons testes de software são aqueles que apresentam maior probabilidade de revelar erros ainda não descobertos!

O que alguns profissionais não entendem é que nem sempre o cliente sabe o que quer ou nem sempre consegue expressar o que pensa. E em muitos casos, expressam totalmente o contrário do que realmente queriam passar. É fácil entender isso, levando em consideração pontos tais como: falta de conhecimento de tendências, falta de sensibilidade, falta de conhecimento técnico, entre outros fatores que podemos enumerar. E, consequentemente, há um gasto excessivo de investimento e mão de obra e frustrações dos dois lados são inevitáveis.

É provável que você já deve ter se deparado com vários casos parecidos. Na prática, é bem comum no início do projeto uma conversa informal com o cliente e depois de quase tudo pronto ele dizer que não era bem aquilo que se esperava. Outro caso, é a mudança contínua das iterações do projeto para atender ao nível “alto” de satisfação do cliente (que nunca está satisfeito).

A verdade sobre esses fatores são muitas. A começar pelo preço de custo/benefício, “tempo” e a pressão dos gestores em sua equipe para construírem softwares com tempo cada vez menor, e, contudo, a falta de planejamento sério e de chegar a um nível maduro de entendimento do que realmente o cliente espera do produto final.

Conseguir bons requisitos não é tarefa fácil, e, nem tão pouco, empresas estão interessadas em investir neste tipo de profissional. Investir neste processo, gasta-se um tempo de planejamento, mas algo necessário, ou seja, levando-se pelo ponto de vista maduro, é algo que se ganha lá na frente da iteração do projeto.

Estudos indicam que requisitos detectados depois do software implementado ou erros em sua análise são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro. A ilustração abaixo mostra a realidade na construção de softwares e podemos até dizer (desconsiderando alguns passos) que em determinados tipos de serviços mais informais, isso também acontece.

Essa é uma realidade não apenas no desenvolvimento de softwares, mas é algo corriqueiro e que acontece em nosso cotidiano. Para isso, basta precisarmos de um serviço específico de uma determinada área que desconhecemos, um tipo de conserto de um aparelho, etc. Nestas situações, recebemos muitas opiniões e “conselhos” do que realmente não  se deve fazer. Mas, em alguns casos, encontramos algum bom profissional que realmente está atento a nossa necessidade e provê uma solução ao problema.

“Um bom profissional sabe comunicar o seu jargão técnico com o jargão informal do seu cliente.”

Outro ponto que alguns profissionais (mesmo os melhores) não entendem, é o fato que o cliente não é obrigado a saber/entender de um determinado assunto ou uma necessidade. Isso eu chamo de visão, ou seja, alguns profissionais têm (e conquistam o cliente), outros não.  Saliento a importância em dar à atenção ao cliente e se dedicar em ouvir sua história de forma a entender o que ele quer e para que ele quer.

Especificamente falando de softwares, a análise é fundamental, pois em sua construção, um dos maiores desafios no desenvolvimento é o da construção do sistema certo, que preencha as necessidades dos usuários a um preço razoável. E para que isso aconteça, é preciso atingir boa comunicação e boa compreensão do mundo dos usuários (é onde entra a Análise de Sistemas). Este artigo é uma abordagem bem superficial de uma análise de softwares, onde há várias iterações, bem como sua documentação, no qual a documentação dos requisitos e de casos de uso é uma forma “contratual” entre a equipe de desenvolvimento e o cliente a respeito do software que será desenvolvido. Mas, o artigo aborda um ponto de vista que se deve ter na hora de construir software de qualidade.

Por outro lado, posso afirmar que o grande desafio do analista não se limita apenas em implementar melhores soluções tecnológicas, mas sim em mudar a cultura de uma empresa. Estudar, se dedicar e se especializar no que faz é parte da vida do profissional, mas, saber lidar com essas situações divergentes é o que faz o grande diferencial do profissional e o sucesso no que se faz.

Fonte: Blog Rafael Amaral

O filósofo

O filósofo adora construir códigos bonitos, bem escritos e bem estruturados. A energia do filósofo é colocada na robustez, elegância e flexibilidade do código e esse tipo de programador não consegue passar uma semana sem citar “boas práticas”.

Motivação

O filósofo é motivado pela necessidade de proteção e segurança que se manifestam pelo controle severo. Um programa bem ordenado e bem escrito, que siga princípios claros são o “pedacinho do céu” desse programador. O caos é seu pesadelo. A beleza se dá pela legilibilidade do código.

Superpoderes

1. Constroem códigos tão bons que você poderia apostar sua vida neles!
2. Podem criar ambientes aonde a base do código permaneça em forma pura, independente das habilidades dos outros membros da equipe
3. Se eles construíram o sistema, ele será escalável

O Lado Negro

1. Sempre acredita estar certo
2. Se preocupa mais com os casos de teste do que com os problemas do usuário
3. Nunca considera o sistema como acabado

Deixe-os com raiva

1. Misture espaços com tabs
2. Evite dar commit e testar seu código
3. Escale-os para atividades de improvisação

O inventor

Algo diferente e legal está sempre saindo do “laboratório” do inventor. Ninguém lhe pediu nada, mas ele está sempre criando coisas novas.

Motivação

O inventor é movido pela necessidade de explorar e dar vida a algo completamentamente novo e único. A curiosidade do “E se…” o leva a procurar novas soluções.

Superpoderes

1. Cria novas soluções de tecnologia que (às vezes) são úteis
2. Tem um entusiasmo contagiantes
3. Fazem você dizer: “Nossa, eu nunca tinha pensado nisso dessa maneira”

O Lado Negro

1. Não foi inventado ainda

Deixe-os com raiva

1. Vá contra as ideias dele dizendo que “Aquele não é o padrão da indústria”

O conquistador

Nenhum problema é difícil demais para o conquistador. Para eles, programar é estar em uma odisséia com cada vez mais desafios a superar. O conquistador é esforçado e competitivo, mas não necessariamente competitivo com outras pessoas.

Motivação

Quando maior o desafio, maior será sua empolgação.

Superpoderes

1. Consegue resolver problemas que você pensava ser impossíveis
2. Têm foco mais nítido do que um laser e são mais resistentes do que um corredor de maratona
3. São uma enciclopédia ambulante de algoritmos

O Lado Negro

1. Vão fazer problemas triviais se tornarem complexos somente pelo prazer de resolve-los
2. Estão sempre entediados e aborrecidos

Deixe-os com raiva

1. Escale-os para atividades simples do tipo CRUD
2. Force-os a usar linguagens imperativas
3. Presentei-os com livros de Sudoku Nível Iniciante

O resolvedor de problemas

O resolvedor de problemas é uma pessoa determinada e pragmática. Um problema bem definido será resolvido, e resolvidos rapidamente por todos os meios necessários.

Motivação

Esse programador é focado na agregação de valor. Assim, deixa de lado o processo criativo a fim de entregar exatamente o que lhe foi pedido.

SuperPoderes

1. Escuta
2. Resolve
3. Usa a tecnologia para resolver os problemas do negócio e não para trazer mais problemas

Lado Negro

1. Irrita os programadores puristas
2. Podem ser oportunistas

Deixe-os com raiva

1. Dê a eles muito trabalho
2. Atribua-lhes tarefas de programação sem qualquer contexto, em que tenham que apenas “digitar código”

E você, se encaixa em alguma dessas classificações? Comente!

Postado originalmente em Eu Faço Programas.

Essa forma de trabalho, no entanto, obriga o projetista a estabelecer relações entre certas classes que possuem pouco ou nada em comum, resultando em modelagens por vezes confusas e complicadas de se dar manutenção. Para ilustrar essa questão, imagine que você está modelando um sistema com operações que serão tratadas como transações no banco de dados.

Neste sistema, haverá operações para movimentação de estoque (com saída de quantidade de um depósito e a respectiva entrada no depósito destino), para registrar contabilizações (envolvendo uma ou mais contas contábeis para débito e crédito) e para efetuar pagamentos a fornecedores. Distingue-se neste cenário a necessidade de modelagem de diversas classes de objetos: item de estoque, conta contábil, movimento de estoque, contabilização, fornecedor, entre outros. Há ainda claramente uma entidade que deve controlar as transações no banco de dados para garantir que as alterações comandadas numa operação sejam tratadas como um bloco único. Embora nada tenham em comum, tanto movimentos de estoque quanto pagamentos a fornecedores devem ser contabilizados. Um diagrama de classes que ilustre essas relações ficará confuso por misturar conceitos de movimentação de itens e de pagamentos. A situação tende a piorar se surgirem outras operações que precisem ser contabilizadas. E do ponto de vista da programação, modificações na classe de contabilização afetarão todas as outras classes, exigindo que estas também sejam revisadas.

Recursos que permeiam várias classes de um sistema, vinculando mesmo aquelas que implementam regras conceitualmente distantes, são chamados de cross-cutting. Outros exemplos de recursos assim: criação de logs de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados, autorização para executar operações, tratamento de exceções, etc. Melhorar a solução para esse tipo de recurso é a proposta da Programação Orientada a Aspectos (POA), onde o código que implementa os recursos cross-cutting são retirados das classes de negócio e inseridos em módulos próprios – os Aspectos. O código das regras de negócio fica mais limpo e alterações no funcionamento dos recursos cross-cutting passam a ser centralizadas no Aspecto.

A POA depende ainda de um mecanismo que permita vincular a execução dos códigos do Aspecto à execução das regras de negócio. A solução proposta pela POA é centrado no modelo de pontos de ligação (Join Points). Tal modelo é definido por 3 características: o momento em que o código poderá ser executado – chamado de join point -, uma forma de especificar esses momentos e uma forma de especificar o código que deve ser executado em cada momento.

Um ponto de ligação pode ser encarado como um evento que ocorre no código da regra de negócio – marcado pela execução de um determinado método ou pela alteração no valor de uma propriedade, por exemplo. Criar pontos de ligação significa, portanto, indicar quais desses eventos devem ser monitorados pelo Aspecto, usando para isso estruturas chamadas de pointcuts. Os pointcuts se valem de uma sintaxe especial para possibilitar a indicação de quais métodos e propriedades dispararão a execução do código relativo a um ponto de ligação. Ao código que será executado pelo Aspecto quando um ponto de ligação é encontrado dá-se o nome de Advice.

Assim como as Classes, Aspectos também podem conter variáveis internas (membros) e ter heranças para especializar seu comportamento, adequando-o a uma função mais específica. Voltando ao exemplo das operações dado no início deste post, uma solução usando Aspectos seria criar um Aspecto base para tratar transações com o banco de dados. Isso implica a criação de um ponto de ligação para apontar o início da função que realiza a operação, momento em que o advice desse ponto de ligação deve tomar providências para garantir a existência de uma transação no banco de dados. Outro ponto, ao final da operação, deve encerrar a transação. Para cuidar das transações que precisem ser contabilizadas faríamos uma herança desse Aspecto e introduziríamos o código necessário num dos pontos de ligação já estabelecidos. Nesta herança, indicaríamos como pointcuts apenas as classes expressando regras passíveis de serem contabilizadas.

A experiência mais bem sucedida para popularização da POA por enquanto é uma extensão da linguagem Java criada pelo Centro de Pesquisas da Xerox que tem o nome de AspectJ. Trata-se de um projeto open source disponível na Fundação Eclipse. Há ainda algumas bibliotecas voltadas para C#, disponíveis na forma de frameworks. O Delphi Prism – IDE para programação na plataforma .NET usando a linguagem Delphi – incorporou uma implementação para uso de POA em sua versão 2010 usando para isso recursos do próprio .NET. Veja aqui um exemplo de uso com a sintaxe do Delphi.

Tudo o que foi apresentado aqui não poderia ser resolvido apenas com uso de classes? Sim, poderia. Poderíamos até mesmo implementar tudo em uma solução exclusivamente procedural, se desejássemos. O ponto aqui é que as ferramentas até então existentes podem ser melhoradas para resolverem de forma mais eficiente determinados problemas. Uma nova filosofia está sendo amadurecida no campo da análise de sistemas e da programação e, mais cedo ou mais tarde, as linguagens também terão que evoluir para acompanhá-la consistentemente.

Fonte: Balaio Tecnológico