O que fazer no ubuntu quando a porta do mogrel ficar ocupada?

Olha so pessoal, isso parece besteira mas tem muita gente que reinicia o computador sempre que aparece uma mensagem assim “RoR TCPServer Error: Address already in use - bind(2)” ao tentar estartar o mogrel.

Bom, seus problemas terminaram. Faca o seguinte, primeiramente voce precisa descobrir quem e o programa que esta ocupando a porta do seu servidor, por isso digite o seguinte comando em um terminal

lsof|grep 3000

dai vai aparecer algo mais ou menos assim

ruby   5303  vinicius  5u  IPv4

beleza, o que interessa e a numeracao apos nome ruby. Vamos derrubar esse processo digitando o seguinte

kill -9 5303

note que estou usando a mesma numeracao do processo por isso ele sera eliminado da lista. Agora voce podera rodar normalmente seu server sem nenhum problema.

att,

Metaclasse em Ruby! parte II

Este artigo é uma continuação de Metaclasse em Ruby!

Bem Continuando……….

Vamos colocar nossa classe de Teste aqui para relembra-la!

Bem se a Metaclasse é um Objeto da classe “Class” e todos os métodos dos Objetos desta classe buscam seus métodos na Metaclasse, entao eu posso adicionar métodos na Metaclasse e usá-los nos Objetos. Vejamos! Antes para criarmos uma classe tinhamos algo como no exemplo acima, mais poderiamos fazer assim:

Bem ficou bem claro! Talvez a mágica esteja sendo desvendada, isso pode ser legal para alguns e muito triste para outros. Bem eu amo a simplicidade de Ruby, alguns amam suas mágicas, outros temem seu dinamismo. Porém o mais importante é que todos ao conhecer Ruby sempre criam algum sentimento por ele.

Voltando ao Assunto!

Agora, é que as coisas ficam mais complicadas e mágicas.

Em Ruby, os objetos de uma classe sempre compartilham os mesmos métodos e esses métodos ficam em sua Metaclasse, isso voces ja viram, porém, é possivel que objetos possuam métodos particulares, isso nós chamamos de singleton_methods.

Os métodos singleton de um Objeto só pertencem a ele, e não aos outros objetos da classe! São métods individuais, é como o ruby propoe que possamos dar individualidade aos objetos, ele deixa que nós dinamicamente adicionemos alguma funcionalidade que só aquele objeto precisa, e não nos obriga a adicionar essa funcionalidade a todos os obejtos de uma classe, isso é ser singleton_methods. Bem vejamos como isso é feito!

Lembrando que os métodos singleton são guardados no próprio objeto e não na metaclasse.

Bem existem muitas outras coisas cobre o assunto mais acho que o mais importante ja vimos! O mais interessante é podermos ver as coisas claramente. Ruby é uma linguagem que superficialmente é muito simples, porém quando nos aprofundamos podemos nos confundir em algumas coisas, o mais importante é poder ver a coisas claramente para sermos melhores!

Valeu!!

Programando em Ruby II - Tipos, Numeros, Strings, Array

Continuando os Artigos sobre Ruby…..

Hoje falaremos sobre Tipos, Numeros, Strings, Array

Antes de começarmos a falar propriamente da linguagem ruby, vamos pensar um pouco sobre algumas caracterí­sticas de outras linguagens de programaçío. No fundo de qualquer linguagem de programaçío o objetivo é disponibilizar uma sintaxe e semantia que sejam capaz de escrever a soluçío de um problema que seja finito e bem delineado. Porém existem várias complicações nesse meio, ou seja, imagine qual seria a atribuição verdadeira de uma linguagem, podemos pensar de várias formas, mais vamos aos extremos:

Uma Linguagem tem que ser:

Uma Linguagem tem que ser completa, com todas as funções possiveis prontas, tem que ser rigida e formal o suficiente para que não leve o programador a errar, tem que ser formal o suficiente que transforme o ato de programar algo previsí­vel e desenhavel como um processo de engenharia, onde antes de começar a ato de programar seja possí­vel prever o resultado com grande garantia.

Bem essa seria a linguagem ideal, porém vamos aos detalhes. Uma linguagem que tenha todas as funções possiveis prontas e ja disponí­veis seria ótimo pois ja teria tudo a mío durante a programação, porem o aprendizado de várias funções prontas seria mais demorado e complexo tornando mais dificil o aprendizado do linguagem. Uma linguagem que seja formal o suficiente para não deixar o programador errar torna o resultado mais previsí­vel, porém, torna o processo de programar algo mecanico e mata a possibilidade de criar metodos novos de resolvel algum problema de uma maneira diferente limitando a capacidade dos programadores. Tornar o processo de programar algo como um processo puramente de engenharia seria o ideal pois tornaria os software mais previsí­veis, porém o ato de programar e um ato de arte não de pura matemática, sendo onde deve ser bem dosado o que será arte e o que será planejamento e previsão.

Ou uma linguagem deve ser simples, só com as funcionalidades indispesáveis, com alto poder de explansão, tem que ser totalmente flexivél e adaptavél para que libere a criatividade do programador, deve ser dinamica o suficiente para que o software seja algo perfeito e nada previsí­vel.

Bem essa também seria a linguagem ideal porém vamos as detalhes: Uma liguagem simples que só contenhas funçoes básicas seria muito simples de aprender, porem a toda nova necessidade seria necessário que seja escrito, onde tornar o ato de programar totalmente artí­stico em nada previsí­vel torna o software mais sucessí­vel a erros e falhas.

Bem isso são alguns pontos que são interessantes serem lembrados antes de começarmos a falar em ruby, pois ruby é uma linguagem que tende mais a segunda opção acima não tão extrema, mais algo perto. A linguagem ruby foi feita por um programador e visa a satisfação do programador, ela também e altamente expansí­vel e adaptavel, e dinamica e simples.

Bem Vamos a Ruby!

TIPOS

Bem, em ruby nao tem tipos! não da maneira que se tem em java, como primitivos, ou seja, numeros, caracteres, booleanos.

Em Ruby tudo é objeto, e sendo assim:

1 - é um Objeto da classe Fixnum

1231231.654645 - é um objeto da classe Float

“a” - é um objeto da classe String

true - é um objeto da classe TrueClass

false - é um objeto da classe FlaseClass

Sabendo que objetos tem métodos, quas sío os métodos de um Fixnum ou do 1

irb(main):007:0> 1.methods

["%", "inspect", "<<", "singleton_method_added", "&", "clone", ">>", "round", "method", "public_methods", "instance_variable_defined?", "divmod", "equal?", "freeze", "integer?", "chr", "*", "+", "to_i", "methods", "respond_to?", "-", "upto", "between?", "prec", "truncate", "/", "dup", "instance_variables", "__id__", "modulo", "succ", "|", "eql?", "object_id", "zero?", "~", "id", "to_f", "singleton_methods", "send", "prec_i", "taint", "step", "to_int", "frozen?", "instance_variable_get", "^", "__send__", "instance_of?", "remainder", "to_a", "+@", "nonzero?", "-@", "type", "**", "floor", "<", "protected_methods", "<=>", "instance_eval", "display", "==", "prec_f", "quo", ">", "===", "downto", "id2name", "size", "instance_variable_set", "kind_of?", "abs", "extend", ">=", "next", "to_s", "<=", "coerce", "hash", "ceil", "class", "tainted?", "=~", "private_methods", "div", "nil?", "untaint", "times", "to_sym", "[]“, “is_a?”]

Notem que o Objeto 1 tem todos os metodos necessários para ser auto-suficiente, ou seja, o objeto 1 é capas de se somar, subtrair, multiplicar, dividir e muitas outras ações usando os métodos. Legal isso sendo assim a linguagem ruby não tem nada a ver com soma, isso e responsabilidade dos objetos.

Bem parece que a linguagem ruby realmente e bem simples, ela nao faz quase nada, nem mesmo operações matemáticas básicas. Então o quela realmetne faz.

Bem uma coisa interessante da linguagem ruby e o “sintax sugar”, e como e chamado alguns recursos de ajuda ao programador, coisas que tornam algo complicado de ser lido ou escrito em açucar sintatico para o programdor.

Olhem esse exemplor - a = 10 + 20

Bem para se chamar um método de um objeto escreve-se assim “Objeto.Metodo”

Então ja que em Ruby o 10 e um Objeto Fixnum e + é um metodo do objeto ficaria ssim:

a.=(10.+(20))

ai entra o sintax sugar em açao e deixa voce escrever assim:

a = 10 + 20

Isso nao mudou nada o 10 continua sendo objeto e + um metodo do objeto 10, porem a sintaxe ficou açucarada e bem mais legí­vel, legal isso.

A função de sintax sugar é muito usada em ruby, sempre que ruby puder tornar as coisas mais legí­ves e simples ele as tornará.

Funções avançadas em numeros

Voltando as números, talvez voce tenha notado que apesar de a Classe Fixnum ter bastantes métodos ela nao contem métodos muito avançados de matemática, isso fica a cargo de um módulo chamado Math

Raiz Quadrada de 25 ficaria assim em ruby

Math.sqrt(25)

Metodos do módulo Math

["inspect", "cos", "log10", "private_class_method", "const_missing", "clone", "method", "public_methods", "atan", "public_instance_methods", "instance_variable_defined?", "erf", "method_defined?", "equal?", "freeze", "included_modules", "const_get", "asinh", "methods", "respond_to?", "sin", "module_eval", "class_variables", "sqrt", "dup", "protected_instance_methods", "cosh", "instance_variables", "public_method_defined?", "erfc", "__id__", "eql?", "object_id", "const_set", "atanh", "id", "singleton_methods", "tan", "send", "frexp", "class_eval", "taint", "frozen?", "instance_variable_get", "sinh", "include?", "private_instance_methods", "__send__", "instance_of?", "private_method_defined?", "to_a", "name", "exp", "autoload", "type", "<", "protected_methods", "instance_eval", "<=>", "acos", "display", "==", ">", "ldexp", "===", "instance_method", "instance_variable_set", "tanh", "kind_of?", "extend", "protected_method_defined?", "const_defined?", ">=", "ancestors", "atan2", "to_s", "<=", "public_class_method", "log", "hash", "class", "tainted?", "instance_methods", "asin", "=~", "private_methods", "class_variable_defined?", "hypot", "nil?", "untaint", "constants", "acosh", "is_a?", "autoload?"]

Conversão de numeros

Felizmente a classes Numericas possuem métodos de conversão, ficando assim:

1.to_i - Converte para inteiro

1.to_s - Converte para String

1.to_f - Converte para Float

1.chr - Converte na tabela Ascii

Tem muito mais conversoes possí­vel que voce pode ver na documentaçío

STRING

Bem agora vamos falr um pouco sobre String

String é uma cadeia de Caracteres, em ruby não, String é um objeto da Classe String.

“Ola eu sou uma String” ou ‘Ola eu sou uma String’

A diferença entre scrings com Aspas dupla e Simples e que Strings com Aspas duplas aceita caractere de formatação, tipo quebra de linha e outros.

Vamos dar uma olhada nos métodos diponí­veis em Strings

“Ola eu sou uma String”.methods

["%", "select", "[]=”, “inspect”, “<<”, “each_byte”, “clone”, “method”, “gsub”, “casecmp”, “public_methods”, “to_str”, “partition”, “tr_s”, “empty?”, “instance_variable_defined?”, “tr!”, “equal?”, “freeze”, “rstrip”, “*”, “match”, “grep”, “chomp!”, “+”, “next!”, “swapcase”, “ljust”, “to_i”, “swapcase!”, “methods”, “respond_to?”, “upto”, “between?”, “reject”, “sum”, “hex”, “dup”, “insert”, “reverse!”, “chop”, “instance_variables”, “delete”, “dump”, “__id__”, “tr_s!”, “concat”, “member?”, “object_id”, “succ”, “find”, “eql?”, “each_with_index”, “strip!”, “id”, “rjust”, “to_f”, “singleton_methods”, “send”, “index”, “collect”, “oct”, “all?”, “slice”, “taint”, “length”, “entries”, “chomp”, “frozen?”, “instance_variable_get”, “upcase”, “sub!”, “squeeze”, “include?”, “__send__”, “instance_of?”, “upcase!”, “crypt”, “delete!”, “detect”, “unpack”, “to_a”, “zip”, “lstrip!”, “type”, “center”, “<”, “protected_methods”, “instance_eval”, “map”, “<=>”, “rindex”, “display”, “any?”, “==”, “>”, “split”, “===”, “strip”, “size”, “sort”, “instance_variable_set”, “gsub!”, “count”, “succ!”, “downcase”, “min”, “kind_of?”, “extend”, “squeeze!”, “downcase!”, “intern”, “>=”, “next”, “find_all”, “to_s”, “<=”, “each_line”, “each”, “rstrip!”, “class”, “slice!”, “hash”, “sub”, “tainted?”, “private_methods”, “replace”, “inject”, “=~”, “tr”, “reverse”, “nil?”, “untaint”, “sort_by”, “lstrip”, “to_sym”, “capitalize”, “max”, “chop!”, “is_a?”, “capitalize!”, “scan”, “[]“]

Com certeza uma das atribuiçoes mais importantes de uma linguagem de programaçao e manipular bem strings ou textos, e ruby com certeza da conta do recado, trabalhar com String e ruby e buito facil e produtivo.

Manipulaçío de String

a = “bom” => “bom”

a * 3 => “bombombom”

a + ” dia” => “Bom Dia”

a << ” Hacker” => “Bom dia Hacker”, a diference de + e << e que o + gera um novo objeto e o << adiciona no memo objeto.

a.upcase => “BOM DIA HACKER”

a.downcase => “bom dia hacker”

a.capitalize => “Bom dia hacker”

Percorrendo e Alterando uma String

a = “Estudando Ruby” => “Estudando Ruby”
a[0] = “e” => “estudando Ruby”

a[10] => 82, codigo da tabela ascii

a.delete(”R”) => “estudando uby”

a.insert(9,”R”) => “estudando Ruby”

a.reverse => “ybuR odnadutse”

Bem temos em ruby uma maneira simples de concatenar textos

Exite a notaçío “#{}”

Imagine escrever o texto assim

a = “nome do usuario”

“Bom dia”+ a => “Bom dia nome do usuario”

“Bom dia #{a}” => “Bom dia nome do usuario”

Tem muito mais coisas legais sobre String, mais veremos mais adiante em outro artigo.

ARRAY

Agora vamos ver um pouco sobre Array

Array é um capitulo aparte em Ruby, aqui e que ruby mostra seus diferenciais e torna tudo mais interessante, algo que com certeza voce vai se beneficiar.

a = [] => Cria um array vazio

a = [1,2,3,4,5] => cria e ja popula uma array

Vamos dar uma olha nos methos da classe array

a.methods

["select", "[]=”, “inspect”, “<<”, “compact”, “&”, “clone”, “last”, “method”, “public_methods”, “partition”, “delete_if”, “empty?”, “instance_variable_defined?”, “equal?”, “freeze”, “each_index”, “*”, “grep”, “sort!”, “assoc”, “+”, “to_ary”, “methods”, “respond_to?”, “-”, “reject”, “insert”, “reverse!”, “dup”, “push”, “delete”, “instance_variables”, “concat”, “member?”, “__id__”, “|”, “find”, “eql?”, “pack”, “join”, “reverse_each”, “object_id”, “each_with_index”, “collect!”, “rassoc”, “id”, “at”, “compact!”, “singleton_methods”, “index”, “collect”, “send”, “all?”, “reject!”, “flatten”, “slice”, “taint”, “length”, “entries”, “pop”, “instance_variable_get”, “frozen?”, “transpose”, “include?”, “__send__”, “instance_of?”, “detect”, “to_a”, “indexes”, “zip”, “map!”, “uniq”, “type”, “fetch”, “protected_methods”, “instance_eval”, “map”, “<=>”, “values_at”, “rindex”, “display”, “any?”, “==”, “===”, “shift”, “size”, “sort”, “instance_variable_set”, “clear”, “min”, “kind_of?”, “extend”, “find_all”, “to_s”, “indices”, “each”, “class”, “flatten!”, “slice!”, “hash”, “first”, “tainted?”, “replace”, “inject”, “=~”, “private_methods”, “delete_at”, “reverse”, “nitems”, “nil?”, “untaint”, “sort_by”, “unshift”, “max”, “fill”, “is_a?”, “[]“, “uniq!”]

Algumas funções básicas sobre arrays

a = Array.new ou a=[]

a << “Joaquim” => ["Joaquim"]

a.insert(1,”Silva”) => ["Joaquim","Silva"]

a.first => “Joaquim”

a.last => “Silva”

a.empty? => false

Bem na verdade a classe array tem muitos métodos, e com certeza tem um que supre sua necessidades, vamos ver um pouco sobre interação com array.

a = [4,5,6,7,8,9,10]

a.each {|i| puts i} => 4,5,6,7,8,9,10

Bem existem várias variaçoes de interadores em array, mais acredito que ainda falaremos muito sobre esse assunto, que certamente sera aborado em outros temas, sendo assuim, ficamos por aqui!

Depois continuamos, valeu!

Programando em Ruby I - Orientação a Objetos

Tudo no Paradigma de Programação a Orientada a Objetos resume-se em:

• Classes
• Atributos
• Metodos

Na construção de uma Classe, observamos:

• Herança
• Abstração
• Encapsulamento
• Polimorfismo

E por fim tudo Acaba em Objeto.

Ou seja, Objetos são Instancias de Classes que forma construídas observado Heranças, Encapsulamento, Polimorfismo e abstração.

Bem! Voce pode estar se perguntando, isso eu ja sabia! Porem vale apena lembrar antes de entrarmos no assunto, pois em alguns momentos esses conseitos serão importantes para esclarecer dúvidas sobre as várias implementações do Paradigma.

Para entendermos melhor vamos analizar a função seguir:

a = 10 + 20

Vamos Ver o que é cada um dos membros dessa função.

“a” - é uma variável

“=” - é um operador

“10″ - é um número

“+” - é um operador

“20″ - é um número

Na primeira olhada na funçao podemos identificar facilmente as partes que a compoem. E bem claro que a função e composta de variáveis, operadores e números.

Bem voltemos então as bases da Orientação a Objetos(no começo do artigo), procure por variáveis, operadores e números. Isso mesmo não existe variáveis, operadores e números, na Orientação a Objetos sã existem, Objetos compostos de atributos e metodos.

Vamos rever a função, agora Orientado a Objetos

a = 10 + 20

“a” - é um objeto

“=” - é um método do objeto “a”

“10″ - é um objeto

“+” - é um método do objeto “10″

“20″ - é um objeto

Poderia ser escrito assim:

a.=(10.+(20))

Ou seja, tudo em uma linguagem Orientada a Objetos são objetos.

É assim que Ruby implementa a Orientação a Objetos, tudo que é manipulado em um Programa segue a seguinte ordem, Palavra Reservada, Objeto ou Método, não existe nada além disso.

Isso simplifica muito o aprendizado da linguagem, pois aprendendo as palavras reservadas, o resto é tudo objetos, e quando voce precisa fazer alguma coisa com um objeto basta chamar seus métodos e pronto, simples assim.

Vejamos um exemplo de um objeto em ruby

“eu sou um objeto”

Voce deve estar olhando e vendo que isso é uma String, isso mesmo, e também e um objeto, e tem um monte de métodos

Vamos fazer o texto ficar todo em maiúsculo

“eu sou um objeto”.upcase

“EU SOU UM OBJETO”

Notem, nós chamamos o métodos “upcase” diretamente na String. O Objeto é auto-suficiente, contém todos os métodos pertinentes a sí, isso é muito importante, pois libera a linguagem dessas obrigações.

Vejamos os numeros

10

Isso também é um objeto e tem seus métodos por exemplo, o + é um métodos do objeto 10.

10.+(20)

ou 10 + 20

Um pouco mais de filosofia sobre Orientação a Objetos!

Bem voce deve estar pensando, “bem se o + e um método do objeto 10, eu poderia sobrescreve-lo, e fazer o + realizar qualquer coisa!”, Sim isso mesmo voce pode sobrescrever qualquer método e modifica-lo de acordo com suas necessidade.

Ficaria assim:

class MeuNumero < Fixnum
def +(numero)
42
end
end

numero = MeuNumero.new(1)
# Repare como um operador de soma é um método em ruby, ao contrário de outras linguagens
puts numero+2 # 1+2 = 42 ??? Sim, sobrescrevemos o método de soma para retornar 42 sempre.

Bem mais isso não e perigoso, imagine um método que chama + e que realiza uma divisao, poderia confundir o programador. Isso é verdade, porém da muita flexibilidade, e deixa tudo Orientado a Objetos.

Muitas linguagens como o Java deixam os operadores dentro da prãpria linguagem e nao como um método do objeto numero, e os númentos também são primitivos e não objetos, com isso se diminui a possibilidade de uso errado das coisas, porém deixa a linguagem muito suja e complexa, pois nao sabe quando deve-se chamar um método ou quando deve-se chamar uma função da linguagem, e também deixa o conseito de Orientação a Objetos errado, por isso que java é PseudoOrientada a Objetos, em alguns pontos ela e totalmente procedural, ou seja:

a = 10 + 20

Isso é totalmente procedural pois:

“10″ - é um número(primitivo)

“+” - é uma função da linguagem java

“20″ - é um número(primitivo)

Essa função em java não é nada orientado a objeto.

Bem essa era a parte filosãfoca do nosso artigo, mais era importante saber e relembrar as bases do Conseito de Orientação a Objetos, pois serão muito úteis no aprendizado da linguagem Ruby.

No proximo artigo veremos mais a fundo na Linguagem Ruby.

Interpretando o Ruby!

Acho que é um assunto interessante e por isso vou falar um pouco sobre os Interpretadores Ruby!

Bem antes de falar dos interpretadores de Ruby, vamos falar um pouco sobre interpretadores. Na verdade era interessante deixar bem claro a diferença entre anbiente de execução e instruções executadas.

O que é Ruby, na verdade Ruby é o nome que se dá ao conjuto de Interpretador e Linguagem que o interpretador reconhece, ou seja, o Linguagem Ruby é reconhecida pelo Interpretador Ruby.

Bem nem sempre foi assim, a muitos e muito tempo (hehe to brincando), os programas eram compilados, ou seja escrevia-se o código fonte e depois o código era convertido para linguagem de máquina (binarios) e executado diretamente pelo processador, nunca mais necessitando ser lido o código fonte. É assim que a linguagem C faz usando o Compilador GCC. Ou seja Tem a Linguagem C e o Compilador que entende a Linguagem C.

Voltemos a Ruby, no mundo Ruby é um pouco diferente. A diferença logo de cara é que o Codigo Ruby não é Compilado para Binários e sim Interpretado durante a Execução. Fica mais ou menos assim, quando executamos um programa Ruby, primeiramente chamamos um programa que reconhece as instruçoes Ruby (o interpretador ruby), este programa lê as instruções e executa durante a solicitação. O legal é que o Interpretador sempre precisa de ler o código fonte para executar a instrução. O legal disso é:

Primeiro! Seu código pode ser rodado em qualquer ambiente. Basta que haja um interpretador Ruby no ambiente, tails como Linux, Windows, Unix, BSD, etc.

Segundo! Ao Interpretar o codigo pode ser otimizado excessivamente para ser mais rápido e mais eficiente.

Bem mais não acaba ai, linguagens orientadas a objetos tem um grande desafio em uso de memória. Notem que quando se instancia um Objeto ele e repleto de Atributos e isso consome muita memória, porem, também torna as variaveis bem mais regenciaveis, pois elas sempre dependem de um objeto. Bem para resolver este problemas existe um outro programa que auxilia o Sistema Operacional a gerenciar a memória, ele tem por objetivo remover objetos não usados da memória e liberar espaço para outros objetos. Este programa tem o nome de Coletor de Lixo.

Ja notamos que a coisa ta ficando cada vez mais interessante. Então vamos falar dos interpretadores de Ruby.

MRI - Matz Ruby Interpreter

Como o Próprio nome ja diz é o interpretador que o Matz fez, ele é o primeiro Interpretador Ruby, é lindo em sua forma, porém não é o mais otimizado, talvez porque o Matz não buscasse o que o java buscava, em ser o melhor, mais seguro e mais rápido de todos. O que significa isso, um programa ruby executado pelo interpretador MRI, é bem mais lento que um programa Java ou um programa Smalltalk, quem, porém isso não é necessariamente um grande problema, pois com a facilidade de programação que a linguagem proporciona, é possivel otimizar código tornando a aplicação em si mais rápida idependente do interpretador.

YARV - MRI1.9

Este é o grande esforço da comunidade Ruby para melhorar o MRI, ele tem por objetivo resolver alguns problemas conseituais do MRI e aumentar sua performance, porém isso nao está sendo tão simples assim, por mais interessantes que venham se mostrando os testes a velocidade em si não tem melhorado muito, isto é normal, em alguns casos a otimização de um interpretador leva vários anos para encontrar algo performático e seguro.

Rubinius

Este com certeza é o mais elegante e promissor de todos. A idéia do Rubinius é fazer um interpretador de Ruby escrito em Ruby. Como? O jeito é fazer os elementos essenciais em C, e depois o restante todo em ruby puro. É como construir uma ferrovia, os primeiros trilhos usaśe um caminhão pra llevar, quando cabe a locomotiva, ja usa-se a prórpia ferrovia apra levar os proximos trilhos. Qual é a grande vantagem de se escrever um interpretador de Ruby em Ruby, a grande sacada é que escrever em Ruby é muito fácil e rápido, em quanto um interpretador de Ruby em C precisa de 10 mil linha um Escrito em Ruby precisa de 1 mil, e enquanto em um Interpretador escrito em C voce precisa mudar 1000 linhas pra melhorar algo em Ruby voce precisa mudar apesa 10, isso tornaria a evolução do Rubinius algo vertiginoso e inesperado. Porém o inicio ainda é muito lento e singular, talvez ainda demore um pouco para chegar ao estado perfeito da arte.

Bem além disso a idéia do Rubinius é ser um Maquina Virtual, a diferença entre ser uma VM ou somente um Interpretador é que é necessário implementar no interpretador todas as rotinas que o sistema Operacional disponibiliza diretamente ao sistema, ou seja, ao inves de vc pedir ao SO para ler um arquivo, pedesse a MV que por sua vez pede a Sistema Operacional, isso torna a Sua Aplicação bem mais portavel, pois dependendo do Sistema Operacional ele disponibiliza diferentes recusos, e é possivel vc estar usando algum recusrso que nao esteja disponível em todos SO, um exemplo classico é a gerador de imagens MAGIC, que é escrito em C e é possivel usar no MRI, porém nem todos os SO tem o MAGIC instalado e disponível. Voltando uma VM é muito mais capaz de resolver tudo que seu programa pede sem depender o Sistema Operacional, isso torna seu Programa mais portavel.

Além disso tem algo muito legal que aconteceu durante o desenvolvimento do Rubinius. A idéia de compatibilidade, o Rubinius priorizou testes automatizados em seu desenvolvimento, com isso usando os mesmos testes que o Rubinius fez é possivel avaliar a compatibilidade de vários interpretadores, ous eja, é dizer que um MRI 1.8 é compativel com MRI1.9 e compativel com RUbinius, etc. Isso da mais tranquilidade pois é possivel saber se um codigo escrito em Ruby sera bem interpretado por qualquer Interpretador Ruby.

JRUBY

Talvez essa seja a melhor opção hoje para interpretar código Ruby. O que é JRuby? JRuby é um esforço da comunidade e da propria SUM em possibilitar que o interpretador java reconheça código Ruby. A pergunta que nao quer calar! Porque a SUM deseja que o código ruby seja interpretador pela JVM? É porque a Linguagem Ruby é muito melhor que a linguagem Java, eheh, bem não é so por isso, a linguagem Ruby implementa muito bem outros paradigmas que a linguagem Java não é capaz, tais como meta programação, desenvolviemnto ágil, etc..

E o que Ruby ganha com isso? Toda a maturidade, velocidade, segurança da JVM. Sem falar que para a JVM chegasse a ser o que é hoje, formam investidos milhares de milhares dolares e tempo, e quando se executa seu programa Ruby sobre essa estrutura voce automaticamente se beneficia disso.

Outra vantagem é ser Enterprise, bem esse conseito inútil é muito respeitado belas grandes empresas, onde ter uma aplicação em uma linguagem conhecida é muito mais aceitavel que ter uma aplicação melhor em uma linguagem pouco conhecida, quando voce tem um programa Ruby sendo executado sobre a JVM, o programa normalmente é mais aceito. Sem falar que a maioria das empresas que exigem coisas Enterprise não sabem nada sobre tecnologia e seguem o fluxo de todas as outras, e ter a SUM dizendo que acredita em Ruby ja as deixa mais calmas e conformadas, eu sei que isso não é nenhum parametro tecnico mais é muito usado no mundo doente dos Enterprise.

O bom efeito colateral em usar JRuby é a possibilidade de usar toda as Bibliotecas, APIs, escritas em Java em seus programas Ruby, isso é legal até certo ponto, porém em alguns casos reduz a curva de resistencia em se usar uma nova linguagem, onde os programadores Java podem continuar usando sua bibliotecas Java em vez de ter que reescreve-las em Ruby, bem só o futuro dirá se isso é realmente uma boa idéias, eu escrevi um outro artigo falando sobre isso deem uma lida. Da Vinci Machine Project!

IronRuby

A idéia do IronRuby é fazer que o interpretador .NET da Microsoft reconheça código Ruby, este projeto também é mantido pela comunidade e própria Microsoft. Bem por mais estranho que pareça este projeto deveria ser bem melhor que o projeto JRuby, levando em conta que a VM .NET da Microsoft é bem mais preparada para executar linguagem dinamicas como Ruby. Porém é um projeto apagado e sem muitas grandes novidades, talvez pela antipatica que a comunidade retem pela Microsoft. Existem outras coisas, o projeto .NET é proprietário, fechado bem ao estilo Micro$oft, porém existe um outro projeto que é o Mono que nada mais é que a implementação da VM .NET em software livre, e o IronRuby é capaz de rodar também sobre Mono, mais mesmo assim a projeto IronRUby não decolou ainda, mais eu acredito bastante que seja viavél talvez não seja a melhor opção hoje mais no futuro pode se tornar algo interessante

MagLev

Uma estrela cadente! Talves essa seja a melhor imagem para descrever o Maglev. A idéia do Maglev e fazer o Interpretador GemsStone de Smalltalk reconhecer código Ruby. Essa idéia veio de Avi Bryant, o cara é muito bom. Tudo começou em um tempo em que a comunidade Ruby vinha sofrendo com a frase “Rails não escala”, e Avi Bryant disse, “Eu vim do futuro e sei como isso acaba”. Após isso ele me aparece na RubyConf com nada mais nada menos que a Maglev, puxou o Datashow e rodou alguns códigos Ruby sobre a GemStone, o que mais assuntou é que a Maglev chegou a ser 60 vezes mais rápida que o MRI, e algumas grandezas mais rápida que o JRuby. Isso criou um clima estranho, pois centenas de programadores estavam se dedicando em fazer o Jruby que é 2 ou 3 vezes mais rápido que MRI, ou Rubinus que é algumas vezes mais lento que o MRI.

Bem o mais legal é que Smalltalk e uma linguagem dinamica como Ruby, entao um interpretador de Smalltalk e quase a mesma coisa que um interpretador de Ruby, isso torna as coisas muito mais simples de serem feitas, diferente de Jruby que tem que fazer uma JVM interpretar código dinamico, que é muito dificil, a GemStone foi facilmente adaptada para rodar código Ruby com a mesma eficiencia que roda código SmallTalk.

O ruim de tudo isso é que a GemStone é um VM proprietária e tem custo para usa-la, e nao tem o código fonte aberto, tal como o MRI, JVM, Rubinus. Isso me preocupa, mais voltando ao pensamento Interprise pode ser uma solução viável apra alguma empresas.

Bem mais nem tudo são flores, o Avi Bryant, foi mostro o Maglev na RubyConf e depois sumiu, eu venho buscando mais coisas sobre Maglev e nao veja nada na comunidade, talvez seja esse o plano deles ser bombático sempre, mais isso deixa a gente sem rumo, ou pode ser que o projeto ta meio parado mesmo, bem vamos vem.

Este são os projetos mais conhecidos de Interpretadores e VM Ruby. Como o Ruby é OpenSource quanquer pessoa pode pegar o MRI e fazer algumas modificações, sendo assim pode existir vários outros projetos ai que eu não conheço, mais acredito que esses sejam os mais relevantes. Depois a gente fala mais sobre VM, para deixar mais claro as diferenças e caracteristicas de cada VM Ruby tais como Rubinius, Jruby, IronRuby, Maglev.

Valeu!!!

O Projeto Da Vinci VM!!

A Proxima Grande Revolução da Informática!

De Tempos em Tempos acontecem algumas coisas que mudam o mundo de maneira tão grande que é impossível tentar prever as coisas depois da mudança, e também após a mudança fica dificil lembrar como viviamos sem ela. Bem são essas mudanças que mudam o rumo de nossas vidas e torna o mundo diferente.

Talvez voce esteja se perguntando, do que o IsaacGuerra ta falando! Que mudança é essa?

Sim eu vejo um projeto que pode mudar o modo em que programamos e tratamos a programação!

Só o simples pensamento de que a maioria das coisas que fazemos pode ser bem mais fácil, que  tudo que criamos pode ser mais acessível, ja cria em mim um anseio e uma esperança que me faz ter curiosidade e um pouco de medo do futuro.

Bem vamos falar de programação!! de Código que é o que interessa!

Hoje com certeza vivemos uma mudança interessante mais muito timida da forma que programamos, com o aparecimento de linguagens mais gostosas como Ruby, Smalltalk, Phyton, etc.. Porém, como o Fabio King sempre diz, nao existe a linguagem completa que resolve tudo que agrega em si a solução total para todos os problemas e isso.

É isso que eu busco em uma liguagem, algo que eu possa nao escrer tudo em uma boa linguagem e sim que eu possa usar a linguagem certa na hora certa, onde tudo que eu fizer seja cambiavel entre elas, sem nenhum transtorno. Neste sentido eu busqui muito, hoje eu acedito que possamos fazer muita coisa em muitas linguagens legais, tais como C, C#, PHP, JAVA, RUBY, PHYTON, PERL, LISP, SMALLTALK, JAVASCRIPT, etc.. Em si toda linguagem faz alguma coisa de bom, agrega em amlgum ponto algo memorável e que ajuda o programador fazer algo.

Porem por mais que eu tenha procurado uma linguagem que faça tudo da melhor maneira ainda nao encontrei. Bem mais foi quando eu vi algumas coisas acontecerem meio timidas e elas foram se encaixando e mostrando que este sonho, o sonho de poder juntar tudo varias linguagens em uam só, nde seis Conponentes, APIs, Bibliotecas sejam cambiaves. Bem eu esperava a linguagem completa mais nao é isso que vai ser.

A Algum tempo a SUM a mantenedora do JAVA abriu o fonte de sua maquina virtual, isso nao foi bombastico nem muita novidade, porém, de alguma forma esse movimento esta mudando o mundo. Na verdade o JAVA e um conjunto de tecnologia sendo RunTime, SDK e linguagem, onde a pior parte de tudo isso com certeza e a linguagem, porém a Maquina Virtual ja tem mais de dez anos e muitos bilhoes de dolares de grandes empresas investidos em otimiza-la, com isso criu-se um ambiente seguro e confiável. Bem mais onde entra e revolução.

Notem que a JVM ja e Multiplataforma agora o grande esforço é que ela seja multilinguagem, onde todas linguagens de ante mao ganham o poder de serem multiplatafor, ganham também o poder e as otimizações do Ambiente Java, e por fim o melhor onde as APIs e bibliotecas ja escritas podem ser consumidas por qualquer Linguagem. Bem isso é legal e dizer que eu posso a partir do Phyton acessar um recurso escrito em Java, bem isso e legal, mais o mais legal e que algo escrito em Ruby seja acessivel em Java, e assim por diante, ou seja todos os recursos escritos habitarem um ambente comum e ser acessível por qualquer linguagem, com isso todo esforço será reusado.

Isso e diser que suas bibliotecas escritas hoje possam ser usadas nas proximas linguagens que vc quiser usar, e entendender que seu programa pode ser escrito por várias linguagens onde cada linguagem faça o que tem de melhor e por fim o seu sistema seja melhor.

Bem esse projeto ja existe e se chama “Da Vinci Machine Project”.

Uma linguagem que foi extremamente importante para o inicio do projeto Da Vinci foi Ruby com o JRuby, onde é possivel rodar aplicações Ruby sobre a VM Java, e mais legal e poder usar todas as bibliotecas escrita em Java em Ruby, bem é interessante também para equipes multidisciplinares, com a possibilidade de escrita em várias linguagens não obriga a equipe escrever tudo na mesma linguagem. Bem eu vou continuar esse assumto com mais dados tecnicos, falando mais sobre HotSpot, JIT, GC, etc.

Valeu!!!

Cobertura do Rails Summit

Ae possoal!!

A Comunidade Amapaense de Rails esta no participando do Rails Summit 2008, ao todo, viream ao evento nada mais nada menos que 4 participanetes da comunidade Amapaense de Rails, são eles, Isaac Guerra, Guilherme Carvalho, Rafael Pomar e Vinicius.

Estaremos blogando nossas observaçoes aqui no blog da comunidade, comentes divulguem.

Valeu!!

Linguagem de Programação! Conhecendo para melhor Escolher!

Meu nome e Isaac Guerra, sou programador a vários anos e sempre tenho me deparado com as mesmas dúvidas sobre linguagens de programação!! E o que sempre me incomoda é tentar saber, qual é a melhor? Talvez você também se sinta pressionado a sempre estar mudando de linguagem para acompanhar o mercado ou para integrar uma equipe diferente, mais no fim o sempre se pergunta qual é a melhor linguagem pra você.

Talvez seja melhor definirmos quais sao pontos importantes para uma linguagem ser boa, ou, o que realmente é importante para uma boa linguagem de programação.

Para entendermos bem sobre requisitos de linguagem seria interessante voltar-mos e vermos um pouco da história das linguagem, para levantarmos onde e quando o que usamos hoje se tornou padrão.

No começo quando criaram os primeiros computadores a valvulas, eles processavam alguns programas simples, e esses programas eram escritos diretamente em suas memórias e só continham 0s e 1s, isso mesmo não se escreviam programas, e sim binarios que seria processados diretamente nos processadores. Isso com certeza era muito ruim, pois se alterassem qualquer bit, o resultado dava errado, sem falar no tempo que se levava para se escrever um programa. Aqui ja notamos que teria que haver um meio termo entre a linguagem binária, que o computador entende, e a linguagem humana que nos entendemos, e esse meio termo é que nos chamamos de linguagem de programação, e desde então estamos tentando encontrar a lingagem ideal para ser transformarmos pensamentos em bits.

Neste momento o que tinhamos para apoiar o programador eram alguns microcódigo internos no processador (RISC, CISC), que realizavam rotinas mais complexas diminuindo assim a extensão do programa, bem mais chamar microcódigo é muito complicado, é quase como escrever binários, entao criaram os primeiros programas de apoio que serviam para montar as chamadas de microcódigos, os chamados montadores(Assembly), acredite os montadores eram revolucionários e ajudaram em muito as coisas.

Ainda que ja tivéssemos os montadores o processo de escrever um programa era muito complexo, pois tudo era feito pelo programador, tipo, se vc quisesse esvrever algo na memória RAM tinha que ir na memória achar um espaço vago, e depois escrever, ou seja, tinha que gerenciar todo o Hardware, isso era muito complexo e um programa ficava quase que 99% de codigo para gerencia Hardware e 1% com o foco fim ou seja o programa.

Neste momento vieram a linguagem de Primeira Geração que tinham como objetivo essas facilidades de genciamento de memória, outros periféricos. Escrever um programa com a obrigação de cuidar do hardware ficou mais facil, mais ai veio um complicante, a multiprogramação, ou seja varios programas rodando no mesmo hardware, bem neste momento nao era mais suficiente pois alem de gerenciar o hardware tinha que conciliar o acesso ao hardware com outros programas.

Foi quando criou-se uma camada de software que tem por objetivo gerenciar e assumir a responsabilidade de controlar o acesso ao Hardware, o Sistema Operacional(Linux, Unix, BSD, etc). Neste momento a programação ficou bem mais simples, pois essa camada apoia o Programador, onde, quando ele precisa de um espaço na memoria RAM basta pedir ao S.O. e ele realiza toda a complexa tarefaz de falar com o Hardware, e assim é com todos outros perifericos(Video, Impressora, Rede, etc) ai ficou fácil bem mais fácil, onde escrever um programa e quase que totalmente focar no objetivo fim, ou seja as funcionalidades do programa.

Até neste momento o ato de programar era pura e simplismente criar procedimentos que seriam executados pelo processador, sendo assim todos os programas nada mais eram que um monte de procedimentos, e as linguagens de programação davam condições de se escrever esses procedimentos, uma das facilidades era dar nomes aos procedimentos para depois poder chamalo pelo nome, isso é legal, outra coisa que as linguagem fazim bem era, poder nomear endereços de memória e depois chama-las pelo nome.

Foi quando um dia alguem pensou que poderia organizar melhor os procedimentos, bem a ideia nao mudou e sim mudou a organização das coisas, ainda tinhamos procedimentos nomeados, e areas de memoria nomeadas, entao criaram o objeto, um objeto nao e um procedimento a ser processado, nem tao pouco uma area de memoria a ser acessada, e sim um estrutura organizacional que juntaria em si procedimentos e memória. Por fim um programa conteria muitos objetos e os objetos conteriam os procedimentos e as variaveis, e um se comunicaria com outros por meio de menssagens. Bem parecido com o mundo real, Nasceu ai a Programação Orientação a Objetos. Muito mais complicado, mais no fundo a mesma coisa. Bem mais neste mesmo período os programadores estavam preocupados com outro problema e nao deram muita bola para a POO.

O mundo assistia a primeira onda de informatização, ja tinhamos computadores capazes de processar grandes volumes de dados e aplicações multiprocessadas, com multiusuarios, etc. E o problema era guardar grande volumes de dados de maneiras persistente, foi quando nasceu os primeios programas destinados a gerencia de dados persistentes, os SGBDs. Com isso programar ficou ainda mais facil pois ja nao nao tinhamos que se preocupar com codigos de maquina, ja nao era necessário se preocupar com acesso a hardware, agora nao era mais necessário se preocupar com guarda e busca de dados persistentes. E assim o mundo ficou por mais de uma decada, sem muitas novidades.

Nesse meio tempo nasceu várias alternativas, criaram-se impérios em Software, porém no mundo da programaçao nada de muito novo acontecia, era tudo procedimetnos nomeados, e areas de memória nomeadas, guadando dados em SGBDs onde quase tudo era feito para rodar sobre um S.O(ruindows). O problema de deixar o S.O. cuidar do acesso ao hardware e que se o S.O for ruim a aplicaçao que funciona sobre ele também será ruim, outro problema é que se a aplicaçao faz chamada as funóes do S.O ele fica altamente dependente dele, e isso foi foi o que motivou a próxima mudança no mundo do Software.

Um empresa gigante na área de Hardware(SUN) queria que as aplicaçoes rodassem em qualquer hardware ou S.O, foi quando nasceu uma nova plataforma com esse Objetivo(JAVA), essa plataforma era composta por alguns modulos, um a camada de abstraçao entre a Plaicaçao e o Sistema Operacional(VM), um interpretador RunTime, Um gerenciador de Memória(GC), Um compilador e uma Linguagem para ele(JAVA) e por fim uma biblioteca cheia de funçoes prontas(JDK). Bem para melhor funcionamento dessa estrutura ele buscaram um paradigma de programaçao que apoiasse essa filosofia, e acharam o Orientaçao a Objetos, que ja existia porém nao era muito usada.

Agora sim Programar ficou mais simples ainda, ja nao precisavamos nos preocupar com codigo de maquina, nem acesso ao hardware, nem persistencia de dados, agora uma aplicaçao poderia ser rodada em qualquer Hardware ou S.O, tinhamos também um Avanço na gerencia de memória com o “Garbage Colector” diminuindo a preocupaçao com o uso da memória RAM, tinhamos uma infinidade de codigo pronto disponívem no “Development Kit”, e o que restou para o desenvolvedor era apenas digitar poucos códigos, ai o mundo ser tornou muito chato para o progamador.

Neste mundo certinho, cinza, rapidamente germinou a cultura de transformar o ato de programar em um processo de simples engenharia, quadrado, pobre e sem brilho, foi quando mudou-se o foco do programa para o projeto, e criaram-se várias formas de escrever projetos de software(UML, etc) e por fim a documentaçao ficou rapidamente varias grandesas mariores que o proprio software, e o programador se tornou apenas um mero digitador sem grande importancia, as linguagem de programaçao(JAVA. etc) apoiaram os engenheiro e massacravam os programadores com seus, tipos e interfaces, tornado um programa um amontoado de regras que inibiam a criatividade do programador.

Bem chegamos nos dias atuais, e podemos pensar em alguns pontos que sao importantes par uma linguagem de programação.

Memória: Gerencia de memória não é tão importante estar sob responsabilidade do programador, pois hoje temos o Sistema Operaciona gerenciando o Hadware, e o Garbage Colector que gerencia o uso da propria memória. Sendo assim ao criar um variavel nao e tao importante dizer que tipo ela será, a linguagem pode fazer isso dinamicamente, sem problemas.

Hadware: É interessante que a linguagem tenha uuma infriestrutura que possibilite a execuçao em qualquer hardware, usando ou nao uma estrutura de Maquina Virtual.

Procedimentos: É notorio que o Paradigma de Orientaçao a Objetos e melhor que o Procedural, onde os procedimentos pertencem a um objeto. Porém, é interessante essa estrutura não seja tao rigida ao ponto de dificultar a programaçao, é bom que se possa criar metodos coletivos, individuais, staticos e também que se possa em tempo de execuçao criar métodos para suprir alguma necessidade desconhecida, é legal também a possibilidade de criar metods nao nomeados e dinamicos para suprir algo como programaçao dinamica.

Persistencia de Dados: Bem o Paradigma de Orientaçao a Objetos é muito bom na gerencia de procedimentos, porém não apoia em nada em persistencia de dados, e a integraçao com os antigos SGBDs e pessimo. Seria muito interessante que a Linguagem de programaçao possuíssem em sua infraestrutura a capacidade de Persistencia de dados, transparente e eficiente, que mantesse o acesso a dados totalmente na forma de objetos com uma boa infraestrutura de compartilhamento desses objetos(Algo como uma Gemstone Samlltalk).

Bibliotecas: Uma boa linguagem deve ter uma boa Biblioteca Objetos fundamentais para a funçoes mais massantes prontas porem é importante que esses Objetos sejam facilmente alterados e melhorados.

Criatividade: Por fim uma boa linguagem de programação apoia o programador em sua tarefa, pois a linguagem nada mais que que uma ferramenta para ser usada, a linguagem tem que ser simples, poderosa, deve apoia a criatividade do programador, deve ajuda-lo a encontrar possiveis falhas.

Bem na verdade exstem hoje algumas linguagem que suprem bem esses requisitos, cito smalltalk, ruby, Phyton, etc.

No fim temos que ter uma visao do que seria interessante  para o futuro, mais isso veremos em um outro artigo.

• Pesquisar por:

• Arquivos

  • julho 2009
  • novembro 2008
  • outubro 2008
  • setembro 2008
  • agosto 2008

• Categorias

  • CSS
  • JRuby
  • Off-Topic
  • Rails
  • Ruby
  • Sem categoria
  • Tutorial

• Lista de Links

  • Akita On Rails

• Tags

  email historico da programaçao Linguagem de programaçao Rails RoR Ruby ruby rails amapá macapá

Copyright © 2008 AmapaOnRails • Todos os direitos reservados!