domingo, 5 de julho de 2015

Performance com AngularJS

Palestra da InfoQ que recomendo:

Alguns destaques:
* Use $emit em vez de $broadcast para troca de mensagens entre scopes
* Use two-way data binding somente quando realmente necessário, caso não seja, utilize one-way data binding. O one-way data-binding foi implementando na 1.3 e faz o valor ser renderizado uma só vez não sendo mais visitado pelo dirty checking. Para isso use ::, como em {{::valor}}. Tome cuidado somente ao usar one-way em valores dentro de um ng-repeat que possa vir a ser filtrado para não ter valores apresentados de forma incorreta.
* use ng-if em vez de ng-show. O ng-if inclui o elemento no DOM somente quando a condição for atendida enquanto que ng-show só oculta (display: none), com isso o dirty checking irá verificar o elemento com ng-show mais vezes do que com ng-if tendo um custo maior.
* use com moderação os filters, porque toda vez que um atributo two-way data binding é alterado o dirty checking repassa toda a árvore DOM revalidando todos os bindings. Sugestões aqui é já trazer o atributo já formatado ou manipular o array formatando-o usando o método map de Array (quando o filter foi utilizado para formatar) ou outra forma.
* nos ng-repeat utilize track by $index, isso irá otimizar o loop:
           ng-repeat="item in items track by $index"
* Uso de ng-model-options, também feature nova da 1.3, informa o tempo ou em que momento o model deve ser atualizado.

Veja também:
Exploring Angular 1.3: One-time bindings
Exploring Angular 1.3: ng-model-options

terça-feira, 16 de junho de 2015

Web Design Responsivo - Premissas

Não se preocupe com tamanho da tela ou marca do dispositivo, se foque na resolução.

Os tipos de medidas % e em são escaláveis e px é fixa. Use px somente quando necessário, tipo um input que terá uma data, não tem necessidade de ficar maior que o texto de uma data se a resolução for maior. 

Para layouts usar sempre %, width e height por exemplo. % pega como referência a largura do componente pai, por exemplo, se o browser tem 800px uma div com 50% terá 400px e uma div dentro dessa div com 50% terá 200px.

Em fontes, font-size usar em, o padrão nos browsers é 16px, então se você quiser um texto com 24px então use 1.5em (24 / 16). Esse também sempre pega como referência o componente pai.

domingo, 14 de junho de 2015

JsonIgnore e XmlTransient

Estou fazendo uma aplicação RESTful, e tinha alguns parâmetros que não queria que fossem parseados para JSON. Estava usando @JsonIgnore e o atributo ia igual.

Depois de muita pesquisa na web, me lembrei do @XmlTransient que funcionou como esperado. Mas precisa ter a seguinte anotação sobre a classe @XmlAccessorType(XmlAccessType.FIELD)

Fica a dica, para não ficarem como eu um tempão pesquisando na web.

quarta-feira, 10 de junho de 2015

Mobile Summit - Porto Alegre / RS - 26/09

Fique por dentro das oportunidades e novidades no desenvolvimento mobile.

O evento terá de 8 à 9 palestras, sobre desenvolvimento, ferramentas e melhores práticas.

Eu vou e vc?

Compre seu ingresso R$ 65,00 o 1o lote: Mobile Summit

terça-feira, 9 de junho de 2015

Webinar Design de APIs RESTful

Mais um ótimo material sobre RESTful.
Abrange todos os tópicos necessários para ter uma aplicação realmente RESTful e de uma forma bem clara.


Fonte: Kleber Bacili da Sensedia

Veja também: 

quarta-feira, 27 de maio de 2015

PostGreSQL - Conexões idle

Uns dois meses atrás uma aplicação que tinha desenvolvido para um cliente usando JDBC e hospedada na Amazon, estava dando erro de conexão.

Pesquisando vi que existe o comando:

select * FROM pg_stat_activity

que informa os states das conexões.

E este para fechar as conexões (use com cuidado):

select pg_terminate_backend(pg_stat_activity.pid)
from pg_stat_activity
where pg_stat_activity.datname = 'database' AND pid <> pg_backend_pid();

Pesquisando ainda, encontrei vários links informando para usar o método close nos objetos: Connection, ResultSet e PreparedStatement. Revisei o código adicionando o método close sempre que necessário o que resolveu o meu problema.

Segue então aí a dica de sempre usar close quando estiver usando JDBC.

Nota: Prefira PreparedStatement em vez de Statement para evitar SQL Injection.