É incrível como alguns serviços ainda não conseguem trabalhar com acentos. Minha surpresa, hoje, foi descobrir que eu baguncei a vida do SVN para todos os arquivos que fiz upload. Assim, para você, que como eu, acabou colocando acento e tem de voltar atrás para trocar o seu nome na integração Eclipse + SVNKit a dica é a seguinte:
apague o arquivo .keyring que fica no diretório ECLIPSE_HOME/configuration/org.eclipse.core.runtime/
Outras alternativas como eclipse.exe -vmargs -Duser.name=”usuario” NÃO vão funcionar. Ele até troca o valor do @author, mas não atualiza a conexão com o servidor.
Burj Al Arab e a casa do cachorro
Marcadores:
engenharia,
gka,
propósito,
segurança
Esse é um assunto que está batendo na minha cabeça faz algum tempo e acho que agora consegui dar uma certa forma, encontrando a metáfora correta: Burj Al Arab e a casa do cachorro.
O Burj Al Arab é um dos pináculos da engenharia. Belo, sofisticado, bem planejado, robusto, seguro e pensado para satisfazer aos mais exigentes. Enfim, um pedaço do paraíso (para os que acreditam).
E a casa de cachorro? Bom, é aquela singela construção que lembra uma casa mas que, bem, só serve ao cachorro e não imagino agradar nem a ele.
Mas porque trazer essas duas imagens? Porque quero abordar desenvolvimento de programas e sistemas que muitas vezes oscilam entre o Burj Al Arab e a casa de cachorro. Nos falta (me refiro aos desenvolvedores) uma melhor organização e (agora para pânico de muitos) regulamentação. Por que temos tanto preconceito com a regulamentação da profissão? Alguém já imaginou comprar uma casa (ou mesmo morar numa) que não tenha uma planta baixa? Que não tenha um engenheiro responsável? Alguém aceitaria ser operado por um pedreiro (infelizmente sim com as inúmeras cirurgias espirituais, mas estou digredindo)? A resposta, para a maioria das pessoas, seria não para ambas as perguntas. Todos querem que alguém assuma as responsabilidades e que os profissionais tenham sido aprovados por um órgão regulamentador. Então por que se aceita que alguém não cientista da computação faça o sistema web da sua empresa?
A razão é simples, o cliente quer um Burj Al Arab mas para isso pagar como se fosse uma casa de cachorro.
Outro ponto em que esta metáfora se aplica é quanto ao processo de desenvolvimento. É razoável que se espere o concreto secar para se iniciar os trabalhos de interiores. Ninguém, em sã consciência, aceitaria que se levantassem paredes sem que as fundações estejam prontas e devidamente verificadas. Não se coloca o telhado antes das paredes. Não se assume que: "bom, se não ficar de pé tentamos mais uma vez" seja uma metodologia aceitável. Posso mandar o meu "faz-tudo" de plantão montar uma casa para o meu cachorro e se não der certo, bom, faz-se outra. Se a entrada ficar pequena para o cachorro? Desgaste-se a entrada até ele passar. Se na primeira chuva a casinha se enterrar na lama do quintal? Azar, amanhã colocamos umas pedras para ver se resolve.
Acho que ficou claro o paralelo. Hoje vemos sistemas sendo construídos como se fossem casa de cachorro: sem planejamento, sem uma visão de vida útil, sem responsabilidade. O que é nosso é de ninguém. Qualquer um que sabe um pouco de estrutura de dados se julga desenvolvedor de programas. O mercado está tão saturado de "faz-tudo" que ninguém está prestando atenção nos verdadeiros engenheiros. Mas o que observo é que todos esperam um Burj Al Arab. Ainda não se entendeu que isso só é possível quando o profissional é capacitado e experiente e que custa caro, MUITO caro. Qualquer um faz uma casinha de cachorro. Basta ver as atrocidades cometidas em JavaScript, PHP, Java EE, etc.
Para mim é uma aberração escutar que site X e Y foram vitimas de SQL Injection. A reação que tenho é a mesma que tive quando soube do caso do Palace I e II no Rio de Janeiro. Como é que pode um sistema sofre com um ataque tão ridículo? É o mesmo que um prédio cair por erro de cálculo estrutural (o B-A-BA do engenheiro civil). É como um médico amputar a perna errada de um paciente.
Isso deveria ser visto como uma aberração e o profissional ser afastado pelo resto de sua vida de suas funções.
Não acho natural aceitar que se desenvolva sistemas como se fossem casas de cachorro. O que parece ser a prática comum, principalmente com prazos no mínimo otimistas que gerentes de projeto impõem. Este normalmente são dotados de um total desprendimento ou mesmo noção da realidade do que é desenvolvimento de software.
A realidade está batendo na porta: 1.000.000 de "faz-tudo" não irão construir um Burj Al Arab e os melhores engenheiros do mundo tampouco o farão em 2 anos. No final das contas não existe mágica: o teu sistema será tão bom quanto os profissionais que se tem a disposição e que condições se aplica ao desenvolvimento.
Abraços,
Gustavo
O Burj Al Arab é um dos pináculos da engenharia. Belo, sofisticado, bem planejado, robusto, seguro e pensado para satisfazer aos mais exigentes. Enfim, um pedaço do paraíso (para os que acreditam).
E a casa de cachorro? Bom, é aquela singela construção que lembra uma casa mas que, bem, só serve ao cachorro e não imagino agradar nem a ele.
Mas porque trazer essas duas imagens? Porque quero abordar desenvolvimento de programas e sistemas que muitas vezes oscilam entre o Burj Al Arab e a casa de cachorro. Nos falta (me refiro aos desenvolvedores) uma melhor organização e (agora para pânico de muitos) regulamentação. Por que temos tanto preconceito com a regulamentação da profissão? Alguém já imaginou comprar uma casa (ou mesmo morar numa) que não tenha uma planta baixa? Que não tenha um engenheiro responsável? Alguém aceitaria ser operado por um pedreiro (infelizmente sim com as inúmeras cirurgias espirituais, mas estou digredindo)? A resposta, para a maioria das pessoas, seria não para ambas as perguntas. Todos querem que alguém assuma as responsabilidades e que os profissionais tenham sido aprovados por um órgão regulamentador. Então por que se aceita que alguém não cientista da computação faça o sistema web da sua empresa?
A razão é simples, o cliente quer um Burj Al Arab mas para isso pagar como se fosse uma casa de cachorro.
Outro ponto em que esta metáfora se aplica é quanto ao processo de desenvolvimento. É razoável que se espere o concreto secar para se iniciar os trabalhos de interiores. Ninguém, em sã consciência, aceitaria que se levantassem paredes sem que as fundações estejam prontas e devidamente verificadas. Não se coloca o telhado antes das paredes. Não se assume que: "bom, se não ficar de pé tentamos mais uma vez" seja uma metodologia aceitável. Posso mandar o meu "faz-tudo" de plantão montar uma casa para o meu cachorro e se não der certo, bom, faz-se outra. Se a entrada ficar pequena para o cachorro? Desgaste-se a entrada até ele passar. Se na primeira chuva a casinha se enterrar na lama do quintal? Azar, amanhã colocamos umas pedras para ver se resolve.
Acho que ficou claro o paralelo. Hoje vemos sistemas sendo construídos como se fossem casa de cachorro: sem planejamento, sem uma visão de vida útil, sem responsabilidade. O que é nosso é de ninguém. Qualquer um que sabe um pouco de estrutura de dados se julga desenvolvedor de programas. O mercado está tão saturado de "faz-tudo" que ninguém está prestando atenção nos verdadeiros engenheiros. Mas o que observo é que todos esperam um Burj Al Arab. Ainda não se entendeu que isso só é possível quando o profissional é capacitado e experiente e que custa caro, MUITO caro. Qualquer um faz uma casinha de cachorro. Basta ver as atrocidades cometidas em JavaScript, PHP, Java EE, etc.
Para mim é uma aberração escutar que site X e Y foram vitimas de SQL Injection. A reação que tenho é a mesma que tive quando soube do caso do Palace I e II no Rio de Janeiro. Como é que pode um sistema sofre com um ataque tão ridículo? É o mesmo que um prédio cair por erro de cálculo estrutural (o B-A-BA do engenheiro civil). É como um médico amputar a perna errada de um paciente.
Isso deveria ser visto como uma aberração e o profissional ser afastado pelo resto de sua vida de suas funções.
Não acho natural aceitar que se desenvolva sistemas como se fossem casas de cachorro. O que parece ser a prática comum, principalmente com prazos no mínimo otimistas que gerentes de projeto impõem. Este normalmente são dotados de um total desprendimento ou mesmo noção da realidade do que é desenvolvimento de software.
A realidade está batendo na porta: 1.000.000 de "faz-tudo" não irão construir um Burj Al Arab e os melhores engenheiros do mundo tampouco o farão em 2 anos. No final das contas não existe mágica: o teu sistema será tão bom quanto os profissionais que se tem a disposição e que condições se aplica ao desenvolvimento.
Abraços,
Gustavo
Retrospectiva do Ano
Marcadores:
eh,
post-it,
retrospectiva
Se você está acostumado aos métodos ágeis, sabe que feedback é um dos valores fundamentais. Ele é dado em diferentes momentos e, de forma sistemática, aparece a cada final de iteração no que se convencionou chamar retrospectiva.Fora da informática esse termo não é incomum. Todos os meios de comunicação, por exemplo, fazem retrospectivas do ano. Ali eles apresentam todos os fatos que consideraram relevantes. No contexto de desenvolvimento de sistemas, a ideia é pegar a informação do time de desenvolvimento. Sem limitação sobre os assuntos.
Normalmente as nossas retrospectivas são feitas verbalmente com auxílio de papel e caneta. Pela primeira vez, resolvemos fazer um período maior que o sprint e usando post-its. Dessa vez, fizemos para o ano todo, separando a parede em três grandes colunas rotuladas como: "Boas", "Não Funcionaram" e "A Melhorar".
O funcionamento da atividade é simples. Vários post-its e canetas a disposição de todos. Cada um do time escreve o que quiser. Todos tem direito de ler o que os outros escreveram, assim como repetir o que já foi apontado, para reforçar alguma ideia. Depois do número de colagens na parede ter estabilizado, vem a rodada de comentários sobre os pontos levantados.
O resultado foi ótimo. O fortalecimento das relações da equipe foram repetidamente ressaltadas. Mais do que isso, aquilo que não funcionou além de identificado, foi analisado. Sem exceção, tudo relacionado a segunda coluna recebeu propostas de alteração para que efetivamente sejam melhor praticadas. Ainda estamos compilando os resultados para que possamos decidir, entre todas as possibilidades, quais atacar prioritariamente.2010 promete!
E você, tem feito retrospectivas?
JBoss, JProfiler, Eclipse e Linux
Para usar o JProfiler no Eclipse dentro do Linux (testado no Fedora 12) são necessários os seguintes passos:
1. Instalar o Fedora 12
2. Instalar o Eclipse
3. Instalar o Web Tools Platform
4. Instalar o JBoss Tools
5. Instalar o JProfiler
Uma vez feita a integração com o Eclipse (leia a documentação do JProfiler) e também a integração do Eclipse com o JBoss Tools (configurado) é necessário adicionar as bibliotecas do JProfiler na carga de bibliotecas do sistema:
#---
cat > /etc/ld.so.conf.d/jprofiler.conf << __END__
/opt/jprofiler6/bin/linux-x86/
__END__
ldconfig
#---
Adicionar a linha: "-agentlib:jprofilerti=port=2025" a execução do JBoss no Eclise:
Ao executar o JBoss disparar o JProfiler e conectar à uma nova seção remota na porta 2025
1. Instalar o Fedora 12
2. Instalar o Eclipse
3. Instalar o Web Tools Platform
4. Instalar o JBoss Tools
5. Instalar o JProfiler
Uma vez feita a integração com o Eclipse (leia a documentação do JProfiler) e também a integração do Eclipse com o JBoss Tools (configurado) é necessário adicionar as bibliotecas do JProfiler na carga de bibliotecas do sistema:
#---
cat > /etc/ld.so.conf.d/jprofiler.conf << __END__
/opt/jprofiler6/bin/linux-x86/
__END__
ldconfig
#---
Adicionar a linha: "-agentlib:jprofilerti=port=2025" a execução do JBoss no Eclise:
Ao executar o JBoss disparar o JProfiler e conectar à uma nova seção remota na porta 2025
Problemas com Eclipse no Fedora 12
Descrição do problema:
Alguns botões, especialmente OK e Finish, não respondem ao clique do mouse. É necessário manter o foco no botão (mantendo o mouse sobre o botão, por exemplo) e pressionar a tecla ENTER.
Solução (simples):
É necessário sobre-escrever uma variável de ambiente antes de executar o eclipse:
#---
GDK_NATIVE_WINDOWS=true eclipse
#---
solução (para atalho no desktop):
Crie um script shell e o use como comando no atalho:
#---
cat > ~/bin/eclipse.sh << __END__
GDK_NATIVE_WINDOWS=true eclipse
__END__
chmod 755 ~/bin/eclipse.sh
#---
Fonte: http://forums.fedoraforum.org/showthread.php?s=a3c988d542abeeb3b04991ab5c12070d&p=1301362#post1301362
Alguns botões, especialmente OK e Finish, não respondem ao clique do mouse. É necessário manter o foco no botão (mantendo o mouse sobre o botão, por exemplo) e pressionar a tecla ENTER.
Solução (simples):
É necessário sobre-escrever uma variável de ambiente antes de executar o eclipse:
#---
GDK_NATIVE_WINDOWS=true eclipse
#---
solução (para atalho no desktop):
Crie um script shell e o use como comando no atalho:
#---
cat > ~/bin/eclipse.sh << __END__
GDK_NATIVE_WINDOWS=true eclipse
__END__
chmod 755 ~/bin/eclipse.sh
#---
Fonte: http://forums.fedoraforum.org/showthread.php?s=a3c988d542abeeb3b04991ab5c12070d&p=1301362#post1301362
DICOM
Marcadores:
DICOM,
Ecocardiografia,
eh,
Grupo de Discussão,
Retinografia
A transmissão de imagens médicas vem sendo feita há algum tempo. Nada mais natural, então, que surgissem alguns padrões nessa área, como o DICOM. Aqui, o estamos usando no manuseio de alguns exames, como Ecocardiografia e Retinografia. Tenho certeza que mais empresas e estudos brasileiros também estão. Assim, criamos uma lista de discussão para que diferentes pessoas possam trocar experiências e dúvidas. Se te interessa, dá uma conferida:
* Nome do grupo: DICOM - Brasil
* Página inicial do grupo: http://groups.google.com.br/group/dicom-brasil
* Endereço de e-mail do grupo: dicom-brasil@googlegroups.com
* Nome do grupo: DICOM - Brasil
* Página inicial do grupo: http://groups.google.com.br/
* Endereço de e-mail do grupo: dicom-brasil@googlegroups.com
Autonomia, Domínio e Propósito
O Gustavo me mandou um vídeo muito interessante sobre motivação. O apresentador reflete sobre a obsolência do sistema de recompensa e apresenta uma solução para o século XXI. Para ele, uma melhor abordagem para a resolução de problemas é baseada em "Autonomia, Domínio e Propósito". Eu estava mesmo lendo esses dias um material que citava como um dos valores centrais da comunidade ágil a autoridade sobre os assuntos técnicos. Segundo os autores, os desenvolvedores estão sempre batalhando para manter seu código simples e direto. Eles avançam sempre para estar de acordo com o que há de melhor em solução tecnológica.
Olhando para os quadros com tarefas (presentes em XP, Lean/Kanbam e afins) onde cada membro da equipe escolhe o que fazer, vemos um bom exemplo de autonomia. Ora, quer melhor exemplo que a livre escolha, sem microgerência, para desenvolver o coeficiente de viração própria e a responsabilidade? Ter o poder de decidir qual tarefa atacar, podendo se basear no que já conhece para ganhar tempo, ou no que não sabe para ganhar conhecimento, fortalece toda a equipe. Longa vida ao nosso quadro!
Aqui no Elsa, é fácil ver o propósito do projeto. Ajudar a ciência e a população são causas muito nobres. Domínio, é uma busca individual, coletiva e diária. Acho que estamos no caminho certo. E você, também está?
Olhando para os quadros com tarefas (presentes em XP, Lean/Kanbam e afins) onde cada membro da equipe escolhe o que fazer, vemos um bom exemplo de autonomia. Ora, quer melhor exemplo que a livre escolha, sem microgerência, para desenvolver o coeficiente de viração própria e a responsabilidade? Ter o poder de decidir qual tarefa atacar, podendo se basear no que já conhece para ganhar tempo, ou no que não sabe para ganhar conhecimento, fortalece toda a equipe. Longa vida ao nosso quadro!
Aqui no Elsa, é fácil ver o propósito do projeto. Ajudar a ciência e a população são causas muito nobres. Domínio, é uma busca individual, coletiva e diária. Acho que estamos no caminho certo. E você, também está?
Segurança ou paranóia
Quando se trata de segurança normalmente existem dois grupos de pessoas: os paranóicos e os otimistas. Eu faço parte do primeiro. Mas a questão é até que ponto a paranóia é realmente paranóia e quando ela passa a ser necessária? O que se observa em metodologias ágeis é que se deve fazer aquilo que é estritamente necessário para o funcionamento do sistema/programa. Mas puxando a "brasa" para o meu lado: quando o sistema deixou de funcionar porque houve um problema segurança, isso não entra no estritamente necessário? Afinal deixou de funcionar.
A questão vai além da definição mais clássica segurança, que é a proteção do sistema contra acesso não autorizado. Mas isso se aplica também a questões de acesso indevido mas autorizado. Como uma funcionalidade que deveria ter acesso restrito à alguns usuários mas por descuido ou relaxamento do programador não teve a sua restrição imposta. Além disso existem as questões da chamada "programação otimista", onde se confia que as coisas irão funcionar, sem que se busque verificar se elas realmente funcionam. Lógico que "blindar" cada parafuso do sistema é bobagem, assim como tentar aplicar alguma validação formal em todos os métodos (nada a ver com TDD). Mas existem momentos em que sim a paranóia não somente é necessária mas como pré-requisito para que se evitem dores de cabeças no futuro (nem tão) distante.
A questão vai além da definição mais clássica segurança, que é a proteção do sistema contra acesso não autorizado. Mas isso se aplica também a questões de acesso indevido mas autorizado. Como uma funcionalidade que deveria ter acesso restrito à alguns usuários mas por descuido ou relaxamento do programador não teve a sua restrição imposta. Além disso existem as questões da chamada "programação otimista", onde se confia que as coisas irão funcionar, sem que se busque verificar se elas realmente funcionam. Lógico que "blindar" cada parafuso do sistema é bobagem, assim como tentar aplicar alguma validação formal em todos os métodos (nada a ver com TDD). Mas existem momentos em que sim a paranóia não somente é necessária mas como pré-requisito para que se evitem dores de cabeças no futuro (nem tão) distante.
Cliente Presente
Marcadores:
agil,
cliente presente,
eh,
on-site costumer,
whole team,
xp
Fui a uma formatura esses dias e o paraninfo tinha uma frase de cumplicidade com seus afilhados que era algo como "Tamo junto". A origem da frase remetia ao fato de tanto o professor como os alunos estarem no mesmo lado, trabalhando pela formação acadêmica todas as sextas a noite e sábados dia todo. Alguns dias depois, fui a um evento de testes onde o palestrante pediu para os presentes se apresentarem. Após um membro da platéia se definir programador, surgiu a piadinha "Temos um inimigo na trincheira."
Essas duas situações me fizeram refletir um pouco sobre algumas práticas ágeis e como elas são importantes para o sucesso do sistema. Uma delas, definida como Cliente Presente (do original em inglês On-site Costumer) e preza que todos os colaboradores de um projeto devem sentar juntos, formando um time. Com isso, absolutamente todos são contribuintes em uma equipe ágil. Vale para equipe técnica e para clientes. Principalmente para o segundo grupo, essa atuação vale em qualquer ponto onde a possam exercer, como na definição de prioridades e/ou criação de testes. Assim, acaba acontecendo que cada um dos papéis possíveis não seja necessariamente propriedade exclusiva de um indivíduo.
Aqui no ELSA, essa prática é bastante real e fácil de ser observada. Temos uma equipe epidemiológica perto e sempre presente nas definições, análises e testes, facilitando muito o trabalho da equipe de desenvolvimento. Sendo a estrutura organizacional do projeto construída sobre um modelo de colegiado, possuir pessoas capacitadas a garantir o papel de Product Owner geograficamente vizinhas às atividades de análise, programação e testes é fundamental. No caso específico dos releases, seus testes de aceitação, complementares aos testes feitos pela equipe durante o desenvolvimento, nos garantem o sucesso das novas versões do sistema que são visíveis aos outros centros do estudo.
É bom saber que aqui estamos mais de acordo com o paraninfo. Se todos os membros da equipe querem o sucesso do mesmo software, a quem serve criar inimizades no grupo?
Essas duas situações me fizeram refletir um pouco sobre algumas práticas ágeis e como elas são importantes para o sucesso do sistema. Uma delas, definida como Cliente Presente (do original em inglês On-site Costumer) e preza que todos os colaboradores de um projeto devem sentar juntos, formando um time. Com isso, absolutamente todos são contribuintes em uma equipe ágil. Vale para equipe técnica e para clientes. Principalmente para o segundo grupo, essa atuação vale em qualquer ponto onde a possam exercer, como na definição de prioridades e/ou criação de testes. Assim, acaba acontecendo que cada um dos papéis possíveis não seja necessariamente propriedade exclusiva de um indivíduo.
Aqui no ELSA, essa prática é bastante real e fácil de ser observada. Temos uma equipe epidemiológica perto e sempre presente nas definições, análises e testes, facilitando muito o trabalho da equipe de desenvolvimento. Sendo a estrutura organizacional do projeto construída sobre um modelo de colegiado, possuir pessoas capacitadas a garantir o papel de Product Owner geograficamente vizinhas às atividades de análise, programação e testes é fundamental. No caso específico dos releases, seus testes de aceitação, complementares aos testes feitos pela equipe durante o desenvolvimento, nos garantem o sucesso das novas versões do sistema que são visíveis aos outros centros do estudo.
É bom saber que aqui estamos mais de acordo com o paraninfo. Se todos os membros da equipe querem o sucesso do mesmo software, a quem serve criar inimizades no grupo?
Assinar:
Postagens (Atom)
