Live data from Hacker News

Play framework 2.10 released

playframework.com

61–70 of 76 posts

Re: Play framework 2.10 released

#61
post #58
post #23

Earlier quoted context omitted.

Stated by Guillaume Bort here[1] Play uses static methods only when it makes sense: - in the controller layer, because controllers are not object oriented. Controllers act as mapper between the HTTP world (that is stateless, and request/response based) and the Model layer that is fully object oriented. [1]: http://stackoverflow.com/questions/5192904/play-framework-us...

It only 'makes sense' on a theoretical basis. On a practical basis, unit testing tons of static methods is a nightmare.

In our Play app, we isolate the real tricky stuff from our controllers and then write unit tests for it there. The controllers themselves end up being fairly lean and simple, so we test them (along with the front-end) with Selenium. We're not dogmatic about 100% coverage as we are a start-up trying to move fast, but this approach has worked well for us.

Re: Play framework 2.10 released

#62
post #58
post #23

Earlier quoted context omitted.

Stated by Guillaume Bort here[1] Play uses static methods only when it makes sense: - in the controller layer, because controllers are not object oriented. Controllers act as mapper between the HTTP world (that is stateless, and request/response based) and the Model layer that is fully object oriented. [1]: http://stackoverflow.com/questions/5192904/play-framework-us...

It only 'makes sense' on a theoretical basis. On a practical basis, unit testing tons of static methods is a nightmare.

I find it pretty easy to test static methods. To me, testing a ton of static methods would seem a bit easier than testing a ton of classes, since static methods are usually stateless and so require less setup/cleanup work.

Could you explain a bit more about what makes static methods harder?

Re: Play framework 2.10 released

#63

Earlier quoted context omitted.

and SSL: https://groups.google.com/d/msg/play-framework/FeTUDQwaEPg/q... But not TLS (and client certificates, yet), that is for Play 2.2: https://github.com/playframework/Play20/pull/475

Since when is 10 Edit: the title is wrong, it's play 2.1.0, not 2.10!!

yep, it can be easy to confuse that with scala 2.10

Re: Play framework 2.10 released

#64
post #37
post #12

Does anyone know a good Django/Play comparison or Rails/Play comparison? Or a tutorial along the lines of "Play for Rails developers" or "Play for Django developers"? I'm learning Scala and I want to play with it for webdev, but I know how much "hidden effort" is in learning any framework so i's really love something like this...

I'm also an Django developer and did a play application some time back[0], so maybe I can give some insight on development with Play!. My background in functional program was non-existent at the time so going in I was already going to have problems. I choose to create my project as Scala project since I wanted to learn the tech. While Scala can be done with normal OOP/procedure programming I wanted to have the full a…

http://en.wiktionary.org/wiki/per_se :)

Re: Play framework 2.10 released

#65
post #12

Does anyone know a good Django/Play comparison or Rails/Play comparison? Or a tutorial along the lines of "Play for Rails developers" or "Play for Django developers"? I'm learning Scala and I want to play with it for webdev, but I know how much "hidden effort" is in learning any framework so i's really love something like this...

I'd say just jump in. The documentation are top notch. If you've used Rails it will feel very familiar to you. I'd say in an afternoon, if you have experience building web apps, you'll be up to speed.

I'd say most enterprise Java projects (think J2EE) have better documentation. I wouldn't choose Play because of that, I'd choose it because of the practicalities.

Re: Play framework 2.10 released

#66

I've been eyeing Play for a bit now, but I've been wondering what kind of server it would require for a modest app with basic CMS functionality. So, for example, will it run fine on a 128MB RAM VPS (assuming average IO speeds), a remote db and nginx?

As the other comment said, no need for NGinx unless you're dealing with external assets you don't want to add to your project structure.

That said, I will say I run my Blog on Play 2.1 (RC2 IIRC) and 512MB means I have to set some tuneables to limit the max memory to 384MB. I haven't figured out how to get those to work with 'play dist' either, so I got it running by cloning the source and installing Play locally. Which isn't much fun.

I'm sure with a little more digging I could figure it out. That said, the default limit of 1.5GB is probably there for a reason. It seems well suited to EC2's m1.small instance (1.7GB).

Considering the in-memory caching, I'd just pony up the $44/month for such an instance for anything more than my personal blog.

Re: Play framework 2.10 released

#67
post #58

Earlier quoted context omitted.

It only 'makes sense' on a theoretical basis. On a practical basis, unit testing tons of static methods is a nightmare.

I find it pretty easy to test static methods. To me, testing a ton of static methods would seem a bit easier than testing a ton of classes, since static methods are usually stateless and so require less setup/cleanup work. Could you explain a bit more about what makes static methods harder?

Static methods can be easy to test, if they are zero or near-zero dependency. e.g. Math.log(x) is easy to test.

However, a static method that accesses other layers is often very hard to test (at least in isolation). For example if you have a static controller method that accesses some service layer you would normally want to mock that service layer for testing so you can test the controller code in isolation.

If the method is non-static and that service layer object is a class member, it is very easy to replace your production service layer with a mock (using dependency injection or mockito, etc).

However if your controller is static, it can only access static members of its class or instantiate the service object with a 'new' operator. Either way there isn't a 'seam' in the code where something like dependency injection or mockito can intercept your app's wiring to replace the service object with a mocked version.

Worth noting I'm coming from the Java side of things here, perhaps Scala is built in such a way that 'new' and 'static' type things are interceptable in a way that allows mocking.

Re: Play framework 2.10 released

#68
post #18

Love it. Exquisitely type safe. Just one thing: Weren't we supposed to get WAR deployment support in 2.1?

They haven't done this because the Servlet 3.1 spec has not been released yet. Play 2 supports some features that cannot be supported with Servlet containers https://github.com/dlecan/play2-war-plugin
Post reply on HN