Docker, infraestrutura simples e rápida

O que é Docker

Uma plataforma aberta para desenvolvedores e administradores de sistemas, usada para construir, executar e distribuir máquinas.

Tudo isso é possível por conta da Docker Engine, que é um forma de empacotamento portável, simples e pequena de infraestrutura, que constitui facilmente várias máquinas executando no mesmo kernel, porem isoladas logicamente, usando as tecnologias LXC, AUFS e BTRFS.

Parece uma máquina virtual, não é? Porém é diferente!

Continuando sobre o conceito da plataforma Docker, eles disponibiliza também um serviço de Nuvem para armazenar e compartilhar imagens prontas, criadas tanto pela comunidade responsável pelo Docker, como por qualquer outra pessoa interessada, e o melhor, sem custo!

Cada pessoa registrada no serviço tem a possibilidade de criar um número ilimitado de máquinas públicas (todos podem ver e baixar) e apenas uma máquinas privada na conta gratuita.

Imagens e Containers

Uma máquina docker pode ser composta de várias camadas. E essas camadas se dividem em dois tipos; Imagens e Containers.

• Imagens: Uma vez as máquinas em execução essas camadas são montadas como somente leitura. Elas podem ser compartilhadas por várias máquinas, ou seja, uma vez modificadas afetam todas as máquinas que usam essas imagens.
• Containers: Essas camadas são montadas como leitura e escrita. É onde de fato estão as modificações da máquina em execução. Toda modificação realizada em uma imagem é feita a partir de um container.

Imagens e containers, perfeita sinergia.

Instalando o Docker

Se você usar Debian Jessie ou superior, não terá problemas. Basta executar o comando abaixo:
# aptitude install docker.io

Caso não utilize GNU/Linux, pode usar o boot2docker.

Conhecendo alguns comandos básicos

Infelizmente o docker ainda não tem uma interface web ou gráfica desktop suportada de forma estável pela sua comunidade oficial, sendo assim falaremos aqui apenas de comandos no shell.

Segue abaixo os comandos mais básicos do docker:

docker pull [nome da imagem] : Baixar imagem
docker images : Listar imagens
docker run [nome da imagem] : Iniciar a imagem
docker ps  : Listar containers
docker exec [id do container] [comando] : Executa comandos no container

Mais comandos, podem encontrar nesse link.

Instalando uma máquina e executando em 2 minutos

Dois comandos, e o tempo gasto será apenas de download:

# docker pull nginx
# docker run -d -p 80:80 nginx


Pronto! Sua máquina estará funcionando.

O parâmetro -d, informa que a máquina será executada em background e o parâmetro -p informa que toda requisição da porta 80 no ip do hospedeiro, será redirecionado para a porta 80 da máquina que acabou de ser iniciada.

Sem persistência

Lembrando que as mudanças são apenas aplicadas no container, toda vez que desligar a máquina, na verdade você estará desmontando essa camada, e ao iniciar a máquina a partir de uma imagem será criado um novo container, ou seja, terás uma máquina “novinha em folha”.

É possível reiniciar um container que foi “desligado”. Usando o comando abaixo:

# docker start <id do container>


Obs: Lembrando que todos os dados de memória RAM serão perdidos, apenas os dados em disco serão armazenados e reutilizados na próxima execução.

Por hoje é só, aguardem novos artigos sobre Docker, pois falaremos sobre modificação de imagens, mapeamento de disco, criação de máquinas “do zero” e outras coisas interessantes sobre o docker.

Fonte : https://docs.docker.com/reference/

MuseScore 2.0 is great, try it!

A bit of context: two years ago I joined an undergraduate program in electroacoustic music composition at the Université de Montréal. Fortunately the faculty has decided to use mostly free software in the classes. They recently moved from Max/MSP to Pure Data to teach algorithmic composition. OpenMusic has been used for computer assisted composition classes. On acoustics classes, Sonic Visualiser is the recommended tool. For everything related to audio processing and sound synthesis we mainly use Python pyo library and Cecilia, both developed by the professor himself. Other many free softwares are used for building digital musical instruments in the courses: Arduino, SuperCollider, OpenCV, openFrameworks etc.

So far I touched two proprietary softwares for my classes. First it was Reaper, a sequencer which has been recently adopted in replacement of Pro Tools in some grades. Reaper has a less unfair distribution model compared to Pro Tools and despite being a closed piece of software it somewhat looks like a community-oriented project, being developed by a small team of free software enthusiasts. Being an amazing, complete and still lightweight DAW I hope it goes free some day in the future (I've read about this possibility somewhere in a forum that I can't find now). Anyway, after some months playing with Reaper I went back to Ardour. Because it's free, not because it's better (Reapper still seems unbeatable here).

The other was Finale, an alternative to MuseScore for music notation. I used it for three compositions mainly due to its playback capabilities. As a middle-aged music student I don't have the internal ear enough developed to listen orchestral textures, articulations and other details provided by expensive VST stuff. However, I found editing with Finale a pain in the ass. It's so bugged that I thought I were using a sort of alpha version. Basic editing is much more logical and elegant with MuseScore. After all, these first experiences with Finale didn't convince me that such realistic playbacks are adding any value to my music. I suspect that moving back to soundfonts or even composing with no playback at all will probably force me to exercice more critical/analytical listening whenever I need to understand the effects of a specific instrumental gesture and instrument combinations. So, I'm back to MuseScore. Not only because it's free, but also because it's better (at least for my current needs).

MuseScore has allowed me to easily edit music scores in a free operating system, using a small and not so powerful laptop. Unable to donate money to this amazing project I've been happily giving some time to it, by testing new releases, reporting issues, translating to portuguese and making available unofficial Debian packages while the current maintainer prepares the official one, which seems to be coming very soon. If you're a Finale/Sibelius user and don't strictly need that universe of orchestral VSTs samples for your music work, please give MuseScore a try. Have a quick look at its online handbook and in a few minutes you will be able to experience the real pleasure of music scoring using a computer. You can try different soundfonts, including the so nice Sonatina Symphonic Orchestra.

Below is a screenshot of MuseScore 2.0, which will be released very soon. You can download the RC version for your system in the MuseScore website.

MuseScore 2.0

Freeing myself from flickr

Não faça hoje o que pode deixar para amanhã

Neste post irei falar sobre gestão pessoal de tempo usando a técnica Do It Tomorrow (DIT), uma proposta de Mark Forster publicada em seu livro de mesmo nome traduzido para o português como Deixe para amanhã, o título deste post é uma provocação ao conselho pupular “Não deixe pra amanhã o que você pode fazer hoje”, que vai totalmente de encontro à proposto feita pelo autor em seu livro.

Desde 2009 venho utilizando a técnica DIT proposta no livro de Mark Forster, é uma técnica muito simples e eficiente, tomei conhecimento dela através do post 3 alternativas para o GTD — 7 Hábitos, Deixe para amanhã e Zen To Done de autoria de Rafael Perrone em seu blog fazendoAcontecer.net.

Neste post Rafael Perrone cita algumas alternativas ao Getting Things Done (GTD), uma técnica para organização pessoal de tempo bastante popular e também muito eficiente, ela propõe uma série de ferramentas diferentes, como lista de coisas a fazer, lista de algum dia/talvez, lista de próximas ações, e algumas outras, possui também um workflow bem elaborado para que funcione bem, isso tudo faz o GTD ter uma curva de aprendizado relativamente grande e exige um esforço mínimo de aprendizado antes de começar a ser efetiva, e foi exatamente isto que me desmotivou à utilizá-la e me fez ir em busca de alternativas.

Assim, em 2009, cheguei ao DIT, uma técnica extremamente simples, com praticamente zero esforço de aprendizado inicial, e desde então tenho utilizado ela para gerenciar todas as minhas atividades.

Por que eu estava à procura de técnicas para gerenciamento de tempo?

Desde 2006 eu venho trabalhando como autônomo, gerenciando meu próprio tempo, sem patrão, sem relógio de ponto, sem fiscalização, e sem todas essas artimanhas que as empresas criam para tentar fazer seus funcionários serem eficientes. Eu precisava de algo que me tornasse de fato eficiente, algo que fizesse eu usar o tempo da melhor forma possível, caso contrário os cronogramas iriam furar, as atividades iriam ficar para depois, a procrastinação iria rolar solta, e isso iria inviabilizar minha vida como autônomo.

Ao usar DIT consegui a eficiencia que procurava, mas é importante destacar que nenhum método ou técnica irá fazer milagres, o importante é ter disciplina e se esforçar para pôr algo em prática, qualquer método que funcione vale à pena, eu escolhi o DIT pela simplicidade, apesar de simples é preciso ter disciplina, e isto será necessário para qualquer outro método. Ler sobre o assunto ajuda bastante, e o livro de Mark Forster me ajudou muito neste sentido.

Mas, como funciona esse método afinal?

O autor do DIT basicamente propõe uma modificação em algo já conhecido por todos nós, a famosa lista de coisas a fazer, é aquela listinha que fazemos num pedaço de papel com tudo que precisamos fazer. Ela se parece mais ou menos com a imagem ao lado.

É uma listinha imensa, que nunca chega ao fim…

Acredito que todos nós já fizemos uma lista semelhante a esta ao menos uma vez na vida, Mark Forster sugere que transformemos esta lista de coisas a fazer em uma lista de coisas que serão feitas, a lista de coisas a fazer tende a crescer eternamente e nunca conseguimos terminá-la, isto causa a sensação de que o trabalho nunca é concluído, e esta sensação não ajuda a melhorar ou mesmo a manter a nossa auto-estima.

A lista de coisas que serão feitas deve ser elaborada diariamente, e não deve ser alterada ao decorrer do dia, idealmente deve ser feita com antecedência, ou ao menos antes de começar o trabalho. Não se deve adicionar itens de última hora, ou seja, aquela lista de terça-feira que planejei na segunda, não deve ser alterada durante o decorrer do dia. Ela é uma lista fechada, uma vez planejada, nada mais entra, se surgir algo novo, planeje para o dia seguinte, ou para a semana seguinte, isto vai depender da natureza da atividade e do seu planejamento pessoal.

O objetivo é sempre começar o dia com uma lista de atividades previamente planejada, ao final do dia ela deve estar concluída, uma lista por dia, nada de transferir a lista de hoje para amanhã, isto não vai funcionar! O que costumo fazer é usar uma agenda de papel, e a cada dia na data correspondente eu anoto minhas atividades.

Eu indico fortemente o uso da agenda de papel, com ela você pode anotar seus compromissos, reuniões, etc, e também sua lista de atividades, uma coisa está ligada à outra, se num certo dia você tem anotado uma reunião que dura a metade do dia, saberá que não poderá planejar tantas atividades nesta data, ter estas informações num mesmo lugar facilita a gestão.

Veja por exemplo minha lista de atividades (coisas a serem feitas) do dia 05 de Fevereiro de 2015.

Nesta lista eu marco um X ao finalizar a atividade, o objetivo de cada dia é marcar todas as atividades como finalizadas, neste dia em particular eu consegui finalizar todas elas (ufa!), o autor Mark Forster fala em seu livro dos benefícios emocionais relacionados à isto, quando conseguimos completar o dia, uma sensação de trabalho concluído, um sentimento de missão cumprida, bem diferente do que seria causado por aquela enorme lista de coisas a fazer que nunca termina.

Nem sempre é possível finalizar todas as atividades planejadas, quando isto ocorre marco um N na atividade e planejo ela imediatamente para outro dia, assim, mesmo que não complete o planejamento diário, não perco a atividade de vista. É importante notar que isto deve ser evitado ao máximo, se perceber que está sendo constante replanejar atividades, procure descobrir o motivo, talvez você esteja colocando muitas atividades no dia, ou talvez você esteja procrastinando, se for a segunda opção, cuidado, isto é um problema sério!

Bem, é nisso que a proposta Do It Tomorrow (DIT) se resume, uma simples lista de coisas a serem feitas (de fato) por dia, o mais importante é ter disciplina e praticar até ganhar o hábito de sempre planejar o seu dia de trabalho, e lógico, ter responsabilidade com o seu próprio planejamento e buscar cumpri-lo sempre.

O autor Mark Forster dá uma série de dicas para conseguir chegar lá, sugiro que você leia o livro dele, mas faça isso hoje, não deixe para amanhã! rs

rmail: reviving upstream maintaince

It is always fun to write new stuff, and be able to show off that shiny new piece of code that just come out of your brilliance and/or restless effort. But the world does not spin based just on shiny things; for free software to continue making the world work, we also need the dusty, and maybe and little rusty, things that keep our systems together. Someone needs to make sure the rust does not take over, and that these venerable but useful pieces of code keep it together as the ecosystem around them evolves. As you know, Someone is probably the busiest person there is, so often you will have to take Someone’s job for yourself.

rmail is a Ruby library able to parse, modify, and generate MIME mail messages. While handling transitions of Ruby interpreters in Debian, it was one of the packages we always had to fix for new Ruby versions, to the point where the Debian package has accumulated quite a few patches. The situation became ridiculous.

It was considered to maybe drop it from the Debian archive, but dropping it would mean either also dropping feed2imap and sup or porting both to other mail library.

Since doing this type of port is always painful, I decided instead to do something about the sorry state in which rmail was on the upstream side.

The reasons why it was not properly maintained upstream does not matter: people lose interest, move on to other projects, are not active users anymore; that is normal in free software projects, and instead of blaming upstream maintainers in any way we need to thank them for writing us free software in the first place, and step up to fix the stuff we use.

I got in touch with the people listed as owner for the package on rubygems.org, and got owner permission, which means I can now publish new versions myself.

With that, I cloned the repository where the original author had imported the latest code uploaded to rubygems and had started to receive contributions, but that repository was inactive for more than one year. It had already got some contributions from the sup developers which never made it in a new rmail release, so the sup people started using their own fork called “rmail-sup”.

Already in my repository, I have imported all the patches that still made sense from the Debian repository, did a bunch of updates, mainly to modernize the build system, and did a 1.1.0 release. This release is pretty much compatible with 1.0.0, but since I did not test it with Ruby versions older than than one in my work laptop (2.1.5), I bumped the minor version number as warning to prospective users still on older Ruby versions.

In this release, the test suite passes 100% clean, what always gives my mind a lot of comfort:

$ rake
/usr/bin/ruby2.1 -I"lib:." -I"/usr/lib/ruby/vendor_ruby" "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test*.rb"
Loaded suite /usr/lib/ruby/vendor_ruby/rake/rake_test_loader
Started
...............................................................................
...............................................................................
........

Finished in 2.096916712 seconds.

166 tests, 24213 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

79.16 tests/s, 11546.95 assertions/s

And in the new release I have just uploaded to the Debian experimental suite (1.1.0-1), I was able to drop all of the patches and just use the upstream source as is.

So that’s it: if you use rmail for anything, consider testing version 1.1.0-1 from Debian experimental, or 1.1.0 from rubygems.org if you into that, and report any bugs to the [github repository](https://github.com/terceiro/rmail). My only commitment for now is keep it working, but if you want to add new features I will definitively review and merge them.

Raspberry Pi Foundation moving away from its educational mission?