Migração de artigos do Mambo para o Joomla

Olá, eu sou o Leonardo Fukui, funcionário da Inspira, e recentemente trabalhei com migração de dados do Mambo para o Joomla, ambos em PHP.

Durante a migração percebi que o script utilizado para adaptar os artigos, o "imgReplacer", tinha alguns problemas. Ele só importava a primeira imagem dos artigos, replicando-a para todas as imagens encontradas no restante da página. E também não estava recuperando todo o estilo e o texto alternativo das imagens.

Cheguei a pesquisar sobre o assunto e acabei caindo em fóruns oficiais, fóruns especializados em Joomla entre outras páginas que falavam em Mambots para importação. Porém em todas as páginas que entrei tinham pessoas questionando esse problema na migração, dizendo que só conseguia importar a primeira imagem, ou seja, o mesmo problema que tive.
Para não dizer que a minha busca foi um fracasso, encontrei uma página onde vendiam uma ferramenta para a migração de imagens, que eu acredito que funciona.
Entretanto não vinha ao caso pois se existe alguma forma de fazer, nós faríamos.

Com sucesso consegui modificar os dados de artigos com o um Script que fiz, adaptando o "imgReplacer" para funcionar com mais imagens e pegando todos os dados de estilo e texto alternativo.

Para ninguém mais ter esse problema, resolvi compartilhar o script com vocês!
O script deverá ser rodado após a importação dos dados (ele modificará o banco).



Abraços e boas migrações!

Implementando metodologia ágil na Inspira

Uma das minhas atribuições como responsável pela área de Tecnologia aqui na Inspira é garantir que os projetos de TI vão atender as demandas de nossos clientes. Como em todo bom projeto, principalmente de TI, os prazos são curtos e os recursos são limitados. Mas talvez a grande característica que diferencia TI das demais áreas é a necessidade de adaptação a mudanças.

O ser humano é, inevitavelmente, um ser que não gosta de mudanças. Psicologicamente falando, nós temos medo de sair "no prejuízo" quando os cenários mudam. Se a mudança é do tipo "Ganhar 10 milhões na loteria", ninguém tem medo desse tipo de mudança... mas se o seu chefe pede para que você compareça na sala dele em 5 minutos porque "mudanças" acontecerão na empresa, esse sim é o tipo de mudança que nos deixa bem inquietos.

Lidar com a mudança e encará-la como algo positivo (ou pelo menos neutro) envolve principalmente coragem. Coragem para peitar o cliente e explicar que certas decisões dele podem arruinar o projeto. Coragem para não varrer a sujeira para debaixo do tapete, deixando as tarefas mais arriscadas para o final do projeto. Coragem para discutir certos temas, principalmente envolvendo falhas e desvios de projeto.

Meu grande desafio aqui vai ser propor uma metodologia que seja realmente ágil, e que encoraje discussões construtivas, análise de erros anteriores e melhoria contínua.

Já usamos Scrum em alguns projetos, com ótimos resultados. Porém, precisamos ligar o processo de desenvolvimento com a estratégia da empresa; afinal, somos uma empresa de tecnologia. Isso significa poder mensurar e gerenciar os projetos de TI de forma ágil e eficiente. Provavelmente, vamos precisar criar uma metodologia própria, baseada em Scrum, XP, Agile, Lean, etc. Isso vai envolver um longo trabalho de pesquisa, mas será divertido.

Conforme tivermos avanços eles serão publicados aqui. Sugestões serão muito bem-vindas. Aguardem!

Algoritmo para início e fim do horário de verão

Quem nunca teve problemas com o computador durante o horário de verão? Ninguém sabia com antecedência as datas de início e fim. Pior: o Windows tentava adivinhar e sempre fazia caca. Era o terror dos administradores de rede.

A partir de 2008 passou a valer uma nova regra muito simples: o horário de verão se inicia no terceiro domingo de outubro à meia-noite (de sábado) e se finda no terceiro domingo de fevereiro (também à meia-noite de sábado para domingo).

Notícia fantástica para quem precisa calcular o horário de verão no computador (viu, Microsoft?).

Seria perfeito, se não fosse uma "pequena" exceção: quando o terceiro domingo de fevereiro coincidir com o domingo de carnaval, o final do horário de verão ocorre uma semana depois.

Lindo isso, né? O legislador que propôs esta regra é simplesmente um gênio.

Isso complicou bastante o algoritmo, mas pelo menos ele ainda é determinístico. Chupinhei-o descaradamente desta página e transcrevi-o para C#. Resolvi publicá-lo aqui porque pode ser útil para alguém.

Bom, chega de papo. Segue o algoritmo:



Achei que ficou relativamente bem escrito e fácil de entender. Qualquer dúvida, mande um comentário. Até a próxima.

Como aumentar a eficiência da sua área de TI

Se você é responsável direta ou indiretamente pelos resultados da área de tecnologia da sua empresa, eu gostaria de compartilhar com você algumas idéias sobre como aumentar a eficiência e tornar o trabalho da sua equipe mais tranquilo e divertido.

(Enquanto você ler este post, reflita sobre o texto e faça uma análise crítica. Pode discordar à vontade. Se quiser escrever um comentário no final, melhor ainda!)

Se o seu objetivo é fazer mais software em menos tempo, com maior qualidade e menos dinheiro, você tem algumas alternativas de investimento, dentre elas posso citar seis sete:

1. Treinamento e boas contratações
2. Ferramentas de desenvolvimento (IDEs)
3. Metodologias e processos
4. Hardware
5. Plataformas e frameworks
6. Ambiente de trabalho
   
7. Geração de código

Investir em treinamento e boas contratações

A importância do investimento em treinamento tem sido muito enfatizada nas revistas de gestão. Não vou entrar na discussão sobre quando e como devemos treinar, porque esse assunto foge do escopo deste post. Mas eu estou convencido de que profissional sem a qualificação necessária é dinheiro jogado fora duas vezes (gasta-se $ para fazer software mal-feito e depois mais $ para corrigir os defeitos).

Aproveito para indicar um bom post do Joel Spolsky sobre contratações: como fazê-las corretamente e a importância disso.

Ferramentas de desenvolvimento (IDEs)

Ferramentas como o Eclipse e o Visual Studio são fundamentais para economia de tempo e dinheiro, pois ajudam o programador a produzir e testar código com maior rapidez. Porém muitas vezes estas ferramentas encobrem deficiências da plataforma ou da linguagem.

Por exemplo, a geração de "getters" e "setters" economiza alguns segundos de digitação do programador. Porém, o grande problema dos programadores não é escrever código... é ler. Quando um programador precisa ler código? Quando faz manutenção! É um tipo de trabalho que programadores costumam odiar, mas que precisa ser feito o tempo todo.

E convenhamos, ler código cheio de "getters" e "setters" é um pé no saco! Por isso a adoção de linguagens como Ruby e Python está crescendo tanto em relação a Java ou PHP.

Quando você contrata um programador por R$ 30 a hora, não importa se ele passa uma hora pensando ou uma hora digitando, você vai pagar o mesmo valor.

Porém o tempo que ele passa pensando é o que faz a diferença no projeto. Não adianta nada o editor de texto gerar um monte de código (economizando tempo de digitação) se o programador vai ter um esforço muito maior depois para entender o código gerado. Código bom é código conciso, escrito por humanos para humanos. Por isso existem compiladores.

Resumo: se você gasta muito tempo usando funcionalidades de geração de código do seu IDE, tem algo errado com a sua plataforma/linguagem de desenvolvimento e você vai ter um custo maior de manutenção no futuro. Nada contra os IDEs em si.

Metodologias e processos

Metodologias e processos não são exatamente fundamentais para desenvolver software com qualidade, mas ajudam MUITO. Quando você adota uma metodologia de desenvolvimento, não necessariamente precisa fazer algo parecido com as linhas de montagem de Henry Ford (aliás eu nunca gostei do termo "Fábrica de Software").

Metodologias Agile, XP e Lean se adaptam muito bem ao cenário atual de desenvolvimento de software, que envolve transformações constantes. O site infoQ é uma excelente fonte de informação a respeito.

Aqui na Inspira adotamos uma metodologia própria, com forte influência de XP e Scrum, mas muito baseada em padrões de arquitetura e geração de código. Esse tipo de abordagem requer algumas práticas meio ortodoxas (como o Big Design Up Front, que nós amamos aqui e o pessoal do XP não curte muito).

Aqui na Inspira nós botamos muita fé no Manifesto Ágil e valorizamos muito indivíduos e interações. Mas metodologias e processos também são bem legais... desde que você não esqueça do seu programador e nem do seu cliente, que são seus principais objetivos.

Hardware

Estamos em março de 2009. Hoje é muito difícil encontrar um bom programador no mercado por menos de R$ 4.000,00 / mês (sobre o conceito de "bom programador", leia o item 1).

Um bom computador, (quase) top de linha, com 2 monitores de 19'', você consegue por uns R$ 3 mil. Um computador meia boca com monitor de 15'' da AOC você consegue por uns R$ 1,5 mil.

Estudos mostram que só os 2 monitores vão trazer um ganho de produtividade de cerca de 15%. Fora a diversão.

(Ok, admito, para conseguir esse ganho é preciso primeiro criar um hábito de usar os 2 monitores sempre que isso for útil).

Voltando ao assunto. Faça as contas. 15% de 4000 = R$ 600.

Ou seja, o computador top se paga em 3 meses. E eu não estou considerando o ganho trazido pelo poder de processamento, que na minha opinião é muito alto.

Quando eu estou compilando uma aplicação e o Visual Studio trava, sabe o que eu faço na mesma hora?

Abro o FireFox e digito Ctrl + T. E depois digito kibeloco.com.br. E aperto a tecla Enter.

Nessa brincadeira eu perdi uns 10 ou 15 minutos procrastinando na Internet. E pior: eu perco totalmente o foco! Até eu lembrar o que eu estava fazendo antes, e entrar no ritmo, lá se vão no mínimo 30 minutos.

Se você é programador e está lendo este post, eu aposto um chopp no bar do Zé que isso já aconteceu com você pelo menos uma vez...

Se você tiver um computador montado especificamente para programação, grandes chances de você divagar menos pela Internet afora porque o seu Visual Studio parou de responder. Isso representa uma economia absurda de tempo e dinheiro, na minha opinião.

Ou seja, se você é responsável pela área de tecnologia da sua empresa: gaste uma graninha a mais com a sua equipe!

Plataformas e frameworks

Não é muito difícil perceber que plataformas voltadas especificamente para o tipo de problema que a gente quer resolver economizam tempo e dinheiro.

Esse é o motivo de surgirem novas tecnologias como o Ruby on Rails, por exemplo. Explica também o C# 3.0, ASP.NET 3.5, o ASP.NET MVC, o Spring Framework, etc.

Mas fique atento: escolher a plataforma correta é uma decisão difícil que envolve vários fatores. Para mais detalhes, veja meu post anterior.

Ambiente de trabalho

Esse para mim é o mais importante. Um bom ambiente de trabalho envolve a parte física (escritório, ergonomia) e a parte psicológica (salário justo, oportunidades de aprendizado, "clima", etc.)

O gerente de tecnologia, juntamente com os outros gerentes, são responsáveis pelo ambiente de trabalho, e podem fazer a diferença!

Um bom ambiente de trabalho é o que permite que um desenvolvedor possa se superar, agregar muito valor à sua empresa e a si mesmo (e isso é muito importante).

Veja aqui algumas coisas que nerds precisam para amar seu emprego.

Geração de código

Em breve eu vou criar um post específico tratando desse assunto: as utilizações práticas, vantagens e desvantagens.

Por enquanto posso afirmar o seguinte: gerar código funciona! Mas a coisa precisa ser feita corretamente para dar certo.

O InspiraDNA, nosso gerador de código, nos economizou alguns milhares de reais em 2008, e já está ajudando muito em 2009. A Inspira é a prova viva de que gerar código funciona.

Usar uma ferramenta de geração de código não deixa de ser uma forma automatizada e rápida de copiar e colar código... a essas alturas você pode estar pensando: "Se a minha plataforma de desenvolvimento for boa o suficiente, não vou mais precisar de Ctrl + C e Ctrl + V, logo, gerar código não vai ser necessário".

Esse raciocínio faz todo o sentido. Mas há um pequeno problema:

Sabe quando a sua plataforma de desenvolvimento vai ser boa o suficiente?





Resposta: NUNCA
(Ou pelo menos não tão cedo)

Gerar código é encobrir deficiências de plataforma... mas na velocidade em que as tecnologias evoluem, é muito provável que as plataformas sempre tenham alguma deficiência e não sejam perfeitamente adequadas ao seu problema.

Logo, eu penso que gerar código é e vai continuar sendo uma ótima opção por muito tempo. O que muda é o tipo de código gerado e a forma como a geração vai ser feita, conforme as plataformas, frameworks e IDEs vão evoluindo.

Trabalho com geração de código desde 2000, quando trabalhava na TV1. A conclusão a que eu cheguei é que não importa tanto o gerador de código que você usa. O que importa mesmo é o template.

Não adianta nada gerar código se você vai gastar mais tempo adaptando o código gerado do que fazendo do zero.

Digamos que o template tenha um defeito: os dados do formulários são gravados e o ID inserido no banco não é retornado para aplicação. Se você gera código para uma aplicação de 100 entidades, provavelmente você vai precisar fazer a mesma correção (possivelmente complexa) exatamente 100 vezes. E isso não é nada divertido.

Por isso quanto maior a maturidade do template, a robustez e a flexibilidade da arquitetura, melhor para o programador. Aqui na Inspira nós nos preocupamos muito com isso no desenvolvimento do InspiraDNA. A gente acredita que, se o código gerado não ajudar, pelo menos ele não deve atrapalhar. Por isso, em vez de tentarmos resolver 100% dos problemas, almejamos resolver 60% ou 80%, mas dando total liberdade para o programador completar o serviço, sem ficar engessado.

Em breve postarei um artigo aqui com uma discussão mais aprofundada sobre geração de código. Enquanto isso, se você achou o artigo útil, ou tem críticas, comente por favor.

Conhecendo as agências digitais de São Paulo

Aproveitamos o mês de janeiro que normalmente é um pouco mais tranquilo para visitarmos diversas agências digitais de São Paulo. A intenção era de conhecer melhor a estrutura destas agências e a de apresentar nosso portifólio de soluções destinado a elas, em especial a recém lançada ferramenta de geração de código, o InspiraDNA.

Uma curiosidade foi conhecer o ambiente destas agências. TVs de LCD/Plasma, videogames (de Super Nintendo a Playstation 3), mesa de bilhar, pufes, colchão de ar e vários outros recursos de extrema importância para bons desenvolvedores, mas que infelizmente não vimos ninguém utilizando... A decoração também foi destaque, sempre fugindo do comum, do formal, indo para uma cara mais descontraída mas sem esquecer do bom gosto. Destaque para paredes e mesas revestidas de material similar ao dos quadros brancos e utilizadas como tal. Bons computadores, grandes monitores e café sempre ao alcance também foram quase uma regra. 

Fomos muito bem recebidos em todas as agências. Conversamos em geral com os gerentes de tecnologia e desenvolvimento. Percebemos uma certa desconfiança inicial. Provavelmente por estarem acostumados a receberem vendedores de menor conhecimento técnico só interessados em empurrar suas "soluções". Depois de alguns minutos esta impressão inicial passava e o que parecia uma reunião de vendas se transformava rapidamente em uma descontraída troca de experiências sobre este nosso mundo do desenvolvimento web. Foi ótimo perceber a empolgação que ia surgindo a medida que conseguíamos demonstrar nossa competência técnica, entendimento dos problemas do setor e principalmente o potencial da nossa ferramenta de geração de código.

Ao final posso dizer que foi um experiência fantástica que deveremos repetir em breve em outro grupo de agências. Em geral, pudemos confirmar a aderência das nossas propostas e também identificar novas necessidades. Algo que me deixou animado foi perceber a importância dada a área de tecnologia. O interesse destas agências por novidades em recursos e serviços que possam contribuir no desempenho da sua equipe técnica nos mostrou não só que a Inspira está no caminho certo, mas também que estas agências tendem a crescer cada vez mais. Ficou claro que o sucesso destas empresas não está vindo à toa. Já perceberam que a melhor forma de vencer é sair na frente, ficando atento a tudo e não se fechando a nenhuma nova possibilidade.

Fica registrado aqui o agradecimento as agências digitais Sinc, Lov, Chleba:), Oohm, TV1, Neotix, XLab, Webbox, F.Biz, Fulltecno, IThink, Hello, Gringo, 10' minutos interactive, Agência Interativa, PictureWeb, New Creative, Tritone, a fábrica de software Ci&T e a consultoria Headway por participarem deste processo.

Apoio tecnológico para as agências digitais

Com os anos de experiência no mercado de tecnologia web percebemos que havia uma certa carência de suporte tecnológio para as agências. Como em geral, o maior foco destas empresas não era tecnologia e sim a parte de criação e suporte de marketing web, os investimentos nesta área tendiam a ficar em segundo plano. Alguma agências já possuem esta vocação, até por, em alguns casos, terem sido inicialmente empresas de tecnologia que com o tempo foram se especializando em arte.

Porém, na maior parte, a área de implementação é mais um problema do que uma solução. É complicado ter que se preocupar em manter uma equipe técnica de alta qualificação, que  consiga implementar tudo aquilo que é criado para os clientes com custos e prazos mínimos,e ao mesmo tempo manter o foco em arte, arquitetura, atendimento, gerência de investimentos em marketing web.

Com o intuito de ajudar as agências digitais a superarem  este desafio que a Inspira decidiu investir em pesquisa e desenvolvimento de tecnologia para este mercado. A intenção não é a de substituir a equipe técnica das agências, mas sim a de ajudá-la a funcionar melhor. Queremos que estas equipes consigam aumentar sua eficiência para que nunca sejam o gargalo do crescimento da agência. A idéia é que a equipe de vendas possa continuar fechando projetos com a certeza de que a demanda poderá ser atendida de maneira satisfatória. Neste caminho, além de mantermos uma equipe pronta para atender uma eventual demanda de terceirização de projetos, disponibilizamos ainda serviços de alocação de profissionais, treinamento, consultoria e criamos ferramentas para auxiliar as agências a atender melhor seus clientes. 

Uma delas é uma ferramenta de localização de pontos em mapas, o WebMix. Ela já está sendo bem utilizada no mercado imobiliário em clientes de grande porte como a Trisul e a CMarqx.

A outra ferramenta que acabamos de lançar é um gerador de código baseado em templates, o InspiraDNA. Ela permite uma grande economia de tempo e custo no processo de desenvolvimento sem engessar a solução final.

Continuamos pesquisando para a evolução destas soluções e para o desenvolvimento de outras que continuem ajudando as agências digitais a  superar as expectativas de seus clientes. Em outro momento falaremos mais sobre estas e outras novidades. Caso queira conhecer mais visite a página de soluções no nosso site.

Cuidado ao escolher suas abstrações

Ultimamente tenho passado muito tempo estudando arquiteturas de software, visando aperfeiçoar nossa solução de geração de código [InspiraDNA]. Uma grande preocupação minha é não "engessar" o código gerado. Com isso espero que os programadores consigam um alto nível de produtividade e quem sabe até voltar pra casa antes das 19h...

Toda essa pesquisa me fez lembrar de um artigo muito interessante do Joel Spolsky, intitulado "The Law of Leaky Abstractions" (Se você é programador recomendo fortemente a leitura). Muito resumidamente Joel mostra como as abstrações, apesar de serem necessárias, podem causar muita dor de cabeça, por possuirem falhas, ou "vazamentos". Joel afirma que toda abstração não trivial, em algum grau, possui vazamentos.

Por exemplo: os protocolos de transferência de arquivos pela rede foram projetados para funcionarem como se funcionasse num disco local. Mas o que acontece quando a rede está lenta ou a conexão é encerrada no meio da cópia de um arquivo? O objetivo desses protocolos é fazer com que algo complexo (transferência de arquivos via rede) pareça ser simples (cópia de arquivos locais). Isso é o que entendemos por abstração.

Ao pesquisar o código gerado por algumas ferramentas de mercado (ex: CodeSmith e myGeneration), percebi que quem criou os templates precisou criar algumas abstrações. O código gerado pelo template .netTiers, por exemplo, possui uma bibloteca responsável apenas por gerar SQL dinâmico.

Se por um lado estas abstrações facilitam o trabalho do programador, por outro elas fatalmente passarão pelo problema do vazamento.

Tipos de vazamento:

• Erros: quando ocorre algum erro dentro da abstração, pode ser muito difícil ou impossível descobrir as causas do erro (o famoso problema da caixa preta).
  
• Adaptações: quando a abstração não resolve um problema específico, ela deve permitir que o problema seja resolvido da forma tradicional.
  
• Substituições: a arquitetura deve ser modular para permitir substituição de funcionalidades sem impacto (no exemplo do .netTiers ele deveria permitir a troca do SQL dinâmico por Stored Procedures de um jeito muito fácil e sem afetar o funcionamento da arquitetura).
• Conhecimento: quando você precisa treinar um programador para aprender uma nova abstração, ele pode perder muito tempo ou não utilizá-la de forma correta ou eficiente. Ainda no exemplo do SQL dinânico, o código SQL gerado pode funcionar, porém ser muito lento. Neste caso talvez o programador tenha que utilizar a abstração de uma forma diferente (para o código gerado ser mais rápido) ou mesmo abandonar a abstração para atender o requisito de desempenho.

Eu costumava gastar um tempão pesquisando abstrações (eu mesmo já criei as minhas). Hoje no entanto eu sou muito mais chato com relação a esse assunto. Só adoto abstrações em situações específicas: 1) essa abstração se espalhou tanto que praticamente qualquer programador do mercado vai conseguir utilizá-la rapidamente. Foi o que aconteceu com o jQuery ou o Rails; 2) É um projeto específico que não vai sofrer manutenção (ex: hotsite de algum evento) e que usando a abstração "X" conseguiremos economizar centenas de horas de desenvolvimento ou 3) algum grande player do mercado está lançando uma nova abstração e "provavelmente" boa parte do mercado irá seguí-lo (ex: ASP.NET MVC).

Com relação a esse último item, é importante notar que sempre estaremos "apostando" de alguma forma. Eu posso treinar a minha equipe inteira em uma tecnologia que "vai bombar" e no final acaba não passando de um "hype" (LINQ2SQL?). Isso significa que eu ficarei refém de uma tecnologia e que não encontrarei programadores que saibam mexer nela e quando eu precisar contratar terei de treiná-lo.

Muito cuidado ao escolher suas abstrações...