Eu e o empreendedorismo do palco

Em janeiro de 2015 Nanna e eu oficializamos a itexto: foi um dos momentos mais legais da minha vida pois um sonho (O sonho) muito antigo finalmente estava se concretizando. Setembro de 2016 está chegando e de lá pra cá já atendemos quase 30 clientes, formamos uma quantidade enorme de pessoas nas tecnologias que dominamos e as coisas caminham bem.

Caminham bem agora, após 16 anos de incontáveis tentativas, a esmagadora maioria fracassada devido à minha arrogância e ignorância. No meio do caminho decidi reduzir minha ignorância partindo para o mercado e buscando trabalhar com aqueles que fossem mais experientes que eu. Venci a arrogância ao reconhecer que pra comandar meu destino primeiro tenho de ter sido comandado.

Este investimento se pagou: observando os erros alheios (sempre os mesmos) pude chegar a algumas teorias que, finalmente, ao colocar em prática se confirmaram e o negócio começou a caminhar, o que se confirma no crescimento (muito) controlado da empresa em um período de crise econômica profunda do país.

E aí você achou que este seria mais um texto motivacional daqueles que geram uma vergonha alheia profunda né?

Esta “vibe empreendedora” me incomoda

(odeio a palavra “vibe”, mas foi a melhor que encontrei no momento, desculpe)

Vejo muito papo furado em apresentações sobre empreendedorismo, startups e cia. Como alguém que tem uma empresa de verdade, pagando salários e impostos reais, resolvi listar aqui parte das lorotas que dizem.

A ausência de uma palavrinha chave que começa com “R”

simpsons-radioactive

Sabe: quando assisto a algum picareta no palco falando sobre sua “trajetória de sucesso” ou mesmo aqueles caras que claramente nunca abriram seu próprio negócio te dizendo como proceder raramente vejo uma palavra ser dita: responsabilidade.

Ok, você quer abrir seu negócio. Você sonha se tornar alguém que criou algo importante, mas já parou pra pensar na imensa responsabilidade que é ter seu próprio negócio?

Já parou pra pensar na honra que é alguém querer trabalhar contigo? Honra esta que não pode se tornar uma decepção. No compromisso que é mensalmente pagar todos os impostos envolvidos no pagamento de salário desta(s) pessoa(s)? Já se atinou pro fato que você pode fuder a vida de quem trabalha com você?

Se só tem sócios na sua empresa, será que sua empresa terá estrutura para ter pessoas recebendo no regime legal, que é o CLT?  Desculpe: você só sabe o que é ter uma empresa quando assinar a primeira carteira de trabalho de alguém.

E a responsabilidade que é alguém te escolher como fornecedor? Te escolheram, confiaram em ti e no seu serviço/produto: agora vai ter de corresponder.

Agora vamos para um nível acima: já parou pra pensar que ao abrir uma empresa você está influenciando a sua economia local? Que se seu negócio for pura lorota, você pode desacreditar todo um ramo?

Quase sempre a mesma historinha!

conto_de_fadas

Releia os três primeiros parágrafos deste post. É inacreditável como sempre escuto nas apresentações a mesma história composta por três atos.

  1. O empreendedor tem uma ideia que considera genial, mas ele é arrogante devido à sua própria ignorância. Ele segue em frente.
  2. Aparece um obstáculo e nosso herói sofre um forte baque. É o momento em que sua ideia é posta em cheque. Será que ele consegue vencer o obstáculo?
  3. Ele aprendeu com os erros, adaptou-se, adquiriu humildade: agora está mais sábio e tudo deu certo.

Há uma outra variação cruel desta mesma história. Segue abaixo:

  1. O empreendedor tem uma ideia que todos consideram idiota, mas ele tem e segue em frente.
  2. Ninguém acredita em nosso herói, mas ele continua. É o período tenso, no qual sua fé é testada.
  3. De repente sua ideia começa a funcionar! Todos percebem que estavam errados e não o herói, mas o mundo percebe que era arrogante e se redime.

Percebeu que há uma forma compartilhada?

  1. Nascimento da ideia – herói empolgado
  2. Momento da dificuldade – herói se questiona
  3. Dificuldade superada, sucesso atingido – herói confirma sua ideia (mesmo que a adapte)

Você realmente acredita que o mundo é tão simples assim??? Não são expostos muitos detalhes a respeito dos passos reais envolvidos no problema. É como Vitor Hugo, que dizia ter escrito Les Miserables de uma única vez. Anos após sua morte encontraram um baú com inúmeros manuscritos.

Resumindo: sempre o mesmo conto de fadas, a realidade é mais interessante (e árdua) que isto.

(aliás, este é o arquétipo mais básico do herói presente na literatura ocidental)

A ideia de que basta ter uma ideia e um… app

Claro, sou um desenvolvedor, quero trabalhar e tal, então não deveria dizer isto, mas é tanta gente iludida com a ideia de que para ser um empreendedor de sucesso você só precisa de um aplicativo e uma ideia…

E os caras falam isto no palco!!!

“Kico, se tivermos um app como o Krankster ficaremos ricos!” – Yeah! Nem precisamos pensar nas pessoas que cuidarão dos fornecedores, contato com clientes, manutenção, suporte, o computador resolve tudo pra nós!!! O Processo é o sistema!

“Nada pode dar errado!” (copyright)

A venda de uma vida sem sentido

O indivíduo é seduzido pela ideia de ter um negócio próprio, investe horrores na construção da infraestrutura necessária e começa a ver a coisa tomando forma.

Então chega uma pessoa e lhe pergunta: uma vez aberta sua empresa, como será seu dia a dia?

 

 

 

 

Um silêncio profundo dominará a conversa.

 

 

 

cricricri

Sério, já parou pra pensar nisto? Uma das razões pelas quais oficializamos a itexto foi nosso desejo de desempenhar um conjunto de atividades diárias no trabalho. Se você não sabe como será o seu operacional básico, pra quê abrir uma empresa?

Já parou pra pensar que uma vez aberto o negócio, você passará um bom tempo nele fazendo alguma coisa? Será que descobrir o que é esta “alguma coisa” depois é uma atitude inteligente?

A venda de uma realidade gringa

Arde: te mostram um modelo de negócio maravilhoso, aquela estratégia genial que funciona extremamente bem… na Europa e Estados Unidos.

São casos envolvendo ideias pouco convencionais no primeiro momento como Twitter (quem poderia imaginar: 144 caracteres!), Facebook, Apple (quem imaginaria um computador em casa?), Microsoft (os caras largaram a faculdade!) e por aí vai.

Mas não mencionam que lá existe uma cultura empreendedora centenária, uma economia brutalmente competente, um governo que não te sufoca com impostos, etc. Não mencionam que é um ambiente no qual você tem fôlego para falhar.

Sério: criar rede social no Brasil? Nossos problemas  são outros! Cansei de ver consultores ou investidores apresentando modelos gringos aqui.

E sinceramente, desconfio que o modelo de startup no Brasil é fadado ao fracasso por ser vendido, em sua maioria, baseado em ideias estrangeiras muito mal adaptadas à nossa realidade (basta pensar um pouquinho no próprio termo “startup”).

Gente que te ensina a abrir uma empresa e cuja própria empresa é… ensinar pessoas a abrir a própria empresa.

Meus comentários são desnecessários aqui.

(aliás, já escrevi a respeito)

As fórmulas prontas

“X passos para o sucesso”, “N oportunidades para ficar milionário em 2017”, “as Z coisas que pessoas de sucesso fazem todo dia”

Sério que as pessoas acreditam que a realidade é tão simples assim?

Levando em consideração a quantidade de leitores destes livros de “auto-ajuda para empreendedores”, era para estar pipocando milionários. Cadê eles?

Uma infantilização extrema

Por favor, faça o seguinte exercício: acesse o YouTube e busque por vídeos apresentando startups. É grande a possibilidade de você ver o seguinte:

  • Uma animação cartunesca
  • No fundo musical vai ter um banjo (99,99% de chance! Se não tiver banjo, tem pandeiro!)
  • Todas as pessoas sorriem por que todo mundo é divertido e o mundo colorido!

Talvez soe ranzinza mas… quem quer investir em uma empresa dirigida por pessoas assim? Oh: desculpe, talvez eu esteja com inveja por não fazer parte do grupo das pessoas legais… (percebo que não faço, sinto alívio!)

Esta infantilização se manifesta de forma clara quando observamos o uso repetido ao extremo da imagem do jovem prodígio.

Na realidade a infantilização nada mais é que a exploração da carência presente em cada um de nós (e sobre isto ainda escrevo um texto).

Então empreender é ruim?

Claro que não: o que quero mostrar neste texto é que abrir uma empresa não é algo simples ou fácil como este povinho picareta diz nos palcos. Empreender é algo sério e deveria ser um ato virtuoso, mas infelizmente aos poucos estão criando uma aura negativa em torno do verbo.

Quer abrir uma empresa, vai fundo, mas saiba aonde está entrando e nas consequências dos seus atos. Quer ver palestra de gente que diz te ensinar como agir? Vai lá e assista, mas pelo menos questione! Saiba assistir a uma apresentação.

Desculpem a franqueza, mas quem tem uma empresa real, como eu, ao assistir este conteúdo furado tem seu estômago revirado. Alguém tem de falar, tá chato ver a quantidade de pessoas afundando por que se iludem com estas lorotas.

formacao_itexto

Formação itexto de volta – Groovy, Grails, Spring e mais!

Desde o ano passado ministro esporadicamente treinamentos online e ao vivo pela itexto através do nosso projeto Formação. E este momento está se aproximando novamente: desenvolvemos uma nova plataforma de ensino e estamos planejando novos treinamentos de Groovy, Grails, Spring e outras tecnologias com as quais trabalhamos e que sabemos gerar valor real para nossos clientes.

Os treinamentos sempre são ao vivo, pois acreditamos que nada substituí a presença do instrutor e seu contato direto com os alunos (as aulas ficam muito mais ricas).

Nosso primeiro treinamento será o “Grails Essencial”  e já estamos preparando novos relacionados ao ecossistema Groovy e Grails (muitas ideias!).

Se estiver interessado(a), basta preencher nossos formulários de interesse, presentes tanto na página inicial do Formação quanto em todos os treinamentos que irão aparecer no site.

Assim que as turmas forem lançadas, aqueles que manifestarem seu interesse pelo cadastro serão chamados, lembrando que as turmas sempre são reduzidas (8 alunos no máximo) e costumam lotar bem rápido!

Há também um formulário de contato no qual vocês podem nos enviar suas dúvidas e sugestões.

Aguardo vocês!

Link para a Formação itexto: http://formacao.itexto.com.br

grails_vuejs

Grails + Vue.js – A série

Resolvi iniciar uma nova série de vídeos chamada “Grails + Vue.js”. Ainda não sei quatos vídeos serão publicados: o objetivo é apresentar rapidamente e de forma bem leve o Vue.js para desenvolvedores Grails, além de também mostrar como é o desenvolvimento de SPAs usando estas duas ferramentas e mais algumas (como o Zurb Foundation).

Já publiquei o primeiro vídeo, e você pode acompanhar a play list do YouTube neste link, espero que gostem!

O código fonte pode ser obtido no GitHub neste link.

vuejs

Exprimentando Vue.js – aplicando no /dev/All

Recentemente comecei a buscar frameworks JavaScript para serem aplicados em nossos projetos na itexto. Publiquei algum tempo atrás minha experiência de aprendizado envolvendo o Angular.js: chegou a hora de falar sobre o Vue.js.

Como fui parar no Angular.js

 

angular-js_600x400

Aprender Angular foi uma experiência muito enriquecedora para mim pois me pos em contato mais profundo com diversas ferramentas usadas no ambiente JavaScript, tais como o Gulp e o NPM.

O que mais gosto no Angular é a ideia de templates renderizados do lado cliente. Apesar de na esmagadora maioria dos nossos projetos boa parte da renderização ser realizada do lado servidor (diversas razões para isto, o que, por si só, já daria um post), em alguns casos a renderização do lado cliente nos parece a solução ideal.

Um dos nossos projetos em que os templates do Angular cairam como uma luva foi o /dev/All que, até a versão 1.8 usava este framework do lado cliente.  Não conhece o site? Abaixo você pode ver um print do mesmo:

devall_vue

Com o passar do tempo a arquitetura do /dev/All foi sofrendo algumas modificações, dentre elas a criação de uma API na qual estamos trabalhando aos poucos. Entre as chamadas desta API está a nossa busca, que é usada atualmente na interface do site com o usuário final.

A primeira versão do /dev/All era 100% renderizada do lado servidor. Com isto, sempre que o usuário paginava os posts ou realizava uma busca, todo o conteúdo da página era carregado novamente (ignorando os cacheamentos de JavaScript e CSS).

Este problema foi a razão pela qual na versão 1.8 do /dev/All passamos a usar o Angular na confecção da nossa interface gráfica. O resultado foi muito bom: os usuários agora baixavam uma única vez o código da página e em todas as chamadas subsequentes o Angular fazia o trabalho de atualização da interface.

Como encontrei o Vue.js

vuejs

Tivemos esta experiência bem sucedida com o Angular mas fiquei com a impressão de que ele era uma solução muito complicada para as nossas necessidades. A curva de aprendizado do Angular é muito íngreme: são muitos conceitos para que você comece a se tornar produtivo: controladores, módulos, injeção de dependências, inversão de controle, diretrizes. Minha única preocupação era a view: eu só queria um template que fosse renderizado do lado cliente e que tirasse proveito da nossa API.

Eu também queria algo com o qual pudesse reaproveitar conhecimentos que já dominava, como o jQuery: misturar Angular e jQuery é complicado para dizer o mínimo (sei que é possível, mas mesmo assim é mais complexo que o necessário).

Nisto passei por algumas soluções interessantes: Mustache, Rivets, Tangular (apenas 2Kb!) e mais algumas alternativas, dentre as quais estava o Vue.js, cujo primeiro contato foi feito totalmente por acaso através de um vídeo do Vedovelli.

Resolvi experimentar o Vue.js: o primeiro passo foi ler o seu guia para desenvolvedoresA leitura do guia me fez esquecer o Angular. Achei a documentação do Vue.js uma das melhores que já li: rápida, direta e curta. Terminada sua leitura você já consegue criar coisas interessantes com o framework.

(o guia do Vue.js devia ser usado como exemplo de documentação bem feita: virei fã)

A impressão que tive do Vue.js foi a de se tratar de um “Angular” fácil de aprender. Em aproximadamente três horas de estudo você já consegue criar aplicações com o Vue.js: no caso do Angular levou pelo menos uma semana para começar.  Vi esta experiência de aprendizado se repetir com Lucas, nosso estagiário na itexto.

A versão 1.9 do /dev/All, publicada no dia 19/6/2016 substituiu o Angular pelo Vue.js (usamos a versão 1.0). Quantas linhas de código JavaScript precisamos escrever para criar toda a interface do site? 30 (!), incluindo o boiler plate padrão do jQuery ($(document).ready).

O jQuery faz as chamadas ao servidor e o Vue.js renderiza o resultado para nós. É simples assim. :)

Outras coisas que gostei no Vue.js

Além da excelente documentação e facilidade de ser usado com outras bibliotecas (jQuery), houve outras razões pelas quais este framework me ganhou.

API fácil

A API do Vue.js é muito simples: essencialmente você só precisa conhecer o construtor Vue. E não só o guia é fácil de ler: a documentação da API também é excelente!

Levou um tempo até que eu me habituasse com o modo como a injeção de dependências é realizada no Angular (especialmente os problemas que podem surgir durante a minificação e “uglyficação” do código). No caso do Vue, como é focado apenas na view e não há controladores, tudo fica muito mais fácil.

Tem o que gostei no Angular

A sintaxe dos templates do Vue é muito parecida com a do Angular. Tanto é que não precisei reescrevê-los ao migrar para o Vue.js: a grosso modo bastou trocar as diretrizes “ng-*” por “v-*”.  A mesma sintaxe “mustache” se mantém.

Também há diretrizes, como o Angular, assim como filtros. A diferença está na facilidade de aprendizado.

Outra similaridade importante: também implementa o data binding bidirecional. Este recurso é muito interessante, especialmente quando se quer construir interfaces de cadastro mais complexas como, por exemplo, formulários do tipo mestre-detalhe ou mesmo simulação de planilhas (para estes dois casos já estamos projetando soluções baseadas no Vue.js na itexto).

Por falar em data binding, o modo como lida com formulários é também essencialmente o mesmo que temos no Angular.

Criação fácil de componentes

Assim como o Angular, o Vue.js também te permite criar componentes. No caso, o Vue é muito inspirado na spec Web Components do W3C. Note que é inspirado e não uma implementação desta spec.

A vantagem é que você pode escrever sua biblioteca de componentes reaproveitáveis com o Vue e, caso deseje abandoná-lo no futuro, o trabalho de reescrita (em teoria) deve ser bem menor.

Concluindo

Para situações nas quais só me interessa a renderização do lado cliente e a aplicação não é muito complexa (como o /dev/All), creio que Vue.js seja uma solução mais interessante que o Angular.

Se você ainda não o conhece, sugiro que leia seu guia e brinque um pouco com ele: é uma experiência muito interessante.  Na excelente documentação oficial há uma seção interessante na qual o comparam com outros frameworks, recomendo sua leitura, apesar de naturalmente se tratar de um texto tendencioso.

Creio que, apesar de ter preferindo o Vue, estudar Angular é essencial: tenho certeza de que boa parte da facilidade que tivemos em aprendê-lo (Vue) se deve aos conceitos que precisamos aprender em nosso estudo do Angular.

Se você gosta de vídeos, o Fabio Vedovelli tem uma série a respeito que vale muito à pena assistir (como tudo o que ele faz).

comentario_agradavel

Quando o comentário realmente documenta o código

Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.

Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.

Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.

Tudo é história

Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.

Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).

Lidando com o passado – reconstruindo o histórico perdido

 

Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:


/*
Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */
Issue na qual se encontra documentado o requisito que deu origem ao
requisito: http://meusistemadeissues/issue/825
*/
class EmissorEmail {

É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:

int diasEntreDatas(Date dataInicial, Date dataFinal) {
/*
Havia um erro no código abaixo que não considerava sábados e domingos,
gerando resultados inválidos.
Issue: http://seusistemadeversoes/issue/847
Alterado por Henrique Lobo - 1/3/2016 - 14:20
*/
}

Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.

Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.

Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:

  • Use um sistema de issues e o referencie em seus comentários
  • Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
  • Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada

Lidando com o passado recente

Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:


int soma(int x, int y) {
return x + y;
/*
Acho a versão anterior pura frescura, por isto substituí pela
minha alterantiva melhor otimizada e que não usa ifs!
Issue: http://www.meusistemadeissues.com/issue/13
Henrique Lobo - 2/2/2012 - 13:13
return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y;
*/
}

Lidando com o futuro (usando lembretes)

Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).

A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.


boolean autenticar(String login, String senha) {

/*
TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema
Henrique Lobo - 12/3/2004 12:00
Issue: http://www.meusistemadeissues.com.br/issues/666
*/
if (login == "dede") {
return true;
}
}

Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):

todo_eclipse

Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.

Refatorando comentários?

Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?

De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.

Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.

Não divulgue segredos

Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:

  • Credenciais de acesso a serviços ou servidores
  • “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
  • Críticas ao empregador ou outros membros da equipe
  • Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)

Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?

Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.

Boas leituras

Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:

Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman

Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books

As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.

Concluindo

Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.

Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)

logo_freehand_pequeno

Melhorando os Guias da itexto

Na itexto, além do Groovy e Grails Brasil e do /dev/All há um terceiro projeto ao qual me dedico já faz algum tempo: os nossos guias.

São ebooks gratuitos que escrevemos e disponibilizamos gratuitamente para a comunidade: por enquanto há apenas três: Injeção de Dependências com Spring, Usando Git e Usando Jenv. Há m ais alguns a caminho: conforme progrido nos meus estudos sobre Docker, acabei iniciando a escrita de mais este texto e, em um futuro ainda mais próximo, devo publicar outro sobre o uso do Spring Security com Grails.

Hoje lançamos a versão nova do site (pra variar, odiava a antiga). Está com um visual melhor (similar ao do /dev/All), e trás duas novidades interessantes: a primeira é a criação da mailing list para que possamos informar nossos leitores a respeito das novidades.

A segunda é que agora todos os textos terão seu “código fonte” publicado no GitHub da itexto, assim vocês poderão acompanhar o desenvolvimento deste trabalho também.

E o link? http://www.itexto.com.br/guias

Me digam o que acharam, ok? Críticas são bem vindas!