Diário de um programador WEB

Google Chrome - A Google entra na guerra dos Browsers

2008-09-03T12:26:00.000+01:00

O Google lançou ontem um novo browser o Google Chrome, mas no dia 1 de Setembro tinha lançado esta comic que aconselho a lerem atentamente.

Têm aqui um print-screen da página inical da comic:

Ainda não fiz um teste como deve ser, porque só o descobri hoje de manhã, e estou no escritório. Onde há muita coisa para fazer.

A única coisa que testei, foi abrir uma página que estou a desenvolver, para ver se notava alguma diferença a nivel de layouts para o Firefox ou IE, não notei nenhuma diferença, mas também não foi um olhar clínico...

Pelo que li da comic, o Google Chrome usa o mesmo motor que o Safari, o que me parece bastante interessante, o Safari está bem cotado em relação aos Web Standards, o que no final, vai facilitar a vida, a nós programadores WEB.

Já sabem o que têm de fazer, experimentem-no...e vamos ver se a Google lançou um browser capaz de fazer concorrência ao Firefox, IE e Opera ( só para nomear os mais conhecidos ).

A List Apart - The Survey 2008

2008-08-04T15:00:00.001+01:00

Para quem não sabe a "A List Apart", é um website, onde se publicam vários artigos relacionados com WEB, deste a programação de Javascript até ao Design, e citando:

“For people who make websites”

A List Apart Magazine (ISSN: 1534-0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.

Desde que a descobri que tenho tenho lido os vários artigos que eles vão publicando, vale a pena acreditem.

O que interessa é que eles lançaram um questionário para quem trabalha na área da WEB. O ano passado também o fizeram, podem ver aqui os resultados.

Preencham o questionário, não demora mais do que 15 minutos.

A vida está difícil...

2008-07-27T22:58:00.001+01:00

...para um programador WEB!

Estou a implementar um novo site, para um dos clientes da nossa empresa...

E estou a tentar utilizar apenas div's para o fazer, ou melhor no inicio estava, neste momento tenho um misto de de div's e tabelas...

E porquê? Porque causa dos 3 browser's que testo ( FF, IE7 e IE6 ), embora o IE7, já se comporte praticamente de forma igual ao FF para a maior parte do código HTML que metemos na página, ainda existem algumas coisas que falham...sobre o IE6, nem vale a pena falar...

O incrível, é que existem montes de pessoas que ainda o continuam a usar. E não tarde muito terei 4 browser's para testar! ( Isto quando sair o IE8 ).

E sim só testo em 3 browser's diferentes, podem tentar crucificar-me à vontade. E porque é que só testo para 3 browser's? Porque simplesmente não há tempo, bem que gostava de testar no Opera ( está instalado só para eu dar uma olhadela de vez em quando ) e também gostava de experimentar no Safari. Só que se me ponho a testar em todos os browser's nunca mais despacho o trabalho que tenho para fazer.

É que se formos bem a ver ( da perspectiva de um gestor ), o que interessa é que o trabalho fique feito, esteja apresentável, e que seja feito o mais rápido possivél... ( pelo menos é a experiência que eu tenho ).

Ou seja, a vida está díficil para um programador WEB...

Firefox 3 já saiu!

2008-06-18T15:17:00.002+01:00

Que bela supresa hoje! O Firefox saiu ontem!

Até querem fazer um recorde do Guiness, o de o software mais descarregado da internet num dia!

Podem ver aqui, e fazer o download como é lógico.

Projectos e Atrasos...

2008-06-17T20:47:00.001+01:00

Este é um assunto complicado. Principalmente em casos onde não existe nenhuma metodologia de desenvolvimento como "Agile Software Development".

Nestes casos, quem é que tem a culpa? É o programador? É o gestor de projectos?

Melhor ainda, como é que se avalia a culpa num projecto atrasado?

Acho que é impossível de se avaliar a culpa de um atraso num projecto, pelo menos na maior parte dos casos. A não ser que aja mesmo um grande erro de um dos lados.

A meu ver a culpa pode ser atribuída aos dois, ao gestor porque não geriu bem o tempo, não explicou precisamente o que era necessário fazer. Ao programador porque demorou mais tempo do que devia a fazer certas partes da aplicação.

Quem é que deve ser responsabilizado? Depende do caso, mas eu diria que a maior parte das vezes deve ser o gestor, o gestor é o responsável pelo projecto, é ele quem coordena, organiza, planeia todo um projecto. O gestor tem de ter em conta tudo o que se possa passar com os programadores à sua volta.

Isto aconteceu-me no último projecto onde estive envolvido, que finalizei hoje!

O que é que aconteceu?

Eu comecei a desenvolver o script, e acabei-o em 3 dias. Tinha feito de acordo com as especificações que me tinham dado.

No entanto quando foi altura de mostrar ao gestor para ver se estava tudo em ordem, não estava. Afinal o que era um script aparentemente fácil de executar sem grandes complicações, deixou de ser. Passou a existir uma quantidade enorme de cálculos com datas ( basicamente aplicar operações de conjuntos a vários intervalos de datas várias vezes com diferenças entre intervalos de datas, uniões e etc's... ).

Ou seja maior parte do que tinha sido feito, foi simplesmente para o lixo. Toca de refazer praticamente todo o script de novo.

Claro que aplicar todas estas operações no script não foi tarefa fácil, e como é lógico atrasou logo tudo montes de tempo.

Aqui a culpa é de quem?

Em parte também é minha, porque se calhar devia-me ter informado melhor sobre o que estava a fazer, de maneira a não ter que refazer o script outra vez.

Do gestor, por não ter enunciado logo tudo o que o script envolvia, fazendo-me perder tempo, por ter desenvolvido 2 maneiras completamente diferentes.

Quem é que paga?

Paguei eu ( que sou o programador ), que tive de vir trabalhar 6º feira ( feriado ) umas duas horas porque o gestor me andava a apertar os calos. ( Embora ache que não tenha culpa no cartório, pelo menos neste caso, e não devia ter ido ).

Pagou o gestor, porque lhe atrasou tudo o que tinha planeado.

Paga o cliente, porque em vez de pagar 3 dias de trabalho, vai pagar mais.

Soluções para que isto nunca aconteça? Pelo que estive a ler sobre "Agile Software Development", parece que é uma boa aposta, partir o software em várias tarefas minúsculas e só passar para a próxima após a anterior estar completa e testada.

Tenho é impressão que o meu gestor de projecto não vai achar grande piada ( até porque lhe ia aumentar bastante o trabalho )

Um bom link para se irem entretendo sobre desenvolvimento de produtos "Managing Product Development", tenho acompanhado o blog e tenho gostado bastante.

Decisões inteligentes...

2008-03-16T20:51:00.000Z

Esta 6º feira passada, estive a conversar com um professor, que foi prejudicado pelos concursos de colocação de professores, ou melhor prejudicado pelo software onde o concurso foi efectuado.

O problema aqui, é que os engenheiros/ministros/quem quer que seja que está à frente do sistema, teve uma ideia brilhante:

"Não vamos correr o software novo e o antigo ao mesmo tempo, para ver se dão os mesmo resultados! Vamos mas é correr só o novo software e logo se vê."

Como podem imaginar deu barraca e não se podia esperar outra coisa, toda a gente sabe que qualquer software desenvolvido, trabalha bem no servidor de testes, agora quando passa para o servidor de produção, aparece sempre qualquer coisa.

Gostava de saber como é que é possível, aquelas mentes brilhantes, fizeram isto, ora toda a gente sabe, que testa-se sempre primeiro um software em produção. Mantendo o sistema antigo a funcionar, para se poder comparem os dados tanto de um como de outro. Para se ter a certeza que o novo está a funcionar a 100%.

Claro que podem ter existido mudanças na maneira como era feito o concurso, mas mesmo assim... há que ter os 2 sistemas a funcionar para se ter a certeza que o novo software trabalha bem.

Não admira que exista montes de gente a queixar-se dos concursos de colocações dos professores...

IE8

2008-03-06T22:12:00.004Z

Pelos vistos, parece que a Microsoft ganhou juízo, e ainda bem!

Finalmente, vê-se a Microsoft a dar um passo na direcção certa, o que me deixa bastante feliz, e quase de certeza que deixa também muita gente.

Lembram-se daquela história, que sempre que construíssemos uma página, tínhamos obrigatoriamente que por um header, para se poder usar a última versão possível do IE? E que se não usássemos nada, iria renderizar a página como se estivéssemos a vê-la no IE7?

A Microsoft, tomou ( a meu ver ) a decisão certa, se não tiver header nenhum o IE8, vai renderizar sempre no motor mais novo, claro que podemos continuar a "trancar" o modo de render da página, bastando para isso usar os headers.

Fico contente por a Microsoft, ter ouvido a comunidade, e ter tomado a decisão certa, será que vamos ter uma reviravolta na guerra dos browsers??

Embora muita gente, continue sem conhecer alternativas ao IE, muita gente nova, está cada vez mais receptiva às novas tecnologias, e procura alternativas.

Sem dúvida nenhuma, que o futuro, parece bem melhor face a estas novas revelações.

Conselho...

2008-03-03T21:55:00.004Z

Só vos dou um conselho:

Se tiverem uma ideia, executem-na, mal tenham tempo para a fazer, porque senão podem acontecer várias coisas:

Transformam a ideia original, em algo que não vos agrada mesmo nada.
Não vos dão o apoio necessário, para a executarem, e ficam a pensar que a ideia não é realmente grande coisa.

Por exemplo:
Em meados de Dezembro, tive a ideia, de um site que tivesse o preço dos combustíveis, nas várias zonas do país, um sítio, onde qualquer pessoa podesse ir ver/inserir os preços que viu nas bombas que costuma visitar.

Depois de pensar um pouco nisso, decidi apresentar a ideia à chefia, da minha empresa para saber o que achavam, se tinha pernas para andar, se queriam entrar etc etc..

O consenso não foi lá muito favorável, para além de quererem logo construir algo que não estava mesmo na minha ideia original, para além de que tinham de existir lucros o que não me interessava, pelo menos no inicio, e o projecto foi para a gaveta.

Foi para a gaveta, também por minha culpa, que deixei de pensar nisso, e como fazia falta o apoio, deixei andar até ter mais tempo, para o poder executar como deve ser.

Ontem um amigo mostrou-me um site: http://www.maisgasolina.com, e por incrível que pareça é exactamente aquilo que eu tinha idealizado, com menos umas coisas da minha ideia.

Ou seja, perdeu-se/perdi uma excelente oportunidade para fazer algo com bastante interesse, e que poderia ter bastante sucesso. Vamos ver se o site tem o sucesso que eu esperava que o meu tivesse.

Registem-se, e actualizem os postos em que passam.

Repetindo, se tiverem uma ideia, falem com dois ou três amigos, para saberem o que acham. E depois executem-na sem dó nem piedade, porque oportunidades são realmente muito poucas.

Altura a 100% de uma div.

2008-01-29T21:10:00.000Z

Parece-me que existem bastantes dúvidas de como por uma div com altura de 100%, ou seja de modo a ocupar toda a altura de uma janela do browser.

Então deixo aqui um pequeno tutorial de como o fazer.

Primeiro vamos definir o css:

html {
height: 100%;
}

body {
margin:0px;
padding:0px;
height:100%;
background-color:#000000;
}

#main {
min-height:100%;
height:auto;
margin:0px auto;
width:500px;
background-color:#666666;
color:#FFFFFF;
}

/* Para o IE */
* html #main{
height:100%;
}

Explicando, para a nossa div, poder ter todo o tamanho do browser é necessário, que o parent neste caso o body tenha também a altura de 100%, por isso é que o body e html têm a altura de 100%.

Está lá o hack para o IE, porque sem ele o que acontecia era que a div ficava apenas com o tamanho do conteúdo.

Agora temos o código HTML que é muito simples:

<div id="main"> Conteúdo<div>

Como se pode ver é extremamente simples, por uma div com a altura a 100%. Podem ver o demo aqui ( sem conteúdo suficiente para encher a página ) e aqui ( com conteúdo suficiente para fazer aparecer a scroll bar vertical ), e fazer o download aqui do código de ambas as páginas.

Esta é um dos 2, 3 métodos que existem para criar div's com 100% de altura, e de entre eles, este é o mais fiável. Pelo que testei.

Aproveito também para dizer, que já criei uma sandbox, para poder mostrar os demos funcionais do código que for postando aqui. Podem vê-la aqui: http://lancaster.freehostia.com/

O futuro do IE

2008-01-23T21:58:00.000Z

Dia 21 deste mês, foi um dia em grande, para a comunidade que desenvolve para a WEB, e tudo por causa de um artigo da autoria de Aaron Gustafson escrito no A list Apart intitulado Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8.

O DOCTYPE, para quem não sabe, é usado basicamente para o browser saber em que modo há-de renderizar a página que lhe estamos a passar, se usarmos um DOCTYPE válido e completo, o browser tenta mostrar a página no modo "Standard" ( fazendo com que tudo apareça tal como está escrito nas especificações ), se no entanto não existir uma declaração de DOCTYPE válida ou incompleta, ele vai mostrar a página no modo "Quirks", ou seja como se estivesse a ser vista no IE 4.0 ( ou algo parecido ). O DOCTYPE é também usado para fazer validar as páginas, definindo assim qual o "markup" que estamos a utilizar por exemplo: "XHTML 1.0 Transitional".

A equipa que está a desenvolver o IE8, queria seguir a máxima "Don’t Break the Web!", e no que é que isto resultou?

Decidiram implementar um header que indica ao browser qual o motor que deve utilizar:

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

E desta maneira, quando o IE8 ( ou outra versão superior ao IE8), olhar para este header, vai usar o motor do IE8 para mostrar o conteúdo da página.

Existe também um parâmetro para quando se quer usar o último motor disponível:

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

O curioso é que se não incluirmos nenhum destes header's na página, o IE vai mostrar a página usando o motor do IE7.

E aqui é que está o problema. Por um lado tem as suas vantagens, já não é preciso estar a verificar um site, de uma ponta a outra para ver se está tudo bem, e se não tiver, têm que se estar a perder horas e horas de trabalho, para resolver pequenos problemas de design. Mas mantém-nos ( a nós programadores para a WEB ), atentos ao que se passa no resto do mundo o que é uma grande vantagem.

Mas por outro lado, também atrasa um pouco o desenvolvimento dos padrões "Standard", isto porque a tendência, será usar sempre o motor do IE7, porque muita gente não vai usar o header ( existe muita gente a usar o FrontPage, e espantem-se o Publisher para criar páginas ), logo tudo o que tenha sido desenvolvido ( Javascript, e mais importante CSS ) após o lançamento do IE7, não vai funcionar a não ser que se ponha o header correcto.

Para finalizar, a opção default, deveria ser: "Usar sempre o último motor". E no caso de não querermos modificar a página bastaria por o header, com o motor que queremos usar e problema resolvido.

Referências:
meyerweb.com/
NCZ Online
A List Apart 1 - Aaron Gustafson
A List Apart 2 - Eric Meyer

Manutenção de Código.

2008-01-16T00:06:00.000Z

Estive agora a ouvir durante cerca de 45 minutos a palestra do Nicholas C. Zakas, sobre manutenção de código em Javascript...e como é lógico não podia concordar mais com ele em vários pontos. No entanto há muito programador que se esquece da maior parte das coisas que ele fala ( eu inclusive ). Seja pela pressa pela distracção ou outra coisa qualquer. Mas isto não pode acontecer!

Este problema leva a bastantes dores de cabeça, quer sejamos nós a mexer no código que criámos, quer seja um colega nosso. E quase que aposto que é onde um programador perde mais tempo no seu dia.

O que fazer para poder resolver este problema tão comum hoje em dia? Arranjar um bom método de trabalho, este penso que é o mais importante que tudo. Não ir em modas, lá porque toda a gente o anda a fazer, não quer dizer nós precisamos de o fazer e que é o melhor para onde o estamos a aplicar. É preciso analisar muito bem o que estamos a fazer para nos podermos atirar de cabeça com tecnologia X ou Y.

E para além destas duas que dei, outra, é ler, ler e ler ainda mais sobre a matéria em questão.

Se acham que implementaram alguma coisa mal, procurem por isso na web. Para que quando tiverem que criar algo parecido não caiam no mesmo erro.

Para finalizar ficam com o link para a palestra que ele deu intitulada: "Maintainable JavaScript".
http://www.nczonline.net/speaking/

Link para o site dele:
http://www.nczonline.net/

Google Earth download!

2008-01-13T23:58:00.000Z

Se há coisa que me irrite, é quando vou a um site, e esse site começa a dar erros de javascript! E que não nos deixa fazer o que queremos, por causa desses erros..

Desta vez foi com o site do Google Earth!

Primeiro pensei que fosse por estar a usar o Firefox, então toca de experimentar o IE e o problema continuava na mesma..

O que acontecia, como acontece a muito site por aí, que use o Google Analytics, a função urchinTracker(); não estava definida!

Podem ver os erros de tanto do FF, como do IE:

Mas como eu queria mesmo fazer o download, toca de meter mãos à obra com o meu fiel companheiro Firebug, basicamente é uma extensão para o Firefox, que permite editar e fazer debug no browser.

O que fiz simplesmente, foi ir à procura da função que o script javascript chamava quando se carregava no botão, e removê-la de lá. Depois foi só carregar no botão e voilá.. Toca de instalar o Google Earth.

O problema nisto tudo, é que quem visita a página à procura do produto, e vê que não consegue fazer o download, fica logo a pensar: "Mas que incompetentes são estes?!" Pelo menos é o que eu penso..

E até existem maneiras de dar a volta a isto, uma delas seria passar por verificar se o objecto javascript existe, outra seria por tudo dentro de um try catch finally, e problema resolvido. Mesmo que ele desse erro algures, o utilizador poderia sempre fazer o Download. A isto chama-se javascript não obstrutivo, e que degrada facilmente sem retirar qualquer funcionalidade à página que se está visualizar. E que deixa toda a gente contente!

Claro que esta solução dá mais trabalho, acrescenta mais código etc etc, mas não é bem mais vantajosa??

O que é que estes engenheiros/programadores/gestores andam a fazer no Google??

PS: Quem quiser pode fazer o download directo a partir daqui.

Ser um programador WEB a sério!

2008-01-11T01:06:00.000Z

Este não vai ser daqueles post's onde vou dar 2 ou 3 dicas, e pronto é-se um programador WEB de sucesso.

Primeiro há que distinguir, programador WEB de WEB designer, embora as duas profissões, estejam eternamente ligadas, não são bem a mesma coisa. ( Pelo menos na minha opinião ). Há muita gente que chama a um programador WEB, WEB designer...pelo menos é o que me acontece a mim..

Um WEB designer, é alguém que desenha as páginas para a WEB, ou seja, cria os layout's para as várias páginas existentes num site.

O programador WEB, é quem pega no layout feito previamente, e implementa esse layout em código. ( O que às vezes é bem complicado de fazer..)

Existe muita gente hoje em dia, que faz ambos, cria o layout, e também o implementa.

Dito isto, e estando feita a distinção, podemos passar para o segundo passo, como é que alguém se pode tornar num programador WEB digno desse nome.

Hoje em dia, qualquer pessoa pode ter uma página na internet. Existem vários serviços para isso, por exemplo o Google Pages, para além disso a maior parte dos ISP's têm alojamento gratuito no pacote de acesso à net. E como qualquer pessoa tem o Office, que tem o magnífico FrontPage, consegue fazer uma página em 2 tempos. E publicá-la na WEB.

Vê-se muito por aí, e cada vez mais, muitos sites completamente detestáveis, que só trabalham bem no IE ( mas isto é outra guerra, portanto fica para depois ), para além de que existem muitas empresas que têm alguém que sabe mexer no FrontPage, e dizem-lhe para criar uma página com umas coisa e pronto, já têm a sua presença na WEB, o que degrada a imagem da empresa.

A minha história:

Eu comecei pelo FrontPage, há cerca de 8 anos atrás, uma coisa muito simples, punha-se uma tabela aqui ( pronto, muitas tabelas ), formatava-se o tipo de letra e a cor acolá. E pronto, tinha-se uma página toda bonita em questões de minutos.

Passado uns tempos, descobri que fazendo uma página num editor WYSIWYG ( WYSIWYG é o acrónimo para "What You See Is What You Get"), não era a melhor opção, até porque os editores WYSIWYG não são fiáveis a 100%. Para além do código que geram ser do piorio.

Nessa altura, decidi remodelar o site que tinha feito, escrevendo tudo à mão, com o Notepad ( foi esta a maneira que aprendi HTML ), ao fazer isto, para além de perder montes de tempo, também aprendi a sintaxe do HTML, de trás para a frente e da frente para trás...

Passado uns tempos, comecei a usar o Dreamweaver da Macromedia ( syntax highlighting dá mesmo muito jeito, para além de completar as tag's HTML automaticamente.. ). Mas sem usar as propriedades WYSIWYG do software, ou seja faço tudo à mão.

Para finalizar, os meus conselhos são:

Não usar editores WYSIWYG.
Começar logo por escrever tudo à mão.
Não usar o Notepad.
Usar um bom editor, como por exemplo o Dreamweaver.

Existe bastante gente que concorda comigo nestes 4 aspectos. Mas também há muita gente que não.

Existem algumas pessoas que dizem que programar HTML no Notepad é que é bom, sinceramente não percebo porquê, tudo bem que é rápido e nada pesado, mas tentar mexer numa página HTML, com o Notepad, acho um suicídio autêntico, é bem complicado de se ler. Atenção, que até eu uso o Notepad de vez em quando, para fazer uma alteração muito simples nalgum ficheiro. Agora para desenvolver um site do início nem pensar! Em vez de demorar uma ou duas semanas, se calhar demorava um mês ou dois.

Estes são os meus conselhos para alguém se tornar num programador WEB, se será bom ou mau, já depende da sua capacidade e vontade. Mas pelo menos poderá dizer que sabe HTML.

Eu ao fim de 8 anos a programar para WEB, não sei tudo...e ainda hoje continuo à procura de soluções para os problemas que encontro. Até diria que o tempo que um programador WEB gasta, poderá estar dividido da seguinte maneira, 70% em pesquisas, e 30% a programar.

E não se esqueçam que Roma não foi construída num dia!

Nota: Não esquecer, que para ser programador WEB, não basta saber HTML, é preciso saber também CSS, algum Javascript e alguma(s) linguagen(s) dinâmica(s) também, como por exemplo o PHP.

Bom programador, mau programador

2007-12-06T21:34:00.000Z

A meu ver a principal característica para se ser um bom programador é ser autodidacta e ter curiosidade.

Um bom programador:

É aquele que nunca está contente com o código que escreve. Deve sempre procurar melhores formas de o melhorar.
É aquele que está sempre a estudar/pesquisar, sobre novas formas de abordar/resolver problemas.
É aquele que analisa e estuda um programa com antecedência antes de o tentar programar.

Um mau programador é o contrário destes 3 pontos, claro que não abordei muita coisa, mas para mim, estes são os pontos fulcrais para uma pessoa ser/tornar num programador.

Podem também ler este guia intitulado "How to be a Programmer: A Short, Comprehensive, and Personal Summary" escrito por Robert L. Read.

Concluindo, um mau programador é aquele que sabe uma coisa, porque precisa de o saber, um bom programador, é aquele que sabe uma coisa porque tem vontade de o saber.

Web Services - SOAP

2007-11-29T22:25:00.001Z

Nestas últimas duas semanas tive o prazer de começar a trabalhar com WEB Services, mais propriamente com SOAP, usando a library NuSOAP para PHP.

O projecto consistia em centralizar um número variável de bases de dados alojadas em vários locais espalhados por todo o país.

Tendo lido e ouvido falar sobre SOAP, decidi propor SOAP para se fazer essa centralização, ou pelo menos se fazer alguns testes para se verificar a capacidade do SOAP para fazer a transferência de uma grande quantidade de dados através de uma linha ADSL comum.

Quando falo em grandes quantidades de dados, refiro-me a tabelas de base de dados com cerca de 256 colunas ( vários tipos ) com mais de 150 mil linhas, este é um dos casos extremos, mas esta tabela virá a crescer diariamente.

Entretanto ficou outra pessoa responsável pelos testes e exemplos do SOAP, enquanto fiquei a tratar de outros assuntos urgentes.

Como se pode prever, os testes não foram bem efectuados ou totalmente efectuados, não se chegou a testar o envio de uma grande quantidade de dados.

Ou seja, quando se foi testar no servidor de produção, verificou-se que a maior parte dos pedidos excediam o tempo de timeout (30 segundos por default definido no NuSoap), como nesta altura já era eu que estava responsável pelo projecto, tive que assumir as responsabilidades.

Os pedidos estavam a demorar tanto tempo, porque para além de ser necessário enviar uma grande quantidade de dados, é necessário inserir os dados na base de dados central, o que ainda leva um certo tempo.

Depois de algumas pesquisas no Google ( o melhor amigo do programador actual ), descobri que para transferir grandes quantidades de dados o SOAP por HTTP, não deve ser usado para estes tipos de transferências, por uma série de razões, torna-se pesado para o servidor/local porque os pedidos têm de ser completamente carregados em memória antes de serem enviados e também introduz muito "overhead".

Para resolver o problema aumentou-se o tempo de timeout no SOAP para 60 segundos (algo completamente desconhecido pelo meu colega que fez os testes). E até ao momento parece que o problema ficou resolvido. Embora a centralização esteja algo lenta.

O conselho que posso dar em relação ao uso de SOAP, é que não pode ser usado para transferências de uma grande quantidade de dados ao mesmo tempo, como neste caso específico.

O problema maior neste projecto, foi a falta de investigação sobre a tecnologia que se ia usar, como é que ela se comporta em vários ambientes, resultando em vários problemas e dores de cabeça para mim.

Se a tecnologia tivesse sido testada convenientemente poderia-se ter aplicado de maneira diferente ou não ter-se-ia decidido não a usar para fazer a centralização. Poupando bastante tempo.

Será que é nestes pormenores que se distingue um bom programador de um mau programador? Esta será a programação para o próximo tópico deste blog, como distinguir um bom programador de um mau programador.

Em breve também um pequeno tutorial como usar SOAP em PHP usando a library NuSoap.

echo "O ínicio";

2007-11-29T21:56:00.000Z

Como se pode ver pela descrição deste Blog, aqui vai tentar-se discutir, algumas das lacunas. problemas, sucessos das pessoas que têm a profissão de programador enquanto batem ao teclado intermináveis linhas de código...

Sou um programador WEB, e trabalho na mesma empresa à cerca de 2 anos e meio. Frequento a Universidade Nova de Lisboa - Faculdade de Ciências e Tecnologia, onde estive os últimos 6 anos a tentar tirar o curso de Engenharia Electrotécnica, até que decidi mudar este ano para Engenharia Informática, provavelmente a maior, melhor e a mais importante decisão que tomei nestes 26 anos de vida.