Mostrando postagens com marcador dicas. Mostrar todas as postagens
Mostrando postagens com marcador dicas. Mostrar todas as postagens

sexta-feira, 16 de janeiro de 2009

RIA-BA Grupo de Desenvolvedores RIA na Bahia

mini_banner

Essa é uma grande notícia!
Recebemos o “sinal verde” por parte da Adobe para iniciarmos uma comunidade oficial Adobe destinada a desenvolvedores e interessados no desenvolvimento de soluções RIA baseadas e suas tecnologias.
Surge assim o RIA-BA. Acesse o link no site de comunidades da Adobe, que será o site principal do grupo, inscreva-se e conheça mais detalhes sobre como será a nossa atuação.

As tecnologias que abordaremos, são basicamente as que são voltadas diretamente ao desenvolvimento de soluções RIA, que hoje são o Flash, o Flex/FlexBuilder, AIR, ColdFusion (e frameworks), Flash Media Server, BlazeDS, Cairngorm (e outros frameworks) e diretamente ligadas ao Flash Platform, assim como o Flash Catalyst (Thermo) e outras ferramentas que forem anunciadas.

À frente do grupo estaremos eu (Vicente Maciel Jr) e o meu amigo Jefferson Petilo.

Como alguns sabem, atuamos na Bahia (independentemente, por hora) com consultoria, treinamento e principalmente o desenvolvimento de soluções RIA. Nossa intenção com o grupo é concentrarmos esforços, para cada vez mais aumentar o potencial e resposta de demanda de mercado na região, através da distribuição de informação e acesso às novidades que surgirem no setor, de maneira mais rápida e eficiente possível. Para isso, estaremos abertos e firmando boas parcerias que possibilitem alcançar tal objetivo, bem como atender a outras necessidades dos usuários do grupo em relação a outras tecnologias Adobe que não sejam exatamente o foco do nosso grupo abordar, tais como Fireworks, Illustrator, Photoshop, Premiere, etc.

Enfim, interessados, mantenham-se ligados no site, que será nossa principal ferramenta de abordagem, efetivação e comunicação com a comunidade.

Sugestões e criticas construtivas serão sempre muito bem-vindas!

quinta-feira, 25 de dezembro de 2008

Hospedagem de projetos e repositorios SVN

unfuddle_logo

Para quem procura um host gratuito para gerenciamento e colaboração em projetos, a melhor alternativa atualmente, na minha opinião, é o Unfuddle.

assembla_logo Eu usava, até pouco tempo o Assembla. Mas, embora ele não seja mais gratuíto, o custo médio de US$2/mês por integrante (usuário) é bastante considerável para qualquer projeto.

Particularmente eu adotarei daqui para frente o Assembla para projetos comerciais/efetivos (com fins lucrativos) e o Unfuddle para projetos iniciais (fase piloto/concepção).

Em resumo, os recursos disponíveis em ambos, que eu considero primordiais apra qualquer projeto são:

  • Gerenciamento de Milestones: Que permite definir metas para os projetos. Geralmente uma versão final de um projeto. Eu costumo ter Milestones definidos como “versão 1.0”, “versão 1.1”, etc.
  • Gerenciamento de Tickets: Que geralmente contemplam o registro de trabalho (sugestões, soluções, bugs, etc.) que compõem um Milestone.
  • Wiki: Com a finalidade de documentar o projeto. Contemplam geralmente páginas que apresentam o projeto, documentam sua finalidade, acesso ao Download de binaries, sources finais, etc.
  • SVN/Subversion: Repositório de controle de versão dos arquivos que contemplam o projeto. Indispensável no trabalho em equipe.

O Unfuddle apresenta todas as características acima. No caso do Wiki, o nome do recurso está disponível como Notebook. Ainda no Unfuddle, além de Subversion, é possível adotar como sistema de controle de versão o Git.

O Assembla apresenta uma gama muito maior de ferramentas do que o Unfuddle.

Enfim, são 2 opções que certamente resolvem qualquer necessidade de desenvolvedores/equipes que não possuem infra estrutura própria para gerenciamento de projetos.

Na linha de produtos da Adobe, vale lembrar que o Dreamweaver CS4 possui integração com SVN, bem como o Eclipse que é a base do FlexBuilder com o plugin SubClipse.

Se você quer saber mais sobre SVN. Veja esse post publicado aqui no TeclandoAlto sobre o assunto.

terça-feira, 11 de novembro de 2008

POG ColdFusion para identificar registros que nao podem ser excluidos de uma tabela

Odeio POGs. Em primeiro lugar porque a exigência comigo mesmo faz com que eu não descanse até encontrar uma solução verdadeiramente elegante.

A situação desta vez foi a seguinte: Se vocês repararem, todos os sistemas que a gente encontra por ai, no CRUD apresentam a possibilidade de excluir qualquer registro, verificando no momento da transação (server-side) se aquela ação é realmente possível ou não. Se possível, simplesmente efetiva, senão retorna uma mensagem para o usuário. A minha intenção é já desabilitar a opção de excluir na interface, prevendo tal condição. Para isso, preciso que no momento de mandar os registros de uma tabela para serem apresentados na interface, eu verifique se estes não são referenciados de alguma forma.

Conversando com meu amigo Jefferson Petilo, primeiro definimos o que era óbvio. Precisaríamos no banco de dados que fosse, utilizar as restrições de operação entre registros das tabelas através de chaves estrangeiras. Considere:

Tabela1 (TiposDeImagens):

Campo Tipo Função
id (uuid, int, etc) Chave Primaria
label (varchar) Descrição do tipo

Tabela2 (Imagens):

Campo Tipo Função
id (uuid, int, etc) Chave Primaria
label (var char) Descrição da imagem
tipo (uuid, int, etc) Chave Estrangeira
OnDelete = restrito


Logo depois, por não encontrar nada universal no SQL ou que pudessemos facilmente replicar para vários banco de dados, decidimos que a melhor maneira de verificar registro por registro (no exemplo, da Tabela1, TiposDeImagens) quanto a possibilidade do mesmo ser excluído, seria:

POG_cf_img0_11nov08_17h53m

Porém isso, claro, na ocasião de ser disparado contra um registro que não possui ligações, ocasionaria na exclusão do registro em sí.

Ai entra o POG:

POG_cf_img1_11nov08_17h54m

O <cftransaction> com o ROLLBACK logo após o teste de deleção do registro, garante que o mesmo não seja efetivamente excluído.

Continuando a conversa com o Jefferson verificamos ainda a implementação desta solução via “trigger/actions” no banco de dados. Qual não foi a nossa surpresa ao reparar que o “POG” acabou sendo uma solução bem mais simples de se implementar.

Outra coisa em relação ao uso de “triggers/actions” é o fato de tornar a solução dependente de banco de dados e implicar em se ter várias versões de um código relativo a um mesmo e único recurso. Mas essa é definitivamente outra discussão de prós e contras.

O que fica para mim agora, é o desejo de estudar alguma solução, que seja ao mesmo tempo “elegante” (antônimo de POG, embora eu e o Jefferson tenhamos considerado este POG como “elegante”) e simples de ser implementada.

sexta-feira, 19 de setembro de 2008

Produtividade Flex e Cairngorm com o Factory IDE

riaptblog Recebi essa dica do @vedovelli (Fábio Vedovelli) no Twitter, fui conferir no blog do RiaPT e achei simplesmente sensacional! Eu já tinha procurado por algo assim e não tinha encontrado.

Além de aumentar a produtividade, aumenta também a qualidade do código que produzimos, e nos incentiva a produzir uma boa documentação.

Veja post original no RiaPT

segunda-feira, 18 de agosto de 2008

Nirvana em orçamento de projetos

Stock Photos Eu particularmente não gosto de usar (nem ler) as palavras sem esclarecer seu real significado. Portanto, significado de Nirvana no Wikipédia.

Com anos fazendo orçamento para projetos de desenvolvimento, aprendi que muito mais do que as questões técnicas e científicas (matemáticamente) desta tarefa, bem como teorias para se alcançar o melhor resultado possível para ambas as partes, acaba prevalecendo, pelo menos sempre foi assim com a maioria dos clientes que eu já tive até hoje, o fator: "o quanto o cliente quer pagar". Raramente podemos chamar esse fator de: "quanto o cliente pode pagar", embora isso seja contraditório em relação às alegações que ele faz.

Bom, mas isso não importa. Se o seu pensamento for o de arrancar o máximo que ele pode pagar, além disso ser um desvio de comportamento e uma indicação clara de amadorismo (na minha opinião e por mais capitalista que eu seja/tenha que ser), o que vou escrever aqui não lhe serve de nada, pois você só objetiva o seu resultado e não o do seu cliente.

Princípio: Bom resultado como objetivo sempre!

Já tive muitas vezes a sensação não ter cobrado um preço justo. Porém jamais saí com a sensação de não ter atendido as expectativas do cliente. Essa sensação sim seria extremamente frustrante para mim. Portanto, o que tenho praticado e quero relatar aqui, tem como princípio básico a satisfação de resultados. Parece óbvio, mas tentando sempre aplicar algo para atingir esse objetivo, até hoje eu ainda não tinha feito nada que atendesse em todos os sentidos: facilidade, praticidade, conveniência, transparência, objetividade e rapidez quanto ao processo de se desenvolver um orçamento e negociá-lo.

A matéria-prima da fórmula.

budget01Na grande maioria das vezes o seu cliente solicita um orçamento, mas por mais que ele não tenha a menor condição e critérios para tal avaliação (se ele as tivesse ele mesmo faria o projeto), ele já sabe o quanto ele quer (ou pode) investir.

Por outro lado, você como profissional absolutamente bem informado e capacitado quanto as possibilidades de resolver a questão para a qual o seu cliente necessita de solução, tende a oferecer justamente o que há de melhor e com base na sua visão de solução, definir o custo do projeto.

Na grande maioria das vezes, e falo por experiência própria, devido aos custos, após apresentar a sua proposta de solução, junto com o orçamento, o cliente vai solicitar a revisão, não por uma crítica, mas sim por ajustes orçamentários.

O que acaba sendo aprovado é justamente a solução reformulada que o orçamento atende. Ou em outras palavras, o melhor que você pode fazer, pelo melhor que o cliente pode pagar.

A fórmula: inverter a matéria-prima.

Isso mesmo! Simplesmente hoje eu pergunto ao cliente qual o orçamento que ele disponibiliza para aquele projeto e desenvolvo a proposta com a melhor mão-de-obra, técnica e tecnologia que aquele orçamento pode cobrir.

O impressionante desta forma de tratar o orçamento de um projeto, é que se você procura selecionar bem as tecnologias com as quais vai trabalhar, busca o melhor domínio possível sobre as mesmas, bem como as melhores e mais atualizadas técnicas de desenvolvimento com estas tecnologias, você apresentará ao seu cliente algo que atende e até mesmo supera as expectativas dele. E para isso, você não precisa se tornar minimalista. Pode manter a análise sobre o que você consideraria ideal (aquela primeira proposta que normalmente seria rejeitada), mas apresenta ao cliente um projeto escalonável, onde o resultado do primeiro investimento/fase do mesmo oferece o resultado que ele necessita no prazo requisitado. Ao mesmo tempo, ele terá em mãos suas sugestões de implementação que podem servir de base para investimentos futuros no mesmo projeto sob o qual você já tem domínio. Há aí uma grande possibilidade de demanda para você, sem contar que com isso você já apresentou comprometimento com os resultados esperados pelo seu cliente.

Requisitos

Claro, é importante ressaltar que, se você ainda não pensou: "Vicente, isso não é uma descoberta!", deve então tomar essa frase como uma afirmação minha. Embora eu não tenha pesquisado absolutamente nada a respeito para ter funcionado como base de raciocício e tendo usado somente minha experiência particular de 12 anos atuando com treinamento, consultoria e desenvolvimento de soluções web-based, é muito provável que exista algum estudo que analise e explique melhor esse tipo de forma de encarar o processo de orçamento e negociação de projetos.

Outro fator, talvez mais importante , que cabe a mim deixar claro, é que existem alguns princípios que tornaram para mim possível aplicar essa forma de tratar o assunto junto ao cliente:

  • Os clientes com os quais tenho aplicado essa forma de negociar o orçamento de um projeto, são clientes que já tiveram a oportunidade de avaliar o meu trabalho de alguma forma anteriormente.
  • O processo de análise (levantamento de requisitos, casos de uso e outros diagramas e documentações) é exatamente o mesmo. Extingue-se apenas o processo de reavaliar o projeto posteriormente. Portanto não encare o que estou colocando aqui como forma de otimizar o seu trabalho de formalização de um orçamento técnico.
  • Deve-se tomar o cuidado de não penalizar o cliente para favorecer a si mesmo. Ou seja, para tornar um projeto escalonável, acaba-se consumindo um esforço e consequentemente tempo, ligeiramente maior do que se considerar aquela etapa como única. Quero dizer, em favorecimento a sua previsão de melhorias futuras ao sistema, pode-se consumir um tempo/esforço de desenvolvimento a mais, para permitir certas implementações futuras, que acabará refletindo num custo para o cliente, na etapa para a qual ele está investindo em uma solução que o atenda já. Deixe isso claro na apresentação da sua proposta de projeto. Ele pode preferir, ao custo de tornar futuras implementações mais caras, melhorar o resultado da primeira etapa. Seja com custos relacionados a treinamento, implantação/homologação, etc. que poderíam ser extendidos, melhorados em recursos, caso eliminado algumas tarefas inerentes a recursos futuros imaginados para o produto em questão.

quinta-feira, 15 de maio de 2008

Grupo de estudos Flex AIR AS3 em Salvador, Bahia

grupo_estudos_banner01 

O Osmundo (vide blog), instrutor e consultor da iTraining, anunciou hoje o grupo de estudos a iniciar-se dia 22 de maio, as 17h, na sala de treinamentos da iTraining em Salvador/BA. Este grupo, terá como tema de estudo, as tecnologias Flash, Flex, Flex Builder, Actionscript, FlashPlayer e AIR. É previsível que a partir deste, outros grupos sejam formados.

Fui convidado para abrir o grupo de estudos. Convite este que me deixa muito feliz e orgulhoso. Será muito bom estar estudando, evoluindo e tentando colaborar em algo com algum conhecimento que já tenho nessas tecnologias. Sei que vou aprender muito, pois não há motivação maior do que ter pessoas precisando das mesmas respostas que você.

Sobre como será minha pequena contribuição:

Não quero usar da oportunidade só para fazer uma apresentação. Então quem estiver presente, pode aproveitar para tirar qualquer dúvida (sobre os primeiros passos, nessa primeira oportunidade, só para ter foco nivelado) que o meu pouco conhecimento puder esclarecer.

Como se trata de um grupo de estudos, então vou aplicar uma linha de introdução aos estudos dessas tecnologias (AS3/MXML/Flex/AIR), orientando sobre os primeiros passos, questões quanto a configuração e sugestões nesse aspecto, como buscar ser auto-suficiente para esclarecer dúvidas usando a documentação e etc.
Quero dar dicas também quanto a performance no desenvolvimento de aplicações.
Adicionalmente devo apresentar alguns recursos que complementam o meu ambiente de trabalho e que creio eu, podem vir a serem úteis para quem for aplicar profissionalmente esses tecnologias no seu dia-a-dia.

Não esperem que eu vá preparar slides e etc. O que eu estarei mostrando aos presentes, é o que eu faço no meu dia-a-dia como desenvolvedor com foco nessas tecnologias.

E lembrem-se, não quero fazer uma palestra. Quero iniciar um grupo de estudos, colocando em foco as questões práticas. Também não será uma aula pois o tempo não permitiria e eu não a faria sem um bom preparo estutural da sala, de equipamentos, softwares, material e etc.

A intenção é que quem participar, saia doido(a) para chegar em casa e começar a praticar!

quarta-feira, 14 de maio de 2008

Utilidades do Subversion SVN

subversion O Subversion, também conhecido simplesmente como SVN, é um recurso que se tornou indispensável no meu trabalho de consultoria e desenvolvimento, assim como na verdade é para qualquer profissional desta área.

O Subversion foi a proposta da Tigris em substituição ao CVS, implementando muitas diferenças que estão bem documentadas com o produto.

Aos que iniciam ou procuram mais informações a respeito, resolvi colocar aqui um pequeno texto relatando a utilidade prática de uso do Subversion:

Introdução:

Numa apresentação mais breve e superficial possível, o Subversion é um sistema de gerenciamento e controle de versão de artefatos dispostos em um repositório. Este repositório compreende uma estrutura gerenciada pelo sistema servidor da solução. Através de ferramentas clientes, o usuário irá interagir com essa estrutura.

O sistema servidor permite designar usuários, para fins de identificar o autor de modificações no repositório e atribuir aos mesmos níveis de acesso.

O workflow de uso do SVN geralmente é o seguinte:

  1. O repositório é criado
  2. Os usuários e seus devidos níveis de acesso são determinados
  3. Algum conteúdo inicial é colocado no repositório para ser gerenciado (initial commit)
  4. Os usuários fazem uma cópia local dos arquivos para fins de consumo ou colaboração no desenvolvimento (checkout)
  5. Os usuário com permissão para modificar o conteúdo efetivam suas alterações locais no repositório (commit). Esse passo pode envolver ainda diversas outras situações como verificar conflito entre o codigo enviado neste momento e alguma modificação realizada no repositório feita por outro usuário, entre o "checkout" e essa tentativa de "commit" das alterações locais.
  6. Os demais usuários verificam modificações no repositório (synchronization) e atualizam suas versões locais (update). Se o usuário modificou algum arquivo, as situações de conflito entre modificações do conteúdo no repositório e conteúdo local do passo anterior podem ocorrer e o usuário terá como resolver as mesmas com instrumentos simples.

Estabelecido o servidor, suas utilidades podem ser apresentadas em basicamente 2 perfis, conforme relato adiante.

Para o desenvolvedor de conteúdo:

É um sistema que permite controlar a versão dos artefatos que fazem parte do repositório (geralmente códigos-fonte). Ao mesmo tempo, permite, de maneira imperativa (forçada) ou passiva (facultativa) documentar as modificações em cada artefato. Essa documentação se dá no momento de enviar para o repositório (commit) um artefato que foi alterado.

Para o consumidor

Ter uma maneira "atômica" de atualizar e acompanhar as modificações no mesmo. "Atômico" refere-se ao fato de que o sistema é capaz de atualizar somente a parte alterada de um arquivo modificado na fonte. Por exemplo, imagine um arquivo de 8MB no repositório. No primeiro momento (checkout) vc baixa os 8MB para estar em sincronismo com o repositório. Nas atualizações / modificações (updates), você vai baixar somente os "bytes" que diferem a sua versão local do arquivo. Se você for uma das pessoas autorizadas a modificar a fonte (repositório) o mesmo acontece na hora de "enviar" as modificações (commits). Você não precisará fazer o upload de 8MB e sim, apenas dos "bytes" que alteraram a versão no repositório.

Links:

  • TortoiseSVN
    Client para interagir com um servidor/repositório SVN, que integra-se ao sistema operacional.
  • VisualSVN
    Ferramenta de administração (criação de repositorios/controle de usuários).
  • Subclipse
    Plugin de integração com Eclipse IDE. Como o FlexBuilder da Adobe baseia-se no Eclipse, o plugin também é funcional nele.

domingo, 24 de fevereiro de 2008

Teclado Optimus Maximus

optimusmaximuskeyboard Definitivamente eu queria ter US$500 pra gastar com um teclado!

Não seria apenas um "brinquedo" interessante, mas é definitivament produtivo!

segunda-feira, 12 de novembro de 2007

Dica: Estatísticas Web

w3counter Para quem gosta de se manter atualizado quanto a determinadas estatísticas relacionadas ao ambiente Web para o qual desenvolvemos, este site é de grande utilidade. Confesso que há muito tempo a questão de interface pra mim não era lá muito problema porque o destino do conteúdo que desenvolvo na maioria das vezes é para um público alvo concentrado e com perfil bem definido. Mas o que gostei de ver nessas estatíticas mundiais de Web foi que finalmente 1024x786 pode enfim ser considerado um target padrão de desenvolvimento.