Tava com saudades aqui do blog. Ae uhaeuhAEae A correria na Giran ultimamente está pra lá de frenética e estou estudando muito pra escrever algumas coisas legais aqui e de relevância.

Rolou hoje o II Workshop PHP-ES na UVV e posso dizer que por um lado foi muito foda e pelo outro um pouco triste.

O que foi muito foda

As palestras foram altamente maneiras. Um review muito bacana do rolou está no blog do Xiquin (http://www.franciscosouza.com.br/2010/08/28/ii-workshop-de-php-do-espirito-santo-foi-show), que palestrou sobre CodeIgniter com o André Tagliati, vulgo Gligli. A palestra dos dois, inclusive, foi muito bacana assim como as palestras do Marcelo Raposo sobre práticas mágicas no MySQL e de PDO com o mestre Almir M3nd3s.

Outro ponto foi a abertura do evento para assuntos fora do eixo técnico para ir para o entorno no mundo PHP, como a plafatorma Moodle com o Lucas Coradini (nunca pensei que um designer botaria banca num evento de programadores hehehhe zuera sacanagem) e a metodologia Scrum com o Paulo Jeveaux e o Makoto Hashimoto. A escolha dos assuntos não poderia ser mais feliz, porque nas contas finais eu achei as duas palestras mais informativas pelo público presente.

Este público presente foi outra surpresa: a imensa maioria era de pessoas do interior do estado, como Cachoeiro, São Mateus e Pinheiros. Isso nos mostrou o quanto de espaço pode-se ter junto a um público que geralmente só tem acesso a informação desse tipo vindo pra cá. Tivemos alguns contatos e esperamos levar eventos de PHP para lá.

O evento transcorreu muito bem e no geral foi muito bacana até mesmo pra mim que fui sob efeito de muitas drogas anti-gripais. O sorteio no final foi um show a parte de integração e diversão com direito até a contribuição de um brinde por parte da platéia (valew Fabiano!).

Por último, o apoio PRA LÁ DE F*DA da UVV e do prof. Vinicius Rosalen, que não apenas nos cedeu toda a estrutura para a realização do evento como ajudou com café e rosquinhas pela manhã e a tarde. E também da Giran, pela mobilização geral do pessoal no preparo de conteúdo, palestras para o evento e apoio incondicional na organização do evento.

O que foi meio triste

Palestrar, terminar slides, organizar evento e tocar evento doente é foda. Aliás, qualquer coisa nessa situação é foda. Queria ter estado melhor mas no final das contas estar doente foi apenas um empecilho.

Ter no cast de palestrantes uma galera da Giran foi uma honra pra gente, mas por outro lado mostrou uma coisa que quase inviabilizou o evento: não tivemos NENHUMA palestra submetida pelo grupo de usuários que povoa o fórum. Parece que as pessoas preferem discutir coisas abstratas como sindicato de programadores PHP (sic) que movimentar e dar apoio aos eventos da própria comunidade.

Seguindo a lógica, de 260 pessoas inscritas não tivemos nem a metade que seria o normal. E dos que compareceram uma galera era do interior e poucas pessoas da Grande Vitória. Agora não sabemos se há um desinteresse total das pessoas da Grande Vitória por PHP, se os tópicos das palestras foram mal escolhidos ou simplesmente as pessoas se cadastram por diversão. (risos) Isso trouxe um efeito bacana que é agora nossa vontade real de levar esses eventos para o interior.

Enfim …

Para um evento que esteve no limiar do cancelamento por falta de ânimo com um cenário onde nem palestras haviam para fazer o evento, foi um PUTA evento e que me recorda o feeling que eu tinha quando tocava heavy metal em shows que as vezes só sobravam 5 pessoas na frente do palco: você está ali pelas pessoas que ainda acreditam no ideal e no que você acredita e por elas VALE MUITO A PENA.

Simbora.

E lá vamos nós de novo:  depois de muitas barreiras, desanimo de fórum e até mesmo o pensamento de desistência, é com prazer que a venho confirmar a realização do II Workshop PHP-ES.

O evento acontecerá no dia 28 de agosto (último sábado) na UVV, das 8:30 às 18:00 e  será gratuito: estamos tentando alguns patrocínios para bancar um Coffee break básico mas até segunda ordem vai ser tudo o mais básico possível.

A grade confirma é:

PHPZeiro: Adote um Framework (Léo Hackin)

CodeIgniter: turbinando a produtividade com MVC (Francisco Souza e André Tagliati)

MySQL: Técnicas simples e eficazes para tirar o máximo do seu servidor Mysql (Marcelo Raposo)

PHP Data Object – Interface única de comunicação com SGDBs (Almir “M3nd3s”)

Moodle: fazendo EAD de qualidade com PHP (Lucas Coradini)

Aprendendo a começar um projeto com SCRUM (Time da Giran)

Como sempre, a idéia dos eventos de PHP-ES é agregar conhecimento aos desenvolvedores PHP não só da linguagem mas também em todo o seu entorno. Nesta edição vamos mostrar como as frameworks, como o CodeIgniter e o PDO, podem ajudar na produção de aplicativos de modo mais sustentável. Falando em base de dados, teremos uma palestra de “tunning” e macetes para fazer um ajuste fino do MySQL que foram feitas em cima de uma base de verdade com o DBA dela.

Vamos exibir também um case real e de sucesso feito com o Moodle, uma ferramenta PHP de Ensino a Distancia (EAD). No final do dia teremos um workshop de como iniciar um projeto com Scrum, metodologia ágil que está sendo bastante utilizada em várias empresas de desenvolvimento pela sua flexibilidade.

As inscrições pode ser feitas pelo link no página press-release do evento:

http://www.phpes.org/ii-workshop-php-es/

Estamos ainda à procura de patrocionadores e apoiadores: se estiver interessado ou conheça alguém afim de bancar o coffee break, peça para mandar um e-mail para leohackin@gmail.com ou m3nd3s@gmail.com.

Para mais informações acesse: http://www.phpes.org/ii-workshop-php-es/

Um abraço forte e até lá.

Salve pessoal,

Resumir num post apenas o impacto de um evento da importância do AgileBrazil 2010 na vida de um desenvolvedor/gestor é complexo mas vou tentar dar apenas uma pequena e humilde visão do que foi isso.

Remontando alguns fatos, a Giran hoje trabalha muito fortemente com metodologias ágeis (Scrum/XP) a mais de um ano: ou seja, desde que montamos ela. heheh Mas é com o passar dos dias, projetos, pessoas, dificuldades e experimentos é que se consegue ter as reais motivações da definição dos valores do Manifesto Ágil e das técnicas usadas para se manter uma empresa ágil…

Mas ser ágil é o quê? Implementar o Scrum, seguir tudo que o manifesto ágil prediz, fazer religiosamente todas as fases antes e durante uma sprint: não quebrar as regras que agilistas e metodologias dizem? Ou seja, respeitar o processo do início ao fim? Você se mantém assim porque sua empresa é realmente ágil ou tornou sua empresa “ágil” apenas para dar um nome mais bonito ou mais hype pro seu “processo” batido do dia-a-dia com incrementos pra tentar levantar o moral da equipe e/ou vender sua empresa como uma empresa “inovadora” ou “jovem”?

É exatamente em eventos como o AgileBrazil que a percepção em relação à isso se torna EXTRAMAMENTE palpável, visível e de um bom senso tão argumentado e lapidado que chega a ser engraçado como as pessoas e as vezes nós mesmos não conseguimos enxergar algo que está na frente do nosso nariz.

A tônica do evento foi uma: você é realmente ágil? Está nessa pela fama | grana | hype ou qualquer coisa que realmente possa fomentar algo positivo pra sua empresa? Bote a mão no coração e pergunte pra si mesmo: porque você quer ser ágil ou se acha ágil?

As flexões mentais em relação à isso foram levadas a cabo por vários dias (no meu caso por dois) e horas, ensinados, desmontados, analisados e remontados por vários e principais nomes do movimento ágil do brasil e no mundo! Sim, O Martin Fowler em pessoa abriu o início das palestras e jogou luz onde geralmente ninguém vê (ou não gosta de ver).

Com uma estrutura de tirar o chapéu, feito na PUC com uma puta estrutura, uma bolsa com caneta, bloco e até caneca, a organização foi impecável em todos os sentidos possíveis. E o networking … essa parte foi um show a parte. Como disse pros brothers da Bluesoft, é muito foda ver as pessoas fora dos quadradinhos do Twitter e ver que elas são muito mais bacanas ao vivo.

Como eram muitas palestras, eu e meus companheiros na expedição (@jeveaux o @makoto_vix) nos separamos para cobrir o máximo de assuntos. Descrever tudo o que conseguimos absorver nesses dois dias ainda está cedo e talvez vire até post mas resumidamente vi:

• Gente usando BDD/TDD pra substituir boa parte da documentação da descrição de requisitos (coisas que o cliente quer)
• Como otimizar bastante do processo de TDD e torna-lo mais suave
• Como ir além no uso do kanban
• Integrar GTD + Pomodoro + Scrum + Platão (sim, rolou até platão)
• Nomes de vários livros e sites FODARASSOS
• Monstros da agilidade andando ali do lado
• Porque a Giran é ágil …
• E porque eu quero continuar com ela SEMPRE ágil

Se teve partes ruins? A única parte ruim é a saudade de casa, o café que acabou MUITO rápido nos coffee breaks e o cansaço nos aeroportos. Do resto, tudo muito foda.

E o que senti de verdade: é MUITO bom estar entre gigantes da agilidade e reconhecer que tenho (temos) que crescer, estudar e amadurecer muito e sempre. E ainda bem que existem eventos como esse pra irmos todo ano e continuar cada vez mais humildes, felizes … e ágeis.

\\// Vida longa e próspera a todos.

Indivíduos e interação entre eles mais que processos e ferramentas

Mas até que ponto nós, não apenas como desenvolvedores mas como pessoas, levamos à cabo como agilistas ou simpatizantes de metodologias ágeis esse princípio? Mais que isso: até que ponto temos consciência de quanto esse princípio rege não apenas processos mas todo o entorno e mais dramaticamente TUDO num projeto quando pensamos que TUDO é usado, avaliado e aprovado por outras PESSOAS.

MUITO MAIS que resultantes de desempenho, produtos de qualidade e projetos mais humanamente sustentáveis, esse princípio trabalha muito intimamente com o sucesso de uma empresa, marca e seus serviços.

Dúvida?

Meu problema com travas elétricas

Quem me conhece, ouvia muito falar uma frase quando pegavam carona comigo (um carro 4 portas) e viam que as travas estava todas manuais: “Vou levar meu carro amanhã pra consertar…“.

O problema não era inteiramente meu: apesar de ser um cara enrolado, existe um processo chamado “Agendamento” da concessionária que:

• limitava-me a levar o carro bem cedo com um dia pré-agendado
• me fazia deixar o carro lá e conhecer, em tese, o problema real na parte da tarde e com a possibilidade de pega-lo apenas no outro dia
• me fazia voltar pro trabalho e sair dele pra pegar o carro de busão

Apesar de tudo, o processo funcionava bem dentro de um certo contexto, pois não precisava enfrentar fila de atendimento, com sorte eles lavariam meu carro (de grátis), seria feito por profissionais (recurso ou indíviduo?) treinados pra mexer com o meu carro e existia um prazo médio (embora pouco confiável) que poderia sair com o carro consertado no mesmo dia.

Os processos são muito importantes, principalmente em empresas de maior porte onde o padrão de qualidade do produto/serviço depende bastante de um fluxo de ações e validações que certifiquem que as coisas vão funcionar bem sempre e de um modo controlado. Em pequenas empresas e pequenos grupos de trabalho, um processo pode ser substituído em partes (ou até totalmente) por indivíduos e interações.

MESMO nas grandes empresas, ainda sim, os indivíduos e interações podem fazer uma extrema diferença na qualidade: afinal, todo processo é suscetível à inconsistências e nesse ponto o indivíduo, com sua experiência e todo tipo de qualidade pessoal, vai fazer diferença.

Então qual o problema/diferencial no processo? São os indivíduos.

Indivíduo #fail: o atendente/consultor (ou quem está na frente)

Liguei para a concessionária e fui atendido por um indivíduo que atendeu-me prontamente, mas com uma certa impessoalidade incômoda, e agendara meu atendimento para as 8:30 de um dia naquela semana. O dia chegou e o alívio/sossego/esperança de não ter que sofrer mais piadas como “[tom irônico] Amanhã né Hackin?” era tão latente que o dinheiro a ser investido na resolução do problema, naquele momento, era o de menos (não, eu não sou rico … quem pode falar coisas sobre ricos é meu amigo @makoto_vix).

Cheguei para o atendimento e o indivíduo atendente me chamou pelo horário, pelo “quem chegou primeiro?” e só depois pelo nome. A contar que não era o único ali, isso passaria batido pelo meu autruísmo exagerado se não fosse pelo tratamento recheado de “Uhun”s, de “Sei”s e sem uma resposta muito convincente ou entendível ao meu “Bom dia!” recheado de dentes: aquele estava sendo um bom dia pra mim, será que pra ele não? Seja lá qual o problema, estava diante de um indivíduo totalmente guiado pelo processo.

Um indivíduo guiado pelo processo é como estar em piloto automático: não importa o que você seja, ele esta ali apenas para dar fluxo ao processo. A dispêndio de energia e atenção se limita apenas ao que é necessário para concluir o processo. Talvez quem você é po$$a significar algo e otimizar um pouco as coisas.

O indivíduo atendente então me passou o número de meu atendimento e pediu-me para que ligasse por volta das 15:00 para saber do meu problema. Será mais econômico ao processo eu ligar para saber sobre meu carro ao invés do indivíduo? Liguei e fui informado que parte do serviço tinha sido feito (tinha pedido também pra alinhar e balancear) e que o problema das travas estava sendo concluído: eu poderia pegar o carro ao final da tarde. A esperança do produto em mãos me fez deixar pra lá uma interação linear e sem contato humano com este indivíduo.

Às 18:25 chegava na concessionária e recebo a notícia de meu indivíduo atendente que o alinhamento do meu carro não tinha sido feito e que não tinham ainda descoberto o problema real das minhas travas: de acordo com indivíduo atendente, o indivíduo técnico estava com a caixa de fusiveis e tudo mais aberto lá. Como o horário de fechamento era às 18:45, apesar de muito chateado – quase puto – resolvi esperar dizendo que precisava do carro e se talvez rolasse dele descobrir algo nesses 20 min: recebi um “talvez, mas eu acho difícil…”.

5 mins depois o indivíduo atendente me informa que o problema poderia ser que as 4 travas elétricas tinham queimado simultaneamente devido a algum curto e que o valor do conserto seria de R$ 1.000,00. Questionei como 4 travas poderiam queimar ao mesmo tempo e a resposta foi um “Eu também achei bem estranho e se quiser posso conferir com o responsável pela oficina amanhã“. Amanhã? Levei o carro sem consertar as travas e voltei para fazer o alinhamento (e perder mais tempo) dois dias depois. Estranhamente uma indivíduo atendente me ligou perguntando porque não havia levado: porque não haviam me ligado assim no mesmo dia para falar sobre meu carro ao invés de me fazerem ir até lá?

A história é meio grande propositalmente para apontar bem os detalhes do atendimento. Podemos detectar alguns problemas propiciados não pelo processo, que possivelmente não tinha problemas salvo algumas melhorias, mas pelo indivíduo que disparou as ações do processo:

• o tratamento impessoal causou um efeito anti “Efeito UAU! de atendimento” (sou programador, mas aprendi com grandes pessoas grandes coisas – valew Márcio Gomes! – que me fizeram uma pessoa e profissional melhores): não me surpreendeu, nem encantou e isso ajudaria bastante à experiência de uso num todo. Mesmo com um resultado abaixo do esperado ou sem nenhum resultado, minha experiência de uso teria sido boa se a empatia do indivíduo envolvido diretamente em minha interação tivesse sido melhor
• as pessoas são guiadas muito mais pela sua experiência de uso do que as vezes pelo preço: 1k poderia ser um valor justo por um serviço “especializado” se minha experiência de uso estivesse sendo boa. A insatisfação inicial gerou enfim o questionamento sobre o valor e a vontade de “pexinxar”. Quem nunca parou e comprou algo na primeira loja apenas porque o indivíduo envolvido no processo era tão bom que lhe fez sentir-se seguro com a compra.
• o indivíduo comprometeu a confiabilidade do processo quando
  • me relatou que meu carro tinha apenas o problema das travas para resolver quando nem o alinhamento havia sido feito
  • demorou 5 mins orçar e relatar um problema que em tese não tinha sido feito nem descoberto por todo um dia mas por “mágica” foi feito em 5 min
• o indivíduo se aproveitou dos gatilhos e ações do processo para conclui-lo mas de forma a startar apenas mais um processo para quem é dependente dele.

Então, do que adianta investir num processo bem feito se os indivíduos envolvidos na sua execução não estão “comprometidos”?

Várias empresas da área de tecnologia e desenvolvimento ainda acreditam que investir em processos seja melhor para a empresa do que investir nos indivíduos que executam esses processos. Você como empresário ou como desenvolvedor ainda acredita nisso? Tente imaginar algumas situações como:

• Quanto do seu processo de relacionamento é otimizado pelo indivíduo que se relaciona diretamente com seu cliente, tanto na questão de prazos e requisitos quanto em tudo o que envolve o que não é diretamente relacionado ao processo mas tem TUDO para tornar a conclusão ou qualidade dele excelentes?
• Quantas descisões são influenciadas pela empatia dos indivíduos envolvidos no processo?
• Quanto da qualidade final do seu produto é impactado diretamente pelo indivíduo, devido às suas idéias mais que suas certificações?
• Qual é seu melhor quantitativo de desempenho: um processo que segue seu fluxo de forma correta ou os feedbacks positivos de seus clientes em todas as esferas possíveis?
• Como você garante que todas as etapas/ações de seu projeto estão gerando o máximo de retorno para o seu cliente? Ligações pós-atendimento de avaliação não conseguem desfazer o pior dos estragos que é a experiência de compra abaixo do UAU! ou até mesmo abaixo do mínimo aceitável para cada cliente.

Imagine-se como um cliente e todas as situações como essas que passei e pergunte-se de forma analítica, pessoal e envolvendo o que você avalia como importante num atendimento:

Na minha empresa o que me traz diferencial são os indivíduos ou meus processos?

Indivíduo #WIN: numa oficina de 5 indivíduos funcionários

Como sou brasileiro e não desisto nunca, aproveitei o feriado para procurar uma oficina. Numa cidade ao lado encontrei uma oficina com 5 indivíduos funcionários, entre eles o indivíduo dono.

Prestativo, um indivíduo funcionário me recepcionou de forma informal mas muito pessoal, perguntando como estava o dia e como poderia me ajudar. Expliquei meu problema e ele de pronto afirmou que quando uma trava parava todas paravam e poderia ser um problema no módulo. Pediu-me 10 min para que um outro indivíduo, que “mexia melhor que ele” com travas, pudesse me atender.

Esperei por 25 mins, mas com 2 ou 3 interações dos indivíduos da oficina me dizendo que não demoraria muito. O processo até aquele momento me parecia simplista e até intuitivo, mas a interação do indivíduo me trouxe uma calma do tipo “Sem problema, vou aproveitar pra ler um livro“. Findada a espera, José me deu bom dia de uma forma humilde e pessoal, abriu o painel onde ficava o módulo, mexeu pra um lado e pro outro vários fios e em 15 min ele me disse: “Deve ter rolado um curto circuito, pois a corrente chega aqui – me apontando a porta – mas as travas não funcionam. Vamos ter que trocar as 4 travas.”.

Minha experiência de uso estava sendo muito bacana, mas lembrar dos R$ 1.000,00 me deram um amargo na boca até que ele disse “O jogo de travas e o serviço fica por R$ 280,00 e você pode pegar no final do dia“. WOW!!!!!

Pára tudo …

• Atendimento UAU!
• Preço UAU!!
• Prazo UAU!!!!!!

Assenti prontamente mas às 18:00, chegando com pontualidade inglesa por sorte, meu carro ainda estava faltando a ultima trava da porta. Durante os testes, um dos indivíduos dissera que o pino da porta da esquerda estava meio enpenada e a porta não tava fechando direito mas que já tinha ACERTADO ela para mim e agora estava “filet”. 40 mins depois do horário dos indivíduos e meu carro estava pronto, com teste geral de lanternas, vidros e tudo mais. Um “Boa noite” cheio de cansaço mas sincero até a ultima vogal.

O processo estava ali escancarado no final das contas:

• Receber o cliente
• Verificar o problema
• Passar orçamento e prazo
• Executar o serviço

Algo muito próximo e parecido com o da concessionária, mas o que fez a diferença COMPLETAMENTE foram os indivíduos… o José mereceu os R$ 15,00 da gorjeta pra tomar umas na sexta a noite e a oficina minha moral eterna pela ótima experiência de uso que acabara de ter.

• o indivíduo proporcionou qualidade a um processo que prevê ações definidas mas que cobre apenas em parte a real experiência de uso de um usuário
• o indivíduo, mais que o processo, é quem de verdade proporcionou a validação positiva do processo
• processos são inflexíveis, lineares e o que se poderia ter de “inteligência de decisão” são nada mais que algoritmos que não se comparam à empatia e tato que um indivíduo pode ter no momento de uma venda
• um processo não reconhece um sorriso como um feedback válido para alteração de um fluxo
• processos podem burlar indivíduos, indivíduos podem ser burlados pros processos, mas é bem mais difícil um indivíduo burlar outro indivíduo (as vezes hahaha)

Construindo uma marca com indivíduos

Depois de tudo isso, podemos ter uma noção melhor do quanto o indivíduo pesa muito mais numa empresa que um processo. Empresas grandes e flácidas tem um grande problema quando trabalham com zilhões de funcionários e não conseguem detectar de forma enfática e hábil quando esses indivíduos fazem perder todo o processo ou pior: não conseguem enxergar quando esses indivíduos é que fazem toda a diferença no atendimento.

Podemos citar aquele garçom que você sempre procura no bar, aquele mecânico que você conhece pelo nome e não pela oficina em que ele trabalha… os indivíduos são nossa referência nos lugares em que vamos e mantemos um link de confiança e segurança. Quando temos pontos qualitativos sob a forma de indivíduos exemplares em nossas empresas, nossa empresa se torna mais pessoal, mais próxima de quem faz nossa empresa crescer: os usuários.

Agora, se a sua empresa é ainda pequena ou seu centro de produção ainda é restrito a um grupo menor, porque você ainda valoriza mais processos do que indivíduos?

É incrível como varios empresários ainda acreditam que os indivíduos são todos substituíveis, como porcentagens num planilha ou recursos no gráticos Gantt, e que os processos da empresa são o suficiente para a empresa continuar saudável … mas será que estabilidade é sinônimo de sucesso ou apenas de “acomodação”. Empresas não quantificam de forma efetiva o quanto de capital social e humano perdem quando deixam de aumentar um salário em R$ 100,00 ou proporcionar um ambiente de trabalho bacana para um indivíduo que pode representar a qualidade que seu processo tenta emular ou manter de forma artificial e não tão efetiva.

Exemplo clássico é a Giran, empresa em que trabalho e que me serve de inspiração para muito do que sempre pensei com meu sócio Jeveaux.

A Giran é construída pelas pessoas que a compõem: idéias, confabulações, inovações, melhorias de gestão, contratações e até o café que tomamos é uma decisão tomada pelos INDIVÍDUOS que temos em nosso time. Nada escapa ao julgamento das pessoas e nossos processos é quem acabam trabalhando a favor dos indivíduos e felizmente não o contrário.

O que a empresa é hoje lá fora é o reflexo do comprometimento e profissionalismo das pessoas que estão lá dentro. A “marca” Giran não é fruto de um processo admirado por todos: as pessoas admiram uma marca pelo que ela proporciona à elas. Em nosso caso, as pessoas sempre nos elogiam pela nossa abordagem, às coisas e problemas que estão à nossa volta de forma transparente, sincera e fluída. E quem faz isso são nossos indivíduos.

Indivíduos, Indivíduos …

Depois dessa Bíblia, a flexão mental sobre o quão importante um indivíduo é antes do processo tomou um bom rumo, mas longe de chegar ao tremendo brainstorm que isso pode se tornar dentro de sua empresa, entre seu time ou mesmo com parceiros, sócios e quem mais seja importante.

Alguns funcionários, pessoas ou “recursos” não tem a real noção do que eles são dentro de um organismo tão complexo quanto a experiência de uso que deve ser proporcionada às pessoas que se relacionam com ela.

• um e-mail áspero de um programador, pode gerar um sentimento nada bacana com um cliente na frente
• o modo como seus funcionários se comunicam com seus fornecedores e cliente pode estar gerando maus sentimentos
• um “Bom dia … tudo certo” e um  ”Abraço” no final de um e-mail pode fazer a diferença (para melhor ou pior)

Agora imaginou o quanto você, do outro lado da moeda, já passou por isso e sabe (sinceramente) o quanto isso fez a diferença?

Pense nisso.

É com IMENSO prazer que a Giran recebeu um convite para apresentar um case de sucesso na QCon SP este ano …… o que é a QCon????

QCon São Paulo – O principal evento de arquitetos e desenvolvedores chega a América Latina. O QCon SP traz, dias 11 e 12 de setembro, ícones internacionais e nacionais de diversas áreas, com apresentações de alto nível técnico. Com sistemas cada vez mais complexos, o QCon aborda não apenas uma única tecnlogia ou aspecto: passa de Java, .NET e Rails até Arquitetura, Design, Cloud, Escalabilidade, Replicação, Cache e casos de sucesso. Serão dois dias com mais de 40 palestras de alto nível.

O case que será apresentado será o da WINE.COM.BR, o maior e-commerce de vinhos da América Latina e eleita esse mês como uma das 5 lojas mais rápidas da internet brasileira dentre as GRANDES. A Giran é responsável pelo desenvolvimento, manutenção, extensão, novas implementações … enfim: exceto pela parte de design, fazemos tudo. =) Hoje MUITO mais que cliente-fornecedor, somos parceiros e amigos e isso é um ingrediente muito importante pra tudo isso dar certo.

Ou seja, é difícil expressar, tanto como desenvolvedor como empresário, o prazer/realização/felicidade que é receber um convite desses depois de um ano de trabalho duro, sério, feito com carinho mas principalmente do jeito que a gente sempre pensou que daria certo… e DEU!

O que nos deixa mais felizes ainda, é exteriorizar com fatos CONCRETOS que a Giran é o que é pelas pessoas que estão dentro dela, o que pra muita gente é apenas conversa ABSTRATA. Chegar num ponto desses é apenas uma constatação que existe sim vida (e que vida… hehe) após o SCRUM/Pair Programming/DailyScrum/XBOX/Cerveja-e-refri-na-geladeira/Pessoas-ao-invés-de-recursos-e-porcentagens até num mercado que muita gente critica pela falta de recursos como o do ES.

O case será apresentado pelo irmão-sócio-amigo Paulo Jeveaux e o nosso padawan, em breve Jedi, Gabriel Benz (@glbenz … tá na hora dele fazer um blog) junto com outras palestras com grandes nomes nacionais e internacionais.

No blog do Jeveaux tem um post bacana sobre o que será abordado e tudo mais!

Que força esteja com vocês e vida longa e próspera. \\//

Aloha! O cálculo parece ser uma piada, mas na prática é o que este pequeno post vai tentar explanar e pontuar: programação em par rende e faz bem ao projeto, seja você uma equipe ágil ou não.

Programação em par (pair programming) é uma das práticas pregadas pela XP (eXtreme Programming) e metodologias ágeis em geral. Pra lá de polêmica (principalmente entre os gerentes de projeto e de “recursos”) a programação em par é o terror das empresas com poucas pessoas e/ou projetos com escopos malucos e sem vivência ágil, mas é exatamente ai que ela pode ser tornar uma puta aliada ao time, à empresa e aos projetos.

Como o próprio nome já diz, a programação em par descreve a prática de desenvolver software em par no mesmo computador: enquanto um programa o outro fica de “papagaio de pirata”, apontando erros, sugerindo coisas e pentelhando o amigo que está desenvolvendo. Elas se revezam no teclado de tempos em tempos e os objetivos disso são muitos.

Um segura, o outro bate

João e Joca prontos!

Na vida real isso seria uma covardia, mas estratégicamente falando o fato é que se você entra numa briga com um amigo (principalmente que já chega na voadora) tudo fica MUITO mais fácil: você intimida o inimigo, aumenta a auto-confiança e a chance de ganhar a batalha de forma muito mais rapida e efetiva aumenta dramaticamente.

Num projeto isso soa da mesma maneira: a troca de experiências, fundamentos e principalmente sinergia de aptidões e especialidades eleva o nível de programação. O programador menos experiente ganha experiência e macetes. O programador mais experiente, refina seu conhecimento, encara novas possibilidades apresentadas pelo mais novo e lapida de forma fina conceitos da forma mais didática possível.

Então, existem vários pontos e consequências muito positivas quando você, gestor, e você , desenvolvedor “super-homem” e “lobo solitário”, programa em par:

• a troca de conhecimentos fica transparente entre o par e o modo mais bacana de implementar aquele regra de negócio que “só o João é que sabia”  agora é sabida pelo Pedro, Joca e José;
• a abdução pelo MSN/Talk/Twitter (ou as coisas que distraem) será bem menor devido à presença do par ao lado pensando “Coé! Vai trabalhar ou não p*rra?”
• essa é pros gestores não ágeis: programação não é apenas digitação (= trabalho mecanizado) e sim um trabalho de escolha (tentativas corretas ou erradas). E nisso duas pessoas se saem BEM melhor (seja a caminho do #epicwin ou #epicfail).
• o vínculo pessoal aumenta entre o par e com isso a confiança se fortalece, acabando ou diminuindo o “se fosse eu teria saido melhor”
• com a confiança aumentada, o par passa a se comprometer ainda mais com o resultado final de forma muito natural, afinal a pessoa não quer deixar seu novo amigo na mão (e nem a oportunidade de fofocar um pouco durante o pareamento)
• as soluções encontradas tendem a serem melhores documentadas/implementadas
• psicologicamente, o par sempre vai querer mostrar “o seu melhor” para o outro
• quando o par não souber resolver nada ele não vai conseguir passar O DIA INTEIRO abrindo e fechando a mesma tela enquanto pensa numa solução: o parceiro geralmente ou auxilia ou no mínimo vira mais um na pesquisa pela solução correta.
• as barreiras pessoais caem e as pseudo-picuinhas ou viram picuinhas de verdade ou viram uma grande piada entre o par (e com sorte o time) depois de algum tempo
• é uma das melhores formas que vi até hoje de fazer as pessoas entenderem o que é trabalhar em grupo
• e por aí vai…

Mas eu não tenho time, eu tenho recursos

Muitos amigos/parceiros de outras empresas sempre perguntam pra mim e o pro povo aqui da Giran como trabalhamos porque eles mesmos já tentaram, tentam ou tem curiosidade de implementar metodologias ágeis em seus ambientes de trabalho. Geralmente o que me falam é que lá as pessoas são tratadas como recursos e não como um time.

Num dado momento as pessoas tem suas 8 horas/dia (hellllooow! aumenta isso ai tio!) de trabalho e isso no M$ Project fica lindo: afinal, podemos colocar o Joca alocado 70% do seu dia numa tarefa e 10% em outra e mais 20% numa outra completamente distinta. Ou melhor: podemos fazer o João entregar em 2d 4horas aquele módulo de detecção de XSS NO SITE INTEIRO.

Parte do problema que tento passar pros meus amigos é que as pessoas da empresa não são engrenagens mas sim pessoas, com seus problemas pessoais, limitações técnicas, dias ruins (que não rendem nada) e que nem deveriam ter começado. A partir do momento que os recursos não são considerados como produtores de porcentagens em planilhas mas sim pessoas que implementam escolhas e entregam produtos (resultado dessas esperadas BOAS escolhas), uma parte grande do problema se desfaz e o mundo fica até mais claro.

Mas, mesmo enquanto “recursos” (afinal, seu chefe não quer que os cronogramas os enxerguem de forma tão humana porque isso é perder dinheiro), ainda sim a programação em par se apresenta como uma ótima alternativa para driblar algumas limitações impostas pelo modelo manufatureiro (e antiquado) de produzir software:

• você pode botar um recurso que está produzindo pouco para parear com outro mais “ativo” (ui ui ui) ou com mais moral da equipe interna: o recurso que está “patetando” vai se ligar rapidin e começar a “magicamente” trabalhar mais seja pela pressão do par, seja pelo poder de liderança que esse par vai ter sobre ele (as vezes o cara considera o amigo mais chefe do que você que em tese deveria ter esse poder)
• liderar é servir: essa dica acima é muito importante quando você desejar criar um líder natural de equipe que faça as peças funcionarem sob alta temperatura sem rangir ou quebrar
• faça seus recursos parearem ao menos no início de um novo projeto: assim, o alicerce ficará bem conhecido e a tendência do João levantar uma parede de gesso onde o José deveria colocar o quadro ultra-pesado diminui bastante. “Mas você não me falou que tipo de parede era e eu achei que essa iria dar conta do recado… p*rra, você nem pra me dizer que o quadro era tão pesado né?” (sinto cheiro de re-trabalho)
• fazer par com aquele programador/designer/pessoa-difícil que todo mundo fala que faz tal coisa errada, mal-feita ou que poderia ser melhor vai ser uma maneira muito efetiva de faze-lo começar a trabalhar direito a partir de então
• juntar dois recursos-difíceis assim pode ser uma ótima oportunidade de fazê-los melhorar em conjunto ou você matar dois coelhos com uma caixa d’água só

Passos de bebê para a programação em par

Bacana, legal! Mas tem gente que vai se perguntar: “Putz! Mas como transformar 8 pessoas em 4 da noite pro dia”. Tem muita gente doida (acho que essa é a palavra) que acha que radicalizar da noite pro dia vai adiantar ou ajudar em algo. Em se falando de programação em par então, isso fica ainda mais frenético. Na Giran mesmo ainda adaptamos continuamente nossa forma de trabalho com SCRUM/XP com idéias vindas do time, de coisas que lemos por ai e que descobrimos durante o dia-a-dia de trabalho. A programação em par foi uma dela e que nos deixa hoje muito contentes em levar à cabo.

Então, gostaria de compartilhar algumas dicas que podem ajudar você a fazer seu time ou seus N recursos a trampar em par e trazer um retorno de produção bacana num curto espaço de tempo, bem como você descobrir que isso NUNCA vai dar certo na estrutura da sua empresa (isso também num curto espaço de tempo):

• faça pares com um iniciante e um mais experiente para que os conhecimentos trocados seja mais efetivos;
• num escopo de uma semana, faça as pessoas parearem ao menos uma vez por dia por projeto;
• se você trabalha com tarefas de um dia, faça as pessoas parearem em ao menos duas delas por semana;
• um ótimo recurso para temporizar um pareamento é faze-lo em Pomodoros, que são boxes de tempo de 25 min (1 pomodoro = 25 min) em que as pessoas tem que manter o foco. 2 pomodoros são uma ótima pedida para começar um pareamento;
• pareie pessoas com rendimento baixo com pessoas de rendimento maior (independente do nível técnico) para dar um choque de realidade neles;

Para começar isso já deve dar um pouco de “trabalho” para você, gestor ou líder na equipe, implementar isso de uma forma bacana. Uma forma legal de ajudar nisso, e em vários outros pontos, é você praticar reuniões rápidas matinais de 10 minutos em pé (prática conhecida na XP como Stand-up Meeting) para revisar o que foi feito no dia anterior: nesse ponto você vai identificar até que ponto os pares não apenas trabalharam juntos mas também fomentaram novas idéias e alternativas.

Por enquanto é só pe-pe-pessoal! Boas programações em pares e lembrem-se: programar não é apenas digitar.

<pseudo-sufista>
A vibe nerd vai ficar frenética em VIX em Maio. A Faesa vai ficar crowdeada de brothers e ninguem vai mandar o kaô.  :) Por isso eu vou mandar a pala, tá ligado?
</pseudo-surfista>

Acontece no próximo 29 de maio (um sabadão) na FAESA (Av.Vitória) o primeiro Maré de Agilidade em Vitória, carinhosamente chamado de Maré Vix. O evento vem uma semana depois do evento que rolará em BH no dia 22 de maio.

O Maré de Agilidade, que está chegando à sua sexta edição, é um evento itinerante que tem como objetivo disseminar as metodologias ágeis em todo o Brasil. Além do conhecimento, é claro que rolará muito networking entre desenvolvedores e gestores de projetos, negócios sendo fechados, muito café rolando e claro aqueeeeeeeele clima de evento de comunidade que todo mundo conhece. #win

Parafraseando meu brother-sócio-irmão Paulo Jeveaux, “O Maré Vix contará com uma programação bastante recheada e enriquecedora: teremos um dia inteiro com muitas palestras e uma mesa redonda com todos os palestrantes ao final do evento. Dentre os nomes confirmados para o evento, temos: Guilherme Silveira, com a palestra Um produto em duas semanas, Guilherme Chapiewski, Denis Ferrari sobre Domain-Driven Design, Fabrício Vargas Matosfalará sobre TDD e Jeveaux, sobre Negociação de contratos.“.

O evento contará com vários patrocinadores e apoiadores. Entre eles, com muito orgulho estará a Giran. #epicwinever

Para quem quiser ver mais detalhes do evento e coisas do tipo, visite o site do evento: www.mare-vix.com.

Muita gente me perguntou se eu tinha morrido, desistido da internet ou simplesmente virado monge budista lá na minha terra natal, a Índia. Eu mesmo me perguntei isso tudo e mais algumas coisas. hahaha

Vários fatores contribuíram muito fortemente pra essa “respirada” e “tempo” no blog:

• A Giran cresceu de tamanho, de projetos e o que era o Hackin programador agora é o Hackin Programador/Empresário/Propostator/Reunizator
• A vida pessoal se atribulou, me mudei duas vezes em menos de 6 meses e ainda estou na adaptação das coisas
• Estava muito focado em PHP/SimpleTest e precisando “abrir a mente” como fazia outrora
• Desde o final de 2009, estou dando um gás com o time do PHP-ES para fazer uma grade foda de eventos para a comunidade PHP capixaba esse ano
• … e tudo isso me deixou sem tempo nem para respirar.

Todavia, há males que vem pra bem. Com esse tempo, testei frameworks, metodologias, ferramentas, experiências de gestão de projetos e gestão de tempo, novas linguagens e conheci muita gente interessante, inteligente e infinitamente bacanas das quais “pesquei” várias idéias.

E a partir da semana que vem, estarei escrevendo coisas baseadas nisso tudo. Uma das coisas que me deixa triste é dizer que vou dar uma descontinuada (ao menos por enquanto) no SimpleTest. Até o ponto que fomos (com Mock Objects) com ele, pude perceber que as pessoas já tiveram uma boa noção de testes unitários e uma base para continuar nos estudos de TDD.

Mas isso não significa que irei parar com TDD por aqui, porque vou falar sobre PHPUnit, integração contínua um monte de coisas bacanas. Aproveitando o embalo, ver um pouco de Selenium e mais coisas “didáticas” em relação à isso.

Nesse meio, vamos falar de Git, Scrum (estou respirando isso a semana inteira), algumas ferramentas legais e voltar a escrever sobre vãs filosofias sobre o dia-a-dia de desenvolvimento e gestão de tempo/projetos. Sinto que compartilhar isso vai ser muito bom e um pano de fundo pra várias discussões e reflexões legais.

Enfim, estou de volta …

O PHP Macarrônico é assim

Esse método é justificável dentro da PHP até certo ponto: a própria linguagem tem por princípio a simplicidade e velocidade na codificação e resolução de problemas. O próprio Rasmus Lerdorf, criador do PHP, já se mostrou bem contrário aos frameworks atuais pois eles são lentos e não escaláveis, culpa do feeling de  ”faz-tudo” que a maioria delas leva no sentido de continuar ostentando a bandeira de “desenvolvimento rápido” da PHP, que muita gente confunde com gambiarras e que transformou a PHP em sinônimo de POG (Programação Orientada à Gambiarras).

Por muito tempo eu, como muitos desenvolvedores/empresas que conheço e já conversei, pensava assim:

“Porque vou abandonar toda aquela minha infra-estrutura pronta de gerenciamento de conteúdo e minhas bibliotecas caseiras que funcionam muito bem para adotar uma framework MVC e perder $$tempo$$ precioso ou impactar no $$prazo$$ que dei para o meu cliente. Não tem porque eu correr esse ri$co“.

Existem duas situações muito especiais que consigo identificar na hora de desenvolver uma aplicação e que impactam de forma crítica na decisão correta da arquitetura a ser seguida: necessidade de escalar a aplicação e potencial expansão de funcionalidades durante e depois do projeto.

Quantas aplicações de alta consumo de banda você já desenvolveu em sua empresa com PHP ? E dessas, quantas você realmente tem que dar uma atenção e implementação contínua de funcionalidades novas ? Se você não contou nenhuma, o seu caso é bem comparável ao de muitos desenvolvedores PHP por aí. Se você contou alguma e não teve dores de cabeça com a manutenção ou testes em sua aplicação, você é um cara de sorte.

O feijão com arroz do desenvolvimento PHP no Brasil é muito atrelado à gerenciadores de conteúdo, front-end de websites e muitos projetos que geralmente são desenvolvidos por times por vezes multi-disciplinares. Um ecossistema comum são agências digitais, bureau de mídias digitais e várias outras que precisam desenvolver da forma mais simples e eficaz possível, muitas vezes devido até ao orçamento apertado e a menor margem de chance de que as coisas deêm errado para não ferrar um cronograma geralmente apertado e sem vez para os mais lentos. Juntamos isso à realidade dessas empresas que nem sempre tem um desenvolvedor com uma boa experiência, sem background de programação ou “migrados” de outras áreas e a lenha está feita.

Mesmo em ambientes mais profissionais, ainda existem aqueles que ainda resistem à idéia e são os “super-homens” que desenvolvem coisas que só eles conhecem e são difíceis de disseminar conhecimento válido na equipe.

Dentro desse contexto, algumas situações abaixo concerteza já rolaram com você ou na empresa em que você trabalha:

• Designers sobrescrevendo páginas com lógica de negócio embutida
• Programadores detonando CSS dos outros
• Classes das regras de negócio sendo alteradas a torto e direito ferrando algo que ja estava funcionando
• Métodos espalhados pela aplicação com nomes bizarros e/ou funcionalidades redundantes ou no mínimo estranhas
• Lógica de negócio repetidas, implementadas de formas diferentes e sem um lugar comum
• Registros no banco de dados com dados incompletos e inconsistentes
• Formulários que não validam tudo o que deveriam validar e que deixam cadastrar assim mesmo
• e por ai vai ….

Puxadin ali, patchzin aqui e geralmente temos monstros burocráticos ou incontroláveis que temos que lidar com o passar do tempo: fruto de uma arquitetura por vezes equivocada mas que por N motivos não pode ser substituída. E aí José ?

Adote um framework!

A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“.

A resposta é:  ”Você pode ganhar muito mais a curto prazo e com mais qualidade de vida”.

Algumas perguntas e afirmações que já ouvi (e eu mesmo me fiz) antes de tudo:

• Meus programadores (ou eu) tem nível técnico para trabalhar com isso?
• E tudo o que eu tenho? O que eu faço que isso ?
• Isso vai atrasar o projeto cara!
• MVC ? ORM? Que p*rra é essa ?
• As funções dos meus includes já fazem tudo isso e muito melhor!
• Bah! Já temos nosso ADM pronto: é só copiar, colar e alterar os campos.
• O cliente disse que quer apenas produtos e não vai precisar de nada mais.

Todo esse tipo de pensamento/sentimento as vezes não vem de comodismo ou preguiça, mas da falta de conhecimento ou estudo de como uma framework pode ajudar no trabalho, até onde ela pode ir e principalmente em equipe multi-disciplinares com prazos ultra-curtos.

Então, vão algumas observações/pontos de vista em relação às principais frameworks PHP do mercado que podem resumir de certa forma alguns pontos positivos e relevantes para a adoção de uma framework:

• Elas já estão bem difundidas, com boa documentação e geralmente tem uma curva de aprendizado mínima: com um mês um programador iniciante estará fazendo cadastros simples e bacanas;
• Por serem frameworks de conhecimento público, a disseminação do conhecimento e uso é muito maior e não fica atrelado à uma ou duas pessoas;
• Você não tem apenas uma ou duas pessoas pra fazer “aquela melhoria no envio de e-mail”: você terá uma comunidade para te ajudar com isso;
• Se o “dono da framework” morrer, você não perder todo o investimento na ferramenta porque não existe “dono”. Acaba aquela falácia do “super-homem” ou do “cara que fez a framework e só ele sabe mexer nisso”.
• Estatisticamente comprovado, desenvolver e manter uma framework caseira é muito mais custoso que usar e customizar uma framework já extensamente utilizada no mercado, tanto à nivel de suporte quanto à melhoria da ferramenta e correção de bugs;
• O que traz diferencial para o negócio de seu cliente (e o seu) é o conhecimento de negócio: a ferramenta será apenas um meio e é mais que bacana que ela esteja pronta e você se preocupe apenas com o negócio e não como “fazer aquele usuário logar e se manter autenticado em página X e Y”.
• Frameworks trabalham com padrões de design testados e refatorados continuamente por pessoas com anos de experiência em software: é jogar dinheiro no lixo tentar re-inventar a roda ou re-implementar tudo se não for completamente necessário.
• Programadores experientes terão uma ferramenta amplamente testada e na maioria das vezes bem flexíveis quando precisar adaptar “aquela regra de negócio extraterrestre do cliente XPTO“;
• Frameworks tem um conjunto grande de plugins/componentes que cobre a maior parte das tarefas comuns como controle de sessão/cookies, envio de e-mails, upload de imagens, internacionalização, autenticação e por ai vai. Se não existir, geralmente é fácil (e muito didático) desenvolver algo novo e que a comunidade vai concerteza agradecer;
• A parte de visualização dos dados (view) fica separada do controle das ações possíveis no sistema (controller), que por sua vez tem que respeitar as regras de negócio implementadas no acesso ao banco (model) que ficam centralizadas num lugar apenas: ou seja, o MVC (Model-View-Controller) vai diminuir bastante o quebra pau entre designers e programadores e evitar bastante re-trabalho. No caso de sistemas, vai melhorar e muito a manutenção deste;
• O trabalho com testes é praticamente embutido nessas frameworks e é uma forma ótima para iniciar os trabalhos com TDD nos projetos. Testes não são moda e sim uma tendência natural do mercado onde as aplicações precisam ser cada vez mais confiáveis para não trazer prejuízo para seu cliente;

Boa parte das dúvidas que geralmente se tem recaem principalmente na preocupação de comprometer um projeto com questões técnicas e impedimentos ou na parte do aprendizado em si da ferramenta. Felizmente, com o tempo se percebe que com empenho em cerca de um ou dois meses uma boa framework é absorvida naturalmente.

De certa forma, ela até mesmo promove uma auto-reciclagem de todos os profissionais pois começam a envolver questões como padrões de projeto, orientação à objetos, testes, controles de versão e tudo o que há mais de novo no mundo de desenvolvimento e que volta e meia não chega ao mundo das agências ou software houses mais caseiras.

Em resumo

A adoção de uma framework MVC não é um bixo de 15 cabeças cuspindo fogo e destruindo, mas assim como qualquer novidade apresenta riscos e custo, que CONCERTEZA são altamente recompensadores mesmo que no final ela não seja aproveitada: idéias são concebidas e o nível de conhecimento pós-experimentação é notadamente maior.

Para quem quiser tentar, algumas dicas podem ajudar (ao menos me ajudaram):

• Inicie com projetos pequenos ou internos para sentir como a framework funciona e até mesmo descobrir características a favor ou contra sua adoção na empresa. Após conhecer pontos fortes e fracos, decida se ela é realmente viável em seu projeto;
• Se você tem um time, escolha uma pessoa para estudar a ferramenta escolhida e depois faça um hands-on com a equipe pois assim as dúvidas/conclusões fluem de uma maneira surpreendente;
• Procure conhecer sobre OO (Orientação à Objetos), ORM (Object-Relational Mapping), MVC (paradigma Model-View-Controller), TDD (uso bastante o SimpleTest), controle de versão (estamos usando bastante o GIT) e metodologias ágeis (uso bastante o Scrum): essas coisas “puxam” junto um monte de outras coisas que vão fazer o aproveitamento de qualquer framework MUITO maior;
• Participe ativamente de listas para tirar dúvidas suas e dos outros: em pouco tempo se tornar um commiter em um projeto pode ser uma experiência e tanto de aprendizado;
• Mantenha-se antenado nas novidades da framework: a maioria delas tem atualizações constantes e as vezes até chave para alguma coisas que sua empresa pretende fazer;

Existem, claro, frameworks com diferentes abordagens e  vantagens. Então, para tentar encurtar o caminho mas sem traçar um comparativo muito técnico, vão algumas bacanas para se começar:

• CakePHP, hoje uma das frameworks mais conhecidas e utilizadas no PHP, é uma ferramenta bem influenciada pelo Ruby On Rails, com documentação bacana e uma comunidade grande pacas. Sua curva de aprendizado é bem fácil e os resultados saem bem rápido também, devido ao enorme número de coisas prontas para serem utilizadas. Um ponto fraco é sua performance que não é tão rapida quanto às concorrentes;
• CodeIgniter, é uma framework que vai no caminho contrário da CakePHP: ela é mais enxuta e sem muitos componentes para rodar bem rápido. Sua curva é tranquila e a documentação bem bacana. Um ponto fraco é a ausência nativa de ORM para mapeamento do banco de dados.

Existem várias frameworks, com vários “sabores” a serem degustados: é ver, testar e ver qual mais agrada e ser feliz!

Simbora.

Mas e quando não temos nada instalado e precisamos fazer um fluxograma descente e rapidin ? Já vi gente até apelando para aquelas bizarrices do Word: pra alguns funciona, mas vai fazer um rascunho de UML/Diagrama pra ver o lado bom da vida.

Para quem precisa de algo assim, vale a pena demais experimentar o Gliffy.

Descobri por esses dias o Gliffy, uma ferramenta online de geração de diagramas bem bacana, fácil de mexer e o melhor: GRÁTIS por 30 dias na versão Premium! A diferença crítica entre a versão Basic (que você terá após 30 dias se não quiser pagar pela versão Premium) além das adições significativas, é que você poderá ter apenas 5 mapas e todos eles serão públicos.

Então, se a sua idéia é mesmo fazer organogramas e coisas do tipo rapidim pra complementar aquele trabalho, essa é a ferramenta. Se você usa pra caramba, ainda acho que valeria avaliar a ferramenta, pois são apenas 5 dólares por mês.

Para usar o serviço, basta se cadastrar e começar a usar. Enquanto estiver na versão Premium (que é a que você começa assim que se cadastra) você pode criar quantos documentos quiser.

Interface e uso

A interface é bem simplista e tem vários shapes (formas) acessíveis que podem ser usados e manipulados. Os menus também apresentam várias opções como agrupar elementos e afins.

A interface do Giffly é simples e intuitiva

A manipulação dos elementos é bem fácil também, com guias para aumentar, diminuir, rotacionar e inserir texto quando clicados duas vezes.

Manipulação de elementos

Outro lance bem bacana são as opções de propriedades e customizações, que são apresentadas num menu contextual, que apresenta diferentes opções dependendo do elemento selecionado.

Menu de opções contextualizado

Exportando

O Gliffy permite a exportação fácil para JPG/PNG. Ele possuiu um exportador para o Microsoft Visio também (formato SVG). Nunca se sabe né ?

Exportação

E é isso

Para quem quer algo pra fazer algo simples e no pulo, taí uma ótima ferramenta para quebrar o galho. Para quem quer algo para substituir ferramentas desktop tradicionais, vale a avaliação: eu sinceramente achei bem mais prático e com opções que o OmniGraffle para Mac, um dos que o pessoal mais fala bem.

$imbora.