Mostrando postagens com marcador Desenvolvimento. Mostrar todas as postagens
Mostrando postagens com marcador Desenvolvimento. Mostrar todas as postagens

quinta-feira, 16 de dezembro de 2010

Introdução ao C# (CSharp)




Com esse artigo inicio uma série sobre esta linguagem de programação.
C# (pronuncia-se "cê chárp" em português ou "cí charp" em inglês), é uma linguagem de programação orientada a objetos, fortemente tipada, desenvolvida pela Microsoft como parte da plataforma .NET. A sua sintaxe orientada a objetos foi baseada no C++ mas inclui muitas influências de outras linguagens de programação, como Object Pascal e Java.

A criação da linguagem, embora tenha sido feita por vários programadores, é atribuída principalmente a Anders Hejlsberg, hoje um Distinguished Engineer na Microsoft. Ele fora o arquiteto de alguns compiladores da Borland, e entre suas criações mais conhecidas estão o Turbo Pascal e o Delphi.


Características

O C# é, de certa forma, a linguagem de programação que mais diretamente reflete a plataforma .NET sobre a qual todos os programas .NET executam. C# está de tal forma ligado a esta plataforma que não existe o conceito de código não-gerenciado (unmanaged code) em C#. Suas estruturas de dados primitivas são objetos que correspondem a tipos em .NET. A desalocação automática de memória por garbage colletor além de várias de suas abstrações tais como classes, interfaces, delegados e exceções são nada mais que a exposição explicita recursos do ambiente .NET.

Quando comparada com C e C++, a linguagem é restrita e melhorada de várias formas incluindo:

* Ponteiros e aritmética sem checagem só podem ser utilizados em uma modalidade especial chamada modo inseguro (unsafe mode). Normalmente os acessos a objetos são realizados através de referências seguras, as quais não podem ser invalidadas e normalmente as operações aritméticas são checadas contra sobrecarga (overflow).

* Objetos não são liberados explicitamente, mas através de um processo de coleta de lixo (garbage collector) quando não há referências aos mesmos, previnindo assim referências inválidas.

* Destrutores não existem. O equivalente mais próximo é a interface Disposable, que juntamente com a construção using block permitem que recursos alocados por um objeto sejam liberados prontamente. Também existem finalizadores, mas como em Java sua execução não é imediata.

* Como no Java, não é permitida herança múltipla, mas uma classe pode implementar várias interfaces abstratas. O objetivo principal é simplificar a implementação do ambiente de execução.

* C# é mais seguro com tipos que C++. As únicas conversões implícitas por default são conversões seguras, tais como ampliação de inteiros e conversões de um tipo derivado para um tipo base. Não existem conversões implícitas entre inteiros e variáveis lógicas ou enumerações. Não existem ponteiros nulos (void pointers) (apesar de referências para Object serem parecidas). E qualquer conversão implícita definida pelo usuário deve ser marcada explicitamente, diferentemente dos construtores de cópia de C++.

* A sintaxe para a declaração de vetores é diferente ("int[] a = new int[5]" ao invés de "int a[5]").

* Membros de enumeração são colocados em seu próprio espaço de nomes (namespace)

* C# não possui modelos (templates), mas C# 2.0 possui genéricos (generics).

* Propriedades estão disponíveis, as quais permitem que métodos sejam chamados com a mesma sintaxe de acesso a membros de dados.

* Recursos de reflexão completos estão disponíveis

C# Versus Java 

Apesar de C# ser freqüentemente tido como similar a Java, existem uma série de diferenças importantes, tais como:

* Java não implementa propriedades nem sobrecarga de operadores.

* Java não implementa um modo inseguro que permita a manipulação de ponteiros e aritmética sem checagem.

* Java possui exceções checadas, enquanto exceções em C# são não checadas como em C++.

* Java não implementa o goto como estrutura de controle, mas C# sim.

* Java utiliza-se de comentários Javadoc para gerar documentação automática a partir de arquivos fonte. C# utiliza comentários baseados em XML para este propósito.

* C# suporta indexadores e delegados.

Bibliotecas de códigos

Ao contrário das outras linguagens de programação, nenhuma implementação de C# atualmente inclui qualquer conjunto de bibliotecas de classes ou funções. Ao invés disso, C# está muito vinculada ao framework .Net, do qual C# obtém suas classes ou funções de execução. O código é organizado em um conjunto de namespaces que agrupam as classes com funções similares. Por exemplo: System.Drawing para gráficos, System.Collections para estrutura de dados e System.Windows.Forms para o sistema Windows Form.

Um nível de organização superior é fornecido pelo conceito de montador (assembly). Um montador pode ser um simples arquivo ou multiplos arquivos ligados juntos (como em al.exe) que podem conter muitos namespaces ou objetos. Programas que precisam de classes para realizar uma função em particular podem se referenciar a montadores como System.Drawing.dll e System.Windows.Forms.dll assim como a biblioteca core (conhecida como mscorlib.dll na implementação da Microsoft).


Para quem desejar saber mais sobre o assunto seguem alguns links que entre outros serviram de base para este post



quarta-feira, 8 de setembro de 2010

Você conhece Objective-C


Um post do Adriano Santos no seu blog Delphi To Delphi  chamou minha atenção, sobre uma fatia do mercado que percebo como pouco explorada atualmente no Brasil, os aplicativos para iPhone, iPad e iPod.

Procurando um pouco mais de informação sobre o assunto, deparei-me com a linguagem Objective-C, que para quem não sabe é a linguagem usada para criação de aplicações para os sistemas da Apple.

Um pouco de história 

O ObjC foi criado principalmente por Brad Cox e Tom Love no início da década de 1980 na empresa deles, a Stepstone. A principal descrição do Objective-C em sua forma original foi publicada no livro de Cox, Object-Oriented Programming, An Evolutionary Approach, de 1986.

Em 1988, a NeXT de Steve Jobs licenciou o Objective-C da StepStone (a dona da marca registrada Objective-C) e liberou sua própria versão do compilador e das bibliotecas da linguagem nas quais a interface do usuário e da estrutura NeXTstep eram baseadas. O sucesso das ferramentas e a qualidade do sistema operacional resultante ajudaram a NeXT a ocupar um nicho de provedor de workstations bastante popular.

O projeto GNU começou a trabalhar em seu clone livre do NeXTStep baseado no padrão OpenStep, o GNUstep. Dennis Glatting escreveu o primeiro runtime do gnu-objc em 1992, e Richard Stallman criou o segundo pouco depois. O runtime do GNU Objective-C que tem estado em uso desde 1993 é aquele desenvolvido por Kresten Krab Thorup, quando ele era estudante universitário na Dinamarca. Kresten também trabalhou para a NeXT por algum tempo.

Depois de adquirir a NeXT em 1996, a Apple usou o OPENSTEP como base para seu principal sistema operativo, o Mac OS X. Isto inclui o Objective-C e a ferramenta de desenvolvimento NeXT's Objective-C, o Project Builder (mais tarde substituído pelo Xcode), bem como sua ferramenta de projeto de interface, Interface Builder.

A maior parte da presente API Cocoa da Apple está baseada na interface de objetos OpenStep, e este é o mais significativo ambiente Objective-C sendo usado para desenvolvimento ativo.

O Objective-C é uma camada construída sobre a linguagem C e constitui-se num superconjunto estrito de C. Ou seja, é possível compilar qualquer programa C com um compilador Objective-C. O Objective-C deriva sua sintaxe tanto do C quanto do Smalltalk. A maior parte de sua sintaxe (incluindo pré-processamento, expressões, declaração e chamadas de funções) foi herdade do C, enquanto a sintaxe para os aspectos orientados a objetos foi criada para habilitar passagem de mensagens no estilo Smalltalk.

Ambiente de programação

Para programar em Objective-C, tal como em qualquer outra linguagem moderna, você precisa de um editor e um compilador. Ambos estão disponíveis gratuitamente em muitos dos sistemas operacionais atuais.

No MacOS X, você deve instalar os "Developer Tools" gratuitos da Apple, caso eles não estejam presentes no seu sistema. Essas ferramentas incluem dentre muitas outras coisas o compilador gcc e um ambiente de programação extremamente eficiente, denominado Xcode.

No Linux você já deve ter o gcc instalado, bem como muitos editores de texto (vi, pico, emacs). Você tambem pode utilizar algum ambiente de programação, como o KDevelop ou ferramentas GNUStep.

No Windows você pode instalar o compilador Objective-C que acompanha o sistema MinGW (http://www.mingw.org). Para escrever os códigos, qualquer editor de texto puro, como o Notepad, ou algum ambiente de programação devem servir.

Nos três sistemas, compilar um programa utilizando a linha de comando resume-se ao gcc (para projetos maiores costuma-se utilizar ferramentas como make, automake, etc), cujo formato geral de chamada é:

Portanto, chegamos a conclusão que por ser uma linguagem derivada do C, quem já possui algum conhecimento sobre esta linguagem larga na frente. 

Com o crescimento das vendas dos equipamentos da Apple no mercado brasileiro, creio que seja uma possibilidade a ser observada com carinho. 

Um agrande abraço e sucesso ao Adriano Santos o mais novo licenciado como desenvolvedor Apple®.

Fontes utilizadas neste post: 
http://pt.wikipedia.org/wiki/Objective-C
http://www.astro.iag.usp.br/~algol/computacao/ObjCtutorial.html

sexta-feira, 14 de maio de 2010

Compilar em apenas um passo




Na serie de arigos sobre o teste do Joel estou escrevendo sobre os pontos que devem ser levados em consideração para a melhor o processo de produção de software.

A segunda  pergunta do 
teste do Joel é saber se você pode compilar todo o projeto em apenas um passo. Essa é uma questão essencial e um desafio para muitas equipes. Em muitos casos perdem-se horas sagradas para gerar um novo Release.

Boas equipes possuem um único script que faz um checkout completo do zero, reconstrói cada linha de código, faz os EXE's, em todas as suas várias versões, linguagens e combinações de #ifdef, cria o pacote de instalação e cria a mídia final -- layout do CDROM, download do website, o que seja.

Se este processo possui mais de uma etapa, ele tende a ter erros. E quanto mais perto você chega da data de entrega, mais você quer ter um ciclo realmente rápido para corrigir o "último" bug, fazer os EXE's finais, etc. Se você leva 20 etapas para compilar o código, executar o construtor de instalação, etc, você vai enlouquecer e cometerá erros bobos.

Para automatizar o processo de compilação existem diversas ferramentas mas duas premissas sempre se mantêm independente da ferramenta escolhida :
  • Deve ser possível compilar o projeto inteiro em um passo
  • Deve ser possível usar qualquer máquina de desenvolvimento para isso

Citando algumas ferramentas:

Cruise Control
 - ferramenta que automatiza o processo de build, provendo várias tarefas que facilitam o controle sobre o código, incluindo uma interface para visualizar os detalhes sobre cada build

Visual Build Professional
-   ferramenta que possui suporte para o Microsoft Visual Studio .NET/2005, Visual Studio Team System, Visual Basic, Visual C++, SourceSafe, eMbedded Tools, Borland Developer Studio, Delphi, JBuilder, C++Builder, ClearCase.  Para sistemas de builds pequenos/medios ele é excelente. Já para builds de grande porte, pode não ser uma boa já que ele não permite o que, em alguns casos, dificulta o reaproveitamento dos scripts.

Além das ferramentas acima ainda merecem ser lembradas o Quick Build e o Luntbuild


Finalizando ...

Seja qual for a sua ferramenta preferida, o que realmente importa é que o processo seja o mais automatizado possivel, para assim diminuir as possibilidades de erros, como também agilizar o processo de deploy de novas versões do sistema.

Para quem desejar saber mais sobre o assunto seguem alguns links que entre outros serviram de base para este post

terça-feira, 9 de fevereiro de 2010

O Básico sobre Controle de Código



Muitos problemas de desenvolvimento de software são causados por falta de controle de versão. Faça uma avaliação rápida da situação da sua equipe de desenvolvimento:

  1. Alguém já sobrescreveu o código de outra pessoa por acidente e acabou perdendo as alterações?
  2. Tem dificuldades em saber quais as alterações efetuadas em um programa, quando foram feitas e quem fez?
  3. Tem dificuldade em recuperar o código de uma versão anterior que está em produção?
  4. Tem problemas em manter variações do sistema ao mesmo tempo?



Se alguma das perguntas acima teve um sim como resposta, então sua equipe necessita urgentemente de um sistema para controle de versão!

Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões – histórico e desenvolvimento – dos códigos-fontes e também da documentação.

Esse tipo de sistema é muito presente em empresas e instituições de tecnologia e desenvolvimento de software. É também muito comum no desenvolvimento de software livre. É útil, em diversos aspectos, tanto para projetos pessoais pequenos e simples como também para grandes projetos comerciais.

Principais vantagens

As principais vantagens de se utilizar um sistema de controle de versão para rastrear as alterações feitas durante o desenvolvimento de software ou o desenvolvimento de um documento de texto qualquer são:
Controle do histórico: facilidade em desfazer e possibilidade de analisar o histórico do desenvolvimento, como também facilidade no resgate de versões mais antigas e estáveis. A maioria das implementações permitem analisar as alterações com detalhes, desde a primeira versão até a última.
Trabalho em equipe: um sistema de controle de versão permite que diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao mesmo tempo e minimiza o desgaste provocado por problemas com conflitos de edições. É possível que a implementação também tenha um controle sofisticado de acesso para cada usuário ou grupo de usuários.
Marcação e resgate de versões estáveis: a maioria dos sistemas permite marcar onde é que o documento estava com uma versão estável, podendo ser facilmente resgatado no futuro.
Ramificação de projeto: a maioria das implementações possibilita a divisão do projeto em várias linhas de desenvolvimento, que podem ser trabalhadas paralelamente, sem que uma interfira na outra.

Não existe nada mais frustrante do que não ter exatamente o código-fonte da versão que está rodando no cliente ou não saber o que mudou desde que a versão foi entregue. Esse tipo de coisa pode acabar com uma empresa ou fazer com que ela fique muito mal vista no mercado.

Porém, independente do mercado, existe um bom motivo para o desenvolvedor possuir algum tipo de controle de código: controle. Se você ou sua equipe não conseguem corrigir todos os bugs, pelo menos saberão o que já foi feito. Se você achou um bug que não existia antes da versão 10, o histórico das mudanças entre a versão estável 9 e a versão não-tão-estável 10 vai te dar uma pista muito boa de onde o problema pode ter sido gerado. Visto dessa forma, não importa muito o tamanho da equipe ou da organização. O importante de um bom código é que suas mudanças estejam sempre registradas, visíveis e disponíveis a qualquer um.



Opções para Controle de Código

Um controle de código para uma pessoa só não precisa ser nada muito sofisticado, sendo que um amontoado de ZIPs pode dar conta do recado. Porém, a partir do momento em que o número de desenvolvedores aumenta para dois ou mais, aí o controle baseado em ZIPs começa a ruir, e é necessário usar uma ferramenta mais apropriada. Existem algumas opções, que vai do gosto e necessidades de cada um:

Visual Source Safe ou VSS: não é gratuito nem robusto o suficiente para agüentar toneladas de código-fonte, mas vem junto do Visual Studio e pode ser apropriado para empresas de porte pequeno ou médio (e empresas de um programador só).

Concurrent Version System ou CVS: é um sistema fonte aberto, gratuito e robusto. Suficiente para agüentar toneladas de código-fonte e equipes de vários andares. Atualmente está sendo substituído gradualmente pelo

Subversion ou SVN: é um substituto moderno do antigo CVS; igualmente gratuito e poderoso, está rapidamente se tornando a opção predominante.
Git: é um sistema de controle de revisão distribuida, rápido e escalável. O Git foi desenvolvido inicialmente por Linus Torvalds mediante uma necessidade de ter um software robusto para controle de versão do kernel linux. O Git, diferente do subversion, por exemplo, não é um repositório de dados centralizado. Assim, cada pessoa que trabalha no mesmo projeto terá uma cópia completa do repositório, portanto, as operções comuns de um repositório de dados são feitas localmente. Isso dá a liberdade total para o usuário trabalhar com o repositório como quiser, criando branches, fazendo merges, etc... Ao final do processo, ele pode enviar um branch mais bem trabalhado e testado ao repositório remoto.

Para aqueles que queiram aprofundar no assunto recomendo a leitura dos artigos abaixo, que entre outros, serviram de base para este post.

http://pt.wikipedia.org/wiki/Sistema_de_controle_de_versão

http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/conceitos_basicos_controle_versao_centralizado_e_distribuido.php

quinta-feira, 4 de fevereiro de 2010

O Teste do Joel: 12 Passos para um Código Melhor


Nas minhas "andanças" pela internet acabei encontrando o Teste do Joel: 12 Passos para um Código Melhor e fiquei impressionado com o que li. 

Antes de falar do teste de Joel, preciso falar do próprio Joel é claro. Quem será esse tal Joel Spolky, então vamos lá: 



Joel Spolsky é um experiente programador, dono do Blog Joel On Software - um dos melhores (senão o melhor) blog sobre gerenciamento e desenvolvimento de software. Também é  o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O legal do Teste do Joel é que ele consiste de 12 perguntas que deverão ser respondidas com SIM ou NÃO cada questão. Você não precisa realizar cálculos complicados para achar o resultado. Simplesmente atribua à sua equipe 1 ponto para cada "sim" respondido. 

Uma pontuação 12 é perfeita, 11 é tolerável, mas 10 ou menos indica que você tem sérios problemas. A verdade é que a maioria das empresas de software funcionam com uma pontuação 2 ou 3, e elas precisam de uma grande ajuda, porque companhias como a Microsoft funcionam com 12 pontos todo o tempo.

Então vamos lá às perguntas : 

  1. Você usa controle de código?
  2. Você pode compilar em somente um passo?
  3. Você faz compilações diárias?
  4. Você tem uma base de dados de bugs?
  5. Você corrige os bugs antes de escrever código novo?
  6. Você tem um cronograma atualizado?
  7. Você tem uma especificação?
  8. Os programadores tem condições de trabalho tranqüilas?
  9. Você usa as melhores ferramentas que o dinheiro pode comprar?
  10. Você tem testadores?
  11. Novos candidatos escrevem código durante a entrevista?
  12. Você faz testes de usabilidade de corredor?
Se você desejar poderá ler o artigo completo que serviu de base para este post e conhecer um pouco mais sobre cada um dos doze itens clique no link abaixo: 


Diante de tudo que li e do impacto que esse assunto causou em mim, nos proximos posts vou abordar assuntos correlatos aos itens do teste, e o primeiro deles será sobre controle de código, e sobre a ferramenta que uso para esta finalidade o GIT. 

Então ... temos um encontro marcado no próximo post.

Até lá.