Configurando teclado da Apple no Ubuntu

Esta semana eu vendi meu Mac Mini e voltei a usar o Ubuntu como sistema operacional para trabalhar. Continuei utilizando o teclado do Mac, e encontrei alguns problemas:

Problema de acentuação

Tive um problema para fazer o teclado do Mac funcionar no Ubuntu, para corrigir os problemas de acentuação foi só alterar o idioma do teclado (keyboard layout) para “English (US, alternative, international)” – mas isso pode mudar de acordo com o seu teclado.

Teclado numérico

Problema de acentuação resolvido, o segundo problema foi que o numlock não estava ligado – mas descobri que o botão “clear” (em cima do numpad) ativa e desativa o teclado numérico.

Teclas function sempre ativa (F1, F2, etc não funciona)

Um comportamento estranho foi que sempre qualquer tecla Fx (onde x é qualquer número) era pressionada o teclado executava a função (fn) da tecla, como aumentar volume, pausar música, etc.

Para utilizar a tecla “normal”, sem as funções de mídia eu tinha que pressionar a tecla fn.

Você pode resolver este “comportamento estranho” criando um arquivo de configuração para o teclado, se trata da opção “fnmode” do teclado. A opção fnmode pode ter 3 valores (0, 1 ou 2) e funciona da seguinte forma:

0 = Pressionar fn+F1 vai ser o mesmo que pressionar F1.

1 = Pressionar F1 vai executar a ação especial do F1. Pressionar fn+F1 vai executar a função do F1

2 = Pressionar F1 vai executar a função esperada para o F1. Pressionar fn+F1 vai executar a função especial do F1 (o comportamento esperado na maioria dos casos).

Vamos configurar, execute no terminal:

echo options hid_apple fnmode=2 | sudo tee -a /etc/modprobe.d/hid_apple.conf

Ou adicione (crie, se precisar) a configuração do fnmode=2 no /etc/modprobe.d/hid_apple.conf.

Agora é só fazer seu novo arquivo de configuração ser carregado:

sudo update-initramfs -u -k all

Problema resolvido, agora você pode usar o seu teclado do Mac no Ubuntu sem quebrar a cabeça para usar os F´s!

Se você  programa no Ubuntu, leia também:

Mais informações no Help Ubuntu (en)

Customização de CSS com Compass

Trabalhar com componetização do HTML e CSS significa mais qualidade no código e muito mais produtividade no longo prazo.

Já escrevi algumas vezes aqui sobre este assunto, um dos que causaram bastante debate foi sobre CSS orientato a objetos – mais debate pela nomenclatura do que pela metodologia em si.

Este ano tive o prazer de palestrar no Front in Sampa 2013 e falei um pouco sobre componetização de HTML e CSS utilizando o Compass, uma ferramenta extraordinária que vale a pena ser estudada.

A popularização de frameworks como o Bootstrap tornaram mais fácil este tipo de metologia, pois já temos a segmentação da estrutura e trabalhar com a customização visual dos componentes fica bem mais fácil. Aproveitar este conhecimento de arquitetura de front-end destes projetos e trazer para dentro da sua empresa pode ajudar muito na produtividade da equipe.

Abaixo os slides da minha apresentação sobre este assunto:

[slideshare id=28678434&doc=componetizacaodecsscomcompass-131127102153-phpapp02]

E aí, vamos componetizar?

Resolvendo o problema de locale no EC2

Tenho algumas instâncias no EC2 da Amazon e todas utilizam Ubuntu Server. E todas tinham um problema com language, o que me impedia de abrir o terminal do MongoDB por exemplo, ou exibia os avisos abaixo em algumas instalações:

WARNING! Your environment specifies an invalid locale. This can affect your user experience significantly, including the ability to manage packages.

perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

    LANGUAGE = (unset),

    LC_ALL = (unset),

    LC_CTYPE = "de_DE.UTF-8",

    LANG = "en_US.UTF-8"

    are supported and installed on your system.

perl: warning: Falling back to the standard locale ("C").

locale: Cannot set LC_CTYPE to default locale: No such file or directory

locale: Cannot set LC_ALL to default locale: No such file or directory

O problema é não ter um locale definido, eu já tentei várias coisas, a maioria dos tutorias mandava eu fazer o seguinte:

sudo locale-gen fi_FI.UTF-8
sudo dpkg-reconfigure locales

Isso, teoricamente, resolve o problema porém ele voltou acontecer em todas as instâncias, e ter que repetir o processo não é o que chamo de solução.

O que realmente resolveu meu problema foi editar o arquivo /etc/environment e adicionar a seguinte linha:

LC_ALL="en_US.UTF-8"

Agora, sempre que a instância iniciar ela terá o LC_ALL definido, resolvendo o probelma com o locale inválido.

Tutorial – deploy com git no Ubuntu Server (AWS EC2)

Semana passada configurei um servidor novo para um cliente (GS Solutions) e optamos por usar AWS para este projeto (leia meu comparativo entre Locaweb e Amazon) e fiquei encarregado de configurar o servidor.

O servidor será exclusivo para um projeto e optei por fazer todos os deploys com git para manter o controle do código que vai para o ar e automatizar o deploy. 

Já fiz isso para o And After e para o Eu Compraria e lembro que foi um pouco complicado permitir o git pull através do apache (usuário www-data no Ubuntu Server).

Mas uma vez feito, não tem erro. este é um tutorial de 4 passos simples para configurar seu servidor e permitir deploy utilizando o Git.

O tutorial foi testado em servidor Linux (Ubuntu Server) e pode precisar de ajustes simples para outros servidores.

1. Instale o git no servidor

Sem nenhum mistério:

sudo apt-get install git

2. Crie uma chave para o user www-data

Aqui está o segredo de permitir o deploy diretamente por comandos do Apache, que utiliza o usuário www-data.

No meu caso o deploy é feito através de um ambiente fechado do sistema, onde através do PHP o git pull é executado. O repositório em questão será onde está configurado o domínio do serviço, então quando o pull é executado na branch master acontece o deploy.

Para criar uma chave ssh para o user www-data você vai precisar executar o ssh-keygen com este usuário, para isso execute no servidor:

sudo -u www-data ssh-keygen

E gere uma chave para este usuário, com ou sem senha. Na home deste usuáriuo (no Ubuntu Server a home do usuário www-data normalmente é /var/www/) você terá uma pasta .ssh onde ficarão as chaves.

3. Libere as chaves no seu repositório

Agora é só cadastrar as chaves no seu repositório para que seu www-data do servidor tenha acesso ao repositório, no terminal do servidor digite:

vi ~/var/www/.ssh/id_rsa.pub

Cadastre a chave pública no seu repositório e pronto, você está pronto para acessar seu repositório diretamente do seu servidor.

4. Clone o repositório

Agora no seu servidor você pode executar os comandos do git com o usuário www-data, por exemplo:

sudo -u www-data git clone meurepositorio.git

Lembre-se que para automatizar o seu deploy o domínio configurado no Apache (sites available) deve ser o seu próprio repositório.

Para fazer o deploy você pode escolher a forma que achar melhor. Eu executo os comandos com a ajuda do PHP em um ambiente fechado: assim o php (www-data) executa o git pull no repositório do seridor.

Não sei se existe (e qual é) o risco do user www-data ter uma chave pública cadastrada no repositório, mas o ideal é que este usuário tenha acesso apenas de leitura no seu repositório.

Leia também mais algumas dicas e utilidades para seu servidor:

Web Workers FTW!

Como todos sabemos, paralelismo sempre foi um problema quando estamos falando de JavaScript. Porém, com a Web Workers API a situação muda. Vamos conhecer essa oitava maravilha do mundo!

Imagine a seguinte situação: uma página onde você carrega um plugin de slideshow, autenticação com Facebook e load de dados através de JavaScript, entre outra carralhada de arquivos. Comum, certo? Agora me diga, quantas vezes você teve problema com botões que não respondiam aos seus eventos? Nenhum? Ok. Quantas vezes essa aplicação gerou um crash no navegador?

Se você já enfrentou os problemas que citei acima, keep calm, você não está 100% errado. Cada vez mais, nós desenvolvedores, estamos fazendo aplicações que exigem trabalho pesado usando JavaScript. Pensando nisso, eis que surge a oitava maravilha do mundo, Web Workers API, que usa mais de um processo para executar tarefas JavaScript paralelamente.

O que é paralelismo

Vamos à uma rápida explicação. Caso você já esteja ligado no assunto, pule para o próximo tópico.

Paralelismo, ou melhor, Programação Paralela, é a forma com que conseguimos fazer um algoritmo executar diversas tarefas usando mais de um processo, thread, ou no nosso caso, workers! Tudo isso com o intuito de ganhar mais performance. Não entendeu? Beleza. Uma imagem fala mais do que mil palavras:

Web Workers, como funciona

Se interessou por Programação Paralela? Ainda não entendeu? Aí vai uma boa referência: https://computing.llnl.gov/tutorials/parallel_comp/.

Como funciona

Atualmente é possível executar eventos de forma assíncrona usando setTimeout(), setInterval(), XMLHttpRequest entre outros hacks (ok, chutem-me). Porém, isso não quer dizer que é paralelo, sendo que os eventos são executados quando o script é renderizado.

Web Workers trabalham de forma diferente. E melhor. Como JavaScript não é uma linguagem que usa multi-threads, os Workers de certa forma “estendem-a” em alguns casos, possibilitando executar tarefas com mais uma thread. A API define que processos serão executados de forma assíncrona em outro contexto, por scripts que se comunicam através de mensagens que são passadas pelo método postMessage().

Mãos à obra

Para não sair da tradição (risos), vamos à um “Hello World”.

Como Web Workers executam paralelamente de forma isolada ao processo principal, vamos criar um novo arquivo que receberá a “ordem” desse processo e executará sua função. No nosso exemplo, chamei de worker.js e possui a função abaixo:

// recebe a mensagem do processo principal
onmessage = function(event) {
  var message = event.data;
  var result = message + ' no And After!';
  postMessage(result);
}

Feito isso, vamos criá-lo no processo principal:

var myWorker = new Worker('worker.js');

Para passar nossa informação, precisamos do método postMessage():

var message = 'Web Workers';
myWorker.postMessage(message);

E para finalizar, precisamos receber a mensagem do Worker:

// Recebe a mensagem do worker
myWorker.onmessage = function(event) {
  alert(event.data);
};

Se não quiser fazer na mão, é só baixar o exemplo aqui. Ou, você pode ver uns exemplos nesse link.

PS: isso não vai rodar localmente por restrições dos browsers modernos. Então, para aproveitar a trégua, aproveito para explicar que, como workers são arquivos externos, não será possível carregá-lo através de scripts que começaram com http:. Para ver esse exemplo funcionando, clique aqui.

Leia mais sobre segurança em http://www.html5rocks.com/en/tutorials/workers/basics/#toc-security

Talvez você esteja pensando “porr*, pra quê tanta enrolação para escrever uma mensagem na tela?”. Calma lá. Web Workers servem para auxiliar em tarefas porradas, como renderização 3D, cálculos que exigem mais desempenho, etc.

Importante: caso você não tenha percebido, o nosso exemplo não acessa o DOM diretamente. Web Workers não tem acesso ao DOM!

Além do DOM, Web Workers não tem acesso aos objetos window, document e parent. Mas calma, apesar disso, Web Workers tem acesso aos seguintes recursos do JavaScript:

  • navigator com quatro propriedades: appName, appVersion, userAgent e platform.
  • location (somente leitura)
  • self, que aponta para o objeto worker global
  • importScripts() para fazer load de um JavaScript externo
  • todos os objetos do JavaScript, como Object, Array, Math, etc
  • XMLHttpRequest
  • setTimeout()/clearTimeout() e setInterval()/clearInterval()
  • há também um método close() usado parar um Worker

Conclusão

Web Workers é algo novo, logo, a API pode mudar a qualquer hora, e pra melhor. Acredito que eles irão além do browser. Isso é só o começo, e já é demais!

Referências: