Arquivo da tag: programação

Asp.Net, Web Forms e Ninjas – Parte 1

Um padrão que facilita muito a montagem de um sistema orientado à objetos é o de Inversão de Controle e Injeção de Dependência – Inversion of Control / Dependency Injection, ou simplesmente IoC/DI. O padrão tira das mãos do programador o trabalho de instanciar objetos – que pode ficar bem complicado, restando apenas configurar a aplicação.

IoC/DI

Ninja!!!!

Ninja!!!!

Programando para a web, geralmente temos de aprender o ciclo de vida da aplicação web, quais os pontos de chamadas de páginas, controles, beans e etc. Quem tem o controle da aplicação é o servidor de aplicação – IIS/.NET, JBoss, WebSphere – e não o programador. Isto é um tipo de Inversão de Controle.

No caso da Injeção de Dependência, a Inversão de Controle se refere a quem cria os objetos. Quem deve criar os objetos é a própria aplicação. Por que isto? A criação de objetos pode ser complexa e cheia de dependências. Um exemplo: a criação de um objeto Samurai. Mas um Samurai obrigatoriamente precisa de uma Espada. Então você deve primeiro criar uma Espada, para depois criar o Samurai. Mas para criar uma Espada você precisa de uma Forja e um Ferreiro e assim por diante.

A solução é usar um contêiner – ou container – que faça este trabalho e crie estes objetos para nós. Ao programador resta elaborar e estabeler as regras para esta criação.

Um contêiner DI muito utilizado em Java é o Spring Framework. Em .Net temos vários, mas nenhum em amplo uso e aval da MS. Aqui vou falar de um que considero bem prático de usar e cuja configuração não é baseada em XML. O Ninject.

Ninjas!

Ok, criar objetos pode ser complicado e sujo, então contratemos ninjas para fazê-lo. O Ninject possui uma documentação bem simples de se acompanhar, mas vejamos aqui mesmo o básico.

Segue um código com comentários para exemplificar como o Ninject funciona:

class Samurai {
  readonly IWeapon _weapon;

  //O atributo 'Inject' faz com que o Ninject, ao instanciar um Samurai, instancie primeiro um IWeapon.
  //Este IWeapon é então passado para o Samurai como um parâmetro do construtor.
  [Inject]
  public Samurai(IWeapon weapon) {
    _weapon = weapon;
  }
  public void Attack(string target) {
    _weapon.Hit(target);
  }
}

class Espada implements IWeapon {
  public Metal Metal { get; private set; }
  public double Weight { get; private set; }
  public double Length { get; private set; }
  public string Name{ get; private set; }
  public Blacksmith Blacksmith { get; private set; }

  //Este 'Inject' é semelhante ao de cima, com a diferença do Ninject instanciar e atribuir um
  //DamageCalculator após a construção desta Espada.
  //Seria semelhante à um new Espada(...) { DamageCalculator = new DamageCalculator(...) }
  [Inject]
  public DamageCalculator Calculator { get; set; }

  [Inject]
  public Espada(Blacksmith blacksmith) {
    Metal = Metal.Iron;
    Weight = 1;
    Length = 2;
    Name = name;
    Blacksmith = blacksmith;
  }

  public Espada(Metal metal, double weight, double length, string name, Blacksmith blacksmith) {
    Metal = metal;
    Weight = weight;
    Length = length;
    Name = name;
    Blacksmith = blacksmith;
  }
  public void Hit(string target) {
     //código com o ataque, levando em conta as características da espada etc.
  }
}

//etc...

Acima vemos onde marcar nosso código de forma a instruir o Ninject onde agir. Mas como o Ninject sabe qual arma criar para o Samurai, se o Samurai recebe qualquer coisa que implemente IWeapon? Utilizando NinjectModule:

public class SamuraiModule : NinjectModule
{
    public override void Load()
    {
        //Sempre que o código pedir um Samurai, um Samurai será criado
        Bind<Samurai>().ToSelf();
        //Sempre que o código pedir um IWeapon, uma Espada será criada
        Bind<IWeapon>().To<Espada>();
        Bind<Blacksmith>().ToSelf();
    }
}

Basta agora configurar sua aplicação para ter um Ninject funcional sempre que necessário. Como escolhi, por vários motivos, criar meu projeto como um Asp.NET Web Forms (ao contrário do Asp.NET MVC), tive de alterar o Ninject para dar suporte. Sorte que alguém já havia feito isto.
Basta baixar o código fonte do Ninject, aplicar o patch e compilar.

Agora devemos alterar o Global.asax.cs para que ele estenda NinjectHttpApplication e instanciar um novo Ninject.IKernel sempre que a aplicação subir.
É o IKernel o responsável pelo tedioso e oneroso trabalho de instanciar seus objetos, suprindo-os dos elementos necessários para seu funcionamento.

public class Global : NinjectHttpApplication
{
    protected override void OnApplicationStarted()
    {
        base.OnApplicationStarted();
    }

    protected override Ninject.IKernel CreateKernel()
    {
        IKernel kernel = new StandardKernel(
            new List()
            {
                new SamuraiModule()
            }.ToArray()
        );

        return kernel;
    }
}

Nos próximos posts mostrarei como usar o Ninject e o NHibernate em uma aplicação Asp.NET Web Forms.

Programar é arte

O tema é recorrente.  Desde o monumental The Art of Computer Programming ao, hmm…, pragmático  The Pragmatic Programmer existe a noção de que programar não é uma ciência exata. Não é produção, tampouco engenharia. Programar é uma atividade que requer criatividade, visão, trabalho e destreza. É arte.

Vem daí a dificuldade de se estabelecer prazos. De gerar metodologias. De ser produtivo, ter qualidade e criar soluções. Como apressar, controlar e gerenciar algo tão pessoal quanto a produção de código? Talvez tornando-o impessoal e automático. Mas não seria isto remover as características que diferenciam um software bom de um ótimo?

Pode-se criar arte em massa. Pode-se criar obra únicas. Pode-se apreciar ou não uma obra-prima. Não é tão diferente no mundo do código fonte. Quem já não vislumbrou, modificando um programa qualquer, uma obra de arte barroca? Cheia de meandros, voltas, incertezas e becos sem saída. Um labirinto a provocar emoções: fúria, alegria,  raiva, medo, alívio (bom, este só quando o código compila e/ou passa nos testes). Estou divergindo…

E quem programa pode ser entendido como um artesão. Alguém que martela teclas para produzir, vez ou outra, um pouco de arte. E podemos encontrar, procurando bastante, entre estes artesãos, um verdadeiro artista.

Why?

É o caso de Why the Luck Stiff, ou simplesmente _why. Seu trabalho mais conhecido é seu livro: Why’s (poignant) Guide to Ruby. Mesmo que você não programe, mesmo que você não entenda nem mesmo HTML, dê uma olhada.  O livro é excelente. Se parece com algo saído de uma viagem  de LSD, misturado com Alice no País das Maravilhas e lições de Ruby. E existe até uma trilha sonora para acompanhá-la!

Mas, onde encontro este livro? O site do _why saiu do ar. Assim como muitos outros projetos pertencentes a ele. Até a conta no twitter, @_why, sumiu. _why desapareceu. Ninguém sabe ninguém viu.

Where´s why?

É um feito notável para alguém que alcançou certa notoriedade online, e com uma presença forte na internet. Participou de palestras e eventos, mas sempre se identificando por seu pseudônimo.  Ainda existe o anonimato, afinal (há quem diga que _why apenas está dando um tempo e retornará como _because).

Mas dá para apreciar sua obra em alguns mirrors.  E já tratei de guardar a trilha sonora para ouvir enquanto programo. Quem sabe não tenho uma epifania (ou uma síncope, dependendo do código a editar). E tem até tradução para o português, que até onde vi está ótima.

As raposas de _why

So long _why, and thanks for all the chunky bacon.

Desenvolvedor Web

Creio que qualquer pessoa da área já ficou em dúvida de como definir o próprio trabalho.  Programador,  engenheiro de sistemas,  arquiteto de software, desenvolvedor etc.

A fronteira entre um e outro é tênue, principalmente quando você integra uma equipe pequena, e se vê trabalhando no esboço do projeto, coleta de requisitos, definição de funcionalidades, estabelecimento de layout, modelando o banco de dados e o diagrama de classes e finalmente programando tudo isso, tendo de criar e modificar códigos em diferentes linguagens e domínios: C#, SQL, JavaScript, CSS, HTML  etc. A velha história de ter de cobrar o escanteio, cabecear e defender o gol.

Programador

Na comunidade  existe um certo preconceito quanto a se definir como programador.  O fato de ser um termo genérico demais, abrigando tanto o infeliz que aprendeu PHP faz uma semana e o líder de equipe de desenvolvimento, contribui para isto. Fora a infame piada que sempre contam quando você diz que é programador: “Ah! Então você vive de progamas?” entre outras variações.

Uma boa definição para o meu trabalho, que passei a utilizar para nomeá-lo,  é Web Developer ou Desenvolvedor Web.

Web Developer

E, afinal, o que é , faz ou se espera de um Desenvolvedor Web? Segundo a Wikipedia:

A web developer is a software developer or software engineer who is specifically engaged in the development of World Wide Web applications, or distributed network applications that are run over the HTTP protocol from a web server to a web browser.

Desta curta definição pode-se apreender que um desenvolvedor web deve conhecer e ter domínio em:

  • programar em linguagens ditas de servidor - C#, Java, PHP, Ruby etc. -  e de cliente – JavaScript/ActionScript/ECMAScript;
  • manipular elementos DOM;
  • editar elementos CSS;
  • escrever textos usando HTML;
  • entender o HTTP;
  • configurar um webserver.

E com programar em eu digo que deve-se ter destreza em ao menos um,  mas conhecer vários (se existirem, claro)  frameworks para cada linguagem.

Claro que não precisa se resumir a isto. Um bom desenvolvedor deve ter conhecimentos que vão desde redes de computadores a boas práticas em programação e padrões de projeto.

No fundo, no fundo

Eu uso Desenvolvedor Web para rotular meu trabalho por ser um termo cool o suficiente para constar no cartão de visita (ou moo cards para os descolados), mas lá no fundo eu sei que sou apenas um mero digitador, e meu trabalho consiste em martelar as teclas do computador (e às vezes ter vontade de martelar o computador…).

Gerando boletos bancários em Asp.NET – Parte I

Estou em um projeto que necessita a criação de um boleto bancário para o pagamento de um serviço. Como gerá-lo, usando o Visual Studio 2008, Crystal Reports e o Linq To Sql ?

Boleto?

Vamos primeiro entender do que é composto basicamente um boleto:

  • Banco:  quem gerencia a transação;
  • Cedente:  quem vai receber a grana;
  • Sacado:  quem paga;
  • Valor do documento: quanto será pago
  • Data de vencimento: até quando pode ser pago;
  • Modalidade:  com ou sem registro. O comum para vendas online é sem registro.  Se o sacado não pagar, a responsabilidade de correr atrás é do cedente.

A entidade que padroniza os boletos no Brasil é  a Federação Brasileira de Bancos – FEBRABAN.

Continue lendo

Compilando seu Web Application Project com o MSBuild

Programar em um IDE como o Visual Studio te dá muitas facilidades. O processo de compilação fica quase imperceptível para o desenvolvedor.

O problema surge no momento em que você quer algo diferente, como compilar versões distintas do código a partir do mesmo fonte, automatizar o build no servidor etc .

Para os que já usam Makefile ou o Ant, isto é trivial. Mas isto também é simples para os que usam o Visual Studio!

Vamos ver como construir um simples arquivo para o MSBuild compilar nosso projeto.

Primeiro é necessário que você possua o MSBuild instalado. Não se preocupe,  o Visual Studio 2008 já o instala .

E onde está o diabo do msbuild.exe? Aqui:

%windir%\Microsoft.NET\Framework\

Ou melhor,  execute (com as aspas!) o seguinte comando em um terminal:

"%VS90COMNTOOLS%\..\..\VC\vcvarsall.bat"

Teste digitando msbuild.exe /help

Precisamos agora construir um makefile arquivo de instruções para o MSBuild, que chamarei de Makefile.proj:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
  ToolsVersion="3.5">
  <!-- aqui eu importo um projeto que já existe, contendo todos os
      arquivos e assemblies que fazem parte do processo de compilação-->
  <Import Project="MeuProjeto.csproj"/>
  <!-- aqui eu defino algumas variáveis úteis -->
  <PropertyGroup>
      <VersionNumber>1.0.0</VersionNumber>
      <BuildRoot>Deploy\Releases\$(VersionNumber)\</BuildRoot>
      <NewInstallDir>$(BuildRoot)Install\</NewInstallDir>
      <UpgradeDir>$(BuildRoot)Upgrade\</UpgradeDir>
      <CopyRoot>..\EruditoHAOC_PROD_test\</CopyRoot>
  </PropertyGroup>
  <ItemGroup>
      <SourceFiles Include="**\*.*" />
  </ItemGroup>
  <!-- Aqui entram as instruções para a compilação e cópia
      doas arquivos gerados para a pasta de deploy -->
  <Target Name="Build">
    <MSBuild
        Projects="MeuProjeto.sln"
        Properties="OutputPath=$(NewInstallDir)bin\" />
    <Copy
        SourceFiles="@(Content->'%(RelativeDir)%(FileName)%(Extension)')"
        DestinationFiles=
          "@(Content->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
    <Copy
        SourceFiles="@(None->'%(RelativeDir)%(FileName)%(Extension)')"
        DestinationFiles=
          "@(None->'$(NewInstallDir)%(RelativeDir)%(FileName)%(Extension)')" />
    <MakeDir
        Directories="@(Folder->'$(NewInstallDir)%(RelativeDir)')" />
    <CreateItem
        Include="$(NewInstallDir)**"
        Exclude="**\App_Themes\**;**\Web.config">
        <Output ItemName="UpgradeFiles" TaskParameter="Include" />
    </CreateItem>
    <Copy
        SourceFiles="@(UpgradeFiles)"
        DestinationFiles=
          "@(UpgradeFiles->'$(UpgradeDir)%(RecursiveDir)%(FileName)%(Extension)')" />
    <MakeDir Directories="@(Folder->'$(UpgradeDir)%(RelativeDir)')" />
  </Target>
  <!-- Um exemplo de como copiar todo o projeto para outro lugar -->
  <Target Name="Deploy">
    <Copy
      SourceFiles="@(SourceFiles)"
      DestinationFiles=
        "@(SourceFiles->'$(DeployRoot)%(RecursiveDir)%(FileName)%(Extension)')" />
  </Target>
</Project>

Para compilar seu projeto agora basta rodar o comando make msbuild.exe, da seguinte forma:

MSBuild.exe Makefile.proj /target:Build

Isto irá compilar e copiar o resultado da menira definida no xml Makefile.proj.

Referências:

Seu domínio no localhost

Da série como não pensei nisto antes?

Dica útil para quem desenvolve sistemas web e quer testar o tal sistema em condições mais próximas possíveis do ambiente de produção.

Da série como não pensei nisto antes?

Quem desenvolve sites e sistemas web precisa testar seu produto em sua própria máquina (é claro que você não desenvolve direto no servidor de produção, estou certo?). Para isto é bem útil e prático configurar um servidor Apache para rodar em seu computador, principalmente se você estiver programando em alguma linguagem server sided.

O mais legal é que é possível criar uma URL fictícia para testar seu site. Esta dica me foi dada pelo Alex.

Se você ainda não fez, instale o pacote apache2 a partir dos repositórios do Ubuntu.

Vamos então editar o arquivo hosts:

sudo gedit /etc/hosts

Com o seguinte conteúdo:

127.0.0.1 localhost
127.0.0.1 www.meudominio.xyz

Note que apenas adicionei a linha 127.0.0.1 www.meudominio.xyz
Vamos então criar o arquivo de configuração copiando o default:

cd /etc/apache2/sites-available/
sudo cp default www.meudominio.xyz

Depois edite o arquivo /etc/apache2/sites-available/www.dominio.xyz com o segunte conteúdo:

NameVirtualHost www.meudominio.xyz
<VirtualHost www.meudominio.xyz>
	ServerAdmin webmaster@localhost

	DocumentRoot /home/username/sites
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /home/username/sites/>
	...
	...

Trocando /home/username/sites pela pasta em que reside seu site. Note que o arquivo não está completo, coloquei apenas uma parte dele.

Depois habilite o site e recarregue o Apache:

sudo a2ensite www.meudominio.xyz
sudo  /etc/init.d/apache2 reload

Pronto! Teste entrando no site recém configurado: www.meudominio.xyz

Fontpark 2.0

Para quem não sabe, no fim do ano passado, 2008, ocorreu o Japan Media Arts Festival. Olhando a lista de vencedores, me interessei por esta entrada: FONTPARK 2.0, de Nakamura Yugo.

Entrei no site premiado e me surpreendi. Se trata de arte interativa da mais alta qualidade. E o que é melhor, é divertido!

A idéia é você criar alguma coisa visual:  um desenho, um logo, uma animação,  uma paisagem. Mas para isto utilizando apenas letras. E tais letras, ou caracteres para os colegas, podem ser do nosso alfabeto (que agora conta com 26 letras! ha!) ou do japonês! Milhares de opções para você montar sua ilustração,  desenho, paisagem ou o diabo que for.

Deixo com vocês minha criação:

(Já notaram que não tenho dom artístico?)

Tente você também: http://fontpark.morisawa.co.jp/

ComponentArt Grid, ServerTemplate e Linq to SQL

Micro post para reclamar e aliviar a cabeça.

Estou tentando melhorar uma listagem de dados, de forma a ficar mais simples, mais elegante e  mais versátil. É claro que o código fonte também deve ficar mais simples, mais elegante e mais versátil.  Por isso aproveitei para estudar o uso do Linq To Sql.

Fui dar uma olhada também no ComponentArt Grid. Ai de mim.

O ServerTemplate do ComponentArt Grid (CA Grid) não funciona com o LinqDataSource. Ao menos não diretamente, apenas configurando no template aspx. É preciso programar no code-behind.

Mas surge outro problema, montar expressões Linq sob demanda é complicado. É preciso Reflection e bastante persistência (do programador, não dos dados), OU utilizar o Dynamic Linq, uma mão na roda para criar expressões programaticamente.

É claro que outro (velho)  problema apareceu: controles no ServerTemplate não conseguem disparar eventos consistemente. Falham, por xemplo,  se o usuário realiza um agrupamento no Grid e logo depois tentar disparar um evento apertando algum botão do Grid.  O problema é criar o botão a ser apertado usando o ImageButton. Deve-se utilizar o LinkButton. Para qualquer caso. Na verdade esqueça que existe o ImageButton. Eu já esqueci.