Robert Martin, também conhecido como Uncle Bob, um dos signatários do Manifesto Ágil, sugeriu que pessoas que desenvolvem softwares profissionalmente deveriam adotar um código de ética em sua publicação obligation of the programmer:

 

 

(…) o fato é que nós, que escrevemos software profissionalmente, estamos em uma posição de tremendo poder cujas pessoas para as quais trabalhamos não entendem bem; e que até nós mal conseguimos entender melhor.

Grande poder implica em grande responsabilidade. Nós, como profissionais que desenvolvem softwares, devemos reconhecer essa responsabilidade e entender que somos servidores conscientes de nossa sociedade. Devemos estabelecer os limites e padrões de nossa conduta. Nós, profissionais dessa área, não nossos empregadores, devemos decidir o que significa aceitar a responsabilidade e o poder que foi colocado em nossas mãos.

Nesse artigo, publicado em novembro de 2014, Martin compartilhou suas ideias iniciais de um código de ética. Ele sugeriu uma série de pontos que deveriam ser incluídos:

• Nós não causaremos mal propositalmente.
• Nosso software será bem escrito para seu propósito e tempo de vida.
• Nos comportamos com honra e disciplina.

O artigo sugere um juramento para profissionais que programam baseado na obrigação da Order of the Engineer (organização norte americana para fomentar o espírito de orgulho e responsabilidade na profissão de engenharia).

Nils Löwe escreveu sobre a responsabilidade das pessoas que desenvolvem software em construir software de boa qualidade e confiável.

Aprendemos muito sobre a construção de software confiável e de boa qualidade nas décadas passadas. A crise do software nos mostrou nossos limites técnicos e, como bons profissionais da engenharia de software, inventamos processos e métodos para dominar aquela complexidade. Infelizmente, esquecemos de olhar além dos desafios técnicos e reconhecer nossa crescente responsabilidade.

Nós, pessoas que desenvolvem software, acumulamos uma enorme quantidade de influência em um período relativamente curto. Entretanto, tivemos apenas esse curto período de tempo para encarar a responsabilidade se desenvolvendo a partir dessa influência.

No seu artigo, Löwe refere-se ao seu Manifesto of Responsible Software Development (Manifesto de Desenvolvimento Responsável de Software), que tem como objetivo encorajar reflexões e debates sobre as responsabilidades das pessoas que atuam no desenvolvimento de soluções de software.

Em novembro de 2015, Robert Martin publicou o Programmer’s Oath (Juramento do Programador). Seu juramento objetiva “defender e preservar a honra da profissão de quem programa computadores”. O juramento começa com:

1. Eu não produzirei código nocivo.
2. O código que eu produzir será sempre meu melhor trabalho. Eu não permitirei, conscientemente, a acumulação de código defeituoso, seja no seu comportamento, ou na sua estrutura.
3. Eu produzirei, a cada liberação, uma rápida, correta e repetível prova de que todos os elementos do código funcionam como devem.
4. (…)

No artigo the code that I’m still ashamed of (O código do qual ainda me envergonho) em FreeCodeCamp, Bill Sourour conta sua história sobre escrever software para um questionário online que recomendava um medicamento. Embora o website sobre no qual ele trabalhava afirmasse ser um site de informações gerais sobre medicamentos, o requisito do cliente era sempre propor o remédio desses clientes. No final desse artigo ele conclui:

Como profissionais do desenvolvimento de software, somos com frequência a última linha de defesa contra práticas potencialmente perigosas e antiéticas.

Quanto mais o software continuar a assumir o controle de todos os aspectos de nossas vidas, o mais importante para nós será tomar uma posição e garantir que nossa ética esteja sempre presente em nosso programa.

Martin fez o keynote de abertura “The Scribe’s Oath” no Agile Summit Greece 2017. A cúpula é um uma conferência de um dia, para pessoas que programam, lideranças de equipes, pessoas da gestão e alta gestão, que ocorreu em Atenas, em 22 de setembro. O InfoQ cobriu essa conferência com Q/As, sumários, e artigos.

O InfoQ entrevistou Martin sobre a necessidade de um juramento para profissionais do desenvolvimento de software, que objetivos atingir, e como obrigar seu cumprimento.

InfoQ: Porque precisamos de um juramento para essas pessoas que programam profissionalmente?

Robert Martin: Nossa civilização veio a depender do software, muito mais do que muitas pessoas, incluindo a maioria das pessoas que desenvolvem os softwares, percebem. Hoje em dia, vidas e fortunas dependem da construção e execução corretas de programas. Sempre que vidas e fortunas estão em jogo, nossa sociedade exige um compromisso com a conduta profissional. Um juramento é apenas uma declaração desse compromisso.

InfoQ: Você publicou o juramento do programador em 2015. Como as pessoas reagiram?

Martin: Muitas pessoas estavam entusiasmadas a respeito. Outras pensaram que era bobagem. Eu penso que a reação não o que realmente importa. O que importa é o que uma pessoa leiga pensa sobre isso e, por extensão, o que os legisladores pensam a respeito. No final, será o cidadão normal que exigirá o compromisso com a conduta profissional; e exigirá que essa conduta seja monitorada e obrigatória.

InfoQ: O juramento começa com “Eu não produzirei código nocivo”. Você pode explicar isso melhor?

Martin: Existem dois tipos de danos que uma pessoa que desenvolve um software pode causar a quem utilizar sua solução. O primeiro é o mais óbvio: o software pode falhar. Parece ser perfeitamente razoável que prometamos fazer o máximo para entregar programas que não falhem.

O segundo tipo de dano que essas pessoas rotineiramente causam às pessoas que utilizam a solução é danificar a estrutura do software. Quem utiliza, espera que programas sejam fáceis de alterar. Afinal de contas é “soft” ware. Quem utiliza os softwares precisa que seus sistemas mantenham o ritmo da rápida mudança na sociedade e na tecnologia. Parece perfeitamente razoável a promessa que daremos nosso máximo para manter o software “soft” (maleável, manutenível).

InfoQ: O juramento também sugere que as pessoas que desenvolvem sistemas devam fazer tudo que puderem para manter a alta produtividade. Como elas podem fazer isso e continuar entregando boa qualidade?

Ah, essa é uma pergunta complicada. Mantendo a alta qualidade é como mantemos a alta produtividade. A ideia que qualidade e produtividade são inversamente proporcionais é a grande mentira que temos contado para nós mesmos ao longo dos anos.

Toda pessoa que atua com programação teve a experiência de ser significativamente prejudicada por código mal estruturado e emaranhado. Aquele programa foi “fácil” de escrever, mas deixou o sistema em um estado que atrasa a todos. Quanto mais lentamente os demais avançam, mais pressionados se sentem para tomar atalhos que deixam o sistema ainda em pior estado. Sendo assim, todo o projeto é atrasado até que inexoravelmente a produtividade seja zero.

Repita comigo: “A única maneira de ir rápido, é ir bem.”

 

InfoQ: Obrigar um juramento é a melhor coisa a fazer? Como isso pode ser feito?

Martin: Por fim, tal obrigatoriedade será pelo registro das pessoas em uma associação profissional. Empresas contratarão apenas pessoas associadas com boa posição (possivelmente pela lei). O registro pode ser revogado por escandalosas violações do código de conduta da associação profissional.

Eu não conheço esforço algum para se fazer algo assim; entretanto, considero inevitável.

Fonte: InfoQ

Este livro, escrito em 2002, é hoje uma das referências no assunto, escrito pelo próprio pai da metodologia Kent Beck o livro apresenta a técnica de uma forma bem prática, mostrando alguns exemplos e uma série de técnicas e padrões muito úteis para melhor aplicação do TDD.

O livro está dividido em três partes. Na parte 1 – O Exemplo Financeiro – ele mostra um exemplo prático de um modelo que trabalhe com multi-moedas, ou seja, que seja capaz, por exemplo, de somar cinco dólares com dez francos e retornar o total em dólares.

Sempre começando pelos testes, o autor cria classes Dolar e Franco, implementa métodos de soma e multiplicação e assim por diante. E, é claro, ao longo de todo o livro ele vai explicando a técnica, o ciclo red-green-refactor, como fazer o teste passar (green) o mais rápido possível, etc.

Na parte 2 – O Exemplo xUnit – mais um exemplo. Desta vez, ele fala sobre framework de teste no padrão xUnit. Mais do que isso, ele explica a arquitetura xUnit, escrevendo um framework de teste usando TDD. Isso mesmo, TDD para construir um framework de teste! Muito louco rs.

A parte 3 – Padrões para Desenvolvimento Guiado por Testes – é a mais teórica. Ela mostra os padrões adotados no TDD. Ao longo da parte 3, são mostradas técnicas, sempre na base do pergunta-resposta, ou seja, cada tópico ele começa por uma pergunta (“como faço tal coisa?”) e o tópico dá a solução ou dica (padrão parecido pelo usado na série  Use a Cabeça). Também nesta parte, são mostrados vários padrões de projeto e técnicas de Refactoring.

Posso dizer que este é um ótimo livro para quem quer ingressar no desenvolvimento orientado a testes. É um livro pequeno (cerca de 220 páginas), de fácil leitura e com um conteúdo muito bom.

Desenvolver aplicações e softwares exige cuidado na hora de criar um código para que ele não seja apenas funcional, mas também seguro. O fato é que algumas coisas podem passar batidas ou, então, se tornar um problema depois de algum tempo. Para evitar problemas maiores é que existe o code review, responsável por identificar e prevenir vulnerabilidades diversas. Para ter um ambiente realmente seguro, conheça a seguir algumas boas práticas de code review.

Como é feito o code review?

O code review é feito baseando-se em uma análise minuciosa do código de uma aplicação, software ou solução digital em geral. Essa revisão busca não apenas erros, mas também falhas que possam ser exploradas por potenciais invasores.

Essa atuação é como procurar por portas abertas dentro do código de modo a identificá-las e saber como fechá-las. Ao fazer isso, o código se torna menos vulnerável, o que faz com que o ambiente seja mais seguro.

Esse tipo de revisão de código também pode ser utilizado para criar otimizações de uso da solução computacional, como a mudança de um parâmetro para tornar o uso mais fácil, por exemplo.

Por que esse processo é fundamental?

Essa revisão não serve apenas para corrigir o que está errado ou o que está vulnerável. Se for feita da maneira correta, ela também possui um caráter preventivo.

Esse processo é fundamental no desenvolvimento de aplicações justamente por ser um dos responsáveis pela criação de um ambiente realmente seguro. Sem o code review, um código, por mais correto que esteja, pode se tornar vulnerável em pouco tempo ou já ser lançado com falhas de vulnerabilidade.

Quais as boas práticas de code review?

Somente ler o código mais de uma vez não é o bastante para garantir a segurança desejada e por isso é que essa revisão possui algumas boas práticas. Quando elas são seguidas, o processo se torna mais eficiente e mais acertado e, dentre essas práticas, estão:

INCORPORAR AUTOMATIZAÇÃO AO TRABALHO MANUAL

É verdade que a análise de um código muitas vezes é uma tarefa subjetiva, já que passa por todo um processo decisório. Isso não significa, entretanto, que a automação seja totalmente dispensável nesse caso.

Na verdade, ao mesclar automatização e trabalho manual o processo de code review se torna mais rápido e mais relevante, já que diminuem as falhas humanas. No geral, essa incorporação pode ser feita com a definição de busca automática de algumas falhas já conhecidas ou de padrões que indiquem uma vulnerabilidade, por exemplo.

USAR CHECKLISTS

Fazer code review é como fazer uma busca: se você não souber pelo que está procurando, é provável que você não encontre. Por isso, uma boa prática consiste em criar checklists que serão usadas para guiar a revisão de código. Pode ser o caso de fazer uma lista com a verificação da autenticação, da encriptação de dados, de vulnerabilidades anteriores e mais.

REALIZAR A CADA MUDANÇA DE CÓDIGO

As práticas de code review também devem acontecer sempre que o código for modificado, ainda que a mudança pareça pequena. Em ciclos iterativos, uma pequena mudança pode causar impactos em série e gerar vulnerabilidades imprevistas. Por isso, é preciso fazer uma revisão de código a cada mudança que for feita.

CONHECER O FUNCIONAMENTO DE NOVAS AMEAÇAS

De acordo com o que você já conhece previamente pode ser que o código esteja totalmente seguro. Novas ameaças, entretanto, podem explorar vulnerabilidades que antes não eram consideradas, o que torna seu ambiente inseguro.

Por isso, uma boa prática de code review é também manter-se atualizado a como agem as novas ameaças para buscar essas novas vulnerabilidades no seu código.

As práticas de code review é importante para garantir que o código esteja livre de vulnerabilidades, fazendo com que o ambiente fique livre de ameaças. Para garantir isso, as boas práticas incluem o uso moderado da automação, de checklists, a revisão a cada mudança e também o conhecimento sobre novas ameaças.

Há uma a história antiga sobre qualidade de software. Um empresario muito rico tinha uma casa bela e cheia de relíquias de valor inestimável, objetos de arte e assim por diante. Um dia, uma tapeçaria pendurada próxima da lareira de sua sala de estar pegou fogo. O corpo de bombeiros se apressou para salvar o dia. Mas antes de arrastarem suas mangueiras grandes e sujas para dentro da casa, eles pararam – com o fogo ainda enfurecido – para desenrolar uma esteira entre a porta da frente e o ponto de origem do fogo. Eles não queriam estragar o carpete.

Um caso bastante extremo, claro, mas é assim que deveria ser com o desenvolvimento de software. Uma janela quebrada – um trecho de código mal projetado, ou uma decisão insatisfatória durante a existência do projeto – é o que falta para começar o declínio. Se você perceber que está trabalhando em um projeto com algumas janelas quebradas, não vai ser difícil começar a pensar da forma padrão “Todo o resto desse código está perdido. Vou me resignar e segui-lo”. Não importa se o projeto vinha se saindo bem até esse ponto. Na experiência original que levou à “Teoria da Janela Quebrada”, um carro abandonado no condomínio que moro permaneceu meses intocado. Mas quando apenas uma janela foi quebrada, o carro foi destruído em dias.

Da mesma forma, se você perceber que está em uma equipe e em um projeto no qual o código se encontra em estado imaculadamente adequado – escrito apropriadamente, bem projetado e elegante – provavelmente vai tomar um cuidado especial para não danificá-lo, assim como os bombeiros. Mesmo se houver um incêndio ocorrendo (prazo, data de lançamento, demonstração para clientes), você não vai querer ser o primeiro a causar danos.

 

Embora o desenvolvimento de software esteja imune a quase todas as leis da física, a entropia nos afeta muito. Entropia é um termo da física que se refere ao nível de “desordem” em um sistema. Infelizmente, as leis da termodinâmica garantem que a entropia no universo tende em direção ao máximo. Quando a desordem aumenta no software, os programadores chamam isso de “deterioração de software”. Há muitos fatores que podem contribuir para a deterioração de software. O mais importante parece ser a psicologia, ou cultura, em ação em um projeto. Mesmo se você for uma equipe de uma pessoa, a psicologia que envolve seu projeto pode ser algo muito delicado. Mesmo se um projeto tiver grandes planos elaborados e as melhores pessoas, ele ainda pode vivenciar a ruína e a decadência durante seu tempo de vida. No entanto, há outros projetos que, apesar das enormes dificuldades e constantes retrocessos, combatem com sucesso a tendência natural em direção à desordem e conseguem se sair muito bem. O que causa a diferença? Em cidades do interior, alguns prédios são belos e limpos, enquanto outros são estruturas deterioradas. Por quê? Pesquisadores da área criminal e de decadência urbana descobriram um fascinante mecanismo acionador, um mecanismo que torna muito rapidamente um prédio limpo, intacto e habitado em uma construção quebrada e abandonada: uma janela quebrada.

Uma janela quebrada, deixada sem reparos por qualquer período de tempo significativo, faz brotar nos moradores do prédio uma sensação de abandono – uma sensação de que os responsáveis não se preocupam com o prédio. Portanto, outra janela é quebrada. As pessoas começam a acumular lixo na área externa. Surgem grafites. Danos estruturais graves começam a aparecer. Em um período de tempo relativamente curto, o prédio fica danificado demais para o proprietário querer consertá-lo e a sensação de abandono se torna realidade. A “Teoria da Janela Quebrada” inspirou os departamentos de polícia de Nova York e outras cidades grandes a atacar os problemas menores para evitar os maiores. Funciona: ficar atento a janelas quebradas, grafites e outras pequenas infrações reduziu o alto índice criminal.

Não deixe “janelas quebradas” (projetos insatisfatórios, decisões erradas ou código inadequado) sem reparos. Conserte cada uma assim que for descoberta. Se não houver tempo suficiente para consertá-la apropriadamente, feche-a com tábuas. Talvez você possa desativar com comentários o código inadequado, exibir uma mensagem “Não Implementado” ou substituí-lo por dados fictícios. Tome alguma medida para impedir um dano maior e mostrar que você está com a situação sob controle. Vimos sistemas elegantes e funcionais se deteriorarem rapidamente quando as janelas começaram a quebrar. Há outros fatores que podem contribuir para a deterioração de software e mencionaremos alguns deles em outras seções, mas a negligência acelera mais a deterioração do que qualquer outro fator. Você deve estar pensando que ninguém tem tempo para sair reparando todas as janelas quebradas de um projeto. Se continuar pensando assim, é melhor planejar a compra de uma caçamba ou mudar para outra vizinhança. Não deixe a entropia vencer.

Os padrões de projetos foram criados originalmente pelo GOF (Gang of Four) que catalogou 23 padrões de projetos.  Fora estes, existem outros padrões de projetos documentados por outros profissionais, associações e empresas.  Dentro dos 23 padrões de projetos do GOF temos aqueles que são mais utilizados em projetos no dia-a-dia, entre eles podemos citar:  Singleton, Factory, Abstract Factory, Composite, Prototype, Proxy. Há outros que embora não muito utilizados que  merecem destaque pelos problemas que resolvem, por exemplo, Template Metody, Facade e Builder.

Futuramente pretendo escrever uma série de artigos explicando cada um dos principais padrões.

Livro do GOF – Leitura obrigatória

O objetivo será dar uma introdução a vocês e como implementar alguns desses padrões. Padrões de projetos são boas práticas, são soluções reutilizáveis para serem aplicadas em todo e qualquer projeto de software que seja orientado a objeto, independente da linguagem.  Com padrões, você aplica a solução descrita pelo padrão e implementa de acordo com a linguagem que você está trabalhando. Você pode implementar padrão de projeto no seu projeto orientado a objeto, feito em qualquer linguagem dita orientada a objeto. Por quê? Porque os padrões de projetos usam os fundamentos da orientação a objeto (herança, abstração, polimorfismo, encapsulamento), para aplicar as soluções para os problemas a que se destinam. Padrões de projetos não é algo pronto que deve ser seguido. Eles são ideias, são sugestões, sugestões que nos são dadas por profissionais (no caso o GOF) para evitar problemas recorrentes em projetos de softwares.

Qualquer um pode criar um padrão de projeto, desde que consiga, de fato, comprovar que aquilo é uma solução que pode ser aplicada em qualquer projeto, e não num projeto específico em si. Gostaria de sugerir algumas leituras que considero obrigatórias para quem deseja aprofundar seus conhecimentos em padrão de projetos.

O livro padrão de projetos original do GOF em sua versão em português é o primeiro da fila, ele trata de todos os padrões dos 4 pesquisadores com exemplo de aplicação destes padrões em projetos de software, conhecimento de UML é essencial para entender os diagramas. Uma segunda sugestão é o livro da série Use a Cabeça, Padrões de Projeto, que, embora seja em Java, você pode adaptar para qualquer linguagem. O mais interessante deste livro é a linguagem utilizada, ele trata o assunto de uma forma bastante didática e bem natural, que é assinatura da série.

Lembre-se:

Quando a única ferramenta que temos nas mãos é um martelo, tudo vira prego.

Não vá pensar que agora todo projeto deve obrigatoriamente implementar um ou mais padrões do GOF, ou que um projeto que não os use não tem qualidade, veja bem… o SOLID sempre é o melhor padrão, vá com calma sempre 🙂

O Scrum não importa

O Scrum não importa, o Kanban não importa, o Crystal não importa… nenhum Framework importa, porque você será Ágil se você for ágil.

Certo, mas o que isso significa? Vejamos a imagem abaixo:

Este modelo foi proposto por Robert Dilts e Todd Epstein, e mostra como a mente humana se comporta. Seguindo alguns padrões como:

1. Estamos em um ambiente, e temos diferentes comportamentos em diferentes ambientes: Em nossa casa nos comportamos de uma forma, em nossa empresa de outra e assim por diante. Ou seja, o ambiente determina nosso comportamento
2. Nosso comportamento tem como base nossas capacidades. Diferentes capacidades trazem diferentes comportamentos
3. Estas capacidades que temos são desenvolvidas tendo por bases nossas crenças (se sou uma pessoa que não acredita na violência, não há motivos para eu aprender a atirar com uma arma, por exemplo)
4. Estas crenças que temos estão baseadas em nossa visão de mundo
5. E nossa visão de mundo vem de nosso local mais profundo, vem de nossos ideais

Como exemplo, imagine que você está em uma festa. Você vê as pessoas dançando e sente vontade de dançar também (o ambiente agindo sobre você). Porém você não tem esta habilidade ou capacidade e nem acredita ser um dançarino, então você não irá dançar. Agora imagine que você esta na mesma festa e sentiu uma conexão, viu aqueles rostos sorridentes, aquelas pessoas dançando em harmonia com a música e toda aquela magia e viu que aquilo tem tudo a ver com o que você acredita. Neste momento houve uma conexão com aquela atividade (isso é a conformidade com os seus Ideais). Você então passou a acreditar que aquilo é possível e você quer fazer isso, então você percebe que é um dançarino. Então procurará uma escola de dança para aprimorar suas capacidades. Então, seu comportamento nas próximas festas será dançar.

Certo, mas qual relação disso com a Agilidade e desenvolvimento de software? Bem, se você quer ser Ágil, não é um Framework, livro e muito menos uma ferramenta que vai te fazer Ágil, mas sim os princípios ágeis. Estes princípios estariam no nível das Crenças no modelo proposto acima e você só será Ágil se esses princípios estiverem de acordo com a Visão e Ideais que você acredita.

Quando falo dos princípios ágeis, não estou falando somente dos já consagrados:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Estou sim falando dos 12 Princípios Ágeis:

• Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
• Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
• Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
• Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
• Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
• Construa projetos em torno de indivíduos motivados.
• Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
• O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
• Software funcionando é a medida primária de progresso.
• Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
• Contínua atenção à excelência técnica e bom design aumenta a agilidade.
• Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
• As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
• Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Alguns Framoworks colocam outros valores nesta lista. Recentemente o Scrum fez um update de seus valores

Você acredita nestes valores? Você realmente os entende? Você sabe quais são as capacidades necessárias para alcançar cada um destes princípios? E, principalmente, você É Ágil?

Post rápido e direto apenas a nível de duvidas 🙂

Web Service

• É baseado em SOAP e retorna os dados por padrão em XML.
• Ele suporta apenas o protocolo HTTP.
• Não é open source, mas pode ser consumido por qualquer cliente que entende xml.
• Pode ser hospedado apenas no IIS.
• Possui bastante documentação e possui fácil integração com outros frameworks baseados em .Net

WCF

• Ele também é baseado em SOAP e retorna os dados no padrão XML.
• É a evolução do serviço web (ASMX) e suporta vários protocolos como o TCP, HTTP, HTTPS, Pipes , MSMQ.
• O principal problema com WCF é, a sua configuração tediosa e extensa.
• Não é open source, mas pode ser consumido por qualquer cliente que entende xml.
• Ele pode ser hospedado no IIS ou usando window service.

WCF Rest

• Para usar WCF como um serviço WCF Rest basta você habilitar o webHttpBinding.
• Ele suporta HTTP GET e POST por atributos [WebGet] e [WebInvoke] respectivamente.
• Para permitir que outros verbos HTTP você tem que fazer configurações adicionais no IIS, o que pode ser um pouco custoso.
• Passando dados através de parâmetros usando um WebGet o UriTemplate deve ser especificado e configurado.
• Ele suporta XML, JSON e formato de dados ATOM.

Web Api

• Este é o mais novo framework para a construção de serviços HTTP e possui uma proposta de ser mais simples e fácil de utilizar.
• Web API é open source e projetada para a construção de serviços REST-Ful com o .NET Framework.
• Ao contrário do serviço WCF Rest, ele usa os recursos do HTTP (como URIs, pedido / resposta cabeçalhos, o cache, controle de versão, vários formatos de conteúdo)
• Ele também suporta os recursos MVC como routing, controllers, action results, filter, model binders, IOC container e também dependency injection,
• Ele pode ser hospedado como aplicação ou no IIS.
• É uma arquitetura considerada “leve” e boa para dispositivos que a largura de banda é limitada, como dispositivos móveis por exemplo.
• As respostas são formatadas pelo MediaTypeFormatter em JSON, XML ou qualquer formato que você deseja adicionar como um MediaTypeFormatter.

Considerações finais:

1. Escolha WCF quando você quer criar um serviço que deve suportar cenários especiais, tais como mensageria, filas de mensagens, comunicação duplex etc.
2. Escolha WCF quando você quer criar um serviço que pode usar canais de transporte rápidas quando disponíveis, tais como TCP, Pipes, ou talvez mesmo UDP (em WCF 4.5).
3. Escolha Web API quando você quer criar um serviço sobre protocolo HTTP como Post , Get ou Put.
4. Escolha Web API quando você deseja expor seu serviço para uma ampla gama de clientes, incluindo navegadores, celulares, iphone e tablets.

Esta é a minha opinião sobre qual serviço escolher. Avalie bem o seu cenário, seus recursos e tempo disponível para criação de cada projeto.

Hoje não teremos post, semana que vem voltamos a programação normal 🙂

Bom feriado a todos 🙂

Dando continuação ao post anterior Boas Práticas no JavaScript – parte 1 

12. Use {} Ao Invés de New Object()

Há inúmeras formas de criar objetos em JavaScript. Talvez o método mais tradicional é usar o construtor “new”, dessa forma:

var o = new Object();
o.name = 'Jeffrey';
o.lastName = 'Way';
o.someFunction = function() {
 console.log(this.name);
}

Entretanto, esse método recebe o selo de “má prática” sem, necessariamente, ser. Contudo, recomendo que você use uma forma muito mais robusta de criação de objetos, o método do objeto literal.

Bem Melhor

var o = {
 name: 'Jeffrey',
 lastName = 'Way',
 someFunction : function() {
    console.log(this.name);
 }
};

Note que, se quiser criar um simples objeto em branco, basta atribuir {} a uma variável.

var o = {};

Objetos literais permitem-nos escrever código que suporta várias funcionalidades e, ainda assim, torná-lo relativamente direto para os implementadores do nosso código. Não há necessidade de invocar construtores diretamente ou manter a ordem correta dos argumentos passados para as funções, etc”. – dyn-web.com

13. Use [] Ao Invés de New Array()

O mesmo do ponto anterior, se aplica a vetores.

Okay

var a = new Array();
a[0] = "Joe";
a[1] = 'Plumber';

Bem Melhor

var a = ['Joe','Plumber'];

Um erro comum em programas JavaScript é usar um objeto no momento que um vetor é requerido, ou o contrário. A regra é simples: quando os nomes das propriedades são pequenos números inteiros sequenciais, você deve usar um vetor. Caso contrário, use um objeto”. – Douglas Crockford

14. Sempre, Sempre Use Ponto-e-Vírgulas

Tecnicamente, a maioria dos navegadores permitem você não usar os ponto-e-vírgulas.

var someItem = 'some string'
function doSomething() {
return 'something'
}

Com isso dito, isso é uma prática muito ruim que pode levar a problemas, potencialmente, muito mais difíceis de achar.

Bem Melhor

var someItem = 'some string';
function doSomething() {
return 'something';
}

15. Instruções “For in”

Ao iterar sobre itens de um objeto, você talvez perceba que está trazendo os métodos do objeto também. Para contornar isso, sempre envolva seu código usando uma instrução if que filtre a informação:

for(key in object) {
 if(object.hasOwnProperty(key) {
    ...then do something...
 }
}

Como referenciado em JavaScript: Melhores Partes, por Douglas Crockford.

16. Leia, Leia, Leia…

Embora seja um grande fã de blogs sobre desenvolvimento web, não há um verdadeiro substituto para um bom livro enquanto almoço ou antes de ir dormir. Sempre tenha um livro sobre desenvolvimento web na sua mesa de cama. Eis os meus livros facoritos sobre JavaScript.

• JavaScript Orientado a Objetos
• JavaScript: Melhores Partes
• Aprendendo jQuery 1.3
• Aprendendo JavaScript

Leia todos… Várias vezes. Eu mesmo ainda faço isso!

17. Funções Auto-executáveis

Ao invés de invocar uma função, é bem fácil criar uma função que automaticamente é executada quando a página carregar ou quando uma função pai for executada. Simplesmente, envolva sua função em parênteses e adicione um par extra ao final, que, essencialmente, invocará a função. Algo assim:

(function doSomething() {
 return {
    name: 'jeff',
    lastName: 'way'
 };
})();

18. JavaScript Puro Sempre Pode Ser Mais Rápido Que Usar Uma Biblioteca

Bibliotecas JavaScript, como jQuery e Mootools, podem salvar um bom tempo quando estiver programando – especialmente com operações AJAX. Sabendo disso, tenha sempre em mente que uma biblioteca nunca será tão rápida quanto o JavaScript puro (assumindo que seu código esteja correto).

O método each do jQuery é ótimo para iterações, mas usar a isntrução for nativa, sempre será mais um pouco mais rápido.

19. Remova o Atributo “Language”

Anos atrás, não era incomum encontrar o atributo “language” em tags. Porém, esse atributo, há tempos, é obsoleto, então, deixe-o de fora.