Fórum: arquitetura – Discussão: Nomes de classes, métodos e atributos em português

Eu escrevo nos termos do que parece mais natural para a equipe e o domínio.
Misturo tudo, inglês e português, mas com objetivo de ser mais legível.

Não me vejo traduzindo palavras como “Controller”, “Factory”, getters/setters etc. Mas se estou fazendo para controlar cursos, não quero escrever “Curso” ou “Aluno” em inglês porque o dia a dia é falado em português. Então acabo com diversos “CursoFactory” ou “Alunos.all”. Não vejo problema nisso.

Fórum: arquitetura – Discussão: hashbang nas URLs

Eu sou completamente contrário a isso. Aliás é algo que tenho twitado bastante contra (e até já discuti com um cara do Twitter sobre isso).

O correto é usar a nova History API do HTML5, ainda mais agora que até o IE suporta.

E um ótimo post sobre como fazer URLs direito é esse do Github:
http://warpspire.com/posts/url-design/

Fórum: arquitetura – Discussão: JSF + Spring no GAE - recomendam?

É verdade, com muitos poucos acessos, a chance do request que vai subir o contexto ser do serviço de monitoração é alta…

Fórum: arquitetura – Discussão: JSF + Spring no GAE - recomendam?

Oi Welkson!

Essa solução, infelizmente, não vai resolver completamente. Pingar o Site resolve o Cold Start associado a Sites de pouco acesso que são tirados da memória de fica um tempo curto sem acesso. Para resolver isso, beleza.

Mas isso não vai impedir que seu contexto seja startado várias vezes ao dia. Como falei antes, eu uso o AlwaysOn, que segura 3 instâncias na memória sempre ligadas, um serviço feito justo pensando no caso de sites pequenos cujo volume de acessos não seguraria as instâncias.

Mas mesmo com o AlwaysOn, ainda contabilizo uns 30 startups por dia, e vários em user requests.

Aliás, você pode ver o número de startups na sua aplicação procurando por “loading_request=1” nos Logs.

Abraços

Fórum: arquitetura – Discussão: Há riscos em hospedar uma aplicação Java no GAE (Google App Engine)?

O MySQL será parte do novo AppEngine for Business que ainda não foi lançado:

http://code.google.com/appengine/business/#feat…

Eles começaram os testes em Beta com algumas pessoas mas ainda não há informações públicas. Mas te adianto que é um MySQL normal rodando lá que você pode conectar via JDBC, Hibernate etc.

Fórum: arquitetura – Discussão: JSF + Spring no GAE - recomendam?

Nunca tive problemas no Mac com o plugin do Eclipse e o Datanucleus. Ele só é lento e ruim mesmo, mas nunca travou aqui

Fórum: arquitetura – Discussão: JSF + Spring no GAE - recomendam?

Oi Welkson!

Os problemas do GAE estão sendo resolvidos um por um, ainda bem. Desde aquela palestra no QCon, muita coisa mudou. Algumas dicas do que tenho sentido ultimamente:

1) Somos usuários do AlwaysOn desde o primeiro dia do serviço. Realmente minimizou bastante o problema do Cold Start, ainda mais por conta dos Warm Up Requests (ele tenta prever que vai precisar de uma nova instância e dispara um request interno ao invés de ser um request de usuário).

Porém, nem tudo são flores. O Cold Start ainda existe e ainda pega vários requests de usuários. Hoje no caelum.com.br conto cerca de 30 inicializações de instâncias diferentes por dia, mesmo com o AlwaysOn! Dessas, acho que de 15 a 20 ainda são requests de usuário sofrendo o Cold Start.

Mas é o que você falou: toda hora que acessa o site da Caelum parece ser bem rápido. É porque a chance de você ser um dos 20 infelizes que sofrem Cold Start (em milhares de requests) é pequena. Mas ela existe. (PS. a rapidez do Site se deve também às várias otimizações client-side que fazemos, mas isso é outro assunto :)

2) Eu não gosto do Spring e do JSF pro GAE. No caelum.com.br usamos o VRaptor, que por padrão tem o Spring por trás. Trocamos pelo Pico e ganhamos bastante performance no startup (ainda mais sem fazer scanning de classes no startup).

3) JDO/JPA no GAE é outro problema. O Datanucleus é bem lerdo, tanto no startup quanto na hora de usar. A alternativa que estamos usando é o Objectify, bem mais rápido. Mas estamos testando também a versão beta do MySQL no GAE, o que permitiria usar JDBC ou Hibernate puro no GAE sem a porcaria do Datanucleus. Mas ainda é beta e não foi aberto ao público

Abraços

Fórum: arquitetura – Discussão: Taxa de Acesso de Grandes Sites

Quando digo parar de se preocupar com escalabilidade é que tem alguém se preocupando com isso por você, não que seja menos importante. Você foca em construir a aplicação, foca em performance se for o caso (cloud não tem nada a ver com performance) e, se construir ela adequadamente, a infra de seu provedor de cloud cuida da escalabilidade.

Claro que haverá um custo, sempre há. Mas cloud é bem mais barato que infra própria, ordens de magnitude mais barato. Use até esse argumento caso precise convencer algum cliente. Se o medo dele for estourar um certo budget, todo provider de cloud permite colocar um valor máximo para seu budget e ele não estoura nunca o tanto que você reservou.

Pensando apenas em escalabilidade (o tema da pergunta original, pelo que entendi), cloud é imbatível. As outras vantagens são elasticidade, custo baixo, disponibilidade.

Mas claro que há desvantagens também. As mais citadas costumam ser vendor lock-in, preocupação com confidencialidade e não estar 100% no controle.

É seu papel como arquiteto pesar todos os pontos e decidir se é a melhor opção para seu projeto ou não. Aqui na Caelum, temos caminhado cada vez mais para colocar tudo em serviços de cloud, tanto PaaS, IaaS e SaaS. Estou até terminando um post no nosso blog comentando o que temos usado ultimamente…

Abraços

Fórum: arquitetura – Discussão: Taxa de Acesso de Grandes Sites

Por isso que gosto de cloud computing e elasticidade infinita! Parar de nos preocuparmos com isso…

Um cenário de um site pequeno, bem pequeno: o site da Caelum, caelum.com.br. Não é um grande portal e não tem milhões de visitas. O número de requests por segundo gira em torno de 1.5 a 2 durante o dia. Bem pouco, certo?

Mas aí, 1 vez por mês, mandamos uma newsletter da Caelum para milhares de pessoas e, em uma janela de menos de 10 min, a média de requests/segundo sobre para algo em torno de 20 a 30. Um salto de mais de 10x em um curto espaço de tempo.

Antigamente, o sistema capotava nesses picos altos e excepcionais. Mas justo no momento de maior interesse dos usuários, com maior potencial para a empresa, não aguentávamos. Hoje, usamos o Google AppEngine e os picos podem bater na estratosfera que não nos preocupamos.

E aqui a questão não é tanto subir de 2 para 20 requests/segundo – números baixos comparados a sites médios e grandes. Mas ser capaz de escalar elasticamente até um número absurdo se necessário. E se você estimar 100 req/sec no cenário superestimado e um belo dia chegam 200 req/sec?

Abraços

Fórum: arquitetura – Discussão: Acoplar com minhas classes ou com as do FW? DI

Com Spring, a ideia é você não chamar o getBean nunca, e nunca invocar o ApplicationContext diretamente.

Claro, haverá um código que precisa fazer essas coisas e em geral é um pequeno código de Bootstrap, a única parte do seu sistema que teria acoplamento com o framework. E se você estiver em um projeto Java EE, 99% de chances que já existe esse código de bootstrap pronto pra você na integração com os outros frameworks (Struts, JSF, VRaptor etc etc)

Chamar o getBean no meio do código é uma má prática e não é nem Inversão de Controle nem Injeção de Dependências.

Abraços

Fórum: arquitetura – Discussão: Spring 3.0 @Interceptor

O AspectJ hoje não precisa mais de pós compilação. O AspectJ é inteiro baseado em anotações e faz a mágica em Runtime. É inclusive a base do SpringAOP

Fórum: arquitetura – Discussão: Separando Layers em Tiers

Os maiores problemas de se quebrar em 2 tiers são aumento na complexidade, perda de performance e, principalmente, o que se sacrifica no design da aplicação (pense em DTOs, Façades etc). Não é a toa que o Fowler, já em 2003, no seu POEEA formulou a famosa First Law de objetos distribuídos.

Já os maiores argumentos (válidos) para se fazer a separação são: escalabilidade, disponibilidade e integração com diversos clients. (meio o que o Júlio e o Urubatan falaram)

Porém, acredito que os 3 podem ser resolvidos sem essa separação, com tudo na Web Tier por exemplo.

- Escalabilidade: escalar individualmente Web e App não parece ser mais vantajoso que escalar apenas Web se tudo estiver lá dentro. Um cluster de Tomcats escala infinitamente.

- Disponibilidade: mesma coisa. Um cluster de JBoss com um bom load balancer te dá a disponibilidade necessária.

- Integração: usando linguagem Javeira, EJB é péssimo pra integração. Talvez em um caso ou outro ainda se salve, mas em pleno 2011 falar que vai usar EJB (ou RMI, Corba etc) para integrar sistemas diferentes parece retrógrado. As tecnologias de integração atuais são todas baseadas em Web (SOAP, REST, “CRUD Services”) pois percebeu-se que era uma ideia melhor, ainda mais pensando em clientes heterogêneos. Portanto, se você vai de web para integração, porque quebrar os tiers? Deixa tudo no Web Tier mesmo e seja feliz

Fórum: arquitetura – Discussão: Invocacão de operadores: pré, in e pós fix

É, assumi que era Java. Como não conheço Ruby a fundo, não entendi direito as duas soluções que você passou, mas imagino alguma maluquice dinâmica da linguagem :)

E pra ter mais exemplos em outras linguagens, Scala é uma bem bonita pra DSLs. Consigo o seguinte código:

Implementação aqui: https://gist.github.com/742289

Fórum: arquitetura – Discussão: Invocacão de operadores: pré, in e pós fix

Bom, acho que não é só a leitura da invocação que conta na hora de decidir a abordagem a ser usada. Acho que devemos pensar em encapsulamento e SoC na hora de decidir qual objeto tem qual método.

Por exemplo, a terceira abordagem que você citou “cliente.debita(500).da(conta)” faria a classe Cliente ter o método debita(). E muito provalvelmente, mais todos os métodos associados a movimentações financeiras e mais um pouco. Acho ruim colocar isso tudo no Cliente, que ficaria com responsabilidade demais. Prefiro uma classe Conta com esses métodos, mesmo que a leitura da invocação não fique tão bonita.

E falando de linguagens e DSLs, Smalltalk é uma excelente linguagem pra evitar esse monte de métodos Java pequenos como o da() só pra frase fazer sentido. Pegando o último exemplo, criaríamos um único método debita:da que teria invocação assim em Smalltalk:

cliente debita: 500 da: conta.

Fórum: arquitetura – Discussão: Legibilidade de código em ifs

Pelo que entendi, a pergunta não é se deve usar if ou não, mas sim se deve extrair os condicionais para métodos auxiliares.

Eu acho extremamente válido ter pequenos métodos que encapsulem condições mais complicadas. Não sei se apenas aquele “x > y” do seu exemplo eu extrairia, mas condições um pouco mais complexas, sim. Se a preocupação dos seus colegas em extrair métodos pequenos que serão chamados só uma vez é performance, isso não faz muito sentido porque as otimizações do JIT compiler vão acabar fazendo inline desse método, por exemplo.

Por fim, uma coisa que gosto de fazer é colocar vários desses condicionais dentro do próprio bean ao invés de colocar na lógica. Imagine que você tem uma loja virtual que precisa ver se o carrinho de compras é positivo antes de fechar a compras:

Para extrair aquela condição do if, ao invés de colocar na mesma classe de Action, eu colocaria no Carrinho:

Abraços

Fórum: arquitetura – Discussão: Definição de interface em O.O.

A melhor referência sobre Interfaces em OO e sobre o que são tipos que li até hoje é o capítulo introdutório do Design Patterns, GoF, que achei fastástico. Uma leitura que considero absolutamente obrigatória (a introdução, o resto do livro é um porre :)

A primeira coisa é diferenciar a palavra chave “interface” do Java do conceito de interface de OO (eu costumo chamar de “interface de uso” quando dou aula, pra não confundir o aluno). E isso existe em qualquer linguagem OO. Então, Paniz, o exemplo que você deu é sim de interface.

A definição de interface de um objeto é basicamente o conjunto de assinaturas dos métodos expostos por ele (o contrato mesmo). E dá-se o nome de tipo a alguma determinada interface (ou seja, um conjunto de métodos) que tenha um significado especial. Um objeto pode ter vários tipos se obedecer as interfaces definidas por todos eles.

E a grande diferença entre uma linguagem dinâmica como Ruby e uma estática como Java é como garantir determinada interface. Em Java, a interface é garantida pelo compilador; em Ruby, o contrato é mais boca a boca, mas ainda existe.

@matiello
Não entendi o que você quis dizer sobre valores. Dados? Atributos?
(se for, eles estão fora da interface; a interface é sobre os métodos)

Fórum: arquitetura – Discussão: Lucene no AppEngine

A melhor referência de uso do Lucene no GAE é esse projeto: http://code.google.com/p/thoughtsite/

É um demo do uso do Lucene indexando suas entidades e persistindo os índices no próprio Datastore. Parece bem legal, mas eu nunca usei.

Fórum: arquitetura – Discussão: Objetos imutáveis

Eu uso sempre unmodifiableList e a exceção unchecked não me atrapalha (pra falar a verdade é melhor, porque não enche o saco como as checked). Mas claro que seria legal se houvesse uma interface ImutableList ou algo assim, ia ficar mais elegante.

E nos Dates e Calendars você pode usar o clone também, fica um pouco mais curto.

Fórum: arquitetura – Discussão: [Anúncio] Aula aberta na Caelum com GTUG sobre Google AppEngine

A Caelum e o Google Technology User Group de SP convidam para a aula aberta sobre Google AppEngine dia 30 de setembro às 19h45. Teremos duas apresentações:

- Paulo Fernandes, líder do GTUG SP, fará uma apresentação da plataforma do Google AppEngine
- Pedro Matiello e Sérgio Lopes, ambos da Caelum, farão uma apresentação prática de VRaptor no GAE

As inscrições são gratuitas mas as vagas limitadas! Para saber mais sobre o evento e fazer sua inscrição, acesse:

http://www.caelum.com.br/evento/gtug-appengine/

Fórum: arquitetura – Discussão: Armazenamento eficiente com Objectify e Startup otimizado em aplicações do Google App Engine

Não conhecia esse stale-while-revalidate. É padrão HTTP?
Preciso testar se o proxy do GAE suporta essa feature.

Mas eu não entendi como funciona, qual header devo colocar (o link tem um monte de código Ruby mas imagino que a parte HTTP deve ser simples). Você sabe?

PS. Precisa só ver se a gente não esbarra nas duas maiores restrições do GAE quando a gente fala do Cold Start: não poder fazer coisas em paralelo; e não poder dar flush no response antes do processamento do request acabar.