segunda-feira, 29 de julho de 2013

Oportunidade Mobile - Integritas (remoto)

Aproveitando meu post anterior aproveito para divulgar oportunidades em desenvolvimento mobile, principalmente iOS na Integritas onde trabalho.

Quem tiver interesse, por favor, envie currículo para rh@integritas.com.br

Treinamento de iOS

Nos próximos dias irei participar de um treinamento na TargetTrust de iOS.

Já tinha dado uma olhada antes mas agora pretendo me aprofundar nessa tecnologia, já tinha feito o treinamento de Android também pela TargetTrust.

Mesmo gostando de desenvolvimento web a tendência é mobile, então, nada mais certo do que acompanhar a maré.



segunda-feira, 22 de julho de 2013

Auditoria em PostgreSQL

Uns anos atrás na Sadig onde trabalhava precisei alterar o produto BI para fazer com que as chamadas a banco de dados que já "conversavam" com dbf, SQL Server e Oracle para também rodarem em PostgreSQL, gostei muito desse banco, e cada vez tenho aprendido mais sobre ele.

Agora num cliente, a Lexsis, precisamos implementar o recurso de auditoria no PostgreSQL. Se estivéssemos usando Hibernate poderíamos usar o Envers o qual usando a anotação @Audited na classe com a anotação @Entity cria uma nova tabela com atributos adicionais no banco para gravar as alterações na tabela da entity

Outra opção é ter uma única tabela e gravar o DTO serializado num campo dessa tabela, mas não seria fácil de identificar só utilizando a console do banco.

Usamos JDBC puro, então, uma opção que foi definida em reunião foi criar um schema para auditoria com uma cópia de cada tabela com campos adicionais específicos para auditoria da aplicação usando triggers
Bem, mas para cada tabela se precisa criar a trigger / function e um script para criar a tabela de auditoria, o que na primeira vez se torna trabalhoso e repetitivo pelo número de tabelas existentes em cada aplicação que irá usar a auditoria, porque a trigger é vinculada a uma única tabela e a uma function. Usar uma única function é uma ideia mas não cheguei a um código que contemplasse o meu cenário, mas não perdi muito tempo pois sempre achei interessante ser o mais independente do banco, caso seja necessário migrar para outro.

A ideia de ter uma tabela de espelho num schema separado é interessante por ser mais fácil a visualização, não necessitando de uma interface apropriada. Usando este formato e pensando em otimizar o processo me foquei em dois pontos: como otimizar a criação das tabelas espelhos e como não precisar das triggers.

Referente a criação das tabelas, dando uma olhada no create table do PostGreSQL vi que existe as cláusulas INHERITS e LIKE, o primeiro permite herdar a estrutura de uma ou mais tabelas (multi-herança), onde qualquer alteração nas estruturas das tabelas herdadas como alteração de um campo ou inclusão afeta as tabelas filhas o que resolve a situação de ter os mesmos campos de auditoria em todas as tabelas, enquanto que o LIKE permite pegar a estrutura de outra tabela, mas diferente do INHERITS, alterações na tabela de origem não se propaga para a tabela de destino. O LIKE não copia os valores default da tabela de origem (EXCLUDING DEFAULTS) só o faz com a adição de INCLUDING DEFAULTS.

Referente a segunda opção, para ficar independente de banco de dados utilizei introspection / reflection e anotações. Em cada DTO / entity marquei com uma anotação para identificar a tabela (equivalente o @Entity do Hibernate) do banco e outra anotação para identificar o campo id (primary key - PK) na tabela (equivalente o @Id do Hibernate). Com isso passo o DTO para uma classe com mais alguns parâmetros da aplicação que via introspection / reflection monta um insert...select para popular a tabela de auditoria, ficando assim independente de banco de dados e se for necessário migrar para outro banco só se altera uma classe. 
O único cuidado que se tem que ter com o insert...select é que a ordem dos campos da cláusula select tem que fechar com a ordem dos campos da tabela do insert, pois não vincula o campo / valor da tabela do select com o campo na tabela de destino, podendo dar erro de tipo inválido ou gravar um valor de um campo em outro por estarem na mesma ordem e terem o mesmo tipo de dados.

Com esta metodologia, usando introspection / reflection e anotações, consegui montar um início de um ORM, passando o DTO consigo fazer a exclusão, agora o próximo passo é fazer o insert, update passando o DTO e a listagem lendo os valores da tabela e populando os DTOs necessários.


terça-feira, 9 de julho de 2013

T&T seleciona: Analista Programador Pleno

Analista Programador Pleno

Requerido:
  • Graduação completa ou cursando em Ciências da Computação, Sistemas de Informação e afins;
Conhecimentos em:
  • Testes Automatizados             
  • Shell script, Vbscript, Java, C++;
  • Inglês Intermediário
Pretensão salarial: a combinar


Interessados enviar currículos com pretensão salarial para: talentos@tet.com.br