Rafael Dohms Web Engineer

27Sep/113

Como escrever artigos técnicos (melhores) em 10 passos

Blogs. A internet nos últimos anos tem visto o crescimento disparado destes sites, desde o desenvolvedor que escreve no finais de semana até o colunista que ganha para fazer isso. E não é por menos, eles são sim uma ótima ferramenta para divulgar seu trabalho e agregar valor ao seu nome no mercado, porém apenas se utilizado de forma correta. Vou me restringir obviamente a falar de blogs sobre tecnologia e desenvolvimento, embora outras áreas tenham muitas historias de sucesso desta plataforma também. Eu realmente não saberia como comentar por exemplo o mercado de esmaltes e como escrever artigos sobre eles.

Recentemente tenho esbarrado com alguns artigos que me deixam na dúvida se seus autores realmente entendem o que é o papel de um blog e de artigos técnicos, ou se o foco deles seria menos honrado e apenas uma forma de atrair mais visitas. Sim, falo do que já conhecemos hoje na internet como ‘flame-baits’ ou seja, iscas para discussões (negativas). São geralmente posts polêmicos, sem embasamento, movidos por uma opinião pessoal e carregados de termos clichê e piadinhas. Menos mal se estes posts fossem apenas ferramentas de autores de blogs pessoais, muito pior quando aparecem em grandes “veículos” de comunicação ou sites especializados.

Dois exemplos me passaram pelo browser recentemente, um artigo gringo sobre PHP x Python, cujo embasamento completo era um tirinha XKCD, um pato e um pedaço de código ilegível. O segundo, brazuca, intitulado PHPog, uma questão de design, publicado recentemente na iMasters. O grande centro do artigo é uma comparação entre PHP OO e Java OO, como as coisas deveriam ser feitas no PHP, e a grande reação dos leitores foi a de que certas coisas no PHP são diferentes e isso não é negativo (tem mais, mas vamos resumir assim). O questionamento é válido, e as discussões sobre a implementação de OO do PHP também, porém o artigo vai além disso, usando temos como o POG (programação orientada a gambiarras) para descrever a implementação e outras formas pejorativas de tratar a linguagem e seus programadores.

Neste ponto mora o problema. Ao agredir a linguagem com piadinhas o resultado esperado pelo post não é mais uma discussão séria sobre o assunto, e sim atrair milhares de fãs sedentos por sangue para defender sua linguagem e retribuir palavras não carinhosas ao autor do artigo. Este foi exatamente o resultado de ambos artigos, sim eles tiveram muitas visitas, sim tiveram muitos comentários, mas isso realmente é bom? Compare 1000 visitas de xiitas revoltados com 200 visitas de pessoas querendo mostrar um ponto de vista diferente sobre um assunto, com qual você aprenderá mais? E a imagem de sua empresa/sua pessoa, como ela vai ficar após esse barulho todo? Pra mim os resultados de ambos artigos poderiam ser muito mais instrutivo, foco na discussões técnicas e menos barulho de “extremistas” e “ativistas” além de exaltarem a imagem dos sites envolvidos por iniciarem discussões de alto nível.

Por isso, uso este meu espaço para ponderar sobre o assunto, e tentar mostrar minha opinião sobre o que seria um artigo técnico bem escrito.

Como escrever artigos técnicos melhores?

1. Evite usar tirinhas cômicas. Sim é divertido, e vai “quebrar o gelo”, mas se você precisa quebrar algum gelo, repense suas intenções com o artigo, elas podem já estar erradas.

2. Fuja de palavras polemicas e pejorativas. Evite usar termos como o POG citado acima, se o artigo fosse chamado “Aplicando Design Patterns usando PHP: qual a melhor forma?” a discussão final teria se focado muito mais em discutir as implementações de OO do PHP do que comentários como “Como se POG existisse só no PHP”, ou “< ?php print “Calma galera” ?>” e até “Nunca vi tanta ignorância incorporada em um único texto.”. Você pode discordar da linguagem e de como algo foi implementado, deve!, porém faça isso com o devido respeito e seriedade.

3. Expresse sua opinião, mas deixe isso claro. Cal Evans uma vez falou que um desenvolvedor só pode ser considerado Sênior, se o mesmo souber se expressar, ou seja, escrever artigos e mostrar seu trabalho e seu raciocínio através disso. Porém ele deve saber também defender suas ideias e mais importante ainda, saber quando admitir o erro. Lembre-se disso, sempre ˜haverá opiniões contrárias, as vezes todas corretas em sua forma, mas as vezes você realmente estará errado, saiba aceitar isso. Atualize o post se for o caso.

4. Pesquise. Estude. Pesquise. Escreva. Mesmo que sempre que você for falar de um assunto o artigo não passe de sua interpretação sobre o mesmo, é sempre uma boa ideia se precaver. Portanto pesquise muito sobre o assunto, procure opiniões contrárias e analise de outros pontos de vista. Caso esteja aberto a admitir o erro depois lembre-se das regras acima, elas irão potencializar uma resposta positiva e o aprendizado.

5. Referências == credibilidade. Se o que você quer explicar se baseia em algum material que leu, faça sempre referências ao material, aponte de onde ele veio, isso trará para o seu conteúdo mais relevância e agregará os argumentos do outro autor aos seus.

6. Quantidade não significa Qualidade. Ter 1001 visitas não significa que seu artigo é bom, ou ruim. Artigos polêmicos, ou sem embasamento e agressivos acabam atraindo muitas visitas, pessoas que querem ver pra acreditar, ou deixar um comentário agressivo. Se o seu objetivo é ter muitas visitas isso realmente funciona, porém qual foi a impressão que as pessoas tiveram de você ao sair de lá? Agora um artigo que deveria divulgar seu trabalho e te projetar como profissional, acabou de mudar a opinião de pessoas para não mais te considerar para uma possível vaga.

7. Não critique, compare. Respeite. Muitas vezes vejo artigos escritos apenas para debochar ou ridicularizar algo, ou a forma como alguém fez algo. Quer fazer algo construtivo? Faça uma comparação sobre como o artigo foi escrito e como ele poderia ser escrito, talvez até de umas dicas de como melhorar. Além de tudo, respeite o profissional que escreveu ou criou aquilo que é alvo de seu artigo, nem todos concordamos em tudo, mas isso não é motivo para chacota e desrespeito.

8. Exemplos práticos. Nem todo tema é passível de um exemplo prático, mas em se falar de tecnologia e desenvolvimento isso geralmente é possível, então faça! Anexe um código, aponte um repositório, um diagrama de classes ou um ERM. Ilustre seu artigo com exemplos e gráficos, a leitura fica mais agradável e coerente.

9. Começo, meio e fim. Pense e planeje seu artigo. Todo artigo tem um objetivo. Para chegar nele o artigo precisa de um começo ou uma introdução, um meio ou o desenvolvimento do tema, e um fim, a conclusão. Isso se aplica a todos artigos, mas também vale pra artigos técnicos. Por exemplo: Descreva o problema que vai resolver, mostre como resolver e conclua se foi ou não uma boa escolha. Garanto que se o seu artigo passa 5 parágrafos contanto a historia do John Armless e no final não explica onde ele se encaixa no tema nem porque, seus leitores vão ficar confusos, e indignados.

10. Don’t be a douchebag. Eu gosto desta frase em inglês por ela ser a forma mais ofensiva sem ser ofensiva de se dizer, não seja um chato. Acalme o ego, baixe a crista, seja sério e respeitoso, receba comentários bem, mesmo os mal educados.

Bem, seguindo minha própria receita, esta é minha opinião, assim são construídos os artigos que eu respeito e gosto de comentar e discutir. Posso estar errado, então por favor comente sua visão do assunto nos comentários, faltou alguma regra? Espero que este artigo possa inspirar artigos melhores de valor técnico e que discussões possam brotar destes.

4Jan/077

Documentação e Best Practices: Um caso de uso

Documentação, a palavra mais assustadora e antipática criada dentro do ambiente de desenvolvimento.

Ok, isso pode ser o que pensamos, mas não é a verdade. Documentação é uma parte fundamental do desenvolvimento de qualquer sistema, seja ele em equipe ou não. Quantas vezes você não se deparou com um código que voce mesmo escreveu algum tempo atrás e simplesmente ficou sem entender absolutamente nada do que havia feito? Acredite, acontece.

Em um ambiente de desenvolvimento em equipe a situação fica ainda pior. Cada programador tem sua assinatura, desafie varias pessoas a escrever um código para resolver um determinado problema e verifique o resultado. Cada um vai escrever o código de uma forma, então imagine a confusão na hora de se dar manutenção no código de outra pessoa.

A documentação esta ai justamente para preencher esta lacuna, atitudes simples, como uma linha de comentário descrevendo o que o bloco de código logo abaixo, fazem uma grande diferença para o entendimento. Além disso temos a documentação completa de classes e códigos, que pode ser baseado no phpDoc, por exemplo.

Recentemente estive projetando um sistema que será implementado por uma equipe de três pessoas, e pra piorar, eu como gerente de desenvolvimento vou passar quinze dias fora, sem contato com a equipe. Eu precisava achar uma forma de deixar meu parceiro "em código" programar livre, tocar o projeto junto com o designer, mas sem gerar códigos que entrem em conflito com o resto do sistema, ah sim, este sistema integrará 5 subsistemas em uma base única de intranet, mas acho que estes detalhes são coisas para outro post.

Após projetar o sistema e definir objetos e outros detalhes gerais do próprio sistema, tirei meu tempo e aproveitei o recesso do resto da equipe para escrever o "Manual de Best Practices" do sistema. Para que tudo corra bem é necessário definir um padrão para que todos envolvidos possam seguir este padrão e então produzir código inteligivel e que se "conecte".

O manual explica detalhadamente toda estrutura do sistema, desde a estrutura física até as normas de documentação. Começo descrevendo a estrutura do sistema e a integração dos sub-sistemas, explicando a estrutura de pastas e ditando as normas de nomenclatura de arquivos. Em seguida passamos pelo desenvolvimento de módulos, tratamento de erros, conexão com o banco e apresentação. Finalmente apresento as diretrizes de documentação para que possamos das continuidade ao que foi feito.

A apostila como um todo terá mais de 9 capítulos e cerca de 30-40 páginas (ao escrever isso ainda não finalizei a apostila), mas deve continuar sendo re-escrita e novas instruções e padrões devem ser adicionadas. O nível de detalhamento deve melhorar, e alguns padrões de formatação de código devem ser incorporadas.

Funciona? Bem eu acredito que teremos muitos menos problemas de incompatibilidade, mas com certeza voltarei para relatar meu caso de sucesso (ou insucesso) e incrementar na definição e dicas de documentação.

16Nov/066

ReviewMe: Ganhe dinheiro por sua opinião!

Artigo patrocinado por: Review Me

Sim, eu falei patrocínio! Não, eu não virei popstar.
A importância dos Blogs cresce a cada dia, e seu potencial como ferramenta de influencia é cada vez mais inegável. Visando aproveitar esta onda vimos surgir várias formas de anunciar nestes sites, como AdSense, Admarket dentre outros. O que é novo então?

15Aug/060

News Update

O tempo pra variar não espera ninguem, no meu caso já fiquei para trás a muito tempo.

Estou no momento terminando de preparar um post sobre uma palestra que assisti na semana passada, chamada "Buscando Águias", uma palestra muito interessante sobre liderança e formação de líderes, agiardem e já passarei mais informações.

Os últimos dias tem tido um tópico recorrente na minha carreira, "otimização" estou passando pelo step-by-step de como gerenciar um banco de dados de mais de 120 tabelas, algumas com até 200 mil registros. Tudo começa mil maravilhas, mas a continua manutenção e revisão é necessária para que o crescimento do banco não afete a performance final do site, pois um select que demora x milisegundos quando tem apenas 100 registros, pode demorar x*10000 milisegundos quando passa a ter 70 mil registros e 50Mb de dados. Quando terminar o processo compartilho com vocês algumas dicas de configurações e best practices do SQL.

No meu mundo freelancer, me aproximando do lançamento da versão beta de um helpDesk desenhado sob medida para um cliente, decidi me aventurar em algumas novas ferramentas da era Web 2.0. Após muito resistir e "re-inventar" a roda da Web 2.0, decidi que já havia obtido o controle da tecnologia, uma rotina que faço questão de sempre seguir, pois não basta apenas saber aplicar pacotes prontos, é importante conhecer o processo por trás e saber - pelomenos em teoria - aplicar por si mesmo.

Portanto comecei minha experiência experimentando a biblioteca script.aculo.us, que por sua vez utiliza a prototype. Ela possui algumas ferramentas muito interessantes de efeitos e outras funcionalidades, fica aqui a recomendação de que, se você já fez seu dever de casa, de uma olhada e aplique a biblioteca para dar mais vida e interação à sua aplicação web.