Top 10 reasons why I don't like JSF

At this JavaOne Brasil, there was a great discussion about Java Web Frameworks, with folks from Caelum, GlobalCode and Oracle. Arun Gupta, Maiko Rocha, Vinicius and Yara Senger, and many others who came to participate.

The discussion went mostly around what companies and developers should do before choosing a Web Framework. Although I was willing to move the discussion to another level (eg, poiting these 10 reasons), I decided to just take it easy. And as I stated: there's no perfect Web Framework. But there's a perfect web framework for your case.

But now I think it is the right time and place to share my thoughts. Here are my top 10 reasons (mostly non-technical) on why I don't like JSF.

1. Extra step when defining a project's architecture
   People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.
   
   Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.
   
   You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional.
   
   
2. Fragmented Community
   Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs.
   
   It is not easy to ask for help on a fragmented community. If you face a problem with RichFaces, when you were used to work with ICEFaces, you might end up asking something stupid, and probability is you will be told of a different solution to the same problem.
    
3. Fragmented Documentation
   If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on.
   
   
4. Component Incompatibility
   Well, there's not much to say on this. JSF 2.0 address some issues, but not all of them. Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events.
   
   
5. Caveats on some scenarios because of different implementations
   This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.
   
   I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.
   
   With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets.
   
   
6. Designers and developers roles mixed
   Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.
   
   This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.
   
   With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.
   
   
7. Does not improve usual web development process
   Like I said before, companies are still working with a development process based on: design, template, inject dynamic code, fix design issues, release.
   
   That's how Java Web development works. If you disagree, please comment on that. But I've been developing web applications for almost 8 years and that's how I see it.
   
   All frameworks that mix dynamic code on the HTML or some layer that outputs it, doesn't improve the common web development process. Which sucks, IMO. You have Web Designers to do all the prototype. Sometimes, your company pays to a Design shop to do that. And in the end, you have business developers fixing design issues because a pixel here or there is not correctly aligned with that right border.
   
   Now, there are some frameworks that address this issue quite well. Tapestry is one of them, if not the first. Then there's Wicket, which of course the best practice is to componentize the UI, but it is possible to work only with the prototype. With JSF, you have Facelets. It helps a lot, and I'm sure improves *a bit*. But the development process is beyond working with pure HTMLs and prototypes.
   
   With JSF, the developer does a lot of SOP - String Oriented Programming. If you are not working with a great JSF-supported IDE, you will end up doing a lot of copy-paste of Strings of method names, property names and bean names.
   
   Some may argue that Wicket replaces JSTL with Java. It is true. But consider this: if you are working with Wicket and you've already binded your UI, you don't have to look to your HTML again. With JSF, you must look at your ManagedBean and your page to make sure everything is correctly binded. On Wicket, new properties and methods can be added without modifying the UI, and still with JSF you must edit two files to do that. It is one approach, I know. But that does not changes neither improves the development process if you compare to Struts. GWT improves that, just as Wicket, IMO.
    
8. Non-functional prototype
   Ok, not a big deal. But it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?
   
   
9. Performance
   Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... :-(
    
10. Web is fast, standards are slow
    Let's take JPA for example. How old is SQL? Since 1974. Hibernate was build based on something that it was already a standard. So it was JPA. It is reasonable to have a specification for that, and totally acceptable to work with. JPA developers won't have problems dealing with different implementations, at least if they do their job right. What about XML frameworks? Mid 90's. My point is. Some specifications are build based on something with limited scope, even though generic, or on something that is already a standard and well-know by the market.
    
    Now let's take the Web. Although HTML is a specification, and old, it definitely has an unlimited scope. And because of its nature, it is open to innovation and creativity. How to standardize that?! HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.
    
    Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to.

I did work with JSF before, and I love to be a Java developer. I have my work done with it, and I'm paid because of it. But I felt like being left behind while looking at friends building cool apps, quickly and with good quality, with other languages, other platforms. And if I want to deliver solutions with performance, quality AND speed to my customers, I will think twice before choosing JSF.

Sure it has scenarios or business strategies where JSF is the best option. If there wasn't, Oracle/Sun, IBM, Red Hat and others would not put money on that. For companies that want to make sure they will easily and quickly find a developer to replace another, to keep the work on a JSF project, then, it's a business decision.

Now, from a developer perspective, I prefer to do my projects with something non-standard, while the Web is not standardized, and my customers are not worried about that.

Tutorial: Começando com Apache Wicket (Parte I)

Já que não tem Apache Wicket no JavaOne Brasil, vai um tutorial de Apache Wicket, entitulado "Começando com Apache Wicket (Parte I)" publicado no Lado Servidor, com o apoio do Paulo Jerônimo e da wdev, que contribuíram para minha participação no The Developers Conference 2010, em Florianópolis. O bacana desse tutorial é que produzi um video também, para acompanhar (sem cortes) o desenvolvimento da aplicação de exemplo.

Curioso em saber como ficou o resultado? Então vai logo ver.

Tutorial: Começando com Apache Wicket (Parte I)

E se você perdeu a Trilha Web do TDC 2010 e não viu minha palestra, confira ao menos os slides.

Apache Wicket derruba o padrão JSF

[]'s
Bruno

Errar, corrigir, committar - Sobre o JavaOne Brasil

Um programador quando encontra um erro, automaticamente, como que por instinto, sente vontade de corrigí-lo e mandar para o repositório, para ter segundos após, a sensação de um trabalho bem feito. Um orgulho de sí próprio. Às vezes, queremos fazer a mesma coisa na vida real. Com os erros do dia-a-dia, com os erros que envolvem pessoas.

Aproximadamente 3 semanas atrás, me empolguei com uma mensagem da Yara Senger, e submeti para o comitê do JavaOne Brasil, 3 palestras relacionadas à Apache Software Foundation. Soube ao mesmo tempo do The Developers Conference 2010, em Florianópolis, onde meu amigo Rodrigo Cândido, participara da organização. Não hesitei e sugeri à Wdev, cuja empresa agora faço parte, que levasse ainda mais conteúdo para este grande evento. Levamos palestras interessantes. Uma sobre Desenvolvimento para iPad, do Felipe Cypriano, e outra sobre Integração Contínua, do Marcelo Behera. Além das minhas duas palestras sobre projetos Apache (Wicket e Camel); as mesmas que havia submetido para o JavaOne Brasil.

No dia 3 de Novembro, recebi um e-mail do Sharat Chander agradecendo minhas submissões, mas que infelizmente o conteúdo não foi aprovado para o JOBra. Sem razões, sem explicações. E também disse que não é comum enviarem notificações desse tipo. Geralmente o pessoal fica no vácuo.

Ao mesmo tempo, no meio de todos estes eventos, a Oracle com seu processo contra o Google, blogs começam a dizer que a Apache copiou código para dentro do projeto Harmony. Ela esclareceu, mas não encerrou o assunto. De fato, iniciou uma guerra contra a Oracle, em defesa do Software Livre.

Por fim, no dia 8 de Novembro saiu a programação do JavaOne Brasil. Anunciada pela Fabiane Nardon. E obviamente fui conferir a grade, atrás de palestras interessantes e palestrantes a serem prestigiados. Entretanto ao ler o conteúdo, me decepcionei. Por 3 fatores:

• (tweet, tweet, tweet) Falta de conteúdo relacionado à Apache Software Foundation
• Conteúdos repetidos (alguns assuntos, com mais de 2 palestras)
• (tweet, tweet) Metade dos analistas de conteúdo vão palestrar

O que mais me chateou mesmo, foi o primeiro item, e em seguinda o segundo. Com assuntos sendo apresentados mais de uma vez, não seria o caso de pensar melhor na escolha das palestras, e evitar repetição, abrindo espaço para expôr outros projetos? Considerando a Apache com principal fornecedora de projetos Open Source para a plataforma Java?

Claro que fiquei chateado por não ter sido aprovado a participar do JavaOne. Mas frente ao o que está acontecendo, constatei que, não apenas minhas palestras, mas toda e qualquer outra associada à Apache que tenha sido submetida, foi rejeitada, ao que parece, propositalmente. E isso é o que me deixou realmente chateado. E por favor alguém me corrija se eu estiver errado. Seria muito bom saber os reais motivos.

Não reconhecer a Apache, e não incentivar a comunidade brasileira a participar da ASF é ir contra o Software Livre. A falta de palestrantes e palestras entusiasmados com projetos da Apache no evento, ao que parece, é reflexo dos desejos da Oracle.

Pedido de desculpas aos palestrantes

Com toda a minha chateação, e sem refletir bem a respeito, acusei amigos injustamente. É fato que metade dos analistas de conteúdo vão palestrar. Mas como muitos outros eventos, isso é normal. Eu mesmo, por causa da minha amizade com algumas pessoas, obtive espaço no TDC2010. Não bastasse uma palestra, levei duas. E ainda abri espaço para dois outros profissionais.

Acusei amigos injustamente por algo que eu mesmo havia feito alguns dias antes.

Alguns dos analistas são amigos, outros são conhecidos. E muitos outros que irão palestrar, também são meus amigos, de empresas que trabalhei anteriormente. 

Que fique claro: todos os palestrantes selecionados merecem estar lá. Tenho certeza que a escolha foi difícil, e com critérios como +assunto, +técnica, +histórico e +mérito, os melhores palestrantes foram selecionados. Jamais disse algo contrário. 

Por fim, peço desculpas ao Bruno, com quem aprendi muito. À Yara que me incentivou muito para submeter conteúdo ao JavaOne e me deu total apoio no TDC2010. Ao Vinicius (que ironicamente retweetou meu desabafo), Paulo, Guilherme, Bruno Ghisi, Fabiane e Fabio Velloso.

Vocês são excelentes palestrantes e há muito tempo contribuem com a comunidade. Com certeza, estão no evento por mérito.

Um excelente JavaOne Brasil a todos.

Um alô para o Liaw Mike e principalmente ao Michael Nascimento, que me ajudou a enxergar o bug. :-)

ApacheCon Brazil and why we need it?

I'm not sure if this mailing list is the right one to write about this, but I'm gonna take the risk. I suppose "Community" means anything related to it. And this is definitely about community.

Before anything, I'd like to share my history with ASF. (skip if you want... :D)

When I started to get involved with the Apache Software Foundation in a deeper level, I was still just a user, downloading Tomcat and using it. I guess most Java developers for the Web environment still do that.

5 years a go, I joined the Apache Wicket community and then my relationship with ASF has born. And for the last 5 years I've been speaking about it in Brazil, either in JUG meetings or at conferences around the country and sharing everything I wanted to share on my blog. I've even created a Google Groups for that, called Wicket pt_BR. With my contributions as an "evangelist" I gave birth to friendships with great people like Martijn Dashorst, Jeremy Thomerson, Eelco Hillenius and others from the Wicket community.

Then, in 2008 I heard about the Apache TAC and, thanks to ASF, I could meet them in person during ApacheCon @ New Orleans. It was better than anything I've ever experienced. Considering how close I was to great people, professionals and friends, and how easy I could start chatting about anything to them, I thought that was the best conference it could ever exist. I thought: "ApacheCon is the best. I got free beer!". That was cool. Every conference I go here in Brazil, I wish someone put some beers instead of Coke. Until now... only #fail

Then, right after I came back from New Orleans, I started to play with the SOA stack (Camel, CXF, ServiceMix and ActiveMQ). I also became friend of great people like Bruce Snyder, Claus Ibsen, Hadrian Zbarcea and Debbie Moynihan.

Last year, 2009, when I heard about ApacheCon in San Francisco, I took the chance to apply again to the Apache TAC (no, I wasn't bargaining; it really is expensive to fly from Brazil to the USA, specially SF). I just applied for the tickets, and for accommodation I was safe with CouchSurfing friends I already knew. Also, I really wanted to help the organization. It was when I met Nick Burch, Ross Gardler and Noirin Shirley. Could not forget my latin friends Amelia Blevins and Carlos Sanchez. Other names like Jesse McConnell, David Blevins and Yeliz Eseryel are also in my good memories of ApacheCon 2009. Unfortunately this year, because of personal reasons (not because of TAC rules), I couldn't be present at ApacheCon.

With the help of Bruno Souza, I discussed with some people, including Sally Khudairi, the idea of bringing ApacheCon to South America.

What I saw on ApacheCon '08 and '09 was something amazing. Perfect for South America. Perfect for Brazil. The Apache Way is something that must be shared with everyone. 

A few months a go, I went to Brasilia (country's capital) to talk about the ASF in general, not on an specific project. It's amazing how people are unaware of what the ASF really is. And how people limit their knowledge to only what the big players show to them. Still, they all know Struts and Tomcat. It seems that South America is a big user of Apache projects rather than truly contributors.

Now this year, with JavaOne going to happen in Brazil, and the sessions that were scheduled, I believe it is now the time to drive ApacheCon south. There's no single talk about anything related to the Apache Software Foundation in this South American version of JavaOne. And I feel really sad about that. Sad that people that are behind the organization had the opportunity to accept papers (I myself proposed Wicket and Camel - papers I have been presenting since 2008 for rooms of 30~40 attenders).

And I'm sure everyone will use Maven, Ant or Tomcat to demonstrate something.

I don't know if this happened because of recent issues between Oracle and Apache, or just because of Java standards (like JSF, JavaFX, EJB) are more important than non-standard projects. It doesn't matter. I'm sure there was room. On my count, there are at least 3 subjects with more than 1 submission approved. Look at JavaOne track.

Now, if the ASF, the most voted JCP EC member (with 95% votes), has no space on JavaOne Brazil, the country who have been participating in the Open Source movement, giving birth to the OpenJDK thanks to Javali project, and Bruno Souza, than we should start considering other alternatives. Alternatives to standards, like Wicket or Camel.

We already have ApacheCon Europe and North America. I'm sure we can do ApacheCon South America.

Let's do this happen. Let's do it the Apache way.

Bruno Borges

Apache Wicket ainda mais divertido: Parte 1

Este é o primeiro de uma série de artigos para mostrar o Wicket à comunidade brasileira. Cada artigo que eu ler sobre JSF, Facelets e afins que achar interessante e me questionar: "seria ainda mais divertido fazer isso com Wicket", vou fazer um "fork" do artigo e codificá-lo com o Apache Wicket.

Para começar, vou forkar o artigo do Eder Magalhães sobre como tornar um trecho de código Facelets em um componente reutilizável, chamado "Facelets ainda mais divertido! Parte II".

[início do fork]
Neste post vou comentar sobre a criação de componentes usando somente HTML simples e Java puro - na minha opinião o grande diferencial do Wicket. O cenário é um formulário de manutenção de registros de funcionários, e o protótipo é simples:

É comum um protótipo ser entregue por Web Designers, e o nosso trabalho está em adaptar aquele protótipo para processar informações dinâmicas. A página acima se chama CadastroFuncionarios.html e a seguir, o código que o Web Designer entregou:

CadastroFuncionarios.html

Mas é comum ter trechos de telas que são repetitivos. Como os botões de ações deste formulário. Então é interessante tornar isso um componente para ser reutilizado e quando exigir modificação, que seja apenas uma vez, em um único lugar.

No Wicket, páginas são componentes, e funcionam em pares (Java e HTML). Como queremos construir um componente com os botões, precisamos de um painel, para ser reutilizado em outras páginas. O primeiro passo é criar a classe e um HTML exclusivo para o painel, contendo somente os componentes de botão.

Para criar um novo painel para agrupar componentes, existe a classe Panel. Vamos criar uma subclasse dela e especializá-la:

BarraBotoes.java

Por se tratar de um painel de botões, deixei implementado 3 métodos associados 1 para cada botão. Quem utilizar este componente, poderá facilmente sobrescrever estes métodos para adicionar funcionalidades por ação. Outra vantagem aqui está na documentação gerada automaticamente, se o programador preencher o Javadoc.

Para finalizar o componente (segunda etapa), é preciso o HTML do painel, chamado de BarraBotoes.html

BarraBotoes.java

A tag wicket:panel é uma das poucas tags especiais (carregadas pelo DTD). Aqui ela serve para delimitar o que representa o painel, sem prejudicar as ferramentas WYSIWYG. Deixei propositalmente o restante do código HTML por fora da tag para representar um protótipo, que pode ser visto pelo designer e ajustado por ele próprio, caso queira mudar folhas de estilo. A vantagem é que ele pode avaliar se estas mudanças atenderão os requisitos de design. Ou seja, o protótipo continua funcional. Também foi feito o binding entre os componentes no HTML e os componentes em Java através do atributo wicket:id.

A partir desse momento, o painel pode ser reutilizado. Nenhuma outra configuração é necessária. Exceto um import da classe em outras páginas. :-)

Agora precisamos ajustar a página que conterá o painel. Abaixo, o novo HTML da página CadastroFornecedores.html já com os ajustes para binding com Wicket:

CadastroFuncionarios.html

E o código Java para a página:

CadastroFuncionarios.java

Para implementar uma ação, o programador precisa somente sobrescrever os métodos que lhe for necessário. Agora que a página está pronta, e utilizando o componente, o próximo passo é melhorar a inteligência do componente, com zero de alterações nos HTMLs, poucos ajustes na classe do painel BarraBotoes, e uma linha de alteração na classe da página.

• Apresentar o botão excluir de forma condicional, com base em um boolean
• Botão cancelar deve sempre abortar o formulário onde estiver contido

Caso seja de interesse do programador acrescentar mais lógica no componente, para que por exemplo os botões tenham visibilidade condicional, ajustes na classe BarraBotoes devem ser feitos. E somente nela. No HTML nada precisa ser alterado. Abaixo, o código da classe com lógica de visibilidade condicional de botões:

BarraBotoes.java

A primeira acao foi adicionar um construtor que recebesse um Model (assunto para outro post), do tipo Boolean, e associar este Model como condicional para o método isVisible() do botão excluir.

A segunda ação foi ajeitar o construtor padrão para continuar funcionando como anteriormente, e mantendo assim compatibilidade com páginas que sempre mostram o botão excluir. Novas páginas poderão utilizar o novo construtor e condicionar a exibição do botão, se quiserem.

A terceira ação foi cancelar o processamento dos dados do form quando o botão cancelar for clicado. Para isto, a propriedade defaultFormProcessing deve ser desabilitada.
[fim do fork]

A grande vantagem do Wicket está em jogar para o lado Java toda a programação da interface, deixando o protótipo limpo, estático, e mesmo assim permitindo o programador manipular com uso inteligente da orientação a objetos, os componentes de tela.

O que mais você gostaria de saber sobre o Wicket?

Abraço,
Bruno

PS: mock de tela feito no Mockflow

Dicas para uma senha segura

Senha. A porta de entrada para qualquer coisa na era digital. Uma senha fraca e você perde seu perfil no Orkut. Uma senha comum e seu servidor é hackeado. Os riscos são enormes quando não utilizamos uma senha adequada, mas também podemos perder o acesso se não nos lembrarmos dela.

Leia mais deste meu post sobre Dicas para uma senha segura em Lado Servidor.

A bruxa está solta em Floripa

Eu já estou acompanhando o caso há muito tempo, mas agora finalmente saiu na mídia nacional:

http://www.conversaafiada.com.br/politica/2010/07/12/policia-tucana-de-s-catarina-tem-um-estupro-para-esclarecer/

http://www.conversaafiada.com.br/politica/2010/07/11/“heroi”-do-mosquito-vai-aconselhar-serra-em-santa-catarina/

Como já disse ao meu pai, que juntamente com todo o resto da minha família e outros familiares, ainda vivem em Florianópolis: "A Ilha da Magia é o paraíso não-fiscalizado de políticos do PSDB (e aliados)".

O atual prefeito é itinerante (foi prefeito por 8 anos em São José, e não esperou 4 anos para ser prefeito em Florianópolis). 

Roubou quase R$ 5 milhões de reais no último reveillon, com uma árvore de natal superfaturada e um no-show de um cantor italiano que faria a cerimônia dos fogos.

O governador Pavan vive enrolado em casos e descasos.

O irmão do prefeito é, ironicamente, atual prefeito em São José, a cidade vizinha, que junto com Florianópolis forma 80% da economia da Grande Florianópolis.

A RBS (filial Globo) não noticiou um caso de estupro, e quando o fez, nada detalhou e ainda se defendeu atrás do ECA. Motivo? O estuprador é da família sócio-majoritária do Grupo RBS. Com as fortes brigas entre Globo e Record, esta última aproveitou a oportunidade para deitar o cacete. http://tinyurl.com/2clnp2d

Até o momento, nenhum canal de notícias que tenha qualquer vínculo direto ou indireto com a Globo/RBS fez uma reportagem sobre o caso do estupro.

Na internet, se encontra muito sobre o que aconteceu no Barraco de Sorocaba (#Sorocabarraco), assim como sobre o caso do estupro. Entretanto o Fantástico ontem preferiu fazer a matéria sobre o barraco.

Não bastasse tudo isso, ainda não se viu na mídia nacional qualquer exposição às frequentes manifestações de estudantes na cidade a respeito do último reajuste de ônibus, elevando a tarifa ao valor de R$ 2,95, sem aumento de frota, horários ou qualquer melhoria no precário sistema desintegrado de transporte.

É a Ilha da Magia, voltando aos tempos de bruxaria.

Oi é investigada por invasão de privacidade

O Dep. de Proteção e Defesa do Consumidor (DPDC) do Ministério da Justiça investiga possível invasão de privacidade dos usuários Velox, graças ao uso de uma ferramenta de monitoramento, chamada Webwise.

Em Dezembro de 2009 eu já havia mencionado que a Oi, assim como muitos outros provedores, já praticam invasão de privacidade graças a natureza da tecnologia envolvida no acesso à Internet.

Invasão de Privacidade no Oi Velox para controle de velocidade

É possível, sem instalar qualquer programa nos computadores dos usuários, identificar quais sites os usuários estão acessando. O programa Webwise na verdade é um complemento para cruzar informações. Esta investigação do DPDC deveria se extender a uma análise técnica dos roteadores e servidores utilizados pela Oi, e por outros servidores.

Identificar quais sites são acessados pelo usuário não é difícil para a Oi. Ela já faz isso. Difícil é obter informações como tempo gasto e programas.

*** Atualização ***
Enviei o e-mail abaixo à Sra. Laura Schertel Mendes, coordenadora geral de Supervisão e Controle do DPDC, exigindo que nesta investigação com relação ao uso do software BT Webwise, também fosse feito um trabalho para auditoria dos servidores e roteadores da Oi, assim como de outros provedores que praticam Traffic Shaping.

Bruno Borges	Tue, Jun 29, 2010 at 7:26 PM
To: laura.mendes@mj.gov.br
Boa noite Laura,     Acompanho os movimentos da Oi com relação ao Webwise desde Dezembro de 2009, quando apontei em meu blog que a empresa já praticava invasão de privacidade em seus usuários Velox remotamente, ao identificar em seus servidores/roteadores o conteúdo acessado com o propósito de limitar a velocidade dos usuários. Ao ver o recente anúncio da investigação oficial contra o BT Webwise, gostaria de em primeiro lugar, parabenizar pelo trabalho, e em segundo lugar, pedir que esta investigação não se limitasse somente ao uso do BT Webwise nos computadores dos usuários, mas também a uma auditoria e investigação nos servidores/roteadores da Oi, e de outros provedores de Internet. O motivo é o Traffic Shaping ilegal.     A técnica de Traffic Shaping praticada pela Oi é invasiva, pois restringe somente conteúdos de vídeos. Não bastasse a invasão nos dados trafegados entre servidores e o computador do cliente para identificar que se trata de vídeos, a Oi ainda pratica ilicitamente, um limite de velocidade para não prejudicar sua má dimensionada infraestrutura. Os planos oferecidos pela empresa não condizem com a sua infraestrutura, além de induzirem usuários a contratarem planos mais caros (e supostamente mais velozes) ao encontrarem lentidão em suas conexões.     Fica evidente neste vídeo que gravei, que a Oi utiliza técnicas avançadas de Traffic Shaping para dificultar a constatação da prática abusiva de limites de velocidades.     Assim como a Oi induziu usuários do Velox a instalarem o BT Webwise, ocorre também uma indução à contratação de planos mais velozes para solucionar os problemas de velocidades derivados da prática do Traffic Shaping.     Gostaria se possível, de alguma forma participar, como cidadão e usuário, destas investigações ou ao menos receber uma confirmação de que haverá algum trabalho para analisar as constatações levantadas por mim neste e-mail. Atenciosamente, Bruno blog.brunoborges.com.br +55 21 76727099

Tchau!

Em Floripa, manézinho virou otário

Quem é Manezinho da Ilha, pode se ajoelhar agora, erguer as mãos pro céu e gritar: "eu sou otário!". Sim, você mané, é um otário. E nem vou pedir desculpas pois, você é um boca-mole, um bundão, um frouxo sem coragem de lutar pelos seus direitos. Você fica em casa almoçando de frente para a TV, à espera do Jornal do Almoço para ver o que o Roberto Alves tem a dizer sobre o último jogo do Avaí ou do Figueirense. Você é um medroso, que assiste a Cacau Menezes fazer propaganda de suas festas; que você passa meses economizando para comprar a camisa da Feijoada. Você é um acomodado que se contenta em reclamar e concordar junto, da sua casa sentado no seu sofá, dos comentários do Luiz Carlos Prates. Você manézinho da ilha, virou um otário.


Você assiste da sua TV comprada no Koerich, Dário Berger ser eleito de forma ilegal e ainda ajudar a colocar seu irmão na prefeitura da cidade-irmã São José. Sua mulher não se importa com isso, pois está feliz da vida com o anel que você comprou na Quevedo. E seus filhos estão ocupados demais no Playstation 3 para poderem compartilhar com você essas notícias.

Você mané que virou otário, assiste dia após dia, o Grupo RBS (TV, DC, CBN) trazer a você, através de um monopólio de informações, somente aquilo que interessa a eles. Você não se importa com o transporte público pois você tem carro. Mas você é tão otário, que reclama do trânsito todo dia na hora de atravessar a ponte. Reclama que tem carro demais na cidade e que se o transporte fosse bom, até usaria. Mas não usa porque é caro. Que carro compensa. Então você segue essa vida de reclamações, e de submissão. Você se submete ao que os burgueses da cidade te impõem. Você mané, virou otário.


Só não é otário quem está ganhando dinheiro com tudo isso: políticos e empresários. Você mané, é assalariado. É funcionário público. É estudante. Você mané, é otário.

II Guerra do Contestado: em Florianópolis

É o que devem querer os atuais governantes de Florianópolis. Uma briga entre os "caboclos", ou nas atuais circunstâncias, os "estudantes" e a população em geral contra o poder do Estado e o setor privado (o que acabam sendo as mesmas pessoas). A Guerra do Contestado do século 21 renasceu graças a três principais acontecimentos na última década, e se prepara para alcancar seu momento mais delicado na próxima Quinta-feira, dia 20 de Maio de 2010. Anote esta data. Na Sexta-feira, você vai facilmente associar este texto com as notícias do dia:

[...] Originada nos problemas sociais, decorrentes principalmente da falta de regularização do transporte público da posse de terras, e da insatisfação da população hipossuficiente, numa região em que a presença do poder público era pífia [...]

Sim, fiz um ajuste no trecho publicado na Wikipedia, apenas atualizando-o para os dias de hoje. Não muda muita coisa. Veja este resumo, caso você não se lembra, ou ainda não estudou a Guerra do Contestado.

Talvez se associarmos a batalha atual com o que aconteceu entre 1912 e 1916, o movimento ganhe maior apoio da população. Caso você não se recorde dos eventos desta última década que estão impulsionando para este fim, assista ao vídeo abaixo. Se você se recorda, refresque a sua memória.


Democracia Militar from Vinicius Possebon (Moscão) on Vimeo.

Dez anos se passaram, e a causa contra o abuso do poder ganha força. Existe uma diferença entre defender a ordem pública e atacar estudantes em manifestações pelas ruas. Afinal, não fossem essas manifestações, você não estaria vivendo numa democracia neste exato momento. Talvez nem tivesse Internet na sua casa e se tivesse, seria censurada.

O dia 20 de Maio de 2010 antecede meu aniversário. E eu gostaria de acordar na Sexta-feira com a notícia de que nada aconteceu. De que a população não se rebelou contra o Estado. De que a II Guerra do Contestado não aconteceu. Mas só terei certeza disso se antes eu ver a notícia de que o prefeito de Florianópolis cancelou o reajuste das tarifas de ônibus.

Ao acordar e ver que o prefeito não defendeu os interesses do povo, vou ficar feliz ao ver no noticiário fotos e vídeos de estudantes, trabalhadores, mães e crianças com as caras pintadas, com faixas, cartazes, camisetas e megafones, protestando contra este abuso.


Quinta-feira, 20 de Maio de 2010
II Guerra do Contestado

7 passos para destruir Florianópolis

** UPDATE **
II Guerra do Contestado (em 20/05/2010)

Há 5 anos, em 2005, quando saí de Florianópolis meses antes da segunda Revolta da Catraca, já tinha certeza que a cidade estava caminhando para problemas sérios de transporte. Conheci naquela época, o transporte coletivo de cidades de São Paulo, Rio de Janeiro, Belo Horizonte e ainda cidades internacionais como Roma, Barcelona e Paris. Cheguei à conclusão que para destruir uma cidade, torná-la insuportável, basta você destruir o transporte coletivo. Como eu  me arrisco a dizer: o meio de transporte é o sangue de uma cidade, transportando vida em um organismo delicado.

Florianópolis mais uma vez enfrenta reajustes de tarifas. Pesquise no Google, ou visite alguns dos sites indicados no final deste artigo. Neles você vai encontrar muito mais informação, mas resumo: é um dos menos eficazes, e o mais caro do Brasil (R$ 2,95). O que quero mostrar aqui, são os 7 passos que um prefeito, como o Dário Berger, deve seguir para destruir o transporte coletivo da cidade, e consequentemente, a cidade em sí.

1. Ofereça um único meio de acesso à cidade que fica numa ... ilha
   Sim, pois barcas e pontes em outros extremos são eficientes, e isto com certeza facilitaria a vida do povo. O Rio que nem ilha é, decidiu colocar uma pequena ponte ligando-se a Niterói, e um serviço de barcas. Total falta de bom senso dos governantes.
   
   
2. Não invista em transportes sobre trilhos, eles não são poluentes
   Para destruir uma cidade, é importante não abraçar causas ambientais. Transportes sobre trilhos, como trêns, metrôs e bondes não emitem poluentes. Melhor manter estas tecnologias longe dos planos de desenvolvimento da cidade! Nova York cometeu uma loucura ao proibir inclusive, carros em Manhattan. O ar está melhorando. Absurdo!
   
3. Dificulte o uso de bicicletas na sua cidade
   Afinal, bicicletas não ocupam espaço, não emitem poluentes, não causam engarrafamento e são baratíssimas. Compartilhar bicicletas na cidade nem pensar. Isso com certeza iria diminuir o número de automóveis no Centro, indo totalmente contra os planos do prefeito.
   
4. Evite sistemas eficazes de integração de ônibus
   Prefeito bom, tem que parecer inteligente. E tudo que é inteligente, é complicado. Então ele deve complicar. O sistema de transporte público deve ser confuso, sem integração em algumas áreas, favorecendo cobrança adicional de tarifas, ou preços diferenciados. Deve irritar o passageiro, deixá-lo transtornado e depressivo, por saber que no dia seguinte terá que entrar nesse sistema novamente, até o fim da sua vida.
   
5. Dificulte (e cobre mais caro) o pagamento para usuários desavisados
   Cobre uma multa dos usuários que não buscaram informação para obter o cartão-cidadão. Cobre uma multa dos turistas por não terem tempo hábil para conhecer o sistema complicado e a cobrança diferenciada. Cobre inclusive, mais caro na primeira vez que um novo usuário quiser comprar o cartão-cidadão. Afinal para obter o cartão ele deve se dirigir até o Terminal Central. 
   
6. Mantenha um quadro de horários pobre de ônibus e itinerários
   O passageiro deve ter que esperar dezenas de minutos, por um ônibus cheio. Deve se irritar com a pequena quantidade de ônibus trafegando na hora em que ele mais precisar. Os motoristas devem ser treinados para passarem batidos em alguns pontos-de-ônibus.
   
   
7. Por fim, aumentar a tarifa anualmente, com taxas superiores à inflação
   O passageiro deve entender que é ele quem pagará por todo o sistema. Então se a inflação subir, o passageiro deverá cubrir o aumento de salário dos motoristas e cobradores, e o gap no lucro das empresas de ônibus, afinal "alguem tem que pagar a conta".

Seguindo estes passos, a consequência é simples: caos. O prefeito deve então ficar feliz, por ter alcançado seu objetivo.

Trânsito fica mais caótico para todos

Comentei no Twitter que um negócio que será em breve rentável em Floripa, é o transporte ilegal. Vans, moto-táxis, caroneiros e lotações em geral. No Brasil já temos inúmeros exemplos. Podemos facilmente entender porque ele [transporte ilegal] nasce, e o que isso ocasiona.

Transporte ilegal significa mais carros nas ruas, para suprir a necessidade do povo: transporte coletivo eficiente a um preço justo. Entenda eficiente como "traçando uma rota que agrada mais, e mais horários". Aqui no Rio as vans custam em grande maioria, R$ 2,00. E veja que as passagens de ônibus custam em grande maioria, R$ 2,35. O motivo de se usar a van, é para chegar mais rápido e economizar um dinheiro que para muita gente, é muita grana. No mês, pode chegar a R$ 21,00. O que dá para comprar leite para uma semana.

Com transporte legalizado ineficiente, as vans vão nascer e crescer rapidamente. E os ônibus ficarão ainda mais caros, pois afinal, passageiros irão migrar e o faturamento diminuir. Com poucos passageiros, "alguem precisa pagar a conta", e serão aqueles que invariavelmente precisam do transporte mas não podem, ou não querem, migrar para as vans. 

Mais vans: mais trânsito. Se você usa carro e acha que não será afetado, se iludiu. Você deveria também estar batalhando contra os reajustes abusivos.

Florianópolis terá tarifa de R$ 4,50 em 2012

Essa é a minha aposta. Por quê? Vans, poucos passageiros, mais carros. Menos ônibus e serviço mais caro. 

A cidade está à caminho da destruição. E somente você, cidadão, tem o poder de impedir.

Pule você também!

Quem não pula quer tarifa from Doc Dois on Vimeo.

Saiba mais:

• TarifaZero.org
• Reinventa Floripa
• #porumavidasemcatracas
• #contraoaumento
• @lataofloripa

Campanha #BoaDario

Como o Dário irá destruir Florianópolis?
Dê sugestões no Twitter, Orkut ou Facebook. Utilize a tag!
Idéias, passos, feitos e objetivos de Dário Berger rumo à destruição transformação de Floripa. Planejando a próxima Cidade Maravilhosa(mente cheia de problemas).


Abrace essa campanha!

Transformando Floripa em "Rio de Janeiro do Sul" #BoaDario

Por que testes do Inmetro e Anatel serão inúteis?

A Anatel anunciou hoje que, em parceria com o Inmetro e o CGI.Br farão testes para medição da qualidade da banda larga fixa no país. Os testes estão sendo feitos em 160 residências de consumidores das empresas Oi, NET, Telefônica e GVT. Apesar das boas intenções, está longe de alcançar o objetivo: impulsionar a melhoria no serviço prestado.

Estatísticas insuficientes
O Brasil possui mais de 15 milhões de contratantes de serviço banda larga. Mesmo assim, os testes de medição serão feitos em apenas 160 residências. Isto representa menos que 0,0011%. Esta amostragem é (desculpem a expressão) infinitamente insignificante e não pode ser considerado um teste válido. Se os resultados se mostrarem favoráveis às empresas, elas utilizarão destes dados para afirmar que seus serviços estão de acordo com as exigências do Inmetro e da Anatel. Você concorda?

Não bastasse isso, os testes serão feitos através do SIMET - Sistema de Medição de Tráfego de Última Milha. Este programa realizará testes de velocidade, DNS, ping e outros critérios, e reportar automaticamente todas as informações de volta para o CGI.Br. O programa e a proposta são interessantes, porém os resultados serão duvidosos.

O que realmente importa é a velocidade máxima contratada
Veja os principais critérios técnicos utilizados no teste, para fazermos uma análise posteriormente:

Grandeza	Critério
Disponibilidade	Maior ou igual a 99% (equivalente a 7,2h de interrupção ou menos a cada mês)
Vazão/Velocidade Média	Média maior que 60% da vazão/velocidade máxima contratada
Vazão/Velocidade Instantânea	Valor instantâneo mínimo de 20% da vazão/velocidade máxima contratada
Perda de Pacotes	Perda máxima de 2% (dois por cento) do volume de dados enviados
Tempo para estabelecimento de conectividade IP	Tempo máximo de 1 minuto
Número de tentativas para estabelecimento de conectividade IP	Valor máximo de 2 tentativas

Estes critérios são interessantes, porém podem apresentar resultados facilmente distorcidos ou simplesmente, questionáveis. O principal motivo é que o teste será feito possivelmente com servidores do CGI.Br, como a outra ponta da conexão entre o serviço ADSL contratado. Para representar o nível de desconfiança nos resultados (NDR), considerei uma avaliação de 0 a 5.

• Disponibilidade
  Para identificar que durante 1 mês o serviço de ADSL foi devidamente oferecido, ininterrupto (maior ou igual a 99%), seria preciso considerar que: a) não faltaria luz; b) não haveria enchentes; c) teria que provar que não houveram incidentes naturais, externos ou adversos à conectividade. NDR - 
  
  
• Vazão/Velocidade Média
  Este critério parece ser inteligente, e razoável, não fosse por um detalhe: as empresas costumam limitar a velocidade, com regras inteligentes em seus roteadores, baseadas em tipos de arquivos, ou de qual servidor está sendo obtido. Veja meu post sobre Invasão de Privacidade para Limite de Velocidade, presente no serviço Oi Velox para entender melhor. Resumindo: o teste pode apresentar excelente resultado, mas seus acessos ao YouTube ainda parecerão lentos, e a operadora alegará que a culpa é do canal de streaming.
  NDR - 
  
  
• Vazão/Velocidade Instantânea
  Para iludir o usuário de que a velocidade do seu plano está sendo respeitada, as operadoras geralmente deixam um limite de velocidade maior que o contratado, no inicio das transferências. Este critério será respeitado por todas as operadoras, exceto que por motivos que interessam somente às operadoras. Nesse caso, os resultados não precisam ser questionados, exceto a falta de ética das empresas.
  NDR - 
  
  
• Perda de Pacotes
  Para provar os resultados deste critério, é preciso identificar quem perdeu os pacotes. Se foi o lado que enviava dados ou o lado que recebia. E quem é quem. Não sou especialista em TCP/IP, mas acredito que para identificar que a operadora é a culpada em um alto índice de perda de pacotes, é preciso avaliar outros critérios, como ruído na linha ADSL (não previsto na análise da Anatel). Ainda assim, é provável que estes resultados sejam confiáveis, graças à naturalidade do principal meio de comunicação nos testes: TCP/IP (que garante entrega de pacotes). De certo modo, este teste é desnecessário, para não dizer idiota.
  NDR - 
  
• Tempo/Número de tentativas para estabelecimento de conectividade IP
  Outro teste que é difícil de considerar os resultados. Com qual IP será feito o teste? Os da CGI.Br? Ou uma série de servidores espalhados no mundo? Fica difícil de entender os resultados sem melhor clareza no processo e a consequência na melhoria do serviço.
  NDR - 

Qualidade mascarada
Pela forma que os testes serão realizados, fica difícil acreditar nos resultados. Isto pode apresentar uma qualidade mascarada, favorecendo as prestadoras e mantendo a baixa qualidade do serviço prestado. O serviço de banda larga deveria ser fiscalizado de outra forma. O certo é que agentes e técnicos da Anatel deveriam conferir e fiscalizar pessoalmente, os roteadores, backbones e backhauls utilizados na rede brasileira.

Fiscalização presencial
Proibir o uso de regras inteligentes de limites de velocidade, quotas e traffic shaping deveria ser o método utilizado pela Anatel para impulsionar a melhoria nos serviços. Fiscalizar as configurações utilizadas pelas operadoras, que respeitem os planos contratados.

A Anatel deveria fazer escola com a Anvisa, e aprender e entender o que é exigir qualidade de serviço prestado. Mudar o nome para Anvitel já seria um bom começo.

Atitude de Contratante, não de Cliente

O brasileiro tem um problema sério. Quando ele é empregado, prefere ser cliente, do que contratante. Os termos são similares, mas as atitudes são bem diferentes. O contratante avalia opções, avalia custos e a real necessidade do serviço a ser contratado. O brasileiro não sabe o que significa isso. Se ele coloca na cabeça a idéia de "botar" TV a cabo em casa, ele "bota". Se quer botar Sky, Oi TV, NET, Virtua, Velox, qualquer serviço, ele simplesmente bota o pacote que se encaixar melhor no seu bolso. Ele não contrata. Se o serviço não ficar bom, se tiver danos, ele se submete a ligações de dezenas de minutos, atendimento ruim, paga contas que não deveria, e ainda tem seu nome no SPC.

Contratos entre empresas são completamente diferentes. Eles possuem cláusulas bem específicas. Caso o serviço contratado, da empresa contratada, não for entregue como esperado, o pagamento pelos serviços é adiado, cancelado, ou até mesmo a empresa contratada recebe multas. O governo faz isso e tenho certeza que a Oi, NET, Claro, TIM, Vivo, TVA, Sky, Telefônica, Embratel e muitas outras prestadoras de serviço, quando estão em contrato como contratante, elas possuem esta atitude, exigindo uma prestação de serviço excepcional das empresas contratadas, como as que oferecem manutenção das suas linhas, da empresa que realiza o serviço de help desk, da empresa que faz a limpeza dos seus escritórios, enfim, de todo e qualquer serviço que a empresa contrata.

Veja o caso da empresa X. O contrato que ela realiza com a empresa Y, nunca é igual ao contrato que a mesma empresa X realiza com a empresa Z. Isto não ocorre com os contratos que a empresa X faz com seus "clientes". Neste caso, os contratos são todos iguais, pois seus clientes são... brasileiros trabalhadores. É a "massa", e não seria possível escrever contratos específicos para cada um.

Isso não significa que você tem que aceitar esse contrato. Na verdade, você é que decide se o contrato vai ser realizado ou não. É você que possui esse poder. É o seu dinheiro que vai ser reduzido, e o da contratada aumentado. Porém, o brasileiro não sabe o que é ser contratante.

A atitude do brasileiro precisa mudar.
Está na hora de o brasileiro controlar melhor a sua vida. Decidir o que é e não é essencial na sua vida. Deixar de contratar serviços de baixa, ou nenhuma, qualidade. Contratar serviços de qualidade. Trocar de fornecedor quando achar que o atual não está mais entregando o serviço esperado. Está na hora do brasileiro deixar de ser cliente e submisso. Está na hora do brasileiro ser CONTRATANTE. (sim, igual nos contratos que você lê).

Quando você é CONTRATANTE, você tem o direito de reclamar, de exigir qualidade, de pagar somente quando achar que o serviço contratado está sendo devidamente entregue. É quando a CONTRATADA é submissa a você, pois é do seu dinheiro que ela precisa. Você não precisa realmente de TV a Cabo, precisa? Vai morrer se ficar sem? Então coloque na sua cabeça: prestadoras de serviços não-essenciais devem ser submissas a você. É você que deve ditar o jogo. Se achar que o serviço está ruim, não aceite conversa, não aceite descontos. CANCELE. Mude de fornecedor, ou fique sem. Não pense duas vezes. Afinal, é o seu dinheiro.

A mudança de atitude do brasileiro começou. Citando o blog do Felipe Morais, "o lucro da NET caiu 62% no primeiro trimestre deste ano, comparado com o período de 2009". Mas ainda é pouco, pois é uma redução no lucro, diferente de prejuízo. A empresa apenas ganhou menos.

Mude sua atitude. Seja contratante de serviços.
Os termos "consumidor" e "cliente" são submissos. O termo CONTRATANTE não. O contrato só existe quando o CONTRATANTE aceita pagar. Pense melhor antes de aceitar, pois você é o CONTRATANTE.

Código Ruim é Viral

Certo dia um desenvolvedor começou a trabalhar numa empresa e no seu primeiro dia, enquanto configurava seu ambiente, tirou do bolso um pendrive. Lá continha todo o código antigo que ele escreveu na empresa anterior, para poder codificar mais rapido, ele mesmo afirmou.


Apesar do fato de isso ser ilegal e antiético, é também estúpido.
Código que não é ativamente mantido e refatorado se degenera rapidamente. Então ao invés dele melhorar e aprender novas e melhoras formas de fazer as coisas, na verdade piora com o tempo.


Atalhos acabam sabotando projetos de software.
Cada vez mais desenvolvedores acabam escrevendo código ruim e construindo péssimos produtos de software. Nós gostaríamos de culpar os gerentes e as empresas que nos forçam a trabalhar em cada vez mais apertados cronogramas.


"Eu adoraria fazer testes automatizados ou TDD, mas eles não nos dão tempo para isso."


Testes automatizados e TDD são parte da codificação. Quando você entrega um software, ou mesmo um pedaço de código, você está assinando aquela entrega, afirmando que funciona. Testes automatizados e TDD não são opcionais para a empresa, são opcionais para você.

Se você é confiante de que está entregando código de qualidade sem testes, então talvez eles não são necessários. Mas não empurre esta decisão para o (geralmente não-técnico) gerente. Ele pode não oferecer explicitamente a você tempo para "testes automatizados" mas ele com certeza espera que a coisa funcione.

"Eu sei que isso é uma gambiarra, mas eles falaram que a gente precisa disso funcionando agora, e que depois a gente pode voltar a mexer nisso."

Se esta é a mentalidade na sua empresa, quantas vezes você realmente voltou em algum código para refatorar e melhorar? Correria e gambiarra só trazem mais correria e gambiarra. Quanto mais você corre, e pula bons designs e práticas de qualidade, pior seu código vai ficar. Você vai introduzir mais defeitos e mais complexidade desnecessária. Isso vai atrasar seu cronograma ainda mais, resultando em ... mais correria. É um círculo vicioso que nós como desenvolvedores não apenas participamos, como também somos a causa por produzir código ruim.

"Este código não é tão importante, então não precisa ter um bom design."

O que aconteceria se este código não funcione corretamente? Se a resposta é "pouca coisa", então você provavelmente deveria ir trabalhar com outra coisa. Se a resposta é "coisa pra caramba" (geralmente é) então faça direito.


Escrever código ruim é viral.

• Se você escreve código ruim em certas partes do código, vai se tornar um hábito e vai começar a se espalhar em todo o resto do código do sistema
• É a síndrome da janela quebrada: se algumas partes do código estão pobremente escritas, haverá menor ímpeto para escrever código bom em outras partes.
• Sua base de código-fonte é o principal manual de treinamento para novos desenvolvedores no seu time. Se eles estão aprendendo a partir de código ruim, é assim que eles vão codificar também.
• Deixar programadores ruins no seu time pode na verdade ter um impacto negativo na produtividade. Profissionais mais diligentes vão gastar tempo arrumando código ruim, e outros programadores vão acabar se contaminando, como numa epidemia, com código ruim.

Se o código é importante o suficiente para ser escrito, então é importante o suficiente para ser escrito corretamente.
Como tem o código ruim se espalhado pelo seu time? Você tem sido infectado? Possui algum remédio natural para sugerir?


Fonte: codeanthem - bad code is viral