Categorias
Tecnologia

Lendo RSS Feed somente com Javascript (jQuery)

Eu construi uma página estática em HTML, CSS e JS para ser uma espécie de portfólio e cartão pessoal para mim e queria colocar uma seção com os artigos deste blog nela. A melhor maneira de acessar esses artigos sem muito esforço é usando o RSS Feed do blog.

Mas a página é “estática”, então eu poderia usar no máximo o Javascript para ler o Feed do blog. Uma opção seria acessá-lo via Ajax e processar os dados em seguida, mas se o Feed for de outra origem (domínio diferente, que não era o meu caso, mas pode ser o seu) ia acabar esbarrando em um erro de segurança (CORS Error) e não funcionaria.

Então encontrei uma solução (no link de referência no final do artigo), usar uma API do Google que lê um Feed e retorna um JSON com as informações dele.

Segue abaixo uma versão do código que estou utilizando na página, totalmente comentado.

[gist id=”98d6f630b9b89b229deaa19acb38e2bd”]

Os items que temos disponíveis para acesso, como mostra a imagem abaixo, são o autor, categorias e tags, o conteúdo inteiro em HTML, um pequeno snippet do conteúdo em texto puro, a URL do artigo, a data de publicação e o título. Eu senti falta do retorno das mídias, como fotos, por exemplo, mas se for necessário a opção seria pegá-las do próprio HTML que retorna em “content“.

É isso aí, qualquer dúvida ou sugestão deixe nos comentários abaixo. Para ver esse código em funcionamento acesse o site.

Referência: http://pt.stackoverflow.com/a/65758

Categorias
Tecnologia

Usando Grunt para compilar SCSS (Sass)

O Grunt é um gerenciador de tarefas JavaScript. O conheci pela primeira vez quando utilizei o Yeoman para desenvolver um projeto em AngularJS (leia mais).

O Sass é uma linguagem de extensão de CSS, que se auto-intitula “CSS com superpoderes”.

Precisei começar um novo projeto de frontend montando apenas os HTMLs, JavaScripts e CSSs das páginas. Então resolvi conhecer melhor o Grunt e o Sass.

Percebi que dominar essas ferramentas gera dezenas de possibilidades novas para o desenvolvimento frontend. Claro que ainda não dominei, mas vou escrever um pouco sobre o que já aprendi.

Obs: Para todos os comandos abaixo estou utilizando a linha de comando (console) do Linux.

Para instalar o Sass é necessário o package manager do Ruby, o RubyGems.

sudo su -c "gem install sass"

Para instalar o grunt-cli é necessário o package manager do Node.js, o npm. Aproveito para já instalar os pacotes que vou utilizar: grunt-contrib-sass e grunt-contrib-watch.

npm install grunt grunt-contrib-sass grunt-contrib-watch

Estou usando o Bootstrap nesse projeto, então é necessário instalar o bootstrap-sass pelo npm.

npm install boostrap-saas

Minha estrutura de diretórios será a seguinte:

  • project/
    • node_modules/
    • public/
      • css/
      • img/
      • js/
      • index.html
    • sass/
      • style.scss
    • Gruntfile.js
    • package.json

No arquivo Gruntfile.js configuramos todas as tarefas que o Grunt vai executar. No caso desta publicação faremos a preprocessamento do SCSS para CSS.

Todas as tarefas do Grunt são executadas na linha de comando (console) precedidas por “grunt”, como por exemplo “grunt watch” ou “grunt build”.

[gist id=”f1c4801d3fd6f07a76ac28ec4ef3d4d6″]

Primeiro configurei o Sass para compilar para o ambiente de desenvolvimento, nesse caso o CSS não ficará comprimido, para que eu possa vê-lo em ação. No caso da configuração para ambiente de produção ele será comprimido.

Então configuro a tarefa do grunt-watch, ela acionará a tarefa “sass:dev“, que configuramos no passo anterior, a cada mudança que eu fizer aos arquivos *.scss. Isso serve para que eu não precise rodar um comando grunt manualmente a cada alteração no SCSS, o que seria contraproducente.

Obs: Para que isso aconteça é preciso deixar o comando “grunt watch” rodando na linha de comando (console).

No final do arquivo registro as tarefas com o registerTask. No caso apenas “grunt build“, que será usado para gerar o CSS final comprimido para produção, pois a tarefa que gera os arquivos não-comprimidos para ambiente de desenvolvimento já será chamada pelo grunt-watch e não precisa ser registrada novamente.

Estas tarefas registradas ao final do arquivo servem para agregar várias tarefas a um único comando. Assim quando você precisar rodar tudo de uma vez para gerar a versão de produção, você rodorá apenas “grunt build” e todas as tarefas da lista serão executadas. No nosso caso temos apenas o Sass por enquanto, mas futuramente podemos ter diversas tarefas a serem executadas para gerar os arquivos de prod.

Vou falar mais sobre Grunt e Sass no futuro. Se tiver alguma sugestão ou dúvida sobre o conteúdo desta publicação, dexe um comentário abaixo.

Categorias
Crônicas Tecnologia

Lançamento do Diligeiro

Em novembro de 2015 recebi uma ligação de uma empresa na qual eu já havia feito entrevistas e testes meses antes. Nesta ligação marcamos uma reunião e na próxima semana lá estava eu ouvindo pela primeira vez sobre o Diligeiro.

O Diligeiro é um aplicativo para smartphone que serve para conectar advogados correspondentes com escritórios de advocacia ou advogados que precisam do serviço de diligência.

O meu desafio era criar o backend desse aplicativo, uma API. O seu grande diferencial é a geolocalização, mostrar aos correspondentes quais diligências estão mais próximas dele. Ou seja, seria minha primeira experiência desenvolvendo uma API e também a primeira experiência com Geolocalização. Estudei, experimentei e hoje posso dizer que aprendi muito.

Enquanto ainda desenvolvia todas essas coisas novas para mim, fui escalado para fazer também o frontend web do mesmo produto. Mais uma série de aprendizados, desenvolver um frontend web totalmente baseado em requisições de API. Mais estudos, experiências e aprendizados.

Nas últimas semanas o aplicativo para Android e a versão Web do Diligeiro foram lançados em formato Alpha e em seguida em formato Beta, para que os usuários pudessem começar a utilizá-lo e passarem seus feedbacks.

Nesta semana o aplicativo Android e o WebApp foram abertos ao público.

Foram seis meses de muito trabalho, muitos aprendizados e também muita diversão, graças à equipe incrível da TIA Tikal.

O trabalho continua, as melhorias e novas ideias para funcionalidades não param nunca, mas a fase inicial de desenvolvimento acabou. Agora é hora de deixar que os usuários decidam se todo o esforço valeu a pena. O aplicativo iOS continua em desenvolvimento.

Me sinto orgulhoso pelo resultado dessa primeira fase e agradecido a todos os envolvidos. A equipe do Diligeiro e a equipe do LegalNote, o produto irmão do Diligeiro que já está no mercado a mais tempo.

Categorias
Tecnologia

Usando grunt-ng-constant para mudar o endereço da API no build de um app AngularJS

Desenvolvendo pela primeira vez um webapp que consome uma API com AngularJS (e usando o Yeoman e o Grunt para fazer build e para autorefresh durante o desenvolvimento) me deparei com uma questão: Como faria o build dos arquivos para diferentes ambientes? Atualmente este projeto possui os ambientes local (dev), homologação e produção, cada um com seu respectivo endereço de API.

Para atingir esse objetivo, e como essa era minha primeira vez com Angular e com Grunt, pesquisei muito e achei uma solução que funcionou bem.

Usango o pacote grunt-ng-constant eu consigo manter uma constante com a URL de cada ambiente separadamente. Dependendo do comando de build que eu executar no Grunt, terei um resultado diferente nessa constante.

O primeiro passo é instalar o pacote citado. Lembrando que estou utilizando o NPM como gerenciador de pacotes.

npm install grunt-ng-constant --save-dev

Depois temos que configurá-lo no nosso arquivo Gruntfile.js. Aqui segue um exemplo comentado:

[gist id=”3fc6625cd09f3a4c280cf7cb7c662f45″ file=”Gruntfile.js”]

Com o Grunt configurado, podemos passar para nosso AngularJS agora.

Dentro do arquivo app.js injetamos o parâmetro ENV no método run e passamos a constante apiBaseURL para o $rootScope, fazendo com que ela fique disponível por todo o app.

[gist id=”3fc6625cd09f3a4c280cf7cb7c662f45″ file=”app.js”]

Agora você pode usar um service que faça as chamadas de API concatenando seu apiBaseUrl em todos os requests. Como no exemplo abaixo.

[gist id=”3fc6625cd09f3a4c280cf7cb7c662f45″ file=”api.js”]

Para finalizar, fazemos o build com o seguinte comando:

grunt build:homolog

Podendo subistituir o homolog por develop ou prod (ou deixar sem nenhum, que pegará o padrão prod que definimos no Grunfile.js) e testar seus arquivos no diretório dist. Lembrando que o arquivo config.js será gerado automaticamente durante o build.

Tive uma boa batalha com o Grunt no começo, mas depois que aprendemos como funciona ele se torna um aliado incrível para o desenvolvimento.

Espero que tenha gostado dessa postagem, se tiver alguma dúvida ou comentário deixe abaixo.

Categorias
Tecnologia

Summernote, um editor WYSIWYG super simples para Bootstrap

O Summernote é um editor WYSIWYG muito bom, e simples, para utilizar em aplicações web. Pra quem não sabe o que significa WYSIWYG, vejamos o que nos diz a Wikipedia.

WYSIWYG é o acrônimo da expressão em inglês “What You See Is What You Get”, cuja tradução remete a algo como “O que você vê é o que você obtém” (OQVVEOQVO). Significa a capacidade de um programa de computador de permitir que um documento, enquanto manipulado na tela, tenha a mesma aparência de sua utilização (…)

No nosso caso, estamos falando de aplicações web. O Summernote é um dos editores mais simples que já encontrei e sua instalação foi tão fácil que me surpreendi. Até mesmo para personalizar o upload de imagem foi mais simples do que eu imaginava.

Outros editores WYSIWYG para web muito conhecidos, e que eu já utilizei em alguns projetos, são o CKEditor e o TinyMCE. Apesar de suas instalações não serem complicadas, ambos tem muitos arquivos e exigem um conhecimento mais específico para executar qualquer alteração, principalmente no upload de imagens.

Para utilizar o Summernote é preciso jQuery, Bootstrap e Font Awesome (para os ícones). Com as linhas abaixo você consegue essas dependências funcionando na sua aplicação.

<script src="//code.jquery.com/jquery-1.9.1.min.js"></script>
<link href="//netdna.bootstrapcdn.com/bootstrap/3.0.1/css/bootstrap.min.css" rel="stylesheet">
<script src="//netdna.bootstrapcdn.com/bootstrap/3.0.1/js/bootstrap.min.js"></script>
<link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.min.css" rel="stylesheet">

A seguir, basta inserir o CSS e o código JavaScript do Summernote.

<link href="summernote.css" rel="stylesheet">
<script src="summernote.min.js"></script>

Então basta escolher qual é o campo que você deseja transformar em um editor WYSIWYG, adicionar o código de inicialização do Summernote, como no exemplo abaixo, e voilà!

<div id="summernote">Hello Summernote</div>
<script>
$(document).ready(function() {
  $('#summernote').summernote();
});
</script>

Seu campo vai aparecer dessa maneira:

Se você quer personalizar os itens da barra do editor, o tamanho do campo, entre outras coisas, basta ver as features no site do Summernote.

Personalizando o upload de imagens

Ao inserir uma imagem, por padrão, o editor insere os dados da imagem em Base64 ao texto. Mas normalmente não é isso que queremos no nosso código, certo? Então a opção é alterar o padrão para efetuar um upload do arquivo ao ser inserido.

Não vou abordar aqui o script backend por trás do upload, porque isso não tem nada a ver com o editor em questão, vou mostrar apenas como chamamos esse código pelo Summernote.

$(document).ready(function() {
    $('#summernote').summernote({
        onImageUpload: function(files, editor, welEditable) {
            sendFile(files[0],editor,welEditable);
        }
    });
});

function sendFile(file,editor,welEditable) {
    data = new FormData();
    data.append("file", file);
    $.ajax({
        data: data,
        type: "POST",
        url: "url/para/upload/",
        cache: false,
        contentType: false,
        processData: false,
        success: function(url) {
            editor.insertImage(welEditable, url);
        }
    });
}

Primeiro configuramos o callback onImageUpload para chamar nossa função de envio de arquivo. Essa função, a sendFile, cria um novo objeto de formulário pelo javascript e insere o nosso arquivo a ele. Com o método $.ajax do jQuery chamamos nosso script de backend e, mais uma vez, voilà!

Funcionou muito bem pra mim e espero que essas dicas possam ajudar a facilitar a vida de mais pessoas por ai.

Categorias
Tecnologia

Sticky navbar com Bootstrap

Como fixar a barra de navegação do Bootstrap quando a barra de rolagem chegar nela? Essa funcionalidade é chamada de Sticky Navbar.

Utilizando esse código JavaScript abaixo a barra de navegação estática (com a classe .navbar-static-top) passa a ficar fixada no topo da página (classe .navbar-fixed-top) quando a barra de rolagem atinge certa parte da página.

      var num = $('.navbar').offset().top;

      $(window).bind('scroll', function () {
          if ($(window).scrollTop() > num) {
              $('.navbar').addClass('navbar-fixed-top');
              $('.navbar').removeClass('navbar-static-top');
          } else {
              $('.navbar').addClass('navbar-static-top');
              $('.navbar').removeClass('navbar-fixed-top');
          }
      });

A variável num contém a quantidade de pixels do topo até onde a barra de rolagem vai atuar para modificar o estilo da navbar. Neste caso estou utilizando o método offset() do jQuery para verificar a altura da barra de navegação automaticamente.

As classes de navbar descritas acima são originalmente do Bootstrap (testado com o Bootstrap 3.3.2), mas com algumas adaptações pode ser utilizado em qualquer outro CSS, basta alterar os nomes das classes no código.

Esse código foi encontrado nesse JSFiddle e apenas alterei para a utilização do método offset().