24 outubro 2019

Michelly Oliveira

Diferença UX e UI

 



Mas não é tudo a mesma coisa? Talvez seja, ou será que não?
A confusão entre as áreas de UX e UI é muito comum por uma questão de nomenclatura e porque estão profundamente ligadas por processos de trabalho e conhecimentos que são comuns entre elas.

USER INTERFACE – UI

Para entender essa diferença, é preciso saber que UI ou interface do usuário é por onde o usuário interage com o seu produto, todas as partes “físicas” que possibilitam que uma determinada ação de seu produto seja realizada.
A interface do usuário (UI) é responsável pela parte visual de um projeto, por onde o usuário interage com um determinado aplicativo, programa de computador, rede social, site ou até mesmo algum produto físico. É tudo aquilo que é perceptível visualmente em alguma plataforma e leva o usuário a uma interação positiva. Pode ser um botão, um menu diferente ou até mesmo um som.
O papel de um profissional de UI é guiar o usuário de forma simples, ao invés de complicar sua experiência criando um labirinto. Sendo assim, ele deve recomendar uma ação específica ao invés de mostrar várias com a mesma finalidade, deixar o caminho do usuário mais fácil para desfazer alguma interação, deixar bem claro o que pode ser clicado e selecionado, utilizar mais contraste do que similaridade e utilizar menos campos de preenchimento nos formulários, por exemplo.

USER EXPERIENCE – UX

Já UX ou experiência do usuário é a parte emocional, o quão amigável essa interação pode ser e os sentimentos que ele tem ao realiza-la.  Ela engloba toda a estratégia de design e desenvolvimento de um produto, como sua usabilidade, seu conteúdo e a arquitetura de informação.
É uma ciência que pensa exclusivamente na relação de um produto com o usuário, buscando torná-la mais natural e simples. A experiência do usuário (UX), abrange todos os pontos de contato entre a empresa e o consumidor, desde o anúncio que o levou até o website, até a embalagem em que a camiseta foi entregue, o produto em si, o atendimento por telefone, as interações nas redes sociais da marca, entre outros elementos. A experiência, neste caso, inclui valores afetivos que compõem a percepção do usuário, em relação à marca.
O UX design pode ser responsável por evitar 80% dos erros e por auxiliar de forma direta o trabalho de SEO do website. Ele também é responsável por um aumento de 80% nos KPIs. (key performance indicators, ou Indicadores-chave da performance do projeto). E, no caso de E-Commerces, adaptar a plataforma para dispositivos móveis com base na experiência do usuário pode gerar um aumento de até 70% nas vendas.

Ou seja, para que o seu produto possa causar uma boa impressão é importante que toda a jornada do usuário, hierarquia de informação e todos os pontos de contato tenham sido pensados com muito cuidado pelo UX Designer e que o UI Designer consiga apresentar essas informações de maneira clara e visualmente interessante.
Mas, se ainda há dúvidas pairando sobre a sua cabeça, talvez essa imagem possa ajudar:


QUAL O MOTIVO DESSA CONFUSÃO?

O motivo que é responsável pela maioria das dúvidas que as pessoas têm em relação às duas áreas, está relacionado à falta de compreensão dos processos que são destinados a cada uma delas. Não vou me ater aos processos específicos, pois temos dois posts aqui no blog que falam sobre cada especialidade de UX e UI
Uma imagem muito comum quando falamos da diferença entre UI e UX é um modelo criado por Dan Saffer, que deixa bem clara a relação de qual área pertence à outra.

Mas o que você precisa saber é que UX abrange processos como pesquisa, análise de dados, entrevistas com usuários, testes de usabilidade e também fazem parte deles o design de interface e o visual design que são processos de UI.
Se ainda tiver dúvidas sobre as áreas de UX e UI ou se tiver informações a acrescentar, manda pra gente.
Até a próxima!






Fonte: https://www.raffcom.com.br/blog/qual-a-diferenca-entre-ux-e-ui/

23 outubro 2019

Michelly Oliveira

WordPress pede credenciais FTP para atualizar

 



Tive esse problema recentemente e ao procurar a solução, consegui resolver o problema seguindo as informações abaixo:
Não é a primeira vez que me acontece numa instalação de WordPress ao atualizar um plugin ou o próprio WordPress, através do painel de administração do WordPress, pedir dados de acesso FTP.
A mensagem de erro exata é a seguinte:
Para executar a ação solicitada, o WordPress precisa de aceder ao seu servidor. Por favor insira as suas credenciais de FTP para continuar. Se não se lembra das suas credenciais, deverá contactar o seu serviço de alojamento web.
O primeiro passo para resolver é verificar se o utilizador que corre o servidor Web (Apache, IIS, Nginx etc…) tem permissões de escrita nas pastas do WordPress.
No entanto este problema geralmente fica resolvido quando adicionamos a linha seguinte no wp-config.php:
define('FS_METHOD', 'direct');
Pode ser colocado em qualquer lugar do ficheiro desde que fique acima da linha:
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
Fonte: https://antoniocampos.net/2018/03/15/wordpress-pede-credenciais-ftp-ao-atualizar/

29 agosto 2019

Michelly Oliveira

Bitbucket: Unauthorized - Fatal: Could not read from remote repository

 



Recentemente estava tentando sincronizar meu repositório local com o remoto, no Bitbucket (https://bitbucket.org), utilizando o Sourcetree (https://www.sourcetreeapp.com/) via HTTPS e, por algum motivo ainda não identificado, o mesmo ficou abrindo o alerta de preenchimento de senha infinitas vezes, mesmo já estando conectado e inserindo a senha correta.

Fui então tentar a conexão via SSH. Criei a chave, inseri no Sourcetree e também no repositório do Bitbucket, conforme próprio tutorial do Bitbucket.

Finalmente consegui baixar o repositório remoto para a pasta local (pull), mas ao tentar sincronizar o local com o remoto (push) me apareceu o famigerado:
Can't git push to Bitbucket: Unauthorized - fatal: Could not read from remote repository 
Voltando a novas pesquisas de como resolver esse problema, acabei descobrindo que a chave SSH não deve ser inserida no repositório, mas sim no usuário. Pois a chave inserida no repositório dá acesso apenas à leitura do mesmo.

Dessa forma, resolvi escrever esse pequeno tutorial de como fazer Sourcetree e Bitbucket funcionarem utilizando o acesso SSH.

Aqui irei descrever como:
  1. Criar a chave SSH
  2. Inserir a chave SSH no Sourcetree
  3. Inserir a chave SSH no Usuário do Bitbucket.

Os ambientes/sistemas utilizados neste tutorial foram: Windows 10, Sourcetree ver.: 3.2.6 com o Putty Key Generator Release 0.70.2-Sourcetree e o Bitbucket cuja última release foi em 13/08/2019.

Passo 1 - Criar Chave SSH

O primeiro passo é  a criação do par de chaves SSH. Caso você já possua um par de chaves, passe para o segundo passo (Inserir Chave SSH no Sourcetree).

  1. No Sourcetree, acesse a opção do menu "Tools -> Create or import SSH Keys"
  2. No aplicativo que abrir (Putty Key Generator), clique no botão "Generate", será exibida uma barra de progresso. Para que a criação da chave seja mais rápida e efetiva, movimente o mouse aleatoriamente enquanto a barra é preenchida.
  3. No campo "Key passphrase" insira uma senha para este par de chaves (guarde a senha com cuidado, a utilizaremos futuramente).
  4. No campo "Confirm passphrase" insira a mesma senha do campo anterior.
  5. Após a criação da chave, clique no botão "Save public key", para salvar em um local seguro a chave pública criada.
  6. Após salvar a chave pública, clique no botão "Save private key", para salva a chave privada criada.

Finalizamos a criação do par de chaves, agora vamos inserir a chave SSH no Sourcetree.

Passo 2 - Inserir Chave SSH no Sourcetree

Após a criação do par de chaves, ou caso você já tenha uma chave, é chegado o momento de inserir a chave no Sourcetree.

  1. No Sourcetree, acesse a opção do menu "Tools -> Launch SSH Agent..."
  2. Caso já exista alguma chave cadastrada, será solicitada a senha da mesma. Caso contrário, será exibida a janela do aplicativo Pageant Key List
  3. No Pageant Key List, clique no botão "Addkey".
  4. Será aberta uma janela do Explorer para que você selecione a chave privada salva no passo 1. Selecione o arquivo.
  5. Insira a senha do par de chaves. Feche a janela no botão  "Close"

Pronto, agora vamos inserir a chave SSH no Bitbucket.

Passo 3 - Inserir Chave SSH no Bitbucket

Agora vamos para o passo final que é inserir a chave no Bitbucket. Meu Bitbucket está em inglês, ok.

  1. No Bitbucket, acesse seu perfil de usuário. Clique no seu avatar (foto) que encontra-se no canto inferior esquerdo e selecione a opção "View Profile".
  2. No menu lateral que aparece na nova tela, clique em "Settings".
  3. No novo menu lateral da tela Settings, selecione "SSH keys" que encontra-se na categoria "Security".
  4. Na nova tela, clique no botão "Add key".
  5. No modal que abrir, insira um nome para a sua chave, no campo "Label"
  6. Depois, copie do program a Putty Key Generator (Passo 1) o conteúdo do campo "Key" e cole no campo "Key" do modal do Bitbucket.
  7. Finalize clicando no botão "Add key".
  8. A lista de chaves sera atualizada.

Não esqueça ou perca a senha da chave SSH, ela será necessária quando for dar PUSH nos projetos que utilizam a chave.

Assim finalizamos o processo para fazer com que o Sourcetree utilize SSH para realizarmos a sincronização de nossos repositórios.



27 junho 2018

Michelly Oliveira

Guia Completo de Prototipação em UX Design

 

O que é Prototipação em UX Design?


Prototipação é uma técnica muito utilizada na área de UX design para criar e validar soluções de forma rápida. Geralmente, os protótipos são criados depois da fase de pesquisa com usuários ou benchmarking. Assim, você já conhece a dor do seu cliente e tem hipóteses para resolvê-la.
Os protótipos podem ter basicamente 3 níveis de fidelidade: baixa, média e alta. Isso tem relação com a proximidade do resultado final.

Link para o artigo: https://medium.com/awari-mentoria/guia-completo-de-prototipa%C3%A7%C3%A3o-em-ux-design-570b16b28788

29 novembro 2016

Michelly Oliveira

Acrescentar FontAwesome em projeto Angular2

 


O projeto Angular2 foi criado usando CLI, portanto os passos abaixo referem-se aos processos de inserção do FontAwesome em projetos desse tipo.

Passo 1

- No Terminal, digite:
    npm install font-awesome --save

--Isto irá fazer o download dos arquivos do plugin para a pasta node_modules e acrescentar a entrada do mesmo no arquivo package.json

Passo 2

- No arquivo angular-cli.json localize os arrays "styles[]" e "addons[]" e adicione as referências do font-awesome neles, como:

    "apps": [
          {
             "root": "src",
             "outDir": "dist",
             ....
             "styles": [
                "styles.css",
                "../node_modules/bootstrap/dist/css/bootstrap.css",
                "../node_modules/font-awesome/css/font-awesome.css" // -here webpack will automatically build a link css element out of this!?
             ],
             ...
         }
       ], 
    "addons": [
        "../node_modules/font-awesome/fonts/*.+(otf|eot|svg|ttf|woff|woff2)" // - here
    ],


Passo 3

- Acrescente os ícones do font-awesome onde necessário em seu código html:

    <i class="fa fa-american-sign-language-interpreting fa-5x" aria-hidden="true"> </i>  

Passo 4

- Inicie ( ou reinicie) o servidor para que as alterações sejam aplicadas.

    ng serve


18 novembro 2016

Michelly Oliveira

Sass vs. LESS vs. Stylus: Batalha dos Pré-processadores

 

Introdução

Pré-processadores CSS3 são linguagens criadas com um único propósito de adicionar funcionalidades legais e criativas para o CSS sem quebrar a compatibilidade entre browsers. Os pré-processadores disponibilizam milhares de funcionalidades, e nesse artigo iremos falar sobre as mais utilizadas e conhecidas e algumas nem tanto conhecidas. Vamos começar:

Sintaxe

A parte mais importante ao escrever códigos utilizando um pré-processador é entender a sua sintaxe. Felizmente para nós, a sintaxe é (ou pode ser) idêntica à do CSS puro para os três pré-processadores.

Sass e LESS

Ambos utilizam o a sintaxe padrão do CSS. Isso faz com que seja extremamente fácil converter um arquivo CSS já existente para qualquer um deles. Sass utiliza arquivos com extensão .scss e LESS com extensão .less. Uma configuração básica de um arquivo Sass ou LESS pode ser como abaixo:

/* style.scss ou style.less */
h1 {
color: #0982c1;
}

Como você pode ter notado, isso é apenas CSS puro, que compila perfeitamente em ambos pré-processadores (Sass e LESS).

É importante notar que Sass também tem uma sintaxe mais antiga, que omite ponto e vírgula e as chaves. Ainda pode ser usado, mas como é uma sintaxe antiga, não iremos utilizá-la depois deste exemplo. A sintaxe utiliza arquivos com a extensão .sass e são da seguinte maneira:

/* style.sass */
h1
color: #0982c1

Observação pessoal: Essa sintaxe não é por causa de ser mais antiga e sim pois no início o Sass era parte de um outro pré-processador chamado Haml criado por desenvolvedores Ruby, e por causa disso as folhas de estilo escritas com Sass utilizavam uma sintaxe como a do Ruby, sem chaves, ponto e vírgula e controlado por identação.

Stylus

A sintaxe para o Stylus é muito mais adaptável. Utiliza arquivos com extensão .styl, aceita a sintaxe padrão do CSS, porém também aceita algumas variações onde chaves, dois-pontos e ponto e vírgula são todos opcionais. Por exemplo:

/* style.styl */
h1 {
color: #0982c1;
}
/* omitindo chaves */
h1
color: #0982c1;

/* omitindo dois-pontos e ponto e vírgula
h1
color: #0982c1
Utilizar diferentes variações em um mesmo arquivo também é válido, então o seguinte código seria compilado sem erros.

h1 {
color #0982c1
}
h2
font-size: 1.2em


Variáveis

Variáveis podem ser declaradas e usadas através das folhas de estilo. Elas podem ter qualquer valor que seja um valor em CSS (por exemplo: cores, números [unidades também], ou texto), e podem ser referenciadas em qualquer lugar das nossas folhas de estilo.

Sass

Variáveis em Sass tem seu nome começado o símbolo “$” e o nome e o seu valor são separados com dois-pontos, assim como uma propriedade CSS.

$mainColor: #0982c1;
$siteWidth: 1024px;
$borderStyle: dotted;

body {
color: $mainColor;
border: 1px $borderStyle $mainColor;
max-width: $siteWidth;
}

LESS

Varíaves em LESS são praticamente iguais as variáveis no Sass, exceto por começarem seus nomes com o símbolo “@”.

@mainColor: #0982c1;
@siteWidth: 1024px;
@borderStyle: dotted;

body {
color: @mainColor;
border: 1px @borderStyle @mainColor;
max-width: @siteWidth;
}

Stylus

Variáveis em Stylus não precisam começar com nenhum símbolo, porém ele permite a utilização do símbolo “$”. Como sempre, o ponto e vírgula para finalizar não é necessário, mas um sinal de igual entre o nome da variável e seu valor é. Uma coisa importante para se notar é que na versão 0.22.4 do Stylus variáveis com nome começados com o símbolo “@” são compiladas, porém não aplicam seu valor quando referenciadas. Em oturas palavras, não faça isso.

mainColor = #0982c1;
siteWidth = 1024px;
$borderStyle = dotted;

body
color mainColor
border 1px $borderStyle mainColor
max-width siteWidth

CSS Compilado

Cada um dos arquivos acima irão compilar no mesmo CSS. Você pode usar sua imaginação para ver quão úteis variáveis podem ser. Não precisaremos mais ao mudar uma cor reescrever a mesma vinte vezes, ou querer mudar a largura de nosso site e ter de procurar por todo o site para fazer isso. Aqui está o CSS depois de compilado:

body {
color: #0982c1;
border: 1px dotted #0982c1;
max-width: 1024px.
}

Aninhamento

Se precisarmos referenciar múltiplos elementos com o mesmo pai em nosso CSS, pode ser entediante ficar digitanto o pai toda vez.

section {
margin: 10px;
}
section nav {
height: 25px;
}
section nav a {
color: #0982c1;
}
section nav a:hover {
text-decoration: underline;
}

Ao invés disso, usando um pré-processador, podemos escrever os seletores filhos dentro das chaves do elemento pai. O símbolo “&” é usado para referenciar o seletor pai.

Sass, LESS e Stylus

Todos os três pré-processdores utilizam a mesma sintaxe para aninhar seletores.

section {
margin: 10px;

nav {
height: 25px;

a {
color: #0982c1;

&:hover {
text-decoration: underline;
}
}
}
}

CSS Compilado

Abaixo está o CSS compilado do código escrito acima. Está exatamente igual ao mostrado no começo – que conveniente!

section {
margin: 10px;
}
section nav {
height: 25px;
}
section nav a {
color: #0982c1;
}
section nav a:hover {
text-decoration: underline;
}

Mixins

Mixins são funções que permitem reusar propriedades através de nossas folhas de estilo. Ao invés de procurar por todas nossas folhas de estilo e mudar uma propriedade várias vezes, podemos apenas mudar dentro de nosso mixin. Isso pode ser realmente útil para estilização de elementos específicos e para “vendor prefixes” (moz-*, o-*, etc). Quando os mixins são chamados de dentro de um seletor CSS, os argumentos são reconhecidos e os estilos dentro do mixin são aplicados ao seletor.

Sass

/* Mixin em Sass chamado error com argumento $borderWidth opcional, caso não seja fornecido, utiliza o valor padrão de 2px; */
@mixin error($borderWidth: 2px) {
border: $borderWidth solid #f00;
color: #f00;
}

.generic-error {
padding: 20px;
margin: 4px;
@include error(); /* Aplica estilos do mixin error */
}
.login-error {
left: 12px;
position: absolute;
top: 20px;
@include error(5px); /* Aplica estilos do mixin error com argumento $borderWidth = 5px */
}

LESS

/* Mixin em LESS chamado error com argumento $borderWidth opcional, caso não seja fornecido, utiliza o valor padrão de 2px; */
.error(@borderWidth: 2px) {
border: @borderWidth solid #f00;
color: #f00;
}

.generic-error {
padding: 20px;
margin: 4px;
.error(); /* Aplica estilos do mixin error */
}
.login-error {
left: 12px;
position: absolute;
top: 20px;
.error(5px); /* Aplica estilos do mixin error com argumento $borderWidth = 5px */
}

Stylus

/* Mixin em Stylus chamado error com argumento $borderWidth opcional, caso não seja fornecido, utiliza o valor padrão de 2px; */
error(borderWidth = 2px) {
border: borderWidth solid #f00;
color: #f00;
}

.generic-error {
padding: 20px;
margin: 4px;
error(); /* Aplica estilos do mixin error */
}
.login-error {
left: 12px;
position: absolute;
top: 20px;
error(5px); /* Aplica estilos do mixin error com argumento $borderWidth = 5px */
}

CSS Compilado

Todos pré-processadores irão compilar o mesmo código abaixo:

.generic-error {
padding: 20px;
margin: 4px;
border: 2px solid #f00;
color: #f00;
}
.login-error {
left: 12px;
position: absolute;
top: 20px;
border: 5px solid #f00;
color: #f00;
}

Herança

Quando estamos escrevendo CSS da velha maneira, nós usaríamos o seguinte código para aplicar o mesmo estilo para múltiplos elementos de uma só vez:

p,
u,
ol {
/* estilos aqui */
}

Isso funciona perfeitamente, mas se depois precisássemos de estilizar os elementos individualmente, outro seletor deveria ser criado para cada um e rapidamente poderia ficar cada vez mais bagunçado e difícil de manter. Podemos utilizar herança para resolver isso. Herança é a habilidade de outros seletores CSS herdarem as propriedades de outro seletor.

Sass e Stylus

.block {
margin: 10px 5px;
padding: 2px;
}

p {
@extend .block; /* Herda estilos do seletor '.block' */
border: 1px solid #eee;
}
ul, ol {
@extend .block; /* Herda estilos do seletor '.block' */
color: #333;
text-transform: uppercase;
}

CSS Compilado (Sass e Stylus)

.block, p, ul, ol {
margin: 10px 5px;
padding: 2px;
}
p {
border: 1px solid #eee;
}
ul, ol {
color: #333;
text-transform: uppercase;
}

LESS

LESS não tem suporte a herança de estilos como Sass e Stylus. Ao invés de adicionar diversos seletores para um grupo de propriedades, ele trata herança como um mixin sem argumentos e importa os estilos para dentro de seus próprios seletores. O problema disso é que propriedades são repetidas em sua folha de estilo compilada. Abaixo segue como deve-se utilizar:

.block {
margin: 10px 5px;
padding: 2px;
}

p {
.block; /* Herda estilos do seletor '.block' */
border: 1px solid #eee;
}
ul, ol {
.block; /* Herda estilos do seletor '.block' */
color: #333;
text-transform: uppercase;
}

Observação pessoal: Como mencionado nos comentários, o LESS tem suporte a herança e pode ser feita com a seguinte sintaxe:

p {
        &:extend(.block);
}

CSS Compilado (LESS)

.block {
margin: 10px 5px;
padding: 2px;
}
p {
margin: 10px 5px;
padding: 2px;
border: 1px solid #eee;
}
ul,
ol {
margin: 10px 5px;
padding: 2px;
color: #333;
text-transform: uppercase;
}

Como você pode ver, os estilos do seletor .block foram inseridas nos seletores que queríamos aplicar a herança. É importante notar que a prioridade das propriedades pode se tornar um problema, então devemos ter bastante cautela.

Importação

Na comunidade CSs, importar CSS é visto com maus olhos por utilizar diversas chamadas HTTP. Importar com um pré-processador funciona de forma diferente no entanto. Se você importar um arquivo com qualquer um dos três pré-processadores, ele irá literalmente pegar todo o conteúdo do arquivo durante a importação e gerar apenas um arquivo. Lembre-se que arquivos .css comuns importados compilam com o código:

@import "file.css";

Lembre-se também que mixins e variáveis podem ser importadas e usadas em sua folha de estilo principal. Importação faz com que possamos criar arquivos separados para uma melhor organização.

Sass, LESS e Stylus
/* arquivo.{extensao} */
body {
background: #eee;
}
@import "reset.css";
@import "arquivo.{extensao}";

p {
background: #0982c1;
}

CSS Compilado

@import "reset.css";
body {
background: #eee;
}
p {
background: #0982c1;
}

Funções de Cores

Funções de cores são funções nativas que transformam uma cor por compilação. Podem ser extremamente úteis para criar gradientes, escurecer cores no “hover” de elementos e muito mais.

Sass

lighten($color, 10%); /* retorna uma cor 10% mais clara que $color */
darken($color, 10%);  /* retorna uma cor 10% mais escura $color */

saturate($color, 10%);   /* retorna uma cor 10% mais saturada que $color */
desaturate($color, 10%); /* retorna uma cor 10% menos saturada que $color */

grayscale($color);  /* retorna $color na escala de cinza */
complement($color); /* retorna cor complementar de $color */
invert($color);     /* retorna cor inversa de $color */

mix($color1, $color2, 50%); /* mistura $color1 com $color2 com um peso de 50% */

Essas é apenas uma pequena lista de funções de cores disponíveis no Sass. A lista completa das funções de cores disponíveis no Sass pode ser encontrada na documentação do Sass.

Funções de cores podem ser usadas em qualquer lugar que uma cor é válida no CSS. Veja um exemplo:

$color: #0982C1;

h1 {
background: $color;
border: 3px solid darken($color, 50%);
}

LESS

lighten(@color, 10%); /* retorna uma cor 10% mais clara que @color */
darken(@color, 10%);  /* retorna uma cor 10% mais escura @color */

saturate(@color, 10%);   /* retorna uma cor 10% mais saturada que @color */
desaturate(@color, 10%); /* retorna uma cor 10% menos saturada que @color */

spin(@color, 10); /* retorna uma cor 10 graus acima na matiz/tonalidade que @color */
spin(@color, -10); /* retorna uma cor 10 graus abaixo na matiz/tonalidade que @color */

mix(@color1, @color2); /* mistura @color1 com @color2 */

A lista de todas as funções disponíveis no LESS pode encontrada na documentação LESS.

Veja um exemplo de como usar uma função de cores no LESS:

@color: #0982C1;

h1 {
background: @color;
border: 3px solid darken(@color, 50%);
}

Stylus

lighten(color, 10%); /* retorna uma cor 10% mais clara que 'color' */
darken(color, 10%);  /* retorna uma cor 10% mais escura 'color' */

saturate(color, 10%);   /* retorna uma cor 10% mais saturada que 'color' */
desaturate(color, 10%); /* retorna uma cor 10% menos saturada que 'color' */

A lista completa de todas funções de cores disponíveis no Stylus pode ser encontrada na documentação Stylus.

Veja um exemplo de como usar uma função de cores no Stylus:

color = #0982C1

h1
background color
border 3px solid darken(color, 50%)

Operações

Fazer cálculos no CSS é bastante útil e agora totalmente possível. É bem simples e é dessa maneira que fazemos:

Sass, LESS e Stylus

body {
margin: (14px/2);
top: 50px + 100px;
right: 100px - 50px;
left: 10 * 10;
}

Aplicações Práticas

Nós falamos de diversas funcionalidades e novas coisas que pré-processadores podem fazer, mas não mostramos nada na prática ainda. Veja uma pequena lista de aplicações no mundo real em que um pré-processador é um salva-vidas.

Vendor Prefixes

Essa é uma das principais razões para se usar um pré-processador e por um motivo bom – economia gigante de tempo e lágrimas. Criar um mixin para cuidar dos vendor prefixes é fácil e nos salva de uma codificação repetitiva e dolorosa. Veja como fazer:

Sass

@mixin border-radius($values) {
-webkit-border-radius: $values;
-moz-border-radius: $values;
border-radius: $values;
}

div {
@include border-radius(10px);
}

LESS

.border-radius(@values) {
-webkit-border-radius: @values;
-moz-border-radius: @values;
border-radius: @values;
}

div {
.border-radius(10px);
}


Stylus

border-radius(values) {
-webkit-border-radius: values;
-moz-border-radius: values;
border-radius: values;
}

div {
border-radius(10px);
}

CSS Compilado

div {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
border-radius: 10px;
}

Texto 3D

Simular um texto 3D utilizando diversos text-shadows é uma grande ideia. O único problema é que mudar a cor depois de criar é difícil e incômodo. Usando mixins e funções de cores, podemos criar um texto 3D e mudar sua cor sem nenhuma dificuldade.

Sass

@mixin text3d($color) {
color: $color;
text-shadow: 1px 1px 0px darken($color, 5%),
2px 2px 0px darken($color, 10%),
3px 3px 0px darken($color, 15%),
4px 4px 0px darken($color, 20%),
4px 4px 2px #000;
}

h1 {
font-size: 32pt;
@include text3d(#0982c1);
}

LESS

.text3d(@color) {
color: @color;
text-shadow: 1px 1px 0px darken(@color, 5%),
2px 2px 0px darken(@color, 10%),
3px 3px 0px darken(@color, 15%),
4px 4px 0px darken(@color, 20%),
4px 4px 2px #000;
}

span {
font-size: 32pt;
.text3d(#0982c1);
}

Stylus

text3d(color)
color: color
text-shadow: 1px 1px 0px darken(color, 5%), 2px 2px 0px darken(color, 10%), 3px 3px 0px darken(color, 15%), 4px 4px 0px darken(color, 20%), 4px 4px 2px #000
span
font-size: 32pt
text3d(#0982c1)

Escolhi escrever os “text-shadows” do Stylus em apenas uma linha pois omiti as chaves.

CSS Compilado

span {
font-size: 32pt;
color: #0982c1;
text-shadow: 1px 1px 0px #097bb7, 
2px 2px 0px #0875ae, 
3px 3px 0px #086fa4, 
4px 4px 0px #07689a, 
4px 4px 2px #000;
}

Resultado Final






Colunas

Usar operações numéricas e variáveis para colunas é uma ideia que tive da primeira vez que estava brincando com pré-processadores CSS. Declarando a largura desejada em uma variável, podemos facilmente alterá-la sem precisar de nenhum cálculo mental. Veja como fazer:

Sass

$siteWidth: 1024px;
$gutterWidth: 20px;
$sidebarWidth: 300px;

body {
margin: 0 auto;
width: $siteWidth;
}
.content {
float: left;
width: $siteWidth - ($sidebarWidth+$gutterWidth);
}
.sidebar {
float: left;
margin-left: $gutterWidth;
width: $sidebarWidth;
}

LESS

@siteWidth: 1024px;
@gutterWidth: 20px;
@sidebarWidth: 300px;

body {
margin: 0 auto;
width: @siteWidth;
}
.content {
float: left;
width: @siteWidth - (@sidebarWidth+@gutterWidth);
}
.sidebar {
float: left;
margin-left: @gutterWidth;
width: @sidebarWidth;
}

Stylus

siteWidth = 1024px;
gutterWidth = 20px;
sidebarWidth = 300px;

body {
margin: 0 auto;
width: siteWidth;
}
.content {
float: left;
width: siteWidth - (sidebarWidth+gutterWidth);
}
.sidebar {
float: left;
margin-left: gutterWidth;
width: sidebarWidth;
}

CSS Compilado

body {
margin: 0 auto;
width: 1024px;
}
.content {
float: left;
width: 704px;
}
.sidebar {
float: left;
margin-left: 20px;
width: 300px;
}

Peculiaridades Notáveis

Existem algumas peculiaridades ao usar um pré-processador CSS. Irei falar de algumas engraçadas, mas se você está realmente interessado em encontrar todas elas eu recomendo você vasculhar toda a documentação, ou melhor, começar a usar um pré-processador na sua codificação diária.

Relatório de Erros

Se você já escreveu CSS por uma boa quantia de tempo, tenho certeza que você já chegou a um ponto onde você tinha um erro em algum lugar e simplesmente não conseguia o encontrar. Se você é como eu, provavelmente passou a tarde toda arrancando os cabelos fora e comentando diversas coisas para caçar o erro.

Pré-processadores CSS relatam os erros. Simples assim. Se tem alguma coisa errada em seu códigom ele te fala onde e, se você estiver com sorte até mesmo o porquê. Você pode dar uma olhada nesse post caso esteja interessado em ver como os erros são relatados em diferentes pré-processadores.

Comentários

Quando um pré-processador CSS está compilando, qualquer comentário escrito com barras duplas “//” é excluído e qualquer comentários escrito com barra e asterisco “/* */” não é alterado. Dito isso, use comentários com barras duplas para comentários que você queira na versão não compilada e comentários com barra e asterisco para comentários que serão visíveis após a compilação.

Observação: Se você compilar os arquivos, minificando-os, todos comentários são excluídos.

Conclusão

Cada um dos pré-processadores que falamos (Sass, LESS e Stylus) possui um modo único de realizar a mesma tarefa – dando a nós desenvolvedor a habilidade de usar funcionalidades úteis mantendo a compatibilidade entre browsers e um código limpo.

Mesmo não sendo uma exigência para o desenvolvimento, pré-processadores podem economizar muito tempo e tem funcionalidades bastante úteis.
Eu aconselho todos vocês a utilizar e testar a maior quantidade de pré-processadores possível, pois assim você poderá escolher efetivamente um favorito e saber o porquê ele é seu favorito dentre tantos outros. Se você ainda não testou usar nenhum pré-processador para escrever seu CSS, eu recomendo grandemente a você testar.

Traduzido e adaptado de: http://code.tutsplus.com/tutorials/sass-vs-less-vs-stylus-preprocessor-shootout–net-24320

Fonte: http://tableless.com.br/

07 novembro 2016

Michelly Oliveira

Diferenças de tipos de Web Service: SOAP, REST

 

A comunicação entre sistemas e a capacidade de expor serviços através da Internet se tornaram uma necessidade comum para a grande maioria dos sistemas corporativos.

Seja apenas para prover suporte a outros módulos na mesma rede privada ou para permitir o acesso público a um determinado serviço, os web services são uma das tecnologias mais utilizadas tanto no Java como em outras linguagens de grande porte e fazem parte do dia a dia dos desenvolvedores.

Entre as abordagens existentes para a implementação de web services, o protocolo SOAP e o REST são as opções de maior destaque nos dias de hoje, estando presentes em grande parte das discussões relacionadas a arquiteturas orientadas a serviços na web.

Web Services: SOAP ou REST?

SOAP

SOAP

SOAP é um protocolo de transferência de mensagens em formato XML para uso em ambientes distribuídos. O padrão SOAP funciona como um tipo de framework que permite a interoperabilidade entre diversas plataformas com mensagens personalizadas.

Aplicando este padrão em Web Services, geralmente usa-se o WSDL para descrever a estrutura das mensagens SOAP e as ações possíveis em um endpoint.

O SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo. Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso. Além disso, a sigla SOAP deixou de representar "Simple Object Access Protocol". Na especificação 1.2 da W3C, SOAP é apenas o nome da especificação.

Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens. Primeiramente, como dito anteriormente, o SOAP é baseado em XML, de três formas: o envelope, que define o conteúdo da mensagem e informa como processá-la; um conjunto de regras de codificação para os tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse "envelope" é enviado por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) é executada, e o envelope retorna com as informações do documento XML formatado.

Uma das vantagens do SOAP é o uso de um método de transporte "genérico". Enquanto que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte existente para enviar sua requisição, desde SMTP até mesmo JMS (Java Messaging Service). No entanto, uma desvantagem percebida no uso de XML é a sua natureza prolixa e o tempo necessário para analisar o resultado apresentado.
 Uma das maiores vantagens disso é que várias linguagens e ferramentas conseguem ler e gerar mensagens facilmente. Várias linguagens de programação permitem a geração de objetos de domínio, Stubs e Skeletons a partir da definição do WSDL, permitindo a comunicação remota via RPC através de chamadas a métodos remotos, inclusive com argumentos complexos, como se fossem chamadas locais.

O problema desse padrão, é que ele adiciona um overhead considerável, tanto por ser em XML quanto por adicionar muitas tags de meta-informação. Além disso, a serialização e desserialização das mensagens pode consumir um tempo considerável.

Ao se encontrar uma das situações abaixo, o SOAP pode ser uma ótima solução:

  • Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo o WSRM (WS-Reliable Messaging).
  • Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação.
  • Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui uma especificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada.

REST

REST

REST é outro um protocolo de comunicação, baseado no protocolo HTTP/HTTPS e pode ser adotado em qualquer cliente ou servidor. Porém ele não impõe restrições ao formato da mensagem, apenas no comportamento dos componentes envolvidos. Faz uso de um padrão de URI (Uniform Resource Identifier), fazendo uma chamada para um serviço web como em: http://www.minhaempresa.com.br/programa/metodo?Parametros=xx

A maior vantagem do protocolo REST é sua flexibilidade. O desenvolvedor pode optar pelo formato mais adequado para as mensagens do sistema de acordo com sua necessidade específica. Citam ainda, como principais vantagens a facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforço de aprendizado pequeno. Os formatos mais comuns são JSON, XML e texto puro, mas em teoria qualquer formato pode ser usado.

Isso nos leva a outra vantagem: quase sempre Web Services que usam REST são mais "leves" e, portanto, mais rápidos.

O problema com o REST pode surgir justamente por causa de suas vantagens. Como a definição do corpo de dados fica totalmente a cargo do desenvolvedor, os problemas de interoperabilidade são mais comuns.

Pode-se afirmar, então, que casos onde o REST funciona bem são:
  • Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta.
  • Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa.
  • Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia.

 SOAP ou REST?

Em geral, SOAP é bastante maduro, bem definido e vem com uma especificação completa, é uma boa opção para instituições com padrões rígidos e ambientes complexos (várias plataformas e sistemas). Muitas ferramentas corporativas (como ESB) tiram vantagem do padrão e possibilitam filtrarem, enfileiramento, classificação e redirecionamento das mensagens trocadas entre sistemas.

Já a abordagem REST é apenas isso: uma abordagem. Está totalmente aberta. Praticamente todas as plataformas e linguagens modernas que conheço suportam esses conceitos e a solução final é muito mais simples do que o equivalente em SOAP.

Além disso, integrações com alto volume de requisições são inviáveis em SOAP. REST é capaz de atender volume e complexidade sem dificuldades, exigindo apenas um mínimo de experiência do desenvolvedor para estabelecer e reforçar os padrões adequados.

Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural. Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas.

Como se vê, cada uma das abordagens tem sua utilidade. Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web.


Fonte: stackoverflow.com