sexta-feira, 22 de maio de 2009

httpModules e httpHandlers (ashx)

Na última semana o ISEL esteve nas instalações da Simple Solutions a dar uma formação avançada em desenvolvimento Asp.Net. Um dos objectivos era perceber a sequência de geração de eventos no HTTP Pipeline, para a construção de páginas aspx. Identificámos os eventos que mais se adequam a cada situação e a forma correcta de os utilizar, diminuindo por exemplo, o efeito do ViewState.

Dois dos assuntos de que falámos foram os httpModules e httpHandlers. Deixo aqui uma pequena descrição da sua implementação e em que situações devem ser utilizados.

httpModules

A utilizar em situações que queiramos um controlo de entrada ou saída sobre todos os pedidos na aplicação. Exemplos: cifrar a query string, verificar permissões de acessos a recursos (pode entrar na página?).

Implementação:

Registar no Web.config
<system.web>
<httpModules>
<add type="Isel.Handler.RequestTimeModule" name="RequestTimeModule"/>
</httpModules>
</system.web>
Criar uma classe que implementa a interface IHttpModule
namespace Empresa.Aplicacao {
public class RequestTimeModule: IHttpModule {
No evento Init registar os eventos que querem utilizar
public void Init(HttpApplication context) {
context.BeginRequest += new EventHandler(context_BeginRequest);
context.EndRequest += new EventHandler(context_EndRequest);
}
Implementar o código nos eventos registados
void context_BeginRequest(object sender, EventArgs e) {
HttpContext.Current.Items["start"] = DateTime.Now;
}

void context_EndRequest(object sender, EventArgs e) {
if (HttpContext.Current.Response.ContentType == "text/html") {
HttpContext.Current.Response.Write("<p>" + (DateTime.Now -Convert.ToDateTime(HttpContext.Current.Items["start"])) + "</p>");
}
}

httpHandlers (ashx)

A utilizar sempre que quisermos gerar informação a partir da aplicação sem passar por todo o processamento de uma página. Exemplos: gerar imagens a partir da BD, exportação de informação para ficheiros Excel ou XML.

Implementação:

Não é necessário registar nada no Web.config porque o handler ashx já vem de raiz com a plataforma.

Criar uma classe que implementa a interface IHttpModule. No caso de ser necessário acesso à Session, implementar também IRequiresSessionState.
namespace Empresa.Aplicacao.Handler {
public class Exportar : IHttpHandler, IRequiresSessionState {
Definir o evento IsReusable
public bool IsReusable {
get { return true; }
}
Implementar o código no evento ProcessRequest
public void ProcessRequest(HttpContext context) {
try {
string userName = context.User.Identity.Name;
if (userName != null && userName != "") {

string titulo = "";
if (context.Session["ExportarTitulo"] != null && context.Session["ExportarTitulo"].ToString() != "")
titulo = context.Session["ExportarTitulo"].ToString();

if (context.Session["ExportarParametros"] != null & context.Session["ExportarSP"] != null && context.Session["ExportarSP"].ToString() != "") {

context.Response.ContentType = "application/vnd.ms-excel";
context.Response.AddHeader("content-disposition", "attachment;filename=" + titulo + ".xls");
context.Response.Charset = "utf-8";

Regras.Entidade obj = new Regras.Entidade(null, origemErro, userName);
DataSet dSet = obj.Selecciona(context.Session["ExportarSP"].ToString(),
(Regras.Parametro[])context.Session["ExportarParametros"]);

GridView gridLista = new GridView();
gridLista.DataSource = dSet.Tables[0];
gridLista.DataBind();

System.Web.UI.HtmlTextWriter html = new System.Web.UI.HtmlTextWriter(context.Response.Output);

gridLista.RenderControl(html);
}
}
}
catch (Exception ex) {
context.Response.Redirect(ConfigurationManager.AppSettings["NomeApp"] + "Erro.aspx?erro=" + ex.Message);
}
}
Podemos inclusive fazer o override ao comportamento de qualquer tipo de recurso numa aplicação Web.
<httpHandlers>
<add verb="*" path="*.jpg" type="Empresa.Aplicacao.Imagem"/>
</httpHandlers>
Neste caso todos os ficheiros JPEG pedidos à aplicação passam pelo ProcessRequest do tipo “Empresa.Aplicacao.Imagem”.

quarta-feira, 22 de abril de 2009

Scrum ? O prazer de planear, gerir e executar …

Scrum é um processo interactivo e incremental para o desenvolvimento de produtos ou para a gestão de tarefas. A agilidade que suporta esta metodologia de gestão e planeamento, traz uma nova dimensão na capacidade de resposta, adequabilidade, eficácia e eficiência na gestão actual dos processos.” – by http://scrumpt.com/

Quando leio esta definição, questiono-me “ - Como é que eu poderia pensar o quão bom e inovador era abrir o Visio, fazer uns desenhos… Abrir o Project, definir umas tarefas, atribui-las… e fazer umas reuniões mensais?”. Hoje vejo, que tal pensamento se enquadra fora da realidade do que pode e deve ser uma gestão completa e eficiente de um projecto de software.
Mas comecemos do início. Longe vão os tempos em que me sentava numa cadeira na faculdade para ouvir os professores falarem (e quando o assunto era análise de sistemas) do UML, que primeiro era preciso analisar e só depois desenvolver. Sempre fui dessa opinião também, e ainda hoje acredito que é preferível gastar ¾ do tempo a planear e o resto a desenvolver. Isto porque, nunca é demais conhecer o sistema que estamos a desenvolver, conhecer o problema que temos entre mãos. Até aqui a teoria encaixava na perfeição, o pior estava para vir com a prática.

Com o entrar na vida profissional, constato que as coisas nem sempre acontecem como se espera, ou melhor, quase nunca. E hoje que escrevo este artigo, vem-me á memória o último projecto de grandes dimensões em que entrei. Um projecto grande no inicio que se transformou em megalómano. Um cliente exigente, que coloca vários desafios, propõe várias funcionalidades a cada reunião realizada e o sistema dispara. Cada vez que achávamos que tínhamos os requisitos prontos, vinha o cliente e dizia “ – Falta isto. - Era bom que o sistema fizesse isto. “ Chegámos a uma fase que estávamos a desenvolver em velocidade cruzeiro e o levantamento de requisitos ainda não tinha terminado. Situação impensável, cria-se um desgaste na relação cliente/equipa de desenvolvimento, sucedem-se reuniões atrás de reuniões, a maior parte delas inconclusivas e improdutivas. Conclusão, o sistema vai atrasando.

- Para onde caminhar?”, é esta a questão que se coloca perante este cenário. Após algum tempo investido da minha parte em alguns produtos e soluções, há um que se destaca… Scrum. “- Será a solução? “. O Scrum é um processo que nos ajuda a gerir projectos de uma forma hábil. Os seus primórdios tiveram origem no sector automóvel, onde equipas pequenas e multidisciplinares conseguiam melhores resultados. Em 1995, um senhor chamado Ken Schwaber implementa e adapta este mecanismo em desenvolvimento de software. A indústria de software aceita muito bem esta metodologia. “- E porquê?”. Digamos que, de entre os vários interesses que a plataforma despertou, destaco o facto de podermos estimular e intensificar o contacto cliente/equipa de desenvolvimento, através da interrupção do projecto em períodos regulares de tempo. A estas acções dá-se o nome de Sprint. No fim de cada acção o cliente recebe as funcionalidades desenvolvidas, comprometendo-se a utilizá-las, a testá-las, apontando as qualidades assim como os defeitos.

A participação activa por parte do cliente torna-o não um mero comprador de software, mas sim um elo importante no desenvolvimento de todo o sistema, na criação do produto, contribuindo na pesquisa de requisitos, na análise, na formalização de tempos, na execução, nos testes, etc, responsabilizando-o durante todo o processo.

Alguns motivos que justificam a implementação desta prática:

· As mudanças são bem vindas e não alteram a produtividade;
· O cliente participa nas reuniões e vê o produto (sistema) a ser construído;
· A equipa produz o que foi previsto e pode ir acompanhando os resultados diariamente;
· A equipa determina a complexidade da “funcionalidade” e a mesma é debatida até que todos tenham “entendido”, com a participação do cliente;
· Todos os envolvidos conhecem o que deve ser feito e todos contribuem;
· A equipa trabalha em colaboração;
· Maior comprometimento da equipa;
· Mais tempo para o Scrum Master (Gestor de Projecto) concentrar sua atenção no que realmente interessa e não apenas em relatórios;
· A equipa consegue trabalhar e concentrar esforços no que é realmente importante no momento;

Enumeremos alguns conceitos úteis:

Entidades

· Cliente ou PO (product owner)- define as funcionalidades do produto, datas de lançamento e conteúdo, faz ajustes de funcionalidade e prioridade e aceita ou rejeita resultados obtidos;
· ScrumMaster ou Gestor de Projecto – representa a entidade responsável para o projecto, responsável pela aplicação dos valores e pelas práticas do Scrum, garante produtividade e funcionalidade da equipa e serve como filtro de interferências externas;
· Equipa de Desenvolvimento – trabalha de maneira auto-organizável, em grupos de 5 a 9 pessoas, é multifuncional (programadores, testers, designers, etc.) e só pode trocar de equipa no próximo Sprint;

Itens

· Product backlog – é o que deseja desenvolver-se no projecto, é uma lista que estabelece as actividades de acordo com a vontade do cliente;
· Sprint backlog – é o que será desenvolvido, conjunto de tarefas organizado temporariamente, com cronograma e tempo de execução;
· Burndown charts – é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo;

Metodologia

· Planeamento – a equipa selecciona os itens do Product Backlog que irá comprometidamente executar; cria-se o Sprint Backlog, tarefas são identificadas e o tempo é estimado (1 a 16 horas);
· Revisão – a equipa demonstra o que foi realizado durante o Sprint. Geralmente, trata-se de uma reunião informal para abordar novas funcionalidades e estrutura do projecto;
· Retrospectiva – é realizada após cada Sprint e tem como objectivo ver o que funciona e o que não funciona. Toda a equipa participa na retrospectiva, inclusive o cliente;
· Reunião diária – são tipicamente rápidas, realizadas em pé e duram cerca de 15 ou 30 minutos. Assim, mantém-se o foco no que está a ser desenvolvido.