Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

quarta-feira, 5 de dezembro de 2012

Zappos: Satisfação garantida

Estudo de caso da Zappos.com, empresa conhecida por "entregar felicidade", examinando as práticas que Tony Hsieh e sua equipe utilizaram para sucesso.

quarta-feira, 28 de novembro de 2012

Acredite no impossível: Romero Rodrigues, fundador do Buscapé

Quando dizem que algo é impossível, Romero Rodrigues vai atrás de provar o contrário. O fundador do Buscapé conta nesse vídeo como se fortalecer para enfrentar os obstáculos no caminho. Nunca deixou de acreditar no modelo do Buscapé que, recentemente, foi envolvido em uma das maiores transações de negócios digitais da história do Brasil.

Inspire-se com seu Day1, uma grande dose de motivação para empreendedores.

Versão compacta (5 minutos):

Versão completa (25 minutos):

terça-feira, 27 de novembro de 2012

Técnicas de motivação de times em projetos Agile - Michel Goldenberg

Pessoal, fiz o curso de scrum master com o Michel e realmente a qualidade do treinamento foi excepcional.A experiência passada baseada nos projetos internacionais é o mais interessante ao meu ver.

Nesse vídeo, o assunto é "Técnicas de motivação de times em projetos Agile"

quarta-feira, 21 de novembro de 2012

YoLab s01e03 - 24/11/2012

Galera, há algum tempo começamos a reunir o pessoal de software para fazermos um micro-evento, onde três integrantes, da nossa própria comunidade, nos trás alguma novidade.

Sábado (24/11/2012), teremos nosso terceiro episódio e o convite fica a todos os interessados por desenvolvimento de software e áreas afins.

Nesse sábado teremos os seguintes palestrantes e temas:

Henrique Ribeiro: SignalR: Funcionalidades Web em tempo real;
Lauro Ojeda: Startup;
Guilherme Cardoso: OOmelete (OO, Clean Code, Testes);

Infos:  yodojo@googlegroups.com

quinta-feira, 15 de novembro de 2012

Software: Produto ou Serviço ?

Esse é o segundo vídeo da série Batata Quente de Software idealizada pelo Klaus Wuestefeld (@klauswuestefeld) que tem por objetivo a produção de vídeos de 2 minutos tratando de assuntos relacionados ao desenvolvimento de software e estrelados por profissionais de destaque a cada episódio.

Ao final de cada vídeo a batata quente é passada para o próximo: o autor desafia quem ele quiser a falar sobre algum assunto específico.

Neste vídeo Rodrigo Toledo fala sobre "Software: Produto ou Serviço?"



Mais infos:

terça-feira, 13 de novembro de 2012

2º Congresso Anual do Grupo de Profissionais de Tecnologia da Informação das Empresas do Mato Grosso




Programação

13:00 - Entrega dos crachás aos participantes
13:30 - Grupo de TI_MT - Abertura do Evento & Divulgação das Ações do Grupo
13:50 - Totvs - Cloud Computing
14:20 - TDS Tecnologia - SQL Server BI & Capacitação em TI
15:00 - Razões para Investir em Segurança da informação
15:50 - Intervalo para o café
16:10 - 3RM Technologies - Informações sob demanda Tecnoloiga, Simplicidade e Negócio
17:00 - Bamo IT Service & Networking - Cloud Privada - Servidores Blade Cisco e Virtualização de desktop via Citrix
17:50 - Prodama & Service TI - Smart Planet - Tecnologia para um Mundo Mais Inteligente
18:30 - Grupo de TI_MT - Encerramento
19:00 - Jantar de Confraternização

Informações: http://www.grupotimt.org

quarta-feira, 31 de outubro de 2012

Consumidor poderá exigir velocidade de internet contratada a partir de amanhã

Entram em vigor a partir desta quinta-feira as novas regras de qualidade da internet fixa no país estabelecidas pela Agência Nacional de Telecomunicações (Anatel). Os consumidores poderão exigir uma velocidade instantânea da internet, que não poderá ser menor do que 20% da contratada pelo usuário, em 95% das medições realizadas.

Até agora, as empresas não tinham nenhuma obrigação. Caso o usuário contratasse 1 mega de velocidade, não significava que ele realmente estava recebendo esta velocidade no seu computador.

No primeiro ano, a velocidade instantânea é de 20 %. Nos doze meses seguintes, será de 30% e, a partir de então, é de 40%.

As empresas também são obrigadas a ter uma velocidade média da banda larga fixa. Ela é o resultado da média de todas as medições realizadas no mês. A meta a partir de agora é de 60%, nos doze primeiros meses. A partir de novembro de 2013, será de 70% e, a partir de então, sempre de 80%.

As empresas tiveram um ano para adaptar os seus equipamentos as novas regras de qualidade da Anatel estabelecidas no Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia. Aquelas que não cumprirem as metas de qualidade poderão ser punidas pela agência.

Fonte: O Globo

Existe uma entidade oficial criada justamente para o acompanhamento da qualidade dos serviços de banda larga, é a EAQ.

A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento à Resolução Anatel n.º 574, de 28 de outubro de 2011, como parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à Internet em banda larga no Brasil.

No link abaixo você pode efetuar o teste de velocidade de sua banda larga:

Infelizmente o percentual entregue será apenas de 20% do contratado, depois 30% no segundo ano e 40% a partir disso. Eu discordo, se contrato um serviço e pago por ele, quero 100% do serviço prestado.

terça-feira, 23 de outubro de 2012

Palestra sobre Trac no Javac 2012

Pessoal, no último sábado, dia 20/10/2012, foi realizado o Javac 2012 na Univag.

 
Tive a oportunidade de falar um pouco sobre o Trac utilizado em conjunto com o SVN.


Segue a apresentação :



Infelizmente, a parte de demonstração vai ficar faltando, porém gostaria de deixar uma dica importante para quem se interessou pelo assunto, é o seguinte, existe um serviço on-line chamado Project Locker que permite a criação de uma conta gratuita para até 2 usuários e 200Mb de espaço para gerenciar infinitos projetos de software utilizando Trac com SVN ou Trac com Git.


Eu utilizo esse serviço já a alguns anos e recomendo.

Para aqueles que se interessaram, podem clicar aqui para se cadastrar gratuitamente para utilizar o serviço.


Em nome da organização, agradeço os quase 200 participantes que estiveram presentes e que contribuíram com uma quantidade significativa de alimentos que será doada para uma instituição de caridade.

 Em breve divulgarei aqui algumas apresentações das outras palestras do evento.


quarta-feira, 10 de outubro de 2012

Javac 2012 - Encontro de Desenvolvedores Java de MT

Será realizado no dia 20/10/2012 no Centro Universitário Univag em Várzea Grande o Javac 2012.

O evento já tradicional no estado de MT contará com várias palestras relacionadas ao mercado de desenvolvimento de software utilizando a linguagem de programação Java.

Estarei participando como palestrante com o seguinte tema: Gestão de configuração de Projetos Java com Trac e SVN

Conto com sua presença! ;)

Mais detalhes no cartaz abaixo.



Para se inscrever, clique aqui!

terça-feira, 2 de outubro de 2012

Integração Contínua

O texto abaixo é a uma tradução autorizada do artigo escrito pelo Martin Fowler. Para acessar a versão original em inglês, clique aqui . Caso você tenha sugestões para tornar a tradução melhor, compartilhe através da seção de comentários no final da página.

The text bellow is an authorized translation of the article written by Martin Fowler. To access the original english version, click here . If you have any suggestion to make the translation better, share it via comments section at the end of the page.

Construindo um componente usando Integração Continua

 Para mim, a forma mais fácil de explicar o que Integração Contínua (IC) é e como trabalha é mostrando um pequeno exemplo de como isso funciona com o desenvolvimento de uma pequena parte do sistema. Vamos assumir que eu tenho que fazer alguma coisa para uma parte do sistema, não importa realmente que tarefa é – por enquanto vou supor que isso é pequeno e que pode ser feito um poucas horas ( vamos explorar tarefas maiores e outros problemas mais tarde ). Começo pegando uma cópia atual do código fonte e colocando na minha máquina de desenvolvimento. Faço isso utilizando um sistema de controle de código para ter uma cópia de trabalho a partir do código principal.

O parágrafo acima irá fazer sentido para pessoas que usam sistema de controle de código, mas não será para aqueles que não usam. Então deixe-me explicar rapidamente: um sistema de controle de código mantém todo o código fonte de um projeto em um repositório. O estado atual do sistema geralmente é chamado de mainline( ou linha principal). Em qualquer momento um desenvolvedor pode fazer uma cópia da versão principal em sua máquina, e isso é chamado de check out. A cópia em uma máquina de um desenvolvedor é chamada de cópia de trabalho (na maior parte de tempo você estará atualizando sua cópia de trabalho junto a principal).

Agora eu pego minha cópia de trabalho e faço o que preciso para completar minha tarefa. Isso irá consistir em alterar o código de produção e também adicionar ou alterar os testes automatizados. Integração Contínua assume um alto nível de testes que são automatizados no software: uma facilidade que eu chamo de self-testing code ( ou código auto-testável). Frequentemente estes usam uma versão da popular framework de teste xUnit.

Um vez que eu terminei (e isso geralmente acontece em vários lugares quando eu estou trabalhando), eu faço uma build (ou desenvolvimento de uma versão) automatizada na minha máquina de desenvolvimento. Assim, o código fonte em minha cópia de trabalho é pego, compilado e transformado em um executável – e então é executado os testes automáticos. Somente se todas as builds e testes não tiverem erros que tudo será considerado bom.

Com uma boa build, eu posso então pensar em colocar minhas alterações no repositório. A questão é, claro, que outras pessoas podem fazer (e geralmente fazem) mudanças na versão principal antes de eu ter a chance de fazer um commit ( ou atualizar o repositório principal com a minha versão do código). Sendo assim, primeiro eu atualizo minha cópia de trabalho com as mudanças feitas pelos outros e crio uma nova build. Se as mudanças deles chocarem com as minhas mudanças, será exibido erros tanto na compilação quanto nos testes. Neste caso é minha a responsabilidade de corrigir estes erros e repetir o processo até que minha cópia local esteja sincronizada com a versão principal.

Uma vez que tenho as alterações na minha própria build de uma cópia devidamente sincronizada eu posso finalmente fazer o commit na versão principal, que atualiza o repositório. Entretanto meu commit não termina meu trabalho. Nós fazemos uma build novamente, mas agora em uma maquina de integração baseada na versão principal do código. Somente com o sucesso desta build poderemos dizer que as minhas alterações foram feitas. Sempre existe uma chance de eu ter esquecido alguma coisa na minha máquina e o repositório não ser atualizado corretamente. Somente quando minha build de alterações for lançada com sucesso na máquina de integração é que o meu trabalho terminou. A build de integração pode ser executada manualmente por mim ou ser feita automaticamente usando o Cruise.

Se um choque ocorrer entre as versões de dois desenvolvedores, isso geralmente é pego quando o segundo desenvolvedor atualizar sua cópia local com as builds feitas pelos outros. Caso não, a build de integração deve falhar. De qualquer modo o erro é detectado rapidamente. Nesse momento a tarefa mais importante é consertar os problemas, e fazer sua build voltar a funcionar corretamente. Em um ambiente de Integração Contínua você nunca deve ter uma build de integração com falhas por muito tempo. Um bom time deve ter muitas builds corretas por dia. Más builds podem ocorrer de tempos em tempos, mas devem ser consertadas rapidamente.

terça-feira, 18 de setembro de 2012

Tutoriais de Maven

O site Avajava é uma ótima biblioteca para quem trabalha com desenvolvimento utilizando Java.

Confira abaixo uma lista de vários tutoriais abordando o Maven.

Maven Tutorials


Apache Maven is a popular project management tool for Java projects. Maven can simplify and standardize the project build process. Maven is a complex tool, and these tutorials are meant to help describe some of the common tasks that developers may run into while working with Maven.
  1. What is Maven and how do I install it?
  2. How do I configure Maven for a user rather than globally?
  3. How do I link to my settings.xml file from Eclipse?
  4. How do I set the location of my local Maven repository?
  5. How do I create a simple project using Maven?
  6. How do I perform an archetype:create from Eclipse?
  7. How do I import a Maven project into Eclipse?
  8. How do I update my Maven project to work in Eclipse?
  9. How do I execute tests on my project?
  10. How do I build my project?
  11. How do I install a project artifact in my local maven repository?
  12. How do I use a mirror of the maven central repository?
  13. How do I use the maven clean phase?
  14. How do I generate basic documentation for a project using maven site?
  15. How do I create a web application project using maven?
  16. How do I create a maven web application project from Eclipse?
  17. How do I update my classpath with an Eclipse User Library via the maven eclipse plugin?
  18. How do I run a maven web application in Tomcat from Eclipse?
  19. How do I package a basic maven web application?
  20. How do I deploy a maven web application to Tomcat?
  21. How do I redeploy a maven web application to Tomcat?
  22. How do I compile a maven project to a particular version of Java?
  23. How do I undeploy a maven web application from Tomcat?
  24. What is Archiva and how do I install it?
  25. How do I use Archiva as a mirror of the maven central repository?
  26. How do I precompile my jsps?
  27. How do I precompile my JSTL jsps?
  28. How do I deploy an artifact to an Archiva repository?
  29. How do I list the goals of a maven plugin?
  30. How do I list the goals and goal parameters of a maven plugin?
  31. How do I display the effective settings of a project?
  32. How do I display the effective pom of a project?
  33. What is the XSD for a settings.xml file?
  34. How do I display the active profiles?
  35. How do I list the parameters of a goal?
  36. How do I activate a profile based on a particular version of java?
  37. How do I activate a profile?
  38. How do I display an environment variable?
  39. How do I display the value of a settings.xml element?
  40. How do I display the value of a pom.xml element?
  41. How do I display the value of a property?
  42. How do I add a project as a dependency of another project?
  43. How do I add a transitive dependency to my project's classpath?
  44. How do I create a string substitution variable for maven in Eclipse?
  45. How do I create a multi-module project in Eclipse?
  46. How do I manage the version of a dependency in a parent POM?
  47. What are the phases of the maven clean lifecycle?
  48. What are the phases of the maven default lifecycle?
  49. How do I deploy a site?
  50. What are the phases of the maven site lifecycle?
  51. Where do I put resources in my maven project?
  52. How do I add my own manifest file to a jar file?
  53. How do I specify a main class in the manifest of my generated jar file?
  54. How do I filter resource files to include the values of properties?
  55. How do I filter resources based on values from a properties file?
  56. Where are the three places that I can specify profiles?
  57. How do I activate a profile based on the presence of a property?
  58. How do I activate a profile based on the value of a property?
  59. How do I add a simple site to a project using the archetype plugin?
  60. How do I add a site to a project using the archetype plugin?
  61. How do I create a maven plugin project using the archetype plugin?
  62. How do I create a hello world goal for a maven plugin?
  63. How do I execute a maven goal I've written using shorthand?
  64. How do I deploy a plugin to an Archiva repository?
  65. How do I download a plugin from a remote Archiva repository?
  66. How do I attach a plugin goal to a particular phase of a maven lifecycle?
  67. How do I specify the phase of a lifecycle in a Mojo?
  68. How do I exclude particular resources from being processed?
  69. How do I skip the tests during the default lifecycle?
  70. How do I generate and deploy a source jar file for my project?
  71. How do I generate and deploy a javadoc jar file for my project?
  72. How do I build a jar file that contains its dependencies?
  73. How do I create an archetype?
  74. How do I create a project with an archetype I've created?
  75. How do I create an archetype that can run on an existing project?
  76. How do I generate Maven Changelog Plugin reports for a site?
  77. How do I generate a javadoc report for a site?
  78. How do I generate a JXR report for a site?
  79. How do I generate a unit test report for a site?
  80. How do I generate a Checkstyle code style report for a site?
  81. How do I generate a StatSCM report for a site?
  82. How do I generate PMD and CPD reports for a site?
  83. How do I generate a Cobertura test coverage report for a site?
  84. How do I generate a FindBugs bug pattern report for a site?
  85. What is Continuum and how do I install it?
  86. How do I add a maven project to Continuum?
  87. How do I schedule how often Continuum attempts to build a project?
  88. How do I decompile Java classes in the maven central repository?

terça-feira, 11 de setembro de 2012

Artigo na Java Magazine 107: Gerência de Projetos - Otimize sua vida com Trac e SVN

Pessoal, saiu o meu artigo na Java Magazine 107 agora no início de Setembro.

Tive a honra de estrear com um artigo de capa sobre a gestão de configuração e mudanças de projetos de software.

No artigo falo sobre o TRAC, uma ferramenta simples e leve para o gerenciamento de projetos, de interface web e escrita em Python. São apresentados os passos necessários para sua instalação, configuração e integração com o controlador de versões SVN.

Outra característica importante demonstrada é a possibilidade de estender suas funcionalidades com a adição de plugins, e são listados alguns de grande utilidade.

É apresentada também a utilização dessa ferramenta em um projeto Java, integrada diretamente ao Eclipse, fazendo uso de marcações wiki nas descrições de atividades e nas mensagens de commit do SVN, onde são criados automaticamente links e referências entre tickets (atividades), changesets (conjuntos de alterações no SVN), arquivos e páginas wiki.

São apresentadas também as opções de como consultar todos os eventos do projeto de forma ordenada em uma linha do tempo, e em relatórios personalizáveis, possibilitando assim acompanhar o progresso do projeto facilmente.


Mais infos:
- Edição 107 Java Magazine
- Artigo no site DevMedia

Outro artigo já está em andamento, será publicado em uma das próximas edições. Por hora, boa leitura e obrigado a todos pelo apoio!

As 10 causas mais comuns para o fracasso

Excelente post do blog Saia do Lugar sobre as maiores causas do fracasso e como evitar comportamentos que tendem ao insucesso.


Muitas pessoas estudam o sucesso, mas não tantas estudam o fracasso.
Fazê-lo é uma das maneiras mais pertinentes de se obter aprendizado contundente que crie anticorpos que o ajudarão a se proteger da vontade de manter comportamentos que, com frequência, levam ao fracasso.
Como já sabemos, é mais inteligente atuar na causa, do que no efeito.
Jornada empreendedora
Algumas vezes você já chegou longe demais para fracassar

Confira abaixo algumas das causas mais comuns do fracasso e aja sobre elas.

1ª Causa do Fracasso: O velho truque de pôr a culpa nos outros
Você é daqueles que tem sempre um belo discurso para se esquivar? Cuidado.
2ª Causa do Fracasso – O oposto da 1ª. A tendência imediata a se culpar e se rebaixar
A auto piedade gera auto censura que gera auto desprezo
3ª Causa do Fracasso – Não ter objetivos
A pergunta é: quando começaremos a viver como se compreendêssemos a urgência da vida?
4ª Causa do Fracasso – Escolher objetivos errados
Fazê-lo, é dedicar esforços e orientar toda sua vida em função de algo que não o realizará.
5ª Causa do Fracasso – O Atalho
São muitas as formas de ceder a tentação e seguir pelo caminho aparentemente + fácil e não fazer o necessário
6ª Causa do Fracasso – Escolher uma estrada longa demais
Não ver a linha de chegada pode desanimar e cansar, por isso planeje a rota antes.
7ª Causa do Fracasso – Negligenciar pequenas coisas
A falta de atenção aos detalhes põe abaixo grandes obras.
8ª Causa do Fracasso – Desistir cedo demais
Os homens não falham, eles desistem de tentar. Não pare em qualquer topada.
9ª Causa do Fracasso – O fardo do passado
As crenças e padrões do passado continuarão cobrando o preço caso você não se resolva.
10ª Causa do Fracasso – A ilusão do sucesso
O momento + perigoso vem com a vitória. Com ela vem a negligência e falta de concentração fatais.

Scher Soares é um autor convidado do Saia do Lugar e um dos empreendedores por trás do Grupo Triunfo.

Nota do editor: Apesar de ser sempre bom evitar o fracasso, vale a pena lembrar que ele faz parte da jornada rumo ao sucesso. Veja mais sobre como aproveitar seus aprendizados no vídeo: Se você nunca falhou, você nunca viveu.

domingo, 19 de agosto de 2012

Lançada versão Release Candidate do PrimeFaces 3.4

Foi lançada recentemente a versão Release Candidate do PrimeFaces 3.4, com vários componentes inovadores como Mindmap por exemplo, que permite a criação de mapas mentais dinamicamente.

Realmente o PrimeFaces vem se dispontando entre as implementações da especificação JSF, e vale a pena dar uma conferida.

Outra iniciativa que achei bem legal foi o trailler que fizeram dessa nova versão, confiram:


PrimeFaces 3.4 Trailer from cagataycivici on Vimeo.

Mais informações:

Site PrimeFaces - http://www.primefaces.org
RoadMap - http://code.google.com/p/primefaces/wiki/Roadmap


Obs. E dá-le Bootstrap no novo site do PrimeFaces!

sexta-feira, 10 de agosto de 2012

RichFaces Bootstrap

Ótima notícia: Uma nova versão do RichFaces está no forno, e vai utilizar o Twitter BootStrap como biblioteca de componentes.

O projeto já está bem avançado conforme o engenheiro da JBoss Brian Leathem divulgou em seu blog:

I’m happy to share the news that the RichFaces community has started an effort to wrap Twitter Bootstrap with the RichFaces CDK. If you haven’t yet heard, Twitter’s Bootstrap project is a set of HTML/CSS/js “widgets” that you can use for building a website/web application with an emphasis on a fluid layouts that adapt well to mobile devices. The RichFaces community effort centres around providing a set of first-class JSF components built using these Bootstrap widgets via the RichFaces CDK.
O legal disso tudo é que tanto o Twitter BootStrap quando o RichFaces BootStrap estão disponíveis no GitHub.

Alguns exemplos:

b:buttonDropdown

The buttonDropdown can be used to provide alternate actions for a button on your page:

b:gridContainer

The bootstrap grid components (gridContainer/gridRow/gridColumn) provide a powerful means to layout your page. Being proper JSF components, they are also valid JSF execute/render targets.


Mais informações:

- Site Twitter BootStrap http://twitter.github.com/bootstrap
- Código Fonte https://github.com/twitter/bootstrap

- Site RichFaces BootStrap http://bootstrap-richfaces.rhcloud.com
- Código Fonte https://github.com/richfaces/sandbox

- Blog Brian Leathem http://www.bleathem.ca

quinta-feira, 9 de agosto de 2012

Tutorial simples parte 2: git branch e merge

Esse tutorial faz parte de uma série de 3 artigos que explicam a utilização do Git e foi escrito e publicado pelo Codexico no blog codexico.com.br o qual detém todos os méritos pelo conteúdo de extrema qualidade e utilidade.

A parte 1 (Como usar o git e o github) foi sobre instalar o git, ssh-key, criar um projeto no github e os commits básicos.

Em projetos super simples tudo bem, mas para qualquer coisa maiorzinha já é melhor usar branchs, é fácil também, nem tirei o simples do título do post.

Vou abordar os branchs de forma educacional, como se fosse um projeto de uma só pessoa. A parte 3 trará uma visão mais prática, com um fluxo de trabalho completo e voltado para equipes, graças ao git ainda será simples.

Será usado o mesmo repositório da parte 1.

Branch

Para criar um branch no diretório do projeto:

1

$ git branch parte2

Atenção, somente foi criado o branch, o git não mudou para ele, qualquer alteração ou commit será feito no master. O git mostra onde está:

1
2
3

$ git branch
* master
  parte2

Para mudar para o branch é necessário um checkout:

1
2

$ git checkout parte2
Switched to branch 'parte2'

Os dois passos podem ser substituídos por um só (mas é sempre bom saber de onde veio):

1

git checkout -b parte2

Agora sim as modificações serão feitas no branch correto. Que tal criar um diretório, uns arquivos e também alterar o README da parte 1?

1
2
3
4
5
6

mkdir parte2
touch parte2/testeparte2
git add .
git commit -m "arquivo para testes da parte2"
vim README
git commit -a -m "README parte2"

Foram criados dois commits, ambos no branch parte2, um push agora não irá alterar nada no repositório.

Merge

Para enviar as modificações é necessário primeiro um checkout para voltar ao master, depois o merge com o branch e então o push.

Dica: TAB autocompleta os comandos e também os nomes dos branchs.

1
2
3

git checkout master
git merge parte2
git push origin master

Foi enviado o código mas o github não percebeu que havia um branch pois o branch está somente na máquina local, para enviar o branch ao repositório o push muda um pouco:

1

git push origin parte2:parte2

O formato é o seguinte git push repositorioRemoto nomeLocalDoBranch:nomeRemotoDoBranch, assim dá para enviar com um nome diferente se quiser.

1
2
3
4

git checkout parte2
vim parte2/testeparte2
git commit -a -m "texto teste"
git push origin parte2:parte2

Agora sim dá para ver que existe um branch, olha lá https://github.com/codexico/tutorial-github/network

Quando não for mais usá-lo, o branch pode ser deletado com:

1

git branch -d nome-do-branch

Legal, já deu pra perceber que dá por exemplo para trabalhar em uma nova funcionalidade do projeto sem alterar o código principal. Quando tudo estiver pronto, os testes passaram e tal, pode ser feito o merge e só então enviar para o repositório.

Pronto, acabou o básico sobre branch e merge com git.

Branch e Merge exemplo 2

Até agora foi muito básico, normalmente enquanto se está trabalhando num branch aparece um bug para ser arrumado no master, ou outro branch também está sendo trabalhado, ou seu sistema de desenvolvimento é dividido em produção, desenvolvimento, homologação e outros, são muitas possibilidades, cada lugar trabalha de uma maneira. Na parte 3 terá mais sobre isso.

Agora um exemplo um pouquinho mais trabalhado:

1
2
3
4
5
6
7

git checkout -b funcionalidadeX
touch funcionalidadeX
git add .
git commit -m "funcionalidadeX iniciada"
vim funcionalidadeX
git add .
git commit -m "funcionalidadeX parcialmente executada"

Foi iniciado um branch para a funcionalidadeX e depois de alguns commits ela ainda não está finalizada.

Então apareceu um bug no master que precisa ser corrigido rapidamente (colocar o link da parte2 antes do texto da parte2 do README, urgente né, o usuário é fogo).

1
2
3
4
5
6

git checkout -b bug42
vim README
git commit -a -m "bug 42 corrigido"
git checkout master
git merge --no-ff bug42
git branch -d bug42

Foi criado um branch para o bug, o bug foi corrigido, voltou ao master, foi dado um merge para incluir as alterações no master e então o branch foi deletado. A opção –no-ff é utilizada para forçar a criação de um commit, sem ela o merge não cria commit e fica mais difícil recuperar o código anterior.

Agora é só completar a funcionalidade X.

1
2
3
4
5
6
7

git checkout funcionalidadeX
vim funcionalidadeX
git commit -a -m "funcionalidadeX finalizada"
vim README
git commit -a -m "README atualizado com a funcionalidadeX"
git checkout master
git merge --no-ff funcionalidadeX

Correu tudo bem? Pode ser que sim, o github vai fundir o código da funcionalidadeX com o master, que já contém a correção do bug. Mas e se a correção conflita com as alterações da funcionalidade X? Neste caso o git mostra um alerta e não permite o merge, mas mostra os conflitos:

1

git status

Os conflitos precisam ser corrigidos manualmente e então o merge será aceito. O git inclui marcações no código dos arquivos em conflito para ajudar na resolução do conflito.

Com um fluxo de trabalho melhorzinho dá para evitar muitos conflitos, logo mais na Parte 3 do tutorial…

No final os merges ficaram assim:
 

Para finalizar uma tag:

1
2

git tag -a v2.0 -m 'parte 2'
git push origin v2.0

Referências:

Pro Git – Basic Branching and Merging
github – Working with remotes
nvie.com – A successful Git branching model

Fonte: http://codexico.com.br/blog/linux/tutorial-simples-parte-2-git-branch-e-merge/

Tutorial simples: Como usar o git e o github

Esse tutorial faz parte de uma série de 3 artigos que explicam a utilização do Git e foi escrito e publicado pelo Codexico no blog codexico.com.br o qual detém todos os méritos pelo conteúdo de extrema qualidade e utilidade.

Ultimamente estou envolvido em vários projetos ao mesmo tempo com várias equipes diferentes, então controle de versão é essencial.

Segue um manualzinho básico para iniciar com o git, espero atualizar e complementar este passo-a-passo com mais exemplos logo.

O git serve para versionamento local, você pode compartilhar de algumas maneiras, a mais fácil é com serviços online. Neste exemplo vou usar o github, testei também o projectlocker, que dá repositórios private grátis,  mas não gostei. Outro que parece legal é o Codaset, ainda não testei.

1) Instalar git

1

$ sudo apt-get install git-core

É necessário gerar uma chave ssh e fazer um cadastro em algum repositório git. ( Esta etapa não é exatamente sobre o git, mas sobre a segurança dos repositórios. )

Confira se vc já tem alguma chave com um "ls ~/.ssh/", se já existir uma você pode utilizá-la ou gerar uma nova:

1

ssh-keygen -t rsa -C "comment"

"comment" é só um lembrete para saber do que se trata a chave, normalmente usa-se o seu nome de usuário do serviço que vai usar, por exemplo o github.

Falando nisso, está na hora de criar um usuário lá (http://github.com), vai lá que eu espero…

Depois de logado vá para https://github.com/account e clique em "SSH Public Keys" e "add another public key". A cópia da chave precisa ser exata(eu ia escrever que 'precisa ser precisa' mas é feio né), então pode-se fazer assim:

1
2

sudo apt-get install xclip
cat ~/.ssh/id_rsa.pub | xclip -sel clip

Aí é só colar com um Ctrl+V normal. Agora já dá para se comunicar com o github:

1

ssh git@github.com

Vai aparecer "ERROR: Hi codexico! You've successfully authenticated, but GitHub does not provide shell access", não se assuste com o ERROR, o que interessa é que o github te reconheceu. Qualquer duvida tem o help do github: Generating SSH keys (Linux).

Por padrão o git vai pegar o usuário do sistema, para que seu nome de usuário do github apareça corretamente use os comandos:

1
2

git config --global user.name "Your Name"
git config --global user.email codexico@gmail.com

2) Criar Projeto no github

1) Podemos criar um novo projeto ou usar um existente. Para criar um novo vá até o github e no alto da página clique em "Dashboard" e depois em "New Repository".

Crie um espaço para o projeto no comnputador:

1
2

$ mkdir nomedoprojeto
$ cd nomedodiretorio

2) Iniciar um git neste diretório:

1

$ git init

Saída do comando:

1

Initialized empty Git repository in /nomedodiretorio/.git/

Deve aparecer um diretorio oculto .git, neste .git ficam as configurações que serão usadas para este projeto.

Por exemplo:

1
2
3

$ ls .git
branches config description FETCH_HEAD HEAD hooks index info logs
objects refs

3) Adicionar o repositório, neste exemplo vou usar um que criei para este tutorial, pode ser também o repositório criado no passo 1, o endereço fica na página do projeto (neste caso https://github.com/codexico/tutorial-github):

1

$ git remote add origin git@github.com:codexico/tutorial-github.git

Formato do comando:

"git remote add" adiciona um repositório ao git que foi iniciado neste diretório, "origin" é o apelido para o projeto, "git@github.com:codexico/tutorial-github.git" é o endereço do projeto.

Resultado:(apareceu a parte [remote "origin"])

1
2
3
4
5
6
7
8
9

$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:codexico/tutorial-github.git
fetch = +refs/heads/*:refs/remotes/origin/*

4) Baixar(pull=puxar) o projeto:

1

$ git pull origin master

Formato do comando:

1

git pull apelidoDaOrigem apelidoParaDestino

Saída do comando:

1
2
3
4
5
6
7

remote: Counting objects: 52278, done.
remote: Compressing objects: 100% (10917/10917), done.
remote: Total 52278 (delta 40975), reused 51715 (delta 40669)
Receiving objects: 100% (52278/52278), 8.33 MiB | 189 KiB/s, done.
Resolving deltas: 100% (40975/40975), done.
From git@github.com:codexico/tutorial-github.git
* branch  master -> FETCH_HEAD

3) Usar o git

Exemplo (escolha um nome diferente para o arquivo teste):

1

$ touch testegit

1) Adicionar as alterações:

- Podemos adicionar somente uma alteração:

1

$ git add testegit

- Ou adicionar todas as alterações:

1

$ git add .

Neste passo as alterações ainda não estão sob o controle de versão, elas somente foram adicionadas para quando der um commit.

2) Comitar as alterações:

1

$ git commit -m "mensagem teste para o tutorial"

É obrigatório acrescentar uma mensagem.

Saída do comando:

1
2
3

[master de2f5ce] teste para o tutorial
    1 files changed, 1 insertions(+), 0 deletions(-)
    create mode 100644 testegit

Agora as alterações foram adicionadas ao controle de versão. Mas ainda estão somente na máquina local.

3) Enviar(push=empurrar) as alterações:

1

$ git push origin master

Saída do comando:

1
2
3
4
5
6
7

Counting objects: 4, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 288 bytes, done.
    Total 3 (delta 1), reused 0 (delta 0)
    To git@github.com:codexico/tutorial-github.git
    3be4c21..de2f5ce  master -> master

Se durante o tempo em que fez o pull e o push outra pessoa que também participe do projeto fez alterações o push será rejeitado. Então é necessário atualizar o projeto local antes de enviar novas alterações.

1

$ git fetch origin

Atualizar antes de enviar é uma boa prática a ser seguida para quem usa svn ou cvs e é obrigatória no git.

4)Pronto, confira as alterações no navegador acessando o endereço do projeto (http://github.com/codexico/tutorial-github neste exemplo).

Dica final: para que não precise digitar sempre a senha do ssh siga os passos desse link: http://help.github.com/working-with-key-passphrases/

Atualizado em 09/09/2010, mudei o repositório e adicionei instruções para gerar a chave ssh.

Fonte: http://codexico.com.br/blog/linux/tutorial-simples-como-usar-o-git-e-o-github/

terça-feira, 7 de agosto de 2012

10 ações para ter sucesso na adoção do Agile

Matéria interessante sobre o processo de adoção do Agile escrito por Allan Kelly no blog Target Trust

Ken Schwaber teria dito que apenas 30% das equipes que utilizam Scrum são bem sucedidas. Ken, em seu blog, afirma não se lembrar dessa afirmação; ele indica que apenas 30% se tornarão “excelentes equipes de desenvolvimento”.

Scrum em Porto Alegre

A afirmação de Schwaber está alinhada com vários estudos sobre a gerência de mudanças. Especialistas no assunto, tais como o professor de Harvard, John Kotter, afirmam que 70% dos grandes esforços de mudança organizacional irão falhar. Independentemente da perspectiva pela qual se olha para os estudos, o prognóstico não é positivo. Então, o que podemos fazer para garantir que estaremos entre os 30% que obtêm sucesso?

Aqui listo dez sugestões. A lista poderia ter um maior número de itens, mas esses dez me pareceram mais significativos que quaisquer outros. Já retirar algum reduziria muito a efetividade da lista. Aqui vai!

1) Utilize um quadro físico

Estou convencido de que a maior diferença entre as equipes que adotam o Agile com sucesso e as que falham (ou que ficam “travadas”) está na utilização de um quadro físico. Apesar de algumas equipes estarem distribuídas geograficamente e de existir tecnologia razoável para substituir o quadro físico por um virtual, mantenho a recomendação. Se for possível afixar um quadro em algum lugar onde muitos, senão todos, possam vê-lo, as chances de sucesso serão bem maiores.

É difícil explicar todas as razões para utilizar um quadro físico; é preciso experimentar e testemunhar seus efeitos. Parece ocorrer alguma espécie de mágica quando o mundo abstrato do software entra em contato com o mundo físico dos cartões e do quadro.

Visualizar o trabalho é apenas o começo: é importante aprender a interpretar o que o quadro está dizendo e a agir de acordo com isso.

2) Comece a coletar e usar métricas e estatísticas

Métricas, como velocidade, burn-down, defeitos identificados, defeitos registrados em log etc. não têm boa fama no desenvolvimento de software – por razões justas, em muitos casos. Mas não significa que não sejam úteis; apenas que têm sido vítimas de má escolhas ou de coletas mal feitas.

No mínimo, meça a velocidade da equipe e crie o gráfico de burn-down, ou um diagrama de fluxo cumulativo de trabalho (cumulative flow).

A beleza de trabalhar com Agile é que é bem fácil levantar algumas métricas simples. Quando as métricas se tornam complicadas, as pessoas não as entendem e é mais difícil aprender com elas. Da mesma forma que acontece com os quadros para visualização do trabalho, as métricas têm utilidade intrínseca, mas são muito mais úteis como ferramenta de aprendizado.

3) Envolva um coach/consultor

É possível adotar o Agile sem ajuda de terceiros; livros podem ser lidos, experimentações feitas e cursos realizados. Mas a falta de ajuda faz todo o processo ser mais lento e corre-se mais risco de ficar fora dos 30% de sucesso. Além disso, a adoção levará mais tempo, o que aumenta ainda mais o risco.

Não há grandes distinções, na minha opinião, entre um coach e um consultor ágil. Assim, independentemente de qual papel se escolha, o que se quer é alguém que seja capaz de:

  • Observar, examinar, interrogar e desafiar os conceitos sobre o que está sendo feito;
  • Oferecer ajuda em quais práticas e processos adotar e sobre a melhor forma de adotá-los;
  • Oferecer exemplos do que viram funcionar ou não em outros lugares, e como outras equipes atacaram problemas similares.

Pode ser necessário trabalhar com mais de um consultor/coach, pois poucos serão capazes de conhecer todos os processos, práticas, tecnologias, produtos e estratégias. Uma opção é ter um consultor/coach com dedicação integral, mas o modelo com o qual obtive mais sucesso foi o de ter o aconselhamento leve, juntamente com um sistema de mudanças “puxadas” (veja mais abaixo).

Apesar de não haver necessidade de um consultor/coach dedicado, deve haver um acompanhamento contínuo. Tenho praticado e escrito sobre o coaching ágil leve; seguindo este modelo procuro voltar às empresas em intervalos de aproximadamente um mês, para continuar o acompanhamento.

4) Ações no lugar de palavras

Ações valem bem mais que palavras. Não se pode prever os problemas e questões que vão emergir até que se comece a utilizar o Agile de fato. Falar sem agir gera mais expectativas, aumentando cada vez mais o risco de que o Agile pareça apenas outra moda passageira de gestão.

Fale sobre o Agile, planeje-se, mas não deixe de mergulhar na ação, pois não há substituto para isso. Aprenda com suas ações e melhore; refine. Utilize algumas métricas que possam indicar o que está acontecendo.

Em especial, não gaste muito tempo decidindo se é melhor utilizar XP, Scrum, Lean, FDD, DSDM ou Kanban. Todos são similares, e no final você acabará montando sua própria versão híbrida, de uma forma ou de outra.

5) Treine a todos e realize discussões envolvendo todo o grupo

As equipes não se tornam ágeis por decreto da gestão, apesar de ter havido várias tentativas nesse sentido. A leitura de livros funciona para alguns, mas a maioria dos livros permanece não lida ou simplesmente não é absorvida.

Explique para as pessoas o que é o Agile – ou pelo menos o que significa para a organização. É quase impossível achar alguém da área técnica que não tenha ouvido falar de Agile; mas o que cada um sabe, as partes que se lembram, são diferentes. É importante que todos partam de um entendimento comum.

Porém não pare por aí; abra tempo para discutir o que é o Agile para cada um, o que gostam e o que não gostam de fazer. O Agile é um esporte coletivo; sem um entendimento comum, cada um estará jogando um jogo diferente. Essas discussões devem começar nas sessões de treinamento, ao mesmo tempo em que a equipe chega a um entendimento compartilhado das técnicas ágeis.

6) Anime mas não force

Quem já trabalhou em empresas por alguns anos já viu mudanças organizacionais serem forçadas para todos: BPR, ISO 9000, Seis Sigma, CRM etc. Um dia alguém tem uma ideia e então o rolo compressor de mudanças é ligado, passando por cima de todos.

Vivemos em um mundo pós-moderno, pós-BRP, pós-demissões, pós-recessão, pós-tudo. Os funcionários não são crianças e já sabem tudo o que está acontecendo. Além disso, é comum haver redundâncias antes do início do movimento de mudanças, especialmente quando consultores estão envolvidos. Se houver necessidade de cortar pessoal, faça-o antes de mudar para o Agile.

Aplique um princípio Lean: puxe, não empurre. Quando se fala em “gerência de mudanças”, entra-se no mundo das mudanças “empurradas”; então proíba o uso dessas palavras.

Caso você esteja na gerência e queira introduzir o Agile, crie um movimento que gere entusiasmo com mudanças de baixo para cima, e forneça apoio de cima para baixo. Tentar uma adoção do Agile com uma abordagem unicamente de cima para baixo quase certamente resultará em fracasso – os funcionários são sempre céticos em relação a mudanças forçadas.

Procure entusiasmar indivíduos e equipes, faça-os pedir o uso do Agile. No lugar de impor mudanças, os gestores devem estimular a curiosidade das pessoas, fazer com que levantem dúvidas e peçam ajuda.

Faça tudo para que a “chama se acenda” e não deixe que se apague. Quando for pedido, ajude e forneça suporte a todas as necessidades. Permita gastos, abra espaço no orçamento para palestrantes, treinadores ou coaches. Apoie a ida a conferências; seja generoso. E envolva-se; também é preciso aprender – mesmo que se saiba que tudo o que o necessário é estar lá para quando o entendimento comum estiver construído. Aprenda a mudar também e a adequar seus próprios comportamentos de acordo com as necessidades.

7) Seja claro nas razões para adotar o Agile

Independentemente da posição que se ocupa – seja ela de engenheiro, analista de testes, gerente de projetos, diretor – entenda qual o problema que se quer resolver com o Agile. Entenda porque é importante mudar e o que esperar como resultado da mudança.

Não adote o Agile porque está na moda, mas sim para obter resultados reais. Procure entender o que as pessoas querem do Agile e o que isso pode melhorar na vida delas; entenda ainda o que a organização quer do Agile. Inovação? Cronogramas confiáveis? Menos defeitos?

É importante também compreender como cada membro da equipe enxerga os benefícios de se adotar o Agile. Se todos veem os benefícios, então (claro) haverá apoio na adoção; caso contrário, as mudanças serão difíceis. À medida que o Agile é adotado, utilize o que se esperava como resultados para escolher as ferramentas, otimizar seus processos e medir seu sucesso.

8) Adote tanto os aspectos técnicos quanto os de processo

A mudança do processo sozinha não é capaz de fazer tudo funcionar bem. Deve-se dar atenção aos aspectos técnicos também; melhorar a qualidade, dar apoio aos engenheiros, analistas de testes e outros que estejam realizando o trabalho.

Algumas empresas veem com desdém o lado técnico: a atitude parece ser de “isso é técnico demais” ou “eles que sujem as mãos”, ou ainda, “podemos mudar para um país com custos mais baixos”.

Caso essa seja sua visão, será difícil obter sucesso. Suje as mãos, fale com os engenheiros, adote o desenvolvimento orientado a testes (TDD), a refatoração; evite planejar a arquitetura toda de uma vez antes do desenvolvimento; aprenda a conviver com decisões difíceis de projeto e de evolução da arquitetura. Há ciclos de feedback positivo importantes nessas práticas.

9) Torne o fluxo de requisitos claro e limpo

Não basta melhorar apenas a parte da programação; a parte dos requisitos deve ser tratada também. Deve haver uma comunicação clara entre quem representa os requisitos (Product Owners, Gerentes de Produto etc.) e a equipe de desenvolvimento. Haverá muito mais negociações sobre o que fazer do que sobre quando fazer. Alguém precisa representar a equipe e se responsabilizar por essa parte do trabalho.

É comum que empresas tenham pouco pessoal para desempenhar este papel. O Agile torna esta escassez ainda mais grave, pois o gargalo nos requisitos terá efeito sobre o desenvolvimento.

Faça um exercício mental; pense no que aconteceria se o Agile duplicasse a produtividade dos desenvolvedores. Seria necessário o dobro do esforço no lado de requisitos. A princípio, pode-se apenas vencer um grande backlog, mas conforme se faz isso, o valor do que é entregue provavelmente entrará na descendente.

10) Mudanças estruturais e grupos funcionais

Monte suas equipes com as pessoas necessárias para fazer o trabalho sobre o qual são responsáveis; acabe com grupos funcionais (por exemplo, desenvolvedores de banco de dados e desenvolvedores de interfaces de usuário em equipes separadas). Esta é apenas a primeira de muitas mudanças organizacionais necessárias. Mas se esta falhar, será praticamente fim de jogo.

Equipes irão parar, ficar travadas, se precisarem pedir ajuda de outros grupos para ter acesso a habilidades especializadas ou obter permissões. Outros grupos têm outras prioridades, e pequenos impedimentos se acumulam, cada um tirando um pouco de velocidade da equipe, minando sua moral e tornando a adoção do Agile mais difícil.

Texto por Allan Kelly
Fonte: http://www.targettrust.com.br/blog

quinta-feira, 21 de junho de 2012

Padrão brasileiro de TV Digital abre oportunidades a desenvolvedores Java

Oracle calcula 130 mil programadores no Brasil e projeta boom de mercado de serviços distribuídos via televisão a partir do próximo ano

O Brasil aprovou o uso do Java em seu Padrão de TV Digital. O movimento abre um mercado para os aproximadamente 130 mil desenvolvedores brasileiros que atuam com a plataforma. A expectativa é um boom nesse mercado a partir de 2013, a partir da evolução do programa e queda de preço dos dispositivos com mais interatividade. “É uma tecnologia nova. A TV vai criar um novo paradigma para pessoas de qualquer renda, com acesso a conteúdo e interação de uma forma diferenciada”, aposta Dimas Oliveira, consultor de vendas da Oracle.

A fabricante acredita em uma ampla adesão dos produtores de televisores e settop box ao padrão, que aumentarão a oferta de soluções interativas e de inclusão digital. Atualmente, já existem alguns aparelhos com esses recursos – mas a proporção ainda é muito tímida. A ideia é que uma popularização de aparelhos mais sofisticados impulsione serviços diversos distribuídos via TV. “O que vai determinar o sucesso ou não da plataforma será o desenvolvimento”, comenta.

“Esses desenvolvedores podem criar os mais diversos aplicativos interativos, seja para transmissão de conhecimento, conscientização, educação, cultura, lazer, comércio, etc. Para isso, os fabricantes de equipamentos de televisão e de settop-box têm apenas de incluir em seus produtos o middleware interativo DTVi, que roda em máquina virtual Java – Oracle JVM, cujo padrão de qualidade se diferencia pela flexibilidade, robustez, certificação e padronização, garantindo a continuidade da oferta e que o mercado não sofra fragmentação”, detalha um comunicado da fabricante sobre o tema. Os programadores forneceriam soluções a emissoras e retransmissoras, produtoras de conteúdo e anunciantes.

Na visão do consultor, a interatividade propiciará que a população acesse, através dos televisores, serviços bancários e públicos, por exemplo. A plataforma também permitirá novas modalidades de comércio (T-commerce, como foi batizada as negociações via TV digital), a partir de ofertas segmentadas e do relacionamento com telespectadores.

“Hoje, cada TV tem seu próprio ambiente de desenvolvimento. A ideia do Ginga é que, independente do fabricante ou desenvolvedor de software, o aplicativo funcionará em qualquer marca de aparelhos”, explica Oliveira.

Oliveira vislumbra um mundo onde as aplicações para TV digital seguiriam uma lógica similar ao mercado de telefonia móvel, no qual um próximo passo seria a abertura de canais alternativos de conteúdo de outra fonte que não seja o broadcaster, o que ajudaria a dar escala ao conceito. Sem dimensionar de maneira precisa o quanto esse mercado movimentaria, ele mostra-se otimista. “É um mercado mais interessante do que o de dispositivos móveis”, compara.

Fonte: http://crn.itweb.com.br/36923/padrao-brasileiro-de-tv-digital-abre-oportunidades-a-desenvolvedores-java/

terça-feira, 19 de junho de 2012

Aplicação Mobile com HTML5 e Java

Saiba como construir uma aplicação em HTML5 com interface mobile e desktop nesse tutorial.

Saiba mais em http://www.jboss.org/aerogear/WhatisAeroGear.html

Screencast - Começando com Git

Excelente vídeo aula sobre o GIT, um controlador de versões centralizado que está agradando muita gente.

sábado, 2 de junho de 2012

Python: a “arma secreta” do Google

Se você é desenvolvedor e tem interesse em seguir carreira com computação gráfica, saiba que Python é a linguagem que possui hoje uma importância fundamental nesse mercado. Quem faz a afirmação é Luciano Ramalho, assim como o título deste post. Luciano é um dos principais articuladores do mundo Python em comunidades e eventos em que participa. Um desses eventos foi o DevInVale 2011, em São José dos Campos, onde Luciano apresentou um overview da linguagem. “Python, embora seja uma linguagem orientada a objeto, segue a filosofia da linguagem C++ no sentido de não te obrigar a programar orientado a objetos. Você não é obrigado a criar classes, pode criá-las quando faz sentido com o tipo de abstração do seu projeto. Além disso, o Python suporta também o paradigma funcional”, resume ele.

Antes de falar das características da linguagem, Luciano Ramalho alfinetou linguagens como PHP e JavaScript, as quais, segundo ele, foram prejudicadas pelo pouco tempo de desenvolvimento e maturação. “Python e Ruby são linguagens que foram desenvolvidas e maturadas ao longo de muitos anos, Python já tem 20 anos, Ruby um pouco menos, mas que começaram com uma pequena comunidade e um desenvolvedor que não estava com pressa e eles conseguiram desenvolver linguagens muito bem feitas”, observa.

Características

- Não obriga a declarar variáveis, mas obriga a inicializá-las
- Tipagem dinâmica forte, obriga conversões explícitas
- Suporta sobrecarga de operadores e herança múltipla (algo não encontrado em Java)
- Usa exceções, mas não obriga a declarar ou tratar (todas as bibliotecas trabalham com exceções, o que confere um conforto muito grande ao programador, pois ao chamar uma função, você sabe que pode confiar no resultado dela)
- Usa namespaces, módulos e pacotes (que permitem a construção de programas muitos grandes)

Implementações

- CPython: interpretador padrão, escrito em C (vem instalado no Linux e no OSX)
- Jython: implementado em Java, roda sobre a JVM (o framework Djando roda sobre ele)
- IronPython: implementado em C#, roda sobre o .NET CLR
- PyPy: implementado em Python, compilação JIT (comenta Luciano que o PyPy começou este ano a atingir um nível de desempenho em que passou a bater o CPython em quase todos os benchmarks)

Casos de sucesso

O YouTube foi desenvolvido em Python – Uma das três linguagens predominantes nos servidores do Google (as outras são C++ e Java)
O G1 foi construído em Django – Framework mais popular do mundo Python
Mozilla Firefox Add-Ons
Dropbox
Google App Engine
The Foundry, NUKE (interface escrita em Python)
Autodesk Maya
InVesalius (software de análises de imagem de tomografia, usa biblioteca Python)
Civilization IV (Game)
Frets on Fire (Game)

Assista ao vídeo com a íntegra da palestra de Luciano Ramalho no DevInVale 2011 para ver “de tudo um pouco” sobre Python, inclusive um live coding bem básico como demonstração da facilidade de uso e aprendizado da linguagem:

 

 

Referências:

Python Brasil

Google Groups: python-brasil

Khan Academy

Google Code University

“Introdução à Programação com Python”, de Nilo Menezes

“Python e Django”, de Osvaldo Santana e Thiago Galesi

Inteligência Artificial

 

Por Laura Loenert em GoNow

quinta-feira, 31 de maio de 2012

Enviando notificações do Trac pelo Gmail

Recentemente precisei configurar uma instância do Trac para enviar notificações via email utilizando o Gmail.

As notificações serão enviadas toda vez que um ticket for criado, alterado ou fechado.

Edite o arquivo “trac.ini” e no bloco "[notification]” informe a seguinte configuração:

 [notification]  
admit_domains =
always_notify_owner = true
always_notify_reporter = true
always_notify_updater = true
email_sender = SmtpEmailSender
ignore_domains =
mime_encoding = base64
sendmail_path = sendmail
smtp_always_bcc =
smtp_always_cc =
smtp_default_domain =
smtp_enabled = true
smtp_from = sua_conta@gmail.com
smtp_from_name = Trac
smtp_password = sua_senha
smtp_port = 587
smpt_replyto = sua_conta@gmail.com
smtp_server = smtp.gmail.com
smtp_subject_prefix = __default__
smtp_user = sua_conta@gmail.com
ticket_subject_template = $prefix #$ticket.id: $summary
use_public_cc = false
use_short_addr = false
use_tls = true