Equalizar tabelas tomando como base um banco de dados

Olá a todos!

Já deve ter acontecido contigo: precisar mandar um script de BD para algum cliente mas ninguém faz idéia da versão que o banco de dados do cliente está.

Enfim, já passei por isso diversas vezes e tinha que assumir que o banco de homologação interno da empresa seria o correto. Então eu fiz esse script para tentar simplificar (um pouco) a minha vida ao equalizar tabelas de clientes. Segue abaixo o código:

A importância de se manter calmo

Apesar do assunto no geral ser tecnologia, dessa vez eu vou sair um pouco do foco.

Acabei de perder uma chance única de trabalhar na Europa porque eu fiquei nervoso demais pra pensar claramente. Pois é... Eu estava com a faca e o queijo na mão para imigrar pra Europa como imigrante qualificado e por causa de besteira minha, perdi a chance.

O pior de tudo é que ao sair da empresa em que fiz a entrevista, 5 minutos depois, os programas que eu deveria ter escrito apareceram como mágica na minha cabeça.

O que eu quero dizer com isso tudo? Inteligência emocional. Demonstrei que não tenho tanta assim e ao invés de pedir 5 minutos pra respirar um pouco e refletir melhor sobre as decisões que eu tomaria, fui querer dar uma de Braddock e encarar o desafio do jeito que ele veio. Óbvio que as minhas chances foram a zero quando fiz isso. Nessa hora não importa capacidade técnica, experiência, preparo, nada... Basta manter-se calmo.

Não posso culpar a empresa por não me querer no seu quadro de funcionários, afinal, eles já tinham feito muito por mim me levando até a Europa para que eu pudesse fazer a entrevista com eles. A culpa disso tudo é minha e somente minha. Daí a importância de se manter calmo, pensar devagar, não se importar com a pressão em volta e fazer o seu, sem problemas. Me prendi demais a um framework, esqueci de contar complexidade algorítmica, na fácil notação Big O. Enfim, meti os pés pelas mãos e só um milagre faria efeito naquela hora.

Triste, mas é vida que segue.

Cuidado com o excesso de especialização!

Olá a todos!

A especialização no geral é uma coisa boa tende a te render certa fama. O chato é deixar acontecer aquela máxima de que "Para quem é muito bom com martelo, tudo vira prego".

Pois é, às vezes precisamos recuar um pouco nas convicções e reavaliar se o caminho que estamos seguindo é realmente o melhor, ou se realmente aquela técnica ou tecnologia que nos é tão familiar é a melhor forma.

Já ví gente substituindo foreach por iterator só porque acha que é melhor implementar Design Patterns. Ok, os padrões de projeto tem sim o seu mérito, mas na minha opinião (que pode valer porcaria nenhuma...) só justificam a sua utilização quando o projeto tem tamanho para isso. Eu acho que escreve-se muito para obter o mesmo resultado (com a vantagem de ser escalável, claro!!). Para o usuário final, não importa qual foi a metodologia utilizada, desde que funcione.

Não entenda isso como uma licença poética para escrever programas porqueiras. Não é isso. O que eu quero dizer aqui é que toda técnica tem algum uso em alguma situação. O nosso trabalho como programadores envolve entender essas situações e apresentar a melhor solução possível. Às vezes, o prazo, orçamento, pressa do usuário, etc, vão justificar muito mais a implementação do foreach, já que o objetivo (neste caso específico) é percorrer uma lista qualquer.

Aí alguém vai te dizer "Implemente padrões de projetos!! O seu software vai ficar fácil de manter, bla, bla, bla...". Deixe-me contar um segredo: quem programa mal continua programando mal, mas com padrões de projeto. Eles não substituem a lógica de programação. Só dão uma nova abordagem à técnica.

Enfim, a idéia desse post é tentar te colocar em linha com o Keep It Simple.

Grande abraço!!

Larga a mão de ser micreiro!

Micreiro. Esse é praticamente o início de todo programador. No começo da carreira, a maioria dos programadores tem seu estágio "Che Guevara", querendo mudar o mundo e desenvolver softwares livres, com linguagens open source.

Não importa se foi com Perl, Python, PHP, etc, principalmente se você assistiu àqueles filmes como "Jogos de Guerra", "Matrix" ou "Hackers - Piratas de computador". Todo aquele glamour de desenvolver softwares para invasão, vírus de computador, war dialing, azucrinar as grandes corporações...
Seria legal, se não precisássemos de comida, água, energia elétrica. Mas não é assim: portanto é imprescindível que exista uma fonte de renda.

Nessa hora você ignora o seu Karl Marx interior, encara o mercado e vai numa APInfo da vida procurar emprego como programador PHP, por exemplo. Salvo exceções (sim! Elas existem!), você vai trabalhar feito um camelo por um salário digamos, ridículo. Estamos falando aqui de vaga pagando R$ 900,00 para turnos de 10 horas em média para profissional em nível pleno ou até sênior. Fora que você vai precisar de dois idiomas, proatividade, motivação por desafios e toda aquela papagaiada que os RHs adoram pregar. Quando eu vejo uma vaga dessas, a minha vontade é de bater no infeliz que teve a coragem de publicá-la com um gato morto não até miar, mas até cantar as Bodas de Fígaro sem desafinar.

Então fica a pergunta: dá pra ganhar dinheiro com programação?
Sim! É possível voltando ao título desse post. Essa é uma frase de um amigo, quando a uns 8 anos eu comentei que faria um curso para administração de PostgreSQL. E assim como você quando leu o título desse post, eu me senti meio contrariado. Eu conhecia VB6, SQL Server, etc (dada a época...), mas achava que eram ferramentas caras demais pro que faziam. Só que para ganhar dinheiro com informática tem que usar o que o mercado usa: SQL Server, Oracle, .Net. O Java é a exceção das linguagens open source, pois paga melhor, mas tem que negociar bem ao entrar na empresa.

Em suma, não sou baba ovo de Microsoft, Oracle, etc, mas quem dita os caminhos é o mercado. Se a maioria usa ferramentas proprietárias, vale a pena investir tempo nessas tecnologias. O retorno é mais rápido, fora que projetinho em PHP dá pra fazer por fora depois, certo?

Grande abraço e até a próxima!

So, you wanna be a programmer.

Então, você quer ser um programador. Ok. Mas por onde começar?


Leitura: Você não gosta de ler? Então pare por aqui e acesse o Facebook. Leitura para programador é essencial, pois por mais autodidata que você seja, vai precisar de algum material de referência. E adivinha onde esse material está?


Inglês: Se você conseguiu traduzir o título desse post, parabéns, é um bom começo. Inglês para programadores é essencial. Não quero criticar o material brasileiro, mas as melhores publicações de informática estão no idioma do tio Sam. Portanto, se o seu inglês se limita a contar até dez, é hora de se matricular em um curso de inglês.

Lógica de programação: essa parte é complicada porque lógica não se ensina como as outras matérias, digamos, normais. Lógica envolve treino (muito treino, diga-se de passagem) e aquela aula de lógica de programação que os cursinhos ministram por ai são só a parte superficial. Todo o resto vem com a vivência. Portanto, é interessante que você crie algum projeto para treinar a sua lógica. E passar muito tempo fazendo projetinhos de software. Só assim você vai afiar a sua lógica a ponto de resolver a maioria dos problemas que aparecem.

Orientação a objetos: Não é um pré requisito para programar, porque existem linguagens que não trabalham com objetos, mas é interessante pois o conceito começa pregando reutilização de código, o que para mim é um dos pilares da programação. Mas orientação a objetos no começo é complicado de aprender e ainda mais quando a lógica ainda não está a todo o vapor. Portanto: estude bastante, mas preze pela sua lógica.

Manutenção de softwares: Isso parece estranho, mas todo programador precisa de um pouco de código alheio pra poder identificar o que é bom de se usar nos seus códigos. Isso vai te mostrar um pouco do mundo real para você ver que nem tudo são rosas, inclusive dentro de um código fonte. Fora isso, manutenção em programas prontos é um teste e tanto pra sua lógica, pois mostra qual a sua capacidade de corrigir um erro sem reconstruir tudo do zero. Óbvio que nem sempre isso é possível, mas em 99% das vezes é possível corrigir um programa sem ter de reconstrui-lo.

Paciência: Se você não é nenhum poço de paciência, para ser um bom programador, você terá de exercitá-la diariamente. Bugs, usuários, chefes, gerentes e quaisquer outros seres vivos ou mortos que não sejam você e o seu computador enchem o saco. Os usuários tendem a acreditar que o computador vai substituir o cérebro deles e que tudo é "implícito". Para isso, só posso recomendar muito maracujá e um jogo de videogame bem violento para quando você chegar em casa. Esportes também ajudam a relaxar e exercitar a paciência, principalmente esportes coletivos.

Por fim, Linguagens de Programação: No geral a lógica é a mesma, mudando algumas funcionalidades, mas vale aquela máxima de ser bom em uma linguagem ao invés de ser mediano em um monte. Eu recomendo começar pelo C# ou Java, pois tem nível suficiente pra te preparar para desafios mais contundentes que o mercado te prega. Não é uma regra, mas geralmente o que você resolve em uma linguagem baseada em C, fica mais fácil de refazer se precisar traduzir pra alguma outra linguagem.

E se você achava que programar é fácil, acertou. Não é tão difícil, mas como qualquer outra atividade, requer um esforço da sua parte pra começar a valer a pena.

Até a próxima!

O javascript não sabe fazer conta??

Essa foi a minha primeira impressão ao fazer uns cálculos um pouco mais complexos no javascript. Depois de resolver a maior parte dos erros de contas com o parseInt e o parseFloat, eu descobri outra faceta bem chata deles: se vc digitar um zero à esquerda no valor a reconhecer, ele vai passar pra octal e a sua conta vai ficar mais bonita ainda.

Pra resolver esse problema, basta atribuir a base numérica na própria função parseInt ou parseFloat. Então o código vai ficar assim:

var x = parseInt(y, 10) + parseInt(z, 10); // Assim o javascript vai converter pra um número na base 10, e conseguiremos efetuar nossos cálculos sem problemas. O parseFloat é a mesma coisa.

Agora vem a minha pergunta: por que o javascript não assume a base 10 como default?? Por que ao digitar um zero à esquerda mudamos a base numérica da variável?

Javascript: ruim com ele, mas muito pior sem ele...

Múltiplas implementações de uma mesma camada

Olá a todos,

Neste post eu vou dar um exemplo de como fazer um modelo de implementação que mantenha a mesma camada de negócios, mas que utilize uma camada de dados que só é conhecida pela camada de interface com o usuário.

É muito comum um programa ter mais de uma implementação específica, principalmente quando os usuários finais podem estar geograficamente em locais de difícil conexão, etc. Enfim, às vezes é necessário fazer o mesmo programa praticamente duas vezes. Somente o fato de pensar em reescrever o mesmo programa já me dá frio na espinha, então estava eu aqui pensando com os meus botões: "Será que não dá pra deixar pelo menos a camada de negócio intocada e eu mudo somente a parte em volta??". Depois de alguns ensaios eu vi que dá sim e não é tão complicado quanto parece.

A idéia aqui é basicamente a clássica implementação em 3 camadas (interface com o usuário, regra de negócio e persistência), mas adicionaremos duas camadas intermediárias que farão o trabalho de seleção e carga da camada de persistência, de acordo com as configurações do programa via web.config ou app.config.


Ok, vamos aos detalhes:

- Camada de interface com o usuário: Sem novidades aqui, você vai implementar do mesmo jeito de sempre, deixando-a com o mínimo de regras de negócio possível (num mundo perfeito, nenhuma regra de negócio...), mas adicionando uma chave ao seu arquivo de configuração, conforme abaixo:

Deste jeito, a camada de factory vai abrir a camada de persistência pelo seu nome de assembly, onde o único trabalho que teremos será o de ajustar a versão do assembly.

- Camada de negócio

Aqui também há pouco a adicionar, mas é importante que todas as classes tenham um objeto privado fazendo referência ao acesso a dados. Então fica praticamente como um cabeçalho das classes de negócio a implementação abaixo:

DLInterface.IDL assemblyToRun = new DLFactory.Factory().getDataLayer("Class1");

DLInterface é o meu namespace para identificar a interface de acesso a dados. Como serão implementações separadas, eu preciso deixar algo em comum entre elas, portanto essa intersecção será feita por uma interface.

- Factory

Aqui é uma novidade: Muita gente simplesmente referencia a camada de dados na camada de negócio e a persistência de dados está resolvida. Sim, em aplicações normais isso funciona muito bem, obrigado. O detalhe aqui é que a camada de dados tem mais de uma implementação. Portanto eu vou colar o código inteiro da minha factory e explicar melhor depois.

Parece confuso, mas é só aparência:

No método getDataLayer cria uma instância de um assembly (previamente criado por você, óbvio) e retorna a classe passada no parâmetro. Essa classe é referenciada pelo nome mesmo, por isso o método recebe uma string.

O método getAssemblyType é somente uma centralização de código para buscar a chave no web.config (ou app.config). Se você quiser ignorar, sem crise, mas precisará implementar o conteúdo dele mesmo assim.

Os dois últimos métodos fazem parte de um POG (Programação Orientada a Gambiarra) para contornar uma característica bem chata que eu acabei enfrentando. Se a classe não tem nenhuma referência em código das camadas que ela acessa, o Assembly.Load não toma conhecimento do assembly (mesmo que esteja referenciado certinho...)

- Acesso a dados

As camadas de acesso a dados devem ser implementadas com os mesmos métodos, mesmo que alguns não sejam necessários. Isso porque a interface força a implementação do método e a sua camada de negócios vai precisar conhecer uma estrutura mínima para poder acessar ambas as classes sem conhecê-las completamente.

No meu exemplo aqui, eu defini uma interface bem boba, com apenas um método para teste:

O método showMe simplesmente vai mostrar qual é a camada que está sendo acessada.

No final das contas, a arquitetura desta implementação fica assim:

Esta dica foi testada utilizando o Visual Studio 2010.

Até a próxima!