Mapeamento de Objeto Relacional com Delphi

No desenvolvimento orientado a objeto uma das coisas mais trabalhosas de se fazer e á montagem do modelo de negocio que vai servir de base para a construção de um sistema, e quanto maior o sistema maior o trabalho, as linguagens que hoje dominam o mercado de desenvolvimento  tem vários recursos para diminuir este trabalho, um desses recursos é o framework de persistência de dados que faz a abstração desta camada deixando o desenvolvedor mais seguro, na hora de trocar o banco de dados da aplicação se esse for o caso. No desenvolvimento utilizando Delphi já foram lançados vários framework para esta funcionalidades porem nem todos tiveram continuidade nas novas versões do Delphi,  como exemplo podem ser citadas as ferramentas DePO (DEPO), InstantObjects (INSTANTOBJECTS), tiOPF (TECHINSITE).

O tiOPF é um dos mais interessantes sendo  disponibilizado pela empresa australiana TechInsite, e tem como objetivo facilitar o mapeamento entre um modelo de negócio orientado a objetos e um banco de dados relacional, sendo assim possível construir aplicações para a plataforma Windows de 32 bits (Win32) e o sistema operacional Linux, uma vez que ela é compatível tanto com a ferramenta Borland Delphi (DELPHI, 2007) e como com o compilador multiplataforma FreePascal.

Na página desta ferramenta na Internet está disponível uma ampla documentação, juntamente com o código fonte aberto e grauito. Algumas características chave são destacadas:

• Flexibilidade na troca de camada de persistência, permitindo alterar facilmente o SGBD utilizado, sendo compatível com vários SGBDs disponíveis atualmente no mercado, como Oracle, MS Access, MS SQLServer, Interbase, Firebird, entre outros.
• Conjunto de classes base abstratas para construção de complexos modelos de objetos.
• 32 objetos visuais compatíveis com objetos do framework para a construção de GUI complexas.
• 1518 testes unitários com DUnit para garantir estabilidade.
• 160 páginas de documentação para começar a trabalhar com tiOPF
• Newsgroup para suporte
• O uso do conceito de RTTI no coração do framework também é destacado na documentação disponível na página desta ferramenta na Internet, por exemplo, para capturar dinamicamente a lista contendo o nome dos atributos publicados por uma classe.

Ainda nesta documentação é demonstrado como construir uma aplicação de exemplo utilizando o tiOPF. Após construir o diagrama de classes UML contendo o modelo orientado a objetos do negócio, a codificação destas classes deve ser feita manualmente, porém é sugerido o uso de modelos que acompanham o código fonte em forma de comentários, a fim de facilitar o trabalho e padronizar quanto à herança que deve ser realizada a partir das classes de base do framework. A figura a seguir exemplifica o modelo de abstração proposto pelo Framework

O tiOPF já foi abordado em artigos na revista ClubeDelphi ed. 121 Artigo: Mapeamento Objeto / Relacional em Win32, Sendo esse o mais ressente e este é o link para o projeto  http://tiopf.sourceforge.net/

Por Bruno Borges

Personalizando o setup de sua aplicação

Geralmente, nossas aplicações necessitam de algum tipo de personalização no ato de instalação. Para este fim, o Visual Studio nos oferece ferramentas as quais nos permite criar projetos de setup. Esse tipo de projeto possui um processo padrão de instalação, contudo ele pode ser personalizado. No link abaixo há um post no qual ensino em 8 passos como personalizar um projeto Setup desenvolvido no visual Studio.

http://devbrasil.net/profiles/blogs/8-passo-para-personalizar-o

Poder e Responsabilidade

“É a vontade de poder que leva o nobre a criar o “bom” relacionando-o a tudo aquilo que lhe serve, que o fortalece.” (Nietzsche, 1998)

“É esse o sentido da vida, criar o seu próprio “bom’’, sendo o “ruim” um reflexo, aquilo que fica fora dos meus interesses, aquilo que não desperta qualquer desejo no nobre, e portanto, é como se não existisse.” (Nietzsche, 1998)

No livro genealogia da moral o filósofo Nietzsche faz uma reconstrução do bom e do ruim partindo da necessidade de poder em direção aos interesses do individuo que dita a moral vigente.

O antropólogo inglês Richard Wrangham, após décadas de observação do comportamento dos primatas percebeu que os chimpanzés possuem uma estrutura hierárquica que estabelece a divisão do poder no grupo e que todos os indivíduos do grupo disputam os níveis de poder. O poder num grupo de primatas gera um status que resulta em recompensas como mais fêmeas ou melhores alimentos.

As relações de poder nas organizações humanas seguem a mesma estrutura descrita por Nietzsche e Wrangham. Nas empresas a vontade do poder e por consequência a busca do status destaca a liderança do colaborador. De acordo com Chiavenato existem seis tipos de poder organizacional: legítimo, de Recompensa, Coercitivo, de Especialização, de Referência, e de Informação. O poder legítimo é gerado pela estrutura funcional da empresa. O poder de recompensa também é inerente à estrutura organizacional. O poder coercitivo está relacionado à habilidade do superior em punir um funcionário. O poder de especialização é alicerçado pelas habilidades de um gestor. O poder de referência, muitas vezes chamado de carisma pessoal, é o poder de um indivíduo de influenciar um outro por sua força de caráter. O poder de informação deriva da posse de informação importante em um momento crítico quando esta é necessária ao funcionamento da organização. Parafraseando Stan Lee, poder traz responsabilidade.

A responsabilidade sobre as consequências resultantes das escolhas feitas pelo detentor do poder é inerente a qualquer tipo de poder existente nas organizações. No ocidente é comum saciarmos nossa sede de poder sem assumirmos o ônus das escolhas quando essas geram mais consequências ruins do que boas. Deter poder em uma organização significa acumular responsabilidades.

Os leões vivem em bandos. As fêmeas caçam, enquanto os machos vigiam o território. Quando um novo macho assume o controle de um bando, ele mata os filhotes do outro leão. O que muitos de nós percebemos facilmente é o poder que o macho possui diante da não necessidade de caçar. É difícil percebermos que o macho tem a responsabilidade de manter a segurança dos filhotes e do território. Caso ele também tivesse a responsabilidade de caçar, a prole e o território ficariam muito vulneráveis, pois após a caça as leoas ficam exaustas.

É evolutivo e natural que tenhamos sede de poder, mas é necessário que aprendamos com os outros animais a pagar o preço do status adquirido através da aquisição do poder, assumindo as consequências de nossas escolhas como líderes.

Por Jorge Santos

CHIAVENATO, Idalberto. Gerenciando pessoas. São Paulo: Makron Books,1994, 3ª ed., pp.167-181

NIETZSCHE, Genealogia da Moral. São Paulo: Companhia das Letras, 1998.

WRANGHAM, R e PETERSON , O Macho Demoníaco: As origens da agressividade humana. São Paulo: Editora Objetiva, 1998.

LEE, Stan, Amazing Fantasy #15. EUA: Marvel Milestone Edition, 1962.

Class operator

classe operator são métodos que vão sobrecarregar os operadores mais comuns do dia-a-dia ( < , >, =, +, -, *, /, ….). O compilador gera uma chamada para a sobrecarga apropriada, combinando com o contexto, para a assinatura da função de operador.No nosso exemplo abaixo usaremos  “GreaterThan” para comparar dois objetos do tipo TQuadrado, cuja os atributos altura e base serão necessária para o calculo da área.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Por Lindemberg

Os Papeis da Programação Extrema

A Programação extrema é umas das metodologias bastante utilizadas em empresas de vários tamanhos, sendo ela mais indicada para aplicação em times pequenos e em novos projetos, não é impossível implantar esta metodologia em um time que já esta com projeto em andamento, nesta forma esta implantação pode começar aos poucos com algumas praticas respeitando sempre a cultura e o ambiente em que se pretende fazer tal implantação, para isso o XP apresenta alguns papeis para que esta transição seja algo suave e organizado e sustentável. São Eles :

Cliente –  Define o que é o projeto e como deve ser desenvolvido, o termo de cliente pode não estar associado a uma pessoa individual, mas sim a um conjunto de pessoas que :

• Define e dá prioridade as “user stories”
• Define requisitos do projecto
• Descreve os testes que cada fase de desenvolvimento tem de passar antes de se passar à fase seguinte
• Poderá ser o utilizador final da aplicação

Treinador (Coach) – Pessoa responsável pelas questões técnicas do projeto. Recomenda-se que esta pessoa seja a que possua maior conhecimento do processo de desenvolvimento, dos valores e práticas da XP. É de responsabilidade do coach verificar o comportamento da equipe frente ao processo XP, sinalizando os eventuais erros cometidos pela equipe.

Programador – Pessoa responsável em analisar, projetar e codificar o sistema. Na XP não existe diferença entre analista, projetista e programador, uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades. Naturalmente existem níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas da XP, como a programação em par, a tendência é a equipe se tornar uniforme em suas habilidades.

Tester – Tem como objectivo realizar testes funcionais do projecto em desenvolvimento, podendo esses testes serem efectuados junto do cliente, se o desenvolvimento foi efectuado correctamente existem poucas hipóteses de chegarem “bugs” graves a esta fase, pois o código já se encontra testado a priori pelos programadores à medida que o vão escrevendo.

Treinador (Traker) – Cria estimativas de tempo sobre as User Stories e tarefas, verifica se o tempo gasto nas tarefas completas coincide com o previsto inicialmente, e vai actualizado o tempo total previsto para a duração do projecto. Tem ainda a responsabilidade de guardar um histórico dos testes funcionais criando um registo dos problemas encontrados, assim como o número de classes métodos e linhas de código geradas.

Gerente – É a pessoa que lidera o projecto internamente e com o consumidor, e protege a equipa de interferências exteriores.

Todo este conjunto de responsabilidades que sera dividido emtre a equipe serve para dar flexibilidade a metodologia e mesmo assim não se aconselha utilizala em todos os projetos, existe algumas avaliações a serem feitas para poder tomar esta decisão. Segundo Kent Beck em Programação Extrema Explicada, um dos fatores mais impeditivos para se adotar a metodologia é a cultura da empresa que entra em choque com o time e o cliente seja na especificação do requisito ou no tempo que vai ser gasto ate no resultado final do que vai ser entregue, outra cultura que não contribui com XP é aquela que o programador tem que trabalhar mais de uma semana em velociade maxima e alem do horario para entregar um valor, uma equipe cansada não consegue executar bem as praticas do XP. Existe outros fatores a serem avaliados, segue alguns links com mais detalhes.

http://www.slideshare.net/mauricio.linhares/extreme-programming-explicada

http://www.slideshare.net/cmilfont/apresentando-extreme-programming

Por Bruno Borges.

Métrica Ágil: Pareamento

Muitas equipes aderentes à programação em par sofre de um(ns) problema(s), um deles é o revesamento dos pares na sua equipe, muitas vezes o rodizio que deveria acontecer com frequencia não acontece, gerando uma ilha de conhecimento limitada a certo(s) par(es).

Uma das soluções que encontrei foi o acompanhamento em um quadro de pareamento que li em um post no blog da Caelum.

Essa imagem indica a quantidade de tarefas que cada programador desenvolveu com um outro programador. O problema de isolamento de conhecimento pode ser acabado com uma simples análise deste quadro, pode-se melhorar a organização, o rodizio dos pares e consequentemente 0 compartilhamento de conhecimentos. A Caelum sugere a quantidade de tarefas que cada programador fez com um outro e acrescendo ainda mais, pode-se até informar a quantidade total de pontos neste quadro para melhor análise, pois não adianta um par fazer 5 tarefas de 1 ponto, enquanto outro par fez 2 tarefas de 8 pontos. Fica um pouco “desequilibrado”, daí pode-se acrescentar tal informação para facilitar o gerenciamento e organização.

Fontes:

http://blog.caelum.com.br/pensando-em-metricas-para-times-ageis/

Por Carlos Cavalcanti
@CarlosCaval
www.CarlosCavalcanti.com

Programadores “medíocres” e “bons” programadores

Já que o tema programadores medíocres estar na moda…acredito que essa imagem seja reflexo do amadurecimento do mercado que já consegue reconhecer os próprios erros e enxergar o perfil de um bom profissional de desenvolvimento de sistemas. Pois bem começando pelos mediocres, a caracteristica mais comum nesses programadores são aqueles cumpridores de meta, tarefas…o seu negócio é fazer, fazer, fazer…se o seu código não tem qualidade, não importa! o negócio é atingir a meta!  Entregam o que é solicitado e seja o que Deus quiser…. Inovação com certeza é carta fora do baralho. O seu pensamento é “Inovar pra que ? sou pago para programar e não para inovar”. Triste isso não!? São programadores que não gastam o mínimo de tempo para estudo da programação, se acham conhecedores profundos de regras de negócio, e pode até ser, mas regras essas que os clientes dele ensinaram… É um programador que “vai levando o barco”, de segunda a sexta… Nada de novos estudos, nada de investimento, nada de espetacular no seu código. Simplesmente vai “levando o barco”. Alguns “aprendem” só enquanto trabalham realmente… E o pior é que ele tem plena certeza disso…o lema é “aprendizado só no trabalho!”. Não tomou consciência da importância da engenharia de software e do Estudo de arquiteturas, POO,  padrões de projetos…. conceitos de interfaces ? … Lembro-me muito bem que quando expliquei o uso de interface e o programador simples replicou com uma seca frase “Não funciona!”. Para finalizar, se ele for demitido, reze, pois hoje em dia ele estará mais perdido do que cego em briga de facão. OK!! Chega de tanto terrorismo e vamos aos “bons”. Programador bom é aquele que estuda, analisa, ele sabe que tem bagagem, acompanha o mercado, faz parte de grupos de programação e acima de tudo ENSINA, não para dizer “Eu sei”, mas porque conhece a importância de ensinar. Programador bom tem que ser DOIDO… doido por conhecimento, ele destroi paradigmas e maus costumes, conhece os pontos fracos de um sistema, ele vai além dos requisitos documentados de um sistema, ele consegue ver o futuro do sistema como quem conhece o último capítulo de um livro. Ele conhece as necessidades que nem mesmo o próprio usuário se dar conta, ele tem um foco na solução que transcende dimensões, ver o mundo de outra forma, alias ele nem parece que é deste mundo. Seu lema é “Hoje, melhor que ontem e pior que amanha”. Resumindo, você não precisa ser obrigatoriamente bom e não tem necessidade de ser medíocre, o que deve ficar claro é que você precisa ser melhor, não melhor que os outros, você precisa ser melhor do que você já é.

 

Por Lindemberg

Quer uma ajuda ?

A utilização de Class Helper permite que uma classe seja estendida sem que para isso seja necessário o uso de Herança.

Exemplo:



Neste exemplo temos a classe TPessoa que possui a propriedade nome e em seguida temos a classe TEndereco que, ao se associar com TPessoa, expõe todos seus os atributos e métodos, ou seja…. TEndereco ajuda TPessoa.

Abra-Cadabra!!!….Perceba que na instância de TPessoa os atributos da classe TEndereco são expostos como se fossem de TPessoa. Com esse recurso, você pode tornar a sua classe mais fragmentada, legível , coesa e independente.

Dica: Alguém já sentiu a necessidade de estender as classes do Delphi sem alterar o código nativo ?

Bom proveito!

 

Por Lindember Cortez

Introdução as Expressões Regulares (RegEx)

Nos últimos meses ouvi muito falar sobre Expressões Regulares, que vou chamá-las de Regex, acho mais elegante e fácil de tratar. Bem, Regex tem se mostrado uma forma muito dinâmica de verificar padrões em texto, e podem ajudar e muito o dia a dia de qualquer programador. Verifiquei os mais diversos usos do Regex de simples substituições em blocos de textos até testes mais elaborados como os feitos pelo Cucumber, uma “gem” para testes muito utilizada no mundo RoR (Ruby on Rails).

Com o contato que tive com o RoR foi que tomei conhecimento do Regex, mas vale salientar que não é exclusividade do RoR, na verdade não existe uma ligação direta, o Regex está ai independente da linguagem de desenvolvimento (Delphi, C#, PHP) e em inúmeros editores de textos.

O que irei mostrar nessa introdução é como definir algumas Regex que poderão validar se os dados informados num CEP, CNPJ, CPF ou Telefone foram preenchidos seguindo os seu modelo de definição. Agora vale uma ressalva, o Regex não validará se os dados (o dígito, por exemplo) estão corretos, ele apenas verificará se estão dentro do modelo (máscara) correto.

Deixemos de conversa e vamos ao primeiro exemplo:

^\d{5}-?\d{3}$

Pronto, esta sopa de letrinhas é nossa primeira Regex, parace complicado mais vou “destrinchá-la”

^ = Identifica o início da nossa Regex
\d{5} = Define que deverá ser informado uma cadeia de 5 dígitos (d), isto é, apenas números.
– = Simplesmente um hífem
? = Este símbolo “fala” que o caracter anterior a ele, neste caso o “-” (hífem), é opcional.
\d{3} = Como vimos mais acima define que deverá ser informado um cadeia de 3 números.
$ = Finaliza nossa Regex

Com esse código acima  o usuário estaria autorizado a digitar, por exemplo, “12345-123” ou “12345123”, mas não poderia digitar “12345 123” ou “a1234-12c”.

Mais um exemplo:

^\d{2}-\d{4}-\d{4}$

Esta é muito fácil, mas ganha um doce quem adivinhar onde poderíamos utilizá-la.
Não vá dizer que não percebeu. Vou dá uma dica: te……

\d{2} =dois dígitos
\d{4} = quatro dígitos
\d{4} = quatro dígitos

Muito bem, telefone.
Nesse caso tem uma diferença, o “-” (hífem) não é opcional.

Pronto acho que para uma introdução está bom, abaixo segue mais alguns exemplo que você poderá estudar:

CPF = ^\d{3}\.?\d{3}\.?\d{3}\-?\d{2}$
CNPJ = ^\d{3}.?\d{3}.?\d{3}/?\d{3}-?\d{2}$
IP = ^\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b$

No final um bônus.
Quer validar sua Regex?  Visite o site http://www.regextester.com/ , confesso que achei o site muito “poluído”, mas dá pra quebrar um galho.

 

Por Vitório Ramon

Fontes:
http://pt.wikipedia.org/wiki/Express%C3%A3o_regular
http://guia-er.sourceforge.net/index.html
http://www.devmedia.com.br/post-17709-Regular-Expressions-Em-C-Parte-1.html
http://www.devmedia.com.br/post-12042-Validando-Formularios-Usando-Regular-Expression.html

Uma boa rede social para desenvolvedores

Todos sabemos que redes sociais já fazem parte do cotidiano de muitas instituições, bem como de pessoas que as utilizam para se manter informado, transmitir conhecimentos etc. Nesse universo existem muitas comunidades de todos os gêneros. Dentre elas a comunidade de desenvolvedores, que, diga-se de passagem, é muito ativa nesse meio, possuem uma vastidão de redes de difusão de conhecimento. Dessas várias redes, gostaria de apresentar uma que vem ganhando grande destaque. A DevBrasil é uma comunidade de desenvolvedores que hoje conta com mais de 3000 usuários os quais comentam sobre os mais diversos temas como o uso de ferramentas da tecnológicas, ciclo de vida de aplicações, boas práticas etc. Se você é  desenvolvedor e gostaria de conhecer mais sobre o universo da programação, esta rede social é um bom ponto de partida. para acessar a comunidade basta acessar o endereço http://devbrasil.net/

Yan Justino