Fabrício Tavares de Oliveira

Lines of Code

2013-10-29T00:00:00+00:00

Lines of Code

Atualmente uso o seguinte para ver o tamanho dos meus projetos:

git ls-files | xargs cat | wc -l

.mongorc.js

2013-09-27T00:00:00+00:00

.mongorc.js

Para não ter que ficar sempre digitando db.collections.find().pretty() no mongo shell, basta criar o arquivo $HOME/.mongorc.js e adicionar:

DBQuery.prototype._prettyShell = true

Node dependency

2013-09-05T00:00:00+00:00

Node dependency

npm install dependency --save

Instala a dependência e salva no arquivo package.json.

Meetup - Visualização de Dados e d3.js

2013-09-04T00:00:00+00:00

Meetup - Visualização de Dados e d3.js

Ontem, 3 de setembro de 2013, aconteceu o primeiro meetup sobre d3.js de Belo Horizonte (do Brasil?) e contou com a presença de onze pessoas. Fiquei bem satisfeito. Apesar do foco ser d3.js, o objetivo do meetup foi reunir pessoas interessadas no lado mais técnico de visualização de dados.

Foi bacana ver pessoas com formações diferentes interessadas no tema — algumas já trabalhando na área, outras querendo começar a trilhar esse caminho. Acredito que demos um pequeno passo para a construção de uma comunidade de visualização de dados no país.

Mas afinal, o que é um meetup?

Um meetup é um encontro local, organizado pelos participantes, que pode ter qualquer tópico como tema, onde um dos objetivos é compartilhar conhecimento.

Participar de um meetup permite que se conheça, face a face, outras pessoas que tem interesses em comum. Foge um pouco da "frieza" de fóruns e grupos de discussão, além de permitir uma informalidade maior.

E agora?

Visualização de dados não é um campo novo ou "moderno". No século XVIII William Playfair já criava visualizações.

Nos últimos três/quatro anos, entretanto, houve um crescimento exponencial na visibilidade e no número de pessoas dedicando ao estudo e à prática da criação de "gráficos bonitos". Explodiu a quantidade de material disponível sobre o tema: de posts em blogs à livros publicados.

Em português? Praticamente nada.

O meetup é um bom ponto de partida para começar a movimentar um campo que, até o momento, anda meio desconhecido de brasileiros que, no fundo, "precisam" de visualização de dados no dia a dia.

Espero poder contribuir, juntamente com os demais participantes do meetup d3js-BH, com o crescimento do uso de técnicas, conceitos e ferramentas que auxiliem a retirada de informação dessa massa cada vez maior de dados.

Tem interesse em participar? Confere lá a data do próximo encontro!

Podcast

2013-08-28T00:00:00+00:00

Podcast

Vez ou outra, quando comento com amigos sobre algo que ouvi em algum podcast, a reação é quase sempre a mesma: "que que é isso? Podcast?!oO?"

O que é, afinal?

Podcasts são programas de áudio, frequentemente episódicos, distribuídos em formato mp3. Existem podcasts sobre os mais diversos assuntos, que variam tanto em "densidade" do conteúdo abordado, quanto em tempo; é comum encontrar podcasts de 2min à 2h. Quer aprender francês? Tem. Design? Tem também. Quer saber sobre baratas? Yep.

Se quiser saber um pouco mais, confere na Wikipedia: Podcast e Podcasting.

O que ouvir

Acredito que o tempo que gastamos em deslocamento, seja dentro de carro, ônibus ou a pé, deve ser melhor aproveitado. Alguns gostam de ouvir música no rádio, outros aproveitam pra ler (dor de cabeça, alguém?) ou cochilar. Eu não vejo forma melhor de valorizar essas horas do que ouvindo algum programa interessante, aprendendo algo novo, ou simplesmente dando risada.

Ao longo do tempo fui descobrindo novos programas e abandonando outros tantos. Atualmente consigo preencher todo o tempo que gasto dentro do carro ouvindo à algum episódio. Abaixo segue a lista dos que, por enquanto, estão na estante (em ordem alfabética).

Como acompanhar

É difícil, pra não dizer impossível, acompanhar tantos programas simplesmente acessando os sites, verificando se tem algo novo, e fazendo os downloads dos episódios. Então é comum a utilização de algum aplicativo, para celular ou PC, que faça a gestão dos podcasts. Quando tem algo novo, o aplicativo avisa e, dependendo da configuração, faz o download automaticamente.

Ainda não estou satisfeito com o que tenho usado, mas atualmente uso o Podkicker (Android) e o RSSRadio (iOS) — o padrão da Apple para iPhone e iPod Touch, o "Podcasts", trava demais.

Ouve algum podcast bacana, que não está na minha lista? Qual?

Ah, se souber de aplicativos melhores do que os que eu citei, dá a dica!

Precompilando templates Handlebars para aplicações Ember.js

2013-05-31T00:00:00+00:00

Precompilando templates Handlebars para aplicações Ember.js

O Ember.js utiliza, como padrão, o Handlebars para especificações de templates JavaScript. É possível utilizar outras formas de templating client-side, mas perde-se uma infinidade de vantagens já existentes, como helpers e bindings.

Quando o tamanho da aplicação não é maior do que alguns routes (diria algo em torno de 5), podemos facilmente lidar com todos os templates da seguinte forma:

<script type="text/x-handlebars" data-template-name="application">
Esse é o template padrão.

{{ outlet }}
</script>

Ao integrar mais funcionalidades no Web App, consequentemente aumentando o número de templates, esse modelo fica estremamente difícil de manter. Não é difícil chegar a mais de 100 templates em um Web App comercial. Quando isso acontece, precisa-se de uma forma de manter a ordem, e uma saída interessante (diria obrigatória) é a precompilação dos templates que serão utilizados. Dessa forma consegue-se separar cada template em um arquivo (criando uma estrutura mais fácil de entender e manter), e aumenta-se a performance da aplicação, já que, quando requisitado, o template já estará pré-compilado. Além disso, só é necessário colocar o runtime do Handlebars como dependência, que na versão 1.0.0-rc.4 tem apenas 10kb (60kb a menos do que a versão com o compilador embutido). Ok, mas como fazer? Se você já está familiarizado com o [Node.js][nodejs], basta instalar o pacote [em-hbs-precompiler][em-hbs-precompiler].

  npm install -g em-hbs-precompiler

A utilização é extremamente simples. Informa-se o diretório onde estão os templates, e o nome do arquivo que conterá os templates compilados.

  precompilehbs -s diretorio/com/os/templates/ -o compilados.js

Pronto. Agora todos seus templates estarão pré-compilados e com nome correto.

Caso haja sub diretórios no seu diretório de templates, a nomeação será como padrão do Ember.js: resource ou, em caso de templates em subdiretórios, resource/route.

Dúvidas ou sugestões, coloque aí nos comentários!

Usando uma instância EC2 como git

2013-05-20T00:00:00+00:00

Usando uma instância EC2 como git

Provavelmente você, assim como eu, já abandonou ftp e scp em favor de uma forma bem mais eficiente e, porque não, elegante de subir arquivos para o servidor.

Caso nunca tenha ouvido falar do Git, recomendo o Git Immersion.

Se você ainda está se acostumando ao GitHub e ainda não possui uma conta paga — o que permite respositórios privados, ou se simplesmente não precisa de muitos repositórios privados, acho interessante

Na Instância Amazon

Configurando o repositório na instância (usado e testado no Debian):

mkdir project.git
cd project.git
git --bare init

Caso apareça essa mensagem de erro:

fatal: GIT_WORK_TREE (or --work-tree=) not allowed without specifying GIT_DIR (or --git-dir=)

Basta checar algumas variáveis de ambiente:

env|grep GIT

e "unset" elas:

unset GIT_WORK_TREE

Onde project.git é o nome do diretório do seu projeto.

Crie um post-receive hook:

cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/home/admin/git/ansee.git
export GIT_WORK_TREE
git checkout -f

Na máquina local

Adicione a chave pública que você usa para se conectar à instância EC2 para o path correto:

ssh-add /path/da/sua/chave.pem

Crie o diretório local:

mkdir project
cd project
git remote add origin ssh://admin@/home/admin/project.git

Para o primeiro commit, faça

git push origin +master:refs/heads/master

Para todos os outros:

git push origin master

Dúvidas? Só colocar nos comentários.

Ember.js snippets para Sublime Text 2

2013-03-25T00:00:00+00:00

Ember.js snippets para Sublime Text 2

Considero o Sublime Text 2 o melhor editor de texto atualmente para trabalhar com JavaScript e Python. Resolvi, então, disponibilizar os snippets de Ember.js que utilizo atualmente como um plugin para o Sublime Text 2.

No Mac OS, o atalho para instalação do plugin é shift + command + p, depois Package Control: Install Package, e aí é só buscar por Ember.js Snippets. Se você ainda não tem o Package Control, você pode baixá-lo aqui.

A lista dos snippets pode ser encontrada no repositório no GitHub. Se utiliza algum outro snippet com frequência, sinta-se livre para forkar o repositório!

Dúvidas ou sugestões, coloque aí nos comentários!

Estrutura

2013-02-22T00:00:00+00:00

Estrutura

Convenções de Nomenclatura no Ember.js

2013-02-21T00:00:00+00:00

Convenções de Nomenclatura no Ember.js

Muito do que o Ember automaticamente faz por você depende dos nomes utilizados para classes, objetos e properties. Portanto, é fundamental conhecer a forma que o Ember espera encontrar tais nomes. Vamos lá.

Classes

Todas as classes devem ser CamelCase.

Routes, views e controllers devem ter essa especificação após o nome. Por exemplo, um resource (existem Routes do tipo resource e do tipo route) com nome people, deve gerar:

App.PeopleRoute = Ember.Route.extend({});
App.PeopleController = Ember.ObjectController.extend({});
// ou 
// App.PeopleController = Ember.ArrayController.extend({});
App.PeopleView = Ember.View.extend({});

Um model com nome people deve ser da seguinte forma:

App.People = Ember.Object.extend({});
// ou, no caso do Ember Data
App.People = DS.Model.extend({});

Mixins possuem nomes como os models.

Instâncias

O Ember cria automaticamente instâncias das classes na inicialização da aplicação. Então não há necessidade de fazer algo como:

App.PeopleView = Ember.View.create({});

Nos casos em que seja necessário, os nomes devem ser camelBack. Como no exemplo abaixo.

App.peopleView = Ember.View.create({});

Templates

Templates de resources, devem ter como nome o nome do resource. No caso de um resource com nome people:

<script type="text/x-handlebars" data-template-name="people">
</script>

Routes do tipo route devem vir após o nome do resource "pai", da seguinte forma:

// No caso do route padrão
<script type="text/x-handlebars" data-template-name="people/index">
</script>

// No caso de um route com nome `new`
<script type="text/x-handlebars" data-template-name="people/new">
</script>

Properties

Todas properties devem ser camelBack.

Handlebars Helpers com Ember.js

2013-02-20T00:00:00+00:00

Handlebars Helpers com Ember.js

Handlebars é um ótimo template engine JavaScript construído sobre o Mustache. Se ainda não conhece, dá uma olhada no site, dá pra ter uma noção bem bacana do que ele é capaz.

Criando um Helper

Para criar um novo handlebar helper para, por exemplo, um botão de submit form, usa-se o seguinte:

Handlebars.registerHelper('submitButton', function(text) {
    return new Handlebars.SafeString(
        '<button type="submit">' + text + '</button>'
    );
});

Entretanto, às vezes é interessante usar um helper para algum tipo de formatação, como, por exemplo, centavos para real:

Handlebars.registerHelper('real', function(centavos) {
    var real = Math.floor(centavos / 100);

    return real;
});

Template:

<div>
    R$ {{real totalCost}}
</div>

Saída HTML:

<div>
    R$ 150,43
</div>

Se o valor da variável totalCost for alterado, o helper só imprimirá o novo valor se a página for recarregada. O que não é bem o que queremos quando estamos usando o Ember.js.

Criando um Bound Helper

Em situações onde queremos que o helper seja chamado toda vez que o valor da variável for modificado, utilizamos o Ember.Handlebars.registerBoundHelper.

Ember.Handlebars.registerBoundHelper('real', function(centavos) {
    var real = Math.floor(centavos / 100);

    return real;
});

Dessa forma, sempre que o valor da variável alterar, o helper será chamado.

Conceitos básicos do Ember.js

2013-02-20T00:00:00+00:00

Conceitos básicos do Ember.js

Atenção! Esse post está desatualizado, e utiliza a versão v.1.0.0-rc.1.

Obs. 1: Esse post assume um conhecimento básico de JavaScript.

Obs. 2: Decidi não traduzir vários termos em inglês para o português por serem conceitos fundamentais ao Ember. Quando possível, utilizo de termos em português. Entretanto, não se preocupe, pois todos os conceitos estão explicados. Qualquer dúvida quanto a isso, coloque nos comentários.

Obs. 3: Este não pretende ser um guia completo, apenas uma introdução. Trabalharei conceitos mais avançados em futuros posts.

O que é o Ember.js?

Do próprio site:

A framework for creating ambitious web applications.

Em uma tradução livre: Um framework para criação de grandes aplicações web.

Vou falar sobre os conceitos básicos necessários para a criação de um micro aplicativo (lista de pessoas e seus frameworks favoritos), que será construído ao longo do texto. A versão final está aqui.

Por quê utilizar o Ember?

Se você já teve a experiência de criar uma página web, com várias requisições ajax e modificações da interface de usuário, sabe que, em pouco tempo, o código vira um espaguete. Extremamente complicado de manter, principalmente quando há mais de uma pessoa trabalhando no projeto.

Portanto, se há a necessidade de ações CRUD - create (criar), read (ler), update (alterar) e delete (remover) - na página, e você deseja melhorar a performance, evitando recarregamento a cada ação, o padrão de arquitetura MVC, adotado pelo Ember, vai facilitar sua vida.

É claro que é possível ter código bem estruturado sem a utilização de um framework. Entretanto, quando a sua base de código começar a crescer e crescer, e quando começar projetos novos, vai perceber que estará escrevendo as mesmas funções para cada uma das aplicações.

"Trivial choices are the enemy" - Yehuda Katz, Ember Core Team

Ember se apóia bastante no paradigma convention over configuration. Quase sempre o que é necessário para a aplicação será gerado automaticamente, em memória, sem precisar, explicitamente, instanciar classe alguma.

Isso não significa que não seja possível configurá-lo para ficar exatamente da forma como te agrada. Apenas elimina as decisões triviais que toda aplicação requer ao longo do seu desenvolvimento.

Padrão de arquitetura MVC

MVC significa Model View Controller. Não vou entrar em detalhes sobre a história desse padrão, nem sua evolução ao longo dos anos. Falarei apenas dos conceitos necessários para entender e construir uma aplicação com Ember.

MVC no Ember é como MVC em aplicações desktop. Portanto, se você já utiliza algum framework MVC no servidor, como Django, Zend ou Ruby on Rails, deixe de lado por um momento os conceitos que você já sabe.

Application

Para criar uma aplicação, primeiramente é necessário instanciar a classe Ember.Application.

window.App = Ember.Application.create();

App será o namespace do aplicativo. Aqui usei a palavra App, mas pode ser qualquer outra. A convenção é que o nome comece com letra maiúscula.

Todas as classes serão instanciadas sob esse namespace.

Templates

Toda a interface de usuário residirá nos templates. O Ember utiliza, por padrão, o Handlebars. É possível utilizar outro template, mas, a não ser que você saiba bem o que está fazendo, não recomendo. Ganhamos várias coisas ao utilizar o Handlebars, sem precisar preocupar com coisas triviais.

O template default do aplicativo é chamado application, e é criado da seguinte forma:

<script type="text/x-handlebars" data-template-name="application">
Esse é o template padrão.

{{ outlet }}
</script>

Esse é o menor aplicativo possível, criado com Ember. Muita coisa está acontecendo nos "bastidores". Vejamos:

o aplicativo é inicializado;
o template application é renderizado;
automaticamente é criado um route, que reflete o estado do aplicativo na URL.

O {{ outlet }} serve como um espaço reservado para outros templates.

Ao estender o controller abaixo, tornamos disponível alguns dados para o template application.

App.ApplicationController = Ember.ObjectController.extend({
    nome: 'Eddard',
    sobrenome: 'Stark'
});

<script type="text/x-handlebars" data-template-name="application">
Olá, {{ nome }} {{ sobrenome }}!

{{ outlet }}
</script>

O resultado HTML será:

<div id="ember151" class="ember-view">
    Olá, Eddard Stark!
</div>

Não se preocupe com os atributos HTML id e class por enquanto.

Router

O router é responsável pela manutenção do estado do aplicativo. Como estamos construindo um aplicativo web, que roda em um navegador, seria ótimo se o estado ativo fosse refletido na URL.

Bem, o Ember faz isso automaticamente.

Vamos criar uma nova rota para listar as pessoas do nosso app.

App.Router.map(function(){
    this.resource('people');
});

<script type="text/x-handlebars" data-template-name="people">
<h1>Pessoas</h1>
</script>

Isso criará automaticamente a seguinte URL:

http://dominio.com/#/people

Ao ser acessada, o template people será renderizado e adicionado no outlet do template application.

Além da manutenção dos estados, o router é também responsável por atribuir aos controllers a representação de um ou mais models, e lidar com eventos.

Resources e routes

Há duas formas de se criar um novo route:

App.Router.map(function(){
    // Cria um route e um novo namespace
    this.resource('people');

    // Cria um route no namespace que o route está aninhado
    this.route('new');
});

Ao criar um novo resource, será criado também um novo namespace; quando é criado um route, o namespace é o do route "pai". Isso vai afetar a forma como se declara os nomes dos controllers, views e templates. Ao criar os routes como no código acima, temos o seguinte:

URL	Nome do route	Controller	Route	Template
`/`	`index`	`App.IndexController`	`App.IndexRoute`	`index`
`/people`	`people`	`App.PeopleController`	`App.PeopleRoute`	`people`
`/new`	`new`	`App.NewController`	`App.NewRoute`	`new`

A medida que a complexidade da aplicação aumenta, será necessário ter routes aninhados. Eles podem ser criados da seguinte forma:

App.Router.map(function(){
    this.resource('people', function() {
        this.route('new');
    });
});

E os nomes ficam assim:

URL	Nome do route	Controller	Route	Template
`/`	`index`	`App.IndexController`	`App.IndexRoute`	`index`
N/A	`people`	`App.PeopleController`	`App.PeopleRoute`	`people`
`/people`	`people.index`	`App.PeopleIndexController`	`App.PeopleIndexRoute`	`people/index`
`/people/new`	`people.new`	`App.PeopleNewController`	`App.PeopleNewRoute`	`people/new`

Veja que, ao aninhar o route new ao resource people, automaticamente foi criado um novo route, o index. Todo resource que tiver routes aninhados, terá um route index.

Dynamic segments

Ao acessar um determinado estado da aplicação a partir de uma URL, o route utiliza a informação da URL para determinar o model correspondente, e carregar esse model para o controller.

A versão final do router do nosso aplicativo será:

App.Router.map(function(){
    this.resource("people", function() {
        this.resource('person', { path: ':person_id' });
        this.route('new');
    });
});

Repare que o valor da property path, no resource person, possui um :, seguido do nome do resource junto com um _id. Isso faz com que, ao acessar a URL /people/3, o router automaticamente busque pelo model App.Person com id 3.

Caso haja interesse em ter uma URL com nome diferente do nome do route, como, por exemplo, o nome "pessoas" para o route people, é só adicionar o valor à property path.

App.Router.map(function(){
    this.resource("people", { path: '/pessoas' }function() {
        this.resource('person', { path: ':person_id' });
        this.route('new');
    });
});

Os nomes ficam assim:

URL	Nome do route	Controller	Route	Template
`/`	`index`	`App.IndexController`	`App.IndexRoute`	`index`
N/A	`people`	`App.PeopleController`	`App.PeopleRoute`	`people`
`/people`	`people.index`	`App.PeopleIndexController`	`App.PeopleIndexRoute`	`people/index`
`/people/:id`	`person`	`App.PersonController`	`App.PersonRoute`	`person`
`/people/new`	`people.new`	`App.PeopleNewController`	`App.PeopleNewRoute`	`people/new`

Models

Os models são responsáveis pelo controle dos dados da aplicação. São completamente independentes da interface do usuário, apesar de serem requisitados por ela. Ao sofrer atualização, o model notifica os observers, que traduz isso para a UI.

No Ember, os models são javascript objects ligeiramente modificados (para suportar bindings e outras funcionalidades).

Definindo um Model

App.Person = DS.Model.extend({
    firstName: DS.attr('string'),
    lastName: DS.attr('string'),
    fullName: function() {
        return this.get('firstName') + ' ' + this.get('lastName');
    }.property('firstName', 'lastName')
});

Estou utilizando o Ember Data, uma biblioteca responsável por carregar dados do servidor, fazer alterações no navegador, e salvar as alterações de volta ao servidor. Esta biblioteca ainda não está mesclada ao Ember, mas o será em breve.

As properties firstName e lastName são carregadas diretamente do servidor através de alguma REST API, e serão persistidas ao servidor após as alterações. A property fullName é uma computed property, que tem seu valor determinado a partir de alguma função. No código acima, ela é composta do nome e sobrenome (firstName e lastName).

Toda vez que qualquer uma das properties do model App.Person for alterada, a computed property também será.

Definindo uma Store

A Store é o repositório que contém todos os models já carregados, além de ser responsável pelo carregamento dos models que ainda não foram carregados.

App.Store = DS.Store.extend({
    revision: 11,
    adapter: DS.RESTAdapter.create();
});

A property revision é o número de revisão da API, utilizada para a notificação de alterações que podem quebrar código já existente. O adapter é responsável pela comunicação com o servidor.

O Ember Data possui dois adapters padrões: DS.FixtureAdapter e o DS.RESTAdapter. O primeiro é utilizado para dados hard coded (extremamente útil para prototipagem de uma aplicação, já que independe do backend), enquanto que o segundo é usado quando se tem um servidor REST.

Para esse aplicativo, vamos usar uma REST API criada em node.js, que persiste os dados apenas no processo. Essa REST API possui apenas um resource:


GET http://api.dadospublicos.org/people
GET http://api.dadospublicos.org/people/:id
POST http://api.dadospublicos.org/people
DELETE http://api.dadospublicos.org/people/:id

Para utilizá-la na aplicação, vamos configurar a sua url no adapter.

App.RESTSerializer = DS.RESTSerializer.extend({
    init: function() {
        this._super();

        this.map('App.Person', {
            frameworks: {embedded: 'always'}
        });

        this.configure('plurals', {
            person: 'people'
        });
    }
});

App.RESTAdapter = DS.RESTAdapter.extend({
    url: 'http://api.dadospublicos.org',
    bulkCommit: false,
    serializer: App.RESTSerializer.create()
});

App.Store = DS.Store.extend({
    revision: 11,
    adapter: App.RESTAdapter.create();
});

Controllers

Um controller é responsável por representar um model para um template e por armazenar properties que não serão salvas no servidor.

Para representar um único model, utiliza-se o Ember.ObjectController. Quando é necessário representar uma matriz (array) de models, utiliza-se o Ember.ArrayController.

É no route que se determina qual será o model que será representado no controller. Para carregar o model App.Person no controller App.PersonController, utilizamos a property model, como mostrado abaixo.

App.PeopleRoute = Ember.Route.extend({
    model: function() {
        return App.Person.find();
    }
});

Adicionar pessoa à lista

O controller App.PeopleNewController será o responsável por adicionar novas pessoas à lista. Precisamos, então, configurar seu model. Como o route people.new é para a criação de uma nova pessoa, não há model algum sendo carregado.

App.PeopleNewRoute = Ember.Route.extend({
    model: function() {
        // Model vazio
        return null;
    },

    setupController: function(controller) {
        controller.startEditing();
    },

    exit: function() {
        this._super();
        this.controllerFor('people.new').stopEditing();
    }
});

Toda a manipulação do model é feita no controller.

App.PeopleNewController = Ember.ObjectController.extend({
    startEditing: function() {
        this.transaction = this.get('store').transaction();
        this.set('content', this.transaction.createRecord(App.Person, {}));
    },

    stopEditing: function() {
        if (this.transaction) {
            this.transaction.rollback();
            this.transaction = null;
        }
    },

    save: function() {
        console.log( "return", this.validate() );
        if (this.validate()) {
            this.transaction.commit();
            this.transaction = null;
        } else {
            alert('Nome inválido');
        }
    },

    validate: function() {
        var firstName, regex;

        regex = /^[A-ZÄÁÀËÉÈÍÌÖÓÒÚÙÑÇa-zäáàëéèíìöóòúùñç][A-ZÄÁÀËÉÈÍÌÖÓÒÚÙÑÇa-zäáàëéèíìöóòúùñç ]{1,70}[A-ZÄÁÀËÉÈÍÌÖÓÒÚÙÑÇa-zäáàëéèíìöóòúùñç]$/;
        firstName = this.get('content').get('firstName');
        firstNameOk = regex.exec(firstName);

        if (firstNameOk) {
            return true;
        } else {
            return false;
        }
    },

    transitionAfterSave: function() {
        if (this.get('content.id')) {
            this.transitionToRoute('people.index');
        }
    }.observes('content.id'),

    cancel: function() {
        this.stopEditing();
        this.transitionToRoute('people.index');
    },

    addFramework: function() {
        this.get('content.frameworks').createRecord();
    },

    removeFramework: function(framework) {
        framework.deleteRecord();
    }
});

E no template temos:


<script type="text/x-handlebars" data-template-name="people/new">
<form {{action save on="submit"}}>

<div>
    {{view Ember.TextField placeholder="nome" valueBinding="firstName"}}
    {{nameValidation firstName}}
</div>
<div>
    {{ view Ember.TextField placeholder="sobrenome" valueBinding="lastName"}}
</div>
<div>
    {{ view Ember.TextField placeholder="twitter" valueBinding="twitter"}}
</div>

{{#each frameworks}}
    <div>
        {{view Ember.TextField placeholder="framework" valueBinding="name"}}
        <button {{action removeFramework this}}>-</button>
    </div>
{{/each}}

<div><button {{action addFramework}}>Adicionar framework</button></div>
<div>
    {{submitButton "Salvar"}}
    <button {{action "cancel"}}>Cancelar</button>
</div>
</form>
</script>

Views

A responsabilidade da view é traduzir os eventos primitivos do navegador, e.g. click, key press, em eventos que tenham algum significado para a sua aplicação.

As views são utilizadas quando há necessidade de componentes reutilizáveis, como inputs, e.g. Ember.TextField, ou quando há eventos complexos.

No nosso aplicativo, não precisamos alterar comportamento de view alguma. Apesar disso, as seguintes views foram geradas automaticamente:

App.ApplicationView = Ember.View.extend();
App.PeopleView = Ember.View.extend();
App.PeopleIndexView = Ember.View.extend();
App.PeopleNewView = Ember.View.extend();
App.PersonView = Ember.View.extend();

Juntando tudo

Todo o código pode ser baixado aqui e o app pode ser visto aqui.

Coisas importantes que não foram vistas aqui

Existem várias áreas extremamente importantes para o desenvolvimento de um aplicativo web, como:

depuração de erros;
testes;
organização de arquivos;
implementação em servidores.

O objetivo desse post é somente fazer com que você coloque a mão na massa e conheça esse excelente framework javascript. Em futuros posts cobrirei outros tópicos.

Dicas:

Utilize a versão não "minificada" do Ember durante o desenvolvimento.
Mantenha o Chrome Developer Tools sempre aberto. Caso não saiba como utilizá-lo, corra atrás. É uma ferramenta indispensável para a criação de aplicações javascript.

vhost no node.js utilizando express

2013-02-18T00:00:00+00:00

vhost no node.js utilizando express

Sempre utilizo virtual hosts quando trabalho com Apache, o que permite, dentre várias coisas, ter vários domínios apontando para a mesma porta de um ip.

Como, nos últimos meses, praticamente abandonei o Apache em favor do node.js como servidor, precisei achar uma alternativa.

Utilizando o framework Express, o processo é muito simples.

var express;
express = require('express');

// Primeiro aplicativo
appOne = express();

// Segundo aplicativo
appTwo = express();

// Terceiro aplicativo
api = express();

// Aplicativo principal
app = express();

// Os parâmetros do express.vhost são o domínio e o aplicativo
app.use(express.vhost('app-one.com', appOne));
app.use(express.vhost('app-two.com', appTwo));
app.use(express.vhost('api.dominio.com', api));

app.listen(80);

E voilà!

O roteamento acontece da forma como você provavelmente está acostumado:

appOne.get('/', function(req, res) {
    res.send('Tudo funcionando!')
});

Qualquer dúvida, coloca aí nos comentários.

WhatsApp no Mac

2013-02-17T00:00:00+00:00

WhatsApp no Mac

Uso o WhatsApp, um excelente aplicativo para celular para troca de mensagens, desde o início de 2011. Nos últimos meses vários amigos/familiares começaram a adotá-lo como fonte primária de comunicação rápida, deixando de lado SMS, email, etc.

Como trabalho o dia inteiro na frente de um computador, nada mais sensato do que enviar mensagens pelo serviço de uma maneira mais rápida e prática, além do benefício em poder digitar as mensagens usando meu teclado físico.

O problema é que, ao instalar o WhatsApp em algum aparelho celular, ele utiliza o número do telefone como nome de usuário; com isso vêm coisas bacanas, como automaticamente pesquisar quais contatos da sua agenda também possuem uma conta ativa. Ótimo.

Solução: emular um OS de celular.

O BlueStacks é um emulador de Android, extremamente fácil de instalar e usar.

Como?

Passo 1

Instale o BlueStacks.

Passo 2

Acesse http://www.whatsapp.com/android a partir do navegador do emulador. Como eu não consegui achar o navegador, acessei minha conta do Twitter (vem pré-instalado), e cliquei no link que havia postado.

Passo 3

Baixe a versão pra Android.

Passo 4

Puxe para baixo a barra de notificações que fica no topo da janela.

Passo 5

Quando ver o "WhatsApp.apk : Download complete", é só clicar pra instalar.

Passo 6

Uma vez instalado, acesse o aplicativo e configure-o com seu número de celular.

Passo 7

Profit.

Dropbox como servidor Git

2012-11-23T00:00:00+00:00

Dropbox como servidor Git

Fazem quase 2 anos que utilizo o Git para várias coisas, inclusive para controle de versão.

Cheguei a utilizar repositórios privados do GitHub, e funcionam muito bem. Entretanto possuem a limitação de espaço e quantidade (eu usava o plano Micro, que permite até 5 repositórios privados).

A alternativa: Dropbox.

Pressupostos

Conta no Dropbox;
Git instalado.

Ou mais:

Instância amazon

Dropbox em uma instância AWS EC2 Ubuntu 12.04 LTS

Acesse a instância por ssh.

ssh -i sua_chave.pem ubuntu@seu_ip

É necessário baixar o Dropbox. Caso a versão do Ubuntu seja 64 bits:

cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -

Se for 32 bits:

cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86" | tar xzf -

Agora é necessário rodar o daemon do Dropbox que está na pasta recém criada.

~/.dropbox-dist/dropboxd

Você precisará copiar o link que aparece no seu navegador para adicionar o servidor à sua conta. Assim que você fizer isso, será criada a pasta Dropbox no seu diretório ~.

Para controlar o Dropbox a partir da linha de comando, é só baixar esse CLI:

mkdir -p ~/bin
wget -O ~/bin/dropbox.py "http://www.dropbox.com/download?dl=packages/dropbox.py"
chmod +x ~/bin/dropbox.py

E para utilizá-lo:

~/bin/dropbox.py help

Não sincronizar todas as pastas

Eu não gosto de deixar todas as minhas pastas sincronizadas com o Dropbox da minha instância EC2, então eu removo aquelas que não desejo (na verdade removo todas, deixo apenas a pasta que fica os repositórios).

~/bin/dropbox.py exclude add NOME_DA_PASTA

Para ver quais pastas estão excluídas da sincronização:

~/bin/dropbox.py exclude list

Problemas conhecidos com Dropbox no servidor

Caso o processo comece a dar problema, basta:

$ ps -e | grep dropbox
3892 ? 00:01:07 dropbox
$ kill 3892
$ ~/bin/dropbox.py start
Starting Dropbox...Done!

Reiniciar o .profile

2012-07-18T00:00:00+00:00

Reiniciar o .profile

Para reiniciar o arquivo .profile, basta:

source ~/.profile

Iniciar um repo git

2012-07-15T00:00:00+00:00

Iniciar um repo git

Para iniciar um repositório git, com o propósito de servir como um repositório compartilhado:

mkdir repositorio.git
cd repositorio.git/
git --bare init

Agora, no seu repositório local:

git remote add origin /path/repositorio.git

chmod

2012-07-15T00:00:00+00:00

chmod

chmod é um comando Unix que permite a configuração do acesso dos usuários à arquivos e diretórios.

Para listar as permissões atuais de arquivos de um diretório, basta digitar ls -l (o l significa long).

Suas permissões de arquivo

Na primeira coluna, ao se usar o comando ls -l, a primeira letra informa se é um diretório d ou um arquivo -. As próximas letras informam que tipo de acesso é permitido para o arquivo.

As três primeiras letras se referem às permissões para ler, escrever e executar um arquivo (caso seja um diretório, a letra x significa que é possível fazer buscas no diretório), do usuário dono do arquivo, (aquele que é listado pelo comando ls -l).

As próximas três letras se referem às permissões do grupo. As últimas três se referem às permissões de qualquer outro usuário.

Mudando a permissão de arquivos

Usamos o comando chmod para mudar o modo de acesso (change the access mode of a file).

chmod who=permissions filename

u: o usuário dono do arquivo
g: o grupo à que pertence o arquivo
o: qualquer outro usuário
a: todos os usuários

Mudar o grupo de um arquivo

Basta usr o comando chgrp:

chgrp groupname filename

Salvar Screenshots no Mac OS X

2012-07-07T00:00:00+00:00

Salvar Screenshots no Mac OS X

Para alterar o local padrão de salvamento das screenshots tiradas no Mac, basta abrir o Terminal e digitar isso:


defaults write com.apple.screencapture location /path/

Onde /path/ é o caminho da pasta que você escolher. Após essas mudanças é preciso digitar:


killall SystemUIServer