segunda-feira, 21 de setembro de 2009
terça-feira, 15 de setembro de 2009
Nova ferramenta Google Fast Flip facilita visualização de notícias online
Serviço permite que internauta visualize e navegue rapidamente entre diversas páginas de notícias, como se estivesse folheando uma revista.
O Google começou a testar um novo formato para leitura de sites de notícias chamado Fast Flip. O serviço lançado pelo Google Labs, em fase de testes, na segunda-feira (14/9), permite que o internauta pré-visualize diversas páginas de sites de notícias de só vez e navegue rapidamente entre elas. Com isso, não há necessidade de esperar que a página seja carregada, especialmente quando há conteúdos multimídia mais pesados.
A ideia, segundo o Google, é reproduzir na internet a prática de folhear páginas de jornais e revistas, motivando a leitura de conteúdos online. Ao clicar na página visualizada, entretanto, o internauta é direcionado ao respectivo site, onde o conteúdo é exibido sem a ferramenta.
Inicialmente, o Fast Flip reúne artigos de 36 sites de conteúdo, incluindo The New York Times, Washington Post, Salon e Newsweek, exibindo anúncios de acordo com o contexto.
O Fast Flip também vai contar com ferramentas de buscas e compartilhamento de conteúdo. Por enquanto, o serviço não conta com aplicações para terceiros.
"Lançar o Google Fast Flip no Labs permite que possamos aprender com nossos usuários e nossos parceiros de conteúdo para que continuemos explorando novas formas de ajudar as editoras a gerar mais receita com seus conteúdos", disse uma porta-voz do Google.
Além de funcionar em navegadores para desktops, o site do Fast Flip se adapta às plataformas do iPhone, da Apple, e de celulares com o sistema operacional Android, do Google.
O Google começou a testar um novo formato para leitura de sites de notícias chamado Fast Flip. O serviço lançado pelo Google Labs, em fase de testes, na segunda-feira (14/9), permite que o internauta pré-visualize diversas páginas de sites de notícias de só vez e navegue rapidamente entre elas. Com isso, não há necessidade de esperar que a página seja carregada, especialmente quando há conteúdos multimídia mais pesados.
A ideia, segundo o Google, é reproduzir na internet a prática de folhear páginas de jornais e revistas, motivando a leitura de conteúdos online. Ao clicar na página visualizada, entretanto, o internauta é direcionado ao respectivo site, onde o conteúdo é exibido sem a ferramenta.
Inicialmente, o Fast Flip reúne artigos de 36 sites de conteúdo, incluindo The New York Times, Washington Post, Salon e Newsweek, exibindo anúncios de acordo com o contexto.
O Fast Flip também vai contar com ferramentas de buscas e compartilhamento de conteúdo. Por enquanto, o serviço não conta com aplicações para terceiros.
"Lançar o Google Fast Flip no Labs permite que possamos aprender com nossos usuários e nossos parceiros de conteúdo para que continuemos explorando novas formas de ajudar as editoras a gerar mais receita com seus conteúdos", disse uma porta-voz do Google.
Além de funcionar em navegadores para desktops, o site do Fast Flip se adapta às plataformas do iPhone, da Apple, e de celulares com o sistema operacional Android, do Google.
Kernel Modules in Haskell
If you love Haskell and Linux then today is your day – today we reconcile the two and allow you to write Linux Kernel modules in Haskell. By making GHC and the Linux build system meet in the middle we can have modules that are type safe and garbage collected. Using the copy of GHC modified for the House operating system as a base, it turns out to be relatively simple to make the modifications necessary to generate object files for the Kernel environment. Additionally, a new calling convention (regparm3) was added to make it easier to import (and export) functions from the Kernel.
I haven’t made a dry run through all these instructions, but have done each part at separate times and believe them correct – feel free to comment with bug reports!
Building GHC to Make Object files for Linux Modules
Start by downloading the House 0.8.93 [1]. Use the build system to acquire ghc-6.8.2 and apply the House patches. The House patches allow GHC to compile Haskell binaries that will run on bare metal (x86) without an underlying operating system, so this makes a good starting point.
> wget http://web.cecs.pdx.edu/~kennyg/house/House-0.8.93.tar.bz2
> tar xjf House-0.8.93.tar.bz2
> cd House-0.8.93
> make boot
> make stamp-patch Now acquire the extra patch which changes the RTS to use the proper Kernel calls, instead of allocating its own memory, and to respect the current interrupt level. This patch also changes the build options to avoid common area blocks for uninitilized data (-fno-common) and use frame pointers (-fno-omit-frame-pointers).
> wget https://projects.cecs.pdx.edu/~dubuisst/hghc.patch
> patch -d ghc-6.8.2 -p1 < hghc.patch
> make stamp-configure
> make stamp-ghc # makes ghc stage 1 Next, build a custom libgmp with the -fno-common flag set. This library is needed for the Integer support in Haskell.
> wget ftp://ftp.gnu.org/gnu/gmp/gmp-4.3.1.tar.bz2
> tar xjf gmp-4.3.1.tar.bz2
> cd gmp-4.3.1
> ./configure
# edit 'Makefile' and add '-fno-common' to the end of the 'CFLAGS = ' line.
> make
> cp .libs/libgmp.a $HOUSE_DIR/support Apply ’support.patch’ to alter the build systems of the libtiny_{c,gcc,gmp}.a and build the libraries.
> wget https://projects.cecs.pdx.edu/~dubuisst/support.patch
> patch -d $HOUSE_DIR < support.patch
> make -C $HOUSE_DIR/support Build the cbits object files:
> make -C $HOUSE_DIR/kernel cobjs In preparation for the final linking, which is done manually, pick a working directory ($WDIR) that will serve to hold the needed libraries. Make some last minute modifications to the archives and copy libHSrts.a, libcbits.a, libtiny_gmp.a, libtiny_c.a, and libtiny_gcc.a
> mkdir $WDIR
> ar d support/libtiny_c.a dlmalloc.o # dlmalloc assumes it manages all memory
> ar q $WDIR/libcbits.a kernel/cbits/*.o
> cp ghc-6.8.2/rts/libHSrts.a support/libtiny_{c,gcc,gmp}.a $WDIR
Build a Kernel Module
First, write the C shim that will be read by the Linux build system. While it might be possible to avoid C entirely its easier to use the build system, and its plethora of macros, than fight it. The basic components of the shim are a license declaration, function prototypes for the imported (Haskell) functions, initialization, and exit functions. All these can be seen in the example hello.c [2].
Notice that many of the standard C functions in the GHC RTS were not changed by our patches. To allow the RTS to perform key actions, such as malloc and free, the hello.c file includes shim functions such as ‘malloc’ which simply calls ‘kmalloc’. Any derivative module you make should include these functions either in the main C file or a supporting one.
Second, write a Haskell module and export the initialization and exit function so the C module may call them. Feel free to import kernel functions, just be sure to use the ‘regparm3′ key word in place of ‘ccall’ or ’stdcall’. For example:
foreign import regparm3 unsafe foo :: CString -> IO CInt
foreign export regparm3 hello :: IO CInt Continuing the example started by hello.c, ‘hsHello.hs’ is online [3].
Now start building the object files. Starting with building hsHello.o, you must execute:
> $HOUSE_DIR/ghc-6.8.2/compiler/stage1/ghc-inplace -B$HOUSE_DIR/ghc-6.8.2 hsHello.hs -c * note that this step will generate or overwrite any hsHello_stub.c file.
When GHC generates C code for exported functions there is an implicit assumption that the program will be compiled by GHC. As a result the nursery and most the RTS systems are not initialized so the proper function calls must be added to hsHello_stub.c.
Add the funcion call “startupHaskell(0, NULL, NULL);” before rts_lock() in the initializing Haskell function. Similarly, add a call to “hs_exit_nowait()” after rts_unlock().
The stub may now be compiled, producing hsHello_stub.o. This is done below via hghc, which is an alias for our version of ghc with many flags [4].
> hghc hsHello_stub.c -c The remaining object files, hello.o and module_name.mod.o, can be created by the Linux build system. The necessary make file should contain the following:
obj-m := module.o # Obviously you should name the module as you see fit
module-objs := hello.o And the make command (assuming the kernel source is in /usr/src/kernels/):
> make -C /usr/src/kernels/2.6.29.6-217.2.16.fc11.i586 M=`pwd` modules This should make “hello.o” and “module.mod.o”. Everything can now be linked together with a single ld command.
> ld -r -m elf_i386 -o module.ko hsHello_stub.o hsHello.o module.mod.o hello.o *.a libcbits.a A successful build should not have any common block variables and the only undefined symbols should be provided by the kernel, meaning you should recognize said functions. As a result, the first command below should not result in output while the second should be minimal.
> nm module.ko | egrep “^ +C ”
> nm module.ko | egrep “^ +U ”
U __kmalloc
U kfree
U krealloc
U mcount
U printk
Known Issue
The House-GHC 6.8.2 run-time system (RTS) does not clean up the allocated memory on shutdown, so adding and removing kernel modules results in large memory leaks which can eventually crash the system. This should be relatively easy to fix, but little investigation was done.
A good estimate of the memory leak is the number of megabytes in the heap (probably 1MB, unless your module needs lots of memory) plus 14 bytes of randomly leaked memory from two unidentified (6 and 8 byte) allocations.
[1] http://web.cecs.pdx.edu/~kennyg/house/
[2] https://projects.cecs.pdx.edu/~dubuisst/hello.c
[3] https://projects.cecs.pdx.edu/~dubuisst/hsHello.hs
[4] $HOUSE_DIR/ghc-6.8.2/compiler/stage1/ghc-inplace -B$HOUSE_DIR/ghc-6.8.2 -optc-fno-common -optc-Wa,symbolic -optc-static-libgcc -optc-nostdlib -optc-I/usr/src/kernels/2.6.29.6-213.fc11.i586/arch/x86/include/ -optc-MD -optc-mno-sse -optc-mno-mmx -optc-mno-sse2 -optc-mno-3dnow -optc-Wframe-larger-than=1024 -optc-fno-stack-protector -optc-fno-optimize-sibling-calls -optc-g -optc-fno-dwarf2-cfi-asm -optc-Wno-pointer-sign -optc-fwrapv -optc-fno-strict-aliasing -I/usr/src/kernels/2.6.29.6-213.fc11.i586/include/ -optc-mpreferred-stack-boundary=2 -optc-march=i586 -optc-Wa,-mtune=generic32 -optc-ffreestanding -optc-mtune=generic -optc-fno-asynchronous-unwind-tables -optc-pg -optc-fno-omit-frame-pointer -fvia-c
quinta-feira, 10 de setembro de 2009
Kuki: distribuição Linux sob medida para netbooks Acer Aspire One, baseada no Ubuntu
Trecho da notícia do iG Tecnologia:
(…) Baseado no Ubuntu, o Kuki Linux 2.8 é um sistema leve, com uma seleção otimizada de aplicativos peso-pena. Entre eles, o navegador web Midori, o mensageiro instantâneo Pidgin, o cliente de e-mail Claws, o Deluge, para baixar arquivos por BitTorrent, e o calendário/organizador pessoal Orage. O ambiente de usuário escolhido, pelo seu baixo consumo de memória, foi o XFCE 4.6.1, com um tema personalizado. O XFCE é bastante modificável para ficar semelhante tanto ao Windows como ao Mac OS X. A idéia dos desenvolvedores é dar ao usuário o máximo de recursos, com o menor consumo possível de memória e poder de processamento.
O suporte ao hardware específico do Aspire One também recebeu atenção: itens como controle do ventilador para dissipação de calor, gerenciamento de energia, drivers de vídeo, do modem 3G e leitores de cartões de memória vem pré-configurados.
O Kuki Linux 2.8 pode ser baixado gratuitamente no site oficial, na forma de um arquivo ISO de 399 MB. O arquivo pode ser gravado em CD ou em um pendrive, e usado para instalação ou para uma sessão “Live CD”, que permite experimentar o sistema sem instalá-lo na máquina. Segundo os desenvolvedores, usuários novatos poderão encontrar suporte na forma de salas de bate-papo, fóruns de discussão e tutoriais em vídeo no site oficial. (via tecnologia.ig.com.br)
quarta-feira, 9 de setembro de 2009
Browsers: uma breve história - Parte II
Entra o Netscape
Marc Andreessen, vendo o potencial para a web se tornando muito maior do que era até então, viu uma oportunidade de construir um navegador muito melhor do que o Mosaic, e assim o fez. Netscape, também conhecido como Mozilla, foi lançado em outubro de 1994. Foi legal. Isso permitiu-lhe alterar as cores de links e links visitados. Foi possível adicionar cores de fundo e gráficos. Não mais páginas cinzas com links em azul e vermelho! Claro, se você ainda estava usando Mosaic, você ficaria de fora disso na medida em que esses novos recursos apareciam. A maioria dos autores de páginas web (ainda a serem referidos como web designers) simplesmente adicionariam um texto ou um gráfico dizendo que "melhor visualizado em Netscape" para suas páginas (no futuro mudariam o texto para Internet Explorer!).
Entretanto, houve um problema. A World Wide Web Consortium, que é uma organização que determina e aprova as normas de codificação de HTML. Apesar do W3C pretender adicionar a maioria dos recursos que o Netscape incluiu no seu navegador, eles ainda não tinham decidido, ou lançado o novo padrão HTML, que incluiu alguns desses novos elementos. O Netscape tinha sacado a arma. Apesar das objeções técnicas dos puristas, todo mundo estava empolgado com os novos recursos, e realmente não importava se estava ou não aprovados pelo W3C, o Netscape fazia. Não demorou muito tempo e o Netscape 2.0 foi lançado com outro conjunto de novos recursos de formatação, tais como "tables", "frames" e o temido tag "blink". As coisas estavam avançando rapidamente, e não se pensava muito como alguns desses novos recursos afetariam os navegadores mais antigos, que muitas pessoas ainda utilizavam. Esta tendência iria crescer mais e mais problemática no futuro com a inclusão do JavaScript, Java applets, e muitos outros elementos de página web mais complexos.
Agora que a aparência de uma página web poderia ser (um pouco) controlada, os designers começaram a ter um interesse real pela web. Muitos designers não tinham conhecimento de questões de compatibilidade de navegadores, mas este não era um grande problema, desde que havia apenas um browser dominante. Além disso, o usuário típico da web não tinha grandes expectativas de como uma página da Web poderia ser exibida no seu navegador. Se um site não fosse cinza genérico era considerado bem desenhado (pode?).
A guerra fria começa
"Que coisa está acontecendo no mundo dos computadores, e não é nele próprio?", gritou Bill Gates, e logo o Microsoft Internet Explorer 1.0 nasceu. Anti-trust de lado, a world wide web estava agora engajada em uma guerra civil entre duas facções entrincheiradas, com facões e foices à mão: os Rebeldes Netscape e o Império do IE. De repente, havia dois grandes jogadores cada um tentando superar o outro em capacidades. Dois caminhos muito divergentes surgiram. O padrão HTML controlado pelo World Wide Web Consortium foi deixado na poeira; apenas sobre cada aspecto de como uma página da web trabalhava diferente entre o Netscape e o IE interessava. Por exemplo, alguns dos mais avançados recursos de programação introduzida pela Netscape usava JavaScript. I.E. decidiu que iria usar VB Script em vez de JavaScript. Agora o que tinham os desenvolvedores a fazer? Se quisessem um pop-up de uma janela, usariam código em JavaScript ou VB Script? Durante algum tempo, eles foram obrigados a escolher qual o navegador era o melhor para um determinado site, ou outro código de duas versões de cada página para satisfazer ambos os navegadores.
Como se esses caminhos divergentes não fossem difíceis o suficiente para lidar com as forças do mercado causada pelo Netscape e IE as "novas" versões betas de seus softwares eram quase mensais. Tradicionalmente, quando uma empresa lança um "beta" do produto, é geralmente para um pequeno grupo de desenvolvedores, de "testers" com o propósito de encontrar e erradicar bugs e problemas antes que ele seja liberado para o público. No caso do Netscape e I.E. eles usaram o público como um grupo de "beta testers", liberando o software "bugado", software instável mesmo, para os usuários em geral. Portanto, agora os desenvolvedores não só teriam de determinar como é que iriam apoiar os vários navegadores, mas também como evitar a colisão das versões beta "bugadas" que estavam em circulação constante. Muitas vezes, eles teriam código de uma página web com um "hack" para contornar um problema específico em um browser. Claro que na próxima versão, o bug poderia ser corrigido (ou não), fazendo o "hack" no site existente ser quebrado e, "fixo" na próxima versão do navegador. Uma balbúrdia.
Antes de jogar toda a culpa no Netscape e no IE, precisamos perceber que eles estavam apenas respondendo a um mercado que estava exigindo novos recursos mais rapidamente do que razoavelmente poderiam ser produzidos. Eles queriam layouts "cool", melhores gráficos, rollovers, animação e todos os sinos e assobios que Netscape e IE podiam fazer possível. Uma das características mais importantes exigidas nas página pelos web designers (ops!) e usuários foi a capacidade de controlar o tipo e layout de sites. Netscape e I.E. ambos responderam através de várias maneiras para controlar estes elementos. Evidentemente, cada navegador implementou as características com pequenas diferenças, e onde um pedaço de HTML podia funcionar bem no Netscape, ele podia não funcionar no IE, e vice-versa.
A capacidade teórica de controle de design foi aumentando, e assim usuários de sites na Internet começaram a se acostumar (e finalmente esperando) com "cool layouts" e com maravilhosos recursos interativos. Designers estavam sob constante pressão para os "uau" dos clientes e visitantes do site com os seus desenhos. Quanto mais eles tentaram impressionar com elementos de design complexo e original, mais difícil se tornou para implementar os projetos, especialmente em ambos os navegadores.
Marc Andreessen, vendo o potencial para a web se tornando muito maior do que era até então, viu uma oportunidade de construir um navegador muito melhor do que o Mosaic, e assim o fez. Netscape, também conhecido como Mozilla, foi lançado em outubro de 1994. Foi legal. Isso permitiu-lhe alterar as cores de links e links visitados. Foi possível adicionar cores de fundo e gráficos. Não mais páginas cinzas com links em azul e vermelho! Claro, se você ainda estava usando Mosaic, você ficaria de fora disso na medida em que esses novos recursos apareciam. A maioria dos autores de páginas web (ainda a serem referidos como web designers) simplesmente adicionariam um texto ou um gráfico dizendo que "melhor visualizado em Netscape" para suas páginas (no futuro mudariam o texto para Internet Explorer!).
Entretanto, houve um problema. A World Wide Web Consortium, que é uma organização que determina e aprova as normas de codificação de HTML. Apesar do W3C pretender adicionar a maioria dos recursos que o Netscape incluiu no seu navegador, eles ainda não tinham decidido, ou lançado o novo padrão HTML, que incluiu alguns desses novos elementos. O Netscape tinha sacado a arma. Apesar das objeções técnicas dos puristas, todo mundo estava empolgado com os novos recursos, e realmente não importava se estava ou não aprovados pelo W3C, o Netscape fazia. Não demorou muito tempo e o Netscape 2.0 foi lançado com outro conjunto de novos recursos de formatação, tais como "tables", "frames" e o temido tag "blink". As coisas estavam avançando rapidamente, e não se pensava muito como alguns desses novos recursos afetariam os navegadores mais antigos, que muitas pessoas ainda utilizavam. Esta tendência iria crescer mais e mais problemática no futuro com a inclusão do JavaScript, Java applets, e muitos outros elementos de página web mais complexos.
Agora que a aparência de uma página web poderia ser (um pouco) controlada, os designers começaram a ter um interesse real pela web. Muitos designers não tinham conhecimento de questões de compatibilidade de navegadores, mas este não era um grande problema, desde que havia apenas um browser dominante. Além disso, o usuário típico da web não tinha grandes expectativas de como uma página da Web poderia ser exibida no seu navegador. Se um site não fosse cinza genérico era considerado bem desenhado (pode?).
A guerra fria começa
"Que coisa está acontecendo no mundo dos computadores, e não é nele próprio?", gritou Bill Gates, e logo o Microsoft Internet Explorer 1.0 nasceu. Anti-trust de lado, a world wide web estava agora engajada em uma guerra civil entre duas facções entrincheiradas, com facões e foices à mão: os Rebeldes Netscape e o Império do IE. De repente, havia dois grandes jogadores cada um tentando superar o outro em capacidades. Dois caminhos muito divergentes surgiram. O padrão HTML controlado pelo World Wide Web Consortium foi deixado na poeira; apenas sobre cada aspecto de como uma página da web trabalhava diferente entre o Netscape e o IE interessava. Por exemplo, alguns dos mais avançados recursos de programação introduzida pela Netscape usava JavaScript. I.E. decidiu que iria usar VB Script em vez de JavaScript. Agora o que tinham os desenvolvedores a fazer? Se quisessem um pop-up de uma janela, usariam código em JavaScript ou VB Script? Durante algum tempo, eles foram obrigados a escolher qual o navegador era o melhor para um determinado site, ou outro código de duas versões de cada página para satisfazer ambos os navegadores.
Como se esses caminhos divergentes não fossem difíceis o suficiente para lidar com as forças do mercado causada pelo Netscape e IE as "novas" versões betas de seus softwares eram quase mensais. Tradicionalmente, quando uma empresa lança um "beta" do produto, é geralmente para um pequeno grupo de desenvolvedores, de "testers" com o propósito de encontrar e erradicar bugs e problemas antes que ele seja liberado para o público. No caso do Netscape e I.E. eles usaram o público como um grupo de "beta testers", liberando o software "bugado", software instável mesmo, para os usuários em geral. Portanto, agora os desenvolvedores não só teriam de determinar como é que iriam apoiar os vários navegadores, mas também como evitar a colisão das versões beta "bugadas" que estavam em circulação constante. Muitas vezes, eles teriam código de uma página web com um "hack" para contornar um problema específico em um browser. Claro que na próxima versão, o bug poderia ser corrigido (ou não), fazendo o "hack" no site existente ser quebrado e, "fixo" na próxima versão do navegador. Uma balbúrdia.
Antes de jogar toda a culpa no Netscape e no IE, precisamos perceber que eles estavam apenas respondendo a um mercado que estava exigindo novos recursos mais rapidamente do que razoavelmente poderiam ser produzidos. Eles queriam layouts "cool", melhores gráficos, rollovers, animação e todos os sinos e assobios que Netscape e IE podiam fazer possível. Uma das características mais importantes exigidas nas página pelos web designers (ops!) e usuários foi a capacidade de controlar o tipo e layout de sites. Netscape e I.E. ambos responderam através de várias maneiras para controlar estes elementos. Evidentemente, cada navegador implementou as características com pequenas diferenças, e onde um pedaço de HTML podia funcionar bem no Netscape, ele podia não funcionar no IE, e vice-versa.
A capacidade teórica de controle de design foi aumentando, e assim usuários de sites na Internet começaram a se acostumar (e finalmente esperando) com "cool layouts" e com maravilhosos recursos interativos. Designers estavam sob constante pressão para os "uau" dos clientes e visitantes do site com os seus desenhos. Quanto mais eles tentaram impressionar com elementos de design complexo e original, mais difícil se tornou para implementar os projetos, especialmente em ambos os navegadores.
sexta-feira, 4 de setembro de 2009
Browsers: uma breve história - Parte I
Hoje quando cheguei ao trabalho, começamos algumas conversas sobre buscadores, e, falei que usei bastante o HotBot, que pra minha admiração, ainda existe (www.hotbot.com), e logo em seguida, lembramos do Altavista... e a conversa descambou pro browsers, ou navegadores. Lembro de ter participado do segundo ponto de internet no Pará, no Museu Emilio Goeldi, usando uma linha discada de 9600bps num US Robotics courrier... mas voltemos aos browsers, pois juntei algumas "escrivinhações", que vão abaixo. E vou contar essa história toda em partes.
Em 1989, Tim Berners-Lee, do CERN (o laboratório europeu para física de partículas) começou a desenvolver uma tecnologia para compartilhamento de informações usando documentos em texto hyperlink. Ele baseou sua nova linguagem na já bem estabelecida Standard Generalized Markup Language (SGML) - um padrão de intercâmbio de dados comerciais - e batizou-a de HyperText Markup Language (HTML). Ele também escreveu protocolos de comunicações para formar a espinha dorsal do seu novo sistema de informações em hipertexto, o qual denominou World Wide Web.
A Internet e a World Wide Web seguramente constarão em qualquer lista das mais importantes e profundas criações da humanidade. No passado, a maioria dos aplicativos de computador era executada em aplicaões stand-alone, ou seja, computadores que não estavam conectados uns aos outros. Hoje em dia, podem-se escrever aplicativos para se comunicar com as centenas de milhões de comutadores do mundo. A Internet mistura as tecnologias de computação e de comunicações. Isso facilita nosso trabalho. Torna acessível a informação instantaneamente e de modo coveniente, possibilitando que os indivíduos e as pequenas empresas sejam conhecidos em todo o mundo. A Internet está mudando a maneira de se fazer negócios. As pessoas podem pesquisar os melhores preços sobre qualquer produto e serviço. Comunidades com interesses em comum podem se manter em contato umas com as outras. Os pesquisadores podem conhecer instataneamente os últimos avanços ocorridos no mundo, podem ver fotos e imagens de Marte quase em tempo real.
O desenvolvimento Web nada seria se não fossem os navegadores. Claro que sem eles ainda estaríamos de volta aos dias do Lynx - alguém se lembra do antigo navegador somente modo texto? Navegadores têm feito da web o que ela é hoje, mas eles também têm feito o desenvolvimento de sites para a web um negócio extremamente complicado.
Voltemos, voltemos,... em 1993, Marc Andreessen (criador do Netscape) estava trabalhando no antecessor do Netscape "Mosaic". A Web já existia, mas a linguagem da web, HTML, ainda estava em sua infância. Durante esse tempo, o navegador Mosaic adicionou um novo recurso que levou à corrida dos sites de 1995-96: as imagens. O navegador Mosaic podia apresentar gráficos em uma página web. De repente, não-geeks começaram a se interessar pela web, o que começou tudo. Também deu o primeiro tiro em uma guerra de navegadores que tem continuado até hoje. De repente, os autores de páginas web tinham um problema. Agora que eles poderiam usar elementos gráficos como botões de navegação, como é que todos os usuários da web somente com o navegador de texto Lynx poderiam visualizar a página? Ou sobre aqueles usuários que usavam um modem 9600kbps para transmissão de imagens com o recurso de imagens desligado? Felizmente houve um elemento simples de resolver este problema: a tag "ALT". Se um autor da página web acrescentasse o texto "ALT" a uma imagem, o navegador de texto só iria mostrar o texto no lugar do gráfico. Claro que nem todos os autores de páginas web sabiam disso, ou mesmo se soubessem, se preocuparam em adicionar a tag "ALT".
Problemas de compatibilidade do navegador como este estava destinado a se tornar a maldição da existência de um desenvolvedor web.
Em 1989, Tim Berners-Lee, do CERN (o laboratório europeu para física de partículas) começou a desenvolver uma tecnologia para compartilhamento de informações usando documentos em texto hyperlink. Ele baseou sua nova linguagem na já bem estabelecida Standard Generalized Markup Language (SGML) - um padrão de intercâmbio de dados comerciais - e batizou-a de HyperText Markup Language (HTML). Ele também escreveu protocolos de comunicações para formar a espinha dorsal do seu novo sistema de informações em hipertexto, o qual denominou World Wide Web.
A Internet e a World Wide Web seguramente constarão em qualquer lista das mais importantes e profundas criações da humanidade. No passado, a maioria dos aplicativos de computador era executada em aplicaões stand-alone, ou seja, computadores que não estavam conectados uns aos outros. Hoje em dia, podem-se escrever aplicativos para se comunicar com as centenas de milhões de comutadores do mundo. A Internet mistura as tecnologias de computação e de comunicações. Isso facilita nosso trabalho. Torna acessível a informação instantaneamente e de modo coveniente, possibilitando que os indivíduos e as pequenas empresas sejam conhecidos em todo o mundo. A Internet está mudando a maneira de se fazer negócios. As pessoas podem pesquisar os melhores preços sobre qualquer produto e serviço. Comunidades com interesses em comum podem se manter em contato umas com as outras. Os pesquisadores podem conhecer instataneamente os últimos avanços ocorridos no mundo, podem ver fotos e imagens de Marte quase em tempo real.
O desenvolvimento Web nada seria se não fossem os navegadores. Claro que sem eles ainda estaríamos de volta aos dias do Lynx - alguém se lembra do antigo navegador somente modo texto? Navegadores têm feito da web o que ela é hoje, mas eles também têm feito o desenvolvimento de sites para a web um negócio extremamente complicado.
Voltemos, voltemos,... em 1993, Marc Andreessen (criador do Netscape) estava trabalhando no antecessor do Netscape "Mosaic". A Web já existia, mas a linguagem da web, HTML, ainda estava em sua infância. Durante esse tempo, o navegador Mosaic adicionou um novo recurso que levou à corrida dos sites de 1995-96: as imagens. O navegador Mosaic podia apresentar gráficos em uma página web. De repente, não-geeks começaram a se interessar pela web, o que começou tudo. Também deu o primeiro tiro em uma guerra de navegadores que tem continuado até hoje. De repente, os autores de páginas web tinham um problema. Agora que eles poderiam usar elementos gráficos como botões de navegação, como é que todos os usuários da web somente com o navegador de texto Lynx poderiam visualizar a página? Ou sobre aqueles usuários que usavam um modem 9600kbps para transmissão de imagens com o recurso de imagens desligado? Felizmente houve um elemento simples de resolver este problema: a tag "ALT". Se um autor da página web acrescentasse o texto "ALT" a uma imagem, o navegador de texto só iria mostrar o texto no lugar do gráfico. Claro que nem todos os autores de páginas web sabiam disso, ou mesmo se soubessem, se preocuparam em adicionar a tag "ALT".
Problemas de compatibilidade do navegador como este estava destinado a se tornar a maldição da existência de um desenvolvedor web.
Assinar:
Postagens (Atom)
