The new social media addiction

In the past, at the beginning of social media, Facebook times, I used to be hooked up by them. Checking people’s lives and exposing my life just to get the attention it was the trend. Everyone was doing that and it was fun.

Nowadays I see that this excessive life exposure brought many negative effects on our lives and because of that many people now avoid exposing their lives on social media. But this didn’t stop us from using the social apps, we still doing that but now in search of entertainment.

The problem that this diversion it’s becoming even more addictive and superficial than the previous one. We spend so much time on memes, funny videos, pranks, that we live in a constant imaginary world. Numbing our real feelings just to get out of the world and have microdoses of joy after laughing at a funny Instagram story.

TikTok, Instagram, 9gag are the TV of our generation. They replaced the silly TV shows of the past. They can look inoffensive at first but they numb us into a superficial world. A funny world where we don’t really care about our reality if we can have some fun with cat memes.

internet rabbit hole alice meme

In Brazil, we used to have, and in some cases, we still have, TV shows with auditorium games, competitions, pranks. Silvio Santos, it’s the biggest name of all. He still keeps some time slot dedicated to this kind on his TV network. And it’s the same all over the world. Candid Camera, Just for Laughs, Jackass, you name it. So many worldwide. The big difference it’s that back then we weren’t in control of when to watch, we had to wait and enjoy the most of it. Nowadays we can choose whenever we want to watch, for how long, and from an infinite library: the internet. So we can spend several hours on them and without realizing it. It’s the known “internet rabbit hole”.

down to the rabbit hole alice

This is making people sick. Comparing yourself to others on social media makes you lose your self-esteem. Not only has social media been proven to cause unhappiness, but it can also lead to the development of mental health issues such as anxiety or depression when used too much or without caution.

We have to stop that addiction by finding meaning in what we do. We need to ground ourselves on what matters in life. Looking for human connection, religion, nature will make you feel better. We often have the ego that we don’t need connection, that we are sufficed, this is true but we also are part of the whole. Knowing that you also need to connect, that you are just a grain of sand in this entire universe, that there is a God out there, this helps one to ground itself.

finding inner peace
Silhouette illustration of a man praying outside at beautiful landscape

As with any other struggle in life, you need time to get over it. Take it easy, go step by step and you will make it. After you get the habit of taking care of yourself, loving your family, living up by your faith, taking care of nature, will you be ready for any challenge.


Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe Blog

Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th. is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

REVIEW: The Mythical Man Month: Essays on Software Engineering

As a classic software engineering text, this book is only helped by the addition of Brooks’ latest essays and reflections on his original conclusions. Remember, it won’t do you any good unless you read it.

“As a classic software engineering text, this book is only helped by the addition of Brooks’ latest essays and reflections on his original conclusions. Remember, it won’t do you any good unless you read it.” Rating 10/10

Jason Bennet
The Mythical Man Month: Essays on Software Engineering by Frederick P. Brooks, Jr. (Addison Wesley, ISBN 0-201-83595-9)

While this book has some years on it, the fact that it is still around is a testament to the strength of the text. This latest addition contains additional essays and thoughts about engineering. So, read below and enter into the wonderful world of software engineering.


Before I launch into my review of The Mythical Man-Month, I would be negligent if I did not explain the meaning of the first edition of this book. It’s in 1975. Programmers slave over some of the earliest dumb terminals on massive mainframes from the Great Monopolistic Satan of computing, IBM. Maybe, if their lucky, the programmers can work on a minicomputer from that upstart company, DEC, and their PDP series of computers. FORTRAN and COBOL are your staples, with some PL/I thrown in for good measure. C is a blip on the horizon, just starting to make its way out of Bell Labs. Assembly language is still widely used throughout the industry. Enter Frederick Brooks, one of the industry’s originals. Brooks is reflecting on his time at IBM, specifically his working on the System/360 and its operating system, OS/360 (unique names, no?) during the mid-1960s. Brooks is trying to figure out what was done right, and what was not, especially in how the overall program was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensable part of software engineering. Twenty-five years later, we are still reading the book and learning from it. In an industry where most books are useless after six months, this book is almost prehistoric. Remember, though, what level a book must reach to last so long.

What’s good?

You might be wondering why this book has lasted so long. The answer is simple: the technology of the book is secondary to people’s lessons. Simply put, Brooks’ points are the following:

  1. Programming must turn into software engineering in order to continue to improve the state of the art.
  2. Any well-engineered product must be conceptually and architecturally whole.
  3. The tar pit of software development can only be escaped through a conscientious, dedicated process.

There are so many classic lines in this book that a simple review cannot account for them all. The most famous, of course, is Brooks’ Law of adding people to a late project (hint: it doesn’t help). Surgical development teams, the second-system effect, and the importance of documentation are all covered, sometimes for the first time, in MMM. Through the course of the book, Brooks covers all facets of what must happen to successfully complete a major software project, and in all parts, he gives a firm foundation for solid software engineering and project management. In fact, this was the first major book to accurately assemble the knowledge needed to engineer a large software project into one place and relate it from the perspective of a finished project.

In addition to the original chapters, Brooks’ essay from 1986, No Silver Bullet, is included, along with Brooks’ thoughts on his book twenty-five years later. These essays alone are worth reading, as they give an accurate estimate of where the industry is now. Suffice to say, the easy part is behind us. It’s real work from here on in.

What’s bad?

What’s bad about this book is that people don’t read it. There’s no particularly good reason, they just are too busy reading the latest book on today’s fad. The irony, of course, is that today’s fad will be laughed at next year, while MMM will still be around a decade from now. If you were assigned this book in school, read it again (you probably didn’t the first time :-). If you’ve never heard of it, read it tomorrow.

What’s In It For Us?

Why should any of us read this book? What does project management matter to a bunch of semi-organized groups? Aren’t we doing fine as it is in our striving for World Domination? Well, yes and no.

On one hand, we don’t have the pressures of commercial software. If Apache comes out tomorrow instead of today, no matter. Everyone else is just as bad, so we just have to not be worse. For that matter, most open-source projects are blessed with one or a few leaders who keep everything on track and in one vision. We don’t have too many projects with lots of different architects.

On the other hand, we’ve been blessed with low expectations. No one expected us to succeed, so any measure of success was a victory for the movement. Now, all eyes are on us. If a release comes out a month late, everyone will think we’re no better at keeping a schedule than Microsoft. If we have to rewrite another application because we did a poor design job, we aren’t offering a valid alternative. We have to be better than everyone else to prove ourselves, and we cannot do that in an individually-oriented environment. If the open-source community can learn the lessons of MMM better than the rest of the industry then we win.

More to the point, we as an industry must raise the expectations of our software. We need to strive for accurate schedules. We need to avoid the second-system effect. We need to understand why you cannot just add people to a late project to speed it up. In short, we need to care about producing quality software on time, instead of just getting stuff out there.

Table of Contents

  • Preface to the 20th Anniversary Edition
  • Preface to the First Edition
    1. The Tar Pit
    2. The Mythical Man-Month
    3. The Surgical Team
    4. Aristocracy, Democracy, and System Design
    5. The Second-System Effect
    6. Passing the Word
    7. Why Did the Tower of Babel Fail?
    8. Calling the Shot
    9. Ten Pounds in a Five-Pound Sack
    10. The Documentary Hypothesis
    11. Plan to Throw One Away
    12. Sharp Tools
    13. The Whole and the Parts
    14. Hatching a Cataastrophe
    15. The Other Face
    16. No Silver Bullet – Essence and Accident
    17. “No Silver Bullet” Refired
    18. Propositions of The Mythical Man-Month: True of False?
    19. The Mythical Man-Month after 20 Years
  • Epilogue
  • Notes and References
  • Index


Text written by Jason Bennet and extracted from here

Purchase the book over here at Amazon

Maker’s schedule, Manager’s schedule

“…the mere consciousness of an engagement will sometimes worry a whole day.”

Charles Dickens

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Each type of schedule works fine by itself. Problems arise when they meet. Since most powerful people operate on the manager’s schedule, they’re in a position to make everyone resonate at their frequency if they want to. But the smarter ones restrain themselves, if they know that some of the people working for them need long chunks of time to work in.

Our case is an unusual one. Nearly all investors, including all VCs I know, operate on the manager’s schedule. But Y Combinator runs on the maker’s schedule. Rtm and Trevor and I do because we always have, and Jessica does too, mostly, because she’s gotten into sync with us.

I wouldn’t be surprised if there start to be more companies like us. I suspect founders may increasingly be able to resist, or at least postpone, turning into managers, just as a few decades ago they started to be able to resist switching from jeans to suits.

How do we manage to advise so many startups on the maker’s schedule? By using the classic device for simulating the manager’s schedule within the maker’s: office hours. Several times a week I set aside a chunk of time to meet founders we’ve funded. These chunks of time are at the end of my working day, and I wrote a signup program that ensures all the appointments within a given set of office hours are clustered at the end. Because they come at the end of my day these meetings are never an interruption. (Unless their working day ends at the same time as mine, the meeting presumably interrupts theirs, but since they made the appointment it must be worth it to them.) During busy periods, office hours sometimes get long enough that they compress the day, but they never interrupt it.

When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I’d sleep till about 11 am, and come in and work until dinner on what I called “business stuff.” I never thought of it in these terms, but in effect I had two workdays each day, one on the manager’s schedule and one on the maker’s.

When you’re operating on the manager’s schedule you can do something you’d never want to do on the maker’s: you can have speculative meetings. You can meet someone just to get to know one another. If you have an empty slot in your schedule, why not? Maybe it will turn out you can help one another in some way.

Business people in Silicon Valley (and the whole world, for that matter) have speculative meetings all the time. They’re effectively free if you’re on the manager’s schedule. They’re so common that there’s distinctive language for proposing them: saying that you want to “grab coffee,” for example.

Speculative meetings are terribly costly if you’re on the maker’s schedule, though. Which puts us in something of a bind. Everyone assumes that, like other investors, we run on the manager’s schedule. So they introduce us to someone they think we ought to meet, or send us an email proposing we grab coffee. At this point we have two options, neither of them good: we can meet with them, and lose half a day’s work; or we can try to avoid meeting them, and probably offend them.

Till recently we weren’t clear in our own minds about the source of the problem. We just took it for granted that we had to either blow our schedules or offend people. But now that I’ve realized what’s going on, perhaps there’s a third option: to write something explaining the two types of schedule. Maybe eventually, if the conflict between the manager’s schedule and the maker’s schedule starts to be more widely understood, it will become less of a problem.

Those of us on the maker’s schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager’s schedule is that they understand the cost.

Text extracted from

IHOP is best than Starbucks

I used to always go to Starbucks to work and have a good coffee, but today I tried something different: IHOP and I am delighted for being open minded, because IHOP has a bigger table, a more comfortable seat, coffee refil, many types of meals and I don’t need to order at cashier.

In the IHOP the internet is good, but don’t have wifi in all IHOPs, you need to check first. The air conditioner is not too strong, because in Starbucks I almost freezing.

Starbucks has advantage in: more power jacks, more types of coffee, fast service, internet speed and more interaction with people.

The others characteristics are equals: good ambient music, good food and drinks, availability, parking, etc.

And you, what do you prefer?


Just as referencial, I am at this IHOP and I already gone to many Starbucks in Los Angeles.

Markdown and GitHub language, learn how to format your project README

What is?

It is a very simple markup language, which was created by John Gruber and Aaron Swartz has in its formatting codes converted to XHTML.

In Github you can adorn the README of your project by creating a README.markdown with the markings and automatically it will be interpreted and generated a valid XHTML and beautiful.

How to Use – Codes for Format

Turn any literal code, use ‘\’ (backslash) before: \ # or or \ *

# My Title
<h1>My Title</h1>
## My Subtitle
<h2>My Subtitle</h2>

###### My tiny title
<h6>My tiny title</h6>


Result: <em>text</em>


 Result: <strong>text</strong>


print_r (array ()); '
Result: <code> print_r (array ()); </ code>


> text
<blockquote> text </ blockquote>


[Click here to download the PDF] ( "Click and Download the PDF")
Result: <a href="" title="Clique and Download PDF"> Click here to download the PDF </a>


! [Here should appear a person icon] ( "Person")
Result: <img src = "" alt = "here should you see a person icon" title = "Person" />

Unordered lists

* 1 item
* 2 item
+ 1 item
+ Item 2
- Item 1
- Item 2



<li> Item 1 </ li>

<li> item 2 </ li>

Ordered lists

1. Item 1
2. item 2



<li> Item 1 </ li>

<li> item 2 </ li>

More information and formatting read the documentation

PHP library to make parsing files with Markdown formatting:

There are libraries for other languages:

Campus Party – TOP 10 checklist e dicas #CPBR


Depois de muitos anos (4 anos/edições) como campuseiro vi que preciso de um checklist para aproveitar melhor o evento e não passar por problemas, dificuldades, desconfortos. E aproveito para passar dicas para os novatos também.



  1. Ventilador, aquele pequeno usb de preferência. Porque a CPBR sempre acontece no final de janeiro, verão, com temperaturas maiores que 30 graus e a sensação térmica dentro do pavilhão pode chegar a 40 graus devido a quantidade de pessoas e máquinas ligadas. Pode ser comprado facilmente na Santa Efigênia.
  2. Roupa de cama e banho. Pois quem vai acampar precisa e só é fornecido a barraca.
  3. Colchão inflável ou colchonete, como já disse, só é fornecida a barraca.
  4. Cadeados para a barraca, pode ser aqueles de mala. Então quem trouxer o da mala já pode reaproveitar.
  5. Trancas de computador, notebook, laptop. Para poder deixar sua máquina na bancada sem se preocupar.
  6. Lanches e snacks. Itens não perecíveis como: salgadinhos, biscoitos, bolachas, toddynho, etc são sempre um alívio para passar a fome. Tem uma praça de alimentação mas os preços são mais caros que o normal. Para quem come muito recomendo que compre o pacote de alimentação (Catering) antes do evento, que conta com: café da manhã, almoço e janta. Mas também tem um restaurante dentro da campus com: self-service, pizzas e marmita.
  7. T de tomada ou régua de tomada.Tem muitos pontos de energia, mas você sempre vai precisar de mais um.
  8. Roteador Wireless ou switch. Tem muitos pontos de rede mas você vai precisar de mais. E o roteador Wireless é importante para os celulares, pois o evento só disponibiliza pontos de rede.
  9. Máscara de dormir para quem tem dificuldade de dormir com muita luz, pois o evento funciona 24h, as luzes não apagam nem no camping.
  10. Fone de ouvido, para ouvir seu próprio som ou para dormir, porque o barulho é 24h também.



  1. Chegue cedo no dia da abertura. Mesmo a abertura acontecendo somente à noite, os portões são abertos bem cedo. Então para conseguir uma bancada bem localizada e pegar menos filas é importante chegar cedo.
  2. Ir de caravana é bem legal, pois você faz vários amigos, racha o dinheiro do transporte e ainda tem comodidades dependendo da animação e organização da sua caravana. Fui 2 anos de caravana e vale muito a pena.
  3. Se você quiser assistir várias palestras ao mesmo tempo, sugiro que fique sentado na bancada e acompanhe pelo internet o streaming. Porque aí você consegue ver um pedacinho de cada e evita ficar correndo à toa.
  4. Fique ligado no twitter/instagram/facebook de todas empresas que estiverem na CPBR, pois eles estão lá para conquistar você como cliente e dar brindes. Eles organizam diversas brincadeiras e desafios, basta seguir para ficar por dentro.
  5. Registre seus equipamentos para diminuir as chances de roubos e furtos.
  6. Não se preocupe com a estrutura do banho, eles montam vestiários, com baias, porta sanfonada, chuveiro quente e penduradores. E os banheiros são do próprio local (pavilhão do Anhembi atualmente).
  7. Tem água de graça mas recomendo levar uma garrafa para reabastecer.
  8. Se você é friorento leve um casaco pois de noite dá uma esfriada.
  9. O traje é o que você se sentir melhor. A maioria fica com roupa de ficar em casa mesmo: bermuda, camiseta e chinelo. Mas pode usar seu estilo que a party é democrática, aceita todos os tipos.
  10. Tem um ônibus transfer do evento para o metrô, de 30 em 30 minutos.
  11. Cuidado com a fila na hora de ir embora. Porque tem que passar as malas pelo detector de metais e verificar os equipamentos de todos.
  12. E por final, se alguém gritar: OooOOoOOOoOouuuu!!! Responda imediatamente para fazer parte do coro. Ninguém sabe ao certo o motivo nem quem começou com isso, mas virou uma tradição.

Então é isso, se gostou compartilhae se tiver algo a complementar ou criticar, deixe sua mensagem aqui nos comentários.



Angular Material Design vs Polymer vs SB Admin Bootstrap

Neste post vou documentar minha pesquisa para a escolha da melhor biblioteca de web component, para um projeto web mobile, utilizando AngularJS.

Angular Material

O projeto Angular Material é uma implementação do Material Design em AngularJS. Esse projeto provê um conjunto de reutilizáveis, bem testados e acessíveis componentes UI, baseados no sistema Material Design. Similar à coleção Paper elements do projeto Polymer, Angular Material é suportado internamente pelo Google, pelo AngularJS, Material Design UX e outros times de produtos.

Esta opção é a que mais me agrada, visto que trabalha muito bem com o AngularJS, que já é certeza no projeto.


A biblioteca Polymer foi feita para tornar mais rápido e fácil, para os desenvolvedores, criar maravilhosos e reutilizáveis componentes para os navegadores modernos.

Em geral, ele foca no uso de componentes web. Cria elementos customizados e evolui tanto quanto a web evolui. Até o momento, só suporta as últimas versões dos navegadores modernos. Segue uma imagem que explica a arquitetura do Polymer.

Esta opção é um vislumbre das novas possibilidades que o HTML5 e os novos componentes web podem nos oferecer.


Ionic é um ótimo open source front-end SDK para desenvolvimento de apps híbrido mobile com tecnologias web como: HTML5, CSS e Javascript. Ionic é focado no “look and feel” e interações UI para um app. Atualmente utiliza AngularJS.

Porém, o Ionic está descartado do meu estudo, visto que o foco do meu projeto é web e ele, apesar de ter uma boa atuação web, é focado no mobile, por isso não garante perfeita execução nos navegadores web. Isto é dito na própria documentação do Ionic.

É provável que, em um futuro não tão distante, seja criada uma branch do projeto utilizando Ionic para uma versão totalmente mobile. Mas isso também depende do lançamento oficial do Angular 2.0 e outras decisões arquiteturais.

SB Admin 2

É um tema administrativo, painel de controle (dashboard), ou aplicação web UI, baseado em Bootstrap, juntamente com o poderoso plugin jQuery e funcionalidades herdadas.

Esta opção é a que menos considero, porque o Bootstrap está desgastado, mesmo que com uma grande comunidade e número de plugins e aplicações. Levando em consideração que o AngularJS é certeza no projeto e que ele sempre precisou de muitas adaptações/plugins/modules/gambiarras para que o bootstrap rodasse bem com ele, seria trabalhoso utilizá-lo. Se não existisse o Angular Material esta opção seria a minha favorita.

Então, qual a diferença entre Polymer e Angular Material?

Angular Material já está adaptado para trabalhar com AngularJS, utilizando diretivas e services. O Polymer é uma biblioteca para criação de componentes web personalizados. Angular Material utiliza a biblioteca Paper elements do Polymer, então, eles não são inimigos, são tecnologias amigas que caminham juntas, porém com um foco diferente.

Diretivas Angular vs Custom Elements

Polymer (mais especificamente Shadow DOM) provê a habilidade para compor JS, CSS e HTML encapsulado em componentes personalizados, assim como as diretivas AngularJS.

As diretivas Angular são conceitualmente similares aos Custom Elements, mas elas são implementadas sem o uso da API para componentes web. Diretivas Angular é uma maneira para construir elementos personalizados, e Polymer e a especificação de componentes web são os padrões-base de como fazer isso.

Similar ao AngularJS, Polymer Elements provê um template e bi-direcional data binding. Entretanto, eles também provêm funcionalidades como o Shadow DOM, que permite encapsulamento do CSS. Diretivas Angular não tem nenhuma noção de encapsulamento de estilo, mas é esperado que isto seja incorporado por uma eventual nova funcionalidade.

No futuro, ambos poderão ser usados conjuntamente. Porque custom elements serão o DOM, eles irão trabalhar sem problemas com frameworks como AngularJS. O time do AngularJS disse que eles irão eventualmente usar a API de Web components (custom elements, Shadow DOM, etc).


Utilizarei o Angular Material, pois, além de ter grandes qualidades do Polymer, ele tem o AngularJS por trás tornando-o mais forte e vivo por mais tempo. Nada é eterno, principalmente neste mundo da tecnologia, mas sabemos que um poderoso framework, mantido por uma poderosa organização (Google), sempre leva vantagem. E como o Angular Material já nasceu feito para o AngularJS, ele se destaca em relação ao Polymer. Contudo, acredito que em breve o Polymer seguirá o mesmo caminho e será uma ótima opção, juntamente com o Angular 2.0.

Angular 2.0 é outro assunto que precisa ser estudado, mas ainda é cedo para este projeto. De qualquer forma, deixarei links aqui no final para leitura complementar, casos se interessem.

“May the Force be with you”

Leitura complementar

Angular 2.0


REST e SOAP: Usar um dos dois ou ambos?

Desenvolvedores web têm uma grande quantidade de tecnologias que podem escolher, de ferramentas para acesso simples a bancos de dados, integração com serviços em middleware, a softwares do lado do cliente. A quantidade de opções em si já é um desafio, e escolher uma abordagem específica para construir partes de um aplicativo web exacerba o problema.

Neste breve artigo, vamos nos concentrar em uma dessas escolhas: SOAP ou REST. Ambas possuem vantagens e desvantagens e fica na mão do desenvolvedor determinar a melhor abordagem para cada caso em particular.

A maioria dos desenvolvedores tem exposto seus serviços utilizando REST, que faz uso de um padrão de URI (Uniform Resource Identifier), fazendo uma chamada para um serviço web como em:âmetros=xx

O REST é simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com suporte a HTTP/HTTPS. Os desenvolvedores que o utilizam citam, como principais vantagens a facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforço de aprendizado pequeno.

Por outro lado, o SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo. Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso. Além disso, a sigla SOAP deixou de representar “Simple Object Access Protocol”. Na especificação 1.2 da W3C, SOAP é apenas o nome da especificação.

Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens. Primeiramente o SOAP é baseado em XML, de três formas: o envelope, que define o conteúdo da mensagem e informa como processá-la; um conjunto de regras de codificação para os tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse “envelope” é enviado por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) é executada, e o envelope retorna com as informações do documento XML formatado.

Uma das vantagens do SOAP é o uso de um método de transporte “genérico”. Enquanto que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte existente para enviar sua requisição, desde SMTP até mesmo JMS (Java Messaging Service). No entanto, uma desvantagem percebida no uso de XML é a sua natureza prolixa e o tempo necessário para analisar o resultado apresentado.

A boa notícia para os desenvolvedores web é que ambas as tecnologias são muito viáveis no mercado atual. Ambos REST e o SOAP conseguem resolver um grande número de problemas e desafios na web, e em muitos casos tanto um como o outro podem ser utilizados para fazer o que querem os desenvolvedores.

Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural. Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas.

Pode-se afirmar, então, que casos onde o REST funciona bem são:

  • Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta.
  • Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa.
  • Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia.

Essas três situações abrangem muitas soluções. Então por que ainda precisamos considerar o uso do SOAP? Mais uma vez, o SOAP é bastante maduro e bem definido e vem com uma especificação completa. Já a abordagem REST é apenas isso: uma abordagem. Está totalmente aberta. Por isso ao se encontrar uma das situações abaixo, o SOAP pode ser uma ótima solução:

  • Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo o WSRM (WS-Reliable Messaging).
  • Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação.
  • Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui umaespecificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada.

Como se vê, cada uma das abordagens tem sua utilidade. Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web.

Portanto, a melhor abordagem é a flexibilidade, pois não importa qual seja o problema, no mundo de hoje do desenvolvimento web, conta-se com excelentes resultados ao fazer uso de um desses padrões.