Desenvolvimento, Tecnologia e Informação, na ponta do lápis.
Archive for November, 2009
Um pouco sobre certificações (W3C)
8801 days
Ontem aconteceu a Conferência da W3C Brasil. Infelizmente não pude ir, mas acompanhei tudo pelo twitter através da hash tag #webbr2009.
Diversos assuntos foram discutidos neste dia, dentre eles o que mais me chamou a atenção foi a quantidade de opniões divergentes com relação ao ter ou não ter certificações para os profissionais que lidam com o desenvolvimento front-end todos os dias.
De todas as opniões que foram expressadas neste dia, se juntar tudo e fazer uma categorização das opiniões, vocês vão ver que tudo gira em torno da desilusão dos profissionais quanto a este assunto.
Vi muitas pessoas sendo contra a certificação, pelo fato de muitos ja terem comprovado e sentido na pele o grande interesse de algumas instituições – que prefiro não citar – em vender somente o papel e não o conhecimento.
Depois da discussão que tive com alguns amigos que trabalham na área pude ver que as pessoas não são desiludidas com A CERTIFICAÇÃO em si. Os profissionais estão desiludidos na maneira como ela é vendida e mantida pelas instituições e a forma como as empresas fazem a utilização desta certificação.
A certificação é vendida como se fosse um curso qualquer. Onde o candidato à certificação entra em uma salinha, responde umas perguntas e sai certificado. O que é uma demonstração CLARA de que as instituições não estão nem um pouco interessadas no nível do profissional que sai dali com este papel de baixo do braço e sim pelo dinheiro dos que acreditam que este papel vai mudar o seu mundo – o que tem uma pitada de verdade.
Vi também que muitos estavam “indignados” pelo fato das empresas utilizar tais certificações como filtro em um processo de seleção. Veja bem, eu também acho isso uma sacanagem mas não acho isso, o fim do mundo. A empresa tem um senso equivocado as vezes pensando que se eles ignorarem todos os que não tem certificação e entrevistar somente o que tem estarão fazendo um bom negócio pois os que não tem é lixo – na visão deles.
Mas por outro lado em grandes corporações este filtro serve puramente para agilizar o processo. Imagina uma empresa com uma fila de 3 mil candidatos a uma vaga. Eles iriam demorar 5 anos para entrevistar todo mundo da forma mais humana e minuciosa possível, mas infelizmente, eles acreditam que mesmo ignorando 2 mil sem certificações eles acreditam que pelo menos 10% destes mil que sobraram sejam bons profissionais. Se pensarmos por este lado, é totalmente aceitável o filtro quando aplicado em uma situação como esta – mesmo sabendo que eles podem ter perdido os steve jobs pessoal deles. Steve Jobs não tem nível superior, imagina ele procurando emprego? milhares de empresas aplicando seus filtros em cima de uma mente brilhante, cool. 
A minha opinião sobre estas certificações é: Devemos sim ter certificações. Quanto mais o nosso ramo amadurecer neste sentido e ter instituições que comprovem e testem os profissionais que atuam neste meio é mais um passo que damos rumo a extinção dos sobrinhos. Quanto mais formal tornarmos o nosso ramo de trabalho, mais dificulta o acesso das empresas sérias a profissionais sem compromisso e consideração com o ramo e as pessoas que atuam nele. Tevemos sim ter certificações, talvez tenhamos que amadurecer melhor esta idéia e talvez não oferecermos uma certificação de HTML ou CSS mas sim de Padrões Web, quem sabe…
Se a forma como tudo é “vendido” mudar, estas certificações servirão como uma forma de valorizar o profissional que possui esta certificação. Tudo tende a agregar valor.
Este é um ótimo assunto e que diferente de só fornecer a certificação, devemos GARANTIR que o profissional que porta este selo é um profissional que no mínimo se importa com a gente, com a nossa luta e principalmente, com o cliente.
Meu amigo Chris também falou e apontou suas consideração sobre o debate, vale a pena dar uma lida também.
[]‘s
Igor.
javascript freak, php lover, zend certified engineer, ruby programmer wannabe, ruby developer at Editora Abril, musician and skater at free time.
Posts Relacionados:
Manifesto Slow
6809 days
Cansado de ler sobre este manifesto no Twitter. Resolvi dar uma googada para sumir com a minha wtf-face. 
O que é o Manifesto Slow?
O Manifesto Slow é um manifesto criado por não sei quem cujo este criou um site chamado (claro): Manifesto Slow. Se você se der o trabalho de acessar verá de cara um resumo curto e grosso sobre o que é este manifesto.
“Esse manifesto não contém nada. Porquê? Fazer um consumiria tempo. E tudo se resume em ganhar tempo. Tempo para que? Para não fazer nada.”
E nisto se resumi o Manifesto. Todas as dicas e pensamentos são escritos no blog do manifesto slow com o único objetivo: Poupar tempo. Todas as dicas são totalmente e unicamente em prol de não fazer nada ou fazer menos.
Se você ainda não entendeu nada, no blog do manifesto eles já publicaram alguns exemplos de como você deve fazer para se unir ao Manifesto Slow.
Na minha humilde opnião, você deve tomar muito cuidado na hora de escolher o que vai ouvir e o que vai jogar fora. Nesta lista que eles divulgaram tem apenas 7 exemplos sobre o que se trata o manifesto slow e duas delas eu discordo e uma eu diria que há controversa. Quando temos o dom da palavra é melhor tomarmos cuidado com o que dizemos pois isso pode se virar contra você ou não.
A grande questão é: Tudo isso é uma grande piada ou eles querem mesmo de alguma forma mudar o mundo? rs.
javascript freak, php lover, zend certified engineer, ruby programmer wannabe, ruby developer at Editora Abril, musician and skater at free time.
Posts Relacionados:
William Bonner fala sobre o Twitter
0809 days
O Twitter é o serviço de microblogging mais famoso do sistema solar, porém, muitas pessoas ainda não fazem a menor idéia para o que serve e qual a sua real utilidade.
Acompanhando as atualizações do meu Twitter acabei me deparando com este vídeo onde o William Bonner fala sobre o Twitter, conta como ele faz o uso do Twitter e o que mudou na vida dele após a sua utilização.
Para quem ainda não entendeu o seu uso e não faz a mínima idéia para que serve, o video da uma clareada na cabeça de vocês.
Twitter do Willian Bonner: @realwbonner
William Bonner fala sobre o Twitter
[]‘s
Igor.
javascript freak, php lover, zend certified engineer, ruby programmer wannabe, ruby developer at Editora Abril, musician and skater at free time.
Posts Relacionados:
10 Dicas JavaScript e Boas Práticas
10821 days
Recentemente alguns site e blogs vem divulgando listas de dicas para se codificar em javascript. Apresentando melhores práticas de desenvolvimento e muitas dicas bacanas, Pensei que este seria um bom tópico para se extender e compartilhar com vocês. Neste post estou reunindo as minhas top 10 dicas e boas práticas para codificação javascript.
Espero que gostem.
1. Use o atributo defer para indicar o uso scripts externos no IE
O propósito do defer é avisar o script que está sendo requisitado externamente para esperar até que a página seja carregada ou o DOM esteja preparado. O mesmo pode ser realizado através de bons métodos não-obstrutivos via javascript, que usualmente inclui códigos que previne a execução de scripts antes que o DOM seja carregado por completo.
A vantagem do defer ocorre quando utilizamos o Internet Explorer, tendo em vista que é único browser que suporta o atributo defer. Então, se você precisa de um rápido script que rode únicamente e exclusivamente no Internet Explorer, e você não quer que ele execute antes que o DOM esteja preparado, então simplesmente adicione defer="defer" no sua tag <script> e ela irá rapidamente tratar o seu problema. Corrigir a transparência de arquivos PNG no IE6 é uma das possibilídades práticas do uso do defer.
(Edit: O atributo defer deve ser usado quando escondemos um script de outros browsers com o uso dos comentários condicionais – conditional comment – que afete somente os navegadores da Microsoft – de outra maneira o script vai rodar normalmente em outros browsers.)
2. Use o CData Section para previnir erros de validação XHTML Strict
Muitas vezes seus scripts vão residir em arquivos externos e chamados dentro da tag <script> dentro do <head> do documento, ou então antes do fechamento da tag </body>.
Mas este documento pode estar eventualmente usado em um local que junto dele existem marcações HTML, como abaixo:
<div>
<p>
<script type="text/javascript">
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
</script>
</p>
</div>
Você pode notar que no código acima, dentro do if, existe o símbolo < que representa “menos”, que é parte da sintax, corréto? Este símbolo causa um erro de validação. O validador interpreta ele como um inicio de uma marcação ou uma tag HTML que não foi fechada, a não ser que você encapsule o seu código com o CData, assim:
<div>
<p>
<script type="text/javascript">
//<![CDATA[
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
//]]>
</script>
</p>
</div>
3. Evite palavras-chaves reservadas do JavaScript quando estiver criando funções e identificadores
Muitas palavras são reservadas no javascript, então você deve evitá-las quando forem criar variáveis ou outros idenficadores. A lista completa de palavras-chaves do javascript segue abaixo:
break case catch continue default delete do else finally for function if in instanceof new return switch this throw try typeof var void while with
4. Evite palavras reservadas do JavaScript quando estiver criando funções e identificadores
Que estão também algumas palavras reservadas, que não estão necessariamente sendo usadas pela linguagem mas são reservadas para o uso futuro. São estas:
abstract boolean byte char class const debugger double enum export extends final float goto implements import int interface long native package private protected public short static super synchronized throws transient volatile
5. Não mude o tipo das variaveis depois da declaração inicial.
No javascript, tecnicamente, isso é perfeitamente legal:
var my_variable = "Esta é uma string"; my_variable = 50;
Depois que a variável é inicialmente declarada como string na linha 1, na linha 2 o seu valor é mudado e o seu tipo também. Esta não é uma boa prática e deve ser evitada.
6. Não use variáveis globais.
Para previnir possíveis conflitos, em 99% dos casos, use o “var” no início quando estivermos declarando uma variável e seu valor. Isso faz com que a sua variável exista somente no escopo da função e não fora dela, ou seja, toda variável criada pelo var, só poderá ser acessível dentro do escopo no qual ela foi declarada e não mais fora dele. Então, se acontecer de você utilizar duas variáveis com o mesmo valor em lugares diferentes do seu script, nenhum conflito ocorrerá.
7. Javascript é Case-Sensitive.
Lembre-se do que vem a seguir: No código que segue temos duas variáveis que estão armazenando seus valores em 2 lugares diferentes na memória, e não um só, como alguns podem pensar. São duas variáveis completamente diferentes alocadas em lugares diferentes na memória:
var myVariable = "data"; var myvariable = "more data";
8. Use o switch para lidar com multiplas condições
Não faça isso:
if (example_variable == "cyan") {
// faça algo aqui...
} else if (example_variable == "magenta") {
// faça algo aqui...
} else if (example_variable == "yellow") {
// faça algo aqui...
} else if (example_variable == "black") {
// faça algo aqui...
} else {
// faça algo aqui...
}
Faça isso:
switch (example_variable) {
case "cyan":
// faça algo aqui...
break;
case "magenta":
// faça algo aqui...
break;
case "yellow":
// faça algo aqui...
break;
case "black":
// faça algo aqui...
break;
default:
// faça algo aqui...
break;
}
O segundo bloco de código faz exatamente a mesma coisa que o primeiro – mas o segundo é limpo, fácil de ler, fácil de dar manutenção e modificar.
9. Use o try-catch para previnir que erros sejam expostos para os usuários
Encapsulando todo o seu código no try-catch, você pode evitar que o usuário final nunca veja um feio erro de javascript exposto na tela. Assim:
try {
funcaoQueNaoExiste();
} catch (error) {
document.write("Um erro ocorreu.")
}
No código acima, eu tentei chamar uma função que não existe, para forçar um erro. O navegador não vai exibir o típico erro “not an object” ou “object expected”, mas ao invés disso, vai exibir um erro mais customizável que eu incluí dentro do meu “catch”. Você pode também deixar o catch vázio para nada ser mostrado para o usuário, ou você pode criar uma função que seja chamada dentro do catch que faça o tratamento deste erro para propósitos de debug etc.
Mantenha na sua cabeça que isso pode esconder erros do desenvolvedor também, então uma boa decumentação do código e comentários podem ser úteis neste ponto.
10. Faça comentários multi-linhas legíveis, mas simples
Em javascript, você pode comentar uma linha de código colocando um // no início da linha. Você também pode criar um comentário em bloco como mostra a seguir: /* [comentário aqui ] */. Algumas vezes você precisa incluir um comentário longo, um comentário de mais de uma linha. Um bom método para se utilizar que não tenha uma visual esmagador, mas é fácil de identificar o código é esse a seguir:
/* * Este é um comentário multi-linha... * bla bla bla... * bla bla bla... * bla bla bla... * bla bla bla... */
E é isso
Este artigo é uma adaptação e tradução do texto: 10 JavaScript Quick Tips and Best Practices
javascript freak, php lover, zend certified engineer, ruby programmer wannabe, ruby developer at Editora Abril, musician and skater at free time.
