Fabiano Nunes // @fab_tc

Política de Privacidade

16 Nov 2017

Os dados que você forneceu no momento do cadastro serão armazenadas nos bancos de dados da Rádio Senado.

Como a maioria do sites, durante a utilização do serviço, nós armazenamos alguns arquivos em seu computador conhecidos como cookies.

Eles nos permitem:

  • armazenar que você é um usário autenticado, dessa forma você não precisará informar suas credenciais a cada interação
  • aferir quais os recursos mais utilizados, por meio do Google Analytics, para que possamos aprimorar o serviço de acordo com suas necessidades.

Como utilizamos os cookies

Identificando usuários autenticados

Para que você não precise inserir suas credenciais (email e senha) a cada interação, nós precisamos armazenar um identificador para sua visita.

Nome do cookie Motivo Validade
__ac Identifica que o usuário foi autenticado 15 dias

Aferindo a utilização (Google Analytics)

Nós utilizamos o Google Analytics para coletar informações sobre como os usuários utilizam esse site.

O Google Analytics armazena informações sobre (i) quais páginas você visitou, (ii) o tempo que vc permaneceu nessas páginas, (iii) como você chegou até elas e (iv) em quais botões você clicou. Nós não enviamos para o Google Analytics seus dados de cadastro (email ou endereço, por exemplo). Portanto, suas informações pessoais ou da sua rádio não serão utilizadas pelo Google para identificar quem você é. Nós também não permitimos que o Google use nem compartilhe com terceiros nossos dados estatísticos.

Esse serviço utiliza o recurso UserID do Google Analytics, que nos permite cruzar os dados do Google Analytics com a sua conta. Esse cruzamento de dados só pode ser realizado pela Rádio Senado, uma vez que não enviamos ao Google Analytics nenhuma informação inerente à sua conta.

Os seguintes cookies são utilizados pelo Google Analytics:

Nome do cookie Motivo Validade
_ga Nos ajuda a contar quantos usuários visitaram o serviço 2 anos
_gid Nos ajuda a distinguir os visitantes 24 horas
_gat Usado para controlar a taxa de solicitação 1 minuto

Você pode desativar os cookies do Google Analytics cookies visitando essa página do Google

Sobre CSS

30 Mar 2016

No ano passado, comecei a reescrever algumas folhas de estilos. Não por que estavam mal elaboradas, mas porque não eram reutilizáveis.

Meu objetivo era adotar na área de design os mesmos princípios que os programadores estudam desde o primeiro hello world!.

Como ponto de partida, vou utilizar um trecho css sugerido por um colega:

[href$=".zip"]:before, [href$=".gz"]:before {
   content: '\E004'; /* unicode for the zip folder icon */
}

Embora seja um método muito inteligente e bem elaborado, é uma das técnicas que tento combater. À primeira vista, são uma mão na roda. Porém, além de quebrarem alguns princípios, podem causar problemas que só serão contornados com a quebra de outros princípios.

Seguem alguns exemplos.

Single Source of Truth

Ao configurar como se comportam todos os elementos que combinem com [href$='zip'], interferimos na autonomia de outros componentes, já que, implicitamente, duplicamos as regras que os definem.

Um determinado componente afetado por esse seletor, a partir de agora, possui dois comportamentos: um global e um específico, ambos localizados em pontos distintos da base de código.

/* callout.css */
.Callout--special:before {
  content: 'olá!';
  border: 1px solid red;
}

<a class="Callout Callout--special" href="teste.zip">Download aqui</a>

Uma vez que não é possível acumular dois pseudos-elementos, um dos :before vai perder. A depender da especificidade de cada um, podemos ter um cenário não desejado por nenhuma das regras: um \E004 com borda vermelha.

A apropriação implícita de um :before condicionou inesperadamente um estilo a um elemento.

Explicit is better than implicit

Um comportamento implícito reduz invariavelmente sua previsibilidade.

<a href="http://um_encurtador_de_url_qualquer/Jh6&kJzip">Arquivo PDF</a>
<a href="http://meu_servidor/stream">Arquivo ZIP</a>

No primeiro caso, temos um falso positivo; no segundo, um falso negativo.

Immutability

Imutáveis são aqueles objetos que, depois de criados, não podem ter seus estados alterados.

Não vejo princípio mais útil que este para um CSS de larga escala.

Componentes imutáveis são confiáveis, são agnósticos à sua localização no DOM, são previsíveis e simplificam o seu entendimento. Quando uma classe é global mas não tem o intuito de ser global (que é o caso em questão), ela pode desfazer essa imutabilidade.

Aqui, o componente .Callout--special foi alterado por um agente externo, fora de seu escopo e de seu alcance.

Open/Closed (adaptado à realidade CSS)

As definições devem ser permitir extensões (open), mas coibir modificações (closed).

Imagine que você seja um consumer de duas bibliotecas css.

  • superultra-2.2.2.css, que comporta o trecho sugerido; e
  • framework_embutido_no_CMS-9.9.9.css, que comporta o .Callout.

Das duas uma: (i) ou você modifica um desses arquivos (que não são seus) e mantém um fork, ou (ii) cria um arquivo .css e adiciona a seguinte linha:

/* o odiado !important reativo */
.Callout--special:before {
  content: 'olá!'!important;
}

Acabamos de modificar dois comportamentos: aquele que deveria ser global (pois deixará de ser \E004) e o específico (que não deveria ser !important).

Alternativas

Seguem algumas alternativas. Elas podem parecer pouco práticas, mas, na minha opinião, são flexíveis, reutilizáveis e de fácil entendimento.

<a href="/meu-arquivo.zip">
  <span class="glyphicon glyphicon-package"></span>
  Arquivo
</a>

<a class="Callout Callout--pdf" href="/meu-relatorio.pdf">
  Relatório
</a>

<a class="callout callout-pdf" href="/meu-relatorio.pdf">
  Relatório
</a>

Desafios

Sintaxe

É o principal desafio. Eu nunca imaginaria que uma letra maiúscula causaria tanta controvérsia.

😀 p ~ li > ul + p > div > a ~ b:first-child(:not(div + p)) { ... }

😀 #id { ... }

😱 .Callout { ... }

Confusão de conceitos

Dizem que ‘essa classe não é semântica!!!’, mas veneram o Bootstrap.

  • .row é semântica?
  • .col-offset-xs-12 .col-pull-sm-5 é semântica?
  • .pull-right .hidden-xs é semântica?
  • .clearfix é semântica?
  • <nav class="nav navbar navbar-nav navbar-default collapse navbar-collapse"/> é semântica?

Quer saber o que eu acho? Sigo o relator:

“(…) Not all semantics need to be content-derived. Class names cannot be ‘unsemantic’. Whatever names are being used: they have meaning, they have purpose” – Nicolas Gallagher

Estamos em 2016. Aquela época de CSS Zen Garden já passou. Há 13 anos!!!

É isso

Escrevi demais. E nem abordei todos os princípios aplicáveis, tais como:

  • Don’t repeat yourself
  • Single Responsability Principle
  • KISS

Temos uma variedade de portais, cada qual com seu framework, cada qual com seu grupo de desenvolvedores. É difícil implementar uma regra geral que se encaixe em todos os workflows. Não acredito que essa abordagem apresentada seja definitiva, mas é um começo.

Referências

  • Nicole Sullivan [OOCSS] @stubbornella
  • Lea Verou [Secrets of CSS ] @leaverou
  • Jonathan Snook [SMACSS] @snookca
  • Harry Roberts [inuitcss] @csswizardry
  • Nicolas Gallagher [suitcss] @necolas
  • Yandex [BEM] @bem_en

mosaaaico

30 Mar 2016

Windows

Pré-requisitos

git

Em vez do git-bash, recomendo o terminal cmder. Baixe a versão full e descompacte em algum diretório no disco rígido (diretamente em C:\cmder é uma boa pedida!)

node

Da mesma forma que o Java precisa da JRE; o C#, do .Net CLR; e o python do CPython; o javascript também exige um runtime: o Node.js.

A instalação é bem simples: baixe a versão stable adequada a sua arquitetura (32 ou 64 bits) em https://nodejs.org/en/download/stable/.

npm

O npm é o gerenciador de pacotes do Node. É instalado automaticamente junto com o runtime.

Assim como qualquer outro gerenciador de pacotes, é lento. Se o Maven baixa metade da internet, não se preocupe: o npm vai baixar a outra.

Se preferir, utilize como registro uma instância do local-npm disponível em http://mp1522:5080:

npm set registry http://mp1522:5080

Para reverter:

npm set registry https://registry.npmjs.org

Proxy

Você tá atrás de um proxy? Cara, que azar.

Só tem uma coisa pior que estar atrás de um proxy: estar atrás de um proxy autenticado.

😭

É a vida.

Execute (win + R) SystemPropertiesAdvanced. Em Variáveis de Sistema, adicione as variáveis de sistema HTTP_PROXY e HTTPS_PROXY.

Se o teu proxy é autenticado, ele precisa estar na forma http://user:password@server:port. Mas calma, talvez você não precise colocar a sua senha ali. Veja se existe alguma conta de desenvolvimento disponível.

Ah, a vantagem de utilizar uma instância do local-npm como registro, é que esse passo pode ser desconsiderado.

grunt e yo

O grunt é uma ferramenta de build. É como se fosse um make, um ant, um rake ou as recipes do buildout.

Já o yo (Yeoman) é um gerador de projetos. Ele monta a estrutura de arquivos e diretórios de acordo com um template. É análogo aos archetypes do Maven ou o paster do python.

Para instalar o grunt, o yo e o template do mosaaaico, execute:

npm -g install yo grunt-cli generator-mosaaaico

crie um novo projeto

mkdir meu_projeto_novo
cd meu_projeto_novo
yo mosaaaico

Feito. A seguinte estrutura será gerada:

.
├── app
│   ├── assets
│   │   └── logo.svg
│   ├── index.jade
│   ├── less
│   │   ├── main.less
│   │   ├── utils
│   │   │   └── variables.less
│   │   └── vendors
│   │       ├── bootstrap.less
│   │       └── senado.less
│   ├── scripts
│   │   └── main.js
│   └── senado.jade
├── grunt
│   ├── aliases.yaml
│   ├── autoprefixer.js
│   ├── clean.js
│   ├── concurrent.js
│   ├── connect.js
│   ├── copy.js
│   ├── cssmin.js
│   ├── jade.js
│   ├── less.js
│   └── watch.js
├── Gruntfile.js
└── package.json

Para rodar o servidor embutido, execute no diretório grunt dev. A porta escolhida por padrão é a 8000. Se precisar alterar, passe o argumento --port=.

A interface utilizada é a 127.0.0.1. Se precisar liberar acesso externo, passe o argumento --allow-remote.

grunt dev --port=9090 --allow-remote

DisplayFeatures

04 Mar 2016

Habilitar o DisplayFeatures do Google Analytics

Exigências para utilização do Display Features

Cookies

Os cookies são informações enviadas do cliente (um browser) para um o servidor de rede (um site da web). Geralmente, ficam armazenados no navegador por um período de tempo determinado e são utilizados para salvar informações de uma visita ou sessão.

Os cookies são considerados primários quando as informações são enviadas para o mesmo servidor de rede que disponibiliza e hospeda o site.

Exemplo: quando visitamos www12.senado.gov.br o browser recebe um cookie de nome __ac. A partir daí, toda requisição feita a uma página no domínio www12.senado.gov.br, e somente neste domínio, enviará de volta para o servidor o valor desse cookie.

Já os cookies de terceiros, enviam informações para um servidor distinto daquele que foi visitado. Exemplo: quando visitamos g1.globo.com, algumas informações coletadas durante esta sessão são enviadas para o azure-2mobile.netdna-ssl.com.

O administrador do site não possui controle dos dados transmitidos pelos cookies de terceiros, tampouco possui conhecimento sobre como esses dados são coletados ou utilizados.

DisplayFeatures

O Google Anlytics é um sistema que permite a coleta de dados estatísticos relacionados ao tráfego em um site da web. Essa coleta é feita por meio de um Tracker, que nada mais é do que um trecho de código inserido em todas as páginas que se queira analisar. A cada ação de um visitante em um site habilitado, o Tracker envia para os servidores do Google algumas informações inerentes à própria visita, como, por exemplo:

  • o título da página acessada
  • o tempo em que o usuário está ativo
  • o dispositivo utilizado
  • como o visitante chegou ao site

Os cookies armazenados nessa situação são primários (são enviados apenas para o servidor que hospeda o site habilitado).

Além das métricas de tráfego, o Google Analytics também permite também a coleta de informações demográficas e de informações de interesse dos visitantes de um site habilitado. Este recurso é chamado de DisplayFeatures.

Com o DisplayFeatures habilitado, ao invés dos dados transitarem pela rede do Analytics, eles serão transmitidos pela rede de publicidade do Google, o DoubleClick (via cookies de terceiros).

Para aderir ao DisplayFeatures, o Google exige que seja notificado aos seus usuários (i) quais os recursos de publicidade do Google estão em uso, (ii) como os cookies primários e os cookies de terceiros são utilizados, e (iii) como os visitantes podem desabilitar o rastreio de comportamento durante as sessões no site habilitado (opt-out).

Além da notificação, também é exigido que não haja cruzamento de informações que possam identificar pessoalmente um visitante com informações coletadas pelo DisplayFeatures, a menos que o visitante expressamente concorde com a coleta (opt-in).

Exemplos de Políticas de Privacidade

Sites que utilizam o Analytics sem o DisplayFeatures:

Sites que utilizam o Analytics com o DisplayFeatures mas não possuem política de privacidade adequada: