All posts by Kico (Henrique Lobo Weissmann)

Revista do /dev/All, este blog e o guia do Apache HTTP Server para devs

Estamos iniciando dois projetos novos na itexto sobre os quais vou falar um pouco aqui neste post.

Revista do/dev/All

Com tantos sites bons por aí focados em excelentes posts, tais como o Tableless, Smashing magazine, A List a part e tantos outros, pensei: por que não ter algo assim também aqui no Brasil? E dado que o /dev/All está passando por tantas melhorias, por que não matar o blog antigo (que era um grande flop) e substituir por algo melhor?

Foi assim que surgiu a Revista do /dev/All, que tem posts escritos tanto pela equipe da itexto (incluindo eu, claro) quanto outros que se interessem em participar também. A ideia é sempre a mesma: excelente conteúdo técnico em português.

E isto impacta diretamente neste blog: se você o acompanha já deve ter percebido que faz um bom tempo que posts estritamente técnicos não são publicados aqui. Aqui é o local no qual escrevo minhas experiências que, convenhamos, não batem com as de todo mundo (e também aonde inicio amáveis tretas). A Revista do /dev/All me propicia o local no qual eu possa publicar conteúdo estritamente técnico, ou seja, tutoriais, guias, etc.

O link para acessar? https://revista.devall.com.br

Guia do Apache HTTP Server para devs

Meu primeiro alvo nesta empreitada foi o Apache HTTP Server, e por uma razão muito simples: eu apanhava bastante dele. A documentação oficial é muito ruim e sempre senti falta de um bom livro que me guiasse, do básico ao avançado. Mas não um guia para o pessoal de infraestrutura, mas sim desenvolvimento.

E experiências recentes (isto sim, um post para este blog) me fizeram aprender horrores a respeito do Apache (e não só ele, esperem um guia do Tomcat e Nginx em breve!), e recursos que nem imaginava serem possíveis com ele.

Foi por isto que iniciei o guia, que você pode acessar neste link: https://revista.devall.com.br/apache-http-server-para-devs/

Espero que curtam estas novas empreitadas tanto quanto estou gostando de realizá-las. Aguardo vocês lá!

Eu e o Angular

Semana passada colocamos no ar a nova versão do /dev/All que mudou radicalmente sua arquitetura (detalhes não técnicos neste link): dentre as principais mudanças está o fato de que agora a interface com o usuário é um SPA. Este é o primeiro post no qual compartilho com vocês algumas das coisas que aprendi no processo.

Note que esta é a visão de alguém que tinha como ferramenta principal para o desenvolvimento de aplicações SPA o Vue.js. Sendo assim minhas impressões em sua maior parte fazem uma comparação com ele. Leve em consideração que são “novas novas impressões” a respeito do Angular. Muita coisa pode mudar conforme minha experiência progride.

Por que não gostava

Uma das principais razões pelas quais aprendi Vue.js, confesso, foi para não usar o Angular. Além do trauma da quebra de compatibilidade da versão 1 para a 2, naquele momento ele me parecia muito mais complexo do que eu precisava. E o fato da versão 2 ser essencialmente TypeScript e não mais JavaScript também me incomodava (que ironia, eu, que amo Grails, dizer isto…). Também me incomodava horrores a documentação oficial que peguei na época: era horrível.

Eu já havia experimentado o Angular em projetos legados e, acredito, isto contribuiu também para minha péssima impressão original do framework. Vue.js era para mim como um copo d’água para quem estava no inferno. O tempo passou e acabei dominando o Vue, que se tornou até agora minha ferramenta favorita para o desenvolvimento de SPAs, aplicações híbridas e qualquer projeto que envolvesse interatividade mais rica. Até agora.

Mas o grande lance é que minha visão a respeito do Angular estava errada. Enquanto o Vue é essencialmente focado na camada de visualização (e essencialmente apenas nela), não havia ainda atinado o Angular como um framework, mas sim como uma biblioteca.

Resumindo, minha aversão ao Angular era resultado destes fatores:

  • A documentação de anos atrás que era bem ruim.
  • O trauma da quebra de compatibilidade da versão 1 para a 2 do Angular (acaba que sempre penso nos projetos a médio e longo prazo).
  • O fato de se mostrar mais complexo do que minha real necessidade na época.
  • A adoção do TypeScript como linguagem e não JavaScript.
  • Eu estar ignorando o aspecto essencial do Angular: o deste ser um framework (este doeu) para aplicações maiores.

Por que estou gostando

O que me fez realmente gostar do Angular foi criar vergonha na cara e perceber que já havia passado da hora de aprender o framework a fundo.

Chegou um dia no qual quis finalmente transformar a interface do /dev/All em um SPA e me peguei adotando o Vue.js sem sequer me questionar a respeito. Por que apenas Vue.js estava no meu radar? Era hora de sair da zona de conforto, o que me fez passear pelo React e… Angular novamente.

Um bom livro e uma melhor documentação

Dado que a documentação oficial do Angular que conhecia até então era um lixo, optei por desta vez escolher um bom livro ao invés da documentação oficial, e acertei. Comprei o “Angular in Action”, de Jeremy Wilken, publicado pela editora Manning. Sem sombra de dúvidas foi uma das melhores leituras do ano: é um excelente ponto de partida pra quem está começando, e como foi publicado em março de 2018, eu podia ter certeza de que estava lidando com uma das últimas versões do framework (olha o trauma se manifestando!).

Logo na sequência resolvi visitar novamente a documentação e, que surpresa! Está MUITO melhor. Segui o tutorial de uma ponta a outra e, numa experiência que começou em uma sexta-feira a noite e terminou no domingo, já havia devorado uns 90% da documentação oficial. Esta foi a primeira mudança: um bom livro e uma documentação muito melhor.

O ferramental

Mas mais do que a documentação, me encantou o ferramental do Angular. Quando comecei, muitos anos atrás, ainda não havia a ferramenta de linha de comando (ao menos eu não a conhecia). E caramba, como ela ajuda! Foi graças a ela que o aspecto framework do Angular ficou nítido pra mim (e até agora me pergunto: por que ignorei o essencial por tanto tempo???). Não só isto: o VS Code também oferece um suporte maravilhoso ao Angular e TypeScript (claro, é criação da Microsoft). Este foi o segundo fator: o ferramental do Angular é incrível e está muito à frente do que eu tinha no Vue.js.

Aliás, diga-se de passagem, minha experiência com o VS Code trabalhando no /dev/All foi tão boa que este acabou substituindo meu editor favorito até então, que era o Atom.

Ionic framework

É importante mencionar aqui outra razão importante que me motivou a estudar o Angular: Ionic. Apesar de haverem planos de no futuro este suportar o Vue.js, hoje ele suporta BEM mesmo é o Angular. De todos os frameworks híbridos que analisei, de longe Ionic foi o que, de novo, apresentou o melhor ferramental (isto merece um post no futuro).

(e olha que na itexto existe um framework que desenvolvemos para aplicações híbridas, baseado em Vue.js, que é simplesmente incrível)

TypeScript

Motivos irracionais me levaram a postergar o Angular por causa do TypeScript, confesso. Mas quando me atinei que uso Groovy no mundo Java esta irracionalidade foi aniquilada. Pouco a pouco fui aprendendo TypeScript e me encantando com a linguagem. Percebi que alguns dos erros comuns que cometemos com JavaScript não ocorrem no TypeScript: só isto já era razão para que a linguagem fosse adotada.

Devo confessar que parte da minha crescente adoção da linguagem se deu por causa do VSCode. Como ele me oferece um excelente suporte à linguagem (code complete, detecção de erros), ele me ajudou HORRORES a aprender os detalhes da linguagem e como ela funciona.

Sinceramente, não sei se o TypeScript terá lá uma grande longevidade dado que o JavaScript pouco a pouco vai se tornando um “TypeScript padrão”. Entretanto, hoje, e pelo menos pelos próximos três ou quatro anos, a linguagem se manterá, o que em si já justifica sua adoção.

(agora, sua documentação oficial, achei bem ruinzinha viu)

O framework em si

Quando comecei a entender mais a fundo como o Angular organizava e orquestrava seus elementos me apaixonei por ele. O conceito de módulos, por exemplo, achei incrível. De repente encontrei uma maneira muito mais interessante de modularizar código reutilizável entre projetos. É como um OSGi, só que no mundo JavaScript.

Os serviços também são muito interessantes: enquanto no Vue.js temos o Vuex para estado compartilhado, o que pode virar facilmente uma zona conforme o projeto cresce de tamanho, no Angular tenho serviços gerenciados por injeção de dependências e que podem ser singletons. Pronto: é como o Spring, só que no mundo JavaScript.

(OSGi… Spring… duas coisas que gosto no Java… agora do lado JavaScript/TypeScript da cerca…)

O modo como os arquivos que definem um componente são organizados também gostei bastante. No caso do Vue.js, temos os arquivos .vue do Vue Loader. É uma solução bacana, mas como tenho estilo, marcação e lógica no mesmo arquivo, conforme estes aumentam em complexidade, dificulta-se a manutenção (eu sei que o ideal é termos estes caras pequenos, mas eles crescem).  Gostei de ter arquivos em separado.

(Aliás, conto um segredo aqui: muito tempo atrás, quando comecei a aprender Vue.js, implementei o meu próprio “vue-kico-loader”, que era quase igual ao esquema adotado pelo Angular (sua manutenção ficou complexa, vi que o ideal era o Vue Loader, e aí abandonei o projeto))

Sabe do que não gostei? Da sintaxe dos templates: ter de usar coisas como [(ngModel)], *ngFor, coisas assim achei um saco. Neste aspecto o Vue.js é bem mais interessante.

Resumindo: para projetos maiores, a manutenção do código Angular se torna algo muito mais simples em relação ao Vue.js na minha experiência até agora.

Curva de aprendizado e produtividade

Aprende-se Vue.js muito mais rápido que Angular. Já tive experiências na itexto de pessoas sem nenhum conhecimento de desenvolvimento web que em quatro horas já se tornavam produtivas com o Vue.js. Aliás, este foi o fator que mais me encantou no Vue até hoje.

No caso do AngularJS, em minha primeira experiência, não observei isto. Levava um bom tempo até entender os controladores, o modo como eram as interações entre os elementos do framework e até mesmo alcançar uma produtividade mínima com ele.

No caso do Angular 6, que foi meu alvo, percebi que em um dia eu já estava conseguindo fazer alguma coisa com ele. Repare: “alguma coisa”. Ainda não me sentia confortável com a ferramenta. Mas passada uma semana de prática constante, hoje digo que sou bem mais produtivo com Angular que com o Vue.js. Em grande parte devido ao ferramental e do TypeScript.

No caso do Vue.js, usando o Vue.cli posso usar templates prontos que me dão um scaffolding similar ao do Angular, mas ele em si ainda não é tão evoluído, o que é natural, dado ser uma solução mais nova. Entretanto prevejo que no futuro este jogo vire, pois Vue.js ainda é mais fácil de dominar em pouco tempo, na minha experiência.

Como está sendo até agora

Está sendo ótimo. O grande teste é ter um sistema em produção no qual seja necessário dar manutenção de forma ágil. O projeto é o novo /dev/All, e sim, estou conseguindo realizar mudanças em minutos com um framework que ainda não domino inteiramente e com qualidade. Passou no teste.

Apesar de muita gente estar indo para o Vue.js e saindo do Angular, do ponto de vista corporativo, apostaria no Angular, pois a manutenção e o aspecto “framework” da ferramenta é realmente muito interessante. É fácil dar manutenção em uma aplicação Angular.

No final das contas o aspecto “ferramental” também conta bastante: é boas IDEs que ofereçam suporte decente ao framework adotado, e no caso do Angular, devido à sua própria história, isto fica evidente.

Esta tem sido minha experiência com o framework até este momento: aprendi algumas outras coisas que pretendo compartilhar com vocês em um futuro próximo conforme vou narrando aqui a jornada que entramos ao lançarmos o novo /dev/All, pois muitas das minhas concepções mudaram e estão mudando no processo.

Até lá. ;)

PS:

ainda me confundo um pouco com os termos Angular e AngularJS.

Framework: você REALMENTE sabe o que é isto?

Recentemente retomei meu contato com o Angular: está sendo uma experiência muito enriquecedora pois a imagem negativa que tinha da ferramenta recebeu um significativo upgrade. Li uns 90% de toda a sua documentação oficial (incluindo este livro incrível) e o que posso dizer é: que framework maravilhoso! Mas o que é um framework?

Um post atrasado no mínimo uma década

Meu primeiro contato com o termo “framework” foi quando comecei a aprender Java. Naquela época (1996, 97, bem mais em 2001, 2002) muito se falava a respeito de frameworks, especialmente após o lançamento do Struts.  Confesso que não conseguia entender direito o significado do termo, e não é pra menos. Vejam o que me diziam na época a respeito:

  • “Framework é uma aplicação pré-pronta”.
  • “É um conjunto de códigos que você pode reaproveitar em seus projetos e que te poupa muito tempo”.
  • “É uma solução pré-pronta para problemas recorrentes”.

Mas e uma “biblioteca”? Ela também não é um conjunto de códigos pré-prontos que eu posso reutilizar?

Se existem estas duas palavras: bibliotecaframework, seriam estas sinônimos? Se sim, por que veio depois este termo, framework? Será que eu o descobri posteriormente e que o mesmo sempre existiu (sim)?

Não são sinônimos e hoje, após trabalhar com diversos sistemas que não foram escritos por mim posso dizer algo com plena segurança: boa parte do software que temos dificuldade em manter hoje é mal escrito devido à má compreensão do termo “framework”.

O que é uma biblioteca?

Primeiro é importante saber aquilo com o qual as pessoas costumam confundir o framework: a biblioteca. Esta sim é um conjunto de códigos reutilizáveis que vão se apresentar sob a forma de funções, classes, módulos…

Seu código invoca sua execução e como consequência o trabalho pesado é realizado para você. Vamos a alguns exemplos práticos. O código a seguir, escrito em Java (extraído daqui) usa as bibliotecas de compressão da linguagem para gerar um arquivo zip.

package com.mkyong.zip;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class App 
{	
    public static void main( String[] args )
    {
    	byte[] buffer = new byte[1024];
    	
    	try{
    		
    		FileOutputStream fos = new FileOutputStream("C:\\MyFile.zip");
    		ZipOutputStream zos = new ZipOutputStream(fos);
    		ZipEntry ze= new ZipEntry("spy.log");
    		zos.putNextEntry(ze);
    		FileInputStream in = new FileInputStream("C:\\spy.log");
   	   
    		int len;
    		while ((len = in.read(buffer)) > 0) {
    			zos.write(buffer, 0, len);
    		}

    		in.close();
    		zos.closeEntry();
           
    		//remember close it
    		zos.close();
          
    		System.out.println("Done");

    	}catch(IOException ex){
    	   ex.printStackTrace();
    	}
    }
}

FileOutputStream, ZipOutputStream, ZipEntry, FIleInputStream são classes disponibilizadas pela biblioteca padrão do Java SE. Observe algo interessante: eu simplesmente as importo e, na sequência, meu código define quando estas serão executadas e como.

É possível criar novas sub-classes baseadas nestas que acabei de mencionar, entretanto alguns aspectos se mantém:

  • Estou usando código pré-existente que não foi escrito por mim.
  • Meu código está definindo quando usarei estas classes/funções.

Outro exemplo bem simples podemos ver no código C escrito a seguir:


#include <stdio.h>

int main(void) {
  printf("Aqui de buenas usando a função printf");
  return 0;
}

Agora ao invés de classes estou importando a biblioteca de I/O clássica da linguagem C e, na sequência, reaproveito a função printf, disponibilizada por esta. E novamente o fluxo do meu programa é definido inteiramente por mim: imprima este texto inútil e na sequência retorne 0.

Então vamos à definição Kiconiana de uma biblioteca: código escrito por terceiros focando o reuso e cuja ordem de execução é definida inteiramente por você.

E o framework, o que é?

É uma aplicação semi pronta? Sim, mas esta é uma definição muito vazia (bibliotecas também podem ser consideradas como tal). É um conjunto de código que posso reaproveitar? Óbvio, mas também é uma descrição incompleta e ainda gera confusão em relação ao termo biblioteca. É uma solução para um problema recorrente? Também. Então, qual a diferença?

O significado fica mais claro quando pensamos na tradução do termo para o português: framework pode ser traduzido como molduraarmação. Imagens surgem em minha mente:

isto é uma moldura

Isto é um vigamento, que também é chamado de armação

e esta é uma armação de óculos

Armação, vigamento e moldura: o que tem em comum? Me lembro de ficar um bom tempo me questionando a respeito. Framework: por que este termo? O que isto tem a ver com moldura???

A moldura existe para suportar a gravura/imagem, o vigamento para que as telhas ou piso possam ser incluídos acima de si e a armação dos óculos fornece a estrutura necessária para que as lentes possam estar bem posicionadas em relação à nossa face. E o framework?

Enquanto no caso da biblioteca o ciclo de vida do nosso código é de nossa responsabilidade, ao lidamos com o framework o contrário ocorre: nós fornecemos a gravura para a moldura, o piso para o vigamento e as lentes para a armação.

Não somos nós que definimos quando nosso código executa: quem define isto é o framework. Se você já trabalhou com Spring ou Angular talvez isto lhe soe familiar. Lá vai: frameworks nada mais são que a aplicação mais básica do conceito de inversão de controle.  A propósito, o Martin Fowler tem um texto muito bom sobre isto.

Vamos a um exemplo bem simples baseado em Angular? Imagine que eu queira escrever um componente: então escrevo algo similar ao código a seguir usando TypeScript:


@Component({
  selector: 'login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.css']
})
export class LoginComponent implements OnInit {

  credentials: Credentials;

  constructor(private usuarioService: UsuarioService) { 
    this.credentials = new Credentials(null,null);
  }

  ngOnInit() {
  }

  entrar() {
    this.usuarioService.auth(this.credentials);
  }

}

Aquela função ali, ngOnInit, não sou eu quem a invoco: é o Angular. Repare: apenas forneço os músculos para este esqueleto. Eu sei que aquele método será invocado, mas não por mim. Em momento algum escrevo código como o exemplo a seguir:

usuarioService = new UsuarioService();
login = new LoginComponent(usuarioService);
login.ngOnInit();

O código acima é aquele que tipicamente escrevemos ao lidar com bibliotecas. Mas o que ganhamos com esta delegação? Será que minha função realmente será chamada?

Lembra quando mencionei que sim, frameworks são soluções para problemas que ocorrem com frequência e que também são aplicações pré-prontas, mas que vão além? Pois bem: o problema que todo framework resolve é essencialmente o ciclo de vida do nosso código.

Autores de frameworks se preocupam com a vida de nossos objetos/funções: quando devem ser criados, usados e destruídos. E isto de uma forma ótima, garantindo que nosso trabalho consista apenas em fornecer o conteúdo necessário para que nossas necessidades de negócio sejam atendidas.

Vamos a mais um exemplo: desta vez usando a API Servlet do Java. Um Servlet pode ter diversas formas, a mais comum é o HTTP que tem como objetivo receber requisições pelo protocolo (HTTP), executar nossas regras e, finalmente, retornar conteúdo ao usuário final da aplicação. Vamos implementar um servlet?

package br.com.kicosoft;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletDemo1 extends HttpServlet{
	
	public void doGet(HttpServletRequest request, HttpServletResponse response)
	throws IOException{
		PrintWriter out = response.getWriter();
		out.println("<html>");
		out.println("<body>");
		out.println("
<h1>Sou um servlet feliz!</h1>

");
		out.println("</body>");
		out.println("</html>");	
	}
}

Primeiro eu escrevo a minha classe, que extenderá uma outra chamada HttpServlet. Meu papel consiste apenas em sobrescrever os métodos HTTP que me interessam, no caso, doGet, que corresponde ao método GET do protocolo. Minha função define o que deverá ser retornado ao usuário: o conteúdo HTML que você vê em meu código.

Repare na riqueza: não preciso me preocupar em implementar o protocolo HTTP, ou mesmo um algoritmo de espera (ocupada ou não) de requisições que chegam ao meu servidor. Apenas forneço ao meu framework o código que desejo ser executado.

Então, como posso definir um framework à moda Kiconiana? É o maestro responsável por orquestrar seu código visando resolver um ou mais problemas específicos .

O problema específico pode ser a construção de uma aplicação web, uma integração (pense em Apache Camel implementando os Enterprise Integration Patterns), um jogo (pense em um engine como o Unity). Seu papel é portanto apenas fornecer o código que será executado pelo framework. O que nos leva à grande questão.

Frameworks são burocráticos

Lembra no início deste post quando disse que boa parte do código mal escrito que vemos hoje tem como principal problema o fato de haver uma má compreensão a respeito do termo “framework”? O problema nasce quando ignora-se este fato: frameworks são burocráticos.

O termo burocracia tem uma conotação bastante negativa mas é um fato necessário para que haja ordem, para que se consiga formalizar a identificação de elementos.

(Sabia que a escrita nasce de uma necessidade burocrática? Dica: pesquise sobre a origem da escrita cuneiforme e os sumérios.

Lembre: burocracia é uma coisa, burrocracia, outra.)

A literatura nasce de um hacking da burocracia. Pense nisto!

Imagine que você irá escrever um framework: seu papel é orquestrar a execução de código de terceiros, certo? Como você o identifica este código e o papel a ser desempenhado por este? Alguma formalização precisa ser posta em prática, o que ocorrerá através da definição de padrões, tais como:

  • Presença de arquivos de configuração que identifique os artefatos. Lembra do XML no Java ou Spring?
  • Inclusão de anotações em nosso código. Olha ali o meu exemplo usando Angular e a anotação @Component.
  • A implementação de uma interface ou extensão de classes (lembra do meu Servlet?).
  • Padronizações no código como, por exemplo, a definição de nomes padrão para eventos de ciclo de vida dos objetos (já viu Tapestry?).
  • Qualquer outro dispositivo que sirva para marcar o papel desempenhado pelo código a ser orquestrado.

O principal problema que encontro em código legado é justamente este: quem o evoluiu não se esforçou o suficiente para conhecer o framework adotado na escrita do projeto. E ainda pior: usou esta “moldura” como se fosse uma biblioteca, desrespeitando completamente o ciclo de vida proposto por esta.

Sabe aquele sujeito que sempre “dá um jeitinho” na burocracia cortando caminho? É o programador que usa o framework como biblioteca e ferra a gente no futuro.

Frameworks são limitados

Assim como o termo burocracia, a palavra limitada também tem uma conotação negativa em nossa sociedade, mas infelizmente é verdade: frameworks são limitados (e tem de ser). Aqui nasce outro problema que encontro em muito código legado.

Lembra que na definição Kiconiana menciono o fato do framework visar resolver um ou mais problemas específicos? Pois é: meu framework web favorito é o Grails, mas não o uso para implementar integrações.

Apesar de 90% do código que vejo ser escrito hoje visar resolver o problema da construção de aplicações web (ou web services, micro-serviços), este não é o único problema computacional a ser resolvido.

Talvez você precise escrever uma automação residencial (HomeKit da Apple), ou quem sabe uma integração (Apache Camel), talvez seja a implementação de um jogo de tiro em primeira pessoa (Cry Engine). Posso ficar um bom tempo aqui com exemplos.

O importante é: muitos dos problemas que encontro são resultantes da má escolha do framework para aplicações distintas do seu propósito original. Isto deve ser levado em consideração. Nem tudo é uma aplicação web, e desconfio de gente que diz ser capaz de resolver qualquer problema usando um único framework.

O que a armação, a moldura e o vigamento tem em comum? Eles limitam a forma do que irão orquestrar.

Concluindo

Estudando o Angular (6) fiquei maravilhado com o modo como ele organiza meu código fonte e orquestra a sua execução, o que me fez voltar ao conceito de framework e, na sequência, finalmente liberar este post.

Resumindo, digo que você deve evitar as seguintes armadilhas ao escrever seu código:

  • Saber se precisa realmente de um framework ou de uma biblioteca (em 95% das vezes usará os dois no mesmo projeto).
  • Saber como usar uma biblioteca e, principalmente, um framework.
  • Buscar entender as formalizações definidas pelos autores do seu framework (poderíamos falar o mesmo a respeito de bibliotecas: pense em OpenGL).
  • Entender para qual fim o framework foi escrito e usá-lo apenas para este fim.
  • Resumindo o resumo: você deve respeitar o framework.

Infelizmente (ou felizmente?) não se discute com tanta ênfase hoje o significado dos termos biblioteca e framework. Talvez pelo fato de terem se tornado ubíquos para nós com o passar do tempo, o que mostra termos evoluído (e muito) de lá pra cá.

Mais uma vez o Wittgenstein estava certo: a maior parte dos problemas surge da má compreensão da linguagem.

Ludwig Wittgenstein – 1889 – 1951

Podcast da itexto

Um projeto razoavelmente antigo finalmente foi pro ar hoje: é o Podcast da itexto. O objetivo é divulgar algumas das conversas que temos no escritório (na realidade, é uma volta às conversas, pois é gravado na hora), conversas estas que sempre achei que deviam ser públicas mesmo, por que sempre surgem ideias bem interessantes.

Então achamos um modelo inicial, que é a gravação sem cortes ou edição: apenas nós, conversando e gravando. Estamos aprendendo ainda como é que se faz isto, por isto com certeza quem está acostumado a ouvir podcasts irá encontrar alguns erros. Entretanto já detectamos alguns e para a próxima vez já serão evitados.

A quem se interessar, segue o site do projeto: http://www.itexto.com.br/podcast 

Há também o nosso feed no SoundCloud, que você pode acessar aqui. Em breve já vai estar disponível no iTunes e outras mídias também, vou atualizando vocês por aqui.

Espero que gostem, toda sugestão é bem vinda!

Novos projetos para a comunidade: meetups e mais uma mailing list

Com o crescimento da Itexto estou podendo voltar a me dedicar a antigos projetos que tinha e não conseguia tirar do papel: este post é pra divulgar estes projetos. Conto com a participação de vocês!

Nova mailing list voltada para desenvolvedores Groovy, Grails e Spring

Algum tempo atrás havia criado a mailing list “Semana Groovy”. Foi um projeto bem sucedido por algum tempo, porém, devido à minha agenda acabou indo para o segundo plano e, posteriormente, acabou terminando.

Então, dado que temos mais uma comunidade agora, que é o Spring Brasil, achei que seria interessante unir estas duas turmas (Groovy/Grails e Spring) que, apesar de distintas, possuem muita coisa em comum (na realidade, é como se fossem a mesma, só não sabem ainda disto).

Para unir estas duas comunidades criei uma nova mailing list: Mundo Groovy/Spring, unindo todos os membros das duas comunidades, o que soma mais de 2700 membros hoje.

A ideia é a mesma: divulgar eventos, bons posts, apresentações e notícias relacionadas a estas tecnologias. Se você já é membro do Groovy e Grails Brasil ou Spring Brasil, já participa destas mailing lists automaticamente. Caso contrário, basta preencher o formulário abaixo.

Inscreva-se na lista “Mundo Groovy/Spring”!

Meetup Spring, Groovy e Grails em BH

Este já é um projeto local: já estamos coletando ideias para nossas primeiros encontros. Neste momento estamos apenas coletando participantes que queiram se juntar a nós, ao vivo, aqui em Belo Horizonte.

No primeiro momento os encontros serão presenciais, entretanto já estamos planejando alguns hangouts também. Conto com a participação de vocês.

Link para o meetup? Clique aqui.

Conto com a participação de vocês!

PS: sobre meu último post: “Quem nos forma está nos deformando?”

Um número muito grande de pessoas vêm me procurando em off a respeito do meu último post, no qual começo a relatar as consequências da degradação do ensino acadêmico.

Ainda não exauri o assunto: esta semana exponho algumas consequências reais, não apenas em TI, mas em outras indústrias também.