Blog do Gio : Numix no Ubuntu 14.04!

28 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Vamos utilizar para personalizarmos o nosso Ubuntu 14.04 o pacote de ícones e temas Numix!

Porém esse pacote não está nos repositórios oficiais, então precisamos adicionar o repositório que o contém, logo:

$ sudo add-apt-repository ppa:numix/ppa

Feito isso precisamos atualizar os repositórios:

$ sudo apt-get update

Agora vamos instalar o pacote “completo” de temas e ícones Numix:

$ sudo apt-get install numix-gtk-theme shimmer-themes numix-icon-theme numix-icon-theme-shine numix-icon-theme-circle

O Ubuntu ainda não fornece por padrão uma ferramenta que nos permita personalizar os ícones e o temas do sistema, além dos que já são padrões (Como assim Ubuntu?!). Para resolver esse problema vamos instalar a ferramenta Unity-tweak-tool, logo:

$ sudo apt-get install unity-tweak-tool

Agora basta abrir a ferramenta Unity-tweak-tool e fazer as personalizações, escolhendo os temas que mais gostar:

tweak

Como resultado:

Captura de tela de 2014-04-28 18:44:16
Bacana não?!

Aproveite!

Ps.: Essa versão 14.04 do Ubuntu, está notavelmente mais rápida e eficiente, pelo menos em um primeiro contato.

Abraço!




Farid Abdelnour : Videoclipe Solidariedade Feminina

28 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Solidariedade Feminina é uma música-protesto contra a violência que mulheres ainda sofrem em todo o mundo. É um trabalho autoral da cantora Thabata. O videoclipe foi produzido pela Gunga, com a colaboração da comunidade do Mercado Sul de Taguatinga.

Serviços prestados: direção, edição, filmagem e produção
Sotwares utilizados: Kdenlive e GimpAno: 2014

 



Helio Costa - hlegius : Introspecção

28 de Abril de 2014, por Desconhecido - 0sem comentários ainda

It's time for Change

Mudança. Todos temem à mudanças. E não seria diferente ao codificar software, não é mesmo? Para que mudar se podemos continuar com nossa atual rotina simples e praticamente automática? Aquela coisa de chegar no trabalho, fazer o de sempre, como aprendeu no tutorial há tempos atrás ou que viu o ex-chefe fazer e até hoje executa assim sem questionamentos.

Em software isso recebeu um nome no livro The Pragmatic Programmer. Caso o cenário acima encaixe no seu code-style, você está programando por coincidência. Gosto do termo em português, pois ele é duplo sentido. Além de indicar o estado profissional acima, ele também implicitamente diz que você está na área por um mero acaso. * O livro não fala disso. Essa segunda parte é totalmente de minha autoria. Pode parecer xiita, mas te convido a refletir sobre isso mais a fundo.

Ao entrar no seu modo automático e passar a fazer coisas sem se questionar o porquê está fazendo (ou fazendo novamente) aquilo, você está programando por coincidência. Seguir aquele fluxo toda vez que depara com um problema passado sem questionar-se o motivo e se há melhor alternativa, você está programando por coincidência. Se, você assume coisas - isso vale muito pra teste - por exemplo que o erro X é causado pelo Y, simplesmente porque você acha que isto ocorre, você está programando por coincidência. Neste caso você não deveria assumir, mas sim provar que o problema é aquele mesmo.

Saindo da coincidência

Uma das formas de evitar esse ciclo de tédio e comodismo é justamente fazer Test-First. Explico os motivos:

  1. Lego Effect: como comentei no Teste Unitário?, começar pelo teste fará você pensar em como aquela funcionabilidade que pretende fazer irá se relacionar. Isso te faz pensar mais e consequentemente, dúvidas virão e você buscará saná-las (livros, pesquisa na Internet, Twitter, outros devs, projetos Opensource).
  2. Ah, a preguiça! Os testes te ajudarão a achar o menor caminho possível para aquela implementação. (teste é coisa de preguiçoso, lembra?) Isto te fará repensar técnicas. Com a prática de novas técnicas, você evoluirá como desenvolvedor.
  3. Não mais dúvidas sem resposta! Com teste, você pode testar não apenas o código de implementação mas também as suas suposições. Pensamentos do tipo: será que isto pode funcionar desta forma? serão mais frequentes, uma vez que o espaço entre o será que... e a resposta são apenas escrever um assertion simples e executá-lo.
  4. You on Rails. A prática do Test-first te mantém na linha de fazer o que realmente importa. Sem suposições vazias; Sem achismo; Você se antecipa dos problemas que poderá encontrar. Estar alinhado em fazer o que importa te torna introspectivo.
  5. Test & fail. Test & Learn.
  6. Não sendo mais telespectador. Você no controle! Não mais sendo guiado por processos e rotinas sem saber o motivo de estar fazendo aquilo daquela forma.

Questione-se; Reflita; Pense um pouco mais sobre sua forma de fazer as coisas. Isso é realmente a melhor forma de se obter o resultado que deseja?

Recentemente peguei meu Card Deck que ajudei a fundar (?) no Kickstater. Um dos cards que mais me chamou a atenção, até pelo fato de eu já ter feito isso anteriormente é o Remove your BEST idea.

Remove your best idea

Conseguiu achar uma solução para o problema? Ótimo! Ela poderá ser seu backup caso as coisas dê muito errado. Empenhe-se para achar uma outra melhor ideia. Vale muito a pena esse exercício.

Concluíndo

Test-first é uma das formas de acabar com a programação por coincidência. Test-first entretanto não irá te salvar de todo o mal do mundo - mas posso afirmar, por experiência própria que ele te coloca on track novamente.

A propósito, já leu o The Pragmatic Programmer: From Journeyman to Master? Permita-me dizer que você deveria se ainda não o fez pelo menos uma vez.



Arch Linux Brasil : screen-4.2.0 não consegue recuperar instâncias antigas

24 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Leandro Inácio escreveu:

Usuários do programa screen não estão habilitados a recuperar instâncias antigas depois da atualização para a versão 4.2.0; isto acontece devido ao upstream ter realizado muitas mudanças internas, e trocada a comunicação através de pipes para sockets. Por favor, certifique se suas instâncias atuais não são mais necessárias antes de atualizar.



Magnun Leno : Curso de Filosofia GNU - Parte 8

22 de Abril de 2014, por Desconhecido - 0sem comentários ainda

No penúltimo texto do Curso de Filosofia GNU "Linux e o Sistema GNU" o autor, Richard Stallman, retoma o conflito "Sistema GNU" e "Sistema Linux". Para muitos pode soar como purismo e minúcia, mas para Stallman é assunto sério. Acredito que depois de lerem este texto todos vão entender por que sempre uso o termo GNU/Linux neste site.

GNU/Linux

Lembrando que este é um conteúdo livre obtido no CDTC.

Curso de Filosofia GNU - Parte 8 é um artigo original de Mind Bending



Magnun Leno : Curso de Filosofia GNU - Parte 8

22 de Abril de 2014, por Desconhecido - 0sem comentários ainda

No penúltimo texto do Curso de Filosofia GNU "Linux e o Sistema GNU" o autor, Richard Stallman, retoma o conflito "Sistema GNU" e "Sistema Linux". Para muitos pode soar como purismo e minúcia, mas para Stallman é assunto sério. Acredito que depois de lerem este texto todos vão entender por que sempre uso o termo GNU/Linux neste site.

GNU/Linux

Lembrando que este é um conteúdo livre obtido no CDTC.

Curso de Filosofia GNU - Parte 8 é um artigo original de Mind Bending



Magnun Leno : Curso de Filosofia GNU - Parte 7

21 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Dando continuidade ao Curso de Filosofia GNU, neste outro texto (que pode ser classificado como um conto) Richard Stallman tenta nos levar a uma versão alternativa da terra (em 2096), onde o Software Livre fracassou e as empresas ditam as regras, controlando o acesso, leitura e empréstimo de textos, livros e artigos acadêmicos. Este artigo foi escrito em meados dos anos 90, e na época a ideia de e-books e leitores de livros eletrônicos ainda era remota.

GNU Reading

Lembrando que este é um conteúdo livre obtido no CDTC.

Curso de Filosofia GNU - Parte 7 é um artigo original de Mind Bending



Helio Costa - hlegius : Test Double com Mock e Stub

21 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Lembro-me bem da primeira vez que ouvi o termo. Era meados de 2009, quando li em algum lugar do GUJ sobre um "recurso" muito valioso nos Testes Unitários que era de fundamental entendimento para seguir adiante. Depois de ler algumas coisas na Internet, eu havia encontrado pelo menos três diferentes definições para Mock e Stub. Naquele momento eu descobri de que precisava de bibliografias-referência no assunto para acabar com aquelas meias verdades que pairavam sobre minha cabeça.

Test Double

A primeira definição que encontrei era mais ou menos assim: "Mock você utiliza quando o valor de retorno importar; Stub nos demais casos." - ah, quantas vezes não "testei" software com esse mindset. Mesmo não entendendo bem o que era o tal valor de retorno, eu me aventurava e me forçava a fazer. Segui assim até ler pela primeira vez o livro Growing Object-Oriented Software, Guided by Tests, de Steve Freeman e Nat Price. Naquele momento minha cabeça explodiu e tudo fez mais sentido. Desde então, costumo definí-los da seguinte forma:

Stub é uma dependência da sua classe-alvo (Objeto em Teste), agindo como um substituto, evitando que a implementação real seja executada.

Explicação longa:

class Authenticator
  def login(user)
    return user.password == "123456"
  end
end

describe Authenticator do
  it "will login with valid credentials" do
    user = double('User', password: '123456')
    expect(subject.login(user)).to be_true
  end
end

Repare no teste o user = double('User', password: '123456') e repare que isto permite que eu simule um usuário "válido" (no exemplo é só o password bater com 123456) - ou seja, eu configurei minha dependência (User) para que o objeto Authenticator pudesse ter um usuário válido. Um exemplo mais elaborado seria:

class Authenticator
  def login(user)
    if (user.admin? and user.has_confirmed_account?)
      self.grant_permissions_to(user)
    else
      false
    end
  end

  private
  def grant_permissions_to(user)
    # do something nice with our lovely user
  end
end

class User
  def initialize(sms_api: SMSApi.get_instance)
    @sms_api = sms_api
  end

  def admin?
    type == 'admin' # type could be an Database field mapped
  end

  def has_confirmed_account?
    user.documentation_already_approved? and sms_api.cellphone_confirmed_for(self)
  end

  private

  def sms_api
   @sms_api # SMS Wrapper Injected via initialize (constructor) method
  end
end

describe Authenticator do
  it "will login with valid credentials" do
    user = double('User', :admin? => true, :has_confirmed_account? => true)
    expect(subject.login(user)).to be_true
  end
end

Deixei o exemplo mais elaborado para mostrar o poder e a importância do Test Double: note que stubando o método User#has_confirmed_account? eu simplesmente evito ter que lidar com o SMSApi e com o documentation_already_approved?, bastando eu ter feito meu double retornar true no has_confirmed_account?. Imagina o trabalho que eu teria para configurar o SMSApi e o método de documentação aprovada em todo teste que eu precisasse chamar o método has_confirmed_account?. Insano, né?

Graças ao double eu consigo focar no meu problema que é: o Authenticator#login está, dado um usuário aceito por ele, conseguindo autenticar este user object?

Repare que o método grant_permissions_to(user) não é stubado. Ele precisa ser chamado de verdade pois é um colaborador interno da classe-algo (Authenticator class).

Mock é ligeiramente diferente, precisa estar atento para entender as diferenças.

O Mock irá criar a expectativa de que aquilo que você definiu irá de fato acontecer. Se não acontecer, o teste falhará.
describe Authenticator do
  it "will login with valid credentials" do
    user = double
    expect(user).to receive(:admin?).once.and_return(true)
    expect(user).to receive(:has_confirmed_account?).once.and_return(true)
    expect(subject.login(user)).to be_true
  end
end

Assumindo o exemplo anterior, modifiquei apenas o teste, trocando Stub por Mock. Trocando quando e se, encontrar user.admin? e/ou user.has_confirmed_account?, substitua por true e true respectivamente para você (Authenticator#login) deverá chamar user.admin? e user.has_confirmed_account? (em qualquer ordem no método) apenas uma vez (once), e terá true e true respectivamente como resposta. Saímos de algo simples, para algo assertivo. Se por um acaso eu trocar o código de produção para:

class Authenticator
  def login(user)
    if (user.has_confirmed_account?)
      self.grant_permissions_to(user)
    else
      false
    end
  end
end

O teste neste caso começará a falhar, reclamando a falta do user.admin?. Naturalmente, há regras e boas práticas para quando testar expectativas via Mock's e quando não. Sandi Metz abordou o tema neste Lunch 'n Learn.

Mock/Stub parciais (Partial Mocks)

Um recurso suportado pelo RSpec são os Partial Mocks. Há quem defenda o não uso deles (Prophecy @ PHPSpec, estou olhando para você!). Mock parcial, permite que você utilize um objeto real como dependência e mock apenas determinados métodos dela. Ainda continuando com o exemplo do autenticador, teríamos:

describe Authenticator do
  let(:admin_user) { User.new(...) # faz alguma coisa para construir um Usuário admin? == true}

  it "will login with valid credentials" do
    expect(admin_user).to receive(:has_confirmed_account?).once.and_return(true)
    expect(subject.login(admin_user)).to be_true
  end
end

As diferenças aqui são:

  1. Não utilizamos um double do RSpec. Preferimos utilizar o User object de verdade, fazendo o que for necessário para criar/retornar um usuário administrador, ou seja, um objeto de User cujo o método #admin? retornará true sem a necessidade de mudar o valor de retorno do método com stub.
  2. Com isto, não precisamos definir no teste it... o retorno de #admin? (pude remover a linha)

Com isto, ainda assim, eu mockei o #has_confirmed_account? para continuar retornando true. Com isto, acabei fazendo um Mock Parcial: o método #admin? é chamado de verdade e o #has_confirmed_account? é mockado para retornar sempre true naquele teste.

Concluíndo

Mocks e Stubs são fundamentais para a construção do seu design e para seguir em frente com Test-Driven Development. Neste post, busquei mostrar, com definições mais simples, o que são ambos e dar foco nas suas diferenças. Mas não pense que sair mokando/stubando tudo é boa prática. Há situações onde você não deve mockar; há situações onde o mock aponta um possível problema de design - e então você precisa refatorar seu código e talvez criar uma nova layer na aplicação. Em todo caso, pratique muito o assunto e torne seu código mais legível, testável e plugável.

Happy Mocking ;)



Magnun Leno : Curso de Filosofia GNU - Parte 6

16 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Este texto foi extraído do site gnu.org, nele Richard Stallman — o criador do Software Livre — discorre sobre o projeto GNU e como surgiu o movimento software livre no MIT, tendo como objetivo inicial a criação do sistema GNU. Neste texto ele passa pelo desmoronamento da comunidade hacker até chegar nos GNU/Linux.

GNU/Linux Starbucks

Lembrando que este é um conteúdo livre obtido no Projeto CDTC. Veja o restante deste conteúdo aqui.

Curso de Filosofia GNU - Parte 6 é um artigo original de Mind Bending



Magnun Leno : Curso de Filosofia GNU - Parte 5

15 de Abril de 2014, por Desconhecido - 0sem comentários ainda

Nesta quinta parte do Curso de Filosofia GNU, Djalma Valois Filho discorre sobre a nossa realidade no Brasil — em que setores do país o Software Livre deve ser aplicado, o objetivo de erradicar o analfabetismo tecnológico, o desenvolvimento de valores (solidariedade, cooperação e apoio mútuo) e o como/onde aplicar o retorno deste investimento — bem como suas próprias expectativas.

Open Source

Lembrando que este é um conteúdo livre obtido no CDTC.

Curso de Filosofia GNU - Parte 5 é um artigo original de Mind Bending