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”

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

Sua empresa trabalha com virtualizações de aplicativos em rede? Conhece todas as soluções disponíveis no mercado? O software CockpIT da JETRO Platforms é sugerido para empresas que pretendem virtualizar ou centralizar suas aplicações com baixo custo e alta performance. Na verdade o CockpIT excede as funções do Terminal Server onde, utilizando o protocolo RDP  (remote desktop protocol) , aumenta performance, desempenho e gerenciabilidade do Terminal Server. Além disso, a JETRO disponibiliza uma suite de upgrade competitivo para clientes que já utilizem outras soluções que leiam o protocolo ICA. Com isso, você não perde os investimentos já feitos em outras soluções.

Todos sabemos que hoje as empresas estão buscando :

1. Redução do Custo total de propriedade de Hardware;
2. Redução de custos de Licenciamento de Software;
3. Maior gerenciabilidade e segurança na definição dos perfis de usuários
4. Alternativas para aumentar o ciclo de vida dos PCs ou utilização de Thin Clients
5. Redução de custos e imediata disponibilização de novas filiais remotas

Entre os principais clientes que utilizam a solução JETRO-COCKPIT, podemos citar a MICROSIGA/TOTVS, que  passou a utilizar o software Cockpit para prover serviços através do conceito ASP – Application Service Provider (modelo flutuante – onde mensalmente é reportado o número de usuários que utilizam a solução).

Você utiliza soluções de virtualização em sua rede ou empresa? Quer conhecer uma solução com melhor custo/benefício? Responda ao nosso formulário para que a JETRO entre  em contato e possa lhe oferecer a melhor solução para sua empresa!

Responda ao formulário da JETRO para conhecer novas opções de virtualização para sua empresa

Calliejane começou a trabalhar em uma multinacional, como analista de sistemas, há algum tempo atrás. Toda feliz, achando que tinha tirado a sorte grande, Calliejane só pensava nas vantagens: empresa grande, novos desafios, etc. Não demorou muito para os WTFs aparecerem e a emoção virar um grande sentimento de roubada: Toda a empresa era controlada por Excel e Access. Tudo. Previsão de estoque, custeio, cotações e por aí vai. Lembrnado, Calliejane trabalhava em uma m-u-l-t-i-n-a-c-i-o-n-a-l!

O que mais impressionava era que a multinacional fabricava produtos de ponta, bem caros e com multas de milhares de dólares em caso de atrasos. E, por falta de um TI eficiente, toda a estrutura do local era mantido pelo Excel e Access, alçados a verdadeiros “ERPs” pelos usuários. Tudo o que passava pela cabeça de Calliejane vendo aquele cenário infernal era “porquê que as coisas aqui na TI são tão amadoras?!?!?”.

O tempo foi passando e aos poucos a grande dúvida que assombrava o dia-a-dia dela foi sendo respondida, à medida que ela ouvia pérolas e mais pérolas da gerente, responsável por toda a TI da filial da empresa. Uma vez, enquanto levantava requisitos para a primeira tentativa em desenvolver um sistema “não-access-não-excel” na empresa, Calliejane estava tentando obter informações com o pessoal da TI da sede nacional da empresa, que ficava no Rio de Janeiro, sobre a possibilidade de desenvolver uma interface com o sistema de custos. O sistema era um módulo do ERP da Oracle, o PAC (Periodic Average Costing) – custeio de produtos. E, em uma tarde inspirada, a gerente de TI ergue uma revista Veja e pergunta: “o PAC que você está tentando acessar no Oracle é este mesmo PAC daqui da revista que o Lula tanto fala?“

Anos atrás, quando o sistema que usávamos na empresa ainda era feito em Clipper (desenvolvimento interno), havia uma pequena via crucis quando era necessário reindexar as tabelas: O usuário X reclamava que o sistema estava com problemas, eu verificava que seria necessário fazer a reindaxação, enviava para toda a rede um aviso de que seria necessário sair do sistema, ficava mais cinco minutos mandando a mesma mensagem, ligava para alguns usuários teimosos, e quando finalmente conseguia que todos saíssem, algum usuário sem-noção tentava entrar no sistema NO MEIO da reindexação, detonando TODO o banco de dados.

Quando finalmente foi liberado o orçamento para que um desenvolvedor mexesse no sistema, a primeira alteração (que eu ‘convenientemente’ considerei como crítica) foi criar uma maneira de impedir que usuários usassem o sistema ou até mesmo tentassem acessá-lo, quando fosse necessário reiniciar. O desenvolvedor surgiu com uma idéia simples: sempre que fosse necessário reindexar o banco de dados, era só criar um arquivo ‘para.txt‘ (que ‘pararia’ o sistema, sacaram? hã? hã?) que o sistema automagicamente expulsaria os usuários quando eles tentassem acessar alguma nova tela, e os impediria de entrar.

Alteração aplicada, fiz todos os testes, e funcionou perfeitamente. Para evitar problemas, apenas algumas poucas pessoas ficaram sabendo dessa nova função, assim não aconteceria de alguém criar um arquivo de parada só para causar problemas à empresa. Tudo transcorreu bem, até o fechamento do mês: do nada, o sistema começou a expulsar todo mundo durante a geração dos relatórios finais. E, não importava o quanto eu apagasse o para.txt, ele sempre voltava, poucos minutos depois.

Acusações pipocavam de todos os lados. Seria possível que alguém tivesse descoberto sobre esse arquivo? E estaria esse alguém aproveitando para causar danos à empresa? Mas… quem teria contado?

Com os ânimos exaltados, resolvi partir para a única solução: desliguei a rede, e deixei apenas uma máquina ligada ao servidor, para realizar o fechamento do mês. E lá estava o para.txt, surgindo do nada, em toda sua graça. Algumas horas depois de muita investigação, consegui descobrir o problema:

Durante o fechamento, eram impressos vários relatórios, entre eles alguns que eram divididos por cada estado/região do Brasil. O programador original do sistema, por motivos que nunca entenderei, achou que seria interessante criar um arquivo de texto com o conteúdo a ser impresso, enviar para a impressora, e logo depois apagar o arquivo. Como se a falta de noção não bastasse, ele não usou nomes aleatórios ou coisa do tipo para gerar os arquivos: no caso dos estados, era o nome do estado mesmo, sem acentos ou espaços.

Inclusive um arquivo chamado…. para.txt

Isso rolou há muitos anos, quando eu ainda era um novato. Na empresa não havia condições de comprar licenças para o MS-Office, e na época o OpenOffice ainda era algo muito mais alfa do que beta. Como as opções eram mínimas, acabei instalando como padrão um pacote gratuíto, chamado 602Office.

O 602 era, na melhor das definições, um programa que quebrava um galho, e eventualmente conseguia abrir documentos do MSOffice. Vejam bem: abrir, e não interpretar corretamente. Mas, nas condições que tínhamos, era o melhor que podíamos ter sem cairmos na pirataria.

Em um dado momento, foi necessário criar uma planilha para uma missão especial: organizar todo o sistema de fretes dos produtos, que até então era computado manualmente (e não poderia ser incorporado ao sistema). O problema é que cada empresa de transportes possuia um sistema pessoal, e parecia ser um trabalho quase impossível organizar tudo em uma planilha onde tudo o que você precisasse fazer fosse digitar a quantidade dos produtos e a transportadora, e no final ter o peso final e o valor do frete.

Muitas semanas de trabalho duro, conversas com funcionários, definição de padrões, e uma quantidade absurda de ‘IFs’ nas células depois, foi possível montar a planilha praticamente perfeita: numa aba ficavam os produtos, em outra os dados das transportadoras, e na terceira alguns dados extras, que se fossem preenchidos gerariam todos os dados necessários. E era fácil atualizar com novas transportadoras e produtos, se necessário. Detalhe: o 602 não permitia proteger planilhas.

Os dias foram virando semanas, as semanas viraram meses, e os meses viraram anos. Um belo dia, uma funcionária do comercial me liga, informando que a planilha estava gerando o valor de frete incorretamente. Ao observar o documento, pude ter uma pequena visão do inferno: campos que continham fórmulas haviam sido substituidos por números, colunas importantes estavam todas em branco, e algumas das células que deveriam trazer um valor importante estavam apagadas. Era simplesmente impossível a planilha trazer o dado correto.

Perguntei para a funcionária o que havia acontecido, e ela respondeu não saber, já que só havia começado a mexer com aquilo a poucos dias. Investigando mais a fundo, fui aos poucos descobrindo. A funcionária que originalmente foi treinada pelo uso da planilha saiu, e no processo treinou uma outra garota. Essa garota entendeu pouco do uso da planilha, e ficou por isso mesmo, até que ela precisou treinar outra, que entendeu menos ainda, e assim por diante, até que em um dado momento ninguém mais sabia exatamente como a planilha funcionava, elas apenas acreditavam que os dados ali estavam corretos, e pronto. Sempre que eu perguntava para alguém o que havia ocorrido, a resposta era a mesma “Fui ensinada assim, e sempre foi assim”.

Resultado: durante um período de tempo, todas as contas para gerar os fretes saiam com o valor errado. E, como o financeiro não conversava com o comercial, era bem provável que o valor pago era MUITO diferente do valor avaliado antes de entregar o produto.

Foi necessário criar do ZERO uma nova planilha, já que a original estava perdida. E, dessa vez, já com o OpenOffice, pude proteger algumas células. E colocar VÁRIOS avisos em células próximas células importantes, com avisos como “não mexa aqui, mesmo que sua vida dependa disso”, “use esse valor na planilha X1″, “não encoste aqui”, e por aí vai. E, sempre que a tarefa de gerar custos de frete era passada para outra funcionária, eu pessoalmente treinava a mesma para que não houvessem novos desastres…

Lealcy pensa em fazer um downclock do computador, para conseguir instalar uma simples impressora:

Clique na imagem para ampliar

Juliano ficou feliz de ter poder de escolha. Pena que, como podemos ver, era um poder bem limitado:

Clique na imagem para ampliar

Rafael mandou uma imagem de erro muito, mas muito estranha do Delphi:

Sub_Zer0 conta uma história que faz pensar na importância de escolher um bom provedor:

Trabalho no desenvolvimento PHP para uma empresa de médio porte, que hospeda os sites de clientes em um servidor terceirizado. Um belo dia, percebi que, para fechar um job (Nota do admin: “Deus, como eu odeio esse termo), eu precisava do Smarty. Só que o servidor não tinha nada configurado.

Como não tinha como não usar o Smarty, abri um chamado no servidor, dizendo que precisava da biblioteca instalada, e dizendo que o mesmo podia ser baixado no endereço http://www.smarty.net/ – e continuei o desenvolvimento na minha própria máquina

Horas depois,  recebo um email dando o chamado como concluído, e a seguinte mensagem do suporte:

Informo que o domínio já foi adicionado em seu painel. Qualquer configuração adicional pode ser efetuada diretamente por ele. Grato.

Sem entender nada, vou até a administração do servidor e descubro que, ao invés de instalar a biblioteca Smarty no servidor, ele configurou o domínio smarty.net no servidor! Do jeito que estava, era só alguém alterar o DNS do domínio, que responderia normalmente!

Depois de alguns minutos atônito, resolvi ligar para o suporte e explicar da forma mais clara possível o que eu realmente queria…

Essa é a prova de que o Windows é o melhor gerador de WTFs da história: veja como é simples, em pouquíssimos passos, burlar o sistema de senhas no Windows (pelo gif animado, me parece ser o Win98, mas imagino que não seja difícil fazer o mesmo em outras versões…).

Clique na imagem para ver o gif animado.

Imagem retirada daqui: http://i33.tinypic.com/20ksw89.gif