Oracle lança banco de dados Oracle® 11g
Nova versão ajudará os clientes a inovar mais rapidamente
NOVA YORK, EUA 13-JUL-2007 08:04 AM
Veja o lançamento: http://www.oracle.com/features/hp/oracle-database-11g.html
A Oracle acaba de anunciar o lançamento do Oracle® 11g, última versão do banco de dados mais popular do mundo. Com mais de 400 recursos, 15 milhões de horas de testes e 36.000 pessoa/meses de desenvolvimento, o banco de dados Oracle® 11g destaca-se como o software mais inovador e de mais alta qualidade já lançado pela Oracle.
"O banco de dados Oracle® 11g, construído com 30 anos de experiência em design, oferece recursos de última geração para gerenciamento de informações empresariais", afirma Andy Mendelsohn, vice-presidente sênior de Tecnologias de Servidor de banco de dados da Oracle. "Mais do que nunca, nossos clientes enfrentam desafios, tais como rápido crescimento dos dados, aumento da integração entre eles e pressões no custo da tecnologia para conectividade. O banco de dados Oracle 10g foi pioneiro em grid computing e mais da metade dos clientes Oracle migraram para essa versão. Agora, o banco de dados Oracle® 11g oferece os recursos que nossos clientes solicitaram para acelerar a ampla adoção e crescimento dos grids Oracle, representando uma inovação real, que se volta para desafios reais, trazidos até nós por clientes reais", completa.
Com o banco de dados Oracle® 11g, as organizações poderão assumir o controle de suas informações empresariais, ter uma melhor visão dos negócios e adaptar-se com rapidez a um ambiente competitivo que passa por grandes mudanças. A nova versão aumenta a capacidade de cluster de banco de dados, além de acelerar a automação do data center e o gerenciamento da carga de trabalho. Com grids seguros, altamente disponíveis e escaláveis de servidores e armazenamento de baixo custo, os clientes Oracle têm suporte para as aplicações mais exigentes de processamento de transações, data warehousing e gestão de conteúdo.
Testes com aplicativos ajudam a reduzir tempo, risco e custo da mudança
O banco de dados Oracle® 11g apresenta recursos avançados de autogerenciamento e automação para ajudar as organizações a cumprir acordos de nível de serviços. Por exemplo, como as organizações precisam fazer atualizações regulares do sistema operacional e do banco de dados, além de alterações no hardware e no sistema, o banco de dados Oracle® 11g conta com o Oracle Real Application Testing. Ou seja, trata-se do primeiro banco de dados capaz de ajudar os clientes a testar e gerenciar alterações em seu ambiente de TI rapidamente, de maneira controlada e econômica.
Maior retorno do investimento em soluções de recuperação de catástrofe
No banco de dados Oracle® 11g, o Oracle Data Guard permite a utilização do banco de dados em standby para melhorar o desempenho no ambiente de produção, além de fornecer proteção contra falhas do sistema e catástrofes. O Oracle Data Guard possibilita a leitura e a recuperação simultâneas de um único banco de dados de standby, tornando-o disponível para geração de relatórios, backup, testes e atualizações para bancos de dados de produção. Ao aliviar a carga de trabalho de um sistema de produção para um de standby, o Oracle Data Guard ajuda a melhorar o desempenho dos sistemas de produção e fornece uma solução mais econômica para recuperação de catástrofe.
Aprimoramento da gestão do ciclo de vida das informações e do armazenamento
O banco de dados Oracle® 11g conta com novos e significativos recursos de particionamento e compactação de dados para as gestões do ciclo de vida das informações e do armazenamento com mais economia. O banco de dados Oracle® 11g automatiza muitas operações de particionamento de dados e amplia o particionamento por faixas, por função matemática e por listas (em inglês, range, hash e list), incluindo as novas extensões por intervalo, referência e por coluna virtual (em inglês, interval, REF e virtual columns). Além disso, o banco de dados Oracle® 11g oferece um conjunto completo de opções de particionamento composto, permitindo que o gerenciamento do armazenamento seja orientado por regras de negócios.
Complementando recursos já tradicionais de compactação de dados, o Oracle® 11g oferece ainda compactação avançada para dados estruturados e não-estruturados (em inglês, large objects ou LOBs) gerenciados em ambientes de processamento de transações, data warehousing e gestão de conteúdo. É possível atingir índices de compactação de 2x a 3x ou até mais para todos os dados, com os novos recursos avançados presentes no banco de dados Oracle® 11g.
Registro total de todas as alterações nos dados
A nova versão também apresenta o "Oracle Total Recall", que possibilita a consulta de dados em tabelas designadas a partir de pontos no passado. O recurso é uma maneira fácil e prática de acrescentar uma dimensão de tempo aos dados para acompanhamento de alterações, auditoria e cumprimento de regulamentações.
Máxima disponibilidade de informações
A Oracle tem sido líder no mercado em proteção para aplicativos de banco de dados contra indisponibilidade planejada ou imprevista. O Oracle® 11g mantém essa liderança, pois facilita o atendimento das expectativas de disponibilidade de seus usuários. Dentre os novos recursos estão o Oracle Flashback Transaction, que facilita a reversão de uma transação efetuada com erro, bem como de qualquer transação dependente; Parallel Backup and Restore, que ajuda a melhorar o desempenho do backup e restauração de bancos de dados grandes; e 'hot patching', que melhora a disponibilidade do sistema ao permitir que correções sejam aplicadas sem a necessidade de interromper a operação do banco de dados. Além disso, um novo recurso de aconselhamento – Data Recovery Advisor – ajuda os administradores a reduzir significativamente a parada para recuperação, o que permite automatizar investigação de falhas, determinar planos de recuperação e lidar com várias situações de crise.
Oracle Fast Files
Esse recurso de última geração tem a função de armazenar grandes objetos como imagens, textos ou tipos de dados avançados – incluindo XML, imagens médicas e objetos tridimensionais – dentro do banco de dados. O Oracle Fast Files oferece desempenho dos aplicativos de banco de dados plenamente comparável aos sistemas de arquivos. Ao armazenar uma variedade mais ampla de informações empresariais e recuperá-las com rapidez e facilidade, as empresas podem saber mais sobre seus negócios e se adaptar com agilidade.
XML mais rápido
O banco de dados Oracle® 11g inclui aprimoramentos significativos de desempenho no XML DB, um recurso que permite armazenar nativamente e manipular dados em XML. Acrescentou-se o suporte para XML binário, oferecendo aos clientes várias opções de armazenamento de XML que atendem aos seus requisitos específicos de aplicação e desempenho. O XML DB também possibilita manipulação de dados em XML usando interfaces padrão de mercado com suporte para XQuery, Java Specification Requests (JSR)-170 e padrões SQL/XML.
Criptografia transparente
O banco de dados Oracle® 11g complementa seus imbatíveis recursos de segurança com a adição de outros significativos. A nova versão apresenta um aprimoramento dos recursos do Oracle Transparent Data Encryption além da criptografia no nível das colunas. O banco de dados Oracle® 11g oferece criptografia de tablespaces, que pode ser utilizada para criptografar tabelas inteiras, índices e outros armazenamentos de dados.
Cubos OLAP incorporados
O banco de dados Oracle® 11g também oferece inovações em data warehousing. Os cubos OLAP foram aprimorados para se comportar como visualizações materializadas no banco de dados. Com isso, os desenvolvedores podem usar SQL padrão de mercado para consultas de dados, além de se beneficiarem com a alta performance proporcionada por um cubo OLAP. Os novos recursos de notificação contínua de consultas permitem que os aplicativos sejam notificados imediatamente, sempre que forem feitas alterações importantes nas informações contidas no banco de dados, sem sobrecarregá-lo com pesquisas constantes.
Pool de conexões e caches de resultados das consultas
Os recursos de desempenho e escalabilidade do banco de dados Oracle® 11g possibilitam às empresas manter uma infra-estrutura de serviços de alta qualidade. O novo produto consolida ainda mais a posição da Oracle como líder em desempenho e escalabilidade do mercado, com novos recursos como Query Result Caches, que melhoram o desempenho e a escalabilidade do aplicativo com o armazenamento em cache e a reutilização dos resultados de consultas acessadas com freqüência e as funções das camadas do banco de dados e do aplicativo. Oferece ainda o Database Resident Connection Pooling, que melhora a escalabilidade dos sistemas baseados na web ao fornecer pools de conexões para aplicativos que não são multithread, ou seja, quando diferentes partes de um código são executadas concorrentemente ou simultaneamente.
Desenvolvimento de aplicativos
O banco de dados Oracle® 11g oferece várias ferramentas e um processo rápido de desenvolvimento de aplicativos, que aproveita plenamente os principais recursos dessa nova versão. Dentre eles, estão os novos recursos como cache no cliente, XML binário para melhor desempenho dos aplicativos, processamento de XML e armazenamento e recuperação de arquivos. Além disso, o Oracle® 11g também inclui um novo compilador Java just-in-time para executar procedimentos Java no banco de dados mais rapidamente, sem a necessidade de um compilador de outro fornecedor; integração nativa com o Visual Studio 2005 para desenvolvimento de aplicativos .NET no Oracle; ferramentas de migração de Access com Oracle Application Express; e um recurso para fácil criação de consultas do SQL Developer e rápida codificação de rotinas SQL e PL/SQL.
Aprimoramentos no autogerenciamento e na automação
Os recursos de gerenciamento do banco de dados Oracle® 11g foram desenvolvidos para facilitar o gerenciamento dos grids empresariais, atendendo às expectativas dos usuários quanto ao nível dos serviços. O banco de dados Oracle® 11g conta com mais recursos de autogerenciamento e automação, que contribuem para a redução dos custos de gerenciamento dos sistemas e o aumento do desempenho, da escalabilidade, da disponibilidade e da segurança de seus aplicativos do banco de dados. Entre os novos recursos de gerenciamento presentes no Oracle® 11g, destacam-se o ajuste automático de SQL e memória; o novo Partitioning Advisor que sugere aos administradores automaticamente como particionar tabelas e índices para melhorar o desempenho; e diagnóstico aprimorado do desempenho para clusters de banco de dados. Além disso, o banco de dados Oracle® 11g inclui um novo Support Workbench que fornece uma interface fácil de usar, que apresenta incidentes relacionados à integridade do banco de dados aos administradores, junto com informações para conduzir a resolução rapidamente.
O banco de dados Oracle é o número 1, segundo o relatório mundial do Gartner sobre a participação no mercado de banco de dados relacional (RDBMS, em inglês) de 2006.
O Gartner publicou recentemente seus números de participação de mercado por sistema operacional referentes ao ano de 2006, com base na receita total de software. Segundo o instituto, a Oracle:
Tem 47,1% de participação (contra 46,8% em 2005);
Tem um crescimento da receita de 14,9%, superior à média do mercado de 14,2%, com US$ 7,2 bilhões; e,
Continua a deter mais participação de mercado do que seus dois concorrentes mais próximos juntos.
Sobre o banco de dados Oracle® 11g.
Com o lançamento do banco de dados Oracle® 11g, único banco de dados projetado para grid computing, a Oracle torna a gestão das informações empresariais mais fácil do que nunca. O produto permite que os clientes saibam mais sobre seus negócios e inovem com mais agilidade. O Oracle® 11g oferece desempenho superior, escalabilidade, disponibilidade, segurança e facilidade de gerenciamento em um grid de servidores e armazenamento padrão de mercado e de baixo custo. O banco de dados Oracle® 11g foi projetado para ser implementado com eficácia nas mais variadas plataformas – dos menores servidores blade aos maiores servidores SMP e clusters de todos os tamanhos. Ele conta com recursos automatizados de gerenciamento para proporcionar uma operação fácil e econômica. O recurso exclusivo do Oracle® 11g que gerencia todos os dados – de informações de negócios tradicionais a XML e informações espaciais em 3D – torna o produto ideal para aplicações de processamento de transações, data warehousing e gestão de conteúdo.
###
Sobre a Oracle
Oracle (NASDAQ: ORCL) é a maior empresa de software empresarial do mundo. Para obter mais informações, visite o site www.oracle.com.br.
Marcas Comerciais
Oracle, JD Edwards, PeopleSoft e Siebel são marcas registradas da Oracle Corporation e suas filiais. Outros nomes podem ser marcas comerciais de seus respectivos proprietários.
quinta-feira, 22 de outubro de 2009
segunda-feira, 19 de outubro de 2009
WEB 2.0
Web 2.0
O termo Web 2.0 é a segunda geração da World Wide Web – tendência que reforça o conceito de troca de informações e colaboração dos internautas com sites e serviços virtuais. A idéia é que o ambiente on-line se torne mais dinâmico e que os usuários colaborem para a organização de conteúdo. O nome web 2.0 foi dado pela O’Reilly Media em 2004.
* Novos Serviços Online:
- Britannica Online: wikipedia;
- nytimes.com: Blogs;
- Sites pessoais: My Space;
- abc.go.com: YouTube;
- Yahoo! Directory: dei.icio.us
* Características
- Web como plataforma
- Inteligência Coletiva
- Mashups
- Melhor experiência do usuário
Web como uma plataforma
- Armazenamento e processamento de dados
Ex.: Writely, Flickr, Gmail
- Novas formas de lucro
- Não lançamentos de versões, o aprimoramento é continuo
- Não há necessidade de portar para diversas plataformas
- APIs Online
*Google Maps API, Amazon Web Services, eBay API
WRITELY
Writely é um processador de textos — assim como o Microsoft Word e o OpenOffice Writer — adquirido pela gigante Google que conta com uma grande diferença perante seus concorrentes: é online! Isso mesmo, não será necessário baixá-lo, pois ele é acessado pelo navegador, permitindo dessa forma que você crie, edite, revise e publique textos de qualquer computador do mundo que tenha acesso à Internet.
Como funciona?
Utilizar o Writely é muito fácil, para acessá-lo basta ter uma conta no Google. Ele trabalha com a mesma conta dos serviços Gmail e Orkut, bastando apenas colocar o login e senha desses serviços para conectar-se. Se você ainda não possui uma conta no Google, com apenas algumas horas de uso, você se torna um expert no aplicativo.
http://www.baixaki.com.br/download/writely.htm
FLICKR
Dentre tantas comunidades de compartilhamento de fotos, apenas uma consegue prender a atenção de fotógrafos amadores e profissionais: é o Flickr, uma comunidade online cheia de ferramentas especiais e com um sistema muito mais organizado que o de qualquer concorrente.
Isso justifica o fato das fotos encontradas nessa comunidade terem qualidade tão superior às demais, afinal, fotógrafos profissionais, estudantes de fotografia e mesmo amadores que levam o assunto mais a sério, acabam sempre escolhendo o site como endereço para apresentar aos amigos.
Isso faz com que os conhecedores do site procurem com freqüência imagens para usar em seu papel de parede ou apenas para guardar em seu computador. Entretanto, salvar as imagens uma por uma pode se tornar uma tarefa um tanto desagradável.
É aí que entra FlickrDown, um software que interage com o Flickr, permitindo ao usuário previamente cadastrado na comunidade copiar qualquer foto pública, além das imagens privadas do próprio usuário.
O software pesquisa de quatro maneiras diferentes: por usuário, por e-mail referente à conta, por palavra-chave — conhecida no Flickr com tag — ou por grupo (os usuários da comunidade costumam criar grupos com gêneros de imagens, como natureza, pessoas, etc.).
http://www.baixaki.com.br/download/flickrdown.htm
Inteligência Coletiva
Conceito
O conceito da inteligência coletiva foi criado a partir de alguns debates realizados por Pierre Lévy relacionados às tecnologias da inteligência. Caracteriza-se pela nova forma de pensamento sustentável através de conexões sociais que se tornam viáveis pela utilização das redes abertas de computação da internet.
As tecnologias da inteligência são representadas especialmente pelas linguagens, os sistemas de signos, recursos lógicos e pelos instrumentos dos quais nos servimos. Todo nosso funcionamento intelectual é induzido por essas representações. Segundo o filósofo e sociólogo criador do conceito de inteligência coletiva Pierre Lévy, os seres humanos são incapazes de pensar só e sem o auxílio de qualquer ferramenta.
A inteligência coletiva seria uma forma de o homem pensar e compartir seus conhecimentos com outras pessoas, utilizando recursos mecânicos como, por exemplo, a internet. Nela os próprios usuários é que geram o conteúdo através da interatividade com o website.
http://www.mundoeducacao.com.br/informatica/inteligencia-coletiva.htm
Colaboração
- Wikis
Os termos wiki (pronunciado /uíqui/ ou /víqui/) e WikiWiki são utilizados para identificar um tipo específico de coleção de documentos em hipertexto ou o software colaborativo usado para criá-lo.
O termo "Wiki wiki" significa "super-rápido" no idioma havaiano. Já em maori Wiki significa "fim-de-semana". É também a forma diminutiva de Wikitoria, versão Maori do popular nome cristão Vitória.
Chamado "wiki" por consenso, o software colaborativo permite a edição coletiva dos documentos usando um sistema que não necessita que o conteúdo tenha que ser revisto antes da sua publicação.
Wiki (com um 'W' maiúsculo) e WikiWikiWeb são por vezes usados para se referir ao Portland Patrern Repository, primeiro wiki; os proponentes desta utilização sugerem a utilização de um 'w' minúsculo para distinguir o conceito. Porém, a utilização de diferenciação através de tipos maiúsculos e minúsculos é problemática em função deste tipo de uso não ser aceito nas linguagens humanas, ou melhor, não é perceptível na linguagem oral.
Principais características
WikiWeb permite que os documentos sejam editados colectivamente com uma linguagem de marcação muito simples e eficaz, através da utilização de um navegador web. Dado que a grande maioria dos wikis são baseados na web, o termo wiki é normalmente suficiente. Uma única página num wiki é referida como uma "única página", enquanto o conjunto total de páginas, que estão normalmente altamente interligadas, chama-se 'o wiki'.
Uma das características definitivas da tecnologia wiki é a facilidade com que as páginas são criadas e alteradas - geralmente não existe qualquer revisão antes de as modificações serem aceitas, e a maioria dos wikis são abertos a todo o público ou pelo menos a todas as pessoas que têm acesso ao servidor wiki. Nem o registro de usuários é obrigatório em todos os wikis.
Coletividade
O que faz o "wiki" tão diferente das outras páginas da Internet é certamente o fato de poder ser editado pelos usuários que por ele navegam. Por exemplo, essa parte do artigo foi adicionada anos após a criação do próprio, e, com certeza, não será a última edição; ela será modificada por usuários e visitantes ao longo do tempo. Desse jeito, é possível corrigir erros, complementar ideias e inserir novas informações. Assim, o conteúdo de um artigo se atualiza graças à coletividade. Os problemas que se podem encontrar em wikis são artigos feitos por pessoas que nem sempre são especialistas no assunto, ou até vandalismo, substituindo o conteúdo do artigo. Porém, o intuito é, justamente, que a página acabe por ser editada por alguém com mais conhecimentos!
Página e edição
Em wikis tradicionais, existem 3 (três) representações para cada página: o código HTML, a página resultante do código da sua edição pelo web browser, e o código-editado em HTML que o servidor produziu.
O raciocínio por detrás deste design é que o HTML, com sua enorme biblioteca de tags, dificulta uma edição mais rápida. Ele, às vezes, não pode usar toda a sua funcionalidade, como JavaScript e folhas de estilo, por causa da consistência da linguagem.
Sintaxe Wiki (Wikipedia) HTML Edição de Saída
"''Doutor''? Sem outro título? Um ''sábio''? É justa a autoridade civil?"
"Porque, certamente," replica Harddriveing, amigavelmente. "Todos nós sábios sabemos mais ou menos."
"Porque, certamente," replica Harddriveing, amigavelmente. "Todos nós sábios sabemos mais ou menos."
Alguns mecanismos de edição wiki mais recentes usam um método diferente: suportam a edição "WYSIWYG" ("What You See Is What You Get", que significa basicamente "o que se vê é o que será"), geralmente com o suporte de um controle ActiveX ou um plug-in que traduz instruções graficamente introduzidas como "negrito" ou "itálico" nas tags correspondentes de HTML. Em tais implementações, salvar uma edição corresponde ao envio de uma nova versão HTML da página ao servidor, embora o usuário seja preservado desse detalhe técnico, uma vez que o código é gerado automaticamente, de forma transparente. Usuários que não possuem o plug-in necessário podem, em geral, editar a página do mesmo modo, editando diretamente o texto em código HTML.
As instruções de formatação permitidas por um wiki variam consideravelmente, dependendo do mecanismo wiki utilizado.
Wikis simples permitem apenas a formatação básica, enquanto os mais complexos suportam tabelas, imagens, fórmulas, ou até elementos interativos, como votações e jogos. Por este motivo, atualmente existe um esforço conjunto para definir um Wiki Markup Standard.
Ligando e criando páginas
Wikis são verdadeiras mídias hipertextuais, com estrutura de navegação não-linear. Cada página geralmente contém um grande número de ligações para outras páginas. Páginas com navegação hierárquica são frequentemente usadas em grandes wikis, mas não devem ser usadas. As ligações são criadas usando-se uma sintaxe específica, o chamado "padrão link".
Originalmente, a maioria dos wikis usavam CamelCase como padrão link, produzido por palavras que começam com letras maiúsculas, sem espaço entre elas (a palavra "CamelCase" é em si um exemplo de CamelCase). Embora o CamelCase faça ligações muito facilmente, também cria ligações que são escritas de uma forma que se desvia da escrita padrão. Wikis baseados em CamelCase são instantaneamente reconhecíveis em um grande número de ligações com nomes como "TableOfContents" e "BeginnerQuestions".
Vale lembrar que, dentro de um universo wiki, não existem dois artigos com títulos repetidos, pois faz parte da filosofia wiki utilizar-se da tecnologia de armazenamento para ajudar a eliminar ambiguidades. Ao mesmo tempo, é bom perceber que o wiki tem a sensibilidade de distinguir maiúsculas de minúsculas como letras distintas para o armazenamento. Além disso, a própria ambigüidade do idioma utilizado pode, facilmente, gerar artigos repetidos, até mesmo com títulos extremamente parecidos, diferenciados apenas pelo caps (inglês para "maiúsculas e minúsculas", observado na maioria dos teclados ocidentais).
Controle dos usuários
A idéia por trás de controlar usuários é diretamente relacionada ao tamanho do universo gerado pelo wiki. Quanto mais pessoas estiverem usando o wiki, menor deveria ser a necessidade de níveis de controle, pois o controle é fornecido pela própria sociedade. Mas o controle sempre se faz necessário, em pelo menos dois níveis: gerenciamento e utilização.
Desta forma um wiki muito pequeno costuma ter a necessidade de adicionar um controle que impede autores anônimos para evitar vandalismo. Por outro lado, a maioria dos wikis públicos, que costumam ser grandes, dispensa qualquer tipo de registro.
De todo modo, muitos dos principais mecanismos wiki (incluindo MediaWiki, MoinMoin, UseModWiki e TWiki) têm como limitar o acesso à publicação. Alguns mecanismos wiki permitem que usuários sejam banidos do processo de edição pelo bloqueio do seu endereço particular na Internet endeerço IP, ou, quando disponível, o seu nome de usuário. Ainda assim, muitos provedores de acesso à Internet atribuem endereços de Internet endereço IP diferentes para cada usuário registrado, então o banimento de IP pode ser superado facilmente. Para lidar com esse problema, embargos temporários de IP são utilizados ocasionalmente e estendidos a todos os endereços IP dentro de um determinado âmbito, assegurando, deste modo, que um vândalo não consiga editar páginas durante um certo tempo; entende-se que isso seja uma barreira suficiente. Pode, contudo, impedir alguns usuários não problemáticos -- que venham do mesmo servidor de acesso à Internet -- de utilizar o serviço durante o período de embargo.
Uma defesa comum contra vândalos persistentes é deixá-los desfigurar tantas páginas quanto desejarem, sabendo que podem ser facilmente rastreadas e revertidas depois que o vândalo saia. Essa política pode se revelar pouco prática, no entanto, face a sistemáticas fraudes resultantes de raiva ou frustração.
Como uma medida de emergência, alguns wikis permitem que o banco de dados seja alterado para o modo apenas-leitura, enquanto outros adotam uma política em que apenas usuários que tenham sido registrados antes de algum corte arbitrário possam editar. Em geral, qualquer prejuízo infligido por um "vândalo" pode ser revertido rápida e facilmente. Mais problemáticos são os erros sutis que passam despercebidos como a alteração de datas de lançamento de álbuns e discografias na Wikipedia.
Exemplos
Exemplificando a idéia de que o wiki essencialmente precisa de somente dois níveis de controle, podem ser traçados alguns paralelos dentre as três áreas de estudos científicos (exatas, biológicas e humanas), o que facilita a visualização.
Criando um paralelo com o funcionamento de um computador simples, como uma calculadora, por exemplo, pode-se imaginar o wiki como sendo o próprio computador e o processador que executa o controle, enquanto o resto da calculadora a mantém funcionando, fornecendo entradas e saídas de dados em dois dispositivos diferenciados para o processador.
Fazendo um paralelo com o funcionamento de uma célula viva, pode-se imaginar o wiki como sendo a própria célula e o núcleo faz o gerenciamento de tudo que acontece dentro, enquanto o resto da célula, o núcleo inclusive, se utiliza dos recursos disponibilizados através da membrana externa (membrana plasmática) entre outros componentes da célula que executam múltiplas funções para mantê-la viva.
Fazendo um paralelo com o funcionamento de uma sociedade, pode-se imaginar o wiki como sendo a própria sociedade e o núcleo seria o governo, que cria a quantidade de regras que forem sendo necessárias para manter a sociedade funcionando com base na vida e dentro das possibilidades oferecidas pela própria sociedade e pelo ecossistema.
No ambiente da Educação Corporativa, diversas organizações estão utilizando esta tecnologia, como por exemplo, o Banco do Brasil e sua Universidade Corporativa utilizam em larga escala a Tecnologia Wiki.
Referências
• Aigrain, Philippe (2003). The Individual and the Collective in Open Information Communities. Invited talk at the 16th Bled Electronic Commerce Conference, Bled, Slovenija, 11 de Junho de 2003. Disponível em: http://www.debatpublic.net/Members/paigrain/texts/icoic.html
• Aronsson, Lars (2002). Operation of a Large Scale, General Purpose Wiki Website: Experience from susning.nu's first nine months in service. Paper presented at the 6th International ICCC/IFIP Conference on Electronic Publishing, 6 - 8 de Novembro, 2002, Karlovy Vary, Czech Republic. Disponível em: http://aronsson.se/wikipaper.html
• Benkler, Yochai (2002). Coase's penguin, or, Linux and The Nature of the Firm. The Yale Law Jounal. v.112, n.3, pp.369-446.
• Cunningham, Ward and Leuf, Bo (2001): The Wiki Way. Quick Collaboration on the Web. Addison-Wesley, ISBN 0-201-71499-X Delacroix, Jérôme (2005): Les wikis, espaces de l'intelligence collective M2 Editions, Paris, ISBN 0-201-71499-X. Web site : http://www.leswikis.com
• Jansson, Kurt (2002): "Wikipedia. Die Freie Enzyklopädie." Lecture at the 19th Chaos Communications Congress (19C3), 27 de Dezembro, Berlim. Descrição online: http://de.wikipedia.org/wiki/Benutzer:Kurt_Jansson/VOrtrag_auf_dem_dem_19C3
• Möller, Erik (2003). Loud and clear: How Internet media can work. Presentation at Open Cultures conference, June 5 - 6, Vienna. Disponível em: http:/opencultures.t0.or.at/oc/participants/moeller
• Möller, Erik (2003). Tanz der Gehirne. Telepolis, May 9-30. Quatro partes: "Das Wiki-Prinzip", "Alle gegen Brockhaus", "Diderots Traumtagebuch", "Diesen Artikel bearbeiten".
• Nakisa, Ramin (2003). "Wiki Wiki Wah Wah". Linux User and Developer v.29, pp.42-48. Disponível em: http:/194.73.119.134/lud29-Collaborative_Software-Wiki.pdf
• Remy, Melanie. (2002). Wikipedia: The Free Encyclopedia. Online Information Review. v.26, n.6, pp.434.
http://pt.wikipedia.org/wiki/Wiki
Rich Internet Applications (RIA)
Histórico dos RIAs
O termo Aplicação de Internet Rica foi introduzido pela Macromedia em março de 2002, embora o seu conceito já tenha tido outras denominações anteriores, tais como:
• Remote Scripting, pela Microsoft, em 1998
• X Internet, pela Forrester Research em Outubro de 2000
• Cliente (Web) Rico
• Aplicação Web Rica
Aplicações web tradicionais centralizam todo seu código em torno de uma arquitetura de Cliente-servidor e um cliente magro. Todo o processamento é realizado no servidor, e o cliente apenas utiliza uma tela estática (neste caso em HTML). A grande desvantagem deste sistema é que a interação com a aplicação deve ser feita através do servidor, onde os dados são enviados para o servidor, são respondidos e a página é recarregada no cliente como resposta. Utilizando uma tecnologia uma aplicação-cliente que possa executar instruções no computador do usuário, RIAs podem reduzir significativamente o número de sincronizações e aumentar a interatividade com o cliente. Esta diferença pode ser verificada fazendo uma analogia entre terminal e mainframe e servidor de aplicação/Cliente Gordo.
Os Padrões na Internet foram evoluindo lenta e continuamente ao longo do tempo para acomodar estas técnicas, por isso é difícil traçar uma linha entre aquilo que constitui um RIA e o que não não faz parte de um RIA. Porém, todos os RIAs compartilham uma característica: eles introduzem uma camada intermediária de código, chamada normalmente de client engine, entre o usuário e o servidor. Este client engine é normalmente carregado no início da aplicação, e pode ser acrescido de outras atualizações do código que são baixadas enquanto a aplicação ainda está rodando. O client engine atua como uma extensão do navegador, e é responsável pela renderização da interface de aplicação do usuário e fazer a comunição com o servidor.
O que pode ser feito em um RIA é limitado pela robustez do sistema utilizado no cliente. Mas, em geral, o client engine está programado para executar funções que a seu desenvolvedor acredita que irão reforçar alguns aspectos da interface do usuário, ou melhorar a sua resposta ao manusear certas interações com o usuário, em comparação com a execução da aplicação em um navegador da Web padrão.
Benefícios
Porque os RIAs empregam um client engine para interagir com o usuário? Entre os motivos estão:
• Riqueza. É possível oferecer à interface do usuário características que não podem ser obtidos utilizando apenas o HTML disponível no navegador para aplicações Web padrão. Esta capacidade de poder incluir qualquer coisa no lado do cliente, incluindo o arraste e solte, utilizar uma barra para alterar dados, cálculos efetuados apenas pelo cliente e que não precisam ser enviados volta para o servidor, como por exemplo, uma calculadora básica de quatro operações.
• Melhor resposta. A interface é mais reativa a ações do usuário do que em aplicações Web padrão que necessitam de uma constante interação com um servidor remoto. Com isto os RIAs levam o usuário a ter a sensação de estarem utilizando uma aplicação desktop.
• Equilibrio entre Cliente/Servidor. A carga de processamento entre o Cliente e Servidor torna-se mais equilibrada, visto que o servidor web não necessita realizar todo o processamento e enviar para o cliente, permitindo que o mesmo servidor possa lidar com mais sessões de clientes concomitantemente.
• Comunicação assíncrona. O client engine pode interagir com o servidor de forma assíncrona -- desta forma, uma ação na interface realizada pelo usuário como o clique em um botão ou link não necessite esperar por uma resposta do servidor, fazendo com que o usuário espere pelo processamento. Talvez o mais comum é que estas aplicações, a partir de uma solicitação, antecipe uma futura necessidade de alguns dados, e estes são carregados no cliente antes de o usuário solicite-os, de modo a acelerar uma posterior resposta. O site Google Maps utiliza esta técnica para, quando o usuário move o mapa, os segmentos adjacentes são carregados no cliente antes mesmo que o usuário mova a tela para estas áreas.
• Otimização da rede. O fluxo de dados na rede também pode ser significativamente reduzida, porque um client engine pode ter uma inteligência imbutida maior do que um navegador da Web padrão quando decidir quais os dados que precisam ser trocados com os servidores. Isto pode acelerar a solicitações individuais ou reduzir as respostas, porque muitos dos dados só são transferidos quando é realmente necessário, e a carga global da rede é reduzida. Entretanto, o uso destas técnicas podem neutralizar, ou mesmo reverter o potencial desse benefício. Isto porque o código não pode prever exatamente o que cada usuário irá fazer em seguida, sendo comum que tais técnicas baixar dados extras, para muitos ou todos os clientes, cause um tráfego desnecessário.
Deficiências e restrições
As deficiências e restrições associadas aos RIAs são:
• Sandbox. Os RIAs são executado dentro de um Sandbox, que restringe o acesso a recursos do sistema. Se as configurações de acesso aos recursos estão incorretas, os RIAs pode falhar ou não funcionar corretamente.
• Scripts desabilitados. JavaScripts ou outros scripts são muitas vezes utilizados. Se o usuário desativar a execução de scripts em seu navegador, o RIA poderá não funcionar corretamente, na maior parte das vezes.
• Velocidade de processamento no cliente. Para que as aplicações do lado do cliente tenha independência de plataforma, o lado do cliente muitas vezes são escritos em linguagens interpretadas, como JavaScript, que provocam uma sensível redução de desempenho. Isto não é problema para linguagens como Java, que tem seu desempenho comparado a linguagens compiltadas tradicionais, ou com o Flash, em que a maior parte das operações são executas pelo código nativo do próprio Flash.
• Tempo de carregamento da aplicação. Embora as aplicações não necessitem de serem instaladas, toda a inteligência do lado cliente (ou client engine) deve ser baixada do servidor para o cliente. Se estiver utilizando um web cache, esta carga deve ser realizada pelo menos uma vez. Dependendo do tamanho ou do tipo de solicitação, o carregamento do script pode ser demasiado longo. Desenvolvedores RIA podem reduzir este impacto através de uma compactação dos scripts, e fazer um carregamento progressivo das páginas, conforme ela forem sendo necessárias.
• Perda de Integridade. Se a aplicação-base é X/HTML, surgem conflitos entre o objetivo de uma aplicação (que naturalmente deseja estar no controle de toda a aplicação) e os objetivos do X/HTML (que naturalmente não mantém o estado da aplicação). A interface DOM torna possível a criação de RIAs, mas ao fazê-lo torna impossível garantir o seu funcionamento de forma correta. Isto porque um cliente RIA pode modificar a estrutura básica, sobrescrevendo-a, o que leva a uma modificação do comportamento da aplicação, causando uma falha irrecuperável ou crash no lado do cliente. Eventualmente, este problema pode ser resolvido através de mecanismos que garantam uma aplicação do lado cliente com restrições e limitar o acesso do usuário para somente os recursos que façam parte do escopo da aplicação. (Programas que executam de forma nativa não tem este problema, porque, por definição, automaticamente possui todos os direitos de todos os recursos alocados).
• Perda de visibilidade por Sites de Busca. Sites de busca podem não serem capazes de indexar os textos de um RIA.
• Dependência de uma conexão com a Internet. Enquanto numa aplicação desktop ideal permite que os seus usuários fiquem ocasionalmente conectados, passando de uma rede para outra, hoje (em 2007), um típico RIA requer que a aplicação fique permanentemente conectada à rede.
Dificuldades no Gerenciamento
Com a advento das tecnologias RIA introduziu-se consideravelmente novas complexidades dentro de uma aplicação web. Aplicações web tradicionais eram construídas usando somente o HTML padrão, sendo sua arquitetura relativamente simples e com estruturas e opções limitadas de desenvolvimento, possuía um design relativamente simples para ser gerenciado. Para uma pessoa ou organização usar tecnologias RIA em uma aplicação web, a complexidade acrescida torna-se indispensável um design mais rígido, com testes, dimensionamento da aplicação e suporte.
Usar uma tecnologia RIA é muitas vezes um novo desafio para o SLM, ainda não totalmente solucionado. SLM não só se preocupa em manter seu foco nos desenvolvedores e aplicativos, e raramente suas práticas são percebidas pelos usuários da aplicação, mas são vitais para o sucesso da entrega de uma aplicação online.
• Grande complexidade torna o desenvolvimento mais difícil. A capacidade de mover o código para o cliente dá aos designers e desenvolvedores muito mais liberdade criativa. Mas, em contrapartida, o desenvolvimento torna-se muito mais complexo, e a probabilidade de erros e defeitos (bugs) aumenta, o que exige testes mais complexos. Com isso, o processo de desenvolvimento de software torna-se mais longo, independentemento do processo ou metodologia específica empregada. Alguns desses problemas podem ser atenuados com a utilização de frameworks de desenvolvimento, para padronizar as características principais do design e desenvolvimento RIA. Aumentar a complexidade implica também prolongar o processo de testes, pois aumenta o número de casos de usos a ser testado. Testes incompletos ou deficientes reduzem a qualidade do software e sua confiabilidade durante a utilização. Pode-se dizer que o comentário acima não se aplica especificamente à tecnologia RIA, mas a complexidade em geral. Por exemplo, este argumento foi utilizado quando a Apple e a Microsoft anunciou a independência da GUI na década de 1980, ou mesmo quando a Ford anunciou o Modelo T. No entanto, os seres humanos têm mostrado uma notável capacidade de absorver os avanços tecnológicos ao longo de décadas, senão séculos.
• Arquitetura RIA quebra paradigmas de uma página Web. Aplicações web tradicionais podem ser vistas como uma série de páginas, cada uma com solicitações distintas de carregamento, inicializadas por uma requisição HTTP GET. Este modelo pode ser caracterizado como um paradigma de uma página web. RIAs invalida este modelo, introduzindo comunicações assíncronas adicionais para apoiar uma melhor resposta da interface para o usuário. Em RIAs, o tempo para completar o download de uma página já não corresponde como algo que um usuário vê como importante, porque o client engine pode prever a necessidade de carregar previamente alguns conteúdos para uso futuro. Novas técnicas de medição devem ser concebidas para poder mensurar um RIA, para poder a analisar se o tempo de resposta reflete na experiência do usuário. Na ausência de normas e ferramentas para tal, desenvolvedores RIA devem ter suas próprias técnicas para poder produzir os dados necessários para a medição SLM.
• Comunicação assíncrona torna mais difícil para isolar potenciais problemas. Paradoxalmente, as ações empreendidas para melhorar a aplicação e torná-las mais amigáveis tornam-na mais difícil de avaliar, compreender, reportá-las, e gerenciar sua compreensão. Alguns RIAs não emitem qualquer outra requisição HTTP GET ao navegador após o carregamento da primeira página, usando solicitações assíncrona realizadas pelo client engine para realizar os carregamentos necessários. O client engine pode ser programado para baixar continuamente novos conteúdos e atualizá-los na tela, ou (em aplicativos usando programação Comet) o novo conteúdo vai sendo baixado sem que a conexão com o navegador nunca se feche. Nestes casos, o conceito de uma "baixar uma página" já não é mais aplicável. Essas novas ténicas mais complexas tornam mais difíceis de se medir e subdividir os tempos de respostas de uma aplicação, um requisito fundamental para o isolamento de um problema e o seu gerenciamento.
• 'O uso do client engine torna a medição do tempo de resposta mais difícil'. Para aplicações tradicionais web, o tamanho de um software pode ser medido tanto na máquina do cliente ou em uma máquina próxima do servidor, desde que o nível do fluxo do trafego da rede TCP e HTTP possa ser observado. Como estes protocolos são síncronos e previsíveis, um sniffing pode ler e interpretar os pacotes de dados, e inferir o tempo de resposta através do rastreamento das mensagens HTTP e TCP. Mas uma arquitetura RIA reduz esta capacidade de inferir o tempo de resposta, pois o client engine rompe a comunicação entre usuários e servidores separando a comunicação em dois ciclos assíncronos: um ciclo externo (usuário para client engine) e interno (client engine para servidor). Ambos os ciclos são importantes, porque não funcionam sozinhos, e este tipo de relacionamento que define o comportamento da aplicação. Mas como este relacionamento depende do design da aplicação, que (em geral) não pode ser medida por uma ferramenta de medição, especialmente esta que observa somente um dos ciclos. Assim sendo, uma medição mais completa de um RIA só pode ser obtido usando feramentas que residem no cliente e que possa observar os dois ciclos.
http://pt.wikipedia.org/wiki/Internet_rica#Hist.C3.B3rico_dos_RIAs
O termo Web 2.0 é a segunda geração da World Wide Web – tendência que reforça o conceito de troca de informações e colaboração dos internautas com sites e serviços virtuais. A idéia é que o ambiente on-line se torne mais dinâmico e que os usuários colaborem para a organização de conteúdo. O nome web 2.0 foi dado pela O’Reilly Media em 2004.
* Novos Serviços Online:
- Britannica Online: wikipedia;
- nytimes.com: Blogs;
- Sites pessoais: My Space;
- abc.go.com: YouTube;
- Yahoo! Directory: dei.icio.us
* Características
- Web como plataforma
- Inteligência Coletiva
- Mashups
- Melhor experiência do usuário
Web como uma plataforma
- Armazenamento e processamento de dados
Ex.: Writely, Flickr, Gmail
- Novas formas de lucro
- Não lançamentos de versões, o aprimoramento é continuo
- Não há necessidade de portar para diversas plataformas
- APIs Online
*Google Maps API, Amazon Web Services, eBay API
WRITELY
Writely é um processador de textos — assim como o Microsoft Word e o OpenOffice Writer — adquirido pela gigante Google que conta com uma grande diferença perante seus concorrentes: é online! Isso mesmo, não será necessário baixá-lo, pois ele é acessado pelo navegador, permitindo dessa forma que você crie, edite, revise e publique textos de qualquer computador do mundo que tenha acesso à Internet.
Como funciona?
Utilizar o Writely é muito fácil, para acessá-lo basta ter uma conta no Google. Ele trabalha com a mesma conta dos serviços Gmail e Orkut, bastando apenas colocar o login e senha desses serviços para conectar-se. Se você ainda não possui uma conta no Google, com apenas algumas horas de uso, você se torna um expert no aplicativo.
http://www.baixaki.com.br/download/writely.htm
FLICKR
Dentre tantas comunidades de compartilhamento de fotos, apenas uma consegue prender a atenção de fotógrafos amadores e profissionais: é o Flickr, uma comunidade online cheia de ferramentas especiais e com um sistema muito mais organizado que o de qualquer concorrente.
Isso justifica o fato das fotos encontradas nessa comunidade terem qualidade tão superior às demais, afinal, fotógrafos profissionais, estudantes de fotografia e mesmo amadores que levam o assunto mais a sério, acabam sempre escolhendo o site como endereço para apresentar aos amigos.
Isso faz com que os conhecedores do site procurem com freqüência imagens para usar em seu papel de parede ou apenas para guardar em seu computador. Entretanto, salvar as imagens uma por uma pode se tornar uma tarefa um tanto desagradável.
É aí que entra FlickrDown, um software que interage com o Flickr, permitindo ao usuário previamente cadastrado na comunidade copiar qualquer foto pública, além das imagens privadas do próprio usuário.
O software pesquisa de quatro maneiras diferentes: por usuário, por e-mail referente à conta, por palavra-chave — conhecida no Flickr com tag — ou por grupo (os usuários da comunidade costumam criar grupos com gêneros de imagens, como natureza, pessoas, etc.).
http://www.baixaki.com.br/download/flickrdown.htm
Inteligência Coletiva
Conceito
O conceito da inteligência coletiva foi criado a partir de alguns debates realizados por Pierre Lévy relacionados às tecnologias da inteligência. Caracteriza-se pela nova forma de pensamento sustentável através de conexões sociais que se tornam viáveis pela utilização das redes abertas de computação da internet.
As tecnologias da inteligência são representadas especialmente pelas linguagens, os sistemas de signos, recursos lógicos e pelos instrumentos dos quais nos servimos. Todo nosso funcionamento intelectual é induzido por essas representações. Segundo o filósofo e sociólogo criador do conceito de inteligência coletiva Pierre Lévy, os seres humanos são incapazes de pensar só e sem o auxílio de qualquer ferramenta.
A inteligência coletiva seria uma forma de o homem pensar e compartir seus conhecimentos com outras pessoas, utilizando recursos mecânicos como, por exemplo, a internet. Nela os próprios usuários é que geram o conteúdo através da interatividade com o website.
http://www.mundoeducacao.com.br/informatica/inteligencia-coletiva.htm
Colaboração
- Wikis
Os termos wiki (pronunciado /uíqui/ ou /víqui/) e WikiWiki são utilizados para identificar um tipo específico de coleção de documentos em hipertexto ou o software colaborativo usado para criá-lo.
O termo "Wiki wiki" significa "super-rápido" no idioma havaiano. Já em maori Wiki significa "fim-de-semana". É também a forma diminutiva de Wikitoria, versão Maori do popular nome cristão Vitória.
Chamado "wiki" por consenso, o software colaborativo permite a edição coletiva dos documentos usando um sistema que não necessita que o conteúdo tenha que ser revisto antes da sua publicação.
Wiki (com um 'W' maiúsculo) e WikiWikiWeb são por vezes usados para se referir ao Portland Patrern Repository, primeiro wiki; os proponentes desta utilização sugerem a utilização de um 'w' minúsculo para distinguir o conceito. Porém, a utilização de diferenciação através de tipos maiúsculos e minúsculos é problemática em função deste tipo de uso não ser aceito nas linguagens humanas, ou melhor, não é perceptível na linguagem oral.
Principais características
WikiWeb permite que os documentos sejam editados colectivamente com uma linguagem de marcação muito simples e eficaz, através da utilização de um navegador web. Dado que a grande maioria dos wikis são baseados na web, o termo wiki é normalmente suficiente. Uma única página num wiki é referida como uma "única página", enquanto o conjunto total de páginas, que estão normalmente altamente interligadas, chama-se 'o wiki'.
Uma das características definitivas da tecnologia wiki é a facilidade com que as páginas são criadas e alteradas - geralmente não existe qualquer revisão antes de as modificações serem aceitas, e a maioria dos wikis são abertos a todo o público ou pelo menos a todas as pessoas que têm acesso ao servidor wiki. Nem o registro de usuários é obrigatório em todos os wikis.
Coletividade
O que faz o "wiki" tão diferente das outras páginas da Internet é certamente o fato de poder ser editado pelos usuários que por ele navegam. Por exemplo, essa parte do artigo foi adicionada anos após a criação do próprio, e, com certeza, não será a última edição; ela será modificada por usuários e visitantes ao longo do tempo. Desse jeito, é possível corrigir erros, complementar ideias e inserir novas informações. Assim, o conteúdo de um artigo se atualiza graças à coletividade. Os problemas que se podem encontrar em wikis são artigos feitos por pessoas que nem sempre são especialistas no assunto, ou até vandalismo, substituindo o conteúdo do artigo. Porém, o intuito é, justamente, que a página acabe por ser editada por alguém com mais conhecimentos!
Página e edição
Em wikis tradicionais, existem 3 (três) representações para cada página: o código HTML, a página resultante do código da sua edição pelo web browser, e o código-editado em HTML que o servidor produziu.
O raciocínio por detrás deste design é que o HTML, com sua enorme biblioteca de tags, dificulta uma edição mais rápida. Ele, às vezes, não pode usar toda a sua funcionalidade, como JavaScript e folhas de estilo, por causa da consistência da linguagem.
Sintaxe Wiki (Wikipedia) HTML Edição de Saída
"''Doutor''? Sem outro título? Um ''sábio''? É justa a autoridade civil?"
"Porque, certamente," replica Harddriveing, amigavelmente. "Todos nós sábios sabemos mais ou menos."
"Doutor? Sem outro título? Um sábio? É justa a autoridade civil?"
"Porque, certamente," replica Harddriveing, amigavelmente. "Todos nós sábios sabemos mais ou menos."
"Porque, certamente," replica Harddriveing, amigavelmente. "Todos nós sábios sabemos mais ou menos."
Alguns mecanismos de edição wiki mais recentes usam um método diferente: suportam a edição "WYSIWYG" ("What You See Is What You Get", que significa basicamente "o que se vê é o que será"), geralmente com o suporte de um controle ActiveX ou um plug-in que traduz instruções graficamente introduzidas como "negrito" ou "itálico" nas tags correspondentes de HTML. Em tais implementações, salvar uma edição corresponde ao envio de uma nova versão HTML da página ao servidor, embora o usuário seja preservado desse detalhe técnico, uma vez que o código é gerado automaticamente, de forma transparente. Usuários que não possuem o plug-in necessário podem, em geral, editar a página do mesmo modo, editando diretamente o texto em código HTML.
As instruções de formatação permitidas por um wiki variam consideravelmente, dependendo do mecanismo wiki utilizado.
Wikis simples permitem apenas a formatação básica, enquanto os mais complexos suportam tabelas, imagens, fórmulas, ou até elementos interativos, como votações e jogos. Por este motivo, atualmente existe um esforço conjunto para definir um Wiki Markup Standard.
Ligando e criando páginas
Wikis são verdadeiras mídias hipertextuais, com estrutura de navegação não-linear. Cada página geralmente contém um grande número de ligações para outras páginas. Páginas com navegação hierárquica são frequentemente usadas em grandes wikis, mas não devem ser usadas. As ligações são criadas usando-se uma sintaxe específica, o chamado "padrão link".
Originalmente, a maioria dos wikis usavam CamelCase como padrão link, produzido por palavras que começam com letras maiúsculas, sem espaço entre elas (a palavra "CamelCase" é em si um exemplo de CamelCase). Embora o CamelCase faça ligações muito facilmente, também cria ligações que são escritas de uma forma que se desvia da escrita padrão. Wikis baseados em CamelCase são instantaneamente reconhecíveis em um grande número de ligações com nomes como "TableOfContents" e "BeginnerQuestions".
Vale lembrar que, dentro de um universo wiki, não existem dois artigos com títulos repetidos, pois faz parte da filosofia wiki utilizar-se da tecnologia de armazenamento para ajudar a eliminar ambiguidades. Ao mesmo tempo, é bom perceber que o wiki tem a sensibilidade de distinguir maiúsculas de minúsculas como letras distintas para o armazenamento. Além disso, a própria ambigüidade do idioma utilizado pode, facilmente, gerar artigos repetidos, até mesmo com títulos extremamente parecidos, diferenciados apenas pelo caps (inglês para "maiúsculas e minúsculas", observado na maioria dos teclados ocidentais).
Controle dos usuários
A idéia por trás de controlar usuários é diretamente relacionada ao tamanho do universo gerado pelo wiki. Quanto mais pessoas estiverem usando o wiki, menor deveria ser a necessidade de níveis de controle, pois o controle é fornecido pela própria sociedade. Mas o controle sempre se faz necessário, em pelo menos dois níveis: gerenciamento e utilização.
Desta forma um wiki muito pequeno costuma ter a necessidade de adicionar um controle que impede autores anônimos para evitar vandalismo. Por outro lado, a maioria dos wikis públicos, que costumam ser grandes, dispensa qualquer tipo de registro.
De todo modo, muitos dos principais mecanismos wiki (incluindo MediaWiki, MoinMoin, UseModWiki e TWiki) têm como limitar o acesso à publicação. Alguns mecanismos wiki permitem que usuários sejam banidos do processo de edição pelo bloqueio do seu endereço particular na Internet endeerço IP, ou, quando disponível, o seu nome de usuário. Ainda assim, muitos provedores de acesso à Internet atribuem endereços de Internet endereço IP diferentes para cada usuário registrado, então o banimento de IP pode ser superado facilmente. Para lidar com esse problema, embargos temporários de IP são utilizados ocasionalmente e estendidos a todos os endereços IP dentro de um determinado âmbito, assegurando, deste modo, que um vândalo não consiga editar páginas durante um certo tempo; entende-se que isso seja uma barreira suficiente. Pode, contudo, impedir alguns usuários não problemáticos -- que venham do mesmo servidor de acesso à Internet -- de utilizar o serviço durante o período de embargo.
Uma defesa comum contra vândalos persistentes é deixá-los desfigurar tantas páginas quanto desejarem, sabendo que podem ser facilmente rastreadas e revertidas depois que o vândalo saia. Essa política pode se revelar pouco prática, no entanto, face a sistemáticas fraudes resultantes de raiva ou frustração.
Como uma medida de emergência, alguns wikis permitem que o banco de dados seja alterado para o modo apenas-leitura, enquanto outros adotam uma política em que apenas usuários que tenham sido registrados antes de algum corte arbitrário possam editar. Em geral, qualquer prejuízo infligido por um "vândalo" pode ser revertido rápida e facilmente. Mais problemáticos são os erros sutis que passam despercebidos como a alteração de datas de lançamento de álbuns e discografias na Wikipedia.
Exemplos
Exemplificando a idéia de que o wiki essencialmente precisa de somente dois níveis de controle, podem ser traçados alguns paralelos dentre as três áreas de estudos científicos (exatas, biológicas e humanas), o que facilita a visualização.
Criando um paralelo com o funcionamento de um computador simples, como uma calculadora, por exemplo, pode-se imaginar o wiki como sendo o próprio computador e o processador que executa o controle, enquanto o resto da calculadora a mantém funcionando, fornecendo entradas e saídas de dados em dois dispositivos diferenciados para o processador.
Fazendo um paralelo com o funcionamento de uma célula viva, pode-se imaginar o wiki como sendo a própria célula e o núcleo faz o gerenciamento de tudo que acontece dentro, enquanto o resto da célula, o núcleo inclusive, se utiliza dos recursos disponibilizados através da membrana externa (membrana plasmática) entre outros componentes da célula que executam múltiplas funções para mantê-la viva.
Fazendo um paralelo com o funcionamento de uma sociedade, pode-se imaginar o wiki como sendo a própria sociedade e o núcleo seria o governo, que cria a quantidade de regras que forem sendo necessárias para manter a sociedade funcionando com base na vida e dentro das possibilidades oferecidas pela própria sociedade e pelo ecossistema.
No ambiente da Educação Corporativa, diversas organizações estão utilizando esta tecnologia, como por exemplo, o Banco do Brasil e sua Universidade Corporativa utilizam em larga escala a Tecnologia Wiki.
Referências
• Aigrain, Philippe (2003). The Individual and the Collective in Open Information Communities. Invited talk at the 16th Bled Electronic Commerce Conference, Bled, Slovenija, 11 de Junho de 2003. Disponível em: http://www.debatpublic.net/Members/paigrain/texts/icoic.html
• Aronsson, Lars (2002). Operation of a Large Scale, General Purpose Wiki Website: Experience from susning.nu's first nine months in service. Paper presented at the 6th International ICCC/IFIP Conference on Electronic Publishing, 6 - 8 de Novembro, 2002, Karlovy Vary, Czech Republic. Disponível em: http://aronsson.se/wikipaper.html
• Benkler, Yochai (2002). Coase's penguin, or, Linux and The Nature of the Firm. The Yale Law Jounal. v.112, n.3, pp.369-446.
• Cunningham, Ward and Leuf, Bo (2001): The Wiki Way. Quick Collaboration on the Web. Addison-Wesley, ISBN 0-201-71499-X Delacroix, Jérôme (2005): Les wikis, espaces de l'intelligence collective M2 Editions, Paris, ISBN 0-201-71499-X. Web site : http://www.leswikis.com
• Jansson, Kurt (2002): "Wikipedia. Die Freie Enzyklopädie." Lecture at the 19th Chaos Communications Congress (19C3), 27 de Dezembro, Berlim. Descrição online: http://de.wikipedia.org/wiki/Benutzer:Kurt_Jansson/VOrtrag_auf_dem_dem_19C3
• Möller, Erik (2003). Loud and clear: How Internet media can work. Presentation at Open Cultures conference, June 5 - 6, Vienna. Disponível em: http:/opencultures.t0.or.at/oc/participants/moeller
• Möller, Erik (2003). Tanz der Gehirne. Telepolis, May 9-30. Quatro partes: "Das Wiki-Prinzip", "Alle gegen Brockhaus", "Diderots Traumtagebuch", "Diesen Artikel bearbeiten".
• Nakisa, Ramin (2003). "Wiki Wiki Wah Wah". Linux User and Developer v.29, pp.42-48. Disponível em: http:/194.73.119.134/lud29-Collaborative_Software-Wiki.pdf
• Remy, Melanie. (2002). Wikipedia: The Free Encyclopedia. Online Information Review. v.26, n.6, pp.434.
http://pt.wikipedia.org/wiki/Wiki
Rich Internet Applications (RIA)
Histórico dos RIAs
O termo Aplicação de Internet Rica foi introduzido pela Macromedia em março de 2002, embora o seu conceito já tenha tido outras denominações anteriores, tais como:
• Remote Scripting, pela Microsoft, em 1998
• X Internet, pela Forrester Research em Outubro de 2000
• Cliente (Web) Rico
• Aplicação Web Rica
Aplicações web tradicionais centralizam todo seu código em torno de uma arquitetura de Cliente-servidor e um cliente magro. Todo o processamento é realizado no servidor, e o cliente apenas utiliza uma tela estática (neste caso em HTML). A grande desvantagem deste sistema é que a interação com a aplicação deve ser feita através do servidor, onde os dados são enviados para o servidor, são respondidos e a página é recarregada no cliente como resposta. Utilizando uma tecnologia uma aplicação-cliente que possa executar instruções no computador do usuário, RIAs podem reduzir significativamente o número de sincronizações e aumentar a interatividade com o cliente. Esta diferença pode ser verificada fazendo uma analogia entre terminal e mainframe e servidor de aplicação/Cliente Gordo.
Os Padrões na Internet foram evoluindo lenta e continuamente ao longo do tempo para acomodar estas técnicas, por isso é difícil traçar uma linha entre aquilo que constitui um RIA e o que não não faz parte de um RIA. Porém, todos os RIAs compartilham uma característica: eles introduzem uma camada intermediária de código, chamada normalmente de client engine, entre o usuário e o servidor. Este client engine é normalmente carregado no início da aplicação, e pode ser acrescido de outras atualizações do código que são baixadas enquanto a aplicação ainda está rodando. O client engine atua como uma extensão do navegador, e é responsável pela renderização da interface de aplicação do usuário e fazer a comunição com o servidor.
O que pode ser feito em um RIA é limitado pela robustez do sistema utilizado no cliente. Mas, em geral, o client engine está programado para executar funções que a seu desenvolvedor acredita que irão reforçar alguns aspectos da interface do usuário, ou melhorar a sua resposta ao manusear certas interações com o usuário, em comparação com a execução da aplicação em um navegador da Web padrão.
Benefícios
Porque os RIAs empregam um client engine para interagir com o usuário? Entre os motivos estão:
• Riqueza. É possível oferecer à interface do usuário características que não podem ser obtidos utilizando apenas o HTML disponível no navegador para aplicações Web padrão. Esta capacidade de poder incluir qualquer coisa no lado do cliente, incluindo o arraste e solte, utilizar uma barra para alterar dados, cálculos efetuados apenas pelo cliente e que não precisam ser enviados volta para o servidor, como por exemplo, uma calculadora básica de quatro operações.
• Melhor resposta. A interface é mais reativa a ações do usuário do que em aplicações Web padrão que necessitam de uma constante interação com um servidor remoto. Com isto os RIAs levam o usuário a ter a sensação de estarem utilizando uma aplicação desktop.
• Equilibrio entre Cliente/Servidor. A carga de processamento entre o Cliente e Servidor torna-se mais equilibrada, visto que o servidor web não necessita realizar todo o processamento e enviar para o cliente, permitindo que o mesmo servidor possa lidar com mais sessões de clientes concomitantemente.
• Comunicação assíncrona. O client engine pode interagir com o servidor de forma assíncrona -- desta forma, uma ação na interface realizada pelo usuário como o clique em um botão ou link não necessite esperar por uma resposta do servidor, fazendo com que o usuário espere pelo processamento. Talvez o mais comum é que estas aplicações, a partir de uma solicitação, antecipe uma futura necessidade de alguns dados, e estes são carregados no cliente antes de o usuário solicite-os, de modo a acelerar uma posterior resposta. O site Google Maps utiliza esta técnica para, quando o usuário move o mapa, os segmentos adjacentes são carregados no cliente antes mesmo que o usuário mova a tela para estas áreas.
• Otimização da rede. O fluxo de dados na rede também pode ser significativamente reduzida, porque um client engine pode ter uma inteligência imbutida maior do que um navegador da Web padrão quando decidir quais os dados que precisam ser trocados com os servidores. Isto pode acelerar a solicitações individuais ou reduzir as respostas, porque muitos dos dados só são transferidos quando é realmente necessário, e a carga global da rede é reduzida. Entretanto, o uso destas técnicas podem neutralizar, ou mesmo reverter o potencial desse benefício. Isto porque o código não pode prever exatamente o que cada usuário irá fazer em seguida, sendo comum que tais técnicas baixar dados extras, para muitos ou todos os clientes, cause um tráfego desnecessário.
Deficiências e restrições
As deficiências e restrições associadas aos RIAs são:
• Sandbox. Os RIAs são executado dentro de um Sandbox, que restringe o acesso a recursos do sistema. Se as configurações de acesso aos recursos estão incorretas, os RIAs pode falhar ou não funcionar corretamente.
• Scripts desabilitados. JavaScripts ou outros scripts são muitas vezes utilizados. Se o usuário desativar a execução de scripts em seu navegador, o RIA poderá não funcionar corretamente, na maior parte das vezes.
• Velocidade de processamento no cliente. Para que as aplicações do lado do cliente tenha independência de plataforma, o lado do cliente muitas vezes são escritos em linguagens interpretadas, como JavaScript, que provocam uma sensível redução de desempenho. Isto não é problema para linguagens como Java, que tem seu desempenho comparado a linguagens compiltadas tradicionais, ou com o Flash, em que a maior parte das operações são executas pelo código nativo do próprio Flash.
• Tempo de carregamento da aplicação. Embora as aplicações não necessitem de serem instaladas, toda a inteligência do lado cliente (ou client engine) deve ser baixada do servidor para o cliente. Se estiver utilizando um web cache, esta carga deve ser realizada pelo menos uma vez. Dependendo do tamanho ou do tipo de solicitação, o carregamento do script pode ser demasiado longo. Desenvolvedores RIA podem reduzir este impacto através de uma compactação dos scripts, e fazer um carregamento progressivo das páginas, conforme ela forem sendo necessárias.
• Perda de Integridade. Se a aplicação-base é X/HTML, surgem conflitos entre o objetivo de uma aplicação (que naturalmente deseja estar no controle de toda a aplicação) e os objetivos do X/HTML (que naturalmente não mantém o estado da aplicação). A interface DOM torna possível a criação de RIAs, mas ao fazê-lo torna impossível garantir o seu funcionamento de forma correta. Isto porque um cliente RIA pode modificar a estrutura básica, sobrescrevendo-a, o que leva a uma modificação do comportamento da aplicação, causando uma falha irrecuperável ou crash no lado do cliente. Eventualmente, este problema pode ser resolvido através de mecanismos que garantam uma aplicação do lado cliente com restrições e limitar o acesso do usuário para somente os recursos que façam parte do escopo da aplicação. (Programas que executam de forma nativa não tem este problema, porque, por definição, automaticamente possui todos os direitos de todos os recursos alocados).
• Perda de visibilidade por Sites de Busca. Sites de busca podem não serem capazes de indexar os textos de um RIA.
• Dependência de uma conexão com a Internet. Enquanto numa aplicação desktop ideal permite que os seus usuários fiquem ocasionalmente conectados, passando de uma rede para outra, hoje (em 2007), um típico RIA requer que a aplicação fique permanentemente conectada à rede.
Dificuldades no Gerenciamento
Com a advento das tecnologias RIA introduziu-se consideravelmente novas complexidades dentro de uma aplicação web. Aplicações web tradicionais eram construídas usando somente o HTML padrão, sendo sua arquitetura relativamente simples e com estruturas e opções limitadas de desenvolvimento, possuía um design relativamente simples para ser gerenciado. Para uma pessoa ou organização usar tecnologias RIA em uma aplicação web, a complexidade acrescida torna-se indispensável um design mais rígido, com testes, dimensionamento da aplicação e suporte.
Usar uma tecnologia RIA é muitas vezes um novo desafio para o SLM, ainda não totalmente solucionado. SLM não só se preocupa em manter seu foco nos desenvolvedores e aplicativos, e raramente suas práticas são percebidas pelos usuários da aplicação, mas são vitais para o sucesso da entrega de uma aplicação online.
• Grande complexidade torna o desenvolvimento mais difícil. A capacidade de mover o código para o cliente dá aos designers e desenvolvedores muito mais liberdade criativa. Mas, em contrapartida, o desenvolvimento torna-se muito mais complexo, e a probabilidade de erros e defeitos (bugs) aumenta, o que exige testes mais complexos. Com isso, o processo de desenvolvimento de software torna-se mais longo, independentemento do processo ou metodologia específica empregada. Alguns desses problemas podem ser atenuados com a utilização de frameworks de desenvolvimento, para padronizar as características principais do design e desenvolvimento RIA. Aumentar a complexidade implica também prolongar o processo de testes, pois aumenta o número de casos de usos a ser testado. Testes incompletos ou deficientes reduzem a qualidade do software e sua confiabilidade durante a utilização. Pode-se dizer que o comentário acima não se aplica especificamente à tecnologia RIA, mas a complexidade em geral. Por exemplo, este argumento foi utilizado quando a Apple e a Microsoft anunciou a independência da GUI na década de 1980, ou mesmo quando a Ford anunciou o Modelo T. No entanto, os seres humanos têm mostrado uma notável capacidade de absorver os avanços tecnológicos ao longo de décadas, senão séculos.
• Arquitetura RIA quebra paradigmas de uma página Web. Aplicações web tradicionais podem ser vistas como uma série de páginas, cada uma com solicitações distintas de carregamento, inicializadas por uma requisição HTTP GET. Este modelo pode ser caracterizado como um paradigma de uma página web. RIAs invalida este modelo, introduzindo comunicações assíncronas adicionais para apoiar uma melhor resposta da interface para o usuário. Em RIAs, o tempo para completar o download de uma página já não corresponde como algo que um usuário vê como importante, porque o client engine pode prever a necessidade de carregar previamente alguns conteúdos para uso futuro. Novas técnicas de medição devem ser concebidas para poder mensurar um RIA, para poder a analisar se o tempo de resposta reflete na experiência do usuário. Na ausência de normas e ferramentas para tal, desenvolvedores RIA devem ter suas próprias técnicas para poder produzir os dados necessários para a medição SLM.
• Comunicação assíncrona torna mais difícil para isolar potenciais problemas. Paradoxalmente, as ações empreendidas para melhorar a aplicação e torná-las mais amigáveis tornam-na mais difícil de avaliar, compreender, reportá-las, e gerenciar sua compreensão. Alguns RIAs não emitem qualquer outra requisição HTTP GET ao navegador após o carregamento da primeira página, usando solicitações assíncrona realizadas pelo client engine para realizar os carregamentos necessários. O client engine pode ser programado para baixar continuamente novos conteúdos e atualizá-los na tela, ou (em aplicativos usando programação Comet) o novo conteúdo vai sendo baixado sem que a conexão com o navegador nunca se feche. Nestes casos, o conceito de uma "baixar uma página" já não é mais aplicável. Essas novas ténicas mais complexas tornam mais difíceis de se medir e subdividir os tempos de respostas de uma aplicação, um requisito fundamental para o isolamento de um problema e o seu gerenciamento.
• 'O uso do client engine torna a medição do tempo de resposta mais difícil'. Para aplicações tradicionais web, o tamanho de um software pode ser medido tanto na máquina do cliente ou em uma máquina próxima do servidor, desde que o nível do fluxo do trafego da rede TCP e HTTP possa ser observado. Como estes protocolos são síncronos e previsíveis, um sniffing pode ler e interpretar os pacotes de dados, e inferir o tempo de resposta através do rastreamento das mensagens HTTP e TCP. Mas uma arquitetura RIA reduz esta capacidade de inferir o tempo de resposta, pois o client engine rompe a comunicação entre usuários e servidores separando a comunicação em dois ciclos assíncronos: um ciclo externo (usuário para client engine) e interno (client engine para servidor). Ambos os ciclos são importantes, porque não funcionam sozinhos, e este tipo de relacionamento que define o comportamento da aplicação. Mas como este relacionamento depende do design da aplicação, que (em geral) não pode ser medida por uma ferramenta de medição, especialmente esta que observa somente um dos ciclos. Assim sendo, uma medição mais completa de um RIA só pode ser obtido usando feramentas que residem no cliente e que possa observar os dois ciclos.
http://pt.wikipedia.org/wiki/Internet_rica#Hist.C3.B3rico_dos_RIAs
Assinar:
Comentários (Atom)
