gdp's Comments

Edgard Davidson : Localização e Decodificação de Código de Barras em Imagens Digitais

Sun, 18 Mar 2012 04:00:18 +0000

Só devem existir barras finas e barras grosas. Me parece que esse código de barras foi mal plotado.

Edgard Davidson : Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis

Sun, 18 Mar 2012 03:59:05 +0000

Existe quatro entradas por ano. Uma em março, outra em maio, a terceira em agosto e a última em outubro.

Edgard Davidson : Pós Graduação em Teste e Qualidade de Software

Sun, 18 Mar 2012 03:58:14 +0000

Olá Bruno Não temos planos para oferecer o curso em modalidade EAD. Acreditamos que as dinâmicas realizadas neste curso devem ser essencialmente presenciais

Edgard Davidson : Utilização de Polimorfismo

Thu, 3 Nov 2011 16:48:55 +0000

Se você chamar a função "fazQualquerCoisa" passando um funcionario como parâmetro, a função não será mais polivalente e neste caso só aceitará receber objeto do tipo funcionario.

Edgard Davidson : Tipos de Relacionamento entre Objetos

Thu, 3 Nov 2011 16:43:46 +0000

Obrigado. Recomendo leitura dos livros do Martin Fowler, Robert Martin e Bertram Mayer e bertrand meyer. Aqui no blog brevemente irei postar um videos sobre esse assunto.

Edgard Davidson : CRUD com Flex e Java

Thu, 3 Nov 2011 16:41:14 +0000

Olá Farnetani O Flex é bastante flexível quanto a utilização de backend. Se você implementar no backend um webservice, "teoricamente", você poderá fazer um frontend em flex para acessá-lo. Em java e .net eu tenho certeza que funcionará. Contudo em Delphi já tive problemas nesse tipo de comunicação. Mas isso já tem algum tempo e penso que já devem ter corrido. Entretanto, com certeza o acesso via webservices ficará mais lento, mas isso também dependerá do seu caso, da quantidade de dados para transmitir e dos seus condutores arquiteturais.

Edgard Davidson : Gestão 3.0 - Para Líderes Ágeis - Parte 1

Tue, 27 Sep 2011 20:26:30 +0000

Olá Rodrigo. Obrigado por mais um comentário aqui no blog. Realmente, esses temas são bastante delicados, mas não são visões minhas, é a visão do autor do livro Management 3.0. Inclusive no livro também tem esse exemplo do hidrogênio e oxigênio. Esses assuntos são densos e geram muitas discussões filosóficas.

Edgard Davidson : Gestão 3.0 - Para Líderes Ágeis - Parte 1

Sun, 25 Sep 2011 11:13:51 +0000

Olá André Na verdade fiquei sabendo do livro Management 3.0 através desse seu post no seu blog. Ele faz parte de um dos referenciais teóricos da minha dissertação de mestrado. Entre outras coisas estou estudando também: learn organization, complexity systems, system thinking, Lean, knowledge management, Storytelling, como base para propor um modelo ágil para criar, registar, transmitir e usar conhecimento em equipes que utilizam desenvolvimento de software agil. A medida que eu for progredindo, irei compartilhando meus "relatórios técnicos" aqui no blog. Value!

Edgard Davidson : Paginação com Datagrid

Wed, 14 Sep 2011 18:09:04 +0000

Priscila. O código fonte está no final do post, em appServidor e appCliente

Edgard Davidson : Palestra #DevDay 2011

Sun, 11 Sep 2011 23:59:00 +0000

Olá Acaz Como sabemos, herança é um excelente mecanismo para obter reuso em código OO. Herança é um mecanismo para estender as classes existentes para aprimorar classes já existentes. No entanto ela deve ser utilizada com cautela. Em um post anteiro meu, falo sobre as "Condições pra uso de herança". http://edgarddavidson.com/?p=30. Condições que devem ser atendidas para justificar o uso de herança. Substituir herança por delegação, é uma das técnicas de refatoração apresentadas no livro de Refactoring do Martin fowler, também a citada com boa prática de programação no livro de design patterns Erich Gamma, além de atender aos princípios de projetos Orientados a Objetos. Você verá isso também no livro também Head First Design Patterns. No exemplo que apresentei no #devday, utilizo "substituir herança por delegação" porque MyStack anula o contrato da classe Vector. Outro motivo é que MyStack não é um tipo especial de Vector. Vector possui métodos em seu contrato como "removeElementAt" e "insertElementAt" que quando são herdados por MyStack passas a ser acessíveis para objetos do tipo MyStack. No entanto, apesar que estendido, os métodos "removeElementAt" e "insertElementAt" não fazem parte do contrato de MyStack, portanto MyStack anulo o contrato da superclasse. Nesse caso, o melhor a se fazer é refatorar o código, para atender a princípios de projeto aplicando "substituir herança por delegação" e fazendo com que MyStack encapsule o Vector e não mais utilizando o contrato de maneira indevida.

Coisas d'luisa : É tempo de liquidação!!!

Thu, 25 Aug 2011 19:32:50 +0000

legal

Edgard Davidson : Princípios de Projeto OO - Single Responsibility Principle (SRP)

Tue, 2 Aug 2011 18:35:45 +0000

ahh intense

Edgard Davidson : Localização e Decodificação de Código de Barras em Imagens Digitais

Mon, 11 Apr 2011 19:52:59 +0000

Sim, você pode, desde que use um código de barras que suporte caracteres. Por exemplo o Code39

Edgard Davidson : Localização e Decodificação de Código de Barras em Imagens Digitais

Tue, 15 Mar 2011 05:45:57 +0000

Olá phabio Envie um email para mim, edgard.davidson@gmail

Edgard Davidson : Da Imaturidade à Agilidade

Mon, 14 Feb 2011 00:10:00 +0000

Olá Rodrigo O seu ponto de vista sobre o legado da imaturidade dos gestores me fez lembrar o caso dos "macacos da jaula". Dizem que uma vez um cientista colocou dez macacos em uma jaula. Em seguida ele dependurou uma corda no meio da jaula que ia do teto até o chão, então, o cientista colocou uma banana no alto dessa jaula.Os macacos que não são bobos disputaram, quase que a tapas, quem iria conseguir subir na corda e pegar a banana. De repente o mais esperto conseguiu subir e ficou lá em cima comendo a banana sozinho. Como punição, o cientista lançou um jato d'agua nos outros nove macacos que ficaram em baixo. No outro dia, novamente o cientista colocou a uma nova banana no alto da jaula, e mais uma vez o macaco mais esperto conseguiu subir e comeu a banana sozinho lá em cima. Mais uma vez, como punição, o cientista lançou o jato de água gelada nos outros nove macacos. E essa rotina continuou nos outros dias, até que um dia quando o macaco mais esperto foi tentar subir novamente na corda, os outro macacos o seguraram e o cobriram de porrada. Naquela ocasião, os macacos perceberam que sempre que um deles subia na corda para comer a banana, os outros nove levavam água fria. E quando nenhum deles subia na corda, a banana apodrecia lá em cima, mas também nenhum deles levava água gelada. E por muito tempo essa situação se manteve estável e os macacos aprenderam, a duras penas, que eles não podiam subir na corda para pegar a banana sob pena de levar um jato de água gelada. Essa regra então foi definida, e todos os macacos a entendiam e sabiam as consequências do não cumprimento dela. Um belo dia, o cientista retirou um dos macacos da jaula e colocou um macaco novo. O novo macaco, sem saber de nada, viu a banana, viu a corda, olhou pra um lado, olhou pro outro e nenhum dos outros se manifestaram, então o novo macaco inocentemente tentou subir na corda quando foi surpreendido pelos outro macacos que lhe encheram de porrada. O novo macaca apanhou sem nem saber o porquê. No próximo dia, o cientista retirou mais um macaco da população dos dez iniciais e colocou um outro novo, e novamente dependurou uma banana no alto da jaula. Esse último macaco, também inocentemente tentou subir na corda para pegar a banana. Isso era contra a regra estabelecida naquela população de macacos e, surpreendentemente, o macaco que mais deu porrada foi justamente o que entrou no dia anterior, e que apanhou e bateu sem saber o porquê. Nos dias decorrentes, o cientista foi substituindo cada um dos macacos que estavam na população dos dez iniciais por macacos novos e por todas as vezes a regra de não subir na corda pra pegar a banana perdurava. Até que um dia todos os dez macacos inicias já tinham sido substituídos por novos macacos. O curioso é que mesmo com a população de macacos totalmente renovada aquela antiga regra se manteve. Ou seja, os macacos seguiam um "processo" sem nem saber para o que serve tão pouco porque foi criado. Agora voltando à imaturidade dos gestores, será que eles não são esses macacos na nova geração?!

Edgard Davidson : Qualidade em Processo de Desenvolvimento de Software

Sat, 5 Feb 2011 13:49:05 +0000

Olá Rodrigo. Obrigado pelo seu comentário. A intenção do post é essa mesma; gerar opiniões e discussões em torno deste tema. :) Apesar de mal escrito... rsrsr O interessante é que no post não usei nenhum "grau superlativo"... Te confesso que quando citei "escola tradicional" estava me referindo a engenharia de software de maneira mais ampla, não focando no corpo de conhecimento em gerencia de projeto proposto pelo PMI. Concordo contigo sobre a documentação e não penso que é dispensável. Desde que ela apoie a conformidade com o produto e não a conformidade com o processo. Isso já foi tema de um outro post aqui no meu blog. Quando eu compro um carro, eu como consumidor estou preocupado com a qualidade do produto (carro). Se as minhas expectativas forem supridas em relação a este produto, para mim consumidor esse é um produto de qualidade. No entanto, vejo que em engenharia de software se discute muito o meio (o processo) e não muito o fim (o produto de software). Assim como exemplo do carro, o usuário final não está interessado em saber como ele foi construído, se foi em uma linha de montagem automática, com robôs com braços pneumáticos, etc etc. Para mim, a documentação só tem dois propósitos; 1° fazer com que a equipe entenda o que precisa ser feito; 2° facilitar o comunicação entre os envolvidos no projeto, incluindo o cliente. Esses propósitos são suficientes para manter a conformidade com o produto. Quando esse tipo de documentação é omitida no processo, então devo concordar com você. A burocracia da engenharia de software "tradicional" é em insistir tanto em controle operacional, sobrecarregando a equipe, as vezes até com micro-gerenciamento, em prol da conformidade com o processo. A equipe de Quality Assurance nas auditorias de garantia de qualidade com o processo promovem esta rigidez. Não há nenhum problema desenvolver software seguindo a risca modelos de maturidade como CMMI e MPS-BR, mas lembre-se do preço que irá pagar para manter a coerência entre todos os artefatos gerados durante as iterações e alterações de requisitos. Se é pra fazer assim, então faça direito. E tenha equipe (braço, labor) para manter. O que tenho visto é que manter a referida coerência é custosa, trabalhosa e financeiramente cara. E não há nenhuma relação entre manter esse tipo de conformidade com a qualidade do produto final. "...Um bom processo de software é um bom indicador que o produto de software será de qualidade, mas não é garantia dê." Em outras palavras, isso não agrega valor para o usuário, ele não vê isso, o que ele vê é software. Não sou xiita por métodos ágeis, tão pouco pelos tradicionais. Minha visão é em encontrar o que preciso extrair de cada abordagem para extrair o melhor de cada uma, e, sobretudo que satisfaça as expectativas de quem está comprando e de quem irá utilizar o produto de software. No mais muito obrigado, seus comentários sempre enriquecem essas discussões!

Edgard Davidson : CRUD com Flex e Java

Wed, 3 Nov 2010 00:23:54 +0000

Para usar MySQL é da mesma forma. Crie o seu banco normalmente e na opção conexão com banco de dados você irá escolher banco de dados do mysql

Edgard Davidson : Coding Dojo na Criação do Conhecimento

Sat, 25 Sep 2010 01:44:16 +0000

Olá @Rodrigo Primeiramente obrigado pela pertinência de seu comentário. Concordo contigo quando diz que o terreno de Gestão de conhecimento é altamente instável. Estou pesquisando sobre integração de conhecimento em equipes ágeis de desenvolvimento de software. Estou procurando entender como isso pode ser feito, como isso pode ser "explicitado". Sei que a caminhada é difícil com infindáveis controvérsias pontos de vista de contradições. A socialização como você mesmo citou é um grande trunfo de metodologias ágeis. Interações face-a-face sobre um domínio de saber são muito mais efetivas do que externalização e combinação de conhecimento em um canal de comunicação com por exemplo um documento, que, diga-se de passagem, como você bem citou não é conhecimento e sim informação. A caminhada é longa, infindável e outros pontos de vista são sempre bem vindos! Obrigado pela contribuição

Edgard Davidson : Esse semestre não dei prova Final - Dei DOJO

Sat, 25 Sep 2010 01:25:10 +0000

@Prof.Roberto O Dojo é um conceito que veio das artes marciais. Naquele contexto os treinamentos realizados, repetições de golpes, aperfeiçoamento de técnicas da arte marcial, tudo isso se resume em preparar o lutador para o combate. No arte marcial, o objetivo de treinar é aperfeiçoar a arte, sem propósito de competição e ilusões a egos pessoais. Esse conceito foi introduzido na área de desenvolvimento de software com o pressuposto que o programador não treina, ela vai direto para o combate. E isso, eventualmente gera uma séria de problemas no desenvolvimento de software devido ao débito técnico da equipe. Um lutador com débito nas técnicas de sua arte marcial certamente perderá a luta. Partindo deste princípio e assumindo que os programadores não treinam surgiu então o conceito de "coding dojo". Onde o propósito é fazer com que o programador possa treinar em ambiente fora da produção de projetos reais. Esse coding dojo utiliza valores, princípios práticas de XP (eXtreme Programming) como: programação em par, TDD, refatoração etc. No contexto de um curso de administração, parto do pressuposto de que o administrador, como o programador, também não treina, ele vai direto ao "combate". Se essa afirmação é verdadeira, então já existe uma excelente justificativa para a implementação de um, sei lá :) "management dojo". Uma forma extremamente simples, rápida e efetiva onde os envolvidos pudessem trocar experiências por meio de pequenas simulações com um enfoque altamente prático e que pudesse ser aplicado na prática (combates) no mundo real.

Edgard Davidson : Formei, mas não sei NADA!!!

Wed, 22 Sep 2010 01:48:05 +0000

Olá @eduardo. Prefiro responder por aqui mesmo. Penso que se você gosta da área de Análise então você deve concluir o curso. Sei que existem um monte de matéria chatas que você tem que enfrentar. Isso pode ser por vários fatores, desde um desinteresse natural seu quanto ao assunto até por um professor que não tem muito a manhã. Na real, o curso de graduação é necessário, mas não é suficiente. No curso você não vê nem 10% das coisas que você precisa saber para atuar de forma agressiva no mercado. E isso independe de curso e de instituição de ensino. Alguns conseguem sucesso até mesmo sem o curso superior, não é uma regra quanto menos uma garantia, portanto para alguns não é tão necessário assim. A pergunta que você deve se fazer não é se você está gostando da matéria x ou y. A pergunta que você tem que fazer é se você está mesmo disposto a trabalhar com tecnologia, a ter que aprender linguagens, frameworks, técnicas e mais um monte de coisas constantemente. Trabalhar com TI ou análise e desenvolvimento de software significa estudo constante. E você tem que gostar disso. Grande profissionais são aqueles que andam com as próprias pernas, buscam conhecimento por conta própria, são curiosos, pro-ativos, estudiosos e conseguem materializar isso tudo em seu trabalho. Mesmo que pra isso teve que ter passado por algumas chatices na faculdade.