Arquivos da categoria "dicas":
01/11/2011 - 12:05
Uma das boas práticas que podemos adotar para agilizar o carregamento de uma página é comprimir o css e o js. Essas compressões, costumam, retirar os comentários. as quebras de linha e às vezes até alterar o nome de variáveis de escopo, alterando as para por exemplo “a”.
Uma das principais ferramentas que conheço é o YUI compressor. Tem um site que utiliza essa ferramenta para comprimir o JS. Aconselho o uso, mas devemos sempre ter a versão sem otimização para alterar caso necessário.
O site é o http://jscompress.com/.
Fica a Dica!
Enviado por: leandro garcia - Categoria(s): dicas
Tags relacionadas: otimização
28/10/2011 - 18:14
Recebi um e-mail do Rodrigo Pereira me pedindo dicas para começar a trabalhar com desenvolvimento front-end.
O front-end é algo que muito aprecio e ao responder para ele me empolguei e acabei escrevendo um post e colo aqui abaixo.
O que um programador front-end deve saber?
São três itens básicos que um programador front-end deve saber.
HTML
Um programador front-end deve saber bem HTML, o HTML 5 ainda não é necessário saber bem, mas em pouco tempo será. Ainda não é, pois depende dos navegadores e o principal ainda é o ie e apenas a versão 9 do ie aceita HTML 5, embora tenha como burlar nas demais. Mas atente-se a aprender bem HTML.
CSS
CSS é necessário, pois é onde a “beleza” da página acontece. Saber é necessário.
Javascript
Dos 3 o javascript é o menos importante, mas é de extrema importância, uma vez que é com javascript que fazemos as interações da página.
Isso é o básico.
Agora vem coisas importantes:
Tableless
Tableless é primordial, pois não dá pra codificar um layout com tabelas, elas não foram feitas para isso.
Quando alguma pessoas lêem tableless acreditam que não se deve usar tabela em hipotese alguma, não é isso. Pode usar sim, mas pra fazer uma tabela e não um layout. Ex A tabela de medalhas do Pan, se usa tabela. Errado seria usar outra coisa.
DivLess
É comum quando as pessoas migram a programação de tabela para tableless sairem colocando div em tudo, não se deve fazer isso, embora seja menos ruim que tabela, existem diversas tags em html para diversas coisas nas quais se encaixam melhor. O HTML 5 tem tags melhores, mas semânticas, mas não temos que nos atentar a apenas essas, por exemplo se você tem um título de uma notícia, deve se usar os Hs h1, h2, h3, h4, h5, h6, Um texto deve conter parágrafos <p> e assim por diante.
SEO
Não precisa se aprofundar nisso se não for a área com que você vai trabalhar, mas uma noção é importante, por exemplo saber onde colocar as tags, o que se deve fazer para melhora e o que não se deve fazer em hipótese alguma.
WebSemantica
Websemantica é uma coisa que ainda não existe, no sentido que a idéia original da web semantica é o computador entender o conteúdo e conseguir dar opções semelhantes. Mas não devemos nos atentar a isso. Devemos trabalhar a semantica da página no sentido de melhorar o fluxo da informação. A semantica é dizer ao computador o que é cada coisa e para isso devemos escrever nosso código o melhor possível. Isso quer dizer, usar as tags certas para a coisa certa, nomear corretamente as classes e ids, um id deve ser único em uma página, etc.
jQuery
Veja, o que vou escrever aqui, é a minha idéia, mas conheço outros progrmadores que pensam diferente.
Primeiro, conhecer bem javascript normal antes de usar um framework, pois se de cara você aprender um frameworks, pode se tornar complicado aprender outros frameworks, aliado à isso, você pode ter que participar de algum projeto em que não se possa usar qualquer framework e ai? Ou ter que usar o mootoos ao invés de jquery, são muitas variantes.
Na minha opinião, você não precisar ser um expert em javascript pra usar jquery, mas conhecer bem o básico.
Fora isso, usar jQuery é mais do que recomendado.
Lógica de programação
Embora para front-end não seja um pré-requisito ou não tão necessário quanto para back-end, eu acredito que ter uma boa lógica de programação auxilia o fronten dev na execução de um melhor trabalho, principalmente com JavaScript.
Ler
Um bom programador Front-end deve estar sempre antenado no que está acontecendo na área. Ler é fundamental. Há alguns livros bons, mas eu considero que se você tiver que escolher entre ler um liro ou blogs de programação, leia os blogs, costumam ser mais atuais.
Fazer
Não existe melhor escola para aprender do que fazer. Quando eu estava aprendendo, eu costumava escolher um site que eu gostasse e tentava refazê-lo. Outra coisa que eu costumava fazer e ainda faço, é ver o código dos outros. Abro o fonte dos sites e tento entender o que o front-end que desenvolveu fez. Aprendemos bastante assim.
Se você já fez uma coisa, se der tempo refaça, você vai se surpreender como você pode melhorar o que você fez antes. Se não tem tempo, mas tem que fazer uma coisa parecida, não tenha preguiça, refaça o código ou ao menos tente melhorá-lo.
Firbug, é um complemento do firefoz que auxilia o front-end dev a fazer o site, uma vez que com ele conseguimos simular situações conforme vamos fazendo. tipo almentar o texto e ver o que aontece, mudar cor tamanho de fonte, essas coisas direto no navegador, é excelente. Existem equivalentes para chrome, Safari, Opera e até IE, mas o melhor é o FireBug, só que é um pouco pesado.
Navegadores
Você deve conhecer os principais navegadores, não que dizer que você tenha que usá-los, mas deve conhece-los, pois toda interface programada deve ser testada nos navegadores, IE, FireFox,Chrome, Safari e se possível no Opera. Pois são os mais utilizados, inclusive em versões anteriores do ie, pelo menos até a versão 7, já que a maioria das empresas pararam de dar suporte à versão 6.
De todos os navegadores, a maior diferença dá entre o ie e os demais. Os demais não mudam muita coisa.
Concluindo
A área de desenvolvimento web está em alta, está muito boa para trabalhar, desde que você não tenha medo de ter que trabalhar de fim de semana as vezes e até ter que virar a noite. É raro, mas acontece.
Eu programo PHP, já programei outras linguagens, mas o que eu gosto mesmo é do front-end é onde me sinto realizado. Onde eu consigo ser diferente, fazer coisas diferentes.
Nunca se atenha só a seu trabalho. Faça coisas deiferentes do seu trabalho, exemplo se você nunca programou um blog, programe um fora do trabalho.
Saia da Zona de Conforto.
—
Enviado por: leandro garcia - Categoria(s): dicas
Tags relacionadas:
14/10/2011 - 18:28
Acabei de publicar um aplicativo na Chrome Web Store. Agora vocês conseguem colocar o blog do Garcia para acessar direto do seu navegador Chrome.
Para instalar é só acessar o endereço: https://chrome.google.com/webstore/detail/fahinlhmlookaaafkfolpdpfgbipieba?hl=pt-BR&hc=search&hcp=main
Enviado por: leandro garcia - Categoria(s): dicas
Tags relacionadas:
14/10/2011 - 17:21
Tem um site que acompanho chamado nettuts, que possui diversos tutoriais sobre diversas coisas, uma dessas é sobre a melhor maneira de aprender javascript. Vou tentar sintetizar o eles recomendam. Eu recomendo seguir este site. 
Item 0: Entender o que JavaScript é e não é
Javascript não é jQuery, Java ou flash. JavaScript é uma linguagem do navegador. Sua primeira proposta é adicionar interatividade à páginas estáticas. Não substitui PHP ou Ruby. Nem mesmo HTML ou CSS, é usado em conjunto. Talvez você tenha ouvido falar em jQuery jQuery não é Javascript ou não substiui o javascript. jQuery é uma ferramenta de trabalho escrita em Javascript, ou seja, você programa javascript sem jquery, ams o jQuery pode facilitar sua vida.
Item 1: Aprender através de screencasts
O site http://learn.appendto.com/ tem uma série de screencasts interessantes para iniciantes.
Item 2: Ler uma boa introdução de JavaScript
Uma introdução ao Java Script – Mozzila
Eloquent JavaScript: A Modern Introduction to Programming
http://rockablepress.com/books/getting-good-with-javascript/
Item 3: Instalar e aprender FireBug ou Devlopers Tools
Uma vez que você começou à trabalhar com javascript no navegador, instale o firebug para aprimorar seus conhecimentos. Tempos atrás eu fiz um post sobre Firebug, leia-o, é interessante. Leia o wiki do Firebug, leia sobre o developer tools.
Item 4: Ler um livro
Presumindo que você já está familiarizado com a linguagem, agora é hora de ler um livro à respeito. Os que acho mais interessantes são da editora O’reilly
Professional JavaScript for Web Developers (Wrox Programmer to Programmer)
JavaScript 24-Hour Trainer (Wrox Programmer to Programmer)
JavaScript Patterns
Item 5: Construa alguma coisa
Este item eu acho o mais importante. Para você ser bom, você tem que fazer. Faça uma lista de tarefas, uma galeria de fotos, uma caixa que se move, sei lá, faça algo e depois tente melhorar o código
Item 6: Aprenda alguma biblioteca JS
Usar uma bilbioteca ou framework traz uma agilidade enorme para o desenvolvimento das coisas, mas acredito que para você ser bom em alguma biblioteca você deve aprender Javascript tradicional, pois em algum momento você pode ser desafiado à fazer alguma coisa sem a biblioteca que você está acostumado.
Item 7: Acompanhe os melhores
Ler é a melhor maneira de você evoluir na programação e para ler, nada melhor do que ler o que os melhores postam. no post http://net.tutsplus.com/articles/web-roundups/30-developers-you-must-subscribe-to-as-a-javascript-junkie/, há uma série de excelentes programadores que tem muito a ensinar. Leiam seus blogs.
Enviado por: leandro garcia - Categoria(s): dicas, JavaScript
Tags relacionadas:
07/07/2011 - 19:36
Salve.
Nesses últimos dias, fiz um tema para um blog. Esse Blog depende do agendamento para a publicação dos seus posts, pois devem ser publicados à determinada hora do dia, mas (tem sempre um mas) o agendamento do wordpress não estava funcionando, agendava, mas no horário não publicava.
O erro? missed schedule… Como consertar?
Depois de muito quebrar a cabeça e procurar na web encontrei a solução um plugin. Com o nome bem sugestivo missed schedule em principio, duvidei, mas testando, realente funcionou.
Fica a dica, caso se deparem com este erro, tentem este plugin. Me ajudou bastante.
Enviado por: leandro garcia - Categoria(s): dicas, wordpress
Tags relacionadas: erro, missed schedule, plugin, wordpress
06/07/2011 - 13:08
Viewport é uma metatag para dispositivos móveis (telefones, tables, etc), serve para informar ao navegador desses dispositivos como eles devem exibir a página reduzida.
Quando uma página não tem versão mobile, os dispositivos móveis (modernos) a carregam como são visualizadas nos navegadores tradicionais só que de maneira reduzida para se adequar ao tamanho do dispositivo, é exibido a página to tamanho total da interface, por exemplo, se a largura da página for de 1000px, aparecera esses 1000 pixels de maneira reduzida e colada no navegados, sem respiro, o que torna a experiência ruim.
Ao usar a tag viewport a página informa ao dispositivo a largura que ele deve exibir.
Este blog, tem sua largura definida em 1000px, e seu viewport em 1200px, isso significa que o navegador dos dispositivos móveis vai exibir 1200px de largura da página, e não os 1000, ou seja, um respiro de cada lado.
<meta name="viewport" content="width=1200" />
Além da largura, é possível controlar qual o nível de zoom quando a página é carregado, usando a própriedade initial-scale dentro da tag. O maximum-scale, minimum-scale, e user-scalable controla quanto o usuário está permitido dar o zoom a página, para mais ou menos.
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
device-width = largura do aparelho
Enviado por: leandro garcia - Categoria(s): dicas, HTML, MetaTags
Tags relacionadas:
25/06/2011 - 19:54
No último post, eu escrevi sobre a importância de comentar o código, e ao escrevê-lo, me deparei com uma outra situação muito comum, e que em principio pode parecer irrelevante, mas se pensarmos bem ajuda bastante.
Quando vamos escrever um código é comum termos que escolher nomes de funções, classes, métodos, variáveis, etc, ou seja, coisas que não fazem parte da sintaxe da linguagem, mas sem não tem como escrever um código. É nesse ponto que deve-se tomar cuidado.
No calor do momento em que estamos escrevendo um código uma determinada nomenclatura que adotamos para uma variável pode parecer perfeitamente coerente, mas pode não ser bem assim. Pensemos, se vamos receber numa variável o resultado da média escolar, é comum, simplesmente optarmos pelo nome de resultado ou result, mas e se essa função crescer? ou pior se ao invés de resultado tivessemos dado o nome dessa variável de r?
var result = resultado(n1,n2);
var r = resultado(n1,n2);
Um exemplo
Um software para cálculo de médias escolares, que faz a média de cada matéria. Que precisa ter um botão para aumentar o valor de uma nota, ao invés de digitá-la. Porém por necessidade de negócio deve ter um botão que aumenta ou diminui a fonte do texto entre outras coisas.
function mais(v){
return v + 1;
}
var r = function(){n1+n2+n3+n4/4}
function menos(v){
return v - 1;
}
function ma(v){
return variaelexistentea + 1;
}
function me(v){
return variaelexistentea - 1;
}
var result = mais(r);
E ai? Hoje é possível entender o que foi escrito facilmente, mas e daqui a um ano? Vai ser difícil e se não for você quem vai fazer a manutenção deste código? Imagina a dificuldade de alguém que caiu de paraquedas no projeto, pois é se escrevermos claramente o que queremos dizer, será bem mais fácil.
function aumentarMedia(nota){
return nota + 1;
}
var media = function(){n1+n2+n3+n4/4}
function diminuirMedia(v){
return v - 1;
}
function aumentarLetra(){
return variaelexistentea + 1;
}
function diminuirLetra(){
return variaelexistentea - 1;
}
var mediaAumentada = mais(r);
Não mudei nada no código, apenas a nomenclatura das variáveis e das funções, no entanto ficou bem mais evidente o que esse trecho de código faz.
Enviado por: leandro garcia - Categoria(s): dicas
Tags relacionadas: código bem escritp
22/06/2011 - 19:41
Para muitos isso que vou escrever é chover no molhado. Mas acho interessante abordar esse tema.
Antes de abordar esse tema, devo admitir que cometi muito esse erro, muitas vezes deixei de comentar meu código, ou por esquecer ou muito pior, por achar que meu código estava fácil de ser interpretado. Isso foi um enorme erro, pois ao fazer a manutenção do código tempos depois me vi obrigado a interpretar o código e consequentemente a perder um enorme tempo com isso, o que eu deveria ter feito? Comentar, simples assim.
Código Sem comentário
function fazer(variavel1, variavel2){
if(variavel1 > variavel2){
v3 = (variavel2-varialve1)/2
}else{
v3 = (variavel1-variavel2)*5;
}
switch(v3){
case 1:
vf = faca(1);
break;
case 2:
vf = faca(2);
break;
default:
vf = faca(v3);
}
alert(vf)
}
Essa é uma função simples, mas por não ser comentada quando eu ou alguma outra pessoa for dar manutenção isso poderá ser um problema, pois a pessoa vai ter que interpretar essa função, pra entender o que ela faz e pior, ela não terá certeza quando ela é chamada, o que pode ocasionar erros ou no mínimo uma perda de tempo.
Com comentários indecifráveis
/*22/06/2011*/
function fazer(variavel1, variavel2){
if(variavel1 > variavel2){
v3 = (variavel2-varialve1)/2
}else{
v3 = (variavel1-variavel2)*5;
}
switch(v3){
case 1:
vf = faca(1);
break;
case 2:
vf = faca(2);
break;
default:
vf = faca(v3);
}
alert(vf)
}
Contém um comentário na função, mas o que ele diz? A data de atualização? De criação? O que deve imprimir na tela? Não tem como saber.
Mal comentado
/*alerta uma variável*/
function fazer(variavel1, variavel2){
if(variavel1 > variavel2){
v3 = (variavel2-varialve1)/2
}else{
v3 = (variavel1-variavel2)*5;
}
switch(v3){
case 1:
vf = faca(1);
break;
case 2:
vf = faca(2);
break;
default:
vf = faca(v3);
}
alert(vf)
}
Nessa mesma função há um comentário dizendo o resultado esperado para essa função, mas não explica seu funcionamento. Mudou alguma coisa? Sim mudou, melhorou, mas não muito, ou quase nada.
Bem comentado
/*Função para alertar um resultado*/
function fazer(variavel1, variavel2){
/*Se a váriável1 for maior que a variável 2, dividir o resultado da subtração por 2, caso contrário multiplicá-la por 5*/
if(variavel1 > variavel2){
v3 = (variavel2-varialve1)/2
}else{
v3 = (variavel2-variavel1)*5;
}
/*Validar o resultado da variável v3 e acionar a função faca com o valor de cada caso.*/
switch(v3){
case 1:
vf = faca(1);
break;
case 2:
vf = faca(2);
break;
default:
vf = faca(v3);
}
/*Alertar o retorno da função faca*/
alert(vf)
}
Nesse caso, há bastante comentário sobre o funcionamento da função, o que o futuro pode melhorar e muito a manutenção desta função.
Concluindo
Os comentários são a melhor arma que um programador pode ter para evitar maiores trabalhos no futuro. Todas as linguagens tem sua forma de comentar, algumas até mais do que uma, que pode ser /*, //, ‘,# entre outras.
Use sempre os comentários, afinal daqui a um ano, sua cabeça não será a mesma de hoje, mas a função será.
Enviado por: leandro garcia - Categoria(s): dicas
Tags relacionadas: comentar
17/06/2011 - 18:57
O Google lançou recentemente um site com informações sobre desenvolvimento de mobile apps.
Neste site não há código mas informação do ponto de vista de negócio sobre mobile Apps, inclusive com exemplos reais que deram certo, como o Angry birds, por exemplo, vale dar uma lida no conteúdo, mesmo se você não tem interesse em desenvolver mobile Apps, pois são informações preciosas sobre a construção de negócios. E para quem tem interesse, diria que é obrigatório estudar o conteúdo.
http://www.guidetotheappgalaxy.com
É interessante também avaliar o código do site, pois é uma animação bem interessante e não é flash, é uma construção interessantíssima de um website com conteúdo, animação, interatividade com um código bem contruido.
Sem dúvida vale uma visitinha
Enviado por: leandro garcia - Categoria(s): dicas, Sites que rolam, Vale um clique
Tags relacionadas:
10/02/2011 - 14:34
O Operador ternário está presente na maioria das linguagens de programação e serve para agrupar condicionais em uma única linha, economizando código e na minha opinião deixado o código mais clean.
A sintaxe é simples (condição) ? verdadeira : falsa
Em PHP uma sintaxe normal
$direcao = "d";
if($direcao == "d"){
$sentido = "direita";
}else{
$sentido = "esquerda";
}
print $sentido;
Agora com o Operador ternário
$direcao = "d";
$sentido = ($direcao == "d") ? "direita" : "esquerda";
print $sentido;
ou
$direcao = "d";
print ($direcao == "d") ? "direita" : "esquerda";
Em javascript é a mesma coisa.
Vejam:
Tradicional
var direcao = "d";
if(direcao == "d"){
sentido = "direita";
}else{
sentido = "esquerda";
}
document.write(sentido);
Operador ternário
var direcao = "d";
var sentido = (direcao == "d") ? "direita" : "esquerda";
document.write(sentido);
Enviado por: leandro garcia - Categoria(s): dicas, JavaScript, PHP
Tags relacionadas: operador ternário