Posts arquivos para setembro, 2010
30set2010
Depois de mais de 5 meses sem participar de uma corrida de rua, neste domingo, dia 26 de setembro de 2010, corri a Etapa de Primavera do Circuito das Estações Adidas.
Como de costume, o percurso de 10 Km foi todo nas ruas da região do Pacaembu, largando em frente ao estádio, passando pela avenida Pacaembu, Elevado Costa e Silva e terminando com a chegada também em frente ao portão principal do estádio do Pacaembu.
Apesar de muita chuva e bastante tempo sem treinar, fiz um tempo rasoável para quem está voltando a correr.
Tempo total: 00:55:43
Tempo médio por km: 05:34
Tempo em cada km:
- 05:50
- 05:57
- 05:56
- 05:26
- 05:46
- 05:16
- 05:20
- 05:27
- 05:31
- 05:14
Foto de WebRun
Foto de MidiaSport
Foto de WebRun
Foto de Treino Online
Foto de WebRun
Foto de WebRun
Link deste post
30set2010
No artigo anterior eu mostrei como o self muda em diferentes contextos. Neste artigo, você verá o que são as metaclasses e como elas podem ser úteis na metaprogramação.
Entendendo classes Singleton
Todo objeto do Ruby está associado a duas classes: a classe que a instanciou e uma classe anônima, escondida, específica do objeto. Esta classe anônima é chamada de Singleton Class, mas antes de ter um nome oficial também era chamada de anonymous class, metaclass, eigenclass ou ghost class.
O nome Singleton usado pelo Ruby nada tem a ver com o Singleton Pattern, que também está disponível com a biblioteca Singleton.
A sintaxe mais comum para acessar a classe Singleton é
class << object
end
onde object é o objeto cuja classe Singleton você quer. É muito comum vermos algo como o exemplo à seguir para definir métodos em uma classe.
class Person
class << self
def count
@count ||= 0
end
end
end
Aqui, estamos definindo um método na classe Singleton do objeto Person (lembre-se: tudo no Ruby é objeto, inclusive classes). Como consequência, isso irá definir o método Person.count. O efeito é exatamente o mesmo que
class Person
def self.count
@count ||= 0
end
end
No Ruby 1.9.2, foi adicionado o método Object#singleton_class, que é apenas um atalho para a sintaxe class << self; self; end. Em versões mais antigas, você pode injetar este método com
class Object
def singleton_class
class << self; self; end
end unless respond_to?(:singleton_class)
end
Toda vez que injeta métodos em um objeto, eles são adicionados como métodos singleton. O que é realmente importante saber é que estes métodos pertecem unicamente ao objeto em que foram definidos, não afetando nenhum outro objeto da hieraquia.
string = "Hi there!"
another_string = "Hi there!"
def string.to_yo
self.gsub(/\b(Hi|Hello)( there)\b?!?/, "Yo! Wassup?")
end
string.to_yo
#=> "Yo! Wassup?"
another_string.respond_to?(:to_yo)
#=> false
E para provar que o método to_yo é singleton, podemos utilizar o método Object#singleton_methods.
string.singleton_methods
#=> ["to_yo"]
another_string.singleton_methods
#=> []
Você também pode adicionar métodos singleton de outras maneiras. Uma delas é estendendo um objeto com um módulo.
module Extension
def sum
self.inject(0) {|sum, number| sum + number}
end
end
numbers = [1,2,3]
numbers.extend Extension
numbers.singleton_methods
#=> ["sum"]
Outra maneira é usando a própria classe Singleton.
numbers = [1,2,3]
class << numbers
def sum
self.inject(0) {|sum, number| sum + number}
end
end
numbers.singleton_methods
#=> ["sum"]
Ou ainda, executando código no contexto do objeto.
numbers = [1,2,3]
numbers.instance_eval do
def sum
self.inject(0) {|sum, number| sum + number}
end
end
numbers.singleton_methods
#=> ["sum"]
Quando você cria uma classe Singleton em um objeto, não poderá mais utilizar o método Marshal.dump, já que a biblioteca Marshal não suporta objetos com classes Singleton (ela irá lançar a exceção TypeError: singleton can't be dumped). A única maneira de fazer isso e ainda poder utilizar o Marshal é utilizando o método Object#extend.
Agora, sabendo que você pode adicionar métodos em um objeto com uma sintaxe como def object.some_method; end, perceba que é exatamente isso que fazemos quando definimos um método em uma classe; a única diferença é que passamos o próprio self.
class Person
def self.say_hello
"Hello there!"
end
end
Person.singleton_methods
#=> ["say_hello"]
Com base nesse exemplo, é possível afirmar que métodos de classe não existem no Ruby! Pelo menos não no sentido de métodos estáticos! O que acontece é que estes métodos pertencem a um objeto, que por acaso é uma classe.
Finalizando
No próximo artigo veremos mais sobre definição dinâmica e execução de métodos.
Link deste post
30set2010
por
Daniel Cukier em
Academic,
Agile,
agile methods,
cbsoft,
course,
metodos ageis,
mini-curso,
rafael prikladnicki,
salvador,
slides,
Technology
Ontem, durante o I CBSoft (Congresso Brasileiro de Software), Rafael Prikladnicki e eu (representando a Locaweb e a Agilcoop) demos um mini-curso de Introdução a Métodos Ágeis. Ficamos muito felizes em saber que foi um dos cursos mais procurados do evento. No início do curso, fizemos uma dinâmica com os participantes para que escrevessem em post-its suas experiências. Eles teriam que nos dizer sua opinião sobre por que um projeto de software fracassa ou por que um projeto de software tem sucesso. Baseado nessas respostas, fomos moldando o curso, tentando responder o que Métodos Ágeis ajuda a resolver e o que não.
Uma das coisas mais interessantes foi o fato de que eu não conhecia o Rafael antes. Nós organizamos o esqueleto do curso por e-mail, nos encontramos um dia antes para acertarmos os últimos detalhes e improvisamos muito durante a apresentação. Assumimos a filosofia ágil e íamos apresentando os assuntos que mais interessavam ao cliente (no caso o nosso público). Foi uma experiência divertida.
Para quem quiser ver um pouco do conteúdo do mini-curso, aqui vão os slides.
Link deste post
29set2010
Quando você decidiu aprender Ruby, ficou sabendo que tudo é objeto; números, classes, módulos… tudo, sem exceção, é realmente um objeto. Só que isso traz algumas implicações que nem todos conhecem. A ideia é fazer com que você realmente entenda a essência de Ruby em uma série de artigos sobre o Ruby Object Model e Metaprogramming.
Entendendo o self
self será sempre uma referência ao receiver atual e pode ser diferente dependendo do contexto em que você estiver. Por exemplo, quando estamos no namespace global, nosso self será o objeto main. Já em uma classe, nosso self será a própria classe.
puts self
#=> main
class Thing
puts self
end
#=> Thing
Sempre que executar um método, o Ruby irá verificar se esse método existe no receiver padrão—self— a menos que você especifique-o explicitamente. E, pelo fato de o receiver padrão ser self, você nem precisa especificá-lo se não quiser.
class Thing
def do_something
puts "doing something"
end
def do_something_else
do_something
end
end
No método do_something_else poderíamos usar self.do_something, mas isso faria com que nosso código apenas ficasse mais poluído. No entando, definir o receiver é uma coisa muito comum e que, você pode até não se dar conta, mas o faz constantemente quando escreve código Ruby.
numbers = [3,1,2]
numbers.sort
#=> [1,2,3]
ou ainda
text = "some string"
text.upcase
#=> "SOME STRING"
Na prática, o receiver é especificado antes do ponto na chamada de métodos, como em numbers.sort ou text.upcase.
Além de ser o receiver padrão, self também é o responsável por armazenar variáveis de instância de um objeto. Veja o exemplo abaixo.
class Person
def initialize(name)
@name = name
end
def name
@name
end
end
john = Person.new("John Doe")
john.name
#=> "John Doe"
A instância da classe Person possui uma única variável de instância associada ao seu objeto—self—que é retornada pelo método name. Analogamente, podemos definir variáveis de instância em qualquer objeto, como classes.
class Person
def self.count
@count ||= 0
end
def self.count=(increment)
@count = increment
end
def initialize(name)
@name = name
self.class.count += 1
end
def name
@name
end
end
john = Person.new("John Doe")
Person.count
#=> 1
O exemplo acima mostra como variáveis de instância podem ser usadas em contextos diferentes. Primeiro, estamos definindo um contador de instâncias da classe Person, cujo valor será armazenado em @count. Depois, em nossa própria instância, definimos o nome com a variável @name.
Finalizando
No próximo artigo, irei falar sobre metaclasses do Ruby. Até lá!
Link deste post
28set2010
por
Marcelo Leal em
7000-series,
Dtrace,
fishworks,
General,
Java,
Opensolaris,
oracle,
oracle-sun,
storage,
sun,
Tecnologia,
Zfs
Maybe if i could understand the Oracle’s mind, i could learn how to make money. I think that is the key in this whole Oracle/Sun situation: Java, Dtrace 1, 2, 3, 4, and ZFS creators did leave the company. Why someone would buy a technology company, with so many skilled persons (some that did create [...]
Link deste post
26set2010
Salve,
Nos dias 11 e 12 de Setembro de 2010 aconteceu a primeira QCon São Paulo, organizada pela Caelum, que é a mantenedora do InfoQ Brasil. O evento é a versão nacional, e oficial, do famoso QCon, que acontece todos os anos em San Francisco e em Londres, uma conferência de desenvolvimento e arquitetura de software, e contou com mais de 700 de participantes que assistiram 40 palestras divididas entre 6 tracks, ainda tivemos vários Lightining Talks e excelentes happy hours :) Recomendo que vocês leiam o resumo da QConSP no blog da Caelum.
Tivemos vários palestrantes vários internacionais, e tive a oportunidade de falar com dois deles após suas palestras. O primeiro foi Randy Shoup, Distinguished Architect do eBay (o que acredito ser algo como o engenheiro-chefe do lugar). Em sua palestra, "Best Practices for Large-Scale Web Sites -- Lessons from eBay", ele mostrou os números e os desafios absurdos dos sistemas do eBay (veja o segundo slide para ter uma noção da escala), e explicou as lições que aprenderam para lidar com esse monstro, uma boa apresentação muito instrutiva.
Foto do perfil de Randy Shoup site do QConSP
Porém, ao fim da apresentação, fiquei com algumas dúvidas e consegui conversar rapidamente com ele. Um dos itens que ele repetiu dezenas de vezes foi a importância de se desenvolver sistemas resistentes à falhas e com dezenas de alternativas para evitar problemas que, inevitavelmente irão acontecer. Muitas pessoas, leia-se, PHBs, acham que esse tipo de preocupação é um exagero, e classificam investimentos de tempo e dinheiro nisso como desperdício.
Mas no fim, é um problema estatístico: se você tem 10 mil aplication servers e mil instâncias de bancos de dados, mais cedo ou mais tarde você vai ter problemas. Minha primeira pergunta foi: na prática, esses problemas acontecem regularmente? Ele me disse que sim, é normal haver problemas, que vão desde falhas de infra e conexão, até erros em programas e falhas de deploy. Graças as medidas tomadas, a maior parte dos problemas são evitados. A resposta só seria melhor se ele tivesse números para termos uma noção melhor da escala dos problemas :)
Ok, essa resposta era esperada, dado o conteúdo da apresentação. Outra questão é que, segundo as informações da palestra, os sistemas que hoje estão em operação começaram a ser desenvolvidos em 2001 (minha memória é péssima), ou seja, são sistemas relativamente antigos. Naquela época testes automatizados e as preocupações incessantes com qualidade de código e boa arquitetura eram muito menos difundidas do que hoje, então perguntei a ele: dada a idade do sistema, como é a qualidade do código? Ele confirmou minhas suspeitas, disse que os sistemas mais antigos não tem os padrões de qualidade que sonhamos hoje em dia, mas que eles investem tempo para consertá-los e melhorá-los e também substituí-los.
O fato deles terem reescrito os sistemas é um atestado de que mesmo corporações de tecnologia do tamanho deles precisam em algum momento parar e reavaliar a necessidade de um big rewrite. Concordo que big rewrites não devem ser comuns, ou mesmo a primeira opção, mas classificar todos eles como preciosismo técnico ou desnecessários é burrice.
Ainda sobre a idade do sistema, perguntei sobre a grande quantidade de sistemas especiais, escritos para fazer coisas como uma real-time search engine e bancos de dados chave-valor. Hoje em dia temos dezenas de opções open ou closed source para essas necessidades, e apesar de que provavelmente nem todas elas serem boas o suficientes para a escala absurda deles, algumas deveriam diminuir a necessidade de reinventar a roda. Tendo isso mente perguntei: vocês usam soluções open source atuais como os bancos NoSQL (Redis, CouchDB, etc), linguagens além do Java (Ruby, Python, Erlang, etc) ou search engines como o Lucene ou coisas similares? A resposta foi: sim, eles utilizam algumas dessas ferramentas, na época em que desenvolvimento foi feito muitas dessas ferramentas não estavam disponíveis ou eram muito novas, e eles preferiram escrever muitos sistemas eles mesmos. Segundo Shoup, se o desenvolvimento fosse feito hoje, provavelmente utilizariam algumas delas, e estão fazendo testes e experimentos com várias delas apesar da maioria dos sistemas em produção não utilizá-las.
Foi uma conversa bastante instrutiva, ele foi bem legal. Ouvir histórias de sucesso sem analisá-las, questioná-las ou colocá-las em contexto fazem as transformam em passatempo, perguntar faz toda diferença, e nos mostra que nem nessas empresas monstro os sistemas são perfeitos.
No próximo post vou falar sobre a conversa que tive com Charles Nutter, lead do JRuby.
Permalink
| Leave a comment »
Link deste post
23set2010
Pessoal, publiquei o conteúdo do linuxti. Por enquanto terá links provisórios, pois pretendo formatá-lo para ficar de acordo com o wordpress. Para acessar o link dos patches clique aqui. Para acessar o link dos tutoriais clique aqui. A palestra de segurança bem como as demais palestras clicando aqui. Qualquer dúvida ou falta de alguma coisa [...]
Link deste post
23set2010
Que a Novell não andava muito bem das pernas e já estava a venda há pelo menos seis meses, quase todo mundo já sabia. A novidade é que, segundo o Wall Street Journal, a VMware pretende comprar apenas uma parte da Novell: a parte referente ao Linux, ou seja, o SuSE Linux e os softwares de gerenciamento de sistemas operacionais virtualizados.
There, I fixed it
Não é difícil imaginar que o real interesse da VMware está nos programas de gerenciamento de sistemas virtuais, e isso vem deixando os fãs do SuSE (todos os dois que sobraram) preocupados: Caso a compra se concretize, como ficaria uma das mais tradicionais distros Linux? Vale lembrar, o SuSE já foi uma distro de respeito em tempos antigos, e (em minha opinião pessoal) perdeu muito da força que tinha depois da compra pela Novell. Só nos resta rezar para que a VMware faça a distro voltar a brilhar.
As negociações ainda estão rolando, e pode até ser que a compra não se concretize. Caso aconteça, a parte “não-livre” da Novell iria para outra empresa, chamada Attachmate Corp.
Fonte: Tecnoblog
Link deste post
Parabéns!!! 
