Arquivo

Arquivo da Categoria ‘JavaScript’

2010 em livros

5 de janeiro de 2011

Estou a “plagiando” uma idéia de Phillip Calçado que fez um post em seu blog mostrando os livros lidos no ano de 2010, com um pequeno comentário sobre cada um.

Com certeza minha lista é muito mais modesta e curta, mas a idéia de compartilhar conhecimento é a mesma.

Esse post também serve para me alertar a ler mais, mesmo com toda a correria de trabalho, família, estudo e prática de esportes, gostaria de ter lido mais que 7 livros durante 2010.

Os livros são apresentados na ordem que foram lidos:

Clean Code: A Handbook of Agile Software Craftsmanship

Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin
Prentice Hall
August 2008

Muito bom

Todo programador deveria ler. Uncle Bob nos concede um pouco de sua vasta experiência em desenvolvimento de software, mostrando como deixar seu código mais enxuto, legível e simples. Esse livro serviu de inspiração para várias palestras e apresentações por aí sobre como escrever código de melhor qualidade.

The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends

The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends

David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
The Pragmatic Programmers
December 2010

Ótimo

Essencial para quem quer aprender RSpec. Explica como seria o ciclo ideal de BDD. Também traz exemplos práticos de utilização de RSpec e Cucumber com Ruby e Ruby on Rails.

JavaScript: The Good Parts

JavaScript: The Good Parts

Douglas Crockford
O’Reilly
May 2008

Muito bom

Quem curte JavaScript irá gostar bastante. Fiz anotações sobre esse livro nesse post.

Design Patterns in Ruby

Design Patterns in Ruby

Russ Olsen
Addison-Wesley Professional
December 2007

Bom

Traz uma boa parte dos design patterns apresentados pela GoF utilizando Ruby. O que eu achei mais interessante foi a abordagem utilizada pelo autor: dado um design pattern, o mesmo é implementado de uma maneira clássica e depois reimplementado usando os recursos que o Ruby oferece, como por exemplo, metaprogramação, tornando alguns patterns totalmente diferentes de sua implementação original.

Professional ASP.NET MVC 2

Professional ASP.NET MVC 2

Jon Galloway, Scott Hanselman, Phil Haack, Scott Guthrie, Rob Conery
Wrox
June 2010

Muito bom

Sempre gostei da séria Professional da Wrox e esse livro mantém a linha de qualidade. Logo no primeiro capítulo tem um passo a passo da construção de uma pequena, mas completa, aplicação ASP.NET MVC 2. Os demais capítulos cobrem os demais recursos do framework. Só pelos autores já vale a leitura.

ASP.NET MVC 2 in Action

ASP.NET MVC 2 in Action

Jeffrey Palermo, Ben Scheirman, Jimmy Bogard, Eric Hexter, Matthew Hinze
Manning
June 2010

Regular

Talvez se eu não tivesse lido o livro da Wrox antes teria classificado melhor este. Em algumas vezes os autores focam demais no uso de ferramentas extras, auxiliares ao desenvolvimento de aplicações ASP.NET MVC 2. Isso é bom para quando você já tem conhecimento e/ou vivência do framework.

Test-Drive ASP.NET MVC

Test-Drive ASP.NET MVC

Jonathan McCracken
The Pragmatic Programmers
June 2010

Regular

Eu esperava bem mais desse livro por se tratar de TDD. Havia imaginado vários passos práticos de desenvolvimento orientado a testes no melhor estilo Kent Beck ou Uncle Bob. Para quem já conhece TDD, não irá ver grandes novidades.

Eu uso o Shelfari como prateleira virtual para organizar os livros que li, estou lendo e pretendo ler.
É bem legal e tem vários recursos. Por exemplo, esse endereço lista os livros que li no ano de 2010.

.NET, Arquitetura, JavaScript, Livros, Ruby, TDD , , , , , , , , , , , ,

Melhores posts do ano de 2010

31 de dezembro de 2010

Um objeto JavaScript para confirmar se o usuário quer sair da página

29 de novembro de 2010

Existe algumas situações que é interessante confirmar se usuário realmente quer deixar a página atual. O usuário pode sair acidentalmente sem salvar o que está editando ou quando o fluxo de edição de conteúdo da página é complexo que pode induzir o usuário a não salvar no final.

Por exemplo, no WordPress que uso nesse blog aparece uma confirmação se eu tento sair da página de edição de post sem ter salvo antes:

Clique na imagem para ampliá-la

Clique na imagem para ampliá-la

O segredo é configurar o evento onbeforeunload do objeto window com uma função que retorna o texto da confirmação:

<html>
<head>
  <script>
    window.onbeforeunload = function() {
      return "Minha mensagem de confirmação.";
    }
  </script>
</head>
<body>

</body>
</html>

Abordagem procedural

O ideal é podermos configurar se a mensagem de confirmação irá aparecer ou não, conforme as ações do usuário na página. Vamos criar uma variável que servirá como condição se a mensagem de confirmação será exibida.

<html>
<head>
  <script>
    var needToConfirm = false;

    window.onbeforeunload = function() {
      if (needToConfirm) {
        return "Minha mensagem de confirmação.";
      }
    }
  </script>
</head>
<body>
  <form onsubmit="needToConfirm = false;">
    <p><input type="text" onchange="needToConfirm = true;" /></p>
    <p><input type="submit" /></p>
  </form>
</body>
</html>

O código acima exemplifica a ativação e a desativação da exibição da mensagem de confirmação na saída da página em um formulário. Toda a vez que o valor do campo texto for alterado (linha 15), a variável needToConfirm é configurada para true. Já na submissão do formulário (linha 14) a confirmação é desativa.

Usando orientação a objetos

Agora vamos extrair essa funcionalidade para uma objeto JavaScript, salvando o código em um arquivo .js.

function ExitPageConfirmer(message) {
  this.message = message;
  this.needToConfirm = false;

  var myself = this;

  window.onbeforeunload = function() {
     if (myself.needToConfirm) {
       return myself.message;
     }
   }
}

O objeto ExitPageConfirmer recebe como parâmetro no seu construtor a mensagem de confirmação. Por padrão, a necessidade de exibir a confirmação é configurada para false. Veja um exemplo de sua utilização:

var exitPage = new ExitPageConfirmer("Minha mensagem de confirmação.");

E quando quiser ativar a exibição da mensagem de confirmação:

exitPage.needToConfirm = true;

Vamos utilizar nosso confirmador de saída de página no formulário HTML do exemplo anterior:

<html>
<head>
  <script src="scripts/Prodis.ExitPageConfirmer.js"></script>
  <script>
    var exitPage = new ExitPageConfirmer("Minha mensagem de confirmação.");
  </script>
</head>
<body>
  <form onsubmit="exitPage.needToConfirm = false;">
    <p><input type="text" onchange="exitPage.needToConfirm = true;" /></p>
    <p><input type="submit" /></p>
  </form>
</body>
</html>

Na linha 3 fizemos a referência para o arquivo .js que contém o código do confirmador e criamos uma instância de ExitPageConfirmer na linha 5. Nas linhas 9 e 10 configuramos a necessidade de exibir ou não a mensagem de confirmação utilizando usando a variável exitPage.

Detalhe sobre a implementação

Há um detalhe interessante sobre a implementação do objeto ExitPageConfirmer. Vamos ver o código novamente para ficar mais fácil de visualizar.

function ExitPageConfirmer(message) {
  this.message = message;
  this.needToConfirm = false;

  var myself = this;

  window.onbeforeunload = function() {
     if (myself.needToConfirm) {
       return myself.message;
     }
   }
}

Na linha 3 é criada a variável myself que recebe o valor de this. O this nesse escopo se refere à instância do objeto. Por exemplo, quando criamos a variável exitPage no código do formulário, o this dentro do objeto se refere a essa variável.

Dentro da função que é passada para o evento onbeforeunload do objeto window existe um if verificando o valor de needToConfirm do próprio objeto ExitPageConfirmer. Isso serve de condição para exibir a mensagem confirmação.

Mas por que não usamos this.needToConfirm ao invés de myself.needToConfirm na linha 8?

Acontece que a partir do momento que estamos configurando algo dentro do objeto window, o this se refere ao objeto window e não mais ao objeto ExitPageConfirmer. Sendo assim, criamos a variável myself que recebe uma referência da instância atual do objeto ExitPageConfirmer.

Como a variável myself fica disponível também no escopo da função que é atribuída ao evento onbeforeunload do objeto window, podemos utilizá-la sem problemas.

O escopo da variável myself se limita ao construtor de ExitPageConfirmer, então a mesma não pode ser acessada de fora do objeto.

Conclusão

O objeto ExitPageConfirmer pode ser utilizado em qualquer página, evitando assim a duplicidade de código. Além disso, o uso de programação orientada a objetos em JavaScript, ao invés de abordagem procedural, torna o código mais elegante e fácil de manter.

O código completo você encontra aqui no meu Github.

Referência:
Asking Users To Confirm If They Wish To Leave The Page

JavaScript , , , , ,

Anotações sobre o livro “JavaScript: The Good Parts”

15 de agosto de 2010

Em geral quando eu leio um livro, costumo fazer anotações de trechos interessantes que encontro.

No livro JavaScript: The Good Parts, de Douglas Crockford, encontrei um punhado deles. Eu listo esses trechos aqui, até sendo um forma de eu organizar meu estudo.

Só lembrando que minha intenção não é publicar partes do livro. Na verdade, espero que você, que usa/gosta de JavaScript, se sinta incentivado a ler o livro, o qual gostei muito e recomendo.

Ah, para quem quiser, também há a versão traduzida para português, O Melhor do JavaScript, publicada pela editora Alta Books.

Analisando o JavaScript

O JavaScript se baseia em algumas idéias muito boas, que incluem funções, tipificação fraca e objetos dinâmicos, e umas poucas idéias ruins, como um modelo de programação baseado em variáveis globais.

Se você deseja aprender sobre as partes ruins e como mal utilizá-las, consulte qualquer outro livro sobre JavaScript.

Números

Há um único tipo de número, onde não há um tipo inteiro distinto, diferente de outras linguagens de programação. Então 1 e 1.0 têm o mesmo valor.

Strings

Strings são imutáveis, nunca podem ser alteradas. Concatenando com o operador “+”, uma nova string é criada.

Duas strings que contém os mesmos caracteres na mesma ordem são considerados a mesma string. Por exemplo, o resultado da expressão abaixo é true.

"P" + "r" + "o" + "d" + "i" + "s" === "Prodis" // true
Escopo

Diferente de outras linguagens, os blocos (grupo de comandos entre chaves) não criam um novo escopo. Uma variável declarada dentro de um bloco é visível em qualquer lugar da função que contém esse bloco. Sendo assim, as variáveis não deveriam ser definidas nos blocos, e sim no começo da função.

Valores booleanos

false, null, undefined, string vazia “”, o número 0 e o número NaN são valores falsos. Todos os outros valores são considerados verdadeiro, inclusive true, a string “false” e os demais objetos.

Operador typeof

“number”, “string”, “boolean”, “undefined”, “function” e “object” são valores retornados por typeof. Para o uso de typeof com null ou uma matriz, o retorno é “object”, o que não é certo. Um teste melhor para detectar nulos é simplesmente:

myValue === null
Objetos

Números, strings e booleanos não são objetos, pois são imutáveis. Objetos são grupos mutáveis com índices. Matrizes, funções, expressões regulares e objetos são objetos.

Para criar novos valores de objetos, uma forma conveniente é criar um objeto literal, um par de chaves contendo zero ou mais pares nome/valor. Por exemplo:

var contact = {
  "email" = "pedro@bo.com.br",
  "phone" = "(11) 9999-9999"
}

Todo objeto é ligado a um protótipo de onde ele pode herdar propriedades. Todos os objetos criados de literais são associados a Object.prototype, um objeto que vem como padrão no JavaScript.

Funções

A melhor coisa que JavaScript possui é sua implementação de funções.

Funções são ligadas à Function.prototype, que está ligada à Object.prototype.

Funções podem ser armazenadas em váriaveis, objetos e matrizes. Elas podem ser passadas como parâmetros para funções e serem retornadas por funções. E como são objetos, funções também podem ter métodos.

Quando uma função é chamada e os parâmetros não coincidem, não há erro em tempo de execução. Se os valores informados excederem a quantidade de parâmetros, os valores excedentes são ignorados. Se o inverso acontecer, undefined será atribuído aos valores faltantes.

Uma função sempre retorna um valor. Se um valor não for fornecido no comando return, então undefined é retornado.

Ao invés de escopo de bloco, JavaScript possui escopo de função. Todos os parâmetros e variáveis definidos em uma função não são visíveis fora dela. É recomendável declarar todas as variáveis utilizadas em uma função no início do corpo da função, diferente de outras linguagens onde as variáveis geralmente são declaradas logo antes de sua utilização.

Partes péssimas e ruins

A dependência de variáveis globais é a pior parte do JavaScript, pois uma dessas variáveis pode ser alterada em qualquer parte do código e em qualquer momento, algo que pode complicar muito o comportamento de um programa.

O operador “+” é utilizado tanto para concatenar strings, quanto para somar números. Se você quer usá-lo para somar, precisa se certificar que os dois operandos são números. Caso contrário, esses operandos serão convertidos em strings. Veja o exemplo abaixo:

10 + 15 // 25
10 + "15" // "1015"

O valor NaN (not a number) é um tanto incoerente. O typeof não distingue entre números e NaN:

typeof(NaN) // "number"

E NaN não é igual a ele mesmo:

NaN === NaN // false
NaN !== NaN // true

No JavaScript, há dois grupos de operadores de igualdade:

  • Os bons: === e !==
  • E os maus: == e !=

Os bons funcionam como esperado: se dois operando tiverem o mesmo valor e forem do mesmo tipo, === retorna true e !== retorna false. Já os maus funcionam bem quando os operando são do mesmo tipo, mas quando eles são de tipos diferentes, eles tentam fazer coerção de tipo e coisas estranhas podem acontecer:

"" == "0" // false
0 == ""   // true
0 == "0"  // true

false == "false" // false
false == "0"     // true

false == undefined // false
false == null     // false
null == undefined  // true

" \t\r\n " == 0 // true

O melhor é sempre usar o grupo de bons operados de igualdade: === e !==.

JavaScript, Livros , ,