Relatos de um Desenvolvedor Aventureiro

Criando um projeto Grails 3 com Angular 2

Willian Krause — Mon, 13 Mar 2017 00:00:00 GMT

Desde que comecei a estudar frameworks de Frontend, uma coisa que me incomodou era a necessidade de se precisar de um servidor para o Frontend e outro para o Backend. Em aplicações muito grandes, onde os dois projetos são totalmente separados, é algo que até dá pra entender, mas em projetos menores, é um custo a mais que acaba sendo desnecessário, pois poderíamos aproveitar o servidor onde vamos publicar nosso projeto Backend para servir também o front sem nenhuma configuração adicional.

Por gostar bastante de Grails e do Angular 2, há algum tempo comecei a procurar uma forma de desenvolver um projeto único, mas onde eu pudesse usar as duas tecnologias ao mesmo tempo. Depois de algum tempo de pesquisa, consegui chegar a uma solução que acredito ser simples, porém que atende perfeitamente este cenário.

Criando o projeto Grails

Grails Application Forge

Aproveito aqui pra falar sobre o Grails Application Forge, uma ferramenta magnífica feita pelo pessoal do Grails. Com ela, você pode criar um novo projeto Grails escolhendo quais dependências deseja utilizar, qual a versão do Grails e qual o profile que deseja utilizar no seu projeto. Utilizando o benefício do Gradle Wrapper e do Grails Wrapper, você pode começar seu projeto sem precisar baixar os binários do Grails, sem configurar variáveis de ambiente, e sem precisar rodar o comando grails create-app. Basta baixar o arquivo zip gerado, extrair e rodar o comando gradlew bootRun dentro da pasta do projeto. Com isso, eliminamos problemas de versões diferentes no ambiente de desenvolvimento.

Criando o projeto

Prosseguindo com o projeto, criei um novo projeto usando o profile rest-api. Pode ser criado tanto via linha de comando quanto pelo Grails Application Forge que citei acima. Eu utilizei o Application Forge, pois facilita muito na hora de montar um novo ambiente.

Caso prefira criar o projeto via linha de comando, é só rodar grails create-app myapp --profile rest-api

Alterando as configurações

Precisamos alterar alguns arquivos de configuração para nosso projeto funcionar com o Angular 2. O primeiro deles é o application.yml. É preciso adicionar a linha grails.resources.pattern: /** para indicar que o conteúdo estático gerado pelo Angular será servido a partir da raiz do projeto. Vamos falar um pouco sobre o conteúdo estático já já. O arquivo fica assim:

application.yml

grails:
    profile: rest-api
    codegen:
        defaultPackage: grails3.angular2
    spring:
        transactionManagement:
            proxies: false
info:
    app:
        name: '@info.app.name@'
        version: '@info.app.version@'
        grailsVersion: '@info.app.grailsVersion@'
spring:
    main:
        banner-mode: "off"
    groovy:
        template:
            check-template-location: false

grails.resources.pattern: /**

...

Depois, é preciso alterar também o arquivo UrlMappings.groovy. Vamos alterar as URLs dos endpoints colocando o prefixo api a elas, e vamos alterar o mapeamento da URL / para um arquivo index.html. O mapeamento fica assim:

UrlMappings.groovy

class UrlMappings {

    static mappings = {
        delete "/api/$controller/$id(.$format)?"(action:"delete")
        get "/api/$controller(.$format)?"(action:"index")
        get "/api/$controller/$id(.$format)?"(action:"show")
        post "/api/$controller(.$format)?"(action:"save")
        put "/api/$controller/$id(.$format)?"(action:"update")
        patch "/api/$controller/$id(.$format)?"(action:"patch")

        "/"(redirect: '/index.html')
        "500"(view: '/error')
        "404"(view: '/notFound')
    }
}

Conteúdo estático no Grails

Muitos não sabem, mas é possível servir conteúdo estático em um projeto Grails. Para isso, usamos a pasta src/main/resources/public ou a pasta src/main/webapp. A vantagem de se usar a primeira pasta é que o conteúdo também é exportado quando se cria um arquivo .jar. Já na segunda, o conteúdo só é exportado quando se cria um arquivo .war.

Por padrão, o conteúdo estático é servido através da URL http://servidor:porta/static/. Ao criarmos a configuração no arquivo application.yml, estamos dizendo ao Grails para servir o conteúdo estático através da URL raiz do nosso projeto (http://servidor:porta/). Se quiser fazer um teste, crie um arquivo index.html qualquer na pasta src/main/resources/public e execute o projeto. Antes de adicionar a configuração, este arquivo pode ser visto pela URL http://localhost:8080/static/index.html. Após adicionar a configuração, o arquivo pode ser visto na URL http://localhost:8080/index.html.

Criando o projeto Angular 2

Agora vamos criar o projeto Angular 2, que será servido através do mesmo container do projeto Grails.

Precisamos, primeiro de tudo, instalar o Node.js na máquina. Usaremos também o Angular CLI para gerar e executar nosso projeto Angular.

Instalando o Node

Instalar o Node é bem fácil. É só baixar o executável do site (preferencialmente uma versão acima da 6.9), executar o instalador e pronto. Não esqueça de marcar a opção para adicionar o Node à variável de ambiente path.

Instalando o Angular CLI

Depois de instalar o node, é só executar no terminal o comando npm install -g @angular/cli. Depois de instalado, será possível executar o comando ng no terminal. Para uma lista completa de comandos, execute ng --help.

Criando o projeto Angular 2

Para criar um projeto Angular 2, usamos o comando ng new . Vamos executá-lo na pasta um nível acima de onde está nosso projeto Grails, usando o mesmo nome de projeto. Por exemplo, se o seu projeto Grails está na pasta C:\des\grails3-angular2, abre um terminal, navegue até a pasta C:\des e execute o comando ng new grails3-angular2. Pode dar um conflito no arquivo .gitignore. Eu recomendo copiar o conteúdo do arquivo do projeto Grails existente para um editor de texto, deixar o Angular CLI sobrescrever o arquivo, e depois colar de volta o conteúdo do arquivo antigo no novo arquivo gerado.

Configurando o projeto Angular 2

Depois de criar o projeto, vamos alterar o arquivo .angular-cli.json. Vamos alterar o valor da propriedade outDir para src/main/resources/public. Esse atributo indica onde o Angular CLI vai gerar o código Javascript e HTML do projeto Angular2. Colocamos nesse atributo o caminho da pasta de conteúdo estático do Grails.

O arquivo vai ficar mais ou menos assim:

angular-cli.json

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "project": {
    "name": "grails3-angular2"
  },
  "apps": [
    {
      "root": "src",
      "outDir": "src/main/resources/public",
      "assets": [
        "assets",
        "favicon.ico"
      ],
      "index": "index.html",
      ....
    }
  ]
  ...
}

Depois, precisamos alterar também o arquivo package.json. Vamos alterar o script start para ng build --watch. Fica mais ou menos assim:

package.json

{
  "name": "grails3-angular2",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {
    "ng": "ng",
    "start": "ng build --watch",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  ....
}

Executando o projeto

Abra um terminal na pasta raiz do projeto. Nesse terminal, execute o comando npm start. Isso irá iniciar a construção em tempo real do projeto Angular 2.

Depois, abra outro terminal também na pasta raiz do projeto, e execute o projeto Grails. Se você está usando o Wrapper, rode gradlew bootRun. Se está usando o Grails instalado, rode grails run-app.

Ao iniciar, abra o endereço http://localhost:8080 no navegador. Você deverá ver a página inicial padrão do projeto Angular 2. Como estamos executando a construção em tempo real do Angular 2, caso algum arquivo seja alterado, é só atualizar a página que as alterações já podem ser vistas.

Ao exportar o projeto como JAR ou como WAR, a pasta de conteúdo estático também será exportada, e o projeto pode ser acessado da mesma maneira.

Conclusão

Sei que muitos vão argumentar que o projeto Front deve ficar separado do projeto Backend, porém esta abordagem é pra quem, assim como eu, quer poder criar um projeto usando os dois frameworks sem ter que criar configurações separadas de servidor.

Se tiver alguma dúvida, pode escrever nos comentários ou me mandar um e-mail.

Aqui tem o código-fonte do projeto hospedado no GitHub: https://github.com/willcrisis/grails3-angular2

Módulos para Angular JS

Willian Krause — Fri, 10 Jun 2016 00:00:00 GMT

Nossa… Quanto tempo desde a última vez que apareci por aqui!

Esse post é pra falar sobre alguns projetos que venho desenvolvendo para AngularJS.

Nos últimos meses, comecei a trabalhar efetivamente com Angular 1, e diante de algumas necessidades bem específicas dos projetos nos quais trabalhei, me vi obrigado a desenvolver alguns módulos para facilitar a implementação dessas necessidades. Com isso, surgiram alguns projetos que visam facilitar a vida de nós, desenvolvedores apertados por prazos minúsculos.

Angular Auth

Esse foi o meu primeiro módulo criado para o AngularJS 1. É um módulo para encapsular as regras de autenticação e autorização do projeto. Com ele, é só configurar alguns atributos e informar uma URL de backend que a autenticação já estará funcionando. Também suporta validação de regras por Papéis (Roles), que podem ser definidas direto no State (ele depende do fenomenal Ui-Router). Aí no link tem as informações de instalação e configuração. Também estou evoluindo ele para trabalhar em conjunto com o Firebase, mas essa integração ainda é experimental.

Angular Select2

Esse projeto nasceu a partir da necessidade de implementar Selects usando o Select2. Encontrei alguns módulos para Angular que fazem isso, mas achei a complexidade deles muito grande para uma coisa tão simples. Por isso decidi implementar minha própria solução. Compartilhei a mesma no GitHub caso alguém também queira uma solução simples pra esse problema.

Ajude a melhorar!

Se você interessar em algum desses projetos, sinta-se a vontade para abrir Issues ou fazer um fork! Não deixe de fazer seu PR!!

De casa nova

Willian Krause — Wed, 11 Nov 2015 00:00:00 GMT

O Willcrisis.com está de casa nova!!! Agora hospedado no Github Pages usando o magnífico Hubpress.

Hubpress: Usando o Travis-CI para gerar feed RSS

Willian Krause — Fri, 23 Oct 2015 00:00:00 GMT

Assim que descobri a existência do Hubpress, tive vontade imediata de migrar todo o conteúdo do meu site para ele, na intenção de centralizar minhas experiências todas no GitHub. Porém, logo de cara, percebi um grande problema: ele não gera o feed RSS dos artigos nativamente.

Isso poderia inviabilizar a minha idéia. Mas dei uma pesquisada e encontrei algumas coisas interessantes, como esse comentário nas issues do projeto. Seguindo as instruções do link, consegui gerar o feed usando uma classe Groovy tranquilamente. Mas aí apareceu um problema: eu teria que ter um ambiente com o Groovy configurado e seria necessário disparar a geração do feed manualmente. Dessa forma, eu não teria como criar um post de qualquer lugar.

Há alguns dias atrás eu estava tentando incorporar o Travis CI em um outro projeto meu feito em Grails, então lembrei que o Travis é capaz de executar comandos Groovy. Então decidi que usaria o Travis para gerar o RSS do meu blog.

Pesquisei por algumas horas, fiz várias tentativas sem sucesso. Até que depois de misturar vários tutoriais diferentes, consegui criar um arquivo .travis.yml que gerasse o RSS da forma que eu queria.

Não vou cobrir aqui como instalar o Hubpress ou criar uma página no GitHub Pages. O Google é nosso amigo nessa hora :D

É relativamente fácil fazer isso: primeiro é preciso ter uma conta no Travis CI (é só entrar com seus dados do GitHub). Depois é preciso ativar a integração contínua para o repositório .github.io e criar na raiz do repositório um arquivo .travis.yml.

Depois, devemos criar um arquivo chamado generateFeed.groovy, que será o script que vai gerar o RSS em um arquivo para nós. Crie na raiz do projeto com o seguinte conteúdo:

generateFeed.groovy

@Grab('com.rometools:rome:1.5.1')
@Grab('org.jsoup:jsoup:1.8.2')
import com.rometools.rome.feed.synd.SyndCategory
import com.rometools.rome.feed.synd.SyndCategoryImpl
import com.rometools.rome.feed.synd.SyndContent
import com.rometools.rome.feed.synd.SyndContentImpl
import com.rometools.rome.feed.synd.SyndEntry
import com.rometools.rome.feed.synd.SyndEntryImpl
import com.rometools.rome.feed.synd.SyndFeed
import com.rometools.rome.feed.synd.SyndFeedImpl
import com.rometools.rome.io.SyndFeedOutput
import groovy.io.FileType
import groovy.json.JsonSlurper
import org.jsoup.Jsoup
import org.jsoup.nodes.Document

import java.text.DateFormat
import java.text.SimpleDateFormat

def conf = new JsonSlurper().parse(new FileReader('hubpress/config.json'))

SyndFeed feed = new SyndFeedImpl()
feed.with {
    title = conf.site.title
    link = conf.site.url
    description = conf.site.description
    feedType = 'rss_2.0'
    author = conf.socialnetwork.email
    publishedDate = new Date()
    language = 'en-UK'
}

List entries = []
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss")
df.setTimeZone(TimeZone.getTimeZone('GMT-2'))

new File('2015').eachFileRecurse(FileType.FILES) { File post ->
    SyndEntry entry = new SyndEntryImpl()
    Document document = Jsoup.parse(post, 'UTF-8')

    SyndContent syndDescription = new SyndContentImpl()
    syndDescription.value = document.getElementsByTag('meta').find { it.attr('property') == 'og:description' }.attr('content')

    entry.with {
        title = document.getElementsByTag('meta').find { it.attr('property') == 'og:title' }.attr('content')
        link = document.getElementsByTag('meta').find { it.attr('property') == 'og:url' }.attr('content')
        description = syndDescription
        publishedDate = df.parse(document.getElementsByTag('meta').find { it.attr('property') == 'article:modified_time' }.attr('content'))
        categories = document.getElementsByTag('meta').findAll { it.attr('property') == 'article:tag' }*.attr('content').collect {String tag ->
            SyndCategory category = new SyndCategoryImpl()
            category.name = tag
            return category
        }
    }

    entries << entry
}

feed.entries = entries.sort { it.publishedDate }.reverse()

Writer writer = new FileWriter('rss');
SyndFeedOutput output = new SyndFeedOutput()
output.output(feed,writer)
writer.close()

Também é preciso gerar um Personal Access Token no GitHub que vai ser usado para fazer o commit do arquivo de feed para o nosso repositório. As permissões que já vem selecionadas são mais que suficientes para isso.

Depois de gerar o token, é preciso usar a ferramenta de linha de comando do Travis para converter nosso token em um "secret" que será usado pelo Travis. Depois de instalar a ferramenta, execute o seguinte comando (deve ser executado dentro da pasta onde foi feito o clone do projeto):

$ travis encrypt GH_TOKEN="the-token-from-github" --add

Isso vai adicionar um "secret" ao nosso arquivo .yml que pode ser convertido pelo Travis usando a variável ${GH_TOKEN} nos comandos.

Feito isso, coloque o seguinte conteúdo no arquivo .travis.yml fazendo as devidas alterações para coincidirem com o seu repositório:

travis.yml

language: groovy
before_script:
- git config --global user.email "krause.willian@gmail.com"
- git config --global user.name "Willian Krause"
script: groovy generateFeed.groovy
after_success:
  - git add rss
  - git commit -m "Updated RSS feed [ci skip]"
  - git branch temp
  - git checkout master
  - git merge temp
  - git branch -d temp
  - git remote add github https://${GH_TOKEN}@github.com/willcrisis/willcrisis.github.io.git
  - git push github master --quiet
env:
  global:
  - secure: 
  - GH_REPO: github.com/willcrisis/willcrisis.github.io.git

É preciso criar uma branch temporária pois o commit aqui será feito em uma branch detached, o que impede que o arquivo seja enviado para o repositório na hora em que o push é executado.

Após seguir todos os passos, basta adicionar um novo post na área administrativa do seu blog e ver a mágica acontecendo no Travis!

Movendo um repositório do BitBucket para o GitHub (ou vice-versa)

Willian Krause — Wed, 21 Oct 2015 00:00:00 GMT

Utilizo o BitBucket há algum tempo por causa da possibilidade de criar repositórios privados grátis sem muita complicação, e também por ele ter integração com o Codeship (ainda pretendo escrever um post sobre ele). Mas decidi abrir alguns dos meus projetos particulares após começar a participar da comunidade um pouco mais ativamente. Por isso, optei por mover esses projetos abertos para o GitHub devido à maior popularidade deste para projetos opensource. Pensei que teria dificuldade, que seria muito complicado transferir todo o histórico de commits e etc, mas é uma tarefa muito mais simples do que parece.

Primeiro de tudo é preciso criar o novo repositório no GitHub. Dentro da sua página de perfil, abra a aba "Repositories" e clique no botão "New". Assim:

Tenha o cuidado de desmarcar a opção "Initialize this repository with a README" enquanto cria o repositório. Dessa forma, o GitHub vai criar um repositório totalmente vazio.

Depois, copie a URL do repositório criado. Dentro da pasta onde você já possui o projeto hospedado no BitBucket clonado, execute os seguintes comandos:

$ git remote rename origin bitbucket
$ git remote add origin 
$ git push origin master

Pronto! Todo o repositório do BitBucket vai ser copiado para o GitHub, inclusive mantendo o histórico de commits. Se desejar remover totalmente o projeto do BitBucket, execute também:

$ git remote rm bitbucket

É possível também fazer o processo inverso, movendo um projeto do GitHub para o BitBucket. Basta inverter a ordem dos repositórios utilizados.

Não cheguei a testar, mas acho que esses comandos funcionam para migrar para qualquer outro repositório Git (GitHub, BitBucket, GitLab, etc).

Se tiver interesse, confere lá o meu perfil no GitHub e no BitBucket pra ver alguns projetos que eu desenvolvi! Sinta-se a vontade para fazer forks! Se ver alguma coisa que possa melhorar, manda um pull request!

Grails: Sobrescrevendo o UserDetailsService do Spring Security em um plugin

Willian Krause — Fri, 16 Oct 2015 00:00:00 GMT

Recentemente comecei a implementar alguns plugins para encapsular as lógicas comuns entre as aplicações que desenvolvo usando Grails. Uma dessas lógicas é a de segurança, onde eu adiciono alguns campos às classes do Spring Security e mais alguns recursos de cadastro (envio de e-mails ao usuário cadastrado, recurso de "esqueci minha senha", etc). Decidi escrever então um plugin que teria o SpringSecurityCore como dependência, e dentro dele eu definiria toda a minha lógica para ser reaproveitada em outros projetos.

Tudo muito lindo, tudo muito fácil, não fosse um pequeno detalhe: eu não conseguia sobrescrever o bean userDetailsService de nenhuma forma dentro do bloco doWithSpring dentro do meu descritor do plugin. Por mais q tentasse, nada de conseguir substituir esse bean pela classe que criei seguindo a documentação oficial do plugin. Cheguei ao ponto de editar o código fonte do plugin e submeter um pull request, que foi devidamente rejeitado pela equipe. Mas como a comunidade é algo lindo de se ver, o próprio Burt Beckwith me ensinou como fazer para funcionar. E não poderia ser mais fácil.

Todo o problema acontece porque o plugin do Spring Security é carregado após o plugin que eu desenvolvi. Dessa forma, a minha configuração sempre é sobrescrita. O que deve ser feito é adicionar, dentro do descritor do plugin (arquivo MeuPluginGrailsPlugin.groovy, fica na raiz do projeto), o atributo loadAfter e especificar quais plugins devem ser carregados antes dele. Assim:

def loadAfter = ['springSecurityCore']

Dessa forma, o meu plugin SEMPRE vai ser carregado após o Spring Security Core. Então, em vez de ser ele quem sobrescreve o meu bean, sou eu quem sobrescreve o bean dele!

Claro que se eu tivesse lido a documentação da forma adequada, teria visto isso escrito lá. Mas não teria tido a oportunidade de ser respondido pelo próprio Burt (que, a propósito, fez um fork e um pull request em um outro projeto meu!!).

Grails: Internacionalização em banco de dados e arquivos

Willian Krause — Fri, 19 Jun 2015 00:00:00 GMT

Fala, pessoal!

Estive pesquisando uma forma de gravar internacionalização em banco de dados para permitir que alguns textos da minha aplicação sejam alterados sem a necessidade de precisar subir uma nova versão no servidor, mas continuando a usar as chaves definidas nos arquivos messages_*.properties caso o texto não esteja definido no banco.

Depois de ver esse e esse post, pude fazer esse esquema funcionar perfeitamente.

Primeiro de tudo, é preciso criar uma classe de domínio para armazenar os valores no banco:

class Mensagem {
    String code
    Locale locale
    String text

    static mapping = {
        cache true
        columns {
            code index: 'idx_message_key'
            locale index: 'idx_message_key'
        }
    }

    String toString() {
        text
    }
}

Criei um índice para tornar a busca das mensagens mais rápida.

Depois, foi preciso criar a classe DatabaseMessageSource estendendo a classe AbstractMessageSource, que será a classe responsável por fazer a pesquisa no banco de dados e, caso não encontre um valor, retornar a chave definida em arquivo:

class DatabaseMessageSource extends AbstractMessageSource {

    Ehcache messageCache
    def messageBundleMessageSource

    @Override
    protected MessageFormat resolveCode(String code, Locale locale) {
        def key = new MessageKey(code, locale)
        def format = messageCache.get(key)?.value
        if (!format) {
            Mensagem mensagem = Mensagem.findByCodeAndLocale(code, locale)

            if (mensagem ) {
                format = new MessageFormat(mensagem.text, mensagem.locale)
            } else {
                format = messageBundleMessageSource.resolveCode(code, locale)
            }
            messageCache.put(new Element(key, format))
        }
        return format
    }
}

Usei o EhCache para evitar que a cada exibição de página seja feita uma consulta no banco retornando os valores já encontrados em execuções anteriores, poupando assim uma quantidade razoável de recursos do servidor. Para configurar esse cache corretamente, primeiro é preciso criar a classe MessageKey:

@Immutable
class MessageKey implements Serializable {
    String code
    Locale locale
}

Depois, é preciso dizer ao Spring para carregar os beans que acabamos de criar no resources.groovy:

messageCache(EhCacheFactoryBean) {
    timeToLive = 500
    // outras configurações de cache
}
messageSource(DatabaseMessageSource) {
    messageCache = messageCache
    messageBundleMessageSource = ref("messageBundleMessageSource")
}
messageBundleMessageSource(org.codehaus.groovy.grails.context.support.PluginAwareResourceBundleMessageSource) {
    basenames = "WEB-INF/grails-app/i18n/messages"
}

Usamos a classe PluginAwareResourceBundleMessageSource porque, segundo este comentário, algumas mensagens de plugins podem ser ignoradas caso usemos alguma outra classe aqui.

Depois de fazer essa configuração, basta fazer o teste. Eu gerei o controlador e páginas para a classe Mensagem usando o comando grails generate-all pacote.Mensagem. Depois é só fazer os testes usando a tag nas GSPs e a action message(args) nos controladores, e pronto! Sempre que for preciso sobrescrever um texto no sistema, basta criar um registro na tabela Mensagem e imediatamente a mensagem estará disponível, sem a necessidade de precisar subir uma nova versão da aplicação!// = Your Blog title

Grails: Rodando duas aplicações na mesma instância do Tomcat em subdomínios diferentes

Willian Krause — Wed, 10 Jun 2015 00:00:00 GMT

Recentemente precisei fazer deploy de duas aplicações Grails na mesma instância do Tomcat. Tudo seria simples, se não fosse o fato de que cada aplicação seria acessada pelo seu próprio subdomínio, e que a URL deveria ser algo parecido com http://aplicacao1.meudominio.com/controller/id

A princípio, basta configurar o servidor web Apache com o módulo mod_proxy configurado corretamente que tudo está resolvido. Porém, o Tomcat em sua configuração default adiciona o contexto de cada aplicação na URL que está sendo acessada. Como fazer então para que cada aplicação tenha seu subdomínio exclusivo?

A solução me tomou bastante tempo de pesquisa e testes baseados em tentativa e erro. Segue aqui a forma como consegui resolver meu problema.

Primeiro de tudo, precisei alterar o arquivo server.xml do Tomcat e fazer algumas alterações: Adicionar um novo Service, criar um Connector, definir uma Engine e um Host. Ficou mais ou menos assim (vou ocultar algumas partes do arquivo por não ser o foco):


    ...
    
        
        
            
            
        
    

    
        
        
            
            
        
    

    
        
            ... (aqui são as configurações default do Tomcat)

Depois de fazer essa configuração, dentro da pasta do Tomcat, criei as pastas aplicacao1 e aplicacao2, no mesmo nível em que a pasta webapps está. Também é preciso dar permissão 775 e mudar o proprietário dessas pastas para o usuário tomcat7.

# mkdir aplicacao1
# mkdir aplicacao2
# chmod 775 aplicacao1
# chmod 775 aplicacao2
# chown tomcat7 aplicacao1
# chown tomcat7 aplicacao2

Vai ficar mais ou menos assim:

Depois, eu copiei os WARs pra dentro da sua respectiva pasta e renomeei eles pra ROOT.war. Por fim, fiz as alterações no Apache para que o proxy redirecione corretamente as requisições:


    ServerName aplicacao1.meudominio.com
    ServerAlias aplicacao1.meudominio.com

    ProxyRequests Off

    ErrorLog /var/log/apache2/error-aplicacao1.log

    
        Order Allow,Deny
        Allow from all
    

    
        Order deny,allow
        Allow from all
    

    ProxyPass / http://meudominio.com:8081/
    ProxyPassReverse / http://meudominio.com:8081/



    ServerName aplicacao2.meudominio.com
    ServerAlias aplicacao2.meudominio.com

    ProxyRequests Off

    ErrorLog /var/log/apache2/error-aplicacao2.log

    
        Order Allow,Deny
        Allow from all
    

    
        Order deny,allow
        Allow from all
    

    ProxyPass / http://meudominio.com:8082/
    ProxyPassReverse / http://meudominio.com:8082/

Depois é só reiniciar o Apache e o Tomcat e partir pro abraço!!

Grails: Ordenar uma classe de domínio por mais de um campo

Willian Krause — Fri, 05 Jun 2015 00:00:00 GMT

Muitas vezes precisamos que os registros de uma classe de domínio venham ordenados por um determinado campo na listagem padrão. Isso é fácil de fazer em Grails! Basta definir o atributo sort dentro da seção mapping da nossa classe.

static mapping = {
    sort 'campo'
}

Se precisarmos especificar a ordem (ascendente ou descendente), também é bem simples:

static mapping = {
    sort campo: 'asc' //ou 'desc'
}

Mas como fazer para ordenar por dois campos ao mesmo tempo? Simples também:

static mapping = {
    sort campo: 'asc', outroCampo: 'asc'
}

Isso é possível pois o método sort definido dentro do bloco mapping recebe uma String ou um Map como parâmetro. Quando recebe um Map, ele é inteligente o suficiente para realizar a ordenação por todos os campos e ordens informados.

Grails: Mapear enum para um campo Integer em vez de String

Willian Krause — Fri, 08 May 2015 00:00:00 GMT

Quem programa em Grails sabe que há uma certa limitação na hora de mapear enums dentro de uma classe de domínio. O comportamento padrão é que o key do valor será salvo no banco. O Grails também dá a opção de mapear o enum de forma ordinal, o que também é possível no Hibernate.

Mas imagine o seguinte cenário: Você possui uma classe de domínio qualquer que possui um enum indicando um nível de dificuldade, conforme ilustrado abaixo:

class DominioQualquer {
    NivelEnum nivel

    static mapping = {
    	nivel enumType: 'ordinal'
    }
}

enum NivelEnum {
    BAIXO
    MEDIO
    ALTO
}

Neste caso, o Grails irá criar um mapeamento usando um campo inteiro no banco de dados. Mas e se, por algum motivo de força maior, você for forçado a incluir os níveis "Médio-Baixo" e "Médio-alto" ao seu domínio? Para facilitar a visualização do código, estruturaríamos o enum da seguinte forma:

enum NivelEnum {
	BAIXO
	MEDIO_BAIXO
	MEDIO
	MEDIO_ALTO
	ALTO
}

Porém isso iria quebrar os registros já incluídos, pois mudamos a ordem dos valores no enum! Como resolver isso?

A solução é ridiculamente simples, mas que me tomou muito tempo de pesquisa: basta definir um campo chamado id dentro do enum e remover o enumType do mapeamento. Dessa forma, o Grails irá usar este campo para persistir no banco, em vez de usar o ordinal. Nosso código então fica assim:

class DominioQualquer {
    NivelEnum nivel
}

enum NivelEnum {
    BAIXO(0)
    MEDIO_BAIXO(3)
    MEDIO(1)
    MEDIO_ALTO(4)
    ALTO(2)

    Integer id

    private NivelEnum(Integer id) {
        this.id = id
    }
}

Lembrando que o nome do campo PRECISA ser id. Já o tipo pode ser qualquer tipo conhecido do Hibernate que estenda Serializable (String, Date, char, etc…).

Preparando um projeto Cordova para publicação

Willian Krause — Fri, 23 Jan 2015 00:00:00 GMT

Na pasta platforms/android do projeto, executar os seguintes comandos:

ant release
cd bin
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore ../../../keys/nome_do_arquivo.keystore AppName-release-unsigned.apk nome_do_alias_keystore
jarsigner -verify -verbose -certs AppName-release-unsigned.apk
zipalign -v 4 AppName-release-unsigned.apk AppName.apk

DigitalOcean: Hospedagem na nuvem de forma rápida e fácil

Willian Krause — Wed, 13 Nov 2013 00:00:00 GMT

Fala, pessoal! Quanto tempo, hein?

2 anos depois da última postagem, estou de volta! Muita coisa aconteceu nesse meio-tempo (muito-tempo, na verdade). Os próximos posts vão relatar as mudanças!

Mas hoje, vamos falar um pouco de nuvem, esse assunto que anda tão na moda.

Depois de pagar caro por hospedagens de sites, sofrer com problemas de permissões de arquivos, FTPs lentos e outras coisas, decidi experimentar uma coisa diferente: servidores na nuvem.

Uma das coisas que mais me deixava irritado nas hospedagens convencionais era quando eu fazia upload de um arquivo usando o Wordpress (ou o Joomla) e o mesmo era atribuído a um usuário que eu desconhecia. Dessa forma, eu ficava impossibilitado de editar, ou até mesmo de excluir esse arquivo. Tinha, então, que abrir um ticket pro suporte da hospedagem pedindo para excluírem o arquivo pra mim.

Com um servidor na nuvem, esse problema não acontece: o servido é seu, então fica mais fácil de resolver esse tipo de situação. Também podemos criar o servidor do nosso jeito, instalando os aplicativos que precisarmos.

Experimentei por um tempo o Amazon EC2, que por sinal é muito bom, possui algumas imagens de servidores pré-carregadas, é de fácil utilização e dá 1 ano grátis se o seu servidor estiver dentro do Free-Tier. Porém, quando subi um aplicativo Grails lá (aplicativo simples, sem muitos plugins nem operações complexas), o processamento e a memória dispararam e acabei pagando um valor um pouco alto.

Foi aí que um amigo, o Emílio, falou sobre o DigitalOcean, um serviço que disponibiliza um servidor da mesma maneira que o Amazon EC2, porém com o custo fixo de 5 dólares por mês no plano básico.

No começo fiquei meio receoso, pois nunca tinha ouvido falar no serviço, mas depois de algumas pesquisas na internet, vi que o mesmo é bem avaliado por muita gente.

Arrisquei e fiz a conta. O servidor ficou disponível para mim em menos de 1 minuto, com Ubuntu 12.04 e acesso SSH imediato.

É possível encontrar muito material e "HowTo"s na comunidade, o que faz com que seja muito fácil de se configurar o que for necessário.

Venho brincando nesse servidor há alguns dias e, muito em breve, irei migrar o site e meus projetos pessoais para lá.

Se estiver interessado, pode acessar por esse link e me garantir alguns créditos (o DigitalOcean trabalha com esquema de referências :D):

https://www.digitalocean.com/?refcode=a8cd65b5d607

Se tiverem perguntas, dúvidas, sugestões, não hesitem em comentar!