R.I.P – Engenharia de Software

Atenção: Este é um post provocativo, então não se surpreenda com alguns argumentos radicais. O objetivo principal é gerar discussão e avançar a área de desenvolvimento de software.

Quando eu comecei a conhecer Engenharia de Software, era tudo lindo e maravilhoso. Eu li livros como o tradicional livro de Sommerville e toda aquela idea de fazer com que o  desenvolvimento de software chegasse mais perto das tradicionais engenharias fazia muito sentido para mim. Com isso, “ganhamos” o nome de Engenharia de Software.

Quem não lembra (ou vive no seu dia-a-dia) todos aqueles conceitos como gerenciamento de riscos, gerenciamento de mudanças, gerenciamento de projectos, gantt charts, gerenciamento de requisitos, mil e um diagramas UML, etc, etc??

Desenvolvimento de Software deixou de ser uma coisa artesanal para ser uma coisa um tanto quanto burocrática. E o que acontece quando se vira burocrático demais? Sua capacidade de reagir ao que seus clientes querem vai gradativamente diminuindo.

( Nesse momento é importante fazer uma observação para explicar que existem determinados domínios de aplicações que precisam de um controle e burocracia maior do que outros. Um software embarcado que é safety-critical precisa naturalmente de um controle e rigidez maior no seu desenvolvimento. No entanto, uma aplicação web que pode ser deployed muitas vezes ao dia e não um impacto muito grande pode muito bem ser desenvolvida sem maiores burocracias )

Bom, um grupo de pessoas já chegaram a essa conclusão lá em 2001 e eles fizeram nascer uma coisa chamada Manifest Ágil! Esses caras entenderam que existem coisas mais importantes no desenvolvimento de software do que seguir todo o conhecimento que (ainda hoje) tentamos adiquirir de outras disciplinas. Que saber porque??

Porque [praticamente] todo software é SINGULAR!!

Nas outras engenharias é claro que existem desafios, mas a maioria dos projetos como construir um ponte, ou uma casa, ou um carro é um conhecimento estabelecido. E uma vez contruido/montado o primeiro carro (que por sinal, provavelmente vai demorar mais do que os demias), se segue exatamente o mesmo processo para montar os proximos duzentos mil.

No mundo do software, a diferença é que [praticamente] todo software é Singular, [praticamente] todo software é igual ao primeiro carro que precisa ser construido. [praticamente] Todo software é único. Cada linha de código, cada classe, cada método, cada framework. Algumas coisas contribuem para isso como, por exemplo, a velocidade que surgem novas tecnologias, novas linguagens de programação, novos frameworks javascript (os frontend developers sabem do que estou falando).

O post vai ser finalizado com algumas perguntas, que podem gerar debates interessantes….

Levando em consideração que [praticamente] todo software é NOVO, faz realmente sentido tentar se parecer mais e mais com as engenharias tradicionais? Ou deveríamos achar qual é o caminho que faz mais sentido para o desenvolvimento de software  (a depender da área de aplicação?

Deveríamos nos livrar do nome Engenharia de Software? Ou faz sentido tentar se beneficiar de conceitos já estabelecidos nos outras engenharias?

Deixa aí teu comentário sobre esse tópico 😉

Chave Estrangeira e Integridade Referencial é coisa do passado?

Praticamente todo mundo do mundo já estudou bando de dados e ouviu falar sobre chaves estrangeiras e integridade referencial. Se você nunca ouviu falar nisso, páre de ler agora e vá procurar ler algo sobre esse assunto. Não quero entrar em detalhes sobre o que é integridade referencial, mas aqui vai uma definição básica da wikipedia:

Num banco de dados relacional, quando um registro aponta para o outro, dependente deste, há de se fazer regras para que o registro “pai” não possa ser excluído se ele tiver “filhos” (as suas dependências).

O relacionamento é feito através das chaves estrangeiras das tabelas, avaliadas antes da execução do comando de delete, insert ou update.

O grande objetivo de manter a integridade referencial, é evitar a presença de registros no banco de dados que tenham relação com registros que não estão mais no banco de dados (porque foram apagados ou qualquer outro motivo). Manter a consistência e integridade dos dados. Faz muito sentido, por qual razão alguém gostaria de ter dados inconsistentes?? è importante lembrar que integridade referencial e normalização de banco de dados são conceitos que andam lado a lado. Uma vez que normalizamos, precisamos “espalhar” os dados em lugares (tabelas) diferentes e aí não queremo que os dados fiquem inconsistentes.

Tudo bem até aí, mas agora entra em cena o choque de realidade que 2 outros conceitos trazem consigo:

  • Banco de dados NoSql
  • Arquiteturas baseadas em Micro-Serviços

Vamos tratar um de cada vez, começando com NoSql e uma descrição simples (retirada da wikipedia)

NoSQL (ás vezes interpretado como Not Only SQL – Não Somente SQL) é um termo genérico para uma classe definida de banco de dados não-relacionais que rompe uma longa história de banco de dados relacionais com propriedades ACID.

Quem conhece sabe que (em especial os banco de dados document based) armazenam os dados de forma “nao-normalizada”, o que significa que os dados estão menos “espalhados”, e consequetemente existem menos relações entre registros armazenados no banco dados. Obviamente, se existem menos tabelas e menos relações, também pode existir mais duplicação dos dados armazenados.

Ainda assim, é preciso existir relações entre os registros (ou documentos), e para isso, ao invés de fazer a relação baseada em chaves estrangeiras, podemos usar simplesmente uma URI (de uma determinada API). Agora preste atenção, esse é um ponto chave desse post. Se a relação entre um registro e outro é baseada em uma URI/URL (que vai levar a outro resource), esse outro resource pode não estar armazenado no mesmo banco de dados, inclusive pode incluse estar em outro servidor, em outro lugar do mundo. Nesse caso, chaves estrangeiras não ajudariam. E agora faremos a ponte entre os 2 conceitos que mencionamos anteriormente: Micro-Services.

Para começar, uma breve descrição do que seria micro serviços (retirado deste site):

O termo “Arquitetura de Micro-serviços (Microservice Architecture)” surgiu nos últimos anos para descrever uma maneira específica de desenvolver software como suites de serviços com deploy independente. Embora não exista uma definição precisa desse estilo de arquitetura, há certas características comuns em relação à organização, à capacidade de negócios, ao deploy automatizado, à inteligência nos terminais e ao controle descentralizado de linguagens e de dados.

Como em quase todas as coisas, se você aplicar o conceito do “divide and conquer”, é melhor e mais gerenciável ter algumas/várias partes pequenas do que uma só grande parte. Seguindo essa linha de raciocínio, as arquiteturas baseadas em serviços, caminham na direção de micro serviços. Seriam partes que teriam um deploy independente, potencialmente em servidores independentes e que se comunica com outras partes da sua arquitetura por meio de uma RESTfull API.

Tudo bem, e qual é a conclusão?

Levando em consideração essa tendência, que diferentes partes do sistema podem estar em servidores/banco de dados diferentes, não faz sentido sentido controlar a integridade referencial com chaves estrangeiras no nível do banco de dados como estamos acostumados e estudamos nas universidades. Esse controle tem que ser em um nível acima do banco de dados.

Claro que chaves estrangeiras ainda tem seu lugar, e são muitíssimo indicadas para solucionar/arquitetar determinados problemas. Contanto, com o mundo da computação ficando cada vez mais e mais distribuído, nossas queridas chaves estrangeiras como conhecemos não são mais suficientes em todos os casos.

Tudo bem, e como controlar a integridade referencial nesse novo cenário?

Existem algumas opções, algumas muito simples, mas talvez não solucionem seu problema. Uma delas é, simplesmente não se preocupar com isso (ok, eu concordo que é meio ridículo). Outra é, em um nível de abstração acima dos banco de dados e servidores, ter um serviço específico para fazer o controle, o que pode se tornar uma tarefa dificílima e passível de erros também. Então, se você precisa de uma solução em que os dados estão espalhados, e a integridade é absolutamente essencial e vital, você deveria estar usando bancos relacionais e serviços mais centralizados em minha opinião.

“Eu não concordo com você”

Então meu amigo, deixe um comentário falando como você resolveria esse problema 🙂 Eu vou ficar mais do que feliz de ler e possivelmente incorporar tua solução no texto desse post.

GRASP – Coisas que todo programador deveria saber

the-thinkerEsse é o segundo post do BdB (Bytes don’t Bite) da série “Coisas que todo programador deveria saber”. Caso você tenha perdido o primeiro post, nele eu falei sobre os princípios de design de software chamado SOLID e você pode acessar esse post aqui (Não se preocupe pois a leitura do primeiro não é pre-requisito para esse post).

O foco do segundo post é sobre o GRASP, que é algo desconhecido para muita gente, mas é também muito importante. GRASP não é uma ferramenta, não é uma metodologia, não é um software, não é um plugin nem nada do tipo. De forma similar aos princípios do SOLID, o GRASP é um conjunto de conceitos que ajudam na hora de pensar no design do software, em como suas classes estarão estruturadas e relacionadas, onde cada operação vai ser implementada, etc.

Craig Larman escreveu no seu livro (mesmo livro onde ele descreve o GRASP), uma frase interessante:

“the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology.”

Quando eu vi essa frase eu já me identifiquei, pois reflete o que eu penso também. UML não vale de nada se você não souber como estruturar (design/architecture) o seu sistema. Se você não sabe como fazer um design bem feito, UML vai se resumir a uma ferramenta de desenho, como o paintbrush. Isso só faz reforçar a importância de princípios e padrões como o SOLID e o GRASP.

Como disse antes o GRASP é um conjunto de princípios e padrões para design de software, e nesse post eu vou cobrir alguns desses princípios/padrões que acho relevantes. Então vamos lá:

  1. High Cohesion (Alta Coesão) e Low Coupling (Baixo Acoplamento): Esses 2 pontos merecem ser tratados juntos, pois estão sempre de mãos dadas. A idéia central aqui, é diminuir as dependências entre as classes, de forma que uma mudança em uma classe não afete muitas outras. E a melhor forma de fazer isso é separando as responsabilidades de cada classe, dessa forma aumentando a coesão. Quanto mais coisas não relecionadas uma classe faz, menos coesa essa classe é. O resultado de uma alta coesão e um baixo acoplamento é que suas classes e componentes vão ser mais reusáveis.
    (Esse ponto também está relacionado com um dos princípios do SOLID)
  2. Creator: Quem deve ser o responsável por criar uma instância de uma classe X? Essa pergunta as vezes pode parecer fácil, mas se você der uma resposta errada, você começa a ferir outros pontos importantes como o acoplamento e coesão discutidos no ponto anterior. Esse padrão lista algumas dicas para responder essa pergunta. Geralmente a classe Y responsável por instanciar objetos da classe X deve ser sob as seguintes condições (quanto mais melhor) : (i) Classe Y contém ou é composta por X (ii) Classe Y usa extensivamente classe X (iii) Classe Y possui todas as informações necessárias pra instanciar X (e aqui está um ótimo link para falarmos sobre o próximo ponto, que talvez seja um dos mais importantes na minha opinião).
  3. Information Expert: Como saber quais responsabilidades atribuir a quais classes? A resposta é simples, mas é preciso ter essa resposta sempre em mente se quiser definir o design de seu sistema de forma satisfatória e elegante. A resposta é: A responsabilidade de uma determinada operação, deve ser da classe que tem todas as informações necessárias para completar aquela operação. Se você tiver isso sempre em mente, fica fácil saber em qual classe você vai implementar determinado método, qual classe vai conter um determinado atributo, e qual classe vai ser responsável por instanciar uma outra classe (aqui está o link de volta para o ponto 2 “Creator”)
  4. Indirection: Esse princípio prega que, de forma a diminuir (ou evitar) o acoplamento entre duas entidades quaisquer, a melhor forma é atribuir essa responsabilidade a uma entidade intermediária. Alguns design patterns se baseiam nesse princípio, como por exemplo: Adapter, Bridge, Façade, Observer, etc.
  5. Controller: Uma aplicação clara do princípio de Indirection, é o Controller. De quem é a responsabilidade de diminuir (ou evitar) o acoplamento entre os dados (model) e sua representação (view)?? Resposta clara, Controller 🙂 Não quero explicar o que é um Controller, mas queria chegar nesse ponto só para ficar claro a relação dos padrões e como um ponto impacta e afeta os outros. No final estão todos conectados!

Esse foi o segundo capítulo da série “Coisas que todo programador deveria saber”. Se você gostou, e gostaria que essa série continuasse, deixe um comentário aqui ou compartilhe esse post com seus amigos que você sabe que acharia útil essa informação.

Qual o FUTURO da computação nos países ricos?

Enquanto dirigíamos para uma high school no estado de Iowa nos Estados Unidos, escutei de um engenheiro de sotware americano (muito compentente por sinal) sobre um fenômeno que estava acontecendo nos USA que me deixou pensativo. O motivo pelo qual estávamos indo para a high school era porque a empresa onde eu trabalho participa de um projeto social onde os engenheiros de software experientes da empresa fazem uma espécie de “aula” e acompanham os estudantes em tópicos relacionados a TI, numa tentativa de despertar a curiosidade desses alunos por computação, desenvolvimento de software e afins.

Voltando ao assuto que tinha me deixado pensativo, aquele 8213e2b9121b11c16d18a02e2899d724engenheiro me falou que as pessoas que prestavam aconselhamento vocacional para as crianças/adolescentes nas escolas, muitas vezes estavam com um discurso que não valia a pena escolher computação, especialmente se for para enveredar em desenvolvimento de software. O Motivo? Simples demais. Pra que você vai ser programador/tester/etc se as empresas nos países ricos e desenvolvidos estão cada vez mais transferindo o desenvolvimento para países onde a mão de obra é mais barata (seja terceirizando ou abrindo filiais nesses países)? Isso é um fato, não existe dúvida que isso está acontecendo. Países como a Índia já estão cheios de centros de desenvolvimento de software, e a matemática é simples: Para que contratar um desenvolvedor/tester na Alemanha (por exemplo) se é possível contratar 4 ou 5 na Índia pelo mesmo valor?

Claro que existem diversas questões atreladas a isso, como por exemplo se realmente vale a pena, questões relacionadas com a qualidade do produto final, questões relacionadas com como gerenciar o desenvolvimento geograficamente espalhado, como coordenar da melhor forma e assim por diante. Não quero entrar nos detalhes dessas questões, quero me ater ao fato de que isso está acontecendo, e cada vez mais.

Gostaria de deixar aqui algumas reflexões:

1) Antes eu pensava [e ainda hoje penso] que seria ótimo se meus filhos seguissem o caminho da computação, mas agora, estou pensando se realmente é isso que quero para o futuro deles. Será que você também aconselharia seu filho a fazer computação, ou seria melhor algo que não pudesse ser facilmente transferível para a Índia (ou qualquer outro lugar no mundo onde seja mais barato)? Estou honestamente pensativo sobre isso… acho que essa reflexão é válida.

2) Outra reflexão válida, é se o nosso Brasil vai virar uma Índia nesse sentido. Não sei até que ponto o nosso “Custo Brasil” permite que isso aconteça, mas o fato é que temos recursos humanos excelentes em TI… será?

3) Essa terceira reflexão, vai de encontro com a reflexão número 2. Nessa aqui, eu coloco o Brasil como um país “rico”, pelo menos no que diz respeito a terceirizar os serviços de TI e contratar países onde os serviços sejam mais baratos. Nesse caso, o ponto 1 começaria a fazer sentido também para os brasileiros. E aí, o que vocês acham?

S.O.L.I.D – Coisas que todo programador deveria saber

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Pensamentos sobre a aquisição da Motorola pela Lenovo

bntf9wjceaaoico-jpg-large

Para aqueles que ainda estão assimilando essa aquisição, se pensarmos bem, essa aquisição da Lenovo faz muito mais sentido do que a aquisicao da Nokia (comprada pela microsoft ano passado).

 Motorola mobility é uma empresa em ressurgimento[ou ressurgida] (depois de apostar pesado no android, fato esse que fez o google comprar em primeiro lugar). Enquanto a nokia, é uma empresa afundando (ou seria melhor dizer afundada? Mas também dá pra entender a sua aquisicao pela Microsoft, uma vez que a MS precisava de alguem pra usar o windows phone como plataforma principal, e só uma empresa “afundada” iria topar :P)
A moral da história é que quem quer entrar pesado pra competir com apple e samsung nao tem muita escolha, e a motorola podia ser considerada uma escolha clara ao meu ver. (ninguem vai apostar na tb afundada blackberry,  ou HTC, etc, etc… )
E o que você acha? Faz sentido pra você essa aquisição?
O mercado android x iOS x Windows Phone continua quente e tende a esquentar mais ainda!

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Privacidade na web! Será que existe?

Ao meu ver existem dois pontos relativos a privacidade pessoal na web que devem ser levados em consideração:

  1. Nós estamos escancarando cada vez mais nossas informações na internet (principalmente através das redes sociais). Nossos dados, opiniões, relações, fotos, desejos, gostos, etc! Está tudo nos facebooks, twitters, youtubes,  google+, amazon (suas compras e seus hábitos de compras), etc. Essa informação é facilmente encontrada por qualquer um, e ela por si só já é perigosa. Precisamos ter muito cuidado.
  2. Mas adianta ter cuidado?? Até as coisas que não abrimos para o mundo todo, como nossos emails ou nossas conversas via voz no skype, estão sendo (podem ser) devidamente analisadas e acompanhadas por entidades superiores. E o que nós podemos fazer diante disso? No momento nada…

O ponto 1 acima é algo que precisamos aprender a conviver e aprender com tempo. Mas o ponto 2, é algo inadmissível que precisa ser mudado e precisamos criar formas na web onde não fiquemos nas mãos desses “magnatas da informação”. Recentemente essa questão de espionagem atingiu a mídia do mundo inteiro com o caso Snowden. Recentes relatos mostram como essas “magnatas da informação” ajudam (e podem ajudar) o governo dos EUA a espionarem e bisbilhotarem a privacidade alheia. Microsoft (outlook e skype), Google (principalmente youtube e gmail), etc são somente alguns exemplos de “magnatas” que tem “nossas vidas” nas mãos deles.

E agora? O que fazer?

Minha previsão sobre isso tudo é que, a longo prazo, essas magnatas vão modificar a forma como implementam seus serviços para uma forma mais “descentralizada” da informação (aonde as empresas magnatas não terão poder e domínio sobre todas as informações). Mas isso é uma coisa difícil de acreditar e ainda mais difícil de checar se é realmente acontece o que as magnatas dizem que acontece.

Então a possibilidade mais tangível ao meu ver (uma vez que as pessoas amadureçam como usuários da internet) é que vamos gradativamente parar de utilizar serviços e sistemas dessas magnatas e migrar para soluções descentralizadas que serão mais seguras (apesar de não serem lá tão maduras ou bonitas como as soluções das magnatas). Esses serviços e soluções provavelmente usarão tecnologia P2P (peer-to-peer), ou algo mais avançado que ainda não conhecemos. Soluções aonde a informação seja descentralizada e seja de todos, regulamentada e protegida por todos, ao invés de somente por uma empresa “dona” dos dados. Soluções assim já são realidade hoje em dia, e um exemplo muito bom é o do BitCoin (leia aqui se você não conhece o bitcoin).

A outra possibilidade é comprar máquinas de escrever ao invés de usar computadores 🙂 A Rússia já está fazendo isso para produção de documentos confidenciais (veja aqui isso)

Temos que lembrar que a humanidade toda é um bebê no mundo da web, e precisamos começar a amadurecer, crescer, abrir os olhos e parar de engatinhar… Caso contrário, temos que continuar aceitando calados os pontos 1 e 2 que citei acima.

Como reduzir o tempo gasto em testes?

Teste é sempre um gargalo! Não dá pra estimar quanto tempo é gasto em testes (e certificação),  mas algumas fontes mostram que cerca de 50% do esforço para desenvolver um produto é gasto em testes. Com esse dado, e o senso comum de quem trabalha com desenvolvimento de software, teste de software se torna um excelente alvo para ser estudado com o objetivo de se reduzir o tempo gasto.

Obviamente, muitos estudos já foram feitos nessa direção, e nesse post vamos falar um pouco sobre um artigo que realizou um mapeamento sistemático com o objetivo de identificar todos os trabalhos existentes (acadêmicos) que tratam sobre redução de tempo e esforço de testes. O artigo, publicado em 2012, tem como título “Reducing test effort: A systematic mapping study on existing approaches” e pode ser encontrado aqui.

Primeiramente, é claro que poderíamos reduzir o esforço de testes simplesmente tendo menos testes, mas é claro que reduzir a qualidade do produto final é inadmissível, principalmente quando tratamos de sistemas críticos e safety-relevant.

Diante disso, o artigo identificou 5 categorias que se propõem a diminuir o esforço gasto com testes (consequentemente diminuindo o tempo também na maioria das vezes). As cinco categorias são:

  • Test Automation – 50% dos estudos identificados nesse mapeameanto sistemático abordam essa categoria. Isso não é surpreendente pois automatizando testes muito tempo consegue ser economizado.
  • Prediction – 28% dos estudos abordam predição, no sentido de dar suporte a decisões sobre quanto esforço de teste precisa ser gasto para um dado sistema e como distribuir esse esforço entre as diversas atividades.
  • Test input reduction – 15% dos estudos abordam essa categoria, com o intuíto de ajudar da seleção e priorização  de test cases (essa categoria também é conhecida como redução de suítes de teste)
  • Quality assurance (QA) before testing – Essa categoria (encontrada em 5% dos estudos) lida com atividades executadas antes dos testes propriamente ditos e que ajudam a reduzir os testes. Essas atividades são: análises estáticas, inspeçoes e revisões.
  • Test Strategies – Essa categoria (encontrada em 2% dos estudos) aborda pontos  como a seleção de diferentes técnicas de teste e também seleção de diferentes níveis de teste para economizar tempo e esforço.

É claro que esses pontos são focados em estudos acadêmicos, e que nos projetos reais da vida real podem existir outras abordagens para reduzir esforço dos testes. Você usa/conhece alguma abordagem? Compartilhe conosco 🙂

Vou cancelar minha conta do facebook… quer saber o(s) motivo(s)?

Quem me conhece ou acompanha alguns dos meus posts vai ver que o Facebook para mim é uma questão meio complicada. Quem acompanha o BdB também já deve ter visto alguns posts meus reclamando a respeito do facebook. Se quiser entender melhor esse post você pode primeiramente ler esses outros aquiaqui e aqui. Caso não

67037_474539079272861_1104199120_nqueira ler os posts antigos, tudo bem, você pode começar a ler por aqui mesmo.

Nem todos vão concordar com meus argumentos
Queria começar esclarecendo que o que estou falando aqui reflete apenas a minha opiniao sobre o assunto. Entao todos os pontos de vista sao pessoais, e nao refletem a opinao do blog.  A grande maioria dos argumentos aqui são a respeito de como utilizar da melhor forma e também o motivo pelo qual você utiliza. Provavelmente, algumas pessoas vão odiar esse post, outras pessoas vão se identificar, e outras até vão parar de ler antes de chegar nesse ponto.

Queria também ressaltar que meu objetivo com este post nao é fazer com que você cancele sua conta do facebook, mas talvez que você reflita um pouco sobre sua utilizacao e sobre os pontos que vou falar 🙂

O facebook tem muitos pontos positivos…
e ponto final! Sei do poder como ferramenta de rede social que é, a quantidade de dinheiro que movimenta através de seus anúncios, etc. Sei que cada vez mais criamos grupos, e até disciplinas de faculdade e assuntos mais “sérios” sao tratados e discutidos dentro do facebook. Além disso como ferramenta de marketing e divulgacao ele é espetacular. O próprio blog (Bytes Don’t Bite) tem uma página no facebook para divulgacao dos posts, e vai continuar tendo, pois é um ótimo canal de comunicacao. Talvez até, o facebook seja o bode expiatório no meu caso. E o cancelamento da minha conta simplesmente uma atitude em direcao ao movimento de DESCONECTAR-SE! Mas vamos aos motivos do cancelamento.

1- Meu tempo é muito precioso, aliás, o seu também é…
Acredito que todos nós temos vontade de investir nosso tempo em coisas que regularmente não fazemos como indivíduos (como ler mais livros, fazer exercícios, aprender uma nova lingua, aprender uma nova tecnologia, estudar para um concurso, etc…), e também como coletividades que somos (dar mais tempo para seus pais, mais tempo para seus filhos, para seus irmãos, se importar com os outros, fazer mais favores, escutar as pessoas, conversar, etc…).

Tudo isso demanda tempo, mas só temos 24 horas no dia, e visitar alguém ou algo do tipo pode tomar muito tempo. Conversar com seus amigos, fazer uma ligacão, mandar um email,  toma muito tempo. No entanto, gastamos uma quantidade CONSIDERÁVEL de HORAS no facebook diariamente (é óbvio que isso não vale para todo mundo, mas tem uma quantidade absurda de pessoas que vão se identificar).

Eu decidi que: Quero dar mais tempo para minha família, meus amigos, para as pessoas e para meus projetos pessoais.

2- A mudança de valores que vem junto com uma “curtida do facebook”…
Sabe aquela sensação que tínhamos antigamente quando recebíamos uma carta? Era muito legal, você sabia que alguém (que provavelmente se importava o suficiente com você para isso) tinha gastado o tempo dela para escrever algo para você. Tudo bem que o email veio ao mundo,  e substituiu praticamente por completo essa situação descrita a pouco. Mas, ainda hoje, a sensação de receber um email (destinado a você somente) é algo muito precioso (pelo menos para mim) e ainda dá uma sensação de satisfação muito grande.

É muito bom quando comentam e curtem nossas fotos e status no facebook. É legal ver que muitas pessoas curtem, e muitas dessas pessoas realmente se importam com conosco, se preocupam conosco, e procuram fazer com que a relacao de amizade vá além de um curtir. No entanto, para muitas outras pessoas aquele curtir é um resumo da relacao que se tem, a “consideração” que muitos demostram uns ao outros, hoje é um simples CURTIR na sua foto/status.

Eu decidi que: Não vou demonstrar minha amizade e meu carinho por alguém utilizando um simples curtir. Quero fazer a diferença na vida de verdade, e não no facebook.

3- Fora do facebook vamos perder muita coisa que acontece no dia-a-dia…
Primeiramente queria dizer que não tenho NADA importante acontecendo no facebook.

Além disso, eu possuo telefone celular, telefone fixo, email, whatsapp, linkedin, instagram, twitter, foursquare, skype, facetime, blog, slideshare, pinterest, etc… Isso que significa que se alguém quiser verdadeiramente entrar em contato comigo, não é pelo fato de eu não ter facebook que essa pessoa não vai conseguir entrar em contato.

Caso alguma delas tome mais meu tempo do que eu gostaria eu simplesmente vou cancelar minha conta também, ou pensar em alternativas que minimizem o problema.

Eu decidi que: Tudo que tirar meu tempo e não trouxer benefícios muito claros para mim eu vou tirar da minha vida.

4- Roda de amigos, todos eles de olho no celular…stock-footage-two-female-friends-with-mobile-phone-in-bar-outdoors-camera-stabilizer-shot
É muito triste ver isso, mas a gente faz parte disso e faz isso sem sentir. As pessoas são os bens importantes que temos na vida, e ainda assim estamos ao lado delas (nossa familia, amigos, etc) e simplesmente abaixamos a cabeça para checar e responder as notificações do facebook (ou qualquer outra app) no celular a cada 10 minutos. Ou simplesmente trocamos uma conversa real, para responder conversas virtuais no celular. Por esse motivo eu já tenho desinstalado o facebook do meu celular a um bom tempo, e não me arrependo nem um pouco. Talvez outras apps, como whatsapp, também sejam o motivo de trocarmos conversas e relacoes reais por virtuais.

Eu decidi que: Quando estiver com pessoas, não quero que o celular tenha maior atenção que as próprias pessoas

5-O facebook amplifica o alcance das nossas opinioes e pensamentos… Boas ou ruins…
Neste ponto, eu vou  usar um texto que li em um blog da Luciana Honorata nesse link e achei muito bom, e reflete exatamente o que penso sobre esse ponto.

“Antigamente, quando não havia internet, “todo mundo” ficava sabendo das catástrofes. Os desastres naturais, os acidentes aéreos, a enchente não sei de onde, o assassinato de Daniela Perez, a morte de Ayrton Senna… Todo mundo chorava, lamentava, comentava e criticava. As pessoas tinham suas opiniões formadas, mas elas ficavam restritas ao seu círculo social. Vizinhos, família, colegas de trabalho. Caso tivessem um comentário infeliz a fazer, deixavam uma marca negativa em seis, sete pessoas, e quando muito, (sendo bem pessimista) 20 ou 30 desafortunados os ouviam, mas isso não causava um efeito tão devastador na imagem de um grupo quanto nos dias de hoje. 

A internet, entretanto, facilitou a comunicação de um modo que potencializou o poder de influência das pessoas. Sites, blogs e redes sociais massificaram a opinião, e agora todo mundo diz o que pensa quando quer e bem entende sobre qualquer coisa, não na mesa do restaurante, para um público que se pode contar nos dedos da mão, mas para milhares de indivíduos, simplesmente quando decide responder ao sr. Facebook ‘ O que você está pensando?’ “

Como ela falou, sempre fomos desse jeito que somos agora,  a única diferenca é o alcance das nossas opinoes e comentários. Entre o pensamento e o teclado, acredito que exista uma distancia menor do que entre um pensamento e a boca. Agora temos “coragem” de escrever qualquer coisa no facebook. Coisa que nao teriamos “coragem” para dizer cara a cara com alguém, mas é tao fácil simplesmente escrever no facebook. É muito comum pessoas reclamando de TUDO, e “metendo o pau” em todo tipo assunto possível. É comum ver opinioes de pessoas que você nunca conhecia antes, e nao por nao terem tido contato suficiente, mas simplesmente porque o nível de “coragem” dessas pessoas ao publicar algo no facebook é muito alto. Diferentemente de uma conversa cara a cara.

Além disso,  a “coragem” aumenta pelo fato de nao precisarmos nos preocupar com o impacto de algo que falamos, quem nao gostou do que você falou que lhe bloqueie.

Eu decidi que: Quero evitar falar “besteiras” e “reclamacoes” para um público de milhares de pessoas sem me preocupar com o alcance real dessas palavras e com as consequencias disso. E nas redes sociais que ainda continuar participando quero ter cuidado com o que falo, e contar até 10 antes de compartilhar, postar, responder, rebater, curtir, etc.

7- E a privacidade?
Repare que eu ainda nao toquei no ponto da privacidade, que por sinal é muitíssimo discutido. Privacidade é algo que nao me preocupa muito pois ninguem é forcado a usar o facebook (ou qualquer outra rede social). Entao existe uma opcao simples para escapar dos problemas de privacidade do facebook: Parar de utilizar! Cancelar sua conta. Mas…. se você quiser utilizar e ainda assim manter um nível bom de privacidade você vai ter problemas sim, tenho certeza. Nao consigo pensar em nada na web que exponha tanto sua vida pessoal com o facebook. Se tiver algum outro servico ou app ou qualquer outra coisa que exponha tanto ou ainda mais que o facebook por favor me avisem.

6- Porque ainda daqui a 10 dias somente que vou cancelar minha conta no facebook?

O motivo disso é simplesmente porque pode ser que eu esteja errado, então se alguém me der motivos fortes o suficiente para não cancelar, eu posso até mudar de idéia. É importante salientar também que se eu julgar que por algum motivo o facebook é uma parte integral da minha vida que eu não posso viver sem ele eu simplesmente reativo minha conta (mas eu espero de verdade que isso não aconteça).