13 Razões para Programadores Java aprenderem Flex e BlazeDS
Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.
Rastreando mudança e inovação na comunidade de desenvolvimento de software corporativo.
Postado por Sebastien Auvray , traduzido por Flávia Castro de Oliveira em 17 Nov 2008 02:13 PM
As formas de cache de uma aplicação web são numerosas e muitas vezes complexas. O caching básico do Rails pode tornar tedioso o gerenciamento da infra-estrutura conforme sua aplicação cresce.
Rails 2.2 introduziu conditional GET através do uso de cabeçalhos http: last_modified e etag. Seguindo a seção de caching padrão da internet da RFC2616, Ryan Tomayko introduziu Rack::Cache.
Rack::Cache é uma peça do Rack middleware que implementa a maioria das funcionalidades da caching da RFC 2616 com um conjunto básico de opções de storage (disk, heap, e memcached) e um sistema de configuração para ajuste do cache. Isto deverá funcionar igualmente bem com qualquer framework web Ruby habilitado para Rack e é testado em Ruby 1.8.6 e 1.8.7.
Parte do seu design foi inspirado pelo framework de cache do Django's (escrito em Python).
Rack::Cache age como um gateway proxy (Varnish , Squid) sem a dor de cabeça de configuração. O Rack::Cache supporta cache baseado em expiração, modelo de validação, e campos de cabelçalho do tipo Vary.
Como Ryan King afirma, você pode migrar suavemente para o gateway proxy de verdade se sua aplicação realmente precisar disso:
Uma vez que sua aplicação fica maior e mais complexa, faz sentido usar um cache de proxy http reverso como squid ou varnish, mas a transição do estilo de caching do rails para HTTP caching é não-trivial. Você tem que alterar seu deployment e sua aplicação de maneiras significativas. Não é divertido.
Com Rack::Cache você só tem que alterar seu deployment. Você pode fazer isso até mesmo de forma incremental. Você poderia começar usando Rack::Cache para cache no heap, depois mudar para o sistema de arquivos e finalmente para memcache. Quando isso atingir o limite de escalabilidade você pode adicionar o squid ou varnhish na fremte de sua aplicação e então remover Rack::Cache. Deployments que envolvem só uma alteração importante em cada passo são muito mais fáceis de acertar do que tentar várias mudanças maiores em uma única operação.
Será interessante dar uma olhada nos próximos benchmarks do Ryan.
Padrões de Design de Interação - Parte I
Padrões de Design de Interação - Parte II
Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.
Rob Bazinet e Matthew Bass, ambos da InfoQ, tiveram a oportunidade de conversar com Jeremy McAnally, sobre o livro "Ruby in Practice" no qual foi co autor junto à Assaf Arkin.
Danijel Arsenovski tenta esclarecer alguns mitos sobre refatoração e como isso se aplica para desenvolvedores .NET
Em maio, Adobe lançou a primeira versão beta do Flex 4, codinome Gumbo. A lista a seguir proporciona uma visão geral de alto nível dos itens que foram modificados na última versão do framework RIA.
Um dos anúncios mais interessantes recentemente feito à comunidade Ruby foi o lançamento da IDE JetBrains RubyMine para aplicações Ruby e Ruby on Rails.
Data Services são serviços de software que encapsulam operações das entidades chave relevantes para a empresa.
O uso do XML traz consigo desvantagens, como problemas em potencial com desempenho, mas também oferecem um nível de abstração que permite diminuir o acoplamento entre as partes envolvidas na troca.
Como programadores, a nossa primeira prioridade é criar código que funciona. Infelizmente, código que simplesmente “funciona” não é suficiente.
Nenhum comentário
Acompanhar Discussão Responder