Banco de Dados, Dica de leitura, Legislação

LGPD – Cenário e regras para adequação

Cenário 

Proteção de dados tem sido um tema de grande destaque nas mídias e claro, nos diversos níveis governamentais de muitos países, principalmente os países da União Europeia, onde esse tema tem sido tratado a mais tempo.

Dados pessoais são bens de altíssimo valor para todos, pois se mal-utilizados, podem nos trazer grandes problemas em qualquer esfera, seja pessoal, profissional e financeira. Devido ao fato de estarmos 24 horas conectados, entrando nessa ou naquela rede social, fazendo compras on-line e assinando serviços via internet, estamos expondo dados pessoais sem sequer nos questionarmos se aquelas informações estão realmente protegidas, e caso estejam, qual o nível de proteção ao qual estão submetidos esses dados, que garantia temos dessa proteção e qual o controle que nós, titulares, temos sobre estes dados. Essas são algumas questões que devemos prestar atenção. 

Do lado corporativo a situação também é delicada, pois a empresa muitas vezes confia a coleta e/ou o processamento dos dados à terceiros sem muitas vezes exigir deste garantias de proteção, regras de tratamento e inviolabilidade. Não podemos deixar de considerar pessoas mal-intencionadas, acreditem, elas existem em toda parte, sorte nossa, são minoria. Houve de um caso próximo a mim, onde um funcionário excluiu propositalmente parte das informações de um sistema, mas esse nível de proteção já nos leva por um outro viés que foge um pouco deste tema, citei aqui somente enfatizar que esta pessoa pode estar ao seu lado. 

Breve histórico 

General Data Protection Regulation, essa é a prima europeia da nossa LGPD. Durante 4 anos a GDRP foi elaborada e discutida até ser aprovada pelo Parlamento Europeu em 14 de abril de 2016 passando a vigorar em 25 de maio de 2018.  

No Brasil, a LGPD foi aprovada em 14 de agosto de 2018 e inicialmente entraria em vigor 18 meses após a sua aprovação, mas através da medida provisória 869/18, a lei teve seu período de vacância estendido para 24 meses após a aprovação, portanto entrando em vigor em agosto de 2020.  

A LGPD possui pontos similares à GDPR, embora seja mais sucinta, o que não significa que seja mais branda, inclusive em alguns aspectos nos quais ambas se parecem, a LGPD algumas vezes se apresenta mais rígida que a versão europeia. 

Organizações que já atendem a GDPR precisarão se adequar aos pontos que diferem uma da outra – visto que ambas podem regular organizações estrangeiras e/ou dados coletados no Brasil e tratados no exterior.  

Mas o que é a LGPD? 

A Lei Geral de Proteção de Dados (Lei 13.709/18) é uma lei que regulamenta o tratamento de dados pessoais, inclusive nos meios digitais (pois ela se aplica a outras formas de armazenamento que não seja exclusivamente digital), por pessoa natural (física) ou por pessoa jurídica de direito público ou privado.  

Esta lei define regras detalhadas para a coleta, uso tratamento e armazenamento de dados pessoais e afetará todos os setores da economia. Após a aprovação, a lei sofreu um veto parcial pelo ex-presidente Michel Temer, o qual vetou a criação de uma agência reguladora – Autoridade Nacional de Proteção de Dados (ANPD)-, considerando contrária aos interesses públicos e inconstitucional. Mas numa medida provisória de 27 de dezembro de 2018 (869/18), a agência finalmente foi criada. 

A LGPD possui alguns fundamentos a saber: 

  • Respeito à privacidade; 
  • Autodeterminação informativa; 
  • Liberdade de expressão, de informação, de comunicação e de opinião; 
  • Inviolabilidade da intimidade, da honra e da imagem; 
  • Desenvolvimento econômico e tecnológico e a inovação; 
  • Livre iniciativa, a livre concorrência e a defesa do consumidor; e 
  • Os direitos humanos, o livre desenvolvimento da personalidade, a dignidade e o exercício da cidadania pelas pessoas naturais. 

Aplicabilidade 

Aplica-se a qualquer operação de tratamento de dados realizada por pessoa natural (física) ou jurídica, de direito público e privado e independente do meio. Confira abaixo a relação de casos em que a lei é aplicável. 

  • Quando operação de tratamento seja realizada no território nacional; 
  • Quando a atividade de tratamento tenha por objetivo a oferta ou o fornecimento de bens ou serviços ou o tratamento de dados de indivíduos localizados no território nacional; ou                  
  • os dados pessoais do objeto do tratamento tenham sido coletados no território nacional. 

Para que a coleta seja considerada em território nacional, o titular dos dados deverá estar neste território no momento da coleta. 

A LGPD não se aplica nos seguintes casos: 

1 – Realizado por pessoa natural para fins exclusivamente particulares e não econômicos;

1.1 – Realizado para fins exclusivamente:

1.1.1 – Jornalístico e artísticos; ou

1.1.2 – Acadêmicos;  

2. Realizado para fins exclusivos de:

2.1 – Segurança pública;

2.2 – Defesa nacional;

2.3 – Segurança do Estado; ou

2.4 – Atividades de investigação e repressão de infrações penais;

Quanto aos dados 

Para os fins desta Lei, considera-se acerca dos dados: 

  • Dado pessoal: informação relacionada a pessoa natural identificada ou identificável; 
  • Dado pessoal sensível: dado pessoal sobre origem racial ou étnica, convicção religiosa, opinião política, filiação a sindicato ou a organização de caráter religioso, filosófico ou político, dado referente à saúde ou à vida sexual, dado genético ou biométrico, quando vinculado a uma pessoa natural; 
  • Dado anonimizado: dado relativo a titular que não possa ser identificado, considerando a utilização de meios técnicos razoáveis e disponíveis na ocasião de seu tratamento; 
  • Banco de dados: conjunto estruturado de dados pessoais, estabelecido em um ou em vários locais, em suporte eletrônico ou físico; 

Quem são os agentes envolvidos? 

  • Titular: pessoa natural a quem se referem os dados pessoais que são objeto de tratamento; 
  • Controlador: pessoa natural ou jurídica, de direito público ou privado, a quem competem as decisões referentes ao tratamento de dados pessoais; 
  • Operador: pessoa natural ou jurídica, de direito público ou privado, que realiza o tratamento de dados pessoais em nome do controlador; 
  • Encarregado: pessoa indicada pelo controlador para atuar como canal de comunicação entre o controlador, os titulares dos dados e a Autoridade Nacional de Proteção de Dados;   

Direitos do Titular 

O titular dos dados passa a ter amplo controle sobre estes dados mediante requisição, os quais compreendem: 

  • Confirmação da existência de tratamento; 
  • Acesso aos dados; 
  • Correção de dados incompletos, inexatos ou desatualizados; 
  • Anonimização, bloqueio ou eliminação de dados desnecessários, excessivos ou tratados em desconformidade com o disposto nesta Lei; 
  • Portabilidade dos dados a outro fornecedor de serviço ou produto, mediante requisição expressa e observados os segredos comercial e industrial, de acordo com a regulamentação do órgão controlador; 
  • Eliminação dos dados pessoais tratados com o consentimento do titular, exceto nas hipóteses previstas no art. 16 desta Lei; 
  • Informação das entidades públicas e privadas com as quais o controlador realizou uso compartilhado de dados; 
  • Informação sobre a possibilidade de não fornecer consentimento e sobre as consequências da negativa; 
  • Revogação do consentimento, nos termos do § 5º do art. 8º desta Lei. 

 Penalidades 

As penalidades aplicadas poderão ir de uma advertência até uma multa de 50 milhões por infração.  

  • Advertência, com indicação de prazo para adoção de medidas corretivas; 
  • Multa simples, de até 2% (dois por cento) do faturamento da pessoa jurídica de direito privado, grupo ou conglomerado no Brasil no seu último exercício, excluídos os tributos, limitada, no total, a R$ 50.000.000,00 (cinquenta milhões de reais) por infração; 
  •  multa diária, observado o limite total a que se refere o item acima; 
  •  Publicização da infração após devidamente apurada e confirmada a sua ocorrência; 
  •  Bloqueio dos dados pessoais a que se refere a infração até a sua regularização; 
  •  Eliminação dos dados pessoais a que se refere a infração; 

Referências:

http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2018/Lei/L13709.htm

https://eugdpr.org/

https://www.congressonacional.leg.br/materias/medidas-provisorias/-/mpv/135062

Padrão
Técnicas

C# 8 – Novidades – Parte 1

Esse é o primeiro post de uma série onde serão abordadas as novas funcionalidades da versão 8 do C#. 

Começaremos por uma funcionalidade chamada Nullable Reference Types, que permite ao desenvolvedor evitar os conhecidos NullReferenceExceptionEsse tipo de erro ocorre quando tentamos acessar um membro em um tipo cujo valor é null ou sem instanciar o objeto previamente. 

Esse problema pode aparecer por descuido ou inexperiência na linguagem, mas agora  podemos identificar esse problema durante a codificação e não mais na hora de testar ou pior, em alguns casos, em  produção.

Abaixo temos os principais métodos deste exemplo. O código completo pode ser baixado aqui.

public static string ExibirDadosAluno(Aluno aluno)
        {
            return 
$"Nome: {aluno.Nome} 
Sobrenome: {aluno.Sobrenome[0]}., 
Idade: {aluno.Idade}";
        }

public static IEnumerable<string> ListarAlunos(IList<Aluno> alunos)
        {
            foreach (var aluno in alunos)
            {
                yield return ExibirDadosAluno(aluno);
            }
        }

O método ListarAlunos itera sobre uma coleção e exibe os dados de cada um dos alunos no formato {Nome} {S.}, {Idade}. Ex.: Fernando F., 38.

Para exibir apenas a primeira letra do sobrenome, utilizamos a sintaxe aluno.Sobrenome[0]. Ao executar esse código, teremos o erro da figura abaixo, pois estamos tentando acessar um valor null.

Imagem 1 – NullReferenceException.

O contexo #nullable

Agora podemos dizer ao compilador que estamos trabalhando com tipos que podem ser null e deixar que ele nos alerte sobre potenciais problemas. Para isso vamos submeter nosso código a um contexto de tipos anuláveis. Para fazer isso, basta inserir #nullable enable no início do arquivo.

Imagem 2 – Definindo o contexto para tipos anuláveis.

Para fins didáticos, a classe Aluno – Imagem 3 – foi deixada no arquivo principal, portanto esta também faz parte do contexto, que verifica o arquivo completo em busca de inconsistências.

A parte legal começa agora, podemos notar que o construtor está sinalizado por um alerta, informando que há um membro não inicializado que este poderá causar problemas no futuro.

Imagem 3 – Alerta de membro não inicializado.

P.S. Por se tratar de um alerta, este também também aparece na janela de erros (Error List).

Vamos inicializar esta propriedade e ver como se comportará nosso código.

Imagem 4 – Associação inválida.

Nesse caso estamos associando um null para um tipo que não aceita este valor. Agora marcaremos a propriedade “Sobrenome” com o símbolo “?” para que esta possa receber null, conforme imagem abaixo:

Imagem 5 – Alterando a propriedade para aceitar null.

Note que após os devidos ajustes terem sido feitos, ainda temos um alerta para tratar no método ExibirDadosAluno.

Imagem 7 – Possível “desreferência” de null.

Esse alerta informa uma possível “desreferência” de null, ou seja, o compilador está nos avisando que em algum momento a referência desta propriedade pode se tornar null. Neste caso, basta que façamos um tratamento condicional no retorno do método.

Imagem 8 – Tratando o retorno no caso de null.

Assim podemos evitar aqueles bugs bobos e indesejados que podem nos trazer muita dor de cabeça, pois quando eles ocorrem, são nos piores momentos.

É possível também configurar a verificação de tipos nulos para todo o projeto, para isso é preciso adicionar a linha destacada no arquivo “.csproj”, conforme a imagem 9.

Imagem 9 – Adicionando a linha de configuração para o projeto inteiro.

O operador “!”

Este operador serve para dizer ao compilador que você tem certeza do que está fazendo. O que isso significa? Significa que quando você receber um alerta de uma possível “desreferência” – situação em que o retorno poderá ser null e sem um tratamento adequado – e você quiser inibir este alerta, basta colocar o operador “!” – sem aspas – imediatamente após a propriedade e/ou campo que retornará o valor.

Imagem 10 – Inibindo alertas.

Lembre-se que maiores poderes carregam consigo maiores responsabilidades!

Padrão
Técnicas

Retry pattern

Cada vez mais a web se torna uma plataforma de serviços ao passo que necessitamos estar conectados para que possamos fazer o uso destes. A grande maioria dos serviços hoje são hospedados na nuvem e a comunicação entre a aplicação e o serviço é extremamente crítica neste cenário. Os servidores que oferecem serviços de nuvem são servidores de alta disponibilidade e robustos o suficiente para minimizar ao máximo uma possível paralisação. Porém o caminho até um servidor pode não ser tão estável assim, visto que há outros recursos durante o percurso que podem impactar a utilização de um serviço, como infra interna da empresa e a operadora por exemplo.  Diante deste cenário, cada vez mais é exigido que as aplicações consigam lidar com esta instabilidade e garantam uma responsividade (capacidade de dar repostas) aceitável num cenário que pode ser imprevisível. 

 

Contexto 

Existem certos tipos de erros em uma aplicação que são momentâneos, são chamados erros Transientes. Estes erros, ou falhas, como ficar melhor, são devido a diversos fatores externos à aplicação e que muitas vezes não são previstos no desenvolvimento. Se um serviço torna-se indisponível por um certo tempo, a aplicação deveria saber tratar este problema. É comum fazer o acesso aos serviços dentro de um bloco Try catch para tratar uma possível falha. Porém, como já vimos, existem erros que são momentâneos, e nesse caso uma nova tentativa teria grande chance de obter sucesso. Simplesmente “empacotar” uma chamada de um serviço dentro de um bloco Try catch apenas impede o erro de “quebrar” a aplicação e uma abordagem mais reativa cairia bem nesses cenários. 

O padrão conhecido como Retry Pattern vem ao encontro dessa abordagem e permite que a aplicação converse com os serviços de uma forma mais responsiva num cenário de instabilidades.  

Para implementar esse padrão, deve-se levar em consideração a natureza da falha em questão, pois nem sempre tentar novamente é o procedimento apropriado naquele momento. Podem haver casos em que simplesmente abortar a operação é o mais indicado.  Para identificarmos qual será a abordagem a ser seguida, vamos considerar o seguinte: 

  • Falhas que indicam não ser transitórias: falhas na autenticação ou dados inconsistentes por exemplo, devem ser abortadas após uma tentativa malsucedida, pois reenviar a mesma solicitação provavelmente não implicará num retorno bem-sucedido. 
  • Falhas pouco comuns ou raras: em situações como esta, onde a falha ocorrida é incomum ou raramente acontece, tentar novamente é uma boa abordagem, pois é muito pouco provável que esta volte a ocorrer em uma nova tentativa, dada sua natureza rara. 
  • Falhas recorrentes (problemas de conexão ou ocupado): essas são falhas em que uma nova tentativa provavelmente resultará em um retorno bem-sucedido, isso porque esses tipos de problemas são instabilidades momentâneas e por serem de natureza esporádica, a chance de sucesso aumenta muito em uma nova tentativa. 

 

Use com parcimônia 

Se o problema por exemplo for relacionado a uma sobrecarga no servidor, fazer uma nova chamada pode agravar ainda mais a situação. Isso fará com que o servidor leve mais tempo para normalizar seu funcionamento. Então como lidar com essas situações? O Gmail implementa uma forma bem interessante de resolver isso, se você estiver off-line e tentar atualizar seus e-mails, suas tentativas terão intervalos cada vez maiores. Essa abordagem de intervalos maiores ou exponenciais permite que outras requisições sejam finalizadas antes de um nova tentativa, garantindo assim que o servidor não seja sobrecarregado por inúmeras requisições em um curto espaço de tempo. Não esqueçamos também de sermos cuidadosos com a quantidade de vezes que essa requisição será solicitada, até que atinja um limite. Limites altos, podem fazer com que a aplicação sobrecarregue ainda mais o servidor que ainda não restabeleceu o serviço, acarretando em um problema ainda maior. 

 

Modelo de implementação 

O modelo consiste em tentativas sucessivas de requisições em caso de falha. O diagrama abaixo mostra o fluxo das requisições. 

RetryPatternImage

 

Exemplo 

O exemplo abaixo faz o download do conteúdo de uma página e retorna a string correspondente à estrutura da página. Foram utilizadas as rotinas assíncronas do .NET (async e await), porém isso não se faz obrigatório. Existem diversas formas de implementar esse padrão, inclusive existem bibliotecas prontas para isso, um bom exemplo é a Polly.  

Obs.: Tratamentos na saída do resultado foram desconsiderados.

 

    class Program
    {
        private static int _maxTentativas = 3;
        private static readonly TimeSpan _delay = TimeSpan.FromSeconds(5);

        public static string DownloadContentFromWeb()
        {
            var client = new WebClient();
            return client.DownloadString("http://www.microsoft.com");
        }

        public static async Task<string> DownloadContentFromWebWithRetry()
        {
            int _tentativaAtual = 0;
            var client = new WebClient();
            var conteudo = string.Empty;

            for (; ; )
            {
                try
                {
                    conteudo = await client.DownloadStringTaskAsync("http://www.microsoft.com.br");
                    break;
                }
                catch (Exception ex)
                {
                    Trace.TraceError(ex.Message);
                    _tentativaAtual++;

                    if (_tentativaAtual > _maxTentativas)
                    {
                        throw;
                    }
                }
                await Task.Delay(_delay);
            }
            return conteudo;
        }

        static void Main(string[] args)
        {
            Console.WriteLine(DownloadContentFromWebWithRetry().Result);
            Console.ReadKey();
        }
    }
}

 

O código acima define alguns valores inciais como número máximo de tentativas e o tempo de espera entre cada tentativa. Todo o processamento ocorre dentro de uma estrutura de repetição for. Se o resultado chegar na primeira tentativa, o comando break interrompe o laço e retorna o valor, do contrário, este cairá na captura da exceção, incrementa a variável que controla a tentativa atual e em seguida verifica se o número máximo de tentativas foi atingido. Se ainda não foi, a task aguarda o delay para a próxima tentativa.  

É um processo bem simples que mostra uma forma resiliente de deixar uma aplicação mais responsiva na hora de lidar com possíveis falhas que possam vir a ocorrer. 

Fonte: Microsoft Docs 

 

Padrão
Técnicas

Conhecendo a filosofia de codificar da NASA

O conteúdo deste artigo é uma tradução do original escrito por Abner Coimbre que pode ser conferido aqui. Ao final do texto há mais referências sobre ele bem como seus contatos. O texto traz algumas premissas utilizadas pela NASA no desenvolvimento dos seus softwares e na sequência algumas considerações do próprio autor sobre o mundo do desenvolvimento de softwares

Desde já agradeço ao Abner por ter permitido esta tradução.

Nearly an hour after launch, contrails from the lift-off of US space shuttle Atlantis float above the Vechicle Assembly building 08 June, 2007 at the Kennedy Space Center in Florida. The shuttle is on an 11-day mission to the International Space Station. (Photo credit should read TIM SLOAN/AFP/Getty Images)

O Mundo do software moderno

Existe um tema recorrente na comunidade de desenvolvimento que está associado a encontrar “melhores formas” de escrever “software moderno”.  Se o termo “moderno” é ou não realmente útil – programação de computadores é relativamente nova –  eu definitivamente sigo com a impressão de que sempre há algo novo ou melhor para falar. Então, se nós prestarmos atenção nos temas abordados no desenvolvimento de software hoje, rapidamente perceberemos o quão importante é separar o joio do trigo: o que é útil e o que não é.

Dada toda essa conversa sobre software moderno, eu tenho visto programadores iniciantes perguntando o que eu penso ser a questão mais importante das suas carreiras: “No que devemos prestar atenção?”, e honestamente, é um pouco cruel encorajá-los a seguir com:

  • POO deve ser o futuro da programação?
  • Vamos nos juntar ao Rust Evangelism StrikeForce
  • Go é muito melhor que qualquer <language_with_other_design_goals>?

Pelo menos, não é assim que a NASA se posicionou para responder quando esta pergunta foi feita. A história da agência é bem conhecida, sabemos que o programa espacial pode sofrer consequências irreversíveis se alguns dos seus softwares tiver problemas, podendo ser fatal. O choque de realidade permitiu-lhes desenvolver certas atitudes a respeito do seu modelo de desenvolvimento. Vale a pena conferir o que eles têm valorizado.

Com alguns anos de trabalho lá, gostaria de apresentar em primeira mão a filosofia de trabalho que permitiu a agência espacial produzir alguns dos softwares mais confiáveis do mundo e irei elencar suas atitudes em relação a programação num conjunto de quatro premissas que eles praticam na sua força de trabalho (e que eu vivenciei diretamente).

 

As quatro premissas da NASA 

  • Você terá acesso a um mentor.

Quem é seu mentor? É um quebra gelo comum com qualquer programador da NASA graças ao seu compromisso de garantir que todo programador possa ter um mentor. Isto poderia ser no nível de negócios, com o programa OSBP’s Mentor-Protégé, com o projeto interno NEXT ou com o Pathways Agency Cross-Center Connection (PAXC). Curiosamente, você não precisará sair procurando por um porque todos nós temos nossos mentores pessoais desde o início. A ideia de que um programador não pode ter alguém com uma experiência sênior para acompanhar seu progresso é descartada no programa espacial.

 

  • Nós confiamos no potencial de cada um

Existe um razoável grau de confiança quando você entra em uma equipe, devido as investigações de antecedentes a que você é submetido. Também assumimos que cada um tem algum valor para oferecer e nós confiamos no potencial do indivíduo. Mostre que você é bom e o título se torna quase sem sentido. Não é incomum um estagiário contribuir com projetos de software de alto nível da NASA.

 

  • Você dirá “Eu não entendo”

Esta declaração é dita a todo momento. Você verá desenvolvedores experientes perguntando para estagiários “Eu não entendo essa parte do código, é um novo recurso da linguagem que eu ainda não conheço? ” ou gerentes perguntando para engenheiros “Eu não tenho certeza das implicações do seu trabalho neste momento. Poderíamos rever mais algumas vezes até que eu tenha uma boa ideia disso? ” Estas são questões que fazem parte da rotina de trabalho.

 

  • Nós valorizamos Insights sobre como os sistemas computacionais funcionam

A NASA procura incessantemente por novas descobertas sobre os o funcionamento dos computadores, o valor desta procura está em conhecer as limitações dos sistemas para prevenir decisões ruins no desenvolvimento de softwares.

Considere Gene Amdahl. Ele foi um dos pioneiros da computação com uma interessante questão: Qual é a eficácia de melhorar um componente de um sistema? Digamos que 50% do tempo de execução do seu programa foi melhorado por apenas um fator dos quatro existentes e agora queremos saber o quão rápido a aplicação está. Em outras palavras, algo consumiu o tempo T1 para executar até o fim, agora uma parte desse algo (que consumiu uma fração f de T1) é k vezes mais rápida. Pouparei de você alguns cálculos, embora seja muito simples – definir o novo tempo T2 e expressar a melhora relativa de performance como uma razão de T1 e T2. Você terá a seguinte equação:

Al1

Continuando com o exemplo anterior para saber o quão rápido sua aplicação está,vamos aplicar na fórmula:

Al2

 

O resultado é 1,6. Embora você tenha otimizado para ser quatro vezes mais rápido, no geral o sistema é somente 1,6 X mais rápido. Vamos ainda mais longe. Digamos que você melhorou algum outro componente e o tempo que este leva para rodar é agora zero (k tende ao infinito). Você agora tem um tipo especial da lei de Amdahl.

Al3

 

Suponha que o componente responda por 60% do tempo de execução do seu sistema, e agora não consome tempo algum para executar. A velocidade máxima teórica é de 2,5… a lei de Amdahl nos diz que para melhorar significantemente a velocidade de execução, teremos que melhorar uma grande fração disso. Pura verdade, mas facilmente esquecida. A lei é usada frequentemente na computação paralela para prever acelerações utilizando processadores de vários núcleos e Julian Browne reformulou ela no seguinte contexto: “Essencialmente a lei afirma que enquanto um processador pode trabalhar com fluxos que podem então rodar em paralelo, o tempo tomado pelo processo inteiro será significativamente limitado pelos fluxos que restam sequencialmente”. Ver Artigo sobre a Lei.

 

Com estas suposições em mente, o resto do artigo fornece uma visão mais pessoal sobre as lições que poderiam ser aprendidas.

  

Evitar fontes de conhecimentos duvidosas

Alguns dos meus amigos concordam que a atividade de programar ainda precisa amadurecer, pois ela estaria no estágio pré-científico da sua existência. Eu diria que muitos de nós estamos aderindo subconscientemente a fontes tradicionais de conhecimento que tem se provado duvidosas, e posso dizer que a NASA tem feito um bom trabalho para se proteger contra isso.

 

Eu não quero dizer fé no sentido de esperança. Fé também é compreendida quando nós queremos acreditar em algo sem que tenhamos bons motivos para acreditar. Vejamos um exemplo:

 

Lead: “Gosto das novas funcionalidades das aplicações para nossos usuários, mas você disse que baixou uma biblioteca para escreve-las. ”

 

Junior: “Sim. Funcionaram muito bem. ”

 

Lead: É código aberto? De qualquer modo, quem é o fornecedor e como é o suporte que eles oferecem?

 

Junior: “Não é, mas eu tenho usado ela e por enquanto não tive nenhum problema. ”

 

Lead: *PLONK*

 

Isto acontece não apenas para downloads aleatórios, mas quando seu código não estava funcionando e então magicamente ele funcionou e você resolve utiliza-lo um dia. Pode ser difícil perceber quando alguém está confiando na fé para decidir o quão bom é o seu software, mas se isso se prolongar por muito tempo, o resultado será um software lento de cheio de bugs.

 

Revelação

Por revelação, quero dizer quando uma figura de autoridade revela algo como incontestavelmente verdadeiro, ou algum fato que tem sido transmitido até hoje, e você acredita ser verdade simplesmente porque se acredita ser verdade. Se você associar isso com a necessidade de as pessoas se identificarem com algum assunto aleatório da comunidade de programação, vai descobrir que essa é a causa raiz de discussões calorosas sobre qual editor de textos reina supremo e se a linguagem que usa faz de você um verdadeiro programador.

 

Carisma

A conferência está repleta com uma atmosfera de euforia, empolgação para o anúncio do que virá a ser o próximo framework. Um palestrante empolgado chega ao palco com uma voz altissonante.  A fala e os slides discorrem sobre os mais novos princípios que prometem práticas de programação a prova de balas – do tipo que fará de você um programador 10X melhor. Com uma habilidade natural para interagir com a plateia e conduzir muito bem o tema da palestra, pode ser difícil de perceber que passamos a acreditar em suas afirmações, e o mais importante, comprando seus livros.

 

Brilho

Percebo que esta é uma palavra estranha para usar, mas quando uma ideia é atraente e empolgante o suficiente isto parece dar um certo “brilho”.  É “brilhante” e, portanto, deve ser verdadeiro. Poderíamos continuar, mas afastar-se desse tipo de desejo (ou sentimento) é o que significa ser científico sobre o nosso progresso tecnológico.

 

Expanda seus conhecimentos na área

Uma conversa sobre a natureza do universo geralmente é mais interessante quando as pessoas envolvidas são pessoas cientificamente alfabetizadas. Igualmente, uma conversa sobre programação beneficia a todos elevando a um certo patamar os seus conhecimentos. De fato, existem conhecimentos já bem difundidos sendo utilizado em novos sistemas computacionais, e os programadores deveriam estar atentos a isso.  Se nos intitulamos profissionais, temos uma grande responsabilidade em aprender os conceitos fundamentais da computação. Isso nos protege de fontes de informação não confiáveis e nos mostra aquilo de devemos prestar atenção. A NASA percebeu isso e garantiu que a cultura da organização seja capaz de expandir rapidamente seus conhecimentos.

 

Recomendações

Alguma coisa lhe chamou a atenção? Você é um programador procurando melhorar seus conhecimentos? Se for, eu tenho algumas sugestões pessoais.

Computer System’s: A Programmer’s Perspective: Foi muito importante na minha carreira, e para constar, este é meu conteúdo favorito de programação. Os temas apresentados aqui são os fundamentos que eu acho que todos deveriam ter. Pelo menos um estudo mais aprofundado dos capítulos 1-3, a hierarquia de memória e os sistemas de entrada e saída são excelentes. Se você está trabalhando em qualquer coisa relacionada a web, é claro que o capítulo sobre redes é de extrema importância.

Encontrando pessoas com o mesmo interesse

Existe uma pequena comunidade chamada Handmade Network, essa comunidade possui um time incrível (eu faço parte do time) onde tentamos construir um lugar em que evitamos conversar sobre softwares modernos, em vez disso, falamos sobre coisas que eu citei aqui. Assim como em qualquer comunidade, somos passíveis de cair em um dogma (já aconteceu no passado) mas estamos cientes disso.

Na comunidade também há entrevistas com programadores conhecidos discutindo diversos assuntos independentemente de nossas ideias. Confira algumas aqui.

 

Blogs/sites relacionados:

 

Abner Coimbre foi um estagiário do Kennedy Space Center no ano de 2015 e no ano de 2016 foi nomeado como Kennedy’s 2016 top 10 innovators. Onde encontra-lo: TwitterTwitch ou e-mail.

Padrão
.NET, Banco de Dados, Certificação, Dica de leitura, Mova-se, Técnicas, Visual Studio

Certificações Microsoft – Por onde começo?

Olá pessoal, o objetivo desse post é esclarecer um pouco mais sobre a nova linha de certificações Microsoft, e também ajudar a direcionar aquele profissional que pretende obter uma certificação mas não sabe por onde começar.

A Microsoft criou uma linha de certificações chamada MTA – Microsoft Technology Associate. Essas provas são a “base da pirâmide” para uma carreira nas tecnologias Microsoft. O objetivo dessas provas são fornecer um conhecimento sólido dos fundamentos na tecnologia em que você pretende se especializar. Fazendo uma prova MTA, você já é um MTA Certification e já possui os conhecimentos fundamentais para seguir em frente.

Dentro do nível MTA, o profissional deve escolher qual área pretende seguir carreira, podendo optar por uma das três áreas conforme figura 1.

Áreas Microsoft

Figura 1 – Áreas na plataforma Microsoft

Mais detalhes: http://www.microsoft.com/learning/en-us/mta-certification.aspx

Como já sabemos o nível MTA visa garantir o conhecimento necessário para as outras provas (MCSD e MCSA ou quem sabe um dia MCM), então essa prova é obrigatória? Não, você não precisa se tornar um MTA para fazer as outras provas. Se você já é um profissional que tem experiência na sua tecnologia, então você pode pular esse nível. Porém se você está começando agora, certamente esse é o seu ponto de partida na carreira.

Em resumo, agora temos o nível MTA (de cada área) para iniciar, e a partir desse nível, cada um escolhe a carreira que pretende seguir. Para compreender melhor como ficou o RoadMap das provas vamos ver a figura 2.

Provas Microsoft

Clique para Download em PDF.

Figura 2 – RoadMap das provas

Existem dois centros de testes que você pode agendar a sua prova, Certiport para quem é estudante e Prometric para quem não possui nenhum vínculo acadêmico. Para o caso dos estudantes, é necessário verificar se a sua instituição está registrada no Certiport, verifique com seu professor ou chefe do departamento.

Um caminho para aprender e ajudar na preparação para as provas no nível MTA é através do Microsoft Virtual Academy que oferece diversos treinamentos gratuitos para desenvolvedores, profissionais de infra e banco de dados.

Lembrando que o mercado está carente de profissionais qualificados, enquanto sobram ideias, planos de marketing, investimentos dos mais variados, profissionais com uma boa qualificação ainda são uma pequena parcela do mercado, portanto uma certificação será muito bem vinda!

 Abraços!

Padrão
.NET, Boas Práticas, Técnicas

String VS StringBuilder – O Coiote não pega o Papa Léguas!

O título desse post remete a dois personagens bem conhecidos de todos (principalmente das crianças) em que um deles sempre tenta capturar o outro, porém esse último é muito mais veloz e raramente se dá mal. A ideia por trás dessa analogia é que algumas vezes tentamos utilizar tipos de dados com limitações de desempenho em nossos códigos e então saímos fazendo mil coisas (“gambiarras”) para tentar se aproximar do melhor desempenho possível, nem preciso comentar o resultado final. Esse fato no leva ao problema de atualização de conhecimento, pesquisas, estudos sobre as novidades de uma linguagem e/ou uma ferramenta. Aquela famosa frase “Para quem só conhece o martelo como ferramenta, parafuso é prego” cabe perfeitamente aqui.
Quando precisamos trabalhar com strings, o primeiro tipo que vem a mente é o tipo String ou string (essa última é apenas um apelido). Legal, esse é o tipo mais conhecido, e naturalmente, mais usado. Acontece que um objeto do tipo String é imutável, o que isso significa? Significa que uma vez atribuído um valor a um objeto desse tipo, esse valor jamais mudará, isso mesmo, jamais mudará. Mas então como eu consigo fazer concatenações e o novo valor é atribuído ao objeto? O que ocorre por baixo dos panos é algo que talvez você nunca imaginasse, a cada nova atribuição de valor a um objeto String, é criado um novo objeto semelhante que agora contém o valor antigo mais o valor atual. Isso mesmo, um novo objeto é criado e isso é transparente aos desenvolvedores. Você simplesmente solicita o valor do objeto e lá está ele.
No momento em que um novo objeto é criado, o objeto antigo continua na memória heap a disposição do garbage collector. A figura 1 mostra esse cenário, podemos ver que ao final das concatenações sucessivas temos um único objeto que iremos trabalhar e mais quatro objetos aguardando para serem eliminados da memória.

StringVSStringBuilderFigura 1

A cada nova iteração criamos um novo objeto e descartamos o antigo, isso causa um overhead imenso nas aplicações e um péssimo aproveitamento da memória do computador. Ma então o que devemos fazer quando precisarmos utilizar strings em iterações? A solução presente no .NET chama-se StringBuilder. Essa classe foi especialmente desenhada para trabalhar com strings dinâmicas, strings em que o valor muda constantemente e garante uma performance excelente quando recebe grande quantidade de dados. Os métodos disponíveis para trabalhar com StringBuilder fazem uma referência a mesma instância e não a uma nova como no caso da String. Vamos ver na prática como isso funciona. A figura 2 mostra dois métodos, o primeiro faz um loop de 20000 iterações utilizando um objeto StringBuilder e ao final exibe em milissegundos o tempo gasto. O segundo método faz a mesma coisa porém utilizando um objeto String.

ExemploCodigo

Figura 2

ExemploStringBuilder_2

Figura 3

Ao compararmos os resultados da figura 3, podemos concluir a enorme diferença no tempo de execução. Quando chamamos o método que utiliza String, gastamos um tempo de 2637 milissegundos e o mesmo loop utilizando StringBuilder consumiu apenas 10 milissegundos.
Então o tipo de dados String é um tipo ruim de trabalhar? A resposta é que String não é um tipo de dados ruim para trabalhar, porém ela atende exatamente aquilo que ela se propôs a atender, trabalhar com strings estáticas ou com poucas mudanças.

Abraços!

Padrão
Uncategorized

Resumo do Livro Engenharia de Software de Ian Sommerville 8ª Ed.

Segue um resumo que preparei do livro de Ian Sommerville  – Engenharia de Software 8ª Ed. Esse resumo aborda os principais tópicos dos capítulos 1 ao 7. Aproveitem! Imagem

Introdução a Eng. De Software

É um ramo da engenharia com foco no desenvolvimento de softwares dentro de custos, prazos adequados e alta qualidade. Software é abstrato, não há limitações físicas. Essa falta de limitações pode torna-lo extremamente complexo e de difícil compreensão.

O conceito de ES foi proposto em 1968 em uma conferência para discutir o que foi chamado de “crise do software”, que resultava do surgimento de novos hardwares de computadores baseados em CI’s e tornava sistemas impensáveis até então em projetos realizáveis e mais complexos que os anteriores. O desenvolvimento informal não era suficiente, atraso, não confiável, difícil de manter, baixo desempenho. Novas técnicas surgiram pois o custo do hardware caía enquanto do software aumentava. Até hoje em dia essas técnicas não são aplicadas efetivamente por muitas empresas.

O QUE É SOFTWARE?

                Além do programa executável, são todos os dados de documentação(sistema e usuário), arquivos de conf. necessários a operação do software.

Existem 2 tipos de produtos de software:

  1. Produtos genéricos: Sistemas do tipo Stand-alone e vendido no mercado para qualquer cliente;
  2. Produtos sob encomenda (ou personalizados):  Encomendado por um determinado cliente/ ou modificado para ele;

DIFERENÇAS:

Nos produtos genéricos quem controla a especificação é a empresa que desenvolve. Já nos produtos sob encomenda, essa especificação é controlada pela empresa que compra o produto.  Existe também o caso em que um produto genérico é modificado para atender um cliente específico (ERP’s como SAP).

O QUE É ENG. DE SOFT.?

É uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde a especificação até a manutenção.

Por que Disciplina? – Os engenheiros aplicam teorias métodos e ferramentas onde for apropriado e de forma seletiva mesmo quando não existem teorias e métodos aplicáveis, e fazem as coisas funcionarem.  Trabalham também sob restrições organizacionais e financeiras.

Todos os aspectos? – Porque também se relaciona com atividades do gerenciamento do projeto, desenvolvimento de ferramentas, métodos e teorias que apoiem a produção.

Em geral utiliza-se uma abordagem sistemática e organizada, mas pode ser extremamente eficaz selecionar uma abordagem alternativa e menos formal para uma determinada circunstância.

DIFERENÇA ENTRE E.S. E C.C.

A C.C. diz respeito as teorias e os métodos que formam a base para computadores e softwares. A E.S. se dedica aos problemas práticos da produção de software. Teorias mais elaboradas da C.C. nem sempre podem ser aplicadas a E.S. nos seus problemas reais e complexos.

DIFERENÇA ENTRE ENG. DE SOFTWARE E DE SISTEMAS

A Eng. Sistemas trata de todos os aspectos do desenvolvimento e da evolução de sistemas complexos. Relacionada ao desenvolvimento de hardware, políticas e processos de implantação e a própria Eng. De Soft. Mais envolvida com definição de arquitetura, integração de partes e menos envolvidos com eng. Dos componentes, hardware, software etc.   Enquanto a Eng. De Soft. se dedica aos problemas práticos da produção do software e faz parte da engenharia de sistemas.

O QUE É PROCESSO DE SOFTWARE?

É um conjunto de atividades e resultados associados que produz um produto de software(software, documentação, etc).

Atividades de processos comuns a todos os processos:

1 – Especificação: Definição do que será produzido;

2 – Desenvolvimento: Projetado e programado;

3 – Validação: Verificação se o que foi feito é o que o cliente deseja.

4 – Evolução: Adaptação as mudanças futuras e/ou melhorias;

Diferentes tipos de sistemas necessitam de diferentes tipos de desenvolvimento. Ex.: Alguns podem requerer que sejam especificados totalmente antes do desenvolvimento, para outros, essas atividades podem ocorrem em paralelo. O uso de um processo inadequado pode reduzir a qualidade ou a utilidade do produto de software a ser desenvolvido e/ou aumentando os custos de desenvolvimento.

O QUE É UM MODELO DE PROCESSO DE SOFTWARE?

É uma descrição simplificada do processo sob uma determinada visão. Os modelos incluem atividades do processo, produtos de software e os papéis das pessoas envolvidas.

A maioria dos modelos é baseada em um dos 3 modelos gerais ou paradigmas de desenvolvimento:

  • CASCATA – Fases separadas de processos. Uma fase não inicia sem que outra termine e seja aprovada.
  • DESENVOLVIMENTO ITERATIVO – Intercala as atividades. Desenvolvido rapidamente com base em especificações abstratas e depois é refinado com informações dos clientes para que possa satisfazer a necessidade desse.
  • E.S. BASEADA EM COMPONENTES – Supões que partes do sistema da já existem. Concentra-se mais na integração dessas partes do que no seu desenvolvimento a partir do início.

QUAIS SÃO OS CUSTOS DA ENG. DE SOFT.?

Não existe uma resposta simples. No modelo cascata, os custos de especificação, projeto, implementação e integração são medidos separadamente. Nesse caso, integração e testes são as atividades mais caras, entre 40 e 50% do custo total de desenvolvimento.

Na abordagem iterativa, não existe uma linha precisa entre especificação, projeto e desenvolvimento. Custos de especificação reduzidos, pois apenas uma especificação de alto nível é produzida antes do desenvolvimento, e também precisa de uma atividade de teste independente uma vez que a implementação inicial esteja completa.

A CBSE  tem sido aplicada  apenas nos últimos tempos, e sabemos que os custos de desenvolvimento são menores que os custos de integração e testes, porque é necessário assegurar que os componentes utilizados, realmente satisfazem as especificações e funcionam conforme o esperado, mas além disso não há dados precisos para os custos.

Custos também incorrem em alterações após a sua liberação para o uso. Os custos de evolução variam muito de acordo com o tipo de sistema.

Essa abordagem de custos é válida para softwares sob encomenda.  Nos produtos genéricos, há uma abordagem evolucionária, e os custos de especificação são relativamente baixos. Já os custos de testes são mais altos justamente por serem previstos para rodar em diferentes ambientes de configuração.

Os custos de evolução de produtos genéricos são relativamente difíceis de serem estimados, pois não são avaliados separadamente como nos softwares sob encomenda, mas são simplesmente custos de desenvolvimento.

O QUE SÃO MÉTODOS DE ENG. DE SOFTWARE?

                Um método é uma abordagem estruturada para o desenvolvimento de software, cujo objetivo é facilitar a produção de software de alta qualidade dentro de custos adequados. Não há um método ideal, e diferentes métodos possuem diferentes áreas onde são mais aplicáveis. Todos os métodos são baseados na ideia de modelos de desenvolvimento.

O QUE É CASE?

São ferramentas utilizadas para dar apoio as atividades do processo de software, tais como análise, modelagem, depuração e testes. Todos os métodos vêm atualmente com uma tecnologia case associada.

OQUE SÃO ATRIBUTOS DE UM BOM SOFTWARE?

Os atributos de um software refletem o comportamento do software, enquanto esse está em execução, sua estrutura e organização dos fontes bem como a documentação associada.

Alguns atributos: Facilidade de entendimento dos fontes, tempo de resposta a uma consulta. O conjunto de atributos varia de acordo com a sua aplicação. Pode-se resumir em: Facilidade de manutenção, confiança, eficiência e aceitação.

QUAIS SÃO OS DESAFIOS CHAVES DA E.S.?

Hoje a E.S. se depara com 3 desafios:

Desafio da heterogeneidade: É necessário que os sistemas de software operem com sistemas distribuídos e também com sistemas mais antigos (legados). Necessário técnicas para desenvolver sistemas flexíveis e confiáveis para adaptar-se a essa heterogeneidade.

Desafio de entrega: Muitas técnicas tradicionais demandam tempo para obter a qualidade. O desafio da entrega consiste em reduzir os tempos de entrega dos sistemas grandes e complexos sem comprometer a qualidade.

Desafio da confiança:  Os softwares estão presentes em todos os aspectos da nossa vida e precisamos confiar nele. O desafio da confiança consiste em desenvolver técnicas que demonstrem aos usuários que é possível confiar nele.

RESPONSABILIDADE PROFISSIONAL E ÉTICA

Confidencialidade: respeitar a confidencialidade de seus funcionários ou clientes independente ou não de acordo formal.

Competência: Não deve conscientemente aceitar um trabalho que esteja fora da sua competência.

Direitos sobre propriedade intelectual: Estar ciente das leis locais, patentes e assegurar que a propriedade intelectual de funcionários e clientes esteja protegida.

Mau uso de computadores: Evitar mau uso desde o trivial (como jogos por exemplo) até o mais sério (disseminação de vírus).

Baixar o Resumo no formato PDF.

Abraços!

Padrão