Cuidado com sessions no heroku

Só uma passada rápida por aqui. Estava mexendo no Agendatech para melhorar o processo de participar de uma promoção ou de informar que a pessoa vai em um evento. O problema era o seguinte: quando você clicava no botão, a aplicação redirecionava o usuário para a página do twitter e na volta, mesmo com o usuário já logado, ele era obrigado a clicar novamente para participar da promoção.

A minha solução, não que tenha sido a melhor, foi guardar uma session com o evento e o tipo de botão que ele clicou e, na volta do login realizado no twitter, eu pego esse objeto que ficou guardado na session e faço a associação com o usuário que acabou de se logar. Dessa forma, ele não precisa clicar novamente para confirmar a participação, isso já fica sendo feito automaticamente.

O problema foi que eu guardei na session um objeto do tipo Evento, que é o principal do sistema. Por conta disso ele tem alguns relacionamentos, além dos atributos como data do evento, descrição, etc… Parece que o Heroku não gostou muito do tamanho do objeto que ele teve que serializar e começou a soltar uma exception do tipo CookieOverflow. A solução foi guardar apenas o id do evento na session :).

Bom, essa blogada é mais para eu sempre ficar com isso em mente. Quando você tá num ambiente de Cloud no estilo PAAS da vida, temos sempre que tomar cuidado quando o assunto é guardar coisas aleatorias no disco. Afinal de contas, isso não te pertence mais, pelo menos no plano básico :).

Getting into the new Scala’s 2.10 Reflection API

The newer version of Scala brings us some new features. In this post, Simon Ochsenreither listed many of these new things. One of  the most expected, at least for me,  is the new Reflection API. In my last project at Caelum, we faced a lot of problems using Java’s Reflection API to discover things that just existed in a Scala class. For example, we needed to know if a method was implicit or not and this information was not clearly pointed at the bytecode. In order to solve this problem, we had to use the scalap library and I can tell, the code is not beautiful.

So my point here is just that, show you how to use the new Reflection API to discover if a method is or not a implicit. The code must be a starting point to do whatever you might need with the rest of the API.

To get started I was looking for a way to get information about the class, such as methods implicitness, existence of companion objects and so on. So I created an Object with an implicit method just to test:

 object Pimps{
    implicit def pimp(str:String) = new {
       def test = println("hello")
    }
 }
 

Now I need to get information about this class, all the traits that you must know to work with Scala’s Reflection are at Scala’s github repository, and that was my starting point. The Mirror trait is the entry point of the api, its implementation can be found here. So let’s get started retrieving all the informations about our class. Here is the code:

val aType:Type = Mirror.typeOfInstance(Pimps)

Now we have the Type instance of our class. This object provides informations about your class, for example we can pick all the members. Let me show you the code:

 val members:List[Symbol] = aType.members
 

The Symbol trait is the abstraction of everything that you have in your class, constructors, methods, variables and the class declaration itself. And, at least for me, this was my savior. With an instance of Symbol is possible to get information about the Scala code. For instance, let’s filter all the Symbols that contains an implicit modifier in our Pimps class:

val justImplicits = members.filter(member => member.hasModifier(Modifier.`implicit`))

I think this is a good starting point to test the new API. All the code was tested in REPL with the 2.10 version, milestone 2. Also, there is a gist with the example code. Don’t forget the imports :).

Thanks to @adrianoalmeida7 for kindly reviewing this post.