Eric Carneiro descobriu que, se você ligar o HD do Steam diretamente ao computador, consegue obter taxas altíssimas de download. Um recorde!
Cerca de dois anos atrás, Walkovyr ouviu de um colega o seguinte comentário ao erro abaixo:
Error: Table does not exists.
- Porque a tabela “does” não existe?
Obviamente, depois disso o sujeito ficou sendo conhecido apenas pelo apelido “DOES”
Parecia ser apenas mais uma chamada de “computador fazendo barulho estranho” para diassunção, mas a verdade era bem mais aterradora: Provavelmente cansado dos maus tratos, humilhações e de ser constantemente exposto a todo tipo de pornografia e coisas nojentas, o HD simplesmente… resolveu se auto-cortar até ser destruído! Veja as fotos abaixo, e lembre-se: Nem todo barulho vindo do PC é um peça solta. Pode ser também um pedido de ajuda.
Veja a galeria abaixo:
O Windows de diasssunção é o Windows Ninja, escondendo as principais informações nas sombras:
E infelizmente o bisavô de Irio teve que mentir a idade para poder entrar no fórum 
640k emails serão suficientes para o projeto
Posted on: 16-03-2010
Uns dois anos atrás, contei um WTF de um dos personagens mais estranhos que já passou na minha vida de sysadmin/programador, o Canceroso. A idéia era desenvolver toda uma saga que se ilustraria as centenas de WTF’s que o Canceroso criou durante o ano, mas várias coisas mudaram de lá pra cá, e o projeto acabou morrendo por pura falta de tempo e organização da minha parte. Mas como o bem sempre vence o mal, o projeto será retomado. Até porque preciso escrever antes que minha memória comece a falhar. 
Enfim, em algum ponto do projeto que o Canceroso desenvolvia, ele começou a projetar todo o sistema de envio de orçamentos para fornecedores, recebimento, entrada dos valores no sistema, escolha da melhor opção e envio do pedido de compra. Com o processo todo rabiscado no papel, ele me chamou para uma reunião e começou a verificar alguns requisitos:
“Então, só para saber, qual o limite que nós temos para criar emails no servidor?” – ele perguntou
“Acho que só podemos criar mais uns cinco” – respondi
“Ih, cara, pra isso aqui dar certo vou precisar de uns nove emails…”
“Como assim, pra quê tudo isso? Não é só usar o compras@empresa?”
“Então, da maneira que pensei, teria que ter o orcamento@empresa para enviar o orcamento às empresas, um receb_orcamento@empresa para que elas enviem o orçamento, um respond_orcamento@empresa para dar retorno às empresas, (…)” – Aqui, tomo a liberdade de cortar toda a explicação do sujeito.
“Mas… não faz sentido algum. Pra quê ter nove emails? O usuário vai ter que ficar acessando todos?”
“Não, eu vi umas classes em Java, o sistema vai enviar o email, e verificar essas contas que eu falei. Quando chegar o orçamento, ele vai automaticamente ler o email, pegar os dados, e jogar no banco de dados. Na verdade o usuário nem vai precisar acessar o email, vai tudo pelo sistema.“
O estalo que meu cérebro pôde ser ouvido por kilômetros, assustando alguns animais. Havia tantas falhas óbvias no raciocínio dele que me perguntei por alguns momentos se ele estava falando sério. Na dúvida, resolvi questionar:
“Canceroso, simplesmente não faz muito sentido. Cada empresa, cada fornecedor, possui diferentes formas de enviar um orçamento, pode ser no corpo do email, em um pdf anexo, ou um doc do word, ou um arquivo texto, ou uma planilha, ou…. sei lá, milhões de possibilidades. E como você vai fazer para ler cada um dos orçamentos?”
“Não, isso é tranquilo, o sistema vai enviar automaticamente uma planilha para os fornecedores, cada item vai ser formatado corretamente, e aí quando ele enviar pra gente o sistema vai ler e jogar no banco de dados.”
“OK, mas e se acontecer dele salvar a planilha em um formato diferente do Excel? O sistema não vai ler?”
“Ele vai ter que salvar no formato definido”
“E se ele tiver que incluir dados extras, como promoções ou condições especiais?”
“Ele não vai poder colocar nada difente na planilha, ou vai dar erro. E nós vamos avisar isso pra eles”
“E se o fornecedor não tiver um email, somente fax?”
“Eles vão ter que ter um email.”
“E se eles enviarem em outro formato?”
“Simples, a gente não compra.”
“Então, basicamente, você está criando um sistema que além de exigir nove emails, exige também que os nossos fornecedores se adequem ao modelo de orçamento enviado, e que eles se adequem ao nosso modelo de pedido, ou eles não vão vender pra gente?”
“Sim, é isso mesmo. Mas essa é só a parte de compras, ainda tenho que fazer o processo de vendas, então é bem provável que você tenha que criar mais uns nove emails”
Felizmente, o sistema nunca saiu de uma página de entrada com login hard-coded em javascript. Durante meses me perguntei como seria se esse aborto da natureza tivesse realmente saído do papel…..
(como sempre, cliquem para ampliar. 
)
Lealcy descobriu que o Facebook, assim como o Orkut, não sabe contar.
Já Passion acha que o preço do Blu-ray ainda precisa baixar MUITO antes de estar disponível para toda população:
E, já que falamos que o Orkut não sabe contar, o Willian descobriu que o novo Orkut não sabe…. reconhecer URLs…
Pelo menos ela não precisa de armário, joga tudo no cesto de lixo…
Posted on: 04-01-2010
Se tem uma coisa em que usuários são mestres é na capacidade de criarem técnicas de organização bizarras e poucas produtivas. Já conheci uma usuária que organizava os emails por mês, em pastas diferentes, e por isso achava desnecessário apagar qualquer coisa, já que “se eu quiser ver algo, é só ir no mês que me mandaram o email…”. Há muitas outras histórias tão absurdas quanto essa, como veremos agora….
William de Oliveira Ferreira trabalha em uma empresa de plano de saúde e ficou encarregado de encaminhar por email para uma funcionária do setor de faturamento e movimentação de notas fiscais uma tabela de códigos conversão de códigos de procedimentos médicos (pois essa funcionária faz auditoria das guias médicas, e tal informação era importante…). Um procedimento até bem simples e comum.
Passados alguns dias, a funcionária procurou William para saber sobre a tabela de códigos. Confuso, William disse que havia encaminhado a tabela por email, e acabou ouvindo a seguinte pérola:
- “ah, eu devo ter guardado ela na lixeira, vou olhar se está lá”
Atônito, William ainda foi educado o suficiente para falar: “Não se preocupe, eu envio novamente a mensagem para você…”
Escrito em 2005 por Philipp Lenssen, um texto mostrava a importância de bons programadores terem condutas que muitos poderiam considerar ‘defeitos’. Dias atrás, tive o prazer de reencontrar esse mesmo texto, e percebi que muita coisa continua atual. O que se segue é uma tradução / adaptação do texto original, com alguns comentários pessoais sobre o assunto. Reflitam. WTF’s não vem apenas dos usuários, mas principalmente dos programadores…
Ao longo dos anos, percebi que, por mais paradoxal que isso possa parecer, bons programadores devem ser preguiçosos e burros.
Preguiçosos, porque apenas programadores preguiçosos irão pensar em escrever o tipo de código que no fim fará o trabalho por eles. Preguiçosos, porque apenas um programador preguiçoso evitará a todo custo escrever trechos repetitivos e monótonos de código – o que evita a redundância, principal inimigo da manutenção no código-fonte. Principalmente, as ferramentas e processos criados por esse comportamento de pura preguiça irão aumentar a velocidade de desenvolvimento.
Isso tudo faz com que o programador preguiçoso um bom programador. Claro, isso é apenas uma parte da verdade: para um programador preguiçoso ser um bom programador, ele (ou ela) também deve ser extremamente ‘não-preguiçoso’ quando se trata de aprender a como permanecer preguiçoso – ou seja, qual software faz sey trabalho mais simples, quais métodos evitam redundância, e como ele pode fazer com que a manutenção do seu código seja a mais simples possível.
Em segundo, (e vou elaborar um pouco mais a partir daqui, porque o conceito é bem menos claro que o primeiro) um bom programador deve ser burro. Por que? Oras, se ele for inteligente, e tiver a consciência de que ele é inteligente, o programador irá:
a) parar de aprender
b) parar de ser crítico com relação ao seu próprio trabalho
O primeiro ponto fará com que seja complicado para ele encontrar novas técnicas para que trabalhar mais rápido. Basicamente, o programador que para de aprender não busca novas soluções, não busca novas alternativas e permanece preso às ferramentas e métodos que ele já conhece. O segundo ponto fará com que ele perca muito tempo debugando o próprio código. Na interminável luta entre um programador e o compilador, é melhor que o programador desista logo e admita que a culpa é sempre dele, e não do compilador, e vá tentar entender o quê ele está fazendo de errado. (nota: OK, há casos em que a culpa É do compilador. Mas são tão raros que dificilmente você vai encontrar várias situações assim no seu dia-a-dia).
Mas há um ponto ainda mais importante sobre porque um programador deve ser burro. Para encontrar sempre a melhor solução para o problema, ele deve ser capaz de manter uma mentalidade fresca e aprender a “pensar fora da caixa”. Tem em mente que o problema nem sempre é o que parece, e a melhor solução nem sempre é o que você imagina, e saber pensar em soluções alternativas e fora do comum.
O contrário disso não seria muito construtivo: conhecer todos os parâmetros e funções, e aceitá-los. Quem garante que os limites que você conhece são reais? Quanto menos você souber, mais radicais serão suas soluções: assim, melhores serão as ferramentes que você criará, e melhores serão os produtos que você desenvolverá com essas ferramentas.
Um bom programador sempre se perguntará “Por que?”, porque ele é burro (ou suspeita de um problema maior).
Um bom programador, quando confrontado com um problema vindo dos usuários, vai adotar a mentalidade de ser burro: ele começará a fazer as perguntas mais simples e infantis possíveis. Isso é porque ele não aceita os parâmetros sugeridos pra ele do que alguém pensa que pode estar causando o problema. Por exemplo, veja uma conversa típica de desenvolvedores web frente a um problema:
“Desde ontem, nosso cliente não consegue ver o logo no site.”
“Ele reiniciou o navegador?”
“Sim.”
“Ele reiniciou o computador?”
“Sim.”
“Limpou o cache?”
“Sim.”
“Ele roda o Internet Explorer 6?”
“Sim.”
“Tem certeza de que ele não consegue ver o logo?”
“Sim.”
“Ele olhou para o site na tela?”
“Como assim?”
“Talvez ele tenha visto o site impresso em papel.”
“Não, ele estava olhando para a tela.”
“Ele não consegue ver outras imagens também, ou só o logo?”
“Como? Bom, vou perguntar pra ele.”
Para fins de argumentação, vamos dizer que o cliente na verdade tenha desligado a exibição de imagens no navegador. Ou o seu filho desligou. Ou um funcionário desligou. Em qualquer caso, a resposta não poderia ser encontrada da “maneira inteligente“. Nenhuma das questões levantadas pelo programador exigiam algum talento em programação. Nenhuma. Mas simplesmente pelo motivo ser tão estúpido, somente a estupidez pode lidar com isso.
Muitas vezes, a suposição de que alguma ação do programador gerou um problema não passa de uma suposição. Sempre que possível, ouça apenas os fatos antes de começar a debugar, e ignore o que as pessoas pensam que seja a razão do problema.
E isso se aplica a VOCÊ. Recentemente, tive um problema aparentemente simples: migrar um sistema de um domínio X para o subdomínio de um domínio Y. Coisa aparentemente simples, se o domínio Y não redirecionasse automaticamente para o domínio Z no Ning, e o subdomínio não estivesse fazendo a mesma coisa. Depois de várias horas batendo cabeça com o DNS e o CPanel, decidi deixar pra lá e fazer algumas atualizações no sistema em questão. Nos primeiros minutos, descubro que o redirecionamento era feito pelo sistema, em um trecho de código que eu havia colocado por questões de segurança. Removido o trecho, tudo funcionou como deveria desde o princípio. Por descuido, cansaço e vários outros motivos, havia perdido tempo e cabelo com um problema que não existia, na verdade….
Pode parecer complicado, ou até mesmo burocrático, mas esse é um processo investigativo simples: quanto mais informações reais você possui, mais fácil é o processo de chegar ao que realmente está causando o problema. Aceitar que o usuário diga apenas “Há um problema no site, e acho que pode ter sido causado pela sua última atualização” só fará com que você perca horas, talvez dias, até perceber que na verdade o problema era mais simples do que parecia.
(Nota: sim, meus caros usuários, nós não tratamos vocês como idiotas ou ignoramos completamente o que você fala do problema por acharmos que somos melhores do que vocês. Nós fazemos perguntas E chegamos à conclusões baseado no que você nos diz que está acontecendo, não no que você acha que pode ser o problema. Na verdade, muitas vezes o que você acha só nos atrapalha. Bons programadores vão ignorar suas sugestões, pelo menos em um primeiro momento…)
Pensem nisso. Sejam burros e preguiçosos. E sejam bons programadores.
Telas WTF – Erros Infernais, problemas com tóxicos, e muito mais
Posted on: 14-09-2009
Category : screenshots, WTF
Rafael descobriu como o MegaUpload consegue manter toda aquela estrutura
Diassunção precisa urgentemente fechar alguns programas no seu equipamento com 4GB de RAM. Recomendo remover o Vista.
Rafael Arcanjo, protetor dos sistemas de ERP, excomungou um módulo por essa heresia:
Já eu pessoalmente acho que tem algo muito errado com esse tipo de anúncio no GMail…
É a pergunta feita nesse post do Microsoft Answers: o usuário comenta que, sempre que ele instala programas ou copia arquivos para o notebook, o peso do mesmo aumenta. E que, estranhamente, acontece a mesma coisa com o XBox.
O que nos leva a perguntar: Já imaginaram o peso de um HD com 1TB lotado? Ou…. já imaginaram o peso dos servidores do Google? Provavelmente, os objetos próximos são atraídos para os HDs dessas máquinas, e algumas pessoas até orbitam em volta dela!
E, se só a pergunta já não é um WTF suficiente, basta ver o nível dos comentários logo abaixo…..