Restaurando o Eclipse após crash

Restaurando o Eclipse após crash.

Quem nunca se deparou com um crash dos projetos do Eclipse após uma queda de energia ou após um travamento do Sistema Operacional onde é necessário desligar a máquina na "força-bruta".

Em alguns casos após esse crash da máquina, ao tentar restartar o Eclipse o mesmo trava no momento do startup.

Uma das formas de resolver esse problema é deletando os arquivos "*.snap" existente dentro do diretório ".metadata/.plugins/org.eclipse.core.resources".
Caso não resolva, é possível apagar esses mesmos arquivos "*.snap" de todos os demais projetos utilizados.

Como alternativa, utilizar o comando abaixo no Linux (terminal):
find .metadata/.plugins/org.eclipse.core.resources/.projects -name "*.snap" -exec rm -f {} \;

Laboratório Secreto do Google relembra seriado Jetsons

Em um laboratório secreto em local não revelado da Bay Area (Califórnia) onde robôs correm livremente, o futuro está sendo imaginado.

É um lugar no qual seu refrigerador pode estar conectado à internet e encomendar legumes quando o estoque estiver baixo. A louça do jantar pode postar informações sobre o cardápio de uma refeição nas redes sociais. Um robô pode substituí-lo no escritório enquanto você fica em casa de pijamas. E você talvez possa subir de elevador ao espaço sideral.

Esses são apenas alguns dos sonhos que estão sendo perseguidos no Google X, o laboratório clandestino no qual o Google trabalha em uma lista de cem ideias ambiciosas. Cerca de uma dúzia de pessoas discutiu essas ideias em entrevistas; algumas trabalham no laboratório ou outras áreas do Google e estão informadas sobre o projeto. Mas nenhuma permitiu que seu nome fosse mencionado, pois o Google é tão sigiloso sobre o projeto que muitos funcionários nem sequer sabem que o laboratório existe.

	Divulgação/Google
	Eric Schmidt, Larry Page, Sergey Brin (da esq. para a dir.) e o carro sem motorista desenvolvido pelo Google

Embora a maioria das ideias na lista esteja em estágio conceitual e nada próximas de se concretizarem, duas pessoas informadas sobre o projeto revelaram que um produto do laboratório seria lançado antes do final do ano, mas elas não revelam do que se trata.

"Eles estão trabalhando em ideias bem excêntricas", disse Rodney Brooks, professor emérito de ciência da computação e inteligência artificial no MIT (Instituto de Tecnologia de Massachusetts) e fundador da Heartland Robotics. "Mas o Google não é uma companhia convencional, e por isso os critérios usuais não são aplicáveis."

Na maioria das empresas do Vale do Silício, inovação significa desenvolver aplicativos ou formas de publicidade on-line, mas o Google se vê como diferente. Agora que ele se tornou uma grande empresa, sob ataque de novas companhias criadas nos últimos anos, o laboratório reflete a ambição da empresa em continuar a ser um polo de pesquisa e desenvolvimento inovadores, semelhante ao Parc (Centro de Pesquisa de Palo Alto), da Xerox, que desenvolveu o computador pessoal em sua forma moderna, nos anos 70.

Jill Hazelbaker, porta-voz do Google, se recusou a comentar sobre o laboratório, mas afirmou que investir em projetos especulativos é parte importante do DNA do Google. "Embora as possibilidades sejam incrivelmente inspiradoras, por favor tenha em mente que as somas envolvidas são pequenas em comparação ao investimento que fazemos em nossos negócios centrais."

No Google, que utiliza técnicas de inteligência artificial e aprendizado de máquinas em seu algoritmo de busca, alguns desses projetos extravagantes podem não ser tão absurdos quanto pareceriam à primeira vista, mesmo que estejam bem distantes das operações de busca on-line que representam a atividade primária da empresa.

Por exemplo, elevadores espaciais, uma fantasia antiga dos fundadores do Google e outros empreendedores do Vale do Silício, podem recolher informações ou transportar objetos ao espaço. (Em teoria, eles envolveriam viagens espaciais sem foguete, por meio de um cabo ancorado na Terra.) "O Google está coletando todos os dados disponíveis no mundo, então agora poderia estar recolhendo dados sobre o Sistema Solar", disse Brooks.

	Noah Berger/The New York Times
	Os pesquisadores do Google Sebastian Thrun (dir.) e Peter Norvig na sede da empresa, em Mountain View

Sergey Brin, cofundador da companhia, está profundamente envolvido no trabalho do laboratório, disseram diversas pessoas que conhecem os projetos, e foi o criador da lista de ideias, com ajuda de Larry Page, o outro fundador do Google (que trabalhava no Google X antes de se tornar executivo-chefe da empresa em abril), Eric Schmidt, o presidente do conselho, e outros importantes executivos. "Dedico meu tempo a projetos ambiciosos, que espero venham a se tornar importantes negócios-chave no futuro", disse Brin recentemente, sem mencionar o Google X.

O Google pode transformar uma dessas ideias --os carros sem motorista que testou em estradas da Califórnia no ano passado-- em um novo negócio. Como não considera que as montadoras de automóveis de Detroit tenham espírito inovador, o Google está considerando a possibilidade de fabricar esses veículos nos Estados Unidos, disse uma pessoa informada sobre o projeto.

O Google poderia vender tecnologia de navegação ou informação para automóveis e teoricamente exibir publicidade vinculada à localização aos passageiros, enquanto eles passam velozmente por empresas locais, sentados no banco de trás e jogando Angry Birds.
Frotas de robôs podem ajudar o Google a recolher informações, substituindo a equipe humana que fotografa as ruas para o Google Maps, disseram pessoas informadas sobre o trabalho do Google X. Robôs criados pelo laboratório podem trabalhar em residências e escritórios, auxiliando em tarefas simples ou permitindo que as pessoas trabalhem sem sair de casa.

Outras ideias envolvem o que o Google chamou de "web de coisas" em uma conferência de seus programadores em maio --um meio de conectar objetos à internet. A cada vez que alguém usa a web, isso beneficia o Google, argumenta a empresa, e por isso seria interessante para ela que acessórios domésticos e objetos pessoais, não apenas computadores, estivessem conectados.

Entre os itens que poderiam se tornar conectáveis estão um sistema de jardinagem (que permitiria que plantas sejam regadas a distância), uma cafeteira (que poderia ser acionada remotamente) e uma lâmpada (ligada e desligada a distância). O Google anunciou em maio que até o final do ano outra de suas equipes planejava lançar uma lâmpada conectada à web capaz de se comunicar sem fio com aparelhos com o sistema operacional Android.

Um engenheiro do Google que conhece o Google X disse que as operações do laboratório são misteriosas como as da CIA (Agência Central de Inteligência) --ele contaria com dois escritórios, um para fins logísticos, que funciona sem identificação na sede da empresa em Mountain View, e outro em local sigiloso, para os robôs.

	Peter DaSilva/The New York Times
	Andrew Ng (esq.), cientista do Google X, no laboratório de inteligência artificial da Universidade Stanford

Enquanto as equipes técnicas de outros departamentos do Google são formadas principalmente por engenheiros de software, no laboratório predominam os especialistas em robótica e os engenheiros elétricos. Foram contratados da Microsoft, da Nokia Labs e de universidades como Stanford, MIT, Carnegie Mellon e Universidade Nova York.

Um dos líderes do Google X é Sebastian Thrun, um dos maiores especialistas mundiais em robótica e inteligência artificial, que leciona ciência da computação em Stanford e desenvolveu um carro sem motorista. Outro cientista do laboratório é Andrew Ng, também professor de Stanford, cuja especialidade é a aplicação da neurociência na inteligência artificial para ensinar os robôs e máquinas a funcionar como pessoas.

Johnny Chung Lee, especialista em interação entre computadores e seres humanos, trocou a Microsoft pelo Google X neste ano, depois de ajudar a desenvolver o Kinect, o sistema de controle de videogames que responde a movimentos e voz. No Google X, onde ele trabalha no projeto da web de coisas, de acordo com pessoas que conhecem suas funções, ele tem o misterioso cargo de "avaliador rápido".

Porque o Google X é um campo de desenvolvimento de grandes apostas que podem resultar tanto em grandes fiascos quanto no próximo grande negócio do Google --e descobrir qual das duas pode demorar anos--, a simples ideia dessas experiências aterroriza alguns acionistas e analistas.

"Os projetos exageradamente ambiciosos são bem a cara do Google", disse Colin Gillis, analista da BGC Partners. "As pessoas não adoram, mas toleram, porque o negócio primário da empresa, o de buscas, continua a funcionar com alta lucratividade."

Page tenta apaziguar os analistas afirmando que os projetos mais excêntricos representam pequena proporção do trabalho do Google.

"Existem alguns poucos projetos especulativos, de pequeno porte, acontecendo na empresa a cada momento, mas tomamos muito cuidado na gestão do dinheiro dos acionistas", disse ele a analistas em junho. "Não estamos apostando todo o nosso capital nessas coisas."

Fonte: FolhaOnLine - Extraído do "The new york times"

NASA reconhece ação de Deus

O DIA EM QUE O SOL PAROU

Cientistas da NASA, a agência espacial norte-americana, no início da década de 80, em Green Belt, Maryland, dedicaram-se a uma exaustiva pesquisa, com o uso dos mais modernos recursos da Informática, para estabelecer a posição exata do Sol, da Lua e dos diversos planetas do nosso sistema solar durante o milênio.

Harold Hill, presidente da companhia de engenharia Curtis, com sede na cidade de Baltimore, também em Maryland, relata sua experiência no cargo de consultor do programa espacial daquele período:

"Precisamos desses dados para que satélites possam ser lançados ao espaço para missões de exploração de novos corpos celestes sem que entrem em rota de colisão com qualquer um deles. Como pretendemos construir foguetes não-tripulados com autonomia para muitas e muitas décadas no espaço, precisamos traçar sua trajetória com precisão para que as gerações futuras venham a receber e analisar os dados enviados por eles. Nós e os cientistas da NASA, descobrimos que falta um dia no calendário universal. Envolvido nesta pesquisa, pude presenciar uma descoberta fantástica: falta um dia na história do universo!"

Eis como tudo aconteceu: Os engenheiros da NASA colocaram os dados no computador para que ele determinasse a exata posição dos astros, tanto no passado quanto no futuro, e então surgiu um impasse. O computador subitamente interrompeu o programa e mostrou na tela um aviso de que havia algo errado nos números que lhe serviram de base para os cálculos. Entretanto, havia entre eles um evangélico que falou sobre a história de Josué. Os engenheiros da IBM foram imediatamente chamados para verificação de um possível defeito e, após um cuidadoso exame de toda a rede de informática, garantiram que estava tudo em ordem. Foi então, que esse membro evangélico que fazia parte da equipe, lembrou-se de que Josué, segundo os textos sagrados, certa ocasião ordenara ao Sol que parasse e contou o episódio aos seus colegas. Ninguém acreditou, a princípio, pois todos os outros cientistas eram acostumados a fatos concretos. Assim, eles o desafiaram a provar o que dizia. O cientista, ao ser desafiado, pegou a Bíblia e mostrou Josué 10:12 "Então Josué falou ao Senhor, no dia em que o Senhor entregou os amorreus nas mãos dos filhos de Israel; e disse, na presença dos israelitas: Sol, detém-te sobre Gibeom, e tu, lua, no vale de Aijalom". Explicou-lhes que Josué se encontrava rodeado por inimigos e se a  noite caísse, eles poderiam sobrepujá-lo. Pediu, portanto, a Deus que o Sol parasse, e assim aconteceu, o Sol não se pôs o dia todo.

Depois destas explicações, resolveram colocar esses novos dados nos computadores para ver se era realmente o dia que faltava e, voltando no tempo, achamos uma resposta aproximada. O período que faltava no tempo por causa do pedido de Josué era de 23 horas e 20 minutos; não era, portanto, um dia inteiro, conforme garantiam os computadores da NASA. Com esse resultado, os cientistas voltaram ao livro de Josué e acharam o capítulo 10 v.13: "E o Sol se deteve, e a Lua parou, até que o povo se vingou de seus inimigos...O sol, pois, se deteve no meio do céu, e não se apressou a pôr-se, quase um dia inteiro". Bem, o texto bíblico confirmava que não era exatamente um dia inteiro e esse achado foi muito importante, mas ainda assim continuavam em dificuldades, porque faltavam 40 minutos, e não é possível realizar cálculos para séculos futuros com um erro desse tipo.

Após algum tempo, aquele cientista evangélico se lembrou de outra passagem bíblica que mencionava outro episódio a respeito do sol. Dessa vez o astro maior teria regredido no tempo. Todos ficaram atônitos... absolutamente mudos! Novamente o primeiro impulso foi de descrédito, porém, utilizando-se de um programa específico para consultas bíblicas, chegaram ao seguinte texto: II Reis 20: 8 à 11 - "Ezequias disse a Isaías: Qual será o sinal de que o Senhor me curará, e de que ao terceiro dia subirei à casa do Senhor? Respondeu Isaías: Ser-te-á isto da parte do Senhor como sinal de que Ele cumprirá a palavra que disse: Adiantar-se-á a sombra dez graus, ou os retrocederá? Então disse Ezequias: É facil que a sombra adiante dez graus; tal, porém, não aconteça, antes retroceda dez graus. Então o profeta Isaías clamou ao Senhor; e fez retroceder dez graus a sombra lançada pelo sol declinante no relógio de Acaz".

Ficaram todos quietos naquele momento. A incredulidade por causa daquilo que é concreto foi fulminada pelas palavras de um livro milenar, muitas vezes ignorado. Dez graus são exatamente 40 minutos que, somados às 23 horas e 20 minutos do tempo utilizado por Josué, formam precisamente as 24 horas (um dia) faltantes em nossos cálculos.

(Texto extraído de depoimento do Dr. Harold Hill e adaptado pela Revista Plenitude nº13. Extraído do site http://estudosbiblicos.spaceblog.com.br)

Apple anuncia recall do iPod Nano de 1ª geração

A Apple vai trocar unidades do iPod Nano de primeira geração, que podem ter problemas de sobreaquecimento de bateria. Os modelos afetados foram vendidos entre setembro de 2005 e dezembro de 2006.

Para solicitar a substituição do aparelho, o consumidor deve procurar uma assistência técnica autorizada da Apple, diz a empresa. É necessário informar o número de série do iPod para verificar se ele está incluso no programa de substituição.

O consumidor deve obter a unidade de troca em, aproximadamente, seis semanas após a Apple receber o iPod Nano com defeito.

	Cooper-Hewitt/Associated Press
	Modelo de primeira geração do iPod Nano, lançado pela Apple em 2005

A Apple diz que, com o sobreaquecimento, a bateria pode tornar-se "um risco à segurança". "O problema foi rastreado e descobriu-se que um único fornecedor de baterias as produzia com um defeito de fabricação. A possibilidade de acidente é rara, mas ela aumenta à medida que a bateria vai se tornando obsoleta."

No ano passado, o mesmo problema levou a empresa a fazer um recall do iPod Nano no Japão.

A Apple não informa qual modelo de iPod Nano o consumidor deve receber na troca.

Fonte: Folha On Line

Amigos,

Gostaria de compartilhar um breve artigo sobre ORM (Object-Relational Mapping). Por exemplo, o Hibernate junto com JPA é um tipo de framework que provê essa abstração através do mapeamento de Entidades.
Entretanto, quem já não se deparou com casos onde o hibernate gera dezenas de queries indesejadas para carregar os relacionamentos entre entidades, trazendo a velha sensação de saudades do SQL-ANSI através do JDBC, devolvendo o controle sobre as queries ao desenvolvedor.
Enfim, vou postar abaixo o artigo, achei interessante:

ORM is an anti-pattern

I tweeted about ORM last week, and since then several people have asked me to clarify what I meant. I have actually previously written about ORM, but it was in the context of a larger discussion about SQL and I shouldn't have confused the two issues. So here I'm going to focus on ORM itself. I'm also going to try to be very brief, since it became very apparent from my SQL article that people tend to stop reading at the first sentence that makes them angry (and then leave a comment about it, whether or not their point is addressed later on).

What's an anti-pattern?

I was pleased to discover that Wikipedia has a comprehensive list of anti-patterns, both from within the world of programming and outside of it. The reason I call ORM an anti-pattern is because it matches the two criteria the author of AntiPatterns used to distinguish anti-patterns from mere bad habits, specifically:

1. It initially appears to be beneficial, but in the long term has more bad consequences than good ones
2. An alternative solution exists that is proven and repeatable

It is the first characteristic that has led to ORM's maddening (to me) popularity: it seems like a good idea at first, and by the time the problems become apparent, it's too late to switch away.

What do you mean by ORM?

The chief offender that I'm talking about is ActiveRecord, made famous by Ruby on Rails and ported to half a dozen languages since then. However, the same criticisms largely apply to other ORM layers likeHibernate in Java and Doctrine in PHP.

The benefits of ORM

• Simplicity: some ORM layers will tell you that they "eliminate the need for SQL". This is a promise I have yet to see delivered. Others will more realistically claim that they reduce the need to write SQL but allow you to use it when you need it. For simple models, and early in a project, this is definitely a benefit: you will get up and running faster with ORM, no doubt about it. However, you will be running in the wrong direction.
• Code generation: eliminating user-level code from the model through ORM opens the way for code generation, the "scaffolding" pattern which can give you a functional interface to all your tables through a simple description of your schema. Even more magically, you can change your schema description and re-generate the code, eliminating CRUD. Again, this definitely works initially.
• Efficiency is "good enough": none of the ORM layers I've seen claim efficiency gains. They are all fairly explicit that you are making a sacrifice of efficiency for code agility. If things get slow, you can always override your ORM methods with more efficient hand-coded SQL. Right?

The problems with ORM

Inadequate abstraction

The most obvious problem with ORM as an abstraction is that it does not adequately abstract away the implementation details. The documentation of all the major ORM libraries is rife with references to SQL concepts. Some introduce them without indicating their equivalents in SQL, while others treat the library as merely a set of procedural functions for generating SQL.

The whole point of an abstraction is that it is supposed to simplify. An abstraction of SQL that requires you to understand SQL anyway is doubling the amount you need to learn: first you need to learn what the SQL you're trying to run is, then you have to learn the API to get your ORM to write it for you. In Hibernate, to perform complicated SQL you actually have to learn a third language, HQL, which is maddeningly almost-but-not-quite SQL, which then gets translated to SQL for you.

A defender of ORM will say that this is not true of every project, that not everyone needs to do complicated joins, that ORM is an "80/20" solution, where 80% of users need only 20% of the features of SQL, and that ORM can handle those. All I can say is that in my fifteen years of developing database-backed web applications that has not been true for me. Only at the very beginning of a project can you get away with no joins or naive joins. After that, you need to tune and consolidate queries. Even if 80% of users need only 30% of the features of SQL, then 100% of users have to break your abstraction to get the job done.

Incorrect abstraction

If your project really does not need any relational data features, then ORM will work perfectly for you, but then you have a different problem: you're using the wrong datastore. The overhead of a relational datastore is enormous; this is a large part of why NoSQL data stores are so much faster. If your data is relational, however, that overhead is worth it: your database does not merely store your data, itrepresents your data and can answer questions about it on the basis of the relations captured, far more efficiently than you could in procedural code.

But if your data is not relational, then you are adding a huge and unnecessary overhead by using SQL in the first place and then compounding the problem by adding a further abstraction layer on top of that.

On the the other hand, if your data is relational, then your object mapping will eventually break down. SQL is about relational algebra: the output of SQL is not an object but an answer to a question. If your object "is" an instance of X and "has" a number of Y, and each of Y "belongs to" a Z, what is the correct representation in memory of your object? Is it merely the properties of X, or should it include all the Ys, and/or all the Zs? If you get only the properties of X, when do you run the query to fetch the Ys? And do you want one or all of them? In reality, it depends: that's what I mean when I say SQL is the answer to a question. The representation of your object in memory depends what you intend to do with it, and context-sensitive representation is not a feature of OO design. Relations are not objects; objects are not relations.

Death by a thousand queries

This leads naturally to another problem of ORM: inefficiency. When you fetch an object, which of its properties (columns in the table) do you need? ORM can't know, so it gets all of them (or it requires you to say, breaking the abstraction). Initially this is not a problem, but when you are fetching a thousand records at a time, fetching 30 columns when you only need 3 becomes a pernicious source of inefficiency. Many ORM layers are also notably bad at deducing joins, and will fall back to dozens of individual queries for related objects. As I mentioned earlier, many ORM layers explicitly state that efficiency is being sacrificed, and some provide a mechanism to tune troublesome queries. The problem, I have discovered with experience, is that there is seldom a single "magic bullet" query that needs to be optimized: the death of database-backed applications is not the efficiency of any one query, but the number of queries. ORM's lack of context-sensitivity means that it cannot consolidate queries, and must fall back on caching and other mechanisms to attempt to compensate.

What are the alternatives?

Hopefully by this point I've made some kind of case that ORM has fundamental design flaws. But to be an antipattern, there needs to be an alternative. In fact, there are two:

Use objects

If your data is objects, stop using a relational database. The programming world is currently awash with key-value stores that will allow you to hold elegant, self-contained data structures in huge quantities and access them at lightning speed. There's no law that says Step One of writing any web app is installing MySQL. The massive over-application of relational databases to every data representation problem is one of the reasons SQL has acquired a bad reputation in recent years, when in fact the problem is lazy design.

Use SQL in the Model

It's hugely dangerous to claim there is One True Way™ to do anything in programming. But in my experience, the best way to represent relational data in object-oriented code is still through a model layer: encapsulation of your data representation into a single area of your code is fundamentally a good idea. However, remember that the job of your model layer is not to represent objects but to answer questions. Provide an API that answers the questions your application has, as simply and efficiently as possible. Sometimes these answers will be painfully specific, in a way that seems "wrong" to even a seasoned OO developer, but with experience you will get better at finding points of commonality that allow you to refactor multiple query methods into one.

Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count. Resist the temptation to wrap these in too many layers of abstraction, and deal with the data on its own terms. Above all resist the fallacy of OO, that it can represent anything and everything. OO is itself an abstraction, a beautiful and hugely flexible one, but relational data is one of its boundaries, and pretending objects can do something they can't is the fundamental, root problem in all ORM.

In summary (TL;DR)

• ORM is initially simpler to understand and faster to write than SQL-based model code
• Its efficiency in the early stages of any project is adequate
• Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL
• Entirely anecdotally, I claim that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them.
• Objects are not an adequate way of expressing the results of relational queries.
• The inadequacy of the mapping of queries to objects leads to a fundamental inefficiency in ORM-backed applications that is pervasive, distributed, and therefore not easily fixed without abandoning ORM entirely.
• Instead of using relational stores and ORM for everything, think more carefully about your design
• If your data is object in nature, then use object stores ("NoSQL"). They'll be much faster than a relational database.
• If your data is relational in nature, the overhead of a relational database is worth it.
• Encapsulate your relational queries into a Model layer, but design your API to serve the specific data needs of your application; resist the temptation to generalize too far.
• OO design cannot represent relational data in an efficient way; this is a fundamental limitation of OO design that ORM cannot fix.

Fonte: http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Quer trabalhar no Facebook?

O Facebook está oferecendo vagas para trabalhar em seu escritório em São Paulo, pedindo os currículos pela internet. Vale a pena prestar atenção nos benefícios que eles oferecem para entender como é sangrenta a disputa por talentos no mundo inteiro --aliás, seu grande concorrente, o Google, também está tentando atrair gente em São Paulo (o detalhamento está no https://www.facebook.com/careers/department.php?dept=sao-paulo), oferecendo um lugar lúdico e descontraído para trabalhar, com horários flexíveis.

Além dos vários benefícios que as empresas oferecem, como plano de saúde, aposentadoria, apoio a família, horas livres, direito de ficar em casa em caso de doença, assistência social, elas estão oferecendo colocar os funcionários, durante o horário de trabalho, em contato com gente inovadora convidadas para falar de seus projetos. Google e Facebook anunciam nos Estados Unidos que contratam chefs requintados para cuidar da alimentação do funcionário.

Daí você entende a reportagem que acaba de sair no jornal londrino "Financial Times" mostrando como os empresários americanos estão furiosos com as leis que limitam a entrada de estrangeiros no país.

Fonte: Folha

Submarino vendeu notebook e entregou macarrão... só no Brasil

Servidora pública, que pretendia presentar a mãe neste domingo, recebeu pacote do site com duas embalagens de macarrão tipo miojo.

Para presentear a mãe no próximo domingo, a servidora pública brasiliense Maria Luiza Ferreira decidiu usar a loja virtual Submarino no último dia 2/5 para adquirir um notebook. A compra, no valor de 1200 reais, foi finalizada e até entregue antes do prazo. No entanto, em vez do computador, o pacote veio com algo muito menos tecnológico: dois pacotes de macarrão instantâneo, no valor de 89 centavos.

De acordo reportagem da rádio CBN, Maria Luiza, após constatar o ocorrido, entrou em contato com o atendimento ao cliente do Submarino, que não soube como remediar o problema imediatamente. “Falaram que eu tinha de devolver o notebook para receber o novo; informei que eu não tinha o produto, mas sim dois pacotes de miojo” disse a servidora à reportagem da rádio. A consumidora também afirmou que a empresa havia estipulado um prazo de dois dias para fornecer uma resposta – que não foi emitida dentro do prazo – e que, além disso, os atendentes alegaram não ser possível entregar o presente até o Dia das Mães.

Leia também: Procon-SP denuncia lojas virtuais que não entregam produtos

Maria Luiza  informou à rádio que aguarda um posicionamento da empresa para ver se haverá necessidade de entrar na justiça. A assessoria de imprensa do Submarino informou ao IDG Now! que o produto será entregue, no máximo, até 06/05/2011 para a consumidora.

Fonte: IDG Now