iam.guillaume.bort.fr

How we saved the day using playframework?

Reblogged from plevsy:

The week before last was an interesting one. Apart from the usual chaos at our workplaces, we finally had our chance to get some hands-on experience with play! Simply put, it was one of the most pleasing two days of time developing, and the result was probably the best, for two days that is.

First of all i (@agaoglu) wasn’t anywhere near any web application for about 6 months now, so it can be said that i’m somewhat rusty. But i was onto some serious hadoop stuff, so my java blade is sharper than ever. @burakdalgic on the other hand, was simply harvesting his crops of PHP for almost a year and looking for some other ingredients to open his next brewery.

Anyway, @burakdalgic called me on Thursday afternoon to inform me that they would be needing a registrations tool for their front desk at 27th National Congress of IT (27. Ulusal Bilişim Kurultayı[in turkish]). Organizer of the congress had recently bought some barcode readers and by utilizing them, they wanted reports about participants of select sessions. Along with barcode readers, they were supplied with a software to record some details of participants which is developed with Excel/Access and somehow is unable to generate any reports, but that’s another story. When i asked about our deadline, he simply answered the event would start on Wednesday so there were 5 days ahead. I said OK thinking some sleepness nights on weekend is nothing new. Prior to that OK, I didn’t consider any frameworks or languages apart from that it wasn’t going to be any flavor of JavaEE nor PHP.

That evening at home after some chillout music and some rest cured my headache, two choices shined out of the dark: Django and play!. We had experience with Django and a small application like that was nothing compared to what we had been able to achieve with it. Beyond capabilities, it was the fastest-to-work-with environment i had ever been into. Generating HTML form out of the Model class was a huge performance boost but the templating was making up for it. Then i remembered: working in django, i always needed 3 virtual desktops. One for browser, one fore IDE (which is vim) and one for terminal that ‘$ django runserver’ was outputting. Whenever a error happens, django was generating an HTML report to tell me about it in the browser, but since that almost never made sense, i had to go to the terminal to see that i was actually comparing a string with an int in an entirely different place. I know this is not a django problem but a dynamically-typed language problem but it is not my problem now is it? Another problem was ‘$ django runserver’ was not the way to go in production, so we would be forced to deploy some web server, configure it and have another point of failure which is not what we want in a front desk of a conference.

So as the night goes darker one option was becoming brighter: play! Which actually had a bigger problem: we had zero experience with it. Apart from some tests with CRUD module and regular reading of their mailing list, we had no idea how to work it out. Well, we knew it was on java, which is a statically-typed language, which in turn has some great IDEs like eclipse which tell you it is not possible to compare a String with an int, as soon as you write it. That’s what i call a performance boost by the way. On the other hand i was remembering things about play having its own netty powered web server and the recommended way of running a play application was ‘$ play run’ indeed. That way we would able to track down any problems at that front desk more easily, since there would be only one place to look at. So, around 9pm that night i overlooked the lack of experience and take a leap of faith by pulling play/1.1 branch from launchpad.

With the help of ‘$ play help’ project had a structure, eclipsified and was running in no time. After some layout with jquery-ui (which quite sums up what i know about UI), we got our first screen that would be simply the C in a CRUD for our participant model.

After a few trips to documentation i got the form wired to my application code and was able to save entries to database with just one line, thanks to Active-Record-like interface for JPA stuff.

public static void save(Participant participant){
  participant.save();
  show(participant.id);
}

Manually constructing jdbc connections in JNDI, wiring it to JTA and informing hibernate to create the EntityManagerFactory out of that mess, so that i can create my EntityManager to do the same save(), just went out of the window. I don’t even want to remember the things i should have done in a web.xml and any other framework related xml just to wire that form to my application code. I know almost all of the xml-required-frameworks have some eclipse plugins to automate these processes but in my experience they rarely work. And when they work, it’s just for a time to understand they are not capable enough so back to manual. Besides, there are times when it is not possible to use any IDE. play!, with its out-of-the-ordinary package naming scheme, really shines here. It is extremely optimistic to edit something in com/spp42/plevsy/track/controller/Participants.java, compile it to get a war (which you need a previously written ant build at best) and expect it to work just after deploying on tomcat. With play!, it is simply ‘$ vim controllers/Participants.java’ and hitting reload. No need to ant-build or deploy or even quit vim.

Next, we needed the first core functionality which is barcode generation. Quick googling lead me to barbecue and within minutes i was able to output barcodes in PNG. That completed R in that CRUD.

public static void barcode(Long id)
    throws BarcodeException, OutputException{
  Participant participant = Participant.findById(id);
  Barcode barcode = BarcodeFactory.createCode128(
    participant.code);
  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  BarcodeImageHandler.writePNG(barcode, baos);
  ByteArrayInputStream bais = new ByteArrayInputStream(
    baos.toByteArray());
  renderBinary(bais);
}

I remember a good friend of mine struggling to modify a PDF generation in django for days without a result because library wasn’t in a good shape. I might remember that wrong, but i think noone’s gonna argue that the library diversity in java beats the hell out of anything out there.

I committed what i have so far to svn around 11pm and went to bed. That was one less sleepless night for me. Friday morning, at work, i had some free time to finish U and D of the CRUD which took about five minutes combined. I somewhat felt experimental and look into some HTML5 input types which resulted in our participant listing to be more like google instant! (OK that was a bit off). But i didn’t take me more than fifteen minutes.

First what seems to the user

<div class="toolbar search ui-widget-header ui-corner-all">
  <input 
    type="search" 
    name="q" 
    id="q" 
    class="search ui-widget ui-corner-all" 
    value="${session.q}"
    incremental="true" />
  <button class="search">Search</button>
</div>
<div class="list">
  <ul class="partlist clean">
  </ul>
</div>

Then what is on user but does not seem

$('button.search')
.button({text:false,icons:{primary:'ui-icon-search'}})
.click(doSearch);
$('#q').bind('search', doSearch);

function doSearch(e) {
  $.get("@{Participants.search()}", 
      {q: $('#q').val()}, 
      function(data){
        $('ul.partlist').html(data);
  });
}

And in server

public static void search(String q){
  List result = Participant.find(
      "lower(name) like ? or " +
      "lower(lastname) like ? " +
      "order by lastname", 
      q+"%".toLowerCase(), q+"%".toLowerCase()).fetch();
  session.put("q", q);
  render(result);
}

which outputs

#{list result, as:'p'}
<li>
  <a class="ui-widget ui-widget-content" 
    href="@{Participants.show(p.id)}" >
  ${p.name} ${p.lastname} (${p.id})
  </a>
</li>
#{/list}

And as a result

That afternoon i had some more time to implement barcode checkins so i called @burakdalgic to learn that we would be getting a text file out of that barcode readers and users will be uploading them. As the documentation says, it could not be more simpler.

public static void install(Hall hall, File dump)
    throws FileNotFoundException, ParseException{
  Scanner scanner = new Scanner(dump);
  while(scanner.hasNextLine()){
    String line = scanner.nextLine();
    String[] entry = line.split("\\|");
    Date parsed = new SimpleDateFormat(
      "dd.MM.yyyy hh:mm:ss").parse(entry[1]);
    CheckIn checkIn = new CheckIn(entry[0], hall, parsed);
    checkIn.participant = Participant.findById(
      Long.valueOf(entry[0].substring(13)));
    checkIn.save();
  }
  main();
}

In java that is. It would be more concise with functional programming paradigms and anyone who can’t live without them is free to use scala.

I filled my remaining free time trying to figure out how to generate a pie chart with flot which took something like 2 hours. Say, 3 minutes of that 2 hour went to write required jpa-ql so remaining 1 hour and 57 minutes seemed too much time for just a pie chart after all that work in play. Alright, lack of experience with flot is responsible for much of it but i knew almost nothing about play either. However could write a whole another application in that time. Wasting time on less important thing, i went to bed again on time, cause there were only a handful of things left to do.

Saturday morning, after a late breakfast, another 2 hours got me a fully working application with solid layout, barcode checkins, reports and CRUD screens. Sleepless nights aside, we went to the barbecue party at our friends’ house and got some alcohol into our systems. Sunday afternoon, we met to iron out some details about barcode data format, and i didn’t even need to tell anything about play. Because the code was just simple java methods, HTML and javascript; @burakdalgic was able to pick just where i left and move on[to his work of UI].

Well, i mentioned the effort took two days but it seems it wasn’t even whole two days. Just some hours scattered over a weekend and we had what we needed. I wasn’t at the operations or front desk so i don’t know how it went the first hand but that’s a good thing from another angle: they didn’t have major problems [apart from the problem that we started running it in development mode to have some crashes which was fixed as soon as we switched to production] so i didn’t have to be there. For a two day application that is a great technical outcome. And from what i have heard from my collegue, users were pleased with its usage and performance. ‘The bottle neck on the desk was the printer’ he said.

dev derby 2010

Reblogged from lawrence mcalpin:

This weekend, on September 11, 2010, I took part in the Dev Derby 2010.  This was a contest where teams were split up by programming language, and challenged to create as usable and fully functional a program as possible in only six hours.  Sadly, some teams, such as Justin Ko’s Team Ruby, were shorthanded.  However, the PHP and C# teams put up a good fight.

The challenge was to design a software system that could be used to match non-profit organizations with volunteer groups that offer services that match their needs.  There were a number of criteria that we had to meet, such as implementing some external API (most people chose some form of Single Sign On) and implementing all of the required features for the application.

I’m happy to announce that my team, Team Java, won the challenge.  More so, our system was the only one that worked end to end. 

Some might wonder how we did it: well, I started out doing what I do with everything else - I first identified the best tools for the job. And sometimes those tools aren’t the ones we normally use.

At work, as an enterprise Java developer on Wall Street, I normally use a particular stack of frameworks: Spring, JSF, Hibernate.  I think they are the right tools for that job.  The usual development cycle involves coding - compiling - deploying the updated code - restarting the server/process/container - relogging in and whatever else to get back to wherever you were - and then, finally, retesting.  (Of course, we employ automated test suites as well.)

For the contest, we were building a webapp, and competing against languages like Ruby, Python, and PHP that do not have the compile and deploy stages: it’s simply code - hit refresh and test.  Over the long term, that’s not a huge advantage, but in a contest that lasts only six hours, that would have killed us.

So our secret weapon was the Play! framework.  This is a very easy to use to framework.  How easy was it? Well, none of the other six team members had even heard of Play! before the contest.  I sent out a document only a week before the challenge describing how to use it and only two people really read it.  The rest learned as we coded. 

Play! is a very agile framework that is completely stateless and recompiles changes to your codebase transparently - so it erases the advantage that dynamic languages have by not needing a compilation step.  In the meantime, we still benefit from the advantages of static typing that Java gives us, protecting us from a large number of time-wasting bugs.  Certainly, there are certain types of problem domains that are easier or only possible in dynamic languages (that’s why there are no pure static typed languages: they all offer some way to subvert the type system such as reflection or casting), but for a webapp those problems aren’t applicable.

We were allowed to use libraries that would help us in meeting the coding challenge.  Play! has a lot of plugins available for it: we used Search to implement full text search in our filters, and Scaffold to rapidly generate prototype screens.

While not a Play! plugin, we also used the java-facebook-api which was incredibly easy to use when adding Facebook Connect access to the system.

I’m very pleased with how well our use of the Play! framework turned out (even if I’m not entirely pleased with how our CODE turned out: hey, in only six hours, you have to make a few allowances… :) ).  It was a fun challenge, and I hope to try again next year.  Hopefully the Ruby team will have better luck assembling their team so I can show all the cool kids how you should truly achieve web scale webapps.  At least the Zend-spinning PHP geeks got the message.  (Luckily for C#, Microsoft was on hand with paid counselors to help them cope with the loss with promises of improvements in Visual Studio 2011 that would make them more competitive… well, not really, but they should have been!)

My contribution to JS1k

So here it is: Colored isometric 3d objects that bounce on mouse over.

My idea was to do something you can interact with. I’ve started with a more complex object but I’ve realized soon enough that it would be too difficult to minimize.

Minimizing the code was the fun part of course. Here the final line, hand made, 1024 bytes exactly:

Learning scala, the easy way

Learning the scala language can be fascinating. But as I said in a previous post, the tooling is still pretty immature; installing and making the scala plugin work for any IDE can be very painful and it will likely discourage any newcomer.

I think that using play is currently one of the best way to test scala, thanks to its hot reloading feature and to its perfect error reporting.

So I’ve created a bundled version of play framework + the scala module + a nice application that let you try the language features in an incremental way.

Basically you have a scrapbook.scala file executed at each refresh, and all the results of the print(…) calls are displayed in the page.

As for any play application, errors are beautifully displayed and help you to find out what is the error cause;

Of course you can also experiment scala with the integrated REPL, but I think it is easier with the confort of a real text editor. You can easily define classes, methods, implicits, etc…

So if you are interested by giving scala a try, you should download this package and start playing!

Why there is no servlets in Play

Creating a Java web framework without relying on the Servlet API can seem very strange. Most people ask why this uncommon choice? Some love it, others hate it. To be honest the very first versions of the play framework were using servlets and were running in a servlet container. But there are many good reasons why we decided to remove this requirement. I’ll try to explain.

There are two important points (among many others) in play framework: it is based on a completely stateless architecture model, and it auto-magically reloads your code changes. In fact these two points are intimately imbricated.

Making an application stateless is the only way to allow code hotswapping. Have you ever wondered why it just works with PHP while it’s not possible with JEE (I mean, not redeploying the war in the background, but really hotswapping the application code)? It’s just because PHP is totally stateless; between two successive requests, it will restart a fresh PHP process (OK there are some optimizations now using FastCGI but it doesn’t change the underlying model). If your application is not stateless, there is no way to rebuild the in-memory state after the code swap. It could work on some cases, but it will likely fail after any important change.

Allowing code hot swapping is not the only reason why we decided to make of play a stateless web framework. It’s not really the point of this post, but basically, it’s just because the WEB itself uses a stateless architecture. And there are very good reasons for that.

Now, you can always use the servlet API and build a stateless application with it. However you’ll have to refrain from using some features like the HttpSession or the servlet forward mechanism. That’s what we did on the first versions of play framework.

But sincerely, people don’t want access to the servlet API because they love it. Everyone agree on the fact that it is the worse HTTP API ever conceived. No, they want to access the servlet API to be able to reuse existing servlet based components like servlet filters, etc.

The problem with these components is that they are usually poorly designed. They store objects in the session, mess with your HTTP requests and responses objects in your back. So there is a great chance that installing a component like this will break the initial stateless contract of play and lead to a lot of class reloading and class cast problems. It is also because your application has to live in a play custom classloader in order to be reloaded. And to be used the servlet components need to live in the servlet container classloader. Do you need any cooperation between these components? Of course you do. And it will be a nightmare.

In fact there are two kinds of servlet based components. I was faced to this problem when I was searching for a captcha library for play. Some use two well separated layers, one with the captcha generation logic, and the other one for the servlet API integration. The other kind is a mess of imbricated code that you can’t use without using the servlet API yourself. For the first kind you can always use them with play by using only the interesting part. For the other kind, chances are high that it would have broken your application if you were able to install them in play.

Finally there is a last reason why we don’t use the servlet API anymore. A servlet container uses an old fashioned “one thread per request” model. It can be OK for some applications. But these days with all these Ajax and long polling calls, it is not enough.

I think that the fundamental problem is that using the servlet API is the only way you can plug with the HTTP layer of a JEE server. Perhaps the java ecosystem needs something like Rack. I mean, a real low level and portable API to deal with HTTP. Not an half assed HTTP API built on some flawed architectural principles.

My thoughts on Scala

Well, I’m not a Scala master. For now I’ve mostly used it to create the play’s Scala module and tested it with small applications. I had the chance to meet some more experienced people and to discuss with them about the best way to use it.

However this first experience was pretty exiting and helped me to understand what could be the future of Scala. Is Scala a complicated language to learn? Yes I think so. But it is also a Scalable Language; it was the goal of the language design and I think it is really the case: it gives some incredible power to framework creators while letting the end-developer dealing with a very simple API (a very clean DSL in most cases).

Applied to play it is the ideal use case. Even if it requires some really tricky hacks in the core of the play’s Scala module it allows to write a web application in a very expressive way;

Most of the time you can just concentrate on your application without having to deal with technical boilerplate. I guess we have already done a pretty good job on the Java API but Scala gives us more power to do that.

There is some features that really saved our life while creating the Scala module. The native singleton objects definitively remove the nightmare of dealing with static members. The package objects allowed us to keep a coherent API between Java and Scala. And of course the implicits make pimping the existing Java API a breeze.

Traits really allow to reuse and mix several concerns in your controllers. And default arguments solve one of the most problematic issues of the play’s controller API;

Of course all these new concepts can scare a Java developer. But really as a play developer you just have to use them. And I think that it is really straightforward.

Finally a simple way to start with Scala and a play application, is perhaps to just use the new ScalaTest feature that allow to write your test case in a very expressive way;

Now there are still small problems with Scala. These are not related to the language itself but to the tooling that is still pretty immature. Even though the Scala compiler is awesome it’s really slow and has some difficulties to handle incremental compilation (even if the new, currently beta, 2.8 release has done huge progress in this area), and the error reporting can sometimes be a little cryptic. 

Anyway I’m sure these problems will be solved soon when the language will gain even more interest. And then using Scala for your projects, specifically with play as application framework will really change the way you will create your next web applications.

I’m pretty sure of that.

You are what you eat — La bourse ou la vie

In Japanese too

http://playdocja.appspot.com/

A simple hit counter implemented with Software Transactional Memory (STM), using the akka module for The Play! framework.

There should be no business logic in a controller. Read that again. There should be no business logic in a controller.

— Josh Symands; Same apply for play 

Releasing on launchpad; the python way

play 1.0.2 released — what’s next?

Since we released play 1.0 in october 2009, there was a lot of interest about it. It has been downloaded almost 70,000 times in only 5 months and the community has grown to several hundred of users. More importantly, the users feedback has been awesome; we almost have only positive reactions.

Today I’m pleased to announce the release of play 1.0.2 - This version is a maintenance release of the play 1.0 serie. It should be the latest important release of this serie. The now large community gave us a lot of feedback that allowed us to build this rock solid final version.

Now it’s time to concentrate our efforts working on play 1.1 that we hope to release this summer. So what’s new for this version? First, it’s really important for me that everyone understand that play framework is not only about technology but about simplicity and usability too. That’s why people love play framework: because it just works, it has a steep learning curve, and it doesn’t try to over abstract and complicate things.

So simplicity and usability are still the focus for play 1.1. I want to keep a light and rock solid core framework component and let the community build features around it: the main work for play 1.1 will be internal refactoring to allow even better modularity. Among these ones, play 1.1 will come with new languages support, new rendering types and better support for non-JPA based persistence engines.

But now it’s time to play with the 1.0.2 release; stay tuned!

Playframework from the source - Working @ zenexity

Spotify is great but really misses of a media-center ready application. Why not a web application? And even a play based one? 

Started here - http://github.com/guillaumebort/play-spotify - And pure Java