Fragmental

Um e-mail recorrente na lista java-br ganhou uma respsota mais longa e decidi postar aqui…

Quando uma equipe vai iniciar um novo projeto, sendo um projeto pequeno,
quais tópicos devem ser analisados?

Arquitetura
IDE ou ferramenta geradora de módulo

O que vocês sugerem?

Obrigada,

Oi,

Esta é uma dúvida muito comum e, como quase tudo, não possui uma
resposta única ou uma ‘certa’. Algumas dicas…

Se sua equipe é nova na tecnologia a ser utilizada, se preocupe em
fazê-los absorvê-la. Um treinamento de meses geralmente é inviável e
infrutífero, o melhor é dar o suficiente para que o sistema comece e
daí investir em treinamento incremental constante, com sessões de
aulas expositivas, reuniões para discutir design, ciranda de livros
(patrocinada pela empresa preferencialmente), reuniões para discussão
de papers, fórum de discussão e wiki internos, etc.

Partindo do ponto que já se possui um mínimo para começar a aplicação,
vamos criar valor ao cliente. É necessário escolher uma forma de
trabalho, seja qual for especifique um worflow mínimo. Não use
waterfall.

Dependendo da metodologia você vai descobrir o que seu sistema fará de
um jeito ou de outro, então vamos nos ater ao que geralmente não muda.

Arquitetura. Para isso você precisa de alguém experiente porque
arquitetura é algo conceitual, não apenas escolher frameworks e
bibliotecas corretas.

Se não tem um a disposição, identifique todas as possíveis soluções
dentro dos critérios:
- Simplicidade
- Qualidade final do produto
- Facilidade de aprendizado

Basicamente hoje isso quer dizer em utilizar POJOs e quando necessário
os serviços de um container como o Spring (fuja de EJB 2.1 o máximo
possível) e Hibernate se você for ter muitos objetos persistentes
(rule of thumb: muitos é mais que cinco classes) ou tem que fazer
buscas complexas com muitos objetos em memória.

Escolha de ferramentas. Se seus desenvolvedores foram treinados
juntos, provavelmente eles usam a mesma ferramenta, se não e se você
está escolhendo entre ferramentas livres (ou tem liberdade para tal),
deixe que cada um trabalhe com o que achar mais adequado. As IDEs
modernas são razoavelmente não intrusivas e não devem influenciar em
como seu projeto é estruturado. Use um controle de versão. Eu
recomendo o Subversion mas o CVS é bastante usado também. Todos
possuem plugins para as IDEs.

Para codificar, utilize ferramentas como PMD e FindBugs. Estas
ferramentas atuam como um desenvolvedor sênior e pentelho avaliando
seu código o tempo todo. Com o tempo você acaba aprendendo o que não
deve fazer de jeito nenhum e o que é simplesmente feio.

Preferencialmente use tes driven development. Se não conseguir, pelo
menos use Unit Tests, aprender a utilizar o JUnit não é difícil.

Se puder, utilize um build contínuo. Aprenda a usar o DamageControl ou
o CruiseControl. Utilize Maven ou Ant para criar seu build, não crie
JAR/WAR/EAR/RAR/qualquer outra coisa na mão.

Muita coisa, né? Se for um projeto pequeno, um projeto acadêmico ou
sei lá não vai precisar da maioria destas coisas, por isso não dá pra
falar algo com certeza. Um projeto que quer atingir qualidade
profissional é bom ter cuidado com isso.

De qualquer forma a melhor dica na minha opinião é uma só: contrate um
consultor. Existem bons profissionais especializados em pegar um time
‘cru’ e ajudar com mentoria, coaching, treinamento e consultoria. É
profissionalismo saber que alguém experiente é necessário. Pode
parecer caro mas é só colcoar na ponta do lápis o trabalho todo que dá
não ter um guia, quantas horas seus desenvolvedores vão ficar parados
sem saber o que fazer ou vão gastar várias horaspara resolver um
pequeno problema que tomaria minutos se eles forem assistidos por
algum mentor.

[]s

–
Phillip Calçado

A Amazon acaba de entregar meu My Job Went To India.

O livro é muito bom. Li quase 100 páginas desde ontem a noite até agora. Basicamente Chad Fowler fala sobre como não ser um programador commoditie, porque programadores commodities existem aos milhares na índia (ou no não citado Brasil). Apesar do alvo ser de engenheiros americanos (”ficamos gordos e lentos com o tempo“) os conselhos e histórias de Chad são fundamentais para qualquer um.

Além de explicar porque você deve se preocupar com a commoditização do trabalho, ele faz você se preocupar em evoluir como técnico, gerente e especialista em domínio. É um livro pequeno e não muito caro, não perca a chance de ler!

Há algum tempo o pessoal do portalJava me chamou junto com outras pessoas para fazer parte do seu time de colunistas. Hoje foi lançada a parte de colunas do portal.

Minha primeira contribuição é entitulada Identificando e Convertendo Código Orientado a Objetos e Código Procedural e refelte mais ou menos o que eu penso em fazer nesta coluna: artigos curtos e práticos sobre conceitos amplos e teóricos aplicados.

Para feedback, os adminsitradores prepararam um fórum específico. Parabéns ao PJ pela iniciativa e estamos aí ;)

Você está começando a aprender Ruby? tem dificuldades? Sabe tudo e quer ajudar a divulgar? Sabe um pouquinho e quer compartilhar conhecimento?

Junte-se a nós!

Lista de Discussão RubyBrasil

80 membros mas definitivamente não é a a lista de discussão mais movimentada do mundo…

Update: Menção injusta do autor do logotipo: o TaQ sorry :(

…não fique fora dessa!

(na boa, com tanta gente que faz waterfall, seja sem saber, sem ter noção de nada ou praticando mal (R)UP, é de espantar ninguém aparecer com um evento desse de verdade…)

Papo interessante que estava tendo com o Fabrício ainda agora…

fabrício diz:
hehehhe
vc tb ta estudando ruby ?
Phillip Calçado - All that’s sacred..comes from youth! diz:
sim

fabrício diz:
pq ?

Phillip Calçado - All that’s sacred..comes from youth! diz:
por que eh uma linguagem *muito* boa
produtiva e de qualidade

fabrício diz:
rapaz..
hehe
sacanagem, mas eu quero saber o q eh q vcs acharam tao extraordinario nessa linguagem
eu vi aquele videozinho

Phillip Calçado - All that’s sacred..comes from youth! diz:
closures, dinamismo, DSLs

fabrício diz:
realmente me surprendi

Phillip Calçado - All that’s sacred..comes from youth! diz:
hoje eu estava com um problema interessante em java

fabrício diz:
qual ?

Phillip Calçado - All that’s sacred..comes from youth! diz:
tem uma classe qualquer que cria um objeto que pode ser considerado uma sessão com o banco de dados
só que numa jvm só podem existir duas sessões ao mesmo tempo, em threads diferentes
e me foi pedido para toda vez que se tenta abrir uma dessas, logar num arquivo antes quantas existem em memoria
para saber se estavamos tendo muito problema com isso ou se quase nunca duas sessoes ficam abertas
o jeito mais simples seria colocar uma variavel de classes (estatica) na classe que cria a conexão para saber quantas ela criou, certo?

fabrício diz:
é, a principio sim
e aii ?

Phillip Calçado - All that’s sacred..comes from youth! diz:
mas o problema eh que a classe que pede para essa outra criar uma sessão é quem fecha a sessão
então nós poderíamos saber quantas ssessões foram criadas, mas não quando uma for fechada
e essa classe sessão é do fornecedor do banco de dados, ou seja não pode ser alterada
como resolver isso em java?

fabrício diz:
unh … sem alterar a classe do fornecedor do bd, acho q tem q queimar um pouco os neuronios hehe
pq essa classe na pior das solucoes poderia notificar a todos que tem um comunicacao com ela, de que a sessao foi finalizada
sim, e ai?
vc fez o q?

Phillip Calçado - All that’s sacred..comes from youth! diz:
basicamente o que eu fiz rpa contornar a situação foi pegar todas as threads do sistema, ver quais delas possuem sessões abertas e logar, e como isso é bem lento deve ser melhor usar um adapter nesta classe
mas se fosse em uma linguagem como ruby, ao criar a instancia de sessao eu poderia alterar o metodo commit() desta instancia, fazendo ele avisar a classe fabrica que foi fechada antes de chamar o metodo original

Não entendeu a solução? Em Ruby uma classe é dinâmica, você pode alterá-la em runtime. Vamos a um exemplo (você pode testá-lo neste site) . Então supomos que nossa classe Session seja assim:


class Session
    def commit
        puts ‘COMMITED’
    end
end


E que quem crie sessions seja esta fabrica:


class Factory
    def create
        return Session.new
    end
end


Agora vamos modificar a fabrica para que guarde o numero de Sessions abertas e altere o método Session#commit


class Factory
#vamos guardar a quantidade de sessoes aqui
    @count
    

    #cria um ‘getter’ para o count

    attr_reader :count

    

    #construtor
    def initialize
        @count=0
    end
    

    #metodo usado para informar que uma sessao foi finalizada
    def session_ended
        @count=@count-1
    end
    

    def create
        s=Session.new
    

    #muda o metodo do objeto criado e cria variavel de instancia para localizar a factory
    class <<s
    

        #onde vamos guardar uma referencia para nossa factory
        @factory
    

        #cria um ’setter’ para factory
        attr_writer :factory
    

        #Muda o nome do metodo commit real
        alias original_commit commit
    

        def commit
            @factory.session_ended
            #chama o metodo antigo
            return original_commit
        end
    end
    

    #diz à sessao modificada que esta eh sua factory
    s.factory=self
    

    @count=@count+1
    

    return s
    end
end


Ficou bem maior que o método original, mas muito do que foi adicionado são getters, setters e construtores. No fim do post está o texto do teste completo, basta salvar num arquivo e rodar no interpretador ruby.

Note que o código não é thread-safe, teríamos que colocar uns monitores ali. Também é bom notar que não são todas as instâncias de Session que são afetadas mas apenas aquelas criadas pela Factory. Caso fosse necessário, poderíamos fazer com que todas as instâncias d Session fossem alteradas.

É assim que coisas como o Rails são implementadas e por isso é tão complexo criar ‘um Rails em Java’.

Se pudesse fazer isso em Java não estaria quebrando minha cabeça amanhã para otimizar uma ferramenta de diagnóstico… Minhas opções são: (a) empacotar a classe Session num Adapter ou (b) continuar buscando todas as threads e vendo se elas possuem sessões abertas

Provavelmente vou criar um adapter ou se não puder uma subclasse. WrappedSession implements Session e implemento o método commit() fazendo o necessário antes de delegar à Session real. O fato de criar uma classe nova na hierarquia apenas para adicionar um conceito ortognal (ou um cross cutting concern, algo importante para o sistema mas não importante do ponto de vista do usuário) não me faz muito bem. E se eu tiver que acrescentar esta funcionalidade a uma outra subclasse de Session criada por alguma das outras factories? Com wrapper tudo bem, mas se não usar subclasse eu crio outra com a mesma finalidade? E se eu quiser que todas as Sessions, não importa onde foram criadas, tenham esta funcionalidade? Find “Session”/Replace with “WrapperSession”?

Ps: estou tendo problemas com o WYSIWYG do WrodPress, a formatação tem ficado meio bagunçada devido a isso - Com ajuda do Diego isso foi meio que resolvido :P

Exemplo completo:

class Session
    def commit
        puts 'COMMITED'
    end
end
    
class Factory
    
    #vamos guardar a quantidade de sessoes aqui
    @count
    
    #cria um ‘getter’ para o count
    attr_reader :count
    
    #construtor
    def initialize
        @count=0
    end
    

#metodo usado para informar que uma sessao foi finalizada
def session_ended
    @count=@count-1
end
    
    def create
        s=Session.new
        
        #muda o metodo dentro do objeto criado e cria variavel de instancia para localizar a factory
        class <<s
        
            #onde vamos guardar uma referencia para nossa factory
            @factory
            
            #cria um ’setter’ para factory
            attr_writer :factory
        
            #Muda o nome do metodo commit real
            alias original_commit commit
                
    

            def commit
                @factory.session_ended
                #chama o metodo antigo
                return original_commit    

            end
        end
    

    
    #diz à sessao modificada que esta eh sua factory
    
    s.factory=self
    

        @count=@count+1
        

        return s
    end
end
    
f = Factory.new
s = f.create
puts f.count
s.commit
puts f.count


UPDATE: O taq deu uma limpada no código, ficou menor mas se for sua primeira vez vendo algo em Ruby pode ser mais confuso::

class Session
    def commit
        puts "COMMITED"
    end
end

f = Factory.new
s = f.create
puts f.count
s.commit
puts f.count


Essa é imperdível :)

Hoje no auditório do SENAC vai ser realizada mais uma reunião do RioJUG: