Os profissionais que procuram uma colocação em tecnologia podem contar com portais que funcionam como bancos de currículos e propostas de trabalho online.

Por CIO/EUA
21 de dezembro de 2009 – 09h00

Em agosto de 2008, Nathan Wenneker decidiu apostar na contratação dos serviços do site norte-americano e que deve começar a operar fora dos Estados Unidos em 2010 Elance – o qual funciona como um banco de currículos e propostas de trabalho online, no qual profissionais anunciam suas habilidades e capacitações e empresas divulgam oportunidades profissionais temporárias. A ideia do desenvolvedor de aplicações não era a de conseguir um emprego, e sim de complementar sua renda fixa com trabalhos como freelancer.

Wenneker é só um exemplo dos mais de 20 mil profissionais de TI que se cadastram em portais como o Elance todo mês. Apenas em novembro deste ano, o site oDesk, que realiza os mesmos tipos de serviços, contabilizou cerca de 14 mil novas assinaturas. Isso porque muitas das pessoas que trabalham com tecnologia da informação estão desempregadas ou sofreram reduções de salários e benefícios durante 2009.

“Para quem está em busca de recolocação ou simplesmente de uma renda extra, esses sites são muito atraentes”, afirma o dono de uma pequena empresa de desenvolvimento de aplicativos para iPhone e que oferece seus serviços por meio do Elance, Nick Dalton. Ele complementa: “Essa é uma ótima maneira de divulgar o trabalho sem investir em ações de marketing.”

Muitas são as oportunidades para os profissionais de TI no mercado, no entanto, a dificuldade encontrada por eles é justamente de saber como fazer com que suas qualificações cheguem às mãos das empresas contratantes. De acordo com o CEO do Elance, Fabio Rosati, as contratações por meio do site aumentaram 40% em 2009 se comparadas ao ano anterior. “Hoje mais de 60 mil companhias buscam colaboradores temporários no portal”, diz ele.

Enquanto isso, o CEO concorrente oDesk, Gary Swart, confronta afirmando que seu site já contabiliza mais de 85 mil organizações contratantes. “Além disso, registramos mais de 70 mil contratações este ano”, afirma o executivo, que completa: “Isso porque hoje as empresas estão desesperadas em busca de mecanismos que as permitam fazer mais com menos e a contratar funcionários temporários é uma das formas de se chegar a esse objetivo.”

No entanto, os candidatos a ocupar postos sazonais devem saber como aproveitar ao máximo as funcionalidades oferecidas pelos sites para otimizar os resultados da divulgação dos currículos. Para isso, os CEOs de ambas as empresas montaram um “guia” de como criar perfis atraentes aos contratantes.

Fonte: Computerworld

Postado por Vikas Hazrati, traduzido por Marcelo Andrade em 17 Dez 2009 06:46 AM

Scrum Master é um nome que sugere ser o guardião do processo Scrum. Ele é um agente de mudança que apoia sua equipe ao mesmo tempo em que ensina e socializa o Scrum por toda a organização. Ele garante o bom andamento das atividades da equipe erradicando os impedimentos e mantendo a equipe protegida de distrações externas. Entretanto, em certos cenários, equipes ágeis sentem que o Scrum Master em si é o maior impedimento.

Siddharta descreveu um cenário, que ele acreditar prevalecer em equipes offshore devido à cultura hierarquizada e à estratégia de comunicação tradicionalista. Aqui, o Scrum Master acaba se tornando um gargalo entre a equipe e o cliente.

Segundo Siddharta,

Muitas equipes não possibilitam acesso dos membros do time ao cliente ou mesmo ao Product Owner (especialmente se estes não estão fisicamente disponíveis, mas apenas remotamente). Assim, o fluxo de informação é algo como

Você <-> ScrumMaster <-> Product Owner <-> Cliente

Tobias Mayer reagiu a isto sugerindo que se o Scrum Master estiver se tornando um intermediário para a equipe, então a causa do problema é outra.

[Isto é] um estilo simplificado de comando e controle. Chamar alguém de Scrum Master não faz dele um verdadeiro Scrum Master, especialmente se ele estiver profundamente impregnado com o "pensamento arcaico" e não teve treinamento para mudar essa mentalidade.

Jaibeer Malik, compartilha do argumento de Tobias quando menciona que a causa parece se a maneira como Agile está sendo implementada e seguida.. Ele ressalta que a comunicação é a questão fundamental de um processo ágil e que todos os membros da equipe devem ser capazes de se comunicar com qualquer pessoa da equipe sem o intermédio do Scrum Master.

Já Roberto Fasciolo apontou outras razões pelas quais os ScrumMasters estão caindo nos velhos problemas do pensamento tradicional. Ele observou as seguintes armadilhas,

• Scrum Master se comprometendo com o sprint backlog – Isto ocorre particularmente quando o Scrum Master é também um membro da equipe. O time simplesmente aceita o que ele tem a dizer.
• Scrum Master indicando ao time sobre o que fazer ao invés de orientar a auto-organização – Isto acontece muitas vezes quando o Scrum Master é um ex gerente de projetos. O efeito disto é que o time pode se tornar completamente dependente de seu Scrum Master.
• Scrum Master agindo como um proxu entre o time e o Product Owner – – Isto é semelhante ao cenário descrito por Siddharta e é prevalente em equipes offshore distribuídas.

Mike Cottmeyer complementa que se o Scrum Master estiver apenas mantendo registro de impedimentos, então ele é o impedimento. Um bom Scrum Master não deve apenas ser capaz de registrar e remover impedimentos, mas também deve ser um Antecipador que pode antever os problemas e trabalhar com o time para não permitir que as coisas deem errado.

Cesario Ramos descreveu uma situação interessante na qual o Scrum Master também está tão envolvido com o time que suas próprias tarefas de Scrum Master se tornam um impedimento por estarem no caminho crítico.

A questão aqui é que o Scrum Master está fazendo tarefas de projeto “de valor”. Ele ou ela está tentando fazer coisas de que os outros membros da equipe dependem para fazer suas tarefas. Isto pode até chegar ao ponto em que o Scrum Master sente que não conseguirá ter uma sprint concluída sem que ele/ela busque remover todas estas tarefas importantes/difíceis.

Boris Gloger, também tem uma história parecida para contar quando fala que o SM de Scrum Master não significa (S)uper (M)an. Um Scrum Master que não esteja fazendo seu papel adequadamente ou que esteja tentando incorporar múltiplos papéis além de seu papel principal é, na verdade, um impedimento para o time.

Por isso, há muitas situações em que um Scrum Master pode impedir, conscientemente ou não, as atividades do time. A chave aqui está em identificar estas situações o mais cedo possível e tomar as ações corretivas enquanto ainda há esperança para o projeto.

Fonte: InfoQ

Vídeo de abertura do TDC 2009:

Fonte: Twitter de Israel Santiago

Postado por Mike Bria, traduzido por Marcelo Andrade em 04 Dez 2009

Patrick Wilson-Welsh, Chris Beale, Gary Baker, John Huston, Daryl Kulak e outros estão tentando popularizar a ideia de um novo papel, o "Líder de Equipe Ágil", em substituição aos papéis de liderança existentes que normalmente rodeiam equipes ágeis.

Nas palavras de Wilson-Welsh:

Estamos deliberadamente tentando apagar o velho papel de gerenciamento de equipes ágeis e sua responsabilidade rotulada como o Scrum Master e o Gerente de Projetos, que cada vez mais acreditamos estarem fundamentalmente defasados. Achamos que a controvérsia sobre este assunto deve-se justamente aos inconvenientes da empresa: a colcha de retalhos que se tem com a gerência de equipe ágil, a gerência do projeto, os clientes e proprietários do produto e a gestão de melhoria do processo resulta em mais buracos que um queijo suíço.
…

Seja você contra ou a favor, o fato é que precisamos de uma mudança de paradigma envolvendo a liderança em equipes ágeis. Nós precisamos de uma liderança que possa ser mais consolidada, mais focada, mais definida e mais adequada à dialética entre as necessidades internas da equipe e as necessidades externas dos clientes e stakeholders. Nós precisamos de uma pessoa que possa ser responsabilizada na medida em que a autoridade da equipe ágil e a responsabilidade são, de fato, congruentes.

Segundo ele propõe, esta pessoa seria um "Líder de Equipe Ágil". Wilson-Welsh ainda prossegue em apresentar um esboço sobre o que se esperaria de tal papel. Uma visão resumida deste (já resumido) esboço inclui as seguintes cinco categorias de responsabilidade:

• Liderança Contínua

  A compreensão do lugar da equipe dentro dos objetivos organizacionais, sendo um ponto único de liderança (para a equipe) e responsabilidade (para os stakeholders), criando um "ambiente seguro" no qual a equipe possa trabalhar, aumentando a confiança e o respeito entre a equipe e os stakeholders, além de melhorar continuamente a coesão da equipe.

• Planejamento Contínuo
  Garantir que a equipe seja cada vez mais capaz de se realizar seus próprios compromissos já estabelecidos, garantir que todas as coisas estejam sempre "grandes e visíveis", gerenciar métricas, reconhecer a "culpa" no plano (ao invés de atribuí-la às pessoas) e garantir o atendimento às mudanças no plano.
• Execução Contínua
  "Monitorar/gerenciar a velocidade/taxa de entrega da equipe", assegurar recursos, remover e escalonar impedimentos. Por fim, "manter o fluxo, o momentum e o foco da equipe".
• Redução Contínua de Risco
  Identificar riscos e deixar seu "impacto potencial grande e visível para as pessoas certas", garantir que a redução de riscos aconteça e quantificar a efetividade do gerenciamento de riscos.
• Melhoria Contínua (Agile Coaching)
  Comandar as "melhorias acerca das Definições de Pronto como um todo", saber identificar e dedicar a devida atenção às quedas de desempenho, facilitar as melhorias na equipe nas áreas certas e ajudar a equipe no aprendizado de boas práticas emergentes onde quer que elas estejam.

O feedback inicial sobre esta iniciativa é misto. Abby Fichtner (aka, "The Hacker Chick" ou "A Garota Hacker") e John McFadyen ambos apoiam as ideias de Wilson-Welsh, mas se questionam no que um papel de "Lider de Equipe Ágil" difere de um "Scrum Master". Abbey destaca ainda como o pensamento de "a liberdade levando a falhas" depreendido das responsabilidades descritas a fazem lembrar da apresentação de Jared Spool no Agile 2009 na qual ele destacou 3 características comuns de muitos dos projetos "descontroladamente bem sucedidos".

Tobias Mayer discorda deste conjunto responsabilidades sendo determinante para seleção de pessoas quando diz que "cada membro da equipe precisa" encarnar as virtudes descritas por Wilson-Welsh. Segundo Mayer:

Criar um "papel" de líder de equipe é o início de uma jornada de volta ao comando-e-controle. É um aspecto do vigilantismo; uma desculpa para não facilitar o real desafio de se consolidar uma equipe como um líder de verdade faria.

E você, o que acha? Um papel com esta definição poderia ser útil? Se sim, como este esboço de definição poderia ser melhorada? Ou tratar-se-ia de um papel redundante, ou quem sabe não seja de fato uma ideia ruim (como Mayer propõe)?

Fonte: InfoQ

A Caelum há mais de dois anos criou um curso de Rails, depois de passado algum tempo desde sua terceira reformulação, está disponibilizando o material utilizado, para toda a comunidade, seguindo a tradição da Caelum em compartilhar conhecimento.

A apostila cobre itens de Ruby desde o básico da linguagem até meta programação, conhecimentos necessários para utilizar o Rails, onde estudamos partes importantes como Active Record, rotas, Ajax, paginação e integração com Java.

São quase 150 páginas para o auxiliar no aprendizado do Rails. Você pode fazer o download pelo link: http://www.caelum.com.br/curso/rr-71-ruby-on-rails/

Fonte: Caelum

Vídeo exibido no programa Olhar Digital sobre a carreira de programador.

A gigante das buscas está mesmo querendo se infiltrar em novas áreas e está lançando uma nova linguagem de programação chamada Go.

Esta linguagem visa combinar velocidade e manutenção no desenvolvimento (como o Python) com a leveza e agilidade da linguagem compilada C ou C++.

Go irá suportar multi processadores com suporte também a vários servidores.

A empresa está interessada no desenvolvimento desta nova linguagem de programação devido às atuais linguagens não estarem satisfazendo os engenheiros da empresa, que estão vendo os computadores ficarem cada vez mais rápido e as tradicionais linguagens e seus recursos não estarem acompanhando esta evolução.

O Google diz que irá tirar o máximo proveito desta nova linguagem adaptando para os novos hardwares existentes e futuros, simplificando a análise e sintaxe de programação além de evitar as corriqueiras sobrecargas presentes em linguagens como C e seus arquivos de bibliotecas.

Você poderá ver mais sobre o assunto, sabendo como instalar o compilador, os pacotes disponíveis, tutoriais, documentações e outras explicações no próprio site do Go, aqui: http://golang.org/

Fonte: Dicas para computador

Postado por Phillip Calçado
para o Blog Fragmental em 14/11/2009

Neste curto período no Brasil eu tive a oportunidade de conversar com muita gente, tanto do Rio quanto de outros locais que vieram para workshops ou eventos. Como não é novidade para ninguém o Brasil está cada vez adotando mais metodologias menos burras -ou “ágeis” se você preferir.

E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.

Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!

Só cuidado para não quebrar as barreiras que protegem o time.

Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.

E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.

Não vai.

Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.

Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.

Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.

Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.

E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.

E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.

A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.

Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.

Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”

Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.

Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.

E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.

É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.

Fonte: Blog Fragmental

Postado por Abel Avram para o InfoQ, traduzido por Yan Borowski em 12 Nov 2009 09:43 AM

Fabrice Marguerie, um arquiteto de software e consultor, escreveu o artigo Como detectar e evitar vazamentos de memória e recursos de aplicações. NET, publicado no MSDN. O artigo   explica como vazamentos de memória e recursos podem acontecer durante a programação para. NET e como evitá-los.

Linguagens como C #, fazendo a limpeza da casa através de um coletor de lixo de memória, não tem vazamentos de memória em seu sentido original quando perde um programa de acesso completo a um local de memória. Segundo Fabrice, vazamentos de memória ocorrem quando uma localização de memória já não é necessária, mas o programa continua a manter pelo menos uma referência a ele. O coletor de lixo iria reclamar que a memória se era inacessível, mas a memória se torna um vazamento, desde que ela é referenciada pelo programa e não é mais utilizada.

Fabrice também enumera uma série de recursos de sistema operacional que podem ser sujeitos a vazamentos similares:

• O sistema utiliza objetos do usuário para suportar o controle da janela. Eles incluem: aceleradores de tabela, Carets, Cursores, Hooks, ícones, menus e janelas.
• Suporte a Objetos GDI gráficos: Bitmaps, Brushes, Contextos de dispositivo (DC), Fontes, DCs de memória, Metafiles, paletas, canetas, Regiões, etc
• Objetos do Kernel de apoio para gerenciamento de memória , execução do processo e inter-processo de comunicação (IPC): arquivos, processos, threads, semáforos, temporizadores, tokens de acesso, Sockets, etc

Estes recursos são limitados, as chaves do Registro GDIProcessHandleQuota e USERProcessHandleQuota contendo o número máximo de objetos de usuário e GDI que um processo pode usar. Os valores padrão são 10.000 para estas alças. Embora este número seja suficiente para a maioria das aplicações, a utilização de muitas delas fará com que o sistema atinja outro limite de 65.536 alças para uma sessão do Windows. Fabrice relatou que bateu este limite muito mais cedo, em cerca de 11.000.Sua conclusão é que os recursos de sistemas devem ser cuidadosamente utilizados e liberados quando não mais necessários.

Fabrice enumera as seguintes causas de vazamentos, explicando como funciona cada um deles:

• Usando referências estáticas
• Evento com a falta de cancelamento – essa é considerada, pelo autor, como a fonte mais comum de vazamentos
• Evento estático com a falta de cancelamento da referência
• Não chamar o método Dispose
• Usando um método Dispose incompleto
• A utilização indevida BindingSource com Windows Forms
• Não usar a chamada Remove no WorkItem/CAB

O autor continua o artigo, oferecendo aconselhamento sobre como evitar vazamentos:

• O criador ou proprietário de um objeto, e não o seu utilizador, é responsável pelo escoamento
• Sempre remova a referência de um Event Listener quando a mesma não é mais necessária, isso poderia ser feito com o Dispose() para a segurança
• Quando um objeto não gera mais eventos, todos os seus Listeners devem ser removidos através da atribuição de "null" para o objeto
• Quando uma referência é usada por um Model e pela sua View, é recomendado passar   um clone   do objeto referenciado   para a View,   evitaando assim que se perca quem está usando o que
• Chamadas aos recursos do sistema devem ser colocadas em blocos com "using" que forçam automaticamente uma chamada Dispose, ao sair do bloco

Fabrice conclui pela introdução de uma série de ferramentas úteis para lidar com objetos e vazamentos: GDILeaks (EXE), dotTrace, .NET Memory Profiler, SOS.dll, WinDbg.

Fonte: InfoQ