sexta-feira, 30 de outubro de 2015

Minhas aventuras no fantástico mundo de Haskell

Linguagens e raciocínio

Não cheguei a ler The Pragmatic Programmer, escrito por Andrew Hunt e David Thomas. Ainda assim, existe um conselho desse livro que eu já encontrei inúmeras vezes nos meus estudos de programação:

Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.

Traduzindo livremente:

Aprenda ao menos uma linguagem de programação a cada ano. Ao aprender várias abordagens diferentes, você amplia a sua forma de pensar e evita cair na mesmice. Além disso, aprender várias linguagens ficou mais fácil, graças à riqueza de softwares gratuitos disponíveis na Internet.

Cada linguagem de programação tem suas particularidades, e essas diferenças acumulam-se nas soluções. Algumas linguagens são bem parecidas (pense em C++, C# e Java), e acabam resultando em soluções parecidas. Nesses casos não há muito o que ganhar. Mas quando decide-se estudar um outro paradigma, aí a história é outra.

Minha caixa de ferramentas

A primeira linguagem que aprendi foi C++, e Java veio logo em seguida. Depois, aprendi Lua. Como trabalho com desenvolvimento Web, tive que estudar PHP e JavaScript. E no meu mestrado precisei de um pouquinho de Python. Estudei a engine Unity há um tempo atrás, então eu também sei C#. A última linguagem que aprendi foi VBScript, quando recebi um sistema ASP legado para dar manutenção.

Existe uma padrão nessa minha lista de linguagens conhecidas: todas são imperativas. E tirando VBScript, todas são baseadas em C. E mesmo VBScript não é tão diferente assim. Se eu estudar uma outra linguagem imperativa, como Ruby por exemplo, certamente vou aprender uma coisa ou outra. Afinal, sempre há muito o que aprender.

Mas o que eu quero é aprender muito. Meu objetivo não é incluir novas ferramentas na minha caixa, mas aprender a trabalhar com ferramentas totalmente alienígenas às que eu conheço. Eu quero pensar de várias formas diferentes. E acho que para isso, preciso aprender outro paradigma. É aí que entram as linguagens funcionais.

Paradigma funcional

O paradigma declarativo é totalmente diferente do imperativo. Programas imperativos são sequencias de instruções que o processador executa. Já os programas declarativos contém uma descrição do que se deseja, e o programador abstrai o procedimento exato. Ao criar um algoritmo declarativo, o programador diz o que o programa é, e não o que ele deve fazer.

Soa bem diferente de todas as linguagens que conheço. Dá para fazer alguns paralelos. Consultas SQL são declarativas por exemplo. CSS também. Mas nenhuma das duas são linguagens de programação. Então, eu não sei programar em nenhuma linguagem declarativa.

O paradigma declarativo é muito amplo, assim como o imperativo também é. Dos subparadigmas declarativos existem dois que me interessam muito: linguagens funcionais e concatenativas. As concatenativas são mais obscuras, e por isso escolhi começar pelas linguagens funcionais.

E quais linguagens são funcionais? Existem inúmeras, e a maioria delas é alguma forma de dialeto do Lisp. Eu tentei aprender Lisp uma vez, usando uma linguagem chamada Racket, mas não deu muito certo. Lisp é como C++: poderosa e feia. Haja parentêses!

A linguagem funcional que realmente chamou minha atenção foi Haskell. Eu tive uma introdução a Haskell na universidade, em 2004. Mas já faz tanto tempo que não consegui aproveitar muita coisa. Tive que começar do zero. E esta é a minha terceira tentativa de aprender Haskell.

As duas primeiras foram muito similares. Tentei aprender a linguagem usando o livro Real World Haskell, que está disponível online. E em nenhuma das duas vezes deu certo. Chegava até o capítulo 6, e daí já não andava muito. Apesar de não ter aprendido a programar em Haskell, aprendi muitos conceitos de programação que para mim (e para todos os meus colegas de trabalho, parece) eram novos. Principalmente funções puras.

Comecei a sempre tentar codificar usando funções puras. Essa prática me ajudou em várias ocasiões, porque muitas das funções que eu codificava tinham um alto potencial de reuso. No ato da codificação, parecia meio bobo deixar uma função sendo pura. Seis meses depois, essa mesma pureza permitia que um recurso completamente novo pudesse ser rapidamente desenvolvido.

Então, apesar de não ter aprendido Haskell nas duas primeiras tentativas, eu aprendi a programar melhor. As duas tentativas não foram dois fracassos. Depois das funções puras, eu estudei um bocado sobre funções de alta ordem. Basicamente, uma linguagem com funções de alta ordem permite que funções sejam passados para outras funções, ou retornados. JavaScript é assim, com suas funções anônimas.

Recentemente, percebi que estava pronto para uma terceira tentativa.

Finalmente, Haskell!

A terceira tentativa tem sido muito diferente da duas primeiras. Agora estou usando outro livro, o Learn You a Haskell for Great Good!, que também está disponível online. Achei esse livro bem mais didático que o Real World Haskell. Os assuntos são introduzidos com calma, as explicações são bem claras, e ele tem muitos exemplos. Não tem exercícios como o Real World Haskell, mas para começar, eu tentava implementar os exemplos antes de ler o código do livro. E além disso, encontrei uma lista com 99 exercícios para iniciantes. Bastante material.

Acho que dessa vez eu peguei o jeito. Não considero que programo em Haskell, porque ainda me confundo demais com exercícios simples. Sem falar que mônades ainda são um mistério para mim. Eu ainda estou aprendendo, e a terceira tentativa continua. Pretendo escrever alguns artigos sobre o assunto no futuro. E vamo que vamo!

quinta-feira, 21 de agosto de 2014

Como a White Wolf cria jogos tão bons (CONFIRMADO)

Atenção: O próprio Mark Rein·Hagen confirmou que esta é realmente a forma como ele trabalhou em Vampiro: Máscara!

Eu era adolescente, e tinha firmado meu primeiro grupo de RPG, quando ouvi falar pela primeira vez de um jogo chamado Vampiro: A Máscara. E durante os meses seguintes, eu continuei ignorando esse jogo. Havia até jogado uma vez, num dos Encontros de RPG de Viçosa, mas ainda assim o jogo não me chamava atenção.

Foi assim até o dia em que eu pus as mãos no livro básico. Eu lembro até hoje de como foi folhear aquele livro tão elegante, com ilustrações bonitas impressas em papel couchê. E posso dizer sem sombra de dúvida que nunca mais fui o mesmo depois de ler Vampiro: A Máscara. Era a primeira vez que eu tinha contato com uma mitologia tão rica, que elevavam o RPG a um patamar muito acima do velho (e francamente, tedioso) matar-pilhar-destruir.

Os anos se passaram, e até hoje eu considero o Vampiro: A Máscara um dos melhores RPGs já criados. E como criador de jogos amador, eu sempre me perguntei, como foi que Mark Rein·Hagen conseguiu criar um jogo tão especial? Observando os outros jogos do Mundo das Trevas, é fácil notar que existem várias semelhanças entre eles.

O Mundo das Trevas clássico é composto pelos seguintes jogos:

  • Vampiro: A Máscara
  • Lobisomem: O Apocalipse
  • Mago: A Ascenção
  • Wraith: The Oblivion
  • Changeling: The Dreaming

E as tais semelhanças são as seguintes:

  • Todos os personagens possuem alguma forma de afiliação (Clãs, Seitas, Tribos, etc.), que acarretam em vários conflitos por si só.
  • Em nenhum momento espera-se que os personagens são amigos. Conveniência e necessidade são motivos fortes o suficiente para que eles aliem-se.
  • Existem vários caminhos que o personagem pode perseguir (poder, Diablerie, Golconda, Trilhas da Sabedoria, etc.), e cada um deles cria vários novos conflitos.

Existem mais semelhanças, mas eram essas as que mais me chamavam a atenção.

Pesquisa: qual é o seu segredo, Mark Rein·Hagen?

Intrigado, eu pensei, será que a White Wolf não tem um processo de criação preparado para criar jogos nessa linha? Afinal, existe um certo padrão. Eu imaginei que não era coincidência, e foi isso que eu perguntei no RPG Stack Exchange.

A única resposta que obtive era desanimadora. A maioria das pessoas quando perguntadas sobre processos, entendem “receita de bolo”, como se houvesse um monte de passos mecânicos que levassem à criação da obra final. Elas não entendem que o processo é muito mais que isso, que envolve estratégias, filosofias e boas práticas. Acho que as pessoas preferem acreditar que apenas mentes geniais conseguem misteriosamente chegar em obras de arte. Meros mortais devem apenas ficar admirados com a genialidade, e não devem tentar entender a criação para não estragar a “magia” da coisa. Medíocre.

Eu não desanimei, e corri atrás de qualquer entrevista com Mark Rein·Hagen que estivesse por aí. Achei muito material bom, nem tudo referente à minha pergunta, mas tudo bem. De todo o material, existem duas entrevistas que foram muito úteis.

The Gentleman Gamer interview with Mark Rein·Hagen

Nessa primeira entrevista, The Gentleman Gamer interview with Mark Rein·Hagen, o autor de Vampiro comenta vários pontos do processo de criação. Ele dá a entender que utilizou um processo semelhante ao descrito no livro The Art of Game Design, de Jesse Schell. Mark Rein·Hagen não cita esse livro, que foi lançado bem depois do Vampiro: A Máscara, em 2008. Mas suas descrições são bem parecidas.

O mais interessante é quando Mark Rein·Hagen comenta suas três estratégias principais, arquétipos, política e cultura. Estas estratégias podem ser encaradas como as lentes descritas no Art of Game Design: perspectivas que o criador do jogo pode assumir para melhorar aspectos fundamentais do seu trabalho. Estas três lentes são o segredo da White Wolf, e eu vou entrar em mais detalhes sobre elas logo abaixo.

The Gentleman Gamer Interviews Justin Achilli, developer of Vampire: The Masquerade

Essa entrevista, The Gentleman Gamer Interviews Justin Achilli, developer of Vampire: The Masquerade também é muito interesante, mas não acrescenta quase nada para a pergunta original. Só que no meio dela, o Justin Achilli cita que o livro Art of Game Design é uma referência essencial para criadores de jogos, Daí eu deduzi que dá para extrapolar o conhecimento desse livro para entender como a White Wolf criou seus jogos vários anos antes.

Descobertas

Ciclo de criação da White Wolf é o processo recomendado

Sempre existe um ciclo de criação em qualquer forma de design. Cada organização complementa o ciclo básico com as etapas que achar melhor. Mas todas as formas de design que tive contato até hoje seguem, em essência, o mesmo processo: crie um protótipo, teste (e falhe), aprenda com os erros do protótipo, repita.

Mark Rein·Hagen criou várias versões de Vampiro A Máscara, e a primeira nem tinha regra alguma! Regras e cenário foram criadas aos poucos, testadas, e melhoradas, até chegar na versão definitiva.

A criação dos Clãs é um bom exemplo do processo. Os treze Clâs da versão final são menos da metade de todos os Clãs que Mark Rein·Hagen criou e por algum motivo, descartou. Ele não cita o porque de cada descarte, mas dá para imaginar. Uns clãs deviam ser rudimentares demais, e ele juntou dois ou mais em um Clã final. Ou então o Clã não se encaixava de jeito nenhum com o resto do jogo. Vampiro: A Máscara era um jogo melhor sem esses Clãs ruins. E então ele desceu a foice, sem dó.

As três lentes são o diferencial

Eu não vou explicar em detalhes o que é uma lente; prefiro deixar o autor do termo falar sozinho:

Good game design happens when you view your game from as many perspectives as possible. I refer to these perspectives as lenses, because each one is a way of viewing your design. The lenses are small sets of questions you should ask yourself about your design. They are not blueprints or recipes, but tools for examining your design.

Jesse Schell, The Art of Game Design: A Book of Lenses

Traduzindo:

Uma boa criação de jogos é feita quando você encara seu jogo a partir de tantas perspectivas forem possíveis, porque cada uma delas é uma forma de ver o seu design. As lentes são pequenos grupos de perguntas que você deve se perguntar sobre o seu design. Elas não são planos e nem receitas, mas sim ferramentas para examinar o seu design.

Schell apresenta cem lentes em seu livro, e todas elas são genéricas o suficiente para examinar qualquer tipo de jogo: jogos esportivos, jogos de tabuleiro, jogos eletrônicos, e é claro, RPG. Mark Rein·Hagen deve ter usado sem saber várias dessas lentes. Só que existem três perspectivas que ele adotou e que não são cobertas pelo Art of Game Design.

Portanto, sem mais delongas, eis o segredo da White Wolf.

Arquétipos

Não, não estou falando daqueles arquétipos que os jogadores escolhem para Natureza e Comportamento dos seus Cainitas. O arquétipo que Mark Rein·Hagen usa extensivamente em seus jogos são constructos psicológicos propostos pelo psiquiatra Carl Jung.

Um arquétipo são padrões que podem ser identificados na psicologia das pessoas. Exemplos de arquétipos clássicos incluem a Mãe, a Criança e a Sombra (que é usado o tempo todo em Wraith: The Oblivion). Mark Rein·Hagen juntou esses arquétipos com os arquétipos do monomito, de Joseph Campbell, e criou combinações mais específicas dos arquétipos. Basicamente, tudo que tem um estereótipo é um arquétipo, de acordo com esse ponto de vista.

Exemplos (tirados de Vampiro: A Máscara apenas):

  • Cada Clã (ou falta dele, no caso dos Caitiffs) tem pelo menos um arquétipo muito forte associado.
  • A posição do personagem na sociedade também é um arquétipo. Crianças da noite, Anciões, Antidiluvianos, são arquétipos com um estereótipo bem sutil.
  • A hierarquia do personagem também é um arquétipo: Príncipe, Primigene, Senescal, etc.
  • Questões relacionadas à filosofia de vida do personagem também são arquétipos: diableristas, anarquistas, infernalistas, gurus da Golconda, megalomaníacos sedentos por poder, etc.
  • Até mesmo a seita tem um arquétipo bem fraquinho associado: Camarilla, Sabá, Inconnu ou independentes

Para entender um arquétipo, eu faço o seguinte: se alguém consegue imaginar superficialmente um personagem a partir de um rótulo, então esse rótulo é um arquétipo. Por exemplo: quando eu penso no Clã Brujah, eu imagino um punk violento. Pronto! Arquétipo. Já quando eu penso em Harpias, eu não consigo imaginar nada. Por isso, do meu ponto de vista, Harpia não é um arquétipo.

A grande sacada dos arquétipos é também algo muito incompreendido pelos jogadores. Muitos reclamaram que os Clãs determinam demais o personagem final, e por isso acabam limitando o jogador. Isso acontece porque eles encaram os Clãs como classes, e não como famílias. Embora dentro de uma família seja possível deduzir um “familiar típico” cada indivíduo é diferente do familiar típico.

Para entender melhor essa ideia, pense em Romeu e Julieta. Os Montéquios são uma família proeminente de Verona, que odeiam os Capuletos. Então, pense no Montéquio como um arquétipo:

Montéquios são ricos e odeiam os Capuletos.

Esse é o Montéquio típico. Não dá para dizer que todos os Montéquios são assim. Primeiro que embora sejam ricos, cada um é rico de um jeito. Alguns Montéquios podem estar em decadência, outros podem ser os mais bem sucedidos da família. Alguns podem ser ricos comerciantes, outros podem ser mauricinhos que vivem apenas de heranças. Uns têm mais dinehiro, outros são os pobres da família.

A mesma coisa acontece quando você pensa no rancor pelos Capuletos. Cada Montéquio odeia os Capuleto à sua maneira. Alguns não odeiam de verdade, só repetem o discurso da família. Outros podem trincar os dentes só de ouvir aquele nome com C… Os mais violentos vão partir para cima de qualquer Capuleto que cruzar o seu caminho. Outros, vão preferir espalhar fofocas, ofuscando virtudes e enfatizando defeitos.

E o Romeu não é um Montéquio típico (de fato, nenhum deles é). Romeu é rico, mas seu amor por Julieta põe o rancor nato pelos Capuleto numa perspectiva totalmente diferente, gerando conflitos que movimentam a trama. Romeu não é um personagem que fica limitado por ser um Montéquio. Ao contrário, ele é um personagem muito mais interesante por ser um Montéquio.

Política

Política soa como uma lente muito óbvia para os jogos do Mundo das Trevas. Todos eles giram em torno de sociedades secretas poderosas, onde cada personagem tem a oportunidade de escalar a hierarquia de sua cidade enquanto seus rivais tentam o mesmo. Muitos jogadores chegaram a acusar o Vampiro: A Máscara de ter politicagem demais.

Mas não é esse tipo de política que Mark Rein·Hagen cita na entrevista. O que eu entendi é que essas estruturas políticas usadas pela White Wolf em todos os seus jogos é apenas uma possibilidade desta lente. A tal “Lente da Política” parte de princípios muito mais fundamentais. Para Mark Rein·Hagen, política é o seguinte:

  1. Dê às pessoas algo em que acreditar.
  2. Agora dê a elas recursos para lutar por suas crenças.
  3. Deixe-as descobrir o resto por si mesmas.

Política é um confronto de ideologias. O antigo versus o novo. Ciência versus misticismo. Humildade versus conforto. Enquanto dois, três, quatro pontos de vista diferentes existirem, haverão conflitos, e é essa a função da política em RPG. O Narrador que sabe usar política em suas Crônicas tem trabalho apenas para botar a história em movimento. Depois que os personagens já se envolveram na trama, ele pode apenas mediar os acontecimentos, deixando que os próprios jogadores criem a experiência.

Os jogadores também tiram muito proveito desse choque de ideologias que é a política. Os jogos da White Wolf estimulam os jogadores a criar personagens com convicções fortes, totalmente envolvidos na Crônica. Cada personagem não é um mero “instrumento para resolver masmorras”. Ele é sim um indivíduo que tem a sua própria visão de como o mundo deveria ser.

Falando assim, parece que até que estamos falando de jogos mais heróicos, e não do Mundo das Trevas. Afinal, os personagens desse mundo raramente estão engajados em causas nobres. No entanto, note que essa lente não cita nada quanto a causas nobres. As causas que os personagens lutam são causas pessoais. Se o seu Cainita acredita que todos os Membros de geração mais baixa deveriam tratá-lo com mais respeito, então o personagem tem uma visão de como as coisas deveriam ser. E ele provavelmente não irá ficar de cabeça baixa quando uma Criança da Noite exibida apontar o dedo na sua cara…

Cultura

A última grande lente utilizada por Mark Rein·Hagen em seus jogos é também utilizada em vários outros RPGs. A cultura trata de várias particularidades do cenário, e serve para dar mais “cor” ao jogo. Nos jogos da White Wolf esta lente aborda:

  • Jargão
  • Folclore
  • Lendas
  • Rumores

Todos os livros básicos possuem uma seção no fim da introdução que lista todos os termos utilizados no cenário. Nomes de Clãs, seitas, disciplinas, castas, idades, gírias e expressões são rapidamente explicados no começo dos livros, e usados extensivamente a partir de então. Há quem prefira utilizar o muito mais elegante termo Amaranto em vez do vulgar Dialerie. E não se esqueça que vampiros que superaram a sua infância, as antigas Crianças da Noite, tornam-se Neófitos ligeiramente mais respeitados.

Folclore, lendas e rumores são basicamente histórias dentro da história – relatos que a grande maioria desconhece se é verdade.

Até mesmo as várias pronúncias fazem parte da cultura. Mark Rein·Hagen, sempre que é perguntado quanto à pronúncia correta do nome Brujah – e as opções normalmente são brurrá, e bruja – diz que todas as formas estão corretas. É como sotaque: se alguém entendeu que era assim que se pronunciava, então esta variante acontece no Mundo das Trevas. Dá para especular de onde um vampiro veio, sua idade e personalidade pelos termos e pela pronúncia que ele adota.

Conclusão

Não existe uma receita de bolo que resulte jogos tão elegantes quanto os da White Wolf: a genialidade de Mark Rein·Hagen teve um papel fundamental na criação. Ainda assim, há muito o que aprender com essa história. As três lentes – Arquétipos, Política e Cultura – são um grande diferencial na obra de Mark Rein·Hagen. Elas são amplas o bastante para que possam ser utilizadas em uma grande variedade de gêneros, enriquecendo tanto os cenários quanto os personagens que irão habitá-los. As demais lentes do livro Art of Game Design certamente também seriam muito úteis. Essa é uma leitura que eu recomendo muito, sendo quase obrigatório para qualquer criador de jogos que seja.

sábado, 29 de março de 2014

Sistema Morpheus de RPG Liberado

Morpheus RPG

Depois de quase uma década de trabalho, eu finalmente acho que é hora de publicar o meu projeto mais longo: o sistema de RPG Morpheus. Muito sangue, suor e lágrimas rolaram para chegar nesse modesto arquivo de quarenta páginas. E eu deixei o arquivo disponível para download de graça!

Eu não vou enrolar muito mais aqui, porque já arranjei um falatório danado na página dele. Só uma coisa, quem são sabe o que é RPG, dá uma olhada aqui.

terça-feira, 4 de março de 2014

Modo experimental em ambientes de produção utilizando cookies

Testar novos recursos em ambientes de produção é uma prática ruim no desenvolvimento Web, mas tem horas que não tem jeito. Em algum momento a funcionalidade irá para o servidor de produção, e por mais testada que ela já tenha sido, problemas acontecem. Por isso, eu proponho utilizar cookies inseridos manualmente para declarar que um modo experimental está ativo, e impedir que o recurso novo rode quando o cookie não estiver presente.

Introdução: os três ambientes típicos

Para impedir que um sistema que está em uso fique instável por conta de novos desenvolvimentos, é considerado uma boa prática utilizar três instalações diferentes (os tais ambientes): desenvolvimento, testes e produção:

O ambiente de desenvolvimento é utilizado apenas pelos programadores. Ele pode rodar qualquer versão, a qualquer momento, e é populado com dados apenas para testes. Ele é o ambiente mais instável dos três.

Quando o código já está mais maduro, ele é enviado para o ambiente de testes. Este ambiente é utilizado pela equipe de testes para garantir a qualidade do sistema. Tipicamente, o código neste ambiente parece estar pronto, mas provavelmente não está.

Eventualmente o código é considerado estável, e pode ser implantado no ambiente de produção. Esta instalação está em uso pelos clientes, e por conta disso deve ser manuseada com cuidado. Manutenções devem ser bem pensadas, e apenas código estável deve ser inserido aqui.

O problema: como realizar testes em ambientes de produção?

Existem dois tipos de código que tipicamente são implantados em servidores de produção: atualizações e correções de emergência. As atualizações, mesmo quando corrigem algum defeito, devem seguir o fluxo completo entre os ambientes, sendo criadas no ambiente de desenvolvimento, validadas no ambiente de testes e só então implantadas para produção. Elas podem tranquilamente seguir as boas práticas de desenvolvimento, e se der tudo certo, o código que irá para produção não precisará de nenhum ajuste.

Com as correções de emergência não é bem assim. Existem situações onde correções de emergência devem ser implantadas o quanto antes (afinal, ela são de emergência), e o fluxo de implantação é lento demais para isso. Nesses casos, os desenvolvedores costumam fazer testes rápidos no servidor de desenvolvimento, e implantar códigos bem instáveis direto no ambiente de produção, pulando o de testes.

Sejam atualizações, sejam correções de emergência, código novo em ambientes de produção deve ser manuseado com cuidado. O ideal é que apenas os desenvolvedores tenham acesso à execução do novo código; os clientes devem continuar utilizando o sistema antigo. O problema é que estamos falando de dois tipos de usuários, tendo visões diferentes de um mesmo ambiente. Como o sistema poderia diferenciar entre as duas situações, agindo de acordo para cada uma?

A solução: modos experimentais

A solução que estou propondo consiste em criar um modo de operação experimental, acessível apenas para o desenvolvedor. Os clientes irão continuar tendo acesso ao sistema original. Portanto, o sistema deve diferenciar entre dois modos:

  • Padrão: é o sistema atual, sem nenhum dos novos recursos que estão sendo trabalhados. Este modo de operação serve para que o sistema continue atendendo aos clientes.
  • Experimental: é uma variante do sistema padrão. O modo experimental comporta-se da mesma forma que o padrão, exceto nos recursos que estão sendo implantados. Nesse caso, apenas os recursos novos irão executar.

Uma implementação do modo experimental deve ser muito simples, para não sobrecarregar o trabalho dos desenvolvedores quando eles estiverem codificando correções emergenciais. Felizmente, basta um if ... else e um cookie para dar conta do recado.

O algoritmo é o seguinte:

se o cookie experimental está ativo
    execute versão experimental do recurso
senão
    execute versão padrão do recurso   

O tal cookie deve ser definido apenas manualmente. Assim, garante-se que o cliente não irá ter acesso a um recurso experimental por engano. Quando o desenvolvedor estiver satisfeito basta deixar apenas a versão nova do recurso. Ele também pode remover o cookie do seu navegador, se quiser.

O nome e o conteúdo do cookie ficam por conta da situação. Verificar se um cookie modo_exp existe ignorando o seu valor, é a solução mais simples. Alternativamente, o cookie pode possuir valores booleanos, e nesse caso o sistema deveria testar o conteúdo do cookie, considerando que se ele não existe então o modo padrão deve ser seguido.

Ofuscar a existência do modo experimental é simples, bastar dar um nome bem estranho para o cookie. Uma string aleatória fica bem escondida a princípio. No entanto, se o recurso oferece algum risco de segurança, é melhor utilizar uma senha para o modo experimental. Basta codificar a senha utilizando o algoritmo SHA1. Para verificar se o modo experimental está ativo, codifique o conteúdo do cookie usando SHA1, e compare com a versão codificada senha. Se bater, então é seguro liberar o recurso. Não se esqueça de definir a senha como o conteúdo do cookie!

Considerações finais

Modos experimentais com cookies são uma forma simples e rápida de testar novos recursos em ambiente de produção. Esta estratégia não substitui os ambientes de desenvolvimento e de teste, e por isso deve ser utilizada com cuidado, apenas quando necessário.

Esta solução é um quebra-galho. Uma vez confirmado que o recurso novo está pronto retire todos os códigos que implementam o modo experimental. Deixe apenas o recurso novo, ou então em pouco tempo o código estará repleto de ramificações experimentais, mesmo quando nenhum experimento estiver em curso!

Gostou? Odiou? Comente!

segunda-feira, 17 de fevereiro de 2014

Olá blog!

Já notaram como todo primeiro artigo de um blog é um saco? O autor não tem o que dizer, e fica chato entrar de sola já em algum assunto. Tem que ter um primeiro artigo, infelizmente. E para os leitores é outra chatice, afinal que graça tem o primeiro artigo? Falar que o blog existe? Ah claro, como se já não houvessem trocentos outros!

Já que é assim, eu vou tentar ser ao menos um pouquinho construtivo. Meu nome é Rafael Carrasco, e você pode encontrar mais detalhes na minha página de perfil. Eu criei este blog para que ele sirva como um canal entre eu e o resto do mundo. Aqui não existe um tema bem definido. Vou falar de tecnologia, que é a minha área, mas não só disso. Também vou falar de RPG porque é o meu hobby favorito, mas também não é só isso. Também vou expor minha opinião sobre vários assuntos.

Pode parecer que o blog é meio aleatório nos seus conteúdos. Não é bem assim. Esse blog serve para que eu exponha qualquer coisa que eu achar legal que eu tenha criado. Eu não sou lá muito eclético, mas também não sou monótono, e é por isso que vários assuntos vão ir surgindo. Deixa rolar. Se algum artigo não chamar a sua atenção, então nem perca tempo com ele. Não vou guardar ressentimentos!

Bem é isso. Até que para um primeiro artigo, não parece ter ficado tão chato assim…