Em relação a ambientes de desenvolvimento, é sabido que o Visual Studio 2005 e algumas versões do Sql Server parecem ter pequenos problemas de compatibilidade. Para contornar isto, enquanto não for corrigido definitivamente, recomendo vivamente (aliás, mesmo com XP) que se desenvolva exclusivamente em Virtual Machines, quer com o Virtual PC (o beta do 2007 está disponível no Connect e tem funcionado bastante bem) quer com o Virtual Server 2005 R2. Não sei como se comporta o Vmware sobre Vista, mas suponho que já haja alguma versão a suportá-lo.

Em relação a aspecto gráfico, o Aero é um espectáculo! 🙂 Apesar de a placa gráfica não ser nada do outro mundo (NVidia Quadro nvs120), a imagem é muito agradável e rápida q.b. para a minha utilização, apesar de ser o item mais fraco do meu Vista Performance Index (o processador e disco estão acima dos 5, os gráficos pelo 3.5). No único jogo que tenho instalado, o Company of Heroes, o desempenho aumentou das 6fps no Xp Sp2 para 10fps no Vista, o que é interessante (sempre com os drivers mais recentes).

Outro aspecto que me agrada bastante é o novo "menu de Start". Em vez da habitual navegação em menus à procura da aplicação a lançar (que ainda é possível, mas de outra forma), o acesso às aplicações é baseado na pesquisa. Se quero lançar o Word escrevo "w" e carrego em return. Os primeiros resultados da pesquisa são sempre as aplicações, depois os favoritos, e finalmente os meus documentos. Muito conveniente, e mais rápido que o método tradicional.

Um aspecto a que ainda não me habituei é o novo Windows Explorer (porque é que não consigo remover dali o "Favourite Links"?), apesar de ter detalhes interessantes, como a caixa de pesquisa. A estruturação das pastas "built-in" mudou (por exemplo, "Documents and Settings" desapareceu), agora é simplesmente c:\Users\jota\ . Aqui existe uma estrutura de pastas com Favoritos, Imagens, Pesquisas, Contactos, Documentos, Desktop, Downloads. Não tenho nada contra isto, mas nunca recorri à estrutura de pastas sugerida pelo Windows para guardar as minhas coisas, e não é agora que vou começar 🙂 . Já os gadgets são algo que tem piada, e cada vez há mais na galeria. Acho estranho o facto de serem programados em Javascript, no entanto.

Estou à espera do meu USB Apacer Handy Steno para testar o ReadyBoost.

No geral, a minha impressão é bastante positiva, e estou satisfeito com a mudança. Recomendo!

The post Windows Vista RTM: Impressões appeared first on Blog IT.

Na sala estavam muitos dos portugueses da conferência, e agradeço-lhes o apoio, bem como os comentários e ajuda de outras pessoas do GASP, como o Hugo Batista, Tiago Pascoal, Filipe Clérigo, Paulo Morgado, entre outros. Thanks people! O Zé Tó da MS não pode ajudar, porque fazia parte da organização, mas agradeço-lhe, e ao Pedro Rosa, pelo incentivo à participação.

No juri estava o Beat Schwegler, o Ron Jacobs, Juergen Pfeifer, e uma pessoa da organização do evento. Suficiente para me deixar mais nervoso do que em qualquer outra apresentação pública que tenha feito. 🙂

Não tenho o material comigo, mas quando tiver coloco aqui a apresentação.

O site da competição é este: Iron Architect.

The post Iron Architect: YEAH! :-) appeared first on Blog IT.

PS: e obrigado ao Zé Tó pelo encorajamento! 🙂

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

The post BizTalk Server Most Valuable Professional (MVP)! appeared first on Blog IT.

It is generally assumed, however, that the execution is multi-threaded. The excellent post by Scott Colestock about “parallel actions, exceptions, and timeouts…” also seems to assume this, while exploring what happens in parallel shapes, when he describes a work-around to the compile-time validation that doesn’t allow the use of a .Net object instance in more than one un-synchronized branch of the parallel shape.

To test this situation, I did the most simple test possible: I created a simple 3 branch parallel, with the following contents in each of the branches:

– An expression shape writing “start” followed by the ThreadId (Thread.CurrentThread.ManagedThreadId) to the Debug
– A delay shape
– An expression shape writing “end” followed by the ThreadId to the Debug

What I found out when I tested it, was that all the branches print out the same thread id. Plus, they are executed left to right.

Apparently, there is a scheduler that executes one shape (segment?) at a time, but all in the same thread. It is more or less obvious that BizTalk can’t just spawn more threads at will (and there is a BizTalk MaxWorkerThreads registry setting which defaults to 25), and distributing work for the existing threads would probably be too slow.

I did some additional tests, out of curiosity. I created a parallel shape with 6 branches, each containing 3 expression shapes just printing out information do debug, as shown in the following image:

The result was that the branches where fully executed left to right, and the output in the debug out was:

1 – 11 – 21 – 2 – 12 – 22 -3 – 13 – 23 – etc.

Each of the branches (“tasks”) seems to be scheduled together.
After this, I added delay shapes to the branches, as follows:

In this case, the scheduler did something different. Apparently, it schedules all the Expressions in a sequence together, but the Delays are placed at the end. This is the (deterministic) output:

1 – 2 – 3 – 4 – 14 – 5 – 15 – 6 – 16 – 11 – 21 – 12 – 22 – 13 – 23 – 24 – 25 – 26

A lot of things could be happening here. Maybe it is related to MessageBox operations, or maybe it’s by shape.
I used Lutz’ Reflector to take a quick look at BizTalk’s DLL’s, and found classes named RunSchedule and SegmentScheduler, which seem to handle some of this behaviour, but I don’t really think it’s a good idea to count on this, as it might change in future versions.

So, takeaways:

– the parallel shape is not multi-threaded, although it looks like it, and should be used only to handle specific messaging patterns;

– the execution order of the branches is done left-to-right. I don’t recommend you base your orchestration design on this information, but it might be useful in some scenarios.

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

The post BizTalk 2006: Parallel Shape and Threads appeared first on Blog IT.

Nas últimas semanas tenho tido oportunidade de testar várias versões beta do Office, e parece-me um produto com enorme potencial, e que inova em áreas que se poderia considerar ser difícil evoluir neste tipo de produtos, como a interface ao utilizador e usabilidade. Isto para nem falar dos produtos servidor (Excel, SharePoint, Forms e Groove), porque agora quando digo “Office”, referindo-me a coisas como Word ou Excel, acabo por dizer “Office Client”. 🙂

Apareçam!

jota

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

The post Office 2007: GetReady appeared first on Blog IT.

O registo pode fazer-se nos sites da Vue e da Prometric, mas o código de voucher (“TS235”) para que o exame não tenha custo já só funciona neste segundo. Notar que no registo o exame aparece listado com o código 71-235. A pouca informação que há sobre o que sai no exame está no site de learning da MS.

Mais uma nota: a Microsoft disponibilizou 5 novas e interessantes “samples” de BizTalk 2006, neste URL: http://msdn.microsoft.com/biztalk/downloads/samples/default.aspx :

– Use SSO as a [Secure] Configuration Store
– Atomic Transactions with Com+ Serviced Components in Orchestrations
– Exception Handling in Orchestrations
– Implementing Scatter and Gather Pattern
– Using the Sql Adapter with Atomic Transactions in Orchestrations

Destas, acho as duas sobre transacções especialmente interessantes, até porque ajudam a desmistificar um engano comum: o facto de as transacções atómicas no BizTalk, “as-is“, não serem transacções DTC. Nota: as soluções abrem em VS2005 Professional, mas os projectos de testes precisam da Team Suite.

Finalmente: obrigado a todos os que participaram na formação de BizTalk Server 2006, espero sinceramente que tenha valido a pena e não tenha sido demasiada informação em tão pouco tempo. 🙂

jota

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

The post BizTalk 2006 : exame 71-235 e novas samples appeared first on Blog IT.

Fica o link.

“Four years ago, Ask Slashdot asked if anyone was using a Model-Driven Architecture. The number of MDA tools are now almost overwhelming, and I strongly believe that comments to the same questions would be rather different nowadays. What are the drawbacks, difficulties and limitations of MDA? What percentage of code can actually be generated? I would like to add a few more: is it realistic to create a custom GUI rather than CRUD operations with these tools? Finally, what about Microsoft, the new competitor on the scene, and their DSL Tools?”

The post Model Driven Architecture (MDA) e DSL’s no Slashdot appeared first on Blog IT.

Na workshop foi utilizada a versão de Fevereiro 2006, em que as Dsl Tools já vêm incluídas no SDK do Visual Studio. Fez-se a construcção dos conceitos (coisas como Literais, Wildcards, representar a multiplicidade e sequenciamento, etc.), depois a criação da linguagem gráfica, e finalmente a geração de artefactos com base em “desenhos” criados. Muito parecido com o que se faz nos walkthroughs que estão incluídos nas DSL Tools, e se não se cobriram todos os temas, foi ocasião de perceber na prática o motivo para alguns dos problemas/erros mais comuns na criação de linguagens, e também de ter algum conhecimento da realidade da equipa que, em Inglaterra, está a desenvolver as tools.

Acho que a questão que mais dificuldades/erros causa nos exercícios é o mapeamento entre o Domain Model (os conceitos da linguagem) e a sua representação gráfica, a Designer Definition. A equipa que está a desenvolver as tools optou claramente por dissociar a representação gráfica da linguagem conceptual, o que se faz algum sentido não deixa de levantar questões. Uma destas, a meu ver, é que a representação gráfica pode não ser correcta perante a definição da linguagem: por exemplo, podemos especificar que um determinado conector só pode ligar quadrados verdes (conceito X) a bolas vermelhas (conceito Y), apesar de na definição da linguagem também se poder ligar o X a Z, um terceiro conceito.
Esta questão assume dimensões mais problemáticas já que não existe nem um editor visual para fazer o mapeamento entre o Domain Model e a Designer Definition, nem qualquer validador que verifique a “completude” da representação visual.

A próxima versão das DSL Tools (em final de Março?) pode ajudar a relativizar estas questões, uma vez que o Modelo e o Designer vão passar a ser definidos num mesmo ficheiro .DSL (em vez dos actuais .DSLDM e .DSLDD), com o designer no Visual Studio a permitir editar os dois.

Aquilo que a V1 das Tools não vai suportar é a possibilidade de ter formas dentro de formas, sendo que esta é talvez a segunda questão mais referida como insuficiência das tools.

Tenho andado a discutir com pessoas e pensar sobre situações em que será vantajoso desenvolver linguagens interessantes e com elevado potencial de reutilização. Parecem-me existir, globalmente, dois grandes tipos de situações: linguagens para utilização técnica e linguagens ao nível do negócio. É muito mais fácil encontrar situações interessantes de modelar no domínio Técnico que no domínio do Negócio: é trivial identificar DSLs para modelar expressões regulares, ou uma Active Directory, ou um FileSystem, ou formatos de configuração das nossas aplicações, etc., e ver as vantagens que essas mini-linguagens poderiam ter. Mais difícil é identificar situações ao nível dos requisitos do negócio, e mesmo se identificadas, perceber o que fazer com elas, que artefactos gerar.

Num Arccast com Ron Jacobs no Channel9, o Steve Cook aborda um pouco esta distinção, referindo dois pontos interessantes: primeiro, que a criação de DSL’s se deve iniciar pela análise de desenvolvimentos e situações existentes, e não por um “pensamento criativo” de coisas que podem ser interessantes; o segundo, que uma “killer application” para as DSL Tools parece ser na área dos configuradores, de código de cola entre vários módulos ou elementos das aplicações que desenvolvemos. Parece-me uma visão pouco ambiciosa, mas é claramente melhor que pedir o céu.

jota

The post Microsoft DSL Tools Workshop appeared first on Blog IT.

A sessão que o Beat fez em Lisboa foi uma versão resumida da que fez em Inglaterra com o Ingo Rammer, e cujos slides estão disponíveis no site de Arquitectura da MS UK.
(ps: se se interessam por Arquitectura, recomendo a newsletter cujo link aparece no final desta página).

A abordagem seguida na apresentação do Beat dividiu a aposta em “Software Factories” em 4 dimensões (de uma forma até mais clara do que a que está no livro com este nome):
1) Architecture Frameworks
2) Software Product Line
3) Guidance in Context
4) Model Driven Development

O primeiro investimento é auto-explicativo.

O segundo, refere-se a montar estruturas nas organizações que permitam a exploração de “Economias de Âmbito” (em oposição a Economias de Escala), em que se factorizam as semelhanças entre vários projectos realizados em componentes (assets) reutilizáveis e parametrizáveis. O livro de Software Factories entra muito mais em detalhe do que o Beat deu, mas penso que no fundo o que está em causa é apostar de forma sistemática na reutilização, uma vez que esta foi uma das grandes promessas não realizadas da Orientação por Objectos.

O terceiro, refere-se à possibilidade de dar ajuda ao programador em contexto, directamente no IDE. Aqui a aposta da Microsoft é uma coisa chamada GAT, Guidance Automation Toolkit, disponível ainda como Technology Preview. Pode pensar-se nisto (de forma muito simplificada) como um misto das templates do Visual Studio com a possibilidade de associar acções “custom” a artefactos do IDE. Recomendo o Hands-On Lab a quem tiver interesse, uma vez que é muito elucidativo.
O problema do GAT, na versão que eu testei depois do TechEd 2005, é que era complexo definir novos packages. Depois do GAT ter a sua versão definitiva, o que deverá acontecer nos próximos meses, estão previstos vários conjuntos desta guidance, por exemplo, para WCF (o ex-Indigo), o “Service BAT”, em que o Beat também está envolvido.

O quarto ponto é outro tema que me interessa bastante, e que está materializado nas DSL Tools e na aposta na modelação usando linguagens para domínios específicos, em níveis de abstracção elevados, com o objectivo de gerar artefactos dos níveis inferiores (como C#). Para mais informações, podem consultar este post, em que está o link para a apresentação que fiz sobre este tema no TechDays, ou então podem ir simplesmente ao site “oficial”, aqui.

Em relação a este tema, é sempre feito um paralelo com o UML e as suas insuficiências, sendo o UML e as DSL’s colocadas em campos opostos. Não me parece que o Beat tenha fundamentado q.b. o que disse sobre este tema, que em essência parece-me consistir no seguinte: o UML não tem um grau de objectividade que permita a geração de artefactos “vivos”, em que se produz um modelo, geram artefactos, se altera o modelo e se volta a gerar, etc. Geralmente o UML é usado para especificação e comunicação, por vezes para efectuar a primeira geração, mas a partir daí fica apenas como documentação, e eternamente desactualizado. Com as DSLs pretende-se que o modelo esteja sempre vivo, e seja efectivamente a “source”.
Acredito que esta ideia possa gerar alguma incredulidade e resistência, mas se pensarmos no caso do BizTalk, em que o código C# gerado é removido depois de compilado (ou seja, é impossível alterar à mão), ou até no Windows Workflow, que não deixa de ser uma DSL, vemos que isto é algo a que estar atento.

Foi um evento interessante, e parece-me vamos continuar a ter novidades nesta área nos próximos meses.

A terminar, aproveito para me meter com o João Hugo Miranda relativamente ao post dele sobre o evento, e especificamente sobre a eventual resitência de pessoas no “Agile Camp” relativamente a este tipo de desenvolvimentos.
Na minha opinião, e julgo que qualquer pessoa que leia até ao 4º capítulo do livro “Software Factories” vai ficar convencido do mesmo, algo tem de mudar muito rapidamente no desenvolvimento de software. Somos artesãos, cada um faz as coisas à sua maneira e ninguém faz igual, não reutilizamos como podíamos, temos ~70% do custo dos projectos em manutenção, demasiados projectos a falhar, etc. Temos muito a melhorar, como indústria, e as metodologias ágeis estão lado a lado com este tipo de esforços, independentemente de haver ou não um “Arquitecto Génio” a definir coisas à partida. Afinal, se não houvesse “Arquitectos Génios” na Microsoft ou Sun, não tínhamos a .Net Framework (e o Add Web Reference, que é uma espécie de Recipe do GAT) ou as Java Foundation Classes.

Já agora, aproveito para vos referir para um interessante podcast do Channel9 chamado “Developer 2.0”. Este podcast é com o Ron Jacobs e o Harry Pierson (ambos da Microsoft), e levanta questões bastante interessantes relativamente ao presente do desenvolvimento de software. Deixo uma questão como motivação: já pensaram que o que acontece nas fábricas de texteis, por exemplo, que são deslocalizadas para locais onde os custos de produção são mais baixos, é exactamente o mesmo que está a acontecer com o outsourcing do desenvolvimento para a Índia, apesar de serem indústrias totalmente diferentes e as pessoas terem competências completamente distintas? (serão mesmo?)

jota

The post Microsoft Architect Forum 2006 – Lisboa appeared first on Blog IT.

O princípio essencial que suporta esta potencialidade é o facto de tudo aquilo que é usado nos desenhos das orquestrações ser serializável. Isto aplica-se não só às mensagens, mas também a todas as variáveis: todos os tipos utilizados têm de ser serializáveis. [Nota: há duas excepções: a classe XmlDocument, que não é serializável mas com que o BizTalk consegue lidar, e objectos declarados dentro de transacções atómicas, que não necessitam de ser serializáveis porque o BizTalk não faz serializações dentro dessas transacções].

Tendo isto como base, o BizTalk tem durante a sua execução um conjunto de chamados “Pontos de Persistência”, locais em que decide serializar tudo o que tem em memória (todas as mensagens, objectos, contexto de execução, etc.) para uma das base de dados em que está suportado. Estes pontos de persistência ocorrem em locais conhecidos e documentados da execução dos processos:

– quando termina uma transacção;
– quando se chega a um breakpoint;
– sempre que se envia uma mensagem;
(etc.)

A principal vantagem deste mecanismo é possivelmente o sustentar a grande fiabilidade do produto, mas outra de referir é que se todo o estado de um processo pode ser guardado em base de dados para ser restaurando mais tarde, isto quer dizer que a execução até pode ser retomada por um servidor diferente daquele em que foi efectuada a serialização… Por outro lado, no entanto, quando mais pontos de persistência, maior o impacto no desempenho, especialmente se existirem muitos ou objectos muito grandes num processo BizTalk.

Para controlar esta situação, além de algumas optimizações que se podem fazer, a minha recomendação pessoal é utilizarem-se os Performance Counters do produto durante os testes à solução. Note-se que o BizTalk é para ser utilizado principalmente em cenário assíncronos, pelo que ter uma resposta ultra-rápida geralmente não será algo de crítico, mas ainda assim um elevado “throughput” pode ser necessário. De entre os vários PerfCounters, alguns a que presto especial atenção são, na categoria “XLANG/s Orchestations”, os seguintes:

– Persistence Points (total acumulado)
– Persistence Points/sec
– Running Orchestrations

Olhar para estes indicadores ao mesmo tempo que se fazem testes, por exemplo usando tools como o LoadGen ou o BizUnit, pode ajudar bastante a fazer “tunning” dos nossos processos.

jota

Ps: conhecer como funciona a serialização é, na minha opinião, essencial para quem programa em .Net, mesmo sem usar BizTalk. Para quem quiser aprender, recomendo por exemplo este tutorial do TopXml (PDF).

The post BizTalk 2004/2006: Persistência e Performance Counters appeared first on Blog IT.