Arquivo → March, 2009
Is SEO really worth it?
I’ve been tracking the traffic of this blog (I got something like 1000 to 3000 visits/day (thank you all for that)) for some time now, and just noticed something really interesting about it. Less then 4% of all the traffic comes from search engines (and I’m really well placed on these, just type grails or groovy and you’ll see it).
Most of the traffic actually comes from blog agregators like DZone, Digg, and other blogs, which shows something that just now became clear to me: all this SEO sellers talk is bullshit for a single reason: the search engine is not your primary site, but some other which is all about your favorite subject!
Actually, it seems to me that people only use search engines when are getting into some new subject or trying to actually find something for a given need. And watching how other people surf the web, I can see the same behavior over and over again.
Something quite obvious is usually ignored by those SEO experts: people don’t get into your website BY Google. They actually get into your site through some other related source, like blogs, blog agregators and so on! So after doing some search (with a search engine :) ) I got into some conclusions that I whould like to share here:
Google is not the only search engine in the world
Seriously, in my research I found several “experts” which only optimize your website for Google. What about the others? Can you really ignore their existence?
Don’t pay for what is free!
In my research, I saw several “SEO experts” selling a service which is basically the execution of wizards on your site. Would you pay someone to do what you can do by yourself? I found several of these wizards here.
At this point someone could say: “Hey Kico! But you are talking just about your case!”. Yes, it’s true. But is a good argument (at least for me), don’t you think? I didn’t see any convincing SEO service on my research (maybe I didn’t look it right), just things I could do on my own!
So, after these thoughts, I would like to ask you: what do you think? Is SEO really worth it? Is it worth to pay someone for these services as a developer? I may be wrong about this subject, because I’m not a marketing expert (quite the opposite), but this is my first impression about it. What do you think? Am I in the right direction or am I just saying a lot of bullshit here?
SEO realmente vale a pena? (quase off topic)
Este blog tem entre 1000 a 3000 acessos/dia (muito obrigado a vocês por isto!), e analisando seus acessos, constatei algo MUITO interessante: menos de 4% dos acessos são provenientes de motores de busca como Google (e hoje em dia pode-se dizer que basicamente só há o Google…), mesmo com este site sempre presente no topo das listagens do mesmo.
(Faça a experiência: digite groovy ou grails no Google. Entre os sites no topo, com certeza estará este blog.)
A esmagadora maioria dos acessos é proveniente ou de outros blogs ou de agregadores de blogs, como DZone, Infoblogs, Digg, etc, o que me fez perceber algo nítido: o argumento de venda do SEO é essencialmente furado. E a razão é simples: a página inicial das pessoas não é o motor de busca, mas sim um site que aborda seu assunto favorito. No meu caso, por exemplo, consiste no Google Reader (Google sempre está presente…).E observando outras pessoas, ficou nítido que o motor de busca na realidade só é usado quando se está iniciando em determinado assunto ou alguma necessidade de pesquisa corriqueira.
(ai cai a ficha: o sujeito tem de ser MUITO a toa pra ficar o dia inteiro fazendo buscas na internet)
No mais das vezes, o óbvio é normalmente ignorado: as pessoas não chegam no seu site PELO Google, mas sim por sites que abordem assunto similar ou igual. Isto quer dizer que SEO é desprezível? Claro que não, pelo contrário. É um bom negócio ser a porta de entrada para determinado assunto, não resta dúvida sobre isto. Porém, com base nestes números, pude chegar a algumas conclusões bem interessantes:
Se alguém lhe oferecer serviços de SEO baseado apenas no Google, corra!
Apesar do Google ser o motor de busca dominante, isto não quer dizer que seja o único. Eu recebo por exemplo mais acessos provenientes do Yahoo! do que do Google. Seria mais interessante se fosse oferecido um serviço de divulgação mais abrangente. Sei lá: se bobear, comprar anúncio em algum site relacionado mais conhecido.
Se for para de fato divulgar seu site, divulgue-o em sites relacionados
As pessoas não ficam buscando artigos sobre qualquer assunto somente pelo motor de busca. Normalmente o fazem por agregadores de blogs, sites relacionados ou de clipping como Digg e DiHitt. Ao contrário do que ocorre na física, iguais se atraem.
Não é aparecer no motor de busca que atrai acessos: é o conteúdo
Eu realmente acredito que se algo é bom, atrairá pessoas interessadas, mesmo que demore algum tempo. Sendo assim, é muito mais negócio você criar conteúdo que realmente tenha alguma utilidade do que possuir um aglomerado de código html otimizado para aparecer no topo do Google.
Não pague para outros fazerem o que você pode fazer sozinho
Ao pesquisar para escrever este post, vi inúmeros “consultores de SEO” oferecendo um serviço que, sinceramente, poderia ser feito pelo próprio administrador do site, como por exemplo otimização do código da página. Você pagaria a alguém para executar um assistente apenas na sua página quando você mesmo poderia fazê-lo? (aqui há dezenas de ferramentas gratuitas)
Neste momento, alguém poderia dizer: “Ei Kico! Mas você está se baseando apenas no seu caso!”. E de fato, é verdade! Eu não sou um especialista em marketing, propaganda ou coisa do gênero. Na realidade, sou péssimo nisto. Mas os números que observo não mentem e, mais interessante ainda: o comportamento que observo nas pessoas é exatamente o que descrevi.
E após fazer inúmeras buscas pela internet (sim, usando o Google), o que pude perceber é que na esmagadora maioria das vezes, o que é vendido consiste basicamente no serviço de “execução de assistentes”. O sujeito pega o código do seu site e simplesmente executa uma das ferramentas cujo link expus acima, o que me faz de fato perguntar a vocês: SEO é realmente esta maravilha que vendem?
Why (at least for me) Groovy sounds like a Java++
I’m a Java guy, and as may sound obsolete to some, but I really like this language. As time goes by, and I start to know better another languages like Groovy or Ruby, I can’t avoid to feel a little envy of those. Java 5 revamped the language, that’s sure, but it still could be a little better.
This is why I really falled in love with Groovy: it really looks like Java, but solved many of it’s boring spots in a really elegant way. So, it’s no surprise that for me Groovy is like a Java++. Here comes a list of the problems solved by Groovy:
Strings
Interpolation:
In Java
int value = 3; String str = "O valor inteiro vale " + value
In Groovy
int value = 3
String str = "O valor inteiro vale ${value}"
Multiline strings
In Java
String multiline = "This is my string \n" + "which will have more than one \n" + "line!"
In Groovy
String multiline = """This is my groovier string with as many lines I want! And I don't even need those ugly + operators anymore!"""
Avoiding a NullPointerException
In Java
Object value = buildObject();
if (value != null) { // bla bla bla }
In Groovy
def value = buildObject()
if (valor) {//bla bla bla}
In Groovy, the truth isn’t always a boolean value. If something is null, so it’s false! Way simpler!
Checking if something is null:
In Java
Object obj = anything(); String str = "The value of this object is " + obj == null ? "null" : obj.toString(); // Horrible!
In Groovy
Object obj = anything()
String str = "The value will be ${?obj.toString()}" // Clean!
Getters and setters
Let’s face it: it’s really boring to keep writing getters and setters for all our Java Beans, isn’t it? Sure, we have our IDE’s allow us to do it automatically, but the code in the end is quite ugly don’t you think?
Well, here comes another comparison:
Java
class HotClass {
private int value;
public int getValue() {return this.value;}
public void setValue(int v) {this.value = v;}</em>
<em>private String text;
public String getText() {return this.text;}
public void setText(String v) {this.text = v;}
}
In Groovy…
Groovy
class WayHotterClass {
int value
String text
}
I don’t need to type all those getters and setters. Groovy will generate them for me automatically! Neat, don’t you think?
Optional return
This is a kind of a controversial point, but I really whould like to have something like this in Java. In Groovy, the last command on a code block is interpreted as a return value.
This is a completely personal opinion, but I think it generates a clearer code:
int sum(int a, int b) {
a + b
}
Closures
Closures almost were inserted on Java 7. Well, for a Java developer never saw them, the big question is: what the hell are those?
Basically closures are another data type doesn’t store a value, but a set of instructions. This is the most basic description I could find about it. With closures, you can have variables are in fact executable code, like the following example:
def hotClosure = {
print "\nI'm a closure."
}
And a closure may have parameters too:
def hotClosureWithParameters = {a, b ->
a + b}
And these closures are actually attribures of classes. So you can write something like this:
class Class1 {
def closure = {
"I'm the closure of class 1"
}
}</em>
<em> class Class2 {
def closure = {
"I'm the closure of class 2!"
}
}</em>
<em> Class1 class1 = new Class1()
Class2 class2 = new Class2()
class1.closure = class2.closure // See? I changed the behavior of class1 at runtime!</em>
<em>
Numbers on a numeric way!
When you have to deal with a BigDecimal value in Java is always a pain in the ass. Look at this example:
public BigDecimal delta(BigDecimal a, BigDecimal b, BigDecimal c) {
return b.multiply(b).subtract(new BigDecimal(4).multiply(a).multiply(c));
}
Is it easy to read? How could I do it in Groovy?
public BigDecimal delta(BigDecimal a, BigDecimal b, BigDecimal c) {
(b * b) - (4 * a * c)
}
Wow! Now someone can understand my code!
Dynamic constructors
Let’s suppose that in Java you’ll have a class like this:
class Person {
private String name;
private String address;</em></em>
<em><em> // getters and setters
}
In this class, I’ll have only one constructor, is the default one. If I want, I can add new ones as I need those, but usually when I try to populate a new instance, I’ll do something like this:
Person person = new Person();
person.setName("Kico");
person.setAddress("Somewhere in Brazil");
How can I do the same thing in Groovy?
Person person = new Person(name:"Kico", address:"Somewhere in Brazil");
<
Way simpler! Three lines of code in a single one! And the best thing here is: I can do exactly the same thing with default Java classes too in Groovy code!
Conclusions
As its shown, these are only a few spots that I really appreciate in Groovy. And what is way cooler is the fact that many of these characteristics were going to be added on Java 7. If they were, it whouldn’t be exaggerated to say that Java whould became Groovy. :)
Why Grails really matters for a Java developer (and actually rescues JEE from boredom)
Why Grails matters? That’s a fair question if we take a look at the huge amount of web frameworks an average Java developer is used to. Behind this question actually there’s another one hidden: “Does Grails really brings something new or is it just another web framework?”.
Historically speakng, we can see that the only really revolutionary web framework on the Java platform is Struts. Not because is the best, but only because it was the first (at least that I know). After Struts we can see the amazing proliferation of zillions of web frameworks, all promising the same thing: “revolutionize web development through huge gains in developer productivity”. Some really did it (but MANY more didn’t), and at the end of the day, there was this feeling that they actually didn’t bring anything new (with some exceptions, like VRaptor, Tapestry, JSF and some others).
So the question is: will Grails be only one more in the list? And my answer is: no! That’s because Grails brings some new technology, but more than that, Grails bring us a “new” work philosophy.
This “new” work philosophy is actually inspired on Ruby on Rails (RoR). Just to remember, Grails is not the original name of this framework: Groovy on Rails was. When RoR started to became popular, it was like a slap on the face of MANY Java developers. Suddenly, our methodology and tools became amazingly lame (maybe “bored” should be the word). And in that same moment, some JEE problems became crystal clear to everyone.
Hard component integration
If you’re a Java developer you know that we have at our disposal some tools like Hibernate, Spring, Log4j and many others that are simply marvelous. They really improve our productivity, but when we have to integrate them, it’s usual to see all this gain fading in front of us.
There are actually too many jar files to manage. It’s really common to face problems like incompatibilities, version problems and so on. Really a pain in the ass many times.
Configuration files
It’s amazing the amount of time spent on these beasts. We have to configure our servers, the application context, framework behavior, managed beans, tag libraries and so on. And all these things are made using XML files, is a great format, but whose syntax is basically the opposite of the one we are used too, is the Java’s syntax.
It’s true that we can avoid these files if we are using a great IDE, but this is only a silly illusion. You know that some day you’ll have to face these bastards.
Repetition, repetition, repetition and more repetition
If you’re working on a simple CRUD application, the repetitiveness becames clear. Usually you have to create basically four pages for each entity: one for editing, another one for creating, another one for listing and, finally a page will show the details of that register. So, if you have N entities in your application, you’ll have to write approximately 4*N pages.
And what is more sad: basically, these pages are all very much the same. The only change is fields are being exposed. Whould’nt it be nice if you could build these pages automatically?
Stack configuration
Here is the situation: a new programmer arives at your office and you need to setup his environment. So, there are two options: you already have an image ready to be used or you don’t. In the second case, you know how boring this is: you have to install JDK, IDE, libraries, servers and so on. Even worse: sometimes you have to configure the developers IDE to work properly with the components you’re used to.
Of course, someone could say: “but if you install an IDE like Netbeans, all this stuff are there ready to be used”. Well, this is only half true: things are not so beautiful on the real world.
Ruby on Rails (and Grails) philosophy
DRY: Don’t Repeat Yourself
The question is: if there are tasks are repetitive in the development process, why they are executed by humans and not by the framework?
After all, developers are paid to implement a business model, not to execute repetitive tasks. At leat in theory they’re paid to THINK!
At RoR we can see the return of something that we had simply ignored: scaffolding. The framework generates automatically for the developer several artifacts are usually related to repetitive tasks, like for example views and controllers. So, all the repetitive tasks are gone, and your work will be to only customize these artifacts. Neat!
(where we had seen this before? Personal databases like Access (damn!), Paradox, FileMaker and many others)
Convention over configuration (or zero configuration)
Here is where productivity soars. You don’t need configuration files if everything is in its place, do you? When working with RoR or Grails, the framework will stipulate some conventions that simply make configuration files unnecessary.
For example: in Grails every controller is stored on a specific directory. So, it’s not necessary to told the framework are the controllers. He’ll find them automatically. Actually, when working with Grails and RoR, it’s quite common that the only configuration file you’ll ever touch will be the one is responsible for defining the dabase access configuration!
The basic idea here is: configuration files are unnecessary because the application is already well organized. The configuration, in this case, is the application itself!
But, more than that, it’s important to think in conventions over configuration, and not instead of configurations. Why? Simple: because these applications usually are targeted at the enterprise environment, so you’ll have to integrate them with it. So, in this case, you’ll have to change some configuration files, but guess what: it’ll be far easier, because in these cases, you’re not working with XML.
Full stack
As RoR, Grails installation is actually an IDE with everything you need. To install it, all you need is the JDK and Grails installation (of course!). You don’t even need to concern about installing some other IDE or server. All you’ll need is a simple text editor.
And in Grails case, it is based on several components whose quality is already attested like Hibernate, Spring, SiteMesh, Log4J, Apache Commons and many others. So you don’t need to worry about how to integrate those libraries and frameworks, because they already are! Again, all you need to worry is your business logic!
So, after all this talk about RoR, and knowing that “something” called JRuby exists, the question is:
Why Grails and not Ruby on Rails?
Actually, it doesn’t matter. Your productivity boost will be basically the same. However, for the Java developer, already used to it’s syntax, Grails will be way more familiar, because it’s based on Groovy, , by the way, have basically the same Java syntax (with some syntatic sugar). Your learning curve will be reduced on this case.
Another important point is the fact that you’ll be able to reuse all your legacy code on a Grails project without changing anything on it ( is not a Grails advantage, because this same code reuse can be achieved using JRuby too).
But, at the end of the day, this can be solved with a single question: language do you prefer? Grovy (Java) or Ruby? Java? Go Grails! Ruby? Go RoR!
Finally answering the question: “why Grails matters to a Java developer?”
After the success of RoR, the problems of the JEE platform became clear to everyone. Even if Grails or RoR suddenly disappear, from now on the new frameworks that will emerge will be following this “new” philosophy. And taking into consideration that Grails was developed since it’s begining focusing on the Java developer, it’s an undeniable fact that it will have a huge influence over all the new developments on this area from now on.
Or, being more direct: because RoR and Grails suddenly showed us that working with the JEE is amazingly boring.
Por que Grails é importante para os desenvolvedores Java?
Por que se importar com Grails? Esta é uma pergunta justa se formos levar em consideração a quantidade de frameworks com os quais desenvolvedores Java estão acostumados a trabalhar. Por trás desta pergunta na realidade há outra disfarçada: “Grails realmente trás algo de novo ou é só mais um framework?”.
Sou completamente a favor da diversidade, no entanto, se formos observar o histórico das ferramentas com as quais o desenvolvedor Java está acostumado, vemos que o único framework que realmente revolucionou as coisas foi o Struts. Não por ser a melhor coisa do mundo (nunca foi), mas pelo puro fato de ter sido o primeiro. Nese sentido, pode-se dizer que o desenvolvimento web na plataforma Java é antes e depois do Struts.
Após o Struts, o que se viu foi uma proliferação incrível (e saudável) de frameworks, todos prometendo “revolucionar o desenvolvimento de aplicações web aumentando a produtividade dos desenvolvedores“. De certo modo, muitos conseguiram (e MUITOS outros não), mas no final das contas, sempre ficava a impressão de que não traziam nada de realmente novo (com raras excessões, como o VRaptor, Tapestry, JSF e outros).
Sendo assim, a pergunta que fica é: seria Grails apenas mais um para a lista? E a resposta é: não. Isto porque Grails não trás consigo novas tecnologias (na realidade, é tudo baseado em tecnologias que já existiam), mas sim um novo modo de se trabalhar.
O modo de trabalhar no qual Ruby on Rails (RoR) é um dos pioneiros. Só para lembrar, o nome original do Grails era Groovy on Rails. Quando RoR apareceu, foi como um tapa na cara do desenvolvedor Java, pois do dia para a noite, aquele modo de trabalho com o qual estávamos acostumados a trabalhar de repente se mostrou incrívelmente improdutivo.
Do dia para a noite, ficaram nítidos alguns problemas que enfrentávamos diariamente e para os quais simplesmente torciamos o nariz:
Dificuldade em integrar componentes
Quem trabalha com Java sabe: temos ferramentas maravilhosas, como por exemplo Spring, Hibernate, Log4J, JUnit e muitas outras que realmente ampliam muito a nossa produtividade. Fazem maravilhas por nós, mas quando precisamos integrá-los, boa parte desta produtividade é simplesmente perdida.
O Spring nos ajudou a resolver estes problemas, mas no entanto ainda não era suficiente. A quantidade de arquivos jar com os quais precisávamos lidar é um problema. Quem nunca passou por problemas deste tipo que atire a primeira pedra.
Arquivos de configuração
Ao criarmos nossas aplicações, ficava nítido que boa parte do tempo era gasta trabalhando com arquivos de configuração. Configuração do servidor, das ações, dos managed beans, das tag libraries, dos componentes JSF, etc.
E todos escritos em XML, cuja sintaxe, apesar de bacana, é bem distante da qual os programadores estão acostumados. Tudo bem: há assistentes para estas tarefas, porém o confronto com os malditos é inevitável.
Repetição, repetição, repetição, repetição
Quando se está trabalhando com uma aplicação simples, que seja basicamente apenas CRUD, pode-se ver nítidamente o quão repetitivo o trabalho se torna. Você precisa de uma página para consultar registros no banco de dados, outra para criar novos registros, outra para editar estes registros e mais uma para visualizar os detalhes do mesmo. Resumindo: são basicamente 4 páginas por entidade. Logo, se sua aplicação possui N entidades, o número de páginas a serem geradas é no mínimo 4*N.
E sabe o que é mais engraçado? Em sua maior parte, as páginas são basicamente as mesmas. Só variam os campos. Não seria ótimo se estas já fossem geradas para você?
Ambiente de desenvolvimento complicado de ser configurado
Este é um problema comum: chega um novo desenvolvedor na sua equipe e é necessário que você crie ou configure seu ambiente de desenvolvimento. Há duas alternativas aqui: você já tem algo pré-configurado (só copia para a máquina cliente e pronto) ou tem de trabalhar do zero. No segundo caso, será preciso instalar IDE, bibliotecas, JDK, etc. E pior ainda: ainda precisa preparar o ambiente de desenvolvimento para que trabalhe direito com o seu framework (o que nos leva a primeira dificuldade). Tudo bem que você pode simplesmente instalar uma IDE como Netbeans ou Eclipse e teóricamente tudo já viria pré configurado. No entanto, as coisas não são tão lindas assim.
Ao se iniciar um novo projeto, é incrível quanto tempo se perde só para montar o ambiente…
O modo Ruby on Rails (e Grails) de se trabalhar
É importante mencionar que Ruby on Rails não é a solução para todos os seus problemas (assim como Grails), porém os princípios básicos por trás do seu funcionamento apontam diretamente para os problemas que mencionei acima:
DRY: Don’t Repeat Yourself
A pergunta que se coloca aqui é: se há tarefas repetitivas no processo de desenvolvimento, por que não deixar que o framework tome conta destas tarefas para você? Assim você se preocupa apenas com o que importa: o negócio a ser modelado.
No Ruby on Rails vimos ressurgir algo que até então haviamos simplesmente ignorado: o scaffolding. O framework gera automáticamente para o desenvolvedor arquivos pré prontos para as principais tarefas repetitivas, como por exemplo páginas de CRUD (inclusão, edição, listagem e visualização de detalhes) e controladores. O programador só precisa customizar estas páginas e pronto. E se quiser algo a mais, basta escrevê-las por si próprios!
(aonde você viu anteriormente o scaffolding? Nos bancos de dados pessoais como Access (maldito!), Paradox, FIleMaker e outros!)
Convenções sobre configurações (zero configuration)
E aqui é que a produtividade REALMENTE se faz nítida. Você não precisa de arquivos de configuração se tudo encontra-se em seu devido lugar. No caso do Grails e RoR, a partir de algumas convenções estipuladas pelo framework, o programador não precisa se preocupar com arquivos de configuração.
Por exemplo: em Grails, todos os controladores se encontram dentro de um diretório específico. Sendo assim, não é necessário criar um arquivo de configuração que os identifique. Ao ser iniciada, a própria aplicação já irá descobrir quais são os seus controladores.
O grande lance é: os arquivos de configuração são desnecessários porque a própria aplicação já é a sua configuração.
Porém, mais do que isto, deve-se pensar em convenções sobre configurações, e não ao invés de. Por que? Simples: porque aplicações feitas em sua maior parte para serem usadas no ambiente corporativo, sendo assim, precisam ser fácilmente integradas aos componentes pré-existentes. Nestes casos, o programador voltará a alterar arquivos de configuração, porém com uma intensidade bem menor do que a qual já se encontra acostumado.
(porém, na esmagadora maioria das vezes, o único arquivo de configuração com o qual você terá de enfrentar consiste no que configura o acesso a suas bases de dados (e não é um arquivo XML))
Stack completo
Assim como RoR, Grails já vem com o seu ambiente de desenvolvimento completo e padronizado. Você não precisa de uma IDE para começar a trabalhar com Grails. Basta o JDK e a instalação do Grails e pronto. Tudo já está disponível para você. Não é necessário se preocupar com a instalação do Spring, Hibernate, JUnit, Log4J, Commons, etc. A instalação do framework já vem com todos os componentes pré-configurados e prontos para uso.
Isto porque Grails é baseado em componentes com os quais já estamos acostumados e cuja eficácia é comprovada. No final das contas, Grails acaba sendo simplesmente uma fina camada que integra todos estes componentes para o desenvolvedor usando Groovy. É realmente fantástico.
Como resultado, você não precisa se preocupar com arquivos jar, configurações, etc. Já inicia o seu desenvolvimento pensando direto no que realmente interessa: o negócio a ser modelado. Resultado: produtividade instantânea.
E após esta explicação, e sabendo-se que existe o JRuby, a pergunta que fica é:
Por que Grails e não Ruby on Rails?
Na realidade, em ambos os casos o ganho do desenvolvedor será exatamente o mesmo. No entanto, para o programador Java, que já está acostumado com a sua sintaxe, Grails se mostra mais familiar, pois é baseado em Groovy, que no final das contas, possui quase a mesma sintaxe, diminuindo significativamente a curva de aprendizado.
Até o surgimento do JRuby, outro ponto importante em favor ao Grails consistia no fato de ser possível reaproveitar todo o seu código legado em uma aplicação Grails, porém este ponto ainda se mantém para ambos os casos.
Mas no final das contas, a escolha entre Grails ou Ruby on Rails pode ser resolvida com a seguinte pergunta: com qual linguagem você se sente mais à vontade? Groovy (Java) ou Ruby? Mais Java e Groovy? Grails é para você. Curte Ruby? Vá para o RoR!
Finalmente, respondendo à pergunta: por que se importar com Grails?
Após o lançamento do RoR, os problemas da plataforma JEE se tornaram nítidos. Mesmo que Grails não venha a ter futuro (pouquíssimo provável) e que RoR desapareça (mais improvável ainda), os frameworks que surgirão daqui para frente com certeza serão baseados neste “novo” modo de se trabalhar. E levando-se em consideração que Grails desde o início é feito pensando no desenvolvedor Java, é inegável que exercerá (e já exerce) uma influência significativa em tudo o que virmos surgir daqui pra frente.
Ou, resumindo: porque RoR e Grails de repente nos mostraram que nosso trabalho na plataforma JEE era incrívelmente chato.
Grails and legacy code: making old code groovy again!
Code reuse with Grails is amazingly easy. When working with this framework, it’s really cool to see the huge improvement in productivity that we can achieve. But if you have a large legacy code behind you, this productivity will simply disappear. And this is where Grails really shines and become a real choice for a Java developer.
This week I needed to start a new project in reality was just a web interface for one of our legacy projects. So, I had some options in front of me: I could start with Struts, JSF or even plain servlets (I was out of my mind to just cogitate this third option!). At first, I choosed JSF to interact with our legacy code. After all, it was plain Java to deal with Java code, right?
Then I started a new JSF project using Netbeans, added the jars contained my legacy code + all the other jars it depends on (basically all the Spring + Hibernate dependencies). Some time after that, I started to face some problems with Tomcat, was having problems reading my faces configuration file (again). At this moment something hit me: a Grails application doesn’t need domain classes!
In this moment I started my experiment: what if this web interface I needed was entirely wrote in Grails interacting with my legacy code? So I started a new Grails project and used only controllers (just ignored GORM entirely) and my legacy code. And it worked pretty well!
Here is the procedure I took:
1. Start a new Grails project that only uses controller classes
In this state, the only thing I needed to do was to change my DataSource.groovy file to look like the one below:
dataSource {
}
hibernate {
}
// environment specific settings
environments {
development {
dataSource {
}
}
test {
dataSource {
}
}
production {
dataSource {
}
}
}
This step is optional, but is a good move to do so. After all, it’s not a good idea to have a instance of HSQLDB floating around without any use, right?
2. Copy all your jar files to the lib directory of your Grails application
In this case, you only need to copy those jar files contain your legacy code. And here things get really exciting: as Grails already comes with a full stack, basically you’ll only need to copy your legacy code and few libraries your application relies on.
If your code already uses some of the libraries above, you don’t need to copy their jars to your application. Grails will add them for you: after all, they are the basic components of Grails!. Well, here is the list: Sitemesh, Hibernate, Sprng, Log4J, JUnit, Ant, Commons (several Apache Commons are used by Grails), Xalan, Xerces, Hsqldb.
As you can see, in many cases the only library you’ll need is your JDBC driver. In my case, I only needed to copy the MySQL Connector and JExcel! Neat!
Tip: in your Grails installation directory, browse the contents of the lib folder. Maybe you’ll find some library I just forget to mention.
3. There’s no step 3!!!
At the end of this process, all you have to do consist in work only with controllers classes and it’s respective views. And believe-me: it’s far more productive than using JSF managed beans or actions of Struts!
Notice: in this case, the best thing to do is: forget about GORM!
Main advantages of this approach compared to the use of “traditional” frameworks
- 100% code reuse: did you noticed that in any moment I had to recompile any piece of code? All I needed was my jars! That’s because Grails is based on Groovy , at the end, generates bytecode. The same bytecode we are used to work with Java!
- Almost zero configuration: did you ever struggled with JSF or Stuts configuration? What about web.xml? Aren’t those files a pain in the ass? In Grails, the only configuration file we had to change was DataSource.groovy!
- It’s Groovy Code: I must admit that I’m tired of working only with Java code. Sometimes is really nice to write in another language. In my case, Groovy is one of the nicests languages I know.
- Easy to deploy: I don’t have to fight agains a huge amount of jar files. I just need to execute grails war and it’s done. All I have to do is send the war file to my server.
- Easy to write (and understand) controllers: just compare a Grails controller to a JSF managed bean or a Struts Action and you’ll know what I mean. It’s not necessary to configure anything. All I need to do is write some closures. That’s nice.
- Filters in a easy way: I’ll not need to implement interface, extend classes or write configuration files. I just need to implement filters the way Grails does. And it works!
- It’s Grails: this is the most important point for me. I’ll have all the productivity gains I expect from Groovy and Grails using my legace code. Your legacy code will feel refreshed!
In the end, I achieved a paradoxal conclusion: if you are just like me, and have tons of legacy code on your back, Grails without GORM is even more powerfull than Grails with GORM. That’s because unfortunately Grails code isn’t easy to reuse. But your legacy code, when wrapped on jar files is!
Another possibility
After finishing this project another possibility of code reuse with Grails showed up: if you have your source code, you don’t even need your jar files. All you have to is to copy your source code to the src folder inside your grails application. It’ll be compiled when you start or deploy your application
(but I still prefer jar files :) )
Grails e código legado – rejuvenesça seu código legado!!!
Um dos aspectos mais fenomenais do Grails consiste no reaproveitamento de código legado. É muito bacana ter todo o ganho de produtividade que o framework nos oferece, no entanto, este ganho só se torna REAL com reaproveitamento de código. E é neste ponto que Grails se torna REALMENTE interessante para o desenvolvedor que trabalha com Java.
Nesta semana precisei criar uma nova aplicação web que, na realidade, não passava de uma interface para um sistema legado. O que eu tinha então: todos os jars que compunham a aplicação e uma escolha a fazer: qual framework utilizar: JSF, Struts, apenas servlets (um momento de insanidade, concordo)?
Iniciei com JSF. Criei a aplicação no Netbeans, inclui no projeto todos os arquivos jar que precisava (inúmeros: inclua ai todos os arquivos de dependência do Spring + Hibernate e saberá do que estou falando) e comecei o trabalho. Momentos depois, a aplicação começou a dar problemas: o Tomcat havia começado a “implicar” com meu arquivo de configuração do faces, o que me deu MUITA preguiça. Foi quando algo me veio à cabeça: uma aplicação feita em Grails não precisa ter classes de domínio!
Sendo assim, criei uma nova aplicação feita em Grails e, ao invés de utilizá-lo como um stack completo, o que costuma ser feito na maior parte das vezes, optei por trabalhar apenas com os controladores. E não é que deu certo?
O procedimento que segui foi basicamente o seguinte:
1. Criar um novo projeto Grails e, em seguida, anular as configurações de acesso a base de dados.
Neste ponto: a única ação necessária a fazer consiste em editar o seu arquivo DataSource.groovy para que fique exatamente como o descrito abaixo:
dataSource {
}
hibernate {
}
// environment specific settings
environments {
development {
dataSource {
}
}
test {
dataSource {
}
}
production {
dataSource {
}
}
}
Importante: a alteração deste arquivo de configuração é opcional. No entanto, é uma boa idéia alterá-lo, pois você não irá precisar do HSQLDB rodando a toa por trás dos panos, não é mesmo?
2. Copie todos os seus arquivos .jar que você necessite para dentro do diretório lib de sua aplicação
Neste caso, por arquivos .jar, deve ser entendido o seu código legado e suas dependências. E ai é que a coisa fica interessante: como Grails já vêm com o stack completo, você basicamente só precisará incluir neste diretório, além do seu código legado, uma ou outra biblioteca que sua aplicação venha a utilizar.
Caso sua aplicação utilize algum dos frameworks abaixo, você nem sequer precisará copiar os arquivos jar necessários para dentro do diretório lib. Na realidade, para evitar conflitos, é ideal que você não os copie. Muito bem: vamos a lista dos frameworks:
Sitemesh, Hibernate, Sprng, Log4J, JUnit, Ant, Commons (boa parte do Apache Commons já vem com o Grails), Xalan, Xerces, Hsqldb.
Como pode ser visto, a quantidade de arquivos de dependência com os quais você venha a se preocupar diminui bastante neste momento. No meu caso, só precisei copiar o driver JDBC para o MySQL e o jar do JExcel (além, é claro, do meu código legado).
Dica: navegue pelo diretório lib da sua instalação do Grails. Você perceberá que talvez eu não tenha mencionado todas as bibliotecas que o Grails utiliza!
3. Não tem passo 3!!!
Finalizado este processo, tudo o que você precisa fazer daqui pra frente irá consistir em trabalhar apenas com os controladores de sua aplicação, que deverão, por sua vez, acessar diretamente seu código legado, e pronto: você terá reaproveitado 100% do seu código e ainda terá tido no final das contas um ganho de produtividade gigantesco usando apenas a parte dos controladores do Grails!
A grande dica para a finalização de sua aplicação é a seguinte: esqueça o GORM!
Vantagens com relação aos demais frameworks
Nesta experiência, ficaram nítidas para mim algumas vantagens desta abordagem com relação ao procedimento tomado até então, que consistia em utilizar um framework mais tradicional como JSF ou Struts. Seguem as vantagens que observei:
- Reaproveitamento total de código legado: reparem que em momento algum precisei recompilar coisa alguma. Lidei aqui apenas com as camadas de visualização e controle.
- Sem arquivos de configuração. Já sofreu com o maldito arquivo de configuração do JSF ou Struts? Já penou com o web.xml? No caso do Grails, eu nem sequer me lembro de configurar qualquer coisa que não seja o acesso a dados!
- Rejuvenescimento do código legado: há momentos nos quais olho para o meu código Java e, em seguida, ao olhar para o meu código Groovy, tenho a impressão de que o mesmo encontra-se velho.
Ao trabalhar com Grails, estou utilizando código Groovy para acessar meu código Java.
Se assim como eu você também já está um pouco entediado em codificar na lingua mãe, Grails cai como uma luva. - Facilidade de deploy: como não preciso me preocupar com tantos arquivos .jar, os meus problemas de deploy práticamente acabaram. Basta executar grails war e pronto. Lá está o war que precisava!
- Controladores realmente simples. Basta se lembrar do código que você escreve usando JSF ou Struts pra ver a diferença. No caso do Grails, é realmente simples: sem mapeamentos, sem regras: apenas closures simples relacionadas a arquivos de visualização igualmente simples.
- Filtros simples! Nada de implementar ou extender classes ou alterar arquivos de configuração!
- É Grails! Este para mim é o ponto mais importante: eu tenho todo o ganho de produtividade do Grails com meu código legado!
E aqui entra uma conclusão paradoxal: Grails sem o GORM acessando seu código fonte legado é ainda mais poderoso do que com o GORM. Por que isto? Simples: porque o reaproveitamento de código Grails não é a coisa mais simples do mundo. Se você cria por exemplo uma aplicação A em Grails, e em seguida quer reaproveitar parte do seu código em um projeto B, as coisas já se complicam. No entanto, se você tem sua camada de negócio bem organizada, reaproveitá-la no Grails é simples!
Developer traps: how not to become “just another dumb programmer”
As time goes by, I can see some situations in wich developers get into are actually traps. That’s why I call those “developer traps”. The word “trap” was selected because those who are caught on one of these rarely scapes intact (usually the result is “just another programmer”).
Trap #1: Linguistic determinism
That’s my worst nightmare. For those who don’t know what it is, linguistic determinism is the idea that language shapes thought. Here is an example: we from Brazil know many types of bananas (nanica, serra dagua, caturra), but an english person usually can distinguish only one kind of banana: banana. Our vocabulary have many words to distinguish the kinds of bananas wich we have to deal. That’s the most basic example of all, but is enough to get us started on this issue.
How can we apply this to a developer? Simple: those wich only work on a single environment/programming language usually show huge difficulty in learning any other thing. Here is a good example: those who are used to work on a RAD environment like Delphi or VB (more specifically those wich only drag and drop some components on forms (nothing against Delphi or VB!)). When trying to learn some other language like Java or C++, their first reaction consist on the repetition of the same procedure that they are used to on their familiar environments. Obviously, with failure. It’s when we hear some of the most common complaints:
- “Language/Programming Environment X sucks!”
Here we can see the guy trying to apply the same procedures of his original programming language on the new one. Of course it will fail! It’s not the same thing “genius”! - “I’m more productive on language/environment X.”
Here the problem is externalized. The subject is almost saying: “I can’t learn this new environment/language. It’s different from what I’m used to!” - “Programming languages are all the same. Syntax is the only difference”
Well, if that’s true, why so many languages??? Actually, in this case, there whould be only ONE programming language: the one the subject is used to work.
We can see an interesting aspect of who is caught on this trap: the arrogance. They use to blame the language/environment for all their problems, just forgetting one single fact: that language/environment had been used several times successfully on many projects around the world.
Trap #2: software = relational database management system
The subject don’t believe in development beyond CRUD. How to detect someone caught on this trap? Simple: just say anything about any data structure that is not a table or an index. You may go beyond on this experiment: ask the subject to describe how any other data structure actually works (warning: you’ll create a new enemy). Even worse: ask this person if he can code anything without a database behind it.
Here is what happens: the subject works on an environment wich most of his demands consist on applications that are basically only CRUD. In this scenario, the most complex task consist on the creation of some kind of report. Actually, here we can see trap #1: linguistic determinism. But these two traps are slightly different: this trap is way more common (it’s a specialization of the above) and may create bigger losses than that.
The illusion is created because the feedback of a SQL query is instantaneous, the subject starts to believe that his job is finished on the creation of the forms wich displays the data. Things will only get strange for this guy when someone needs something more complex than that. What is really amazes me is that these people are able to do incredible things using only SQL, but usually fails miserably when trying to do anything else.
Actually what we’ll see here is someone forgetting a very simple rule: data is the result of processing, not otherwise.
Trap #3: RAD evironments
The subject learn to code on a RAD environment and stick with it. It’s actually the result of traps #1 and #2 with one little addendum: the illusion that software development is easy.
I really hate how wrongly these tools are used. They are supposed to be used only for the execution of the boring and repetitive tasks, like GUI creation and basic CRUD, wich are only a small part of the process of software development, and not the bigger one. In this case, we can see the opposite: the subject can spend hours (sometimes DAYS) searching for new components to be added to his forms just to execute tasks that are beyond the simple CRUD, in this case ignoring completely other aspects of the process, like scalability, security, quality, etc.
How to detect someone with this problem? Just remove it’s IDE.
Trap #4: “donti speak english”
Sounds improbable, but the amount of developers wich just ignore the english idiom is huge! As a consequence, this crowd will never know what is being published at current time, just what will be translated (IF it will).
Trap #5: lazy readers
How can someone be good in something if it’s not reading about it? Simple as that.
Trap #6: fear of change
If anything changes around the subject, it just get crazy! Any change on a specification? Boom! A new crisis emerge! It’s what I use to call the autistic developer. This kind of developer can’t see the fact that change is what keeps his job! It completely ignore a basic fact about the world: everything changes. On V b.C Heraclitus was almost shouting: “panta rei (everything changes)”!!!
If things change in nature, why whould’nt they change on your work? Is it possible that after 2500 years people still can’t accept this fact?
In my opinion, this problem emerges from the false belief that software development is a kind of math when, in fact, it just uses some math to do the job. The other half of it is composed of human beings wich, as we all know, change all the time (sorry about that).
How to know if someone have this problem? Simple: change the color of his mouse or keyboard. He’ll go nuts!
Conclusions
These are the main traps I know. After discussing them, someone could ask me the following questions:
Why you didn’t mentioned any management traps?
Simple: how can you manage something you don’t know? These are the basic traps to be avoided to anyone wich have the slightly desire to manage anything related to software development.
How to avoid those traps?
Basically avoiding trap #1, accepting diversity as a fact and, even more important: recognizing the fact that software development is a complex task.
Another trap for developers: the Bill Gates Syndrome
Every month I got a phone call like this:
<John Doe> Hello Kico!
<John Doe> Its me, John Doe, how are you?
<Kico> Wow! It’s been a long time! How are you?
<John Doe> Man, I’m great, and now I have a great idea for a new business, and you are the one I need to implement it!
<Kico> Sure… again???
<John Doe> Yep! But this time things will be rather different!
<Kico> Well, let’s see it…
And believe me: John Doe is not a single guy… and talk after talk, just by “accident” I’ll all his dreams with simple questions like: “what about your business plan? Did you wrote one?” or “and how will you finance this thing?” or the worst question of all: “who will want it?”. Of course, at this moment, he will forget about that marvelous idea, but after some time he will call me again.
It’s one of the worsts developer illusions: there’s no easy way to get rich.
It’s usual to see a lot of people starting to get interest on software development based on this illusion. And what is more interesting: money on these cases lost it’s real meaning: as Aristotle used to say between 384bC and 322 bC: “money is a meaning, not and ending”. But even more than two thousand years after, people still don’t get it! Money still is seen as the main goal of everything. And here comes what I call one of the worsts developer traps of all the time: the Bill Gates syndrome:
Just because the wealthiest man on the world get rich with software, it doesn’t mean you are going to be rich too! Based on what the media says, maybe you think you will. But believe me, based on the four main arguments shown by them, you wont. The main arguments are:
- Software development is easy! (“look at Bill Gates! A wacky guy wich got billionary just doing that!”)
- If your idea is great, people will buy it (“you won’t need a business plan! People will be running after you!”). You just need to be inspired.
- Build your software, throw it on the Internet and it’s done. It will be a hit!
- A true genius never is understood at the beginning. Just after!
I’m sorry to tell you, but these four arguments are pure bullshit! So, let’s take a deeper look at them.
“Software development is easy”
Well, if t’s so easy, why most software development projects fail? If it’s so easy, why isn’t everybody coding and designing new software? Why just very few are doing this at this present moment? If it’s really so easy, why botther creating graduation courses like Computer Sciences?
Believe me: software development is hard. It’s not something that everyone can do. It’s easier than it was at the 80s? Yes, we have better tools, but the world is way more complex than it used to be back then. Please, don’t fool yourself with this bullshit.
“If your idea is really great, people will buy it!”
Sure! And you don’t even need a business plan right? How can people know what they really need if they don’t know what they need?
(here we can see the level of arrogance of these people. Just because you solved YOUR problem, it doesn’t mean it will solve everyone else problem!)
If something is going to be successfull, it have to be really well designed. It’s necessary to have a business plan, knowing every single risk. Who are your suppliers and competitors? Who will want your product? Usually, by making these questions, the “future billionaire” starts to feel a little sadness while we talk. And here comes the worst part: usually this “future billionaire” doesn’t even know how do describe his new amazing product!
Here comes my “kiconian” theorem: if you can’t describe something in words, you just don’t know it at all. The prove is simple: if you know something, you also know the vocabulary wich surrounds it and the relationship between the terms involved. If you don’t, there are just two options:
a) Your idea sucks
b) Your idea is still on development (so it still sucks)
“Build your software, throw it on the Internet and it will be a hit”
People really think that just because something is on the Internet, everyone will see it. By doing that they just forget that you have to know at least two things: how to divulge it and, even more important: how to deal with the feedback it may have! I’m the living proof that this argument is false. Here is my story:
In 1999 I wrote my first piece of software, wich was called MatMaker. It was a tool for primary and middle school students wich may have problems solving math exercises. For my surprise, it was a hit! Suddenly I was cited on several academic papers. By throwing it on the Intenet, of course I wanted to make a buck. The strategy was: public schools whould never need to pay a dime for the software, but private ones should. Well, what I got from it? Monetarily speaking: nothing. Just some experience (some (some (some))). For years this software was widely used and I never got a single penny for it. But at least it helped a lot of people, wich already pays for itself.
In 2001 I needed to send lot’s of e-mails to the users of MatMaker, so I wrote another piece of software called KMala. Since it was built just to solve my problem, I thought that maybe it could be usefull for someone else, so, again, I just made it available to everyone, for free on my website at the time. Well, for my surprise, it just got popular. Lot’s of people wrote back to me asking how much does it cost and my answer was always the same: “nothing. It’s free. If it solve your problem to, it’s fine for me”.
Well: another surprise: someone started selling the software (and this someone was not me). How it was 2001, several ISPs started to change how their SMTPs and POP3s servers worked. As a consequence, KMala just stoped working. How I didn’t know that at the time (it was working just fine for me), it was just ok. But suddenly my inbox was full with complaints of people wich actually bought the software threatening to sue me if I don’t fix it. It tooked YEARS for me to clean my name and show those persons that I actually NEVER sold this software to ANYONE.
(important detail: for my horror, a good fraction of Brazil’s spam at the time was sent using this software)
As you can see, I’m a good example that this argument doesn’t work at all. In both cases, it was a hit. The problem was: I didn’t knew how to deal with the feedback.
“A true genius is never understood at the beginning. Just after!“
This is a cruel argument. So, to kill it, just take a look at the pictures of these guys:
 Steve Jobs and Steve Wozniack |
 Kevin Rose, founder of the Digg |
 Mark Zuckerberg, co-founder of FaceBook |
|
Looking at those pictures, we can find a pattern: the illusion that the guys wich are getting billionaires are just developers like you and me. You got the illusion that at the first moment they were completely ignored, but later, given their geniality, they just triumphed over those who ignored them right? Wrong!
They’re actually just the public face of their companies! Who at the beginning do you really think managed the business? Do you really think that Steve Jobs was the only responsible for every single aspect of Apple administration at that time? Of course not! Let’s face it: it’s too naive to think that way. Behind those people there’s actually lot’s of highly skilled executives and venture capitalists wich REALLY manage their companies. Without them, believe-me: there whould be no Microsoft, Apple, Facebook or any other.
Ask yourself: if you are starting a new company, why make it’s public face someone wich doesn’t appear to have any business experience at all? The answer is: because it’s all about marketing. The target audience is you, the developer. They want you to think: “Hey! if they did it! I can do it by myself too!”.
Notice that behind every one of these “leaders”, the product its actually a platform. A platform wich you may enrich by adding new functionality with your software. You may of course make some money with it. But believe me: who really makes the big buck is not you.
So, I’m sorry if I just destroyed one more of your illusions.
Conclusion
Getting rich is not easy. And if you really see money as your goal, well… sorry to tell you. But you are an idiot. Money is only the medium, not the goal. And, after all, when you die, what really matters it’s not the money you made. It’s what YOU made with it stupid!
Software development is extremely difficult. If you just get into how these people really got all their money, you’ll find a lot of work, uncountable frustrations and a huge amount of stress. Nothing is easy. The only thing they all share in common consist in their perserverance.
And where does this perserverance comes from? From their real love to their jobs! You got to be deeply in love with what you do if you REALLY want to make something that matters. You have to wake up, brush your teeths, eat, walk, sleep thinking about what you’re doing. Not as a punishment, but as the main goal of your life, at least at that moment. It must be almost like a sexual experience when you are working. If not, believe me, you’re screwed.
Only if your fathers are extremely rich you’ll get rich in an easy way. If not, sorry to tell you again: it’s going to be a rocky road!
Armadilhas para desenvolvedores: síndrome de Bill Gates
Religiosamente, todo mês recebo um telefonema como o abaixo:
<Fulano> Alô, Kico?
<Fulano> Sou eu, fulano, tudo bem?
<Kico> Opa! Quanto tempo? Como andam as coisas?
<Fulano> Cara, ótimas! Estive pesquisando, e tive uma idéia genial que nos deixará ricos, e você é o CARA para implementá-la. Podemos nos encontrar?
<Kico> Claro… de novo?
<Fulano> É! Mas desta vez é diferente!
<Kico> Sei, uai, bora lá!
E acreditem, Fulano não é um único sujeito! E após nossa conversa, sem querer acabo destruindo os sonhos do sujeito com perguntas como: “cara, que bacana. Mas e o plano de negócios? Você já fez?” ou “hmm… e de onde virá o dinheiro para financiar isto?” ou, a mais cruel: “e quem vai querer isto?”. Claro, como todo bom brasileiro, o sujeito não desistirá nunca, e apenas algumas semanas depois me procurará de novo com outra idéia, e assim iremos progredir até que algo de fato viável surja.
E aqui entra uma das maiores armadlhas para desenvolvedores: não há como ficar rico do dia pra noite.
Percebo que uma multidão começa a se interessar por desenvolvimento com a esperança de ficar rico. E o mais interessante, é que o dinheiro nestes casos perde completamente o seu significado: Aristóteles já dizia entre 384a.C e 322a.C: “o dinheiro não é um fim, mas sim um meio” (Ética a Nicomaco) . Mas mesmo assim, mais de dois milênios após, as pessoas ainda não acreditam nisto. Dinheiro ainda é visto com o O objetivo por tras de todo trabalho. E muitos destes desenvolvedores caem no que chamo de sindrome de Bill Gates:
|
Bill Gates |
Só porque o homem mais rico do mundo ficou rico com software, isto não quer dizer que você também vai. Percebo que a mídia cria uma ilusão na cabeça das pessoas de que os seguintes fatores são reais:
- Programar não é difícil (“vejam o Bill Gates: um carinha todo atrapalhado ficou milionário programando!”)
- Se a sua idéia for realmente boa, as pessoas vão comprar (“e nem precisa de plano de negócios! As pessoas vêm voando em cima de você!”), ou seja, basta estar “inspirado”.
- Após ter implementado seu “programa”, é só colocá-lo na Internet e pronto!
- Os gênios nunca são compreendidos em um primeiro momento.
Na realidade, os quatro argumentos são os mais furados da história: sendo assim, vamos começar a analisá-los um a um:
“Programar não é difícil”
Aham… Na realidade, se programar fosse tão fácil como dizem, então a maior parte dos projetos de software dariam certo, correto? Errado! (e aqui estão algumas estatísticas (embora antigas, porém ainda reais) que mostram isto). Desenvolver hoje em dia pode ser mais fácil que nos anos 80, porém continua sendo uma tarefa árdua. Aliás, se fosse tão simples assim, qual a razão de existirem cursos universitários como ciência da computação? Por que no meu prédio sou a única pessoa capaz de desenvolver sistemas? Não deveriam ser todos capazes?
“Se a sua idéia for realmente boa, as pessoas vão comprar”
Sim sim, claro! E nem precisa de plano de negócios, certo? Nem precisa pensar no que as pessoas realmente precisam, correto? Afinal de contas, elas ainda não sabem que precisam, não é mesmo?
(ocorre aqui uma certa arrogância por parte do “candidato a bilionário”: só porque ele tem uma necessidade específica, isto não implica que todos também as tenham)
Esta idéia é a maior tolice de todas. Para que algo dê certo, é preciso muito estudo por trás. É preciso fazer um plano de negócios completo, observando todos os riscos envolvidos. Quem são seus concorrentes? Quem vai querer usar isto? Qual a sazonalidade? Normalmente, quando o sujeito começa a fazer o plano de negócios já sai completamente deprimido. Antes de completar a primeira página o negócio já se mostra inviável, porque não consegue responder as perguntas simples que citei acima. E, pior: normalmente o sujeito nem sequer consegue descrever o que quer criar.
E aqui entra um famoso teorema Kiconiano: “você só conhece aquilo que consegue descrever”. Explicando: se você conhece alguma coisa, absorve o vocabulário que a envolve. E se conhece este vocabulário, e o relacionamento entre os termos presentes no mesmo, consegue descrever aquilo que está tentando vender. Simples assim. Caso não consiga, é sinal de duas possibilidades:
1) Sua idéia não presta
2) Sua idéia ainda não está formada (resumindo: ainda não presta)
“Após ter implementado seu programa, é só colocá-lo na Internet e pronto!”
As pessoas realmente acreditam que o simples fato de algo estar na Internet a tornará popular. Aham. E ai se esquecem completamente que é preciso divulgar a idéia e, mais importante, após divulgá-la, saber gerenciar a resposta do ambiente a ela. Sou a prova viva de que isto não funciona. Querem ver?
Em 1999 coloquei na Internet um software chamado MatMaker. MatMaker era um soluconador de problemas matemáticos para estudantes de primeiro e segundo grau. Como naquela época eu também era um estudante de segundo grau, resolvi resolver boa parte dos meus problemas criando um programinha para este fim (a palavra programinha é muito bem colocada, uma vez que, na realidade, o software era a coisa mais amadora do mundo). Para minha surpresa, o software foi sucesso imediato. Da noite para o dia, comecei a ser citado em diversas teses de mestrado, doutorado e trabalhos acadêmicos. Já naquela época, eu realmente acreditava que não era necessário cobrar pelo sistema, e ele seria gratuito para todas as escolas públicas do Brasil. Escolas particulares no entanto precisariam pagar pelo bicho. Quanto ganhei com isto? Financeiramente, nada, profissionalmente, alguma (alguma (alguma (alguma))) experiência.
Em 2001, eu precisava enviar e-mails para uma série de pessoas, e achava o Outlook muito complicado. Sendo assim, criei um software chamado KMala e o coloquei disponível no meu site. Nunca cobrei pelo mesmo, porém, para minha surpresa, um belo dia o software foi parar em uma destas finadas revistas de CD-ROM. Resultado: da noite para o dia chovia e-mail em cima de mim perguntando o preço do software. Para todos eu respondia: “nada”. Para meu choque, o software passou a ser comercializado por terceiros (sem que eu sequer sonhasse com isto). E o que aconteceu? Os provedores de Internet começaram a mudar suas regras de configuração dos servidores SMTP. O software parou de funcionar e minha caixa de correio ficou lotada com pessoas reclamando comigo que haviam comprado uma merda de programa que não funcionava. Resultado: gastei ANOS tentando limpar meu nome por algo que não fiz (link aqui).
(detalhe: BOA parte do spam nacional era enviado por este software, que acompanhava aquelas malditas compilações de endereços de e-mail vendidas em CD-ROM)
Sendo assim, sou um bom exemplo de que esta afirmativa é falsa. Principalmente porque em ambas as experiências tive meus softwares extremamente bem divulgados (mesmo sem o meu conhecimento). Como podem perceber, eu poderia ter feito algum dinheiro com isto, no entanto fui completamente incapaz de gerenciar o feedback que obtive.
Levou anos para aprender a fazer isto. ANOS.
“Os gênios nunca são compreendidos em um primeiro momento.”
Esta é a mais cruel das falácias, e como podemos perceber, é muito utilizada. Basta observar algumas fotografias dos nossos recentes bilionários americanos:
|
Steve Jobs e Steve Wozniack |
Kevin Rose, fundador do The Digg |
|
Mark Zuckerberg, fundador do FaceBook |
|
Observando as fotografias, um padrão se repete: os caras ficando ricos não são lindos nem especiais: são pessoas como eu e você. Cria-se então a impressão de que em um primeiro momento, foram caras completamente ignorados pela sociedade, correto? Verdadeiros “gênios” cujas idéias eram tão fantásticas que simplesmente calaram todos aqueles que os ignoram em um primeiro momento, correto? Errado!
Todos tem por trás executivos altamente qualificados (normalmente capitalistas de risco) que controlam cada aspecto por trás do gerenciamento dos negócios envolvidos. Você realmente acha que quem gerenciava os negócios da Apple no início era Steve Jobs? Você realmente acha que toda a grana da Microsoft veio só da genialidade nos negócios de Bill Gates? Convenhamos: é muita ingenuidade. São estas pessoas que definem o que é de fato uma idéia boa ou não. Os fundadores são apenas a imagem pública da empresa.
A pergunta que fica é: se você tem um negócio, e quer vendê-lo, porque expor como lider do mesmo alguém que aparenta não possuir experiência alguma em administração? A resposta é simples: porque o público alvo meu caro desenvolvedor, é você. Repare que sempre por trás do “lider”, o produto vendido consiste em uma plataforma. Uma plataforma na qual você poderá criar seus programas e talvez ficar “extremamente rico” do dia pra noite também. E sabe quem realmente fica mais rico com isto? As empresas, não você.
Resumindo: você caiu de novo no golpe da propaganda. Desculpe por destruir suas ilusões.
Concluindo
Ficar rico não é fácil. E buscar o dinheiro como fim é coisa de idiota (lembre-se: ele é apeanas um meio). Nossa profissão é extremamente difícil, se você analisar o sucesso por trás de cada novo bilionário, irá perceber que é fruto de MUITO esforço, de incontáveis noites sem dormir, de inúmeras recusas e infindáveis frustrações. A única coisa que todos tem em comum é a perceverança. Em nossa profissão, se você não ama o que faz, acredite: jamais irá ter sucesso algum.
É preciso que no desenvolver haja uma paixão incrível por aquilo que se está produzindo, pois caso contrário, você irá simplesmente desistir do trabalho. Os obstáculos são infindáveis até que um produto chegue a ser comercializado (e ser comercializado não é garantia de sucesso): há inúmeros defeitos a serem resolvidos, pessoas a serem convencidas, e contas, muitas contas a serem pagas. Isto sem mencionar a burocracia. Se você realmente acredita que basta começar a programar para ficar rico, acredite: não é verdade, arrange outra profissão.
Apenas programar por programar não lhe levará a lugar algum além do “vale da decepção”. E pior: se você não amar MUITO (mas aqui eu digo amar de verdade, ser realmente APAIXONADO pelo que se faz: ter na sua cabeça o que está fazendo o tempo inteiro), com certeza seu produto será uma merda SE vier a ser concluído.
