Transparência inédita na saúde pública

{ March 7th, 2010 }

Autor: cmilfont

É com satisfação que vejo o trabalho da Milfont Consulting participando diretamente na transparência da saúde pública no estado do Ceará.

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

Posted in crowds, DWR, Engenharia de Software, Ext, Frameworks, Java, Linguagens, Melhores práticas, Metodologia, Métodos Ágeis, Model 3, Orientação a Objetos, Test Driven, web2.0, XP ~ 3 Comments

Criteria na JPA 2.0: Public Review!

{ December 11th, 2008 }

Autor: cmilfont

Na “Public Review” da JSR317 – que trata da JPA 2.0 – foi adicionado suporte a Criteria API na especificação. Pode ser que em menos de dois anos possamos evoluir nessa especificação e usar menos as implementações, minha esperança é que melhorem pelo menos até a versão final, programada para o início de 2009.

Como sempre criaram uma nomenclatura totalmente diferente para entidades da API, dificultando o entendimento da comunidade com anos de uso da única implementação que possuía essa API: Hibernate. Comparem a API de Criteria do Hibernate com a API de Criteria da Spec. Ok, podemos aceitar isso, política…

Faltou muita coisa ainda, mas parece que estão trabalhando para melhorar até a versão final, pelo visto DELETE_ORPHAN vai sair de alguma forma:

@Target({METHOD, FIELD}) @Retention(RUNTIME)
public @interface OneToMany {
    Class targetEntity() default void.class;
    CascadeType[] cascade() default {};
    FetchType fetch() default LAZY;
    String mappedBy() default "";   
    boolean orphanRemoval() default false;
}

Nota para os leitores:

Open Issue: We also discussed the alternative of introducing a separate annotation for the orphanRemoval functionality and the alternative of introducing a REMOVE_ORPHAN cascade
option. We would welcome feedback on the form that this metadata should take.

Não encontrei nada sobre como manipular as estratégias de fetching – que é primordial – nos relacionamentos como temos no Hibernate: Select fetching, Subselect fetching, Join fetching e Batch fetching. Nem a API de Criteria possui estratégia com FetchMode, apenas uma “Issue” aberta para a interface FetchJoinObject que deverá trabalhar isso, eu espero.

Ainda assim continuamos indicando o uso do Hibernate direto ao invés da especificação até que a especificação seja estável o suficiente com features decentes para um desenvolvimento sério em Java. A API de Criteria da implementação Hibernate continua ainda muito superior principalmente se você precisar de consultas um pouco mais avançadas.

Confiram o material e decidam.

Posted in Engenharia de Software, Linguagens, Orientação a Objetos ~ 2 Comments

SCEA com design patterns errados

{ October 28th, 2008 }

Autor: cmilfont

Once upon a time…

… A comunidade em volta da JCP adotou a aberração proposta pela SUN chamada EJB e o mecanismo de persistência seria uma JSR especialista chamada JDO. JDO seria a solução deifnitiva onde não importaria se você usa um txt, um xml ou um Banco de dados parrudo.

Com esse modelo de desenvolvimento foi criado um catálogo de Design Patterns[?] que serviria de “tábua dos 10 mandamentos” para a comunidade. Nasceu a prova de certificação em Arquiteto java com base nessa arquitetura.

Por fora da JCP uma turma se dedicou a criar uma forma de persistência específica para bancos de dados relacionais [Hibernate] onde não estavam preocupados se você guardava seus dados em um xml, queriam apenas resolver os problemas clássicos do mapeamento objeto-relacional. Outro pessoal jogava fora o modelo EJB e criava sua própria JEE [Spring] com técnicas e abordagens que surgiam como IoC, DI, Aspect Programming.

Com esse modelo de desenvolvimento, baseado sobretudo no conjunto de Design Patterns [PoEAA] da turma do Fowler, aposentaram o modelo da SUN apreciado pelos membros da JCP e redirecionaram o comitê para a aprovação de especificações copiadas desse outro modelo.

… and they lived happily ever after.

…

Opa, faltaram atualizar a prova de Arquiteto Enterprisey para adequar aos Patterns corretos. Ainda leio na ementa da prova no capítulo sobre Patterns:

• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
• From a list, select the benefits and drawbacks of a pattern drawn from the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
• From a list, select the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Posted in Certificações, Design Patterns, Engenharia de Software, Java, JSE, Melhores práticas ~ 6 Comments