Fórum: arquitetura – Discussão: Como atingir a Senioridade?

Assumindo que não existe ninguem sem conhecimento nenhum. Não existe ninguém que conhece tudo. O “junior” aprende com o “senior” e vice-versa.
Para ser “senior” antigamente significa ter mais responsibilidades em suas ações e conhecer mais coisas.

Ao meu ver, mais importante que os rótulos (e moldes) de 50 anos atrás, ou tentarmos nos adaptar aos mesmos rótulos com um formato distinto, é percebermos qual a classificação que nos importa.

Para mim, existem algumas fases e essas fases se repetem no mesmo indivíduo dependendo do que ele está fazendo: a fase onde ele é capaz de ver o que está na sua frente, a fase em que questiona o que está na sua frente, e a fase em que pensa nas implicações fora daquilo que ele alcança – as implicações de suas decisões em partes intangíveis de um sistema: as implicações delas no futuro do sistema.

Vou e volto entre essas fases. O tempo todo. Em tecnologias. Em metodologias. Em práticas. E é dessa maneira que aprendo com os outros… e não faltam coisas a aprender.

Fórum: arquitetura – Discussão: Desempenho do Grails 1.4 bate Scala (Play e Lift) e chega próximo ao JSP

Não sou muito fã desse tipo de comparação. Se eu fizer um sistema que faz centenas de requisições para a mesma página com a mesma lista na memória já sei qual framework é mais rápido.

Se eu fizer qualquer site diferente disso, não sei mais.
Ele não usou banco, o que tira da frente qualquer proporcionalidade: se o acesso ao banco demorar 10x que o processamento do framework, o framework (quase) não afeta o sistema. Se o sistema não usa cache (independente de framework) provavelmente o cache afeta 10x mais que o framework.

Tem muita coisa deixada de fora em benchmarks assim. Como os frameworks lidarão com o mesmo usuário acessando dados stateful que ele mantem (mesmo que só o usuário logado), ou algum dado de permissão que ele tem (no banco? na session?).

A aplicação padrão está muito longe da desenhada por ele, por isso só acredito que o benchmark dele é válido para aplicações como a dele.

Abraço!

Fórum: arquitetura – Discussão: IFs malditos

TUdo bem Diego?

Você pode criar a lista básica de nomes:
String[] nomes = new String[]{"a", “b”, "c"};

Definir um método que gera o File baseado no nome:
File getFileFor(String nome) { return new File(“c:\” + nome); }

E agora fazer o for:
for(String nome : nomes) {
facaOQueQuiserComSeu(getFileFor(nome));
}

Pode usar tambem uma maneira funcional como a sugerida do groovy usando bibliotecas de filter para collections.

ps: cuidado com o c:\ pois você nunca sabe onde seu programa rodará daqui uns meses.

Abraço!

Fórum: arquitetura – Discussão: Organização das Views (JSP) x Métodos (Controller) com VRaptor

Oi Leandro,

Não gosto de ifs de negócio na view. Cada componente (widget ou similar) da view possui um propósito. Por isso prefiro, quando possível, usar includes e separar partes da view com própositos distintos em jsps (ou outro) distinto do que misturar tudo.

Abraço

Fórum: arquitetura – Discussão: Static, OO e classes *Utils

Vinicius, perfeito… se não quebra encapsulamento, sem problemas.

Rafael, perfeito tambem. Se não tem variaveis em escopo, é uma função solta. Static nela. EM outro mundo ela seria uma funcao solta tambem.
Creio que a unica maneira de iniciar a instanciacao de um objeto é atraves de uma funcao solta, então seja um new, ou um outro método, ok tambem. Melhor ainda se brincar com DI.

Fórum: arquitetura – Discussão: Static, OO e classes *Utils

Quaiato, os extensions mthods tem acesso a variaveis membro? Em scala os implicits não tem, é composição, não abertura de classe.

Abraço!

Fórum: arquitetura – Discussão: Uso de overloads (sobrecargas) indevidamente? E como resolver?

No segundo exemplo, o metodo é usado para assumir valores default. Algumas linguagens permitem setar o valor default. Tudo depende se você precisa ou não deixar um deles opcional: infelizmente as vezes é o caso.

O primeiro exemplo é de execução de acordo com tipagem. Você pode substituir por polimorfismo na lata, move o metodo fazAlgumaCoisa para a classe A e B, extrai interface:
x.fazAlgumaCoisa()
Pronto. (as vezes vc vai querer, as vezes não, as vezes vai delegar para um terceiro)

Existe um terceiro caso, que é o caso semanticamente errado. É quando voce tem dois metodos com o mesmo nome e que fazem coisas distintas. Pessima opção. A semantica contida no nome do metodo é importantissima… usar o mesmo nome para dois significados distintos só ajuda a confundir a responsabilidade da classe e do metodo.

Principalmente em Ruby, que herança multipla com mixin permite quebrar sua app.

Abraçø

Fórum: arquitetura – Discussão: Static, OO e classes *Utils

Oi Renato,

É como um construtor. Você não precisa de um objeto para construi-lo (ou ele é um metodo do objeto que representa a classe, em algumas linguagens). Mas se ele não altera variaveis globais, você pode chama-lo quantas vezes quiser, sem uma vez quebrar a outra. Não existe estado compartilhado entre o que é devolvido pela invocacao do metodo duas vezes.

Se o metodo retorna um objeto que alterará uma variavel “global” (ou um singleton) você comeca a correr risco: esta compartilhando memoria entre dois acessos e vai incorrer em todos os problemas de encapsulamento.

Melhor com 2 exemplos?

Fórum: arquitetura – Discussão: Static, OO e classes *Utils

Um método estático é um que tem acesso somente a variáveis globais. Muitos metodos estaticos que se invocam indica programação procedural: fuga total de controle de escopo. Não é um design bom (vide as vantagens de OO e de funcional).

Métodos estaticos que controlam acesso a variaveis mutaveis é o caso ruim. “Variaveis imutaveis” não tem problema (o método é reentrante?). Pois invoca-lo nao causa efeito colateral que a segunda invocacao causara loucuras. Ou ainda o que foi devolvido nao afetara o resultado de futuras invocações (quebra de encapsulamento).

Por isso metodos estaticos para fabricar dados, tudo bem, desde que não altere estado. Exemplo desses metodos? Que nao usam a palavra static mas é util? QUando chamamos new em um construtor educado. Não tem problema.

O Guava, o Hamcrest etc, são inteligentes nesse sentido: não há estado mutável. Essa é a diferença do static zoado (com variáveis globais mutaveis, conhecido como programação procedural de 1990) x static controlado (possivelmente funcional).

Não sugiro o estático mutável. Sugiro OO ou funcional para controlar escopo e modelar a interação das partes.

Abraço

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

Acho que existem diversos elementos importantes a serem considerados. O primeiro deles é, como diz um pensador que gosto muito, que não existe sinônimo para “casa”. Mesmo se você escolher a língua de quem irá conversar com você (seja seu end user um cliente comum ou um dev), o grande desafio está em entender o vocabulário.

Escolhendo outra língua, como o inglês, te facilita a trabalhar com os conceitos das bibliotecas que adotou. Creio que se os conceitos são os mais adequados possíveis, a língua (ingles, portugues ou japones) será indiferente – desde que todos entendam o significado das palavras.

Isto é, ingles é uma barreira a mais de acordo com sua equipe. Se não é uma barreira forte ou se você defende a superação dessa barreira, pode usá-lo sem problemas.

Mas o problema da modelagem não está no ingles. O problema da modelagem está em descobrir se uma Conta é uma Conta, ou se ela é duas outras coisas que não tem nada a ver com Conta. Isso é o DDD.

Abraço

Fórum: arquitetura – Discussão: Ruby, vale a pena investir tempo?

Ruby, Java e C# apresentam estruturas muito próximas apesar de não serem iguais. Para alguém que domina a linguagem, tanto faz a escolha. Para alguém que adota boas práticas (testar adequadamente etc) também nnao vai fazer muita diferenca.

Além disso, o mundo ao redor das 3 é bem grande (além da integração entre elas, principalmente Ruby e Java). Por isso, como uma mudança de mindset, outras linguagens são mais valiosas, como Scala e Clojure.

Mas para se manter atualizado e saber o que mais estamos fazendo no mercado, Ruby vale a pena sim.

O mais importante é, continue programando pensando nos outros que vão manter seu código amanhã… em qualquer linguagem que seja.

Abraço

Fórum: arquitetura – Discussão: WebForms ou MVC

Oi pessoal,

Se você não precisa customizar muito os componentes, use ActionBased. A tendência do mercado tem sido expor APIs (REST ou webservices) e fazer o component based no usuário, atraves de Jquery UI, Flash etc. Creio que a tendência seja a médio prazo desse tipo de abordagem se fortalecer mais ainda para quem procura produtividade.

No mercado Java, é a produtividade que VRaptor, Spring MVC oferecem na configuração de uma UI com JQuery ao inves de JSF.

Att

Fórum: arquitetura – Discussão: Rest com BPM

Oi Carlos,

Acho que o Kenobi matou os pontos que você levantou. Qualquer coisa avisa que tento responder tb

Abraço

Fórum: arquitetura – Discussão: Aplicação com banco relacional + não relacional

Tudo bem Hannelita?
Tudo depende do que você fará com essas informações. Se as queries serão executadas no grafo com mais de um de distância, é uma boa modelar o grafo. Crie o DAO para que seu app layer não saiba que esta usando grafos. Se precisar depois mude parte dele para relacional.

Se suas queries não vão envolver buscas no grafo, não há necessidade.

Abraço

Fórum: arquitetura – Discussão: Iniciante na arquitetura REST

Assuma o mínimo de compromissos necessários.

Se você quer que tudo possa ser acessado, ou não tem problemas com isso, permitidno que pessoas desenvolvam coisas inimaginaveis, expõe tudo. Se quer resolver o problema de agora, expõe só o que precisa. A necessidade é o que você julga, como o Julio citou.

Abraço

Fórum: arquitetura – Discussão: MVC, fluxos alternativos

Tudo bem Robson?

Não tem muito segredo… se o UI depende de lógica, a lógica terá que existir. Para evitar repetir, o melhor é colocar ifs e compor. Isto é, o conteudo dentro do if você extrai. Os ifs, você coloca explicitos ou implicitos (anotacoes, configuracoes etc).

Abraço

Fórum: arquitetura – Discussão: Quando testes automatizados não é recomendável...

Yep, muitos metodos em uma classe (privados ou nao) = um ambiente de variaveis globais e procedures… acaba virando programacao procedural. Claro que não é global, mas vc acaba com tao poucos super objetos, que é quase como poucos ambientes semi-globais. É um cuidado importante a tomar… tome cuidado com o numero de metodos em uma classe.

Abraço

Fórum: arquitetura – Discussão: Rest com BPM

Oi Carlo,s

/pedidoFerias/{pedido.id}/aprovar – POST – aprova o pedido ajustando o estado para aprovado.
/pedidoFerias/{pedido.id}/negar – POST – ajusta o pedido para Estado negado

Esses dois são pensamentos mais voltados a serviço. Em recursos, você pode modelar a aprovação
/pedidoFerias/id/aprovacao – POST aprova
/pedidoFerias/id/negacao – POST recusa

A mudança é sutil e ninguem morre por ela. Principalmente pois as URIs em REST devem ser opacas para o cliente. Se o link que voce deveolver via HATEOAS for /xhiuheuifjdsjfsd398472839432 com rel=“aprovacao” (ou algo similar) deve funcionar da mesma maneira que /negar_o_pedido_15_do_guilherme. Afinal é a semântica do link que importa, não a URI. a URI é só sugar.

Se precisar de ajuda no codigo e na DSL e adotar o Restfulie, podemos te ajudar tambem… tanto em java, ruby ou c#. Qualquer coisa grita na lista do restfulie tb.

Abraço!

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

Oi Diogo, a camada que você cria pode ser a que costuma-se chamar de App layer (pelo Evans) ou Presentation Layer (pelo Fowler).

Fórum: arquitetura – Discussão: Branches e Scrum

Diego, escrevemos um post com alguns links de referência sobre o assunto. Feature branching, promiscuous integration e continuous delivery:

http://blog.caelum.com.br/branches-e-integracao…

Emresumo, não recomendo o uso de branches de longo tempo de duração (> 1 dia).

Abraço