Google anuncia nova linguagem de programação: Go

Olá Pessoal,

Tudo claro por aí?:)

Depois do blecaute (apagão) geral de ontem a  noite (que afetou ao todo 12 Estados brasileiros e parte do Paraguai)…

Vamos ao tópico que apresenta a super novidade da Google:  Go. Eu realmente estava precisando estudar algo novo.

O Google anunciou ontem uma linguagem de programação open source. Chamado de Go, o produto ainda é experimental e combina benefícios de performance e segurança associados a uma linguagem compilada como C++ à velocidade de uma linguagem dinâmica como Python.

Para começar as atividades na linguagem escrevendo “Hello World!”, basta usar o seguinte código:

05 package main
07 import fmt "fmt" // Package implementing formatted I/O.
09 func main() {
10 fmt.Printf("Hello, world; or ???????? ?????; or ????? ??n");
11 }

via: imasters assinatura_blog

Programando em equipe – Parte2

Continunação

 

Programador procedural no mundo orientado a objetos:

* Reduza a visibilidade da classe – Nunca deixe público e exposto pela classe algo que somente está sendo usado por ela internamente (atributos e métodos). Quanto mais coisas públicas as classes possuírem, menos flexibilidade de manutenção ela terá.

* Use sobrecarga de métodos – Dê preferência à sobrecarga de métodos em vez de ficar implementando controle de lógica baseado na passagem de parâmetros.

* Longas listas de argumentos – Métodos com muitos parâmetros refletem em geral a falta de percepção de que está faltando a criação de um objeto que contivesse estes dados devidamente encapsulados, utilizado posteriormente como agregação.

* Classes sem métodos ou sem atributos – A classe é a expressão de um componente portador de características e comportamentos. Salvo em raros casos, na utilização consciente de design patterns.

* Reutilização de código – Na POO podemos reutilizar código de duas formas: por herança ou agregação. Sempre faça uma análise crítica no caso de qual utilizar, mantendo em mente de que a agregação é a forma mais flexível. Entretanto, existirão casos de herança (considere casos de classes abstratas). De forma alguma faça CTRL+C e CTRL+V nas classes por menor que seja a circunstância!

* Polimorfismo sempre – Use indiscutivelmente quando puder argumentos, variáveis, tipos de retornos polimórficos. Não existe nenhuma outra coisa na POO que ofereça mais flexibilidade e manutibilidade como a codificação polimórfica.

* Classes Enormes – Isso é uma das picaretagens mais feias que podem ser feitas contra o patrimônio OO!!! Nunca faça classes longas, cheias de métodos, resolvendo tudo……é o famoso canivete suíço. Passe um pente fino nas classes usando a SRP – Single Responsability Principle – na qual afirma que cada classe deve ser implementada para resolver apenas uma situação, uma responsabilidade! Busque a granularidade certa entres as classes do seu projeto, considerando, é claro, o escopo em questão.

* Métodos Enormes – Métodos grandes, cheios de controle de fluxo normalmente devem ser analisados e fracionados em métodos menores com visibilidades mais restritas.

* Abuso em Recursos Estáticos – Outra ofensa contra o patrimônio OO! Na POO não existem funções e variáveis globais perdidas no espaço mágico do mundo encantado! Tudo é objeto se relacionando com outro objeto através de seus estados e ações. Classes que apresentam abusos deste recurso expressam que o programador (autor) não conseguiu visualizar as abstrações e seus relacionamentos dentro do contexto da implementação. Recursos estáticos representam um escopo especial que é compartilhado por todos os objetos de uma classe e devem ser usados para satisfazer somente este caso.

* Nunca Reinvente a Roda – O Java tem 14 anos (desde 1995) de existência e apresenta uma série de recursos agrupados pelas plataformas. Fora isso, existem muitos produtos proprietários, open-source ou pagos e, por esse motivo, nunca tente elaborar ou inventar algo do zero antes de pesquisar a fundo! Porque na maioria dos casos você vai achar alguma coisa pronta (classe, componentes, framework, especificação, produto open-source ou proprietário pago com preço acessível) para resolver aquilo que você está necessitando!

* Encapsulamento – Sempre esconda as estruturas internas de uma classe e controle o acesso ao estado dos objetos através do encapsulamento usando a padronização JavaBean.

* Implemente as Regras Arquiteturais – Se uma classe é a última da hierarquia, declare como final!! Se um método não pode ser anulado, declare com final! Se um argumento ou variável não deve ser mudado, declare como final etc… Ou seja, impeça ou force polimorfismo, libere ou restrinja visibilidades em herança ou agregações. Entenda seu domain model e expresse-as no modelo de classes!

* Ciclo de vida dos objetos – Sempre programe pensando em cooperar com o coletor de lixo!! Ou seja, analise bem os escopos de criação dos objetos (estático, instância ou local) e os libere (atribuindo null para as referências) logo após verificar que não irá mais utilizá-los. Perceba que esta prática deixa o código claro e legível.

* Modere a Criação de Objetos – Sempre seja moderado na criação de objetos, nunca criando mais do que você precisa, sendo que o coletor de lixo é muito eficiente, mas não faz milagres. Quando possível, tente reusar os mesmos objetos reiniciando-os ao seu estado inicial. Analise cada new que você declarar!! Em aplicações de médio/grande porte isso pode resultar em uma grande economia e conseqüentemente performance.

Controlando condições excepcionais:

* Controle de Erros – Nunca use como controle de erros com retorno de booleano ou códigos de erros! Em Java existe uma mecânica padronizada chamada de tratamento de exceções. Lance exceções indicando as condições excepcionais, usando classes existentes no core do JSE ou não tenha receio de criar as suas próprias quando necessário.

* Propagação de Exceções – Nunca propague uma exceção ocorrida de dentro de uma camada lógica para fora da mesma, sendo que a outra camada cliente não deve conhecer detalhes internos de execução. Neste caso propague outras exceções mais significativas referentes ao contexto da camada/componente/classe ou serviço.

* Exceções Polimórficas – Nunca use o tratamento de exceções de forma polimórfica! Sempre encadeie os catch de todas as exceções, deixando o código claro e legível para o próximo programador amigão do peito!

* Comendo Exceções – Nunca faça um try sem colocar nada no catch! No mínimo, tem que existir uma impressão da lista do trace ou substitua, se possível, o try por um if identificando a condição.

* Fluxo de Controle em Exceções – Nunca use um try/catch como fluxo de controle!! Ou seja, não baseie nenhuma lógica condicional no controle de exceções. O próximo programador agradece a legibilidade do seu código.

Bom, pessoal, estas foram as “pérolas” que eu já peguei espalhadas por ai! A área de comentários fica livre para quem quiser complementar ou dar sua opinião. Para quem deseja realmente ter uma boa base sobre o assunto, sugiro a leitura e a prática do Java Code Convention e o livro Head First OOA&D – (em português Análise e Projeto Orientado a Objetos). 

fonte: fernando franzini – imasters

:: LUCIANA COSTA ::

Programando em equipe – Parte1

O desenvolvimento de um software consiste em um grupo de pessoas manuseando os mesmos arquivos fontes e componentes. Se um indivíduo deste grupo não conseguir escrever a sua parte de forma clara, de fácil compreensão e manutenção, o projeto estará comprometido a uma série de conseqüências problemáticas. Entendo que isso é uma situação de peso, uma vez que a manutenção representa em média 80% do tempo de vida de um sistema.

Ao longo das consultorias em projetos de que venho participando, diagnostiquei que os programadores em geral não sabem o significado de se “Programar em Equipe”. Percebo que é um problema de nível cultural e acredito que isso possa ser revertido se cada um pensasse da seguinte forma:

Eu estou trabalhando em uma equipe, por isso eu tenho que me esforçar ao máximo para implementar este requisito da forma mais simples, clara e de fácil manutenção possível…porque haverá algum momento no ciclo de vida do desenvolvimento que um companheiro de equipe precisará alterar ou complementar o que eu fiz e inevitavelmente eu também precisarei manusear algum código que foi construído por outra pessoa.

Acredito que o fato acontece por 3 motivos:

  • Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia.
  • O desconhecimento de que na tecnologia Java existe um padrão de codificação.
  • A falta de uma sólida base de princípios de projeto orientado a objeto.

1. Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia:

Eu percebo que atualmente existe uma galera muito inteligente e esforçada que vem migrando de outras tecnologias para o Java e que realmente tem conseguido produzir softwares funcionais, entretanto 100% deles deixam muito a desejar neste ponto. Percebo que o pessoal traz seus costumes e hábitos de programação para dentro do Java.

2. O desconhecimento de que na tecnologia Java existe um padrão de codificação:

Em Java existe uma forma padrão de como se deve ser escrito um código fonte. Ou seja, o autor não tem a liberdade de ficar usando/inventando uma série firulas, gafs, comentários, regras de espaçamentos sem coerências, delegação de nomes para identificadores completamente malucos etc….. Existe um documento chamado “Java Code Conventions” que possui todas as regras e diretrizes previamente estudadas e estabelecidas para que qualquer pessoa em qualquer lugar no mundo possa escrever o mesmo código fonte. Isto quer dizer o que? Quer dizer que uma pessoa de um lado do mundo pode abrir o código fonte de uma outra pessoa, do outro lado e ter a sensação de que ela mesma que escreveu! Sendo que ambos devem seguir a convenção de codificação.

3. A falta de uma sólida base de princípios de projeto orientado a objeto:

Fácil manutenção está intimamente ligada à utilização de princípios e diretrizes da filosofia orientada a objetos e é aqui onde o galera mais deixa a peteca cair! Como é incrível ver o pessoal mesmo usando uma tecnologia OO conseguir programar usando conceitos procedurais/globais e fazer uma coisa simples OO virar um monte de macarrão trançado. Sempre lembrando que a POO é uma filosofia e pode ser furada fácil, fácil, em qualquer parte do projeto.

Segue abaixo a lista resumida dos erros mais comuns:

* Estado do objeto – Não use variáveis de instâncias para controle de fluxos locais! Variável de instância é usada para definir estado do objeto durante seu ciclo de vida. Caso precise controlar algo localmente, use variáveis locais.

* Declaração de variáveis – Somente declare e inicialize as variáveis locais antes (o mais próximo o possível) de serem usadas! Único momento onde é aceitável declarar uma variável muito longe de sua utilização é em caso de utilização fora de escopos de controle de fluxo ou loop. Mesmo assim, mantenha em mente que você deve declarar sempre o mais perto possível.

* Escopo de variáveis – Sempre reduza os escopos das variáveis o máximo possível! Nunca declare uma variável fora de um escopo lógico (while, if, do/while, for) se você só vai precisar da variável dentro dele.

* Nomeação de variáveis – Independente do seu escopo (instância ou local), os nomes das variáveis devem ser auto-explicativos! Não coloque nomes sem sentido ou com apenas um caractere! Único lugar aceitável para se colocar uma variável com um único caractere é no contador de um for, o resto tem que possuir um nome significativo dentro do contexto de implementação. Outra coisa, não faça nomes grandes demais, resuma ou procure um sinônimo menor.

* Nomeação de classes e métodos – Nome de classe geralmente é um substantivo que reflete a abstração da automação de alguma coisa do mundo real, e os nomes dos métodos devem ser verbos que refletem ações que um objeto da classe faz. Qualquer coisa que passar disso fará com que o projeto fique completamente ilegível e confuso! Única possibilidade de exceção a este caso seria a possível utilização de design patterns dentro da arquitetura.

fonte: fernando franzini-imasters

:: LUCIANA COSTA ::

Dica: VB.Net e VB6

Com o VB .NET você pode efetuar cálculos com valores monetários, no entanto devemos utilizar neste caso, o tipo Decimal.

Já no VB6 HAVIA o tipo Currency que era usado para cálculos financeiros mas no VB .NET ele não existe e foi substituído pelo tipo Decimal.

Portanto, no VB6 a sugestão é não usar o tipos de dados Currency, recomenda-se o uso do tipo de dados Decimal no VB6 e no VB .NET use o tipo de dados Decimal ou Long.

Visual Studio 2005 (Express)

Ola,

Posts atrás havia comentado sobre algumas novidades que teríamos aqui no site. Hoje falaremos um pouco sobre o Visual Studio 2005 em sua versão Express.

 

A partir do Visual Studio 2005 e .NET Framework 2.0 os desenvolvedores ganharam uma linha de ferramentas para desenvolvimento de software totalmente gratuitas. Essas ferramentas ganharam a nomenclatura de “Express”. Vejam os produtos:

Para desenvolver para ambiente Web:
http://msdn.microsoft.com/vstudio/express/web/

Para desenvolver para ambiente Windows:
http://msdn.microsoft.com/vstudio/express/windows/

Achou legal?

Veja que ainda temos o banco de dados SQLServer 2005 Express:
http://msdn.microsoft.com/vstudio/express/sql/

Lembrando que já estamos algum tempo com a versão 2008 disponível.

Luciana Costa

 

Enfim um Grupo de Discussão

Algumas semanas sem poder postar por aqui devido ao problema junto a Telefônica (Speedy). Agora tudo normalizado (assim espero!).

De volta ao mundo Net.

Apenas para divulgar o novo grupo de discussão em TI. Caso queira participar, fique a vontade! Quanto mais informação, melhor!

>> CAFÉ INFORMÁTICA <<

http://groups.google.com.br/group/cafeinformatica

http://www.orkut.com.br/Community.aspx?cmm=61125125

Abraços,

Luciana Costa