A pouco tempo atrás, apesar da minha experiência com front (HTML, CSS, Javascript), achei interessante dar uma atualizada e resolvi ler sobre MEAN. Admito que fiquei fascinado com a produtividade que obtive, mas também tive - e ainda tenho - muita dificuldade com alguns pontos.

Como não sou expert em Nodejs, tão pouco em javascript, precisei efetuar diversas requisições à API que estava escrevendo. Ainda alheio ao pensamento de “Programação Orientada a Eventos”, precisei ir contra as regras do Nodejs e efetuar requisições síncronas. Eu precisava que a ordem das requisições fosse respeitada, mas sem cair no inferno de callbacks.

Foi então que em uma - rápida admito - busca no Santo Google, achei a lib async.

A lib, te permite diferças maneiras de efetuar suas requisições e também agrupar o resultado de todas elas.

Um exemplo de código utilizando a biblioteca:

'use strict';

var async = require('async');
var conteudo = {};
...

exports.index = function (req, res) {
    async.parallel([
        function (callback) {
            uniforme.find(
                {
                    escola: req.escola._id
                },
                {},
                {
                    limit: 5
                },
                function (err, uniformes) {
                    if (err) {
                        console.log(err);
                    } else {
                        conteudo.uniformes = uniformes;

                        callback(null, uniformes);
                    }
                }
            );
        },
        ...
    ], function (err, results) {
        if (err) {
            console.log(err);

            return res.send(500);
        }

        return res.render('index', conteudo);
    });
};

Basicamente, você informa suas funções, uma abaixo da outra,

Mais informações: (async)[https://www.npmjs.com/package/async]

Utilizar um ChromeBook e depender integralmente da internet para trabalhar é uma mudança bem radical para muitos. Eu não consigo trabalhar muito bem quando estou sem internet.

A necessidade do ChromeBook de estar sempre conectado a internet é a mesma que a minha - ao menos para trabalhar - então, não consegui ver isso como um problema na proposta da máquina.

No meu dia a dia, utilizo basicamente a dupla Sublime Text e Zend Studio, o primeiro utilizo para projetos em Javascript e o segundo claro, para os escritos em PHP - que somente virou uma opção porque que ganhei a licença de desenvolvedor quando me certifiquei no ano passado.

Ambientes de Desenvolvimento

Para me acostumar com o a proposta do ChromeBook, passei a utilizar no meu dia-a-dia - inclusive no desktop - alguns ambientes na web

• Cloud9
• Koding
• Codenvy
• Nitrous
• Runnable
• Chrome Dev Editor

Cloud9

O Cloud9 foi a IDE que mais me surpreendeu e logo se tornou meu ambiente de trabalho padrão.

O serviço oferece mais que um simples editor, junto te dá uma VM com Ubuntu para que você possa instalar os pacotes adicionais necessários e um endereço público (que você pode deixar como privado) para que você possa testar.

Achei interessante também - apesar de não ter testado - a possibilidade de compartilhar o ambiente de desenvolvimento com outras pessoas, com permissão de escrita ou apenas leitura.

A área de trabalho permite a integração com o Bitbucket e Github, e todos os projetos são listados em uma barra lateral, permitindo a clonagem e a criação do ambiente de desenvolvimento com poucos cliques.

Koding

O Koding é uma IDE que promete, andou por algumas mudanças nos últimos tempos, mas nada que comprometa a qualidade.

Uma coisa que me desagradou logo de início foi a impossibilidade de minimizar ou mesmo fechar barra lateral, que exibe alguns canais por tags, o módulo de mensagens e a lista de VMs. Acompanhada por uma segunda barra com a estrutura de pastas, ocupando um espaço considerável da tela do ChromeBook.

Ele também tem um comportamento chato de sempre exibir a janela de texto/console e etc abaixo da tela de editor, dividindo ainda mais o pouco espaço disponível para trabalhar. É simples de mesclar tudo e deixar “normal”, mas fazer isso sempre que iniciar o ambiente é um tanto quanto chato.

Assim como o Cloud9, o Koding também nos dá uma VM para que possamos configurar o ambiente do projeto e acessá-lo de fora através de um endereço público.

Ele tenta ser uma espécie de rede social, com alguns canais de discussão e a Koding University, um canal com um ótimo conteúdo na área de desenvolvimento.

Codenvy

O Codenvy eu não consegui testar muito bem pela dificuldade inicial com a interface e no boot da VM logo após o cadastro.

A IDE é simples e sem muitos recursos, assim como a possibilidade de configurações individuais para cada projeto, incluindo a instalação de novos pacotes na VM.

Nitrous.io

Nitrous foi mais uma alternativa que não consegui testar muito bem. As boxes que tentei utilizar, nunca mais startaram depois que desligadas - o que acontece muito se vocÊ ficar por um tempo sem utilizar.

Eles também oferecem uma versão para ser instalada no Desktop e integrada ao ambiente Cloud.

Uma coisa bacana que utilizei, foi o gerenciador de pacotes direto na IDE, já que o acesso ao terminal é limitado ao seu usuário, sem sudo ou acesso root como nas anteriores.

Na lateral também vem com um chat, para conversas entre todos que forem convidados a participar do projeto, achei isso algo bem bacana.

Runnable

Runnable é bem simples e quebra um galho para pequenos experimentos.

Ele não chega a ser uma IDE, é apenas um editor de textos mas que também te dá um acesso ao terminal - logado direto como root - para que você instale os pacotes que achar necessário para configurar o ambiente da sua aplicação.

Também é possível acessar sua aplicação por um endereço público para que você possa testar.

Chrome Dev Editor

Chrome Dev Editor é a opção do Google para quem deseja desenvolver aplicações ou extensões para (é claro) o Chrome.

Não utilizei muito porque minha idéia era de utilizar uma plataforma totalmente baseada na nuvem, mas também achei legal a opção de ter um editor local instalado no ChromeBook.

SSH

Secure Shell, esse foi o único que testei, até por ser uma recomendação do próprio Google, e me atendeu muito bem. Inclusive com a possibilidade de importar minhas chaves.

O ChromeBook também possui um terminal (bem limitado diga-se de passagem) com um cliente SSH, mas não consegui testar.

Conclusões

O ChromeBook é uma máquina legal? É. Principalmente para quem desejar utilizar no dia-a-dia para o básico (e-mail, redes sociais, streaming e etc) ou levar para apresentações, ocupando pouco espaço na mochila e peso imperceptível.

Mas dependendo das ferramentas que você necessita para desenvolver um bom trabalho, talvez não seja uma máquina ideal pra você.

Serve como máquina principal para desenvolvimento? Minha conslusão é: talvez.

Se você tiver uma equipe e quiser manter um ambiente único de desenvolvimento, fugindo de VMs locais, scripts de configuração e etc. Acho uma alternativa bem viável.

Até mesmo para quem trabalha sozinho, a possibilidade de ter um ambiente de desenvolvimento, configurado por você e acessível de qualquer local é realmente legal. E pra mim, ficar sincronizando ambientes (desktop e notebook) é realmente um saco, assim como ficar subindo VM localmente.

Achei pouco pra falar de mal do ChromeBook, é uma máquina bem bacana e cumpre o seu papel. Em casa, utilizo um MacMini para trabalhar, e durante a semana que utilizei para testar o ChromeBook, utilizei em ambos as mesmas ferramentas para fazer meu trabalho e medir a produtividade, que foi bem positiva.

Mas ainda sim, encontrei dois pequenos problemas em todas as IDEs testadas:

• Debugar ainda é uma tarefa um tanto quanto complicada. A grande maioria dos debugadores são para Javascript.
• Os auto-completes são muito limitados e não fazem uma varredura completa do código para ajudar, como nas IDEs locais.

Em pouco mais de uma semana após a aquisição, utilizei praticamente todos os dias o ChromeBook para trabalhar, mesmo em casa, e fiquei bastante animado. Como ele possui uma saída HDMI, fica fácil plugar um monitor externo e extender a área de trabalho.

Para quem já tem tudo “na nuvem”, porque não seu ambiente de desenvolvimento também? Fica aí a dica ;)

Me deparei essa semana com um problema com um cliente que estava tentando enviar um arquivo grande para o servidor, pelo formulário de upload da aplicação. Nos logs, eu vi o seguinte aviso: [error] 25556#0: *52 client intended to send too large body:

Bom, achei um tanto estranho, nunca tinha visto esse erro nos logs. Editei o php.ini e aumentei as definições de post e upload, como abaixo, e mesmo assim não surtiu efeito.

upload_max_filesize = 100M
post_max_size = 100M`

Fuçando um pouco, achei a diretiva :

http {
    ...
    client_max_body_size 100m;
    ...
}

E voilá, tudo certo!!!!

O NetBeans para PHP, nem sempre consegue completar o código, quando uma variável é uma instância de um objeto, que está em outro lugar e etc. Uma dica bacana, que vai ajudar nisso e ainda vai melhorar muito a legibilidade do seu código é colocar um comentário sobre a variável (ou em algum lugar no mesmo arquivo ou bloco de código), como abaixo:

<?php
/* var $teste \ArrayObject */
$teste = new \ArrayObject(array());

Com isso, ao utilizar a variável, o NetBeans irá conseguir completar seu código.

Eu pessoalmente, não gosto do padrão NetBeansProjects, gosto de deixar meus projetos organizados de outra forma, só que o que me irrita, é toda hora o NetBeans criar esta pasta no meu diretório home, então, se você também se irrita, fica a dica para evitar isso:

Adicione a variável projectsFolder ao arquivo projectui.properties informando o diretorio que você deseja ser padrão dos seus projetos, ficando assim: projectsFolder=/Users/mrprompt/Sites

A localização do arquivo pode variar para cada SO: Mac: _~/Library/Application\ Support/NetBeans/7.3/config/Preferences/org/netbeans/modules/_ Windows: _c:\Users\user\AppData\Roaming\NetBeans\7.3\config\Preferences\org\netbeans\modules_ Linux: _$HOME/.netbeans/$VERSION/config/Preferences/org/netbeans/modules_ _ _Dica rápida, só pq achei sem querer na net ;)