Este post é dedicado a quem utilizar Mac OS X (ou mesmo Windows) como sistema de desenvolvimento. Para quem usa uma distro Linux, adapte para usar o plugin de LXC do Vagrant.

A versão TL;DR é muito simples. Baixe e instale o VirtualBox e o Vagrant. Assumindo que está no OS X (já tem Ruby 2.0.0 pré-instalado), faça o seguinte do Terminal:

1
2
3
4
5
6
7
8
9
10
11
12
13
sudo gem install berkshelf
vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-omnibus

mkdir ~/Vagrant
cd ~/Vagrant
git clone https://github.com/akitaonrails/vagrant-railsbox.git railsbox
cd railsbox

export VAGRANT_SYNCED_FOLDER=~/Sites

berks install
vagrant up --provision

Em 2007 escrevi meu primeiro livro "publicado", sobre Ruby on Rails. Em 2006, comecei este blog. Mas essas não foram minhas primeiras experiências escrevendo.

Se acompanha meu blog viu que ontem publiquei um artigo sobre Segurança, onde falo sobre a importância do Backup. Imagine que minha rotina de backup vem de longa data. Eu já fazia backup quando tudo que eu tinha eram caixas de disquetes. E a cada nova geração de mídias eu transferia de uma para outra. Foi assim de disquetes para discos de zip drive, depois para CDs, daí para DVDs e finalmente para meu Drobo, como publiquei em 2009 e parte dele para Dropbox.

De vez em quando dou uma fuçada nesse backup e acabei de esbarrar num "livro" que escrevi quando era estudante do 3o semestre de Ciências da Computação na USP, em Maio de 1996! Aliás, o backup é datado de Maio de 1996, provavelmente eu escrevi isso antes!

Trecho

Fonte: The Road Ahead - Bill Gates

Se você ainda não usa Vagrant como ambiente de desenvolvimento e testes, vá já instalar o seu!

Em seguida, garanta que você está usando NFS para a máquina virtual acessar seus arquivos no seu HD de verdade na maior velocidade possível.

Finalmente, a dúvida que você pode ter é: usar Virtualbox, que é open source e gratuito ou comprar o VMWare Fusion Provider a caros USD 79 e mais a licença do VMWare Fusion pra Mac que vai te custar outros USD 59.99, para um total de USD 138.99 !!??

O problema é que você pode decidir que é caro demais e que o Virtualbox é suficiente, mas aí sempre que sentir algo lento vai ficar pensando "será que vale a pena pagar os quase USD 140?"

A resposta TL;DR é simples: NÃO, fique no Virtualbox. O VMWare pode até ser mesmo um pouco melhor, e certamente se você quer usar Windows e ter uma boa integração entre desktops gráficos e tudo mais, acho que vale o custo. Mas para a maioria de nós, desenvolvedores, o custo certamente não compensa, não pare de se sentir com dor na consciência e aprecie o Virtualbox.

Como sabemos, segurança é uma proposição de "tudo ou nada", não existe "meio protegido". Infelizmente, a única forma de ter certeza que seu dispositivo está 100% seguro é se ele estiver sempre offline e nunca se conectar a nenhuma rede, e que sua localização tenha segurança física (literalmente, numa jaula).

Ou seja, estamos sempre desprotegidos por padrão, parta desse princípio. O que podemos fazer é não facilitar o trabalho de quem quer invadir seus dados. Não deixe nada ao acaso, pois o máximo que vamos fazer agora é dificultar o trabalho dos outros.

Importante:

  • Este artigo parte do princípio que você está usando OS X Mavericks e que está constantemente baixando as atualizações de segurança.
  • Não falar muito de "redes sociais" e "SaaS", onde muito da sua privacidade já está comprometida, vamos falar de alguns aspectos mas tome cuidado com Engenharia Social, mais do que hackers remotos.
  • Não dá pra garantir que, depois de seguir todas as recomendações a seguir, seu Macbook está "garantidamente seguro", ele somente vai estar mais difícil de acessar, mas certamente um técnico mais motivado vai conseguir chegar onde ele quer.

A razão desse artigo é porque, por padrão, seu Macbook vem razoavelmente aberto, não oferecendo nenhuma dificuldade.

Ontem vi um tweet do @fnando falando de Firefox. Particularmente fiquei curioso sobre ele porque faz muito tempo que eu só uso primariamente o Safari e para algumas coisas uso Chrome (coisas de Google, como Hangout, principalmente, mas sem nenhum motivo particular pra isso).

Tipicamente, tenho cerca de 40 abas abertas no Safari. Vou lendo, salvando (se for interessante, no Pocket, ou tweetando ou compartilhando em algum lugar), e fechando. Daí, navegando no Feedly diariamente, acabo abrindo mais e com isso fica essa média de 40 a 50 abas abertas todos os dias. É de fato um fardo que meu Mac precisa lidar diariamente.

Sei que existem algumas coisas que provavelmente só vão funcionar direito no Chrome (coisas experimentais como WebRTC que o Google vai empurrando). O Safari teoricamente deveria ser o que está mais pra trás em termos de funcionalidades, mas das 40 abas que abri iguais nos 3, todos renderizaram os conteúdos sem nenhum problema.

Do ponto de vista de navegação, as abas do Chrome continuam sendo as piores. Odeio o fato dele ir comprimindo a aba até ficar só o favicon e não ter por padrão uma lista das páginas abertas. O Safari e o Firefox tem abas muito mais úteis (e é uma das razões de porque eu abro muitas abas no Safari e não no Chrome). Uma curiosidade é que mudar de abas com shortcut (Cmd+]) é mais rápido no Firefox, em segundo no Safari e bem em terceiro no Chrome. Se eu deixar o shortcut apertado pra ele mudar de abas bem rápido, o Firefox mostra o conteúdo rapidamente. O Safari dá um ligeiro "flick", uma piscada em branco antes de dar refresh e o Chrome praticamente não mostra conteúdo algum, não dá tempo de dar refresh antes de mudar de aba de novo. Achei isso interessante, pessoalmente o Firefox pareceu visivelmente mais responsivo do que os outros.

Neste small bite, começo repetindo a mesma coisa que os seguintes posts do próprio Heroku já explicam:

Sugiro que vocês leiam os dois artigos acima com atenção, para aprender coisas como calcular quantidade de conexões que sua aplicação vai precisar, monitorar quantidade de conexões e muito mais. Em resumão, em todo projeto Rails, na dúvida, garanta que você tem o seguinte:

Diferente dos meus longos posts TL;DR, quero experimentar um tamanho mais 'small bites'.

Vocês devem ter notado que em todo post do meu blog tem uma lista ao final organizando todos os links que eu espalho por todo o texto, assim você pode ir direto até lá se quiser se lembrar de um link, em vez de ter que reler o texto todo.

Para fazer isso eu implementei um simples before_save no meu model de Post onde eu vasculho o texto para buscar todos os links, desta forma:

Um dos mais conhecidos rubistas de nossa comunidade brasileira, Eustáquio Rangel acabou de lançar um bom ebook direcionado para quem quer começar com Rails. Conhecendo Rails. E por apenas USD 15, deixe-me dizer, é uma pechincha.

A intenção deste post é fazer um pequeno review deste livro e aproveitar para linkar mais material que vai te ajudar a ir adiante neste aprendizado.

Por acaso, o livro do Taq tem o mesmo perfil do Agile Web Development with Rails pois ele usa o desenvolvimento de um pequeno aplicativo de loja virtual como base. Obviamente, não será uma loja virtual completa e complexa para ser substituto de um Magento ou Spree Commerce mas serve para exercitar os principais conceitos do framework.

Uma coisa que gosto da linha do Taq é que ele se ateve ao stack básico do Rails. Por exemplo, todos os exemplos de código usam exclusivamente o Test/Unit do próprio Rails em vez de ir direto pra Rspec, incluindo funcionalidades como Fixtures em vez de ir pra FactoryGirl. Eu acredito que o melhor é usar o que vem já no Rails e depois evoluir pra RSpec, FactoryGirl ou Fabrication.

O livro começa explicando os conceitos mais copiados do Rails como "Don't Repeat Yourself" e o famoso "Convention over Configuration", que são as bases de um bom framework produtivo hoje em dia. Logo em seguida começa criando a estrutura da aplicação e indo para conceitos como Migrations, Asset Pipeline, Testes, ActiveSupport. Dali em diante ele expande sobre a aplicação apresentando funcionalidades como Rotas Restful, Views e Layouts, Associação de models do ActiveRecord. Finalmente, avança para conceitos um pouco mais complicados para quem está iniciando como Upload de Arquivos, Caching, Deploy. E no fim do livro ele lista outras coisas fora do framework que usamos nos projetos como Minitest, Guard, Capybara, FactoryGirl, Papertrail, e outros.

Para quem nunca viu o framework, o livro é excelente por apresentar as principais funcionalidades e dar exemplos dos aspectos essenciais.

Esta semana um conhecido desenvolvedor da comunidade Node.js declarou estar deixando o barco. Foi TJ Holowaychuk, um dos mais prolíficos contribuidores dessa comunidade. Obviamente isso deve ter gerado alguma controvérsia e discussões e gente se desesperando.

Se você é um programador experiente, certamente não precisa de mim para ouvir isso. Mas se por acaso você ficou inseguro com as notícias recentes, talvez o que eu tenha a dizer lhes dê perspectiva.

Antes, quero compartilhar com vocês outros artigos que li poucos dias atrás:

  • My Next Chapter - eu achei que isso fosse gerar alguma discussão extra, mas é a declaração e Mike Perham, um dos mais conhecidos rubistas desta geração e criador do ubíquito e excepcional Sidekiq declarou não que está abandonando o projeto ou algo assim, mas que está trabalhando num novo produto e que ele não envolve Ruby.

  • Saying Goodbye To Python - neste caso foi o pythonista Ian Bicking, que declarou deixar o Python pelo Javascript, seguindo a onda atual. Importante entender que a bolha de Javascript atual não "requer" você "deixar" nada por ele. Novamente o caso em que você pode tranquilamente ser pythonista e usar javascript, não há conflito.

  • Why I Left the .Net Framework - um certo desenvolvedor chamado Jonathan Oliver resolveu também declarar porque está deixando sua tecnologia do dia-a-dia e aponta os pontos positivos e negativos das tecnologias Microsoft. Não é um troll, é até uma leitura bem interessante.

  • Java Again - quem é das primeiras gerações da comunidade Java não deve ter se esquecido de James Duncan Davidson, criador de nada menos do que o primeiro Tomcat e Ant. Ele deixou a comunidade Java, integrou a comunidade Ruby temporariamente, dedicou-se à fotografia (quem procurar por fotos das Rubyconf de 8 anos atrás vai ver as oficiais são todas dele). E agora declarou que está retornando ao Java.

  • Why Go Is Not Good - como o nome diz, é uma crítica de porque uma linguagem recém-lançada deveria ter sido melhor pensada para cobrir casos que outras linguagens já cobrem.

  • Rust vs Go - novamente, tem um certo apelo de "dor de cotovelo", no sentido de que Rust realmente parece ser uma tecnologia superior a Go em termos de design de linguagem e funcionalidades, e demonstra certa frustração de porque mesmo assim Go é mais popular.

  • Why Perl Didn't Win - é uma leitura obrigatória para observar circunstâncias de uma das linguagens mais populares desde o final da década de 80 até o final da década de 90, que caiu em esquecimento e desuso. Até mesmo o Swift, lançado pela Apple semanas atrás, já tem mais usuários ativos do que o Perl 6. Uma das conclusões? Qualquer coisa nova precisa almejar resolver os problemas do futuro, não os do passado.

Existe uma nova celebridade na cidade, e seu nome é "Web Components". Ultimamente muitos apresentam esta nova tecnologia como o 'Santo Graal' que vai resolver todos os problemas da Web. Este artigo não é um apoio incondicional, não é uma crítica negativa irrefutável, mas meramente uma apresentação de perspectivas com o objetivo de dar clareza. Nenhuma discussão pode funcionar onde os gritos mais altos são simplesmente "Isso vai revolucionar a Web!" (sem explicar porque) ou "O Google e a Mozilla estão por trás então é foda!" (sem comentários).

Do ponto de vista puramente técnico é muito simples entender o que é um "Web Component". Ele é o conjunto de 4 tecnologias de navegadores web.

  • Custom Elements
  • HTML Imports
  • Templates
  • Shadow DOM

Colocando em ordem de importância, eu resumiria da seguinte forma:

  • Custom Elements - permite criar tags diferente dos canônicos como "body", "input" e evitar o classes-hell ou div-hell onde tudo é um punhado de divs dentro de divs criando os horrendos macarrões de tags. A idéia é encapsular tudo dentro de tags simples e mais fáceis de manusear.
  • Shadow DOM - para o fator encapsulamento, precisamos primeiro conseguir eliminar o sangramento de estilos e comportamentos por tudo que existe numa página. Shadow DOM permite criar trechos de nós de elementos de DOM que são independentes e isolados entre si, onde o estilo de um trecho não interfere com outro. Somente o Chrome e Firefox mais novos suportam isso. WebKit/Safari deixou de suportar a implementação incompleta que tinham (mas talvez voltem) e o IE, para variar, nunca nem tentou implementar isso. Para funcionar na maioria dos navegadores existem projetos como o Polymer/Platform e X-Tag para servir como "polyfill" para navegadores legados.
  • Templates - como o nome diz, para criar componentes dinâmicos, é importante ter trechos de DOM inertes, diferentes de somente uma string, para conseguir manipular e instanciar conforme necessário. Por exemplo, linhas de uma tabela dinâmica. Existem várias bibliotecas de templates, como Mustache, mas para Web Components funcionar, era importante ter um padrão.
  • HTML Imports - e uma vez tendo um trecho de DOM isolado, com estilos e comportamentos independentes de outros componentes, agora precisamos empacotar isso. E para isso servem esses imports que basicamente é um arquivo HTML que declara os arquivos CSS e Javascript que ele depende, e o HTML Import sabe como carregar tudo de uma vez. Aqui fica uma das minhas maiores preocupações - que vou tentar explicar mais para o fim.

Depois do Google I/O 2014 apresentando a nova linguagem de interface unificada "Material Design" espero que desenvolvedores de Android implementem em seus aplicativos o quanto antes. Acredito que o Android L será uma excelente nova versão, seguindo de onde o Holo no KitKat ficou.

Em paralelo, o Google implementou a mesma UI para aplicações Web com o Polymer, usando a nova possível tendência de Web Components. Aprenda sobre custom elements, shadow DOM, HTML imports, web animations.

Depois do Google I/O imagino que muitos vão querer fazer pelo menos aplicações web mobile parecidas com o Topeka - aliás, Topeka pode ser o novo "Hello World" de aplicações web responsivas.

O Polymer usa muitas funcionalidades novas que apenas os Chrome e Firefox mais recentes realmente implementam, o resto vai polyfills. Mesmo assim a compatibilidade ainda não é 100%, especialmente para Internet Explorer, obviamente, e Safari, surpreendentemente (que é mais relevante pois não só deixa OS X um nível pra trás, mas pode dificultar Web Components em dispositivos iOS por enquanto).

Isso tudo dito, imagino que muitos queiram integrar esse novo tipo de interface em sua aplicações Rails. Uma coisa que de cara me deixou um pouco nervoso é o fato de que cada Web Component é um trecho de HTML, e cada um deles tem seus próprios imports de CSS, Javascript. Em Web, isso é horrível pois significa que se você tem 10 web components, cada um com 2 CSSs cada, só isso já significa 10 + 10 * 2 = 30 requisições para puxar assets.

Se tem uma coisa que nós rubistas estamos muito acostumados e gostamos bastante são closures, blocos ou fechamentos. Expliquei esse mecanismo pela primeira vez em 2007 aqui no blog, então se ainda não conhece bem o conceito, releia meu post.

Em 2010 a Apple adicionou a funcionalidade de closures ao Objective-C também e modificou muitas de suas APIs para aproveitar esse recurso. Também postei sobre isso 3 anos atrás, então releia meu post para aprender sobre isso.

Finalmente, Swift é basicamente Objective-C melhorado então temos o mesmo recurso.

Como vocês devem ter assistido no keynote de abertura da WWDC 2014, a Apple lançou uma nova linguagem, mais moderna, para substituir o Objective-C como linguagem padrão para desenvolvimento de aplicações tanto OS X quanto iOS. Não se trata de uma nova "camada" mas uma linguagem que tecnicamente compila para o mesmo tipo de binário que o próprio Objective-C e mesmo C. Graças ao compilador que é implementado sobre LLVM isso se torna possível.

A linguagem Swift é um Objective-C com funcionalidades mais modernas e uma sintaxe mais elegante e menos verbosa. Já havia publicado neste blog anos atrás como o Objective-C e Ruby tem conceitos muito similares. E isso se deve à herança comum da linguagem Smalltalk.

Antes que algum afobado comece a trolar: o artigo não tem como objetivo dizer que Swift tem inspiração em Ruby ou que Ruby tem algum tipo de relação com Swift. Apenas aproveitando o fato de terem origens similares e funcionalidades que fazem sua programação ser próxima, quero usar o artigo para mostrar a rubistas algumas nuances do Swift.

Todos os exemplos de código foram extraídos do eBook “The Swift Programming Language.” que é uma boa introdução à linguagem. Mas para realmente tirar proveito é melhor conhecer a fundo Objective-C, C e obviamente, toda a documentação de APIs dos frameworks para iOS e OS X.

O assunto segurança é bem complicado, este post não tem a intenção de ser a fonte completa de tudo relacionado a segurança no mundo Ruby on Rails mas apenas listar algumas informações e ferramentas úteis. Antes de começar alguns links importantes que, se você ainda não conhecia, precisa ter nos seus favoritos:

  • Ruby on Rails Security Guide - este é o guia oficial básico sobre as diversas brechas de segurança que o Rails, por padrão, já previne mas que você pode desativar acidentalmente. É o "Hello World" da segurança, como Session Hijacking, CSRF, SQL Injection, XSS, etc.

  • Ruby on Rails Security Group - este é o grupo oficial de segurança. Toda vez que uma nova vulnerabilidade é corrigida é aqui que primeiro aparece seu anúncio e você pode avaliar os detalhes para saber se precisa atualizar sua aplicação imediatamente ou não.

  • Brakeman - como disse antes, você pode se descuidar e deixar passar um string com interpolação que pode causar um SQL Injection, por exemplo. Para evitar isso execute este scanner de tempos em tempos. O Code Climate implementa o Brakeman para dar as mesmas métricas de brechas de segurança.

  • RubySec - mantém um banco de dados de vulnerabilidades não só do framework Ruby on Rails mas de diversas Rubygems que usamos todos os dias. E daqui vem uma das ferramentas que vou sugerir neste artigo.

Aliás, um comentário sobre o termo. Nunca se pode dizer "minha aplicação está segura", o máximo que podemos dizer é "minha aplicação parece não ter nenhuma vulnerabilidade conhecida." Só porque você não conhece, não significa que as vulnerabilidades não existam, e as chances são que existam e você simplesmente a ignora. O único tipo de aplicação "segura" é aquela que está completamente off-line numa localização geográfica desconhecida em um bunker anti-nuclear. Tirando isso, qualquer outra coisa é "quebrável".