iMasters

A cada dia os designers são premiados com novos recursos de HTML e CSS que visam ampliar as possibilidades do desenvolvimento front-end. Porém, nem sempre os browsers acompanham o ritmo do surgimento das novidades – e nem sempre os usuários estão em dia com as atualizações de seus navegadores. 

Texto original disponível em http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

⁂

Blocks, Procs e Lambdas (definidas closures na Ciência da Computação) são uns dos aspectos mais poderosos do Ruby, e também os mais incompreendidos. Isso provavelmente acontece porque o Ruby lida com closures de uma maneira única. O que deixa as coisas mais complicadas é o fato de o Ruby ter quatro maneiras diferentes de usar closures, cada uma delas um pouquinho diferente, e às vezes sem sentido. Existe um bom número de sites com informações muito boas sobre como trabalhar com closures dentro do Ruby. Mas eu ainda tenho que encontrar um guia definitivo por aí. Espero que este artigo assuma essa função.  

Primeiro, Blocks

O jeito mais fácil, comum e comprovado de usar closures no Ruby é dentro de blocks. Eles têm a seguinte sintaxe:

array = [1, 2, 3, 4]

array.collect! do |n|
  n ** 2
end

puts array.inspect

# => [1, 4, 9, 16]

Então, o que está acontecendo aqui?

1. Primeiro, nós mandamos o método collect! para um Array com um bloco de código.
2. O bloco do código interage com uma variável usada dentro do método collect! (nesse caso n) e o eleva ao quadrado.
3. Cada elemento dentro do Array agora está elevado ao quadrado.

Usar um block com o método collect! é bem fácil, nós apenas temos que pensar que esse collect! vai usar o código dado dentro de cada elemento no Array. No entanto, e se quisermos fazer nosso próprio método collect!? Como ele vai ser? Bem, vamos construir um método chamado iterate! e vamos ver.

class Array
  def iterate!
    self.each_with_index do |n, i|
      self[i] = yield(n)
    end
  end
end

array = [1, 2, 3, 4]

array.iterate! do |n|
  n ** 2
end

puts array.inspect

# => [1, 4, 9, 16]

Para começar, nós reabrimos a classe do Array e colocamos o método iterate! dentro dela. Nós vamos continuar com as convenções do Ruby e colocar um "bang" no final, dizendo aos nossos usuários para tomar cuidado, pois esse método pode ser perigoso! Então usamos nosso método iterate! da mesma maneira que o Ruby fez no método collect! No entanto, a melhor parte está bem no meio da nossa definição de método iterate!.

Diferentemente de atributos, você não precisa especificar o nome dos blocks dentro dos seus métodos, você pode usar a palavra-chave yield. Ao chamar essa palavra-chave, ela vai executar o código dentro do block fornecido ao método. Além disso, note como estamos passando o n (o número inteiro com que o método each_with_index está trabalhando no momento) ao yield. Os atributos passados ao yield correspondem às variáveis especificadas na piped list do block. Esse valor agora está disponível para o block, e devolvido pelo chamado yield. Para recapitular o que está acontecendo:

1. Mande iterate! para o Array de números.
2. Quando o yield é chamado com o número n (primeira vez é 1, segunda vez é 2 etc…), passe o número para o block do código fornecido.
3. O block tem o número disponível (também chamado n) e o eleva ao quadrado.  Como este é o último valor gerenciado pelo block, ele é devolvido automaticamente.
4. O yield devolve o valor retornado pelo bloco e sobreescreve o valor no Array.
5. Isso continua para cada elemento no Array.

O que nós temos agora é uma maneira flexível de interagir com o nosso método. Entenda os blocks como aqueles que estão dando a seu método uma API, na qual você pode determinar que cada valor do Array seja elevado ao quadrado, ou ao cubo, ou converter cada número em uma string e imprimi-los na tela. As opções são infinitas, deixando seu método bem flexível e, assim, muito poderoso.

No entanto, esse é apenas o começo. Utilizar o yield é uma maneira de usar seu block de código, mas existe um outro, chamado de Proc. Dê uma olhada.

class Array
  def iterate!(&code)
    self.each_with_index do |n, i|
      self[i] = code.call(n)
    end
  end
end

array = [1, 2, 3, 4]

array.iterate! do |n|
  n ** 2
end

puts array.inspect

# => [1, 4, 9, 16]

Parece bem similar ao nosso exemplo anterior, no entanto existem duas diferenças. Primeiro, nós estamos passando um argumento ampersand chamado &code. Esse argumento é, convenientemente suficiente, o nosso block. O segundo é o meio da nossa definição de método iterate!, no qual em vez de usar o yield, mandamos um chamado para todos os nossos blocos de códigos. O resultado é exatamente o mesmo. No entanto, se isso é verdade, por que então temos essa diferença em sintaxe? Bom, ela nos ensina um pouco mais sobre o que blocks realmente são. Dê uma olhada:

def what_am_i(&block)
  block.class
end

puts what_am_i {}

# => Proc

Um block é simplesmente um Proc! Dito isso, o que é um Proc?

Procedimentos, mais conhecidos como Procs

Blocks são bastante convenientes e sintaticamente simples, no entanto é melhor termos vários blocks diferentes à nossa disposição e usá-los múltiplas vezes. Assim, passar o mesmo block múltiplas vezes faria com que nós nos repetíssemos. Como o Ruby é completamente orientado ao objeto, isso pode ser contornado de uma maneira tranquila, ao salvar o código reutilizável como sendo um objeto. O objeto reutilizável é chamado Proc (abreviação para procedimento). A única diferença entre blocks e Procs é que um block é um Proc que não pode ser salvo e, assim, é uma solução única. Ao trabalhar com Procs, podemos começar a fazer o seguinte:

class Array
  def iterate!(code)
    self.each_with_index do |n, i|
      self[i] = code.call(n)
    end
  end
end

array_1 = [1, 2, 3, 4]
array_2 = [2, 3, 4, 5]

square = Proc.new do |n|
  n ** 2
end

array_1.iterate!(square)
array_2.iterate!(square)

puts array_1.inspect
puts array_2.inspect

# => [1, 4, 9, 16]
# => [4, 9, 16, 25]

Por que block em caixa baixa e Proc em caixa alta?

Eu sempre escrevo o Proc em caixa alta como se fosse uma própria classe dentro do Ruby. No entanto, blocks não têm uma classe (afinal eles são apenas Procs) e são apenas um tipo de sintaxe dentro do Ruby. Por isso, eu escrevo blocks em caixa baixa. Mais para frente neste artigo, você verá que eu também escrevo lambda em caixa baixa. Eu faço isso pelo mesmo motivo.

Note como nós não precedemos com um & o atributo do código no nosso método iterate!. Isso é porque passar Procs não é diferente de passar qualquer outro tipo de dado. Como os Procs são criados como qualquer outro objeto, podemos começar a nos divertir e a forçar o intérprete do Ruby a fazer algumas coisas interessantes. Tente isto aqui:

class Array
  def iterate!(code)
    self.each_with_index do |n, i|
      self[i] = code.call(n)
    end
  end
end

array = [1, 2, 3, 4]

array.iterate!(Proc.new do |n| 
  n ** 2
end)

puts array.inspect

# => [1, 4, 9, 16]

Acima temos como a maioria das linguagens lida com closures, e é exatamente o mesmo que enviar um block. No entanto, se você pensou que isso não parece com o “jeito Ruby”, eu vou ter que concordar. A razão acima é exatamente o porquê de o Ruby ter blocos, e isso é para permanecer de acordo com a familiar sintaxe de conclusão "end".

Se esse é o caso, por que não usar somente blocks? Bem, a resposta é simples, e se nós quisermos passar duas ou mais closures para um método? Se esse é o caso, blocks rapidamente se tornam muito limitados. No entanto, ao ter Procs, podemos fazer algo como:

def callbacks(procs)
  procs[:starting].call

  puts "Still going"

  procs[:finishing].call
end

callbacks(:starting => Proc.new { puts "Starting" },
          :finishing => Proc.new { puts "Finishing" })

# => Starting
# => Still going
# => Finishing

Então quando devemos usar blocks no lugar de Procs? Minha lógica é a seguinte:

1. Block: Seu método está quebrando um objeto em pedaços menores, e você quer permitir que seus usuários interajam com esses pedaços.
2. Block: Você quer executar expressões múltiplas automaticamente, como uma migração de banco de dados.
3. Proc: Você quer reutilizar um bloco de código múltiplas vezes.
4. Proc: Seu método vai ter um ou mais callbacks.

Lambdas

Até agora, você usou Procs de duas maneiras, passando-os diretamente como um atributo e salvando-ps como uma variável. Esses Procs agem de maneira muito similar ao que outras linguagens chamam de funções anônimas, ou lambdas. Para deixar as coisas mais interessantes, lambdas estão disponíveis no Ruby também. Dê uma olhada:

class Array
  def iterate!(code)
    self.each_with_index do |n, i|
      self[i] = code.call(n)
    end
  end
end

array = [1, 2, 3, 4]

array.iterate!(lambda { |n| n ** 2 })

puts array.inspect

# => [1, 4, 9, 16]

À primeira vista, lambdas parecem ser exatamente iguais aos Procs. No entanto, existem duas diferenças sutis. A primeira é que, diferentemente de Procs, lambdas checam o número de argumentos passados.

def args(code)
  one, two = 1, 2
  code.call(one, two)
end

args(Proc.new{|a, b, c| puts "Give me a #{a} and a #{b} and a #{c.class}"})

args(lambda{|a, b, c| puts "Give me a #{a} and a #{b} and a #{c.class}"})

# => Give me a 1 and a 2 and a NilClass
# *.rb:8: ArgumentError: wrong number of arguments (2 for 3) (ArgumentError)

Vemos com o exemplo do Proc que variáveis extras são definidas no nil. No entanto, com lambdas, em vez disso, o Ruby gera um erro.

A segunda diferença é que lambdas têm retornos diminutos. O que isso significa é que, enquanto o retorno de um Proc vai parar um método e retornar o valor fornecido, lambdas vão retornar o seu valor ao método e deixá-lo continuar. Confuso? Vamos ver um exemplo:

def proc_return
  Proc.new { return "Proc.new"}.call
  return "proc_return method finished"
end

def lambda_return
  lambda { return "lambda" }.call
  return "lambda_return method finished"
end

puts proc_return
puts lambda_return

# => Proc.new
# => lambda_return method finished

Em proc_return, nosso método aciona a palavra-chave return, ele pára de processar o resto do método e retorna a string Proc.new. Por outro lado, nosso método lambda_return aciona nosso lambda - o que retorna o string lambda –, continua processando, encontra o próximo return e retorna  lambda_return. Por que a diferença?

A resposta está nas diferenças conceituais entre procedimentos e métodos. No Ruby, Procs são trechos dentro do código, não métodos. Por causa disso, o retorno do Proc é o retorno do método proc_return, e ele age adequadamente a isso. No entanto, lambdas agem como métodos, ao checar o número de argumentos e não substituir os métodos return. Por esse motivo, é melhor pensar em lambdas como uma nova maneira de escrever métodos, uma maneira anônima.

Então quando você deve escrever um método anônimo (lambda) em vez de um Proc? O código a seguir mostra um exemplo:

def generic_return(code)
  code.call
  return "generic_return method finished"
end

puts generic_return(Proc.new { return "Proc.new" })
puts generic_return(lambda { return "lambda" })

# => *.rb:6: unexpected return (LocalJumpError)
# => generic_return method finished

Parte da sintaxe do Ruby é que argumentos (um Proc neste exemplo) não podem ter uma palavra-chave return dentro deles. No entanto, um lambda age da mesma maneira que um método, o que pode ter um retorno literal, e assim passar ileso por esse requerimento! Essa diferença em semântica aparece em situações como a do exemplo a seguir:

def generic_return(code)
  one, two    = 1, 2
  three, four = code.call(one, two)
  return "Give me a #{three} and a #{four}"
end

puts generic_return(lambda { |x, y| return x + 2, y + 2 })

puts generic_return(Proc.new { |x, y| return x + 2, y + 2 })

puts generic_return(Proc.new { |x, y| x + 2; y + 2 })

puts generic_return(Proc.new { |x, y| [x + 2, y + 2] })

# => Give me a 3 and a 4
# => *.rb:9: unexpected return (LocalJumpError)
# => Give me a 4 and a 
# => Give me a 3 and a 4

Aqui, nosso método generic_return está esperando a closure para retornar dois valores. No entanto, fazer isso sem a palavra-chave return se torna arriscado. Com o lambda, tudo é fácil. No entanto, com o Proc, temos que tirar vantagem do modo que o Ruby interpreta os Arrays com atribuições.

Então quando usar Proc em vez de lambdas, e vice-versa? Honestamente, além da checagem de argumentos, a diferença é simplesmente como você vê as closures. Se você tem a finalidade de passar blocks de códigos, fique com o Proc. Se mandar um método para outro método que pode retornar um método faz sentido para você, use lambdas. Mas se lambdas são apenas métodos em forma de objetos, podemos armazenar métodos existentes e passá-los como Procs? Para isso, o Ruby tem algo intrigante debaixo da manga.

Métodos dos objetos (Method Objects)

Então você já tem um método que funciona, mas você quer passá-lo para outro método como uma closure, e manter seu código. Para fazer isso, você pode tirar vantagem do método do Ruby:

class Array
  def iterate!(code)
    self.each_with_index do |n, i|
      self[i] = code.call(n)
    end
  end
end

def square(n)
  n ** 2
end

array = [1, 2, 3, 4]

array.iterate!(method(:square))

puts array.inspect

# => [1, 4, 9, 16]

Nesse exemplo, nós já temos um método chamado square (potência de 2) que funcionaria bem para essa tarefa. Assim, podemos utilizá-lo novamente como um parâmetro ao convertê-lo a um método do objeto e passando-o para o nosso método iterate!. Mas qual é esse novo tipo de objeto?

def square(n)
  n ** 2
end

puts method(:square).class

# => Method

Bem, como você adivinhou, o square não é um Proc, mas um Método. A melhor parte é que esse método do objeto vai agir como um lambda, porque o conceito é o mesmo. Esse método, no entanto, é denominado método (chamado square), enquanto lambdas são denominadas métodos anônimos.

Conclusão

Para recapitular, vimos quatro tipos de closures no Ruby - blocks, Procs, lambdas e Methods. Nós também sabemos que blocks e Procs agem da mesma maneira que métodos. Finalmente, através de uma grande quantidade de exemplos de código, você está pronto para decidir quando usar cada um deles da maneira correta. Agora você deve ser capaz de começar a utilizar esse interessante e expressivo recurso do Ruby no seu próprio código, e começar a oferecer métodos flexíveis e poderosos aos outros desenvolvedores que trabalham com você.

---

artigo publicado originalmente no iMasters, por Roberto Sosinski

O ato de escrever códigos faz com que você seja um cara que programa, mas não necessariamente um programador.

Texto original disponível em http://www.zimuel.it/blog/2011/02/encrypt-php-session-data/

⁂

Este artigo apresenta um exemplo de sólida criptografia no PHP para proteger os dados de sessão.

É uma implementação bastante simples, que pode ser usada para melhorar a segurança de aplicações PHP, especialmente em ambientes compartilhados, nos quais diferentes usuários têm acesso aos mesmos recursos. Como você sabe, as sessões de dados PHP são gerenciadas, por padrão, usando arquivos temporários. Em um ambiente compartilhado, um usuário malicioso que é capaz de acessar esses arquivos temporários pode facilmente ler os dados de sessão, uma vez que eles estão armazenados em plaintext (dados em um arquivo de sessão são a serialização do array $_SESSION).

Em teoria, os dados de sessão deveriam ser armazenados em arquivos que são acessíveis somente ao proprietário do site, mas nunca diga nunca (inclusive, você pode gerenciar o local dos dados de sessão usando a função session_save_path ou mudando o session_save_path no the php.ini).

Para proteger os dados de sessão, eu usei uma sólida criptografia para criptografar o conteúdo usando a extensão mcrypt do PHP. Eu escolhi a cifra simétrica AES (Rijandel-256) para criptografar os dados de sessão e a função openssl_random_pseudo_bytes() para gerar uma chave randômica do bit 256.

A ideia é usar um cookie variável para armazenar a chave que será utilizada para criptografar os dados de sessão. Dessa maneira, a chave é armazenada somente no cliente (o browser) e somente o cliente é capaz de descriptografar os dados de sessão no servidor. Cada vez que criptografamos os dados de sessão, nós geramos mais uma vez o vetor IV de uma maneira randômica usando a função mcrypt_create_iv(). É muito importante gerar um único IV em cada criptografia. Essa prática aumenta a segurança do algoritmo de criptografia. É importante notar que essa implementação não protege contra um ataque de session hijacking. Se alguém for capaz de capturar o cookie variável de um cliente e ter acesso aos arquivos temporários da sessão, no servidor, ele ou ela serão capazes de descriptografar os dados de sessão. Nosso objetivo é proteger os dados de sessão contra ataques em ambientes compartilhados.

A ideia de criptografar dados de sessão não é nova, Chris Shiflett por exemplo, propôs uma implementação em seu livro “Essential PHP Security” (O’Reilly, 2006). Shiflett usou uma variável $_SERVER para armazenar a chave usada para criptografar os dados de sessão. Kevin Schroeder, meu colega na Zend Technologies, implementou um algoritmo de criptografia da sessão bem parecido, estendendo a classe Zend_Session class do Zend Framework (você pode encontrá-lo aqui). Na minha solução, eu usei algumas das melhores práticas relacionadas à uma sólida criptografia para implementar um handler de sessão segura.

Abaixo temos o código-fonte para a minha implementação:

/**
 * ------------------------------------------------
 * Encrypt PHP session data using files
 * ------------------------------------------------
 * The encryption is built using mcrypt extension 
 * and the randomness is managed by openssl
 * 
 * @author Enrico Zimuel (enrico@zimuel.it)
 * @copyright GNU General Public License
 */
class SecureSession {
    const CIPHER= MCRYPT_RIJNDAEL_256;
    const CIPHER_MODE= MCRYPT_MODE_CBC;
    /**
     * Key for encryption/decryption
     * 
     * @var string
     */
    private static $_key;
    /**
     * Path of the session file
     *
     * @var string
     */
    private static $_path;
    /**
     * Session name (optional)
     * 
     * @var string
     */
    private static $_name;
    /**
     * Size of the IV vector for encryption
     * 
     * @var integer
     */
    private static $_ivSize;
    /**
     * Cookie variable name of the key
     * 
     * @var string
     */
    private static $_keyName;
    /**
     * Generate a random key
     * fallback to mt_rand if PHP < 5.3 or no openssl available
     * 
     * @param integer $length
     * @return string
     */
    private static function _randomKey($length=32) {
         if(function_exists('openssl_random_pseudo_bytes')) {
    	          $rnd = openssl_random_pseudo_bytes($length, $strong);
        	  if($strong === TRUE) 
        	       return $rnd;
         }
         for ($i=0;$i<$length;$i++) {
              $sha= sha1(mt_rand());
          $char= mt_rand(0,30);
          $rnd.= chr(hexdec($sha[$char].$sha[$char+1]));
         }	
         return $rnd;
    }
    /**
     * Open the session
     * 
     * @param string $save_path
     * @param string $session_name
     * @return bool
     */
    public static function open($save_path, $session_name) {
        self::$_path= $save_path.'/';	
    self::$_name= $session_name;
    self::$_keyName= "KEY_$session_name";
    self::$_ivSize= mcrypt_get_iv_size(self::CIPHER, self::CIPHER_MODE);

    if (empty($_COOKIE[self::$_keyName])) {
         $keyLength= mcrypt_get_key_size(self::CIPHER, self::CIPHER_MODE);
         self::$_key= self::_randomKey($keyLength);
         $cookie_param = session_get_cookie_params();
             setcookie(
                  self::$_keyName,
                  base64_encode(self::$_key),
                  $cookie_param['lifetime'],
                  $cookie_param['path'],
                  $cookie_param['domain'],
                  $cookie_param['secure'],
                  $cookie_param['httponly']
             );
    } else {
         self::$_key= base64_decode($_COOKIE[self::$_keyName]);
    } 
    return true;
    }
    /**
     * Close the session
     * 
     * @return bool
     */
    public static function close() {
        return true;
    }
    /**
     * Read and decrypt the session
     * 
     * @param integer $id
     * @return string 
     */
    public static function read($id) {
        $sess_file = self::$_path.self::$_name."_$id";
  	$data= @file_get_contents($sess_file);
  	if (empty($data)) {
  		return false;
  	}
  	$iv= substr($data,0,self::$_ivSize);
  	$encrypted= substr($data,self::$_ivSize);
  	$decrypt = mcrypt_decrypt(
             self::CIPHER,
             self::$_key,
             $encrypted,
             self::CIPHER_MODE,
             $iv
        );
        return rtrim($decrypt, ""); 
    }
    /**
     * Encrypt and write the session
     * 
     * @param integer $id
     * @param string $data
     * @return bool
     */
    public static function write($id, $data) {
        $sess_file = self::$_path.self::$_name."_$id";
    $iv= mcrypt_create_iv(self::$_ivSize, MCRYPT_RAND);
    if ($fp = @fopen($sess_file, "w")) {
         $encrypted= mcrypt_encrypt(
                  self::CIPHER,
                  self::$_key,
                  $data,
                  self::CIPHER_MODE,
                  $iv
              );
          $return = fwrite($fp, $iv.$encrypted);
          fclose($fp);
          return $return;
     } else {
          return false;
     }
    }
    /**
     * Destroy the session
     * 
     * @param int $id
     * @return bool
     */
    public static function destroy($id) {
        $sess_file = self::$_path.self::$_name."_$id";
        setcookie (self::$_keyName, '', time() - 3600);
    return(@unlink($sess_file));
    }
    /**
     * Garbage Collector
     * 
     * @param int $max 
     * @return bool
     */
    public static function gc($max) {
    	foreach (glob(self::$_path.self::$_name.'_*') as $filename) {
    	     if (filemtime($filename) + $max < time()) {
      	          @unlink($filename);
    	     }
  	}
  	return true;
    }
}
// Set the custom PHP session handler
ini_set('session.save_handler', 'user');
session_set_save_handler(array('SecureSession', 'open'),
                         array('SecureSession', 'close'),
                         array('SecureSession', 'read'),
                         array('SecureSession', 'write'),
                         array('SecureSession', 'destroy'),
                         array('SecureSession', 'gc')
);

Você pode fazer o donwload da classe SecureSession aqui.

Para poder usar a classe SecureSession, você tem que incluí-la no seu projeto PHP antes da função session_start.

Depois disso você pode usar a sessão PHP como de costume.

---

artigo publicado originalmente no iMasters, por Enrico Zimuel

Olá, pessoal!

Texto original disponível em http://davidwalsh.name/mootools-history

⁂

Uma das razões pelas quais gosto da tecnologia AJAX é porque ela permite evitar que páginas desnecessárias sejam carregadas. Por que carregar o cabeçalho, o rodapé, e outros dados estáticos múltiplas vezes se eles não mudam? É um desperdício de tempo, processamento e conexão. Infelizmente, até o momento, atualizações constantes são a norma na internet – mas elas não precisam ser.

Christoph Pojer, um desenvolvedor MooTools, adicionou o plugin para gerenciamento de histórico à sua biblioteca Power Tools. Ele substitui o carregamento de URLs do mesmo site fornecendo um método para capturar cliques de links, carregar o conteúdo das páginas via AJAX (Mootools' Request.HTML class), modificar o objeto que guarda endereço da página para manter registros de histórico, e reavaliar conteúdos de links para permitir que os desenvolvedores criem websites de uma página rápidos e eficientes.

Ver Demo 

O método tradicional de um sistema de histórico dinâmico com suporte do "botão voltar" sempre foi baseado no uso de JavaScript com endereços de âncora hash. Tecnologias mais novas, incluindo métodos HTML5's window.onpopstate and history.pushState permitem opções mais confiáveis de administrar o histórico. O plugin Moo Tools para gerenciamento de histórico suporta métodos modernos para administração do histórico. Deixe-me mostrar como implementá-lo rapidamente.

Estrutura HTML

O plugin para gerenciamento de histórico não necessita de nenhum ajuste da estrutura HTML, mas pelo menos um conteúdo designado deve ser identificado; você pode, naturalmente, ter quantas áreas de conteúdo quiser, mas precisará de solicitações múltiplas ao AJAX para acessá-las, a menos que você use uma solicitação Request.JSON para acessar o conteúdo de múltiplas áreas da página. Para essa simples demonstração, definiremos um cabeçalho, um rodapé e uma área de conteúdo:

<div id="body">

  <!-- header -->
  <header>
    <a href="/" data-noxhr>David Walsh Blog</a> <!-- fresh page load due to "data-noxhr" -->
    <div>MooTools History Plugin Demo</div>
    <div>This is a simple example of the MooTools History plugin created by Christoph Pojer</div>

  </header>

  <!-- menu -->
  <ul id="demoMenu">
    <li><a href="mootools-history.php">Home</a></li>
    <li><a href="mootools-history-david.php">About David Walsh</a></li>
    <li><a href="mootools-history-mootools.php">About MooTools</a></li>
    <li><a href="mootools-history-christoph">About Christoph Pojer</a></li>
  </ul>

  <!-- content area -->
  <article id="contentHolder">

    <!-- initial page content goes here -->

  </article>


  <!-- footer -->
  <footer>

  </footer>
</div>

A área de conteúdo é a única parte que terá mudanças. A página deverá carregar como de costume.

O JavaScript MooTools

Considerando que o plugin MooTools para gerenciamento de histórico foi incluído na página, há algumas poucas funções que devem ser criadas no domready. O primeiro é um método que executará a solicitação de conteúdo quando um link é clicado:

// Content holder (all content placed within this element)
var contentHolder = document.id("contentHolder");

// Create a Request object which will be reused when links are clicked
var request = new Request.HTML({
  onSuccess: function(nodeTree,elements,html) {
    // Set the content into the content holder
    contentHolder.set("html",html);
    // Execute directions that should be executed whenever a page changes
    onPageUpdate();
  }
});

// Create a function that loads the page content
var loadPage = function(url) {
  // Make a HTML request to get the content for this page
  request.send({ url: url });
};

O próximo passo é a criação de um método (teoricamente opcional, mas você normalmente vai querer fazer alguma coisa uma vez que o conteúdo tenha sido carregado) que rodará toda vez que um conteúdo seja recebido:

// Function that will execute whenever a page gets changed
var onPageUpdate = function() {

  // Do whatever you'd like here!  

  // Possibly manually record a Google Analytics page view?

};

O plugin MooTools para gerenciamento de histórico não solicita que você faça qualquer coisa quando um conteúdo é recebido, mas provavelmente você vai querer fazer alguma coisa. Por que gravar manualmente  a visualização da página dentro do Google Analytics?

O próximo pedaço é importante em deixar os links das páginas estáticas passarem pelo armazenador de histórico baseado em ajax. Uma única linha do Element.Delegation já consegue realizar o trabalho - não só para o carregando da página inicial, mas para todo carregamento que será executado depois disso:

// The listener that manages all clicks
var listener = function(evt){
  evt.preventDefault(); // Prevent following the URL
  History.push(this.get('href')); // Push the new URL into History
};

// Add event delegation to add clicks.  Both of these work:
//document.body.addEvent("click:relay(a:not([href=#]):not([href^=http://]):not([data-noxhr]))",listener);
document.body.addEvent("click:relay(a:not([href=#],[href^=http://],[data-noxhr]))",listener);

Quando qualquer link que aponta para outra página é clicado, o método listener pára o evento e envia a nova URL para o plugin, mudando a barra de endereços, administrando o clique do botão back/forward.

Uma função back também é criada de forma que possamos providenciar um link “back” e um link “forward”, para andar para trás e para frente no histórico da página, se escolhermos usá-lo:

// Listener for the "Back" link
var back = function(evt){
  evt.preventDefault();
  History.back(); // Go back
};

// Listener for the "Forward" link
var forward = function(evt){
  evt.preventDefault();
  History.forward(); // Go back
};

// Add to links
document.id("backLink").addEvent("click",back);
document.id("forwardLink").addEvent("click",forward);

O próximo passo é adicionar um evento change no próprio plugin para gerenciamento de histórico para rodar nossa função loadPage quando a URL da página muda:

// When the history changes, update the content 
History.addEvent('change',loadPage);

Se o cliente não suporta o método history.pushState, o plugin avalia o hash e carrega a página como necessário:

// Handle the initial load of the page if the browser does not support pushState, check if the hash is set
if(!History.hasPushState()) {
  // Check if there is a hash
  var hash = document.location.hash.substr(1);
  if (!hash) return;

  // If the hash equals the current page, don't do anything
  var path = document.location.pathname.split('/');
  path = path[path.length - 1];
  if (hash == path) return;

  // Load the page specified in the hash
  loadPage(hash);
}

Finalmente, rodar onPageUpdate no carregamento domready não dói, uma vez que os eventos são adicionados uma vez na onPageUpdate:

// Update the page
onPageUpdate();

Agora a página está pronta para suportar permutas de conteúdo baseadas no plugin para gerenciamento de histórico e operadas pelo AJAX. Graças à função onPageUptade, links são adicionados a eventos na medida em que chegam, de modo que até os conteúdos recuperados pelo AJAX podem ser administrados pelo plugin.

Dicas e estratégias para websites que mantêm histórico com hash 

Plugins como o do MooTools para gerenciamento de histórico, a obra prima de Christoph, são muito úteis no enriquecimento da experiência do usuário, mas necessitam de um pouco do conhecimento da lógica do desenvolvedor:

• Uso do Event Delegation – Lembre-se de que num sistema do estilo do plugin MooTools para gerenciamento de histórico, designar eventos a elementos diretamente pode não ser a melhor solução, porque tais elementos podem desaparecer no próximo clique de um link. Usar event delegation em vez de tradicionalmente delegar eventos aos elementos pode lhe poupar de um monte de problemas. Leia o topico MooTools Element.Delegation se não estiver familizarizado com event delegation.

• Não assuma suporte para JavaScript – Tenha em mente de que o cliente pode não suportar JavaScript. Mecanismos de busca adicionaram suporte para JavaScript, mas é importante usar URLs que trabalhem tanto em sites gerenciados pelo plugin MooTools para gerenciamento de histórico quanto em websites sem JavaScript.

• Use detecão para AJAX – O MooTools proporciona um cabeçalho específico para AJAX na requisição chamada HTTP_X_REQUESTED_WITH.  Clique aqui para aprender como usá-lo para detectar solicitações de AJAX. Você vai querer ser capaz de detectar o AJAX de forma que tais solicitações simplesmente retornem o conteúdo, e não o cabeçalho ou o rodapé (etc) juntamente com ele. Você pode escrever um client-side script/regex para analisar o conteúdo, mas isso é muito ineficiente. Meu demo usa PHP para armazenar o conteúdo da página em variáveis, como segue:

// Load pages based on querystring
$qstring = $_SERVER['QUERY_STRING'];
if($qstring == 'home' || $qstring == '') {
  $content.= '<h1>Welcome Home!</h1>';
  $content.= '<p>History Management via popstate or hashchange. Replaces the URL of the page without a reload and falls back to Hashchange on older browsers.</p><p>This demo page aims to teach you how you can use Christoph Pojer's outstanding History widget to load only the content you need, dynamically and reliably.</p>';
}
elseif($qstring == 'about-david') {
  $content.= '<h1>About David Walsh</h1>';
  $content.= '<p>My name is David Walsh. I'm a 27 year old Web Developer from Madison, Wisconsin. In the web world, I am:</p>
  <ul>
  <li>Founder and Lead Developer for Wynq Web Labs.</li>
  <li>Software Engineer for SitePen.</li>
  <li>Core Developer for the MooTools JavaScript framework.</li>
  <li>Co-Founder of Script & Style, a website aimed at making web developers and designers better.</li>
  </ul>
  <p>I don't design the websites - I make them work.</p>
  <p>I am also an admirer of the great <a href="?about-christoph">Christoph Pojer!</a>.</p>';
}
// and more....
// Page not found
else {
  $content.= '<h1>Page Not Found</h1>';
  $content.= '<p>The page you were attempting to find could not be found.</p>';
}

// If request was via AJAX, push it out.
if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
  echo $content;
  exit();
}

Obviamente seu sistema estará buscando conteúdo de um banco de dados ou outros arquivos estáticos, mas você entende o ponto – carregar o conteúdo antes de qualquer saída de página, aspirar para o AJAX e distribuir o conteúdo condizente. Se não for uma solicitação AJAX, você deve distribuir o conteúdo dentro das áreas de conteúdo do HTML, via métodos tradicionais.

Essas dicas devem bastar para colocá-lo em condições de usar um sistema baseado no plugin MooTools para gerenciamento de histórico. Lembre-se de que o JavaScript visa a melhorias – tenha em mente de que seu usuário (ou mecanismo de busca) pode não suportar JavaScript e, sendo assim, certifique-se testando seu website extensivamente!

Teste o exemplo. Clique de página em página, use o back button, dê refresh na página etc. O plugin MooTools para gerenciamento de histórico é sólido como uma rocha!

---

artigo publicado originalmente no iMasters, por David Walsh

Texto original disponível em http://programmingzen.com/2011/03/28/what-programming-language-should-i-learn-first/

⁂

Existem centenas de linguagens de programação diferentes por aí. Se você for um novato, pode ignorar o fato que a maioria delas existe. No entanto, mesmo se restringirmos a lista para apenas uma dúzia das linguagens mais importantes, decidir qual linguagem de programação aprender primeiro pode ser uma tarefa desafiadora. Você pode se perguntar: devo aprender primeiro C, C++, Java, C#, ou PHP? Se você fizer essa pergunta para 10 programadores, você provavelmente irá escutar 10 respostas diferentes. Aqui está a minha.

Da mesma maneira que as linguagens humanas, as linguagens de programação são utilizadas para comunicar. Curiosamente, elas também envolvem a comunicação entre pessoas, uma vez que outros programadores irão acabar lendo/modificando/melhorando seu código ou você fará isso em algum momento. Diferentemente das linguagens naturais, no entanto, as linguagens de programação são compreendidas perfeitamente por computadores, graças à ajuda de intérpretes, de compiladores e de outros tipos similares de software.

Dependendo do tipo de programa que você está tentando escrever, e em que ambiente você está trabalhando, você descobrirá que algumas linguagens de programação se encaixam melhor do que outras para certas tarefas, mesmo se as linguagens de programação mais comuns forem rotuladas como sendo para “uso geral”.

Por exemplo, se você quiser criar um aplicativo para iPhone e iPad, sua melhor aposta seria usar Objective-C. Para smartphones Android e tablets, na maioria dos casos, você precisará aprender tecnologias do lado cliente, como HTML, CSS e JavaScript (dessas 3, somente o JavaScript é uma linguagem de programação real, mas as outras duas são importantes do mesmo jeito). Para o lado servidor do seu aplicativo web, você provavelmente precisará aprender linguagens como PHP, Ruby, ou Python (todas as três têm frameworks que irão ajudar a deixar as tarefas web mais fáceis e menos demoradas), em vez de um sistema de programação favorito como o C. (Claro, é preciso mencionar o SQL se você estiver criando uma interface com um banco de dados relacional).

Então você deve começar sua aventura pelo mundo das linguagens de programação com o JavaScript? Mas e o Objective-C? SQL? Meu conselho é evitar começar sua jornada de programação com uma linguagem que é atrelada a um ambiente específico. No início do jogo, seu principal objetivo é aprender como programar – e como pensar como um programador – em vez de aprender uma linguagem específica. Uma vez que você estiver craque nos conceitos fundamentais com a ajuda do objetivo geral da linguagem de programação, você pode facilmente aprender novas linguagens à medida que a necessidade aparecer, dependendo do tipo de software que você gostaria de desenvolver.

Esta é uma profissão em que a maioria das suas habilidades são desenvolvidas e aperfeiçoadas quando você realmente pratica. Se você titubear nos fundamentos da programação, você pode facilmente escolher uma linguagem específica e um framework quando precisar construir aplicativos para iPad ou qualquer outra coisa que você queira criar.

Um programador bem preparado irá acabar aprendendo várias linguagens de programação e ferramentas ao longo de sua carreira. Dito isso, se você está apenas começando, foque em uma linguagem primeiro. Enquanto isso possa parecer um pouco bobo no início, a boa notícia é que, a não ser que você escolha uma linguagem de programação verdadeiramente exótica, muito do que você aprender também poderá ser usado em outras linguagens de programação. Lembre-se de que nesse estágio, acima de tudo, você está aprendendo como comunicar seus pensamentos em afirmações precisas para que outros programadores possam entender (e para o computador poder executar).

Por esse motivo, você não pode errar muito com qualquer uma das linguagens de programação com objetivos gerais (p.e., C, Java, C#, Perl, Ruby, Python, ou Scheme). Dito isso, se você está aprendendo sozinho, eu te aconselharia a escolher uma linguagem que irá tornar seu caminho de aprendizado mais fácil. Em outras palavras, opte por uma linguagem de programação que é vastamente usada, bem documentada, e amigável para iniciantes. Você está procurando por uma linguagem que não seja muito burocrática, não precise que você gerencie a memória diretamente, ou tenha conhecimentos profundos em matemática para começar.

Assim, minha sugestão seria começar com o Python, e a use como uma ferramenta para aprender a arte geral da programação. Aprender Python é divertido, fácil e útil. Você será capaz de usá-lo para uma vasta gama de projetos em diversos ambientes (scripting, web, pesquisa científica etc).

Existe uma variedade de tutoriais grátis na web, mas se você quiser instruções mais rigorosas/sistemáticas/acadêmicas, eu recomendo  “Python Programming: An Introduction to Computer Science (2nd Edition)” - “Programação em Python: Uma introdução à Ciência da Computação (Segunda Edição”) - (USA | UK | Canada).

Uma vez que você tiver aprendido os fundamentos da programação, tiver um conhecimento decente da linguagem Python, e tiver ganho alguma experiência com projetos práticos no Python, você deverá estar melhor preparado para evoluir e para escolher outras linguagens e frameworks baseados em projetos em que você tem interesse de desenvolver ou contribuir no futuro (projetos Open Source são ótimos para esse objetivo). 

---

artigo publicado originalmente no iMasters, por Antônio Cangiano

Neste artigo abordaremos um tema fundamental para administradores de sistemas GNU/Linux e também para usuários avançados deste sistema: o gerenciamento de pontos de montagem em modo Shell. Todas as técnicas explanadas neste artigo são aplicáveis a qualquer distro GNU/Linux.

Houve uma discussão interessante no JSMentors.com sobre JSONP e como deixá-lo mais seguro. Foi uma boa experiência, principalmente porque me forçou a examinar o assunto com profundidade e a apresentar uma contraproposta própria.

No primeiro artigo, falamos do JSON. Neste, abordaremos o JSONP.

Quando falamos de desenvolvimento ágil, logo pensamos em programação pareada, quadros de rendimento com tickets e, é claro, testes unitários com integração contínua.

Olá, pessoal!

Zend Server CE é a Edição da Comunidade do Servidor de Aplicação PHP da Zend Technologies. É um ambiente livre que pode ser utilizado para executar aplicações PHP usando recursos adicionais comparados com a versão PHP.net. Alguns desses recursos são:

Eu e o criador do moo4q  Ryan Florence geralmente concordamos na maioria dos tópicos relacionados com o JavaScript, dentre os quais o de que a maioria dos frameworks em JavaScript, inclusive jQuery, MooTools e Dojo, tem muito mais recursos do que a maioria dos websites precisa. Você não construiria um website de um grande empreendimento ou de uma corporação sem um framework extenso em JavaScript, mas muitos websites menores simplesmente não precisam de tantos recursos.