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 (CORSError) 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.
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.
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.
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”.
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.
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.
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.
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:
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.
Agora você pode usar um service que faça as chamadas de API concatenando seu apiBaseUrl em todos os requests. Como no exemplo abaixo.
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.
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.
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à!
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.
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.
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().