Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

use Perl Log In

[ Create a new account ]

dami (6728)

dami
(email not shown publicly)

Journal of dami (6728)

Wednesday June 20, 2007

04:22 AM

plat_forms report published June 20th, 2007

[ #33559 ]

The results and final report of the "Plat_forms" international programming contest were released yesterday in a press conference in Nuremberg, and will be published today June 20th, 2007 on http://www.plat-forms.org/.

For each of the categories Perl, PHP and Java, three teams of three people each competed to produce a comprehensive "social networking" application in just 30 hours.

Team Etat de Genève / Optaros was declared winner of the Perl track. The Geneva solution, based on Catalyst and DBIx::DataModel, was especially praised for its compactness. However, other Perl solutions by "plusW" (Germany) and "Revolution Systems" (USA) were very close, and it was hard for the jury to decide. The report notes that compactness and extensibility are consistent qualities of the Perl solutions.

For the Geneva team, that was a really instructive experience. It confirmed that we work with the right technology and skills ... but also showed that we still have some progress to make as a team in the priorization and quality insurance processes!

See http://www.plat-forms.org/ for the complete report and for many interesting observations on these 3 development platforms. A detailed report of what happened in Geneva team is published on http://www.plat-forms.org/2007/blog/archive/2007/01/29/journal-of-team1

List all Journal entries

Plat_Forms Report Published More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Response to Plat_forms conclusions? (Score:2)

by brian_d_foy (44)

The full Plat_forms report notes that all the of the Perl teams had trouble implementing the web service requirements and that the Perl solutions did not stand up to malformed URL attacks. Any comments on why that is?
- Re: (Score:1)
  
  by dami (6728)
  
  Web service : yes, that is true. The requirement was a complex WSDL interface and none of the Perl teams found any CPAN module powerful enough to do that; and doing it by hand in 30h. was just impossible.
  
  About attacks: I guess you mean SQL attacks. We used bind parameters, so we don't agree with what the report says. True enough, the application did not do too much checking on the input, but then wrong data was rejected by the database, and you got an unfriendly error message. That's not nice to the user
  - Re: (Score:2)
    
    by TeeJay (2309)
    
    URL attacks are not necessarily SQL Injection - could be XSS, abusing url redirection, setting env vars, modifying session/user/etc id's. Lots of things - what do they actually say in the 118 page report?
    
    --
    
    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
    - Re: (Score:1)
      
      by stu42j (6348)
      
      They considered it a failure if an error is returned from the database, rather than the application logic, when testing for SQL Injection. Although, they admit that it is probably not an actual security risk. They also tested for XSS attacks by entering simple html. Non of the Perl teams handled it in a way they considered acceptable. As far as I can tell from my skimming of the report, no actually security breaches were found, only what they considered to be potential problems.
      - Re: (Score:1)
        
        by rolf (7972)
        
        For Xss that's not true. As a member of one of the teams I know, that we did html filtering on the user input. And the result shows on page 43 , that two of the perl teams are Ok here.
        Also we do not agree what they say about SQL injection. We were using DBix::Class and relied on bind params. We did no actual filtering of the input or length checking (what I agree is a mistake).
        Also trying to insert 8 byte chinese ideograms while internationalisation was no requirement at all is a bit, well, strange to
- Re: (Score:1)
  
  by rolf (7972)
  
  As dami said, it was a complex WSDL interface and I (as member of team plusW) absolutely had no experience with this and I didn't find a way to map what I implemented with SOAP::Lite to was required in the WSDL.
  Another problem while developing this was, that we had no test client for the SOAP interface. I could test it with my own perl client, but I would have preferred a client from the organisers to test it.