Software By Developer

2011-12-21T10:02:00.000-08:00

Hoje após duas horas desesperantes, descobri a solução para o problema do scrollTop no IE8, quando é usado dentro de um 'SELECT'.

Basicamente, no IE8 quando se adiciona um elemento 'OPTION', via Javascript a um 'SELECT' que seja do tipo 'multiple' (nota: estou a usar um 'size' de 10), não posiciona a scroll bar, de forma a mostrar o elemento 'OPTION' que foi inserido (já pré-selecionado).

Isto tem o inconveniente de o utilizador não se aperceber que o elemento foi realmente adicionado, se a combo não estiver na posição ideal.

Note-se que estou a inserir os elementos ordenados alfabeticamente, logo a inserção poderá ocorrer em qualquer posição, dependendo dos elementos já existentes e do elemento inserido.

Para corrigir este problema de usabilidade, defini o seguinte código após ter efectuado a inserção no 'SELECT', dentro de um objecto JS que o contém:

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll; // <=- linha problemática
   }

No entanto, após fazer debug da coisa, a 'linha problemática' aparentemente não executa !!!
Isto é, mesmo que o valor topScroll seja diferente de zero, o campo 'this.select.scrollTop' fica intocado.
É como se a instrução nunca tivesse sido executada !!!

Após perder umas centenas de neurónios, reparei que se eu forçar o valor no debugger a correcção funcionava !

Após mais algumas tentativas, para perceber o problema, cheguei ao momento Eureka!

O IE8, pega de empurrão!

Isto é a solução é insistir à canzana ! :)
Ou seja, repetir a instrução de atribuição !

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll;
      this.select.scrollTop = topScroll; // WE MUST DUPLICATE THIS LINE, due to an IE8 Bug !
   }

Incrível, mas é verdade ! E assim já funciona como esperado e é inócuo para os outros browsers, como seria de esperar.

Java decompiler para o Eclipse

2011-09-22T08:44:00.000-07:00

O Eclipse Java Decompiler pode dar jeito, quando ao meio do debug, nos deparamos com uma classe de uma lib (jar) qualquer, da qual não temos a source disponível.
Permite fazer o decompile da class enquanto fazemos debug, para determinar a fonte do problema.

IE8 Document Mode é Sticky !

2011-08-09T10:30:00.000-07:00

Mais uma "feature" do IE8!
Se tivermos uma página simples, que abrimos em dois tabs, mas no primeiro tab definimos o URL como 'localhost' e o outro tab com o URL com o nome da máquina propriamente dito ("wheat", no exemplo).

Vamos constatar que o IE8, vai fazer o 'render' da página com margin e offset distintos, para a tag BODY.

A página está definida com o seguinte DOCTYPE:


Após mais alguns testes, acabei por descobrir que o problema não era do URL, mas sim devido ao facto de ter reutilizado um tab (alterando o seu URL), que conteve anteriormente uma página que forçou o modo de compatibilidade 'IE7' no IE8, com o seguinte meta dado no head !

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

Resumindo e concluindo, o modo de compatibilidade aparentemente é uma propriedade do tab, e que não muda com a alteração do endereço (URL), como devia.

Isto implica que uma página que faça um render correcto, seguindo os standards, pode ficar completamente desfigurada no IE, se o tab tiver sido usado para aceder a outra página previamente, que tenha forçado o modo de compatibilidade do IE.

IE8 não gera evento form submit, em certas condições

2011-07-22T02:25:00.000-07:00

Ultimamente, tenho andado a dançar o fandango com o IE8, ao fazer um 'port' de uma aplicação IE6 para IE8.

Infelizmente os bugs são mais que muitos: James Hopkins IE8 Bugs e Gérald Talbot's IE8 Bugs chegam para ter uma ideia dos problemas que se tem pela frente, já para não falar nos modos de (in)compatibilidade, que o bicho trás para o IE7.
Estranho é que alguns anos após o lançamento do IE8, a grande maioria dos problemas continua por resolver.

Mas voltando ao que interessa, o IE8 tem outro BUG ainda não documentado que consiste na falha em gerar um evento de 'submit' num form, em certas condições.

Se tivermos o seguinte código, o IE8 gera o evento 'submit' correctamente:

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input type="submit" value="Submit" />
</form>

Mas se quisermos adicionar um botão adicional, para por exemplo limpar o form (exemplo simplificado), o evento já não é despoletado.
NOTA: A implementação da funcionalidade em 'javascript' não é mostrada.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iClear" type="button" value="limpar" />
 <input id="iSubmit" type="submit" value="Submit" />
</form>

E isto acontece apenas e somente, porque o IE8 não gosta que exista nenhum INPUT do tipo 'button', antes de um INPUT do tipo 'submit'. Isto é. aparentemente o IE8 procura o primeiro botão disponível e activa-o, mas se não fôr um botão do tipo 'submit', o form não é submetido, pois activa o botão errado.

A solução passa por ter o INPUT com o type='submit' aparecer em primeiro lugar no HTML.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iSubmit" type="submit" value="Submit" />
 <input id="iClear" type="button" value="limpar" />
</form>

Se não gostarem do botão à esquerda, até por questões de usabilidade, podem sempre posicionar os botões por css com um float:right, que na pratica vos inverte a ordem relativamente a existente no HTML.

Tabela com múltiplos THEAD versus TBODY (IE Quirk)

2009-09-30T03:41:00.000-07:00

Caso se crie uma table com mais do que um thead, algo deste género:

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
 </thead>
 <thead class="days">
  <tr>
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>TESTE</td>
    ...
  </tr>
  ...
 </tbody>
 <tfoot>
  ...
 </tfoot>
</table>

Tudo funciona perfeitamente (em FF3.0.14 ou no IE6.02900), inclusive aplicar CSS específico ao thead cuja class="days".

Mas se tentarem aceder por javascript ao array the objectos tBodies da tabela, as coisas ai mudam de figura.

var myTable = document.getElementById( 'myTable' );

var rows = myTable.tBodies[0].rows;

alert( 'Dados da primeira coluna do body = ' + rows[0].cells[0].innerHTML );

No caso do FF, retorna exactamente o esperado "TESTE", no entanto, no caso do IE vai retornar "4" ou seja, o conteúdo da primeira coluna do segundo thead.

Isto acontece porque o IE, erradamente associa o segundo thead (days), como se fosse o primeiro tbody, o que claramente não é, inclusivamente é incoerente com a aplicação de estilos, que essa sim funciona correctamente.

A solução para o problema, passa por fugir dele :) isto é, evitar o uso do thead adicional, e aplicar o estilo (class) directamente no tr. Não esquecer de actualizar o CSS de forma a corresponder com a alteração efectuada.

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
  <tr class="days">
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
  ...
</table>

JSPs e comentários

2007-12-19T08:30:00.000-08:00

Comentários em JSPs pode não ser tão linear como deveria ser. Vejam o código seguinte:

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
// usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> )
...
%>

À partida parece estar tudo bem, mas não está, porque o pre-processador das JSPs não gosta de tags embebidas (<% ... %>). Como executa/processa antes do compilador Java, e não considera os comentários java (// ou /* ... */) caput!
A solução passa então por comentar usando comentários JSP.

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
<%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%>
...
%>

Mas novamente, esbarramos com a limitação das tags embebidas não serem suportadas pelo Pre-processador JSP. Vamos resolver o problema fechando e abrindo o bloco envolvente de forma a evitar que um bloco fique contido no outro:

<%
...
SimpleDateFormat javascriptDateFormat = new SimpleDateFormat( "yyyy, (MM-1), dd" );
%> <%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%> <%
...
%>

E agora já funciona e até seria um resultado expectável, não fosse haver aqui algo estranho!
A formatação da data, que está em código JSP, está dentro de um comentário JSP, ora reparem bem:

<%-- // usage: var mydate = new Date( <%= javascriptDateFormat.format( myJavaDate ) %> ) --%>

Ou seja, tags para código JSP (<% ... %>) podem estar contidas em comentários JSP (<%-- ... --%>), mas o inverso não é verdade !
Confuso no mínimo.

CSS - IE6 versus Selector de Atributos

2007-12-17T10:20:00.000-08:00

O IE6 não suporta CSS "attribute Selectors", como no exemplo seguinte:

div.Field input[type="text"]
{
   color: blue;
}

Assim, temos que circundar o problema, e a solução mais comum, é adicionar uma class específica para o caso que queremos resolver, e atribuir a class ao elemento respectivo, por exemplo:

div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Passamos então a representar o conteudo da seguinte forma:

<div class="Field">
   <label for="Name">Nome</label>:<input class="Text" type="text" id="Name" value="">
</div>

Mas numa perspectiva futura, podemos querer suportar ambas as regras, com algo como o seguinte:

div.Field input[type="text"],
div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Perfeitamente válido ! Certo ?
Sim, é perfeitamente válido segundo o standard; Mas não, não funciona no IE6!
E de nada vale trocar a ordem das regras, dado que o comportamento é exactamente o mesmo.

O problema é devido ao IE6 rejeitar as regras que não suporta, conjuntamente com qualquer outra que lhe esteja associada.

Para resolver o problema temos que duplicar as formatações, de forma a que a rejeição da regra não suportada, não afecte as restantes, ou seja:

div.Field input[type="text"]
{
   color: blue;
}

div.Field input.Text /* IE6 Does NOT support attribute selector */
{
   color: blue;
}

Saber isto pode poupar-vos muito tempo :)

Validação de Parametros

2007-11-13T07:04:00.000-08:00

Hoje deparei-me com o seguinte Código Java numa página JSP:

boolean bDisabled = (new Boolean ((String) (request.getParameter("bDisabled")))).booleanValue();

É mais um caso de conversões implícitas, usadas abusivamente. Mas desta vez o programador, gostou de complicar a coisa, para além do razoável.
Nomeadamente, é preciso que quem chame a página, saiba exactamente, qual é a conversão implícita esperada, que é "true" para true e "false" para false, e tem que respeitar o case.
Assumindo eu, que é válida a seguinte afirmação:

Se não é "true" é implicitamente "false".

Então podemos optar por algo bem mais simples.

boolean bDisabled = "true".equals( request.getParameter( "bDisabled" ) );

A vantagem é óbvia em termos de legibilidade e eficiência.
Nota: No caso em que o parâmetro não é enviado, assumimos que seja equivalente a false, o que é uma assumpção razoável, mas que validei no código existente como perfeitamente válida.
Caso não fosse, bastaria testar esse caso também, e gerar uma excepção para qualquer outro caso, por exemplo.

Estruturas de dados em Javascript

2007-11-02T10:17:00.000-07:00

Aqui temos mais um caso típico de código Javascript:

for (i=0;i < arrParameterRange.length ; i++)
{
    // set the temporary variables, to improve the code readability
    sParamFormat    =  arrParameterRange[i][0];
    sParamRangeFrom =  arrParameterRange[i][1];
    sParamRangeTo   =  arrParameterRange[i][2];
    ...
    alert(  sParamFormat + " for range " + sParamRangeFrom + " : " + sParamRangeTo );
    ...
}

O que me levou a escrever sobre este código foi o comentário que lhe está associado.
De facto a intenção é boa, mas estão a tentar resolver o problema errado.

O problema deste código reside na forma como os dados estão a ser guardados, nomeadamente estão a usar Arrays de Arrays.
A inicialização típica destes arrays é algo como o código seguinte:

var arrParameterRange = new Array();
arrParameterRange[0] = new Array( 'DumbFormat', 'DumbFrom_0', 'DumbTo_0' );
arrParameterRange[1] = new Array( 'DumbFormat', 'DumbFrom_1', 'DumbTo_1' );
...

E isto depois implica código semelhante ao que vimos no início, com indices HardCoded por todo o lado, que não é nada fácil de ler, expecialmente quando temos sub Arrays com dimensão 10 ou mais, pois nós humanos perdemos a capacidade de associar eficazmente os indices com os dados.

Curiosidade: Está provado experimentalmente que o limite do humano médio é de 7 itens. Isto é relevante em questões relacionadas com usabilidade (número máximo de opções de um menu, por exemplo), assim como em outras aplicações.

alert( arrParameterRange[i][2] + " : " + arrParameterRange[i][3] );

Existem alguns programadores mais iluminados que tentam dar a volta ao problema, definindo "constantes" para usar para os indíces, mas novamente estamos a resolver o problema errado.

var RANGE_IDX_FORMAT = 0;
var RANGE_IDX_FROM = 1;
var RANGE_IDX_TO = 2;
...

alert( arrParameterRange[i][RANGE_IDX_FROM] + " : " + arrParameterRange[i][RANGE_IDX_TO] );

O problema que deviamos estar a resolver, era como estruturar correctamente os dados. E para isso temos objectos em Javascript, que servem a sua função, mas que também servem para dar nomes aos dados, nomeadamente às propriedades do objecto. Isto porque Objectos sem métodos são equivalentes a estruturas (dado que é tudo público, em Javascript).

Então vamos definir um objecto em Javascript para guardar os nossos dados:

var ParamRange = function( format, from, to )
{
    this.format = format;
    this.from = from;
    this.to = to;
}

E com esta simples alteração, já conseguimos código legível e fácil de manter:

var arrParameterRange = new Array();
arrParameterRange[0] = new ParamRange( 'DumbFormat', 'DumbFrom_0', 'DumbTo_0' );
arrParameterRange[1] = new ParamRange( 'DumbFormat', 'DumbFrom_1', 'DumbTo_1' );
...

for( i=0; i < arrParameterRange.length ; i++ )
{
    var paramRange = arrParameterRange[ i ];
    ...
    alert( paramRange.format + " for range " + paramRange.from + " : " + paramRange.to );
    ...
}

Claro está que o melhor seria mesmo definir métodos para isolar as propriedades do objecto, e providenciar as funcionalidades necessárias, mas este tema já vai longo e ainda tinha muito que escrever se fosse por ai.

Conversões implícitas

2007-11-02T09:40:00.000-07:00

Recentemente deparei-me com o seguinte código numa JSP (Java+Javascript):

if( <%= sTestParam.equals("true") %> )
{
 ...
}

À primeira vista não parece haver problema nenhum com este código, mas este código é tudo menos intuitivo por usar uma conversão implícita abusivamente e por assumir um pressuposto que não é garantido na especificação do Java.

Se olharmos com cuidado, temos um metodo que nos devolve um booleano (Java), que por sua vez devido ao método de embeber resultados numa JSP ( <%= ... %> ) é implicitamente convertido para String (Boolean.toString), que retorna "true" ou "false", e que finalmente é usado como código Javascript, que mais tarde o browser interpretará como um booleano novamente.

O problema principal é isto tudo ser muito obscuro, mas existe também um problema subjacente potencial, é que não existe garantia nenhuma que as futuras versões do Java continuem a converter um booleano implicitamente para "true" ou "false", isto pode mudar e depois este código deixa de funcionar, é pouco provável mas possível.
Como exemplo puramente ilustrativo, poderia passar a retornar "True", "_true_" ou "'True'" ou "Vero" par uma implementação italiana.
javascript:void(0)
A solução seguinte é bem mais intuitiva e explícita, e sem usar qualquer conversão implícita:

<% if( sTestParam.equals("true") ) { %>
 ...
<% } %>

Ter em atenção que conversões implícitas são úteis e até facilitam o trabalho, quando bem aplicadas. Mas como em tudo, quando se abusa das ferramentas e da sua função, acaba por se perder os benefícios e eventualmente criar problemas.

Sem comentários

2007-10-22T07:08:00.000-07:00

Hoje deparei-me com o código Javascript seguinte:

function returnFalse()
{
    return false;
}

Validação de Strings

2007-10-22T06:19:00.000-07:00

É muito frequente encontrar código java semelhante ao seguinte:

if( myStr != null && myStr.equals( "TestString" ) )
{
...
}

Embora o código esteja correcto, é uma pattern recorrente que pode e deve ser simplificada, como na sugestão seguinte:

if( "TestString".equals( myStr ) )
{
...
}

Isto funciona, porque "TestString" existe sempre por ser uma constante (literal), e dado representar um objecto, podemos sempre chamar o metodo equals(...) que por sua vez sabe lidar com o caso de o parâmetro ser null.

Existem ainda situações semelhantes, por exemplo:

if( myStr != null && !myStr.equals( "" ) )
{
...
}

Que podem ser simplificadas de forma a serem mais eficientes, como sugerido a seguir:

if( myStr != null && myStr.length() > 0 )
{
...
}

NOTA: Comparar com a String vazia é menos eficiente, mas se preferirem podem usar a sugestão seguinte, por ser mais concisa.

if( !"".equals( myStr ) )
{
...
}

Ingenuidade versus desempenho

2007-10-15T11:05:00.000-07:00

A ingenuidade de alguns programadores, relativamente à forma como as linguagens funcionam a baixo nível, trás muitas vezes impactos inesperados no desempenho das aplicações.
Vou mostrar um exemplo típico, que se encontra frequentemente em Javascript, uma função que usa um ciclo for para gerar uma lista de valores separados por virgulas.

function getValidZoneList()
{
 var zoneList = '';

 for( var i=0; i < arrValidZone.length; ++i )
 {
   if( zoneList == '' )
     zoneList  = arrValidZone[ i ][ 0 ];
   else
     zoneList += ', ' + arrValidZone[ i ][ 0 ];
 }
 return zoneList;
}

O primeiro problema com que nos deparamos é o teste

( zoneList == '' )

, que é tipicamente mais lento que testar

( zoneList.length == 0 )

O segundo problema é fazer testes desnecessários dentro dos ciclos!
Neste caso concreto o teste só é necessário, para determinar se precisamos de adicionar o separador virgula no caso de já termos algum elemento na lista. O facto é que este teste só é relevante no primeiro elemento, sendo falso para todos os restantes.

Se a função fosse implementada da forma que se sugere a seguir, aumentaria significativamente o seu desempenho, pois fariamos apenas um único test, no início:

// returns a comma separated String with the list of Valid Zones
function getValidZoneList()
{
 var zoneList = '';

 if( arrValidZone.length )
 {
   var i = 0;
   zoneList += arrValidZone[ i ][ 0 ];

   for( ++i; i < arrValidZone.length; ++i )
     zoneList += ', ' + arrValidZone[ i ][ 0 ];
 }
 return zoneList;
}

Debug "Artesanal"

2007-10-15T08:34:00.000-07:00

Quantos de nos já não fomos forçados ao método de debug "Artesanal", de fazer prints pelo meio do código. À falta de melhor solução, sempre é uma solução, ainda que pobre.

Mas hoje deparei-me com o seguinte, numa tag Body (HTML):

onload="javascript:window.open('about:blank').document.write('<pre>' + document.documentElement.outerHTML.replace(/</g, '<') + '</pre>');"

A ideia desta alma é fazer debug numa janela à parte, atráves de um dump do html/código gerado.
A motivação é clara, pois trata-se de uma página gerada dinâmicamente, e que neste caso inclui geração dinâmica de Javascript, outch!
O "único" problema é que ao fazer isto, qualquer Javascript embutido na página vai deixar de funcionar, dado que todas as variáveis e funções definidas, não o foram, logo vai dar sarna para o "inventor" se coçar, com todas as mensagens de erro que irá receber.

"Martelar"

2007-10-12T04:53:00.000-07:00

O termo "martelar" pertence ao calão informático Português e refere-se ao acto de alterar uma aplicação de uma forma rápida, localizada e sem grandes cuidados estruturais.
Normalmente resulta numa solução suficiente, mas não propriamente ideal, na medida em que não tem em consideração o código circundante ou desenvolvimentos futuros.

Estou a "martelar" o código.

É uma analogia com a profissão de Carpinteiro, mais concretamente ao acto de martelar um prego, supostamente uma actividade que não requer grande destreza ou cuidado, para obter um resultado minimamente satisfatório.

Termos relacionados:

"martelanço"
O acto de "martelar".

Estou no "martelanço".
"martelado"
O estado final do código depois da intervenção.

Este código está todo "martelado".

Esta "técnica" é tipicamente usada em situações de urgência/falta de tempo, nomeadamente quando se está em cima dos prazos de término dos projectos, quando já não há tempo para estruturar correctamente o código.

Infelizmente encontram-se com alguma frequência, "Carpinteiros de Software" a tempo inteiro.

IE 6 window.opener Javascript BUG

2007-10-11T11:02:00.000-07:00

Há males que vêm por bem.

Já me aconteceu inumeras vezes ao fazer debug do IE 6 (6.0.2900.2180.xpsp_sp2_gdr.070227-2254) usando o "Microsoft Script Editor (10.0)" determinar que o object window.opener não está definido quando deveria estar, nomeadamente no documento carregado dentro de uma Iframe.
A atitude natural e expectável é culpar o browser (IE), pois já faz tanta coisa mal, que é só mais uma. Assim sendo arranja-se uma forma de circundar o problema.
Mas hoje descobri o cálice dourado :)

O culpado desta vez é o debugger "Microsoft Script Editor".

Se o debugger estiver activo durante a execução de uma instrução que envolva window.opener este objecto não está definido (undefined).

Mas se só chamarmos o debugger depois de executar essa linha, ou simplesmente não lançar o debugger, o código com o window.opener executa sem problemas, pois este encontra-se correctamente definido.

O seja, no caso seguinte window.opener não está definido e dá erro, no debugger:

function GiveZipCode( zipC, cityN, streetN )
{
debugger;
window.opener.fillBoxes( zipC, streetN, cityN );
...
}

desta forma o window.opener JÁ ESTÁ CORRECTAMENTE definido e funciona:

function GiveZipCode( zipC, cityN, streetN)
{
window.opener.fillBoxes( zipC, streetN, cityN );
debugger;
...
}

Para os mais incrédulos, basta chamar o debugger dentro da função fillBoxes() que ele para lá dentro, sem qualquer problema, ou seja conseguiu aceder ao window.opener, logo está definido.

"Bombar"

2007-10-10T06:24:00.000-07:00

O termo "bombar" pertence ao calão informático Português e refere-se ao facto de uma aplicação ou programa estar finalmente a executar sem problemas (conhecidos).

Está a "bombar"

É uma analogia ao funcionamento de uma bomba usada num poço, para extrair água.
Quando está a funcionar existe "output" (água) na saída.