SEJAM BEM VINDOS!!!

Este blog é destinado a todos que interessam em aprender e compartilhar conhecimento sobre desenvolvimento de aplicativos, linguagens de programação, banco de dados, entre outros.

O que é OCX?

Abreviatura de OLE custom control. Módulo de software que se baseia nas tecnologias OLE e COM que, quando chamado por uma aplicação, produz um controle que acrescenta algum recurso interessante à aplicação. A tecnologia OCX é independente de plataforma, opera em sistemas operacionais de 16 e 32 bits e pode ser usada com várias aplicações. É a sucessora da tecnologia VBX (Visual Basic custom control), que aceitava apenas aplicações do Visual Basic, e constitui a base dos controles ActiveX. Os controles OCX podem ser criados em diversas linguagens, embora o Visual C++ seja a linguagem mais utilizada. Desenvolvida pela Microsoft, a tecnologia OCX é tratada na especificação OCX 96 (1996 OLE Controls specification). Pesquise também ActiveX controls (controles ActiveX); COM (definição 2); control (controle – definição 2); OLE; VBX; Visual Basic.

Fonte: http://o-que-significa.blogspot.com.br/2011/06/ocx.html#.UxivZPldXik

sexta-feira, 18 de setembro de 2009

Ruby on Rails - RubyOnRails

Ruby on Rails é um meta-framework gratuito que promete aumentar velocidade e facilidade no desenvolvimento de sites orientados a banco de dados, uma vez que é possível criar aplicações com base em estruturas pré-definidas. Freqüentemente referenciado como Rails ou RoR, o Ruby on Rails é um projeto de código aberto escrito na linguagem de programação Ruby. As aplicações criadas utilizando o framework Rails são desenvolvidas com base no padrão de projeto MVC (Model-View-Controller).
ORIGEM: Ruby on Rails foi uma extração de David Heinemeier Hansson de um projeto seu, o gerenciador de projetos Basecamp. Foi lançado a público pela primeira vez em julho de 2004.

Características

O Rails é um "meta-framework", uma vez que é uma junção de cinco frameworks:
Active Record: O Active Record é uma camada de mapeamento objeto-relacional (object-relational mapping layer), responsável pela interoperabilidade entre a aplicação e o banco de dados e pela abstração dos dados.

Action Pack: Compreende o Action View (geração de visualização de usuário, como HTML, XML, JavaScript, entre outros) e o Action Controller (controle de fluxo de negócio).
Action Mailer: O Action Mailer é um framework responsável pelo serviço de entrega e até mesmo de recebimento de e-mails. É relativamente pequeno e simples, porém poderoso e capaz de realizar diversas operações apenas com chamadas de entrega de correspondência.
Active Support: Active Support é uma coleção de várias classes úteis e extensões de bibliotecas padrões, que foram considerados úteis para aplicações em Ruby on Rails.
Action WebServices: Provê uma maneira de publicar APIs interoperaveis com o Rails, sem a necessidade de perder tempo dentro de especificações de protocolo. Implementa WSDL e SOAP.
O Action Web Service não estará mais presente na versão 2.0 no Rails, visto que o mesmo está voltando-se para a utilização do modelo REST. Mesmo assim, aos ainda interessados em utilizá-lo, será possível fazê-lo através da instalação de um plugin.

Ambiente de Desenvolvimento

Ruby on Rails segue dois conceitos que visam aumentar a produtividade do desenvolvedor: DRY e Convention over Configuration. Estes métodos estão implementados por todo o Rails, mas podem ser mais notados nos "pacotes" do Active Record (ORM, Object Relational Mapper) e Action Pack (MVC) DRY: DRY (Don't Repeat Yourself, Não se repita) é o conceito por trás da técnica de definir nomes, propriedades e códigos em somente um lugar e reaproveitar essas informações em outros. Por exemplo, ao invés de ter uma tabela Pessoas e uma classe Pessoa, com uma propriedade, um método "acessador" (getter) e um "mudador" (setter) para cada campo na tabela, tem-se apenas no banco de dados. As propriedades e métodos necessários são "injetados" na classe através de funcionalidades da linguagem Ruby. Com isso, economiza-se tempo, já que não é necessário alterar a tabela, o "bean", o "form bean", o "local home", o "home", o "session", ... Alterando apenas no banco de dados, tudo o que se baseia nessas informações é atualizado automaticamente. Convention over configuration: Na maioria dos casos, usamos convenções no dia-a-dia da programação, em geral para facilitar o entendimento e manutenção por parte de outros desenvolvedores. Sabendo disso, e sabendo que o tempo gasto para configurar XML em alguns frameworks de outras linguagens é extremamente alto, decidiu-se adotar esse conceito. Ele diz basicamente que deve-se assumir valores padrão onde existe uma convenção. Se o desenvolvedor quiser, pode-se sobrescrever essa convenção com o valor necessário. Por exemplo, uma classe User pode ter seus dados armazenados na tabela Customer. Seguindo a convenção, seria na tabela Users. Com isso, o tempo de desenvolvimento cai ainda mais. Tempo de Execução A maioria dos sites não necessita de esquemas sofisticados de escalabilidade, bastando alguns aceleradores. Em sites menores ou normais, uma configuração padrão do servidor web consegue suportar uma boa quantidade de carga, principalmente se forem usados o FastCGI, LightTPD ou Mongrel, que são necessários para obter uma velocidade aceitável de abertura da página. Comparando uma aplicação com FastCGI e sem FastCGI (rodando Ruby direto como CGI), a diferença é perceptível em qualquer aplicação. O processamento do código (sem contar o tempo de download) em CGI ocorre em no mínimo 10 segundos mesmo em servidores Quad Core, enquanto que em FastCGI o desempenho é notável: em no máximo 1 segundo a página é processada, tal qual linguagens web como PHP. Existem casos de sites feitos em Rails que suportaram 5 milhões de visitas em um mês, ou seja, aproximadamente 115 por minuto, uma performance considerada suficiente para 90% das aplicações atuais. Nestes sites, uma questão freqüente é sobre a escalabilidade de aplicações escritas em Rails. Ao contrário de outras tecnologias, você não precisa fazer um código específico para que o sistema esteja preparado para "escalar". Quando necessário pode-se adotar uma das táticas disponíveis para escalabilidade em Rails. Vale notar que o único problema da escalabilidade é a manutenção de sessões entre servidores. Portanto, a saída mais óbvia é guardar estas sessões em volumes NFS, acessíveis por todos os servidores de aplicação. Outra tática é usar o armazenamento de sessões diretamente no banco de dados. Uma terceira, seria salvar a sessão em um cookie na máquina do usuário. Como pode-se ver, uma aplicação Rails já nasce com todo o suporte necessário para crescer sem traumas
Site Oficial: http://rubyonrails.org/
Apostila: http://www.4shared.com/file/133721269/8f8266dc/Apostila_de_RubyOnRails_-_fonteOCX.html

Nenhum comentário:

Postar um comentário