Tenho utilizado o SO Ubuntu eu meu notebook desde sua verão 9.4, e desde então tenho acompanhado sua evolução em termos de Interface. Na versão 10.10 Maverick Meerkat o Ubuntu passou por um redesenho onde foram apresentadas várias novidades em seu layout, e uma que eu gostei bastante foi a nova fonte.
A fonte chamada Ubuntu Font Family foi criada com o intuito de dar mais personalidade ao Ubuntu, de certo modo impor uma marca. Mais sobre a fonte: http://meiobit.com/70152/nova-fonte-ubuntu/
Ubuntu Font Family
E voltando ao foco desse poste, hoje vou apresentar 3 formas de adicionar a fonte em sei site:
A primeira é forma é só adicionar no <head> do HTML a seguinte linha:
<link href='http://fonts.googleapis.com/css?family=Ubuntu' rel='stylesheet' type='text/css'>
Outro modo de importar a fonte é colocando diretamente no CSS:
@import url(http://fonts.googleapis.com/css?family=Ubuntu);
E ainda há possibilidade de fazer isso por JavaScript:
<script type="text/javascript">
WebFontConfig = {
google: { families: [ 'Ubuntu:latin' ] }
};
(function() {
var wf = document.createElement('script');
wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
'://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})();
</script>
E depois é só indicar em seu CSS, como no exemplo abaixo:
body {
font-family: 'Ubuntu', arial, serif;
}
Para mais informações sobre a utiilização: http://code.google.com/webfonts/specimen/Ubuntu
Gabriel RubensPostagens Relacionadas:
Utilizando a fonte Ubuntu em seu Site (Ubuntu Font Family) Assine o Feed Grupo Haw FeedBurner
]]>
Bom dia caro amigo leitor, no post de hoje abordarei o assunto sobre ontologia na computação. Este post foi baseado na compilação de várias fontes disponíveis na internet, conforme você for lendo, alguns links serão apresentados, para um estudo mais aprofundado.
O objetivo é apresentar um breve resumo sobre este tema tão importante e essêncial nos quesitos web semântica, interoperabilidade, recuperação de informações,…
O termo ontologia é muito antigo, vem da área da filosofia e foi cogitado por Aristóteles sobre o assunto metafísica, que tem por um dos seus objetivos o esclarecimento de como as pessoas entendem o mundo. (veja aqui )
Com as ontologias era possível estruturar e classificar o pensamento sobre um determinado assunto, por exemplo, uma águia poderia pertencer a uma determinada espécie, ou uma determinada animal poderia ser classificado como mamífero. Com a estruturação do pensamento é possível entender melhor o mundo, ou melhor o domínio do conhecimento. (veja aqui )
Porém, observando a disponibilidade das informações na grande rede Internet, é possível compreender o porque de se trazer um assunto tão antigo para os dias atuais. Vamos entender o por que.
Através das afirmações abaixo, conseguiremos entender a motivação para se trazer o estudo da ontologia para a computação.
Primeira afimação – Esta é de Tim Berners-Lee, que diz o seguinte: “A maior parte do conteúdo presente na Web é projetado para entendimento de nós seres humanos”. (veja aqui )
Continuando o raciocíonio de Berner-Lee, nós entendemos temos a capacidade de compreender que assuntos são ligados a outros, por exemplo sabemos que HN1 é o mesmo de que GRIPE A, por exemplo. Esse nível de inteligência não existe nas máquinas.
Segunda afirmação – Com o aumento exponencial dos dados disponíveis na internet houve a necessidade de técnicas de organização das informações (veja aqui )
Entendendo que um computador não tem a capacidade pensante de um ser humano, a melhor forma de fazê-lo pensar (“pensar” entre aspas) é criar uma espécie de raciocínio através das classificações dos dados disponíveis, ou seja, conectar um dado com o outro através de Ontologias.
Em resumo ontologias na computação servem para descrever e representar uma área do conhecimento (Domínio do conhecimento). (ver referência )
Não se trata de inteligência artificial e sim a criação de formalismos para um determinado domínio do conhecimento (ou como alguns autores preferem falar, domínio de discurso). Com isso tornará mais fácil que humanos e computadores atinjam a mesma resposta ao se recuperar um determinada informação, como no exemplo da GRIPE tipo A.
Também não se trata unicamente em criar diagramas UMLs, modelos de entidades relacionais para representar um conhecimento, mas trazer esse conhecimento para a máquina. O intuito é que a máquina possa interpretar os formalismo de um determinado domínio.
De acordo com o link http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0024134_02_cap_04.pdf , ontologias possuem as seguintes vantagens:
- Ontologias fornecem um vocabulário para representação do conhecimento.
- Permitem o compartilhamento do conhecimento entre pessoas e entre máquinas.
- Fornece uma descrição exata do conhecimento.
- Pode ser possível estender o uso de uma ontologia genérica de forma a que ela se adeque a um domínio específico.
- Entre outros
Para se criar, ontologias podemos utilizar a ferramenta Protégé criado pela Universty of Stanford, baseado em Java, Free, Open Source, é uma das ferramentas mais utilizadas para esta finalidade.
Bom pessoal, termino aqui este post, mas em breve darei continuidade com este assunto ainda recente na computação!
Postagens Relacionadas:
O PMBOK (Project Management Body Knowledgment) é um guia, ou como muitos lugares definem, um conjunto de boas práticas, criado pelo PMI – Project Management Institute para auxiliar a todos que estejam envolvidos com gerenciamento de projetos. Foi publicado na forma de livro e hoje encontra-se em sua 4ª edição, sendo a principal bibliografia para todos que desejam obter certificação em Gestão de Projetos.
O conteúdo do guia é formado por um conjunto de conhecimentos, escritos em linguagem universal (sem termos técnicos), para que possa ser útil a profissionais de todas as áreas e facilite assim a troca de experiências sobre o assunto.
Na sua 4ª edição, o PMBOK é constituído por 42 processos, 5 grupos de processos e 9 áreas de conhecimento.
O fato do PMBOK ser um guia composto por boas práticas, significa que não precisamos aplicá-las todas e sim verificar quais se encaixam no nosso projeto.
É sempre bom lembrar que um projeto é único e temporário, existem projetos que resultarão em um mesmo produto, como uma única planta para criação de vários prédios, porém, cada vez que for executado terá um contexto diferente, com pessoas diferentes trabalhando, novos fornecedores, outros prazos, outros valores, circunstâncias diferentes entre outras coisas que tornam cada projeto diferente do anterior.
Abaixo, podemos ver como é composto o PMBOK:
- Fonte: www.pmtech.com.br
Os 5 grupos de processo são:
-
Iniciação (em alguns lugares conta como Concepção)
-
Planejamento
-
Execução
-
Monitoramento e Controle
-
Encerramento
-
Integração
-
Escopo
-
Tempo (também descrito como prazo)
-
Custo
-
Qualidade
-
Recursos Humanos
-
Comunicações
-
Riscos
-
Aquisições
Postagens Relacionadas:
- Nenhuma postagem encontrada
PMBOK 4ª edição – Rapidinho Assine o Feed Grupo Haw FeedBurner
]]>
Bom dia, amigos, o texto que segue abaixo faz parte de um trabalho que fiz para uma disciplina na Unicamp. Abaixo apresento alguns conceitos sobre Governo Eletrônico. O intuito é começar o assunto e dar continuidade a este post futuramente, apresentando outros assuntos pertinentes a este tema.
Bom vamos lá, um sistema de Governo Eletrônico (sigla EGOV) nada mais é do que a utilização das tecnologias da informação para interação de cidadãos, comércios e indústrias onde este deve prover melhora na administração pública de um determinado órgão público. A interação neste caso se dá através de processos e produtos que estes governos podem disponibilizar aos usuários deste sistema.
Segundo um artigo que li (chamado Aplicações de Tv Digital em Governo Eletrônico de 2009)diz que EGOV “tem despertado o interesse do meio acadêmico pela sua contribuição ao aprimoramento dos serviços prestados ao cidadão e pela possibilidade de contribuir com a democracia eletrônica”. A abordagem democracia eletrônica resume o verdadeiro intuito dos Governos Eletrônicos.
De acordo com um outro artigo (The Economic Impact of Interoperability, feito pela Microsoft e ultima atualização feita em 2008), os serviços eletrônicos providos pelo EGOV proporcionam não só uma melhora na qualidade dos serviços oferecidos aos cidadãos, mas também melhoram a eficiência e a eficácia do governo como um todo e fazem que procedimentos de órgãos públicos sejam mais transparentes.
Características
O artigo (Sistema de Informação Geográfica Móveis aplicados no Governo Eletrônico Municipal, de 2009) diz que um EGOV pode ser dos tipos:
• Governo para Governo – (G2G – Government – to – Government), que são relações do governo com seus próprios órgãos e departamentos.
• Governo para Cidadão (G2C – Government to Citizen) e Cidadão para Governo (C2G – Citizen to Government), que são as relações entre o governo e os cidadãos, onde o objetivo e prover informações e serviços ao cidadão e como consequência promover a inclusão digital.
• Governo para Empresa (Goverment to Business) e Empresa para Governo (Business to Government), que são as relações entre setor privado e o governo, cuja finalidade é prover informações e serviços de investimento e negócios.
• Também é conhecido a abordagem (G2E – Government to Employee e E2G – Employee to Government), onde trata-se da relação funcionário para governo e governo para empregado que visa prover melhora no processo e no trabalho realizado.
Para haver efetivamente um sistema EGOV é necessário algum dos seguintes parâmetros, sendo eles realizados em qualquer sequência:
• Presença – A informação disponibilizada para aquele que está solicitando.
Por exemplo: Endereços de localidades e horários de funcionamento.
• Interação – Refere-se aos acréscimos de funcionalidades como no caso as buscas internas.
• Transação – Onde o usuário pode efetuar uma operação de forma completa por um portal EGOV por exemplo.
• Transformação – Rearranjar as tarefas realizadas pelo sistema.
Exemplos de Portais EGOV
No Brasil existem vários sistemas EGOVs a serviço do cidadão, abaixo são citados alguns portais disponíveis atualmente e com grande sucesso entre governo e cidadão:
• Receita Federal – (http://www.receita.fazenda.gov.br/), que disponibiliza serviços para cidadãos e empresas, como por exemplo, arrecadação de imposto de renda, situação fiscal do contribuinte, cadastro de CPF e CNPJ, impressão de declarações, entre vários outros.
• Polícia Federal – (http://www.dpf.gov.br/), oferece serviços, por exemplo, requerimento de passaporte, declarações de antecedentes criminais, oferece suporte também para adoções internacionais, entre outros.
• PoupaTempo – (http://www.poupatempo.sp.gov.br/home/), portal do governo do estado de São Paulo para facilitar o acesso do cidadão para as informações de serviços públicos. Fornece serviços várias espécies, que vão desde solicitaçãi de documentos até abertura de empresas e fechamento de empresas.
• Sistema Público de Escrituração Digital SPED – (http://www1.receita.fazenda.gov.br/), disponibiliza a promoção de entrega de fiscos, racionalização e uniformização das obrigações acessórias para os contribuintes e tornar mais célere a identificação de ilícitos tributários.
• Sistema Integrado de Administração Financeira do Governo Federal SIAFI – (http://www.tesouro.fazenda.gov.br/siafi/index.asp), trata de assuntos vinculados ao tesouro nacional, onde é possível controlar e acompanhar os gastos públicos.
• Projeto OntoJuris – (http://www.i3g.org.br/ontojuris/), tem o intuito em facilitar o acesso a informações sobre legislação na área de propriedade intelectual, direito do consumidor e direito eletrônico.
Estes são alguns exemplos no Brasil, logo abaixo serão apresentados alguns portais EGOV nortes americanos:
• NIC USA – (http://www.nicusa.com/Pages/default.aspx), site do governo que tem como principal ideal, permitir que o setor privado possa interagir de forma rápida é fácil com governos federais, estaduais e locais. Auxilia cidadãos e empresas a fazerem transações financeiras.
• FIX MY STREET – (http://www.fixmystreet.com/), site que apresenta aos cidadãos e ao governo os problemas locais, onde os cidadãos são os responsáveis pela divulgação das irregularidades.
Aqui foram mostrados alguns poucos exemplos dos serviços disponíveis no Brasil e nos Estados Unidos, com certeza existem muitos outros, todos com as mesmas finalidades, servir o cidadão, a empresa, o comercio, em conjunto com o governo.
Postagens Relacionadas:
Governo Eletrônico – EGOV Assine o Feed Grupo Haw FeedBurner
]]>
Cá estamos de novo!
O que é um sistema de controle de versões?
Um sistema de controle de versão, para muitos, é o software responsável por armazenar a documentação, código-fonte, bibliotecas e todo o restante dos arquivos utilizados em um projeto de desenvolvimento de software, vulgo “repositório”.
É, mais ou menos.
No desenvolvimento de software, muitas pessoas trabalham com os mesmos arquivos e nestes promovem constantes mudanças. Por esse motivo, é extremamente necessário que certifique-se que todos estejam trabalhando com o documento mais atualizado e enxerguem as mesmas informações. Para isso e não somente, utilizamos os softwares de versionamento.
Assim que alguém altera algum código ou documento, já é possível visualizá-lo e trabalhar em cima dele. Basta solicitar, através de um comando, a última versão do mesmo ao software de CV e trabalhar em cima dela.
Isso já nos traz um grande benefício, que é minimizar problemas por conflitos de edições.
Legal!
Já vimos que o Controle de Versões é uma maneira de fazer com que todos os membros do time trabalhem com as mesmas informações, mas e o que mais ele faz?
Os sistemas de versionamento são considerados os salvadores da pátria pela turma de Gerência de Configuração nas empresas de Desenvolvimento de Software. Com ele, é possível dar permissões diferenciadas a grupos de usuário para acesso e manipulação de determinados arquivos ou pastas. Isso aumenta a segurança, já que cada um só trabalha com o que é de sua responsabilidade.
Fonte: http://www.webartigos.com - Controle de Versão Centralizado
O CV também guarda um histórico das versões dos arquivos que foram criados e alterados dentro da sua área de cobertura. Assim, é possível retornar o documento à uma versão antiga e estável, depois de ter feito alguma cagada.
Claro que nem tudo é perfeito, existem problemas de conflito que ocorrem quando 2 ou mais pessoas estão alterando um documento exatamente ao mesmo tempo, porém há alternativas como mesclagem de arquivos e outras, dependendo do software que você está utilizando.
Fonte: http://www.webartigos.com - Controle de Versão Distribuído
As características citadas acima, são comuns nos diversos softwares de controle de versão mercado a dentro, no entanto, existem conceitos diferentes de versionamento, como por exemplo controle de versão centralizado e distribuído. Isso ficará para um post mais detalhado sobre como cada um deles se comporta.
Abaixo listei alguns dos softwares mais utilizados:
Até a próxima, galera!
Postagens Relacionadas:
- Desenvolvimento de Software não é especulação!
- Todos de pé!
- PMBOK 4ª edição – Rapidinho
- Quebrando em Tarefas!
- Quanto tempo leva? – Planning Poker
- Terminando a tempo!
Controle de Versões – Rapidinho Assine o Feed Grupo Haw FeedBurner
]]>
Vocês já ouviram falar sobre Web 2.0, que foi um termo criado no ano de 2004 para designar as mudanças que estavam acontecendo no modo de utilizar da web, onde usuários deixaram de utilizar páginas como simplesmente um jornal ou um panfleto, e passaram a colaborar com o conteúdo online.
Na web 1.0 existia papéis fixos de quem fornecia a informação (aquele que criava a página) e de quem era fornecido pela informação disponível.
Já na Web 2.0 houve a revolução, agora podemos fazer parte da grande engrenagem de informação através dos mais variados sites disponíveis, onde podemos participar de redes sociais ( facebook , orkut, twitter, etc e etc mesmo), ler e compartilhar informações em wikis (como por exemplo, o wikipedia), armazenar e recuperar nossas informações em qualquer lugar (exemplo, o openDrive” ), utilizar mashups, que é a utilização de uma aplicação disponibilizada por outros em nosso próprio site, sites como o google maps (ferramenta de geoprocessamento), FeedBurner (blogs), Del.icio.us (para acessar os sites favoritos de qualquer lugar), entre muitos outros exemplos, a colaboração e interatividade certamente são as palavras que resumem bem a web 2.0.
Poderia continuar escrevendo sobre Web 2.0 por muitas horas, porque há muita disponibilidade de serviços variados para os usuários, muitas pessoas em toda parte do mundo usufruem destes serviços e muitos alegam que não conseguiriam viver sem estas facilidades digitais.
Apesar de tudo isso, se observarmos adequadamente, ainda falta algo para facilitar de vez a nossa vida.
Pense no seguinte exemplo: Como faço pra recuperar uma informação desejada precisamente? Imaginem a situação, necessito fazer uma busca que me traga os preços do livro João e Maria disponíveis nas livrarias no Brasil, afinal gosto muito desse livro e quero comprar aquele que tiver mais em conta.
Outro exemplo, (esse eu encontrei no link Históra sobre sites de busca) “vamos supor que um cientista esteja trabalhando no desenvolvimento de uma nova droga. Ele sabe que efeitos a substância provoca no corpo, outro entende por que isso acontece, muitos outros técnicos podem ter informações sobre o que ocorreu no passado, quando se tentou usar esse mesmo medicamento mas nenhum deles, e principalmente nenhum programa ou aplicação, é capaz de reunir e cruzar todas essas informações”. Esse exemplo é muito bom e reflete bem o problema.
Da maneira que as informações estão dispostas na web não é possível que um computador saiba realmente o que é um livro ou a saber relacionar assuntos em comum, pois os sistemas de buscas são limitados no aspecto semântico. O que falta pra facilitar nossa vida é fazer a máquina “pensar” por nós.
A solução para tipos de situações como estas está no nascimento de mais uma terminologia para a web que passará a se chamar web 3.0, que certamente será a cara padrão da web em um futuro muito muito próximo, ela consiste basicamente da idéia de web semântica, que foi um conceito proposto desde 2001 pelo criador da web, Tiiiiiim Berners-Leeeeeeee (sim, foi antes do nascimento da web 2.0), mas que somente a pouco tempo, pelo menos ao meu modo de ver, vem guanhando grande atenção pela comunidade web ao redor do globo.
O objetivo principal da web 3.0 é fornecer mecanismos para que o computador possa entender os dados e não somente os usuários. O usuário sabe o que é um livro mas o computador não.
Tecnicamente falando, o estudo da web semântica é a organização dos dados disponíveis, onde estes possam ter ligações entre as mais diversas informações que fazem parte de um contexto, ou seja, tornar os dados legíveis para computadores. Em resumo, a idéia é tornar o caos de informação em algo que tanto a máquina possa entender máquina quanto homem possa entender a máquina.
Para que isso seja possível leva-se em consideração alguns elementos como: ontologias, agentes e representação de conhecimento. Outras abordagens Imprescindível são o uso do XML (eXtensible Markup Language), RDF (Resource Description Framework), arquiteturas de metadados, tudo isso para facilitar e garantir a interoperabilidade e a cooperação.
Existe grandes esforços em pesquisas acadêmicas para resolver o problema da web semântica, algumas delas são realizadas pelo W3C(World Wide Web Consortium).
Bom pessoal esse post é meramente introdutório ao assunto sobre web 3.0, mas através deste post já é possível compreender que o intuito é tornar a internet inteligente, nos facilitando em vários serviços que fazemos manualmente. A web 3.0 será um marco será um novo marco da tecnologia e do relacionamento homem – máquina.
Eu retornarei para ir mais a fundo neste assunto, um abraço!!!Postagens Relacionadas:
- Nenhuma postagem encontrada
Web 3.0 – Internet Inteligente. Assine o Feed Grupo Haw FeedBurner
]]>
Em uma postagem intitulada de Os Nomes São Importante eu escrevi um desabafo sobre um problema que estava tendo sobre o como a importância de se escrever nomes corretos. Ter que olhar a tabela do banco de dados pra enter qual é o real significado de um atributo em um objeto é tempo perdido.
Para minha surpresa lendo o livro O Programador Pragmático eu encontrei mais um ótimo exemplo de como esse retrabalho de interpretar qual o o significado de uma variável pode ser chato.
Logo no início da página que trata sobre o assunto Tudo de Resume a Escrever o autor coloca um provérbio chinês: A tinta mais fraca é melhor que a memória mais afiada.
Dito esse proverbio imagine a cena, você está lendo o código e encontra um método chamado buscarPessoaPorId(Pessoa pessoa) só que ao perceber um comportamento estranho e vai olhar a implementação do método. Pela implementação do método na verdade o busca é feita pelo CPF e não pelo ID.
Agora imagine você tendo que implementar uma lógica complexa utilizando não só esse mas dezenas de métodos com nomes ambíguos.
É assim que você vai ficar: Código Limpo - Uncle Bob
Nessas horas nós perdemos um tempo enorme pelo chamado Efeito Stroop que segundo a Wikipédia é “[...] é uma demonstração de interferência no tempo de reacção de uma tarefa[...]”, “[...] ocorre um atraso no processamento [...] causando tempos de reação mais lentos e um aumento de erros [...]” (http://pt.wikipedia.org/wiki/Efeito_Stroop).
Agora um exemplo que é apresentado no livro e também na Wikipédia que demonstra o quanto esse trabalho de traduzir o real significado de um método com nome ambíguo pode atrapalhar.
Leia esse texto rápido:
Vermelho Amarelo Azul Verde.
Verde Vermelho Amarelo Azul.
Azul Verde Vermelho Amarelo.
Amarelo Azul Verde Vermelho.
Agora leia novamente o mesmo texto seguindo a mesma ordem do primeiro texto, ignore a cor que está pintada o texto:
Vermelho Amarelo Azul Verde.
Vermelho Amarelo Azul Verde.
Vermelho Amarelo Azul Verde.
Vermelho Amarelo Azul Verde.
Se você consegue ler sem muitas dificuldades parabéns, só que provavelmente você não será o único a utilizar e dar manutenção em um código com um nome ambíguo que não expressam o seu significado.
No final das contas tenha em mente que você vai passar muito mais tempo lendo código que escrevendo e os outros desenvolvedores também, então é válido alguns segundinhos pensando em uma boa nomenclatura. Claro que escrever um bom código vai de encontro com as limitações técnicas de cada pessoas, e alguns livros como Refatoração, Código Limpo, O Programador Pragmático e outros ajudam a melhorar suas habilidade de escrever um bom código, mas não ter lido esses livros não é desculpa pra escrever um objeto com o atributo Pessoa.nmPes no lugar de Pessoa.nome.
É comum ler o próprio código antigo a encontrar muitos trechos que poderiam ser feitos de uma forma melhor, esse é o processo natural do crescimento profissional, o problema é a negligência que acarreta problemas futuros.
Gabriel RubensPostagens Relacionadas:
- Os nomes são importantes
- Início
- Certificado Java com o jeitinho brasileiro: Oracle Certified Java Programmer – OCJP/SCJP
- Iniciando em Ruby
- Mestrandos do Grupo Haw
O Efeito Stroop no desenvolvimento de software Assine o Feed Grupo Haw FeedBurner
]]>
Olá povo, voltei aqui só para fazer um post rápido, dessa vez um mais técnico, vou mostrar como acessar um método privado usando o lindo reflection, resolvi fazer esse post para quebrar as pernas do Eduardo definitivamente.
Para quem não acompanha o nosso blog vou explicar… o Eduardo começou a escrever uma serie de post sobre POO (Orientação a Objetos em Cinco Minutos e Orientação a Objetos em Cinco Minutos parte 2) sendo que nesse segundo ele me desafiou a burlar a regra de negocio da classe dele… se quiser entender melhor leia os posts do Eduardo….
Então vamos começar…
Se você é programador de verdade é curioso e já deve ter perguntando: Como o Hibernate, Struts e Cia fazem para acessar nossas classes sem as conhecer? Como acessam nossos atributos e métodos privados…
Para entender isso direito e realmente ser um programador Java e não um framework boy você deve conhecer um recurso não muito novo do Java mas muito inteligente chamado reflection. Ele existe dês da versão 1.1 do Java e nada mais é que uma API para obter e modificar em tempo de execução informações sobre um objeto, com ele você pode criar um objeto simplesmente escrevendo o Classname dele, listar e executar métodos sem precisar saber o nome dele dentre inúmeras outras funcionalidades legais…
Para esse primeiro post sobre reflection do grupo HAW vou ensinar a modificar o valor de um atributo privado e para isso vou usar as classes dos artigos do Eduardo(Orientação a Objetos em Cinco Minutos e Orientação a Objetos em Cinco Minutos parte 2)
No post do Eduardo ele criou uma classe chamada Carro que deveria decolar caso a velocidadeMaxima fosse igual a velocidadeAtual, só que para mudar de velocidadeAtual o usuario da classe deveria disparar um metodo chamado acelerar e o mesmo seria o responsável de mudar o atributo pois ele é um atributo privado, como você sabe a gente faz isso para poder executar uma regra de negocio toda vez que o atributo for modificado, no caso o Eduardo alterara a velocidade de acordo com a marcha em que o carro esta… bom… isso é matéria do artigo do Eduardo é só você lê para entender…
Então para poder fazer o carro decola quando a atributo não era privado ( no primeiro artigo) eu acessei diretamente e coloquei o valor dele na munheca como abaixo:
public class FabricaDeCarrosDoWenderson {
public static void main(String[] args) {
Carro carro1 = new Carro();
carro1.nome = "Carro Alegórico";
carro1.marca = "FastWend";
carro1.velocidadeMaxima = 1000;
carro1.quantidadeDeMarchas = 5;
carro1.velocidadeAtual=1000;
carro1.decola();
}
}
Mas como no segundo artigo ele colocou o atributo como privado(e pensou que tava tudo resolvido), então vamos usar o Reflaction para quebrar as pernas do Eduardo, abaixo o código e depois a explicação:
import java.lang.reflect.*;
public class FabricaDeCarrosDoWenderson {
public static void main(String[] args) {
Carro carro1 = new Carro();
carro1.nome = "Carro Alegórico";
carro1.marca = "FastWend";
carro1.velocidadeMaxima = 1000;
carro1.quantidadeDeMarchas = 5;
// carro1.velocidadeAtual=1000;
try {
Class objetoCarro = Class.forName("eduardo.Carro");
Field atributoVelocidadeAtual = objetoCarro
.getDeclaredField("velocidadeAtual");
atributoVelocidadeAtual.setAccessible(true);
atributoVelocidadeAtual.setDouble(carro1, 1000);
} catch (Throwable erro) {
System.err.println(erro);
}
carro1.decola();
}
}
Quando agente trabalha com reflection precisamos colocar um bloco para tratamento de erro, (futuramente o grupo haw irá fazer uma artigo sobre isso), pois é um trabalho extremamente passível a erro (abaixo explico o porque), na linha 14 agente cria o objeto objetoCarro que servirá como um “objeto de apoio” contendo toda a assinatura da classe Carro.
Passando o forName da classe Carro para o método abstrato da classe Class, ele cospe o objeto desejato para assim podermos colocar no objetoCarro.
Logo depois temos que criar um objeto do tipo Field que será o responsável por controlar o atributo ao qual queremos acessar, para isso devemos usar o método getDeclaredField que pertence a classe Class, esse método é o responsável por procurar na assinatura da classe um atributo com o nome exatamente igual ao passado via parâmetro.
Com o campo na Mao podemos trabalhar em cima dele livremente, alterando quase tudo dele, para esse exemplo estamos mudando a acessibilidade dele para acessível, é como se colocássemos ele como publico ao invés de privado, sem isso não conseguiríamos manipular seu valor
Na linha de baixo setamos o valor 1000 do campo no objeto carro1 note que usamos o método para setar Double tem um para cada tipo de objeto, terminando assim a maracutaia de mudar o valor de um atributo privado fora da classee quebrando as pernas do Eduardo mais uma vez… (wenderson 2 X Eduardo 0)
Considerações finais…
Primeiro quero falar que não devemos usar esse recurso da maneira que eu apresentei, pois matamos as regras de negocio da classe, se quisermos fazer isso devemos usar um javabean com métodos Gets e Sets e ainda que por estarmos em tempo de execução o controle do erro fica muito complicado, pois o compilador só vai perceber que a string que você informou trata-se de uma classe que não existe somente depois de tentar achar-la no contexto e não encontrá-la, o mesmo para a criação do Field, essa técnica é totalmente passível de erro por isso é até obrigatória estar em um bloco de tratamento de erro (ou em um throws).
A pedido do Gabriel vou informar que não quebrei a perna do Eduardo é apenas uma figura de linguagem e uma brincadeira que usamos para aprender (nenhum animal foi maltratado nessa elaboração do post)
Futuramente farei uma serie de post com um exemplo real de uso de reflection juntamente com criação de annotations assim que acabar a serie do RUP(Rica Utopia Pobre) até lá.Postagens Relacionadas:
- POO(Programação orientada a Objetos) em PHP (parte 1)
- POO(Programação orientada a Objetos) em PHP (parte 2)
- RUP(Rica Utopia Pobre) ou A vida como ela é.
- RUP(Rica Utopia Pobre) Parte 2
Acessando atributos privados com reflection Assine o Feed Grupo Haw FeedBurner
]]>
No dia 24 de fevereiro eu fiz a prova pra certificação Java da Oracle, mas precisamente a prova OCJP 5 (Oracle Certified Java Programmer) também conhecida como SCJP (Sun Certified Java Programmer).
Eu já tinha pretensão fazer a prova a um bom tempo, esse até foi um dos motivos da criação desse blog porém com o tempo estudando Java, por sempre tentar me aprimorar como programador lendo muitos blogs e pela maturidade natural que eu fui adquirindo eu percebi que há muitas coisas que aprender pra se tornar um bom programador, e essas habilidades vão além de saber bem uma linguagem de programação. E o resultado é essa pilha de livros:
Dieta de um Programador Junior
(Há outros livros que só chegaram depois dessa foto, e outros em uma listinha de compra. Alguma sugestão de livro? Deixe nos comentários ou pelo twitter)
Pelas minhas previsões eu não iria parar pra estudar pra certificação tão cedo. Porem…
Por meio do Twitter e seguindo o Jornal Java eu participei de um sorteio pra um Voucher Oracle. Para minha surpresa pela primeira vez na minha vida eu ganhei um sorteio! 
Sorteio Voucher - Gabriel Rubens. fonte: http://www.jornaljava.com/
Bom, como o Voucher tinha validade até o dia 25 de fevereiro e local que eu escolhi para faze a prova só tinha data até o dia 24 do mesmo mês esse foi o dia escolhido. Na época eu estava lendo o livro O Programador Pragmático e não queria interromper a leitura me sobraram uns 40 dias de estudo.
Com esse tempo pra estudar, por já ter o livro do exame SCJP 5 e por eu achar que é pouco tempo de estudo para o exame OCJP 6 (SCJP 6) que é em inglês eu optei por fazer a prova OCJP 5 em português.
A minha meta era ler o livro SCJP 5 inteiro fazendo códigos de exemplo e fazendo anotações para ler depois que acabar o livro. Também comprei o Guia de Bolso para SCJP do Camilo Lopes, sendo que esse ultimo eu tinha em mente de ler uns 4 dias antes da prova.
Feito o planejamento, o meu ritmo de estudo até que foi bom (não tão quanto o esperado), eu estava fazendo a leitura, escrevendo códigos de exemplo sempre sem IDE e fazendo anotações em documentos simples (cap1.txt, cap2.txt e etc…), e assim eu segui até um terço do livro onde pelos simulados eu havia notado que errava mais por falta de atenção (as pegadinhas), isso por um lado era bom, já que eu sabia o conceito e só tinha que me concentrar um pouco mais.
Só que aí venho uma surpresa mais que desagradável, fui roubado em plena luz do dia… Tudo bem (#not), infelizmente isso não é novidade pra ninguém, o problema é que eu fiquei sem notebook.
- E estando sem o note e fiquei:
- Sem os resumos feito nos txts;
- Sem os códigos de exemplo;
- Sem fonte de pesquisa na hora que eu estudava (em casa).
Apesar de utilizar o DropBox e o Ubuntu One Murphy marcou presença: Eu deixei as pasta de estudo na área de trabalho e não estava sincronizada nem pelo DropBox nem pelo Ubuntu One.
Só que eu gosto bastante da sabedoria popular que diz “Não adianta chorar pelo leite derramado” e infelizmente eu tinha certeza que o Boletim de Ocorrência foi só por protocolo (e perda de umas 3hr) sobrou procurar os lados positivos (nenhum! 
): O livro não estava na mochila e sobrava um tempo durante a hora de almoço que eu poderia aproveitar pra fazer alguns exemplos de código no computador do trabalho (sem dinheiro pra outro note)!
Passado isso voltei aos estudo (de forma bem mais lenta), só que não deu pra ler o livro SCJP todo, assim eu só li o resumo do capítulo sobre Threads e não li sobre formatação de String. Além de não ter feito o simulado desses dois capítulos (mas String já é parte da rotina).
Um dia antes da prova eu li o Guia de Bolso SCJP e no dia da prova eu fiz o simulado da Caelum (http://mock.caelum.com.br/) pra passar o tempo, já que eu acordei cedo e nesse dia fui dispensado do trabalho.
Resultado: Passei!
Contente por ter passado, é claro… Pero no mucho.
De certa forma eu já imagina que passaria, pelos resultados dos simulados do livro que eu tinha, só que ficou aquela sensação de que dava pra ser melhor, principalmente por não ter lido sobre Thread, que por sinal eu nunca fiz um código com Thread que foi pra produção.
Eu tinha em mente fazer um tutorial de como eu estudei, mas minha jornada não serve de exemplo de plano de estudo, acho que os exemplos do GUJ e até no Google são menos conturbados .
Mas o importante é que eu passei, já estou postando com outro note e voltei a ler a pilha de livros.
E com o jeitinho brasileiro que muitos acham que é sinônimo de malandragem, mas eu prefiro a visão do Andrew Smith trata no livro Jeito Brasileiro que é de correr atrás das metas. No final deu tudo certo.
Agora, que venha a próxima (menos conturbada, por favor!).
Obs: Não acho que o certificado garante que você é um bom desenvolvedor, mas é um ótimo modo de estudar e se testar. Vale a pena fazer!
Gabriel Rubens
Gabriel RubensPostagens Relacionadas:
- Iniciando em Ruby
- Regras de Interfaces Java
- Início
- O Efeito Stroop no desenvolvimento de software
- Método, Variável e Classe Final
- Os nomes são importantes
- Mestrandos do Grupo Haw
Certificado Java com o jeitinho brasileiro: Oracle Certified Java Programmer – OCJP/SCJP Assine o Feed Grupo Haw FeedBurner
]]>
Olá povo, estou aqui para continuar a serie de posts sobre a minha experiência com RUP, no ultimo artigo eu falei sobre a minha antiga empresa e o que aconteceu com ela quando resolveram adotar essa metodologia, expliquei as dificuldades que enfrentamos e ainda que essa mudança não foi uma boa escolha, pois o sistema não foi entregue e a maturidade da empresa não era satisfatória para essa metodologia.
Agora vou falar sobre a minha atual empresa e as dificuldades com essa metodologia, mas antes vou ressaltar que o intuito principal dessa serie de posts não é esclarecer o que é o RUP nem levantar uma bandeira contra ou a favor dessa metodologia somente quero compartilhar minha experiência com a mesma.
Perfil da empresa:
A empresa que estou trabalhando é uma multinacional de grande porte, do tipo que nem conheço metade do povo que trabalha na mesma divisão que eu, ela utiliza o RUP há muitos anos, sendo que possuem o IBM Rational como recurso adicional para o gerenciamento dos artefatos do mesmo, aqui nós utilizamos todas as documentações que a metodologia prevê, sempre voltadas as Demandas ou seja cada alteração em um ou “n” sistemas, gera uma demanda e a mesma tem toda a documentação responsável por dizer o que tem que ser feito, o que vai ser alterado e o que o cliente espera receber nessa demanda, não há uma centralização de documentação do sistema.
Para explicar melhor vai um fluxograma simples com uma visão bem macro (bem macro mesmo) dos procedimentos:
Cada passo descrito acima tem um ou vários documentos entregáveis, sendo que para evoluir há sempre o “De acordo” do cliente, a entrega das alterações são feitas em interações e o prazo para finalização total de uma demanda simples gira em torno de 3 meses.
Pontos Fortes
- Há um envolvimento pleno do cliente, pois o mesmo visualiza e aprova todos os passos do projeto
- Antes de mandar a demanda para TI o Consultor verifica se a necessidade do cliente dá para ser suprida por algum procedimento simples eliminando assim um desenvolvimento desnecessário
- Antes de envolver os sistemas o arquiteto verifica se há em algum sistema a funcionalidade desejada
- O arquiteto decide em qual sistema pertence a alteração dando assim maior lógica e especialidade aos sistemas
- São feitas varias entregas descobrindo antes de finalizado se há uma discrepância no que o cliente recebeu e o que ele esperava receber.
Pontos Fracos:
- Primeiro ponto fraco é que o fluxograma acima é Macro, sendo que há muitos outros passos a serem realizados e muitas outras documentações
- Uma demanda simples (acrescentar um campo de classificação) demora até 4 meses para entrar em produção.
- É extremamente caro manter esse esquema de trabalho, sendo necessários inúmeros profissionais e inúmeros documentos
- A linha que divide o que deve ser escrito em um documento ao que deve ser escrito em outro documento, as vezes é tão pequena que acabamos tendo documentos muito semelhantes.
- Apesar do envolvimento do cliente o mesmo não tem muita capacidade de decisão, pois aonde vai ser feito e o que vai ser feito fica a cargo da equipe de TI dizer (alguns Analistas aceitam sugestões do cliente)
- O orçamento é realizado apenas 1 vez na faze de estimativa, fazendo com que tenhamos que acrescentar 10 a 20% para cobrir eventualidades no projeto
- Caso o cliente queira algo simples como mudar o nome de um campo já especificado o desenvolvimento deve retroceder ao inicio atrasando assim ainda mais a data de entrega, e aumentado ainda mais os custos de manutenção.
Então povo, esse post acabou ficando muito grande vou deixar a conclusão para o próximo e ultimo post sobre o tema, te vejo láPostagens Relacionadas:
RUP(Rica Utopia Pobre) Parte 2 Assine o Feed Grupo Haw FeedBurner
]]>
Enfim, chegamos até aqui!
Depois de estimar tarefas, planejar iterações, brincar de Pôquer do planejamento e muito mais, precisamos nos reunir para alinhar o andamento do projeto.
Mas como sempre, nosso tempo é muito curto. Reuniões levam tempo, e esse tempo mais na frente pode deve fazer falta. O que faremos então, já que é preciso manter toda a equipe informada e caminhando junto?
Reuniões curtas e diárias. Mais conhecidas como Reuniões em Pé ou Stand-up Meeting.
Fonte: agilesoftwaredevelopment.com
Como o próprio nome já diz, as reuniões acontecem com todos os membros da equipe em pé, geralmente em círculo e deve durar no máximo 15 minutos para que não impacte no serviço diário.
Porque em pé?
Exatamente para não durar mais do que o planejado, pois ninguém gosta de ficar uma hora em pé.
O Líder de Projetos deverá conduzir a reunião mantendo a ordem e o foco. Somente uma pessoa fala por vez, os outros escutam. Cada participante responderá sempre a 3 questões básicas:
O que eu fiz ontem?
O que farei hoje?
Existe algo que me impede de fazer meu trabalho? O quê?
Cada membro responde as perguntas em um sentido anti-horário ou horário, a combinar antes. Todos devem se sentir a vontade para falar, a reunião diária é uma forma de obter informações para manter o projeto sob controle. Muitos membros se sentem incomodados em dizer que não fizeram nada ou repetir todos os dias a mesma tarefa, isso faz com que se empenhem mais.
Assim, um a um vai respondendo as perguntas e com as informações o Líder de Projeto já aproveita para atualizar o quadro de tarefas e o gráfico BurnDown. Como trabalhamos com iterações curtas, essa reunião nos dá um retorno imediato da situação, e assim podemos agir para evitar atrasos e outros problemas. O Líder de Projeto é o responsável por solucionar os problemas apresentados pelos membros da equipe.
A reunião deve ter local e horários fixos a serem cumpridos rigorosamente. Os atrasados devem ser “punidos” de maneira divertida, como por exemplo, pagar balas a todos os outros membros do time, ou até depositar uma quantia insignificante de dinheiro no “cofrinho” da equipe. Isso faz com que horários sejam respeitados e ninguém se sinta humilhado. Se desejar, um participante atrasado pode ligar e passar suas informações por telefone e o Líder do Projeto repassa a equipe, porém o “castigo” é aplicado da mesma forma.
Se algum membro ficar sem nada para fazer, deve ir junto ao Líder no quadro de tarefas, verificar se encontra algo que possa realizar. Caso contrário, passará o dia servindo os outros colaboradores com tarefas como buscar café, fazer massagem, comprar comida e etc. Isso faz com que ninguém queira ficar sem nada pra fazer.
Usar um despertador é uma boa idéia para avisar que os 15 minutos da reunião se esgotaram.
obs.: o que chamamos Líder de Projeto seria o Scrum Master da metodologia ágil Scrum, para saber mais sobre clique aqui
Este post foi escrito com base na leitura do livro Use a cabeça: Desenvolvimento de Software e continua…
Lucas MenezesPostagens Relacionadas:
]]>
Quando levantamos nossas funcionalidades, utilizamos roteiros de usuários ou histórias do usuário (user stories) para conhecer o nosso provável escopo do projeto. As histórias são representadas com um simples cartão que contém informações como título da funcionalidade, uma breve descrição, um campo para colocarmos nossa estimativa de tempo e um espaço para o cliente dar uma prioridade. No entanto, para começarmos a execução do projeto precisamos de um pouco mais.
Fonte: Scrum e XP direto das Trincheiras
Uma história (funcionalidade) pode ser quebrada em diversas tarefas menores, mantendo assim um controle melhor do andamento do projeto, já que o gráfico burndown é atualizado com mais precisão (a cada tarefa concluída). Com isso o Líder de Projeto tem um feedback mais rápido e pode interferir antes que a coisa realmente fique feia.
Assim como nossas histórias de usuário tiveram estimativas, as tarefas também podem ser estimadas.
Mas como?
Da mesma maneira, ou seja, Planning Poker. Com isso a nossa confiança no tempo previsto para realizar uma determinada história aumenta, já que a soma das estimativas das tarefas deve ser igual a estimativa da história a qual pertencem. Caso o número não bata, não se desespere. O fato de ter dividido as funcionalidades em pequenos pedaços nos permite ir encaixando aqui e ali conforme vai sobrando um tempo já que dificilmente nossas iterações serão cem por centro preenchidas.
Fonte: Scrum e XP direto das Trincheiras
O ideal é que a quebra em tarefas seja feita quando estamos estimando o prazo total do projeto para o usuário, porém nem sempre temos tempo para isso. Neste caso os roteiros de usuário são suficientes para que possamos organizar nossas iterações. Uma divisão a nível de tarefas faz com que não precisemos ignorar uma história de usuário inteira que depende de outra, pois sempre há alguma tarefa dela que pode ser adiantada.
Pegar todas as tarefas de um roteiro ou pegar uma de cada?
A resposta é quase sempre a mesma. Bom senso! Pode ser que algumas histórias tenham uma forte dependência de outro, nesse caso seria bom terminá-lo por inteiro logo. E como trabalhamos com iterações curtas o que vale mais para o cliente, duas funcionalidades pela metade ou uma funcionando?
Aparentemente é melhor pegar as tarefas de uma única história, mas se uma tarefa não pode ser executada antes da outra então é melhor dar outras tarefas para os desenvolvedores.
Este post foi escrito com base na leitura do livro Use a Cabeça: Desenvolvimento de Software e continua…
Lucas MenezesPostagens Relacionadas:
]]>
Hoje o assunto é usabilidade na WEB, começo este post com uma afirmativa: usabilidades de telas são tão importantes quanto ao código desenvolvido. Sim caro amigo leitor, muitos pessoas estão mais preocupadas em desenvolver códigos que agreguem valor ao cliente, códigos que utilizem os famosos design patterns, desenvolver com metodologias ágeis, códigos fáceis de se entender e fáceis de fazer manutenção. Isso é importante? Sim, isto é muito importante, mas isso é uma obrigação nossa como desenvolvedor, repetindo O B R I G A Ç Ã O nossa.
Todo sistema que nos dispusermos a desenvolver, deve ter o máximo de qualidade desde a análise de requisitos, passando pela codificação até a entrega do produto final.
Vamos adotar isso como uma verdade, vamos supor que todos deveriam fazer a melhor análise e melhor código do mundo, neste ponto estaríamos apenas no marco zero, o início de tudo, o cliente nos pagou para isso. E o usuário ficará verdadeiramente contente com isso? Claro que sim, o sistema funciona adequadamente.
Imagine o seguinte software desenvolvido: Navegabilidade ruim, necessário fazer vários cliques para se alcançar um resultado, tela visualmente poluída com muitas informações, cansativo de se trabalhar… mas que foram desenvolvidos através das melhores tecnologias, metodologias, empresas, ou seja, todos os melhores processos para uma boa codificação e tudo aquilo que está informado no primiero parágrafo deste post.
O cliente certamente dirá:
-Muito bom este software, verdadeiramente atende o que eu preciso.
Óbvio que o cliente apresentará satisfação, ele muitas vezes não conhece as tecnologias existentes. Ao ver o software realizando aquilo que ele necessita (ou seja alcançando o objetivo independentemente da complexidade que necessita para chegar em um determinado resultado) acredita que o software está perfeito.
Qual seria o diferencial do seu projeto neste momento? Com certeza a criatividade é o diferencial. Tornar o software o mais fácil possível ao usuário é um ato de criativadade que exige muita visão por parte da equipe de desenvolvimento para saber o que realmente torna o software em algo com qualidade.
Vou ilustrar uma idéia, comparemos duas lojas de roupas que vendem o mesmo produto, os produtos são de ótima qualidade, chamemos de loja 1 e loja 2.
Na loja 1, o cliente entra na loja e é mal atendido, já na loja 2 o atendimento é excepcional, o cliente se sente a vontade para escolher suas roupas.
Na loja 1 as roupas estão desorganizadas e o cliente tem que ficar procurando em que lugar da loja pode estar o roupa desejada, já na loja 2 existe divisão clara de setores dos tipos e tamanhos das roupas.
Na loja 1, existe muito barulho, ambiente é desconfortável, iluminação precária, filas enormes onde cliente chega a ficar por várias horas em pé, bla bla bla, na loja 2, existe som ambiente, clientes possuem total conforto para escolher, para efetuar o pagamento, cliente mal enfrenta filas e aguarda num lugar sentado podendo até tomar um chazinho.
Qual você preferiria? Se conhecessemos somente a loja 1, acharíamos que esta loja é um modelo de loja ideal, certamente compraríamos sempre lá pois os produtos são de ótima qualidade. Mas e quando chegar o concorrente, que foge desta visão de modelo, como ocorre na loja 2?
Mesma coisa é o software confuso e difícil, você vai utilizá-lo mas se surgir uma nova proposta que atenda a todos os requisitos e seja fácil e divertido, você vai desejar continuar com aquele software em sua empresa? Cuidado com o concorrente.
Portanto caro GHAW maníaco, na hora de desenvolver, não se contente somente em códigos e linguagens de programação, perceba aquilo que será verdadeiramente útil ao usuário na manipulação deste sistema criado. Qual será a melhor maneira do usuário pegar as informações na tela de uma forma fácil, rápida e extremamente agradável, faça-o se divertir com o visual das telas.
O cliente não quer saber que tecnologias e como o software vai ser desenvolvido, somente irá querer saber se o software atende aos requisitos e se atrativamente o software é gostoso de se trabalhar.
O que atrai o cliente sempre será a interface amigável, a usabilidade de fácil aprendizagem e divertida e por fim se realmente o sistema fazer aquilo que foi solicitado. Todos este critérios devem ser cuidadosamente analisados igualmente. Em relação ao código e a documentação, é obrigação dos profissionais de TI.
Muitas profissionais não se atentam ao que é uma perfumaria e ao que é verdadeiramente útil pelo usuário.
Perfumaria é tudo aquilo que você coloca a mais que não tenha efeito positivo ou negativo, mas fica legal na visão do profissional de TI. Tudo que apresenta efeitos positivos ao usuário deixa de ser perfumaria.
Vamos tornar o mundo virtual melhor, mais agradável e na hora de planejarmos um software, percebamos o quão importante é a usabilidade. Usabilidade é tão importante quanto os código desenvolvido.
Vamos abrir os olhos amigos desenvolvedores bitolados em tecnologias porque o usuários e clientes pedem um pouquinho de atenção, mesmo sem dizer uma só palavra.
Seu feedback é extremamente importante para nós, se você leu e achou interessante, me responda, se por acaso leu e não gostou me responda também, agora se você leu e não achou nada…hãããã… vá ler outro post.
Eduardo GomesPostagens Relacionadas:
- Nenhuma postagem encontrada
Usabilidade para sistemas WEB Assine o Feed Grupo Haw FeedBurner
]]>
Amigo leitor, você já deve ter percebido que este blog é mais voltado para assuntos sobre desenvolvimentos de softwares, pois bem, me deparei com um problema extra desenvolvimento, minha namorada comprou um netbook sob minha indicação e descontente com o S.O. (Linux Mandriva) do netbook que comprara, pediu amigavelmente, tranquila e serena para que eu mudasse para o fabuloso WIINDOWS 7.
-AAAAAA, você vai ter instalar aquele Windows novo aqui!!!!!!
-Mais amor, o Mandriva é…
-Nããããooooooo quero isso aqui maissss!
Aiii, aiii, mulheres são tão compreensíveis.
Bom, mas pensei: Isso é tarefa ganha!
Mas com um DVD com o Windows Seven na mão e com minha percepção apurada rapidamente notei que netbooks não tem drivers de DVD somente portas USB. HÃÃÃ, e agora, pensei?
Fui em busca de solução, perguntei pra um e pra outro e sempre me retornavam soluções nada fáceis, teve até gente que se propuseram a me ajudar por apenas míseros R$50,00. O que são 50 pilas hoje em dia?
Demorou cerca de 3 dias pra eu ter uma idéia fantástica, pesquisar no Google.
Então foi aí que encontrei a luz para este problema, a solução megablaster enfim estava descrita no blog do Taylor Lopes (http://taylorlopes.com/?p=1552). UHUUUUU, era do jeito que eu queria, simples, fácil e rápido de se fazer.
Aí vai a dica…
MODO DE FAZER:
- Primeiramente criar um arquivo de extensão ISO do DVD do WINDOWS SEVEN (windows7.iso).
Para fazer isso, baixei do BAIXAKI ( www.baixaki.com.br) o programa CDBURNERXP (É um software gratuito).
— Instale e abra o CDBURNERXP.
— Escolha a opção COPIA DISCO.
— Na aba OPÇÕES DE CÓPIA, selecione o DVD que já deve estar no DRIVER.
— Selecione a opção DISCO RÍGIDO, informe o local e o tipo de arquivo que deve ser ISO.
— Clique no botão em COPIAR DISCO.
— Até aqui o arquivo já foi gerado. Qualquer dúvida sobre a extensão veja as propriedades do arquivo, lá o campo Tipo de Arquivo terá a descrição “Arquivo do WinRAR (.iso)”.
- Segundo, deve baixar gratuitamente do site da microsoft ( http://store.microsoft.com/help/iso-tool ) o programa “Windows 7 USB” (aqui está o link direto ).
Observações, o pen drive deve ser superior a 4GB, eu utilizei um de 8GB porque no de 4 (tamanho é precisamente 3,72GB) não coube.
- Instale e abra o WINDOWS 7 USB.
- Em source File selecione o arquivo ISO que você criou.
- Conecte o PEN DRIVE
- Clique em NEXT.
- Clique em USB DEVICE
- Selecione a mídia PEN DRIVE
- Clique BEGIN COPYING
- Uma caixa de diálogo surgirá, clique em ERASE USB DEVICE.
- O pen drive bootável será criado neste instante.
- Ao término você poderá utilizar seu pen drive para instalar o Windows Seven em seu netbook.
- No netbook, acesse o SETUP (geralmente é tecla f2, depende do fabricante) e escolha opção para dar boot pelo dispositivo USB.
- E por fim, uma dica preciosa do blog Taylos Lopes, “Durante a instalação, quando for feito o primeiro reboot automático do sistema, então TIRE O PENDRIVE para não bootar novamente por ele.”
Pronto, sua namorada também ficará muito feliz inclusive esse foi o presente de aniversário que dei pra ela e você ainda vai ser aclamado por muitos como o grande mestre da computação e por outros será chamado de mágico, porém alguns falarão:
- Isso eu já sabia, perdi meu tempo lendo isto.
Eduardo GomesPostagens Relacionadas:
Instalação do Windows 7 em NetBooks Assine o Feed Grupo Haw FeedBurner
]]>
Olá amigos, depois de um bom tempo sem postar no GrupoHaw, volto novamente aqui para continuar o tema sobre Orientação a Objetos em Cinco Minutos, aproveito para informar–lhes que “cinco minutos ” não é um valor fictício, pois se você gostar realmente deste tema você aprenderá todos os conceitos em aparentes 5 cinco minutos de uma forma bem agradável, mas por outro lado se você não gostar…. e continuar insistindo nessa, o tempo será muito mais longoooooooo e muitas vezes chato, quem sabe você aprenda orientação a objetos em uns 250 anos.
Bom, deixe-me contar um fato que ocorreu com o código do programa para fábricas de carros, pois bem, um dia desses o Wenderson (o cara dos Posts de PHP) testou meu código e disse o seguinte:
- AHAHAAH seu código esta furado…. eu consigo fazer o carro decolar sem ter que atingir a velocidade máxima.. AHAHAHAHA
Ele me apresentou sua classe de testes assim:
public class FabricaDeCarrosDoWenderson {
public static void main(String[] args) {
Carro carro1 = new Carro();
carro1.nome = "Carro Alegórico";
carro1.marca= "FastWend";
carro1.velocidadeMaxima=1000;
carro1.quantidadeDeMarchas=5;
carro1.velocidadeAtual=1000;
carro1.decola();
}
}
Puuutz, realmente o Wenderson acabou de quebrar minha regra de negócio que diz: “Para um carro decolar ele precisa atingir a velocidade máxima”.
Eu tinha que fazer algo, mas o que???? O que?????
Foi aí que me lembrei dos modificadores de acesso (public, private e protected), ahahaaha Wenderson, quem ri por ultimo ri melhor….ahahah !!!
Minha classe Carro, possui atributos que estavam em “default”,
Eu explico melhor, o Wenderson verificou que meus atributos não possuiam modificadores de acesso como public, private ou protected e se aproveitou da oportunidade.
Atributos que não possuem esse modificadores de acesso, por padrão é default, ou seja, pode ser acessado por objetos em outras classes no mesmo pacote, como aconteceu no nosso caso.
Foi criado na classe FabricaDeCarrosDoWenderson um objeto do tipo Carro e foi acessado um atributo (velocidadeAtual) que serve unicamente para a regra de negócio funcionar não devendo ser manipulado por ninguém somente pelo próprio programa.
Na mesma situação estão os atributos marchaAtual e estaVoando (que devem ser acessados somente pelos métodos da classe Carro, caso contrário poderá mudar toda a regra de funcionamento do programa).
Mas como eu falei anteriormente, “vou quebrar as pernas do fulano” desta forma: vou bloquear o acesso direto a esses atributos colocando a palavra private na frente dos atributos que quero…AHAHAHAHAHA!!!
O código dos atributos da classe “Carro” vão ficar assim:
class Carro{
String nome;
String marca;
int velocidadeMaxima;
int quantidadeDeMarchas;
private int marchaAtual=0;
private double velocidadeAtual=0;
private boolean estaVoando;
- AHHAHAHAHAHAHAHAHA….. fechei o acesso a esses atributos… somente os métodos dessa classe tem permissão para acessar estes atributos… (falei para o Wenderson)…
Mas o Lucas que não tinha nada pra fazer e estava “fuçando” o código, descobriu mais alguns problemas….
- Esse “@$#%$$#$&!!%” só me arranja problemas…..
Só pra deixar claro o funcionamento dos modificadores de acesso, estes são utilizados não só em atributos, mas também em métodos e nas próprias classes contribuindo para garantir o encapsulamento
Definição para Encapsulamento: Encapsular é apenas o fato de esconder o funcionamento interno de rotinas ou atributos, pois quem utiliza um objeto de uma certa classe não precisa saber como ela funciona e sim o que ela faz.
| Modificador de acesso | Observação | Onde pode ser usado |
| public | Permite acesso em qualquer parte de um projeto. | Classe, Método e Atributos. |
| private | Não permite acesso fora da classe da qual pertence. | Metódos e Atributos. |
| Protected | Deixará visível para todas as classes e subclasses que pertençam ao mesmo pacote. | Classe, Método e Atributo. |
| ” “(default) | Não é um modificador de acesso e permite acesso somente no mesmo pacote. | Classe, Método e Atributo. |
Bom termino este post, mas logo logo vou voltar aqui para resolver mais alguns probleminhas recém descobertos…
Eduardo GomesPostagens Relacionadas:
Orientação a Objetos em cinco minutos (parte 2 – encapsulamento) Assine o Feed Grupo Haw FeedBurner
]]>
Resolvi escrever sobre essa metodologia após muitos aborrecimentos e tristezas no coração sendo meu principal intuito o de compartilhar minhas experiências com a mesma, coloquei esse nome no post,, pois ela é extremamente Rica de documentos e burocracias, uma Utopia que as grandes empresas gostam de seguir, as quais não conseguem enxergar que o RUP é Pobre de informação, assim como dizia o Renato Russo “O que é demais nunca é o bastante”.
Antes dessa empresa que trabalho eu trabalhei em outra que nunca havia utilizado nenhuma metodologia de analise, os clientes tinham contato direto com os Programadores, solicitavam o que queriam e o mesmo fazia a alteração necessária, funcionava até bem, mas como não havia uma cobrança no sentido de comentar o código e de fazer a nomeação certa nos métodos, acabou que a empresa ficou “na mão” dos programadores, pois só quem fez a merda a reconhecia, o pior é que era uma empresa do setor publico, então o chefe não conseguia melhorar a vida do programador para poder segurar ele na empresa;
Com a vazão dos programadores houve vazão do conhecimento, então alguém em um momento de extrema burrice decidiu que precisava documentar tudo sendo que no próximo contrato seria uma premissa obrigatória a adoção do RUP.
Mas a equipe responsável por esse contrato era extremamente pequena, então fizemos uma “customização” no RUP, tiramos quase todos os documentos e deixamos ele mais leve (pelo menos é o que pensávamos), ao começar o trabalho percebemos o quanto seria difícil manter o documento atualizado, foi necessário realizar muitas mudanças em documentos já entregues, pois ao se deparar com um outro caso de uso percebíamos que precisávamos integrar esse ao anterior, então voltávamos e alterávamos os 2, isso acabou sendo um trabalho exponencial, já que a equipe não teve um treinamento adequando para se trabalhar com essa metodologia e ainda muitos nem tinham interesse de aprender tendo em vista que não é uma maneira agradável de trabalhar.
Como conclusão, se passaram quase 2 anos e ainda não entregaram nem um décimo do que deveria ter sido realizado, as iterações foram planejadas muito dsitantes e ainda acabaram não conseguindo acontecer pois decidimos começar o projeto pelas beradas ao invés de começar pelo principal (o que realmente agregaria valor ao cliente), e quando o coração do sistema foi analisado percebemos que teríamos que alterar todos os Casos de Usos projetados até o momento, bom esse projeto ao qual me refiro não foi problema somente do RUP a empresa contratada para realizar a programação também era muito incompetente e inexperiente, e ainda nosso responsável não tinha “Culhao” para falar “Errei vamos rever tudo”.
Se tivéssemos usado uma maneira mais ágil no trabalho, perceberíamos o erro mais cedo e conseguiríamos resolver.
Esse post continua irei comentar a respeito da minha atual empresa e colocarei a conclusão geral no próximo post até lá.
Wenderson LisardoPostagens Relacionadas:
RUP(Rica Utopia Pobre) ou A vida como ela é. Assine o Feed Grupo Haw FeedBurner
]]>
No post passado aprendemos como estimar nossas funcionalidades para dar ao cliente um prazo. Somando as estimativas chegamos a um número final. Porém, como levamos em consideração o tempo que 1 desenvolvedor sozinho seria capaz de concluir cada tarefa, devemos agora dividir esse número pela quantidade de programadores na equipe
Finalmente, esse é o nosso prazo! Mas não se anime, o cliente quase nunca concorda.
Suponhamos que ele exija proponha um prazo menor. Teremos então que re-planejar nosso cronograma, ou seja, estabelecer o tempo de nossas iterações. Mas como saber se nossa equipe é capaz de fazer no tempo que ele pediu?
Com a certeza de que ninguém é produtivo por todo o tempo, usaremos uma fórmula baseada na velocidade da equipe para saber quanto tempo levaríamos para terminar um trabalho.
Na fórmula, a velocidade significa a porcentagem produtiva do tempo que temos. Por exempo, 0.7 significa que 70% do nosso tempo é realmente produtivo. Alguns livros dizem que esse é um bom número para começarmos. Depois conforme vamos obtendo os resultados, podemos reajustar o valor.
Vamos a um exemplo numérico para facilitar.
O cliente nos deu um prazo de 90 dias para entregar o sistema a desenvolver. Então podemos fazer 3 iterações de 1 mês. No entanto, tirando os finais de semana, nossa iteração de 1 mês equivalerá a 20 dias de trabalho.
Levando em consideração que temos 3 desenvolvedores na equipe, utilizaremos o seguinte cálculo:
O número acima é a capacidade real que nossa equipe tem de produzir num ciclo de 1 mês (20 dias úteis). E é com esse número que escolheremos as tarefas de cada iteração, não esquecendo a priorização feita pelo usuário.
Cada iteração deverá ter no máximo 42 dias de tarefas a realizar. Podemos colocar 4 tarefas de 10 dias e 1 de 2 dias, por exemplo.
Controlando o andamento do projeto.
Existe uma ferramente muito útil para saber como estamos nos saindo a cada dia que passa da nossa iteração. Essa ferramenta é o gráfico Burndown.
Burn Down Chart (Gráfico Burn Down)
O gráfico é utilizado para cada iteração que se inicia, colocando no eixo y (vertical) os dias de trabalho a realizar naquela iteração e no eixo x (horizontal) a quantidade de dias da iteração. A cada término de expediente o gráfico é utilizado ou então logo pela manhã quando o expediente começa.
Nele podemos observar o trabalho realizado, o que resta e quanto tempo já se foi. Além de nos dar uma visão de como anda nossa iteração.
Utilizando os métodos descritos acima, nossas chances de terminar o projeto a tempo aumentam.
Esse post foi escrito com base na leitura do livro Use a Cabeça: Desenvolvimento de Software e continua.
Postagens Relacionadas:
]]>
No post passado começamos a falar sobre princípios de como desenvolver software usando como base a leitura do livro Use a Cabeça: Desenvolvimento de Software. Foi explicado que dividindo o nosso projeto em iterações podemos nos aproximar daquilo que o cliente realmente precisa, obtendo seu feedback e mostrando o andamento do projeto em pequenas partes de Software funcional.
Vimos também que é muito importante que o cliente priorize as funcionalidades a serem desenvolvidas, pois temos um prazo a cumprir e nem sempre tudo caberá no período acordado para entrega do produto.
Para dar ao cliente um prazo, a nossa equipe precisa realizar a estimativa de tempo de cada tarefa a ser construída durante o nosso processo de desenvolvimento. Uma forma de se fazer é reunir a equipe e mostrar uma funcionalidade, daí cada membro dará sua estimativa para que ela seja desenvolvida. É importante que um membro do time não saiba previamente a estimativa do outro para não ser influenciado, todos podem escrever em uma plaquinha e mostrar simultaneamente quando solicitado pelo líder da reunião. Os “palpites” devem ter unidade definida antes da reunião começar e normalmente é utilizado dia/programador, ou seja, quantos dias um programador sozinho leva para realizar determinada atividade.
Fonte: superstock.com
É necessário que não hajam suposições sobre o que se refere a funcionalidade estimada, caso os participantes estejam em dúvida é aconselhado entrarem em contato com o cliente para esclarer realmente do que se trata. Após entrarem em consenso, passamos para a próxima funcionalidade até terminar todas.
No final, basta somar cada uma e teremos o prazo do projeto. Mas e quando as estimativas forem muito diferentes uma das outras? O que posso fazer? Bom, é extremamente aconselhável que os valores sejam colocados com confiança, e para isso todos precisam saber exatamente sobre o que se trata a funcionalidade em questão. Existe uma técnica conhecida como Pôquer do Planejamento que nos auxilia em casos de divergências na Estimativa.
Planning Poker – (Pôquer do Planejamento)
O pôquer do planejamento é uma técnica para auxiliar na estimativa de estórias ou funcionalidades quando há muita divergência por parte da equipe. Pode ser feito da seguinte forma:
- Colocar um cartão com o nome da funcionalidade/estória e sua descrição no centro de uma mesa onde todos participantes possam ver.
- Distribui um baralho com 13 cartas a todos os membros do time. O baralho pode ser visto na figura.
- Todos escolhem uma carta com o valor estimado e colocam virada para baixo.
- Ao combinado, todos viram sua carta ao mesmo tempo.
- O responsável por comandar a reunião anota o valor das cartas.
- Cada um explica o motivo da escolha.
- Participantes conversam para entrar num acordo.
Fonte: crisp.se
Cada carta da imagem corresponde ao valor numérico em dias, o valor “0″ informa que a funcionalidade já está pronta, a carta “?” significa que a pessoa não tem a mínima idéia e a carta com uma xícara significa “que tal uma pausa para o café?”.
É importante ressaltar que as estimativas devem levar em conta todas as etapas seguidas no nosso processo de desenvolvimento, ou seja, cada uma deve ter projeto, codificação, teste e entrega. Intervalos grandes de valores podem significar mal-entendido e é sempre bom contactar o cliente.
Enfim, como deu para perceber a idéia é sempre a mesma. Entrar em acordo e esclarecer as dúvidas sobre o que deve ser feito. Se não quiser realizar o pôquer do planejamento pode simplesmente trancar os membros da equipe em uma sala, dar-lhes Coca-Cola e pizza e dizer “Só saiam daí quando tiverem um valor”.
Esta postagem foi escrita com base no livro Use a cabeça: Desenvolvimento de Software e continua.
Lucas MenezesPostagens Relacionadas:
- Desenvolvimento de Software não é especulação!
- Terminando a tempo!
- Quebrando em Tarefas!
- Todos de pé!
- PMBOK 4ª edição – Rapidinho
- Controle de Versões – Rapidinho
Quanto tempo leva? – Planning Poker Assine o Feed Grupo Haw FeedBurner
]]>
Um software de qualidade necessariamente precisa atingir os 3 princípios básicos de qualquer projeto:
* Requisitos do cliente //afinal esse é o motivo do projeto
* Prazo //sejamos pontuais, like british people
* Custo //pedir mais dinheiro é uma coisa muito feia
Itere sempre!
Clientes são ansiosos e entregar-lhe pedaços de software funcional por mais simples que sejam lhe dá mais tempo para trabalhar. Além disso, é uma maneira de obter um valioso feedback e descobrir que estás no caminho certo (amém).
Caso não esteja, descobriu a tempo de corrigir. Ou preferes entregar tudo no fim e saber que não foi o que ele pediu?
Ao ver partes do sistema funcionando o cliente pode orientá-lo melhor quanto alguns requisitos que talvez não tenham ficado claros. É uma boa estratégia e assim ele pára de ligar de 10 em 10 dias para encher o saco.
A cada iteração o software se torna mais completo e “consertamos” o que o cliente não gostou, podendo estar sujeitos a novas idéias, porém lembramos que há um prazo a cumprir
Faça com que o cliente priorize!
Muitas vezes surgem mudanças e nova idéias motivadas pelas pequenas entregas de software, no entanto nem sempre o prazo combinado comporta a inclusão de novos requisitos. O que fazer?
Deixe que o cliente decida o que deve ser priorizado. Ninguém melhor que ele para saber o que é mais importante ser feito primeiro.
Este post foi escrito a partir do Use a Cabeça Desenvolvimento de Software e continua..
Lucas MenezesPostagens Relacionadas:
- Quanto tempo leva? – Planning Poker
- Terminando a tempo!
- Quebrando em Tarefas!
- Controle de Versões – Rapidinho
- Todos de pé!
- PMBOK 4ª edição – Rapidinho
Desenvolvimento de Software não é especulação! Assine o Feed Grupo Haw FeedBurner
]]>
E exatos 8 dias atrás eu participei do evento denominado Encontro Ágil 2010, fui lá com bastante curiosidade pra conhecer um evento que não tem palestras… Então parti pra minha peregrinação até a Selva de Pedras.
Pra minha surpresa esse foi o evento mais inovador que eu já participei, com o formato totalmente diferente de outros, onde não havia uma pessoa falando e outras com o caderninho anotando e ouvindo, simplesmente todo mundo era “palestrante”.
Pela primeira vez eu tive a oportunidade de participar de um Open Space, onde alguém escolhia um tema, o horário e um local e quem estivesse disposto a discutir o assunto era só se apresentar no local marcado, e caso não gostasse do assunto era só olhar pro lado e escolher outro das dezenas de assuntos que estavam sendo discutidos simultaneamente.
Não tenho muito pra falar das palestras, já que elas não houveram, simplesmente quis escrever esse post para parabenizar os organizadores, pois criaram o melhor evento que eu já tive oportunidade de participar.
O pessoal da Bluesoft criou um vídeo com alguns trechos do eventos. E pelo vídeo da pra ver como em quase todas as salas as cadeiras estão organizadas em grupos, e não para uma pessoa na frente, e é assim que o evento foi, mão na massa.
O evento em uma palavra? Fantástico!
Até a próxima edição do Encontro Ágil.
Gabriel RubensPostagens Relacionadas:
- Terceiro Encontro Ágil – Eu Vou!
- Resumo TDC 2010 – Domingo
- Resumo TDC 2010 – Sexta
- Resumo TDC 2010 – Sábado
Terceiro Encontro Ágil – Eu Fui! Assine o Feed Grupo Haw FeedBurner
]]>
No próximo sábado dia 6 de novembro acontece o Terceiro Encontro Ágil, o evento em que os organizadores fazem questão de deixar claro que não haverá palestras apenas os três tipo de atividades: workshops, lightning talks e open spaces.
E com várias opções de atividades eu ainda tenho que fazer o meu planejamento, e como vou com o companheiro de trabalho Valdilanio, vamos fazer duas threads pra depois compartilhar o conhecimento.
Infelizmente eu só fiz minha inscrição na prorrogação (dia 3 de novembro no final da tarde) não deu tempo de anunciar o evento.
Igual a todo estagiário que se preze eu não tenho carro, então lá vou eu fazer aquela aventura até São Paulo novamente com todo o conforto do nosso transporte público (ônibus, metro, trem e etc…).
Fonte: http://www.flickr.com/photos/brazilnut72/4075222914/
Então sabadão direto de Santos pra São Paulo, EU VOU!
Gabriel RubensPostagens Relacionadas:
- Terceiro Encontro Ágil – Eu Fui!
- Resumo TDC 2010 – Sábado
- Resumo TDC 2010 – Domingo
- Resumo TDC 2010 – Sexta
Terceiro Encontro Ágil – Eu Vou! Assine o Feed Grupo Haw FeedBurner
]]>
E dando continuidade a leitura e o resumo do Programador Pragmático…
Tendo em mente que nunca criaremos um software perfeito, devemos nos precaver, por exemplo, quando temos que alterar uma classe que outro programador fez, nós testamos antes, verificando se não há bugs para só então modificar. Temos a tendência de achar que o que nós fizemos está certo, que o nosso modo é o melhor. Programadores pragmáticos não se previnem só com os outros, eles sabem que também erram e se previnem deles mesmo.
Contratos
No nosso cotidiano estamos acostumados fazer acordos dos mais variados tipos, onde as partes se comprometem a cumprir algo. Alguns usam apenas a palavra, mas isso dificilmente funcionária com a companhias de fornecimento de Água, Luz e etc… O modo mais comum de estabelecer responsabilidades são os contratos, que definem condições para o uso de determinado recurso.
Do mesmo modo que garantimos uma condição em nosso cotidiano podemos fazer com a programação. Definindo contratos que obriguem a todos a cumprirem as pré-condições e assim garantir as condições posteriores. Como foi dito no início do post, programadores pragmáticos são prevenidos, e a técnica de projeto por contrato pode ser uma ótima maneira de garantir pré-condições e pós-condições para o uso de um método.
Para saber mais leia sobre Design by Contract.
Programas mortos
Sempre que algo inesperado acontecer encerre o programa, como os altores escrevem “Programas mortos não mentes.”
Quando um erro ocorrer, o melhor que seu programa pode fazer é parar a execução, pois nada que vier após erro não terá garantia de integridade. Um programa parado não causa danos, mas um programa sendo executado com dados imprecisos podem causas erros, e esses erros podem ser difíceis de serem vistos.
Cuidado com as Exceções
Quando resolver lançar uma exceção, verifique se é mesmo necessário, pois há casos em que um verificação por método ou um if pode ser mais conveniente.
Usar exceções de forma indiscriminada pode quebrar o encapsulamento, já que o chamador pode fica mais acoplado ao método que é chamado.
Lidando com recursos
Como diria o Arnaldo César Coelho “a regra é clara”, crie, utilize e descarte. Há casos e casos, mas no geral é isso que devemos fazer: Abrir um transação, utilizar e fechar, assim evitamos surpresas. Outra coisa que devemos ter em mente é que quem aloca o recurso deve liberá-lo, em muitos casos isso significara que o método que aloca o recurso é quem deve liberá-lo.
Quando trabalhamos com linguagens que fornecem suporte a Orientação a Objetos esse trabalho pode ser ainda mais indolor, podemos encapsular os recursos em classes, e quando criamos instancias dessa classe o recurso é alocado, assim que o objeto sair do escopo o coletor de lixo entrará em cena, varrendo o objeto e consequentemente o recurso que ela encapsula.
Uma prática normalmente utilizada por programadores de C++ é a configurar as referências a Objetos já utilizados com null, e em linguagens como Java isso ajuda a diminuir a quantidade de referencias que apontam para Objeto, desse modo pode ser que ele seja qualificado para o coletor de lixo mais rápido.
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – parte 7
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – Resenha do prefácio
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – parte 6
- O Programador Pragmático – Capítulo 1
O Programador Pragmático – parte 8 Assine o Feed Grupo Haw FeedBurner
]]>
Como prometido pela Canonical hoje dia 10/10/10 foi lançado o Ubuntu 10.10 Maverick Meerka.
Para saber mais características: http://www.ubuntu.com/desktop/features
Ubuntu 10.10 Maverick Meerkat
A página oficial de download: http://www.ubuntu.com/desktop/get-ubuntu/download
Download alternativo: http://www.ubuntu.com/desktop/get-ubuntu/alternative-download
Em breve o site em português www.ubuntu-br.org também deve atualizar a página de download.
No caso de quem está com outro sistema operacional há ainda a alternativa de utilização diretamente pelo CD ou via USB.
Vale da uma olhada sem compromisso no Live CD, se você gostar e não quiser tirar o outro sistema operacional há alternativa do dual boot.
Gabriel RubensPostagens Relacionadas:
Lançamento do Ubuntu 10.10 Maverick Meerka Assine o Feed Grupo Haw FeedBurner
]]>
E seguindo a série de post… Aqui vai mais um que também fala em aumento de produtividade com a automação de tarefas recorrentes.
Escrevendo código que cria código
Muitas vezes nos temos tarefas repetitivas quando estamos em determinado projeto, como as tradicionais classes só com getters e setters, e para diminuir essa tarefas algumas IDEs fornecem atalhos. Mas há casos específicos que não são cobertos pela IDE, como uma classe Dummy que simplesmente tem os mesmo métodos e atributos da Entity ou a arquitetura em camadas que deve seguir uma regra específica de nomeação das classes, em fim, isso vai depender do seu problema.
Para esses casos devemos criar um programa que faça isso, já que teremos que gastar tempo criando uma determinada estrutura repetidamente, podemos investir em automatizar essa tarefa, e uma soluções é criar código que gere código.
Para facilitar ainda mais o trabalho devemos escolher uma linguagem que facilite o processamento de texto, no livro os altores falam muito de Perl.
Um exemplo disso é o Hibernate que permite gerar o banco de dados através das classes anotadas com @Entity do sistema, ou gerar o banco e as classes o partir do arquivo XML. E assim conseguimos seguir o principio “Não Se Repita”, já que as informações que devem ser iguais (tabela e entity) passam a ser geradas automaticamente ,e se a estrutura muda é só gerar as classes novamente. Outro exemplo é os Scaffold do Rails e o recém-lançado VRaptor Scaffold.
Para facilitar ainda mais o nosso trabalho devemos utilizar o mesmo principio de texto simples dito no post anterior (também XML ou YAML), assim com esse texto podemos gerar classes a partir de linguagem diferentes.
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – parte 6
- O Programador Pragmático – parte 8
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – Capítulo 1
- O Programador Pragmático – Resenha do prefácio
- Livro SCJP (guia de bolso)
O Programador Pragmático – parte 7 Assine o Feed Grupo Haw FeedBurner
]]>
Aqui estou no terceiro capítulo do livro, mais empolgado que nunca, e vendo que ainda tenho muito que aprender. As vezes a leitura me faz parar pra refletir um pouco no meu dia a dia, exemplo disso são as anotações que eu estou mantendo em um txt para poder comparar as estimativas com o tempo que realmente eu gastei nas tarefas.
Outro exemplo é que eu acabei o segundo capítulo é já coloquei outros livros na lista de compras, dessa vez livros de regex, Shell Script, Python e outros.
Mais uma coisa, eu decidi que não vou mais ficar escrevendo resumos de cada capítulo, de agora em diante eu simplesmente vou lendo e fazendo minhas anotações, então poderá ter capítulos divididos em vários posts e mais de um capítulo em um post.
Então até agora ficou assim:
O Programador Pragmático – Resenha do prefácio
O Programador Pragmático – Capítulo 1
O Programador Pragmático – Capítulo 2 – primeira parte 1
O Programador Pragmático – Capítulo 2 – segunda parte 2
E de agora em diante será: O Programador Pragmático parte 6, parte 7… E assim por diante.
Agora continuando com o resumo…
Logo no inicio o livro fala sobre saber utilizar e bem as ferramentas que temos em mão, assim podemos ampliar nossa capacidade. Só que ao mesmo tempo não devemos ser totalmente dependentes delas, principalmente as do tipo “next, next e finish”.
Texto Simples
Na hora de escrever algo, prefira escrever textos simples e que sejam legíveis por pessoas e máquinas, como por exemplo o XML. Qual a vantagem disso? Textos simples não dependem de nenhuma implementação, qualquer linguagem de programação pode ler e escrever e assim que você bate o olho consegue entender. Veja esse texto:
nome=gabriel
nome:gabriel
Esses dois exemplos são textos que podem ser facilmente lidos por um programa ou pessoa, agora imagina se isso estivesse e hexadecimal ou binário.
O Problema com a IDE
Muitos de nós nos acostumamos com as facilidades de arrastar, copiar e colar que temos com as ferramentas de desenvolvimento, já que está tudo ali, é só ir no menu e selecionar uma opção que tudo é executado como mágica. Isso é ótimo e nos proporciona produtividade, como por exemplo as Refatorações do Eclipse, mas, não devemos ser totalmente dependentes da IDE.
Como diz no livro a grande jogada do IDE é “o que você vê é o que você tem”, mas por outro lado “o que você vê é tudo que você tem”.
Com uma IDE ficamos limitados as suas ferramentas ou se dermos sorte podemos adicionar algum plugin, já com a utilização de comandos em Shell temos todas as combinações possíveis.
Se você ainda não está convencido do poder da utilização do Shell, compre o livro que os altores dão vários exemplos de tarefas por linha de comando (uma página inteira).
Mais uma coisa… Sabe aquela tarefa que deve ser executada todo santo dia? Não seria melhor criar um script pra isso?
Se você também é adepto a sistemas Linux ótimo, você tem uma excelente ferramenta pra criar seus scripts, caso contrário procure ferramentas para utilização de comandos Unix no Windows, pois eles são mais poderosos.
Conhecendo o Editor
Como artesão temos como ferramentas os editores de texto, e assim como o pintor utiliza pincel para colocar no quadro a sua criatividade devemos utilizar os editores de texto. O ideia é que os atalhos sejam automáticos e que você não tenha que parar pra pensar quando for utilizar o seu editor, por isso o ideal é ter um único editor de texto. Assim podemos programar sem tira as mãos do teclado, e isso é muito mais rápido que pegar o mouse e ir no menu.
Também não podemos exagerar e utilizar o bloco de notas do Windows, já que ele não possui nenhuma característica que facilite nosso trabalho. No meu caso eu utilizo o NotePad++ com alguns plugins no Windows, e no Ubuntu o Gedit com plugins, e os dois sistemas também estão com o Eclipse.
Depois dessa leitura eu procurei no Google alguns atalhos paro Eclipse e achei esses links:
http://www.n0sl33p.org/dev/eclipse_keys.html
http://eclipse-tools.sourceforge.net/EclipseEmacsKeybindings_3_1.pdf
Controle de Versão
Esse assunto já deve ser entendo pela maioria, e se você não conhece é só da uma procurada no google por Subversion, Mercurial, Bazaar e Git e etc… Sobre o Git há um screencast muito bom feito pelo Akita que é bem barato.
Quem deu commit nessa classe com Bug?
A resposta é simples: Não importa quem, é problema SEU.
Essa é a primeira postura que devemos tomar, ao invés de procurar culpados encontre a solução!
Antes de começar a procurar o erro você deve ser desarmar, e evitar ficar se esquivando, depois a regra é: Não entre em pânico.
E como é da filosofia pragmática, saiba que não adiante resolver o problema de forma isolada, procure “agente transmissor” do problema.
A primeira dica que fica é que devemos obter o máximo de informações possíveis, e para isso talvez seja necessário entrevistar o usuário.
E para encontrar o bug podemos utilizar as ferramentas que já vem na IDE, onde você pode ir acompanhando os valores das variáveis. Esse trabalho também pode ser feito com papel e caneta.
Outra técnica para encontrar a causa do problema é explicar para outra pessoa, muitas vezes a outra pessoal não vai dizer nada, mas o simples ato de explicar fará você ter outra visão da situação.
Essa técnica eu já tinha aprendido a um tempo atrás, só que quando me ensinaram foi para que eu fixasse melhor as coisas que estudo, então eu sempre tento explicar para alguém as coisas novas que vou aprendendo.
Por enquanto é isso, pois já são 2:30 da madrugada e eu tenho que trabalhar (hoje!).
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – parte 7
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – parte 8
- O Programador Pragmático – Resenha do prefácio
- O Programador Pragmático – Capítulo 1
O Programador Pragmático – parte 6 Assine o Feed Grupo Haw FeedBurner
]]>
E aí vai a segunda parte do segundo capítulo do livro que deve estar na cabeceira de qualquer programador: O Programador Pragmático.
Mais uma vez, esse resumo é uma anotação pessoal, e se é pessoal é influenciada por minhas experiências (meio obvio), então compre o livro que vale cada centavo investido.
Projéteis Luminosos
Essa parte do livro é simplesmente fantástica (eu já escrevi essa palavra várias vezes =P), mais uma vez começa com uma analogia que sobre os modos com que podemos dar um tiro no escuro, em resumo são:
Podemos calcular onde está o alvo, temperatura, umidade, fazer diversos cálculos, etc… E se o ambiente não mudar, o alvo não se mover, a temperatura estiver constante e assim por diante o tiro tem uma chance de chegar perto (hmmm, isso me lembra uma tal de “cascata”, ou um tal de RUP que é iterativo e incremental, mas que o levantamento tem que ser feito todo de uma vez “cascata com outro nome?!?!”, “argh!!”).
O segunda alternativa é a utilização de projéteis luminosos que são carregados junto com as balas comuns, só que estes deixam um rastro quando queimam, assim podemos ver se estão acertando o alvo, caso a responta seja positiva, as balas comuns também estão.
Acho que com essa analogia não precisa mais de comentários, só ler um pouquinho sobre Agile, entregas frequentes, ciclos pequenos e etc…
E já que estamos dando um tiro no escuro quando estamos construindo algo que outra pessoa pediu, nós podemos fazer do modo que manda o figurino: Levantar tudo que o sistema pode ter, escrever tudo em todos os diagramas que a UML tem, fazer contratos em que qualquer mudança que o usuário venha a pensar seja muito cara e burocrática. E não podemos esquecer da clausula que diga que se ele não gostar a culpa é dele, já que o documentação estava lá e ele assinou!
Ou podemos optar pro projéteis luminosos, a escolha de um Programador Pragmático, com pequenas partes feitas, testadas, integradas e apresentadas para o usuário e caso ele queira alterar já estamos preparados para isso.
A utilização de projéteis luminosos não garante que você irá acetar o alvo, mas garante que você terá o feedback rápido, e assim saberá se está perto ou não do alvo.
Utilizando Protótipos
Outra abordagem para verificação e validações é o esboço em protótipos, os protótipos podem ser feitos por ferramentas específicas ou um quadro branco (eu já utilizei HTML), os protótipos tem a função diferente dos projeteis luminosos, pois provavelmente será descartado. A grande vantagem da utilização de protótipos é que eles são mais baratos que a implementação final do sistema, assim ele permite um entendimento comum antes que as coisas sejam feitas.
Nem sempre os protótipos são das GUI, eles também podem referencias esboços da arquitetura em post-it. O livro apresenta algumas coisas que podem ser prototificadas:
Arquitetura
Nova funcionalidade em um sistema existente
Estrutura ou conteúdo de dados externo
Projeto de interface de usuário
Etc…
Outro ponto que deve ser lembrado é que os protótipos não são precisos, são apenas esboços e sendo assim não deve ser despendido muito tempo na sua construção.
O livro também deixa a dica de que quando optarmos em fazer as presentações por protótipos devemos deixar bem claro que ele não será reaproveitado. Do mesmo modo que um protótipo de um avião que é construído para testar a sua aerodinâmica não é utilizado em um voo.
Linguagens de Domínio
Após os protótipos o livro fala sobre Linguagens de Domínio, sobre como a linguagem de programação influencia no modo de solucionar o problema, e logo após os autores dizem que devemos aproximar a linguagem do domínio com a solução que será implementada na linguagem de programação.
A tema central dessa parte é que devemos programar o mais próximo possível da domínio do problema. Entre as diversas vantagens que há em utilizar esse estilo na programação podemos dizer da facilidade em manter a diálogo com quem conhece o domínio e quem está desenvolvendo o sistema.
E nessa parte eu fiquei devendo os exercícios já que não sei expressões regulares (vai pra lista de estudo).
Estimativas
Na parte de estimativa ele ensina a pensar da seguinte maneira: Primeiro entender bem o problema, depois disso é hora de construir um modelo mental do sistema que foi pedido. Depois de construir todo o modelo mental é hora de dividi-lo em componentes e pensar em quanto tempo esses componentes serão construídos. Outra dica é consultar um pessoa que já tenha feito algo semelhante ao que você está se propondo a solucionar, não que isso lhe de o tempo exato, mas desse modo você terá uma base dos problemas que podem surgir.
Outra coisa importante é sempre verificar o tempo que realmente foi gasto com o que foi previsto, essa é uma forma de acompanhar as suas habilidades e estivar.
Mais um dica: COMPRE O LIVRO!!
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – Capítulo 1
- O Programador Pragmático – parte 8
- O Programador Pragmático – parte 6
- O Programador Pragmático – parte 7
- O Programador Pragmático – Resenha do prefácio
- Livro SCJP (guia de bolso)
O Programador Pragmático – Capítulo 2 – segunda parte Assine o Feed Grupo Haw FeedBurner
]]>
Continuando a leitura e resumo do livro O Programador Pragmático, vai aí o resumo do segundo capítulo que vai ser dividido em alguns pedaços.
Obs.: Esse resumo não substitui de modo algum a leitura do livro!
Duplicação
O segundo capítulo é iniciado abordando o problema da duplicação, não somente a duplicação de código, mas também as especificações e documentações. O problema da duplicação no código já e reduzido quando passamos a trabalhar com Orientação a Objetos (ou não) e isso não significa que só por programar em Java, Ruby ou C# estamos programando OO.
Nesse parte o livro fala sobre os males de se duplicar informações, já que teremos o problema de a cada modificação teremos que procurar todos os locais que a informação está duplicada. E esse problema não é só em código, as informações podem está em documentações excessivas ou comentários exagerados em métodos que deveriam ser refatorados.
A solução para o problema da duplicação está em um conceito chamado de NSR que é o acrônimo de Não Se Repita (DRY, ou Don’t Repeat Yourself). Nessa parte os autores deixam a seguinte dica: “Cada bloco de informação deve ter um representação oficial, exclusiva e sem ambiguidade dentro de um sistema”
Ortogonalidade
A segunda parte do segundo capítulo trata sobre ortogonalidade (veja mais aqui), sobre as vantagens de se desenvolver um sistema onde alterações em um modulo não causam danos a outros, coisas já conhecidas por quem utiliza MVC e sistemas baseados em componente, outro exemplo dado no livro é a utilização de AOP para diminuir o problema de sistemas não ortogonais.
Mais uma vez o livro trata de assuntos que são cobertos pela Orientação a Objetos, como o encapsulamento, onde escondemos a estrutura interna de nossas classes, fazendo com que o cliente apenas conheça a sua API. Um exemplo bem básico é quando encapsulamos o nosso acesso a dados com o DAO, assim a troca de código SQL nativo por JPA fica mais fácil.
Os exercícios dessa parte são bem simples, mais é fantástica a explicação das respostas, principalmente a parte que fala da Orientação a Objetos x Procedural.
Reversibilidade
A frase do Emil-Auguste no início do item reversibilidade já deixa bem clara a abordagem que os autores propõem “Nada é mais perigoso do que uma ideia quando ela é a única que você tem”.
É desse modo que a reversibilidade é iniciada, basicamente falando que soluções simples são mais fáceis de serem alteradas. Uma mensagem que fica é que devemos sempre ter em mente que a solução que nós adotamos para combater determinado problema não é a única. Existem muitas abordagem para o mesmo assunto, por exemplo, podemos ter que alterar o banco de dados que está sendo utilizado no projeto. Os autores dizem que devemos tomar cuidado com cada pequena decisão que tomamos, já que podemos chegar ao ponto em que o bater de asas de uma borboleta em Tóquio pode causar uma série de eventos que encadeiam um furacão no Texas. E para se prevenir desse tipo de problema devemos tomar mais cuidado com as decisões e ter em mente que os requisitos podem mudar (e vão mudar), e como diz no livro “Em vez de tomar decisões esculpidas em pedra, considere-as mais como se tivessem sido escritas na areia da praia”. Mais uma dica dada nessa parte do livro é de sempre encapsular ferramentas e bibliotecas de terceiros, e até mesmo a suas, já que ela pode deixar de ser a melhor solução no futuro.
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – parte 6
- O Programador Pragmático – parte 7
- O Programador Pragmático – Capítulo 1
- O Programador Pragmático – parte 8
- O Programador Pragmático – Resenha do prefácio
- Livro SCJP (guia de bolso)
O Programador Pragmático – Capítulo 2 – primeira parte Assine o Feed Grupo Haw FeedBurner
]]>
Fala galera,
diretamente de Brasília com mais uma postagem arroz com feijão. Hoje, aproveitando que voltei a estudar para certificação (antiga SCJP) vou falar um pouco sobre Enum.
O Enum é um recurso disponibilizado a partir da versão 1.5 do Java (ou Java 5), que veio para limitar uma determinada faixa de valores para variáveis. Ou seja, uma lista com valores pré-definidos.
Alguns descrevem como um tipo de classe especial, eu gosto de dizer que ele é uma lista de constantes. Porém não sei se o termo é correto.
A declaração básica de um Enum é parecida com a de uma classe e deve ser feita da seguinte forma:
enum <nome da variável> { valor 1, valor 2, …, valor n}.
Tal como exemplo:
//declaração de Enum
enum TamanhoRefrigerante { PEQUENO, MEDIO, GRANDE} ;
//aqui a classe do Refrigerante
public class Refrigerante{
TamanhoRefrigerante tamanho;
}
//aqui vamos testar o exemplo
public class Teste{
public static void main(String[] args){
Refrigerante refri = new Refrigerante();
refri.tamanho = TamanhoRefrigerante.MEDIO;
}
}
Podemos declarará-los fora de classes como mostrado acima ou dentro de classes conforme abaixo:
//classe Refrigerante com a declaração do enum
public class Refrigerante{
enum TamanhoRefrigerante {PEQUENO, MEDIO, GRANDE}
TamanhoRefrigerante tamanho;
}
// e aqui utilizamos os tamanhos pré-definidos
public class Teste{
public static void main(String[] args){
Refrigerante refri = new Refrigerante();
refri.tamanho = TamanhoRefrigerante.MEDIO;
}
}
Perceberam alguma diferença na declaração do Enum no primeiro e segundo exemplo? Não? O ponto-e-vírgula no fim da declaração é opcional, então muito cuidado, isso pode valer uma questão na sua prova de certificação.
Apesar de podermos declará-los dentro ou fora de classes, eles são proibidos dentro de métodos e o compilador gritará de raiva caso você faça isso. O enum se declarado em um arquivo a parte, deve seguir as mesmas regras de uma classe, ou seja, nome do Enum é o mesmo nome do arquivo. No nosso caso é o TamanhoRefrigerante.java.
Enums não podem ser instanciados (não daria para usar o new TamanhoRefrigerante()) e são acessados estaticamente através do nome.CONSTANTE;
Um enum possui um método values() pelo qual é possível iterar seus valores pré-definidos.
Bom pessoal, essa foi só uma introdução ao assunto. Ainda tenho muito mais a acrescentar como falar de sobrecarga de construtores e mais, porém fica para uma próxima postagem. Por ora é o suficiente.
Abraços.
Lucas MenezesPostagens Relacionadas:
]]>
Continuando a leitura do livro O Programador Pragmático… Acabei de ler o primeira capítulo e novamente mais uma surpresa com o livro. Basicamente ou autores dão uma visão geral de todo o conteúdo do livro e abusam das analogias por todas as partes, e isso pra mim é mais um ponto positivo, o entendimento da ideias e da forma de pensar dos autores ficam muito mais claras, e de forma objetiva.
O primeiro capítulo começa contando a filosofia do pragmatismo, onde os autores falam de onde veio a ideia de pragmatismo.
Agora mais um resumão das partes que mais me chamaram a atenção:
Logo no início os autores exemplificam como um programador pragmático se diferencia de outros, e em um parte está escrito: “Ele raciocinam além do problema imediato […] sempre tentando tomar conhecimento do cenário em maior escala”. Além disso os autores fazem questão de repetir sobre atitude e responsabilidade, onde o programador sempre é responsável por tudo que faz e assume seus erros.
Ainda sobre dar opções os autores falam sobre como dizer que algo não pode ser feito, “[…] Antes de abordar alguém pra dizer que algo não pode ser feito […], pare e escute a si próprio […]. Sua desculpa parece convincente ou estúpida?”
Os autores falam sobre pensar em quais perguntas o ouvinte irá lhe fazer, é bom ter as respostas antes, e se nada pode ser feito, é hora de falar sobre as opções.
Na segunda parte do primeiro capítulo o livro fala sobre não conviver com janelas quebradas, ele exemplifica com mais uma analogia que diz que se você tolerar falhas, logo as coisas vão sair do controle, para saber mais é só procurar sobre a “Teoria das Janelas Quebradas”.
A terceira parte do primeiro capítulo fala sobre estar preparado para mudanças, pois muitas vezes as pessoas tem medo de mudar e os autores propõem que nós devemos ser catalizadores de mudanças, “[...]Planeje o que você deseja pedir. Desenvolva isso bem.[...] Mostre o que obteve as pessoas e deixe que se admirem. Então diga ‘é claro que ficariam melhor se adicionássemos…’”. As pessoas tendem a apoiar ideias que já estão funcionando, então tome atitude e mostre os resultados.
“Aceite e esteja preparado para as mudanças, assuma que o que você está fazendo agora pode não ser o melhor modo amanhã”
Porém, a atitude de mudar deve ser tomada com cuidado!
Continuando a terceira parte os autores falam sobre verificar constantemente o seu cenário, como por exemplo as pequenas falhas que são inseridas diariamente no projeto, em pouco tempo saem do controle, então não tolere janelas quebradas.
A quarta parte fala qualidade, onde você deve desenvolver pensando em qualidade, o sistema deve ser satisfatório para o usuário e também em sua estrutura interna. Você deve se preocupe com a qualidade mas deve saber a hora de parar, isso não quer dizer que é pra fazer código feito, só que devemos saber a hora de para.
O processo de desenvolvimento deve envolver os usuários, já que é pra eles que desenvolvemos (Assunto muito falado nas metodologias ágeis).
A quinta parte é sobre conhecimentos, onde os autores chamam de carteira de conhecimento as habilidades que nós possuímos, e essa habilidades tem prazo de validade. Entra as várias dicas que os autores dão uma que me chamou atenção é a de ler pelo menos um livro técnico a cada três meses. Há também uma parte sobre ter pensamento crítico que é bem legal, esse é um assunto que eu já tinha visto em uma apresentação do Akita (http://www.akitaonrails.com/2008/09/13/off-topic-matando-a-m-dia).
E no final há entre os desafios um que é de aprender um nova linguagem de programação por ano (vide: http://www.programadorpoliglota.com.br/).
Pra finalizar o primeiro capítulo, os autores falam bastante sobre a importância da comunicação, e de saber se comunicar direito independente de ser em uma reunião, apresentação ou e-mail. Nessa parte também há uma pequena receita de bolo de como manter um boa comunicação, e entre essee todos os tópicos há três que eu achei bem interessantes, que são:
1. Saiba o que você quer dizer
2. Conheça seu público-alvo
3. Escolha seu momento
O item número três dessa lista também e exemplificado no livro “[...] Aborde um gerente que acabou de ter problemas com seu chefe porque algum código-fonte foi perdido e terá um ouvinte receptivo para suas ideias sobre repositórios de códigos-fonte[...]”
O item número dois me lembra bastante um artigo que eu li a um tempo atrás na InfoQ BR sobre Diferenças entre Gerações, que por sinal veio a calhar já que na época eu tinha que fazer uma apresentação sobre metodologias ágeis para um professor de COBOL, e após a leitura desse artigo eu percebi que teria de adaptar a abordagem da apresentação.
Gabriel Rubens
Postagens Relacionadas:
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – Resenha do prefácio
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – parte 6
- O Programador Pragmático – parte 7
- Livro SCJP (guia de bolso)
- O Programador Pragmático – parte 8
O Programador Pragmático – Capítulo 1 Assine o Feed Grupo Haw FeedBurner
]]>
Ultimamente eu tenho refletido sobre como a nomeação de classes, variáveis e métodos são importantes. As vezes perdemos mais tempo tentando entender o código do que entendendo o algoritmo que o método executa (por isso até comprei o livro Código Limpo do Robert C. Martin, está na fila). Eu acho que programar já é complexo o bastante, e pra que complicar ainda mais?
Eu nunca estudei efetivamente RubyOnRails, comprei dois livros mais até hoje não li todo, mas li uma parte da documentação e muitos posts pelo Google Reader, e se tem uma coisa que eu apendi é que método bem nomeado torna seu trabalho e o do profissional que trabalha com você muito mais fácil.
As vezes nós nos esforçamos muito para manter a performance do sistema, verificando cada tipo dos atributos das classes, otimizando o IO com o banco de dados e servidor de aplicação e etc… E tudo isso é perfeitamente válido, só que esquecemos de uma coisa básica: “Quem da manutenção no código é uma pessoa”.
Agora um exemplo simples:
class UmaClasseQualquer {
//pega todas as pessoas
public List<Pessoa> pegaPessoaList(){ }
// pega as pessoas com mais de 18 anos
public List<Pessoa> pegaPessoaList2(){ }
//pega as pessoas que são funcionários
public List<Pessoa> pegaPessoaList3(){ }
}
É claro que esse exemplo não é nem de longe complexo para demostrar a dificuldade que a má nomeação pode causar (esse método poderia receber um critério ou algo assim), é só um exemplinho com poucos métodos, mas imagina isso em um sistema em produção, imagina ter que alterar uma classe em uma equipe grande, e talvez quem fez o código está de férias. Hmm, aí a coisa complica. E se pra piorar ainda mais a situação o sistema não possuir teste automatizados? Bummm, aí a bomba estoura!
Nesse exemplo mesmo da classe “UmaClasseQualquer”, foi gasto tempo escrevendo comentários no código, tudo bem, muitas vezes um breve comentário ajuda, mas quando o comentário passa a descrever como funciona o método é sinal que o nome do método não está muito claro, e pra piorar ainda mais temos que lembrar que se o comportamento do método mudar temos que atualizar os comentários também.
As vezes eu acho que esse mania vem do tempo em que nós estamos aprendendo uma linguagem, com tutoriais contendo classes pequenas que muitas vezes são nomeadas com “public class A{}” e “class B extends A”, mas uma coisa é você ler meia duzia de classes e outra coisa é ler classes em um sistemas dividido em camadas. Até mesmo esse CRUD de um formulário que você está fazendo pode ser tornar um sistema, e as coisas fogem do controle.
Então da próxima vez que estiver programando pense um pouco mais nas nomenclaturas, crie padrões de nomeação, conheça os padrões da sua empresa, programe em par, faça testes, etc… Um modo legal é chamar o seu colega e perguntar se ele entende o finalidade do método só de bater o olho.
Diminua o tempo de manutenção ao invés da quantidade de caracteres nos nomes das classes e métodos. Eu não sei qual é o motivo dessa mania chata de ficar abreviando nomes para classe e métodos, não seria melhor abreviar o tempo que você leva pra entender o código?
Link legal do Urubatan: http://www.urubatan.com.br/manifesto-pela-legibilidade-de-codigo/
Gabriel RubensPostagens Relacionadas:
]]>
Depois de muito ouvir falar eu resolvi comprar o livro O Programador Pragmático, e pra melhorar ainda mais minha compreensão e fixar cada capítulo eu resolvi fazer uma resenha do conteúdo que eu for lendo, então aí vai a primeira parte.
Para minha surpresa a primeira resenha não é nem do primeiro capítulo, é do prefácio. De cara já deu pra notar que os autores (Andrew Hunt e David Thomas) não se atentam a tecnologia utilizada como linguagens, sistemas operacionais ou ferramentas, e tratam o processo de desenvolvimento como arte e não como “fábrica”.
“[...]Não há respostas fáceis. Não há uma solução melhor, seja uma ferramenta, uma linguagem ou um sistema operacional. [...]”, “[...] Aí que o pragmatismo entra em cena. Você não deve se ater a uma tecnologia específica[...]”. Só por essas duas passagens do livro já me deixarem empolgado com o que vinha pela frente.
Ainda no prefácio os autores dão algumas características que fazem parte de um programador pragmático, que são:
Adoção antecipada/adaptação rápida.
Inquisitivo.
Pensador crítico.
Realista.
Pau pra toda obra.
No livro cada um desses pontos é seguido de uma explicação, mas por aí já deu pra ter uma noção da forma de pensar do autores.
Outra coisa que eu estou gostando bastante são a dicas espelhadas pelo livro, como por exemplo a dica 1 e 2: “Preocupe-se com seu trabalho” e “Reflita sobre o seu trabalho”. E essas dicas também estão seguidas de explicações.
Essas duas dicas me faz lembrar do tempo em que eu ainda trabalhava com todos o fundadores desse blog, onde quase que diariamente nós discutíamos algum assunto sobre tecnologia, na maioria das vezes era sobre Java e boas práticas de programação, e até mesmo sobre os posts de outros blogs que nós liamos pela net. Eu não tenho certeza, mas eu acho que essas discussões também influenciaram uma postagem feita pelo Lucas.
Eu sempre me questionei sobre programadores que somente leem tutoriais na net e trabalham com o “Ctrl+c e Ctrl+v”, onde muitas vezes você não tem noção do que código está fazendo (eu já me peguei fazendo isso), “mas funciona” então não meche (qualquer semelhança é mera coincidência). Acho que por esse tipo de “profissional” que ainda há pessoas que acreditam que daqui a pouco as ferramentas RAD vão acabar com os desenvolvedores (vide: aqui e aqui).
Outro ponto bem bacana no livro são as analogias feitas, e entra elas há uma que ele mostra que mesmo havendo engenharia a concepção é através da arte com habilidades individuais (quer saber mais? Compra o livro).
As resenhas vão ser bem curtas, e eu não pretendo ficar escrevendo o livro todo aqui (isso até seria errado), só quero apresentar o meu ponto de vista sobre o conteúdo que estou lendo para fazer comparativos com as situações que eu já vivenciei. Para o conteúdo completo, compre o livro, pelo menos pelo prefácio eu não estou arrependido.
Bom, não sei se o livro todo vai ser assim, mas o prefácio foi o bastante para despertar o meu interesse.
Agora chega de escrever que eu vou voltar a ler o livro! Antes outras citações do livro: “Programadores pragmáticos executam o trabalho e executam bem”, “Quando colegas dizem ‘porque é assim que é feito’ ou um fornecedor promete a solução para todos os seus problemas, você fareja um desafio”.
Gabriel RubensPostagens Relacionadas:
- O Programador Pragmático – Capítulo 1
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – parte 6
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – parte 8
- Livro SCJP (guia de bolso)
- O Programador Pragmático – parte 7
O Programador Pragmático – Resenha do prefácio Assine o Feed Grupo Haw FeedBurner
]]>
Agora o último resumo feito pelo André, é um resumo de como foram as palestram de domingo no TDC 2010.
Para mim Domingo foi disparado o melhor dia! Segui a trilha de Agile.
Primeira palestra: Código Limpo:
Palestrante: Hugo Corbucci: http://twitter.com/hugocorbucci
A mesma palestra, só que num evento anterior: http://devinsampa.blip.tv/file/4024593/
Falou da importância de ser ter código fácil de se manter, ser profissional, somos pagos para testar, documentar e escrever código correto.
Temos que corrigir o código assim que possível, não deixar a DÍVIDA TÉCNICA crescer de forma a ficar impossível de ser refatorar depois.
Se o código está muito sujo, mesmo que seja de outro programador, devemos ir corrigindo aos poucos.
Código sujo, de uma forma resumida, é código que não segue padrões, sem identação adequada, com nomes de variáveis, métodos que não correspondem ao que eles realmente fazem.
Podemos medir um código ruim, pelo quantidade de “Que porra é essa” ditas por minutos, uma alusão ao tempo que você demora para entender código de outro programador.
Código limpo, é aquele que você bate o olho e sabe dizer o que ele faz, mesmo sem ler o bloco de código.
Dicas para manter um Código Limpo:
Refatorar o código sempre:
1. Controle o tamanho do código. Em geral um método não pode ser maior que sua tela, ou seja, umas 30 40 linhas, reparta em métodos menores;
2. Revele suas intensões: Escolha bons nomes para suas Classes, Variáveis, Métodos, enfim, tudo. Cuidado com comentários: É muito constante ocorrer o fato de você arrumar ou refazer um código e deixar o comentário antigo lá, atrapalhando o entendimento. Por último: faça testes unitários!!! Na hora você consegue saber o comportamento de um método.
3. Controle fatores externos: Proteja o software, Faça testes de integração, afinal, as classes tem que conversar umas com as outras. Faça o tratamento de erros corretamente e não se esqueça da concorrência, ou seja, execução simultânea de um mesmo bloco de código entre duas threads.
4. Formatação do código: Siga a padronização! Use muita identação. Nós identificamos muito mais rapidamente pelo VISUAL; Deixe o código formatado de uma maneira que só de bater o olho dá para saber o que ele faz. (Peça a opinião de outra pessoa). Use também o espaçamento vertical: separe os blocos de código como numa redação: reúna as linhas que executam uma mesma idéia.
5. Regra do escoteiro: Sempre que você ver um código ruim, arrume-o! Se o código é grande, faça uma pequena correção apenas para entender o que ele faz. Desse modo, sempre que algum programador passar por ele, vai corrigindo em pequenas partes até ficar bom.
Pergunta no final da palesta:
Como eu faço se eu encontrar um código péssimo, extremamente crítico para a aplicação, de modo que se eu mexer errado pode ocorrer uma tragédia, ou seja, uma verdadeira bomba atômica.
Resposta:
1. primeiro escreva um teste básico e rode! Provavelmente você não vai conseguir rodar porque vai ter uma porrada de dependências no código;
2. Vá criando mocks necessários e tentando rodar o teste;
3. Quando conseguir isolar a bomba, ou seja, conseguiu criar os mock necessários o passar no teste básico, comece a criar os testes pra valer;
4. Após ter criado todos os testes que você conseguir identificar como necessários, comece a “cortar os fios” da bomba.
Todo esse processo demora muito. Dependendo do código, se antes de começar a cortar os fios você descobriu que alguns testes falham, mostre para os responsáveis, pois até ai você ainda não mexeu em nada do código original.
Segunda Palestra: Integração Contínua
Palestrante: Giovanni Bassi, http://twitter.com/giovannibassi
Slide: http://www.slideshare.net/giovanni.bassi/integrao-contnua-5033914
Integração contínua é uma prática. Mostrou opções de como aplicá-la em ambientes diversos, com repositórios centralizados e distribuídos. Ele recomendou SVN, Mercurial ou GIT, sendo que repositórios distribuídos tem um sistema de merge e controle de versão superiores e permite o desenvolvimento de branchs em paralelo. É importante eleger alguém para o papel de integrador, ou seja, que funcionalidade entra ou não no trunk principal.
Para funcionar é essencial se automatizar tudo o que for repetitivo. Item principal: Escrever TESTES.
Mostrou como seria o fluxo ideal de desenvolvimento concorrente:
- Início do trabalho: Baixar todo o código commitado;
- Mandar executar o teste integral. Desde modo você se certifica que não baixou código quebrado, que não compila ou roda.
- Desenvolver seu código.
- Testar seu código.
- Testar todo o código (teste integral).
- Baixar todo o código commitado até agora.
- Rodar o teste integral. Importante: se não passar no teste, interrompa o trabalho dos envolvidos e resolve na hora.
- Commita todas suas alterações.
- Compila e testa na máquina de homologação.
Práticas de Integração contínua:
1. Estrutura do repositório de código: (centralizado ou distribuído)
Projeto
|— Branch1
|— Branch2
|— Trunk
—–|— docs //-> manuais, documentação
—–|— libs //-> todas as libs usadas na versão atual do trunk
—–|— src
———–|— meu projeto
—–|— toots
2. Build Automático:
Tudo tem que estar configurado para ser executado com um único click, incluindo banco de dados e testes. As ferramentas atuais permitem isso.
3. Frequência de commits:
Pelo menos 1 vez por dia. Terminar uma tarefa por dia. Se não está conseguindo terminar, reduza o tamanho das tarefas.
Importante: O seu commit gera um build? Então só termina após o build passar em todos os testes.
Se os testes são demorados use testes de fumaça, ou seja, rodar os testes básicos e deixa os demais testes agendados.
É necessário ter uma máquina dedicada ao build. A partir dela são geradas as releases.
O teste do ambiente tem que ser equivalente ao da produção.
Permitir que qualquer desenvolver tenha acesso fácil ao build, seja um EXE ou WAR/EAR
Todas as informações de compilação do build e dos testes precisam estar disponíveis na hora.
Em algumas empresas, quando um desenvolvedor quebra o build, sua foto é divulgada, em painel eletrônico ou e-mail, com um grande #FAIL anotado. Fica lá até o problema se resolvido.
Ir para produção? Tem que ser com um click também. E ter a opção de retornar ao estado anterior imediatamente, com um click também (Ctrl+Z)
Terceira Palestra: Cultura mais que a práticas – Na minha opinião, essa palestra valeu o evento inteiro!!!
Palestrante: André Nascimento: http://twitter.com/alnascimento
Gerente executivo da Stefanini IT Solutions em São Paulo.
Ainda não tem o slide, mas, vendo o blog, encontrei um post muito bom: http://blog.anascimento.net/2010/07/14/faz-sentido-bloquear-internet/
Nossa área está prostituída!!! Fábricas de software contratam a rodo profissionais sem nenhuma experiência, juniores, estagiários, que aceitam qualquer valor, para “desenvolver” até sistemas críticos, com prazos impossíveis. Só querem ganhar dinheiro, entregar o lixo e sair correndo!
Fecharam contrato com uma gigante para desenvolver seu e-commerce.
Uma equipe com os analistas mais experientes levantou os requisitos e casos de uso do cliente.
Um ano depois entregaram uma tonelada de documentação. Eles mesmo não conseguiam entender perfeitamente toda a documentação imaginem o cliente, que não conseguia validar. Desenvolvimento iniciou, já havia comprometido metade do orçamento, quando eles perceberam que não ia dar.
Para tudo! Se sabe que vai cair no abismo, não tem o porquê continuar empurrando.
Se reuniram para decidir qual atitude tomar para trazer novamente o projeto aos trilhos. Ouviram falar de um tal de Scrum, metodologia ágil, essa promete! Reuniram os líderes, fizeram o melhor curso que encontraram, voltaram e estava decidido: “Agora somos ágeis, vamos trabalhar assim”. A equipe não entendeu nada o que eles estavam falando, então deram treinamento de 15~30 dias para o resto da equipe. Não adiantou bosta nenhuma. Equipe ficou perdida, entregaramum sistema ruim (lembram-se daquela e-loja famosa que oferecia notebooks a 9,90, macbooks a 100 reais?, pois é…), ficaram decepcionados e agora tinham motivos pra falar mal dessa tal metodologia ágil.
Eles tentaram seguir o conceito do K.I.S.S (Keep It Simple Idiot), mas não é bem assim, ser ágil exige uma equipe interdisciplinar madura, que além de dominar conceitos de TDD, BDD, sabe que a responsabilidade é de todos, inclusive do cliente. Antes a equipe era composta de programadores, dbas, designers e testers, ou seja, cada um estava preocupado só com a sua parte, como numa “Fábrica”, mas ninguem se responsabilizava pelo todo. As pessoas costumam ser tratadas como “recurso”.
Também não adianta impor uma tecnologia, uma metodologia, nem dar treinamento e largar lá pra “se virarem”. Tem que ter coaching, tem que ficar do lado. Hoje eles tem gente lá que só faz isso, inclusive, tem até coaching para ensinar o cliente a ser Product Owner.
Não caiam da Hipe (não siga a onda). Tá cheio de consultoria dizendo que é ágil por ai. Chegam no cliente, “levantam o blacklog” e entregam o “cronograma do Sprint”. Hoje tem até curso de MBA que ensina a fuder com o fornecedor. Explica como usar artifícios de contrato para por toda a responsabilidade em cima do fornecedor. É a cultura do Go Horse, acessem: http://gohorseprocess.wordpress.com/extreme-go-horse-manifesto/
ANTES DE SER ÁGIL, PRECISA TER CULTURA ÁGIL.
Eles querem se livrar do termo “Fábrica de software”, por enquanto estão usando um o nome provisório de “Software Delivery Center”.
NÃO EXISTE CRONOGRAMA DETALHADO! Um cliente pediu: quero o cronograma completo do projeto. Ele respondeu: Cliente, você quer ser enganado? Eu não quero te enganar.
Eles preferem negar o projeto à ter que desenvolver no modelo em cascata. Se o cliente tiver a cabeça fechada e não entender, ou eles mandam fazer com outros, ou tentam passar para as demais filiais que ainda trabalham assim. Somente a equipe dele em São Paulo que pratica metodologia ágil. Eles estão discutindo como fazer para espalhar para as demais unidades.
PRECISA TER APOIO DA GESTÃO!!
Depois do fracasso da primeira tentativa, eles tiveram que dedicar tempo para pensar em como mudar a cultura, trabalhar com as pessoas. Ele ainda acreditava na metologia, sabia que tinha gente capacitada lá para isso, mas sem o apoio da liderança não seria possível.
GESTÃO PARTICIPATIVA!!!
Todos participam, todos precisam ter autonomia para decidir pois, só assim serão auto-gerenciaveis. Ele procurou ler a literatura do Ricardo Semler, para ter exemplos e aplicar na empresa:
- Banir Comando e Controle. (engraçado que ainda ensinam isso na faculdade, eu tive em 2008!!!). Fim do Manda quem pode, Obedece quem tem juízo. O “Gerente/Chefe/Diretor” tem que aprender a ser líder (Leiam: O Monge e o Executivo)
- Auto organizável: Trabalho verdadeiramente em equipe. As pessoas tem que agir, ser pró-ativo, não esperar alguém te passar serviço. Se não tem o que fazer, vá ajudar aos outros.
- EVIDENCIAR OS PROBLEMAS: FALA LOGO O QUE TA ERRADO, SOBRE SEU TRABALHO, SOBRE AS DEMAIS PESSOAS, ABRA O JOGO! NÁO DEIXEI A MER#@ CRESCER E ESTOURAR. FALE O QUANTO ANTES, PARA TODO MUNDO OUVIR.
A decisão de contratar e demitir é do próprio time. Hoje eles demoram para contratar, mas para demitir é um instante. Certa vez a equipe tentou, ajudou mas um cara não conseguia ser adaptar a cultura da empresa. Então eles sugeriam: “Não tem como remanejá-lo para outra equipe?” e a resposta: “Mas como? querem fazer tráfico de drogas?”. Uma alusão ao fato de que a única pessoa que pode mudar você é você mesmo. Se a pessoa só oferece resistência à mudança, não adianta insistir.
- APRENDER SEMPRE!
Não pode parar de estudar e, inclusive, durante o horário do trabalho se precisar.
O trabalho tem que dar prazer. Eles não pegam projetos em que o cliente comenta: “Vai precisar fazer hora extra e trabalhar nos finais de semana”. Eles não sacrificam os funcionários em trocar de fechar contratos desse tipo, obviamente NÃO porque eles querem ou gostem, mas porque ISSO TRÁS RETORNO FINANCEIRO!!!
Para quem não conhece o Marco Stefanini, O Dono, SÓ PENSA EM DINHEIRO. Ele não ia permitir que tudo isso fosse feito se não desse retorno financeiro.
Atualmente 90% dos projetos estão dentro do tempo, orçamento E FORA DO ESCOPO INICIAL do contrato, ou seja, atendendo em 100% as necessidades do cliente. Mas deixou claro que ainda estão longe do que pretendem aplicar por lá.
Eles também usam a metologia Kanban para manutenção de alguns sistemas.
E finalmente, ele conclui a palestra dizendo que faz parte do grupo de “Cascateiros Anônimos” pois, sabe como é né? Entre um cliente aqui, outra equipe ali, você sempre encontra alguém fumando project por ai…
Nas perguntas do final, ele falou que está numa campanha para tornar o salário público para todos dentro da empresa. Comentou que a diferença salarial entre um júnior recém contrato e um sênior é muito pouca.
Quarta Palestra: O sistema Kanban para equipes de manutenção
Palestrante: Dairton Bassi: http://twitter.com/dbassi
Mostrou como funciona o Kanban.
Importante, também sobre cultura: Ao invés de Revolucionar, Evoluir!!! Nunca dizer que vai revolucionar, tentar implantar toda uma metodologia, que exige mudança de cultura, de uma vez só. Vá evoluindo aos poucos, caminhe naturalmente de acordo com o seu ambiente, pois isso reduz a resistência.
Assim como qualquer outra metodologia ágil, Kanban, por ser menos burocrático que Scrum, exige ainda mais uma equipe interdisciplinar madura, com boa experiência em TDD, BDD, Design Patterns, enfim, todas as boas práticas da orientação à objetos.
- Quebrar as funcionalidades em tarefas bem pequenas;
- Limite a quantidade de tarefas de acordo com a capacidade de absorção dos desenvolvedores. Não permita que um desenvolvedor trabalhe simultaneamente em duas ou mais tarefas simultaneamente.
- Kanban não tem iterações como o Scrum, ou seja, não se determina “Sprints” com tempo, incio e fim. Ele implementa fluxos contínuos, onde as funcionalidades vão sendo entregues conforme vão ficando prontas.
- Estimativas são opcionais…
Ele mostrou algumas métricas para medir desempenho da equipe, tempo de duração de desenvolvimento de uma estória, etc…
Para adotar o Kanban (além do que eu já escrevi acima)
- Mapeie seu fluxo de valor;
- Visualize seu workflow;
- Limite o trabalho em progresso;
- Meça seu desempenho;
- Estabeleça uma cadência;
- Viabilize melhoria contínua.
Kanban é puxado. O próximo livre da equipe escolhe a tarefa que vai fazer. Ninguém vai ter passar uma tarefa pra fazer (promover a melhoria do trabalho em equipe);
Comentou do http://alissonvale.com
Quinta Palestra: Porque devo me interessar por Lean?
Palestrante: Samuel Crescêncio: http://twitter.com/screscencio
Slide: http://prezi.com/w6pjte9n4bsq/the-lean-pyramid/
Mostrou a metologia Lean.
Assim como as demais metodologias ágeis: Precisa de uma equipe bem desenvolvida.
Princípios:
- Entregar valor contínuo;
- Promover aprendizado contínuo;
- Criar melhoria contínua.
Ele considera também os valores que os criadores do Lean, Mary e Tom Poppendieck
- Promover a integridade: Somos pagos para fazer software com qualidade, documentado e testado, trabalhando dentro do nosso horário (nada de horas extras e fins de semana)
- Respeitar as pessoas;
- Entregar Rápido;
- Ver o todo: Toda a equipe tem que conhecer seu papel. promover a mistura das pessoas, permitir que elas aprendam todas as partes do projeto, desde arquitetura, build, deploy, banco de dados, etc.
Remover Desperdícios:
Tudo o que não trás valor para o cliente;
Até mesmo no local de trabalho podemos remover desperdícios;
Principais desperdícios:
- Código documentado não codificado;
- Código não sincronizado; (deve ser sincronizado diariamente)
- Código sem testes;
- Código sem documentação;
- Código sem deploy;
Código Limpo:
Exibe o gráfico mostrando como a Dívida Técnica cresce exponencialmente devido à código sujo.
Automatizar tudo o que for repetitivo. (Build, Deploy, Testes, tudo)
Quando ocorrer um erro na produção: PARAR TUDO! Concentrar TODOS para detectar a resolver o problema.
JUST IN TIME.
Ir evoluindo conforme a demanda. Ele não perde tempo pensando na complexidade que “talvez” tenha na próxima estória para desenvolver. Se concentra na estória atual, que já esta ordenada de acordo com o que vai trazer mais valor ao cliente, e só quando chegar a vez da próxima estória, vai analisar e pensar na melhor solução.
A arquitetura do sistema deve ser flexível para permitir isso, ou seja, seguir as boas práticas da orientação à objetos.
Pull System:
Lean também é puxado. Tudo o que é “empurrado” para os outros é ruim. A equipe é quem tem que puxar a próxima tarefa para desenvolvimento.
Nivelar o conhecimento:
Todos devem ter domínio do todo.
Obedecer a cadência da equipe, sem Rush (Horas extras e trabalhar finais de semana)
Gabriel RubensPostagens Relacionadas:
- Resumo TDC 2010 – Sábado
- Resumo TDC 2010 – Sexta
- Terceiro Encontro Ágil – Eu Vou!
- Terceiro Encontro Ágil – Eu Fui!
Resumo TDC 2010 – Domingo Assine o Feed Grupo Haw FeedBurner
]]>
Continuando o post anterior com o resumo que o André fez, este post apresentará o resumo do sábado do TDC.
Primeira palesta: Como escolher API`s e Frameworks
Foi uma discussão com todos presentes sobre como escolher frameworks para seu projeto.
Pessoal também comentou sobre suas más experiências ao escolher frameworks.
Consenso geral: Escolher um framework que seja usando por muita gente, que esteja maduro e que tenha empresas E pessoas físicas por trás.
Essa escolha vai durar anos com você. E por isso, em algum momento, alguém novo vai falar “Quem foi o idiota que escolheu esse framework?” Natural pois a tecnologia está sempre evoluindo.
Mudar um framework custa muuuito caro e quase nunca se justifica.
Segunda palestra: Casos de sucesso com java
A Fabiane Nardon contou sobre sua experiência com arquiteta chefe no maior sistema JEE do mundo: O sistema de saúde pública da cidade de São Paulo, vencedor do Duke’s Choose Awards
Era em época de eleição, contrato assinado no fim de 2003. O sistema seria utilizado por 80 mil profissionais. 14 milhões de pacientes e tinha que ficar pronto em 10 MESES.
Chegou a ter 100 desenvolvedores participando(orçamento permitia isso). Tinha equipes fisicamente distantes.
Tecnologias: Repositório SVN. JSP/HTML, Struts1+Tiles+Validator, EntityBeans, SessionBeans e Message-Driven Beans. Era independente de Banco de dados usando SQL com CROSSDB, uma espécia de ORM da época. Ferramentas: Eclipse, ant e xdoclet para gerar os EJBs. Tinha +610 EJ’s. Vários órgãos internacionais vieram conhecer o sistema. O código fonte pode ser solicitado para a prefeitura de São Paulo.
Outro caso de sucesso foi na própria globalcode. Eles tem apenas 1 desenvolvedor dedicado para todos os seus sistemas.
Eles usam servidores da server4you, com Fedora, MySQL, JBossAS. JSP, JMS, MDB, JDBC, JPA, JasperReports, JSF com Facelets, RichFaces, Seam, URL Rewrite, Jquery e Mashups com blogger e twitter. Billing da PagSeguro, UOL
Na época criaram um framework caseiro chamado JAREF que juntava as principais tecnologias, mas que hoje acabou criando um problema pra eles devido a falta de integração com os demais padrões. principalmente JPA.
Teve também: Mobile Payment com JEE e JME
Mostrou as opções de pagamento via celular, via RFID, com NFC’s (especificação JSR-257)
E um projeto novo, usando QRCode com OTP e aplicativo Mopis, ainda em implementação e testes.
Terceira Palesta: JAVAFX na prática
Mostrou um joguinho. Comentou que a TV poderá ser “o pulo do gato” pra quem manjar de JavaFX.
Quarta palestra: Outras linguagens que rodam na JVM
Mostrou o groovy com sua produtividade por sem bem menos verboso, o repositório Grape e o sistema ERP open source: OFBIZ
Mostrou também o PHP rodando mais rápido que o seu interpretador padrão em C, com o Quercus, que inclusive permite usar classes java no código PHP.
Comentou sobre o PHPClasses.org, que possui implementações para vários problemas.
Quinta palestra: Dicas e Truques de Performance para JPA, JSF e JavaEE
Alem de algumas dicas de consulta jpql, por ex, o uso de join fetch, para obter todas as classes dependentes num relacionamento lazy, também o cuidado com paginação usando o setFirstResult e setMaxResult com relacionamentos eager em collections e o método clear para liberar objetos gerenciados não mais utilizados, o que achei mais importante foi a dica de utilizaçao dos caches, principalmente com os novos escopos: VIEW e CONVERSATION
O cache de nível1, que fica na instancia do EntityManager do usuário e mantem os objetos que ele esta utilizando no momento. É importante deixar a EntityManager aberta nesses escopos e deste modo evita o lazyInicializationException e fica muito mais responsivo.
O cache de nível 2, que fica na EntityManagerFactory e é compartilhado por todos os usuários. Nela é bom manter as entidades mais usadas que não sofrem muitas alterações.
Outra dica, quando precisar buscar uma lista de entidades que usa um outro subtipo com muitos objetos, fazer primeiro uma consulta prévia de todos esses subtipos, que ficaram no cache e, deste modo, quando for realizar a busca da entidade principal, o framework ORM vai fazer muito menos selects, pois vai obter os subtipos do cache.
Quanto ao JSF, usar componentes com suporte a lazyload na camada web, reduzindo muito a geração do html retornado, que só vai renderizar se o usuario clicar.
Integrar a ViewHelper(pattern) com a camada de persistência com, se possível, o DataModel do JSF e, quando precisar de ordenação e filtro (por ex resultado paginado), usar o CriteriaBuilder(JPA). (tudo isso é JSF2)
Sexta palestra: Google vs Oracle e o que o OpenJDK tem a ver com isso?
o Bruno Souza contou a historia: em meados de 98~2000 ninguém tinha interesse em criar suas maquinas virtuais 100% compatíveis com o java. A M$ criou a sua própria implementação. A SUN, mais tarde processou e ganhou. Depois disso houve a liberação da JVM sobre licença GPL. Surgiu um projeto de maquina virtual 100% livre e compatível: Apache Harmony. A Sun não aceitou homologar essa implementação (eles queriam manter os direitos sobre plataforma mobile). Enquanto isso a google pegou as bibliotecas do Harmony e criou a sua implementação, chamada Dalvik, que é onde roda o ANDROID.
A Sun tentou varias vezes negociar com o google sem sucesso. Mais tarde a oracle comprou a Sun, que agora esta processando a Google por quebra de patente. E quando se fala de “patente” de software, xiiii é péssimo para a comunidade open source. Ninguém sabe o que vai acontecer.
Gabriel RubensPostagens Relacionadas:
]]>
Nos dias 20, 21 e 22 deste mês (Agosto) rolou o TDC 2010, e eu não pude comparecer, mas o André Reis (Twitter) que trabalha comigo foi e fez um resumo de tudo que ele viu por lá. A principio esse resumo foi passado por e-mail pra todos da empresa, mas como ficou bem legal eu pedi a autorização do André pra divulgar aqui esse resumo. O resumo está escrito em forma de anotações, e conta os pontos principais de cada palestra segundo o ponto de vista do André.
Eu vou dividir esses resumos em três postagens, e a primeira é essa de sexta-feira:
Sexta Feira
Na abertura, a Yara Senger da globalcode mais uma vez ressalta a importância da participação da comunidade na realização desses eventos e agradece a todos os patrocinadores, apoiadores, coordenadores e participantes.
Devido ao tempo muito curto, os palestrantes corriam muito com o conteúdo. Os slides serão disponibilizados posteriormente. Vamos ficar de olho no twitter.
Primeira palestra: JSF 2.0
JSF sem nenhum conjunto de componentes não faz sentido. Na versão 2, a dica é usar o Primefaces, que está mais maduro que o RichFaces e o Icefaces.
Segunda palestra: JSF 2.0 no GAE
Para usar o JSF 2 no Google App Engine, precisa de um pequeno hack em um classe da API. Infelizmente não consegui anotar qual era exatamente a classe.
O trecho se refere a chamada JNDI do EJB remoto, pois como o GAE está na CLOUD, não faz sentido escrever o “caminho do serviço”.
Fica a dica pra pesquisas futuras no Google se precisar.
Nesse endereço: http://www.yaw.com.br/open tem exemplos de apps adaptadas para rodar no GAE
Terceira palestra: JBoss Seam
Agora tive uma ideia legal do propósito do Seam. Ele possui implementações para facilitar a vida dos desenvolvedores JEE de ponta a ponta, desde a camada WEB até o Mapeamento Objeto Relacional com o Banco de dados. Com suas annotations podemos dizer que um simples POJO é um ManagedBean do JSF, sem tocar no faces-config.xml ou até mesmo um EJB sem configurar nada. Enviar e-mail pela javamail.api com apenas uma linha de comando e usar o próprio JSP para criar o html do e-mail. Com a annotation @In qualquer dependência pode ser injetada automaticamente nas suas classes, por exemplo, o EntityManager e o Transaction. Com a anotação @Resource declaramos que este objeto fica disponível para essa injeção. Não preciso nem falar que ele abre e fecha toda a transação automaticamente.. mais exemplos quando sair o slide.
Quarta Palesta: Arquitetura JEE 6
Essa foi apenas conceitual, exibindo algumas novas features do EJB 3.1 como a annotation @Singleton.
Mostrou também algumas opções de camadas lógicas e físicas de arquitetura, por exemplo, como camadas lógicas:
Cliente (HTML, Javascript, XML, etc.)
Presentation (JSP, MBs JSF, Action Struts, outros Controllers, etc…)
Business (EJB, JTA, …)
Integração (DAO, JPA, JMS…)
Recursos (Banco de dados, Mensageria, …)
E depois ele mostrou alguns exemplos de camadas físicas e onde ficavam as camadas lógicas.
Quinta Palestra: JPA 2 na prática
Antes de falar no JPA em si, criou um Servlet, usando a annotation @WebServlet disponível no Java 6. Essa anotação elimina completamente a declaração do Servlet no web.xml.
Exemplo: http://www.javabeat.net/articles/97-new-features-in-servlets-30-1.html
API doc: http://download.oracle.com/javaee/6/api/index.html?javax/servlet/annotation/WebServlet.html
Uma dica para facilitar na hora de criar os testes: No arquivo persistence.xml não declarar explicitamente o tipo de transação, se será JTA ou ResourceLocal. O conteiner faz isso automaticamente, evitando ter que criar um mock para poder testar um método que utilize essa unidade de persistência.
De resto, não deu tempo pra fazer muita coisa, ele só criou rapidamente relacionamentos OneToOne e OneToMany e mostrou o JPA criando as tabelas e persistindo no banco.
Para o relacionamento ManyToOne, quando a lista é enorme, é melhor optar por um query porque perde muito em performance.
Falou também da diferença entre os métodos .persist() e .merge();
Salientou que qualquer mudança de estado feita num objeto gerenciado durante uma transação pode ir para o banco de dados.
Sexta Palesta: 10 Dicas para Tunning do JBoss
Quando ele fala em tunning, ele não esta se referindo apenas a performance, mas também à usabilidade e à customização.
Mostrou muitos detalhes de configuração, pastas etc… Para saber quais só quando o slide estiver disponível.
Dica 1: slimming
Deletar todos os serviços não utilizados. Ele mostrou como faz isso e mostrou em tempo real o tempo de inicialização reduzido quase pela metade.
Dica 2: Binding Service
Este é para evitar o conflito de portas quando estiver subindo mais de uma instancia do servidor na mesma maquina, sem precisar ficar alterando xmls
Criar um alias, ex. “ports-01″, e configurar para somar + 100 ao numero das portas, por ex 8080+100 = 8180. Criar quantos alias for necessário.
Depois é só rodar o comando de inicialização, passando o parâmetro de qual binding usar para cada instancia. Acho que o parâmetro era:
-Djboss.service.binding.port = ports-01; Passou muito rápido o slide.
Dica 3: Jboss Web Thread Pool
Aumentar o maxThreads para melhorar o throughput da aplicação. Observar o currentThreadBusy pelo admin console.
Quem não sabe a quantidade ideal, ele sugere por 200 threads por cpu core. Ex Intel quadcore = 200 x 4 = 800 no maxThreads
Falou tb sobre um tal conector AJP… (pesquisar)
Dica 4: JVM Tunning
Ele mostrou muuuuitos parâmetros para otimizar a JVM… Desde os -Xmx, -Xms e -XX:PermSize até os que configuram a estratégia do garbage collector. (novo no Java 6: -XX:UseG1GC)
Só com o slide mesmo.
Dica 5: StackSize
Diminuir o tamanho reservado para cada Thread. Parametros -Xss ou -XX:ThreadStackSize
Evita erros de não conseguir alocar espaço para mais objetos ou threads.
Dica 6: JCA Thread Pool, StrictMaxPool para Message-Driven Beans e Jboss Messaging Thread Pool
Configurar os parâmetros para Mensageria JMS, Message-Driven Beans, no arquivo jca-jboss-beans.xml.
parametros maximumQueue, maximumPool, PoolSize e outros.
Dica 7: Logging
Diminuir o nível de log para WARN ou ERROR quando em produção, para reduzir a quantidade de I/O no sistema operacional
Mostrou o parametro -Djboss.server.log.thresold
Desligar o appender console em produção. (usar só o arquivo .log)
Usar o appender ASYNC junto com o FILE
Mudar a pasta do log, pelo parametro -Djboss.server.log.dir
E usar if(logger.isDebugEnable())
Todas essas dicas tem o objetivo de reduzir o I/O, que diminui bastante a performance.
Dica 8: Trocar o banco de dados nativo
Não consegui entender direito. Ele falou que o JBoss vem com o Hypersonic (HSQLDB) como padrão. Não sei se o JBoss usa esse banco para persistir alguma coisa própria.
Dica 9: Datasource
Falou que, por exemplo, cada conexão aberta no Oracle consome aproximadamente 8MB de memória, no servidor do banco de dados.
Mostrou alguns parâmetros do datasource:
min-pool-size, max-pool-size.
prefil (se setado como true, ja preenche o pool com conexões até o min-pool-size setado)
falou vários outros: blocking-timeout-millis, idle-timeout-minutes, transaction-isolation (setar conforme o banco), prepared-statement-cache-size, e outros…
Dica 10: Segurança
Não se esquecer de setar senha para o admin console
Falou para descontentar algumas linhas nos arquivos de configuração para habilitar a segurança.
Sétima Palestra: Escalando APPs
Falou dos problemas enfrentados quando chega a necessidade de se escalar as aplicações.
- Configurações estáticas, Sessão do usuário perdida quando o nó cai, custo de upgrade, balanceamento de carga não considera capacidade dos nós, etc…
Explicou a estratégia DNS Round-Robin.
Mostrou a nova solução da JBoss: mod_cluster, que implementa configuração dinâmica
Oitava e última Palestra: HornetQ
Apresentou essa solução para mensageria, que obteve um desempenho 307% maior que o JMS padrão do JBoss.
Pode rodar stand alone, não precisa o JBossAS.
Gabriel RubensPostagens Relacionadas:
]]>
Hoje eu vou deixar a dica para o lançamento de um livro sobre a prova SCJP, eu ainda não li o livro (está na lista de compras), mas como o autor já é conhecido principalmente por quem participa do fórum GUJ e costuma ler o o blog http://www.camilolopes.com.br/.
Como eu já vi o Camilo Lopes (LpJava) ajudando muita gente GUJ… Vale a publicidade! =).
O autor diz no site “O livro não substitui o livro da Kathy Sierra, pelo contrario ele vem como um material auxiliar. Ah outro detalhe, eu busquei usar uma linguagem não muito formal nas explanações para que o leitor acredite está conversando comigo.”
O livro também conta com um simulado, e para mais informações: http://blog.camilolopes.com.br/guia-de-bolso-para-scjp-lancamento/.
Gabriel Rubens
Postagens Relacionadas:
- O Programador Pragmático – Resenha do prefácio
- O Programador Pragmático – parte 7
- O Programador Pragmático – Capítulo 1
- O Programador Pragmático – parte 6
- O Programador Pragmático – Capítulo 2 – segunda parte
- O Programador Pragmático – Capítulo 2 – primeira parte
- O Programador Pragmático – parte 8
Livro SCJP (guia de bolso) Assine o Feed Grupo Haw FeedBurner
]]>
A partir de agora (sexta passada, 30/04/10) o Grupo Haw terá que aprender a trabalhar remotamente. É isso mesmo, até então nós trabalhávamos no mesmo local que é na cidade de Santos, e foi daí que surgiu a idéia do blog. Mas agora haverá uma mudança no nosso modo de estudar e manter os projetos pessoais, pois dois dos integrantes passaram a morar em Campinas para fazer mestrado na Unicamp.
Fonte: http://farm4.static.flickr.com/3566/3522104760_8c6e6eae4b.jpg
Bom então primeiro fica o desejo de boa sorte para o Eduardo e o Lucas (e o André que foi com eles) que já estão com o Mestrado em andamento, e agora vamos ter oportunidade de aprender a trabalhar remotamente.
Eu acho que será divertido tentar sincronizar os horários para dar continuidade com os projetos pessoais, além disso, vale a experiência para o futuro.
Mais uma vez, boa sorte para vocês nesse novo desafio!
Até mais.
Gabriel RubensPostagens Relacionadas:
]]>
Nesse artigo vou falar sobre um tema bem interessante Validação de Formulários, é uma coisa muito comum, mas que leva um tempinho considerável.
Vou mostrar um jeito no qual você não vai precisar ter quase nenhum trabalho, basta mudar um parâmetro. Mesmo tendo vários artigos na internet abordando o mesmo assunto, resolvi fazer mais um por que nunca vi um com um código parecido com esse.
Primeiro passo.
Nós vamos trabalhar com dois arquivos sendo um o javaScript.js e o outro o nosso formulário chamado aqui de formulario.htm.
javaScript.js
Você deve saber que nesse arquivo vai estar todo o código do javaScript e que ele não muda não importando qual é o formulário, abaixo segue o código comentado:
//aqui é a declaração da função ela vai receber como parâmetro um array contendo
//todos os objetos do formulário
function validaForm (formulario)
{
//aqui já é a estrutura de repetição responsável pela varredura de todos os objetos
//contidos no formulário, é bom ressaltar 2 pontos importantes aqui, primeiro que
//a varredura passa por todos os objetos do formulário não importando qual seu
//tipo como, por exemplo, “submits”, password, textarea e etc. e o outro ponto
//importante de ressaltar é que o “formulario.length-1” é usado porque o array
//começa do 0 sendo o i a variável de controle do índice.
for(i=0;i<=formulario.length-1;i++)
{
//Como já foi dito antes o “for” acima passa por todos os objetos do
// formulário, então para economizar processamento e também para
// evitar possíveis erros é necessário esse “if” verificando o tipo do objeto,
// note que acessamos os objetos com a variável passada por parâmetro
// usando como um array desse jeito: formulario[i] isso é a mesma coisa
//de chamar o objeto pelo nome, então nós temos acesso a todas as
// propriedades desse objeto uso então a propriedade type que retorma
// o tipo do objeto em uso.
if ((formulario[i].type=="textarea")||(formulario[i].type=="file")||(formulario[i].type=="hidden")||(formulario[i].type=="text")||(formulario[i].type=="password"))
{
//Agora começa a interação com o formulário, mas a frente você vai entender
// melhor esse “if”, ele serve para ver se a propriedade “wmsg” é diferente
// de vazio porque se for é porque você disse que esse campo é obrigatório,
// sendo que é nessa propriedade aonde é guardado a mensagem que vai
// aparecer caso o campo esteja vazio.
if ((formulario[i].getAttribute('wmsg')!="")&&(formulario[i].getAttribute('wmsg')!=undefined))
{
//Outra propriedade que você vai usar é a “email” nela você fala se no objeto
// além de ser obrigatório ainda tem que ter uma validação para um campo do
// tipo email essa validação é uma validação básica procurando” @ e” .” no
// email. E o “try catch” serve para não aparecer mensagem de erro pois não
// é possível dar um” focus” no campo do tipo “hidden”
// o return false diz q ocorreu um erro e os dados não devem ser enviados ainda
if (formulario[i].getAttribute('email')=="sim"){
if((formulario[i].value=="")||(formulario[i].value.indexOf('@')==-1)
||(formulario[i].value.indexOf('.')==-1)){
alert(formulario[i].getAttribute('wmsg'));
try{
formulario[i].focus();
}catch(e){}
return false
}
}
//aqui já é caso não seja um campo do tipo email ai não precisa ter o @ e nem o .
else
{
if(formulario[i].value=="")
{
alert(formulario[i].getAttribute('wmsg'));
try
{
formulario[i].focus();
}catch(e){}
return false
}
}
}
}
}
}
Segundo passo
Agora que você já passou pela parte mais difícil dessa matéria, vamos ao html. Você pode fazer da maneira na qual está acostumado com as diferenças em vermelho.
Na primeira marcação de vermelho é onde adicionamos o javaScript criado no primeiro passo desse artigo, a segunda marcação já é onde chamamos a função criada no java. Observe que o “return” precedido da função é utilizado para travar o envio das informações caso seja constatado que algum campo esteja irregular.
Já a ultima marcação em vermelho é onde está mesmo a grande diferença das maneiras convencionais. Temos duas propriedades novas criadas a “wmsg” e a “email”.
wmsg: é exatamente a mensagem que vai aparecer caso o campo esteja irregular e a segunda serve para verificar se o campo é do tipo e-mail ou não, observe que para ser obrigatório, um campo precisa ter essa propriedade preenchida com alguma mensagem, se essa propriedade ficar vazia significa que o campo não é obrigatório.
email: se essa propriedade estiver marcada como sim significa que o campo é do tipo e-mail e, conseqüentemente, além de ser obrigatório o campo ele ainda precisa conter o “@” e o “.”
<html> <head> <title>Formulário</title> <script src="javaScript.js"></script> </head> <body> <form id="form1" name="form1" method="post" onsubmit="return validaForm(this)" action=""> Teste de formulário <br /> <br /> <input type="text" wmsg="Campo Text Em Branco" name="textfield" /> <br /> <br /> <input type="text" wmsg="Campo Text Em Branco verificando email" email="sim" name="textfield3" /> <br /> <br /> <input type="password" wmsg="Campo password Em Branco" name="textfield2" /> <br /> <br /> <input type="file" name="file" wmsg="Campo file Em Branco" /> <br /> <br /> <textarea name="textarea" wmsg="Campo textarea Em Branco"></textarea> <input type="hidden" name="hiddenField" wmsg="Campo hidden Em Branco" /> <input type="submit" name="Submit" value="Submit" /> </form> </body> </html>
Espero que tenha gostado dessa dica e aprendido algo com esse artigo. Estou à disposição para qualquer dúvida, sugestão ou reclamação.
Obs. Esse artigo eu já havia publicado no imasters, apenas arrumei para poder funcionar no Firefox também.
Os fontes podem ser baixados nos links abaixo:
JavaScript
HTMLPostagens Relacionadas:
- Nenhuma postagem encontrada
Validação Automatica de Formulario Assine o Feed Grupo Haw FeedBurner
]]>
O modo ideal de escrever os testes de unidade é utilizando o ciclo de Desenvolvimento Dirigido (Guiado) por Teste ou TDD.
- Criar um teste
- Executar todos os testes
- Escrever o código
- Executar todos os testes novamente até executarem com sucesso
- Refatorar
- E repetir o ciclo
Que pode ser descrito como Red ->Green -> Refactor!
Pra quem está querendo começar a entender o framework JUnit pode utilizar as facilidades proporcionadas pelo Eclipse, que é criar o classe e os métodos de teste.
Bom, vamos ao exemplo onde primeiro será criada uma classe e seus métodos sem implementação (retornando 0), e depois com a ajuda do Eclipse já criar a classe de teste já com os métodos.
As classes apresentadas ficaram nos pacotes “main.java.br.com.haw.calculadora” e “test.java.br.com.haw.calculadora”, sendo que o primeiro é para a classe “Calculadora” e o segunda é para classe “CalculadoraTest”.
Nesse caso a classe é criada junto com os métodos que ainda estão sem implementação:
public class Calculadora {
public int soma(int numeroUm, int numeroDois) {
return 0;
}
public int subtrai(int numeroUm, int numeroDois) {
return 0;
}
public int multiplica(int numeroUm, int numeroDois) {
return 0;
}
public int divide(int numeroUm, int numeroDois) {
return 0;
}
}
Essa calculadora está com seus métodos retornando 0 só pra não indicar erro no Eclipse. Depois disso é só clica com o botão direito sobre a classe Calculadora New -> JUnit Test Case:
Após clicar aparecerá a tela New JUnit Test Case, selecione o rádio New JUnit 4 test e para deixar as coisas mais arrumadas é bom manter os pacotes das Classes e dos Testes com nomes semelhantes, como mostra a seta na próxima imagem, que só muda o main para test:
Na próxima tela selecione todos os métodos criados pela nossa classe e clique em Finish:
E aparecerá uma tela avisando que o JUnit 4 não está no build path, selecione a opção Perform the following action clique em Ok:
Agora uma classe chamada CalculadoraTest foi criada no pacote indicado:
public class CalculadoraTest {
@Test
public void testSoma() {
fail("Not yet implemented");
}
@Test
public void testSubtrai() {
fail("Not yet implemented");
}
@Test
public void testMultiplica() {
fail("Not yet implemented");
}
@Test
public void testDivide() {
fail("Not yet implemented");
}
}
Ao rodar os testes vamos ter quatro testes falhando e a famosa “barra vermelha” que indica que os métodos não estão funcionando.
Agora vamos ao primeiro método que é o soma, onde nosso método de teste utilizará o assertEquals(message, expected, actual) para testar se o resultado é o esperado. O primeiro argumento é a mensagem que será apresentada no caso do teste falhar, o segundo argumento é o valor esperado e o terceiro é o método que devolverá o valor testado que será comparado.
message: Mensagem amigável para descrever o comportamento ideal, ou algo que indique o funcionamento do método;
expected: Valor que deve ser retornado;
actual: é a condição a ser testada, no caso o método correspondente ao método.
Então o método pode ser lido desse modo: Caso o resultado esperado (expected) seja diferente do retornado (actual) mostre a mensagem (message).
@Test
public void testSoma() {
Calculadora calc = new Calculadora();
assertEquals("Deve retorna 57", 57, calc.soma(30, 27));
}
Agora o próximo passo é rodar o teste mais uma vez e… Opa, todos falharam novamente!
Então vamos a implementação dos métodos, começando pela soma:
public int soma(int numeroUm, int numeroDois) {
return numeroUm + numeroDois;
}
E rodando os testes vemos que um erro sumiu, e agora o método soma que nesse caso representa a unidade testada está funcionando:
Mais a barra continua vermelha, então vamos ao próximo método e que é subtrai:
@Test
public void testSubtrai() {
Calculadora calc = new Calculadora();
assertEquals("Deve retorna 9", 9, calc.subtrai(100, 91));
}
Aí está o método de teste, que por motivos óbvios ainda não está passando, então vamos implementar o método subtrai da classe Calculadora:
public int subtrai(int numeroUm, int numeroDois) {
return numeroUm - numeroDois;
}
Agora rodando temos dois métodos passados nos teste, mas a barrinha ainda está vermelha… E como a tarefa diária de um desenvolvedor que programa com teste de unitário é fazer a barra ficar verde, mãos a massa.
@Test
public void testMultiplica() {
Calculadora calc = new Calculadora();
assertEquals("Deveria ter retornado 500", 500, calc.multiplica(50, 10));
}
Rodando os testes vemos que a multiplicação está falhando, e assim o ciclo é repetido com a implementação do método:
public int multiplica(int numeroUm, int numeroDois) {
return numeroUm * numeroDois;
}
Agora são três dos quatro métodos passando nos testes, mas… A barrinha ainda está vermelha.
E o teste para o divide fica desse modo:
@Test
public void testDivide() {
Calculadora calc = new Calculadora();
assertEquals("Deveria ter retornado 1", 1, calc.divide(50, 50));
}
Rodando os testes… Continuam falhando então vamos a implementação:
public int divide(int numeroUm, int numeroDois) {
return numeroUm / numeroDois;
}
E rodando os testes vemos a esperada barrinha verde do JUnit… Parabéns, o trabalho está quase terminado…
Só que olhando direito esse código tem algo errado, está funcionando, mas da pra ver que estes métodos não estão muito OO.
public class CalculadoraTest {
@Test
public void testSoma() {
Calculadora calc = new Calculadora();
assertEquals("Deve retorna 57", 57, calc.soma(30, 27));
}
@Test
public void testSubtrai() {
Calculadora calc = new Calculadora();
assertEquals("Deve retorna 9", 9, calc.subtrai(100, 91));
}
@Test
public void testMultiplica() {
Calculadora calc = new Calculadora();
assertEquals("Deveria ter retornado 500", 500, calc.multiplica(50, 10));
}
@Test
public void testDivide() {
Calculadora calc = new Calculadora();
assertEquals("Deveria ter retornado 1", 1, calc.divide(50, 50));
}
}
Em todos os métodos de teste eu tenho que “criar uma calculadora”, então eu tenho que separar essa criação em um método, para não ficar muito repetitivo.
Para esse tipo de problema o JUnit 4 conta com as Annotation @Before que roda antes de cada teste. Sendo assim, todos os métodos que estão anotados com @Before são executados antes de cada método anotado com @Test, e os que estão @After são rodados depois de cada teste.
E pra dar uma refatorada (se essa palavra existir) na classe de teste vamos excluir todas as linhas que criam calculadoras, e depois criar o método criarCalculadora() com a Annotation:
public class CalculadoraTest {
private Calculadora calc;
@Before
public void criarCalculadora() {
calc = new Calculadora();
}
@After // Libera os recursos criados
public void destruirCalculadora() {
calc = null;
}
@Test
public void testSoma() {
assertEquals("Deve retorna 57", 57, calc.soma(30, 27));
}
@Test
public void testSubtrai() {
assertEquals("Deve retorna 9", 9, calc.subtrai(100, 91));
}
@Test
public void testMultiplica() {
assertEquals("Deveria ter retornado 500", 500, calc.multiplica(50, 10));
}
@Test
public void testDivide() {
assertEquals("Deveria ter retornado 1", 1, calc.divide(50, 50));
}
}
Se a barrinha estiver verde, pense em mais alguns testes que possam ser implementados (e há outros nessa classe) e continue o ciclo -> Red -> Green -> Refactor -> Red -> Green -> Refactor -> Red -> GreenRefactor. ->
A classe Calculadora até é fácil de testar, mas a idéia é ir brincando de teste com tudo que for possível, eu pelo menos estou tentando seguir as apostilas e livros que estou lendo com TDD, e a parte mais complicadas são classe/componentes complexos, onde entram os Mocks.
Uma coisa que me deixou curioso são os teste com os DAOs/Hibernate/JPA, ainda não cheguei nessa parte, mais quero ver como fazer teste com os objetos que vem do banco…
Por enquanto eu estou brincando com uma classe utilitária que cria o banco, popula a tabela, testa e exclui o banco (eu sei, é totalmente inviável em uma aplicação comercial, mas foi só pra brincar um pouco).
UPDATE: E o agradecimento ao Thiago @thgraca por me cobrar pela postagem e ser o beta tester.
Há braços! ; )Postagens Relacionadas:
- Método, Variável e Classe Final
- Regras de Interfaces Java
- Palavras-Chave Java
- Identificadores Legais – Java
Teste Unitário com JUnit – Rapidinho Assine o Feed Grupo Haw FeedBurner
]]>
Olá amigo leitor, estou retornando a postar neste blog depois de muiiiitoooo tempo sem postar, estou atualmente estudando java para aplicações WEB, e o grande motivo aqui é auxiliar a grande quantidade de pessoas no mundo dos códigos binários que possuem problemas ao fazer o primeiro exercício com struts da apostila FJ21 da Caelum (www.caelum.com.br).
Bom, eu passei muito tempo pra fazer funcionar este pequeno exercício (agora está explicado o porquê que não venho postando !!!!! rsrsrsr).
O objetivo deste é mostrar o funcionamento de um controlador struts, que tem como objetivo redirecionar a aplicação para o jsp olaMundoStruts.jsp quando a url http://localhost:8080/fj21-tarefas/olaMundoStruts for acionada.
Fiz tudo certo…
- Baixei o arquivo struts-2.1.8.1-lib.zip do struts 2 do site http://struts.apache.org/2.x/.
- No Eclipse Galileo (fiz o download do site http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR2/eclipse-jee-galileo-SR2-win32.zip) criei um projeto “Dynamic Web Project” conforme diz a apostila.
- Descompactei o arquivo struts-2.1.8.1-lib.zip e coloquei todos os arquivos JARs dentro da pasta WebContent/WEB-INF/lib do projeto que criei.
PÃÃÃ … PRIMEIRO ERRO…. Não utilize arquivos JARs que você não vai utilizar, apenas o necessário…
mas quais são os arquivos necessários???? peguei essa resposta do fórum do GUJ (aí vai a url, http://www.guj.com.br/posts/list/200940.java)
- Descompactei o arquivo struts-2.1.8.1-lib.zip e coloquei somente os arquivos JARs (commons-fileupload-1.2.1.jar, commons-io-1.3.2.jar, freemarker-2.3.15.jar, ognl-2.7.3.jar, struts2-convention-plugin-2.1.8.1.jar, struts2-core-2.1.8.1.jar, xwork-core-2.1.6.jar ) dentro da pasta WebContent/WEB-INF/lib do projeto que criei.
- Em seguida Startei… ou melhor cliquei no START do Servlet Container Apache TomCat (download: http://tomcat.apache.org/) (muitos dizem erroneamente Servidor Web)
- Abri a página WEB e informei a url http://localhost:8080/fj21-tarefas/olaMundoStruts e .. tãn-tãn tãn-tãããn….
PÃÃÃ … SEGUNDO ERRO…. A página Web apresentou um saboroso erro 404… putzzzzz e agora…
ahhhhhhh esse é fácil, a dica veio do meu caro amigo das POOs em PHP Wendersonnnn, que viu minha classe OlaMundoAction da seguinte forma:
package br.com.caelum.tarefas.action;
import org.apache.struts2.convention.annotation.Action;
import org.apache.struts2.convention.annotation.Result;
public class OlaMundoAction {
@Action(value = "olaMundoStruts", results = {
@Result(location = "/olaMundoStruts.jsp", name="ok")
})
public String execute(){
System.out.println("Executando S T R U T S II");
return "ok";
}
}
Com seu olho extra biônico viu o erro que estava na linha número 9 e rapidamente corrigi para:
@Action(value = "olaMundoStruts", results = {
@Result(location = "/WEB-INF/olaMundoStruts.jsp", name="ok")
})
então continuando o fluxo
- Abri a página WEB e informei a url http://localhost:8080/fj21-tarefas/olaMundoStruts e .. tãn-tãn tãn-tãããn…
Funcionouuuuuuu uhuuuuuuuhuuu…!!!!!!!!!!!!!
Por favor caro leitor, vamos ajudar quem precisa de ajuda, passei muito tempo pra descobrir estes detalhes, se você achar necessário correção neste post, faça um comentário que brevemente eu alterarei o postarei novamente, faça uma pessoa feliz.
Eduardo Gomes da Silva
Grupo HawPostagens Relacionadas:
Problema para rodar o STRUTS 2 Assine o Feed Grupo Haw FeedBurner
]]>
Faala!
Depois de uma eternidade sem postar, o Grupo Haw está de volta. Esse tempo parado foi bastante proveitoso para meter a cara nos livros.
Hoje acordei com o seguinte questionamento:
“Por quê atualmente os desenvolvedores tem tanta restrição dentro das empresas?”.
Novas tecnologias, novas idéias, novas metodologias, ou qualquer coisa proposta por eles não são bem vistas. É enfrentado por analistas, arquitetos, engenheiros, DBA’s e às vezes pessoas sem o mínimo de conhecimento técnico no assunto, mas que por uma questão de hierarquia acabam tendo esse poder.
O problema não é ter idéias avaliadas por profissionais capacitados com os quais você pode discutir, mas sim barrada por motivos irrelevantes como alguém querendo fazer valer sua posição na “cadeia alimentar”. De que vale investir tanto em conhecimento técnico, se não é permitido exercer o rótulo de Desenvolvedor e pensar no que se está criando?
Fonte: QualidadeBR
A exigência de conhecimento em um processo seletivo não justifica as funções hoje exercidas pelos profissionais. Para quê cobrar tanto se no final você vai seguir um tutorial apenas?
Estão acabando com o termo, transformando o profissional em apenas um digitador de código que traduz documentos de Caso de Uso para linguagem de programação. O que chamávamos de Desenvolvedor é na verdade o Analista Programador, que modela e desenvolve tendo um pouco mais de liberdade.
O Desenvolvedor de hoje é infelizmente um macaco treinado. Não por ignorância sua, mas sim por impotência (perante seus chefes) para poder desempenhar o que gostaria.
Toda essa censura impede o profissional de evoluir. Por isso, não parem de estudar e rumo ao topo para que possamos mudar toda essa baboseira que nos é imposta.
Postagens Relacionadas:
Desenvolvedor ou Digitador de Código? Assine o Feed Grupo Haw FeedBurner
]]>
Essa é a segunda parte da saga POO em PHP, se você não leu a parte 1 CLIQUE AQUI e dê uma olhada antes.
Hoje falarei sobre herança e faremos alguns exemplos. Irei lentamente, pois esse assunto é um pouco complicado de entender. Então vamos nessa!
No ultimo post criamos uma classe chamada polígono. Mas e se ao invés de polígono nós precisássemos fazer um retângulo? Bom, na programação estruturada deveríamos refazer tudo ou criar uma nova função para isso, mas na POO o mundo fica um pouco mais fácil. Nós devemos simplesmente criar uma classe chamada retângulo, que estende a classe polígono (você também pode falar que a classe polígono é a super classe da classe retângulo), ao fazermos isso a classe retângulo recebe todos os atributos e métodos da classe polígono (não é tão assim depende da visibilidade, mas veremos depois, por enquanto você pode dizer que a classe retângulo herda tudo da classe Polígono). Abaixo está o exemplo do que foi explicado até agora.
Usarei o mesmo exemplo do post anterior com apenas a adição de 1 classe:
class Poligono
{
public $lados = array();
function __construct( $parLados) {
echo('<BR><BR>Objeto CONSTRUIDO<BR>');
$this->lados=$parLados;
print_r($this->lados);
}
function __destruct ( ) {
echo('<BR><BR> Objeto destruído');
}
function perimetro(){
$auxPerimetro = 0;
foreach ($this->lados as $l) {
$auxPerimetro +=$l;
}
return $auxPerimetro;
}
}
$l = array(10,20,30);
$pol = new Poligono($l);
echo('<BR> <BR> o perimetro do poligono é:'.$pol->perimetro());
class Retangulo extends Poligono
{
}
$l1 = array(10,20,10,20);
$re = new Retangulo($l1);
echo('<BR><BR> o perimetro do Retangulo é:'.$re->perimetro());
O código está exatamente igual ao código do ultimo post até a linha 30, aonde há a declaração da classe retângulo. Note que a única diferença dessa declaração para a outra do polígono é a palavra reservada extends, ela informa que a classe retângulo estende a classe Polígono. Perceba que eu não coloquei nenhum método ou atributo na classe, mas logo abaixo na linha 36 eu tive que passar por argumento os lados do retângulo na construção do objeto, isso se dá porque a classe retângulo herda o construtor da classe polígono, e ainda na linha 38 eu consegui acessar o método perímetro, mesmo sem ter escrito nada, de novo a mesma coisa, a classe retângulo herdou o método perímetro da classe polígono.
Até ai tudo certo e fácil de entender, mas a classe retângulo acabou sendo mesma a coisa que a classe polígono, devemos colocar as particularidades do nosso retângulo nessa nova classe.
Primeiro o construtor ficou muito burro, pois ele recebe um array de lados, mas sabemos que o retângulo tem sempre 4 lados e vamos fazer um retângulo regular, então a base tem o mesmo tamanho que o topo. Nosso construtor deverá receber 2 parâmetros (base a altura), para tanto vamos fazer uma coisa chamada de sobrescrita (override).
Sobrescrita é quando queremos mudar algum método da classe Pai (superclasse), significa que ao invés de o objeto acessar o método da classe Pai ele vai acessar o método da classe filha, e para realizar a sobrescrita temos apenas que manter o mesmo nome do método na classe filha.
Veja como fica o código do nosso teste (da linha 30 para cima não precisa alterar nada, portanto irei omitir esse código)
class Retangulo extends Poligono
{
function __construct( $parBase,$parAltura) {
echo('<BR><BR>Retangulo CONSTRUIDO<BR>');
$auxLados = array($parBase,$parAltura,$parBase,$parAltura);
parent::__construct($auxLados);
}
function area(){
return $this->lados[0] * $this->lados[1];
}
}
$re = new Retangulo(10,20);
echo('<BR><BR> o perimetro do Retangulo é:'.$re->perimetro());
echo('<BR><BR> e a area do Retangulo é:'.$re->area());
Você pode notar que na linha 33 eu sobrescrevi o método “function __construct”. Agora ao instanciar um objeto da classe Retangulo, o PHP vai executar o construtor da classe filha e não da classe Polígono (eu também adicionei um método para calcular a área do nosso retângulo).
Você deve estar achando estranho o comando parent, ele é o responsável por acessar os métodos da superclasse.
Explicando o que está fazendo o construtor da Casse Retangulo:
Recebe dois parâmetros(base e altura), cria um array de arestas para depois acessar o construtor da classe pai passando o array como parâmetro.
O resultado desse código você pode ver abaixo:
Para finalizar o artigo de hoje eu quero que você note na figura acima, as duas ultimas linhas, ao acabar o programa o PHP libera os objetos da memória, por isso aparece essa informação de objeto destruído 2 x (já que criamos 2 objetos).
No próximo artigo iremos ver a Visibilidade do PHP e começar a ver a Pseudo sobrecarga também.
Até
Wenderson Lisardo
<- Parte 1Postagens Relacionadas:
POO(Programação orientada a Objetos) em PHP (parte 2) Assine o Feed Grupo Haw FeedBurner
]]>
Há um falatório muito grande em cima deste conceito. Muitas pessoas acreditam que em PHP não existe Orientação a Objeto.
A verdade é que ela é Orientada a Objeto desde a sua versão 3.0 apesar de ser uma coisa muito porca e mal feita, pois somente dava suporte a sintaxe e não permitia a correta utilização do conceito em si. A partir da versão 4 veio uma coisa mais inteligente, porém ainda longe da POO real.
No PHP5 sim, vieram os conceitos de visibilidade, interface, clonagem e tipagem dos parâmetros. Então para poder visualizar os exercícios abaixo você deve ter instalado em sua maquina o PHP5.
Bom, chega de lero-lero e vamos ao que interessa: a Orientação de Objetos em PHP!
Para se declarar uma classe, usamos da sintaxe abaixo (apesar do exemplo ser clássico vale a pena usá-lo):
class Poligono
{
<span> </span>public $lados = array();
<span> </span>function __construct( $parLados) {
<span> </span>echo('Objeto CONSTRUIDO<BR>');
<span> </span>$this->lados=$parLados;
<span> </span>print_r($this->lados);
<span> </span>}
<span> </span>function __destruct ( ) {
<span> </span>echo('<BR>Objeto
destruído<BR>');
<span> </span>}
<span> </span>function perimetro(){
<span> </span>$auxPerimetro = 0;
<span> </span>foreach ($this->lados as $l) {
<span> </span>$auxPerimetro +=$l;
<span> </span>}
<span> </span>return $auxPerimetro;
<span> </span>}
}
$l = array(10,20,30);
$pol = new Poligono($l);
echo('<BR> o perimetro do poligono é:'.$pol->perimetro());
Note que temos em nossa classe 2 métodos diferentes, o método contruct e o destruct. Usamos essas duas funções para realizar os passos necessários ao se instanciar um objeto e ao liberá-lo da memória respectivamente.
No exemplo acima, ao instanciar o polígono recebemos por parâmetro a base e a altura do mesmo para assim poder setar os atributos da classe com os valores passados por parâmetro.
Então resumindo a obra, o método construct é o método construtor da classe, quando criamos um objeto dessa classe o método construct é acionado assim como no exemplo acima, recebe por parâmetro os lados do polígono e inicializa o atributo da classe polígono. E depois quando é finalizado o programa, o PHP automaticamente libera o objeto da memória, dispara o método destruct e exibe a mensagem do objeto destruído.
Se você copiar o código acima e rodar você receberá isso como resposta.
Esse é nosso primeiro passo em relação à POO em PHP, aqui você aprendeu como se declara uma classe e o para que serve o método costruct e destruct. No próximo artigo veremos o como se trabalha com sobrecarga de métodos e alguns controladores que agora lhe parecem estranhos como o $this, até lá.
Postagens Relacionadas:
POO(Programação orientada a Objetos) em PHP (parte 1) Assine o Feed Grupo Haw FeedBurner
]]>
Basicamente o modificar final é aplicado da seguinte maneira:
- Variável: Uma variável final não pode ter o seu valor alterado
- Método: Um método final não pode ser sobrescrito
- Classe: Uma classe final não pode ser estendida
Sendo assim, é importante saber que você dever ter algumas coisas em mente antes de sair declarando tudo como final, principalmente classes e métodos, pois alguns princípios de orientação a abjetos (veja aqui e aqui) são quebrados quando esse modificador é utilizado de forma indiscriminada.
Mas também tem o outro lado, pois em muitos casos o modificador final garante a segurança, como podemos ver na classe String.
Linguagens como Ruby permitem que você mude (não sei se mude é a palavra mais apropriada) a classe String, por um lado isso é ótimo, pois garante mais flexibilidade, mas por outro lado pode ser perigoso, e exige conhecimento do que você está fazendo.
Agora vamos para as regras:
Variável Final
Uma Variável final não pode ter ser valor alterado. Sendo assim, quando declaramos uma variável assim:
final int var = 10;
Não podemos alterar seu valor, e caso você tente alterar ocorrerá uma exceção, exemplo:
class VarFinal{
public static void main(String args[]) {
final int idade = 20;
System.out.println(idade);
idade += 1; // Erro!!
}
}
Ao tentar rodar essa classe você verá a exceção: VarFinal.java:6: cannot assign a value to final variable idade.
Lembrado que se essa variável for um atributo de um objeto ela deve ter o seu valor inicializado, pois as variáveis finais não são inicializadas com valor default.
Argumento Final
Além de ser usado em variáveis, métodos e classe o modificador final também pode ser utilizado nos argumentos, e como ver em código é melhor do que em texto, vamos a mais uma classe:
class ArgFinal {
// a declaracao e bem simples
public void argumentoFinal (final int idade) {
/* do mesmo modo que uma variavel final
se tentarmos alterar o seu valor... */
idade += 1; // Erro!!
}
}
Só lembrando que também não podemos alterar o valor de um argumento final, e se você insistir em tentar o compilador reclamará: ArgFinal.java:4: final parameter idade may not be assigned
Método Final
O modificador final normalmente é utilizado em métodos importantes para o programa, e que não podem ter o seu comportamento alterado (voltamos ao exemplo da classe String), e se tentarmos sobrescrever um método final, vai aparecer uma exceção igual ao próximo exemplo:
class MaeFinal {
final void imprimeOi(){
System.out.println("Oi");
}
}
class FilhaFinal extends MaeFinal {
void imprimeOi() {
System.out.println("Oi novo");
}
}
A classe MaeFinal compila sem nenhum problema, mas ao tentar compilar a classe FilhaFinal teremos a seguinte exceção: FilhaFinal.java:2: imprimeOi() in FilhaFinal cannot override imprimeOi() in MaeFinal; overridden method is final.
Classe Final
E finalmente, as classes finais (que trocadilho ridículo)…
As classes marcadas com o modificador final não podem ser herdadas (ter subclasses/classes filhas), sendo assim nenhuma classe pode reaproveitar as funcionalidades dela.
Bom, mas vamos ao código em Java:
final class MaeFinal {
// variaveis e metodos
}
class FilhaFinal extends MaeFinal {
// Erro!!
}
E mais uma vez, se tentarmos executar a classe FilhaFinal, teremos a seguinte exceção: FilhaFinal.java:1: cannot inherit from final MaeFinal.
É importante lembrar que uma classe não pode ser marcada como final e abstract ao mesmo tempo, final e abstract são praticamente o oposto, enquanto com final uma classe não pode ser estendida, com abstract ela deve ser estendida.
Chegamos ao final de mais um post, e em breve estarei escrevendo também sobre minha nova experiência com Ruby, comecei a estudar agora (claro que em “banho Maria”) e estou tendo uma boa impressão, e não é só outra linguagem de programação, é um novo conceito (outro modo de solucionar um problema)… E é claro que eu vou escrevendo sobre esses conceitos na medida em que eu for estudando.
Gabriel RubensPostagens Relacionadas:
- Regras de Interfaces Java
- Identificadores Legais – Java
- Teste Unitário com JUnit – Rapidinho
- Palavras-Chave Java
- Certificado Java com o jeitinho brasileiro: Oracle Certified Java Programmer – OCJP/SCJP
Método, Variável e Classe Final Assine o Feed Grupo Haw FeedBurner
]]>
Depois de um tempo pensando sobre o assunto, eu decidir investir nessa linguagem também.
Eu sei que vai ser difícil estudar duas coisas ao mesmo tempo (Java, Ruby), mas eu acho que vale o esforço. Então a partir de agora eu vou dividir meu tempo de estudo entre Java e Ruby e, além disso, ainda tem a faculdade e trabalho. Mas vai ser bom, principalmente porque agora eu vou ter que gerenciar melhor o meu tempo, coisa que eu faço muito mal (nem faço).
Além disso, já vou incluir nesse “gerenciamento de tempo” o Inglês. Porque já está me fazendo falta, e isso vai ser essencial pra eu poder continuar avançando nos estudo, é o único modo de ter acesso a materiais sempre atualizados, e ler as versões originais dos livros. E já passou da hora, chega de desculpas de não ter tempo, vou começar do zero, mas uma hora eu tenho que começar, e vai ser agora!
É claro que esse interesse por Ruby não surgiu do nada, já faz um tempo que eu leio artigos sobre Ruby, assino os Feeds de vários blogs, e muitos deles também falam sobre Ruby, e outra coisa que me incentivou bastante é o ânimo da comunidade RoR, o pessoal é bem empolgando, e eu gosto disso. Eu sempre tentei me policiar nesse aspecto, pois eu sou o tipo de cara que quando aprende uma coisa nova fica ansioso pra poder falar pra alguém, explicar, discutir o assunto e ver um ponto de vista diferente, e até então, eu achava isso ruim. Mas desde o tempo que eu comecei a ler mais blogs como o AkitaOnRails, Nome do Jogo, entre outros… E principalmente participar do grupo rails-br, eu percebi que eu não sou o único cara empolgado em aprender coisas novas…
Bom, pelos meus planos meu Tempo de Estudo agora vai ficar assim:
- Java (SCJP) 2/6;
- Ruby (RoR) 1/6;
- Faculdade 1/6;
- Inglês 1/6;
- Outros 1/6.
E agora chega de escrever, que eu tenho que estudar!!
Gabriel RubensPostagens Relacionadas:
]]>
Quem nunca se perguntou isso? Acredito ser a primeira pergunta que vem a cabeça de quem está iniciando na orientação a objetos. Por esse motivo tentarei encontrar uma maneira simples, clara e objetiva de explicar.
Ok, então vamo nessa!
Antes de tentar revelar o mistério precisamos dar uma repassada básica em orientação a objetos. OO é um paradigma de desenvolvimento, ou seja, um modelo ou padrão a ser seguido, que tenta representar conceitos da vida real através de objetos com o intuito de atingir algum objetivo.
Eu disse conceitos, pois como foi bem lembrado em um artigo do Urubatan, nem todos os objetos na programação representam exatamente objetos na vida real. Tal como um objeto Compra que não é algo materializável no nosso mundo. Acho que agora podemos partir para as classes.
Classe como muitos livros definem, é o molde para criação de um objeto, ou seja, a fôrma de como ele deve ser criado. Um exemplo de comparação é a planta de uma casa, ela seria a classe e a casa em si o objeto. Através de uma única planta podemos construir várias casas. O projeto de um carro serve para construirmos vários carros e cada um, apesar de serem construídos a partir do mesmo projeto, podem ter suas particularidades (cor, airBag,etc..). O carro é o nosso objeto e o projeto do carro a nossa classe.
A classe que serve para a criação de um objeto, ou seja, representação de um conceito na vida real pode ter origem basicamente através de: uma coisa tangível, de uma função desempenhada, de um incidente ou uma interação;
Coisa tangível: um objeto em si, carro, bola, martelo, etc.;
Função determinada: representação de um emprego ou função. Ex.: dentista, professor, etc.;
Incidente: que incide sobre algo, acrescenta qualidade ao antecedente. Ex.: vôo, apresentação, aula, etc.;
Interações: que interagem, de movimentação. Ex.: compra, venda, casamento, etc.;
Uma classe define o estado de um objeto e o modo como ele se comporta através de atributos e métodos que seriam as características do nosso carro e as funcionalidades que ele apresenta.
Características ou atributos: cor, preço, ano, modelo e etc.
Funcionalidades ou métodos: acelerar, buzinar, derrapar e etc.
Em algumas fontes de pesquisa podemos encontrar classes como uma estrutura que abstrai um conjunto de objetos similares (vide Wikipédia), ou seja, um molde, fôrma, projeto que foca nos aspectos mais importantes de um objeto a fim de representá-lo de forma generalizada, podendo ser reutilizado.
A idéia é tentar generalizar, agrupando as informações mais importantes no momento em que se descreve uma classe para que ela possa ser utilizada muitas vezes. Esse conceito será melhor explicado em tópicos futuros como os de Generalização e Herança
Bem gente, eu espero não ter esquecido nada. Tentei facilitar ao máximo e por isso é interessante que vocês nos dêem um retorno sobre os post’s. Assim podemos saber se estamos falando de uma maneira que todos entendam e também descobrimos se não erramos em nada.
Hasta La Vista,
Lucas MenezesPostagens Relacionadas:
Mas que diabos é uma classe? Assine o Feed Grupo Haw FeedBurner
]]>
Olá caros amigos leitores usuários do WINDOWS XP, venho em caráter urgente para dar uma explicação de como configurar variáveis de ambiente para rodar o Java no prompt do MS-DOS.
Sabe aquele probleminha quando você digita javac no DOS e ele não reconhece?? Esse é o primeiro obstáculo para o autodidata… e abaixo estará a fantástica e mágica solução em 10 passos…
1 – CLIQUE com o botão direito do mouse em “MEU COMPUTADOR”
2 – CLIQUE no item “PROPRIEDADES”
3 – CLIQUE na guia (aba) “AVANÇADO”
4 – CLIQUE no botão “VARIÁVEIS DE AMBIENTE”
5 – Na parte “Váriáveis de ambiente” procure a variável “JAVA_HOME”…se você não localizou crie clicando no botão “NOVA”
6 – Coloque o nome da variável com —> JAVA_HOME <— em maiúsculo e o valor da variável como C:\Arquivos de programas\Java\jdk1.6.0_11 ( é o caminho de onde está sua pasta “jdk1.6.0_11” que foi gerada quando você instalou o JDK, por padrão o caminho é este que acabei de informar)
7 – Conclua com um OK
8 – Localize a variável “Path” e informe ou simplesmente acrescente o seguinte valor no campo “valor da variável” — > %JAVA_HOME%\bin < —
9 – Conclua com um OK nesta janela e dê um outro OK na janela VARIÁVEIS DE AMBIENTE
10 –PÉÉÉÉÉÉÉÉNNNNN você acaba de concluir a configuração das variáveis de ambiente para utilização do Java no prompt do DOS…
Um abraço a todos vocês autodidatas e bons estudos!
Eduardo Gomes da Silva
Grupo HawPostagens Relacionadas:
Como Configurar Variáveis de Ambiente para Usar o Java? Assine o Feed Grupo Haw FeedBurner
]]>
Olá amigos leitores tentarei ser o mais breve e preciso no conceito orientação a objetos.
Pra que usamos orientação a objetos? Simplesmente para resolvermos problemas que tínhamos com a programação estruturada, como por exemplo, a dificuldade de realizar manutenções no código devido presença de um código macarrônico e de difícil compreensão de Ideia do programador.
Pensando nisso, foi criado este conceito de orientação de objetos, que nada mais é do que refletir a maneira de programar com a vida real, para isso basta abstrair idéias reais.>
Baseando-se nisso pensemos que tudo seja objeto, por exemplo carro, telefone, maça, cachorro, teste de inglês, batata, quadro… parece confuso mas observe, tudo que nós faz pensar em algo unitariamente isto chama-se objeto.
Vou citar um exemplo para prosseguirmos em todo o texto… bom pensemos que temos que criar um sistema em JAVA para construir de carros possantes… bem, eu ainda não sei onde você vai usar esse sistema, mas use a imaginação…. como devemos pensar para este caso???
Bom, pense na vida real…. vamos criar carros … carro para nós é um objeto… mas para este sistema não basta saber que carro é um objeto, precisamos saber o que estes carros contém…temos que definir o que compõe o carro, falamos que temos que definir os atributos que um carro pode ter.
Neste caso os itens que compõe o carro são: nome, marca, velocidade máxima, quantidade de marchas, aro do pneu e tamanho das asas…sempre sonhei em construir um carro que voa… mas é claro que dependendo do que você vá fazer essa idéia muda radicalmente.
E por fim falaremos o que um carro pode fazer.. acelera, freia, troca marcha, decola (você achou que as asas eram para quê?)e.. ..e… acho que só né ?
Tudo o que o carro pode fazer chama-se métodos
Vamos dar uma resumida, temos atributos e métodos definidos para construirmos carros… Repare que os atributos e métodos se referem a qualquer carro que nós queiramos criar..ou seja, é tudo genérico.
Temos que colocar os atributos e métodos num lugar que seja genérico também para podermos num futuro próximo criar um carro… chamamos esse lugar de classe
Na literatura você pode encontrar a definição de classe como: “classe é uma estrutura que abstrai um conjunto de objetos com características similares.”
Talvez esse conceito não tenha ficado muito claro, então dá uma conferida no post do Gabriel “Programação Orientada a Objetos”
Vamos visualizar isso em Java, abaixo estará uma classe com o nome Carro com os atributos e métodos que falamos até aqui:
class Carro{
String nome;
String marca;
int velocidadeMaxima;
int quantidadeDeMarchas;
int marchaAtual=0;
double velocidadeAtual=0;
boolean estaVoando;
void trocarMarcha(){
if (marchaAtual < this.quantidadeDeMarchas){
this.marchaAtual = this.marchaAtual + 1;
System.out.println("marcha = " + this.marchaAtual);
}else {
System.out.println("As marchas já estão no limiteee!!! uhuuuu");
}
}
void acelerar(){
if(this.velocidadeAtual<=this.velocidadeMaxima){
int velocidadePorMarcha = this.velocidadeMaxima / this.quantidadeDeMarchas;
this.velocidadeAtual = velocidadePorMarcha * this.marchaAtual;
System.out.println("VRUUMMM ... velocidade atual é: " + this.velocidadeAtual);
}else{
System.out.println("Não mais pra acelerar...aaaaa!!!");
}
}
void freiar(){
this.velocidadeAtual = 0;
System.out.println("RSSSSHHHHHHHH que freiada");
}
void decola(){
if(this.velocidadeAtual==this.velocidadeMaxima){
this.estaVoando = true;
System.out.println("UHUU DECOLAMOS.. iiii caramba não dá pra pousar..");
}else{
this.estaVoando = false;
System.out.println("Para decolar você deve atingir a velocidade máxima!!!");
}
}
}
Esta é a classe Carro da qual falei, claro que ela está super básica, faltou citar muitas outras coisas como por exemplo o encapsulamento, da qual postarei em breve..e também falta te explicar alguns detalhes do código…
Esta classe possui alguns problemas que ainda não conteplamos pois na segunda parte deste post continuarei este exemplo explicando o código, implementando-o e corrigindo-o…
Os componentes que compõe a orientação a objetos básica são:
Atributos, Métodos, Classes, Encapsulamento, Polimorfismo, Casting, Herança e Interface… vamos tentar usar todos estes no exemplo do carro, nós vimos somente os 3 primeiros…. acho que não eu pra explicar tudo em cinco minutos vou precisar de mais algum tempinho pra te explicar tudo sobre, ok..
Aaaaa já ia me esquecendo… para você testar esta maluquice aí… tem que criar uma outra classe que chamaremos de Teste.. (poderia ser qualquer nome)
class Teste() {
public static void main(String[] args) {
Carro carro1 = new Carro();
carro1.nome = "duds race";
carro1.marca= "edu company";
carro1.velocidadeMaxima=700;
carro1.quantidadeDeMarchas=5;
carro1.trocarMarcha();
carro1.acelerar();
carro1.acelerar();
carro1.decola();
carro1.trocarMarcha();
carro1.acelerar();
carro1.trocarMarcha();
carro1.acelerar();
carro1.trocarMarcha();
carro1.acelerar();
carro1.trocarMarcha();
carro1.acelerar();
carro1.trocarMarcha();
carro1.acelerar();
carro1.decola();
}
}
Teste como desejar… e analise o código para melhor compreensão…
Bons estudos galera!!!
Eduardo Gomes da Silva
Grupo Haw
Postagens Relacionadas:
Orientação a Objetos em Cinco Minutos Assine o Feed Grupo Haw FeedBurner
]]>
Bom, depois de algum tempo sem postar no Grupo Haw, cá estamos…
Já tivemos introdução à orientação a objetos, formas normais e convenções de código. Então nada mais justo que falarmos das variáveis do JAVA. Conhecer o que são e como são tratadas pelo compilador.
O que são variáveis?
São nada mais que espaços, de tamanho definido, alocados na memória no qual pode se armazenar um “valor” que pode ou não variar (variáveis, sacou?) no decorrer do seu programa. Ou como diz no Use a cabeça, uma xícara de diversas formas e tamanhos, um container para se guardar algo dentro.
Basicamente existem 2 tipos de variáveis no JAVA, as variáveis Primitivas, ou seja, que contêm valores básicos primitivos (int, short, long e etc..) e as variáveis de referência que guardam um endereço de memória para um objeto criado, ou seja, indicam através de um endereço de memória, onde está localizado o objeto.
Para declarar variáveis dos tipos primitivos devemos informar o tipo seguido do nome, podendo ainda atribuir (ou não) um valor no momento da declaração. O tamanho do espaço de memória alocado (reservado!?) para cada variável é definido no momento em que o tipo é declarado.
Ex.:
int x = 1;
ou
int x;
A declaração de variáveis segue alguns padrões estabelecidos pelo JavaDoc como informado no post “Convenções de Código” e também não permite o uso de palavras reservadas do Java.
Os tipos primitivos existentes no Java são:
|
boolean |
char |
byte |
short |
int |
long |
float |
double |
|
true ou false |
16 bits |
8 bits |
16 bits |
32 bits |
64 bits |
32 bits |
64 bits |
Uma forma de lembrá-los é criando uma frase com as iniciais:
B – C – B – S – I – L – F – D
Opa, espera aí… Está faltando algo nessa tabela de tipos primitivos, cadê o tipo String?
Não, não está faltando String nenhuma, uma String não é um tipo primitivo, em Java uma String é um objeto, que merece TAMBÉM (sim, acredite) um post só sobre isso, mas agora vamos voltar aos primitivos.
Aqui vai um exemplo do nosso co-piloto Gabriel para declarações:
class Primitivo {
public static void main(String args[]){
boolean flag = false;
char character = 'X';
char ascii = 65;
// pode receber valores da tabela ASCII (65 = A)
byte b = 10;
short pequeno = 100;
int contador = 0;
long derciGoncalves = 100000L; //o long deve terminar com L
float fatura = 100.9F; // o float deve terminar com F
double media = 75.5;
System.out.println(flag);
System.out.println(character);
System.out.println(ascii);
System.out.println(b);
System.out.println(pequeno);
System.out.println(contador);
System.out.println(derciGoncalves);
System.out.println(fatura);
System.out.println(media);
}
}
A saída será:
false
X
A
10
100
0
100000
100.9
75.5
Uma variável só pode receber valor de variáveis de tipos com tamanho menor que o tipo que ela foi declarada. Assim os valores sempre caberão. É isso que importa para o compilador, pois mesmo que você tenha um valor do tipo double que caiba dentro de um int ele não permitirá a atribuição, já que não conhece o valor que você vai inserir. Ele somente deixará se você informar que sabe o que está fazendo. Utilizando um “cast”, mas isso é assunto para mais adiante.
A declaração de variáveis de referência basicamente é a mesma coisa. Declara-se o tipo do Objeto a referenciar e o nome da variável (não necessariamente precisa criar o objeto no momento da declaração). A diferença é que o tamanho do espaço alocado para uma variável de referência é sempre fixo, porque se trata de um endereço de memória que mostra como chegar ao objeto que se refere.
Exemplo
class DeclaraVariavelReferencia {
public static void main(String args[]){
HotDog dogao;
dogao = new HotDog();
}
}
A variável de referência serve para guardar um endereço de um determinado objeto e acessar seus métodos (post, uno más). Para acessar os métodos utilizamos o nome da referência + “.” + método.
Exemplo:
dogao.montarDog();
Uma variável de referência somente aponta para UM objeto e duas variáveis de referência podem apontar para o mesmo objeto.
O Java possui restrições quanto a referenciar objetos iguais as do tipo primitivo. Por exemplo, uma variável referência do objeto Carro não poderá se referenciar a um objeto do tipo Caminhão. Somente fazendo o tal do “cast” como nas variáveis primitivas.
Então, eu vou ficando por aqui… tentei explicar de cabeça (menos os valores que não lembrava) e caso tenha esquecido de algo peço que complementem nos comentários para que eu estude também…
Valeu galera,
Hasta la vista.
Obs.: Não citei variáveis primitivas como variáveis de instância de tipo primitivo como em alguns livros para não confundir com as variáveis de referência.
Grupo HawPostagens Relacionadas:
]]>
Olá pessoal… Hoje estou aqui pra falar sobre as famosas interfaces Java!
Não interface gráfica (GUI, Swing e AWT), mas as classes 100% abstratas, que são declaradas com a palavra-chave interface.
Ainda me lembro do dia em que eu tive o meu primeiro contato com as interfaces (estudando). Eu tinha acabado de entender como funcionava a herança em Java… Tinha descoberto que boa parte dos meus problemas havia acabado naquele momento, afinal, eu tinha aprendido que poderia economizar centenas de linhas de código nos meus programinhas herdando tudo.
Aí veio a decepção, quando eu comecei a aprender sobre as interfaces… Eu descobri que o que eu estava fazendo era herdando por preguiça, e a herança não foi feita pra isso, a herança tem que fazer sentido. Mas, isso vai ficar pra outro post, porque o assunto de hoje é sobre a prova SCJP.
Vamos ao resumo para certificação…
Declaração de Interfaces
- Uma interface é como uma classe 100% abstrata;
- As interfaces são implicitamente abstract, colocar esse modificador é opcional;
- Uma interface só pode ser public ou default;
- Uma interface NÂO pode ter o modificador private ou protected;
- Uma interface pode estender várias interfaces (isso mesmo, a palavra usada é extends);
- Uma interface NÂO pode implementar outra interface ou classe (parece estranho, mas uma interface estende outras interfaces);
Classes que Implementam
- Uma classe concreta (não abstract) que implementa uma interface deve fornecer implementações para todos os seus métodos;
- Uma classe abstract quem implementa uma interface não é obrigada a implementar seus métodos, mas a primeira classe concreta da arvore de herança deve implementá-los;
- Uma classe que implementa uma interface não pode declarar nenhuma exceção nova, ou mais abrangente, mas pode declarar exceções de tempo de execução em qualquer método;
Regras dos Métodos
- Todos os métodos de uma interface são implicitamente public e abstract;
- E já que os métodos são abstract eles devem terminam com ponto-e-vírgula (;);
- Os métodos declarados em uma interface não podem ser static;
- Os métodos da interface não podem ser marcados com final, native, strictfp ou synchronized;
Regras das Variáveis (Constantes)
- Todas as variáveis de uma interface são public, static e final, sendo assim, todas as variáveis são constantes (toda constante deve ser inicializada);
- As declarações public, static e final são opcionais;
Como de costume, agora vamos a alguns exemplos em código:
Um ponto que pode confundir, é que uma interface estende outra, então a seguinte interface não é válida:
interface B implements A{
// Uma interface estende outra interface
}
interface C extends A, B{
//*Uma interface pode estender várias interfaces
}
Como dito anteriormente, todos os método de uma interface são public e abstract implicitamente, e colocar esses modificadores fica opcional.
Todo método que é declarado desse modo:
interface TesteInterface {
int getExemplo();
void setExemplo();
}
É lido pelo compilador assim:
interface TesteInterface {
public abstract int getExemplo();
public abstract void setExemplo();
}
Abaixo segue alguns exemplos de métodos que não são válidos:
int getExemplo(){
// O método deve terminar com ponto-e-vírgula
}
static int getExemplo(){
// O método não pode ser static
}
final int getExemplo(){
/* O método não pode ser final,
native, strictfp ou synchronized */
}
Todas as variáveis são constantes, então devem ser inicializadas na declaração:
interface A {
int TAMANHO; // Declaração inválida
double MEDIA = 1.5; // Declaração válida
}
Todas as variáveis são implicitamente marcadas como public, static e final, sendo assim a seguinte declaração:
int VALOR = 20;
É lido dessa maneira pelo compilador:
public static final int VALOR = 20;
Bom, os exemplos de códigos vão ficando por aqui (está tarde, eu tenho uma semana de prova, e tenho que estudar!!!)… rsrs
Esse é um tipo de assunto que vale apena entender, não só pra certificação, é importante saber como é sua utilização na prática, e qual o motivo que fez o Joshua Bloch escrever em algumas partes do seu livro Effective Java fases do tipo “Prefira composição ao invés de herança”, “Prefira interfaces a classes abstratas” e “Herança quebra o encapsulamento”.
Não é difícil entender como declarar e implementar interfaces, difícil é saber qual é a hora de utilizá-la, e em que a sua utilização vai implicar no programa.
Uma ótima explicação para a utilização de interfaces está no livro Use a Cabeça! Java, em que a resposta é simples e direta, “Polimorfismo, polimorfismo, polimorfismo… As interfaces são a última palavra em flexibilidade…”. Esse é um assunto que dever ser destrinchado além das explicações que são dadas no livro SCJP.
Com certeza as interfaces serão abordadas em outras postagens.
Até breve! ; )
Grupo HawPostagens Relacionadas:
- Método, Variável e Classe Final
- Palavras-Chave Java
- Identificadores Legais – Java
- Teste Unitário com JUnit – Rapidinho
- Certificado Java com o jeitinho brasileiro: Oracle Certified Java Programmer – OCJP/SCJP
Regras de Interfaces Java Assine o Feed Grupo Haw FeedBurner
]]>
Depois de um tempo sem postar nada no Grupo Haw por causa da faculdade (provas e trabalhos), eu decidi escrever sobre um assunto bem básico, que é Orientação a Objetos. Pelo que eu vejo é Orientação a Objetos uma das maiores dificuldades de quem está iniciando em Java.
Eu mesmo tive certa dificuldade em entender Orientação a Objetos, e na minha cabeça sempre apareciam perguntas do tipo:
- Pra que tantas classes?
- Por que eu não coloco todo o código na mesma classe?
- E essa lógica, eu tenho que usar três métodos pra fazer isso, mas eu poderia fazer em um método só.
Então eu resolvi escrever sobre orientação a objetos, um termo que antes de ser aprendido até parece um bicho de sete cabeças. Não que seja fácil, pois eu estou a cada dia aprendendo mais, e a cada artigo, blog e livro que eu leio, os conceitos vão se “clareando” mais na minha cabeça.
Mas, vamos ao que interessa…
O conceito de Programação Orientada a Objetos (POO) foi baseado na lógica da natureza, pois as coisas na natureza já existem por si só, muito antes de se pensar em computadores ou em sistemas. Na natureza não temos fatos isolados, as coisas interagem entre si, e todas essas coisas se comunicam através de mensagens.
A programação orientada a objetos tenta se aproximar ao máximo da natureza, trazendo o mundo real para os sistemas, onde tudo que na natureza nós chamamos de coisa passa a ser chamado de objetos. E é assim que chamaremos as coisas de agora em diante, tudo é objeto.
Todos os objetos (coisas na natureza) possuem características que os tornam únicos, e nos permite identificá-los. E é com essas características que vamos levá-los ao nosso sistema, tornando nosso programa mais parecido com o mundo real. Para exemplificar esse conceito vamos pensar em um veículo, como descreveríamos um veículo do mundo real?
O veículo é uma coisa que possui uma cor, uma marca, quantidade de portas, modelo, e assim por diante. E agora pensando nas coisas que um veículo faz, podemos dizer que um veículo acelera, freia e buzina.
E voltando a abordagem de programação orientada a objetos, no nosso sistema tudo que um veículo tem passa a ser chamado de atributos, e tudo que ele faz passa a ser chamado de métodos, assim essa coisa que no mundo real nós chamamos de veículo, será um objeto veículo, com atributos e propriedades:
Atributos:
- Cor
- Marca
- Quantidade de portas
- Modelo
Métodos:
- Acelerar
- Frear
- Buzinar
Pensando em um sistema para uma escola, podemos modelar uma sala de aula inteira de modo orientado a objetos, desse modo teríamos: O objeto professor, o objeto aluno, o objeto aula, objeto cadeira, assim por diante. E todos os objetos desse exemplo possuem características que nos permite identificá-los.
Existem ainda diversas vantagens na programação orientada a objetos que serão explicadas em outra postagem, como a herança, generalização, especialização, polimorfismo, etc. E outro conceito que será explicado em breve é o de classes.
Por enquanto é isso…
Grupo HawPostagens Relacionadas:
- Nenhuma postagem encontrada
Programação Orientada a Objetos Assine o Feed Grupo Haw FeedBurner
]]>
É com imenso prazer que me apresento neste blog, um pouco atrasado é claro.. mas prometo ser breve…Bom.. meu nome é Eduardo Gomes da Silva sou analista de sistemas (estagiário ainda…) e sou fascinado por programação… especficamente o Java, ainda sou um iniciante sonhador.. sim sonhador pois acho que temos que sonhar para poder visualizar nossos objetivos..e traçar nossas metas…
E como principal objetivo tenho as palavras: “aprender” “aprender” e “aprender”… Java principalmente e tudo quanto eu possa absorver.
Baseando nisso foi que então decidi participar deste blog com esses “caras” aííí.. pois seus pensamentos são muito semelhantes ao meu.. sem falar que são “gente boa pra caramba”.
Espero que as informações encontradas aqui possam de alguma forma agregar conhecimento pra todos nós leitores do grupo HAW…
Concluindo.. O grupo haw não é só meu… ele é de todos nós leitores, pois aprenderemos com ele, peço que você participe conosco para que este blog seja grande e repleto de informações úteis.
Eduardo Gomes
Grupo HawPostagens Relacionadas:
]]>
como ando meio desanimado… resolvi postar. O Gabriel já escreveu os tópicos do livro SCJP do qual eu havia feito resumo, então hoje vou tentar falar um pouco de Convenção de Código.
A pergunta quer não quer calar: Pra quê?
Bom imagine-se trabalhando em uma empresa no setor de folha de pagamento. Aquele sistema lindo escrito em COBOL cujo código tem no mínimo 5 mil linhas e que é responsável pelo pagamento de todos os funcionários da sua empresa.
Seu chefe te pede pra dar manutenção urgente, pois a data do pagamento está chegando. Pra piorar, você é novo na empresa e o código não foi escrito por você. A primeira coisa que você faz é xingar o programador de todos os nomes conhecidos.
Depois mais calmo você tenta entender o que ele faz e identificar o problema ou o local de uma possível mudança mas… é osso.
Indentação , variáveis, procedimentos, metódos, funções, classes e etc, tudo escrito de maneira que o programador dono do código bem entendeu. Ele poderia chamar a variável de Salário por “bufunfa“, “money“, “cascalho” ou coisas beeem piores (acredite, existem caras assim). A culpa é de quem escreveu? Em partes sim, mas se você tivesse escrito poderia sair a mesma coisa (desde que não conheça nenhum documento desses)., pois cada pessoa pensa de um jeito Por isso existem documentos de convenção de código e inúmeros livros de boas práticas de Programação. A Sun disponibiliza no seu site o documento do JAVA, ideal para quem deseja se tornar um bom programador. Então para quem num entendeu, aqui vão alguns motivos da convenção do código.
- Facilita o entendimento dos demais desenvolvedores
- Simplifica a manutenção em grandes sistemas, reduzindo o tempo gasto
- Diminui necessidade de uma documentação, se aplicados comentários aos códigos
- Minimiza erros bobos por nomeação de variáveis por exemplo
Então é isso…
Vou ficando por aqui com mais um tópico que me fez refletir sobre boas práticas de programação e como diria meu professor…
“Não escreva seu código para você e Deus, pois depois só Deus entende,”
Hasta la vista,
Postagens Relacionadas:
]]>
Tabela de Palavras-Chave Java
Bom pessoal, como anteriormente eu escrevi um resumo sobre os Identificadores Legais, eu acho que para complementar tudo que foi explicado é bom saber quais são as Palavras-Chave Java.
Como um identificador não pode ter o mesmo nome da uma Palavra-Chave Java, então está aí a tabela com as Palavras-Chave.
| abstract | assert | boolean | break | byte |
| case | catch | char | class | const |
| continue | default | do | double | else |
| enum | extends | final | finally | float |
| for | goto | if | implements | import |
| instanceof | int | interface | long | native |
| new | package | private | protected | public |
| return | short | static | strictfp | super |
| switch | synchronized | this | throw | throws |
| transient | try | void | volatile | while |
Sendo assim, esse exemplo abaixo não é válido:
int abstract = 10;
Repare que nome escolhido para o identificador (abstract) é a primeira Palavra-Chave da tabela, e por isso esse identificador não é válido.
A idéia e transformar cada palavra da tabela em um link, que irá para um tópico com sua explicação. Assim que os tópicos forem criados essa tabela vai ser atualizada (para links).
Por enquanto só isso…
Grupo HawPostagens Relacionadas:
]]>
Identificadores Legais Java
Hoje eu estou aqui pra falar dos Identificadores que são permitidos em Java, e os exemplos abaixo são para os nomes de variáveis. É importante entender quais são permitidos, pois violar a regra causará uma exceção.
Let’s go…
- Os identificados devem conter apenas caracteres Unicode, números, símbolos de moedas ($) e caracteres de conexão underscores (_).
- Os identificadores devem começar com uma letra, um cifrão ($) ou um underscore (_).
- O primeiro caractere de um identificador não pode ser um número.
- Após o primeiro caractere, os identificadores podem conter letras, números, cifrões ($) e caracteres de conexão (_).
- Os identificadores em Java são case-sensitive, sendo assim, nome é diferente de Nome.
- Um identificador não pode ser uma palavra-chave Java. (logo mais irá ter um post com a tabela de palavras reservadas Java).
Exemplos de identificadores Válidos:
int idade; double media_de_salario_do_departamento_de_compras_$; float ______valor___final; int $compras; int $_;
É claro que utilizar esses quatro últimos identificadores (normalmente) não faz muito sentido, mas é bom saber que eles são válidos.
Agora os próximos exemplos são de identificadores NãO válidos:
int :contador; float –numero; int 8oitavo; double .um_nome; int índice#;
Para explicar a parte em que está escrito que Java é case-sensitive, vai aí um programinha que mostra duas mensagens de boas vindas, sendo que um identificador será chamado de ola e outro será Ola.
public class Case {
public static void main(String args[]){
String ola = "Hello World!";
String Ola = "Olá Mundo!";
System.out.println(ola);
System.out.println(Ola);
}
}
Repare que ao compilar esse programa a saída será:
Hello World!
Olá Mundo!
Nesses exemplos tivemos algumas palavras novas (int, double e float) que são os Tipos Primitivos, e serão explicados em outro post.
Por enquanto é isso, até mais…
Grupo HawPostagens Relacionadas:
- Palavras-Chave Java
- Regras de Interfaces Java
- Teste Unitário com JUnit – Rapidinho
- Método, Variável e Classe Final
Identificadores Legais – Java Assine o Feed Grupo Haw FeedBurner
]]>
meu nome é Lucas Menezes, tenho 20 anos e atualmente estou cursando o último ano de Processamento de Dados na FATEC-BS. Pretendo, assim como meus camaradas, tentar tirar a certificação de JAVA SCJP e por isso decidi colaborar com o blog do Grupo Haw escrevendo artigos dos capítulos que estudar daqui pra frente.
Atualmente faço estágio em Análise de Sistemas, o que vem contribuindo muito para minha formação como profissional de TI. Espero com essa iniciativa poder ajudar quem ainda não tem vivência na área passando informações importantes e também absorver ao máximo o conteúdo estudado.
Espero que haja retorno dos tópicos que eu postar aqui até pra saber se esse é realmente o caminho das pedras. Como ainda tô começando acredito que não serão poucas às vezes que vou escrever besteira, mas é isso aê. Críticas (de leve?) serão muito bem-vindas, mais até que elogios pois ajudaria muito a saber o que melhorar nessa fase tão sofrida de aprendizado.
Bom, é nesse tom que eu me despeço de amigos, namorada e familiares pois a partir de agora a “xiripóca vai piá”…
hasta la vista,
Postagens Relacionadas:
]]>
Bom, como é minha primeiramente postagem eu vou começar me apresentando, e vou contar qual o motivo da criação desse blog…
Meu nome é Gabriel Marcos Santos Rubens tenho 20 anos e trabalho na área de Desenvolvimento de Sistemas, e atualmente sou estagiário. Tenho uma meta de tirar certificação SCJP (Sun Certified Java Programmer), mas a um bom tempo eu começo a estudar e paro. Então eu e mais dois companheiros de trabalho que também estão começando a estudar, decidimos criar esse blog para servir como mais uma ferramenta de apoio ao nosso aprendizado. Então está aqui, esse é o blog Grupo Haw, e esse nome… Nem adianta eu tentar explicar, pois esse nome surgiu de uma “Piada interna”, e ficou.
Apesar desse nome, o intuito do blog é muito sério, pois ao meu modo de estudar eu vou fazendo anotações que eu uso como referência para relembrar os assuntos, mas como os rascunhos sempre ficam espalhados, decidi usar esse blog como uma ferramenta em que eu possa escrever meus rascunhos, além de poder compartilhar e aprender com outras pessoas. Mas não é o meu intuito escrever artigos técnicos, tudo vai ficar de modo bem impessoal.
Então, de hoje em diante eu espero aprender muito com isso, vai ser uma experiência nova, pois eu sempre fiz minhas anotações de modo bem “pessoal” (que só eu entendo), mas vai ser um desafio aprender a escrever de modo explicativo, e de quebra ainda aprender Java.
Acho que já escrevi mais do que eu pretendia, e por enquanto é isso… A próxima postagem minha vai ser alguma coisa mais útil …
Até a próxima!
Grupo HawPostagens Relacionadas:
]]>