Hoje venho falar de mais um evento ocorrido em Natal-RN (em 02/03/2010), no auditório da Biblioteca Zila Mamede (UFRN), o qual teve como palestrante o prof. Dr. Roberto Ierusalimschy, da PUC-RJ, criador da linguagem de programação Lua, utilizada em diversos projetos pelo mundo. A palestra abordou temas como o que considerar na criação de uma linguagem de programação e aspectos técnicos de Lua, como seu sistema de números e as chamadas co-rotinas. Em seguida, darei uma breve descrição do evento.

O que escolher ao projetar uma linguagem

Primeiramente, o professor Roberto definiu que não há uma linguagem ótima para tudo, pois na criação de qualquer uma é preciso escolher entre temas como Segurança vs. Flexibilidade, ao escolher tipagem estática ou dinâmica; Legibilidade vs. Concisão, no caso de haver diversos modos para realizar a mesma tarefa; e Desempenho vs. Abstração, principalmente em linguagens interpretadas. No entanto, o foco é Simplicidade vs. Quase todo o resto, ou seja, se você deseja criar uma linguagem bem simples, é preciso abdicar de muitas outras qualidades, já que muitos problemas podem ser resolvidos ao adicionar complexidade.

Lua

Em seguida, o docente da PUC-RJ explicou que um dos objetivos principais de Lua, se não o principal, é a simplicidade (“Tão simples quanto possível, mas não mais do que isso.”). Contudo, eles almejaram sempre algo com muitos usos e usuários, focando também em portabilidade e o termo “embedability”, criado pelo próprio Ierusalimschy para designar que pode ser incorporada a diversos outros projetos, como C/C++, Java, Fortran, C#, Perl, Ruby, Python, Ada, etc.

Lua possui um tamanho extremamente pequeno se comparada com outras linguagens com o mesmo poder que ela, pois tem seu binário com menos do que 200KB e possui o núcleo da linguagem separado de diversas bibliotecas, sendo bem fácil removê-las e tornar um projeto ainda menor, sendo possível rodar em quase tudo o que já se ouviu falar. O professor Roberto deu algumas características fundamentais da linguagem, como: sintaxe convencional; sintaticamente parecida com Scheme; escopo estático; tipagem dinâmica; procedimentos são objetos e argumentos são passados por valor (as alterações no valor dos parâmetros não são feitos na própria variável passada, mas em uma cópia dela); modelo de aritmética do IEEE 754.

Design

Nesse ponto da palestra a discussão começou a ser mais técnica, abordando aspectos do projeto da linguagem Lua, como seu sistema numérico, as tabelas, as co-rotinas e o casamento de padrões (também conhecido por expressões regulares, mas de forma equivocada, segundo o professor Roberto Ierusalimschy).

Os números em Lua são tratados em um único tipo numérico, o que possibilita regras claras e bem documentadas, evitanto regras de conversão entre tipos e possuindo uma implementação simples em C, contudo há uma enorme lentidão quando o hardware não suporta ponto flutuante e é difícil lidar com operações bit-a-bit, pois não se sabe quantos bits exatamente estão sendo usados para representar o número.

As tabelas são arrays associativos, ou seja, permitem qualquer valor como chave, e é a única estrutura de dados em Lua, podendo implementar tanto módulos (math.sin(3)) quanto objetos, no entanto não há controle de acesso com as palavras reservadas private, protected, etc., sendo necessário convencionar entre os próprios programadores essa permissão. Outro problema é a determinação de tamanho de sequências utilizando tabelas, pois índices nil são tratados como inexistentes, gerando inconsistência em situações como (1, 2, nil, 4) [Quantos elementos há nessa sequência?].

A co-rotina é uma funcionalidade de Lua pouco presente em outras linguagens (parecida com as continuações de Scheme, mas com implementação e semântica mais simples) e podem ser chamadas em qualquer ponto do programa e controladas em qualquer nível de função (no caso de recursividade). Para entender melhor esse conceito e os outros, é recomendado que se veja a documentação da linguagem.

Também foi abordado o casamento de padrões, funcionalidade não muito completa na linguagem, possuindo uma biblioteca padrão pequena e sendo desenvolvida a biblioteca LPEG, ainda não-padrão, com muitas alternativas, todavia ainda muito grande para ser incorporada a Lua (~ 2200 linhas de código).

Conclusão

Por fim, pôde-se perceber que o projeto de qualquer linguagem envolve conflitos de objetivos e, dessa forma, é preciso ter bem definido na mente do criador quais são suas prioridades, porque, como o professor Roberto também frizou, é mais fácil fazer algo novo em uma linguagem do que tirar.

Posts interessantes:

• Não é apenas o emprego dos sonhos
• Segmentation Fault – a memória do PC pede ajuda!
• Google Docs para estudantes
• Minhas 10 coisas favoritas sobre Ruby

E você, o que achou da palestra sobre a criação da linguagem Lua? Alguma dúvida? Comente e vamos discutir o assunto!

Helton de Melo Duarte

“Porque vale mais um dia nos teus átrios do que, em outra parte, mil. Preferiria estar à porta da Casa do meu Deus, a habitar nas tendas da impiedade.” Salmos 84.10

“Porque o SENHOR Deus é um sol e escudo; o SENHOR dará graça e glória; não negará bem algum aos que andam na retidão.” Salmos 84.11

Hoje venho dar dicas bem importantes, principalmente para aqueles que sempre sonharam em trabalhar numa grande empresa, porém pensam que nunca passará de um sonho. Tenho só uma coisa a dizer: pode virar realidade, mas você vai ter que ralar! Primeiramente, tive a ideia do post por causa do Dia Livre 10.01, que aconteceu no IFRN, com a palestra de Daniel Rocha sobre a vida de um Googler (aquele que trabalha no Google), além do mais, também tenho um exemplo próximo de sucesso em grandes empresas. Aproveitando o espaço, dia 19/02/2010, no IFRN, haverá o Dia Livre 10.02, com o Leonardo Martins mostrando como é sua vida no portal Globo.com

Primeiramente, como o próprio Daniel disse em sua palestra: estude! Não deixe nada passar desapercebido, afinal, todo conhecimento lhe trará algo importante. Aquela matemática que você tanto criticava? É pré-requisito para o cargo de Gameplay Engineer da Electronic Arts. Aqueles infindáveis protocolos de redes que lhe tiravam do sério? É pré-requisito para Software Engineer no Yahoo!. E o curso de Ciência da Computação que seu amigo faz, mas você sempre disse a ele que é melhor ser auto-didata? É obrigatório em praticamente todos os empregos no Google, Microsoft, Facebook, etc. Não estou dizendo que todas essas características são indispensáveis a qualquer programador, mas, pelo menos, para aqueles que querem tentar uma vaga nessas multinacionais americanas.

Google Jobs

Vaga: Software Engineer

Tenha um conhecimento avançado(íssimo) em algoritmos e estruturas de dados, principalmente nas linguagens C++ e Java (um ótimo treinamento para isso são as competições de programação pelo mundo afora e seus sites relacionados, como o USACO Training Program, TopCoder e UVa Online Judge). Conhecimentos em Python ou JavaScript/Ajax também são importantes, assim como a essencial fluência em inglês.

Microsoft Careers

Vaga: Software Engineer: Development

Habilidade na resolução de problemas e, pelo menos, 3 anos de experiência em C++ e/ou linguagens de script (novamente a dica das competições, pessoal!), com mestrado ou doutorado nas áreas de computação ou matemática. Fluência em inglês (como em todos!). Além de paixão por qualidade de software e desenvolvimento.

Yahoo Careers

Vaga: Senior Web Developer

Como é uma vaga para Web Developer, esse foi o único que vi e não pedia conhecimentos avançados em C++, no entanto você precisa saber bem de HTML/CSS/JavaScript/Ajax, além de conhecer o Unix/BSD e o servidor Apache. Dessa forma, é exigido o conhecimento em PHP e SQL, com conhecimentos de orientação a objetos e bancos de dados relacionais. E inglês fluente para não perder o costume.

Facebook Carrers

Vaga: Software Engineer, Data

Grande experiência em trabalho com quantidades gigantescas de dados, alto conhecimento em C++, Java ou *nix (também conhecido com Unix-like, é como nos referimos a SOs que são parecidos com o Unix, by @adorilson), além de habilidade com sistemas de arquivos, arquiteturas de servidores e sistemas distribuídos. Algo interessante no Facebook foi a versatilidade em requerer um funcionário com conhecimentos em PHP, Python ou Ruby. Inglês fluente!

Electronic Arts Jobs

Vaga: Gameplay Engineer

Possuir um Bacharelado em Ciência da Computação ou Matemática (ou algo parecido) e, como adicional, um mestrado ou doutorado, além de demonstrar experiência com desenvolvimento de jogos, com habilidades em C++ e LUA/Python (vão participar de competições, que resolve “todo” o seu problema). Deve ter pelo menos um jogo lançado oficialmente (difícil para iniciantes) e, como extra, experiência em arquitetura ou implementação de Inteligência Artificial em um personagem.

Lionhead Studion Jobs

Vaga: Standard Gameplay Programmer

Deve ter pelo menos dois anos de experiência em projetos de bom nível com C++, com experiência em algum jogo lançado e com desenvolvimento para XBox 360 (não obrigatório). Conhecimentos avançados em C++, habilidade com Lua e conhecimentos de Otimização de Código são bem cotados para a vaga, portanto treinar para qualquer competição de programação seria uma passo a mais na sua jornada!

Esses são somente alguns exemplos de grandes empresas esperando por grandes profissionais. Como já foi falado para mim, gostaria que vocês ficassem com isso em mente: participar dessas competições é sim uma marca significativa em seu currículo e “garantem” sua habilidade em programação, por isso muitas dessas empresas estão sempre “pescando” os competidores assim que os eventos terminam (Google Code Jam é um exemplo bem dado para isso).

Posts interessantes:

• Segmentation Fault – a memória do PC pede ajuda!
• Treinando para a OAH 2009
• Google Code Jam 2009: uma nova oportunidade
• XNA – A fábrica de jogos da Microsoft

E aí, qual das empresas você prefere trabalhar? Diga sua opinião e comente sobre o que achou das ofertas!

Helton de Melo Duarte

“A ti, ó Deus, glorificamos, a ti damos louvor, pois o teu nome está perto, as tuas maravilhas o declaram.” Salmos 75.1

“Tu és o Deus que fazes maravilhas; tu fizeste notória a tua força entre os povos.” Salmos 77.14

Venho treinando nos últimos dias com o foco na OBI 2010 e, quem sabe, na IOI 2010 (se Deus quiser!), no site de treinamento da equipe dos Estados Unidos, mais conhecido como USACO Training Program e percebi que é uma fonte impressionante de treinamento para competições de programação, especialmente as citadas acima. Durante algumas resoluções de problemas me deparei com um erro chamado “Segmentation Fault” quando eu tentava executar o programa e resolvi pesquisar a respeito para esclarecer melhor na minha mente e poder passar a todos, já que não é um erro tão raro de ocorrer em programas.

Quando se tem um irmão expert em C++ e amante de competições de programação assim como eu tenho, é bem mais fácil tirar as dúvidas, portanto segue a explicação (adaptada) que Herbert Duarte deu para esse problema.

Segfault, como também é conhecido, ocorre quando um programa está tentando acessar uma área de memória protegida, ou seja, que não faz parte de seu endereçamento (espaço da memória revervado pelo Sistema Operacional para cada um dos programas que estão sendo executados), ou quando tenta acessar um local de forma inapropriada, como por exemplo, tentando escrever em um espaço que é de somente-leitura. As causas mais comuns para esse tipo de erro são as seguintes:

• Ponteiros não inicializados ou com valores inválidos, pois quando o programa tenta acessá-lo provavelmente irá cair em algum lugar aleatório da memória que o programa não tem acesso;
• Acessar uma posição inválida de matrizes ou vetores, já que o programa irá calcular a posição como se ela existisse e provavelmente irá cair em um local sem acesso (ocorrendo frequentemente quando o programa calcula, em alguma situação, uma posição para ser acessada, porque, se houver qualquer erro nesse cálculo, a posição acessada será inválida);
• Tentar alterar um caracter de uma string que foi inicializada como “Somente leitura”.

Bem, dessa forma, espero que cuidem melhor de seus programas para não caírem nesse mesmo erro, lembrando apenas que Segmentation Fault não é um erro de compilação de código, mas um erro de execução de programa.

Fonte para auxílio: Segmentation Fault – Wikipedia

Posts interessantes:

• Treinando para a OAH 2009
• Google Code Jam 2009: uma nova oportunidade
• Categoria: Programando Melhor

Mais algum erro está perturbando vocês? Comente e nos conte que procuraremos sempre ajudá-lo!

Helton de Melo Duarte

“Eu, porém, estou aflito e necessitado; apressa-te por mim, ó Deus; tu és o meu auxílio e o meu libertador; SENHOR, não te detenhas.” Salmos 70.5

“Por ti tenho sido sustentado desde o ventre; tu és aquele que me tiraste do ventre de minha mãe; o meu louvor será para ti constantemente.” Salmos 71.6

Estamos distantes nos últimos tempos, devido à falta de tempo por estar concluindo o curso de Técnico de Nível Médio Integrado em Informática pelo IFRN Campus Natal/Central, contudo estou voltando à ativa hoje, modificando a organização das categorias do blog e redefinindo a sua missão, ou seja, o próposito ao qual ele se propõe.

Missão do blog

Trazer aos leitores um treinamento para competições de programação, dando um embasamento tanto na área de algoritmos e estruturas de dados, quanto na matemática.

Atualizar os leitores em relação às novidades da área de informática, especialmente de programação, além de informar sobre os principais eventos, trazendo sempre a avaliação e resumo dos presenciados pelo autor.

Realizar recomendações de leituras, tanto com resenhas de livros e revistas, quanto com indicações de outros blogs, e também disponibilizar reflexões para os leitores.

OBS: Essa informação também pode ser acessada na área de Sobre do Blog.

Espero que apreciem as nossas mudanças para tornar o blog mais atrativo e, em breve, traremos novidades para todos.

O que você achou das mudanças? Comente sobre o assunto e peça novidades.

Helton de Melo Duarte

“A justiça do sincero endireitará o seu caminho, mas o ímpio, pela sua impiedade, cairá. A justiça dos virtuosos os livrará, mas, na sua perversidade, serão apanhados os iníquos.” Provérbios 11.5-6

Gostaria de desculpar-me pelo tempo inativo aqui no blog, justificando que estou em meu ano de vestibular e, por isso, tempo não é algo comum em minha vida recente. =( Hoje venho fazer novamente a tradução de um documento para apresentar a vocês o Google Docs, ferramenta para criação, edição e compartilhamento de documentos, planilhas e apresentações. (Link do original: Google Docs for Students)

Seu prazo está perto. Seu colega está longe.

Se você está trabalhando em um projeto de disciplina ou algo mais divertido, economize tempo e colabore em documentos, planilhas e apresentações.

Editem o mesmo documento, com amigos, colegas de turma ou professores.

Acesse seus documentos em qualquer lugar e a qualquer hora, desse modo eles não irão embora juntamente com seu disco rígido.

Crie facilmente documentos para sua escola ou jogos e organize-os em um local sem bagunça.

Dicas e truques usando o Google Docs

1. Não começe do zero – Confira nossa galeria de templates para assistentes, assistentes de professores e líderes estudantis.
2. Diga não para anexos de e-mail – Use o histórico de revisões para olhar qualquer versão anterior de seus documentos.
3. Anotações das ideias para os projetos em grupo – Com a gravação dos pensamentos de todos em um só local, nenhuma boa ideia será deixada para trás.
4. Precisa de pesquisas para as aulas? – Envie um formulário para suas listas de e-mail e consiga uma planilha organizada das respostas instataneamente.
5. Olhe os guias para iniciantes – Crie seus primeiros documentos facilmente com guias para documentos, planilhas e apresentações.
6. Confira os manuais avançados - Explore as entradas e saídas de documentos, planilhas e apresentações.
7. Use formulários para seu grupo de estudantes – Colete respostas, organize seu orçamento ou participe de reuniões colaborativas.
8. Faça guias colaborativas de estudo – Convide qualquer um para o mesmo documento do Google e coloque em suas anotações de aula.
9. Planejamento de viagens – Deixe qualquer um contribuir para seu itinerário em um documento, complete seu orçamento em uma planilha, etc.
10. Converse enquanto trabalha – Chats são feitos dentro de planilhas do Google, tornando fácil discutir com os outros as mudanças que você está fazendo.
11. Faça listas pessoais sobre o que falta fazer – Com poucos cliques em sua caixa de entrada, fique certo de que nenhuma atividade importante foi deixada sem fazer.
12. Experimente as funções da planilha – Reúna estatísticas como a classificação de uma equipe ou o PIB de um país com o GoogleLookup.

Bem, as dicas para utilização do Google Docs foram dadas, então comece a experimentar!

Posts interessantes:

• Getting Real e mais sobre a 37signals
• Google Chrome OS – Como será?
• Computação em nuvem: Evolução?
• Computadores de mão: Smartphones

E aí, o que achou do Google Docs? Comente sobre sua experiência com essa ferramenta!

Helton de Melo Duarte

“Cantai a Deus, cantai louvores ao seu nome; louvai aquele que vai sobre os céus, pois o seu nome é JEOVÁ; exultai diante dele.” Salmos 68.4

“O nosso Deus é o Deus da salvação; e a JEOVÁ, o SENHOR, pertencem as saídas para escapar da morte.” Salmos 68.20

Bem, pessoal, como alguns já devem saber, próxima sexta-feira acontece em todo o Brasil a primeira fase da III Olimpíada de Algoritmo Hostnet e estarei participando mais um ano, em busca do bicampeonato =D. A fim de treinarmos para essa competição, resolvi fazer esse post, dando umas dicas e um exercício, como exemplo, para vocês tentarem fazer. OBS: Quem quiser saber se resolveu corretamente, faça um comentário dizendo isso que entrarei em contato por e-mail, ok?

Dicas

Tirando como base as dicas do site da Maratona de Programação e o artigo do Shariar Manzoor na revista Crossroads, pensei em umas dicas básicas:

• Não há nada pior do que gastar muito tempo fazendo e passando a limpo um algoritmo para, depois, descobrir que ele está errado. Na OAH, esse erro é fatal, já que o tempo é sempre um grande adversário. Por isso, apesar de a pressa ser necessária, procure sempre certificar-se da corretude do algoritmo ANTES de escrevê-lo!
• A escolha de seu time é essencial. Um bom time de programação precisa que cada componente tenha um conhecimento de algoritmos básicos (ordenação, encontrar n-ésimo número primo, calcular MDC/MMC, etc.), além da capacidade de criar novos para situações diversas.
• Ao treinar, certifique-se de que cada membro do time sabe fazer o básico, como escrever procedimentos e fazer “debug” de um algoritmo. Um time bem-sucedido terá membros com algumas especialidades, como aquele que resolve problemas com busca, ou aquele bom em matemática, ou aquele que encontra erros facilmente. Todos os membros devem saber as qualidades e defeitos dos outros para saber quem ficará responsável por cada questão.
• Todos devem estar aptos para realizar Pair-Programming, ou seja, resolver uma das questões juntamente com outro membro, principalmente as mais difíceis. Não aconselho que fiquem os 3 membros pensando sobre o mesmo problema, a não ser em casos extremos.
• Faça treinos de simulação, pois é a melhor forma de fazer a prova em um bom tempo. Treinar nas mesmas condições da competição é uma ótima dica, ou seja, fazer uma prova passada com o tempo cronometrado e depois pedir para um professor da instituição corrigí-la.
• Faça muitas questões daqui para sexta-feira!

Exercício

Coleta de Lixo Ecológica (traduzido e adaptado de “Ecological Bin Packing”, do UVa Online Judge)

O Problema

Reciclar vidro requer que ele seja separado por cor em uma das três categorias: vidro marrom, vidro verde e vidro transparente. Nesse problema você terá 3 latas de lixo, cada uma contendo um número específico de garrafas marrom, verde e transparente. No intuito de serem recicladas, as garrafas terão de ser movidas a fim de cada lata de lixo conter apenas garrafas de uma cor.

O problema é minimizar o número de garrafas que serão movidas. Você deve assumir que o único problema é minimizar o número de movimentos entre os cestos de lixo. Para a proposta desse problema, cada lixo tem a capacidade de armazenar infinitas garrafas e a única restrição é movê-las para cada cesto conter garrafas de uma única cor.

A Entrada

A entrada que seu programa irá ler consiste em uma linha contendo nove inteiros. Os primeiros três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 1, os segundos três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 2, os últimos três inteiros representam o número de garrafas marrons, verdes e transparentes (respectivamente) na lata 3. Por exemplo, a linha 10 15 20 30 12 8 15 8 31, indica que há 20 garrafas transparentes na lata 1, 12 garrafas verdes na lata 2 e 15 marrons na lata 3.

A Saída

A saída indicará as garrafas de que cores que estarão em cada lata para minimizar o número de movimentos. Você também deve escrever o número mínimo de movimentos com as garrafas para que isso ocorra.

O programa deverá escrever uma string com três letras maiúsculas ‘M’, ‘V’ e ‘T’ (representando as cores marrom, verde e transparente) representando a cor associada a cada lata de lixo.

O primeiro caracter representa a cor relacionada com a primeira lata, o segundo caracter representa a cor relacionada com a segunda lata e o terceiro caracter representa a cor relacionada com a terceira lata. Além disso, o inteiro representando o menor número de movimentos a serem feitos deverá vir seguido da string, separados com um espaço.

Se mais de uma ordem de latas marrom, verde e transparente produzir o número mínimo de movimentos, então a string que vier primeiro alfabeticamente deverá ser escrita.

Exemplo de Entrada 1

1 2 3 4 5 6 7 8 9

Exemplo de Saída 1

MTV 30

Exemplo de Entrada 2

5 10 5 20 10 5 10 20 10

Exemplo de Saída 2

TMV 50

Com isso, nossas dicas para a OAH 2009 estão dadas, então eu desejo a todos os competidores, desde já, boa sorte! Mostrem a todos que vocês são capazes, mas não esqueçam, Deus é o único responsável por qualquer conquista sua.

Posts interessantes:

• Categoria: Cursos – Programando Melhor
• Google Code Jam 2009: uma nova oportunidade
• Top Coder Marathon Matches
• OAH 2008

Vamos lá, treine bem para mais essa competição! Comente e diga qual colégio estará representando, além do mais, tire qualquer dúvida!

Helton de Melo Duarte

“O justo se alegrará no SENHOR e confiará nEle; e todos os retos de coração se regozijarão.” Salmos 64.10

“Bendito seja Deus, que não rejeitou a minha oração, nem desviou de mim a sua misericórdia.” Salmos 66.20

Hoje será um pouco diferente, pois o texto não foi escrito por mim e sim pelo @wycats (Yehuda Katz) do blog “Katz Got Your Tongue?”. Ele é um membro da equipe do Ruby on Rails e desenvolvedor líder do projeto Merb. Ele é um membro do time principal do jQuery e um grande contribuidor para o DataMapper. Ele contribui para muitos projetos de código aberto, como Rubinius e Johnson, e trabalha em alguns que ele mesmo criou, como Thor. Yehuda gentilmente concedeu que eu traduzisse seu post e o colocasse no blog e, além dele, tive também a ajuda do grande @elomar, que fez a revisão completa da tradução com seus ajustes essenciais. Então, aí vai o post! (Link do original: My 10 Favorite Things About the Ruby Language)

OBS: Infelizmente, o código disposto aqui não está sendo tabulado corretamente, tornando difícil sua visualização. Peço desculpas a todos por isso e, assim que possível, corrigirei o problema.

“Eu trabalho com Ruby todos os dias e ao longo do tempo comecei a realmente gostar de usá-lo. Aqui está uma lista de algumas coisas específicas que eu realmente gosto em Ruby. Algumas delas são óbvias e algumas também existem em outras linguagens. A proposta é compartilhar coisas que eu gosto em Ruby, não para comparar e competir com alguma linguagem específica.

1. Tipagem Dinâmica

Existem coisas muito boas sobre linguagens de tipagem estática, como verificação em tempo de compilação e suporte a IDE. No entanto, na minha experiência, tipagem dinâmica realmente ajuda a conseguir projetos concisos e limpos durante as mudanças, especialmente nos estágios inicial e mediano deles.

Eu estou muito feliz que eu não preciso criar uma interface formal para meus novos objetos implementarem, simplesmente para me possibilitar trocar facilmente as classes por outras, no futuro.

2. Duck Typing

(nota: como é um termo técnico, não há tradução que seja interessante colocar)

Isso é efetivamente só uma extensão de Tipagem Dinâmica. Em Ruby, métodos que esperam ser aptos a operar objetos String não checam se é uma String (is_a?(String)). Eles checam se o objeto responde a mensagem to_str (respond_to?(:to_str)) e então chamam o to_str naquele objeto se ele permitir. Similarmente, objetos que representam Paths em Ruby podem implementar um método to_path para proporcionar uma representação de path.

Em Rails, nós usamos essa técnica para objetos que tem características de “model” ao esperar deles o respond_to?(:to_model). Isso permite-nos suportar qualquer objeto em contextos relevantes, se aqueles objetos puderem nos fornecer uma representação “model” deles.

3. Módulos Incríveis

Ruby fornece um benefício similar ao “traits” em Scala, Squeak e Perl. Efetivamente, os módulos de Ruby permitem a adição dinâmica de novos elementos da hierarquia de classe em tempo de execução. O uso de super é dinamicamente avaliado em tempo de execução para considerar qualquer módulo que possa ter sido acrescentado, tornando fácil extender funcionalidade em uma superclass quantas vezes você desejar, sem ser forçado a decidir onde super estará ao declarar sua classe.

Além disso, os módulos de Ruby fornecem os eventos append_features e included, que tornam possível usar módulos robustamente para isolar extensões uma da outra e para dinamicamente extender classes na base da característica de inclusão.

4. Corpos de classes não são especiais

Em Ruby, corpos de classes são tem um contexto especial. Eles são simplesmente um contexto onde self aponta para o objeto da classe. Se você já usou Rails, você provavelmente viu um código como esse:

class Comment < ActiveRecord::Base

validates_presence_of :post_id

end

Pode parecer que validates_presence_of é uma característica da linguagem, mas na verdade é um método sendo chamado em Comment que é fornecido por ActiveRecord::Base.

Esse método pode executar um código arbitrário, também no contexto da classe, incluindo criar novos métodos, executar outras partes de código ou atualizar a variável de instância da classe. Ao contrário das “Java annotations”, que devem ser executadas em tempo de compilação, corpos de classes em Ruby podem pegar informações em tempo de execução para considerar, como opções fornecidas dinamicamente ou os resultados da avaliação de outro código.

5. String Eval

Eu não estou me referindo a “String eval” arbitrários em tempo de execução, mas a String eval que são usados para criar métodos no processo de boot de uma aplicação Ruby.

Isso torna possível pegar estruturas definidas pelo Ruby, como Rails routes ou AOP-definitions, e compilá-las em métodos Ruby. Claro, é possível implementar essas coisas como complementos para outras linguagens, todavia Ruby torna possível implementar esse tipo de coisa em Ruby puro. É, numa visão ampla, uma linguagem “self-hosting” (que compila seu próprio código fonte).

6. Blocos e “Lambdas”

Eu já disse isso algumas vezes e repetirei: eu não considero linguagens sem “lambdas” anônimos poderosas o bastante para meu usuo diário. Essas construções são, na verdade, extremamente comuns e encontradas em linguagens como Ruby, JavaScript, Scala, Clojure e Lisp.

Eles tornam possível implementar construções de escopo de bloco que parecem características da linguagem. O exemplo mais comum é o de operações com arquivos. Em linguagens sem “lambdas”, usuários são forçados a utilizar um bloco no mesmo escopo que ele abriu o arquivo para assegurar que ele está fechado.

Em Java:

static void run(String in)

throws FileNotFoundException {

File input = new File(in);

String line; Scanner reader = null;

try {

reader = new Scanner(input);

while(reader.hasNextLine()) {

System.out.println(reader.nextLine());

}

} finally { reader.close(); }

}

Entre outras coisas, o Java precisa colocar a criação do Scanner em um bloco TRY para garantir que será fechado. Em contraste, a versão Ruby:

def run(input)

File.open(input, “r”) do |f|

f.each_line {|line| puts line }

end

end

Por causa da existência de blocos, é possível abstrair a necessidade de fechar o arquivo em um único local, minimizando erros do programador e reduzindo duplicação.

7. Ataque Combo: Linguagem que se “auto-compila”

A combinação de diversas das características acima produz exemplos reais de formas que podemos “extender” o Ruby em Rails. Considere o seguinte:

respond_to do |format|

if @user.save

flash[:notice] = ‘User was successfully created.’

format.html { redirect_to(@user) }

format.xml { render ml => @user, :status =>ted, :location => @user }

else

format.html { render :action => “new” }

format.xml { render ml => @user.errors, :status => :unprocessable_entity }

end

end

Nesse caso, nós estamos aptos a misturar métodos (respond_to) com código Ruby (if e else) para produzir um novo escopo de bloco. A semântica do Ruby para blocos permite-nos retornar ou executar blocos de dentro deles, mas misturando mais as fronteiras de blocos de código e construções como if ou while.

Em Rails 3, nós introduzimos:

class PeopleController < ApplicationController

respond_to :html, ml, :json

def index

@people = Person.find(:all)

respond_with(@people)

end

end

Aqui, respond_to é fornecido em um nível de classe. Isso diz ao Rails que respond_with (índice) deve aceitar HTML, XML ou JSON como formatos. Se o usuário solicitar um formato diferente, é automaticamente retornado um erro 406 (não aceito).

Se você for um pouco mais profundo, você pode ver que o método respond_to é definido como:

def respond_to(*mimes)

options = mimes.extract_options!

only_actions = Array(options.delete(:only))

except_actions = Array(options.delete(:except))

mimes.each do |mime|

mime = mime.to_sym

mimes_for_respond_to[mime] = {}

mimes_for_respond_to[mime][:only] = only_actions unless only_actions.empty?

mimes_for_respond_to[mime][:except] = except_actions unless except_actions.empty?

end

end

Esse método é definido no módulo ActionController::MimeResponds::ClassMethods, que é colocado no ActionController::Base. Além disso, mimes_for_respond_to é definido usando class_inheritable_reader. O método do class_inheritable_reader (macro?) usa class_eval para adicionar métodos numa classe em questão para emular a funcionalidade attr_accessor.

Entender todos os detalhes não é importante. O que é importante é que usando as características do Ruby descritas acima, é possível criar camadas de abstração que podem aparecer para adicionar funcionalidades na linguagem.

Um desenvolvedor olhando para o ActionController::MimeResponds não precisa entender como class_inheritable_reader trabalha – ele só precisa entender a função básica. E um desenvolvedor olhando para a documentação da API não precisa entender como o respond_to a nível de classe é implementado – ele só precisa entender a funcionalidade fornecida. Dito isso, descamando cada camada leva a simplificar as abstrações que controem outras abstrações. Não há necessidade de descamar tudo de uma vez só.

8. Bons Literais

(nota: literais são tipo valores básicos, que você pode criar sem chamar um método .new)

Eu geralmente esqueço isso quando programo em Ruby, somente para reclamar quando uso uma linguagem com menos e pouco expressivos literais.

Ruby tem literais para quase tudo:

• Strings: single-line (uma linha), double-line (duas linhas), interpolated (interpolado)
• Números: binary, octal, decimal, hex
• Null: nil
• Boolean: true (verdadeiro), false (falso)
• Vetores: [1,2], %w(cada palavra é um elemento)
• Dicionários: {chave => valor} e no Ruby 1.9 {chave: valor}
• Expressões regulares: /hello/, %r{hello/path}, %r{hello#{interpolated}}
• Símbolos: :name e :”string qualquer”
• Bloco: {bloco literal}

E eu penso que estou perdendo algo. Enquanto isso pode parecer acadêmico, bom, legível, literais podem aumentar a habilidade do programador de escrever um código curto, mas extremamente expressivo. É claramente possível conseguir as mesmas coisas que você pode com um Dicionário “literal” ao instanciar um novo objeto Dicionário e colocar as chaves e valores um por vez, mas isso reduz a capacidade deles como parâmetros de algum método, por exemplo.

A concisão de um Dicionário “literal” permitiu os programadores de Ruby a efetivamente adicionar um recurso de argumentos limitados por palavras-chave à linguagem sem precisar da aprovação dos criadores dela. Ainda é outro pequeno exemplo de auto-compilação.

9. Tudo é um Objeto e Todo Código é Executado e tem um Self

Eu mostrei isso um pouco atrás, mas muito da razão dos corpos das Classes trabalharem como eles trabalham é uma consequência da infalível orientação a objeto da linguagem Ruby. Dentro do corpo de uma classe, Ruby é simplesmente executado com um self apontando para a classe. Além disso, nada é especial no contexto da classe; é possível avaliar o código de um contexto de classe de qualquer localidade. Veja:

module Util

def self.evaluate(klass)

klass.class_eval do

def hello

puts “#{self} says Hello!”

end

end

end

end

class PersonName < String

Util.evaluate(self)

end

Isso é exatamente equivalente a:

class PersonName < String

def hello

puts “#{self} says Hello!”

end

end

Ao remover as fontreiras artificiais entre código em diferentes locais, Ruby reduz a sobrecarga conceitual de criar abstrações. E isso é o resultado de um forte e consistente modelo de objeto.

Mais um exemplo nesse tópico. Essa expressão é muito comum em Ruby: possivelmente_nulo && possivelmente_nulo.nome_do_metodo. Já que nil é somente um objeto em Ruby, mandar mensagens a ele que não serão entendidas resultará em um NoMethodError. Alguns desenvolvedores recomendam a seguinte sintaxe: possivelmente_nulo.try(:nome_do_metodo). Isso pode ser implementado em Ruby como a seguir:

class Object

alias_method :try, :__send__

end

class NilClass

def try

nil

end

end

Essencialmente, isso adiciona o método try a qualquer Object. Quando o Object é nil, try simplesmente retorna nil. Quando o Object não é nil, try simplesmente chama o método em questão.

Usando aplicações segmentadas das classes abertas de Ruby, combinado com o fato que tudo em Ruby, incluindo nil, é um objeto, nós estamos aptos a criar um novo recurso de Ruby. Novamente, isso não é grande coisa, mas é outro caso no qual as escolhas certas na linguagem podem permitir que nós criemos abstrações muito úteis.

10. Rack

Eu irei trapacear um pouco porque Rack não faz parte da linguagem Ruby, mas ele demonstra algumas coisas úteis sobre a linguagem. Primeiramente, a biblioteca Rack só chegou ao 1.0 no começo desse ano e já todo framework web de Ruby suporta Rack. Se você usa um framework Ruby, você pode ser garantido que ele usa Rack e qualquer “Rack middleware” padrão irá funcionar.

Isso foi tudo feito sem qualquer sacrifício de compatibilidade anterior, um tributo à flexibilidade da linguagem Ruby.

Rack também traz recursos do Ruby para fazer seu trabalho. A API Rack parece com isso:

Rack::Builder.new do

use Some::Middleware, param

use Some::Other::Middleware

run Application

end

Nesse breve trecho de código, muitas coisas estão trabalhando. Primeiro, um bloco é passado para Rack::Builder. Segundo, esse bloco é avaliado no contexto de uma nova instância de Rack::Builder, o que dá acesso a usar e rodar os métodos. Terceiro, o parâmetro passado para usar e rodar é uma classe “literal”, que em Ruby é um simples objeto. Isso permite Rack chamar passed_in_middleware.new(app, param), em que new é somente uma chamada de método no objeto da classe Some::Middleware.

E no caso de você pensar que implementar o código seria hediondo, aqui está:

class Rack::Builder

def initialize(&block)

@ins = []

instance_eval(&block) if block_given?

end

def use(middleware, *args, &block)

@ins << lambda { |app| middleware.new(app, *args, &block) }

end

def run(app)

@ins << app #lambda { |nothing| app }

end

end

Isso é todo o necessário para implementar o código que eu mostrei acima que cria uma nova aplicação Rack. Instanciando o middleware é uma simples questão:

def to_app

inner_app = @ins.last

@ins[0...-1].reverse_each { |app| inner_app = app.call(inner_app) }

inner_app

end

def call(env)

to_app.call(env)

end

Primeiro, nós pegamos o último elemento, que é nosso ponto final. Nós, então, iteramos os elementos restantes com reverse, instanciando cada middleware com o próximo elemento da cadeia e retornando o objeto resultante.

Finalmente, nós definimos uma chamada de método no Construtor, que é requerida pelo Rack especificamente, que chama to_app e passa o ambiente por ele, retirando a cadeia.

Através do uso de um bom número de técnicas descritas no post, nós estamos aptos a criar uma aplicação compatível com Rack que suporta o “Rack middleware” em menos que duas dúzias de linhas de código.”

Posts interessantes:

• Manifesto ágil
• Getting Real e mais sobre a 37signals
• Aprenda Ruby on Rails com os experts no assunto
• Ruby on Rails, a nova sensação da Web

Vamos lá, conte-nos o que achou desse nosso primeiro Guest Post! Já está com todo o gás para entrar no Ruby? Comente e pergunte!

Helton de Melo Duarte

“Em Deus está a minha salvação e a minha glória; a rocha da minha fortaleza e o meu refúgio estão em Deus.” Salmos 62.7

“Ouve, ó Deus, a minha voz na minha oração; livra a minha vida do horror do inimigo.” Salmos 64.1

Hoje venho mostrá-los algo que já está na comunidade de informática a algum tempo, contudo está ganhando forças a cada dia e mostrando-se muito eficaz: desenvolvimento ágil de software. Chega de milhões de diagramas das aulas de engenharia de software (eu sei que tem um propósito, mas é muita burocracia!), vou traduzir abaixo o Agile Manifesto, publicado em 2001 por grandes nomes da área.

“Nós estamos descobrindo melnhores maneiras de desenvolver software ao fazer isso e ajudando outros a fazer. Por esse trabalho, nós começamos a valorizar:

• Indivíduos e interações, ao invés de processos e ferramentas;
• Software funcional, ao invés de documentação compreensiva;
• Colaboração do cliente, ao invés de negociação de contrato;
• Resposta a mudanças, ao invés de seguir um plano.

É isso, enquanto há algum valor nos itens à direita, nós valorizamos mais os itens à esquerda.

Princípios por trás do Manifesto Ágil

Nós seguimos esses princípios:

• Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual.
• Seja bem-vindo à mudança de requisitos, mesmo que tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
• Entregar software utilizável frequentemente, de algumas semanas a alguns meses, com preferência a menores escalas de tempo.
• Executivos e desenvolvedores devem trabalhar juntos diariamente durante o projeto.
• Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda que eles precisam e confie neles para ter o trabalho concluído.
• O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é conversa face-a-face.
• Software funcional é a medida primordial do progresso.
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente.
• Atenção contínua à excelência técnica e bom design aumenta a agilidade.
• Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
• As melhores arquiteturas, requisitos e design surgem de um time auto-organizado.
• Em intervalos regulares, o time reflete em como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento.”

Se você quiser saber mais sobre o assunto, sugiro que dê uma olhada na história de criação do Manifesto e sobre os autores, para ter uma visão mais legal. Além do mais, você pode demonstrar que realmente apóia o assunto e assinar o manifesto.

Posts interessantes:

• Getting Real e mais sobre a 37signals
• Aprenda Ruby on Rails com os experts no assunto
• Ruby on Rails, a nova sensação da Web

E aí, o que achou do desenvolvimento ágil? Conte suas experiências com técnicas como eXtreme Programming ou Scrum, pois depois haverá posts sobre eles. Comente!

Helton de Melo Duarte

“Livra-me, meu Deus, dos meus inimigos; defende-me daqueles que se levantam contra mim.” Salmos 59.1

“A ti, ó fortaleza minha, cantarei louvores, porque Deus é a minha defesa, é o Deus da minha misericórdia.” Salmos 59.17

Hoje venho falar sobre um livro muito bom e extremamente recomendado a quem é da área de informática (ainda não o li por completo, mas já li diversas partes): Getting Real, da 37Signals (criadores do framework Ruby On Rails). Na verdade, venho divulgar ainda mais o trabalho da empresa que mudou o modo de pensar no desenvolvimento para a internet.

37signals

Empresa sediada em Chicago, EUA, com um objetivo claro: fazer as coisas mais simples. Atualmente, são 14 pessoas que desenvolvem aplicações na web com foco em grupos pequenos, seja uma pequena empresa, seja um departamento de uma multinacional. Os principais executivos da empresa são Jason Fried e David Heinemeier Hansson, do blog Loud Thinking (e criador oficial do Rails).

Getting Real

Esse livro mostra as filosofias de negócio, design, programação e marketing da 37signals, responsável por 5 aplicações de extremo sucesso na web: Basecamp, Campfire, Backpack, Writeboard, Ta-da List. Qualquer um que trabalha em aplicações web – empresários, designers, programadores, executivos ou “marketeiros” – irão encontrar valor e inspiração nesse livro, sub-titulado de “O modo mais inteligente, rápido e fácil de criar um aplicação web de sucesso”.

Para acompanhar a evolução do software livre, de código aberto, presenciado em todo o mundo, o livro Getting Real está disponibilizado gratuitamente na web, com diversas traduções.

Rework

Hoje, foi oficialmente revelada a criação de mais um livro pela empresa, o Rework, o qual estará disponível para venda no dia 9 de março de 2010, todavia já pode ser pré-vendido pela Amazon.com. Segundo eles, tudo o que sabem sobre negócios estará nesse novo livro…só nos resta esperar! =D

Mais…

Outro livro deles é o Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points, que o @elomar me informou. Para mais informações, vejam os blogs da 37signals: Signal vs. Noise e Product Blog.

OBS: Aproveitem a área para você dar suas sugestões de assuntos e nos ajudem a criar um blog melhor.

OBS 2: Foi feita uma alteração nas categorias do blog, organizando-as de uma melhor forma. Por favor, conte-nos o que achou dessa modificação.

Posts interessantes:

• Aprenda Ruby On Rails com os experts no assunto
• Google Chrome OS – Como será?
• Computação em nuvem: Evolução?
• Ruby on Rails, a nova sensação da Web

Está doidinho para trabalhar na 37signals? Bem, como isso não é para qualquer um, pelo menos ajude a criar uma web melhor e dê suas dicas! Comente sobre o que achou do post!

Helton de Melo Duarte

“Deus é o nosso refúgio e fortaleza, socorro bem presente na angústia. Pelo que não temeremos, ainda que a terra se mude, e ainda que os montes se transportem para o meio dos mares.” Salmos 46.1,2

“Tem misericórdia de mim, ó Deus, segundo a tua benignidade; apaga as minhas transgressões, segundo a multidão das tuas misericórdias.” Salmos 51.1

Olá pessoal,

Passei um bom tempo sem postar não foi? Bem, primeiramente tive provas e fiquei sem tempo…aí depois vieram as férias e precisava de descanso ^^ Mas voltando ao batente, venho avisá-los de outra competição de programação que está vindo por aí: Google Code Jam 2009! É mais uma competição em que podem participar profissionais e estudantes no intuito de construir algoritmos desafiantes e com um diferencial: permite que você programe na sua linguagem favorita com o ambiente de programação à sua escolha! =D

Você já pode fazer seu registro, tendo até o dia 3 de setembro para isso. O desafio é composto de algumas fases de qualificação, nas quais os competidores terão de 3 a 6 problemas para resolver, sendo recebidos além de uma descrição dos mesmos, um arquivo de entrada para testar seu programa, sendo divididos entre Entradas pequenas e grandes, valendo pontos independentemente um do outro.

Como serão as fases da competição?

O Code Jam irá começar com um Qualification Round, do dia 2 ao 3 de setembro, consistindo de 3 problemas. Não há limite no número de pessoas a avançar para a próxima fase, sendo essa primeira fase apenas para “peneirar” os programadores: para avançar é necessário resolver um conjunto de testes pequeno e um grande, independente do problema.

Agora chega o Online Round 1, o qual será subdividido em 3 sub-rounds para poder abranger o maior número de fusos horários, possibilitando ao participante escolher em qual irá participar. Para o Online Round 2 seguirão 1000 programadores de cada sub-round, totalizando os 3000 melhores classificados.

O Online Round 2 serve “apenas” para selecionar os bons programadores, avançando 500 para o Online Round 3 e, desse último, 25 para os Onsite Finals. As finais acontecerão em Mountain View, Califórnia, na sede do Google, no dia 13 de novembro de 2009, mas não se preocupem: Viagem e acomodação serão pagas pela gigante da internet. Lembrando também que os 500 melhores colocados ganharão uma camiseta do Google Code Jam e os 25 primeiros ganharão prêmios em dinheiro, distribuídos da seguinte forma:

• 1º lugar -> US$ 5000,00
• 2º lugar -> US$ 2000,00
• 3º lugar -> US$ 1000,00
• 4º ao 25º lugar -> US$ 100,00

No entanto, acredito que o maior prêmio seja a visibilidade que uma competição dessa proporciona, tendo quase garantia de contratação pelo Google para os melhores. Para mais informações, veja as regras. Para quem se interessou, vá logo treinando nos sites do TopCoder.com, UvaOnline Judge ou nos problemas dos JAMs anteriores.

OBS: Para quem ainda não viu, temos novidades no blog: uma área para você dar suas sugestões de assuntos e o Twitter Tools, do Super Wordpress da Hostnet, permitindo que você veja as atualizações do meu Twitter direto do blog! Aproveitem!

Posts interessantes:

• Aprenda Ruby on Rails com os experts no assunto
• Desafio Nacional Acadêmico
• Programando melhor: Aula 8 – Grafos III
• Programando melhor: Aula 7 – Grafos II
• Programando melhor: Aula 6 – Grafos I

E aí? Quem vai participar do Google Code Jam? Tire suas dúvidas aqui e, quando tiver mais novidades da competição, postarei informações! Comente e diga sua opinião.

Helton de Melo Duarte

“Eu disse: Guardarei os meus caminhos para não delinquir com a minha língua; enfrearei a minha boca enquanto o ímpio estiver diante de mim.” Salmos 39.1

“Bem-aventurado o homem que põe no SENHOR a sua confiança e que não respeita os soberbos, nem os que se desviam para a mentira.” Salmos 40.4