Tuesday, January 24, 2006

Evento PontoNetPt: BizTalk e Windows Workflow

No evento da Comunidade PontoNetPt de 5a-feira, onde espero venham a estar presentes, a |create|it| vai fazer duas apresentações. A primeira, sobre BizTalk Server 2006, vai ser muito prática, podem contar com poucos slides e com a grande maioria do tempo a mostrar que coisas se podem fazer com o BizTalk. Esta apresentação não será específica sobre as novidades do 2006, mas sim em geral sobre as funcionalidades do BizTalk Server. Para quem já conhece o produto, não será talvez uma sessão muito interessante, mas para quem não sabe nada dele, será uma boa introdução (espero) à jóia da coroa dos servidores da Microsoft.


A segunda sessão, que vou fazer juntamente com o Raúl Ribeiro, vai ser sobre Windows Workflow (WF). O WF é possivelmente a mais interessante das novidades de fundo que foi apresentada o ano passado no PDC, e pode mudar muito a forma como se desenvolvem aplicações daqui para a frente. Para quem se lembra de aprender a programar a desenhar fluxogramas, isto vai parecer muito familiar. Vão haver 3 ou 4 demos, baseadas já na versão beta 2 (ainda fresquinha), e vai terminar com um posicionamento do WF face ao BizTalk, uma pergunta que tem aparecido muito em blogs e fóruns.


Espero ver-vos lá!


jota


 

Monday, January 16, 2006

Object Orientation, herança, gets e sets, módulos e BizTalk

No seguimento de uma apresentação do GASP no Porto, dedicada a Padrões de Desenho, e de uma recomendação nesse sentido, comecei a ler um livro chamado “Holub on Patterns: Learning Design Patterns by Looking at Code”, de um autor chamado Allen Holub. Quem o recomendou disse que tinha lhe mudado a forma de ver a programação Orientada a Objectos. Antes do livro, li um artigo... polémico do mesmo autor, intitulado "Why extends is evil", a defender a utilização de interfaces em detrimento da herança, e não utilização de herança de implementação e get/sets (se estiverem interessado no tema, recomendo também uma réplica: Why Extends is Not Evil). Recomendo vivamente este artigo, bem como os comentários sobre o mesmo. Já na leitura do livro, que é uma alternativa ao clássico "Design Patterns" do GoF, e que apesar de baseado em exemplos Java se lê e aplica a C# (obviamente), tenho encontrado algumas reflexões e comentários muito interessantes. Um destes, de que me recordei hoje ao ler o livro do João Hugo Miranda e José Almeida, "Desenvolvimento Orientado por Objectos- Domain-Driven Design, Testes Unitários e Refactoring", diz o seguinte:


 


«The real abomination in MVC architecture is the "data-bound grid control," a table-like widget that effectively encapsulates the SQL needed to fill its cells from a database. What happens when the underlying data dictionary changes? All this embedded SQL breaks. You'll have to search out every screen in the system that has a data-bound control and change that screen using a visual tool. Going to a "three-tier" system, where the UI layer talks to a layer that encapsulates the SQL, which in turn talks to the database, does nothing but make the problem worse since the code you have to modify has been distributed into more places. In any event, if the middle tier is made of machine-generated code (usually the case), then it's very existence is of little use from a maintenance point of view.
All this modifying-every-screen-by-hand business is way too much work for me. Any time savings you may have made in using some tool to produce the initial code is more than lost as soon as the code hits maintenance.»


Polémico talvez., mas o argumento faz todo o sentido.


O que me fez lembrar este excerto, por curiosidade, foi a defesa, no livro do João Hugo Miranda e José Almeida (página 67, "Módulos"), de que os módulos (assemblies) devem estar estruturados em torno de conceitos do domínio do problema, e não em torno de conceitos tipo camadas, como sejam Apresentação, Negócio e Acesso a Dados.


E isto, por sua vez :-), chamou-me a atenção porque, nos desenvolvimentos em BizTalk, a recomendação "oficial" e tida por boa prática é agrupar as coisas em assemblies por tipo de artefacto: um assembly para os schemas, outro para as orchestrations, outro para os pipelines, outro para os mapas, etc. O problema desta recomendação é óbvio: se mudarmos um schema utilizado num qualquer processo de negócio, vamos acabar a substituir uma assembly da qual dependem todos os outros componentes do projecto, e não apenas o processo que utiliza esse schema - em BizTalk, por causa das dependências, para substituir essa assembly teremos de desinstalar as assemblies que dela dependam. Parece-me que esta é uma recomendação tem de ser revista, e substituída por um agrupamento semântico (possivelmente por processo).


E finalmente, outro comentário que também tinha aqui para fazer, refere-se a convenções de codificação para BizTalk. Quase todas elas, e existem 3 ou 4 diferentes, defendem a utilização de prefixos nas próprias shapes das orquestrações. Ora se na generalidade das shapes só cabem 12 a 18 caracteres, usar prefixos como Send_ é um desperdício em termos de facilidade de leitura. Adicionalmente, os nomes que se usam nas shapes não são identificadores, mas apenas para conveniência "humana". E o ícone que acompanha a shape já a identifica como send/receive/listen/etc., por isso... para quê o prefixo? Fica aqui o link, é para um post de um Leonid Ganeline.


jota

Thursday, January 12, 2006

Office 12 Beta - primeiras impressões

Instalei ontem o Office 12 Beta numa VM, para começar a brincar com esta nova versão. Ainda só instalei as aplicações "clássicas" de Office, incluindo o Visio e o OneNote, e estou sinceramente impressionado com o que vi. As alterações de interface utilizador do Word, Excel, Access e PowerPoint são radicais, e vão surpreender muita gente. As outras aplicações da "suite" não apresentam novidades tão grandes, pelo menos em termos de interface.


Quando se pensava que não era possível inovar em termos de usabilidade deste tipo de suites Office... Vão ficar surpresos. O mais visível são as novas "toolbars" e menu de topo, mas também interessante é a possibilidade de se mudar a formatação do texto "in-place", ou seja, as opções estão onde está o rato. Muito interessante. :-) Por mim, substituía já o Office 2003 por este.


Também estive a ver por dentro o novo formato do Word. Como já devem saber, o Word (e outros) está agora baseado num novo formato, em Xml. Os novos ficheiros Word têm a extensão docx, e são Zips de vários Xml. É possível fazer alterações no Notepad2, zipar, e abrir no Word. Não vi os ficheiros das outras aplicações.


Ainda não tive oportunidade de testar as componentes mais interessantes desta versão, nomeadamente o SharePoint v3 (e o seu fiel companheiro, o FrontPage 12 - que agora é uma espécie Sancho Pança do SharePoint), nem o Office/Groove Server, também incluídos no DVD: infelizmente, a VM tinha XP e não Win 2003 SP1. Volto a isto mais tarde.


jota