VidaGeek.net

Linux, Open-source, Programação e Produtividade

Archive for 2010

A Associação Software Livre Santa Catarina – SoLiSC – informa a abertura da chamada de trabalhos para o 5º SoLiSC – Congresso Catarinense de Software Livre.

O evento será realizado em Florianópolis, SC, em local a ser definido, nos dias 22 e 23 de oububro de 2010.

A submissão das palestras deve ser feita até o dia 01/09/2010 (primeiro de setembro de 2010), através do sistema papers, no seguinte endereço: http://papers.solisc.org.br/2010/speaker/. Para quem já postou palestra no ano passado, pode utilizar o mesmo cadastro.

Graças à excelente avaliação do público para as palestras que vieram da chamada de trabalhos no último ano, o espaço para estas será ampliado na grade de 2010.

O comitê organizador do evento definiu os seguintes macro-temas ou trilhas para este ano:

  • Administração de Sistemas e Desenvolvimento de Software
  • Software Livre em Desktop  (Distribuições, Ferramentas de Produtividade, Multimídia, …)
  • Negócios e Casos de Uso
  • Telecomunicações
  • Hardware e Sistemas Embarcados
  • Software Livre em Geral (demais assuntos relacionados aos temas de software livre e conhecimento livre)

As palestras devem ser preparadas para a duração de 50 minutos, incluindo o tempo para perguntas.

Os trabalhos serão avaliados pelo comitê de programa do SoLiSC.

A organização do evento informa que todos os palestrantes aprovados terão isenção da inscrição do evento, mas que não irá dispor de ajuda de custo para quem tiver a palestra aprovada.

Datas Importantes:

  • 01/07/2010 – Abertura da Chamada de Trabalhos
  • 01/09/2010 – Encerramento da Chamada de Trabalhos
  • 15/09/2010 – Divulgação das palestras aprovadas
  • 22 e 23/10/2010 – 5º SoLiSC

Posts Relacionados:

  • Textos Clássicos
  • FISL 8.0
  • Cuba Libre
  • Economizando com Software Livre
  • FISL8.0: DRM como ameaça para o software livre: música, filmes e TV digital
  • Show Us The Code, Mr. Ballmer!!!
  • FLISOL terá sede no IME/USP
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

  • 0 Comments
  • Filed under: Eventos, OpenSource
  • Aqui na nossa série de linguagens de programação (sem posts já faz um tempo), já falamos de Ruby, mas ainda não de Python. O ideal seria falar de Python antes mas, graças a uma palestra interessante que assisti online, resolvi fazer alguns comentários e críticas a cada uma delas.

    Antes de mais nada, é importante entender quais as bases e as motivações de cada uma dessas duas linguagens. Ambas as linguagens têm como metas permitir código bonito, legível e o mais simples possível. Mas o critério de bonito e legível difere para cada uma delas. De acordo com o Zen do Python (numa tradução livre):

    [...]
    Casos especiais não são tão especiais para quebrarmos as regras.
    [...]
    Quando se deparar com uma ambiguidade, não ceda à tentação de tentar adivinhar.
    Deveria haver uma, e preferencialmente só uma, maneira óbvia de fazer algo.
    [...]
    Se a implementação é difícil de explicar, não é uma boa ideia.
    [...]

    Já o Ruby, de acordo com o próprio criador Yukihiro Matsumoto:

    [...] é simples na aparência, mas muito complexo no interior, tal como o corpo humano.

    Nota-se que isso contraria a parte da simplicidade de implementação do Zen do Python. E nota-se isso também em bibliotecas famosas escritas em Ruby, como o ActiveRecord, por exemplo. Você já tentou entender a implementação da classe ActiveRecord::Base?

    Além disso, Ruby herdou de Perl, uma de suas fontes de inspiração, a ideia de ter várias formas de fazer uma mesma coisa. E também tem alguns casos especiais de sintaxe, como a invocação de um setter (que pode ser com espaço antes do igual, apesar de o nome do setter não ter esse espaço), os parênteses opcionais na invocação de um método ou as chaves opcionais num hash passado como argumento.

    Agora, minha opinião

    Acho que é bom ter mais de um jeito de fazer a mesma coisa, como o Ruby possibilita. Um jeito só de fazer a mesma coisa, a meu ver, tem a vantagem de facilitar um pouco a leitura do código, graças à uniformidade. Mas, por outro lado, nos comunicamos uns com os outros numa língua que permite expressar uma mesma ideia de muitas formas diferentes, e mesmo assim nos entendemos, não? É claro que às vezes com alguma dificuldade, mas na maioria das vezes por causa da ambiguidade da língua. E liberdade de expressão também é importante em programação!

    Por outro lado, as peculiaridades da sintaxe de Ruby não me agradam; acho que tornam a linguagem mais difícil de compreender. Os casos especiais são muitos e, às vezes, deixam o programador confuso quanto à necessidade de chaves, por exemplo.

    Uma característica muito importante que a linguagem Ruby deveria ter, mas só Python tem, são argumentos rotulados. Em Ruby, costuma-se utilizar um hash para suprir essa necessidade, o que, convenhamos, não é muito elegante.

    Um ponto sobre o qual ainda não tenho uma opinião muito elaborada é sobre a modificação de classes e métodos em tempo de execução. Em Ruby, ela é implícita: se você declarar uma classe com o mesmo nome de uma que já existe, você estará modificando a existente. Em Python, ela é explícita: você só pode modificar a classe existente se você escrever código específico para isso; se você declarar uma classe com o mesmo nome de uma já existente, você está criando outra classe. Por um lado, acho bom deixar explícito que você está modificando uma classe existente. Mas, por outro lado, faz sentido ter duas classes diferentes com o mesmo nome?

    E você, qual a sua opinião? Quais são suas críticas a cada uma dessas linguagens?

    Posts Relacionados:

  • FISL 10: Seaside versus Rails
  • Linguagens de Programação - C
  • Linguagens de programação - Ruby
  • Rails Vs Java e PHP
  • Linguagens de programação - Smalltalk
  • Linguagens de Programação - Basic
  • Lambda the Ultimate
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Dia 19/05/2010 o Rafael Ferreira dará uma palestra na reunião do SouJava.

    Programação:
    18:30 - Meeting
    19:00 - Scala: Mais poder e menos burocracia na JVM.
    22:00 - Encerramento

    Palestra: Scala: Mais poder e menos burocracia na JVM.

    Palestrante: Rafael Ferreira
    Consultor de desenvolvimento de software, trabalha com Java
    há 6 anos. Foi embaixador no campus da USP pela Sun
    Microsystems, e atualmente é um entusiasta de paradigmas
    alternativos de programação.

    Inscrições: http://migre.me/C1Xf

    Local:
    SUCESU - Sociedade de Usuários de Informática e Telecomunicações - São Paulo
    Rua Treze de Maio, 681 - 1º Andar - Bela Vista
    01327-000 / São Paulo - SP
    http://www.sucesusp.org.br/portal/index.php/contato.html

    Essa é uma palestra que recomendo muito. Não apenas por gostar de scala, mas por conhecer há um bom tempo o trabalho que o Rafael Ferreira faz.

    Posts Relacionados:

  • InteGrade: Um Sistema Brasileiro para Computação em Grades
  • INC - Labelled Loops
  • O Mal da Google
  • O Poder do Linux
  • Atualizações de Segurança do Windows Vista
  • Rodas existem porque inventamos várias
  • Na crista da onda
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

  • 1 Comment
  • Filed under: Uncategorized
  • Aplicações para a Internet que se comunicam umas com as outras é algo mais do que comum. Ou sua aplicação consome algo que outra produz ou ela produz algo para outra consumir.

    É bem fácil testar o que sua aplicação produz. Basta subir um servidor local, fazer uma requisição para o endereço correspondente e processar o resultado. Mas, por outro lado, como testar que sua aplicação consome o que outra produz adequadamente?

    É claro que não vamos querer depender da aplicação remota de verdade. Queremos deixar os testes automatizados o mais isolados possível dos recursos externos. Então vamos, provavelmente, querer que o objeto responsável por fazer as requisições para fora não as faça de verdade e que devolva dados semelhantes aos da aplicação real.

    Um jeito de fazer isso seria “embrulhar” a comunicação com a Internet numa classe nossa e, nos testes, mockar essa classe e passar essa classe mockada para as classes (ou os métodos) que precisam dela. É possível fazer isso em qualquer linguagem que suporte orientação a objetos.

    Em Ruby ainda temos uma outra possibilidade. Como as classes são abertas, podemos re-escrever os métodos da classe Net::HTTP, por exemplo. Assim, não precisamos criar um embrulho; podemos utilizar sempre a classe do sistema.

    Pois também não precisamos fazer isso na mão. A gem FakeWeb permite mockar requisições para determinadas URIs com um código bastante sucinto. Por exemplo, se você quiser que seu programa receba “olá mundo” quando fizer uma requisição do tipo GET para a URI http://foo.com/bar, basta escrever antes do código que executa a requisição:


    FakeWeb.register_uri(:get, "http://foo.com/bar", :body => "olá mundo")

    Em Java também é possível fazer algo parecido com um pouco de magia negra, desde que controlemos a criação do objeto responsável pela requisição. Mas, a meu ver, a primeira abordagem resulta num código mais desacoplado. Qual a sua opinião?

    Posts Relacionados:

  • Atualizando o RubyGems no Mac
  • FISL 8.0: Wireless Meshing with OLPC
  • Eleições via Internet?
  • Firefox começa a dominar Europa
  • Aplicações portáveis em C/C++
  • Os criadores do Skype atacam novamente…
  • Algumas impressões de JavaME
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.