quarta-feira, 14 de dezembro de 2011

SAC da NET pelo número 10621 é grátis

O número de telefone de call-center/SAC da NET divulgado por eles é o 4004-7777. Entretanto todas as ligações feitas para esse número são tarifadas como ligação de fixo para fixo.
Considerando que antes do atendimento ser realizado precisamos navegar pelas opções da URA por aproximadamente 1 minuto, já estamos tomando prejuízo de 1 minuto na ligação.

Para contornar esse problema, existe outro número de call-center da NET que eles não divulgam (por ser gratuito): 10621.

Ao ligar para o número 10621 a ligação é direcionada para o mesmo call-center da NET, porém como ligação gratuita.

quinta-feira, 8 de dezembro de 2011

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 {} \;



terça-feira, 29 de novembro de 2011

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
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
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
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"

terça-feira, 22 de novembro de 2011

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)

segunda-feira, 14 de novembro de 2011

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
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

domingo, 19 de junho de 2011

ORM is an Antipattern

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

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.

quarta-feira, 25 de maio de 2011

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

quinta-feira, 5 de maio de 2011

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.
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

quinta-feira, 28 de abril de 2011

Desenvolvedores estão ficando frustrados com a plataforma Android

Cresce descontentamento em relação à OS da Google devido à fragmentação do sistema e pela presença fraca no mercado de tablets, diz pesquisa.

A última pesquisa de dispositivos móveis da Appcelerator/IDC revelou uma crescente onda de frustração entre os desenvolvedores da plataforma Android, principalmente devido a preocupações como tablets decepcionantes, fragmentação do sistema operacional e múltiplas app stores.
Durante os últimos 12 meses, os dois relatórios trimestrais da Mobile Developer Report identificaram que o crescimento do interesse no Android diminuiu drasticamente o espaço entre a plataforma do Google e o líder da pesquisa, o iOS da Apple. Entretanto, em 11/4 deste ano, os níveis de interesse do Android entre os 2 700 pesquisados caiu pela primeira vez, de 87% para 85%, atrás dos 91% e 86% a respeito do iPhone e do iPad, respectivamente. Mais notório anda foi a queda em relação aos tablets Android, que caiu três pontos, chegando a 71%.
Quase três terços citaram a fragmentação dos dispositivos Android como principal aborrecimento, com mais mais de 30% mencionando que a fraca participação do sistema operacional no mercado de tablets, um nicho dominado quase que inteiramente pela Apple. O modelo aberto do Android também foi alvo de 28% das criticas de usuários preocupados com a existência de múltiplas lojas de aplicativos.
As únicas boas notícias para a Google é que, a não ser pela Apple, os desenvolvedores estão ainda menos atraídos pelo BlackBerry OS e Windows Phone 7, ambos com menos de 30% de interesse entre os desenvolvedores pesquisados. Com sua plataforma recém-lançada, a Microsoft terá como conforto o fato de que o Windows Phone está agora pelo menos no terceiro lugar com 29%, à frente da RIM, que conta com 27%.
A aparição modesta do Android talvez não seja uma surpresa tão grande, depois de tantos sustos em relação à segurança e o reconhecimento público da Google de que também está muito preocupado com a fragmentação, através do hardware dos aparelhos e das redes de telefonia. A companhia ainda irritou os desenvolvedores no começo deste mês, ao impedir temporariamente a disponibilização do código-fonte do sistema operacional da empresa para tablets, o Android 3.0 (denominado Honeycomb), permitindo o acesso somente aos grandes parceiros. Uma data para o relançamento para os desenvolvedores menores ainda será estipulada.
Um problema mais profundo que todas as donas dessas plataformas pretendem corrigir pode ser a sobrecarga dos desenvolvedores “O maior empecilho da Microsoft com seus desenvolvedores pode simplesmente ser o tempo disponível, pois 46% dos pesquisados indicaram que “estão sobrecarregados com iOS e Android", de acordo com os autores do estudo.
Neste contexto, o problema da fragmentação do Android provavelmente amplifica a ansiedade dos desenvolvedores por causa de uma divergência de habilidades de programação, necessárias para criar softwares para diferentes plataformas.
Fonte: IDGNow

terça-feira, 26 de abril de 2011

Americanos preferem o Android ao iPhone, e desprezam o Symbian


Nos EUA, 31% dos consumidores pretendem comprar um aparelho Android, ante 30% dos que deverão optar pelo aparelho da Apple. Nem 1% citou o Symbian.

Pela primeira vez no mercado americano, o Android superou o iPhone na preferência dos consumidores. Segundo pesquisa do instituto de pesquisa Nielsen, entre janeiro e março deste ano, 31% dos entrevistados disseram que seu próximo smartphone terá o Android como SO, pouco à frente dos que citaram o iOS (30%). O BlackBerry, por outro lado, não está mais na briga, pois só 22% deverão escolhê-lo.
ascensão da plataforma da Google é notória inclusive nesse estudo. Entre julho e setembro de 2010, seu índice ficara em 26%, ante 33% do produto da Apple. A queda do iPhone – de 9% – no entanto, deverá ser interrompida com o lançamento do iPhone 5, previsto para setembro.
Se o BlackBerry enfrenta dificuldade para retornar à velha forma, o Windows Phone 7 não consegue sequer decolar. O sistema da Microsoft, que começou a ser comercializado em novembro nos EUA, estava em melhor situação antes de ser lançado do que agora. Entre julho e setembro, 7% dos usuários tinham interesse em comprar um aparelho da plataforma – ou mesmo do Windows Mobile – número este que caiu para 6% na pesquisa conduzida entre janeiro e março.
Outros dados divulgados pela Nielsen chamam a atenção. Nem 1% dos entrevistados devem comprar um Symbian nos próximos meses – seu índice ficou em 0% – mas 1% lembraram do WebOS, sistema operacional que ainda não está no mercado –  e não há previsão de quando estará. Há também muitos consumidores indecisos: dois a cada dez não sabem que plataforma escolher para a próxima compra.
A partir dos números divulgados, é possível concluir que a disputa do mercado de smartphones continua restrita a Android e iPhone, apesar do pesado investimento da Microsoft no setor. A esperança da gigante dos softwares recai em sua parceria com a Nokia. Esta, porém, por mais útil que possa ser em termos globais, dificilmente a favorecerá nos EUA, visto que a empresa finlandesa nunca foi muito popular no país.
Fonte: IDGNow

quinta-feira, 14 de abril de 2011

São Paulo sobe 21 posições em ranking de produção científica

Um relatório divulgado na Grã-Bretanha diz que São Paulo subiu da posição 38 para o 17º lugar em um ranking de cidades com mais publicações científicas no mundo.
De acordo com o estudo feito pela Royal Society, a academia nacional de ciência britânica, a evolução da capital paulista nesse setor “reflete o rápido crescimento da atividade científica brasileira”.
O relatório, chamado Conhecimento, Redes e Nações: A Colaboração Científica no Século 21, analisa a publicação de trabalhos científicos por país no período entre 1996 e 2008.
O documento indica que o Brasil e outros países emergentes, liderados pela China, estão despontando como grandes potências na área de produção de estudos científicos, capazes de rivalizar com países que têm tradição nessa área, como os Estados Unidos, nações da Europa Ocidental e o Japão.
A representatividade dos estudos brasileiros teve leve aumento: entre 1999 e 2003, eles equivaliam a 1,3% do total de pesquisas científicas globais. Entre 2004 e 2008, essa porcentagem subiu para 1,6.
Mas “as reduções significativas no orçamento de ciência em 2011 levantam preocupações”, diz o relatório. Em meio aos cortes de R$ 50 bilhões anunciados pelo governo no orçamento federal, o Ministério de Ciência e Tecnologia deve perder R$ 1,7 bilhão.
China
Segundo o levantamento, o desempenho da China é ''particularmente notável'' - a publicação de documentos científicos do país superou as do Japão e da Europa nos últimos anos.
O país asiático só é ultrapassado pelos Estados Unidos, mas deve superá-los antes de 2020, se a atual tendência continuar.
Em 1996, os Estados Unidos tinham produção científica dez vezes maior que a chinesa; hoje, sua produção, com crescimento menor, não chega a ser o dobro da do país asiático.
No entanto, o relatório diz que ''ainda demorará algum tempo para que a produção dessas nações emergentes esteja à altura de ser uma referência para a comunidade científica internacional'', ressalta a pesquisa.
Áreas específicas
O estudo diz que há avanços em áreas específicas da ciência em alguns países, entre eles o Brasil.
''Existe diversificação de alguns países demonstrando lideranças em setores específicos, como a China em nanotecnolgia, e o Brasil em biocombustíveis, mas as nações avançadas do ponto de vista científico continuam a dominar a contagem de citações.''
A pesquisa também identificou nações emergentes no campo da ciência que não costumam ser associadas a uma base científica forte, como o Irã, a Tunísia e a Turquia.
As projeções feitas pelo relatório “sugerem que o sistema científico global está se desvencilhando de seu padrão anterior”.
“China e Coreia do Sul cumprem com suas ambiciosas metas de investimento em pesquisa e desenvolvimento, enquanto economias como Brasil e Rússia também prometem recursos substancialmente maiores para pesquisas.”
Com isso, é possível que nações emergentes – Brasil incluído – superem os investimentos de países como Japão e França no setor.
Fonte: BBC

quarta-feira, 13 de abril de 2011

Cinco pontos fundamentais para decisões relacionadas à carreira

Tomar decisões sobre o curso da carreira nunca é fácil, esteja o profissional procurando por um novo emprego ou avaliando a oferta de um empregador em potencial.
É por isso que ter um guia objetivo para a tomada de grandes é importante. A recrutadora da empresa norte-americana de RH Russel Reynolds Associates, Shawn Banerji, aconselha os executivos a seguirem cinco critérios na avaliação de uma oferta de emprego: posição, pessoas, plataforma, lugar e pagamento. “Esses são os cinco pontos que devem ser levados obrigatoriamente em consideração”, diz Banerji.
Essa metodologia ajuda a reduzir a complexidade da decisão direcionar o foco da análise e levar o executivo a refletir se vale mesmo a pena deixar a posição atual.
Confira os detalhes sobre cada ponto a ser a avaliado:
1 – Posição – Para determinar se a posição que está sendo oferecida é a certa para o profissional, ele deve ter respostas claras para uma série de perguntas: qual será seu papel efetivo na nova empresa? Quais serão as responsabilidades do papel e as expectativas para com o mesmo? Está confiante que pode ser bem sucedido no papel? Para quem se reportará? Qual a importância do cargo na escala de valor da companhia? Terá o poder necessário para fazer as realizações que espera?
2 – Pessoas – O profissional se dá bem com as pessoas com as quais trabalha atualmente ou com as quais pode vir a trabalhar? Banerji ressalta que isso é muito importante, já que o tempo gasto com os colegas chega a ser maior do que o investido em família e amigos.
3 – Plataforma – O profissional conta com uma plataforma com a qual se sente confiante e pronto para dar contribuição material? É importante considerar os objetivos de negócios da companhia: ela está passando por uma reformulação? Crescimento? Aquisições ou alienação? Banerji diz que essencial é entender como as habilidades e competências do profissional se alinham com a direção dos negócios.
4 – Lugar – Onde a vaga está localizada fisicamente? O mercado imobiliário na região facilita a realocação para assumir o novo cargo? O novo empregador ajudará com a mudança?
5 – Pagamento – O retorno da investida é proporcional ao risco que se está tomando ou a contribuição que será feita?
Apesar de os conselhos de Banerji terem sido direcionados aos executivos, eles se aplicam a profissionais de todos os níveis. Tente aplicá-los.
Fonte: Computerworld

quarta-feira, 6 de abril de 2011

Herança vs Composição

Gostaria de compartilhar o artigo publicado no site iMasters pelo colega Lucio Camilo, fazendo um comparativo interessante entre Herança e Composição.

Na verdade, esse artigo não é bem um comparativo, e sim uma "desqualificação" do uso da herança. Na minha opinião, não há solução ideal para todos os problemas, nem modelo ideal de arquitetura. Há sim uma solução específica para um problema específico.

Citando o velho exemplo do objeto Veículo, que pode ser especializado como Carro, Bicicleta, Carroça, Caminhão, é um caso claro onde a Herança se aplica muito bem. Mas volto a dizer, não sou defensor de arquitetura A, B ou C, defendo sim a avaliação de cada problema, e a aplicação da solução adequada para cada um, seja com Herança, Composição, Agregação, ou seja lá o que for.

Vamos ao artigo publicado:
Há algum tempo, herança era considerada a ferramenta básica de extensão e reuso de funcionalidade. Qualquer linguagem que não possuísse o conceito de herança “não servia para nada”. Atualmente, todos os artigos sobre padrões de projeto desaconselham a utilização de herança.

E agora?

Um princípio básico de padrões de projeto é “dar prioridade à composição”, preferir sempre “tem-um” ao invés de “é-um”. Quanto à herança, deve ser utilizada com muita prudência e em pouquíssimas situações.
Uma das poucas certezas que temos no desenvolvimento de aplicações é que existirão alterações. Portanto, a utilização de herança para fins de reutilização não dá tão certo quando se tratam de manutenções nos códigos já existentes.
Supondo que utilizamos uma classe pai para encapsular o comportamento de algum objeto. Dessa forma, todas as nossas classes filhas herdarão esses comportamentos. E o problema ocorre quando alguma das classes filhas não precisam de algum dos comportamentos que estão encapsulados. Passamos a ter que mudar o código na classe filha para que o método que foi herdado funcione da maneira específica para esse objeto. Ou, pior ainda, quando esse objeto não necessitar desse comportamento, então teríamos que sobrescrever o método para que ele não faça nada.
Alguns dos problemas dessa implementação é que o encapsulamento entre classes e subclasses é fraco, e o acoplamento é forte. Assim, toda vez que uma superclasse for alterada, todas as subclasses podem ser afetadas. Perceba que estamos violando o princípio básico de OO (Alta Coesão, Baixo Acoplamento).
Ainda com herança, a estrutura está presa ao código, e não pode sofrer alterações facilmente em tempo de execução, fazendo diminuir a capacidade de polimorfismo.
Quando utilizamos composição, instanciamos a classe que desejamos dentro de nosso código. Dessa forma, estamos estendendo as responsabilidades pela delegação de trabalho a outros objetos. Em vez de codificar um comportamento estaticamente, definimos pequenos comportamentos padrão e usamos composição para definir comportamentos mais complexos. Ainda na utilização de composição, podemos mudar a associação entre classes em tempo de execução e permitir que um objeto assuma mais de um comportamento.
Ao utilizar a composição, teremos muito mais flexibilidade, além de ser mais comum em muitos padrões de projetos. Porém, na herança, temos uma possibilidade de desenvolver mais rápido, diminuindo o tempo de desenvolvimento, levando em conta que perdemos muito mais tempo mantendo e alterando o código original do que com o desenvolvimento inicial. Portanto, nosso esforço deve ser sempre voltado para a reutilização e para a manutenção.

Aproveito para indicar um artigo interessante que conta com códigos mostrando o motivo de nunca se utilizar herança: veja aqui.
Fonte: iMasters